From the pen of Jake Maly

I pooped well this morning. Halmony washed me up nicely.

I came downstairs sans diaper & pants, and decided to go to wake sleeping Harabujy up.

Harabujy pleasantly woke up by me. Since I was feeling extra happy with the nice bowel movement, I decided to sit on Harabujy’s lap on his bed.

Harabujy and I were chilling. But then something strange & stinky happened behind me. Harabujy and I both got shocked and we started screaming together.

Halmony seems busy today washing lots of things.

Ford Flex Test Drive

Spec: 2010 Ford Flex, AWD Limited, 3.5l www.twitpic.com/lhvda

Having an extended family of six and desire for a road trip from Toronto to NYC during Thanksgiving weekend, the trusty '08 Altima was relegated to a driveway rest and we rented a Ford Flex. I was quite intrigued by the vehicle before, so I was quite happy I got to rent it for a long drive.

It's a big car. It feels like a big car inside, it drives like a big car. Lot's of toys inside, Sync is fantastic, great seats, great versatility, good handling and comfort, great HID projectors up front, LEDs in the rear. So many good things that the shortcomings are even more disappointing. In sum, it feels like a two step car. Turn the wheel and wait - it shall turn. Step on the brakes and wait - it shall break. Step on the gas and wait - it shall accelerate. There is no progressin, no modulation. It's on or off. Anemic steering feel negates very solid suspension setup. Lazy (very) 6sp automatic transmition does absolutely no favors to the 262hp V6. The important instruments are too small - speedo. There's a million buttons (so it seems) on the console http://twitpic.com/lhvgi and it does no favours to the driver on a long drive through the night and rain। Great functionality, good fit and finish but lacking ergonomics - I was really distracted by the flowing field of green buttons when needing to adjust temperature and fan speed (toggle+button action) after 4hrs of driving. What's with the single stick with turn signals, highbeams, lowbeams, front wipers rear wipers and windsheeld washer? Couldn't Ford fit even more functions in there :-)?
The writeup may sound a bit negative, but I really like what this the car COULD BE as whole. Great handling, good power, great utility and comfort in a package seating 6 people. If the next iteration fixes some of the issues and puts a bit more GT and refinement into the car (which I hope the EcoBoost version already does, to some extent), I'll put it towards the top of my shopping list for large family car, regardless of make.

Agile Done Right

Agile as a software development methodology [http://www.agilealliance.org/]. The empowering of teams, the productivity of team which surpasses combined efforts of individuals. The starter fluid to change and improvement. The results orientation. Constant iterations and reflection. All of it provides tremendous potential for an organization to deliver outstanding results.

It can be a tall order to influence the way an organization works. I work for a large financial institution and rigid, risk averse environments are typically hard to change. But I'm proud that our own "Agile Mix" is successful and finding its way to broader and broader audience. I was the main advocate, proponent and preacher of Agile, at the beginning. Not so lonesome, anymore. Given trust and a seed team, we have not only developed out own "Agile Mix". We have also delivered the product with zero variances detected through out QA, on time, on budget. Our plans and estimates were aggressive and REAL. The team loved working in high paced and stimulating setup. They loved owning the product.

Everybody listens and learns from success stories. There is no better way to convince anybody that Agile works, other than when teams love it, while superb results are delivered.

Agile done right will evolve organically, with thin layer of "impediments removal" on top of it. The core values need to be reiterated and reflected in each team's decision. The particular flavor of Agile - XP, Scrum, Lean doesn't quite matter. All of the different methodologies provide yet another set of tools we can choose from, with useful variation in approach to achieving the same thing.

To make Agile work in any organization, you need results. Go get a team and DO IT. No matter the scale of the project, doing it is the only way to figure out what works in your environment and what doesn't. Your "Agile Mix" will always change and evolve - that's a good thing. Set the expectations right, be 100% transparent with all stakeholders. Apply the same rules on the process, which you'd apply on the product. Iterate. Iterate. Iterate.

My Work

Craftsmanship:

The paramount of my efforts is to be a good craftsman. Regardless if I'm replacing a light bulb, designing software, doing R&D, strategic planning or giving presentations and executive summaries. I want my work to be meaningful. I want to know it is making a difference. I want to keep getting better at it. Day in and Day out. [http://manifesto.softwarecraftsmanship.org/]

I like Agile software development methodology very much. It helps in making good craftsmen - it makes work personal. I blog about Agile here.

The rest is some tech stuff I enjoy working with, in no particular order:

Concept Development

Software Architecture

Best Practices

Software Design

Enterprise Portals

J2EE

OOA and OOD

OSGi and all things modular

RIA

Services and SOA

Strategy and Planning

And when the push comes to shove, I lead the technology SWAT team to action on large scale enterprise projects.

Browser as a Platform, HTML 5, WebSockets

In 2009 QCon London presentation "Browser as a Platform" Mozilla’s own Ben Galbraith and Dion Almaer presented their view of current state and potentials for the future state-of-the art in pure browser based applications. Very enthusiastic and entertaining presentation, lots of familiar icons and visuals from many organizations, some Bespin tease, all great stuff and fun.

But it got me thinking more about aspects of HTML5 that got very limited spot light (at a bit unfortunate cost of constant comparison to Flash and other plugins) - WebSockets and Server (sent) Events.

WebSockets and Server Events should become the real game changers of the browser world. Rendering technology (HTML DOM and JavaScript) issues and browser issues (threading et al.) are mere growing pains of an infant, but it is when we start looking at (and talking about) full duplex communication capability from the browser (WebSockets) and about standardized browser "PUSH" Comet style (Server Events), we'll know we've reached the maturing phase of an adolescent first class, full fledged presentation technology.

Communication is the key.

HTTP served us great as an information exchange protocol over many years, achieved great standardization and ubiquitous penetration. It enabled new architectural styles such as SOA; it is deeply reflected in REST, among many others. It also held the information flow back a little bit, which could be good and also bad. With browsers, it held it back.

Post-back driven web applications of earlier times, even with AJAX "wizardry" of late have kept the browser from becoming first class player in presentation technologies. Not that there are not great examples to the contrary, there are many amazing applications delivered in plain browser client.

But any first class player has to be able to achieve this in a simple, easy and replicable manner. It maybe simple, it is not always easy and not very often replicable to deliver browser application where user doesn't notice there is a browser involved and is interacting with the system in natural and intuitive way. Applications need to be specially tailored, users need to be trained.

It is the limited information flow paradigm that has held the browser from becoming first class player, capable of delivering of any application to all users, even more than the browser and presentation issues. After all, simpler presentation is often better and as great as Canvas and SVG (RIP?) are, their utility is centered around specialized set of applications.

But in any case, only after the information flows naturally to seamlessly enable application's flow and support user's thought process, can we present the information effectively and without technology infused stops and gaps. That is why I see the changes introduced by WebSockets and Server Events as profound and truly significant additions to the capabilities of browser based applications.

We'll still probably hear more about the presentation aspects, JavaScript Engines and threading tweaks of the next generation browser and standards, but the more we hear, talk and focus on the information flow features, the further stage has been reached on the Hype Cycle of "New" Technology.

OSGi Complexity?

Functional decomposition and modularization of applications is a popular topic. Instead of building singular, monolithic applications, we can build little Bundles or Modules that represent business functions and put them together Jigsaw Puzzle style.

The idea is that any overhead of such an approach is greatly offset by the benefits of encapulations - from software development to enterprise function placement.

For example, an application can "Shake bread crumbs with some chicken" and "Bake dinner", these two concerns are agnostic of each other, but can be composed into business flow "Shake 'N Bake". Or other business flows can be "Shake 'N Freez" or "Defrost 'N Bake".

Anytime we need to add/remove/change anything in the application we know exactly the place where the logic lives - as opposed to hunting throughout large codebases of potentially manyy application. It works great for testability, enables effective refactoring and short iterations.

OSGi has done a terrific job in championing of the modular concerns. But OSGi implementation can get quite complicated, for a reason that is not part of its core value proposition ...

Large portion of OSGi complexity comes from the assumption that the whole system is highly dynamic - OSGi bundles can come and go during the runtime and the system needs to constantly adapt. That is great and usefull for certain applications - I imagine telco world is a great example, but for most applications, this ability introduces too much complexity. Take the stallwart of OSGi examples Eclipse - the dynamic bundle update (called Plugins) is not used everyday and most new bundles force restart of the application after update, anyway.

Here's a solution: As soon as I replace "highly dynamic" with "fairly static" environment assumptions, it gets much simpler. I know that my application will either "shake" or "bake" sometime during application's runtime, anyway. I can live without introducing brand new business functions (say brand new operation "DeepFry") while the application is running. Now I could concentrate on the real issue at hand - modularity and functional decomposition, which is the core reason I arrived at OSGi gates.

Most of the OSGi complexity goes away with this change. It is a simple change, but it has far reaching impact. Bundles still have dynamic lifecycle, the major change is that all the Bundles are present from the start of the application and the application doesn't have to deal with Bundles exiting or brand new Bundles entering the application on a whim. Maybe this could be called SimpleOSGi.

Thanks to Ricky Bobby and Cal Naugton Jr. for inspiration in naming business functions examples. Dear Kraft Foods, please do not sue me.

Name Things Right

In Object Oriented languages, Class represents a definition of what will become an Object at runtime. In some languages (Smalltalk, Ruby) Class can be a runtime Object as well, in others it is more static formula (Java, C#). It always contains the prescription, the recipe. A Class may say: Add two arms, body, head and two legs to create a Person. It can also say that Person can speak.

When software runs, two instances of Person Object are created and they can speak with each other.We try to model the problem domain which is the target of our software as collection of Objects that can interact with each other (i.e. two Persons can speak with each other). This added level of abstraction helps us understand the domain better – we do not primarily focus on the details of sound wave exchange that is human speech, we primarily focus on the fact that two Persons can speak with each other. This way we do not get lost in details from the start, we find a place to put appropriate logic and move on.

The trick to software modeling is the ability to “Name Things Right”. If I can give names to all the actors in my domain I have created all the Classes. Then I decide what the actors (now Classes) can do in form of methods and I’m done creating my domain model. If I can not name my actors, I do not understand the problem domain enough to try to solve it with software. I have to go back and get more information, remodel and refactor. It takes several iterations before the problem domain is solved.

When “Utility Classes” rear their ugly heads: Utility Classes are convenient holder of unrelated methods, often accessed statically. I’m convinced that proliferation of Utility Classes is evil in Object Oriented software. It is clear indication that we have failed to model our domain correctly and started to put methods into one size fits all bag. Strobe lights should go off and sirens should sound every time this happens – just to attract attention. “Name Things Right” and your design will be conducive for beautiful code to happen.

Hat tip to Derek Zoolander for “Name Things Right” inspiration.

Twitter this, Twitter that II.

I found about Michael Jackson's death last night, via Twitter. RIP King of Pop. Even though I never was a proper fan, I think he's been a major factor in the culture of late 20th century. The music will live on.

Suddenly it became a bit clearer what is the magic of Twitter, for me. Information comes to me, I do not actively come to it. I have no idea what I'm going to see each time I open TweetDeck.

This is also known as the Hollywood Principle and IOC . It's used heavily in the software world and the main benefit is the removal of coupling among systems, computers, components, classes or files. One part of system doesn't assume anything about others, it declares its capabilities and lets others use it. The less coupling, the less assumptions, the less plumbing, the cleaner and simpler designs and lesser potential for mistakes. It makes it easier to develop great software. It also makes it easy to understand.

IOC has caused a shift in the software development paradigms and it's also changing the way we digest information in general. Applications like Twitter are trully Inverting the Control of Information flow from "browse and search" to "publish and subscribe".

Twitter may come and go, but it has moved the paradigm shift along a bit. It didn't start the shift, either, there's been bss and newsgroups and rss feeds long before it. I used to think rss is the greatest, just like I do about Twitter, now. Rss reader is still one of the most heavily utilized applications on my smart phone. Twitter is simpler, faster and more engaging. Search results from search.twitter.com are great complement to Google search.

Any (web) application needs to be aware of this shift. Information access needs to be simplified, simplified, simplified. It is not that there's too much of information, it is that it's too tedious to get to. If it's not simple, I'm not interested - and I'll never know how great a product you might have.

What's for lunch

That's a reccuring question, every day I forget to "brown bag it". I wish there was a simple way I could be suggested what is the current soup du jour by local eateries. I don't want to perform an extensive (re)search, just recieve short notification that "Wednesday Wings are 20c each @ Lawrence Wings". I wish to receive such notification only on Wednesdays, and only if I'm in the vicinity of Lawrence Wings. Just that and not much else. Sounds both simple enough and exciting to do. Bit of RoR for the web front end, android extension for mobile , Twitter API for the broadcast ... . Why don't I do it?

There are many applications centered on food industry - Urban Spoon, Open Table, Yelp, Menu Palace ... and it's still a hedeache to order pizza online in Toronto (except from PizzaHut, if you are into it). Lot of great apps, but I feel that each is trying to do too many things at once, forgetting to satisfy the ONE need, first and foremost. My need is to find What's for lunch. Period.

I find myself to have lower threshold for the amount of information I'm willing to digest, than I used to have. I want to find what I'm looking for, not much more. I don't browse around much anymore, I search and I'm gone. The one way to make me stick around (and eventually monetize on me) is to give me what I'm looking for first, than weave a web of distraction around it.

STICK TO IT

There are many approaches to designing and developing software. There are even fancy names to each. Structured or Procedural, Data Centric, Domain Driven, Event Driven, Object and Aspect Oriented ... and more. Add any implentation language of choice to the mix and stir well. People may tell you that some are better than other, some are practical, and others are just playgrounds for theory obsessed folks wearing funny hats. Some are old school and others are the new kids on the block. There are as many opinions on what it all means as many people get involved in discussions revolving around these topics. Books have been written, countless presentation were sat through.

We still keep discussing which the best way to build software is. The answer is simple: It doesn't quite matter. Potato, Potatoe. Different hats for different heads. Different tools for ... different folks. I may have mixed up my analogies a bit. Ultimately it is the type of job that has to determine the correct approach (insert another toolbox analogy).

The point is once you've chosen one approach, methodology or philosophy - for a particular task - STICK TO IT. It is the "dog pretending to be a cat" solution that brings out the worst in any given approach, combined. It is because each paradigm can be very different in nature, have different value system, different focus. And these do not mix well, especially if we try to make one look like the other.

The final product may look OK - on the first take, but sure won't taste great (insert the Cat and Dog making a cake tale details). It will have the worst traits from each approach involved, under such circumstances. Our OO code will be overun with inheritance, our Procedures interrupted without any apparent reason, our Domain Objects will not represent any business reality, our Pointcuts will attempt to crosscut accros dimensions.

So show your colors. Wear a 'God thought in Erlang' T-shirt. Spray paint 'Shuttles run on Procedural' all over you cubicle. Be critical but also proud of your decision despite what is the soup du jour. Beautiful code can happen using any approach. Choose what is the best for your team and project and STICK TO IT. Once you are done, re-evaluate your decisions, explore new teritories and get closer to the cutting edge. Then STICK TO THAT until you are done again.

Twitter this, twitter that

As a believer in the goodness of disruptive nature of new *stuff (well, mostly limited tech), I've been following Twitter for quite some time (@danielssonn).  Using a cell phone with Windows Mobile (don't ask), good Twitter client is hard to find. Now I want to try the Twikini client, and the good folks are giving 'em for free! All you have to do is publish a blog post, following few simple rules.

Twikini

Kids and books

This morning in the neighborhood was beautiful. Sun was shinning, birds chirping and the tulips blooming in plethora of colours. The neighbour’s son was dragging his huge backpack off the front steps, on the way to school. One of the last generations to have to do this, I hope. Once the time comes for my son Jake, he’ll be travelling light. The word on the street is that Amazon is to announce textbook size Kindle, soon. In the years to come, EBook readers such as the Kindle will become ubiquitous, come down in price and serve the broadest content of written word. There’s still time for this to happen, Jake is not even two years old. But if I see him dragging his backpack full of books off the doorstep, on his way to school, I’ll give the Amish thing a try.

Current Kindle model: http://www.amazon.com/Kindle-Amazons-Wireless-Reading-Generation/dp/B00154JDAI