Tuesday, August 6, 2013

Seriously [insert name of online photo site here], seriously?

So my brother is on vacation and sent me a link to some trip photos on his SmugMug site. I'd never heard of that site, and was quite impressed. Since I've always hosted my photos on my own custom site, I signed up for their free trial to check it out.

And then when the site couldn't handle a particular feature I'm working to add on my own site that I have to have (I'll tell you what that is in a bit), I went to Flickr. Then I went to Google+. Then Photobucket. Then ShutterFly. Then PictureTrail. This was quickly turning into a rabbit hole I lost interest in going down.

The feature I can't live without? I have tagged about 20,000 photos in my Aperture library with family and friends. I just want an online album that can handle that.

But Flickr does handle that, you say. Well, not really. I uploaded 200 samples to Flickr, then did a search. Nothing. So then I went to Tags, and there were all my people tags. So I clicked on one, and there were the photos with search box populated with the people tag. So I click in the search box - which already had the pre-populated tag from before, hit enter and it told me there were no matches. Huh?

But Google+ does that, you say. Well yes, if everyone in your family that you want to see and search the photos has a Google+ account - or the entire world if you want it all to be public. No thanks.

The story seems to be the same everywhere I looked. Why is this software so hard?

It isn't. I'm almost done with my own. A simple file scan from a servlet upload handler for the jpg people tags from Aperture, fed through Lucene for search, Bob's your uncle, Fanny's your aunt and your done. It just ain't that hard. And these companies are HUGE and they can't do this right? Please.

Tuesday, June 25, 2013

So there I was wanting to develop on my Chromebook...

I have a new project I'm working on, and since I've switched to my Chromebook I was wondering if there was a way to do Java web development using it. My fallback plan is always to use Chrome Remote Desktop to connect to my iMac and just do normal development there. Enter Codenvy, stage left.

Codenvy is a cloud-based development IDE that can publish to a number of cloud-based platforms such as Google App Engine - the one I was interested in using for this new project. Seems like a perfect fit, and in some ways it is, some ways it isn't. Codenvy is really easy to start using and get connected to your Google App Engine account, so that was very slick. The deeper I got, however, the more shortcomings I encountered. For one, while the Codenvy IDE looks a lot like Eclipse, it just isn't - not yet, anyway. No control-click to go to a method is a huge disappointment. The auto-complete is mostly there, but only when you do things the way Codenvy wants. For example, if I have a CSS file, then auto-complete for CSS works well. But if you're editing a JSP with inline CSS or CSS in the HEAD, you're out of luck. I've also had a few occurrences of a file I edited and saved not getting updated on the remote end. I would go to test, realize that the change wasn't there, close the file in the IDE and reopen it, and sure enough the saved changes were gone. Ugh.

Still, it's a very interesting piece of work. It might not be ready for every developer yet, but for anyone like me that has totally fallen in love with their Chromebook and wants to develop within its limitation, Codenvy is some very slick software.

Wednesday, June 5, 2013

My shiny (ok, Matte) new Chromebook

Well after much deliberation, I finally bought a Samsung Series 3 Chromebook. Not only that, and you should be seated for this part, it's my primary laptop now. Stop laughing, I'm serious! In all fairness, my old 2009 MacBook has been a bit twitchy lately, so I needed a replacement anyway. I thought about getting a new MacBook, but I knew I'd rather have a new iMac instead - much faster and more spacious for movie editing etc. So the Chromebook really fits my needs - and budget, no way I'd buy an iMac and a MacBook!

I really like this Chromebook. I've moved all my most common tasks to the cloud (Google Drive w/Docs, LucidChart, etc) and there isn't much I can't do on it. Development and heavy-duty movie/photo processing is still on a "real" computer, but even development can be done in the cloud now (Codenvy), it's crazy.

And while I know my Chromebook is slower than my MacBook, it doesn't feel slower. It actually feels faster - it only does one thing, and the entire system is tuned to that task, making it feel very snappy. Yes, I said "snappy" - deal with it.

My only gripes:

  • All ports (except headphone) are on the back. That can be a little annoying, although that's where most cables naturally want to be so it's only a minor peeve.
  • The unit closes really tightly - it's definitely a two-handed operation to open it up because it is so light!
  • No Cisco IPSEC support, which is what my work VPN requires.
  • Memory not expandable - comes with 2 GB which works quite well, but I'm sure 4 would be better!
Overall, I am really in love with the Samsung Series 3 Chromebook - highly recommended!

Sunday, March 3, 2013

jOOQ: Missed it by that much

I've been using JPA at work, and also on my home projects. I loathe it at work, but the databases I use in home projects are pretty simple - and JPA does simple pretty well, just not complicated schemas. Still, I hate the internal complexity of JPA, the memory footprint, and the library size.

Enter jOOQ, stage left. I loved the stuff I read on their home page:

  • SQL was never meant to be abstracted. To be confined in the narrow boundaries of heavy mappers, hiding the beauty and simplicity of relational data.
  • SQL was never meant to be object-oriented. SQL was never meant to be anything other than... SQL!
I also loved their tag line:

jOOQ: A peace treaty between SQL and Java

So, I started converting my home-grown CMS (Content Management System) from JPA to jOOQ and got very excited. jOOQ was simpler than JPA, smaller than JPA, and more efficient than JPA. I'm almost done with my conversion and absolutely love what I can do with jOOQ. So I spent the last week seeing if I could convert the very simple dynamic SQL builder framework I had written into jOOQ.

I had to start with some work to add iSeries DB2 support to jOOQ, which it lacked, but that only took a day so I was off and running. At first, there was the honeymoon period and I was really loving how the conversion was going. Then in testing I got into some issues - not unexpected. I couldn't control the scroll type or concurrency for the prepared statements via the jOOQ API, but no problem - I just added them. But then the @$%# hit the fan. Some of the application code that was using my SQL builder framework generated some pretty complicated where clauses. And despite spending about 2 days trying coax jOOQ into generating the same or equivalent conjunctives, I couldn't make it work. I tried modifying jOOQ to do what I wanted, but it quickly became apparent that was a rabbit hole I didn't have time to go down. So, I've abandoned that effort.

Still, for my home projects where life is simpler, I really love using jOOQ, and am really happy I discovered it and am using it. But for work, in the words of Maxwell Smart: "Missed it by that much"!

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.