The problem is all inside your head they say to me

No activity in this blog, since I attended JZ'10. I crashed and burned on the blogging marathon, and after writing two pieces, taking notes at a whole lot of the sessions, I said to my self that it wasn't worth it. So I quit.

The blog is not dead though. I just had to think it through; I don't know if I want to regurgiate what other people say without me actually getting something out of it. This sort of blogging is totally useless to me, so I just won't do it.

That's my excuse for not doing what I said I would do. 

Right now I'm working on a cool project for the community and I will write a little piece on that soon.

I will cover the november meeting as well (as long as it's interesting).

Session 1 : Emergent design

(btw, sorry about the delay. in contrast to my work, I don't always deliver on time! apologies aside .. here is the first one...)

Holding the lecture: Neil Ford

Link to his bio

So he has a page on this topic;

Evolutionary architecture and emergent design : investigating architecture and design

Link til this article

Ok, let's start off by saying, I was looking forward to this one. Not only being the first of the sessions, but also with Neil Ford, whom I've never seen, but only heard good things about. That being said, I did enjoy it. Sort of.

It was basic. Is that ok to say? It should be. I'll sum it up in the end.

The tagline "There are things we do not know we don't know" was the red line through the talk.

In bullet form I'd say he says this is the problems;

• software is changable, not like hardware. it's soft. this is the cause of the problems that might emerge.
• software we produce has two parts that can be changed, but some stuff is harder to change than other. architecture is harder to change than design choices.
• don't build lots of layers for extension that can be built on later. sometimes you create a generic obfuscation and sometimes you add complexity to something that might be simple.

There are ways to get out of the problems by:

• postpone decisions as long as you can. if you wait until you really have to, you can make the right decision easier. it's all about what you know. 
• fix stuff right away. waiting will only make it worse. you know it. I know it.
• try to take metrics from the complexity and usage of your code. the combination of these factors might give you an indication for what you ought to fix.
• write tests when writing code. your code will get a structure that might save you from making mistakes.
• make use of patterns, and try to find places where you've repeated yourself. 
• time spent early on design costs money and is prone for errors

There was more, but all in all, this is what I got out of the session. My memory might be playing tricks with me as well, since it's been a whole day since I saw it. But all in all, I found the session a bit basic, and I feel I've heard this in some form or another over the last years repeatedly.

JavaZone 2010 - introduction day #1

Welcome welcome, small and big to the event of the year! Forget about christmas, birthdays, midsummers eve and your grandfathers 80th aniversary; this is the one that counts.

About 2000 people are now on their way to Oslo Spectrum. There will be music, coding, bullshit and sessions. Over the years javaZone had numerous crazy stage shows performed by some insane people; Pain solution, Cirkus cirkör, Rammsund etc. It's always some cool show. I'll post some pictures after we're done.
(note: this year they haven't invited insane people, but rather asked companies to form garage bands, and they will be the entertainment. I'm skeptic, but I will keep an open mind.)

JavaZone first released a trailer to this years event. Someone ripped it and put it on youtube, and must have been viewed by more than 1 million ppl. Here's a link;

Java-4-ever trailer

then they followed it by a music video

Lady Java music video

Pretty professional! I think the split between ".net and java"-part is funny, even though I think the community is past this "conflict" by now.

I've planned to attend the following sessions the first day:

• Seven cost-efficient ways to reduce your project overruns (or maybe I will try "Emergent design", all depends how full the room will get)
• JRuby: Now With More J!
• How we blew our shot at beating Spotify, spending two metric truckloads of cash doing it
• Flying with Griffon
• How to Defend Against the OWASP Top Ten Web Security Threats
• 97 Things Every Programmer Should Know

Check out the agenda for more info. I probably won't be able to attend all of this, since I have other stuff to do here at the conference.

After the sessions there is club zone, and I'll try to cover that (we'll see if I bother).

In addition to being an attendant at the conference I'm also part of the crew organizing the event.
You can come and talk to me at the javaBin stand from 14:10-15:40 (on wednesday).

Well that's enough intro, I guess; Let the sessions begin!

JavaZone 2010 coming up. 8-9th of September.

So after a couple of months in the cave, the grizzly awakens with renewed strength. Me being the grizzly.

The main java event in Norway of the year is approaching, and I'm going to be there. Not only be there, but also try to blog about every single session I attend. A tour de force in blogging as far as I'm concerned. You can expect all my posts to be sort of incomplete and unsatisfying on some level :)

Check back here on the 8th for the first post!

May: Play Framework

So we had the good fortune to have Jean-Francois Poux from the development team of the Play Framework join us for a session at the meet up in May.

If you haven't heard of Play before, take a look at http://www.playframework.org/

Jean-Francois basically coded through the screencast found at the frontpage of their web site, answering questions as the session progressed. If you look through the 10 minute screencast, you will probably get much of the same information as we got at the meet up.

A couple of days after the meet up, some of us got together to code through the Blog-example of the application with some developers that hadn't done anything in play before. It seemed as if people's reactions were overall positive with the experience; the comfort of coding in java and the convenience of the framework handling many aspects of the complexities connected to developing a web application. Concerns were ; a) the uncertainty of the longevity / popularity of the framework and b) how it would be possible to use/sell play in a enterprise situation.

I had done the blog example on a previous occasion, so I set out to code something different and very simple that could go out in production on the same evening. This is what I created;

App name: javaBin:Helter

Purpose: Vote for your JUG community hero.

Real purpose: Recruit people to get active in the community

Github: http://github.com/esschul/javabin-helter

I tried to use some of the stuff that play helps you with;

• routing
• email support
• captcha
• upload image

Check it out :)

btw: I code in Norwegian, because I like it. You might not...and oh yeah .. the code isn't exactly what I would call good, but I did it quickly and it works :) So improve it if you like ;)

The bad:

• The documentation is at first sight very good. "It's funny, it must be good". I felt like they started something good, but never completed it. I am convinced there is a lot of the magic they could've explained in more detail. But then again, it's as good as the other stuff we use day to day. My other beef with the docs is that it could be more organized.
  
• How to sell this to a client? You could say that it's just another java-framework, but that's just not true. It's a complete revolution, and many will feel like this is something very different from what they've done before. The client will also have a problem accepting a technology called "play". Like Groovy; it feels more on the fun side and less on the "we are serious business men"-side. But they do have this page of testimonals ... so maybe :)
  
• Smaller community than f.ex Grails. Small communities don't produce as many modules as the big ones. I do love my modules.

The good:

• It's a real "share nothing"-framework. Just check out routing in play. I do love the urls I get here (wicket does this soooo much harder).
• It has what I need. If it doesn't, I just drop a jar in the lib-directory. If you need dependency management, check out the Ivy-plugin or the Maven-plugin.
• No building. You needn't. It compiles runtime. I also love to get clear errors right out in the browser. It's the first time I've coded java in texteditor, I simply didn't need the IDE (not that you can't, it has support for both eclipse and intellij).
• You have to like the template system
• Nice samples and tests are bundled with the framework. Look at them to get inspiration.

Afterthoughts:

I like Play. Simple, elegant, and most important; fun. I don't think I will ever use it in a big enterprise project, but this is not because I don't want to. They(you know who I'm talking about) probably won't let me. Maybe if it catches on in a big scale.

If you do decide to start something, know that you can get support from the community at their google group. I don't know how responsive the board is though, since I haven't used it much myself.

Since this is my first post here, feel free to say what works and what doesn't. I do want this to be readable.

Reboot

I've done a reboot of the blog, and will now churn out monthly posts about the meetings held at the Oslo Java User Group (javaBin Oslo - http://www.java.no).

Expect a variety of code examples posted to my github-account, and rantings about what's good and bad (in my opinion).

Stay tuned!