Posted by Mark Bakker in the early morning: May 27th, 2010
Summary
In the first part of this review (the JavaEE6 back-end) I tested a small application which is a JSON REST service to be used as back-end for a JavaFX front-end. My conclusion for now is that JavaEE6 has a lot of new features which makes it a lot easier to use Java EE without extra libraries like Spring, Seam or Resteasy. I was able to make a back-end application which was noticeable fast with a low overhead in bandwidth and CPU usage.
Introduction
In a search for the current best technology platform I am building a small real-world application for personal use in different languages and frameworks. First up is Java EE 6 and JavaFX 1.3.
I think this review can be helpful for others as well. If you just want to see the implementation you can skip the functional and technical requirements. If you are interested in the application and want to help creating the new version; please send me a reply:-).
Posted by Denis Koelewijn just before lunchtime: May 13th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. Last week we discussed the first principle Always involved. In this blog entry we discuss the second principle that applies to the architect role and the architectural artifacts and is called “Travel Light“. Travel light should be taken literally, how much does the architect have to carry around running from stakeholder to stakeholder? How much material does he need to explain the business needs to the development team, what does he need to explain the vision of the product to the business, to involve operations early on, etc., etc. ?
Posted by Iwein Fuld in the early evening: May 9th, 2010
Without exception in all teams I’ve developed software in people have expressed their aversion against pair programming. It’s not that developers don’t want to try, or that they don’t believe it will help. On the contrary, they are usually very enthusiastic about trying it and give it more than a fair chance. After a few days they sit alone behind their keyboard coding like zombies with headphones. What’s going on? Is pair programming too hard? Doesn’t it pay off? In this post I’ll try to explain what I think is happening, and I will give you some clear pointers to avoid the traps. At the end I will go into distributed teams and what part of the game changes there.
So what are people saying when they have stopped pair programming and you ask them why:
- I’m faster on my own
- Can’t pair with that guy, he’s getting on my nerves
- Pair programming is too tiring
- We’ve split up the work and we’ll get it done faster if we use two keyboards
- There’s too much background noise
- I’m just slowing her down
Some of this might sound plausible, so let me axe that down first. No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. If your code is so simple that you can split up the work in advance you’re writing it on too low an abstraction level, or you need to work on this in two pairs. If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.
(more…)
Posted by Erwin van der Koogh just before lunchtime: April 30th, 2010
I was triggered recently by a status update from someone that mentioned that we will have to get ‘this’ right the first time around in the future.
This particular case was about a test, very late in the project cycle, where lots of things needed to get together perfectly to make it work. Any delays would not only delay the current project, but all other projects that rely on the shared resources being used. This huge cost if things go wrong is why it is so imperative that we do get it right the first time around.
The problem is that this involves tens of people across multiple companies and departments, who have written thousands of lines of code.
Now I do not know what they are going to do to make things right in the future, but if we go by past experience most people will want to enforce even stricter entrance criteria.
There are a couple of problems with this approach:
(more…)
Posted by Sander Hautvast mid-morning: April 28th, 2010
What is ‘middleware’? French professor Sacha Krakowiak defines middleware
as [a] software layer [which role] is to make application development easier,
by providing common programming abstractions,
by masking the heterogeneity and the distribution of the underlying hardware and operating systems,
and by hiding low-level programming details
This makes sense, considering the fact that writing an http server nowadays or a servlet-container is not considered sane anymore, given the multitude of commercial and open source products that have already proven themselves. Over the years a range of products and standards has emerged that to a growing extent hide the low-level intricacies and provide the application programmer with easy yet powerful abstractions. They range from webservers, databases and application servers to EBS´s and BPM platforms. They form the IT landscape that enable modern business. And it´s their heterogeneity and distribution that is at the heart of the emerging problems that we will address in a top-10 style series of blogs in the coming weeks.
(more…)
Posted by Andrew Phillips around lunchtime: April 22nd, 2010
While recently fiddling with some more runtime generic type extraction for Deployit, I was caught out by some unexpected behaviour by the reflection API. A check of the Javadocs quickly revealed that I had once again been too hasty in relying on “common sense”. Still, the case seems sufficiently unintuitive to merit discussion. (more…)
Posted by Wilfred Springer mid-afternoon: April 20th, 2010
If there is anything that made Java popular during the last decade, then it must be the community. This may sound like a paradox at first: popularity does sort of imply the existence of a community. But it’s really not just the existence or even the size of the community. It’s the vibe that counts.
(more…)
Posted by Iwein Fuld in the early evening: April 14th, 2010
A lot of automated acceptance testing pioneers have come around and denounced their fate in heavy automated test suites. A recent article on InfoQ sums up the trend quite nicely. I am not going to jump on that bandwagon, but I will try to find the safe middle ground between the overzealously created maintenance burden and anarchy. The main point is that automating acceptance tests is the way to go, you just shouldn’t automate and maintain useless tests. The tricky part is to find out what tests are useful and what tests are not.
(more…)
Posted by Albert Sikkema at around evening time: March 30th, 2010
When running Selenium tests from JUnit it’s very useful to be able to capture screenshots when something fails. Especially when you run it in a Continuous Integration environment which you aren’t monitoring. A screenshot combined with the stacktrace makes identifying and fixing the error easier. When you combine this with a JUnit @Rule you can make it transparant and use it for every testcase (more…)
Posted by Andrew Phillips mid-morning: March 9th, 2010
From Java EE to Google App Engine to GigaSpaces, the idea of developing against a middleware or “infrastructure” API is well established in the Java world.
But these are fixed environments. With the (re-)advent of virtualization, it is now becoming feasible to package and rapidly provision your own environment, custom-designed to meet your application’s needs.
As the big middleware vendors are realizing, it is not just possible to create such Virtual Appliances, but necessary: a production app’s setup inevitably includes more than just a couple of EARs.
Here, we’ll look at the current state of cloud and middleware deployment tooling, examine possible future developments and draw parallels between deployment and related processes.
(more…)