DaedTech

Stories about Software

By

Factory Method

Quick Information/Overview

Pattern Type Creational
Applicable Language/Framework Agnostic OOP
Pattern Source Gang of Four
Difficulty Moderate — slightly easier than Abstract Factory

Image courtesy of dofactory

Up Front Definitions

  1. Creator: This is the basic, abstract factory interface.
  2. Concrete Creator: Inheritor factory classes that implement some actual object creation scheme.
  3. Product: This is the base/abstract polymorphic object that gets created by the factories.

The Problem

Let’s say that you’re coding up some kind of game and in this game a character navigates a world and encounters various entities with which to interact, including enemies. You’re starting out with a very bare bones proof of concept, and here is your sketch of some enemies:

The concrete enemies return a string representation of their attack, which you will, no-doubt, later transform into some kind of first class attack object or even graphic as the game moves along, but for now, you just want to get the concept right. To get things going, you create the following class:

You want to keep things clean, so you abstract an interaction method, knowing that at some point this will probably mean something different than dumping to Console. From there, you’re now left to figure out the enemy situation based on where the character goes and you’re off to a good start since gators tend to hang out in swamps. Let’s add in a few more scenarios:

Now you’re off and running. You decide that HouseFly is a good enemy to use in this case, since it seems like a good stock enemy ala the “Goombas” in Super Mario Brothers or Foot Soldiers in the Teenage Mutant Ninja Turtles (I’m probably dating myself a bit here). But wait a minute — house flies could happen anywhere. Let’s say that they’re the else condition, but they also have a 50/50 chance of appearing in the other places. Hmmm… let’s introduce an abstraction to hide the ugly and annoying details of randomization and do this:

Ew, that’s starting to smell a bit, but no time to worry about that now. Your efforts here have led to some angel investment capital and now the pressure is on. You use that money to hire a UX/gameplay expert so that he can worry about the gaming decisions while you focus on architecture. He tells you that you need to introduce the concept of difficulty and that Chuck Norris can be anywhere except Middle Earth but only if the difficulty level is set to 5 or more. But Chuck Norris is a family man himself, so he’ll only attack you at a family reunion on a really high difficulty level like 10. Otherwise, he’ll wait until you leave. Hmmm….

You look at this and realize that you’re definitely whipping up some spaghetti code here, but no time for that now. Your game designer tells you that you need a new mode of the game where instead of interacting with the enemies you talk with them first. The logic for encountering the enemies is exactly the same and you still need your old code, but you need it in a new module. Oh, and you should probably add a few new enemies that you find in a few new places. And house flies should probably stop appearing after difficulty level 7. Oh, and dragons can appear in Starbucks sometimes after a successful battle with MotherInLaw. Oh, and gators can appear at your family reunion if you have it in Florida.

Here’s the code for that… just kidding. You’re probably not going to read subsequent posts if I destroy your eyesight with the code I’m describing.

So, What to Do?

As has become customary in this section, let’s examine what went wrong. Most of the time it’s the point at which copying and pasting start, but not in this case. Another good tell in this series of posts where things go off the rail is when I start trotting out excuses for what ‘you’ are doing in the second person narrative. As soon as things are a little ugly because ‘you’ have a deadline or ‘your’ project manager is riding you, that’s usually when things went wrong. Here is no exception. Let’s rewind to the second code snippet, representative of a simpler time:

This is alright, though I would argue that we can make a nice improvement here. Notice that we’re following a pretty consistent pattern here: we check place name and then we invoke the same method on a polymorphic object that varies with place name. It might seem like a trivial bit of redundancy, but these add up as you leave them in and, I would argue, poison the well when it comes to future design decisions. Broken Window Theory and all that. So let’s change the code to this:

Notice that there’s now only one call to “InteractWithEnemy” and we’ve split the functionality of mapping place name to en enemy instance from the functionality of interacting with the enemy in a nod to the SRP. You also might notice that we have implemented what has come to be a common variant of the original Factory Method pattern, which is the static factory method. A static factory method is a stateless method that takes in some criteria and spits back a matching polymorphic instance of the common base return type. For instance, this method says “if the place is middle earth, we need a dragon enemy.”

With this refactoring accomplished, let’s take on the next requirement, which is that house flies can occur anywhere with a 50% probability. Before our heads start rushing with design patterns and complex implementations, let’s consider what might be the easiest way to get this working. Didja think of this:

Notice how easy that is with a little bit of logic separation. But, if that implementation strategy were going to hold up, there’d be no meat to this post, so let’s press on. Chuck Norris can be anywhere except for Middle Earth and a family reunion if the difficulty level is at least 5 and anywhere except Middle Earth if the difficulty level is at least 10. At this point it’s important to recognize what’s happening here and it’s easier to do so now with this factored road down which we’ve started. What’s happening is that what was originally a simple mapping from place name to enemy inheritor is becoming muddied by a growing number of additional factors. And what’s a good way to handle additional complexity in an object oriented programming language? Well, encapsulate it in an object.

The idea of centering the enemy generation around places is appealing since that’s how we originally conceived of it, so let’s stick with that. The family reunion one seems to be the most complicated, so let’s take a look at that:

(I added a “choose at random” method to the interface of signature T ChooseAtRandom<T>(params T[] thingsToChoose) to keep the emphasis on the factory class as much as possible rather than distracting with worries about random implementation. I acknowledge that this would have made the problem code a little less noisy, but it still would have been headed down a bad street with creeping complexity)

Cool! Now the GameNarrative class doesn’t need to worry about the creeping complexity around what goes into the decision of which enemy to generate beside the place name. We have a class with the single responsibility of figuring out how enemies get generated for the family reunion location. But how does this fit with the original class? Well, let’s take a look at an interim solution. Here is an updated, no-longer-static factory method:

Notice that instead of directly instantiating an enemy when we’re at the family reunion, we delegate that task to our newly created factory. Let’s make a factory for each place now so that we can remove that awkward GetEnemy call and keep this method clean. In order to do this and return a factory instead of an enemey, we’re also going to need to make these factories polymorphic cousins of one another, by defining an interface (could also be an abstract base, which is less decoupled but allows implementation of a common constructor).

And, with that in place and all of the other factories defined (elided), here is the new narrative class:

That’s looking pretty darn legible now. But it’s not just that the code is easy to read or even that it’s separated into factored methods and classes. The important thing here is conformance to SRP and the fact that it’s easy to find what needs to change and change it independently of other concerns. Think back to the change request that broke our spirit earlier. Adding new enemies? Piece of cake — just add classes for them and then add them to the random generation in the factories that are eligible to generate them. Porting enemy generation? Just make the GetEnemyGeneration method (or some variant of it) publicly accessible and call it elsewhere. All of the new enemy generation business rules? Put them in their appropriate factories. Cross cutting rules? Create a base factory class. These tasks are now quite manageable.

A More Official Explanation

The stated purpose of the Factory Method design pattern (from dofactory) is:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

This creational pattern is also sometimes referred to as “virtual constructor” because of the way it separates the promise of object creation from the implementation via polymorphism. Be it an interface or abstract base class, the abstract definition defines a contract for the generation of polymorphic entities and then delegates that work to implementers/inheritors.

This has the powerful benefit of allowing flexibility and following of the open/closed principle not just for creation of objects but for strategies for object creation. In our example above, the IEnemyFactory is the Creator, the various factories are the Concrete Creators and the enemies are Products. We have the ability with this implementation to seamlessly add new enemies but also to seamlessly add new schemes for generating enemies. If we wanted to add a location called “mountains” with its own unique set of denizens to the game, this would be straightforward and have nearly 0 bearing on existing code.

It is worth noting the conceptual similarity to Abstract Factory at this point and pointing out that the jump from Factory Method to Abstract Factory is just the addition of more polymorph families. For instance, if each location had enemies, terrain, and allies, Abstract Factory would be a good fit. That said, the transition from Factory Method to Abstract Factory is extremely violent to the code base since the addition of methods to the factory require changes to all implementers. Thus it is probably good to spend some effort up front reasoning about what the factory should do, particularly if the concrete factories are spread far and wide (unless you are using an abstract base class and then there is some reprieve here as you can specify default behavior).

Other Quick Examples

  1. An enterprise application capable of pulling information from multiple persistence models (factory methods to create DAOs).
  2. A GUI intensive application that generates controls/forms/pages on the fly depending on user interaction.

A Good Fit – When to Use

This is an interesting one circa 2012 because it seems like a decent amount of the heavy lifting that I used to see this pattern do has been replaced by IoC containers or plugin architectures. In other words, the Gang of Four made it fashionable to move complex instance creation into its own place in your code, and the Unit Test/TDD crowd later made it fashionable to move it out of your code altogether. It’s also been squeezed on the other side, so to speak, by the prevalence of the “poor man’s factory method” — a simple static method that returns polymorphs representing a common interface or base class.

But in reality, this pattern has its own niche not covered by either of these situations. IoC containers and, to some extent, plugin architectures are really about decisions made at application start time. The point of abstracting them out of the codebase is to allow application behavior to be changed without rebuilding and re-deploying. Factory Method as I would advocate covers a subtly different usage scenario wherein the polymorphic type is not known at application startup. An obvious example (and the one we covered in this post) is where the user supplies input that governs which object should be created in some way.

But this could still mean using the static method rather than the class hierarchy of Factory Method. I would recommend the latter specifically in situations where the logic surrounding instance creation is more complex than switching over a simple argument or two and/or likely to grow and change with time (the aforementioned Open/Closed Principle). If you find that you have a static factory method that’s ballooning in size and cyclomatic complexity it’s probably time to consider a factory method hierarchy.

Square Peg, Round Hole – When Not to Use

The inverse of various situations described in the previous section is a good place to start. You probably don’t want to use this pattern for very simple scenarios (say, switching over an enum or character to create instances) and you probably don’t want to use it for decision that can be made prior to runtime as that introduces more complexity and indirection to your application than necessary. Another place that you’d avoid this is when you need an abstract factory because you’re creating object families.

As always, YAGNI applies, and factories are sort of iconic in representing over-engineering in OOP. I once heard a cynical but funny quote (don’t recall who originally said it, but if you know, please comment): “some people think they’ll use java to solve their problems — now they have a problem factory.” This is obviously tongue in cheek, but the implied point about pattern happy enterprise development shines through. It’s easy to get pretty elaborate when abstracting instance creation out of plumbing and service code (and I love the practice) but there’s a fine line between this and creating too many levels of indirection. Be careful that you actually need these factories and aren’t just speculatively abstracting. As a rule of thumb, I’d say that you should be able to look at them and think “man, it’s a good thing I pulled that into a class.”

So What? Why is this Better?

As show in the example, when judiciously used, the Factory Method pattern can transform what would have been a snarl of instantiation spaghetti into a well separated, maintainable set of classes. The “after” in this picture shows code that conforms to established OOP principles such as the Open/Closed Principle and the Single Responsibility Principle (you can throw Liskov in there too since there’s a lot of polymorphism here).

Once this is in place, adding new target/product objects for creation is a segregated and approachable problem and adding new creation schemes becomes quite easy. It’s also straightforward to separate creation from use in your code as well, leading to a lot of architectural flexibility. And, properly applied, it’s a good mechanism for avoiding the bane of programming existence — copy and paste coding.

By

Practical Math for Programmers: DeMorgan’s and Other Logical Equivalences

The “Why This Should Matter to You” Story

TL;DR: You read my post about conditional bloopers and thought, “what’s wrong with that?!?”

Let’s say that you recall the lesson from last time and you make sure that you also avoid statements like “if(A && (A || B))”. You draw out truth tables whenever you feel you have time (and when no one is looking because, if you’re honest with yourself, you feel a little awkward doing it when people are watching). And yet things like this still happen to code you’ve written:

gets refactored to:

When you notice this in the source history, you check with your truth tables, and sure enough, it’s right. You kind of get it, in the end, but you always feel like you’re a step behind.

Math Background

In Boolean algebra, truth tables are sort of the equivalent of rote arithmetic memorization such as learning multiplication tables and using them to perform long-hand multiplication of larger numbers. It’s a rote, brainless, and time-consuming algorithm that you follow when there isn’t something better to use to get you to the answer more quickly. But the good news is that if you memorize a different set of information — some axiomatic laws of equivalence — you can get a lot of answers more quickly and easily. Here is the series of equivalences paired with explanations that will really help you understand the finer points of simplifying your conditional logic.

Identity Laws:  (A ^ TRUE) = A and also (A v FALSE) = A.  These identity laws simply point out the identity of variables compared with special constants.  This is like talking about additive identity (x + 0 = x) or multiplicative identity (x*1 = x) in elementary algebra (i.e. what you learn in junior high).

Domination Laws:  (A ^ FALSE) = FALSE and also (A v TRUE) = TRUE.  These are the opposites of the identity laws and have elementary algebra annihilator equivalent (x*0=0) or (x/x = 1).  These operate simply in that any false in a conjunction or any true in a disjunction renders the entire expression false or true, respectively.

Double Negative:  ~~A = A.  (Probably more formally known as “double negation” or negation of negation, but I think this easier to remember).  This quite simply says that if something is not not there, then it is there or, in Boolean logic, two falses make a true.

Commutativity:  (A v B) = (B v A) and (A ^ B) = (B ^ A).  This simple but important law    shows that the order of arguments to the conjunction and disjunction operators do not matter.  Think back to your arithmetic days when you learned that 4+3 = 3+4.  Same principle.

Associativity:  (A v B) v C = A v (B v C) and (A ^ B) ^ C = A ^ (B ^ C).  You can think of this as demonstrating that the location of parantheses is irrelevant when all operations are conjunction or disjunction operations.  If you reach ever further back in your brain from arithmetic, you may remember this guy as 3 + (4 + 5) = (3 + 4) + 5.

Tautology:  (A v ~A) = True and (A ^ ~A) = False.  We went over this in more detail last time, but suffice it to say that conjunction and disjunction with a variable’s negation leads to vacuously true or false results.

Idempotence:  (A v A) = A and also (A ^ A) = A.  Idempotence in general is the idea that an operation can be applied multiple times but only have a single effect.  For a rather practical example, consider turning a light switch on; the first time you push up a light turns on, but subsequent pushes up don’t turn the light somehow “more on”.  Idempotence in Boolean expressions means that redundant conjunctions and disjunctions simply have no effect.

Distribution:  A ^ (B v C) = (A ^ B) v (A ^ C) and A v (B ^ C) = (A v B) ^ (A v C).  This is a powerful equivalence because it provides a means to “move” parentheses around in Boolean expressions and retain their exact truth values.  Consider this in English and there is sense to it: “If A is true and also either B or C is true then A or C is true and A or B is true.”  Should that be a little abstract for your taste, think of it conversationally “It’s raining and either I’m inside or I’m wet” is the same as “It’s raining and I’m wet or it’s raining and I’m inside.”

De Morgan’s Laws:  ~(A ^ B) = (~A v ~B) and ~(A v B) = (~A ^ ~B).  This is another heavy hitter like distribution except that this one allows us to “move” negations when simplifying Boolean expressions.  This one also makes sense conversationally: “If it’s not true that person X is male and person x is female, then either person X is not male or person X is not female.”  De Morgan’s Laws also have an interesting incarnation in higher order logics like first order logic, but that’s probably going to be beyond the scope of this series for quite some time.

Absorption: A v (A ^ B) = A and A ^ (A v B) = A.  This was the main example we covered last time, so you can work out the truth table if you like.  As it turns out, this is a formally defined equivalence as well.

How It Helps You

In the last post in this series, I covered truth tables, which are sort of like the Boolean algebra equivalent of long division.  They’re a mechanical, inelegant process by which you can brute force a correct answer.  Logical equivalences are algebraic axioms that provide you with the building blocks for deductive reasoning — the building blocks for really thinking things through and critically solving problems.

You don’t necessarily need to memorize these, but I would study them enough at least to have something tickle the back of your mind the next time that you’re staring at an incredibly complex looking conditional.  That something will be “I think we can do better than this” and then, even if you don’t have the equivalences memorized, at least you’ll know enough to go look them up.  Armed only with truth tables, this can feel like flailing around in the dark while looking for a pattern.  But armed with logical equivalences you’ll say “oh, that’s right — I can eliminate the not here and I can turn these ors into ands over here, and… yeah, much better.”

Memorizing these equivalence laws would be even better, but not for the sake of pedantry or winning obscure trivia games.  I say that memorizing them is better because if you memorize them, you will practice them and conditionals, particularly complex ones, will start to work themselves into simpler forms automatically in your mind.  You will see things like Neo in the Matrix when he’s about to defeat Agent Smith, if the movie were a lot more boring.  Point is, though, you’ll develop an extremely good sense for when conditional logic could be simplified, corrected, or clarified and that has powerful ramifications for the readability, correctness and maintainability of the code you work with.

To circle back to the small example of a real world situation, understanding these Boolean laws of inference is likely to put you ahead of the curve, rather than behind it, when it comes to understanding conditional simplification.  Rather than the person whose code is always getting refactored, you’ll be the one doing the refactoring and doing it confidently.

Further Reading

  1. Wikipedia
  2. A bit more circuit flavored, but with some applied examples at the bottom.
  3. An introduction to the idea of proofs in Boolean algebra
  4. Very theoretical, with formal proof for most of the inference laws.

By

One Singleton to Rule Them All

I would like to preface this post by saying that I don’t like the Singleton design pattern at all. There are some who love it, others who view it as a sometimes-useful, often-abused tool in the toolbox, and then there are people like me who believe that it’s extremely rare to see a use of it that isn’t an abuse — so rare that I consider it better to avoid the pattern altogether. I won’t go into much more detail on my thoughts on the Singleton (stay tuned for that when I get to this pattern in my design patterns series), but here is some further reading that expounds a lot on reasons not to like this pattern:

  1. Scott Densmore: Why Singletons are Evil
  2. Misko Hevery: Singletons are Pathological Liars
  3. Alex Miller: Patterns I Hate
  4. Steve Yegge: Singleton Considered Stupid

With all of those arguments against Singleton in mind, and considering the damage that abuse (and I would argue use) of the pattern causes in code bases, I found myself thinking of code bases I’ve heard of or encountered where the code was littered with Singletons. In these code bases, refactoring becomes daunting for a variety of reasons: the hidden dependencies, the complex temporal dependencies, the sheer volume of references to the Singleton instances, the almost obligatory Law of Demeter violations, etc. Singletons cause/encourage a rich variety of problems in code bases. But I think that something could be done about two such problems: the redundant Singleton implementation logic and the Single Responsibility Principle (SRP) violation of which Singleton classes are prima facie guilty.

Take a look at how the Singleton is implemented (as recommended by Microsoft, here). The basic implementation initializes the static instance in the property accessor while variants use field initializing syntax and introduce thread safety.

The basic implementation is here:

More specific even to C# is James Michael Hare’s implementation using the Lazy<T> class to eliminate the redundant if-instance-null-instantiate logic needed in each Singleton class. But that still leaves the redundant Instance property, the redundant _instance field, and the awkwardness (SRP violation) of an object managing its own cardinality. What if we got rid of both of those issues?

Using generics, this implementation allows an instance of every Singleton to be expressed in the code of a single class. In this fashion, any type can be implemented as a Singleton without the type being coupled to an internal Singleton implementation. It also standardizes the Singleton implementation by making sure it exists only once in the code base. With this pattern, there is a similar feel to IoC containers — classes can be implemented without concern for who will instantiate them and how.

Here is my take on the disadvantages and potential disadvantages of this approach:

  1. You still have Singletons in your code base.
  2. This might actually encourage more Singleton usage (though fewer actual Singleton implementations) by removing responsibility for implementation.
  3. Since constructor of object in question must have public default constructor, removes the Singleton gimmick of making the constructor private and thus the safeguard against additional instances being created is also removed.
  4. A natural extension of the previous item is that it remains a matter of documentation or convention to use Singleton<T> and not instantiate rather than it being impossible to instantiate.

But the advantages that I see:

  1. Only one class implements cardinality management, meaning refactoring away from Singleton is nominally easier.
  2. No Singleton SRP violations
  3. Singleton implementation (initialization, lazy load, thread-safety) is standardized to prevent inconsistent approach.
  4. I actually consider preventing the private constructor gimmick to be a plus — particularly where potential refactoring may be needed (and it pretty much always is when Singletons exist).
  5. With this pattern in your code base developers are less likely to be come comfortable/familiar with implementing the Singleton pattern.
  6. No need to introduce interfaces for Singletons to inject instance into classes using dependency injection — just inject a non-Singleton managed instance.
  7. A code base with nothing but normal instances is very easy to reason about and test, so the closer you get to that, the better.

I would like to reiterate that I’m not suggesting that you run out and start doing this everywhere. It mitigates some of the natural problems with the Singleton design pattern but “mitigates some” is a long way from “fixes all”. But, if you have a code base littered with Singletons this could potentially be a nice intermediate refactoring step to at least standardize the singleton implementation and provide slightly more friendly seams to testing legacy code. Or if you’re faced with and outvoted by a group of other developers that love their global variables (er, excuse me, Singletons), this might be a decent compromise to limit the damage they cause to the code’s maintainability. On balance, I’d say that this is an interesting tool to add to your arsenal, but with the caveat that something is probably wrong if you find that you have a use for it.

I’d be curious to hear others’ takes on this as well. I just kind of dreamed this up off the top of my head without taking a lot of time to explore all potential ramifications of it use. If you’ve implemented something like this before or if you have opinions on the advantages/disadvantages that are different than mine or if you see ways it could be improved, I’d be interested to hear about it in the comments.

By

Happy Thanksgiving!

Here’s wishing all DaedTech readers who celebrate Thanksgiving today a safe and happy holiday. I will most likely not make anymore posts this week as I celebrate the holiday over this long weekend. Posts will resume as per normal next Monday.

Cheers!

By

A Tale of Two Web Stacks: Java vs .NET

For the last few years, I’ve focused largely on desktop development doing WPF and C#. I’ve dabbled a little here and there in web development, but the lion’s share of my web development up until the last few months occurred several years ago or earlier. Recently, I’ve been doing nothing but web development, in the form of webforms primarily, but also with Java and my home automation projects here at home. One weekend several weeks ago (it was “last weekend” when I started this post) I decided to upgrade my main machine at home from XP to Windows 7, and this required me to wipe everything and start fresh. Part of this meant that I’d have to port my IntelliJ/Spring/Maven/Java setup to a new machine.

I had ported my project from Eclipse to IntelliJ (which went very smoothly — compliments to IntelliJ), so it had been a long time since I’d actually set up a web development project in Java. Interestingly, it had also been a long time since I’d done the same in the ASP world since the work I’ve been doing the last several months had already been setup from a project structure perspective. However, given my situation with the home automation project and the fact that I’m starting on FeedPaper, I’m in a unique position to document my comparative experiences with both, being in the position of generally experienced developer and relatively familiar with the technologies, but not practiced at setting up these specific types of projects. I’ve done this documentation below.

Before you read on, please note that I’m not in the tank for anyone or a fanboy of any technology, company or platform. I’ve spent years developing in both Java and .NET and there are things that I like about both. I’m a happy, equal opportunist polyglot and hope to stay that way. But for me to do so (with Java and .NET at least) would require both technologies to succeed, and I see trouble on the horizon for Java. I don’t like this because I like Java. It was a nice alternative for web development when Microsoft wanted to charge me $500 for Visual Studio and who knows what for whatever else I would have needed to write web applications. I like it because it was real, big boy server side code, capable of expansion to enterprise sites and not sloppy (I’m looking at you PHP). I like it because of the vibrant and inventive community of developers committed to improving it. But, I still think dragons be coming and Java might have a fight on its hands not to become COBOL.

Setting up For Java Web Development in 158 Easy Steps

Here’s why I say there’s trouble. I wanted to set up a minimally functional site with both Java and .NET web technologies — “hello world” in concept. My steps to set up Hello World with Java are detailed here (if you get tired of reading, feel free to skip to the bottom of the list as it is incredibly long):

  1. I download and install IntelliJ Community Edition.
  2. I download and install JDK 7 and create a “JAVA_HOME” environment variable.
  3. I download Tomcat and unzip it in C:\program files\Tomcat.
  4. I set “CATALINA_HOME” environment variable and point it here.
  5. I go to Tomcat’s “webapps” directory and set its permissions to allow anyone to modify since that’s where I’ll be deploying my projects and I don’t want UAC messages each time I do.
  6. I run Tomcat’s “startup.bat” and fire up localhost:8080 to manage tomcat. Fail. HTTP Status 500 – java.lang.ClassNotFoundException: org.apache.jsp.index_jsp.
  7. I refresh and get a different error: HTTP Status 404 – /.
  8. I try going to the manager URL directly. Error: HTTP Status 500 – java.lang.IllegalStateException: No output folder
  9. I google, but don’t really know what to google, and don’t have much luck.
  10. I try running random bat files in the Tomcat directory with names like “setclasspath.bat”. No joy.
  11. I put quotes around my environment variables since Windows directory names and their spaces are kinda screwy.
  12. Oops, now startup.bat in the Tomcat folder does nothing. So much for that. I put the environment variables back.
  13. I open the file “RUNNING.txt” in Tomcat root directory and see if it has anything helpful to say. It does, but it only covers the stuff I already know (all this environment variable crap and that I should start the web server with startup.sh)
  14. I google again and find nothing useful.
  15. I start looking through the Tomcat output to the Console and see a bunch of exceptions about a log file not existing because access is denied. This doesn’t seem like it ought to be critical, but you never know.
  16. In a scorched Earth approach, I make the entire Tomcat directory writeable by any user and restart Tomcat where I see no more log errors.
  17. Joy! Half an hour in, I have the web server running.
  18. Time to make sure I can see what apps there are — I remember I can do that from the manager.
  19. Tomcat 7 helpfully tells me that I need to configure security for the web server (previous versions didn’t) so I do that by editing tomcat-users.xml.
  20. I uncomment the examples in the file to use and that doesn’t work, I get a 401. But, the 401 is pretty helpful (another improvement) and I follow the directions in it, which unfortunately don’t work.
  21. I try restarting the web server.
  22. Joy! That was my stupid mistake — assuming that the roles were processed at login time rather than startup. 45 minutes in I can manage the web server.
  23. Going back to IntelliJ, I try to create the project I need, but can’t because I don’t have a web template available.
  24. I google and discover I should use Maven.
  25. I read and try to understand what Maven was and where it came from. Don’t really understand (kinda like NuGet I think), but apparently IntelliJ has it so I don’t need to install it or anything.
  26. I try to create a Maven project, which goes fine except for the “Finish” screen, which tells me that the Maven Home Directory is not specified.
  27. I specify it as the directory with the user settings file, but apparently that isn’t right because the Maven Home Directory is “invalid” (no mention of why or where I might find one that isn’t).
  28. I google this error message, wondering why I have to bother with this and why it doesn’t just work. Epic fail. I’m apparently the only one that’s ever had this problem.
  29. I do a search on my hard drive for “maven” and find that there are a few hits in the folder C:\users\erik\.IdeaIC11, so I figure, what they hey, I’ll give that a try. Nope.
  30. I look at the “user settings file” and “local repositories” specified by default and notice they don’t exist, so I create them, figuring that this might make the directory a valid maven directory. It doesn’t.
  31. I google and find this stack overflow post that leads me to an example settings.xml file and I try adding the xml I find there into mine, hoping this might at least result in a new error message. It doesn’t.
  32. I go downstairs and get some soda and take a break.
  33. I come back, wondering whether I have to install maven separately.
  34. Apparently not, according to Jetbrains as it “ships with” IntelliJ. I testily wonder “if it ships with IntelliJ, why the %&$# is it asking me where the Maven directory is?!?”
  35. Back to google. I find this post telling me that “opening maven project is as easy as pie”. I chuckle.
  36. Back to google. Nothing helpful after another 5 or 10 minutes. At this point, I’m 1:15 into this effort.
  37. I decide that I’ll install Maven anyway, whether or not it “ships with” IntelliJ. What can it hurt at this point?
  38. I go to the maven download page and am a bit concerned that IntelliJ says that it integrates with Maven 2 and that a third of the roughly 17,400 options I have for downloading Maven are for a version 3. And which of the version 2’s on there does IntelliJ integrate with. I abandon this plan.
  39. I google again for a while and discover that most problems with the M2_Home/Maven Home seem to be for Linux and Mac users. Apparently there is some sort of known issue there. I wonder if that’s true on Windows at all.
  40. I go get another soda. I’m about 1:45 minutes in now.
  41. I download Apache Maven v2.2.1, reasoning that even messing things up badly at this point would be better than no change (and it takes less time to format my drive, re-install Windows 7 and get all my drivers going than setting up this hello world web project anyway, so how bad can it be?)
  42. I unzip Maven to C:\program files\maven.
  43. I look in the conf folder and see “settings.xml” so, having learned my lesson from Tomcat, I decide to move the whole operation to C:\users\erik\.m2
  44. I try again and it fails using M2_HOME, but when I “override” and type the directory in manually, it works. I guess “defaults to M2_HOME” is a bit of a fib, but that doesn’t matter at this point, since I’ve won.
  45. Joy! About 1:50 in, I have a web server installed and I’ve created my project!
  46. My joy is short-lived as I see that there is no Web-Inf or welcome JSP page or index or anything to indicate that this is a web app. Sigh.
  47. Whatever, let’s at least get what we have building.
  48. I do a “make project” and get an error: “Cannot find home directory C:\program files\java\jdk1.7.0. Update Project Configuration.” I’m actually pretty pumped about this error message since it offers some kind of actionable feedback. My standards, as you can tell, are now pretty low. I mean, you’d think this could be inferred from my “JAVA_HOME”, but whatever.
  49. I go into settings and look under “Compiler” and see nothing about the JDK to user, so back to google.
  50. I find nothing helpful there, so I start randomly looking at menus and context options.
  51. I right click on my module and see “open module settings”, which looks promising. I go to the “Project” under “Project Settings” and see that there is a SDK specified, but it just says “1.7” and it’s red. I click the dropdown and see there’s also 1.7 (1) and that’s red too. Apparently the default is not 1, but 2 copies of a nonexistent JDK. I delete both of those and manually browse to the actual JDK.
  52. Now, I build and nothing happens, which is an improvement. I’m just told “all files are up to date.”
  53. I’m not going to worry too much about that now because I don’t actually seem to have any files, so it stands to reason that there’s nothing to compile.
  54. I’m not sure what the Maven “web-app” goal or archtype or whatever actually did for me, but I did notice something interesting when clicking around called “Add Framework Support”, so I’ll try that.
  55. Bummer, my only option is “Groovy”. Back to the drawing board.
  56. At this point, 2:15 in, I knock off for the day. I’m doing this on nights and weekends and so clearly hello world web app is going to need to be a longer term project than just one day. I have chores and bills and occasionally a life, I’ll have to resume setting up the simplest, most basic web setup imaginable later when I can really devote a lot of time to it. I’ve managed to install the web server and create a project that doesn’t do anything, compile, or even have any files. Quite a productive day, I guess…
  57. I pick back up the next day and, having slept on it, I remember something about adding things to pom.xml. Perhaps if I add Spring stuff to it, the “Add Framework Support” thing will work.
  58. I google and find this stackoverflow post. It’s not particularly helpful, and I consider “add this bunch of random crap to this XML file” to be an enormous framework fail, but misery loves company, and I can see that most people that do this are also confused and that you can “learn the basics of Maven in a few days” if you read a book. I’m not really clear on why this Maven is better than downloading Jars on my own, which wouldn’t take me a few days, but I’m trying to do things the “right way”.
  59. I google some more and find this from Spring, and it looks promising. I still think it’s utterly preposterous that the way to get dependencies is by hunting down blobs of random XML from the internet to copy and paste into a file, but I seem to be making progress. I copy and paste.
  60. I then right click and click “sync Pom.xml” because I seem to remember doing that before and it seems to make sense for some reason.
  61. I try “Add Framework Support” again, but no joy. Still only groovy.
  62. I delete all that XML and flail around google some more.
  63. I find another post where I see some sample XML from another pom, and I see that all that crap I copy and pasted needs to go inside of a “dependencies” tag.
  64. The syntax highlighting looks more promising now, but I try synchronizing and importing and whatnot, and still no framework support. Now there’s a lot of angry red in the IDE about my pom.xml file and a squiggly under it in the project explorer. But, errors are different, and different is progress.
  65. Back to google, and I’m now 2:45 in.
  66. I find another blog post and learn that the “properties” tag needs to go outside of the “dependencies” one. Of course – I shoulda known (/sarcasm). This guy’s blog is pretty helpful — too bad he doesn’t use IntelliJ.
  67. I make the change and synchronize again, and nothing really happens.
  68. After a minute, the squigglies and angry red goes away and suddenly a bunch of stuff about spring appears under “External Libraries”. It’s like magic (but more like a kid putting on a magic show and needing a few mulligans than David Blaine).
  69. This doesn’t help setting up the directory structure to get hello world up and running.  I still have a blank module under a blank project.
  70. I google and find this on stack overflow.  It doesn’t help me, but it is interesting to note that someone experienced in all three technologies (Spring, Maven, IntelliJ) would likely take longer than 30 minutes to set this up.  Someone not experienced with Maven and IntelliJ… 3:00 and counting.
  71. I try creating a new module for the heck of it, to see if maybe this time the “Maven Web App” actually has some kind of directory structure or code in it.
  72. Nope.
  73. I go to delete this module that I don’t want and spend a few minutes getting annoyed until I discover that I have to delete all of the files in the module, then delete the directory, then do it again for reals (it’s separating delete from project and disk).  That took a pointless 5 minutes.
  74. Back to google.
  75. I find this page, which has exactly what I want.  It’d be awesome if it my IntelliJ actually worked like that.
  76. I see that that post was written 9 months ago, so perhaps setups were simpler back then.  Yep, those were the days.
  77. I try creating a new project anyway because I’m really pretty much out of ideas.  Not surprisingly, that doesn’t work.
  78. Back to google.  Nothing.
  79. I start to wonder if it’s even possible to have IntelliJ create a web project directory structure for you.  I could have sworn it worked before when I did this some weeks back.
  80. I find this on the IntelliJ site, which suggests creating a Java module from scratch instead of a web module.  I try that and it doesn’t work, but I try creating a Maven module again and now have the option of creating a Spring project.  I do that, and it actually gives me a “src” directory.  Sweet!  We’re getting somewhere.
  81. This module inside the project also has a pom.xml.  I copy all of the crap from the main pom to this one and try adding framework support.  Nope.
  82. I am seeing “fatal error, cannot find JRE1.7” in the “messages maven goal” window.  I clear the message and I can’t get it to come back.  I have no idea what’s causing it.
  83. At this point, I think it isn’t worth spending anymore effort trying to get the IDE to setup a basic project structure.  Clearly I’m asking the impossible of the incapable.
  84. Luckily, I have the source code for a previous Eclipse project that I converted to IntelliJ laying around, so I re-create that directory structure (I eventually want to be using a lot of the source from this project anyway, so I’ve kind of decided that skipping hello world might, ironically, be easier).
  85. I copy the entire WebContent directory and then copied the structure of src, at which point I copied a few controller java files.
  86. The files I copied have a little j with a red circle around them and a line through them.  That don’t look right, so I google and find this.  I have to specify a “source” directory.  Sigh.  Of course I do.
  87. I follow the instructions in the post and my src directory automatically converts into a package structure (which is admittedly pretty cool) and three of my controllers are error free.
  88. The problem was that they were referencing other files that I need to add, so I start adding them, but that’s where things get wacky.
  89. The package structure seems to work much differently than Eclipse and my package names are getting out of sync with the disk structure and each other, so I delete everything and started over.
  90. I try to google an example package structure for IntelliJ IDEA to mimic, with predictably useless results.
  91. For those keeping score, I’m now about 3:50 in.
  92. I find this on IntelliJ and it’s like a blast of fresh something.  It actually clearly explains something in this byzantine process for the first time in a long time, and I came to understand that IntelliJ’s way of handling packages is actually pretty slick — it lets you retain package names like “com.daedtech.daedalus.controller” without the silly requirement of having 4 nested folder on disk.
  93. I add my second most abstract set of classes to the new structure and do a build, which fails as I wanted it to (red before green, refactor).
  94. I add the most abstract types that these depend on those and then rework the package naming as necessary until compiling is successful (oddly, for one of the broken dependencies, alt-enter works and for the other it doesn’t).
  95. I’m calling it another night (I didn’t start working on this until a little after midnight, so it’s pretty late now).  I figure I’ll go to bed celebrating a win.  4:15 and 95 steps into setting up Java web development, I have compiling code.  Hopefully in the next few hours I can build a WAR file and actually shoot hello world to the screen, to say nothing of setting up the IOC.
  96. Picking back up the next day, I copy all of my code files over and start resolving the differences in package naming.
  97. I spend about 20 minutes resolving all of the various compiler errors and naming issues that resulted from copy.
  98. Now I copy over the ant Build that I had been using and try it out.  Fail.
  99. Start googling what on Earth “‘includeantruntime’ was not set” means.  This helped.  Apparently, I need to set some random attribute in the javac tag that I didn’t need to before for some mysterious reason I might have cared enough to investigate in the first few hours of this.
  100. New set of errors when I try to build.  Cool, different is good.
  101. The errors say that the spring framework package does not exist, which is weird considering the module compiles in the IDE.
  102. Looking at the source files, IntelliJ randomly borked my packages in the files, so I put them back to what they were.  I’m pushing the 4:45 mark and battling the IDE.
  103.  Now onto figuring out why the ant build says springframework packages don’t exist but the IDE compiler says they do.  Apparently, this is some sort of ‘feature’ where plugins compile code differently than the IDE or something.  Boo.
  104.  I do some fruitless googling but don’t really know what to search for.  “Why does Ant suck? ” amuses me but provides no answers.
  105. I see a squiggly under one of my java files and realize that I missed one of the borked package renames.  I have no idea why it would compile with an unresolved reference.  Maybe the Ant compiler is the good one and this mystery, non-functional one the IDE uses is the problem.  My apologies to Ant.
  106. This doesn’t fix the problem of the Ant build not recognizing the spring packages.  Back to flailing around google.
  107. After about 10 minutes, I stumble across this stackoverflow post.  This reminds me that usually there’s some goofiness about “classpath” in both Eclipse and IntelliJ, in my experience, so I poke around the project and module settings looking for something like that.
  108. Poking around, I see something in the Ant properties about “Additional Classpaths”.  I find this.  My suspicion is confirmed.  It’s apparently some kind of insurmountable technical challenge to have the IDE and the build plugin use the same library configuration for building and the task falls to the user.  What a mountain of fail.
  109.  Now I find where the libraries are actually located (that .m2 directory from about 70 steps ago) and add those as an “additional classpath”.
  110. Nope.  Same error.  Back to google to celebrate hour number 5 of hello world setup.
  111. I have no luck for a while and then decide to re-read that last link and see that after line 3 it says “if you want to add the contents of a whole directory, you can click the ‘Add All in Directory’ button”.  Silly me, I just would have assumed the classpath would already have meant this or else it would have been the classfile.  I delete my useless “directory with no children” entry and opt instead for the option whose existence makes sense.
  112. I try again and all errors but one disappear.
  113.  That seems like progress until I see that the single error says “Ant build completed with 86 errors and one warning” and provides me with a single stack trace and no information beyond “compile failed”.  Sweet.
  114. I run the IDE compiler to see if that works.  It does, but I don’t know how much that tells me since it seems to ‘work’ even when there are red squigglies.
  115. I spot inspect the files, but it doesn’t seem to have changed any of them this time, so I suppose the IDE compile is really working.
  116. I re-run Ant and the missing springframework exceptions re-appear.  Two steps forward, two steps back.
  117. I add one of the child directories containing an actual JAR, in case Ant/IntelliJ have yet to discover directory recursion, but that doesn’t seem to help.
  118. At this point, I decide to concede defeat for the night because it’s late and I’m tired.  The good news is that I’m probably about half done with my project — I imagine that actually writing all of the code for the application can’t be anywhere near as difficult as setting up the development environment.  Once you’ve configured Java, writing applications in it is probably a walk in the park. I’m reminded of Rational Clear Case in that perhaps it makes sense to have experts that specialize in falling on this setup grenade so that developers are freed up to actually develop code instead of doing what I’m doing. (As an aside, if I were doing this work for a client, it would have made economic sense to pay someone up to $1000 to set all of this up for me.)
  119. I’ve been somewhat busy, so two weeks have actually passed between steps 118 and now, but in terms of raw time I’m at 5 hours, 30 minutes and counting to get Hello World (or anything at all) going.
  120. First step coming back, I googled the error message Ant was reporting and found a stack overflow post asking for help.  No answers.  Gave a sympathy upvote and moved on.
  121. I expand the “compile” node in the output, even though it has no error indication and discover that it’s littered with errors.  I think I’m partially an idiot for not checking that sooner but think that the tool needs to meet me halfway by not collapsing dozens of errors and having their section header look like everything is fine.  Still, now I’m in business.
  122. All of the errors seem to be about packages and stereotypes not existing, so I suspect it’s something to do with Maven (which, for the life of me I can’t figure out why this isn’t worse than nothing).
  123. More googling and I find this post, which tells me that I maybe need to do something with the class path as I was flirting with back in step 111.  I’m not going to follow accepted answer though because it wants a lot of things and there has to be a less stupid way to do this than redundantly adding all of these definitions to the actual Ant file.
  124. I look at the settings and see there’s a bunch of checkboxes next to the Dependencies in Module->Daedalus-> Dependencies and they aren’t checked.  I check them.  It doesn’t make a difference, so I put them back.
  125. I go into the ant build properties and exhaustively add the actual jars, but that doesn’t matter.  Still errors.  I delete everything in there.
  126. I go under the Ant properties execution and tell it to use a different JDK.  Doesn’t matter, same result.
  127. Back to google, but I don’t really find anything after 5 or 10 minutes.
  128. I start poking around settings randomly.  I try adding the Maven repository root directory to my classpath.  Nope.  I celebrate the start of hours 6 of hello world with that unsurprising failure.
  129. I try adding the MongoDB driver explicitly to the classpath.  Doesn’t help.
  130. Deciding I have nothing to lose, I go scorched Earth and choose Build->Generate Ant Build.  After doing that, it adds a few new XML files to the project.  This doesn’t help my existing build run any better, so I remove it as an Ant build from the Ant window.
  131. I add the one that IntelliJ created and theirs only has two errors, which is some sort of rather sad progress, I suppose.  I also take solace in the fact that even IntelliJ doesn’t know how to generate an Ant build and they’re experts.
  132. Time for baby steps.  I run “clean” and that works.  Huzzah!  Init also runs without errors.  I run “build.modules”.  Doh!
  133. I get an error about IntelliJ not being able to find its own ant definition file.  Apparently I’m not alone.  In the world of setting up Java, just finding someone else that has the same error as me is a huge win – an actual proposed solution is like Shangri-La.  In this case, the problem is apparently that ${idea.home} is not defined.  Oh, of course — as the question asker points out after hearing the answer, he should have known to check a checkbox that was unchecked by default, as I should have too!  /sarcasm (As a brief aside, I think that this sort of thing epitomizes an Emperor’s New Clothes paradigm in programming where we’re afraid to point out that there might be benefits in simplification because we don’t want to appear as though we aren’t clever or knowledgeable.)
  134. Not knowing how to make this ‘obvious’ correction, I delete the whole build and regenerate it.  Success!  Woohoo!!!  There were no other defaults I needed to magically know to override.  Happy Day!  Finally, after 6 hours and 20 minutes, I have an application compiling both in the IDE and with the strangely separate build engine!
  135. Now time to put my build.xml targets into this new ant build and see if I can make the magic happen.  There are actually two ant build files, for some reason, and the targets seem to be spread out sort of randomly across them.
  136. I start adding all of my stuff from my old build into the new build and run it, and then I get all of the same errors.  Time to take baby steps again.  First, I go back to the known build that was running.
  137. First I define all of my custom properties, and that seems to work, so I add a path definition from that file, and that seems to work too.
  138. I then add the war target, and run it, and that works.  Woohoo!!!  I’m building a WAR file.  Almost there.
  139. Now, it’s building it in the wrong directory for some reason.  I hard code the directory name and give that a try.  That works.  I’ll figure out why my variable scheme didn’t port over later.  I want to keep going while I’m on a roll.
  140. I copy over the “start tomcat” and “run chrome” targets to see if I can run my web app.  Doh!  Doesn’t like the directory variables here either.  So, more hardcoding.
  141. That works and tomcat starts, but it can’t find chrome… forgot to hardcode that as well, so I do and then everything runs, and I get a 404!!  (I’m not being sarcastic — I’m delighted that everything at least compiles and deploys).
  142. When I look at the tomcat webapps directory, I see that the war is being generated and it’s being unpacked, but that it has actual Java files and no classpath/lib.  So, there’s something wrong with the actual packing of the WAR.  As I investigate, I see that the lib directory is empty and that so are some other key directories.  I realize that this is because the old Eclipse structure for ouptut was different than what I have now, so I reconfigure the war target, setting the classes directory appropriately.
  143. That works, and when I re-run, I see my default JSP page in the browser, which is definitely a win.  None of the controller links work, but I’m getting tantalizingly close.
  144. I see that the main problem I have now is my lib directory not being populated with my JAR dependencies.    I googled around for a while and found this page and decided to add an “artifact” with my dependencies for deployment rather than manully dropping a bunch of jars into my “lib” folder for deployment, which seems redundant and brittle.
  145. After doing this, the settings window pops back open once for each dependency I had, which seemed screwy.  I’m not optimistic about this working and I’m prescient because it doesn’t.
  146. After playing around in the settings some more, I see that I can move my libraries, so I figure I’ll move them to the lib folder.  I try that and the window starts showing me errors, so I cancel.  Unfortunately, the cancel seems only to have sort of canceled.  I now have an error left that I have to troubleshoot.  Back to google.
  147. I google around and can’t find anything, so I try  just deleting the offending library.  That seems to work and everything still builds.  Ah, the mysteries of life…
  148. After wasting another 15 minutes or so, I’m getting less picky about redundancy.  I decide to copy the jars manually to Web-Inf/lib, but apparently the IDE can only handle this one at a time, so I have to laboriously do it for each one with a right click rather than doing them all together.  /Sigh
  149. Upon further review, I don’t think that did what I thought it would.  It just created a blank module name in that same screen.  Nothing should ever be this convoluted and counter-intuitive.  I want to copy a file.  Only the java world could make this a task that requires a PhD.  Back to google.
  150. After a while, I just decide to give up and manually copy all of the dependencies in that stupid directory.  I was dissuaded all along from doing this because (1) it’s astronomically stupid that you should have to, (2) it’s redundant information, (3) it’s a huge PITA since all of the jars are in their own folders several levels deep and (4) did I mention how incredibly stupid it is that you should have to do it when the IDE already knows about both folders?
  151. I do find and try following the process here but the options in IntelliJ are different now, so this handy-dandy 10 step process for copying files is no longer accurate.  No doubt they’ve improved it to take 23 steps.
  152. Halfway through doing the manual copy, I just can’t bring myself to continue doing something this stupid, so I stop, celebrating the 7th hour of Java hello world with a soda break.
  153. Coming back and doing a lot of googling, I find  this site.  This is a three step process for copying the Jars where step 2 is “Copy the Jars”.  Of course!  /Facepalm.  But I do pick up the interesting tidbit here that this is not the proper, Maven way to do things.  That is, perhaps I shouldn’t have a Web-Inf/lib folder after all.  I tried following the link from that site to the Maven FAQ, but it might as well have been Greek for all the sense it made to me.  I am not “confident” with Maven, so apparently I can ‘conveniently’ use the command line to do God-knows-what.  If that massive parameter-list command line is the convenient option, I think the inconvenient option will probably break my spirit.
  154. I do some more googling for things like “IntelliJ Maven Web-Inf Lib” and lots of IntelliJ bug reports came up.  From using it, I like IntelliJ and the Jetbrains people are sharp.  The only possible conclusion I can formulate the further I get into this is that Maven is a complete train wreck of an implementation however good it might be in theory.
  155. More googling and I find this site.  It doesn’t help me in any way, but the post’s title, “Set up a maven web project in Intellij with Spring and JPA – Part Six” seems somehow perfect to me.  Notice the “part six”.  How many blog posts are required for hello world?  Perhaps his 155 and counting steps are simply distributed into 6 posts of a more manageable 25 step each.  Anyway, a bit of levity for the 7:30 mark.
  156. I found this wiki, which seems to indicate that this would all be much less comically difficult in the Ultimate edition.  Somehow, I’m not intersted in giving money to anyone that has anything to do with this.
  157. After another 20 minutes of fruitless googling, I bite the bullet and do the manual copy.  It only actually takes about 5 minutes, but I just can’t wrap my head around the fact that the IDE knows exactly where these JAR files are on the disk and exactly where my lib folder is, and yet the only way to get those files into that folder is for me to open up two explorer windows and copy/paste all the jars.  The mind boggles.
  158. It works!!!  Hello World (or really, just anything) up and running in just 8 hours with 158 easy steps!!!  It’s like


Setting up for Microsoft Web Development in Many, Many Fewer and Actually Easy Steps

Here are  the steps I followed for Microsoft’s ASP MVC:

  1. Downloaded and installed Visual Studio.
  2. Went to File->New Project and chose ASP MVC project (“Internet Application” template).
  3. Hit F5.

Yep. That’s it.

Threats To Validity

Is this a fair assessment? I’d like to address a few points that I can imagine people raising. First, while it’s true that I’ve been doing a lot of .NET development over the last few years and not much Java development, the overwhelming majority of that work has been desktop development in WPF and a bit of Webforms, so that gives me no experience setting up an ASP MVC project, which means I actually have more experience setting up Java web projects than ASP MVC projects (though a lot has no doubt changed in the last few years).

Another consideration is that I’m using the Community version of IntelliJ instead of the paid version of IntelliJ or using Eclipse. These are valid points, though with Eclipse, it’s been my experience that things are no less of a headache to configure. I also feel as though this is not a significant mitigating factor because of the sheer number of tutorials I encountered for both Eclipse and IntelliJ that had half a dozen or more different posts in sequence for “getting started with web development” or some such thing. As for the paid version of IntelliJ or anything else, there would be a high degree of irony to needing to pay for something in the Java world that you get for free from Microsoft.

Finally, and perhaps most up for debate is whether or not I’m just an idiot (or at least too much of a “noob” to figure things out). Perhaps I just don’t have the programmer chops to do something that an expert could have done quickly. I fully acknowledge that this could be argued (and I’d love anyone to give me time saving tips for next time), but I’d say it misses the point that I’m trying to make here. And that point is that an extremely complicated setup discourages adoption and use. I’m an experienced, polyglot developer that has previous web development experience (even if I am also an idiot), including J2EE experience, and it takes me 8 hours over several weekends to get this going. Imagine how it might go for someone new to web development or just development in general. They’ll try to set things up, get frustrated, look for web tutorials and see things like “Getting started with Java/Spring/etc part 22”. Their next step will be to download Visual Studio and start an ASP project or to download Apache start writing PHP.

Take-Aways

Part of the beauty of Java and its stack of FOSS technologies is that it’s an alternative to Microsoft’s “golden coffin”. You have tooling options for everything you might want to do. Choose your web server, your IDE, your IoC container, your web framework, your runtime, your development kit version, etc. And not just that, but you can mix and match versions. Nobody tells you the ‘right’ way to do things — you can pick all of the options that work for you.

However, it’s important to recognize that this incredible flexibility is great for someone already immersed in these technologies, but daunting and discouraging to someone who isn’t. To this person, it’s pure, confusing fragmentation. Someone who wants to write a hello world app is going to say “what do you mean Ant v1.2.3 doesn’t work with Maven v4.5.6 and JUnit 7.8.9 on windows — I don’t even really know what those things are, I just want hello world!”

Something I’ve noticed that results from this too is that developers come to view understanding how to navigate this setup minefield as a badge of honor. Somewhere in the Java setup steps, I referred to this as “Emperor’s New Clothes” kind of tolerance for complexity. Everyone immersed in the world is afraid to call something out as byzantine and convoluted for fear of being labeled a newbie or lacking chops. But having battle scars from spending weeks configuring a development technology time and time again isn’t a badge of honor — it’s indicative of a problem in tooling.

Now that I have Java set up and finally working, I’m actually excited. I love developing in it. I like the language, I like the choices that I have with it, I love IntelliJ as a tool, and I like that I can work on any OS I choose. But I don’t think we need to settle for this horrendous “hello world” experience to have customizability. I would love to see work done on something that preserves all of the flexibility and power but allows developers to go to a site, download something, and then have a working java web setup. Something that has roughly the same number of steps and complexity of the Microsoft process (or the PHP process, which would be pretty close) would be ideal and perhaps even essential. In a world where the competition offers setup ease that allows developers to be up, productive and tweaking in minutes, a confusing process that spans hours or even days is a sure path to irrelevance and obsolescence. Maybe this already exists (and please someone correct me if I’m just not aware of it — seriously, I’d love it), but it seems doubtful given the number of entire series of posts dedicated to basic setup. If it doesn’t exist, it ought to, and not to stop me from grousing but for the future of the technology stack.