A/Bingo is a Ruby on Rails A/B testing framework written as a plugin.
At times when the RightThing is difficult to ascertain and a lot of time has been spent without much progress, it may be better to do something rather than just enter AnalysisParalysis. The experience gained in the process often yields insight into what the RightThing may be.
UML is applying an abstraction at the wrong end of the problem. It is primarily used to sketch object models for inferior languages.
For all of my professed admiration of Ruby on rails, I personally don't think that easier and more productive CRUD application writing will shake things up. I personally care very much about writing applications in a tenth of the time, but using Rails is like listening to Jaco Pastorius. The real learning experience comes when you try to duplicate the feat.
The goal of modelling is to produce something substantially simpler than the world. This is achieved not through endlessly inventing new types and relationships -- in fact, it's just the opposite. It's by eliminating entities and restricting types that we get a model that's simpler than the world and thus useful.
You should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do.
In a recent post, Stephan Schmidt makes several suggestions in order to write "Next Generation Java". Unfortunately, I disagree with most of them
Even if you’ve trapped, you can change your programming style and reap some of the benefits of those new languages. In the last 15 years Java programming style has changed significantly.
By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback.
As we get ready to upgrade our servers I thought it’d be a good time to upgrade our deployment process. Currently pushing out a new version of GitHub takes upwards of 15 minutes. Ouch. My goal: one minute deploys (excluding server restart time).
We had a conversation about the fact that the 'TDD is about testing vs TDD is about design" debate that keeps popping up, especially now in the Ruby community.
Not all icons in the Finder are created equal. There are the normal file and folder icons. Then there are disk icons, which appear in the same context as normal icons, but behave differently. Then there are the proxy icons in window title bars. Then there are the quasi-alias icons in the Dock or the Finder sidebar - but even among the Finder sidebar icons, there are differences. These non-obvious inconsistencies are confusing to new users
For instance, the UI finds that a certain card is in the graveyard. It is essential that the UI sub-system does not care why the card is there, or how it got there. It is entirely a dumb client.