How to Optimize Your Website Checklist

 Yottaa’s website optimization checklist. Very insightful.

Micro-services Architecture - by StrongLoop

A good read on Loopback API framework. Below is the end to end Loopback API framework architecture for model driven development from StrongLoop Blog.

The Mixology of Databases - from DZone

Which Programming Language to choose? - Lifehacker

What to throw, Checked or Unchecked Exceptions?

If you throw a checked exception (and don't catch it), you will need to declare the exception in your method's throws clause. Client programmers who wish to call your method will then need to either catch and handle the exception within the body of their methods, or declare the exception in the throws clause of their methods. Making an exception checked forces client programmers to deal with the possibility that the exception will be thrown.

If you throw an unchecked exception, client programmers can decide whether to catch or disregard the exception, just as with checked exceptions. With an unchecked exception, however, the compiler doesn't force client programmers either to catch the exception or declare it in a throws clause. In fact, client programmers may not even know that the exception could be thrown. Either way, client programmers are less likely to think about what they should do in the event of an unchecked exception than they are in the case of an checked exception.

The simple guideline is:
If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.

Note that when String.charAt(int index) receives a bad input, it doesn't throw RuntimeException or even IllegalArgumentException. It throws StringIndexOutOfBoundsException. The type name indicates that the problem was a string index, and the program can query the object to find out what the bad index was.

Here is a collection of the exception guidelines put forth by an article:

• If your method encounters an abnormal condition that it can't handle, it should throw an exception.
• Avoid using exceptions to indicate conditions that can reasonably be expected as part of the normal functioning of the method.
• If your method discovers that the client has breached its contractual obligations (for example, by passing in bad input data), throw an unchecked exception.
• If your method is unable to fulfill its contract, throw either a checked or unchecked exception.
• If you are throwing an exception for an abnormal condition that you feel client programmers should consciously decide how to handle, throw a checked exception.
• Define or choose an already existing exception class for each kind of abnormal condition that may cause your method to throw an exception.

Here's a summary of the mechanical aspects of exceptions:

Runtime exceptions

• A method signature does not need to declare runtime exceptions
• A caller to a method that throws a runtime exception is not forced to catch the runtime exception
• Runtime exceptions extend from RuntimeException or Error

Checked exceptions

• A method must declare each checked exception it throws
• A caller to a method that throws a checked exception must either catch the exception or throw the exception itself
• Checked exceptions extend from Exception

Java Checked vs Unchecked Exception

Some guidelines about check and uncheck exception:

• Only exceptions that will cause a method to complete abruptly should appear in its throws clause.

• There are two kinds of exceptions in Java, checked and unchecked, and only checked exceptions need appear in throws clauses.

• Any checked exceptions that may be thrown in a method must either be caught or declared in the method's throws clause.

• Whether or not an exception is "checked" is determined by its position in the hierarchy of throwable classes.

• To create a new checked exception, you simply extend another checked exception. All throwables that are subclasses of Exception, but not subclasses of RuntimeException are checked exceptions.

• Most unchecked throwables declared in java.lang (subclasses of Error and RuntimeException) are problems that would be detected by the Java virtual machine.

• Errors usually signal abnormal conditions that you wouldn't want a program to handle.

• If you are throwing an exception to indicate an improper use of your class, you are signalling a software bug. The class of exception you throw probably should descend from RuntimeException, which will make it unchecked. Otherwise, if you are throwing an exception to indicate not a software bug but an abnormal condition that client programmers should deal with every time they use your method, your exception should be checked.

• At least one clause, either catch or finally, must be associated with each try block. If you have both catch clauses and a finally clause with the same try block, you must put the finally clause after all the catch clauses

Why set download header to x-download?

It’s important to set the Content-Type header to a non-standard value such as application/x-download because, although the HTTP specification provides a mechanism for file downloads, many browsers second-guess the server's directives and do what they think is best rather than what they're told.

These browsers--including Microsoft Internet Explorer and Opera--look at the file extension and "sniff" the incoming content. If they see HTML or image content, they inline-display the file contents instead of offering a Save As dialog. Turns out there are no 100% reliable ways to download a file across all browsers.

According to a reference site, the HTTP specification recommends setting the Content-Type to application/octet-stream. Unfortunately, this causes problems with Opera 6 on Windows (which will display the raw bytes for any file whose extension it doesn't recognize) and on Internet Explorer 5.1 on the Mac (which will display inline content that would be downloaded if sent with an unrecognized type). So, the best way to cater for max scenario case coverage will be to set to application/x-download.

Some Java String & Collections API notes

Some summary of String and Collections API usage to remind myself :)

Criteria to choose among String, StringBuffer and StringBuilder:
1. If your text is not going to change use a string Class because a String object is immutable.

2. If your text can change and will only be accessed from a single thread, use a StringBuilder because StringBuilder is unsynchronized.

3. If your text can changes, and will be accessed from multiple threads, use a StringBuffer because StringBuffer is synchronous.


Collections API:
1. Vectors and Hashtable classes are available from the initial JDK 1.0. But, ArrayList and HashMap are added as a part of new Collections API since JDK 1.2.

2. Vectors and Hashtable are synchronized where as ArrayList and HashMap are unsynchronized.

3. Use Vector if there are multiple threads and ArrayList if there is only a single thread.

4. Use Hashtable if there are multiple threads and HashMap if there is only a single thread.

Merge log files and sort the records in Linux

Recently I need to do merging of log files and sort the records according to timestamp. This is what I did, use the bulk replace file extension way to change the log files to .txt files, then applied the following command through Shell script.

#!/bin/sh

export MFILE=merge_file.txt
export SFILE=complete_file.txt

for file in `ls *.txt`
do

cat $file >> $MFILE

done
sort -k4,4 $MFILE > $SFILE
rm $MFILE


Note:
Log files are expected to have same format, otherwise the sorting will not be possible.

-k, --key = POS1[,POS2], means sorting by start a key at POS1, end it at POS2 (which is where the timestamp position in my log files)

Bulk replace file extension in Linux

Recently need to do a mass rename of files extension to another in Linux environment. I rename them one by one using "mv" command, which is super slow if talking about 200 over files. Thanks to Sunny who provide me the following solution:

Replace all '.txt' file extension to '.log' extension and display "rename" command in console:
ls *.txt |awk ' {s=substr($1, 1, length($1) - 4); print "mv " s ".txt " s ".log"}'

Executable mode of bulk replace file extension from '.txt' to '.log':
ls *.txt |awk ' {s=substr($0, 1, length($0) - 4); system("mv " s ".txt " s ".log")}'

This save me lots of time, probably yours too. :)

Thanks again, Sunny!