Saturday, December 17, 2011

Continuing Education for a Programmer

CSE at UF
One of my junior engineers asked the other day for resources to continue building up his experience with web development over the Christmas break.  So I put together a length email detailing items that I thought would be good for my team to read and do.  After re-reading the email, I realized that this was perfect blog material, so here it is un-cut from my original email.

Web Programming
The piece that makes web programming different from say standard gui applications is the web itself.  You have HTML and CSS and javascript on top of frameworks and server languages and databases.  Its a lot of different angles to become proficient in.  Start small and work your way in.  Some resources for learning more about the web.

  • CSS Zen Garden - Why do we use CSS?  This is why, a perfectly structured site that can look completely different with the change in a style sheet.
  • w3 schools - The W3 decides web standards, though browsers are sometimes lacking in following them.  They have a ton of tutorials on their site, check it out.
Computer Science Reading
Becoming better programmers doesn't always involve reading books about programming.  It could be a book about a developer, or a book about a methodology.  Some books you all should consider reading over your break
  • The Cathedral and the Baazar - Ever heard of Eric S Raymond?  This essay talks about the differences between Open Source and traditional development.  The book contains his original essay and other articles he has written, you can find all of his articles on his site.
  • The Art of Unix Programming - Another ESR Book about the philosophies of decisions made in building unix.  It can get preachy at times, but push through you'll be glad you did.
  • The Mythical Man Month - Want to be a project or technical manager some day?  Read this book.  Its probably been suggested in class and if you were like me, you ignored it as you had three other classes suggesting 6 books a piece just like it.
  • Just for Fun - The autobiography of Linus Torvolds.  It is not a technical book at all, but a very good read.
  • The Design of Design - another Fred Brooks book, this one I have yet to start but it has excellent reviews and reading the overview it sounded like a good read for anyone in Software Development.
  • Design Patterns - Very interesting book for those who love algorithm and technical design.  If you've taken the Oo class its required reading.
You should also consider adding to your weekly "programming/developer fitness program" reading blogs by programmers.  A few on my reading list are
  • Joel on Software - Joel Spolsky has worked all over the map in software development, from programmer to manager to tech writer.  He isn't as prolific anymore, but there are some really great articles in his archive.  He is one half of the minds behind Stack Overflow and created Trello
  • Coding Horror - Jeff Atwood another almost former blogger he has been picking up momentum again recently.  He is the other half behind Stack Overflow.
  • Mark Shuttleworth  - Started following his blog after last years UDS, he has some interesting posts on a variety of subjects.
Those are the individuals I follow currently, though my actual list is quite larger I've stopped reading some of my .Net blogs since joining CTRIP.  Another reading strategy is to follow planets that aggregate blogs.  A few planets to think about
If you have been around technology for a while you may already have a couple of technology sites that you read ever day.  For me its
"Google" New Ideas in Software Development
I keep throwing out things like Code Review, Gerrit, and Jenkins during our standups.  These are things that are coming down the pipeline at CTRIP, but why are they coming at all?  Being a better developer involves immersing yourself in new technologies and methodologies and being able to distinguish the fads from the game changers.  Use Google and Wikipedia to your advantage and look up things you are hearing in class and around the office.  Some key terms to "google" that have been floating around lately

  • Agile Development
  • KanBan
  • Bazaar
  • Gerrit
  • Code Review
  • Testing (there are different kinds than just Unit, Integration, and Acceptance)
  • Jenkins
  • HTML 5
  • SPARQL
  • Semantic Web
  • Linked Open Data
  • Bio-Medical Informatics vs BioInformatics
  • Clinical Trial
  • Personalized Medicine
  • Translational Science
Try other frameworks!
You may notice that I often give you all(my team as this was originally written for just them) a vague idea of how it should work and then expect you to go find the actual solution.  Why is that?  Its because I have experience in other frameworks and know how to do what we are talking about in them, but perhaps not exactly in grails.  Learning additional web frameworks and in other languages will often connect concepts in your primary framework that you haven't already grasped.  Think of it as looking at web programming from a different angle.  The perspective is different so there are differences, but their are also similarities.  A couple of good frameworks to get started in:
  • CakePHP (this is our other framework at CTRIP/ESE)
  • Django - a python framework similar to cake and grails
  • ASP.NET MVC 3 - a complete 180 from our usual style but not a bad idea to understand a completely different viewpoint.  As students you should be able to get VS 2008 for free or use Visual Web Developer Express.  Use C# as its closest to Java.  Just be careful of the differences like toString() which in C# is ToString() ... very annoying.
  • Spring - one of the layers that Grails is built upon.  Its a good idea to learn Spring without Grails to better understand Grails itself
Learning is often doing, you can't just read it from a book and expect to be able to do it.  Find tutorials in these frameworks and take them for a test drive.  You'll learn a lot about web development in the process.

Sunday, December 4, 2011

IDE's: is there a tool for every occasion?

IDE, Integrated Development Environment, a programmer's best friend.  The best ones run unit tests, pre-compile code, do code completion, and run the code in a demo environment.

Saturday, December 3, 2011

The value of a second pair of eyes

A long time a go in an office far far away I had to sit for four hours a day watching someone else write code.  It was slow, it was boring, and it drove me nuts.  It was pair programming and in retrospect I've noticed that it did make both of us better programmers and the code itself better.  I often get little reminders of one of the important reasons for pair programming.

A second set of eyes

This weeks example, I received an IRC message asking if I could help out with a CSS issue.  I'm not a "CSS guy" I'm more a "CSS thief" but I was game.  So, we looked over his Django template and a solution eventually presented itself.  I mocked it up, uploaded a patch and he merged it in.  Great!  Now he states if he could only figure out one other little issue.  

I couldn't help myself, I was in programming mode.  I asked "what was wrong?"  A ManyToMany object wasn't printing out on his page and had him stumped.  It stumped me to, I barely know Django and after going through all the documentation everything looked correct.  I threw in a "{{ forloop.counter }}" and nothing showed up.  Found sites that were doing exactly what he was trying to do and they matched.  Finally I saw he had one little element "related_name" in the foriegnkey attribute.  I had read about it, and it wasn't necessary so I thought "why not try removing it and seeing what happens."  His code worked.  Code he and then I had poured over for hours that was technically correct and one little "un-necessary" element was the cause.

Programming: Putting all of the Pieces together (Part 4)

While teaching the developers the proper process of coding and testing and committing will make them better developers, I need something to help me monitor the process.  So far all I have is labor intensive reviewing individual commits and running the tests by hand.  Pulling back in things learned from cornell while working on VIVO I can automate my tests with Jenkins.

Jenkins is amazing, I've spent part of the previous week putting together a POC installation on a Virtual Machine and the tests that I can run.  There are plugins for Selenium and Grails and code review like codenarq and code coverage.  With this we can automate tests to be performed before code is merged with develop.  If our developers are following the appropriate steps, their code will pass with flying colors.  If they are not following the appropriate steps, I save time and effort by having a robot (jenkins) remind them to test their code and that the code they are trying to submit fails.

How do I put this into our typical development process?  We're using in addition to Git, Git-Flow.  Basically it formalizes our branching structure so that between projects we are all following the same methods for defining the production branch (master) the development branch (develop) the working branches (/feature) and branches for hot fixes, version tags, etc.  Inserting jenkins into my development process isn't as easy as targeting a branch.  If I select master, I'm not testing often enough as its only receives release candidates from develop.  I could select develop, however, I want to insert it before the code comes into the develop.  I want to tigger it when my developer in his branch calls
git flow feature finish featureName

Also I don't want to only rely upon automated review.  What if my developer didn't add the appropriate tests for his or her new feature.  What if the poor code is syntactically perfect, but lacks good design decisions.  The code review tools will catch a lot of these errors, but not all of them.  Re-enter the original concept of code reviews.  When your peers see your code, you code cleaner, smarter, more efficiently.  Enter Gerrit, a code review system that automates the process of reviewing code.  It sets up review tickets, and can be integrated with jenkins to allow jenkins to weight in a pass/fail based on the scripted tests.  Reviewers can be setup for each developer and I can get emails when there is code for me to review.  Upon successful review the code can be automatically merged back into our main development trunk.

So this is the task this week; put it all together.  I have the proper pieces falling into place, now I need to make them match up.  How do I interrupt the git-flow process to insert Gerrit?  How do I make Gerrit preform the rest of the merge with develop if the reviewers and Jenkins approve?