Monday, February 11, 2013

Annotations - Yet Another "Solution" For A Solved Problem

I just don't get annotations. I mean, I know what they are for and how to use them, I just don't get why I'd want to. They are just another in a long trend in Java (and programming in general) to come up with a new and worse way to solve a problem that already has better solutions.

How did we do what annotations do before annotations? We used configuration files. And that was a Good Thing, because it separated changeable configuration data away from our source code. Yet annotations do exactly the opposite, and put this same information directly in our source code. And coders seem to like this for some inexplicable reason. You know what they say about those who don't know history and all.

But annotations are just one example of this phenomena. The entire design philosophy behind JPA is backwards to me. In the beginning, we had data and we had functions - they were separate. Then some enterprising coders decided that Object Oriented was better, and we should combine data with functions - and that makes sense to me; to keep the data with the functions that manipulate it. And then JPA comes along - and before it DAO - and it was decided that when it comes to database data, we really ought to keep the data separate from the functions that manipulate it - again. But, we'll still say it is object oriented code. You know, because we have classes and stuff.

Don't get me wrong - I use JPA and DAO quite happily in lots of smaller projects because they can save lots of development time. Just don't confuse them with true Object Oriented design, because they aren't. They are Data Oriented © ® design. Hey - I just "invented" something!




Tuesday, February 5, 2013

PayPal IPN

Lately I've been working on a site for my daughter's music and photography. She composes the most amazing (yeah, yeah, I'm her dad - but it is good stuff!) music, but she was mostly just messing around. I liked it so much I wanted her to finish an entire album of the sort of compositions I like to listen to when I work. I listen to a lot of Andreas Vollenweider, Enya, Allen Parsons, Tangerine Dream - stuff like that is great to code to. So I commissioned her to finish an album of at least 40 minutes in length of that type of music - I call it easy-listening techno.

I'm really happy with the results, and she wanted to raise some money for some of her interests so I did a site for her to sell her songs and the album I commissioned ("Perspectives"). She also is an avid photographer, and she loves to take photos as the Henry Doorly Zoo - so we added those to the site for sale as well (only $1.29 royalty-free, so hurry now before the internet runs out of bandwidth stock!).

To support the sales via PayPal, I thought about writing a library I could reuse in other projects. But then I had a better idea: Just put that code into an webapp that only processes PayPal IPNs, and have a convention so that the parms I send in to PayPal from a webapp can be picked up by this process during the IPN cycle and route requests to the originating webapp for fulfillment if required. It's really generic and I'm already using it on another site I'm doing for my sister-in-law.

The basic process is this: I use the "item_number" to hold the resource URI, and the "custom" field to hold the site domain/webapp that is originating the purchase. These resource URIs don't point to the real resource to discourage simple piracy, but the IPN webapp turns them into an email with the encoded real URI to send to the purchaser. Clicking the link is handled by a servlet in the IPN webapp that decodes the URI, and then streams the purchased content back to the user's browser. Even this URI is not accessible directly by the browser, and all the user can see in the emailed link is the encoded form. This prevents the user from trying different parms in that link to attempt downloading other content (like the names of other tracks that can be seen on the web page).

Works great, AND it's less filling - what more could you ask for?

An early Valentine for my beloved JSPs

JSPs have had a bad rap for the past several years. JSF wants to replace them, but please - anything you can do in a JSF page I can do in a JSP. Anything I can do in a JSP you cannot do in a JSF page. And with the right code organization, I don't need Expression Language (EL) either, thank you very much.

So why no love for JSPs any more? I think that, along with a lot of other trends in Java programming, coders are getting lazier and stupider - yes, I said stupider. Go ahead and bloat your WAR file to 100 mB with all those frameworks for your latest "Hello World!" webapp because you're afraid to write core java + JSP. I'll develop mine faster and in 100 kB instead.

I swear it's like the latest generation of coders doesn't really understand core java any more. I was helping a colleague debug some code recently and his complete lack of understanding of how to make some code thread-safe and reentrant was truly mind boggling. And he has 5 years of Java experience since getting his college degree in computer science.

"JSPs are soooo yesteryear" I hear them groan. And from the same coders that love to reinvent the wheel in ways that are truly breathtaking. Not to beat the dead horse of JSF, but that's a mighty big framework to re-solve a problem I can do in well under 1000 lines of my own framework code.

And when it comes to HTML-only pages instead of JSPs, go ahead and create some Java POJOs to wrap with some GSON to send to an HTML/JS-only client. Meanwhile I'll generate javascript right in a JSP from the Java beans I already have. You think that makes my code hard to read? Try Perl sometime. This ain't nuttin but a lil bit o' java code.

Don't get me wrong - HTML5 + javascript is great. But HTML5 + javascript + JSP is even more powerful and more efficient as well. But maybe I'm just too old; been around the programming block a few too many times and long for the olden days. Or maybe the founding fathers of Java had it right all along when they wanted to design a language that was simple, powerful, accessible, and not bloated. They stewards of Java have moved away from that over the years. The original JDK download was a fraction the size of just JSF - and that speaks to me.

So to all you gen-X Y Z whatever of coders I only ask that you stop disrespecting JSPs. Oh - and get off my code-lawn.

Book learnin'

It frustrates me to no end when a coder likes to quote chapter and verse of the latest bible for programming pattern methodology oh whatever. Books are nothing more than academic guides. The real world is too different and too messy for any solution to fit properly. So throw out the book learnin', and start with the real-world learnin' - and that is only done by doing. Don't use a 100 mB framework just because you're not sure how to write 100 lines of code to do it yourself. Learn how. Google is your friend.