Programming

More N00b Grails Errors – When a Domain Class Isn’t a Domain Class

Posted on by Matt Woodward

I figure as I make my travails with Grails I’ll post stuff I run into so
others can benefit if/when they jump into Grails.

Today I started a new Grails application and created a domain class and a
controller for User. These were in packages but that’s irrelevant, so I’ll
keep things simple for the purposes of the example.


grails create-domain-class User
grails create-controller User

I then edited my User class:

class User {

String email
String password
String firstName
String lastName

static constraints = {
email(email:true,unique:true)
password(blank:false)
firstName(blank:false)
lastName(blank:false)
}

}

And edited my controller to add the scaffolding:

class UserController {

def scaffold = true

def index = {}
}

When I fired up the app I got an error to the effect of “Can’t scaffold
because User isn’t a domain class.” Weird. Since I hadn’t spent much time
on anything yet, I nuked my domain class, controller, and test files and
started again.

This time around the app ran but I got a 404 error when clicking on the
UserController link on the index page:

/WEB-INF/grails-app/views/user/index.jsp

RequestURI=/myapp/WEB-INF/grails-app/views/user/index.jsp

Very odd it’s looking for JSP, but it dawned on my that I told it to
scaffold AND I had an empty index action defined, so remove the index
action and voila, all is right with the world.

If you got this far and are thinking “DUH!”, remember that I warned you
with the “N00b” declaration in the title. 😉 I’m sure other people are in
the same boat I am, namely augmenting skills they have in other languages
and technologies with Grails, so even if it’s a no-brainer for those more
familiar with Grails I figure I’ll share anyway. Expect my Grails posts to
get more interesting the more I dig into Grails.

How Ravelry Scales to 10 Million Requests Using Rails | High Scalability

Posted on by Matt Woodward

Ten years ago a site like Ravelry would have been a multi-million dollar operation. Today Casey is the sole engineer for Ravelry and to run it takes only a few people. He was able to code it in 4 months working nights and weekends. Take a look down below of all the technologies used to make Ravelry and you’ll see how it is constructed almost completely from free of the shelf software that Casey has stitched together into a complete system. There’s an amazing amount of leverage in today’s ecosystem when you combine all the quality tools, languages, storage, bandwidth and hosting options.

Really interesting and quick read (link to a great interview at the top of the article as well) about building and scaling what started out as a small site (don’t they all?). Excellent details about the technologies used and why, and nice lessons learned. “Keep it fun” is one I continually have to remind myself.

Enterprise Java Community: Programming is Also Teaching Your Team

Posted on by Matt Woodward

Programming has two goals.

One goal is to do something, of course: calculate an amortization table, present a list of updated feeds, snipe someone on Ebay, or perhaps smash a human player’s army. This goal is focused at a computing environment.

The other goal is – or should be – to transfer knowledge between programmers. This has a lot of benefits: it increases the number of people who understand a given piece of code, it frees a developer to do new things (since he’s no longer the only person who can maintain a given program or process), and it often provides better performance – since showing Deanna your code gives her a chance to point out where your code can improve. Of course, this can be a two-edged sword, because Deanna may have biases that affect the code she writes (and therefore, what you might learn.)

Nice reminder of one of the big goals of programming in my mind. Developers often get so busy that we furiously code with an eye only to the short-term end goal, while neglecting the longer-term goals of the development team as a whole. Deadlines may get met this way, but it’s damaging over the long haul.

Additional Thoughts on “Is Java Dead?”

Posted on by Matt Woodward

Part of how I use posterous is as a web scrapbook of sorts, and it’s a great way to keep the full version of something I come across on the web that I find interesting. Still find it odd you can’t edit the excerpts posterous generates, but on the other hand if the original link goes away, then I still have it handy.

Anyway, someone on Twitter asked if I had any thoughts on the “Is Java Dead?” article I found earlier today, and although I had a couple of comments at the bottom of that post, I have a lot more to say about the continual predictions of Java’s demise.

Living in the CFML world for so long I’m used to people proclaiming that one of my technologies of choice is dead. For those not in the know ComputerWorld put ColdFusion on their “Top 10 Dead or Dying Computer Skills” list in 2007/. In the top spot on their list was COBOL, but more on that in a moment. I won’t rehash the whole ColdFusion is Dead trope here, but semi-related to my recent Grails post, I did find a blog post by Dave Lowe from 2007 on this topic that was particularly rational, and it begs the question: has enough changed in two years? I’d say yes and no, but that’s fodder for another post …

Back to Java. The timing of the “Is Java Dead?” post is interesting given that COBOL just turned 50. According to ComputerWorld and many others, COBOL is dead and has been for a long time. The irony here is that COBOL runs most of the world’s ATMs and, according to the article, powers 75 percent of the world’s business applications. I’m not sure how they define “business applications” and that number seems rather high to me, but regardless of the specific statistics, it’s fair to say COBOL is far from dead. As a COBOL programmer friend of mine always says, “I’m not a dinosaur. I’m a shark.” (He’s referring to the fact that sharks have been around for millions of years but are still here and still to be feared, in case that wasn’t obvious.)

Java has still to appear on any ComputerWorld obituaries (only a matter of time), but it seems that every year or so, much as with CFML, people fire up the death rumors once again. This year in particular that’s to be expected since nothing fans the flames of FUD more than Oracle’s acquisition of Sun. And to be frank, the mechanisms for Java to evolve aren’t particularly speedy, which even Sun predicted back in 2000. (Some interesting parallels there with what’s going on in the CFML world today.)

So is Java dead? To answer that we first have to consider what Java is, and it’s much, much more than the OO programming language people love to hate.

What’s Java?

In the first Java programming class I took at Sun back in 1999, the first question my instructor put on the whiteboard was “What’s Java?”

People in the class had various answers, but none got at what the instructor was looking for. “Above all,” the instructor eventually revealed, “Java is a platform.” So Sun had the platform in mind from the start, and it turns out that’s the smartest thing they could have done.

Java is of course also a programming language, and as such it’s great. I can hear people disagreeing already, so let me support my assertion a bit. By “modern” standards (whatever that means) Java is more verbose than people would like, it’s too strict, and compared to languages like Groovy and Ruby it seems downright dated. But what the Groovy, Ruby, Python, etc. advocates forget is that without Java they have nothing against which to look good.

OK, I’m being facetious, but I hope you get my point. Java wasn’t designed to be the latest whiz-bang dynamic web 2.0 wunderkind because that wasn’t the state of the world back in the 1990s. When Java 1.0 was released in 1996 it was, hard to see 13 years later, revolutionary. The garbage collection alone put it lightyears ahead of C++, and Java had serendipitous timing with the advent of the Internet as well.

As a language Java is admittedly rather stodgy compared to the fancy new dynamic rapid ajaxified agile toolkits we have at our disposal today, and yet with JRuby, Jython, and more directly in the case of Groovy, not to mention CFML, modern languages want to run on the Java platform because it’s ubiquitous, it’s powerful, and it’s not going anywhere.

Java as a Platform

Regardless of your opinions of Java the language, there’s much to love about Java the platform. Sun’s original claim of “write once, run anywhere” is technically true even of C and C++ given the one additional step of native compilation, and this slogan has frequently been bastardized into “write once, test everywhere.” But on balance Java lives up to its run anywhere promises, and this is precisely what allowed Java to grow and become as entrenched as it is today.

The notion of a virtual machine, driven by Java’s origins as a platform for set-top boxes, turned out to be a stroke of genius that went far beyond its original intent. It was head of its time, to be sure. The notion of a compiled-yet-interpreted language was odd, and at first Java was dead slow compared to natively compiled languages. The promise–and actual delivery–of true portability was compelling enough for Java to take off, however, and these days the speed argument against Java is wholly irrelevant due to tremendous speed improvements with Java itself and the ridiculously powerful machines we have at our disposal.

So take or leave Java as a language, but as a platform Java got things 100% right. Where web applications in particular are concerned, I still get a big smile on my face every time I drop a single WAR file on a servlet container to deploy my applications as opposed to FTPing scores of individual files, and that’s all thanks to the Java platform. Java thought well beyond being just another language and continues to be hugely compelling on the platform side even if you prefer to write your code in another language.

What Else is There?

Most of the arguments against Java are against its perceived shortcomings as a language, but even on that front Java does what it does incredibly well. It’s extremely fast, and if you need the features that a strongly typed language has to offer, you could do far worse than Java. If you want to go with one of the newer kids on the block, where something like Groovy is concerned you really do get the best of both worlds: dynamic features for rapid development, with the speed of Java and access to the huge Java ecosystem at your fingertips.

When people claim that Java is dead and focus on the language, they’re completely missing the all-important platform piece of the puzzle. So on this point I’d like to ask a blunt question, and one that none of Java’s naysayers ever get around to answering: What else is there? What else out there offers what Java does as a platform?

To my mind the answer is nothing, so if Java truly is dead we’re all a bit doomed. The closest corollary is the .NET platform in the Microsoft world, and therein lies the problem: it lives in the Microsoft world. People who know me know that makes it a 110% non-starter for me, but from a more objective standpoint that’s an issue for much of the rest of the world as well. Why would people sink a lot of time and money into developing business applications that will only run on Windows servers? Yes, there’s the Mono project that allows .NET CLR languages to run on Linux, but I suspect over time that effort will wane, and even now it’s well behind the official MS version. The gNewSense project just announced it’s eliminating Mono from its distributions, and given public opinion on the matter Ubuntu will likely lean in this direction as well.

So 13 years after its release, if you want write-once run-anywhere applications, great speed, and a tremendous platform on which to run all your apps in multiple different languages, Java truly stands alone.

Long Live Java

Even though Java’s a bit long in the tooth in the opinions of some, all these years later it still offers things no other technology does. If Java is truly in jeopardy all of the efforts to run more modern languages on the Java platform wouldn’t continue. Java still has tremendous value as both a language and a platform, and if anything Java seems to be experiencing a renaissance these days from where I stand.

A friend asked me just last week if I thought taking Java classes and learning Java was a good idea. I didn’t hesitate to answer in the affirmative. Java as a skill is still in large demand, the Java community is alive and strong, the number of powerful open source projects written in Java is astoundingly deep, broad, and diverse, and given the other options in which my friend could spend his time and money, Java still comes out well ahead.

Java’s not a dinosaur. It’s a shark. And I can say with a great deal of certainty that sometime in the 2040s we’ll see an article on Slashdot celebrating 50 years of Java. I just hope I’m there to see it.

Is Java dead? (via CodeMonkeyism)

Posted on by Matt Woodward

Written on September 21, 2009 by Stephan Schmidt

Is Java dead?

var dzone_url = ‘http://codemonkeyism.com/java-dead/’;

–>

Is Java finally dead? There has been much discussion about the end of Java. As a developer, do you need to care? How do you need to change your decisions in the case that Java is dead? I have pounding this question for the last several years, beginning with my adventures into Ruby at the end of the 90s. I hope to give a thorough representation of my thoughts here.

In a very interesting thread on LtU Sean McDirmid wrote:

The Java death watch continues. Its future is tied up with Sun, which continues not to make money, and in this economy… JavaFX was late and didn’t make the splash it needed to make. Can Scala (or Clojure I guess) save the JVM? And who would take over the Java mantle if Sun imploded, IBM?

while Ross Smith is adding:

I think Sun will be widely recognised as doomed, if it isn’t already dead, by the end of 2009, and they’ll take Java (and the JVM) down with them.

A lot has happened since then: Orcale is buying Sun, the JRuby team has jumped ship to Engine Yard. 2009 has not yet ended, we will see if that prediction holds true.

Searching for java is dead with Google, one gets

Results 1 – 10 of about 8,620,000 for java is dead.

Dead indeed. Or at least lots of people think it is or will die 2009.

For a start we first need to explore what “dead” means, and in particular what dead means for Java. What dead means to you as a developer. After that I will look into the potential successors and why they are better than Java – or not. Looking into the question “why should Java die” I want to make some prediction about Javas future and especially about some future Java programming style.

What does dead mean?

Let’s begin with some thoughts on what Java means. . Most people mean different things when they talk about Java. There are mainly three parts:

  • Java, the language

  • Java, the libraries (JDK)

  • Java, the virtual machine

So does “Java is dead” mean the language, the libraries or the virtual machine? Contrary to the commentors on Lambda the Ultimate the Java VM is safe. There are considerable efforts to open source the virtual machine beside the language. Indeed with the beginning of the Java language summit it looks stronger than before. Should Sun as a company die, Oracle drop Java or stop development on the VM, most probably some other players with their VM implementations or the OpenJDK community would jump in.

The VM as a platform has grown enormously in 2008 and 2009. Lots of people talk about JRuby as Rails for the enterprise – Engine Yards has pledged support. Scala is an object-functional language on the VM with a strong following and a lot of momentum in 2009. Both Scala and JRuby are established on the JVM, but there are newcomers. Clojure stirred up the Lisp community and the Java community in 2008 and made a lot of buzz in 2009. Just in time for christmas last year Ola Bini released Ioke, what he described as a mixture of Smalltalk, Ruby and Lisp. It looks like a more dynamic Ruby to me after some hours of playing around with it. Great feat. And recently Noop has been released.

Or does “Java is dead” mean the language? What does it mean to be dead for a programming language? Perhaps that it is no longer the default choice for projects? Default choice for what projects? It is obviously not any longer the default choice for web-sites and web startups. For some years this has been Rails, and with good reasons. Though I think a Wicket/WebBeans/Seam/JPA stack is as fast for development as Rails, Rails is a good choice for rapid development for a VC demo. The problems are down the road some years – or so I hear form some CTOs – and Grails might be a safer choice with the easy possibility to go to Java for your stable layer later.

The only large – and lets say profitable and growing – startup that uses Java is LinkedIn. Although some internal systems at FaceBook (Cassandra) and other sites run Java in their core, Twitter runs parts of it’s services in Scala. They show that it can be done. Contrary the German LinkedIn competitor XING is written in Rails.

With Rails and Python moving into the Enterprise, is Java no longer the default choice for new projects there? Not that I know of. Perhaps some grass root projects go with Rails, the default choice still is Java, C or C# depending on your enviroment. Beside some funny view on enterprise applications:

It’s been 10 years and there are still no compelling client side or desktop apps in Java and all the compelling server apps (sorry enterprise apps don’t count as compelling!) are done in PHP, Python, Ruby, Perl, Smalltalk et al.

I can’t see companies move their programmers and default choice to Ruby, Erlang, Python, Lisp or OCaml. As this would mean polyglott programming and as Alex Ruiz writes:

I haven’t seen any practical evidence yet to convince me this is a good idea.

For you as a developer, does dead mean you can’t get any more jobs in Java development? Looking at Dice

shows that Java jobs are still high, with a significant increase in 2008. The German news website Heise News showed the same for project work, a more than 89% increase since the beginning of 2007:

203 in Q1 2007

384 in Q3 2008

Is Java dead because other languages are better?

With a different angle we can discuss the death of Java in the view of it’s potential successors. As a matter of fact a language cannot die without successors, otherwise noone could develop any software. People suggest a lot of successors, some of them are:

  • Ruby

  • Python

  • Groovy/Grails

  • Scala

  • Fan

  • Erlang

  • OCaml

  • Ioke

  • Factor

Not all of them – although excellent and interesting languages – share the same goals as Java and fit into the same place. Ruby and Python seem currently not enterprise ready, mostly because of tools, skills and deployments. This might change in the future, we’re not there yet. OCaml and Factor are interesting and capable, but too far away from the procedural mainstream that is the C legacy. Most prospects have the JVM languages, Fan, Groovy, Scala, Ioke. Fan doesn’t seem to have succession ambitions, Ioke is specially designed as a testing ground for ideas. Scala and Groovy seem to battle it out as successors. Scala has momentum and hype, companies use it in enterprise environments – and it’s also my current favorite. Groovy looks stronger, it made some inroads silently in the enterprise and with Spring having bought the Grails committers – and now VMWare having bought Spring – it’s better positioned than before.

Those successors need to be better than Java, otherwise it would me a folly to replace Java with high costs and gain nothing. What does better mean?

  • Faster to write?

  • More cost efficient?

  • Higher maintainability, cleaner code?

  • Shorter code?

Most of them are faster to write because they have shorter code. As I’ve shown, Java is 1.7x – 4x bigger than Python in lines of code, but does that mean Java is dead?

Most comparisions take 5 to 10-year-old brownfield, legacy Java projects with hundreds of developers – many of them average – and compare them with 2-year-old Rails projects, where the initial developers – most of them excellent – are still on board. For a real comparison one would need to compare state of the art frameworks, Webbeans/Wicket, Stripes/JPA with rapid development frameworks like Rails and Django. I’ll spare this comparison perhaps for another post in the future, but would be happy if someone does a decent comparison. I consider this question open.

A Java successor needs to go through the enterprise. There is the main beef, the most money and the most developers. To die a language needs to die there. Enterprise software is used for longer periods of time, with many developers working on it. The longer time periods mean higher turn-over during the life-time. Were are the problems in the enterprise and how could successors solve them in better ways?

Enterprise pain points

  • Maintenance

  • Readability

  • Reuse

Do the potential successors solve those pain points better than Java? Partially. Some of them have richer reuse models, some of them have better readability and are less noisy. But I also consider this question open – from my experience with many languages those problems aren’t solved. Perhaps because many language designers today disdain the enterprise. Scala is a sweet spot for me, it gains on those issues but doesn’t introduce new problems.

Goals of Java and does Java no longer meet it’s goals?

What have been the goals of Java? Those are linked intrinsically to the success, so we need to take a look at them, and if those goals no longer represent what people need. Those goals are many, but the main ones seem to be:

  1. Solve problems of C++

  2. Internet capable

  3. Standard library – JDK

  4. Automatic Memory Management – GC

  5. No error prone pointer operations

  6. Enterprise-Ready – a goal that evolved after some time (easy to use, low entry, big departments)

  7. Easy concurrency in the language

I can’t see that those goals are no longer valid, or Java does no longer fulfill them. The goals are valid, and fulfilled. Only concurrency is the item which is highly discussed and can be an issue. Concurrency is the future. Concurrency can be an issue as the early lock and synchronize system of Java proofed to be too difficult. The new trend is multi-core. Is Java unfit for massive multi-core machines? Java in later editions added easier concurrency with concurrent lists, queues and fork and join and is fit for multi-core machines. No worries at least for me that Java misses this trend.

One requirement to a language wasn’t seen as important in 1995 as it is today: Rapid development and rapid turnaround. Java still falls flat, even with JRebel which allows seamless reloading of classes, RAD web frameworks like Wicket and splendid IDEs. Rails, Django and PHP are better and have a faster turn around. Period. Java is lacking here, and reloading changes look to be the biggest problem with Java development today. Maven deployments are a pain after you’ve worked with Rails or PHP..

Faster turnaround has higher productivity. Which means more money. If Java doesn’t solve this – Java might be on the way to extinction.

Why should it die, what should we learn?

Java might die, because the drawbacks beside turnaround have gotten too big. Lots of concepts have been proven to be bad ideas.

  • Inheritance: outside of frameworks, inheritance is inflexible, leads to tight coupling and is plain bad. Composition is most often a better choice. As are mixins and traits

  • Noisy syntax: Lately there has been the enlightenment that too much noise in a language is a bad thing. Java is especially noisy in closures (anonymous inner classes) and generics.

  • Null / NPE: Null as the default for object references was a billion dollar mistake. An object should by default need a value. Otherwise NPEs will proliferate through your code. Newer languages prevent nulls or make the null behavior the non default one

  • Design patterns: Many design patterns are a good thing, but some of them are just covering inefficiencies in an only-OO language like Java

  • List processing: As shown by functional languages, list processing should not be done in loops. Many operations in applications are just that: get a list, transform the list, filter the list and return a list. Javas new for loop is better than the old – but solves the wrong problem. Java should have native support for easy list processing, not via the – best we have – constructs in Google Collections.

Those are valid concerns and one wishes Java would die for those. But the Java community is working on fixes – although as can be seen with the discussion on Closures in Java 7 sometimes too slow. I consider those problems painful, but not big enough that they will lead to Javas imminent death. They could lead to a death by thousand cuts though.

Java Future and what does this mean for you

From what I’ve written  I come to the conclusion that Java is not dead. It’s not fundamentally flawed, it still meets it’s goal, there is interest in Java, no really clear successor has emerged, the platform evolves, the JVM shines, new languages flourish and new projects are started in Java.

But just because Java is not dead doesn’t mean it has a future. Developers need to open their eyes and learn new languages. I’m really disappointed in interviews when candidates show no interest in programming beside Java. So for you as a developer: no worries. As a student: You still need to learn Java to have a high probability to get a job – with the conditions you like. For you as a manager or CTO: have a plan ready for when the Java era ends.

It’s too early for a requiem. But if Java dies, what can we learn? Before and foremost one needs to learn from Javas success and eventual decline. The points I’ve written about, wrong concepts, enterprise pain points and what Java did right need to be remembered.

Is Java dead because no-one talks about it anymore?

Thanks for bearing with me through this long post and we now come to an end. Jitter about Java has significantly gone down. My blogging on Java has gone done. My twittering on Java has gone down. Some years ago everyone was talking about Java, now it’s mainly enthusiasts. Java is a none-hype. It’s not as bad as COBOL, but a lot like C and C++. Is a language dead when none talks about it anymore? You decide. In the end the only question that really matters: Is Java dead for me? Would I start a project in Java? I would have in 2008. Would I in 2009? Probably not, I’d use Scala.

You can leave a Reply here.
Of course, you should follow me on twitter here.

Interesting thing to ponder is Java as a language vs. Java as a platform. Java as a platform isn’t going anywhere, and the fact that so many more “modern” (funny to think of Java as not modern now …) languages can be run on the JVM shows that there’s value in the platform.

I also think there’s still a lot of value in the language and when you look at some of the alternatives, I think we’ll see Java as a language around for a long time to come. Nothing else fits in the space Java does quite as well.

JavaScript is Becoming the Lingua Franca For All Development

Posted on by Matt Woodward

Let’s start with a trip down memory lane.

Way back when I got my first real job as a programmer, one of my first tasks was to work on some server-side JavaScript. Now I may be dating myself with that statement but yes, back in the dark ages there was a web server made by none other than Netscape called Netscape Enterprise Server, and you could write server-side code in JavaScript. It was darn handy, and a lot less nasty than some of the alternatives available back then, but for whatever reason it never really took off outside of Netscape’s web server product.

So an embarrassing number of years later, I’m not sure we’d call what’s becoming more and more prevalent these days “server-side” JavaScript, but JavaScript is living in a lot more places than your browser. And why not? It’s a great language, every web developer on the planet already knows it, and for developers who don’t know it, the syntax and concepts are easy enough to pick up very quickly.

We’ve had a few runs at JavaScript outside the browser over the years. I’m sure no one but me remembers IBM Sash, but it was a concept very similar to Adobe AIR–but predating AIR by about 7 years–that let you very easily write desktop applications in JavaScript.

I’m not sure why Sash didn’t take off other than IBM’s typical inability to capitalize on great technology (OS/2 anyone?), but it was a really quick, easy way to write desktop applications that were easily to download and update. And of course since it ran on the desktop you could do much more than you can within the confines of the web browser, like access the filesystem and store data offline to be synced back up later.

It was really interesting to see all the security concerns around AIR when it first came out because they were exactly the same concerns everyone had about Sash, but I wrote some pretty slick little Sash apps for internal use that did online/offline data and even file syncs (great for traveling sales people) long before AIR or even Macromedia Central. Ultimately I think the timing just wasn’t quite right for Sash.

Total aside, but another attempt at this sort of functionality was REBOL, which I also spent a bit of time with a long time ago, and I was a bit shocked to learn today that it’s still around. Who knew?

Anyway, back to JavaScript. Some of you know I’ve recently fallen in love with CouchDB, and the default view server in CouchDB is based on JavaScript. It uses the SpiderMonkey engine (a JavaScript engine written in C), and you write all your views in CouchDB in JavaScript. Simple, effective, and very powerful.

But there’s much more. Today I came across Tropo, which lets you develop cloud-based communications applications in a bunch of different languages, one of which is JavaScript. Tropo is completely new to me but from their code samples it looks like what you’re doing is programming telephony applications in JavaScript. Quite a leap from the button rollovers that used to be the common domain of JavaScript.

I’m sure there are numerous other examples, and perhaps nostalgia is really what prompted this post, but I think it’s interesting and exciting that the language we all know and love (or love to hate) is all grown up and doing a lot of cool stuff outside the web browser.

Where else have people seen JavaScript where you might not have expected it, and what are your opinions on JavaScript as a lingua franca of development? Personally I think it’s a smart move on the part of applications like CouchDB and Tropo to leverage JavaScript in this way but I’d love to hear your thoughts. I for one see a lot more JavaScript in my future.

Who thought OCaml was dead ?!

Posted on by Matt Woodward

Hi,

I’m writing this post because I want to thank and encourage the OCaml community. Indeed, there are many really *great* news this week that you may have seen if you read either Planet OCaml(Core), the Caml mailing list or both.

OCaml and Debian — The first one is a very good one for making OCaml more popular, more easy to install, etc : The OCaml 3.11 Debian package is now in Debian’s official testing repository ! Yeah ! I really congratulate the debian-ocaml maintainer team for the huge work. Considering nearly all installations of Debian stable are for server-like usages, having the package in testing make it easier to install OCaml and get it installed and configured in two seconds for all desktop users of Debian (and Debian-based distributions). Indeed, everything will be done with a single root command :

?View Code SHELL

1

 

# aptitude install ocaml

That’s all.

OCaml Batteries Included — OCaml Batteries Included Beta 1 is out ! If you still don’t know about it, you should quickly go on its website on OCamlCore, download it and install it and then read the documentation for an introduction and a reference manual of Batteries. You can also take the ocaml-batteries-included package on Debian’s unstable repos.
The Beta 1 is already having its first feedbacks and already provide a huge amount of necessary modules and functions, with some syntax extensions and tools for making programming with Batteries the easier possible ! OCaml was criticized because of its standard library, lacking of many additional stuffs that are in Haskell’s SL. Now, it’s over. Batteries is easy to install, easy to use and provide a great new-standard-library. Come on, test it and give some feedback.

Cheers guys !

BTW, the French government still ignores problem related to the reforms about Universities and Research. They’re killing the whole University concept and system and still ignoring that great Researchers are working for a really bad salary, in bad conditions even if they’ve studied 8 years long at least and that there are people paid much more than what Researchers are, for much easier and cool works… Strikes goes on, we must save our Universities !

In case you thought death rumors were unique to CFML. 😉

The Passionate Programmer and Value Rigidity

Posted on by Matt Woodward

I have to thank Mike Brunt for the mention of Chad Fowler’s The Passionate Programmer on Twitter (yes, occasionally worthwhile stuff crops up on Twitter …), because it’s one of the best programming books I’ve read in recent memory. It has nothing to do with coding or a specific technology, but I strongly believe it’s one of the more important and impactful books a programmer can read, regardless of their choice of technology.

Personally I love reading things that cause me to question at a very fundamental level what I’m doing and why I’m doing it. If you don’t do this every once in a while you may find yourself off in the metaphorical weeds, having a hard time getting back on track or even figuring out what direction you’re supposed to be going. The Passionate Programmer made me question something about what I’m doing and where I’m going with every chapter.

Coincidentally enough I watched the documentary TED: The Future We Will Create last week. It was inspirational throughout, but there was a particular moment that resonated with me. One of the TED prize winners that year was Cameron Sinclair, who is the cofounder of Architecture for Humanity, which advocates for “building a more sustainable future through the power of design.” One of the more amazing examples he gave in his TED talk was a building that was planted (as in using seeds), grew to 14 feet in height in a month, and then could be eaten when the building was no longer needed.

That’s extremely cool in and of itself, but another architect at TED that year was Rem Koolhaas, who designed the Seattle Public Library. I haven’t been to the library since I moved here, but after seeing this film I looked into it more, and it’s an amazing piece of modern architecture, both in terms of its visual impact as well as how the space is designed to suit the specific purpose for which the building was built.

In a brief interview with Koolhaas in the TED film, he said that the presentation that impacted him the most was Sinclair’s, because (and I’m paraphrasing here) it made him fundamentally question his approach to architecture and what he was doing with his skills. Coming from a guy who built such an acclaimed building (and I’m sure he’s done many other great things in his career), that’s rather astounding.

So back to programming. The Passionate Programmer is fantastic throughout, but what hit me like a ton of bricks, and what made me think of the TED documentary, was a chapter entitled “The South Indian Monkey Trap.” Without going too much into the reference, this chapter makes the point that “rigid values make you fragile,” and that fragility is definitely not a good thing for a programmer. Quoting the book:

“For example, it’s easy to get hung up on technology choices. This is especially true when our technology of choice is the underdog. We love the technology so much and place such a high value on defending it as a choice for adoption that we see every opportunity as a battle worth fighting–even when we’re advocating what is clearly the wrong choice.”

I’m sure folks in the CFML community recognize the tendencies here. Clearly I’m not saying CFML is a bad choice–far from it. I wouldn’t continue to use CFML if I thought it was bad. But one of the points I made in my “Best of Both Worlds” presentation at cf.Objective() this year (you can watch it here if you missed it), is that while CFML is a great choice for a lot of things, we do ourselves a disservice if we get too myopic on our technology choices. If the only tool you have is a hammer …

Now on the flip side of this, you may look around and find that seeing what else is out there reinforces your notion that CFML is a great tool for most of what you do. Even if you come back to where you started, however, there’s a tremendous amount of value in the exploration.

The other thing I love about The Passionate Programmer is that each chapter ends with an “Act on it!” section. In the case of this particular chapter the actions suggested are:

  1. “Find your monkey traps,” meaning identify your rigid values and do some soul searching on them.
  2. Know your enemy: pick a technology you hate, and build something in it. Not only does it help knowing what you’re fighting against more intimately, you add a new skill to your toolbox and might even find that the technology you hate does some things pretty darn well.

So that’s some of what’s been going through my head lately. Agree or disagree, I really do encourage you to read The Passionate Programmer because it will inspire you far more than I possibly can in a blog post overview.

Comments

Just added it to my Amazon Wishlist, thanks for pointing this out. “The Pragmatic Programmer” is another good one from the same publisher.

Posted by Ryan Stille @ 8/6/09 8:23 PM

Sounds interesting. I hope I will find the time to check out this book.

Shlomo,

http://www.shefertech.com

Posted by Shlomo Schwarcz @ 8/6/09 9:31 PM

I’ll have to check it out. On a side note, TED talks are just the most amazing thing since sliced bread. Clark Valberg turned me on to them a year ago. It’s like candy for my brain.

Posted by Ben Nadel @ 8/7/09 6:49 AM

Hi Matt,

I got the original version of the book when it first came out (My Job Went to India: 52 Ways To Save Your Job) and remember an interview with one of the prag publishers (I think it was Andy Hunt) who said he wished they’d picked a better title because they felt the title killed the sales of the book.

I’m glad they re-released it the other month with a new title, and I think it’s a great read. Hopefully with the new name it’ll get the sales it deserves (well, the new title, and of course the plug on your blog 🙂 ).

Posted by Peter Bell @ 8/7/09 7:02 AM

I was looking at “The Passionate Programmer” on the Pragmatic Programmers site last week, along with “Pragmatic Thinking and Learning”. I would have bought them both by now, but my strategy for managing my spending is to keep telling myself whenever I want to buy something that “I don’t need it yet”. This post (along with the fact that today is my pay day) has convinced me to go ahead and get them.

To correct Ryan’s comment, The Pragmatic Programmers (Andy Hunt & Dave Thomas) wrote the book “The Pragmatic Programmer” but are not the publishers for it, as they wrote it before getting into the publishing business. The biggest consequence of this is that there is no eBook version available of that title. I believe Dave & Andy have made a point of selling DRM-free eBook versions of all the titles they publish, which I think is pretty darn cool.

Posted by Dennis Clark @ 8/7/09 9:46 AM

Avoid Refactoring Yourself Into a Corner

Posted on by Matt Woodward

We have developer meetings twice a week at work, and we use these as a forum for people to show things they’ve been working on, ask for advice on how to approach solving a particular problem, share cool tips and tricks they learned, etc. This has been working really well and fosters what I think is the most important aspect of any development team: learning from each other. Regardless of the various skillsets and experience levels on a team, people have different areas of expertise and I learn something new or start thinking about something differently at every one of these meetings.

Today’s meeting was particularly interesting and since it’s not an uncommon situation, I thought I’d share a bit about it. A co-worker has been working on an application for the past few months and this application has a very hard deadline. Without going into all the specifics, based on the client’s own description of how things should work, this is a person-centric application, meaning everything in the application revolves around data associated with an individual person. Each person has basic demographic data but also a minute-by-minute timeline associated with them, and this timeline consists of events that may either be unique to the individual person or may be inherited from a parent group that is used to organize individual people.

We’ve discussed this application quite a bit at our developer meetings lately because it’s been an interesting exercise in developing with Mach-II, but more importantly it’s been a great case study for effective domain modeling in an OO application. It’s simple enough that it’s not overwhelming from a learning standpoint, but it’s also complex enough and has some interesting wrinkles that take it well beyond the level of the basic OO applications that we’ve likely all studied or seen in conference presentations a thousand times. It’s been great because even the people not involved with the application are learning a lot through the discussions at the developer meetings.

The basic overview of the domain model is there is a Person object, which is a typical bean, and one of the attibutes of a Person is their timeline, which for ease of use and efficiency is a query object. When a Person is instantiated they get their timeline, which is created from events explicitly associated with that individual person and potentially events they may inherit from their group timeline. This works very well in dealing with individual people and their individual timelines.

Just recently a new person on the client side was added to the mix. (If you’re saying “uh oh” at this point, you know where this is going.) This person looked at the application and from her perspective, everything was backwards. Because of her concerns with the data being managed by the application, it shouldn’t be person-centric, but rather should be timeline-centric since her role in things is to be focused exclusively on the high-level aggregate timelines as opposed to the timeline of any individual person.

Natually this was a bit of a “D’OH!” moment. While it would have been nice to have this perspective from the outset and potentially would have changed the approach taken in building the application, the reality of the situation is that we have to get the application done very soon and we have to satisfy the new requirement in order for the application to be useful. Such is life as a developer.

Since the application has been to this point entirely person-centric, my co-worker was going down the path of thinking of aggregate timelines as a grouping of all the individual timelines, which on the face of it might not seem like a bad approach. The issue is that there are a minimum of 1500 individual timelines with a potentially large number of events per timeline, and since they may change extremely frequently, caching isn’t a realistic option. Obviously instantiating 1500 objects just to get at query data would be a nice way to bring the server to its knees rather quickly.

Another great aspect of developer meetings is the chance to get a completely fresh perspective. It’s easy when you’re neck deep in an application to have your thinking get a bit rigid and not be able to see the numerous other ways in which the problem you’re facing might be solved. So you start going down straight-line path you see in front of you and figuring out ways to tweak what’s already there to handle a new requirement that may well be the antithesis of what your domain model was originally designed to address.

My co-worker described this situation as “refactoring himself into a corner” and I think that’s a really apt description of what tends to happen in these situations. Partciularly given the recent discussions about all things OO in the CFML world, this seemed rather timely because my co-worker was thinking all about the objects and the domain model and not about the data. I know, you can probably quote me from any number of my conference presentations saying that’s the way you should think about things, and I stand by that … for the most part.

In this situation, however, what we’re really after has nothing to do with the domain model (well, little to do with the domain model at any rate … more on that in a moment) and everything to do with reporting on aggregate data. These are two completely different ways of looking at things, and going down the object path when what we really want to do is produce a report starts to feel wrong rather quickly. If something feels wrong don’t ignore that feeling, because it probably feels wrong for a reason.

Luckily since my co-worker did focus on the domain model so thoroughly in the initial design of the application, the data itself was all nicely organized in the database. This was really is a side-effect of the domain model design as opposed to a data-centric approach to building the application. (Not enough time to go into detail on that point so I hope it makes sense at a high level.)

With the data sitting in the database, why worry about the Person side of things and all those objects? My suggestion was to forget about all that and focus on the end goal of what we need for the timeline/reporting side of the application. Clearly for Person and individual timeline management what has already been developed is important and will continue to be used as it always has been, but timeline reporting is a different requirement and needs a different approach.

Once you throw all the person-centric bits out the window it becomes a lot more clear. The data’s in the database, so rather than thinking of an aggregate/master timeline as being made up of individual people, why not just leverage the database to do the reporting? Maybe this calls for a view to be created, or maybe it’s a rather simple query/stored procedure, but since what we want is a big list of data, creating that from a huge number of individual objects just doesn’t make sense.

Now that doesn’t mean that OO goes out the window completely. Since this is a Mach-II application, chances are this will mean a Listener, a Service, and a Gateway in front of the raw SQL that does the reporting, which means the reporting functionality will integrate nicely right alongside the person-centric part of the application that’s already done and working well. More importantly, it gets down to using the right tool for the job. Databases are (shocker) great at managing data, so putting that work in the database will not only make things a lot more efficient than shoe-horning all the individual beans into a construct where they don’t belong, it just makes more sense overall. In short, think in objects unless you shouldn’t. 😉

I’m not sure there’s a real moral to this story other than to point out that when you feel like you’re refactoring yourself into a corner, stop, take a deep breath, and force yourself to think about things differently. Throw out all your preconceived notions and if that’s difficult, grab a team member or three and talk through the problem with them. It’s almost better if they don’t know much about your application because they won’t have the mental baggage that you do about things, and won’t have any concept of how much rework is involved to implement their approach. And once you have them sucked in you can always get them to help you build the missing pieces!

Comments

Nice! 🙂 That notion of having “baggage” that keeps you from seeing the simple solution applies to much of life. I don’t have any URLs handy right now, but I know that there’s been at least one study that shows that the more experience a person has in a given field, the less able they become to learn new or different approaches because there’s so much reinforcement behind the techniques they’ve already learned.

And in this case also dovetails rather nicely into a comment Adam Haskell made a while back about one of the nice things about Fusebox being that you don’t have to write objects for things like a report page where there’s not much behavior going on.

Posted by ike @ 11/4/08 12:36 PM

Very good read. I think the comment near the end sums up my feelings:

“More importantly, it gets down to using the right tool for the job.”

If refactoring is the tool that is called for, so be it. Just know that it isn’t the tool *in every case*.

Posted by Shawn Holmes @ 11/4/08 2:21 PM

Great piece, and definitely not a rare situation. Think it bears pointing out that just because the solution isn’t going to be use of the existing objects in the existing domain model, that doesn’t mean the solution isn’t going to be OO. As you noted, the solution to the aggregate reporting is still going to be handled in MachII. The issue really is that the domain model is being extended, right? Because it’s a new requirement, it can be handled by a new domain model, a set of objects that just happen to consume the same data as the original app is already capturing.

I think that can be such a key as well: simply understanding when a change really does impact an existing requirement and when it doesn’t. Often the ability to extend your model to add a B option to your existing A option is entirely reasonable, and that ability to extend without destroying is one of the biggest benefits to OO modeling.

Posted by Jason Fisher @ 11/5/08 5:34 AM

As I am trying to dive deeper and deeper into OO, I am definitely seeing that there is a serious difference between what one might consider as being part of the domain model and one might consider to be reporting.

Not too unlike your scenario, I was going through a thought-experiement in which I imagined a Library object. And I asked myself, Should object have a GetBooks() method that returned a collection of all books in the library (potentially millions of objects).

While months ago I might have said YES, I understand that this is a bad idea. Yes, this would probably crash the server, but that is not what actually swayed me. What made me realize the absurdity of such a method was the question:

Would this collection of data be more useful as objects rather than as a report?

When I was challenged to come up a feasible use case in which I would need to affect millions of objects, I realized that this is data that should be report oriented.

Then, I also came to the realization that there is a difference between domain-based actions and “bulk” actions. If I wanted to increase the price of all products in an ecommerce store by 10%, I certainly would instantiate each product, update the price, and then save it. I think what would make more sense is to have some object (maybe a gateway or a service) have methods that allow for bulk actions.

Posted by Ben Nadel @ 11/5/08 2:48 PM