Jilles van Gurp - Latest Comments

Re: simple note encrypt/decrypt with AES in javascript

Beatagray10 — Wed, 02 May 2012 15:44:22 -0000

Have you found the issue of why it doesn't work with IE7? I can tell that it works with Firefox just fine

Re: Generic event code

TashiaMBurton — Sun, 15 Apr 2012 22:09:38 -0000

This is a great solution to the Java problem.

Re: Lumia 800

Jilles van Gurp — Fri, 30 Mar 2012 14:26:10 -0000

It's 20:22, the next day and I'm down to 15%. So I got a good solid two working days out of this. During that two working days I did about 45 minutes of internet radio listening (my morning routine of half consciously absorbing bbc world); I installed creative studio and played with it for about 30 minutes, I had email syncing on to gmail and outlook as well as the MS weather app updating it self, I did some email reading during the day, a few minutes of browsing, and I installed the firmware referred above yesterday morning. Technically it was on the usb cable charging while I did the update and it came out 96% full of juice around 10am yesterday morning after about 20 minutes on the cable. Not bad. It's way past the moment where it would normally have died before I applied the latest firmware, which in my experience would have been somewhere during last night, and will probably last me until I plug it in around bed time (around midnight usually).

I'm impressed.

Re: maven: good ideas gone wrong

Pasanivea — Tue, 27 Mar 2012 03:26:53 -0000

Great! Thanks for sharing...MAVEN IS CRAP! :)

Re: maven: good ideas gone wrong

Mavenhater — Thu, 22 Mar 2012 20:28:45 -0000

The maven (and JPA - but that is another blog matter) fans are all slaves to marketing. A project comprehension tool? How does a directory structure and a huge xml file make me comprehend a project? All maven ever did to me was to make me confused. Why is the build failing when it built OK the last time (and I haven't changed anything)? And why does it take 15 minutes to run (ant takes 3.5). Use maven at your own peril.

Re: log4j, maven, surefire, jetty and how to make it work

Richard — Sun, 11 Mar 2012 10:18:14 -0000

The title mentions a servlet container and other maven plugins which you only briefly mention in your article. It would be better to remove these keywords from the title otherwise more people will be redirected to your article when looking for such things.

Re: maven: good ideas gone wrong

Jimmy14 — Tue, 06 Mar 2012 19:05:01 -0000

I tried to tell the clowns where I work that maven is breaking Eclipse's incremental compiler, but no one seemed to care.
The kinds of people who really, really hate maven are the power users. These are incidentally the same people who have to debug the system when maven screws it up (not the incompetent fanboys who were pushing the crap in the first place).

Re: maven: good ideas gone wrong

Matt — Sun, 19 Feb 2012 11:52:01 -0000

Totally agree with you. It has been retro fitted to a legacy app where I am. This is unbelievablely bad!!!

Re: OpenID 2.0

Guest — Thu, 05 Jan 2012 13:50:48 -0000

where to test openid

Re: maven: good ideas gone wrong

adam — Thu, 29 Dec 2011 16:48:40 -0000

I typed in 'maven is shitty'. You're on the second place in the ranking, the first is some mvn plugin named 'shitty' :D.

Thanks a lot for that blog, which I can read while putting togather my mobicents project :D.

Re: On Java, Json, and complexity

Jilles van Gurp — Thu, 29 Dec 2011 14:36:05 -0000

Sure, it is not black and white. In python an object is just another dictionary, which means json is a quite natural mapping for whatever python object you want. Jackson indeed supports three ways of interacting with json and it does lists and maps even; if you ask it nicely.

The main issue with throwing pojos at any problem in Java is that you end up with a lot of convoluted, poorly evolvable object structures. I've seen a lot of bad application design and indeed database design that basically resulted from poorly thought through abstractions, needless layers of indirection, etc.

Re: On Java, Json, and complexity

TatuSaloranta — Wed, 28 Dec 2011 20:23:06 -0000

Perhaps it would be more accurate to say that many Java JSON libraries omit one of multiple useful ways of dealing with JSON. Jackson (http://jackson.codehaus.org) supports all 3 canonical modes (including Maps/Lists approach), and does not require setters/getters (can use fields too, as well as constructor arguments).

I disagree in that POJOs are bad, but it sounds like you consider POJO == Bean; if so, I agree in that it's clumsy to always require getter+setter. I actually pref plain struct approach when transferring data: and I think it can be much better approach than Maps/trees. But there are cases where latter approach makes more sense -- and libs can support multiple modes quite easily. Why some don't ... laziness? Lack of thinking things through? Forcing personal prefs on others? Who knows...

Re: Scrum: Agile madness

Jilles van Gurp — Mon, 19 Dec 2011 14:03:10 -0000

I'm well aware of the disclaimers that scrum comes with. The point is, most people implementing and selling it seem to conveniently overlook those. So, yes: technically you can't blame scrum. But I do blame the hordes of overpriced consultants for doing an awful job of selling and implementing it across our industry. I don't blame the tool: I blame the people using it as the proverbial hammer for wacking every nail in sight.

As stated above, observing success in isolated cases proves nothing whatsoever. I'm sure that if you do some honest reflection, you can come up with a couple of failures as well. And you probably learned from those failures. That's called experience and my central claim above is that experience trumps process.

If you need more evidence: make a list of the most important software in your daily life (developer tooling, OS, embedded software in your microwave, etc.). Now filter that list by those doing scrum properly. QED: you can deliver good software without scrum. In fact, that's how most software gets written.

Re: Scrum: Agile madness

Jilles van Gurp — Mon, 19 Dec 2011 13:47:07 -0000

Scrum is being pitched as a silver bullet on a massive scale in our industry and the industry seems to be blindly in love with it now. My point here is that the way the industry is blindly applying scrum everywhere is a form of madness that is very harmful.

I know the theory and I have seen the practice. They don't line up and there is very little acknowledgement of the cold hard empirical facts here of scrum in practice. Now the standard fanboy answer to any criticism is "you're not doing it properly". Well sorry, but I'm calling that out as bull shit. There seems to be a whole lot "not doing it properly" going on in the industry and I have seen 0 credible empirical evidence of people doing it properly doing any good either. It seems the success is always somewhere else. I've seen plenty of over priced consultants making good money out of selling this snake oil but preciously little success for it.

Having seen how credible empirical evidence is supposed to look before: the average scrum sales pitch aint it. Not even close. I've read the research papers and they are excellent studies of very specific situations that only a fool would extrapolate as generally applicable. You will find no such claim in those papers BTW: it would have blocked publication since you can't have baseless claims in a serious publication. People confusing sales pitch with evidence is a big part of the problem. You certainly seem to have bought into it. You being on a successful project proves exactly nothing. It only proves you have completed a project successfully. Probably the skills of the people around you were a massive factor in that success.

Now I've been in the industry long enough to see silver bullets come and go. Scrum is past its prime in that sense and I fully expect people to move on very soon. Consultants have cashed their money and they need new snake oil to sell very soon. Every silly consulting shop is doing scrum these days (or claiming to) and last time I checked the number of failing IT projects continues to be depressingly high. Scrum or no scrum.

Re: Scrum: Agile madness

Guest — Mon, 19 Dec 2011 12:33:11 -0000

I agree with Thilo in as far as Scrum *is* just a process, not a magical problem solver. My understanding of Scrum's basic promise is : it unearths problems, but doesn't deal with them. The people in the team are the problem solvers at the end of the day. Strong technical people, and managers (allbeit in whatever guise that takes in the world of Agile) are still a must have, as is accountability.

Relying on Scrum by itself, in the hope it will solve problems, clearly is not going to deliver anything bar colourful boards showing nothing is "done". Yes, implemented incorrectly (I choose that word on purpose), it can even provide a cover for mediocrity. How often have we heard the phrase "...but thats not Agile!" get uttered by people trying to deflect or else just hide from the truth of the matter?

I've seen Scrum deliver on the promise mentioned at the start of my comment however - and teams happily and repeatedly deliver real business value. Maybe I've just been lucky, yes, but I think luck wasn't such a big factor in these cases - people got into the right mindset and observed the spirit of the approach. The point about it being used as a cure-all for dysfunctional dev orgs being the road to disaster is completely valid, but labelling Scrum "madness" is a bit blinkered, in my humble opinion.

Re: Scrum: Agile madness

Thilo Fromm — Mon, 19 Dec 2011 04:44:14 -0000

You are being hypocritical.

On the one hand you are accusing your managers of seeking salvation in The Process without tinkering with the actual problems. On the other hand you are expecting salvation by The Process without tinkering with the actual problems yourself.

SCRUM is a tool which provides swift feedback on how you are doing, not unlike your compiler gives feedback about syntactical mistakes in your code, or your unit tests provide information about semantic mistakes, or your continuous integration / continuous deployment points you to integration issues.

SCRUM is a huge help when it comes to identifying procedural problems, deficiencies, work overload, or the like. Of course you have to make use of that feedback. You've got to deal with the problems yourself. Your annoying little rant however does suggest a process (specifically SCRUM) should actually fix things for you.

Re: On Java, Json, and complexity

Jilles van Gurp — Sun, 06 Nov 2011 08:04:39 -0000

DOM is an insanely clumsy data structure, so I don't think the comparison is entirely fair here. The problem with XML in Java specifically is that people seem to end up with a lot more code to maintain than the average javascript, python or ruby programmer has to deal with when working with json structures. You have to have model classes, mappings to those model classes. Of course what you store is different than what you receive via the API so you have model classes specific for both and mappings between them. I've seen people do this with hibernate and jaxb. To me this looks needlessly complicated. Most data is actually pretty simple and doesn't really justify having a lot of complexity. I like simple and having data go through several layers of indirection is not simple.

Pojo's are only convenient because there is nothing better in Java. The language is actually kind of clumsy when it comes to pojos. A lot of frameworks depend on having a lot of silly getters and setters. Java has a lot of complex workarounds for its flaws. People have been so preoccupied with those workarounds that they consider them the right way of doing things.

There are lots of json frameworks for Java but few of them can be bothered to implement List or Map on their lists and dictionaries in their parse trees. Why is that? I call that a major design smell. It doesn't even seem to occur to people that using a Map interface on a json dictionary is sort of an accurate way to represent such a thing in the Java world.

Re: On Java, Json, and complexity

TatuSaloranta — Fri, 04 Nov 2011 22:33:00 -0000

Uh. This is way to long of a rant, and I am not even sure I fully understand your grievances (tl;dnr).
However it seems that you claim that the best way to process JSON in all cases would be using JSON-specific data structures.

If you had just said that you find this the most convenient way I would have no objections. But the blanket statement that it is the only sensible way is something I fully disagree with.

JSON is mostly used as a data transfer format, but what you use for handling data is the programming language (like Java). And so representation you use for processing data should be optimal from language perspective. And for statically + strongly typed language like Java, most often this is by using simple OO abstractions. And your POJOs can be as simple or complex as necessary -- all you need at minimum is set of public fields; or an interface with accessors (many libs can generate implementations). So claiming that one should use JSON-centric approach of modelling JSON as alien data seems at best odd.

Now: there are cases where I could consider use of JSON-centric abstractions appropriate: if data is very loosely or inconsistently structured, loose typing and node-based approach makes sense. But conversely if data is regularly structured, it is much more convenient to access using POJO abstraction.

Good Java JSON libraries, then, allow one to choose proper abstraction(s) and convert between them as necessary.

After all, if use of data format specific abstraction was such a superior way to go, all XML handling would be done using DOM. And it clearly is not; rather, data-binding solutions (JAXB, XStream) are preferred methods, along with domain-specific languages (XPath, XSLT).

Re: Maps on Ovi

Frank — Wed, 26 Oct 2011 03:02:26 -0000

Could somebody give me a big and better picture of the OVI
maps because I definitely don't want to diss it without giving a shrewd
verdict? I don't want to close my doors of opportunity just because it couldn't
recognize anything or even close to that!

Re: xdocdiff

Rashmi Shricharan — Mon, 10 Oct 2011 07:08:17 -0000

Hi,

I am able to install xdocdiff, but further dont know how to use it. Can you please guide me

Re: On Java, Json, and complexity

Richard Stanford — Mon, 15 Aug 2011 10:08:20 -0000

Agreed. The real shame is - now that almost everyone uses a JSON parser, even in the browser/JS world - that there is no defined Date literal in JSON. Not having an Interval literal is occasionally annoying, but people actually use dates all the time, and converting them to/from a String representation isn't something that any of the parsers (that I know of) do automatically.

I guess you could regex every string as it comes in and if it meets the full unambiguous ISO format move it into a native Date, but as long as not everybody does that, things will still be odd.

Thanks for the comments - just hoping someone had already truly solved this problem somewhere :)

Re: On Java, Json, and complexity

Jilles van Gurp — Sat, 13 Aug 2011 03:53:42 -0000

There are basically two things you can optimize for: size or readability/understandability. If size is the constraint, go for time in millis. Otherwise go for one of the standard options. I tend to use iso with UTC as the timezone. It seems to be the common solution and it is well understood.

The problem with the standards is that they still give you too much freedom. I once tried to implement a parser for date time objects embedded in hcal objects in web pages. The problem there is that the hcal microformat simply states that you should use iso dates and times. So you can encounter anything from yyyy-mm-dd to yyyyMMddTHHmmZ or yyyyMMdd HHmmss, etc. there's an enormous variation of valid formats under iso and having a parser that can handle them all without it being clear upfront which is used is a major issue.

So I tend to go for a form of of iso 8601 that doesn't have much ambiguity, which is yyyy-MM-dd HH:dd:ssZ. I generally don't include milliseconds

Btw, there's nothing json specific about this; this is just as bad in the xml world.

Re: On Java, Json, and complexity

Richard Stanford — Fri, 12 Aug 2011 17:48:58 -0000

One question about this. What do you do with Dates? That's been the single biggest frustration I've had in moving to a more JSON-oriented world. Sure, there are lots of ways to handle it (use UNIX ms-based values, use ISO "char" dates, etc) but they're all, quite frankly, the kind of must-agree-on-everything-first-crap that JSON-based systems seem so good at otherwise avoiding!

Honestly curious, and I'd value your thoughts.

Re: Publications

Scottkohn2008 — Wed, 27 Jul 2011 04:55:56 -0000

I need these journal papers and they will help me to a very good extent.

Re: New PC & moving itunes library

ToKo — Sun, 17 Jul 2011 00:41:42 -0000

Thanks so much for this useful post! I tried to migrate my library from Windows zu Mac for hours and it didn't work - your tool explained exactly how to do it!
Thank you!