Why you should NOT use a web framework

I honestly can't believe I just wrote that.  I have been a huge proponent of using frameworks for a long time now and I still think they are valuable.  There is great value in frameworks and proponents have written about why you should use them ad nauseum.  Every conference you attend will invariably have a session or two on the state of web frameworks, new web frameworks, and how they are fixing all the things that have ever sucked in the whole world when writing web apps.

B.  S.

Like I said, I do believe in web frameworks, but many developers start the process of building a new web app with choosing a framework before even evaluating the need for one.  You don't need a framework to build a good web application.  I find the arguments of "plumbing is done for you" and, "you get reusability" to be unrealized potential and often over-complicate very simple concepts.  Before adding complexity to an already complex system, you need to make sure you are actually going to use the features that create that complexity.  When is the last time you rewired struts application inside the struts-config.xml so it did something different or reused an action and forwarded somewhere else when you were done?  Those kinds of things are just generally not done and if they are it's a lot more painful than advertised.

One reason I like frameworks, and what I see is the most useful reason to have them is that you can throw a whole bunch of developers who come from different backgrounds and different skill levels and, since they have to fit into the framework you choose, you generally get similar output.  That said, just because Struts or Seam or Shale or Stripes or Spring help you implement MVC doesn't mean you actually get MVC.  I can't tell you the number of applications I've worked on where the entire concept of the separation between view and control layers is just lost.  When you tell me it's MVC and it's not, it's almost more confusing than if you just throw up your hands and say, "stuff is everywhere".

One of the major reasons not to use a framework is the amount of overhead required for additions and changes.  I know... this is supposed to be one of the benefits, but why is it that a simple change to a theme requires a change to the struts-config.xml, the tiles-defs.xml, the Action class, the ActionBean class and so on?  In some web apps, the overhead is reasonable.  In others, I can't actually justify it.

For instance, if you are working in a portal, the portal IS the framework.  Why do you need to use a framework INSIDE the framework?  Then you start matching up spring with struts and the amount of indirection makes it very difficult for a new developer to come into a project and trace through what is actually happening.  If it takes more than a couple weeks for a new developer to be productive in your environment it's time to take a look at the complexity of the application and make sure it is warranted.  Could a new developer trace through the code or would they be stuck because it's not apparent that you are injecting values with Spring or using some AOP concept because the original developer thought it was pretty cool.  This is also a reason I don't endorse the ExpandoMetaClass functionality in Groovy.  Its neat that you can override methods but if you can't expect a class to function the same way every time, you are really opening yourself up to a lot of unnecessary issues.

Author and speaker Scott Davis at the 2007 No Fluff, Just Stuff conference said something so ridiculously simple that I almost dismissed it as obvious the first time I heard it.  If you are trying to decide what web framework to use, stop deciding and don't use anything.  Then if you find that you need it, add it later and do some simple refactoring.  If you hit the hardest problems first and you get through them without using a framework, it's likely you won't need it.

The one thing this type of development requires is consistency from your team.  If you are a very small team, keeping things under control is easy.  If you are more than 5 developers, it will be a little harder to make sure your developers are following good design principles or you're going to end up with a mess.  The thing is, I've seen so many web apps that use frameworks and are still a mess, I'm starting to be convinced that they don't actually prevent the mess, they just structure it.

Lastly, if you are going to use a framework go for simplicity over bells and whistles or configurability.  Most times, configurability is a very difficult thing to accomplish, it adds a ton of complexity, and the goals are often not realized.  By the same token, bells and whistles are often more trouble than they are worth.  The more focused your use for a framework, the more value you'll actually see from it.  I agree with the idea of deciding how to build your application first, then pick the simplest possible framework that allows you to accomplish your goals where one of those choices is no framework at all.

How to pick a log level

While I, in no way, feel that I am the expert in this area this is how I select which log level I use for a message.  The number of applications that fail to have a coherent strategy for this is mind boggling.  Logging should not be a second thought or something that doesn't matter.  Especially when fixing a bug is extremely time sensitive, the more information you can concisely pack into a log message the better.  So here are the guidelines I use for selecting the log level I am going to use.

1. Debug - Messages necessary for debugging a piece of functionality.  A value of some sort should always be appended to the message as there is very little that can be gleaned from the state of the application if you don't know some values.  If there is only one concatenation, I am not concerned with enclosing it in isDebugEnabled, but if there are more than one, if you have an object that calls toString() or if you have multiple log statements, it should be enclosed in isDebugEnabled.
   
2.  Info - Informational messages, can be anywhere but these should be used very infrequently.  These should not be concatenated so there is no real reason to use isInfoEnabled.  An example of an info message would be to notify a user who is watching the log that a long running process has finished or something like that.
3. Warn - Use these whenever the application is in danger of getting into a state that could cause an issue.  For instance, if a call to the database returns 2 values when it should have only returned one but it is still valid to just take the top one, it would be prudent to log a warning to say what is happening so, if it ends up causing a problem we can see it in the log.  Also, warnings are typically the default level used in production applications by default.  That means that, from warn on, you can usually count on the message getting logged even in production.  When choosing if I'm going to append information from the state of the application, I try to be very careful to take the impact of that decision into consideration.
   
4. Error - This should be self explanatory.  I will stop short of saying this should be in every exception handling block, but it should be in most.  At the very least it provides a way for us to know when an exception occurs where it is normally swallowed.  I will say that we should NEVER, EVER swallow exceptions.  By swallowing, I mean: try { ... } catch (Exception e) {//no code to handle the exception}.  A log message is the very least we can do.  In addition, the method log.error(String message, Throwable t) is the only one to use here.  Do not append the output of e.getMessage() as the really useful information is in the stack trace and should be captured.
5. Fatal - I don't think there is much reason to do this in web applications, but if we do find a place, this is for problems that will probably take the server down.  Losing connectivity to the database would be an example of a fatal exception where we would need to restart the machine.

There are two caveats to this list.  Some loggers include a trace level.  I feel this is unnecessary and, if it is actually done, should probably be done by injection with AOP.  The idea of cluttering up the code with "entering this method... ", exiting this method..." makes me shudder.  If I wanted to read through 25 lines of log messages in order to get to the real code.... well... I don't want to do that.


The second caveat is some applications have a monitoring tool like Nagios that looks for errors and sends out an alert.  If this is the case in your system, you probably either want to be discrete with your use of error, monitor fatal instead of error or implement your own log level for bugs that are serious enough to set off a pager at 3 am.  I think, in most cases, I personally like the 2nd option because most applications have no need for Fatal and, when you do get one it is cause for serious concern.

So that's my method.  Perhaps some of you out there have others.  Remember, sharing is a good thing. :)

Related articles by Zemanta

• Random thoughts on Logging (sdk.org.nz)

James Gosling leaves Oracle

There's not really much good that can be inferred from Gosling leaving Oracle and his comments don't do anything but solidify that inference. 

"As to why I left, it's difficult to answer: Just about anything I could say that would be accurate and honest would do more harm than good," he said.

Really?  This doesn't give me great hope for the direction Oracle is steering Java.  If mod_plsql is any indication as to what an Oracle influence on a programming language would be I think those of us who make a living writing Java code may want to start expanding our horizons with more urgency.  


In my opinion, as long as they leave the JVM alone they can have the language.  As more and more alternatives come along, the language itself seems like a detail.  It's one of the reasons I think Microsoft's decision to chase after Java with C# is fruitless because they are chasing a dying language.  Dying... but far from dead as so many others are quick to call it.  Java is used in almost every sector of every business world-wide.  Languages like that don't just die.  Disagree?  Why then are people still writing new applications in Cobol?  I believe that there are some businesses that will still be using Java about 20 years from now.  However, for better or worse, the fact that Oracle has their hands in it means it's going to change... somehow.  More and more it seems like those changes don't jive well with the old guard from Sun.

http://www.reuters.com/article/idUSTRE63B4HV20100412

10 Useful Google Spreadsheet Formulas

Ran across this one in my reader today and I realized I could probably replace half the crappy software built for investors today with a Google spreadsheet and the Google Finance functions.


http://woorkup.com/2010/02/19/10-useful-google-spreadsheet-formulas-you-must-know/

Staying on topic - an off topic rant

Why is it so difficult for bloggers to stay on topic?  At CheckedException, I really try hard to keep the posts focused on technology because that's what I said I was going to talk about.  To me, it's like a contract... I tell you what I'm going to say, you decide if you want to read.  You may read a few times and think I'm full of crap, but at least I've fulfilled my contract with you and, of course, you're free to stop reading at any time.

To clarify, I'm not talking about the occasional off-topic post or rant(like this one) where you have no other outlet but your blog.  I get it.  What annoys me is when the incessant posts about your trips, your skiing, your kids and all the rest of the things in your life start to outnumber your posts relevant to the reason I subscribed to you in the first place.  Most people subscribe to your blog for the content, what they might learn, to get a pulse on what people are thinking in the industry, and so on.  To me, if you are a technical blogger and your only recent posts are about your day skiing, you have broken your contract.  I told a fairly popular blogger that one time because his recent posts were all related to politics or skiing, or his kids, and just about everything else BUT technology.  His response was, "I'd be happy to give you a refund."  Cute... but missing the point.  Unsubscribe.

Of course it's your blog and you can write about whatever you want.  But if you tell people you are going to write about one thing and then you write about something completely different you have failed those of us who subscribed to your blog in the first place because we thought you might actually have some insightful things to say.  When you use your blog as a sign that says, "Hey everyone, look how frickin awesome my life is!" I start to think that if I ever had to have a conversation with you it would end with me punching you in the face for being a pompous douchebag. 

Jealous?  Sure,  I'll admit that I'd love to play hookey because we got 15 inches of powder the night before.  I just think I'd tell everyone about it on Facebook rather than over my blog where I told people I would be writing about technology.

I'm not asking for you to not have a life.  I'm simply asking you to stay on topic and, if you want to write about something else, start another blog and for the love of semicolons, keep the RSS feeds separate!!!