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/

Usability testing is a fact of life

Look, no matter what you're making, the reason you're making whatever it is that you're making is for some user's happiness. In more formal economic speak, you wouldn't be doing what you're doing right now if it didn't provide you some marginal utility over your one nanosecond ago past state, with that marginal utility factoring in anticipated difference in possible utilities gained.

Citing this self-evident fact, usability testing is essential in software development. There is no point to a creation if the reason for creation was for it to be used, but the creation is not usable.

Up to this point I've spoken in the most generalist of terms. Usability testing means making sure your product is optimized for your user. It means avoiding glaring blind-spot stupid design faux pas by checking in with reality, then avoiding more subtle design mistakes, and then making sure your product works really really well. Designing these tests isn't a 1-2-3 easy matter though.

Or maybe it is. Let's see the most basic pattern of basic test creation processes:

1. Ask then answer: "What do I want to have happen?"
2. Ask then answer: "How do I know what I want to happen is actually happening?"
3. Make a test based on your answer to step two.
4. Make sure your input to your test makes sense.
5. Run your test.
6. Make sense of your test results.

So six steps - about double the essence of simplicity. Even then, the dependency involved in all of those steps hinges on the subject of matter in step one: what are you testing? This is a classic case of "the more thou knowest thyself, the more effect thou wilt be."

That is your bi-weekly dose of wisdom.

Blogs I advocate

Google Testing is a must-read for any serious software developer who cares about code maintainability, and what is considered best practice in the industry. I found the blog via their post on testing doubles, and highly recommend following going through "Testing on the Toilet".

Cal Newport is a Dartmouth and MIT graduate who lately became an assistant professor in Computer Science at Georgetown University. I've found his Straight-A post series to be an inspiring condensation of educational common sense, and his driving philosophy that "mastery leads to passion" a gem to keep life in perspective.

Joel on Software is much lauded and you will often find him referenced elsewhere on the Internet. His post on 12 Steps to Better Code is a must-read. The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) is something you will eventually read, no matter what you think now.

Martin Fowler writes excellent posts on software design, Agile development, code refactoring, and NoSQL.

42Go Engineering always writes crazy interesting posts for Scala developers.

JOOQ offers neat perspectives on SQL practices.

QR codes

Visit my LinkedIn profile by scanning this QR code!

What are QR codes?
The "QR" in QR codes stands for "Quick Response." QR codes are a type of barcode invented in 1994 by the Japan-based Denso Corporation in an effort to store more information than the usual vertically striped UPC barcodes:

A QR code involves a square grid of black and white bits, and can either range from a 1x1 square, to a 40x40 grid. The larger the grid, the more information can be encoded. A QR code is essentially a method of information compression. Although it was initially used to store information on manufactured components by Denso, after its release to the public, QR codes are now often used to store URLs to websites or URLs that allow access to applications. 

There are four levels of error correction possible for QR codes: Low (7% codeword restoration rate), Medium (15% codeword restoration rate), Quartile (25% codeword restoration rate), and High (30% codeword restoration rate). For example, with a Quartile QR code, as long as more than three-fourths of the QR code is not damaged, the QR code will still work. The general way to think of it is: "as long as the damaged fraction of the QR code doesn't exceed the codeword restoration rate, the QR code will still work."

How do you use a QR code?

1. Find a QR code scanner for your phone, be it a Blackberry, an Android, or an iPhone.
2. Scan the barcode.
3. See where the barcode takes you!

Why it's important to encrypt your data

People generally only care about securing their data and ensuring their own privacy as far as it is convenient to do so. According to A Large-Scale Study of Web Password Habits published by Microsoft Research in 2007, "Users choose passwords with an average bitstrength of 40.54 bits. The overwhelming majority of users choose passwords that contain lower case letters only (i.e. no uppercase, digits, or special characters)."

The "nothing-to-hide" argument is invalid. Just because one has nothing to hide does not necessarily mean that one has nothing to show. "Having nothing to hide" is equivalent to saying "having nothing one would not be willing to show," which means one is totally comfortable with the potentiality of identity theft that comes with a lack of security. Identity theft notwithstanding, one also needs space in order to think and develop one's identity.

Security is a tradeoff between convenience and privacy.

http://research.microsoft.com/pubs/74164/www2007.pdf
http://www.techhive.com/article/226785/encrypt_your_hard_drives.html
http://www.wired.com/gadgetlab/2012/11/ff-mat-honan-password-hacker/all/

Kravats, D. (2013, April 23). Here's a Good Reason to Encrypt Your Data | Threat Level | Wired.com. Retrieved from http://www.wired.com/threatlevel/2013/04/encrypt-your-data/

A Comparison of Open Source Java Web App Frameworks: Spring vs Play!

---

In the old days, Java web programming was done with Java Web Servlets, and HTML was embedded inside of Java "servlet" code that was placed in "web containers" that interacted with actual servers. This is what servlet code looks like:

Click the sample code above to see a more full-blown example of the process.

Every single time servlet code changes, one needs to stop and start the server running the servlet. This doesn't sound like a big deal; after all, most coding workflows require recompilation and re-execution for every change we make.

As this StackOverflow answer says, Spring is a framework that primarily serves to "wire" components together.

Inspired by Ruby web application frameworks such as Rails and Sinatra, Play Framework differs from Spring in that it supports Scala development and it detects changes to files and automatically recompiles and restarts the server on those changes.

Packaging for distribution in both Play and Spring are both rather straightforward. Either run "play dist" for Play or "./gradlew build" for Spring.

Both Play and Spring support asynchronous programming with Comet WebSocket.

---

What does the Spring framework do? Should I use it? Why or why not? [closed]. (n.d.). java. Retrieved March 17, 2014, from http://programmers.stackexchange.com/a/92672/79516 Spring. (n.d.). Spring. Retrieved March 17, 2014, from http://spring.io/

About Me

This is a practice post in preparation for the Summary snippet on LinkedIn.

---

I'm interested in mastering functional programming techniques, becoming more efficient in web development, and visualizing data.

I worked with basic NodeJS in my Spring 2013 coursework, and picked up JQuery two weeks before the summer started. At my first internship during the past year, I've built an internal web app that essentially acts as a Google Docs & Google Forms replacement with pagination using Scala Play, PostgreSQL, and ExtJS.

In addition to learning new frameworks and Scala, I've learned a lot on how to code and about myself.

• Automated testing can literally save months by shortening how long it takes to get feedback on code and preventing regressions.
• Git is essential for being the time machine for code that it is.
• Always understand "best practices" before writing any code.
• To deal with the current reality, no matter what my previous time expectations were.
• The more I don't know, the simpler problems seem, and the more likely optimistic underestimates will happen.
• Rest is necessary for productivity. "Enjoyment predicts efficiency." - Eric S. Raymond.

I am currently dabbling in Javascript visualization library D3js and the Neo4j graph database in my spare time, along with Java Play and Haskell for some school projects. Any opportunities involving contact with experienced developers in Haskell, Java, Scala, Play Framework, Neo4j, or D3js are especially welcome.

---

On Management and the Maginot Line. (n.d.). On Management and the Maginot Line. Retrieved March 16, 2014, from http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s12.html