Monday, November 28, 2011

My Learning Java Best Books List

After several years of working with Java I've come up with a list of books I've used and some on my future reading list, which I believe will make me a better Java developer.

Absolute beginners start here:

This happened before I started reading...

These titles are also great for beginner's, yet dig a little deeper and help build a strong foundation:

Intermediate materials:

Advanced topics:

Monday, November 21, 2011

Polyglot Programming

Although not new, polyglot programming is the programming concept I've been seeking and love that I can now give a name to the topic. I've got this sneaking suspicion polyglot programming is going be revolutionary, will take the industry by storm and bring the fun back into programming.

I'm so glad to be a part of this exciting development and learning more day-by-day learning  the roots of programming and exploring the variety of languages that run on the JVM to expose me to these ideas. Sometimes overwhelming, always exciting, this is the world of polyglot programming.

Checkout this interesting interview with Venkat Subramaniam, founder of Agile Developer and a proponent of polyglot programming, concerning scala, groovy and the JVM.

There is also a new book from O'Reilly titled, The Well-Grounded Java Developer, that dives into the polyglot phenomenon occurring on the JVM and the advances of Java 7 to embrace dynamic languages. Check out chapter one from the Manning Early Access Program for free.

Two other great books in this arena are Bruce Tate's, Seven Languages in Seven Weeks and Dean Wampler's Functional Programming for Java Developers.

Dean Wampler runs a polyglot programming site to support the this growing community and also writes an interesting blog on the subject.

Friday, November 18, 2011

Agile or not, this stuff works!

I don't have formal agile training, but being on a variety of development projects I've seen what works. Here is my short list for development project success:
  • Find a team manager who is technical, a detail-oriented planner, and can work at 10000 feet and ground level
  • Select a project coordinator who also has a high level understanding of the project and ensures that team coherence is kept and communicates progress across business lines
  • Nominate a tech lead who has a strong point of view, is not technically biased, who periodically reviews what the team is checking in to ensure a certain level of code quality, cohesiveness and consistency
  • Create a business requirements document, which details program functionality to a level of minutiae that can be coded to with certainty
  • Come up with project milestones based on the business requirements before any design is done and go through the document as a team to ensure understanding
  • Break down the milestones into high level tasks, divide and assign to developers to flush out work required and swag estimation times; review with the entire team
  • Pad time in the initial estimated total project time for incidental things like code refactoring, benchmarking and profiling, proof of concepts that may result in dead ends
  • Review developer tasks at the beginning of each sprint (3 weeks works nicely) and have the developers explain what the tasks are in the sprint planning kick-off meeting
  • Use an agile project tracking tool at each stand-up meeting to go around the room, ensure developers are logging time and updating time left for tasks
  • Have 3 stand-ups a week and "parking lot" issues to the end of the meeting that not relevant to the review of the tasks in the sprint
  • Require standardized design documents (provide a template) and design meetings for code or functionality that is not trivial
  • Require peer code reviews before check-ins are committed
  • Use a bug tracker and integrate the tracking numbers in commit messages when code is checked in
  • Ensure QA list exact steps to re-enact a bug when they are written up
  • Provide details in the bug tracker, that may help QA retest fixed bugs
  • Invite QA to attend stand-up meetings to discuss testing and bugs, if there is a showstopper immediately delegate the who, what when for resolution
  • Automate a unit test build, a full regression test, which when failed requires the immediate attention of the dev team so as not to compound issues
  • Enforce the use of the planning, tracking, and build tools
  • Present the entire team when there is an innovation to be considered ask that developers float ideas to team leads to limit unnecessary debate
  • Decide as a team before changing core functionality, 3rd party libraries or technologies, coding or workflow conventions
  • Document and enforce coding standards, IDE tool usage, programming languages, and code formatting style - using shared templates and code coverage tools as much as possible
  • Document development processes, systems, and common practices in a wiki
  • Store design documents, charts, and business requirements in a document repository

Thursday, November 10, 2011

Developer Must-Have Knowledge

This post is going to be a work in progress. Here is a list of typical developer must-have knowledge you'll encounter in many coder interviewing books. I'm going to be looking into each these topics, and expanding on this article as to why these bits and pieces are considered crucial and what the underlying concepts highlight.

Data Structures
Linked Lists
Binary Trees
Vectors / ArrayLists
Hash Tables

Breadth First Search
Depth First Search
Binary Search
Merge Sort
Quick Sort
Tree Insert / Find / etc

Bit Manipulation
Singleton Design Pattern
Factory Design Pattern
Memory (Stack vs Heap)
Big-O Time

Other bloggers writing similar stories:

What programming language should I learn next/first?

I'm always looking for posts about what programming language I should learn next to help me become a better programmer.

My brother-in-law was asking me just this question, which led me to come up with the answer I hold currently. Please take my advice lightly since much of it is base on my own opinion and I've not yet had the opportunity to learn the languages I'm going to talk about, but this essay delves into the thinking a bit of why I choose to go the direction I am headed in for the moment.  It is yet another opinion you can think about as you might be asking yourself the same question.


To start things off here are a few good articles that I've come back to over the years, which are definitely worth reading if you are interesting in programming or thinking about learning a new language or taking your skills to the next level:

I recommend learning a dynamic language such as python, ruby, scala, haskell, or clojure (maybe even Perl, Jython or Groovy). There is something to be said about the type of communities that exist behind these languages. They are dev centric and not driven by the "market".

Scala, Clojure, Jython and Groovy run on top of the JVM, so they allow you to use all the java libraries you can find out there. There is even a version of Smalltalk that runs on the JVM, but it is relatively new.

Ask yourself which would you gain the most from learning the language you are interested in right now? What are your personal goals and motivations, what do you need to get back in order to stick with it?

Perl is getting long in the tooth, but still used everywhere. It is flexible, easy to learn the basics, although the syntax is horrid and you will run into some of its limitations rather quickly once you begin building more complex programs. It is a great glue language and good for quick and dirty scripting and automation.

I've heard Ruby has a gentle learning curve and succinct syntax.

Python is great and worth learning. Jython is python running on the JVM, so it is great for those who know python and want to leverage that knowledge on the JVM.

Scala is a next gen quasi functional language that fully embraces the OO paradigm and runs on the JVM. It is a great language to complement a Java coder who wants more flexibility and the ability to do rapid prototyping. Perhaps one day it will replace Java.

Clojure is similar to Scala in that it is functional, but not purely functional like Haskell, it is however a Lisp dialect. Clojure runs on the JVM and although you can program OO in it, that is not its greatest strength. Lisp was originally developed from the Lamda calculus and the best fit for dealing with functions. Clojure is great for hard problems and concurrent programming, things are mostly immutable and you don't have to worry about complicated locking schemes.

The languages that run on the JVM can interop with other Java code and leverage the many Java libraries in existence allowing great flexibility. This also makes it easier to introduce your code into a more conservative environment. I've known a few folks who convinced their bosses to let them write unit tests in these languages.

Personally I'm learning Clojure at the moment and I plan on learning Scala next after I become more adept with Clojure and probably Python as well someday. For fun I also want to learn Haskell..

Clojure and other languages can run on the .NET CLR. From the looks of where things are are going with newer languages many of them run against different virtual machines (like JVM and .NET CLR) and you wont necessarily be tied to a platform in the future.

Of course there will always be a need for machine specific compiled code for things that need all the horsepower like operating systems, compilers, device drivers, games, etc...

There are real strengths in knowing a handful of different programming languages, and learning what the languages strengths are and how to leverage that knowledge properly. You can cut wood with any saw, but some saws work better than others and different types of wood are good for certain things.

Python, Ruby, Scala, Clojure, and Haskell are what I consider the gems of the programming world. Start learning these and you will learn concepts that can transform your thinking and really take you places. Haskell is probably the least practical, but could possibly give you the most reward. I might add F#, but I don't know much about it, but it would probably be a good thing to check out if you work with Microsoft products.

Assembly, C and C++ are great if you are hardcore and want to work for Google, create operating systems, design fast compilers, hardware drivers, and develop games. They are good getting at the low-level stuff, but as hardware continues to get faster, we are reaching a point where in most cases you can use a higher level language with a lot of abstractions to still crank out a fast program.

I think after learning a couple of the "gems", you should have a pretty good idea if you are the type who might go the Java/C#/VB route or get into C/C++. Maybe you won't ever have to do either though or you might want to foray into both a bit, it all really comes down to what you are interested in and to follow that passion.

Once you start learning a few different programming languages it becomes less of a big deal to learn others, and you can begin to group languages into logical containers based on their conceptual similarities.

Javascript and PHP are good to learn if you are into web programming, but I would still recommend learning the gems beforehand. Javascript is known to be very hard to become proficient with because it is so flexible. There are now many cross-compilers that take Java, Python and even Clojure code and create javascript, since it is the dominant dynamic language used on the web.

So more food for thought as you ask yourself what programming language you want to learn next.

Here are some other bloggers sharing their wisdom along these same lines:

Wednesday, November 9, 2011

Getting to Know Let

This write-up follows along with Brian Harvey's CS61A 2008 SICP class, lecture 4.

Note that these are not good examples of idiomatic Clojure coding style, but more of an introduction to functional programming using Clojure.

Think about the following three patterns of computation.

(TODO: translate these function from scheme to clojure, and add pic for clarity.)
1. every - call for each item
2. keep - keeps some
3. accumulate - smooshes together

In other languages these patterns might be the sort of thing you may be accustomed to performing in an inerative loop. instead of iteration we describe this process as a transformation.

These are all common things one might want to do to a set. They are known as higher order functions.

This is where lambda comes into play. We can better understand higher order functions and lambda by destructuring with let.

Let's take a closer look at the 'let' special form using the qudratic formula as an example.

first let's import a subset of the clojure.contrib library so we can use the sqaure root (sqrt) function
(ns test
  (:use clojure.contrib.generic.math-functions))

(TODO: add pic of quadratic formula.)
basic quadratic formula as a function
(defn roots [a b c]
  (println "roots: " str 
         (/ (+ (- b)(sqrt (- (* b b) (* 4 a c)))) (* 2 a))
         (/ (- (- b)(sqrt (- (* b b) (* 4 a c)))) (* 2 a)) ))
(roots 1 -5 6)

annoying that you have to name the roots1 function in this example
(defn roots-refactor-1 [a b c]
  (defn roots1 [d]
                (println "roots-refactor-1: " str
                       (/ (+ (- b) d) (* 2 a))
                       (/ (- (- b) d) (* 2 a)) ))
    (roots1 (sqrt (- (* b b) (* 4 a c)))) )
(roots-refactor-1 1 -5 6)

example of lamba, an anonymous function, which is passed in data (3 2 1)
(#(+ %1 %2 %3) 3 2 1)

lambda expression version which uses an anonymous function
(defn roots-refactor-2 [a b c]
        ( #(println "root-refactor-2: " str 
            (/ (+ (- b) %) (* 2 a))
            (/ (- (- b) %) (* 2 a)) )
         (sqrt (- (* b b) (* 4 a c))) ))
(roots-refactor-2 1 -5 6)               

the let form is syntactic sugar -- shorthand
let is the syntactic rearrangement of lambda and an invocation of that function
the secret: let = lambda + ()
(defn roots-refactor-3 [a b c]
        (let [d  (sqrt (- (* b b) (* 4 a c)))]
          (println "root-refactor-3: " str 
            (/ (+ (- b) d) (* 2 a))
            (/ (- (- b) d) (* 2 a))) ))
(roots-refactor-3 1 -5 6)

let abbreviates a lambda and invokes the function with arguments these are stored as local variables which will change every time it is called by the wrapper function
(defn roots-refactor-4 [a b c]
        (let [d  (sqrt (- (* b b) (* 4 a c))) ;d is the name of a local variable
              -b (- b) ;same with -b, just a variable name
              two*a (* 2 a)] ;yep two*a is just a variable too
          (println "root-refactor-4: " str 
            (/ (+ -b d) two*a)
            (/ (- -b d) two*a)) ))
(roots-refactor-4 1 -5 6)

Remember: let is a 2 step operation, one to create a lambda and two to invoke that procedure with arguments

Functions of Functions

This write-up follows along with Brian Harvey's CS61A 2008 SICP class, lecture 3.

Note that these are not good examples of idiomatic Clojure coding style, but more of an introduction to functional programming using Clojure.

basic definition of a function
(defn sq1 [x] (* x x))
(def sq (fn [x] (* x x) ) )

an anonymous function (lambda) with a name in scheme ->(define sq (lamba) (x) (* x x)) and the clojure translation is
(def sq #(* % %) )

the truly anonymous function in scheme -> (lambda (x) (* x x)) and the clojure translation is
#(* % %)

scheme -> (define f (lambda (x y) (+ (* 2 x) y))) and the clojure translation is
(def f #(+ (* 2 %1) %2))

a function that takes a function in scheme -> (define (compose f g) (lambda (x) (f (g x)))) and the clojure translation is
(defn compose [f g] #(f (g %)))

going further in scheme -> (define sec (compose first bf)) and the clojure translation is
(def sec (compose first rest))
(sec '(i want to tell you))

another compound function example using the (compose) function defined above
(defn twice [f] (compose f f))
(def fourth (twice sq))
(fourth 3)