Lair of Peppe

I have felt all my time being a programmer that I don’t know enough of my field of profession. I guess you could call it a healthy curiosity and the need to become a better software engineer. At first, when I started working, I wanted to get a better grasps of the very basics. Learning to use Java efficiently, which is the language I work with, learning nifty programming tricks, coding in an object oriented way, testing, building, refactoring, writing maintainable code etc. I feel that I have gotten a hang of these things now and my curiosity has moved on to other things. My latest interest lies in third party frameworks which have caused a big buzz in the Java community lately. I tout people to use our company’s GUI framework, but at the same time I haven’t bothered to look at other readily available frameworks out there.  I guess that many in the branch too easily just starts to code their projects head first, instead of taking the time to look around for a moment too see what’s available out there. Many of the common project requirements have already been coded a bunch of times, and many end up building their own little framework when there is already many proven and free solutions available for download. I don’t think it is so much of a case of the Not Invented Here -syndrome (NIH), although it could be a factor, but more of not just knowing enough of all the powerful tools that you could add to your toolbox.

I have therefore gathered a list of frameworks that interests me, but of which I don’t really know anything about. The biggest one of these is the Spring framework. Next of the bat comes Maven and the third is db4o. There is a few others too but I won’t go into details right now.

The parts of Spring that I’m most interested in is building more modular applications with its Dependency Injection (DI) and Aspect-Oriented Programming (AOP) capabilities and it’s Object-Relational Mapping (ORM) integration tools to automatically handle connections, transactions, exceptions etc. to the database. I use Hibernate a lot and Spring has Hibernate integration, so I’m interested to see what parts of my own code is already implemented in a more generic solution into Spring. I just got the book ‘Spring in Action‘ by Craig Walls that I’ll start exploring at some point. The downside is that the book is 700 pages and I’m a terrible slow reader. On the plus-side, Spring in very modular in itself and the most important modules are presented in the very beginning of the book. That means that I can take some new features to use after every chapter.

The one that I’m going to look at first, however, is Maven. Maven is first and foremost a build system to easily produce jar:s, war:s and ear:s of your projects. Additionally, it can download other framework jar:s for you and easily plug them into your project. I’m looking into it to simplify project structures and have it help me to handle dependencies between my own projects when there can be up to six different projects depending on each others.

db4o interest me because I want to see what alternatives there are to SQL. Object databases is one of them. I’ve heard that db4o is really simple to use and that would be a great asset to small pet projects.

So those are the frameworks I’m gonna start off with to enlarge my Swiss army knife. I’ll start with Maven as I already have tested out it a little, it is fairly compact and it defines the project’s structure. It’ll be a lot easier to add on the other frameworks to the project when I’ve laid the foundation with Maven.

Let’s see how this starts off..

I’m sitting in a car for the moment, on my way to a business trip. I’m listening to music to kill time and I suddenly got an urge to write a blog post about my ambition towards music. But what to do? I have no computer in front of me, and probably at the point when I do, I’ve lost “the right mood” to write the post. I decided to download Tumblr’s own app (Tumblr is where this blog is hosted) for my iPhone and test if it is any good for writing these post. The app seems quite nice, and writing this post hasn’t been an hassle at all. It has the ability to store drafts, so I had the possibility to take a break from the writing too. Only down-side, and this is a big one too, is that it doesn’t support the landscape keyboard. I did a lot of mistakes all the time, but the typing speed was still decent. A spell checker would have been nice too. The next phone I’ll get will probably be a ‘yet to be announced’ android phone with a physical qwerty keyboard. That’ll fix at least the former problem.

On a related note: I dropped my iPhone today for about the 20th or 30th time and this time it shattered in one corner. It however still works perfectly and I’m suprised it lasted flawlessly this long.

By the way, I already forgot all my great ideas for my music-related post, but I’ll at least be prepared the next time I get them.

Two days ago, we had this long discussion on the public Vaadin skype -channel about if how you should run Javascript in an Vaadin application, which continued a little on the forum and over lunch. It turned out fast to be an discussion about if Javascript should be allowed at all to be run from an Vaadin app. It was a discussion between ideology and convention.

The side defending the idelogy had the point that allowing Javascript would break the level of abstraction. The strong point of Vaadin is that it is very easy to use as you can do great things without knowing anything about Javascript, HTML and CSS. You only need Java. By opening the abstraction you soon get some implementations that depends on the low level API, and everybody has to learn those too to use Vaadin. Usability goes down. Another reason not to, is that I guess it would be really easy to break the whole software by running custom Javascript. Just like it is easy to break the software with custom css if you don’t know what you are doing. The whole API gets bloated at the same, when you add feature after feature, so you have to be critical about what you add.

The convetional side had the arguments that every abstraction is leaky. As a reference works Joel Spolsky’s blog post ‘The Law of Leaky Abstractions’. Sometimes you just have to drop down to a lower level to get things done. This becomes apparent when your Vaadin application has to work in symbiosis with some old system, and you have to embed jsp pages somewhere. How do you communicate between the Vaadin app and the jsp pages? Some of the main issues here has been to close a window (js: window.close()) or print some jsp/hmtl page from the application (js: window.print()).

At first I was strongly on the side to not let the user use Javascript. Think of all the possibilities you open up for hackers! Think of all the possiblities you open up for the programmer to really really mess up the application. One option that came up  was that it should be a separate extension to Vaadin, not embedded into the core Vaadin library itself. It should fit well as a component into the upcoming Vaadin side product ‘Directory’, which will be a web page where you could download custom made components for Vaadin. The users can jump the extra hoop and download a component from there, if they really, really want the ability to run Javascript, at their own risk. This way with wont pop up to users that doesn’t care about Javascript. I decided to do just this, build a Vaadin widget that runs any custom JS the programmer specifies. I did it because it was trivial to do and becuase I did not really want the feature into core Vaadin. You can find the code from here, a demo of it from here, and a  forum discussion about it from here.

After thinking about this for a while I have started to lean to the opinion that js built in would not be that bad. Hackers can’t use this very much as Vaadin has a strict barrier between the server and the browser. I also haven’t found out that there is some really really bad that you can do with js. You can’t really crash the server because all javascript runs in the browser. So the risks of having it seems to diminish all the time. I also heard someone saying: When Vaadin fails, GWT saves. When GWT fails, Javscript saves. And this is the solution for all the cases where it would be just easier to to a one-liner in the low level language.

I’m for the moment on the fence if it should be included or not. I’ve heard so many arguments for both sides so I guess I have to let it sink in for a while before forming my final opinioin. Then again, it’s not at all my decision to make. :)