Do you like your daily Scrum?

Over the years, I've attended my fair share of meetings and worked in a couple of places that are sort of "agile". Naturally, I have witnessed some unproductive meetings. It seems to me that the daily scrum -- or daily standup -- are disproportionately dysfunctional. This makes me wonder if there are truly fans of the daily scrum. Consider the following scenes of dysfunction. Have you seen these?

Reconsidering Java cloud hosting with PaaS

I have been looking into Java cloud hosting for my Groovy on Grails application, and I am quite pleased at what has been happening in this space. I last explored cloud hosting a couple of years ago. By contrast, today's PaaS (Platform as a Service) options look quite promising, particularly Cloud Foundry and Jelastic.

Tech conferences on the cheap

I like attending developer conferences. Developer-focused conferences bring a huge breadth of thought and concepts, an intoxicating  buffet of technology and learning that widen my knowledge beyond my current job's focus. Alas, technology-focused conferences have not brought the revolution in conference prices that technology has accomplished in other areas. That is, tech conferences remain very expensive. Including airfare and hotel accommodations, you could spend thousands of dollars for a single conference. I have been fortunate to have my employer pay for me to attend some developer conferences, but wouldn't it be nice if such conferences were cheaper in general?

This brings me to RIM's BlackBerry DevCon developer conferences. True, the conference itself is not unusual: lots of technical content plus parties, concerts and a price tag of a few hundred dollars. What I find interesting is what comes after the conference: the DevCon On-Demand website that lets you access the keynote and practically all conference session content. You get the transcript, streaming video/slides, streaming audio (synchronized with video and transcript) and source code. DevCon On-Demand is available not just to conference attendees but also to the entire public. Last year, RIM charged a mere $20 for a year's access to the US conference content. This year, they are charging … nothing.

BlackBerry development is a hobby for me, so I could never justify the cost -- airfare, hotel, registration and vacation time -- to attend something like DevCon. DevCon On-Demand is a great way for me to access the big ticket technical content without the big ticket cost. True, for some people the networking opportunities justify the cost of the real thing. But for geeks like me where the technical content is the primary draw, this is a great deal. Wouldn't it be great if other tech conferences followed this model?

Twilight of BlackBerry Java

I have mentioned before in this blog that I develop apps for the BlackBerry as a hobby. For all my apps so far, I used RIM's BlackBerry Java SDK, which has been their the "official" way to develop apps. I just learned that by next year all my apps will be obsolete. I am not exactly overjoyed. Here are my thoughts.

From NoSQL to NoServer

I attended an interesting presentation recently on CouchDB, a document store database that helped make the term NoSQL famous. One of the interesting ideas discussed is the idea of CouchApps: pure JavaScript/HTML applications working with and interacting exclusively with CouchDB. So not only do you not need a relational database, you can dump your application server too.

Reminder: hashcode is not a key

I just wanted to share a reminder not to treat Object.hashCode() as a key. This seems very basic, but I have seen experienced developers get tripped up over this method. A number of people seem to think that hashCode can be relied on to return unique integers for each object value, especially for strings. Oops.

My latest BlackBerry app: TempoBeat

My latest BlackBerry app is out. Presenting: TempoBeat, an electronic metronome app. I paid quite a bit of attention to the user interface with this app, since I wanted something that works well with both a keyboard and a touchscreen. The controls can be manipulated by touch, but I also included a number of keyboard shortcuts for non-touch BlackBerry model. It has a bunch of features or characteristics typical of metronomes: tempo, beats per measure, volume control etc. This being a BlackBerry app, I added one more feature that truly belongs on a BlackBerry: you can use the iconic BlackBerry LED to blink the beats, in colors of your choice.

My blog will make you stupid

Apparently, my blog will make you stupid. It's no good fleeing to another blog, though: they all make you stupid. That is, if you agree with Nicholas Carr's book, "The Shallows: What the Internet is Doing to Our Brains". The thesis of the book is that our use of the Internet is changing our brains, affecting deep learning, long term memory and our ability to focus.

I first heard about this book at a No Fluff Just Stuff developer's conference, where more than one panelist at one session cited this book with respect. Clearly, I thought, this is not a book for Luddites if a bunch of technophiles are reading it. This book is not a reaction against modernity. In fact, I'd say that it is trying to preserve an aspect of human progress now threatened by the Internet. I'll get to that in a moment.

NoSQL: triumph of application over data

NoSQL databases are the rage now, aren’t they? Not too long ago, NEJUG hosted a presentation by Tim Berglund called "NoSQL Smackdown." Before giving his tour of several NoSQL databases, Tim tried to give his definition of "NoSQL." After showing the difficulties of defining NoSQL as a series of negatives (no SQL, no relations, no transactions), he merely settled on a vague definition. Basically, he says, NoSQL is merely a set of different approaches in data models, querying and scaling that trade off things like performance and the 3 guarantees of the CAP Theorem.

In other words, there is no such thing as a canonical NoSQL database. Most emphasize key/value or document-oriented storage, but then you have something totally different like Neo4j, a graph database. NoSQL fans like to emphasize scalability, but some candidates don’t really scale. You can’t even say that NoSQL means no SQL, because you have something like GemFire, which does allow you to use SQL. Nevertheless, allow me to give you my own definition of NoSQL. Ready? Here goes:

NoSQL databases are databases for people who don't care about data.

The pain of enterprise Java development

Java enterprise development can be painful. Now, it's true that Java is not as concise as some other languages. It's also true that the Java ecosystem is full of famously complex tools and frameworks such old-style EJBs, JSF and Maven. Still, I believe that for us Java enterprise developers, much of the pain is self-inflicted. Let me suggest a few things we do to ourselves, often unnecessarily. These are generally justified as a Best Practice (spoken in a deep, authoritative voice) or something that decouples something or other. I think it says something about our mindset, and I don't necessarily mean in a bad way.

The trouble with being conventional

"Convention over configuration" is a popular paradigm in developer circles these days. Instead of explicit instructions over every detail or action, you would follow the framework's conventions and get most of the work done implicitly and for free. Ruby on Rails made this idea really take off, and we see it in action in many frameworks. The popular build tool Maven also adopts convention over configuration, and in the process demonstrates how not to do it.

I've had a pretty rough time getting comfortable with Maven. This was a green field Java project: we were starting absolutely from scratch. There were no legacy build processes to support, so we were ready to follow Maven convention everywhere. Nevertheless, it has been a long, painful (one colleague said "character building") journey. Why did it have to be so hard?

Chasing abstractions

We Java enterprise developers love abstractions in code. I suspect the typical software geek comes up with new abstractions more often than he changes his underwear. I admit to writing code with premature abstractions, such as using a strategy pattern where I end up never using a different strategy. We code defensively, afraid that lack of flexibility will hinder future changes. But beyond the code that we actually write, Java enterprise developers also love abstractions in third party libraries. We chase abstractions, in search of that fantasy land where if we adopt this or that framework we need not change our code to accommodate the hypothetical need to change the underlying implementation. The result is comic levels of abstractions upon abstractions.