Welcome Welcome to our blog about all kind of topics that are related to software development. We blog about:
SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.
Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.
Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.
Linked in We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
By jettro, on April 29th, 2008
 How many projects have you done that had a possible issue with performance? How many times was the word Cache used in the same context? I have a very simple rule DON’T use it. Of course, like with every rule, there are exceptions. For one of our projects at JTeam we were asked to try and boost performance for a large data import. It is a pretty big project with a lot of different frameworks and a lot of “AspectJ” aspects. Before diving in the code we decided to have a look at performance bottlenecks using a unit test and a profiler tool. The customer had done this as well so we could reuse his work. Using the profiler it is not hard to find points in the application where a lot of time is spend by the threads using the profiler. The question is what to do to improve performance. Yes finally a good opportunity to use caching?. This article is about caching. I’ll show you a way you can use it within a springframework/jpa application. For now I’ll focus on caching at the back-end. For the code samples I use EHCache, not because I think it is the best. Mostly because most of the samples I could find use it and hibernate has very tight integration with EHCache. I will also give my conclusion of working with caching in general.
Read on for the good stuff
Continue reading Using ehcache and verifying that it works with JPA and springframework
By Ben, on April 27th, 2008
Over the past few years, dynamic programming languages that are based around an interpreter have gathered quite a lot of attention. They’ve made an impression with language constructs that are more high-level than those of older languages and they’ve served as vehicles for some new ideas in software development (and also for some “new” ideas, i.e. old ideas that have been rebranded, like the DRY Principle). Dynamically typed languages are not a new idea at all of course (see Dylan, BASIC and FORTRAN), but the past few years has seen their resurgence in a generation of interpreted languages that have earned themselves the moniker “cool”. Among the languages of this new generation are Ruby, Groovy and Python.
This generation of languages has run the entire gamut of early-days-just-getting-started languages and is now on the verge of moving into the mainstream of software development. They’ve gone from being the new research platform to being the cool thing to play with for students and developers working pet projects and they’ve evolved further to the point where a number of custom development projects (ones that are relatively self-contained) have been done in them for commercial clients and other organizations. They’ve also gathered enough attention that they’ve been embraced by some mainstream platforms (the Java platform for instance has been extended with support for so-called scripting engines to allow bidirectional communication). In short, these languages have arrived at the point where they’ve gathered a following and that following is about to become a real pain in the ass.
Continue reading The Great Dynamic Hope: another hum-drum hype waiting to happen
By jettro, on April 17th, 2008
 Yesterday was the bi-yearly event organized by the NLJug or the Dutch java user group. I like to attend these events mainly because it feels like a reunion. I see a lot of people from previous employers and people that I know from others events. Therefore this is a welcome day to feed your network. Another reason to go there is to try to learn something. I must admit that I do not think the overall quality of the sessions is very good. Still there are always some sessions that do have the level of quality and depth I like to see. Usually I tend to skip the key note, but this year we had no stand. So all the people from JTeam could freely walk around. Therefore I decided to sit the keynote out as well. WOW, that was a very good choice. The guys from atos origin created a very cool application with flex and some hardware for receiving sms and pictures. These were shown on the screen immediately. So we could actually interact. But the guy that made it happen was using the texts and photo’s to sing songs. Hard to explain, but you should have been there. To my opinion this was the best keynote at the nljug events ever. So thank you atos origin.
In all it was a nice day, to bad we now had tickets for the drinks. Mabe we should as a fee of 10 euro and then make it free again? Or even better, a fee of 50 euro, less sponsoring, better food, etc.
During the event I went to a few sessions as well:
- JSR 308, “Annotations on Java Types”
- People vs Process, cultural patterns
- Spring integration
Read on to find out what these sessions were about and where you can find more information if you are curious.
Continue reading NLJug J-Spring 2008
By Ben, on April 15th, 2008
Over the past few days my thoughts have been drawn to what I think is a common problem (in addition to the ones identified by Freddie van Rijswijk in his recent blog) in establishing and participating in a SOA architecture: Won’t Let Go Syndrome (WLGS).
WLGS is a problem akin to the Not Invented Here Syndrome (NIHS), which is itself a specific form of Reinventing the wheel. However, where NIHS is an a-posteriori problem (an unwillingness to use the inventions and work of others), WLGS is an a-priori problem: an unwillingness to let anybody else solve your problems for you.
When working within a SOA, the idea is that you create one or more components, each of which is good at solving a certain problem really well and doing nothing else but that (don’t confuse that with the idea that a single SOA component must offer only one operation). Other problems must be solved by other, specialised components. And for larger problems it is often a good idea to have subproblems solved by other components as well. Back in the good old days of “simple” OOP, this was called delegating. However, as I continue to work in my work environment and am involved in more and more projects that create different components within what will become the companies SOA, I come across a weird phenomenon more and more often. For some reason people working on any given component are unwilling to entrust the care for their subproblems to any other component.
Continue reading Letting go: yet another traditional problem in the SOA world
By jettro, on April 13th, 2008
Hi all,I do not know how many of you are a member of linked in. I have created a linked in group. I do not have the intention to create the largest network around. But I am curious about the people that use my website, especially those that use rss to track all [...]
By freddie, on April 12th, 2008
Why this Blog on four persons? I want to let you know that, as with everyone else, a lot of my thoughts and ideas are coming from discussions with them. And I LOVE DISCUSSIONS that give you a different perspective. This morning it became pretty clear to me that what i write also comes [...]
By freddie, on April 12th, 2008
How is SOA and BPM going to improving the ability to serve and exceed quality while cut in the 30% cost of IT MOOSE? I´m convinced that SOA and BPM is NOT the answer. The discussion on ROI of SOA caused by my Blog-item SOS voor SOA andmultiple discussions with Max J. Pucher and reading his blogs, but also the posting of Ben Tels and others blogs and several papers have strengthen me in my thoughts that SOA althoug a great Architectural concept has lost its meaning. But I´m open for other insights and discussions, so feel free to react after reading this post.
MOOSE?
The term MOOSE comes from Forrester. Executives often look at IT spend as a black box and compare it as a percent to overall revenue. Maintenance and operating the IT organization, systems, and equipment (MOOSE) takes approximately 70% of IT budgets (Forrester: the October 18, 2005, “Defining The MOOSE In The IT Room” report.). The remaining 30% comprises investments to support business growth, to cut business cost, and to cut the cost of IT MOOSE.
Macro-economics conditions shaping the CIO´s job currenlty. The reality is that any business at any time may need to shift its executive focus toward running lean.
The question is how will SOA and BPM help the CIO Invest more in New and Improved Capabilities to support business growth and therefore to Reduce the Cost of Business and above all Cost of IT MOOSE. Seriously, I doubt that we can hold our claim that SOA and BPM are bringing the CIO those benefits. Besides the argument of Cost saving, we also hear the arguments for Business Agility and Compliancy. I will not go into Compliancy and connected to it Security, it´s to broad for this blog but Agility is also something to think somewhat more on.
Continue reading Will SOA and BPM bring the MOOSE Savings and Business Agility?
By Ben, on April 8th, 2008
Everybody is, at least to some extent, familiar with the following quote:
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title….
– Romeo and Juliet, Act II, Scene II
It is with these words that Juliet attempts to persuade Romeo that they are their own persons and the fact that they are by name members of feuding families should not keep them apart. Ever since this phrase has come to be used to mean that two concepts are (or can be) the same even if they are named differently.
I was put in mind of this quote today by a discussion I was in at work. The discussion was one that comes up every now and then in my work environment: the value, need and effort of unit testing. And it involved the usual suspects, one thinking that unit testing is overrated and a lot of work for little return (especially during initial development), one seeing some value but thinking that unit testing is only useful for larger or more complex pieces of code, one thinking that unit testing is very important but not caring whether people work test-first or test-last and me: a test-first purist.
Continue reading A unit test by any other name…
|
|
