Social Dev Camp - Iterative Prototyping: Discover Your Interface Sooner!

Updated Nov 8, 2009

I'm giving a presentation at Social Dev Camp / Chicago this Sunday at 2:30PM.

Title:

Iterative Prototyping: Discover Your Interface Sooner!

Abstract:

Iterative incremental design of software is great as it helps developers discover how to build their applications gradually with small low-risk steps followed by user acceptance testing. However, why limit this agile approach to writing code? This same technique can be applied to user interfaces too during the early conceptual stages of design, enabling ability to make changes in hours instead of weeks since it is done to paper instead of code. For example, can you think how much more time it would take to redesign each page in MySpace to look more like Facebook if it is already coded vs when it was still on paper? Come to this talk to learn the basics of Iterative Prototyping and how you can apply this valuable tool to achieve better user experience.

Polyglot Programmers: Hello, and Beyond.

This might be of interest to developers in the Chicago area who are always
checking out new languages and technologies.

The Polyglot Programmers of Chicago are meeting this Thursday at 6PM
to see a talk by Clyde Forrester titled "Hello, and Beyond".

Abstract:

"When learning a new programming language or testing a new
environment, one commonly runs the "Hello" program, which simply puts
"Hello" on the screen. Some, like me, do not progress beyond that in
great leaps, but must define deliberate small steps to understand new
languages and additional functionality. To help with this, I am
gradually building a set of exercises and implementations in many
computer languages. I will present what I have so far, as well as the
significant problems I have encountered, and some lessons learned."

When: Thursday, October 22, 2009, 6:00-8:00
Where: Obtiva, 566 W. Adams St., Suite 400, Chicago, IL
Eating: Giordano's Pizza

Link: http://polyglotprogrammers.com/usa/illinois/chicago/200910.html

Glimmer Webinar Video

Here is a video of the Glimmer Webinar I gave today:
http://live.eclipse.org/node/792

Enjoy!

And, email me any questions you have.

Webinar: Simplifying Desktop Development with Glimmer

Webinar:

Simplifying Desktop Development with Glimmer

Link:

http://live.eclipse.org/node/792

Abstract:

Programming SWT/JFace user-interfaces in Java often involves a lot of repetitive boiler-plate code that is overly verbose and hard to map to the user-interface visually. This can significantly hinder maintainability and productivity for Eclipse RCP projects.

Enter Glimmer; a JRuby API for SWT that takes advantage of the expressive Ruby language to provide a simple user-interface DSL (domain-specific language). Developers can rely on Glimmer to build the presentation layer of desktop applications in Ruby while keeping the business logic in Java, or alternatively do complete desktop application development in Ruby. Glimmer comes with built-in data-binding support to greatly facilitate writing maintainable and testable desktop application code.

In this webinar, I will introduce Glimmer, demo the latest features by contrasting the code of an application written in both Glimmer and classic SWT, provide a quick update on the status of the project and finally, have a Q&A and feedback session.

Total running time will be approximately 1 hour

9:00 am PDT / 12:00 pm EDT / 4:00 pm GMT - Convert to other time zones

Palm webOS Development First Impression

Yesterday, I got a chance to pair-program on a Palm Pre application with my colleague Roy Kolak, author of the iPhone music bookmarking application NoteWorthy.

The application being built connects to a web service in order to list media offerings available for playback on the device.

Given my non-existent experience with development on the Palm Pre or any mobile device for that matter, I was a little worried about the learning curve, but I was delightfully surprised by how productive I was in helping Roy with the application.

While a part of the reason is Roy's good pairing skills, like explaining things before jumping into code, listening to all questions and suggestions openly, and taking turns driving with the keyboard, another big factor was certainly the Mojo SDK, which enabled me to leverage my existing Javascript/XHTML/CSS web development skills to write code for the Palm webOS without having to learn any new languages.

Additionally, Roy factored the code in such a way that maximizes separation of business logic from the view, enabling us to do true test-driven development with JSSpec (a Javascript spin-off of Ruby's famous rspec). In fact, the Mojo SDK encourages code structure that follows a variation of the familiar MVC pattern.

I asked Roy what he thought of development on the webOS in comparison to the iPhone OS. His response was that it took him several months to truly get how things worked with iPhone development whereas it took him less than a month to figure out Palm webOS development.

Palm sure has a lot of inertia to go against with its platform as the iPhone is a lot more mature and has a very big following. But, given that development on the webOS takes a fraction of the time of that on the iPhone OS, will the platform pay off for Palm in the long term? Only time will tell.

In any case, thanks to Palm's engineers for building such an elegant platform for us developers to quickly deliver value to consumers.

Software Craftsmanship North America Conference Coverage

Last updated at 5:42PM

I am at the Software Craftsmanship North America conference in Chicago, USA.

I will be doing live coverage of the conference in this blog post, so do not be jarred if the content gets updated often.

Here is a twitter stream about it too:
http://twitter.com/#search?q=%23scna%20AndyMaleh

Ken Auer kicked off the conference with a spectacular story about his upbringing both in and out of the software industry. He then proceeded to transition it to software craftsmanship and how he concluded that it is his favorite model for excelling in improving software development skills.

The first talk I attended was "There and Back Again" by Dave Astels, who recently left Google to join EngineYard, a very promising Rails hosting enterprise. His talk kicked off with a Software Craftsmanship version of the Star Wars rolling movie intro. The main emphasis of the talk is for developers to stick with technical work no matter how many ranks they ascend. Those who turn into complete managers cross to the dark side. In fact, that was partially why Dave left Google himself. He did not want to lose touch with the industry so he seeked more technical software work.

Next, I attended "Demonstrating Responsibility: The Mindset of Craftsmanship" by Christopher Avery. This was a talk on how taking responsibility is a key factor in succeeding with software development projects. Whether the process is agile or whatever new buzzword is out there. If team members are not taking responsibility, the chance of excelling and delivering is much lower.

Christopher mentioned the different emotional states people pass through when confronted with problems (sometimes skipping some) as a coping mechanism:

Denial > Lay Blame > Justify > Shame > Obligation

These states get in the way of being responsible, which gets in the way of solving problems and learning. In order to get through the states quickly towards responsibility, Christopher recommended adopting these attitudes:
Intention - The Winning Key: intending to recognize current emotional state and get beyond it
Awareness - The Change Key: being aware of current emotional state
Confront - The Truth Key: confronting current emotional state

Afterwards, I went to Jim Weirich's talk "Grand Unified Theory of Software Design". After quizzing the audience on common software design best practices such as DRY, SOLID, Law of Demeter, etc..., he proceeds to compare these practices to the early upbringing of physics and how there were many different theories in it before they were recently unified (partially) under M-Theory and Super-String Theory. He was wondering if he could do the same with software design principles, and his conclusion was that all principles seem to step from wanting to minimize connascence.

Connascence is a variation on the idea of software coupling, which is defined as follows:
"Two pieces of software share connascence when a change in one requires a corresponding change in the other."

Here are the different types of connascence he went through (C stands for Connascence):
CoName, CoPosition, CoMeaning, ContraC, CoAlgorithm, CoTiming, CoExecution, CoIdentity, CoValue, CoType.

Ward Cunningham talked next about how he designed computers with a completely different paradigm following the way bacteria communicates. In fact, the title of the talk was "What If Bacteria Designed Computers"

Next, I helped moderate a talk/panel given by Kevin Tayler, Micah Martin, and Carl Erickson titled "The Business of Craftsmanship." The audience asked quite a few interesting questions, such as, "How do you sell clients on apprentices working on their projects?", "How often does apprenticeship not work out?", "What happens if apprentices leave after investing in them?"

The last talk I saw before the final keynote was "Selling Craftsmanship in the Enterprise" by Cory Foy. One of the key points he made in it was: "The core of this movement [craftsmanship] is developers taking responsibility for their own careers."

Last but not least, I attended Bob Martin's incredibly dynamic keynote: "Craftsmanship Under Pressure".

Here are some traits he listed on what it means to be a professional:
- Can stay cool under pressure
- Under-commit but over-deliver
- Can have difficult conversations with the customer, like delaying the deadline.
- Know their field
- Live to learn. Love to Learn.

Great conference overall. It has been filmed, and you can find the sessions once announced on the @scna twitter feed.

That's all folks. Maybe we'll meet next year at this conference.

Taking the Status Quo for Granted

Software developers often take the status quo of the software industry for granted, aiming no higher in their solutions than the standards set by their community.

Let's take web programming as an example. In order to build web applications for clients or companies, most developers out there strive to master the standard web technologies: XHTML, CSS, Javascript as well as a back-end programming language+framework such as Java+Spring or Ruby on Rails.

However, once developers are comfortable enough with building web applications, they often seek ways to increase productivity and quality of work (performance, reliability, security, ...) through changes in software development processes and/or technologies.

As far as software technologies though, I've observed that developers too often only think of improvements that are incremental and within the box of what they normally do as opposed to outside the box.

What are some examples of in-the-box thinking?

• You have to program in two languages, one on the server and one on the client, in order to build a web application successfully.


• Despite your best efforts in adhering to web standards, you ought to spend time dealing with many browser-dependent issues while in the midst of building business web applications.


• You have to think about the low-level HTTP protocol details every time you build new business features in order to map them into service requests according to the web resource-oriented architecture.


• You have to code URL history management for Ajax calls yourself (with the aid of some library like YUI Browser History Manager or Really Simple History) to ensure that the back button and bookmark-ability are not broken in your shiny Web 2.0 application.
  

Having listed a few examples of in-the-box thinking, one may wonder "What is the box exactly made of?"

The box is made of all the currently assumed constraints that seem unchangeable, such as available development technologies, team values, and quality standards set by the client.

How do you think outside the box?

Thinking outside the box is an exercise in which people temporarily drop some (or all) of the assumed constraints and imagine how things would go about instead in that alternate reality. It is an exercise in creativity and imagination, and while it may yield some ideas that are not feasible in reality, it often yields other ideas that make people realize some of the assumed constraints are indeed changeable.

This is in fact what some luminaries in the Java world, such as Rod Johnson, did when they envisioned successful enterprise development without the constraints of EJBs (Enterprise JavaBeans). That's what DHH (David Heinemeier Hansson) did when he envisioned simplified web development relying on conventions instead of endless configuration files. That's what Google did when they built GWT (Google Web Toolkit), a framework that abstracts all the web low level details from developers.

In any case, often developers reject out-of-the-box solutions because they are not mature enough yet. For example, I know quite a few developers that are not very fond of GWT despite the fact that it offers these benefits:

• Simplifies the problem of web development by abstracting it to its essence: programming on the server and programming on the client with data passed back and forth in between. This has been successfully solved for desktop applications in the 90s with one programming language, so why have developers deal now with co-incidental technologies like XHTML, CSS, and Javascript?
• Unified debugging interaction for client and server making it very easy to trace data moving between them without having to context switch between many different syntaxes and technologies
• Abstracted all browser-related variations saving the developers from a huge burden in web development. Isn't that the premise of abstraction in software after all?

The reasons GWT is not considered a mature solution by some developers though are:

• Does not render web-standards compliant XHTML/CSS as it relies on the frowned up abuse of HTML tables to do layout


• Relies on the imperative Swing-like Java syntax to layout widgets, which is considered archaic nowadays compared to using DSLs that map closely to the visual layout, like Groovy SwingBuilder and SWIXML (or even good old XHTML)


• Of course, there is the learning curve and the fact that developers would have to remember to debug through an IDE instead of a browser debugger like Firebug. So, traditional web developers are kinda out of luck until they learn the new ways, but veteran desktop developers would be fine.

Still, the reason I bring this example up is because often when people get frustrated with a technology like GWT, they go back to accepting the status quo and working with solutions that are in-the-box as opposed to fixing the problems with the new out-of-the-box solutions.

The few that do persist and go beyond the box though end up with solutions that completely shatter existing expectations. For example, the Java language in its early days was considered by many developers as outlandish and impractical in comparison to writing code with a language that hits memory directly and works close to the hardware, like C/C++.

Who's making all the money now? :)