Drag&Droppers vs. Console-Freaks

In Episode 392 of DotNetRocks Carl and Richard discuss with Ron Jacobs. When they come to M, the modeling language in the Oslo Project, they talk about developers that don't like Drag&Drop-Editing (Designers, Wizards, complete IDE-Integration, whatsoever ...):

... some people really like that. They are like: That's great! And then there is a group of people who are like keyboard guys. They hate to take their hands off the keybord and even touch the mouse...

They give the impression, that those kind of developers are stuck in some age long past, likely ignoring reality and completely indulged in their religious debates about vi versus emacs ...

That's an attitude I often encounter in marketing-infiltrated management persons.

They think that they are enlightened because they have seen some shiny click-and-go demo of the newest flavor of The Application-Generator(tm)... and they think that all the developers out there in the trenches of enterprise IT just refuse to see the light, because their convoluted brains cannot grasp that their existence becomes irrelevant since The Application-Generator(tm) would make coding unnecessary ...

Thats just snotty ... most developers have had experiences with Drag&Drop-Wizard-Whatsoever-Editors, but they have been burned!

Most of the stuff is just demo-ware! A heavy toolchain focussing on an initial surprise effect.

But the resulting solutions are just not elegant, not sustainable and not scalable from a development perspective!

The problem with the Designer in the recent .NET Entity-Framework seems to be a typical example for this ...

Another thing are tools that only integrate into the IDE and do not offer a standalone (this usually means 'command-line') execution. This is just not scalable from a development perspective, because it prevents automated builds! Not having to touch the mouse is not really a personal issue here!

follow me on twitter, I need some friends :-)

Java EE Testing Workshop

Last week I was holding my semi-annual workshop about Java EE Testing at the Software Schule Schweiz (SWS).

The workshop material can be downloaded here.

One thing I did newly include was EasyGloss: a framework for simplifying unit testing of annotated classes that require injection in order to function.

Apart from that I did only very few changes compared to last time. This time was the first time where my preparation effort was actually quite low, which made me somehow proud ...

... but then again, the whole topic is out of fashion as I learned in this interesting presentation: Testing is overrated. Maybe I should start looking for another topic ...

follow me on twitter, I need some friends :-)

Only dead fish swim with the stream...

While I am still pondering about my idea of the transformation from Coding Whore to Opinionated Developer, I stumbled over some quite opinionated statements:

Joe Armstrong (inventor of Erlang) about object oriented programming:

When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong".

Graeme Rocher (founder of Grails) about Maven:

I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered

follow me on twitter, I need some friends :-)

Give me a hint: How are programming languages related to problem domains?

From Jay Fields' The Cost of Net Negative Producing Programmers:

Java and C# are not silver bullets. The languages are good solutions to a certain class of problems, using them for problems that could be better solved with a different language stagnates the growth of other languages.

Now I am wondering: Is a general programming language really predestined for certain kind of problems and not suited for other kind of problems?

I can see that performance could be an issue. But apart from that, is the problem domain really a relevant aspect for choosing a language?

I could agree that platforms and frameworks could be targeted a certain problem domains, but I cannot really see if this is true fro languages. I also think reality shows that the same kind of applications can be solved with all kind of languages, and the results are equally valuable.

I think there are much more important influences for choosing a language than the problem domain. Like experience of the team, available knowhow and infrastructure, reusing investments and creating homogenous environments ...

Can anybody explain to me how the problem domain is relevant for choosing a general purpose language? I would be very much interested in examples ...

I agree that DSLs offer a whole new perspective on this topic, but we are talking about general purpose languages here ...

I also agree that there are niche problem domains (like scientific calculations) that could certainly better solved with special languages, but again, we are talking about general purpose languages ...

follow me on twitter, I need some friends :-)

Followup: From coding whore to opinionated developer?

My post "From coding whore to opinionated developer?" earned some comments which put me in the position of a spoiled whining smartass...

Now Jay Fields has posted The Cost of Net Negative Producing Programmers.


Here two quotes that remind me of the theme of my post:

These NNPP architects build entire armies of NNPPs around them and single-handedly waste millions, if not billions of dollars, annually. And, potentially worse, they ruin or at least drastically hurt the careers of eager to learn teammates.

I do think there are things we can do to help move the industry in the right direction. The good programmers can refuse to work with bad programmers. That might mean moving to an organization where that's a goal, or making that a goal of your current organization.

... it seems that Jay is quite opinionated!

(Eric Evans from Domain Driven Design did say something in the same direction.)

On the same front Obie is blogging about Attributes of Good Clients.

follow me on twitter, I need some friends :-)

From coding whore to opinionated developer?

Have you also been on projects where things were done entirely different to your own opinions.
Maybe they totally contradicted values that are most important for you? But you coped and went along?
Did you feel compromised, even dirty, for not resisting? Did it make you feel like a coding whore?

37signals and Ruby on Rails shaped the concept of opinionated software.

As most ideas from 37signals, I like the concept of opinionated software.

Now I am wondering if the concept of being opinionated could be extended from software to ... the developer?

When coming to a new project, take a good look! As a developer you don't have to put up with everything! Evaluate your opinions:

No Source Control? - Where is the exit, please ...

No Unit Tests? - Thanks, I am out ...

Continuous Integration is a foreign word? - Sayonara from me ...

Staging, what is that? - Good bye ...

Stakeholders are not readily available? - These boots are made for walking ...

...

Is that being arrogant?
If you have opinions, why should you not commit to them?

follow me on twitter, I need some friends :-)

Simplistic CRUD application with Grails on GlassFish V3 Prelude

My colleague Matt wrote a brilliant tutorial: EJB 3.1 and JSF 2.0 with GlassFish V3 Prelude.

A commenter on Matt's post claimed that using Grails to create the same application would be a tremendous simplification.
I wanted to find out if this was really true, and how much effort it would actually take to achieve the same functionality with Grails.

This post is not a Grails tutorial, and it is also not the goal to create an intelligent application. The goal is to reimplement Matt's application as efficiently as possible.

I assume, that you have GlassFish V3 Prelude installed.

Step 1: Install Grails
Start the updatetool or start glassfish an go to the updatetool inside the admin console. Select Grails for installation and perform the installation.

Set the environment variable GRAILS_HOME to point to the Grails installation inside GlassFish, and include the Grails binary in your PATH.

On my OS X system this meant putting the following lines in my .profile:

export GRAILS_HOME=/Applications/NetBeans/glassfish-v3-prelude/glassfish/grails
export PATH=$PATH:$GRAILS_HOME/bin

Step 2: Create a new Grails application
Execute grails create-app CRUD-GRAILS in on the console.
This creates a directory named CRUD-GRAILS with a fully functional Grails project skeleton.

You can start your new Grails project with grails run-app. This starts up GlassFish and loads the application. The application is available at http://localhost:8080/CRUD-GRAILS.
As you can see there is not much there apart from a welcome screen.


Step 3: Create the Book entity
Execute grails create-domain-class book from inside your project directory.
This creates the file grails-app/domain/Book.goovy that contains a skeleton class for the book entity.
You could also create the file manually, the grails command just also creates a file for tests...

Edit Book.groovy to add properties:

class Book {
	String name
	String isbn
}

Step 4: Create a controller
Execute grails create-controller book from inside your project directory.
This creates the file grails-app/controllers/BookController.goovy that contains a skeleton class for the book controller.

As with the Book entity, you could also create the file manually, the grails command just also creates a file for tests...

Edit BookController.groovy to provide the CRUD operations on the book entity (this is called scaffolding):

class BookController {

    def scaffold = true;
}

That's basically it! The application can create, update, show and delete books.

It took typing three commands and writing three lines of code ... all completed in less than 10 minutes ... not bad I would say!

Let's see what Grails has to say: grails stats

	+----------------------+-------+-------+
	| Name                 | Files |  LOC  |
	+----------------------+-------+-------+
	| Controllers          |     1 |     3 | 
	| Domain Classes       |     1 |     4 | 
	| Integration Tests    |     2 |     8 | 
	+----------------------+-------+-------+
	| Totals               |     4 |    15 | 
	+----------------------+-------+-------+

Ok, using dynamic scaffolding is a bit like comparing apples with oranges ... lets change that: grails generate-all
This generates the concrete views and the controller for the book entity, that have been generated dynamically by scaffolding up to now...
... now you can look at the code and adjust it to your needs.

Another little thing is getting rid of the Grails logo. Edit grails-app/view/layouts/main.gsp: Delete the lines between the <body></body> tags except <g:layoutBody /> ... I think we stay with the nice CSS and icons :-)

Ok, I don't claim that Grails is a silver bullet, but it is quite impressive how fast you can achieve some core functionality! The question is now how well it scales for real-world-requirements ...

Matt are you ready to implement some entity-relations, validations, conversations, AJAX-UI ... ? I would be ready for the challenge :-)

follow me on twitter, I need some friends :-)