NOT DEAD

I just noticed that it has been 2 years since I posted anything. Ha!

Spring Criticism, part 2

Ok, I am back with a funky track.

First off, this is not a rant, or a complaint. I just recently hit some functionality within the Spring OSGI container which seems poorly designed, and I wanted to share the love.

So, OSGI is all the rage these days, supposedly. Or so it seems on various marketoblogs disguised as blogs. After a lot of hatin' on/at those blogs, I finally got around to checking it out. Imagine my surprise! OSGI is actually really goddamned awesome. Bundles, dependencies, dynamically bringing them up and down, eeehhh, not so much, but bundles and dependencies! Yayyy. I'm happy.

Enter Spring, with their "I gonna configure your world so hard, you're not gonna know how I configure your world so hard" mentality. After a tiny learning curve, I was happily writing Spring configuration XML files, lusting after the functionality that lay hidden behind various goodies such as spring-osgi-web and spring-osgi-web-extender. I have some experience with the Servlet spec, and it all made sense.

What I wanted to do was deploy a war in an already existing OSGI container, as a bundle. Well, that sounds pretty simple, right? You throw together the webapp, required libraries follow the Servlet spec and reside in the warfile's ${home}/WEB-INF/lib. Throw it in the osgi startup and you're done!

java.lang.ClassNotFoundException

O_o. No! This cannot be! I did everything riiiiiight. Wait a second... The docs say you have to add the jars required by your webapp to the MANIFEST.MF file within ${home}/META-INF. Of course, how could I be so stupid, this is OSGI. Duh!

Or is it a "Duh?" This specifically allows for war files that break the Servlet spec to actually work within an OSGI container's Spring-powered web bundles. Not only can jars be outside of WEB-INF/lib, classes don't have to be within WEB-INF/classes. This is where things kinda get weird. Why would Spring folks (now VMWare, blah blah) want to do this? Why not spend a little extra effort and scan the war file as a J2EE-compliant server would, and make our lives even easier by automatically including the jar files found within to our bundle's classpath?

I don't know. Perhaps they ran out of time. Perhaps no one is using their DM server tech and this has not come up. I do know that this does not quite fit in with their philosophy of "non-invasive configuration." It effectively breaks the Servlet spec.

I am all for that don't get me wrong, technology has to move forward. But why this sudden break with backwards compatibility?

For conspiracy theorists, the other possibility is that Spring is attempting to become the dominant Java enterprise tech puddle that we, the Spring semi-programmers (now with 110% more configuration skills) lurk in.

My two cents? I like the mud here. But I'll be damned if I don't call it out for being mud.

Damn, Overgrowth

Sup y'all.

I've been away for a bit due to an interesting business trip. Luckily it's now over. I'm not going to name any names, but don't ever go to Monaco expecting Monaco Telecom to provide internet faster than a 56k speeds. Sure, it is citywide wireless... but it is SO SLOW. If anyone ever wants to study the effects of monopoly on the quality of service that telecoms provide, go to Monaco and try to download anything. I got burned, badly.

But the main topic of my post! It is just a link. If you are not yet aware of what these folks are doing, you really ought to check it out. It's the future.

Bwahahahahaha

This made me laugh so hard. I love this man!

http://java.dzone.com/articles/secret-architects-cabal#comment-23121

Cygwin 1.7 Installation Problem

So, I was hangin' out at work today. And I decided I wanted to have a C/C++ environment up and running, because it looks like I have some C++ development ahead of me soon.

I downloaded and installed the Netbeans 6.8 C++ environment, in the desire to try something new. It expects either Cygwin or MinGW and is pretty well integrated with Cygwin. So I created my little test project, and tried to compile my main.cpp file, which compiled but on the linking stage, OH GOD THE PAIN.

Yes, friends, pain. See, I had not installed the liblstdc++.a file yet. Well, no problem, I will just run the setup.exe and grab them right? Sort of. Since the version is now 1.7 there is a very fun, evil popup that says

Download incomplete. Try again?

The solution is to hit "yes." This brings you back to the mirror server select screen but the key is, your already downloaded archive files are SAFE AND SOUND. There seems to be some sort of bug with the setup.exe file, but if you keep hitting yes and choosing the same exact mirror server, and then just hitting next on the feature select screen, all is well. The setup will only download the files it has not yet grabbed. As a further note, I had to purge my system of any previous Cygwin files and registry entries in order for the install to work.

Neat Way of Looking at Patterns

Haven't really finished understanding this entry. But it seems real good!

SPAMSPAMSPAMSPAMSPAM

http://www.ibm.com/developerworks/java/library/j-eaed9/index.html


Aaaah, spam complete.

JSR 317

So, JSR 317.

Very cool, very awesome JSR. What's cool about it? Well you see, it makes a Java standard of a technology I am already intimately familiar with! So it's really really great!!!

Ok, I was being sarcastic. Whether or not ORM is a Good Idea™ is still not completely settled in my mind. There is a relatively large amount of overhead, within the knowledge that programmers must have AND efficiency. Also, everyone is doing it.

The good news is that the overhead is partially addressed with the new stuff in JPA 2.0, specifically the Criteria API. This API goes a long way to completely replace the Database with Objects in the mind of the Java enterprise programmer, leaving a scarred wasteland of smoking JDBC bodies and tormented souls of DBAs. In intervals divisible by 2 those souls cry out with words that chill the very spine of those who hear them. Words like "normalization," "query efficiency" and "this is not a search engine."

Well to be fair those last two were phrases.

Oh well. Anyway, I am looking forward to Nov 16th, when the JSR is supposed to hit the streets. I mark the date with a shot of rakia, a toast to the people that told me I must take Relational Databases in college, or else risk not being ever hired as a programmer.

I'm back

After relocating to a certain Eastern European Country of questionable repute, I am back to pollute the internet with my worthless blog.

Oh dear.

It seems that this post is a precondition of the significance of the hypothesis that there are humanly inaccessible blogs. http://www.martinfowler.com/eaaDev/uiArchs.html

Aw damn, son

Very cool video.

STFU and go away

Advice on how to start a new business, pt. 1

Do not tell people you can "prove aliens."

The Sims is Evil

Don't play it.

DAOs ... not... dead? <shotgun blast>

Recently, some guy wrote a whole lot of blog entries about J2EE design patterns he and his team came up with.

As a whole the entries are very nice, packed with info and so on. One particular blog entry struck a cord with me and I wanted to discuss it. It is the DAO object entry.

The beginning of that post immediately addresses the actual need for DAOs in an architecture, by referring to another blog post. The conclusion is that "it depends." If your application is complex, you should use DAOs, as they provide a thin layer on top of JPA and its Entity Manager. In this post I argue that encapsulating the EntityManager functionality is not a job for the DAO layer, and that it in fact needs to be rethought, and eventually absorbed by the Service Facade layer.

There are two concerns that are addressed by the DAO pattern. One is actual persistence, and the other is a logical layer within the architecture of the application. As with all design elements there is a downward concern, as well as an upward concern. The downward concern is the persistence. How will we store the data? The upward concern is the way this pattern will fit into our architecture.

I am not going to use the straw man "there are too many layers" argument which dismisses this debate. The job of the layers is to make an application extensible to future business needs, and goes hand in hand with the SOA concept that businesses usually salivate over. So, let us assume either a medium size application or an application that will see rapid growth in functionality in the near future.

I will discuss the downward concern first. DAOs provide an abstraction of the specifics of persistence. DAOs need to map object data to database tables and back to objects. The JPA standard provides a specification for doing exactly this. There are many JPA providers, as indicated by Vincent Partington's blog. At the end of the day, most of these competitors will use JDBC to write some data to a database. They will also need to figure out how to map the data from JDBC results sets to Java objects and back. As you can see the JPA Entity Manager takes care of the downward concern completely.

The upward concern is much more interesting. DAOs offer many advantages to the client programmer. One big benefit is type safety. Another, perhaps bigger benefit is the separation of concerns, i.e. the creation of the "DAO layer." Why even have layers? Partington accurately portrays the flexibility that is gained when a layer is separate within the architecture. Not only can its functionality be changed without affecting the rest of the codebase (he cites logging as an example) but additionally, the functionality contained within can be reused to build out other components which need it, higher in the hierarchy. There are also other, minor benefits such as the conglomeration of all persistence code in one package, and so on. JPA definitely does not address the typesafety concern, and it lacks the cohesiveness to be used as a layer in our hypothetical mid-sized application.

So a DAO-less architecture using JPA seems to be 1 for 2 here. Or is it? Another one of the posts discusses the Service Facade and DTOs. Yet another well thought out entry, it correctly provides the justifications for DTOs (sometimes called Light Beans) and Service Facades. However there is one concern which I want to add, regarding the Service Facade.

One big time sink in real world projects is communication between developers and business analysts. Even intelligent, motivated and hardworking coworkers have a hard time getting the details knocked out when apps are developed. One of the core challenges they face is language. As human beings we cannot help but use overloaded words and phrases that mean something to us, but not quite the same thing to someone else. A UserEntity might mean something to a developer, but it might mean something completely different to a business analyst. The chief virtue of Object Oriented design is our ability to model code on real world problems and their solutions. Therefore it is my claim that service facade objects and their methods must be identified as business objects and verbs by the business analyst first, and then created verbatim by the architect of the application in the Service Facade layer.

Business logic has no place in the persistence layer. Methods called things like "findExecutingChangePlans" should not be present there at all. Unfortuantely, the old DAO pattern, as presented by Partington, does wed those two concerns: the upward and the downward.

The service facade classes implement two interfaces, the proposed IDataAccess<K,V> and also a particular IBusinessInterface. They do this by extending a AbstractBaseDataAccess<K,V> class, which implements all of the "workhorse" methods as proposed by Partington. But they also implement the various "business verbs" created within the IBusinessInterface. Essentially, the DAO pattern no longer exists, while its two functions are still put to work, separated by the advance of technology.

My proposed solution does not eliminate the layers, it merely lets the appropriate components take care of the previously combined functionality: JPA handles persistence (and only persistence) while the Service Facades handle business logic on a more pure level that old-school DAOs. The new solution still brings all of the benefits listed by Partington as part of the DAO pattern:

• No direct dependency on the JPA api from client code.
• Type-safety through the use of generics.
• One logical place to group all entity-specific JPA code.
• One location to add transaction markers, debugging, profiling. This feature is improved, due to the removal of the DAO layer.
• One class to test when testing the database access code.

As well as the benefits listed under the Service Facade pattern:

• Service Facades map DTOs to domain objects and back.
• Service Facades function as the transaction boundary of your application.
• The Service Facade pattern forces you to think about the interface of your application.

The DAO layer does not disappear, its functionality is divided between the Service Facade layer and the JPA provider.

Game Review: Crystal Clear for the iPhone/iPod Touch

I used to be a video games journalist for a short time. I brought a unique sense of laziness and ennui to a branch of journalism uniquely identified with the word "granola."

I now return, in force.

Crystal Clear is a game available through the App store to Apple whores customers. Billed as an "action game with light puzzle elements" it is very easy to pick up and start playing. Gameplay is very fresh, and quite unique. I really have no way of describing the gameplay in terms of a previous game, which is saying a lot. The best I can do is "Bejewelled family." Basically, you swipe or use multi touch to remove as many same colored "crystals" (not jewels!) from the board. The empty spaces are then filled from the top. You need to hit a certain score before time runs out, and then you progress to a higher level, which makes the same task more difficult. How does it make it more difficult? By reducing the time you have to reach the score and (presumably) increasing the score you need to advance.

That's all there is to it, but it leads into one of my only gripes with the game, which is there tend to be some hidden elements in the game, a big no-no for me. For example, I can see how much I've scored when I make a move. But the score bar that indicates my progress through a level has no numbers in it. Also, every time you make a move you get a "golden egg" in the upper right hand corner. These eggs actually multiply your score when you make the next move. The multiplier does go down with time, and there are also special jewels which will max out the multiplier at 5x and keep it there for a short duration. Problem is, its almost impossible to see which crystals are sparkly and which arent. Why? Well, your goddamned fat fingers are always in the way. The wonderful mechanics of the game are marred by the limitations of the platform. I obscure my own view of the playfield every time I make a move. WHY APPLE??? WHYyyyYYyyYYYYyy!?

The developer of the game cannot invent a better device, but he sure does push the technology in a direction I had not yet seen. Also, a futher note: the sound effects are excellent. I just regret that there is no music, but as most users will probably opt to play their own in the background anyway, its no big loss.

Graphics: 4/5

Sound: 5/5

Music: N/A

Gameplay: 4/5

Multiplayer: N/A

Overall: 4.3/5

Cyrstal Clear coming out soon!

This is a really neat game that will be available to iPhone and iPod touch users in about two weeks. Check out the video:

http://www.youtube.com/watch?v=YV31lxySnRo

Singleton Pattern Icon

Singleton... or is it a coin? -_-

Command Pattern Icon

This one is definitely tougher than abstract factory, which has a real world representation. For you consideration, I present Command:



















The callback capability and main purpose of the Command pattern should be apparent. Missing are the undo queuing qualities. Oh well :)

Visualization of Design Patterns

Check this out:

So I have this idea. The idea is that some people learn visually, and if they could see design patterns, and associate the visual image with the concept, they would understand them easier.

To that end, I am going to try to iconify the GoF patterns. Here is the first one, Abstract Factory:

Project Natal Scoop!

Due to my past experience as a games journalist, I have been made privy to the following information, exclusive to the Cyclopean Encyclopedia. For your eyes only:

Project Natal Natal

That is not a typo. We have all seen the vociferous press releases, RSS feeds, web videos, etc. of Microsoft's exciting, new, technology: Project Natal. From up on high, people such as P-Middlyx, and James Cameron have declared their support for the project! ... Or is it expressing how much thicker their matresses have been in the past three weeks? Inquiring minds do not really want to know.

But forget all that!! Project Natal Natal comes through and breaks all expectations of future technology. Through the Natal interface, the gamer is presented with an in-game avatar of The Gamer, which can seamlessly be controlled through over 48 joints, flabby though as they may be. The setting is a unkempt room with modest furnishings, which has the Virtual Natal Console in it.

Through the Natal interface, the gamer can guide The Gamer to the Virtual Natal interface and begin play of a Virtual Natal Game, which is the greatest game of all time. The Gamer's fun level can easily be discerned through both an visual interface and audio cues such as:

• "Dude!"
• "Dude..."
• "Aw, Come ooooooon!"
• "I said I am coming in two minutes, Mom, leave me alone!!!"

People enjoying the deep and fulfilling gameplay of Project Natal Natal must pay careful heed to the Bladder, Bowel and Hunger meters, making the experience akin to playing that Will Wright masterpiece, The Sims. Microsoft has said not to worry as they have already started looking into addresssing the tedium of bodily functions within Project Natal Natal with unlockable DLC achievements items such as "The Diaper" and "Delivered Hot Pockets."

It is important to note that this project is still in early pre-alpha stages of development. Rest assured, your correspondent will deliver new information and screenshots as soon as they are available.

Java App Store thoughts

Sun has released a Java app store and an accompanying developer portal. It is interesting to see that they are going after the consumer software market. In his blog, The Schwartz points out that the JVM is installed on a  huge number of client PCs (billions), and various other devices. The whole thing reeks of "we are cool like you, Apple, cause we are everywhere!"

So they want to cash in on that ubiquity. One interesting question here is, why is Java so ubiquitous on the client side? I can throw some reasons out there: web pages that require a browser plugin. Fringe apps and games. Bored downloaders that ran out of things to install. And bundling.

In short, consumers didn't really make a huge jump and say "Wow let's download Java!" How are we making the logical conclusion that they will do so now? The only possiblity is that some insane marketing juggernaut makes Java a household name, or some app makes it "cool with the kids." Sun is not a marketing juggernaut, neither is Oracle, hell, neither is Microsoft (Bill Gates!?!?). The iPhone doesnt have a VM either :) Uh oh, spaghettios! The people that are most excited about the Java Store are nerds like yours truly. Yay, now I can make tons of cash too without having to learn Objective C on the iPhone!

Allow me to quote a popular social critic: "Sounds pretty irrelevant."

The one thing that it will do if it takes off is the streamlining content delivery. You can choose to bundle various OpenGL bindings (JOGL and LWJGL) for advanced graphics as well as an OpenAL binding for sound (JOAL). Very nice. Trusted source, lots of bandwidth, classification of apps. Looks like a promising start. But without a deep hierachy of categories (the current one is shallow and weird), and a robust ratings interface, this thing is going nowhere. Also, a 50mb size limit on apps? Oh, my. Oh and please, please stop plugging JavaFX every time you say Java. Seriously, it's getting to be so annyoing. And when people get annoyed, they play with their iPhone.

Here's hoping for that marketing juggernaut. Come on baby, daddy needs a new pair of everything!