Tuesday, July 15, 2008

Hibernate annotations: Reversing the bidirectional relationship

written by Marcel Panse

Making a bidirectional relationship in hibernate using annotations is easy. Just make a ManyToOne at one side and a OneToMany at the other. Use the mappedBy property to make the relationship bidirectional.
I thought this means when editing the Collection side and saving this collection side, that hibernate would update the foreign key automatically at the other table.

For example, when you have a User with multiple Products and you add a product to the user like user.products.addItem(product). And then saves the user like userDao.save(user). This does not update the foreign key in the product table. And next time when you retrieve the user.products from the database, the collection will be empty again. The same goes when you remove a product from the collection.

It all works fine when you do something like product.user = user; and save the product. Then when you retrieve the user the product collection will hold the added product.

The solution is to add a JoinColumn annotation to BOTH sides.

Here is an example:

@OneToMany(targetEntity=ProductImpl.class, cascade={CascadeType.ALL})
@JoinColumn(name = "product_id")
private Collection products;

@ManyToOne(targetEntity=UserImpl.class, cascade={CascadeType.ALL})
@JoinColumn(name = "user_id")
private User user;

Sunday, July 13, 2008

Flex: setting unicode ranges when using a TrueType Font saves over 300kb

written by Marcel Panse

There are a few ways of using fonts in a flex application. The default way of doing it in flex is using 'device fonts'. This means flex will not embed any fonts into you swf file, but it will use the font on the clients computer instead. Flex will try to find a font on his computer that is the closest to the font you configured in you css file.

The following example specifies the device font _sans to use if Flash Player cannot find either of the other fonts on the client machine:

.myClass {
fontFamily: Arial, Helvetica, "_sans";
color: Red;
fontSize: 22;
fontWeight: bold;
}

The drawback of this is that your flex application might not look precisely the same on every computer, which can result in slightly different layouts. Like too long labels resulting in unanticipated scrollbars (Arghh!).

Rather than rely on a client machine to have the fonts you specify, you can embed TrueType font families (.ttf or .otf) in your Flex application. This means that the font is always available to Flash Player when running the application, and you do not have to consider the implications of a missing font.

This has some major advantages; like rotating fonts, making fonts transparent, smoother fonts and anti-aliasing fonts which just means better readability especially with smaller fonts.

But with beauty comes pain: the one major drawback is your swf file will increase in size.. a lot.. Using a standard true type font like Myriad Pro Regular, an increase of about 900kb's is normal (which doubles the size of my entire flex application!). This is because the entire font with all unicode ranges will be embedded into you swf file. At least 50% of these unicode characters you will never use.

But there is hope! The proper way to embed a true type font into you swf file is by specifying the unicode ranges you want to include into you swf file. Only the characters inside these ranges will be embedded into your swf file. You can find the unicode tables on wikipedia: http://en.wikipedia.org/wiki/Latin_characters_in_Unicode

Here is an example which works for me. This example is optimized for the Dutch language. In the Dutch language we use a lot of ë's and é's and stuff, so i also included them, you have to figure out which characters you need for you own language.

@font-face {
src:url("../fonts/MyriadPro-Regular.otf");
fontFamily: myFontFamily;
fontAntiAliasType: advanced;
unicodeRange:
U+0021-U+002F, /* !"#$%&'()*+,-./ */
U+0030-U+0039, /* 0-9 */
U+003A-U+0040, /* :;<=>?@ */
U+0040-U+007E, /* @A-Z[\]^_`a-z{|}~ */
U+00E0-U+00EF, /* àáâãäåæçèéêëìíîï */
U+2022-U+2022; /* • */
}

For more information about fonts see the adobe live docs

Friday, July 11, 2008

Agile Development 'nadelen'

written by Daniel Rijkhof

This blog entry is a reply on an article that’s in Dutch, this is why the blog entry is in Dutch to.

Vandaag las ik een artikel over Agile Development op de site van computable.

In dit artikel worden een aantal nadelen van AD genoemd, waar ik het niet mee eens ben. De nadelen die ik op de schop doe zijn:

• In AD fungeren ontwikkelaars tegelijkertijd als informatie-analist, software-architect en tester
• AD is alleen geschikt voor senior ontwikkelaars
• Ontwikkelaars hebben te weinig skills
• Het werk van de bureaucraten, moet worden gedaan door de specialisten.
• Stakeholders worden niet tevoren gedwongen om hun eisen en verwachtingen te formuleren.
• Planning en budget zijn moeilijk te bepalen
• Belangrijke beslissingen op ad-hoc basis
• Slecht doordachte architectuur en modellen, risico op spaghetti-code
• Veel code weggegooid

De eerste drie
De eerste drie nadelen komen voort uit de gedachte dat een team alleen ontwikkelaars mag bevatten van het zelfde niveau:

• In AD fungeren ontwikkelaars tegelijkertijd als informatie-analist, software-architect en tester
• AD is alleen geschikt voor senior ontwikkelaars
• Ontwikkelaars hebben te weinig skills

Is dit werkelijk een eigenschap van AD?

Het Agile Manifesto is gebaseerd op een aantal principes. De toepasselijke principes voor deze nadelen zijn:

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

De principes achter het Agile Manifesto zeggen niets over het samenstellen van een team! Mag je dan zelf bepalen wie er in je team komen? Zou het zo kunnen zijn dat het team zelf weet waar de gaten vallen binnen het team? Zouden de bovenstaande 3 principes, een basis vormen om daar achter te komen, en het probleem op te lossen? Ik denk het wel.

Er is geen verplichting om een team te nemen waarin elk persoon dezelfde hoge kwaliteiten heeft. Er is geen regel in AD die zegt dat dit niet mag. Kan je een team samenstellen met requirements specialisten, architect(s), developer(s) en tester(s)? AD laat je hier vrij in. Als het werkt voor jou, doe het dan.

De gedachte dat je alleen ontwikkelaars in je team hebt zitten, is niet correct, en daardoor vervallen deze drie nadelen.

Meer ‘nadelen’:
• Het werk van de bureaucraten, moet worden gedaan door de specialisten.
• Stakeholders worden niet tevoren gedwongen om hun eisen en verwachtingen te formuleren.

Deze nadelen komen voort uit het idee, dat AD alles beschrijft dat in een bedrijf moet gebeuren om succesvol software te ontwikkelen.

Het volgende agile principe geeft aan dat het de bedoeling is, zo snel en vaak mogelijk waardevolle software op te leveren:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Stel je voor dat stakeholders niet vertellen wat hun eisen en verwachtingen zijn. Wat moet er nu gedaan worden? Het is een AD noodzaak om te weten wat de stakeholders willen. Vervolgens willen we ook nog weten welke waarde de stakeholders aan hun eigen eisen toekennen, zodat ze zo snel mogelijk werkelijke waarde opgeleverd krijgen. Het nadeel dat ze niet gedwongen worden om hun eisen te formuleren, verwerp ik.

Wie er achter de stakeholders aan gaat om te zorgen dat hun eisen bekent worden, wordt niet gespecificeerd door AD. Zou het een bureaucraat mogen heten? Niets in AD verwerpt dit. Zou het iemand in het team kunnen zijn? Ook dit wordt niet verworpen door AD.

Zou deze ‘bureaucraat’ een specialist zijn op exact dit gebied? Zou dat toch eens mooi zijn!

Planning en budget zijn moeilijk te bepalen

Is dit nadelen toe te kennen aan AD?

Mijn ervaring met non-AD projecten, is dat de planning nooit klopte, en het budget niet te bepalen was. De bedoeling van AD is, om zo snel en vaak mogelijk waardevolle software op te leveren. We kunnen dus kortere planningen maken, en budget voor vrij maken. Het is dan ook makelijker om een correcte planning te maken in vergelijking met non-AD projecten. Het los krijgen van budget is vast makelijker als jou planningen kloppen. Dit kan geen nadeel van AD zijn.

Belangrijke beslissingen op ad-hoc basis

Belangrijke beslissingen, zullen altijd gebeuren, en vrijwel nooit aangekondigd. Ik heb nog nooit gehoord dat een bedrijf een geweldige kans op een vergroting van de winst, heeft uitgesteld omdat er nog een planning vast stond.
Flexibiliteit van het ontwikkel proces is dan ook gewenst, zodat er niet te veel waarde verloren gaat.

Het volgende agile principe is de basis voor flexibiliteit:
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

In non-AD projecten, komt het voor dat er nog geen waarde opgeleverd is, en ook niet zal gebeuren in een korte tijd. In AD projecten word er elke iteratie waarde opgeleverd. Het verlies van waarde wordt geminimaliseerd door een korte iteratie tijd. Er is ook nog de optie, om de iteratie af te maken, waardoor er geen waarde verloren gaat, natuurlijk ten koste van een beetje tijd.

Het volgende agile principe maakt mijn argument af:
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Omgaan met ad-hoc beslissingen, gaat beter met AD projecten vergeleken met non-AD. Dit nadeel is wordt door AD zelfs niet gezien als nadeel, maar als een eigenschap van de business.

Slecht doordachte architectuur en modellen, risico op spaghetti-code

Het volgende agile principe zegt voldoende:
• Continuous attention to technical excellence and good design enhances agility.

In het geval dat dit nadeel toch voorkomt, dient het team zichzelf aan te passen. Zie weer het volgende agile principe:
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Veel code weggegooid

Het zou kunnen voorkomen dat er code is geschreven dat vervangen moet worden, of zelfs niet meer in gebruik is, en weg gehaald dient te worden. Als deze code is geschreven in een vorige AD iteratie, dan was deze code waardevol. Zie weer het volgende agile principe:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

In dit geval was de code ooit waardevol, en is het nodig om deze code aan te passen om de software nog waardevoller te maken. Waar is het nadeel? Ik zie het niet.


Is AD perfect?

Niets is perfect. Wanneer ik AD vergelijk met de oudere manieren van software ontwikkeling, concludeer ik dat AD geweldig is, een stap richting perfectie.