Juixe Techknow

NetBeans 6.7 Release Candidate 2 was released recently and I already have it installed and running. It is also worth noting that several NetBeans related books came out in print just before JavaOne 2009.

In full disclosure, NetBeans is not my primary IDE. I mainly use Eclipse for Java development, sometimes Visual Studio for some C# projects, and occasionally Aptana Studio for Ruby and Rails applications… I probably use Komodo Edit more than NetBeans. In essence I am an IDE connoisseur. I use NetBeans for the sake of familiarizing myself it, for evaluating its features and plugins, and for rapid GUI prototyping.

That said, I am really impressed with NetBeans 6.7 and in particular NetBeans 6.5. NetBeans has very good out of the box support for Ruby, Groovy, and PHP. It has a good GUI Builder support out of the box, no additional plugins required. It also has Spring MVC, JavaServer Faces, Struts, Hibernate support out of the box as well. NetBeans 6.7 is definitely worth the download and install.

NetBeans 6.7 RC2

To help you get started with NetBeans, take a look at some of these recent books covering NetBeans and the NetBeans Platform.

• Pro Netbeans IDE 6 Rich Client Platform Edition
• The Definitive Guide to NetBeans Platform
• NetBeans Ruby and Rails IDE with JRuby

I, like many 10-5 developers not working directly with ajaxified web 2.0 applications, was not able to go to the Google I/O conference. I don’t feel so bad not going since Google has just released video recordings of over 80+ technical presentations from Google I/0. Most of the technical presentations are pushing Google’s APIs such as Android, Google App Engine, GWT, and Open Social.

As an aid for myself, and maybe other GWT developers, I have organized the pertinent tech talks as follows…

The Myth of the Genius Programmer
A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius. In this talk, we discuss how to avoid this trap and gracefully exchange personal ego for personal growth and super-charged collaboration. We’ll also examine how software tools affect social behaviors, and how to successfully manage the growth of new ideas.

Even Faster Websites
Steve is the author of High Performance Web Sites and the creator of YSlow. In this talk, he presents some of the best practices from his next book, including optimizing CSS selectors, flushing the document early, and discovering why 15% of users don’t get compressed responses.

Bespin and the Open Web
The Bespin project from Mozilla Labs is an experiment in re-envisioning how we develop software. In its current guise as a sometimes-fast web-based text editor shrouded in a horribly incomplete code editing platform, its potential might not be readily apparent. In this talk, Ben and Dion (two of the folks behind Bespin) will discuss the goals of the project, how they got to where we are now, go into implementation details on what it takes to build a bleeding edge application for today’s browsers (and not the ones from 1997) and share some hopes and thoughts on the future.

Big Modular Java with Guice
Learn how Google uses the fast, lightweight Guice framework to power some of the largest and most complex applications in the world. Supporting scores of developers, and steep testing and scaling requirements for the web, Guice proves that there is still ample room for a simple, type-safe and dynamic programming model in Java. This session will serve as a simple introduction to Guice, its ecosystem and how we use it at Google.

Do You Believe in the Users?
Too many programmers have forgotten about the lost art of customer service. All software has users, though most developers have forgotten how to respect them, trust them, or “sell” their software to them in an exciting (but honest!) manner. This talk will focus on anecdotes and strategies for keeping software design uncomplicated, making software fast, and putting usability above programming convenience. We’ll also focus on the importance of keeping a healthy illusion of simplicity, while allowing abstractions to deliberately leak for power-users.

I, like many 10-5 developers not working directly with ajaxified web 2.0 applications, was not able to go to the Google I/O conference. I don’t feel so bad not going since Google has just released video recordings of over 80+ technical presentations from Google I/0. Most of the technical presentations are pushing Google’s APIs such as Android, Google App Engine, GWT, and Open Social.

As an aid for myself, and maybe other GWT developers, I have organized the pertinent Android and mobile talks as follows…

Turbo-charge your UI: How to Make your Android UI Fast and Efficient
Learn practical tips, techniques and tricks for making your Android applications fast and responsive. This session will focus on optimizations recommended by the Android framework team to make the best use of the UI toolkit.

Supporting Multiple Devices with One Binary
The Android platform is designed to run on a wide variety of hardware configurations. Learn how to take advantage of the application framework to make your application run on a wide variety of devices without having to build a custom version for each.

Coding for Life — Battery Life, That Is
The three most important considerations for mobile applications are, in order: battery life, battery life, and battery life. After all, if the battery is dead, no one can use your application. In this session, Android engineer Jeffrey Sharkey will reveal the myriad ways — many unexpected — that your application can guzzle power and irritate users. You’ll learn about how networking affects battery life, the right and wrong ways to use Android-specific features such as wake locks, why you can’t assume that it’s okay to trade memory for time, and more.

A General-purpose Caching Architecture for Offline-capable Web Applications with HTML 5 Databases or Gears
Puzzled by all the new architectural choices possible when trying to build an offline-capable web application? So were we until we decided to design the newly launched Gmail Mobile Web for iPhone and Android’s offline capabilities by analogy with microprocessor caches: offline via a portable write-through caching layer running on either HTML 5 or Gears databases.

Mastering the Android Media Framework
Some monks might take a vow of silence, but Android certainly hasn’t. Attend this session, and help your app find its voice. Android engineer David Sparks will explore the multimedia capabilities of the Android platform, lifting the covers on the infrastructure to show you how it works and the right (and wrong!) ways to use it. You’ll learn how things work under the hood, how to dodge the common media-related developer pitfalls, and how to write secure and battery-efficient media code.

Ruby – I was really excited to play with _Why’s latest project, Bloopsaphone. Bloopsaphone allows you to program 8-bit sounds…

• Early 8-bit Sounds from _why’s Bloopsaphone
• What It’s Like Being A Ruby Rock Star
• The Ruby Toolbox
• Fixing Threads in Ruby 1.8: A 2-10x performance boost
• Engine Yard Has Taken Over Ruby 1.8.6 Maintenance
• Ruby Alltop
• Regular expression Ruby
• Ruby Polyglot: Talking with Erlang
• Ruby Currying
• Rubystein: Ruby meets Wolfenstein
• Java kicks Ruby in the what now?
• Macruby Support in any Cocoa Application

JRuby – There are still a lot of news and tutorials regarding deploying JRuby on Rails in Google App Engine for Java.

• Ruby on Rails on Google App Engine
• JBoss Rails Becomes TorqueBox
• BiteScript 0.0.2 Scripting Examples
• The future of Rails is Ruby 1.9 – real performance of 1.8, JRuby and 1.9 compared
• VisualVM: JRuby and the Ruby to JVM Spectrum
• JRuby on Rails, PDF generation and Flying Saucers

Ruby on Rails – This month saw a lot of good articles regarding Ruby on Rails… I particularly enjoyed reading ‘A Django Developer’s Views on Rails.’

• Being a Better Rails Developer
• Speeding up a Rails request by 150ms by changing 1 line
• Rails Alternatives: Merb, Sinatra & Ramaze
• A Django Developer’s Views on Rails
• Create RoR model diagrams with yUMLmeRails
• 5 Tips to Scale Your Ruby on Rails Application
• Ruby on Rails and the importance of being stupid
• RailsBridge
• Rails 3 Gets Supersized With Merb
• Four Ways Ruby on Rails Can Help You
• Ruby on Rails Security Project

RailsConf 2009 -There can’t be a Rails conference without some sort of argument or debate spilling over to the blogosphere. This year is no different but fortunately the biggest issue was the mass walk out of the Keynote speech.

• RailsConf 2009 Blip Channel
• Petition: We Think RailsConf Sessions Should Be Recorded, Properly
• RailsConf 2009 Presentations
• The Mega RailsConf 2009 Round Up
• Tim Ferriss’ RailsConf Keynote Bores Audience To Tears; Mass Walk Out
• Rails Magazine Issue #2: RailsConf 2009
• Rubyology 80: Heroku Interview, RailsConf 2009
• RailsConf 2009 Notes
• Don’t Think, Be a Famous Rails Developer
• RailsConf 2009 Rails is from Mars Ruby is From Venus
• Scotland on Rails 2009

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and I’ll be sure to follow back.

Programming

• Some people expand their mind, I scale and then shard mine.
• Scale your vision, your thoughts, and then yourself.
• Refactor, reduce, rinse, and repeat.
• Model your mind, debug your thoughts, and remove the printf statement from your comments.
• If you perpetuate bad code, you might be a bad developer!
• Code is about learning – If you are not learning you are doing it wrong.
• It is not that an artist knows his tools well that makes him great, it is that he knows his media! As programmers, what is our media?
• If the media of a programmer is the language, what is the media of the program user? The domain space? Should they be the same?
• I am dumbfounded by the amount of repetitive, tedious, and manual work a programmer will endure before they even consider automating tasks.
• Code talks, bugs walks.
• There is a thin line between a solution and a hack…
• The absence of a save button does not mean entities can not be saved.
• Less code is the best code.
• For any bug fix, all the debugging and all the time put into it is lost if you don’t add a test case for the root cause.
• JavaScript + jQuery UI + bookmarklet + PHP + Twitter API = tweetmark. I wrote a bookmarklet to bookmark URLs to @juixe.
• Don’t catch and release exceptions, exception handling is not a sport.
• My job is to make software easier done than said.
• DB Rule of Thumb: Don’t ever change the database schema without a second, third, and even fourth thought.
• There is no magic in software development! Files don’t delete themselves out from version control out of electronic spontaneous combustion.
• To avoid dubious verbose recursive repetition, variable names are not comments and comments should repeat variable declarations.
• Debugging is not just about code, debug your process and focus on what works and remove and modify that which doesn’t have positive results
• Just because you can teach end users new tricks does not get you off the hook from you learning to design an application with fewer tricks.
• Even when saying the same words, it is possible, and not unlikely, that developer understand features differently than what clients expect.
• Code can easily be refactored, but developer way of thinking is more difficult.
• In programming you have to think outside the box and outside the stack.

Continue reading

If you search for ways to become a better developer you will find nearly 70 million results. After reading as many of those results as possible and still learn something, I boiled down all the advice to the following general axioms.

• Read Everything
• Learn Fast, Learn Everything
• Practice What You Know
• Try New Things
• Strive for Simplicity
• Write and Teach
• Assume Nothing
• Question Everything
• It is Not Personal
• Know Your Tools
• Rinse and Repeat

The advice above can be used in just about any industry by anyone trying to advance in their career. This advice holds true whether your are a Ruby programmer or investment banker. The truth is that being a better students makes us better at whatever we do. If we learn how to learn, to see the patterns blindfolded, to navigate up and down the different layers of abstractions, to troubleshoot and debug code you never seen before, to ask the right questions at the right time… all these things help us write better programs no matter what language or technology stack you use.

That said, I wanted to illustrate these rules with more concrete examples specific to programming. Given a particular job title, say Ruby on Rails Developer, we can break down the above axioms to the following advice for being a better Rails developer…

• Read Everything
  • Download sample/Open Source apps
  • Dig into Rails source code
  • Read tutorials
  • Read books
• Learn Fast, Learn Everything
  • Master Ruby
  • Know SQL
  • Understand CSS
  • Use JavaScript
  • Learn HTML
  • Pickup HTTP
  • Use FTP
• Practice What You Know
  • Write code, scripts, and libraries
  • Start Open Source projects
  • Submit patches
• Try New Things
  • Tryout latest release
  • Find new plugins
  • Find new gems
  • Use different frameworks
  • Integrate with new services
  • Catch up on a new languages
• Write and Teach
  • Write prototypes
  • Write a gem
  • Write plugins
  • Write tutorials
  • Give presentations, brown bags, tech talks
• Assume Nothing
  • Don’t believe the hype, dogma, marketing
  • Test everything
  • Quantify assumptions
• Know Your Tools
  • Know editor shortcuts
  • Know editor code templates
  • Use editor plugins
  • Use version control
  • Use FireBug

Again, these are just a few words of advice that we can exercise to help us write better software. No one rule or axiom is enough. Other Rails developer would add additional advice, this is especially true with each new release of Rails. With each new release of Rails or Rails specific tools, we add and remove some of the advice given for a Rails developer. If I had written a list like this for a Java EE developer in 2001, that list would be out of date for a Java EE developer today. The key is that no one process, tool, framework, library, or language will make us better programmers but our daily developer routine, our behavior, and discipline…