Welcome to IDEs

So when you start learning how to program, if you were like me, you started writing out on paper:

public static void main(String args[]) {

           System.out.println("Hello World");

}

Then some friendly upperclassman who told you to write that out on paper introduced you to somewhere for you to type your code in, and then introduced you to saving that file, compiling that file, and finally running it. Wallah, "Hello World" printed.

That "somewhere for you to type your code in" may well have been Notepad that nearly every version of Microsoft Windows comes with. I pray that your text editor was not a full blown word processor like Microsoft Word, because you definitely do not want your program saved as a .doc file; it's just not going to compile with all of the hidden formatting data MSWord includes by default. It's a pain.

Hopefully at some point, somebody or some programming resource pointed you out to something called an IDE. "IDE" stands for "Integrated Development Environment." In layman's terms, that basically means "text editor that makes it easier to code." An IDE often includes an automatic code formatter that fixes indentation or catches syntax errors, a debugger that helps with verifying code, and automatic code compilation and running, so you don't have to switch windows to run your code.

While terminal-based text editors like vim, emacs, and nano are great for fast edits and simply not needing to drop outside of the convenient terminal, IDEs are very useful for a more visual debugging experience, but using text editors prevents one from being handicapped by an IDE's autocompletion feature. This is not to say autocompletion features are not available in text editors, but they usually require extra configuration on the developer's part. Both terminal-lovers and IDE-users aim for the same effect: minimizing the context switching needed in order to code, test, debug, and improve code.

Eclipse, the most widely used Java IDE in industry

NetBeans IDE 7.1: Key to the Java EE 6 Platform. (2012, March 1). NetBeans IDE 7.1: Key to the Java EE 6 Platform. Retrieved May 17, 2014, from http://www.oracle.com/technetwork/articles/java/unlocking-1540042.html

 

 

Huffman's encoding

Huffman's encoding is an algorithm that, given a file to encode that consists entirely of all of the letters present in an alphabet alpha, and the frequencies of each letter appears in the file for all of the letters in alpha, returns a binary search tree that gives a prefix-free encoding that is guaranteed to use minimal space.

What does "prefix-free" mean? Let's try to encode two letters, "a" and "b" as an example. Say that "a" has an encoding of "00", and "b" has an encoding of "0". Then if I have a string I want to decode that is "00000", how do I know which parts of this string are "a"s, and which parts of this string are "b"s? For this example encoding, one would not be able to tell where one letter ends and another begins without a prefix. Note that we wouldn't have this encoding problem if every single letter in the alphabet had the same length encoding, but that we wouldn't be able to get a minimal encoding taking advantage of the alphabet frequencies we know, if everything was of the same length.

Huffman's encoding first puts all of the letters into a priority queue, prioritizing by the frequencies in an ascending manner, with the two letters with the two smallest frequencies at the head of the queue. Then these first two minimum frequency letters are dequeued and a new parent "node" is created from those two letters, with the two letters as children, and with the node's frequency equal to the sum of the two letters' frequencies. This new parent node is then inserted back into the priority queue. Note that this reinsertion is done on a priority queue, and not just a queue, so the ascending order still holds true. Repeat this tree generation until only the root node is left in the priority queue. This results in the root node consisting of a traversable binary search tree that can be used for decoding.

Dasgupta, S., & Papadimitriou, C. H. (2008). Algorithms. Boston: McGraw-Hill Higher Education.

Beta testing

Beta testing means having a small set of users try out your product before the actual product release in order to get feedback. The difference between beta testing and alpha testing is that the test users involved in alpha testing are from the development team, whereas users testing in beta are not from the development team. "Beta testing" is also known as user acceptance testing (UAT), customer acceptance testing (CAT), customer validation (CV), field trials, and pre-release.

Beta testing done badly means beta testing performed while not knowing the point of testing. Having potential users test an incomplete product is a waste of time on both the developers' end and the users' end. More testing would be needed after the product is finished anyway. Having not enough testers to reach a significant conclusion also defeats the purpose of testing in the first place, and having too many testers when a test's question has already been answered is also inefficient. Of course, a beta testing run should be designed well to the point where test managers understand why they are conducting the tests they are conducting. This means understanding different design possibilities for the product, and understanding how each test will clarify which design possibility is better for the product's purpose.

Learn About Beta Testing. (2014, January 1). Centercode Beta Blog. Retrieved May 17, 2014, from http://www.centercode.com/beta/