…is what I would call a duct-tape programmer. And I say that with a great deal of respect. He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.

link: The Duct Tape Programmer – Joel on Software

To me, it is about making things that work. It is an engineering perspective.…

As the Johnson quote clearly points out, it’s not feasible to design (or should I say architect?) an infinitely flexible system. Therefore, it’s imperative that we recognize where flexibility is necessary to reduce the impact and cost of change. The challenge is that we don’t always know early in the project what might eventually change, so it’s impossible to create a flexible solution to something we can’t know about. This is the problem with Big Architecture Up Front (BAUF), and it’s why we must make architectural decisions temporally. It’s also why we must take great care in insulating and isolating decisions we’re unsure of, and ensuring that these initial decisions are easy to change as answers to the unknown emerge. For this, modularity is a missing component that helps minimize the impact and cost of change, and it’s why agile architecture requires modularity.

link: Eliminate Architecture : Software & Technology @kirkk.com

And what are we paying for? The privilege of flipping the magic bits in the software that say “I am blah edition!” It’s all so.. anticlimactic. All that effort, all that poring over complex feature charts and stressing out about pricing plans, and for what? Just to get the one simple, stupid thing I care about — using all the memory in my server. Perhaps these complaints, then, point to one unsung advantage of open source software: Open source software only comes in one edition: awesome.

link: Coding Horror: Oh, You Wanted “Awesome” Edition

It seems like I was just talking about this in response to a previous article of Jeff’s.

The catch is for the companies that do hit the inflection point. The licensing models employed by most large software companies like Microsoft, Oracle, IBM, etc, are built around getting the mid tier companies on their platform at relatively low initial costs. Their business model bets on the idea a certain percentage of those companies will hit an exponential growth curve. This curve will require an expansion of their IT infrastructure which will put them into a different price class. Through…

Grails is a fantastic framework. As well as being ultra-productive and fun to work with, it encourages good testing practices, and provides a swathe of tools to make writing unit, integration, and web tests a real pleasure. As we will see, Grails also lends itself quite well to build automation. However, Grails is not Maven. Grails has a fairly loose concept of the software development lifecycle, and is happy to let you bundle up and deploy your application as a WAR file without running all the unit and integration tests first. A Continuous Integration (CI) server can help you keep the flexibility of the Grails development process, and still ensure that your code is fully tested for each and every code change. In this article, we will take a look at how you can introduce Continuous Integration into your Grails project. More specifically, we will walk through how you can automate your Grails testing and code quality metrics with Hudson, a popular open source CI tool.

link: java.net: Grails and Continuous Integration: An Essential Combo

Here are my thoughts on the topic:

Scaling is about software. These days, virtualization is all the rage for scaling. It comes with it’s own share of issues, but it combines the scaling up and out alternatives in such a way that it becomes a question of licensing. By allowing you to add low cost hardware and combine them into larger virtual hardware, it can give you the best of both worlds. It drives the question from how big does the hardware need to be to questions of how quickly one should add additional hardware to the cluster. Or, what is the cost of scaling my software licenses? Does the software I am using have per cpu/core licensing, concurrent licensing, etc? The software, in most of these cases, become the most expensive factor. Energy use and network bandwidth cost typically run a close second and need to be considered. However, for technical decisions in the mid market, software drives hardware decisions.

Whether you are virtualized or not,…

I thought I’d take a moment and outline the multi-level architectural approach we’ve taken with skinning Controls, and give some rough outline as to when the different levels will be fully supported in JavaFX. There are basically three different levels of support for skinning in JavaFX. Levels of Skinning At the most basic level, which is also the most powerful and flexible, you have the ability to completely replace the Skin for any Control. The Skin is responsible for the entire visual appearance and, ultimately, the visual interaction for a Control. There are not explicit “ButtonSkin” or “RadioButtonSkin” or “ListViewSkin” types that must be extended. There are simply Skins. So for example, you could completely replace the Skin for a Button using your own implementation that, for instance, simply used an image for the button…

Skinning Architecture in JavaFX // FX Experience

Mailinator(tm) Blog: A Beautiful Race Condition

Moserware: The First Few Milliseconds of an HTTPS Connection