Andy Maleh - Eclipse Blog

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

Annas "Andy" Maleh — Fri, 06 Nov 2009 02:16:00 -0800

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.

Annas "Andy" Maleh — Mon, 19 Oct 2009 07:15:00 -0700

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

Annas "Andy" Maleh — Wed, 23 Sep 2009 07:20:00 -0700

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

Annas "Andy" Maleh — Tue, 22 Sep 2009 02:13:00 -0700

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

Annas "Andy" Maleh — Tue, 01 Sep 2009 05:35:00 -0700

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

Annas "Andy" Maleh — Wed, 26 Aug 2009 03:35:00 -0700

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

Annas "Andy" Maleh — Thu, 13 Aug 2009 14:48:00 -0700

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? :)

TODO or not TODO

Annas "Andy" Maleh — Thu, 30 Jul 2009 04:32:00 -0700

In the spirit of continuous improvement and XP's recommendation to always keep the code pristine clean (Refactor Mercilessly), I often perform a lot of refactorings to simplify the code as much as possible as the accumulated debts over the many months of a project can otherwise make working with the code intolerable a few years down the road.

The way I look at refactoring is it's like maintaining your car or cleaning your room. Do it continuously and you'll enjoy driving around or relaxing in your room. Ignore it, and a year later your car is not working as it should anymore and your room is completely intolerable except for running in to sleep and then run out again.

Unfortunately though, while I get insights for many refactorings that can make a significant dent on code simplicity, I often don't seem to find time to perform all of them when approaching a deadline. Should I ignore them and hope for the best? What if I ignore them, and after the deadline, I don't remember them anymore?

The best solution I personally found is to add a TODO in the place where the pending refactoring is useful.

But some developers from the agile community would immediately flinch and say: If you put off refactorings by adding TODO statements, you'll never get to do them and your code will be littered with them.

I used to have that fear myself till I gave that approach a try a few years ago.

Turned out that since continuous merciless refactoring is in my blood, I never find myself ignoring refactorings and letting the code rot. Quite the opposite, I sometimes almost miss deadlines to ensure that the code is in pristine condition.

Nonetheless, given that I have to let go of some refactorings to meet deadlines, I often forget them afterwards. One approach I tried to remedy that is to add reminder tasks about the refactorings in my task management app. Unfortunately, these often get ignored when the list grows too big.

So, I finally resorted to adding TODOs within the code, and I found a number of benefits as a result:

Refactoring ideas are preserved next to the code that needs them, thus maintaining context
Other developers see them and get an opportunity to perform the refactorings in the process of fixing a bug or adding a new feature
Developers are constantly reminded about them whenever they see the code that can benefit from refactoring

Therefore, TODOs are not used as a crutch to avoid performing refactorings when working in the code, they are used instead as reminders for refactorings that there was absolutely no time to perform before some deadline. They are placed right next to the code that needs them, thus constantly reminding developers of them and becoming available for all developers on the team to see as opposed to only the original developer who spotted their need.

I'd be curious to hear the opinions and experiences of other developers on the matter. Feel free to post a comment about it.

p.s. if you're using the Eclipse IDE, there is a view you can bring up called the Tasks view, which aggregates all TODO tasks from your project files (or a selected subset). That can help keep TODOs at the back of your mind at all times. Of course, if you're a command line zealot, you can simply grep or rak the TODOs instead.

Mouse-less Eclipse

Annas "Andy" Maleh — Mon, 27 Jul 2009 13:03:00 -0700

Last updated on July 29, 2009

A fellow blog reader commented on a post I made last month titled The IDE vs Editor War in the Ruby World, asking how I actually use Eclipse in a mouse-less way. So, I decided to post a list of all Eclipse shortcuts that I find practical enough to use in my day-to-day work. Note that my focus will be mostly on text editing shortcuts as opposed to language specific shortcuts.

Mouse-less Eclipse Keyboard Shortcuts:

CTRL+SHIFT+R: lookup up a resource (e.g. html, xml, rb, erb, properties, etc...)
CTRL+SHIFT+T: lookup a class name (e.g. String or Customer)
CTRL+F6: quickly jump between open files
CTRL+E: jump between open files using a filename filter or navigation keys
ALT+LEFT and ALT+RIGHT: navigate back and forth in the history of the files I opened. I rely on this one a lot to avoid using the mouse when navigating back and forth between different classes that collaborate to get a user interaction handled.
CTRL+O: lookup a method (thanks Kristian for reminding me)
F3: jump to method, class, or variable declaration.
CTRL+J keyword: instant search of a keyword within a file
CTRL+F keyword then ENTER: regular search.
CTRL+K and CTRL+SHIFT+K: find next and find previous repeating search for the last keyword
Highlight text to find other occurrances of a keyword and then CTRL+K: lets you find a keyword without even typing it if you see one occurrence already in the file (for example, you see a use of the slow performing method "reindex" and you wonder where else it's used in the file)
CTRL+H: project-wide search for a keyword. You can also specify file patterns. Make sure to tab into fields or use mnemonics and hit ENTER instead of using the mouse. Once the search completes, pick the result you want using the up/down arrows and then hit enter to open the file.
HOME/END/PGUP/PGDN: for navigation of course. I've been surprised many times by how very few developers rely on these buttons to navigate a file efficiently without using the mouse.
CTRL+LEFT and CTRL+RIGHT: jump between words for quicker navigation in a line without taking hand off keyboard to use the mouse.
CTRL+SHIFT+LEFT and CTRL+SHIFT+RIGHT: quick highlighting of words without taking hand off keyboard to use the mouse.
CTRL+L: jump to a particular line number. I keep line numbers visible to quickly locate stack trace errors. This one is invaluable in saving me from paging through a file or using the mouse.
CTRL+ALT+DOWN (or UP): clones a line downwards. It's like copy/paste without using the clipboard, which I use often to avoid emptying the clipboard from something I've copied that I'd like to paste somewhere. This is most useful with the CTRL+UP/DOWN shortcuts.
CTRL+UP and CTRL+DOWN: moves a line up or down quickly. I often start by cloning a line, and then I move the cloned line down or up to the place I want it to be at.
CTRL+SHIFT+F: format content (makes sure everything is indented nicely)
ALT+SHIFT+UP: highlights an entire variable name even if it had underscores and multiple words
ALT+W P: access preferences via ALT+character mnemonics
ALT+character mnemonics in general: useful to do all upper menu navigation instantly without a mouse if you're on Linux or Windows (sorry Mac people). Over time, your nervous system ends up memorizing a lot of the character sequences, saving you from having to even read the menu items, let alone pointing at them with a mouse and clicking them.

Additionally, there are many shortcuts for refactoring and source generation, which I will leave for the readers to discover on their own through the refactoring menus of Eclipse.

If I remember more shortcuts over the next few days, I will make sure to update the list above. Although anyone can look up shortcuts in the Eclipse keys preferences page, not all shortcuts are practical, so I am only highlighting the ones that I consistently use to increase productivity and flow. Of course, there may be shortcuts that I have not learned to appreciate yet, so feel free to contribute in the comments the shortcuts you normally like to use.

How do I know about all these shortcuts? Did I learn them all from a reference? How can I keep learning more shortcuts in my day-to-day job? I'll leave the answers to these questions to a future blog post.

Software Craftsmanship North America

Annas "Andy" Maleh — Wed, 24 Jun 2009 03:28:00 -0700

Dave Hoover, one of my fellow colleagues at Obtiva, is collaborating with the people at 8th Light to bring us one of the first conferences focused on software craftsmanship (Software Craftsmanship North America):
http://scna.softwarecraftsmanship.com/

I originally got introduced to the idea of Software Craftsmanship while reading the Pragmatic Programmer by Andrew Hunt and Dave Thomas, and later learned more about it through the book titled Software Craftsmanship by Pete-McBreen.

I even blogged about Software Craftsmanship contrasting it with Software Engineering over here:
http://andymaleh.blogspot.com/2008/12/software-craftsmanship-vs-software.html

Well, if you want to learn more about it, InfoQ recently posted an interview with Dave Hoover clarifying the purpose and goals behind the conference:
http://www.infoq.com/news/2009/06/software-craftsmanship-conf

Feel free to post a comment if you have any questions about it

The IDE vs Editor War in the Ruby World

Annas "Andy" Maleh — Tue, 02 Jun 2009 14:24:00 -0700

Ever since I switched to Ruby programming last September to develop Rails web applications, I've been fighting an up-hill battle to convince other developers of the value of using Eclipse or IDEs in general.

Since Ruby is an interpreted language (with a transparent compilation step for optimizations purposes only), developers mainly rely on test-driven development to produce reliable code. Auto-compilation and verification of code is thus rendered for the most part unnecessary.

Additionally, given Ruby's support for attributes (via attr* methods) and no need to declare class variables, many of the source code generators used in Java are not needed in Ruby. After all, Ruby's philosophy is about producting the tersest most abstract code, free of boiler-plate repetitive code.

Refactoring with Ruby is often done manually, but given that there isn't usually a lot of code with proper abstraction, and given Ruby's method aliasing support, huge refactorings of the nature that ripples through the whole system are rare, and thus refactoring is quite easy to perform manually especially given the protection of the Ruby must-have unit tests.

So, what does that leave as far as tooling needs? Color coding, syntax highlighting, file lookup, search and replace, and possibly some autocompletion capabilities.

Well, these limited needs brought back the popularity of simple editors that support just these features. By simple editors, I do actually mean good old VIM and emacs as well as the new extremely popular Mac editor, TextMate.

After 10 months of pair-programming with different Ruby developers with varying habits and backgrounds, I got to do a pilgrimage through most Ruby editors and IDEs. So far, I've gone through TextMate, VIM, Aptana RadRails, Eclipse DLTK, NetBeans, and IntelliJ RubyMine.

Yes, I'm a shortcut freak, and I used to write Java programs in Eclipse mouse-less!!! So, how did other editors and IDEs measure in comparison as far as shortcuts and productivity?

I'll leave that to another post.

In the meantime, what is your opinion of the matter? Do any of you prefer editors over IDEs? If so what's your editor/IDE of choice and what are the reasons you like it? Feel free to mention different ones for different programming languages.

iMeow

Annas "Andy" Maleh — Mon, 18 May 2009 02:43:00 -0700

Some of my colleagues at work built a new iPhone app called iMeow (iTunes link).

The instructions for using iMeow are actually encoded in a poem included with the app:

"I like to have my ears and belly rubbed.
But, please don't step on my toes or pull my tail!!!
I'll cry for food if I'm hungry.
And whatever you do. Do. Not. Shake. Me."

Since I have a coffee-colored cat called Java, I decided to try out iMeow with her.

When I pressed the mouth of the iMeow cat to make it meow, my cat suddenly became alert and still. I did it a few times and then tossed the phone away. My cat started moving slowly towards the phone and then went and sniffed it.

Next experiment was to pull the iMeow's cat tail or step on its toes. The shrieks that came out of that sent chills down my cat's spine!!!

Finally, I shook the iPhone forcing the iMeow cat to give an aggressive fighting shriek and exhale (the one cats do right before clawing you). That freaked my cat out, but it was fast enough that my cat was able to get over it quickly.

In any case, I expect the app to get a number of updates in the future, so if you have a cat and you would like to test how it would react to another cat, give iMeow a spin.

My next experiment will be to test iMeow in the wild, either in a pet store, or at a public place to see how everyone will react. ;)

XP West Michigan and EclipseCon 2009

Annas "Andy" Maleh — Wed, 25 Mar 2009 16:47:00 -0700

Tyler Jennings, Jake Scruggs, and I went on a road trip to Grand Rapids, Michigan yesterday and gave two presentations at the XP West Michigan user group. Jake presented "What’s the right level of testing?", and Tyler and I presented "Pairing Parody". Atomic Object hosted us and gave us a tour around their office. They had a nice open environment for pair-programming and a street light that signals the state of project builds (red for failure, green for success, and yellow for build in progress). The experience was very hospitable overall thanks to Michael Swieton.

Today, I flew to the Silicon Valley area around San Jose, California to present at EclipseCon 2009 tomorrow. I will be giving a short talk about Glimmer and the current state of the project.

If you have any specific questions about the project, feel free to list them here in the comments, and I will try to cover them in the talk.

Agile 2009 Workshop: TDD Ping Pong Match!

Annas "Andy" Maleh — Mon, 09 Mar 2009 05:45:00 -0700

By the way, Dave Hoover and I proposed a workshop for Agile 2009 titled: TDD Ping Pong Match!

It's a new and improved version of the same workshop conducted in Toronto last year at Agile 2008.

Abstract:

Attendees will be entered into a competition where they will pair-program on implementing small software application features following the TDD Ping Pong game rules. Each game will last for a few minutes, and the programmer with the least time driving (i.e. doing the simplest thing that works and coming up with the most tests) will be declared winner. This game is a great opportunity to learn TDD and Pair-Programming effectively and pragmatically. Winners will receive prizes, so sharpen your TDD Ping Pong skills and get ready for Andy and Dave’s challenge!

Agile 2009 Talk: Pairing Parody

Annas "Andy" Maleh — Tue, 03 Mar 2009 06:02:00 -0800

I submitted a proposal for this talk with Tyler Jennings:
http://agile2009.agilealliance.org/node/2370

Comments are welcome.

Abstract

Pair programming requires a certain level of social interaction (Yikes!!!) that quite a few developers are not accustomed to - even with their peers. Learning to work effectively with people of different personalities and skills (or even Jedi powers) can sometimes seem daunting compared to the typical habit of working alone in a dark corner. We’ve seen pairing work wonderfully, we’ve seen it be an abysmal failure that involved some shouting and storming away, and we’re going to bring our best-of moments to you in comedic fashion.
Process/Mechanics

First we’ll cover the basics for anyone who isn’t familiar with the drama that often accompanies pair programming. Afterward, Andy and I will be acting out various skits, demonstrating both effective and dysfunctional pairing scenarios. Discussions (and laughter or cries of terror) are highly encouraged at the end of each skit.

Basic Patterns

* Be Verbose
* Questions Not Demands
* Pair Negotiation
* Ping Pong Programming
* 2 x 2 Pairing
* Independent Research / Spikes

Mentoring Patterns

* Let the student drive
* Let the student fail
* The third wheel
* Test Mentor

Anti-Patterns

* The Prima Donna Programmer
* The Apathetic Programmer
* The Human Compiler
* Worshipping The Hero
* The Professional Driver

Learning outcomes

* Recognizing a dysfunctional pairing session
* Patterns for pairing effectively with various personality types and skill levels

Obtiva HackFest and Glimmer Tree Data Binding in Progress

Annas "Andy" Maleh — Tue, 03 Feb 2009 05:47:00 -0800

Today, instead of having our weekly GeekFest meeting at Obtiva, Dave organized a HackFest instead.

Colin, Dave, Roy, and Nate worked on
Colin's ultimate midi controller project. Tom, Leah, and Jake worked on the Metric Fu Aggregator. And, Tyler, Turner, and I worked on implementing Tree Data-Binding support for Glimmer.

In one hour, we made as much progress as we could, which amounted to coming up with a design for the data-binding syntax in this unit test:


 module Node
 attr_accessor :parent, :children
 end
 
 class Person 
 include Node
 attr_accessor :name, :age, :adult
 end
 
 def test_root_node_only
 adam = Person.new
 adam.name = "Adam"
 
 @target = shell {
 @tree = tree {
 items bind(adam, :name)
 }
 }
 
 assert_equal 1, @tree.widget.getItems.size
 assert_equal adam, @tree.widget.getItems.first
 end

To bind SWT Tree items to a model node hierarchy, you pass two parameters to the bind command: the root model node and the name of the attribute to be used for displaying text in the tree.

More tests will eventually be written to test data-binding a root model with children.

In the future, this will probably grow in other directions to handle tree node images and selection.

Test-driven design is a common practice at Obtiva as it gets many birds with one stone: ease of exploration of ideas, test-coverage, clean code design, and higher productivity due to incremental development preventing endless hours of debugging.

Stay tuned for more on Tree Data-Binding support in Glimmer in the future.

Sudoku Solver in Glimmer

Annas "Andy" Maleh — Thu, 29 Jan 2009 08:39:00 -0800

Dave Hoover recently experimented with writing a Sudoku solver in Ruby, so Joseph Leddy and I decided to slap a Glimmer cover on top of it. We pair-programmed on writing it test-first following the Model View Presenter pattern.

Here is how the user-interface looks like:

I'll provide more details once I've committed the code to the Glimmer repository.

About My 2008/2009 Vacation

Annas "Andy" Maleh — Wed, 28 Jan 2009 12:43:00 -0800

I've been wanting to blog about this for a while, so here it goes.

I spent my Christmas vacation this year in Dubai, and I got to see a lot of interesting things, such as the world's new highest tower (higher than CN), one of the world's largest malls (slightly larger than Edmonton's), a 7-star hotel that looks like a sail, an indoor skiing/snowboarding hill, palm artificial islands, and a hotel that is partially underwater and has a massive aquarium.

Best of all, through a friend of mine who works in technology in Dubai, I got to go to a programming user group meeting that had Matt Mullenweg from WordPress/Automattic.

Here are some photos from the trip:

Highest tower in the world (Burj Dubai)

Atlantis Hotel partially underwater at the head of the palm artificial islands

7-star hotel that looks like a sail (Burj al Arab)

Foggy skyscrapers

Indoor skiing/snowboarding hill

Me and a snowboard on the indoor hill

User group meeting with Matt from WordPress

Easily Typable

Annas "Andy" Maleh — Wed, 14 Jan 2009 13:09:00 -0800

For the Rubyists of us, I created a new mixin module called EasilyTypable:

http://github.com/AndyObtiva/easilytypable/tree/master

I am pasting the README for it over here:


Easily Typable
==============


Introduction:
-------------

Often when working with models that belong to an inheritance hierarchy, 
it is useful to verify if a particular model is of a certain type to 
perform some behavior specific to it. For example, this is needed when 
the view needs to handle a special rendering case when encountering a
certain type.

The call typically made to accomplish the task is: 
model.is_a?(CertainType)

Often, to do so in a more readable fashion, developers add a more 
English-like method that hides the details of type checking: 
model.certain_type? 

Writing such methods gets repetitive after a while, so an easier way 
to get these methods automatically is to mixin the EasilyTypable 
module.

When mixed into classes in an inheritance hierarchy, each class gets 
"certain_type?" methods for its type and all of its subclass types.


Example:
--------

require 'rubygems'
require 'spec'
require File.dirname(__FILE__) + '/../lib/easily_typable'

class TypeA
 include Obtiva::EasilyTypable
end

class TypeB < TypeA
end

class TypeC < TypeB
end

describe "Obtiva::EasilyTypable" do
 it "should add type_a? method to TypeA object" do
 TypeA.new.type_a?.should be_true
 end
 it "should add type_b? method to TypeB object" do
 TypeB.new.type_b?.should be_true
 end
 it "should add type_b? method to TypeA object" do
 TypeA.new.type_b?.should be_false
 end
 it "should add type_c? method to TypeC object" do
 TypeC.new.type_c?.should be_true
 end
 it "should add type_c? method to TypeA object" do
 TypeA.new.type_c?.should be_false
 end
 it "should add type_c? method to TypeB object" do
 TypeB.new.type_c?.should be_false
 end
end

Keep in mind that this is no substitute for good Object-Oriented design and is not an excuse to type-check everything in your code instead of letting behavior live in the models or rely on patterns like Strategy and State.

The type checking methods are simply useful in cases where type-related behavior really should not live on the model to maintain its cohesion and avoid strong coupling. An example of that is View logic that depends on the type of the model, but should not live in the model.

Glimmer Short Talk Description Change for EclipseCon 2009

Annas "Andy" Maleh — Mon, 22 Dec 2008 00:33:00 -0800

I reported a few days ago that I will be presenting Glimmer at EclipseCon 2009:
http://andymaleh.blogspot.com/2008/12/eclipsecon-2009-here-i-come.html

I just wanted to mention that I updated the description to provide more value to attendees in the 10-minute talk that I will be giving in 2009. Last year, I provided a quick introduction to what Glimmer is about. This year, I will expand by demonstrating the latest features added to Glimmer.

Here is the part I specifically changed in the talk's description:

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

Looking forward to seeing everyone at the conference.

Black Box vs Invisible Box of Professional Practices

Annas "Andy" Maleh — Sun, 21 Dec 2008 14:22:00 -0800

When a non-technical client requests software development services from a consulting shop, and they agree about the development of a certain application (the what,) is it a good idea to discuss the practices that will be followed in order to get the job done (the how,) or would mentioning the practices be irrelevant to a client who is not technical and has no expertise with software development?

For example, a certain consulting shop may choose to build the client's application following XP practices because from experience, developers at that shop have found that they finish developing features faster and with higher quality when following the XP process.

Is it relevant at all to mention these practices to a client who knows nothing about XP without being asked first? Or is it initially better to provide the client with the minimum amount of information needed, such as the number of developers, hourly-rate, estimated development time, etc...?

If the client was curious to know how the application is being developed, the details can always be provided when asked, but the reason I am asking the questions above is because often, mentioning these details too early can muddy the water and give the client authority over practices they do not have the qualifications to decide on.

For example, mentioning radical practices such as test-driven development and pair-programming sometimes stirs up discomfort and confusion about how these practices work due to lack of experience with them (like the classical misconception that the two practices aforementioned reduce productivity instead of increasing it.) The client then may demand removal/adjustment of the practices when in fact, the main reason the practices are followed is to serve the client in the most professional and productive way possible. That leads to the often frowned upon micro-management of practices, thus hindering creativity and productivity.

Without micro-management on the other hand, when the client is told he is sold the work hours of four developers with a certain estimate for application release, the developers can choose any way they desire to accomplish the client's goals. If they decide that it's more productive to pair on certain tasks and always write tests first, that is their decision. Trusting them with that freedom can often result in higher creativity and productivity in the long run, freeing the client from focusing on practices (the how) in order to focus on coming up with the best product to build (the what.)

After all, when I request from a company to build me a house, I do not want to be bored with all the technical details about how it is going to be built. I just want a quality home built by a certain date. If I get interested enough to know about the practices followed, I will ask, but I do not want to waste my time hearing about them before the beginning of the project if they do not affect my involvement with it.

In either case, clients still need to hear about the practices that directly affect their involvement with the development of the product. For example, stand-up meetings and iterative planning are two XP practices that need to be agreed on with the client before beginning the project in order to get the client's commitment and effectively apply them.

How would you answer the questions asked above? Are you in favor of having a black box or an invisible box around the professional practices that do not directly affect the client? Keep in mind that in either case, the box is transparent. It's just that with the black box, the client has to look closely to see them (like looking at tinted glass) whereas with the invisible box, all the details are being shown even before asking for them.

The Attitudes for Excelling in a Team

Annas "Andy" Maleh — Sat, 20 Dec 2008 09:31:00 -0800

Programmers working on a team often fall into the trap of comparing their skills to their coworkers and feeling negative about it. They often forget that people have different strengths and weaknesses, and having different perspectives and styles of work actually improves synergy and output rather than hinder it.

What are some attitudes that can help a team be more effective though?

Here is a list I just brainstormed quickly:

Motivation, enthusiasm, and excitement
Positive attitude and optimism
Respect and patience
Humbleness
Belief in the value of others
Love for learning

Could you think of other attitudes or traits that would help a team be more effective?

Contributing Value as a Junior Developer

Annas "Andy" Maleh — Thu, 18 Dec 2008 23:40:00 -0800

When I was still a junior software developer in the enterprise, I often felt like my opinion did not count. I had the typical shyness many junior developers have at their first job out of college. Whenever I was in the presence of senior developers, I worried about whether what I said would sound dumb and attempted as much as possible to be right to avoid embarrassing myself.

What was the net result of that?

I shared my opinion less and less, holding back on any ideas I had, and feeling frustrated with myself being junior. I had the illusion that if I gain enough experience and knowledge, I would finally speak intelligently and assert myself.

Also, whenever I was sure of something I said to someone more senior, and he was not convinced of it, I would get really angry.

That attitude finally changed after I learned two things:

Even the most senior and experienced of developers are sometimes wrong and they often humbly admit it because to them, finding the truth and serving the customer is much more important than others' perception of them.
When working with other people, our brains are not directly connected to theirs, so communication is not instantanious or perfect, often requiring a lot of patience and many attempts from both the speaker and listener before the message is communicated successfully.

Once my attitude changed, my behavior changed too as a consequence.

For example, now whenever I have an idea I would like to share, I speak up about it despite knowing that the team may resist it or the idea may simply be bad. Why? Because that's why we work as a team; to get different ideas, different perspectives, and different thoughts. Every opinion matters whether it's from a senior developer or a junior developer. Having a different mind thinking about the problem is very valuable. And, if the idea is not good for some reason, so what? I learn something new and I feel good about stimulating others' thoughts with my suggestion, possibly helping them come up with a different more effective idea.

Also, whenever someone would not see my point of view or not be convinced of something I said, I would take a deep breath and try to communicate it a different way by drawing on the whiteboard, telling a story or scenario, giving a concrete example, or asking the person questions that point him to the message I was trying to communicate. At least, when communication fails, I don't take it personally and appreciate the fact that other people have different points of view and paradigms of thinking, which could make it challenging to communicate a point sometimes. But, if the point does get communicated, the synergistic value of co-operation is priceless!

Ridiculous or Outside the Box?

Annas "Andy" Maleh — Thu, 18 Dec 2008 00:51:00 -0800

Ever heard someone call your idea about something ridiculous?

Well, that may be a good sign about the idea.

Usually, when people call something ridiculous it is not because they objectively thought about it and found it ridiculous. It is because it triggered a feeling in their body that it's ridiculous. If they had thought about it objectively, they would have pointed out why they don't believe the idea is good and/or listened to you actively to figure out why you believe the idea is useful.

But, when someone utters a statement like that, it means the idea completely shattered their first level of habituated thinking and triggered a feeling of discomfort in their body. It means the idea pierced through their current paradigms of thinking. It means the idea is fresh and has potential.

So, the next time you hear the word ridiculous about an idea you mentioned, don't immediately flinch and take that personally. Instead, re-evaluate the idea objectively to verify that it is sound, and calmly present the pros and cons of implementing it versus the status quo or other ideas presented.

After all, is the idea presented really ridiculous or is it simply outside the box?

EclipseCon 2009 Here I Come

Annas "Andy" Maleh — Wed, 17 Dec 2008 02:18:00 -0800

My Glimmer talk proposed for EclipseCon 2009 has been accepted:
https://www.eclipsecon.org/submissions/2009/view_talk.php?id=367

Looking forward to being at Santa Clara, California during Mar 23-26 2009.