JRoller

Withering Maven Rant from Hibernate Guy

Rob Williams — Wed, 8 Feb 2012 15:21:54 -0500

Having succumbed quite often to the need to rant, it was with great pleasure that I plowed through this evisceration of maven as a build tool. For those of you who don't salivate at the prospect of a long slog through a field of nattering nabobs of negativism, let me break it down for you. The real crux of this thing is that, after 8 years, any effort to see a way through the Maven jungle to what we call a release is a. sure to be filled with torture and b. impossible. I am sure I ranted about this some time ago, and this was synchronicity at its finest that I happened across this right after moving all my projects from one nexus install to another because one of the nauseating takeaways was we had no projects that were doing disciplined, layered versioning as part of an automated release.

Let‘s pause for a second to consider how utterly ridiculous this is. A build tool that cannot create releases in an orderly fashion is kind of like a phone that can‘t place a call. One of the funniest parts of this rant is the fact that once the author identifies an element as utterly dead, he adds that the Czar of maven agrees and has announced his intention to replace it with ‘something new‘ (of course there is no timeframe for this, you see, timeframes are for nazis that live in walled gardens).

I found this post because I wanted to look at Gradle again, and that was because I came across a conversation with Colin of Spring fame some time ago where he was declaring its usefulness.

Having just skimmed the surface again of Gradle, here are a few random comments:

Love the idea of a DSL, the bland assertion that Groovy was the right choice because Ruby and Python are better languages than Java is kind of silly. The initial hello world examples are not at all convincing from this perspective. Looks like more of the same: my languages‘ highest goals should be to give me less finger pain from typing, and to make me feel like I am on the cutting edge of coding fashion. I like the O-C conceit: a language‘s highest yearning should be to readability. I think I could make a build DSL in Java that would be a lot more compelling than this in a few days. Sound arrogant? Imagine chaining calls to assemble artifacts or trigger actions, with simple inline rules in anonymous classes. Simple and clean.
The documentation looks decent. But there‘s a new O‘Reilly book that has gotten lambasted on Amazon. Then you see it‘s the first in a proposed 3 volume series. A build system so simple it‘s going to take 3 books and 2+ years to describe all of its beauty (and some hundred dollars or so).

Look at the included source code. If this syntax makes you so excited you want to get out your old matchboxes, you are probably a good candidate for liking Groovy. The infantile fascination with banishing iteration loops is just boring to me, and overall, the code is not more readable than a Java-based DSL would be, period (imho). Furthermore, things like ‘println‘ are totally whacked: if you are going to sell yourself as the vanguard, what on earth would make you reach into one of the ugliest parts of C‘s past, that C++ undid with streams?

On the plus side, even a cursory look at Gradle makes you realize that Maven‘s central conceit: to add a model to what was before a model less wild west of silly string (ant), didn‘t go far enough. Why? Because it really only models the dependency graph, and while it has ambitions to incorporate the build, even the most basic things are left to bolt ons (e.g. surefire). One of the things that Ebersole does not address but would be super high on my list is getting better control over the running of tests. We have a number of projects that have both JUnit and TestNG tests in them, and setting that up to run is a nightmare, then if I want to control what gets run to produce what artifacts, I am left, as SE says, portioning out a strategy as a tool‘s grant or remainder. I would so like to be able to say ‘run these tests when producing a dev artifact, these for production‘ and also be able to say ‘the tests for this artifact need only be run if x happens.‘

The biggest thing is the releases. If you got a few smart people in a room who have worked on large projects, and did some visioning on what a release lifecycle management tool should do, face the facts: it‘s 2000 light years from where Maven is.

This was my favorite line from the rant, in part because it overlays one of the things I‘ve been kind of obsessed with lately: the role of the conceptual in technology. “The entire conceptualization of the build process is much cleaner in Gradle imho.” One of the reasons it was hard to have a lot of sympathy for the car companies (for me personally) is they got more post subsistence dollars than anyone in the 50 years after world war II and delivered so little in the way of real progress. While 50K people a year were dying it took them something like 3 decades to put an airbag in a car. Sadly, we in technology imagine ourselves as promethean barn burners, but the reality is the vast majority is probably no better at keeping a pace of their problem space.

Visit to the Radioactive Dependency Pyre

Rob Williams — Tue, 7 Feb 2012 00:32:06 -0500

Ah the joys of dependency management. You see, Friend, what this all does for you is it, well, manages all your dependencies, because of course, you shouldn‘t want to have to do that yourself! As is so often the case, for the promise of a brief respite from a little bit of work, you have to weigh your savings against the mine collapses and how much time and energy they suck up.

Today, I was trying to fix one of the last jobs that was not building on our new install on Jenkins, which, incidentally, is stupid fast on the i7 mini with an SSD. I figured out its first problem then it had a test failure with a message about Column not being found (class not found). Figured out pretty quickly that the class loader was getting the wrong persistence classes. So I cloned the project and built locally then ran the test in eclipse. It passes there. So the class loader behavior is different. More disturbing? it passes from the command line with maven locally. So I go to see where the hibernate classes are coming from. Surprise, they are being dragged in by one of the other projects.

Ok, so I add the hibernate dependencies. Suddenly, I‘m getting a compilation error on a commons collection method call (apache). So look in the tree and find that hibernate dragged in a new version. Try to figure out why the apache guys would have removed a method that simply determines if a collection is empty. Try excluding the commons-collection from the hibernate declaration and then explicitly adding commons-collections 1.0 and suddenly it couldn‘t find richfaces.

Finally, I decided to write my own isNotEmpty method (in about 10s), remove the commons collection and just have the hibernate dependencies and everything built.

While this was going, 2 guys on the team were messing around with trying to get around a bug in the eclipse update site that mislabels a repository as a duplicate and figuring out how to update m2e so it would work with a settings.xml-based mirror.

Earn an average of $790 per month for a few minutes work

evans — Sun, 5 Feb 2012 15:49:59 -0500

As a developer who has consistently been working and earning a great deal of regular income on the side on ODesk website in the last few years, I was surprised to received an email from them that their affiliate program will be switching to Commission Junction. What this means is that from the end of February this year, all new affiliates will have to go through the third party website.

I have used Commission Junction since 2009 and really love their service. They have some of the biggest and well-known companies advertising through them. So,no matter what sort of affiliate program or niche you're into, you will be sure to find an advertiser that fits your niche. So, I was thrilled to see Odesk joining this great company.

That said, the only downside I see in this move is that new affiliates will end up getting far less that they would if they joined the program through oDesk-managed program. The payout threshold for Commission Junction is a lot higher - meaning that you you'd have to accrue enough before you get paid. Previously, oDesk did not have any minimum payment threshold, so you were guaranteed to receive some payment at the end of the month.

So, if you are a developer and looking for ways to earn money extra money during your free time or weekends, now is the time to have a look and started earning. There are literally thousands of programming tasks to choose from and solve within minutes if you are good.

They are consistently considered one of the best affiliate programs, with some of the highest EPC, best affiliate support, and freshest "swipe content" of any b2b lead generation program.

Click here to get started - remember, THE PROGRAM ENDS THIS FEB

SEO Made Simple, 2nd Edition

evans — Sun, 5 Feb 2012 06:20:11 -0500

Today’s leading SEO Book, SEO Made Simple: Search Engine Optimization Strategies for Dominating the World’s Leading Search Engine, 2nd Edition, is a tell-all search engine optimization guide for anyone trying to reach the highly coveted #1 ranking on Google for their website or blog.

Updated and expanded with the latest information on search engine optimization (SEO) and including more than 20 new pages of proven search engine optimization techniques. SEO Made Simple is today’s top-selling search engine optimization guide. Learn from leading Webmaster, Michael H. Fleischner, the specific SEO techniques that deliver top rankings in less than 30 days.

Whether you’re a search engine optimization expert or new to website rankings, the techniques revealed in SEO Made Simple will give you everything you need to dominate Google and other leading search engines. Generate tons of traffic to your website absolutely FREE with top search engine placement on Google, Yahoo! and Bing.

SEO Made Simple has helped more individuals than another other search engine optimization guide ever printed to achieve top rankings for even the most competitive keywords. This guide has been updated with the latest SEO advice on social media, Google Places, and even a step-by-step link building process that has already produced top results for some of the most sought after keywords.

If you are looking for a guide that provides the information you need to achieve top rankings, without all of the useless fluff, this is it.

SEO Made Simple is the only resource on search engine optimization that you’ll ever need. Learn the techniques that have a direct and significant impact on your website’s ranking.

This book is ranked #1 for a reason.

Beginning Android 4 Games Development

evans — Sat, 4 Feb 2012 03:00:22 -0500

Beginning Android 4 Games Development offers everything you need to join the ranks of successful Android game developers. You’ll start with game design fundamentals and programming basics, and then progress toward creating your own basic game engine and playable game that works on Android 4.0 and earlier devices. This will give you everything you need to branch out and write your own Android games.

The potential user base and the wide array of available high-performance devices makes Android an attractive target for aspiring game developers. Do you have an awesome idea for the next break-through mobile gaming title? Beginning Android 4 Games Development will help you kick-start your project.

The book will guide you through the process of making several example games for the Android platform, and involves a wide range of topics:

The fundamentals of Android game development targeting Android 1.5-4.0+ devices
The Android platform basics to apply those fundamentals in the context of making a game
The design of 2D and 3D games and their successful implementation on the Android platform

What you’ll learn

How to set up and use the development tools for developing your first Android 4 or earlier version game app
The fundamentals of game programming in the context of the Android platform

Libs: Updates to XMLDog

Santhosh Kumar T — Thu, 2 Feb 2012 14:01:09 -0500

JLibs: Updates to XMLDog

XMLDog now supports:
- return DOM Nodes for XPath results
- InstantResults: notify as nodes are hit (suitable for heavy xml documents)
- Command line utility to play

Modeling, with Tools/Without

Rob Williams — Thu, 2 Feb 2012 11:31:31 -0500

It‘s totally crazy that in 2012 there are so few good choices for modeling tools. I got encouraged for a minute today when I found a thread on Stack Overflow that included a bunch of products and I found out about SparxSystems‘ System Architect . Got all the way to downloading the trial version when I saw that it was an exe. Yes, folks, Windows only.. in 2012. Unbelievable. Hilarious that these guys are selling tools for doing MDA. Guys, where is your PIM? Oh, yeah, you don‘t have one (clearly). Your codebase is already a PSM (platform-specific model).

What are modeling tools for? Sure, we could set our sights lower than MDA‘s answer: logical representations of both requirements and specifications, and a generative mechanism for platform-specific versions. My desire for modeling tools is to speed the process of figuring out how to do very complex models. But many tools are pictures only to make people feel better about the fact that someone has thought about something. I used to be driven toward the idea of reversibility way back in the 90s when I was using Togethersoft, but I am not so much into that anymore. I think MDA is too ambitious and is bound to produce very robotic solutions. Guess what I am saying is I am interested in all the pieces, but more interested in using the images to flush out ideas and then a generative layer to get much of the boilerplate done (a la Roo and Forge). And then, the ability to support some basic metaprogramming notions.

I can't see myself running an emulator to get to use Sparx' tool. Which made me go back and take a look at where the Eclipse Modeling Tools are at. The answer is everywhere. That could be a good answer, but if you just go to the page and start reading, its a treatise in what everyone complains about on the Java side: a sloppy dog's dinner of every possible idea cooked to some uncertain degree of doneness. Seriously, this is the page here .

I have written plugins before (for eclipse), and used EMF before (with JET). I have Ed Merks‘ books and generally like EMF a lot, but there was never much tooling with it in the beginning, and now, if this heap has some in it, I fear that ferreting it out will take the better part of a year.

I have been learning After Effects lately because I had an ah ha moment recently where I realized that we jump too quickly into requirements even (we all knew that about specs), and immediately run to get busy before we have probably cemented their predecessor. What is that? The vision? Well, vision docs are a good idea, but I think there is something else that is missing: a conceptual understanding. It‘s not just the abstract types you intend to use, or the couple ways someone‘s going to use your app. It‘s how your app plugs into the world and how it will appear to someone who will attempt to use it. While I was thinking about this stuff a friend of mine gave me a book of Occam‘s philosophy. A guy who has been reduced to a philo sound bite. Turns out he was a conceptual philosopher. I have said this 20x before, but programming could benefit immensely from a greater embrace of philosophy. This is not just answering the question ‘what should this do?‘ It‘s answering questions like ‘how will someone figure this out?‘ or ‘how can we entice people into this part of the problem while making their labors feed this other side of the model?‘ For example, consider Amazon. That company owes 90% of its success to its reviews. If you went to people in 1995 and told them ‘the kind of retail online will be the one who makes it possible for me and everyone else to write sometimes 10 paragraphs on what we did and didn‘t like about the product,‘ 90% of the responses would have been akin to Ballmer gleefully (and stupidly) exclaiming ‘nobody is going to pay $500 for a phone!‘ Is this systems thinking? (yes) heuristics? (yes) and also evolutionary/emergent/complexity-oriented? (yes). A mere smattering of these influences, if you allow them into your mind, make our ‘tools‘ look like tinker toys.

Finally, the other thing I am obsessed with deserves the final spot in this chain of thoughts: reactionaries who think they are revolutionaries . Some amount of reaction is required of course, but think about the degree to which most tooling has been born of frustrations with the stupidity of the current state of affairs. I remember when Sun first introduced EJB, with all of its stupid requirements for XML files, etc., and the toolers got all excited that no one would want to produce that junk by hand, so they could add generation of it to their tools and that would justify a G per seat for their suites. Remind me, Fellas, how did that moonshot go? Oh yeah, it crashed and burned and birthed the biggest reactionary revolutionary of the Java world: Rod Johnson. When I watch the Forge demos or look at Spring Roo, I have to laugh (especially when the Mentos music plays on the Forge ones). Guys, go make a new project in Xcode. It takes about a minute and a half. Yeah, that‘s right, you don‘t have to pick amongst 20 versions of Hibernate (only to find out that 4 is incompatible with Seam 2 3 days later), and you only have one test runner, but you can customize things. I added OCHamcrest to my projects, and OCMock now. While I‘m at it, coming off of days of sifting through the crash site engendered by the innocent need to move Jenkins and Nexus, seriously, the situation with the management of dependencies in Java has gotten to the stage where it‘s like that fire that started in the coal slough pile in Kentucky that‘s been burning for 10 years, or the state budget of California, which no one really has been able to even feign command of for 3 decades.

If there‘s one commandment that has stood the test of time in the software engineering world, it‘s the one laid down by the brilliant Ivar Jacobson: use cases must be the central focus. We have convinced ourselves that we have to have all these things because we were suffering with what we had. A hot dog is a feast to a starving man. Having failed to really deliver on the promise of serious end-to-end modeling, we have comforted ourselves with these rapid fab demonstrations of cutting through the sheets of ice. When it obviously makes more sense to not get yourself stuck in the first place.

A Mini/Lion Server Migration Story

Rob Williams — Wed, 1 Feb 2012 16:31:44 -0500

A lot has been written about Lion Server. First there were a lot of people who came running into the room screaming about how the interface to it had been dumbed down to the point of useless cartoon. Then there were a bunch of reviews saying the idea of the server has been simplified, finally, after all these years. The truth, as usual, lies somewhere in between. Let me make a quick point here though: in a world that should clearly regard complexity as one of the chief things to try to learn and understand, and develop techniques for intelligently reducing, further, where everywhere our worst problems scream out that complexity has beaten back would be simpletonian conquerors, you would think that people would at least show some interest in this. But, sadly, the world is still happy to try to use complexity as a cloak. The experts do everywhere (doctors, chefs, programmers, admins, filmmakers) and when someone comes along and tries to reduce it, they are often met with a thankless lot of being harangued by said experts. Why? Because their simplification didn‘t account for every stupid thing the expert needed (Lion Server, Final Cut). The key is that there has to be a sufficient desire on the other side to make the simplifying party continue on. Not sure whether Apple will (they gave up on iWeb, which was a pretty astounding tool for making websites that could be made an absolutely amazing one with a little TLC and someone who could do some abstracting). I hope they do.

When everything was said and done, the frustrations afforded my cruise from mini 1 to mini 2 that went on the Apple scorecard as debits were minute compared to the ones from my trusted open source java tools. I have whine mercilessly in the past about how Jenkins/Hudson stupidly piles up tons of ancient, useless builds and they are about as easy to get rid of as lice in a population of soldiers stooped in wet foxholes. That came back again. I love Jenkins, but what a stupid way to behave. My first law of computing is ‘thou shalt not make a mess,‘ and Jenkins fails miserably in that regard.

Moving the jobs themselves was pretty easy. The main complication came from the fact that at some point I generated ssh keys for the _appserver user (a hidden user on OS X) and figured out that they had to go into /var/empty, but I could not find where I learned that from (should have blogged about it). This time I will go ask a question on StackOverflow. For this venture, I just moved those keys over to the new server and the build worked (the keys were already installed in the GitHub owner‘s account).

Moving Nexus was no picnic, but a great thing came out of it. When I first moved to Maven way back in 2006, I setup a corporate repo that was served through WebDAV and used certs that each dev had to install into their cacerts file. Sounds simple, but the amount of stupid timesuckery that caused over the years made a huge ant file that pushed binaries around almost look tasty. But Ant (model-less) was so dumb I never put the car in reverse. I used Archiva, but that was a PITA, and really was just a good way to have a ui to stick artifacts into repos (since many of them didn‘t have maven repos). When I found Nexus, thanks to Mert , I was hoping I could have it give me all 3 things: public repos proxied, my own collection of 3rd party crap that didn‘t need to be protected, and my private repo. Took the first 2 and ran at first. Finally went back for the 3rd while moving it this time and got that to work. Ah… ! Thanks Nexus!

Meantime, my couple little nits on moving Nexus:

the config files are cleanly cordoned off in a dir and are even readable XML
the LDAP configuration page is pretty clear and easy (did a StackOverflow Q and A About Configuring LDAP, but getting settings.xml setup for access to private repos is not clear and configuring groups not clear either
moving repositories was pretty easy, but how hard would it be for this thing to have a way to make a repo dump and then restore it into another repo?? I didn‘t want to take all settings because for instance the LDAP server is obviously different..

Anyway, stupid amount of time, but ultimately got there with improvements. My suggestion on the Nexus docs is they are way above average, but, they should think about making some wizards in the app. The problem with apps like this that are completely wizard free is that you end up looking like Microsoft‘s interface for Exchange Server (the way it was when they first launched): a huge maze of tabs with interdependencies that you don‘t know about.

The last thing in moving to the new i7 mini with an SSD and 8 GBs of RAM is to separate out the builds into one build that runs only fast tests that have mocks for anything outside and then have the tests that verify that outside dependencies are still the same run occasionally from another job.

Nits on Apple‘s side are that the migration tool failed 2 or 3 times then we just moved things manually but that mostly worked and was not terribly difficult. We ended up making new user accounts. The wikis migrated which was cool. I thought the Lion Server Wiki was supposedly more powerful, not seeing that so far. Anyway, on the whole a remarkable package. Linux has been going 20 years. I hope Apple will just drive a spike through the idea that you need an admin to setup and then nurse a simple server. It‘s time…

Master/worker or P2P Grid? How about You choose?

Laurent Cohen — Wed, 1 Feb 2012 13:26:04 -0500

What is possible?

Simple master/worker topology

In its initial design, JPPF is a distributed parallel processing framework based on a master/worker architecture. A JPPF grid is made of 3 sorts of components that communicate with each other: clients which submit the work to the grid, nodes which execute the work, and servers which receive the work from clients and distribute it to the nodes in parallel. This gives us a grid topology like this:

An important point to note is that each node can only be attached to a single server at any given time. It doesn't have to always be the same server. For instance, if the connection to the server is broken, some failover mechanisms, whether built-in or user-defined, will allow the node to connect to another server.

Let's get more complex

A further addition to this design enables servers to communicate with each other, allowing a server to offload some of its work to other servers. The current implementation allows users to configure a server so that it can be seen as a node by other servers, and these other servers will be seen as clients. If you define that relationship both ways, you have the possiblity to define much more complex topologies for your JPPF grid:

Here we see that servers can be connected to each other in a P2P topology, but also in one-way fashion, which opens up a bunch of possibilities.

Local nodes

Another possibility in JPPF is the ability to have a node local to the server's JVM. This local node is exactly the same as a remote node, except that it is always connected to the same server, and the communication with the server is done directly in memory instead of via a network connection. This allows for a much faster communication between the local node and the server, however this communication boost is only available to the local node. In a simple topology, it would look like this:

Note that both a local node and remote nodes can be attached to the same server.

Pure P2P

Now, if we only attach a local node to each server, and configure all servers to communicate with each other in full duplex, we achieve a pure P2P topology for the grid:

How is it done?

All the topologies we have seen above are achieved by configuring the JPPF servers accordingly. We will see here how to configure a pure P2P grid. In the simplest case, where all components are on the same network, and when there are no restrictions on UDP multicasting, all you have to do is the following:

enable each server to broadcast its connection information: this is enabled by default
enable each server to receive broadcasts from other servers (disabled by default)
activate a local node in each server (disabled by default)

Concretely, this translates into setting the following properties in the server's configuration file:

# enable the broadcast of connection information
jppf.discovery.enabled = true

# enable auto-discovery for peer-to-peer communication between servers
jppf.peer.discovery.enabled = true

# activate the local node
jppf.local.node.enabled = true

In more complex network environments, you may not be able to rely on UDP multicast for broadcasting. This would happen if some of the servers are on different networks, or if the servers are running within a cloud environment such as Amazon's EC2. In this case you might have to perform a manual configuration of the peer servers to connect to. We won't detail it here, however it is fully documented in our server configuration guide.

Conclusion

We have seen that a JPPF grid is not limited to a master/worker architecture. A lot of flexibility is offered by the framework, which results in complete freedom for the users to chose the topology that works best for them, be it simple, complex, P2P-based, or anything in between. Even better, this can be achieved with simple configuration changes.

JLibs: Updates to DAOPattern

Santhosh Kumar T — Tue, 31 Jan 2012 06:34:36 -0500

JLibs: Updates to DAOPattern

DAOPattern now supports:
- quoting identifiers (table/column names)
- support for database specific sql types
- validating database schema with pojo definitions at compile time

Gentoo: Mount iPhone with FUSE

robert burrell donkin — Tue, 31 Jan 2012 05:25:58 -0500

Thanks to great work by the communities over at FUSE and libimobiledevice, mounting your iPhone on Gentoo is smooth — provided your avoid a Doh! or two. Here's the recipe I use.

Gentoo Prep

The Gentoo box needs:

app-pda/ifuse merged (as root # emerge app-pda/ifuse) and
kernel support for FUSE (those rolling their own may need to recompile).

Create a suitable mount point, # mkdir /media/iPhone say (if one isn't already available).

Once the Gentoo box is ready to play, it's time to connect the phone.

Connecting iPhone

Connect your iPhone to the Gentoo box using USB. My iPhone bleeps when plugged in. This is a little fiddly: if you don't hear a bleep, check that the connections are seated correctly.

Check that the iPhone is available to Gentoo — you should find Apple, Inc. iPhone 4 (or something similar) contained in the # lsusb list.

With your iPhone, unlock the device by entering your passcode.

At your computer as root

# ifuse /media/iPhone (or your favoured mount point)
(if everything goes well, silence)

now

# ls -la /media/iPhone/ should list directories on your iPhone, something like:

total 4
drwxr-xr-x 14 root root  578 Dec 19  2010 .
drwxr-xr-x  4 root root 4096 Dec 20 09:07 ..
drwxr-xr-x  2 root root   68 Dec 19  2010 ApplicationArchives
drwxr-xr-x  4 root root  340 Dec 19  2010 Books
drwxr-xr-x  5 root root  170 Feb 17  2011 DCIM
drwxr-xr-x  2 root root  170 Jun 15  2011 Downloads
drwxr-xr-x  7 root root  340 Dec 20 11:11 PhotoData
drwxr-xr-x  2 root root   68 Nov  6  2010 Photos
drwxr-xr-x  2 root root   68 Jul 22  2010 Podcasts
drwxr-xr-x  2 root root   68 Dec 19  2010 PublicStaging
drwxr-xr-x  2 root root   68 Jul 22  2010 Purchases
drwxr-xr-x  2 root root  918 Sep 18 08:34 Recordings
drwxr-xr-x  2 root root   68 Dec 20  2010 Safari
-rw-r--r--  1 root root    0 Jul 22  2010 com.apple.dbaccess.lock
-rw-r--r--  1 root root    0 Jul 22  2010 com.apple.itdbprep.postprocess.lock
-rw-r--r--  1 root root    0 Jul 22  2010 com.apple.itunes.lock_sync
drwxr-xr-x  6 root root  204 Aug 20  2010 iTunes_Control


And that's it — your iPhone will then be mounted on the Gentoo box.



JLibs: Generating Sample XML from given XMLSchema File
Santhosh Kumar T — Mon, 30 Jan 2012 11:36:43 -0500



  
  JLibs: Generating Sample XML from given XMLSchema File






Generating Sample XML from given XMLSchema File









Michael Feathers: Code Blindness
Sebastian Kübeck — Sun, 29 Jan 2012 11:00:04 -0500
Michael Feathers keynote 'Code Blindness' from Rocky Mountain Ruby 2011:



His own comment on this talk on twitter:

  I'm often v. critical of my talks, but I really like this one.




Static compilation for Groovy poll results
Cédric Champeau — Sun, 29 Jan 2012 09:10:59 -0500
Static compilation or no static compilation?
In my previous blog post, I published a link to the slides from my talk at the Paris Groovy and Grails User Group, where I presented the state of static type checking and compilation for Groovy 2.0. This talk was a unique occasion to retrieve feeback from the user community before we make any final decision about what should (or should not) be included in Groovy 2.0. Especially, we discussed about static compilation (there's a consensus about static type checking, so I won't talk about that here).
I decided to add two polls to my presentation and especially, I wanted the poll about why people wanted static compilation to be answered before I talked about the feature. This was important to me because I didn't want the result to be biased by my talk. After two weeks, 42 persons have answered the polls. Nor me, nor Guillaume Laforge nor Jochen Theodorou answered the poll, once again not to bias the results. Here are the results for question 1:

Again, the question was introduced before I talked about the feature and it's a multiple choices question (you may choose several answers). What is interesting is that only 3 persons said they didn't want static compilation, although on the development mailing list, people against static compilation were very vocal. If only 3 people do not need static compilation, this would mean that the others have a good opinion about why they need it, so the following figures are interesting too:

performance and type safety are both at the same level and the highest number of answers (17). While performance was really to be expected, I didn't expect type safety so high, because basically, if you need type safety, the @TypeChecked annotation is enough (you don't need static compilation). However, this is only true if you don't consider the monkey patching issues, where the behaviour of Groovy can be changed at runtime, leading to runtime type errors while the program was statically checked.
I want a better Java comes next, with 12 answers. I expected this one, because when we talked about the static compilation feature on the mailing list, we had an interesting discussion about why people use Groovy, and I was thinking a lot of people already used Groovy as a better Java, although the language wasn't designed as a replacement but more as a companion to Java.
the next reason coming is that people do not need the dynamic features of Groovy. This is interesting too, because it has to be linked to two different things. First, type safety, because as we already said, you can type check the program to ensure type safety (not needing static compilation) only if you can guarantee that nothing beyond the scope of the compiler (already compiled classes, third party libraries or frameworks) do no modify the behaviour of a program at runtime. Statically compiling the program disables dynamic features, so using static compilation you can ensure type safety. The second point is that if you do not need dynamic features, then you are probably using Groovy as a better Java.
the last option was to comment to tell about why you need static compilation. 4 people chose that option, but didn't comment, so unfortunately I won't be able to tell much about that :-). But it's already interesting to notice that this score is still higher (but not far) than people who don't need static compilation.

In my talk, after this poll, I started explaining the semantic differences that may appear when you statically compile a program, as compared to dynamic behaviour. I did that because I expected my explanation to make some people change their mind about static compilation. Especially, the most visible difference comes from method dispatch (runtime based in dynamic Groovy or ahead of time in static Groovy). I wanted to tell people that this difference is probably the one which will ultimately make the decision about integrating static compilation in Groovy Core or not. I explained 3 options, which were Java-like method dispatch, dynamic groovy like method dispatch and inference based method dispatch. In the end, I asked people to tell which of the options they preferred:

To summarize once more the pros and cons of each method, I would say that:

Java-like method dispatch has the advantage of well known semantics (though many people are uncapable of telling what precise corner cases would do in Java), but adds a lot of verbosity and disables de facto some of the features we already implemented in the type checker (like flow typing).
Dynamic Groovy like behaviour has the major advantage of keeping the same semantics as dynamic Groovy, but has also major problems. First, performance, because runtime time dispatch is much slower than compile time dispatch. Second, statically checking a dynamic program is always error prone: the compiler may think that method 1 would be called, though at runtime, method 2 would be (because Groovy chooses the best method at runtime according to the actual type arguments), so you would have a difference between what the compiler thinks and what is really done. This means that type safety cannot be ensured anymore...
Inference based dispatch, which is the current implementation, which has the advantage of being close to dynamic groovy while preserving a high level of performance. The major problem with that solution being that we introduce a third semantics which is nor the one from Java, nor the one from dynamic Groovy. The question, in the end, is always: "is it a problem?"

Looking at the poll results, there are already two very interesting things to notice: first, very few people answered that question (14 persons, barely 4% of all viewers of the presentation). My interpretation is that the question is complex, and that not many people actually understand the problem (which also makes me think some talks about the subject are important ;-)). But this also confirms to me that even in Java, very few people are actually capable of interpreting how method dispatch works. Basically, I think the reasoning is much simpler. If a program doesn't do what you expect, then you debug it and solve the problem, be it a dispatch problem or not. The second interesting figure, which I did not expect at all, is that nobody chose the Java option. Once more, I interpret this as people are not afraid of having different semantics as long as debugging is possible.
Ultimately, let's compare the results of the two chosen options. Dynamic based dispatch has 6 answers, while inference based dispatch has 8. Being aware that most of the people who viewed the presentation weren't at my talk and didn't get the explanations about why I preferred inference based dispatch, I think the results are very interesting. If you consider that most people want static compilation for performance and type safety which, as I explained, cannot be ensured with dynamic based dispatch, the figures suddenly highlight a strong contradiction. Many people are interested in performance and type safety but still want to keep the dynamic behaviour. My traditional answer for that kind of people is that they should choose invoke dynamic support which will appear in Groovy 2.0 too, as it will guarantee the runtime semantics of a dynamic groovy program while improving performance (though, be warned, type safety cannot be ensured). Of course, static compilation is primarily aimed at people who cannot use invoke dynamic. For that, it seems that the results are in the good direction, because as long as you are aware that you choose a different semantics, then you are not lost. Hopefully, as I said, static compilation is totally optional, so if you choose to use static compilation, you are warned that you will have a slightly different runtime semantics. People who make intensive use of unit tests will probably be very happy with that :-)
Last but not least, the polls are still open. Feel free to answer and comment, as feedback is really important. The most important thing, in the end, is the user community.
Update: below you'll find the updated figures, as of February 9th, 2012:




Monster Turbine High-Performance In-Ear Speakers
evans — Sat, 28 Jan 2012 08:41:46 -0500
First impression: I can't believe this packaging! The box sure is fancy. Much more importantly, I got not one, but two very nice carrying cases for these earphones: one has a magnetic clasp, the other has a spring-loaded clasp. Not much cost-cutting here.


I also got four sets of rubber-like ear tips that go in your ears, various sizes. Also included with Monster Turbine High-Performance In-Ear Speakers are two more that are longer and conically-shaped, with graduated steps. Once I found the set that fit, I was all set: isolation is very good and these things tend to stay in your ears, even when you're moderately active (running should not be a problem at all).


Second impression: The earphones themselves are heavy in your hand and feel more like jewellery than the average, plastic earphones. A good portion of each unit appears to be metallic. They're also larger than many earphones of similar design. The red and blue rings around each unit to identify right and left "speakers" is a welcome touch (I'm no spring chicken and trying to read the word "right" at the gym takes too long). Despite their weight, they don't seem heavy or uncomfortable in my ears. I've had them on for almost five hours with no problem at all.


Most importantly: the sound is surprisingly good for a $99 set of earphones (don't pay $149, though they would be a fair value at that price). The transducers themselves are fast and transient response is remarkably good. Frequency response across the spectrum also seems very good, with an overall "warm" sound. Bass response is good: the bass is there, and is not overemphasized. 


These Monster Turbine High-Performance In-Ear Speakers units are more accurate than their price reflects: classical music sounds surprisingly accurate and "airy", jazz sounds spectacular, club dance music is engaging and enveloping and you can really hear the bass. Turning up the volume seems to improve the sound. I believe some "burn-in" may improve the overall sound, not that improvement is needed.







CRIMC1017E Failed to locate '{0}' resolution
Hazem Ahmed Saleh — Thu, 26 Jan 2012 20:36:35 -0500
I wrote this post in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/27/crimc1017e-failed-to-locate-0-resolution/


Using H2 connection pool in Spring
Fyodor Kupolov — Thu, 26 Jan 2012 10:08:44 -0500
H2 is bundled with a built-in connection pool implementation. The following XML provides an example of using it as a Datasource bean without a need to introduce additional dependencies on DBCP or C3P0:
    <bean id="dataSource" class="org.h2.jdbcx.JdbcConnectionPool" destroy-method="dispose">
        <constructor-arg>
            <bean class="org.h2.jdbcx.JdbcDataSource">
                <property name="URL" value="jdbc:h2:dbname"/>
                <property name="user" value="user"/>
                <property name="password" value="password"/>
             </bean>
        </constructor-arg>
    </bean> 
The database will be shut down by calling a dispose method when Spring application context closes.



Mothballing My AV Receiver
Rob Williams — Wed, 25 Jan 2012 02:55:31 -0500
I put a Sonos system in our office 3 years ago. I‘ve had some gripes, but overall it has been really good. It‘s still better than iTunes, and mostly for stupid reasons, like Apple not adding a queue and the fact that doing multiple rooms with Apple is still a huge PITA.

	I wanted to put Sonos in my house too, but whenever I read about putting in their unit that piggybacks on the receiver, the air just went out of the balloon.

	Then a kind of crazy thing happened. My setup started taking a really long time to startup. I thought it was the Uverse DVR. But then, one day I was reading about AVR receivers and found out that in fact my Onkyo Receiver was the reason. I found a bunch of threads that contained a simple explanation: Onkyo cheaped out on the HDMI components it put in. It‘s kind of weird to wait around for 5 minutes a lot of the time, for something to turn on. After a while, you pretty much just want to throw the thing out the window.

	So I decided I have to get a new receiver, and I might as well put the Sonos in at the same time. Then, as I was reading around, I did a search to see if anyone had assayed the idea of doing a Sonos-only system. Found an article where the CEO of Sonos was interviewed and addressed the question. He said that they didn‘t think component manufacturers were long for this world. Yet, the Sonos Amp doesn‘t have an optical port on it (which is totally insane). But I decided to go ahead anyway, figuring if it sucked, I‘d have the Sonos stuff and I could just pick up a receiver. I was mostly concerned with whether or not the audio on TV/movies would be any good. I got a DAC that has an optical on one side and RCAs on the other.

	This was probably a month and a half ago. So far, it is much better. I had audio in my kitchen for a while which was great, but then eventually didn‘t anymore because Zone 2 on the Onkyo (and most receivers) is analog only so digital sources cannot be used. One of the reasons this setup is much better is that I can just pop out my phone and adjust the volume, turn the kitchen on and off, etc.

	Funniest thing is that I don‘t really need a universal remote anymore, which is good, because the Logitech has been super flakey. I loved it in the beginning but the battery blew up multiple times and had to be rebooted a lot. Stupid. My girlfriend is actually able to do things faster with just the TV remote (dialing up the HDMI sources) and then the iPhone for the audio.

	The one thing I thought of at the last minute was how to do a center channel. I ended up doing a Play3. Works pretty well. There are still dropouts from time to time with Sonos, but overall it probably is the beginning of the end for components. Some of the really high end receivers have started to adopt the iPad as a remote. Good idea, but probably too late. One of the best things about Sonos is using the phone and the iPad. One of the other minor things that kind of sucks with Sonos is you pretty much want to turn it off when you are going to kill the AV, otherwise it makes little noises. BTW, the whole thing should suck a lot less juice than a receiver too, since the Sonos amps are Class Ds. Some of the new really high end AVRs use Ds now too (e.g. the Pioneer SC-57).

	OMG, I was watching a tiny bit of AC360 for SOTU commentary, and just caught a Celebrex commercial with 2 zombies bicycling through the countryside with helmets on while the narrator burbles on about kidney and liver failure and the fact that, should it happen, death will follow. I am going to greet whoever finally delivers real streaming solution free of the huckster/peddler rattletrap as a liberator worthy of a huge stone temple and a single name.


Apple Defies Again
Rob Williams — Wed, 25 Jan 2012 02:17:43 -0500
To say that Apple‘s foes have misread it is the understatement, perhaps of all time, not just the technology era. The weasely geek narrative has been that Apple is a walled garden and will be easy kill as soon as the open source/free guys run it down. Which was going to be easy because walled gardens are supposedly a single little homunculus running at full bore but falling to predation because of the limits of its short little stumps. Not surprisingly, when the 4s came out instead of the 5, the would-be predators beamed with glee: finally, our flesh feast is upon us. What to say after today but ‘whelp?‘

	Of course, we have to note that Google‘s miss a few days ago cuts a nice contrast.

	There‘s a single explanation for both things: it‘s one of the most deadly things in nature, it‘s called monoculture.

	Open is, by definition, an oppositional notion, not super meaningful on its own, at its core, basically just reactionary. It‘s going to save us all from the horror of closed. Well, folks, when do we say the jury is back and the verdict is that the revolutionary saviors have lost. Please, stop trying to save us. Save yourselves. If you can. I‘m pretty sure you can‘t.

	‘How could Google be a monoculture? they do email, they have a social network, they make phones, do photo sharing, maps, flight information…‘

	Well, cultures don‘t mean a huge slate of petrie dishes. It implies that there are things growing in them Google is still an ad peddler, period, and as their results showed, they are finally headed down the scree on their bums. Long before Google was birthed by its wealthy VC progenitors, I was a rabid anti-ad person, so I could not be happier to see that there might be a future where you can buy things and not be carrion for a wake of vultures .

	Just to triangulate this, the other great monoculture, worse, would-be self-crowning failed emperor of the 90s monoculture, Microsoft was featured in a story in BusinessWeek last week that quickly convinced me that I‘ve given them money for the last time. It was so dumb, it made squeaking noises as it made its way from my eyes to my inner voice. The basic slant of it was Ballmer has managed to make the company cool. The sickest, stupidest part was that I suffered all the way to the end of it, like Diogenes, looking for a single thread of truth, to find that, surprise, there was a. not a reason in creation to think Microsoft is cool, but b. less than no reason that if they have succeeded in anything Ballmer should not get a lick of credit. The writer tries to make an argument that Ballmer made tough choices, but each story was ‘Ballmer hired a guy and put him in charge of ____.‘ Did these clowns read any of their searing pieces about the genius of Jobs? Apparently not. Either that or they did, but then the blinding light of their god erased it all on contact: no not, Ballmer, the blubbering marshmallow man who makes Newt Gingrich look like Jack LaLane, Dollar Bill.


Red Hat!
Mario Torre — Mon, 23 Jan 2012 11:56:04 -0500
On the road, again and again :)
I finally decided to accept a great opportunity at Red Hat and signed with them!
I will join the Java Team with Andrew[s] and Deepak and all the other great hackers in a really cool team.
I'm not the only new joiner, and it's amazing how things go in the world at times :)
I'm very proud of being at Red Hat, is since ever I wanted this, so you guess how I'm the happiest person ever now :)
Let me share with you two pictures about this: 
 

The second one comes from one of my contact of Flickr. It's amazing, since she posted this the same day I signed the contract and she was not aware of this. I take it as a good sign :)
Thanks Deepak for this opportunity! 
 
UPDATE: Seems now that the identity of the mysterious guy is finally revealed :) Cheers Roman!



Grails: Bootstrapping data with DomainBuilder
Andres Almiray — Mon, 23 Jan 2012 07:35:21 -0500
A few days ago I was discussing the topic of builders during a Grails training session. After surveying the usual suspects found in the standard Groovy distribution (MarkupBuilder, SwingBuilder, Antbuilder and ObjectGraphBuilder) we jumped into Grails' DomainBuilder. Once we got familiar with it the team seized the opportunity to refactor an existing application they've been working on for a few weeks. The idea was to remove a very verbose data setup during the bootstrap sequence.
Like many other applications out there, this one requires setting up users and roles to secure access to some areas. The User and Role classes looked like the following ones
class User {
    String username
    String name
    static hasMany = [roles: Role]
    static constraints = {
        username(nullable: false, blank: false, unique: true)
        name(nullable: false, blank: false, unique: true)
    }
}

class Role {
    String name
    static constraints = {
        name(nullable: false, blank: false, unique: true)
    } 
}
Nothing complex really. Now, during bootstrap there were a handful on instances of both classes being created and saved. A few users would share roles which meant keeping a reference to the common role to later use Grails relationship methods. This caused the code to be not so much DRY, and while it's good to be WET from time to time this wasn't the case. Let me show you how the code looked like before we added the builder
import com.acme.*

class BootStrap {
    def init = { servletContext ->
        User user1 = new User(username: 'user1', name: 'Regular')
        User user2 = new User(username: 'user2', name: 'Super')
        User user3 = new User(username: 'user3', name: 'Über')
        User user4 = new User(username: 'user4', name: 'Admin')

        Role role1 = new Role(name: 'Observer')
        Role role2 = new Role(name: 'Executor')
        Role role3 = new Role(name: 'Collector')
        Role role4 = new Role(name: 'Administrator')

        user1.addToRoles(role1)

        user2.addToRoles(role1)
        user2.addToRoles(role2)

        user3.addToRoles(role1)
        user3.addToRoles(role2)
        user3.addToRoles(role3)

        user4.addToRoles(role4)

        role1.save()
        role2.save()
        role3.save()
        role4.save()
        role1.save()
        user2.save()
        user3.save()
        user4.save()
    }
}
We could have saved a few lines by collecting all domain classes in Lists then applying *.save() on the lists, however that would still have left the relationship methods being defined explicitly. This is where DomainBuilder came in. With it we were able to define the domain instances and the relationships at the same time. We ended up with code looking like the following one
import com.acme.*
import grails.util.DomainBuilder

class BootStrap {
    def init = { servletContext ->
        DomainBuilder builder = new DomainBuilder()
        builder.classNameResolver = 'com.acme'
        builder.identifierResolver = { 'nodeId' }
        builder.registerFactory 'list', new ListFactory()
        builder.childPropertySetter = new CustomChildPropertySetter()

        List instances = builder.list {
            role(nodeId: 'role1', name: 'Observer')
            role(nodeId: 'role2', name: 'Executor')
            role(nodeId: 'role3', name: 'Collector')
            role(nodeId: 'role4', name: 'Administrator')

            user(username: 'user1', name: 'Regular') {
                role(refId: 'role1')
            }
            
            user(username: 'user2', name: 'Super') {
                role(refId: 'role1')
                role(refId: 'role2')
            }
            
            user(username: 'user3', name: 'Über') {
                role(refId: 'role1')
                role(refId: 'role2')
                role(refId: 'role3')
            }
            
            user(username: 'user4', name: 'Admin') {
                role(refId: 'role4')
            }
        }
        
        instances*.save()
    }
}
DomainBuilder understands perfectly well the relationships between domain class instances. It also makes some assumptions on how the model is setup, but we still need to give it a few hints. In line 7 we can see a classNameResolver set on the builder. By convention the builder will use an strategy to construct fully qualified classnames out of node names. If the classes happen to be defined inside a package then you must define a custom classNameResolver. In our case the classes we're interested in live under the same package so we only need to specify it, the builder will do the rest to figure out the correct class name.
Next, we must set a custom identifierResolver because the id property is of semantic meaning to domain classes. The builder can keep references to all instantiated nodes, it will use the id property by default, assuming that's a synthetic property. This means it will treated in a different way than the rest of properties. Because id is used by domain classes we set a different synthetic property named nodeId. Finally we define a custom factory to serve as the root of the object graph. This custom factory requires additional setup to handle its children, which is why we also register a custom ChildPropertySetter on the builder. These two helper classes can be seen in the following snippets
private static class ListFactory extends AbstractFactory {
    Object newInstance(FactoryBuilderSupport builder, Object name, Object value, Map attributes) {
        []
    }
}private static class CustomChildPropertySetter extends DomainBuilder.DefaultGrailsChildPropertySetter {
    void setChild(Object parent, Object child, String parentName, String propertyName) {
        if (parent instanceof List) {
            parent << child
        } else {
            super.setChild(parent, child, parentName, propertyName)
        }
    }
}
Basically the code inspects the type of the parent node. If it's a List then we append the child to it, otherwise we let the standard behavior take control. You can read more information on the builders used at FactoryBuilderSupport and ObjectGraphBuilder.

Keep on Groovying!


Static type checking talk from Paris Groovy/Grails User Group
Cédric Champeau — Sun, 22 Jan 2012 13:12:14 -0500
Static type checking and compilation in Groovy 2.0
This week, I had an interesting 2 days work session at Paris (La Defense) with Guillaume Laforge, Jochen Theodorou and Rémi Forax as a guest star. On Thursday night, I talked about my work on static type checking and experimental static compilation at the Paris Groovy and Grails User Group. Here are the slides:



Some comments
First of all, a large part of the session was spent in explaining what static type checking implies in terms of semantics for a language like Groovy. I tried to explain that by definition, type checking a dynamic language is impossible, so you have to make decisions and drop support for dynamic features in that case. However, this is in most situations not a problem for people looking for static type checking, because what they need is to guarantee the behaviour of a program at runtime and compile time.
The last part of the talk was spent in explaining the most important difference in behaviour between dynamic method dispatch and static method dispatch. This was necessary to introduce the experimental static compiler which should make its way in the next beta of Groovy 2.0. I tried to explain the three different options we have regarding static compilation and method dispatch:

Java-like method dispatch, which has the main interest of being known of most people (at least, people who faced the problem once). This solution however has major drawbacks. In particular, it removes most of the interest of the flow typing mode, and requires extra verbosity which is the opposite of the Groovy philosophy.
Dynamic-Groovy like method dispatch. Typically, this is wanted to avoid a "third language" (not Java, nor Groovy), and this is were you want a statically compiled Groovy program to behave at runtime like dynamic Groovy does. While this sounds interesting, it also has major problems. The first one is performance, which would be awful because we would have to introduce tons of "instanceof" checks at compile time to correctly dispatch methods. More complicated, this "instanceof cascade" would generate unreadable bytecode (think of parameter combinations) which would also be a major performance issue for CPUs (which, as Rémi said during the session, really do not like branching). Even worse, this wouldn't work anymore if you subclass the statically compiled class because the new overloaded methods wouldn't be known from the compiler. This is why I consider this solution the worse of all, though I understand people who want it. Last but not least, Groovy 2.0 will introduce InvokeDynamic support which should greatly improve performance of dynamic Groovy without loosing its semantics.
The third solution I presented is the one currently implemented in the experimental compiler: inference based method dispatch. This definitely creates a third language in terms of dispatch semantics, but as the developer explicitly adds an annotation, he should be aware of the differences (which only occur when you have overloaded methods). Inference based dispatch also has the advantage of being "flow typing" compatible, and removes a lot of verbosity. It has my preference, which explains why this is what is implemented right now.

Our guest star Rémi Forax also suggested an alternative solution, which would in theory maintain the semantics of dynamic Groovy, though we are in a statically compiled world. The idea is that when the compiler detects an overloaded method, it should generate the appropriate instanceof checks and seal the class (to avoid it to be subclassed). But as we discussed that solution the next day, we found some cases where even in that situation, we wouldn't be able to guarantee dynamic Groovy like behaviour without adding explicit guards on every static method call (in particular, changing the metaclass or detection of category usage). This would also lead in a major performance penalty (Rémi couldn't avoid telling us that all answers to our problem are in InvokeDynamic, but still, we want to offer something for pre-Java 7 people).
The future
I ended the talk with a small view of what's still to be done. There are still bugs in the static type checker (especially in loops where an overloaded method result is assigned to one of its parameters) and probably a lot more in the compiler. Eventually, I insisted on the fact that every point of both static type checking and static compilation are to be discussed with the community. While static type checking will most probably be part of Groovy 2.0, it's still unsure about static compilation, and that's why we would like you to answer the surveys that are in the presentation.
Toward a new MOP
As this session was a gift for static types lovers, we also wanted to offer something for our dynamic language users. This came with a long discussion about a new MOP (also known as MOP 2.0). The result of the discussion will be published by Guillaume Laforge as a new GEP (Groovy Enhancement Proposal). Once again, community will be involved.
Thanks a lot!

French speaking users might also be interested in my talk at the Nantes JUG which introduced DSLs in Groovy.


A little help for an Architect :)
Mario Torre — Sun, 22 Jan 2012 09:25:15 -0500
Last year my girlfriend did a training for an important architecture studio in Biel (Switzerland), and one of the projects she was working on more actively has been now selected as a finalist for "Building of the year".
I'm very proud of her! I've seen this project growing from almost zero since you she was updating me for every single small step, and it's quite amazing to see something that on paper looks like:
 


 
 
Actually becomes like this:
 
 
 
Since the election is open to public, if you would like to help us promoting her amazing job, I share with you the link for the voting; either visit: 
http://www.swiss-architects.com/de/projekte/bau-der-woche-detail/33528_janus_sanierung_und_ausbau_stadtmuseum_rapperswil_jona?vote=49 
or:
http://www.swiss-architects.com/de/projekte/reviews_voting/33 and select the project number 49:
:mlzd
Blick in die Vergangenheit und in die Zukunft
Rapperswil-Jona 
You can  vote by clicking on "Mein Favorit" (In the form: Herr is Mr, Frau is Mrs, Vorname is Name and Nachname is family name... well, I think :)
Thanks for helping out!



Eclipse job in Böblingen
Andrey Loskutov — Fri, 20 Jan 2012 08:26:14 -0500

We (Verigy) have a job opening for a Java / Eclipse developer in Böblingen / Germany. Details on G+.


CodeNarc plugin for IntelliJ IDEA updated
Cédric Champeau — Wed, 18 Jan 2012 03:46:49 -0500
CodeNarc for IntelliJ IDEA 0.16.1
Eventually, I managed to upgrade the CodeNarc for IntelliJ IDEA plugin to use CodeNarc 0.16.1. It took a while (sorry Hamlet ;)), but I faced an awful jar hell issue.
java.lang.LinkageError
It's quite interesting indeed, though I am not fully happy with the "fix". Let's see what's the problem. If any IntelliJ expert is here, I'd be happy to have some help. Basically, for compatibility with newer versions of Groovy, both CodeNarc and GMetrics (a dependency of CodeNarc) embed in their jar three classes which have disappeared from the newest Groovy version (in fact, they were moved in other packages):

org.codehaus.groovy.ast.expr.RegexExpression
org.codehaus.groovy.transform.powerassert.Value
org.codehaus.groovy.transform.powerassert.ValueRecorder

Normally, this shouldn't be a problem, but when I ran the plugin, it failed loading with this cryptic error, well known from OSGI users:
java.lang.LinkageError: loader constraint violation: loader (instance of com/intellij/ide/plugins/cl/PluginClassLoader) previously initiated loading for a different type with name "org/codehaus/groovy/ast/expr/RegexExpression"
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
	at com.intellij.util.lang.UrlClassLoader._defineClass(UrlClassLoader.java:124)
	at com.intellij.util.lang.UrlClassLoader.defineClass(UrlClassLoader.java:120)
	at com.intellij.util.lang.UrlClassLoader._findClass(UrlClassLoader.java:96)
	at com.intellij.ide.plugins.cl.PluginClassLoader.d(PluginClassLoader.java:102)
	at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass(PluginClassLoader.java:63)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Oh my, a LinkageError. Worse than a classical classpath issue. The problem comes from the fact that IntelliJ internally uses Groovy (where ?) and bundles groovy-all-1.7.3.jar. I had to remove the compatibility classes from the CodeNarc jars in order to have the plugin loaded correctly. I think a better solution would be to be able to use an embedded version of Groovy, but the plugin loaded would always include those classes. By the way, it looks to me that CodeNarc would use the internal Groovy version to run (1.7.3) whereas it would probably be better if we could use the version used by the project...
Anyway, the plugin is upgraded, have fun!


Rosetta Stone, the Latest Adobe Victim
Rob Williams — Wed, 18 Jan 2012 02:18:38 -0500
How do you go from unchallenged leader in your software category to an embarrassing gimp hanging on for dear life? Simple, you hire an architect who convinces you to roll the dice on Adobe technology.

	Rosetta Stone has killed everything in the language category for a long time. Recently, when it started to look like we might get Rick Perry or Michelle Bachmann, I decided to brush off my evacuation plan and thought I should learn some French. The install of the app was so stupid, it didn‘t even really piss me off, pathetic becomes funny.

	Then I was reading MacLife a few weeks ago and saw a review and, having forgotten my own time in the pen at the Adobe Goat Rodeo, I burst out laughing when I got halfway down their review to find that the poor reviewer was likewise marooned by the idiot installer problems, and as a consequence, the final verdict was Solid (which, in their ‘let‘s say something nice parlance‘ means ‘pretty much a piece of hud‘).

	Here‘s the funniest part. Rosetta Stone is listed as a success story on the Adobe site.

	It‘s like the commercial where the super rich guy wants someone to give him some fresh ideas on how to burn up his excess cash and they settle on making milk without a cow. They are past the midget reaching for the box on the top shelf, it‘s Marx‘s Brumaire stage of farce.

	Hopefully the Rosetta guys will be able to redo their interface with HTML5 before the flesh eating bacterium devours their internal organs.

	Ironically, last week I got my first exposure to After Effects and found it to be one of the best Adobe apps I‘ve used so far. Clearly, the platform push was Napoleonic. Will be interesting to see if the AE and Edge contingent can hold off the new HTML 5 competitors. If not, they will probably have wished they‘d stayed focused.


TDD's Better Half
Rob Williams — Wed, 18 Jan 2012 02:06:31 -0500
So yesterday I was thinking ‘TDD is really two things: it‘s about testing, but it‘s also just a methodological means of marking progress. Frankly, I have found the latter more compelling over the last few years. The great metaphor from the Beck book on TDD, about pulling the pale up from the bottom of a 200‘ well really says almost nothing about testing. It‘s more about pacing work, making sure that energy expended is not going to leak out as other things are assayed, etc. Meyer was obsessed by the idea of being able to prove correctness. I love BM, but find that kind of laughably old world. Complexity defies certainty. There are of course many things you can be certain about, but being able to move everything into the certain column would be a sure sign of total necrosis.

	Consider this though: things almost always come in the door promising one thing and then end up putting their focus elsewhere. TDD was sold in the beginning with FUD. It was ‘code sucks and is broken all the time because you don‘t have tests that prove it works.‘ I think the only reason the process element even emerged is because the biggest objection to unit tests was the ‘we don‘t have time.‘ [Read: we are too busy piling a bunch more borked code onto the pyre, step back!] The good news is that in addressing that, the better side of TDD emerged.

	I have gotten to the point where I see people not working in tests on pieces that should take no time to setup and it‘s like coming across someone huddling over a bunsen burner by a train track roasting a rat. I had a bunch of code that I wrote 90% of inside tests that ran in a few seconds. Someone came into one of my tests and added 2 new tests that made remote connections. Took my run for all 20 or so tests in that one file from 1–2s to maybe 30. Took me about 5m to get those two tests into their own separate test and back to 1–2s runtimes.

	What of these two sides? Is this a harmonically balanced story of halves complimenting each other? It struck me today how little activity there seems to be on the testing side anymore, ideas-wise. Anyone working on figuring out how good tests are? how long they are taking? plugging some of the typical leakage points like disabled tests? or flagging dependencies that weaken them? How ‘bout simple problems like making it easier to get data into them (without using some fossilized contraption that has an XML format that has to be maintained)? Even the books are just a dog‘s dinner of warmed up tips. O, Lost World..


NextReports 5.0 was released
MDP — Mon, 16 Jan 2012 11:07:16 -0500
NextReports 5.0 was launched today with some big new features.



First, a 'Global Settings' action can be done for every dashboard. Besides some common properties for all widgets , like refresh time and timeout, all common parameters for all the widgets inside a dashboard can be changed just with one click. To make it easier to use the same parameters in more reports or charts, NextReports Designer adds two actions for parameters. You can clone parameters from the current query /report / chart and you can add the parameters defined in other queries / reports/ charts.



Another big change is that all server settings are kept now inside JCR storage and not inside a property file. In this way when you install a new version, there is no need to copy your old property file over the new one. Also, when you change settings, there is no need to make a restart of the server (there are only a few exceptions with properties which are defined also in your web server configuration). Settings may be modified only by administrators. A logo and some color themes can be changed to modify the look.



Designer can now communicate faster with server with bulk publish and download. Also a bulk change for data sources is available on the server.



Server Dashboards can now be created with 1, 2 or 3 columns. Older dashboards can be modified. Users can see statistics about their dashboards. Widgets have now a timeout which can be modified. 



Internally, the server was updated to JackRabbit 2.2.9 and Spring is now on version 3.



http://www.next-reports.com


Reliable calculation of naturalWidth attribute in IE
Fyodor Kupolov — Mon, 16 Jan 2012 05:29:42 -0500
IE gives me hard times again. I wouldn't say it's bad, because it always helps me to better understand how JavaScript/DOM works.This time I was using naturalWidth property to determine original image size, but it turned out it's unsupported in IE versions prior to 9.0. A quick googling found a working solution, but it doesn't always work for large images in IE. So I came up with the following version for jQuery. Tested on IE9/Chrome/FF:
    /*
     * NaturalWith calculation function. It has to be async, because sometimes(e.g. for IE) it needs to wait for already cached image to load.
     * @param onNaturalWidthDefined callback(img) to be notified when naturalWidth is determined.
     */
    jQuery.fn.calculateNaturalWidth = function(onNaturalWidthDefined) {
        var img = this[0];
        var naturalWidth = img.naturalWidth;
        if (naturalWidth) {
            onNaturalWidthDefined(img);
        } else { //No naturalWidth attribute in IE<9 - calculate it manually.
            var newImg = new Image();
            newImg.src = img.src;
            //Wait for image to load
            if (newImg.complete) {
                img.naturalWidth = newImg.width;
                onNaturalWidthDefined(img);
            } else {
                $(newImg).load(function() {img.naturalWidth=newImg.width; onNaturalWidthDefined(img)});
            }
        }
    };


The Shallows: What the Internet Is Doing to Our Brains
evans — Sun, 15 Jan 2012 04:30:08 -0500
Having a hard time remembering what you just read? Do you find it more difficult to complete a whole book or a long article? While advancing age may be a factor, perhaps a bigger one could be how the Internet is reconfiguring our brains, as Nicholas Carr persuasively argues in this book. 


This book comes in the line of previous cultural critics skeptical of technology, such as Neil Postman a couple of decades ago, but he goes beyond it by showing how this particular technology changes not only the way behave, but the very wiring of our brains. Yes, all upbeat articles we read recently about research that shows how our brain remains malleable until well into adulthood has the implication that the technologies we use could alter the brain to adapt to a world of constant electronic interruptions. 


While this makes us better informed than ever, and by some measures our intelligence can improve, we also lose something important, which is the ability to concentrate long and hard and have deep thoughts and insights.


In making the argument Carr presents a concise and vivid history on how past technological changes altered the life of the mind, such as when going from oral to written knowledge, from longform writing to the one we know today, and more importantly, when going from handwritten to printed books, which led to our modern culture and made possible the breakthrough ideas of the last centuries. He also warns on misguided notions of artificial intelligence and how we become shallower and presumably less human when we completely outsource our memory to machines.


The fact that Nicholas Carr is no technophobe, he clearly appreciates the benefits of modern information technology and has in fact was an early adopter of personal computers, gives greater credibility to his argument. Perhaps a downside of this book is that it's a bit too one sided, it leaves us with no hope that life can be much better because of the Internet, when in fact it's too early to know the lasting impact these technologies will have. 


But in these days of techno-utopianism, when we idolize companies such as Facebook, Google, and Apple, this countercultural book, well written and diligently researched, brings a welcome change and deserves a good reading. 


AgileZen: Dark Side of SaaS
Rob Williams — Sun, 15 Jan 2012 00:34:54 -0500
The draw of SaaS from the user side is not setting up machines, messing around with installs, administering software, etc. Did anyone wonder if the compulsion to continue to improve and innovate would keep the value proposition at least comparable to the open market? Maybe we should have. GitHub has rolled out features, and a native app (though I can‘t use it since it‘s kind of simplistic in its flow support), but AgileZen I don‘t think has delivered a single feature and we‘ve been on it for over a year. Is paying $99/month for software that doesn‘t even have a trickle of improvement a good deal? No. Worse than that, obvious features, still are not there. The most pathetic is that the product does not give you a way to see velocity. Ask yourself the question: what kind of product manager would approve adding story points to a product and then not have a way to see velocity? Folks, you only use story points so that you can get your velocity!

	The even more predictable aspect of humanity than death and taxes is the reality that once something makes its way to a teet, there shall be no attention given to anything other than continuing to suckle. Hence, SaaS is bound to produce a lot more of this kind of stuff.

	Am I dwelling on the negative case? I did present a positive one (though not a perfect one).

	There are some differences. AgileZen is now owned by Rally, which, unfortunately has become a big, stupid company that has long ago passed out of the phase of caring about innovating. Also, I would guess that AgileZen sees its customers as less likely to just pick up and leave.

	Time to look around again. The state of tools is so pathetic. Oh, while I‘m at it, AgileZen is so dumb that if you have 10 projects, you had to go change the column configuration 10 times. Guys, if you aren‘t going to finish your product, pay someone to do it for you with the money we are giving you.

	Stupid.

	List of Kanban Tools
Lone Support Thread on Velocity

Update: Had an exchange with the founder/project lead after posting this. He explained that their energy this past year went to a migration to EC2 and also moving from .NET to node.js (sorry, that didn‘t fill me with confidence about the road forward). He did also tell me though that they finally pushed out their GitHub integration. I just installed that. That is pretty bloody exciting.

	I am going to blog about the other elements of our exchange, about why story points aren‘t there and process templates. I think it‘s pretty interesting. He also mentioned there were a bunch of exciting things coming. Sounds interesting..


Refreshing Dijit tree in Dojo (code that works)
Hazem Ahmed Saleh — Sat, 14 Jan 2012 13:20:03 -0500
I wrote this post in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/14/refreshing-dijit-tree-in-dojo-code-that-works/


The Fault in Our Stars
evans — Sat, 14 Jan 2012 13:11:43 -0500
I am not an emotional reader. Hallmark commercials, Disney movies, beautiful songs, but books never really have that effect on me. I read them, I think about them for a few days, and then I let them go. I've never been swept up into the world of a book enough that I feel the triumphs and tribulations of the characters.


Until this book.


I can't accurately describe the life this book has taken inside of me. I read it through Thursday night, staying up hours later than I should have; I woke up three times in the night, heart racing, caught in the emotional impact of the book; I thought about it all through my Friday morning errands and class; I listened to the audiobook (though not in its entirety) when I returned home. Two days later, I am still having a emotional reaction to parts of the book, sometimes out of the blue. I feel like there are these long-reaching aftershocks, and every time, they twist my belly into knots.


Green stated that he'd sought to write an epic in miniature. I cannot think of a better term for this book. It's unlike his others, it's unlike anything I've read, and I am not sure I can carefully set it in one category or another. It is beautiful, it is haunting, it is funny and tragic and overwhelming.


If you are a nerdfighter or simply heard of the hype surrounding this book, believe it with a grain of salt. Believe it with a voice in the back of your head telling you to be cautious. Because the first two chapters we've all heard are nothing like the remaining 23. And all 25 are nothing like Green's other books, but in the best and most wonderful way. I feel like this is the writer Green was meant to be, the one we've all expected to emerge since Looking for Alaska.


Entertainment Weekly picked "luminous" as their descriptor, but I would disagree.


My word is "resonant", and I am still feeling the afterglow. 





Getting the Selected Dijit Tree node in Dojo
Hazem Ahmed Saleh — Fri, 13 Jan 2012 21:17:33 -0500
I wrote this tip in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/14/getting-the-selected-dijit-tree-node-in-dojo/


Getting out of Tomcat Hell - SEVERE: Error listenerStart
Mert Caliskan — Fri, 13 Jan 2012 11:42:35 -0500

While getting up application context if you see the line


SEVERE: Error listenerStart


and nothing more just drop logging.properties to src/main/resources (if you use maven) or to WEB-INF/classes to get the actual stack trace. The content of logging.properties is like below,


org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler





The Calendar HOUR Trap
David Shay — Thu, 12 Jan 2012 13:50:25 -0500
For the need of some algorithm, a developer wrote this small piece of code that theoretically, from a given Date, will return the same Date but with a time set to the end of the day.

    public static Date setDateToEndDay(final Date date) {
        Calendar lcal = Calendar.getInstance();
        lcal.setTime(date);
        lcal.set(Calendar.HOUR, 23);
        lcal.set(Calendar.MINUTE, 59);
        lcal.set(Calendar.SECOND, 0);
        lcal.set(Calendar.MILLISECOND, 0);
        return lcal.getTime();
    }


As you can see, it sets the time to be 23H59. Being used to the quirks of the Calendar class, and having already fallen to the trap, I immediately saw the bug that would, sometimes, change the day to the next one.

If you take a look at the javadoc for the HOUR field, it says the following:
"Field number for get and set indicating the hour of the morning or afternoon. HOUR is used for the 12-hour clock (0 - 11). Noon and midnight are represented by 0, not by 12. E.g., at 10:04:15.250 PM the HOUR is 10."
So the field should have a value between 0 and 11. If the time part of your date is in the morning, everything will work as expected. But If you have a time in the afternoon, or even at noon, something will change. Something small actually: the AM/PM field will be set to PM. The result is that setting the HOUR field to 23 will bring you to the next day at 11...
The correct field to use for this situation is called HOUR_OF_DAY. Be bitten once, and you will remember it.


PaulDotCom Featuring Bruce Schneier
Sebastian Kübeck — Thu, 12 Jan 2012 13:04:06 -0500
Bruce Schneier talks about his new Book Liars and Outliers in the current episode of the PaulDotCom podcast.





I had to read dozens of security books while I wrote my own and in retrospect I have to say that I learned most from Bruce Schneier's Beyond Fear. So I'm looking forward to reading his new book soon...  



An Eclipse Template for Parameterized JUnit Tests
Rob Williams — Wed, 11 Jan 2012 00:25:13 -0500
After refusing much of any changes, especially the ugly TestDecorator fixture, after TestNG showed up, JUnit went bonkers with a  spasm of matching features. Parameterized tests were in 3.8.1, but in 4.x, they were redone with annotations. The results were rather unspectacular. Mainly because you can never really remember exactly how to put one of them together.

	Which makes it a perfect candidate for an eclipse template.

	Developing this one turned into a nightmare. Mainly because it was the first time I needed multiple imports, and the posts I found on the internet all showed just one, didn‘t know that you had to list the types, comma-separated in a single var declaration. I was kind of amazed at the state of the documentation about the templating system in eclipse now: there is a lot of crap in there. Frankly, I kept thinking ‘ugh, heuristics is still utterly lost in development: we either don‘t document things, or whittle them down to minute detailed schematics, hardly ever achieving a fluid balance between examples and specs.‘ [Ok, that was kind of a long half-quoted thought.] I still wish the template system would allow me to define a var and then the same name but small first letter so I could get an instance without retyping.. ! Might be in there, who knows.

	The real timesuck was the package statement in my template (I like to clear out the whole file with Apple-A/DEL) and no matter what I did, the package appears below the imports. Can eclipse really be this stupid a decade on? I finally relented and removed it for now.

	Here is the template. I think it does make it quicker to setup a parameterized test, and relieves you of having to try to remember the non-intuitive way the plumbing is done.

	Parameterized Test Template for Eclipse


Static Builder Extension Choices
Rob Williams — Tue, 10 Jan 2012 16:06:30 -0500
As has been clear on here for some time, I‘m pretty obsessed with the Static Builder pattern from Bloch‘s second edition. It‘s not really a builder. It‘s a fluent interface builder, which is not the classical version from Gang of Four that uses a Director and has multiple implementers. But the great things about it is you can see the properties being ‘set‘ (kind of like named parameters) and the class is immutable: you can stipulate what can only be provided at creation time without making constructors that take 20 arguments.

	The problem when doing dependency injection is that eventually you will have a property that needs to be looked up in the database. For instance, consider a class called Post (if we were doing a news site) and we have a property in it called Source that tells us where this Post came from. When we create a new Post or import one, we have to lookup the source in the database and then put that into the class. Of course, we cannot do that in the builder because it doesn‘t have an entity manager. I have also blogged about this, about what a drag it is that this aspect of injection/persistence is left to the user despite the fact that 90% of the time it‘s really just boilerplate (looking up the related item by id or name (which could be id)).

	Probably the most obvious idea would be to just make a Factory. The Factory could have the related repository injected, then when you ask for the new Article, you could pass the name of the source and it could look it up and inject it into the Post instance and return it. The problem with this is that the builder is gone and you are stuck having to pass all your crap through the Factory interface(s) [if it‘s a Factory Method, s].

	There are two pretty simple solutions to this: one is to have the factory return not the built object, but a reference to the static builder. That sounds hinky when you hear it because you think ‘wait, one of us build it,‘ but remember, the whole idea is immutability so you have to get all the input before calling build.

	The other option is to have the Factory basically take over the fluent interface. I did this recently in another place and liked the results. Basically, you have static methods in the factory that setup chaining and then a build method.

	I think I will also take a whack at the boilerplate lookup problem, with the proviso that the class would provide the Source and the wrapper would simply perform a lookup to make sure it was preventing a dupe. So for instance, I could do builder.source(new Source(“joeblow”)) and inside the wrapper, it would pull out the source and look for it in the db. Kind of ugly. Another option would be to skip injecting the repository, rather, have the Factory create the source, or hold a default source and then inject that. One advantage to that is if you were doing a large import from a single source, you could set the default once on the factory then just build from there.

	If all this sounds like it would lend itself to a Decorator, that‘s what I was thinking, but the problem with that is that Decorators must stand in for the decorated class, and we can‘t inject another implementation of the builder into the source class (Post). Going to do the class builder that wraps itself around the static builder approach.


Accessing parent window elements from child window in JavaScript
Hazem Ahmed Saleh — Mon, 9 Jan 2012 18:25:27 -0500


I wrote this tip in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/09/accessing-parent-window-elements-from-child-window-in-javascript/.



American Sniper: The Autobiography of the Most Lethal Sniper in U.S. Military History
evans — Mon, 9 Jan 2012 16:03:40 -0500
This is truly a disturbing book. However, war is supposed to be disturbing. The life of any individual is tremendously precious. Therefore to hear of someone who has killed, by official count, over 160 people should be disturbing. In the light of our everyday life it is incomprehensible. However, war is not our everyday life and is in itself incomprehensible. Chief Kyle did what he was trained to do: enter into a realm that is foreign from our lives and do the incomprehensible.


I do not want my warriors, the men and women who protect me and my children, to face down the enemy and give them a real severe tongue-lashing. I want them to stop them, neutralize them, kill them. I want the threat removed and prevented from ever surfacing again. Chief Kyle did what he was supposed to do. To study and make judgements on his method from our sanitized position is illogical and insane. It is inconsistent with reality, just as our Rules of Engagement have proved to be.


There are some areas in which some people will never agree with me. First and foremost, I believe Chris Kyle is a patriot. He is an American hero. Call me what names you wish, judge me as being conservative, disillusioned, ignorant, short-sighted, immoral, unfeeling...whatever. It does not change the fact that Chief Kyle saved lives. If I were in danger and needed protection, I would only hope that it could be a Navy SEAL, preferably Chief Kyle, watching over me. Now, that would make me feel safe. 


See the sample copy here >>


window.open Invalid argument in IE
Hazem Ahmed Saleh — Sun, 8 Jan 2012 16:56:13 -0500
I wrote this tip in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/08/window-open-invalid-argument-in-ie/


Anatomy of a Mock Test
Mert Caliskan — Sun, 8 Jan 2012 11:41:12 -0500


I love mockito and trying to use every bit of it. It offers a powerful stubbing and verification mechanism for unit testing. 
As the author states, Mockito is a mocking framework that tastes really good. That’s for sure! So with this article I'll be stating 
how to configure the mockito and I'll focus on the bits and pieces of testing with mockito with a simple example and how the annotations are used to shape it up.
I believe it's the way to get to understand the capabilities of this framework.



To get the latest version of mockito goodies just configure your maven project with the mockito dependency; along with the junit dependency of course,



        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.10</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-all</artifactId>
            <version>1.9.0</version>
            <scope>test</scope>
        </dependency>



You should be resolving the artifact from central http://repo1.maven.org/maven2/org/mockito repo. So here is the simple testing example.



@RunWith(MockitoJUnitRunner.class)
public class MyServiceImplTest {

    @Mock
    MyServiceHelper helper;

    @InjectMocks
    private MyServiceImpl myServiceImpl = new MyServiceImpl();

    @Captor
    ArgumentCaptor<ApplicantProgress> argument;

    @Spy
    Applicant applicant = new Applicant();

    @Test
    public void applyApprovalStateToApplicant(){
        myServiceImpl.initiateApprovalState(applicant);

        verify(helper).approve(argument.capture());
        assertThat(argument.getValue().getStatus(), is(ApplicantStatus.APPROVED));
    }
}

and the rest of the code,

class Applicant {
}

class ApplicantProgress {
    private ApplicantStatus applicantStatus = ApplicantStatus.PENDING;

    public ApplicantStatus getStatus() {
        return applicantStatus;
    }

    public void setStatus(ApplicantStatus applicantStatus) {
        this.applicantStatus = applicantStatus;
    }
}

enum ApplicantStatus {
    PENDING,
    APPROVED,
    REJECTED;
}

public interface MyServiceHelper {
    void approve(ApplicantProgress progress);
}

public class MyServiceImpl {

    private MyServiceHelper helper;

    public void initiateApprovalState(Applicant applicant) {
        ApplicantProgress progress = new ApplicantProgress();
        progress.setStatus(ApplicantStatus.APPROVED);

        helper.approve(progress);
    }

    public void setHelper(MyServiceHelper helper) {
        this.helper = helper;
    }
}



Here concrete MyServiceImpl implementation is being tested. The initiateApprovalState method gets invoked with an applicant.
MyServiceImpl contains a helper that delegates its actual approve process to. So that why an argument is set to capture the ApplicantProgress which is passed
as an argument to the helper's method. So helper gets verified after the actual invoke of the concrete and equality is asserted for the argument captor, which is
an ApplicantProgress with status value ApplicantStatus.APPROVED. Here are some details of the annotations that are used within the test.



@RunWith(MockitoJUnitRunner.class): The starting point for creating a mockito testing is pointing RunWith annotation of 
JUnit to use the MockitoJUnitRunner class. This will initialize the mocks annotated with @Mock. Mocks will get initialized before each test method.



@InjectMocks: This annotation provides injection of mocks and spy’s automatically. It supports setter injection and with mockito version 1.9.x 
it now also supports constructor injection.



@Mock: This annotation enables the actual mock creation.



@Spy: This annotation enables the shorthand wrapping of field instances in a spy object. So it will proxy the real implementation with a CGLib proxy. 
That will give the ability to stub the calls for the spied instance and return a mocked value.


 	
@Captor: This is another handy annotation that does the job of ArgumentCaptor class. It's used to capture argument values for further assertions.


 
Integrating Jenkins Emma Plugin for getting Code Coverage



Currently in one of my projects (which is a total Microsoft stack, sadly) we’re building a web application 
adapter to conduct as gate to the legacy systems written in Java. The second thing that we’d done after 
introducing maven project structure was installing JenkinsCI for continuous integration. 
Of course we needed a test coverage report immediately per package; we ended up integrating Jenkins Emma Plugin on top of it. 
Likewise you can get your mockito tests coverage reports with this nice plugin. Just get your hands on it!




Python Programming for Hackers and Reverse Engineers
evans — Sun, 8 Jan 2012 08:52:40 -0500
In general the book explains how to watch live programs run and reverse engineer how they work by observing the programs behaviour in real time. The author does an excellent job of showing how to do this via Python PyDbg and the Immunity Debugger.


The topics covered include hooking with PyDbg and Immunity, DLL and code injection, fuzzing common bugs, and working with drivers. All of these are covered well with lots of explanation and example.


The best part of the book is the first area though. Step by step a simple, working debugger is built. At each step the author explains how the CPU allows for program debugging, how debuggers can intercept the currently running code, and how to perform three types of debugging. Because the reader gets to build the debugger line by line, it is easy to see how the debuggers work internally. The amount of information learned in this part of the book makes it worth getting just in the first four chapters.


For the next two thirds of the book, the reader is shown how to use the PyDbg and Immunity. Since the basic operation of debuggers has already been covered, it is much easier to understand what the debuggers are doing and how they are able to interact with the running executables.


This book is excellent for students and programmers alike. A definite must have for Computer Science students.


Dependencies for hbm2ddl plugin
Mert Caliskan — Sat, 7 Jan 2012 16:06:21 -0500
If you encounter with error,



Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy



while executing hbm2ddl of hibernate3-maven-plugin then consider adding hibernate dependency to the plugin definition like,



<plugin>

<groupId>org.codehaus.mojo</groupId>

	<artifactId>hibernate3-maven-plugin</artifactId>

	<version>2.2</version>

	<configuration>

		<components>

			<component>

				<name>hbm2ddl</name>

				<implementation>annotationconfiguration</implementation>

			</component>

		</components>

		<componentProperties>

			<export>true</export>

			<drop>true</drop>

			<create>true</create>

			<update>false</update>

			<jdk5>true</jdk5>

			<propertyfile>target/classes/maven.properties</propertyfile>

		</componentProperties>

	</configuration>

	<executions>

		<execution>

			<phase>process-test-resources</phase>

			<goals>

				<goal>hbm2ddl</goal>

			</goals>

		</execution>

	</executions>

	<dependencies>

		<dependency>

			<groupId>org.hibernate</groupId>

			<artifactId>hibernate-core</artifactId>

			<version>3.6.9.Final</version>

		</dependency>

	</dependencies>

</plugin>





if you want to see the details of the exception just run the maven with -X.



[ERROR] Failed to execute goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl (default) on project X: Execution default of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl (default) on project ebtam-core: Execution default of goal 
org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy

	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)

	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojioExecutor.java:153)

	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)

	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)

	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)

	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)

	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

	at java.lang.reflect.Method.invoke(Method.java:597)

	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)

	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)

	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)

	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

	at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

	at java.lang.reflect.Method.invoke(Method.java:597)

	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy

	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)

	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

	... 25 more

Caused by: java.lang.ArrayStoreException: sun.reflect.annotation.EnumConstantNotPresentExceptionProxy
	at sun.reflect.annotation.AnnotationParser.parseEnumArray(AnnotationParser.java:673)
	at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:462)
	at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
	at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
	at java.lang.reflect.Method.declaredAnnotations(Method.java:693)
	at java.lang.reflect.Method.getAnnotation(Method.java:679)
	at java.lang.reflect.AccessibleObject.isAnnotationPresent(AccessibleObject.java:168)
	at org.hibernate.annotations.common.reflection.java.JavaAnnotationReader.isAnnotationPresent(JavaAnnotationReader.java:27)
	at org.hibernate.annotations.common.reflection.java.JavaXAnnotatedElement.isAnnotationPresent(JavaXAnnotatedElement.java:43)
	at org.hibernate.cfg.AnnotationBinder.mustBeSkipped(AnnotationBinder.java:1111)
	at org.hibernate.cfg.AnnotationBinder.addProperty(AnnotationBinder.java:1091)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1038)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.codehaus.mojo.hibernate3.configuration.AbstractComponentConfiguration.getConfiguration(AbstractComponentConfiguration.java:57)
	at org.codehaus.mojo.hibernate3.exporter.Hbm2DDLExporterMojo.doExecute(Hbm2DDLExporterMojo.java:87)
	at org.codehaus.mojo.hibernate3.HibernateExporterMojo.execute(HibernateExporterMojo.java:152)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	... 26 more
[ERROR]


TypeError: this._arrayOfTopLevelItems is undefined
Hazem Ahmed Saleh — Sat, 7 Jan 2012 13:12:38 -0500
I wrote this tip in my new wordpress blog here:

http://www.technicaladvices.com/2012/01/07/typeerror-this-_arrayoftoplevelitems-is-undefined/


Agile Yorkshire: An Extreme Hour, Tue Jan 10
robert burrell donkin — Sat, 7 Jan 2012 06:14:16 -0500

Grant Crofton and I are preparing an Extreme Hour with a few twists contrasting XP and methods like Scrum. All welcome, and — if you can make — it'd be great to see you for Agile Yorkshire on Tuesday January 10 at Old Broadcasting House, Leeds. Details here.



Adobe Flex+AIR sound just like Firefox
Dominique De Vito — Wed, 4 Jan 2012 10:10:09 -0500

I don't use Flex or AIR, but as an architect,
I have finally got how to position Flex+AIR
as rich client platform.
Well, I think I have found 
a good comparison for Flex+AIR (that is, 
the progamming model and its associated platform)
in order to 
get a grasp of its features.
This comparison involves Flex+AIR and Firefox.


Let's compare Flex+AIR and Firefox in order to show they are very close:


- Both platforms include an HTML component, as Firefox is a browser itself,
while 
AIR embeds WebKit
(learn 
here
how to extend the Flex+AIR HTML component for creating your own web browser).


- They understand and leverage both web (HTML/CSS/JavaScript) technologies

 
- Both platforms extend web technologies and offer then to develop rich clients:
the Flex programming model is based on
MXML
and 
ActionScript,
while
the 
Firefox programming model relies on
XUL
and 
JavaScript.
They both target
an XML-based  definition of GUI, and 
a dialect of the
ECMAScript
language
(which is the base of ActionScript or JavaScript).
The runtime associated with Flex is AIR, while the one 
associated with XUL/JS could be Firefox (AFAIK) or part of it
(XULRunner).


- They are all expected to be open source or open sourced



So, my idea
is that a valuable mind model
is, at first sight (!), to think about Flex+AIR as a Firefox sibling.




May the Flex+AIR future rely on providing a "corporate browser" ?



While Flex+AIR and Firefox are siblings
and share quite a lot of similar features,
they are identified as coming from different
horizons: Flex+AIR are associated with
rich client development, while Firefox is 
known, first, as a web browser.
While Flex+AIR look like at a tipping point
for its future (as Flex is now incubated in Apache community),
I just wonder if it would be valuable to market AIR both as a browser and for rich client programming, 
just like Firefox.
Well, 
IE 6 showed us 
there is a place for a "corporate browser", used for 
intranet applications,
and 
while 
Firefox ESR
(Extended Support Release)
is still not available, it looks like 
marketing also AIR as a browser may be an interesting move.



Jeff Sutherland: Are Agile Teams Truly Agile?
Sebastian Kübeck — Wed, 4 Jan 2012 08:04:46 -0500

Michael Floyd's interview with Jeff Sutherland from the Agile 2011 is now online.





Robert Martin: Architecture the Lost Years
Sebastian Kübeck — Tue, 3 Jan 2012 10:01:27 -0500
Robert Martin's Keynote at the Ruby Midwest 2011 is now online...



And here is Jeremy McAnally's review Bad (or, my unfortunately unfavorable review of Bob Martin’s Ruby Midwest keynote) which is, as Robert Martin pointed out correctly, longer than the original post.


Update: Robert Martin added some Comments to the blog post. Unfortunately, Firefox fails to render them.