Skip to Content »
online discount medstore
advair diskus for sale
buy advair diskus without prescription
allegra for sale
buy allegra without prescription
aristocort for sale
buy aristocort without prescription
astelin for sale
buy astelin without prescription
atarax for sale
buy atarax without prescription
benadryl for sale
buy benadryl without prescription
buy clarinex without prescription
clarinex for sale
buy claritin without prescription
claritin for sale
buy flonase without prescription
flonase for sale
buy ventolin without prescription
ventolin for sale
amoxil for sale
buy amoxil without prescription
augmentin for sale
buy augmentin without prescription
bactrim for sale
buy bactrim without prescription
biaxin for sale
buy biaxin without prescription
buy cipro without prescription
cipro for sale
buy cleocin without prescription
cleocin for sale
buy dexone without prescription
dexone for sale
buy flagyl without prescription
flagyl for sale
buy levaquin without prescription
levaquin for sale
buy omnicef without prescription
omnicef for sale
amaryl for sale
buy amaryl without prescription
buy cozaar without prescription
cozaar for sale
buy diabecon without prescription
diabecon for sale
buy glucophage without prescription
glucophage for sale
buy glucotrol without prescription
glucotrol for sale
buy glucovance without prescription
glucovance for sale
buy micronase without prescription
micronase for sale
buy prandin without prescription
prandin for sale
buy precose without prescription
precose for sale
buy cialis professional without prescription
cialis professional for sale
buy cialis soft without prescription
cialis soft for sale
buy cialis super active without prescription
cialis super active for sale
buy cialis without prescription
cialis for sale
buy levitra without prescription
levitra for sale
buy viagra professional without prescription
viagra professional for sale
buy viagra soft without prescription
viagra soft for sale
buy viagra super active without prescription
viagra super active for sale
buy viagra super force without prescription
viagra super force for sale
buy viagra without prescription
viagra for sale
buy celebrex without prescription
celebrex for sale
buy colcrys without prescription
colcrys for sale
buy feldene without prescription
feldene for sale
buy imitrex without prescription
imitrex for sale
buy inderal without prescription
inderal for sale
buy indocin without prescription
indocin for sale
buy naprosyn without prescription
naprosyn for sale
buy pletal without prescription
pletal for sale
buy robaxin without prescription
robaxin for sale
buy voltaren without prescription
voltaren for sale

Tech Life of Recht » archive for 'trifork'

 Google I/O

  • April 6th, 2009
  • 1:25 pm

I’ve been working with GWT for a while now, and like just about everybody else, I’ve also been using some of Google’s other services like maps and calendar. There’s not been a release of the GWT Ant target, but that’s mostly because the current version just works (if it doesn’t work for you, please let me know).
Generally, most of the stuff coming from Google is great. You can always discuss whether they have some sort of evil master plan hidden somewhere, but so far, it seems to be going pretty well. So, I thought I’d ask the company if I could go to the Google I/O conference in San Francisco, and luckily for me, it got approved. It will be very interesting to see if it’s a complete fanboy conference, or if there’s actually some usable content. I’m hoping for the last, but everything fails, I can hopefully grab a bagful of Google merchandise. I’m the only one from Trifork going, but the wife is going with me, so we’ll spend some extra days in SF.

 Hacker Days with Trifork

  • October 31st, 2008
  • 12:06 pm

This week, we had the first Hacker Days with Trifork. It’s a pretty simple concept: Pack up your laptop and other necessities and head out to a more or less remote location and work on whatever little project you want. Basically, it’s a way to get some time to look at new and upcoming technologies and stuff that you can’t normally fit into your daily work.
I spent the two days with four others trying to implement a Scrum board in JavaFX. Of course, that’s not enough for two days, so we threw some Groovy into the mix too. Also, we used NetBeans for the IDE (because of the support for JavaFX), and finally we tried out Git for version control.
No complete product was created (but I don’t think anybody expected that to happen either), but here are some lessons learned:

  • The declarative style of JavaFX seems promising, and the bind mechanism makes a lot of things much easier. However, it can be a little hard to think the JavaFX way – I normally think in Swing terms, and that doesn’t always work out.
  • Effects in JavaFX are pretty nice. Implementing simple animations on widgets is also easy.
  • When you’ve finally worked out how JavaFX works, it’s pretty easy to add new functionality, as long as you stay within bounds. There is a lot of undocumented constructs, and guessing how they work is not easy. Also, googling for JavaFX will give you a lot of articles about earlier versions, which can’t be used for anything anymore.
  • For some reason, there are two worlds in JavaFX: The “native” components and the ones built on Swing. These have different properties, and are not really compatible. I’ve not figured out why yet, but it is a little irritating
  • NetBeans might be a good IDE, but the JavaFX support just plainly sucks. Auto completion only works half the time, it displays errors when the compiler runs with no errors, the component palette is a joke, formatting stinks, no automatic imports. It might be better just to use Emacs or something like that because then at least you know what you’ve got, and you don’t try the auto completer again and again, hoping that it will learn something.
  • Git looks promising, but for a project which needs to sync up all the time, it feels more complicated than Subversion. Especially the push and pull process is somewhat convoluted, and I’ve yet to figure out how to see what’s actually being pushed and pulled.
  • Rumor has it that Git is a pain on Windows. I run Linux, so I wouldn’t know – I used something like 10 minutes to set it up, including an account at
  • Finally, we had Groovy for the data layer. I didn’t work on that part, but I did hear some grumbling, primarily because of the loose typing.

We did get a semi-working application up and running, but not with real data, and only display of data, no input mechanism. However, the focus wasn’t so much on getting a complete system as it was on experimenting with new technology, and I’ve definitely learned a lot about JavaFX. The primary lesson is probably that it’s not production ready yet, and that good IDE support is vital (no surprise there).
Hopefully, the hacker days will become a semi-annual event, so maybe one day, we will have a more complete product.

 JAOO Today

  • September 30th, 2008
  • 1:16 am

This week is JAOO week – the software conference organized by Trifork. Again, I’m on the team publishing JAOO Today, the daily conference newsletter. This year, however, it’s not quite a newsletter, as it’s published online, but the content is still more or less the same: Interviews with interesting speakers, reviews, competitions, and much more.
No matter if you’re actually at JAOO or not, you should probably check it out – there’s a lot of great content. If you are actually at JAOO, please come by and say hi.

 Scrum and the Public Sector

  • May 18th, 2008
  • 2:36 pm

Projects for the public sector have, for a long time, had a reputation of being overspecified, tightly controlled, contract-focused, and in many cases badly managed. Some call them waterfall projects. Luckily, it’s been a while since I was on a project like that – the projects I’ve worked on, also for NITA have been run as Scrum projects with a good amount of success. It has, however, mostly been smaller projects – a month or two, and without any real focus on the process from the customer’s side. Now it looks like we’re finally heading away from the classic waterfall approach, as NITA has openly confessed to Scrum (in Danish only). Just as important, Trifork is helping both with Scrum and doing the implementation. I’m not on the project at the moment (still busy with OIOSAML and REST), but I’d be surprised if I didn’t get involved at some point.

 REST vs WS-*

  • April 22nd, 2008
  • 8:10 pm

Today, we had the OIOREST workshop, a workshop on the OIOREST initiative, we’re a part of at Trifork. The workshop was meant to inform about REST in the Danish public sector and to hear what users and developers had to say. The workshop went pretty well – not a lot was changed, but at least we were (more or less) confirmed in our view that REST does have its place.
The workshop was centered around a couple of Open Space sessions. One of the topics discussed was “REST vs WS-*”. While working with OIOREST, this topic has come up again and again: What is REST in relation to SOAP and WS-*, and when should each be used? This has been the basis for many heated discussions, and today was not much different. Most people say something like “REST is for simple things, but when things get too complicated, you’ll want to use WS-*”. I can’t really figure out what to think about this. First of all, what is simple and what is complicated? Complicated scenarios often include transactions and reliability. Distributed transactions are evil, period. Reliability is handled in REST by adhering to the HTTP verbs and keeping operations idempotent, so that’s not really a good argument either. Another argument against REST is “now we’ve finally developed all these standards for SOAP, why should we then do the same for REST?”. Ignoring that REST is older than SOAP and WS-*, somehow this argument also feels wrong.

I agree that REST is not for everything: if you want a RPC interface, don’t use REST. If you work in an organization which is committed to SOAP-based web services, don’t use REST (at least not openly). If you have the need for hierarchical data in the message header, REST doesn’t quite fit. If you want to use only GET/PUT/DELETE/POST, it will for example, be hard to implement transfers between two accounts in REST.
Now, everything is possible, and all of this can be modeled in REST, but it’s starting to look wrong and diverge from “real” REST. Something like WS-Security seems hard to implement in a nice way in REST. WS-Security makes it possible to sign and/or encrypt XML payloads transparently. The signature is placed in the SOAP header, and the payload format does not have to support digital signatures directly. If you need end-to-end security, this is a pretty nice thing, and REST does not have something similar. Some payload formats, for example Atom Publishing Protocol, supports signatures as a part of the payload itself. WS-Security still has the advantage that no matter what format you’re using, you can use the same mechanism for signing and checking signatures.

WS-Security has some potential, but I’ve also seen a lot of cases where WS-Security could be replaced by plain SSL instead together with a simple Authorization header. So, the original question is still valid: what are the scenarios where SOAP/WS-* simply cannot be avoided? My guess is that there is no good answer for this, just as there is no good answer to the question “when should we use Ruby instead of Java?”, or “when should we use PostgreSQL instead of MySQL?”. The answers to these questions will depend on who you are, what your experience is, where you’re working, and so on. The only way is probably to try some different scenarios in REST and SOAP and see what approach is most successful – which is what we’re in the process of doing with the Danish Nature and Environment Portal, but more about that another day.

 Testing legacy code

  • April 10th, 2008
  • 9:06 pm

I’m currently working on an open source SAML 2 toolkit for the National IT and Telecom Agency. Exciting stuff in many ways, but mostly because we might contribute to the adoption of SAML in a pretty constructive way. I still think that SAML is overly complicated at times, and the closed nature doesn’t make it very scalable – every service provider has to be registered in the identity provider up front in order for anything to work, which is a huge maintenance issue. However, with the right setup, it doesn’t have to be that complicated. We’re developing a servlet filter, which can be plugged into any Java-based web-application in order to protect it with SAML single signon. The work is based on code developed elsewhere, and when we received it, there were no unit tests. At all.
No tests is not exactly the best way to start off, so the first tasks on our backlog was to implement unit tests for as much as possible. While the code is not exactly legacy, it’s still written by someone else, and structured in a way that you don’t quite understand.
Writing unit tests under these circumstances neither easy nor fun. There are clear advantages, though: the code will be tested, and any further work can proceed with a much higher level of confidence, and the code will be refactored intensively in the process. The refactorings happen for two reasons: to better understand the code, and to make the code testable.

So far, the main obstacles for testing have been

  • Passing around too “large” objects – for instance a HttpServletRequest only a single request parameter is needed
  • Calling static methods
  • Relying on static initializers to configure a class, for example from a file on the file system
  • Using singletons and calling them everywhere
  • Methods with side effects – why should a method named getId() put something in the HttpSession?

All of this can be refactored to make it testable. One can only wonder why it wasn’t written that way from the beginning. Anyways, the tests have been written, and the quality of the code base has increased considerably. Because of the tradition of always including new technologies in projects, this has also been the first time I’ve used JUnit 4 and jMock 2 extensively, and I quite like both of them. Especially jMock has helped a lot, and it has a very nice API.

For those who are interested, the SAML toolkit is based on OpenSAML 2, and will be released under an open source license (I’m guessing MPL) at Softwarebørsen at some time in the near future. It’s main focus is on supporting OIO-SAML, but it should support just about any SAML 2 compliant setup.


  • April 1st, 2008
  • 9:32 pm

Apparently, some people has been wondering exactly who I am and what I look like. I’ve more or less kept this blog clean of personal matters without technical aspects, but guess I can make an exception. For those who are interested, I have a SmugMug gallery with all my pictures, and pictures of myself have been tagged.
Please do bear in mind that a lot of the pictures have been taken at parties, and often I try not to look the best.

While we’re at it, I managed to grab some pictures of Trifork’s new offices while they were still being built (last week).

 Becoming a better programmer

  • March 13th, 2008
  • 9:45 pm

As I wrote earlier, I spent the first three days of this week on a Kent Beck courseQCon London to give a keynote with more or less the same overall message as in the course: accountability and responsibility is just about everything. When you take responsibility, you earn trust, which again enabled you to have a better relationship with other people, including developers, customers, managers, and so on.
One interesting bit came up in regard to discipline. I’ve always said that XP and agile processes take discipline to implement and use. Kent Beck’s take on this was that it was just the opposite – not doing XP was hard for him. Instead, it’s more or less a question of habit, which is where the problem often lies: Changing part of yourself requires an investment, but it’s not completely clear when the investment will yield a profit. Ironically, this economical argument is also used to promote XP: push the cost into the future and pull the profit closer – for example by releasing often, not gold plating, and so on.
Adopting an agile process then becomes a question of how you change habits, and keep from falling back into the old ones. Leadership is one way, double- and triple-loop learning is another, and there are probably many more. Incidentally, this is exactly the subject I worked with at university together with Michael with just about the same results.

 Secrets of the agile programmer

  • March 6th, 2008
  • 9:23 pm

Enticing title? Unfortunately, I don’t quite have much to say about the subject – or at least nothing to say here, but hopefully that will get much better next week. For 3 days (Monday-Wednesday), I will be attending a Trifork special, a course held by Kent Beck, the father of XP and much of the agile movement. I’ve never experienced Kent Beck live before, but I expect the best. As always, the main conclusion will probably be that the secret consists of two things: experience and discipline. Still, it doesn’t hurt to learn some new techniques, which I hope will be the case with this course.

 Talking too much?

  • February 11th, 2008
  • 5:58 pm

Today we had a discussion about which agile practices work, and why some tasks just seem to take longer than necessary. One of the reasons seems to be that we don’t really reuse concepts and components very much. Every scrum team has responsibility for meeting their goals and satisfying the customers, but nobody is focused on maintaining a somewhat common architecture, and practices, both good and bad, are not communicated reliably to other teams.
This is not necessarily bad. Most of the developers are pretty bright people, who actually work at companies like Trifork because that way they won’t get some Enterprise Architecture(tm) pushed down their throat. Instead, there is an expectation that everybody will strive to do their best for the project.

The whole agile culture empowers the developers – this is one of the core ideas. The developers get to speak directly with the customer, design solutions, implement them, test them, document them – generally the developers are responsible for as much of the development as possible. A good thing, but maybe developers sometimes have a little too much to say. I don’t particularly like the term architect (mostly because “whiteboard” should have been prepended), but having Scrum teams without a proper architect doesn’t really seem optimal in the long run. By proper architect I mean one who has the capacity to create consistency across projects, and take decisions about key components, languages, and so on. The architect shouldn’t necessarily make all the decisions, but some things are just not worth discussing again and again. Examples of this could be whether to use a coding standard or not, or whether to include a completely new and untested technology. Another classic seems to be that decisions are never final. This means that somebody might spend time in integrating a new tool or component, even though an earlier decision was made against it.
Granted, some of the decisions made on a project are just plain wrong, at least in hindsight, but it just seems that experimenting with new technologies on a project which is due to deliver a working product isn’t the best idea.

As usual, the problem comes down to communication. Scrum and XP handles team communication pretty nicely. We have daily scrums, iteration meetings, retrospectives, and so on, but there are no practices to establish inter-team-communication. You could, of course, go for something like CMMI, which has almost complete focus on organization-wide communication, but that just doesn’t sound very good (theoretically it should be possible, though. My master’s project was about exactly this). In other words, we need some solid agile practices for enabling communication across the organization.

I wish I had some good ideas as to how this should be done. Ask Jeff Sutherland, and he’ll probably begin talking about scrum of scrums, basically arranging teams hierarchically, and letting the scrum masters communicate between the teams. On the face of it, this looks like a good solution, but somehow I don’t quite like it. In really large organizations, it’s probably the only way, but is it appropriate when you have 50-100 developers?

My best proposal is to separate the day-to-day development from the talking and the experimenting. Development happens in scrum teams, and the teams live their own lives, but the design decisions are coordinated with what we could call architects. Maybe librarians would be a better title, because their main purpose is to know what others are doing and have done, what has worked, and what has not worked. The talking and experimenting would take place at other times. This could be the 20% time which Google employees have to spend on something else, it could be something like the JAOO meetups at Trifork, it could be video blogs. Basically anything, the important thing to somehow promote a culture where both learning and teaching is essential. Of course, this requires some ongoing investment from the organization, like the 20% time.
If this separation exists, we as developers might be able to focus better on creating actual value, and we might also become better at learning from each other. It’s important to notice that the separation is there to avoid too much distraction when developing. However, everything good and bad that comes out of the talking and experimenting should be taken into consideration when making important architectural decisions – it’s just a question of where the experimenting takes place, and when the results are brought back into a project. Most of the time, our projects are relatively short, so after committing to some architecture, it doesn’t really pay off to change it.

I expect some of this will be addressed, for example at future JAOO and QCon conferences. In the meantime, it would be nice to hear about inter-team communication patterns – how to ensure common knowledge, and how new ideas, technologies, patterns, principles, and so on can be distributed in an organization full of independent teams.