Keith's Web Blog RSS Feed

why java sucks

Mon, 02 Jul 2007 10:46:04 -0600

my current project has revealed to me what i kinda knew from beforehand: Java blows cock. maybe i'm inexperienced with it or am not knowledgable enough to make it productive for myself, but compared to scripting languages, Java is a REAL fucking pain!

let me justify myself a little. Eclipse is a cool tool. but it's so fucking PHAT that unless you have a shitload of memory, you'll only be able to get that plus a few more items loaded on your desktop. i think this mostly stems from the fact that Java is such a memory hog. i don't know how people can optimize with Java in terms of memory. waiting until the garbage collector kicks in just doesn't cut it for me either.

then you have library dependency hell. if you're not using a good IDE like eclipse (or if you're into torture by doing everything by hand), you're pretty much screwed when getting everything together. there was, for instance, a nasty little problem with the antlr jar file that i found against WebLogic. if you use Hibernate and WebLogic together, you're going to run into this problem. solution? make antlr appear before WebLogic's version on the classpath.

then you have the monstrous XML configuration hell. no wonder Ruby on Rails is so popular. because you have to package everything up into an ugly little war file, you can't simply put all your configurations into one spot easily. if you're running in production, you have to externalize some configuration files and even then stop and restart the web server. geeze!

and then there's the whole J2EE server vs J2EE server crap. i thought the whole idea was to write once, deploy anywhere? you still have to deal to some level with reconfiguring things (at least with our application). for instance, the antlr issue with Hibernate. and don't get me started on EJBs.

the other thing Java severely is in need of is inlining or variable interpolation. variable interpolation would make one's life so easy. also, i just can't see the point in having types in Java for webapps. you end up being forced to check to see if a string is a number and then converting to a number regardless rather than doing some magic during runtime like PHP or perl.

the thing that miffs me the whole is just the whole process of having to compile, war, and deploying something in several different steps compared to fixing a file and refreshing a page.

someone once told me that Java is the new Cobol. Can we call Java COBOL 2.0? i'm starting to believe it....

More Java Failures as a Web Language

Fri, 20 Jul 2007 22:13:19 -0600

Last night, I had some JSP problems that were quite difficult to debug. The problem was that although the JSP failed to compile, the stack trace was not specific and one could not determine where the actual error started or ended. Instead, the error log showed a simple, "overflow error." How can one detect what part of the JSP page died at? The fact that JSPs are compiled into a Java class disallows one to easily locate the problem in the page, especially if one has to go through a long log file. Not to mention making the changes, either re-waring/deploying the file and waiting for the page to compile is quite annoying, at least for prompt development.

I'm being convinced daily that Java is a terrible language for the web. Even with all the various frameworks and such, the incredible number of dependencies and difficulties with configuration and dependency hell makes Java incredibly brittle. It's without a doubt a horrible language for small sites, considering the overhead.

At this point, the only chief advantage I truly see in a language like Java is the large amount of corporate support, services and major API/frameworks and systems. However, as more open scripting languages mature, I think they will slowly overtake Java once large employers see the advantage of the agility for development. You can still get stability through scripting, open languages, just not the support (which to me is massively overrated).

These guys blow hard

Thu, 26 Jul 2007 08:41:52 -0600

My project is excrutiatingly painful for one reason: these goobers. I'm surprised they have been able to convince other companies of any sense of quality whatsoever. Sloppy execution, terrible programmers, zero design skills. If you are an employer and are looking to outsource, make sure you steer clear from this group.

Java Is NOT An Agile Language

Tue, 07 Aug 2007 09:40:50 -0600

My big boss asked me why my side of the project has been taking so long. Why would a business layer be so hard to code up? Why is the testing ridiculously slow?

My answer: Java doesn't help this.

Perhaps, it's my level of expertise in the language, but after dealing with this project, I've come to realize just how HEAVY Java can be. I haven't had a chance to work in detail with the latest version, so I can't say that some of the newer features have made it better (I'm sure it has, but there are still deficiencies in the language). It could be my lack of experience with Eclipse. Maybe I'm not utilizing the right plugins and doing far too much "hand coding" in terms of boilerplate code.

No, the problem is that the language is too bulky and takes itself too seriously.

Read that statement again. Especially the last part.

Let me provide an example.

Let's say you have a primitive type that's supposedly a char and is saved into the database as a number (0 or 1). so in reality you need an int. But let's say another object requires it either as an int or be turned back into a string. So if you try to parse it, you might get an exception rather than letting the language auto-convert it. So you're doing many things here: 1) checking if the value is null; 2) checking if the type can be converted; 3) potentially converting it over to another type; 4) converting it again. And you may have to wrap all these operations in a big try/catch block. If you're working with a database that may contain null values, and you're forced to use primitive types, you're royally screwed. I mean, all you're trying to do is guarantee a value type, but you still need hundreds of checks.

This is just awful. And it's just for one value.

What if you have 40-50 values? How much of this do you have to deal with? What if you have to deal with several operations that require you to do this 40-50 times? What if there's no easy way to loop through the parameters in your object without having to take out the equally bulky Reflection API?

In perl, since objects are glorified (or blessed more specifically) forms of hashes, arrays, scalars or globs, you could, especially if you use a hash, provide a method that can loop through, utilize the Fields pragma, and easily get the same benefit.

In PHP, you can utilize variable interpolation by doing something like this for a dynamic method call:

$obj->$method()

You're pretty much out of luck with Java (at least in doing some easily the same way). You can't naturally take advantage of in-built features to really help you through these situations.

Worse yet, you might be forced to code declaratively in XML because it's nearly impossible to do something easily and dynamically in Java. Take Spring and Hibernate as examples of this.

Out-of-the-box, Java is just a monster of a language. You are forced to employ various plugins, IDEs, frameworks, etc. to really get any significant and immediate benefit. And that can take a while to do as well.

Notice the words used there: "a while." That implies time and implies not moving fast, which in turn implies lack of agility.

More of my friends are turning towards languages like Ruby and being empowered from getting more work done through frameworks like Ruby on Rails. I think people who continue to use Java are quite arrogant in believing too much in Sun's marketing. Java only is good in the hands of those that use it. But for me it's too difficult to get any real benefit that I can see.

The truth is, at the end of the day, you just want to be productive. The language is truly irrelevant as long as you and your peers utilizing it understand in detail how to get the best out of it. I for one see Java as being verbose, cumbersome, and unnecessarily detailed. The flaws that kept a lot of C/C++ programmers away I think never were truly addressed. C/C++ programmers have some advantage over Java people since they have more power and speed naturally.

Overall, if you need to execute something quickly, consider NOT using Java to do the job, unless your people are extremely adept at it. Mine aren't, nor am I so I think I will continue to stay away from it where possible.

Programming (Language) as/is a Philosophy

Wed, 08 Aug 2007 18:11:57 -0600

I was reading something on Perl packages from the O'reilly Perl Programming Book, and one paragraph really stood out:

Whenever you're tempted to do any of these things, you need to sit back and think about what will do the most good for you and your neighbor over the long haul. If you're going to pour your creative energies into a lump of code, why not make the world a better place while you're at it?

This can really apply to any language. The fact that this statement occurred in the Perl book made me realize the connection of programming, programming languages and their attribute as a philosophical mode of thinking.

Think about the flamewars between Java and scripting languages such as Perl. The core arguments that Perl people have against Java is the verbosity while Java programmers call Perl programmers obscure and lacking thoroughness. Shouldn't the real result be about results you bring to a business?

All of these statements above are loaded philosophical questions. The best programmers, in my view, are those that have an issue or stake involved in such questions. Should each little optimization be so critical for a business? Why not just lie to the company and say optimization is impossible that issue?

Again, it's all philosophical. But the intention behind that philosophy is equally critical. The person who refuses to optimize places importance on immediate results at the sacrifice of performance so that his end of the bargain is complete. The person who prefers verbosity emphasizes thoroughness and process. The person who favors obscurity prefers succinctness.

I think those who practice programming philosophy rather than simply programming are those who are looking or have their own set of best practices. This is one area which isn't well defined. Certainly, there are tons of books, online articles and whatnot prescribing sets of best practices, but like any philosophy, there are numerous variations that really fit with a person's core value system.

MVC-B?

Mon, 08 Oct 2007 18:48:56 -0600

Having been working with web architectures for a while, I've come to realize that the common paradigm of MVC (Model-View-Controller) doesn't seem to scale too well in terms of development. My problem with this paradigm is that I've often run into situations where I require ways of improving the centralizing of business logic. Some people believe that the business logic should reside in the controller while others say that model objects should retain these characteristics. I feel that neither are sufficient for this purpose.

If we look at the strict definition of what the Model and Controller are, we can see how the business layer truly does not fit either. Models represent abstract entities of the business. They support some logic but are themselves simply entities. They are not themselves processes and in reality represent some row in a table for a database. Controllers are a form of the Observer pattern and signify a simply notification and kind of triggering device. In the web paradigm, they receive an event with information (the request), perform some limited data manipulation and hand off the data to the view/response for display purposes. However, I've found the controller to be more or less a throwaway object with limited purpose in the context of web programming. If you house all your business logic within the controller, then extending this logic to other objects becomes difficult, and even more difficult during testing.

In a layered architecture, we're now encountering several common but additional functionality in authentication, authorization, validation and some form of business logic (usually CRUD). I tend to place the security aspects like authentication and authorization as being more at the controller level rather than making them strict business functionality (although the actual code can be housed in a class or package that handles authorization and authentication). Next, I tend to split most validation off from the business logic. Of course, some validation is required at the business logic level, for instance checking to see if a credit card number already exist in a database prior to creating the card. But validation, for me at least, in the web sense takes into account simple, non-application specific type of rules such as checking if a string consists of all numbers, ensuring that an input field exists, or disallowing for non-email address formats using a regular expression. I usually insert this piece of logic prior to the routine in the controller that handles the processing of the incoming data.

The business logic layer though is quite ambiguous but I think that EJB's notion/use of session beans to handle the lifecycle of entity beans is what I would consider to be appropriate. Concretely speaking, I see this layer to be the one that manages the lifecycle of the model, not the controller. Lets say for instance that you wanted a routine to create users. If we placed this at the controller level, we might be limited to using one controller for this function. What if we wanted to expand this to a web service? What if we wanted to expand this to various types of web services that outputted various formats? We'd either have to inherit the controller and make that method private or do something funky. In some cases, we may not even have that choice because of how a framework might limit what we can do with that controller. In those cases, we might be forced to create multiple controllers with no chance to extend. So in the end, we'd be forced to do a lot of copy-n-paste code.

Not very reusable.

The business layer would eliminate this notion by providing a middle ground. It's not a proxy for requests. I see it as multitiudes of mini-functions that do a single operation. Method names would be at a high level such as createUser, removeProject, isAccountEmpty, etc. From this, you could easily compose other bigger functions. For instance, a removeUser method might invalidate or remove all related entitlements such as projects the person owns or access rights.

I think one of the difficulties of a business layer is the formalization of how it should be used. If we again compare this layer to be the EJB session bean layer, this situation would make these objects stateless. I don't see much chances for object inheritance here. Perhaps, these objects would have only a few common features like logging, or access to factories that create models or services. Beyond that, these objects would be essentially static method calls that perform no more than one operation. They would be able to interact with the controller, service and model layers using value objects or associative arrays to communicate between layers. Meaningful exceptions should be thrown to the controller level or between business calls. For example, one could have a BalanceLessThanZero type of exception if somehow a person was attempting to withdraw more money than he had in his bank account.

I think this concept needs to be introduced to the web paradigm and that the MVC notion updated overall to include the business layer.

static data members and inheritance in PHP

Tue, 09 Oct 2007 18:23:34 -0600

i found something interesting the other day using PHP. let's say you have a base class (which would be using the singleton design pattern) with a static data member called $instance. later, you inherit the base class with another two additional classes and have them utilize the $instance data member (say through setting it in a method called getInstance()). originally, i had thought that each instantiating class would get its own copy of $instance. nope!!! because the data member is static in the base class, it really only pertains to the base class, especially when you start referring to it as self::$instance.

i'm not sure if this is a good explanation of the situation, but i learned a truly valuable lesson today: be careful when using static data members and inheritance. If you intend to do some sort of polymorphism with the static data member, it probably won't behave as you'd expect.

Zend Framework

Wed, 10 Oct 2007 08:44:01 -0600

I'm currently hacking away at the Zend Framework, which is probably my one millionth framework (okay, maybe not that many. I think I'm up to five or six now). While it's got a lot of jazz, the thing I've come to realize is that these frameworks are nothing more than a bunch of hammers, nails, boards and glue lying around. You still have to draw your own plans to get a basic house going. Or in our case, a real workable website.

The thing I hate about some of these frameworks is that despite preaching good practices by componentizing everything (thus decoupling code), they never actually attempt to enforce on their users true good practices. For instance, the controllers provided by Zend can end up holding monolithic code and redundant. You can dump all types of business functionality within one controller and then potentially copy the same functionality into other controllers. Or your controllers may not necessarily follow the same programmatic flow that one may desire.

It's surprising that these frameworks are not more strict considering the depth of knowledge of web programming that has been developed in the past 10+ years. For instance, the main Zend action controller has a method called preDispatch which would allow one to place authorization and validation code that might be common between controllers. Well, considering that most controllers require authorization and validation code, why not just house part of that code inside of there in the first place? You're going to end up subclassing this class regardless just to create a base class that can be common between controllers.

Another truly annoying "feature" (or lack thereof) is the authorization and authentication methods that come with Zend. For authentication, you practically have to write your own adapter and wrapper just to get a simple login to work. If you want to use it along with a PHP session, you then have to draw together those components on your own. They only provide a thin wrapper just above the $_SESSION global, which still can be accessed. I don't really see a point.

Authorization is handled a little better, but you still have to provide the hooks. It's far too barebones to really be useful. You can employ it just to say that you're utilizing that piece of the Zend framework, but you're honestly better off just rolling your own authorization scheme.

The most annoying thing is that there's no out-of-the-box login controller nor controller that houses the authorization logic. There's no real hooks that allows one to tie their controllers easily into Zend's ACL components. You're practically on your own to put in something that probably has been done a billion times in very efficient manners. This is horrible.

Next we come to the validation piece. I've rarely seen validation done well. The Zend framework is no exception. It's nearly as bad as the Spring Framework's validation methodology. The problem is that you cannot easily do declarative validation. I basically want to say given a page, here are several fields and for each field, here is a set of validations with possible values to validate against. The Jakarta Commons Validator does a much better job, except the XML validation is a pain to use. Still that's the basic gist, combined with using something like Struts to automatically execute the validation piece. On the other hand, in Zend, you're expected to put it in the preDispatch method. I mean, if you already know you're going to expect validation to occur prior to an action, why not just strategically have a subclassed controller that comes with Zend handle the validation automatically? Although I think the Spring Framework's controllers suck for the most part, the one thing they did do correctly was provide numerous out-of-the-box controllers for various purposes. Zend only provides two.

The Model layer was probably the only piece that was done halfway decently. It's fairly easy to program and nothing I haven't seen before. Considering the popularity of some frameworks like CakePHP, Ruby On Rails, and Symfony, I'm quite surprised that Zend left out the scaffolding code. I avoided Symfony because I thought Plone and its scaffolding code was not handled very elegantly (for instance, forcing one to use their convention; legacy databases wouldn't be compatible). Still though, scaffolding is very important in this day's competitive and overdone framework laden programming community. It's shocking to see such a useful tool ignored (at least for now).

Again, my biggest complaint is that Framework only organizes the more web specific code from PHP into a more organized set of classes. I think Frameworks like these need to impose even stricter interfaces and have more useful tools or objects that are well known so people can concentrate on the application logic rather than writing additional wrappers to improve the convenience of using some of these frameworks.

Crappy Firefox/Prototype Bug

Sat, 13 Oct 2007 19:30:52 -0600

I just ran into a crappy Firefox/Prototype bug where headers larger than 10kb are dropped. Other browsers work fine without this limitation (ironically). It doesn't look like they'll fix this problem. This really bites!

Well, the solution if you're using prototype is the following. First upgrade your prototype to 1.5.1+. You might have to use the beta to get it working. Next, do not send the JSON data structure as part of the response header from the server. You have to send it as part of the body. Use "Content-Type: application/json" as your header. Then display your data structure.

On the client side, you might have to modify your javascript if you're using Ajax.Request and utilize the convenience methods that automatically serialize JSON. For instance, if you have a function that looks like:

var ajax = new Ajax.Request(
url,
{
method: 'post', parameters: params, onComplet: someFunction
}
);

then in your function called someFunction, you probably will need to do something like:

function someFunction(r)
{
var json = r.responseText.evalJSON();
// do something with the json data structure
}

i was using the other form of:

function someFunction(r, json)

so the inbound data structure wouldn't get passed if the size was too big. this is a pain and hopefully they can address the convenience mode too. but it was a real pain handling this.

on a similar note, if you upgrade your prototype, you may also have to upgrade your scriptaculous javascript. Additionally, I ran into a "too much recursion" type of error. Geeze.

I'm With Google On This One

Fri, 16 Nov 2007 21:29:41 -0700

Sun's only hand in development, Java, is being threatened by Android. I think the main thing is that Google is trying to move the standards away from the JCP. I've never been a huge fan of Java and I think their community process sucks. I don't know if that reason has been Sun, but I've always hated Sun's position with Java. Now, the article is talking about a potential lawsuit against Google. While I dislike the idea of any single entity running the whole show (in this case Google), I like Sun even less when it comes to how Java has been handled. I am hoping that Google's involvement here can actually provide improvements to Java, rather than leaving it a blotted SOB language to use.

Skilling Up!

Tue, 20 Nov 2007 09:24:04 -0700

Right now, I'm teaching myself some ruby. I've mucked with it in the past, but I've decided to pursue increasing my python, ruby, c/c++ skills. i'm pretty satisfied with my php skills now. i just need to figure out how to use CakePHP eventually and I'll be set. With ruby, I just got through basic inheritance and some simple string manipulation. Syntactically, I like Ruby more than PHP, but I'm extremely used to coding in PHP now. However, the syntactic sugar of Ruby is slowly drawing me in. Lots of shortcuts rather than elongated function names. I hope to get to Rails sometime in the next few months. Eventually, I'd like to put together a simple Rails application just for fun. Maybe I'll build my own music/movie organizer AJAX website. The same with Python in terms of getting into it for fun. I'm not a big fan of Python's syntax compared with Ruby, but Google's use of it along with Zope look like compelling reasons to give it a try.

I'm not as sure what to do with c/c++ in terms of a project. I always wanted to participate in building some KDE project. Not sure what yet.

Got some cool chances to work with a few new toys at work. Got Samba to work (finally!) It's nice being able to go between my Kubuntu system and my laptop running XP Pro and copying files over transparently.

Setup a Subversion repository with WebDav. I want to get a better bug track system or something that'll tie into Subversion. My friend suggested a site for this, but I don't like the fact that they use their own login system. I want a centralized login system that utilizes the same data. Don't want to have to hack a system for this purpose.

Also, worked a bit with Phing. Phing is like Ant for PHP. Only they're still generations behind in terms of support. I had to write a bunch of my own plugins. But that's the cool thing with it. Maybe I might contribute to Phing in terms of adding my plugins to their repository.

Lastly, I've worked with this gzip'd compressed XML data unix set of command tools called Musashi. It was a major bitch to set up. But I wrote wrappers in PHP to be able to interface with the tool. Not native, but still good enough for now.

The Anemic Domain Layer Or A Better Business Layer

Thu, 22 Nov 2007 22:06:16 -0700

I haven't yet checked out Martin Fowler's Enterprise Design Patterns book, but he has a small article online regarding the Domain/Model layer. Or rather he talks about the "Anemic" domain layer, which in short are simply model objects that has getters/setters without any methods for business logic. He then criticizes the notion of a business/service layer that places all the business logic into place. What he doesn't do (at least in the online article) is demonstrate examples of this anti-pattern both in practice and in resolution.

I do think he supports frameworks like Hibernate, which are pojos that perform some object-relational mapping duty with the support of a service layer. I decided to check out his book on Amazon and read some reviews. It seems that some of this theory is older, maybe geared towards the old EJB model, especially for the earlier versions of EJBs where people would pass around value objects to avoid the overhead associated with setting/getting each attribute (because of the whole remote invocation issue).

That said, it would be nice for him to update that section. It's hard to say if his beliefs still apply to ORMs like Hibernate, ActiveRecord, etc.

I have my own homegrown ORM with some operations that might seem like "business logic." But what I can't stand is this ephmeral phrase of "business logic." What is it? The way I structured my application is to use a business layer similar to how Session beans would act as a facade for managing entity beans and keeping all "business logic" at this level. So I would do things like use the business layer as an interface to the domain layer. I've found this methodology to be very effective. If I put the same logic in my controllers, the controllers become difficult to test and are almost always throwaway objects. If I put that logic in the domain layer, then I get tightly coupled model objects.

However, the business layer ensures reusability of operations that are not very object oriented. I read some criticism that this notion isn't very "object oriented" and that it's more procedural. I don't see a problem with this idea. You do lose to some degree the object oriented nature of a business layer. I've found that the business layer has minimal properties except for some injected services (like logging, the models and some utilities). But the business layer is the magical component that truly decouples each layer, allows for a significant amount of reuse, provides the critical area for easy unit testing, allows tremendous reuse because of the lack of coupling and is damn easy to code. How this notion is problematic in software engineering, except for some OOP purist, is beyond me.

Sadly enough, I rarely find good examples on the net for handling this. Here's how I handle it:

My business layer truly is the real "middle" layer as it sits between my controllers and model layer. It's a 4th layer that provides more complex functions of organizing things. It's the glue between your controller and model layer. In coding practice, I use statically instatiated objects. All methods are static because there's no reason to keep state at this level (similar to a stateless session bean). The methods are very operation based; that is, more functional than anything.

My method signatures are composed of associative arrays, other model objects, or a few set parameters that are typed. I tend to avoid having large numbers of parameters since signature changes make the interface very inflexible. If I anticipate a large number of optional parameters, I'll pass in either an object to enforce the types of parameters that I want passed in, or I'll pass in an assocative array that contains a more flexible data structure to mimic what I want being passed around to this layer.

I try to keep my functions/methods simple. Only one operation per method. I try to restrict my methods to be about 5-7 lines per method. That keeps the code very readable. At most, these functions should not exceed a page. You want to ensure that your code is readable and understandable. The more it does, the more you want to split your operations into smaller methods, even if you don't anticipate reusing those functions. Moving them into private methods is a good idea since you can test the operations one-by-one; or it's best to just make them into public methods since obviously you won't be able to call those private methods from the unit test.

It might seem silly to write a facade that might seem to only delegate a call to another function. However, having this interface is a good idea. As it's been stated many times, doing it in this manner ensures that your implementation details are kept well hidden. For instance, if indeed you move your call from one ORM to another (like say I get rid of my ORM for something like Plone), then I still don't have to change the code at the controller layer or whatever calls the code. The code stays the same at those levels, only forcing me to switch out the calls inside the business layer, not outside of it.

The other thing about this is you are insulated by providing only what's needed. You don't have to write CRUD for every single operation that you anticipate. Only the ones that matter. You can trust your ORM layer that it will do the heavy lifting while your business layer manages the high level calls. For instance, imagine create a new project. You might have to do some complex tasks like creating a new user, add tasks, add people to the project, etc. all in one operation. If you did this at a controller level where the controller had direct access to your ORM layer, you might be looking at numerous set and save operations that'll bulk up your controller layer. What happens if next you want to expose similar operations to a web service layer that can return formats like JSON, XML, or HTML fragments? You'd have to copy and paste that code three more times. Now, you have those operations in four different places. Trust me, I've done this and found it nearly impossible to modify the code after a while because I'd end up search and replacing the code, rather than strategically adding a single call to a controller.

In short, I don't think it's a sin for this type of layer to exist. In fact, I think it's a sin that people are still thinking in 1999 and haven't made a lot of progress to focus their efforts on developing the notion of a business layer. I've seen some new enterprise components like rules engines to do bits and pieces of what we're talking about here. However, I don't think they do all that great of a job. All they do is introduce more hardware, software licenses and complexity in a truly easy-to-solve type of problem.

Either way, I really hope that someone who's far more experienced in the field give an appropriate and lengthy explanation on the proper way of dealing with this solution. I think my way is better and I challenge people out there to provide better examples to show me where my thinking can be improved. If that's the case, please sign up an account here, and add your comments freely.

Validation Web Architecture As a Design Pattern

Sat, 24 Nov 2007 23:56:17 -0700

While I do think that the current standard paradigm of web programming should move from the MVC pattern to the MVBC (Model-View-Business Logic-Controller) patter, AJAX introduces a new complexity that makes me think that yet another tier can introduced: the web validation tier. I've seen business rules engines which do something similar to this, except that the interface might be quite complex. It does add yet another middle tier to an enterprise web architecture. However, it's still in its infancy to really see the direction overall in all but the largest architectures. Add on the cost, I don't know if most shops would find it worthwhile to add to their portfolio of systems.

I do see two layers in a business rules engine that are worth talking about, which are the basic business layer and the validation area. I've talked about the business layer before in how it should be implemented. The validation area is something that I haven't discussed yet.

The validation area is simply something that checks your inputs being derived from your inbound web request. Most rudimentary systems have something like this. Checking for empty fields, making sure an email address is formatted correctly, ensuring that a dollar amount isn't negative, etc. There are some libraries out there that can handle it such as Jakarta Commons Validation. Usually, they involve some web integration that eventually passes the validated info down to the processing layer.

However, with AJAX and web services, I'm starting to think that this piece can exist on its own server for processing. If anything it might just exist in its own layer because it's anticipated that this layer will get hit before doing the heavier processing at the business layer. While the processing at this layer might not be as heavy by comparison, this layer will be hit quite frequently. But at the same time, if AJAX is involved, you'll probably want to send a response back immediately for failure.

In the older web paradigm where you might use client side Javascript to validate the request before hitting the servers, you'd be performing double the work in terms of checking input. With AJAX, now you're implementing client side Javascript and still working directly with the server. So it doesn't really look practical to use client side checking anymore as you're already interacting with the server.

Because of this, it might be worth creating this separation in anticipation of the server receiving a higher amount of traffic with unvalidated input. But if the input is considered valid, you could pass the request down to the next tier (the rest of the controller level).

The advantages of coding your web applications in this manner are the following:

No more double coding of client side and server side validation
Consolidated logic of validation code
Not having to worry about whether or not your users turn off Javascript (if you're already using AJAX, then it's a given that they need Javascript turned on)
Input between the validation server layer and controller/business layer will be trusted
Easily able to allocate resources (servers, people) for handling a dedicated task, rather than worrying about where the validation piece should occur

The disadvantages would be:

Potentially more servers to handle
Yet another layer being added to an already heavy application stack
Some potential network lag between the transfer of request from your validation layer and your processing layer
More complexity in general

However, I'd like to note that this architecture really is meant for websites with extreme volume. I do think it's a good idea to split up validation from your web controller side and eliminating client side validation altogether if you're moving onto an AJAX type of platform. However, unless you deal with high amounts of traffic, you won't need extra servers or dedicated controllers for dealing with this.

Request From PHP: We Need An init() method!

Sun, 25 Nov 2007 00:02:26 -0700

One advantage of mod_perl and servlets over PHP is the fact that they have the ability to pre-load information on startup of the web server. Right now, I don't know if PHP has an equivalent but it's something that I'd like to see happen. The reason is that preloading allows some performance optimization by putting some processes or data structures into memory so that the users hitting the server won't have to take a hit. It's kinda like a cache of sorts. I do think that PHP keeps some parts in a cache in memory before eventually cleaning itself up. But you don't want something like this in all cases. It would be a very nice feature.

Unfortunately, in terms of hosting, this feature probably wouldn't be allowed since you really need a dedicated server for something like this. Imagine the memory consumption of some applications. A hosting company wouldn't be able to handle something like this easily. Not to mention people who require this type of setup probably need dedicated servers to handle these needs.

PHP is NOT The Next VB6

Thu, 06 Dec 2007 10:26:31 -0700

I saw this article earlier in doing a Google search for dealing with Anemic Domain Objects in PHP. I think the author is really off when it comes to PHP as being related to VB6. His main argument is that PHP's does not enforce OOP style programming the way .NET does (or some others such as Ruby on Rails, Java or #C). He even calls PHP a "Framework." He also mentions that for large scale projects, PHP is not a serious language compared with .NET.

I think these miscues focus on the wrong issue.
His write up targets mostly the issue of PHP not being serious as a language because the object support enforcement is non-existent. He claims that a lot of the internal procedural style libraries disengage PHP programmers from using more OOP programming, which apparently allows for highly scalable, enterprise-class software.

Let's be honest here. He's full of shit.

PHP's problems as a language being ready for the enterprise has little to nothing to do with not enforcing OOP structure. Actually, that's a huge benefit because the ability to learn something like PHP is far quicker than something that enforces OOP concepts like Java. PHP is primarily a functional language, and functional languages have been traditionally easier to teach than OOP languages. My old professor in college once mentioned how difficult it is to teach OOP to new computer science students. Just to create Hello World, you have to teach about OOP theories rather than just allowing something to use:

echo "Hello world";

Not to mention not enforcing the OOP paradigm simply allows people to build software quicker. You don't have to worry about transforming your object into byte classes or anything complicated.

That said, the real problem with PHP has been the fact that most people who are programming PHP do not typically (nor probably) have fundamentals in computer science to create large scale software. Any language can be faulted as being unmaintainable if 1) there is no architect guiding the younger programmers; 2) there is no vision nor design for the piece of software; 3) the people building and maintaining the software are simply "script kiddies."

From a functional perspective, PHP is one of the richest languages around, having numerous libraries that can support many enterprise related task. You have persistent DB connections, XML parsers, XSLT functions, SOAP, WSDL, caching, graphics manipulation, etc. As a language it can scale too as you can create your own cache or use the PEAR caching system or even use horizontal caching with the memcache piece. And you can't say that PHP is not worthy of large scaled projects since companies like Yahoo, Friendster, etc. all implement PHP in their online applications.

Him calling PHP a framework is ludicrous. It's a programming language. A framework would be Zend, PHP Cake, etc. that do enforce to varying degrees (depending on the framework) the notions of good design patterns.

To say that you cannot promote good design patterns with PHP is also ridiculous. I've been my own frameworks based on the outdated MVC models, using numerous design patterns such as business delegates, service layers, MVCs, singletons, factory/builder patterns, iterators, etc. Heck without some of the newer OOP features since PHP 5, I would've had a much more difficult time designing my systems.

I think a better comparison would've been Ruby on Rails to VB6. The thing with PHP is that you can use it as a decent teaching language since it has all the qualities of a decent programming language (you can even enforce types in parameters and do limited pass-by-reference in function calls!). With Ruby on Rails though, you're teaching a limited paradigm, not the fundamentals of a programming language where you can expand the purpose outside much of a web context. VB6 likewise was limited to GUI client and perhaps some server programmer. With VB6, you're limited in the type of paradigm you are programming so the type of thinking that goes into a VB6 application is more bent towards rapid prototyping, just like Ruby on Rails.

PHP provides you with the tools and basics to build enterprise scalable applications. Rails shelters you into a paradigm and makes you think that scaffolding is king, compared to understanding how certain fundamentals like types, function callls, etc. work in a regular programming language.

The other thing is that I just don't buy the excuse that PHP is bad in his context because of not enforcing OOP thinking. And his bad being the equivalent of not being able to build scalable applications. Well, so what would you call all those C and C++ systems out there? C++ does not enforce programmers to program in OOP like Java either. I've seen so-called enterprise level systems for trading securities written in C++, where everything looked more like a csh-script than some elegant piece of reusable code.

As I mentioned before, the language itself does not impose bad thinking. It's that people who adopt a language themselves were never good programmers to begin with and never learned fundamentals of design. I've been on both ends of the spectrum where I saw horribly designed (for lack of a better term) systems built with C++, Java or these heavily praised languages as well as partaking in building monstrously scaling open source systems like Ticketmaster. And I'm certain his much beloved .NET can easily fall prey to poor design in the hands of an incompetent programmer.

I truly wish people stop blaming the languages themselves in the end for poorly designed systems. The only thing languages offer is a slight difference in taste for syntax with a few more features here and there or syntactic sugar coating to make some developer's weener hard because they enjoy the mental masturbation of the puzzle like ways of twisting a language apart.

guitar hero, electric guitar, PHP script kiddies and Real Programmers

Wed, 02 Jan 2008 06:17:14 -0700

I read an infuriated blog post by this programmer who ripped up PHP programmers for not being "real" computer science people. He also bragged about his guitar ability, saying he could play anything (I doubt it). In the end, I pondered about the arrogance of such a person and brought two things that seemed unrelated together: guitar and computers. Yet the other piece that was missing was this guy's arrogance. A lot of so-called "real computer programmers" hate PHP script kiddies much in the same way that "real guitarists" probably hate the hell out of Guitar Hero.

When I look at Guitar Hero, it reminds me of these scripting languages that seem to devalue "true" computer scientists and their languages (the blogger in question only mentioned objects, closures, which I assume is "real" computer science). I mean, essentially you're making something difficult easier to do for the common person. In the case of guitar hero, you're supposedly making it easier for us to play guitar and be some rock god while being adored by millions of virtual fans.

Or is this the wrong way of looking at the situation?

I think a major difference in scripting languages and Guitar Hero is that scripting languages still allow one to create something. With Guitar Hero, you don't create songs, you barely imitate. And you're not even re-creating something, you're just faking being a star. The one thing about playing a real guitar that anyone who's spent significant time investing their energies into such an endeavor would tell you is that you can actually create art with it as opposed to this virtual toy.

As a guitar player and developer, I can see both worlds. As a guitarist, I realize that I'm not great but I'm still capable of writing small riffs and even having a tiny voice that originates from the way I hit the strings and frets. I've written my own riffs and even put them down on some recording mechanism at one point. I can never do anything like that with Guitar Hero.

But unlike Guitar Hero, scripting languages allow me to create as well. I think it's actually great that we have the capability of things like scripting languages that allowed us to develop so many applications within these past few years. I think scripting languages like Linux has done tremendous work in freeing us from the monopoly of Microsoft. So should so-called "real programmers" unmercifully bash people who earnestly work on things like PHP, but are still able to develop something that's useful to society?

I understand the anger in both areas, but I heavily believe that in scripting languages the anger is slightly misplaced. I think people in development should be proud of being able to create something. If people aren't bashed and are encouraged to improve their skills by continuing to learn how to make better systems, then the criticism is justified. But raw anger and insults don't go a long way.

Now, Guitar Hero on the other hand, is an insult. Guitar Hero makes one a poser because it completely dumbs down the art form of what a guitar is about. If Guitar Hero was able to enhance the ability to create music, it would contribute something to society and culture.

Being A Programmer

Wed, 02 Jan 2008 06:55:13 -0700

I'm linking a very informative talk done by Steve Wozniak about his days that launched him from a hobbyists into someone who helped partake in shaping the world of computing. Woz is a very interesting person to listen to as he reminds me of the idealistic computer prototype person. Some characteristics I got in watching the video was that he enjoyed tinkering, had a solid love of electronics (computer's for computers sake! aka the Dilbert syndrome), his economical/environmental way of thinking in terms of building systems (i.e. constant optimization, working off of minimal parts), natural math skills (scored 800 on the SATs) and started out as a precocious child mostly due to his father. Of course, there were some other more "negative" stereotypical qualities about him as well, namely his lack of business saavy and unwillingness to move towards management (read: selfish hobbyist). However, in coming across many of the better computer science people or engineers and companies that look for engineers, Woz fits or maybe even created the mold of what the contemporary engineer is. He even admitted that fundamentally you had to start at the smallest pieces like the atoms, physics and math.

After watching him and reading the arrogant developer's blog today, it struck me how this characterization of the "ideal" programmer is quite limited. I can certainly see how things had managed to work out for Woz as well as many other people who have been carved in a similar domain as Woz. However, the "purist" viewpoint of computing is what has stereotyped and hurt computer science for a long time and something which I believe needs to have the stigma lifted.

First, this typing of a programmer pretty much narrows who can join the field. While I've done this myself during interviews, many interviewers will practically paste potential candidates because they don't match every single trivial buzzword from their novel tests. I think it's hurt a lot of candidates' pride going into an interview and then getting slammed by the egotism and bigotry of some developers. Not everyone was able to afford the best schools nor at times been allowed to take the same classes. But a lot of people want to be given that chance to prove themselves. It's unfortunate that earnestness doesn't mean much to people.

Another thing that got me was how Woz enjoyed the trivial at times. It seems like he was more interested in solving complex problems rather than practical problems. I've noticed that the typical computer science guy enjoys trivial, mind warping problems that in the end have little to do with improving the quality of life nor solving a real need (both of which are business cases). Some of the things I've seen being produced out of places like Google such as Google Mars honestly have little to no use to the average person. Is it cool to see? Sure, but no one on Earth is living on Mars so what's the point?

Another point was the idea of what an engineer is supposed to represent. Woz reminds me of my old lecturer in computer science at UCI. My lecturer was one of these ideal types that believed in being honest, doing no wrong, etc. etc. It's like you're supposed to be a nobleman with these principles you're supposed to follow. One principle that got me was that engineering represented solving mathematical proofs. I know there's another famous author out there who believed the same thing about programs. So is creating a blog solving a mathematical proof? Or building a social network? Or writing a system that produces video? And if not, are we supposed to mathematically prove the correctness of such systems despite the fact that people (the users) are so random that your test cases become endless?

However, one thing that kinda contradicted that type of thinking and made me give a nod to Woz was that he realized that he needed to break the rules. I think this is the key to what people in computers need to start realizing. These traditions and principles held are more like religions. They serve a purpose for a period as a convention or paradigm of inspiration for that moment. But in the end, these principles need to be constantly upgraded if progress is to be made.

For instance, there's a huge worship of OOP that seem to go on. Take that author for instance or Java developers. Naturally, there's benefits to OOP but does one need them to make something work? No. OOP is not an end-all means to a problem. Of course, those who take "real computer science" courses might end up believing so because professors at times have their own political agenda for furthering or supporting their research which might've taken decades to produce.

The thing is that these are meant to help people who don't have the experience to get a better grasp of what's going on. But they should not necessarily be made mandatory as modes of thought. It's like guitar. You'll hear guys like Satriani guy on about how knowing all the guitar modes can help one's playing. And it's true. If you understand the relations of notes to a key, you can do quite well. Then he admits that there's a trap in knowing too much and falling prey to relying exclusively on theory. Many of Satriani's criticizers noted that Satch would rely more on the technical aspects of guitar, which would limit the feeling of his music.

If we take the same notion, combine that with what Woz is saying and look at what computer science is, we'd realize that it's just theory. You still have to produce and produce well in the end. More than that, you have to produce something that works well with how you do things. I've seen and been part of horrible failures in projects because there was some level of blind devotion of trying to just do the idealistic "right thing" as opposed to doing something at all to make something work.

I think it's hard for a lot of so-called real developers to grasp this notion. I think that they've become so involved in what they're doing that they lose focus on what our purpose really is at times. It's a fine line between being an artist and doing something useful for others.

PHP OpenID Library/JanRain

Sun, 17 Feb 2008 03:36:58 -0700

I'm SLOWLY plowing through this library. It's really horribly documented. There's almost no tutorials and the example code is poorly written. Unfortunately, I haven't seen any other libraries with the flexibility as this one so I decided to implement it.

Well, I've managed to get my code to the point where I can authenticate round trip. Now, it's up to me to finish up the whole login/registration process. Tonight, I hit a major stumbling block where I didn't know that the stupid library uses the $_SESSION global behind the scenes in setting up some key values. In my case, I do something where I shut the session down temporarily. This is for login purposes. However, when I did that, obviously, the library wasn't able to extract the data from the session. Well, isn't that convenient! The sample code for the consumer doesn't mention a damn thing about this. And secondly, I'm now facing an issue where I'll have to figure out if this will disrupt anything during the login process that I wrote up.

On top of that, I spent hours logging various messages trying to figure out where the killer point was. I had to go through those fugly libraries and went a bit nuts placing tons of data dumps all over the place.

Before this incident, I had tried building my own system but had numerous problems trying to get it to authenticate. Then I realized that one of the return points wasn't setup yet and so the authentication server wasn't providing a response. However, the library makes no real mention of this and I couldn't really see for a few days what was going on.

There's, of course, other hitches and hurdles that I'll probably face as I descend lower into the details of the library. But I think when I nail this thing down, I'm going to write up a good tutorial so people won't have to go through the same pain that I'm suffering

WireIt.js and Other Coding Projects

Mon, 24 Mar 2008 10:02:20 -0600

I found a neat little Javascript library called WireIt. With this library, you can create Yahoo Pipes-like wires. But the key underlying technology is actually another Javascript library called excanvas. It's quite convoluted because excanvas is really a wrapper around VML that allows the dynamic shapes being drawn. WireIt also utilizes Yahoo's UI Javascript to handle events, drag and drop and some level of animation. It took some time to get over the initial hump for learning how to handle the thing. Right now, the hardest part is determining how to get the terminal nodes positioned. Once you get it all hooked up though, it's quite neat as you can create visual workflows with Javascript.

Also, I had been working a bit with extjs. I got to utilize the tree aspect. It felt a bit difficult, but again, it's something you gotta get used to. Lots of server programming to structure the output JSON for extjs to correctly format the tree. The library is quite big so there's plenty to learn. I like the fact that the library creates visually appeasing windows and components. My only criticism, outside of it doing the same thing that Swing does, is that it's kinda awkward to program. So far, only jquery has been easy to utilize.

Finally, at home I'm messing around with Amazon's Web Service system. I had long ago signed up for their API key, but never used it as I was too busy. Now, I found some interesting applications and will make use of it. In conjunction with Amazon's Web Service API, I'm using the Zend Framework. I've been quite critical of the majority of it. However, one nice thing is that it has several web service APIs bundled into their system. So today I finally got a chance to dig a little into those areas. It seemed a lot easier than creating my own parsing tool for handling the XML produced from the web service.

Re-sharpening My Perl Skills

Wed, 23 Apr 2008 10:35:47 -0600

In my programmatic quest to shrink all lines of code into one line, I have managed to tune my Perl scripts recently at work into 1-3 line wonders. I've been influenced a bit (perhaps in a geeky negative way) by some people over at ValueClick in the past in creating obfuscated, but killer Perl code. The great thing is that I'm learning how to really utilize some of the more lesser known features that you probably won't see much in anything but the most hardcore type of modules out there.

For instance, I started using the following paradigm:

sub func {
+{ map { $_->{something} => $_->{value} } @{$_[0]->someMethod($_[1], $_[2])} };
}

this is a cool little piece of code that i finally got to use the +{. I found that little bit of code in the O'Reilly SOAP book, the author of SOAP::Lite.pm had a few statements like that. I scratched my head for a while trying to figure out what it did. Later, I found out that it's a type hint to the interpreter to return back a hash reference.

I used it here because if I just did something like:

{ map { ....} };

I'd receive an array, which isn't what I wanted. The +{ sign will convert this into the appropriate hash reference. I showed my boss to see if he knew what the heck it did, but it's a pretty obscure thing in Perl that I don't see often times used. But I'm finding it immensely useful with statements like that.

Of course, your next comment might be, well why the heck would you need a statement like that in the first place? I'm working quite a bit with various types of data. Sometimes, I have lists of data in the array format. But I occasionally want to convert it over to a hash format. Map partly helps here, but if I want to stay true to my virtue of one liners and avoid returning another array, then the +{ becomes quite useful in conjunction with map.

I really enjoy programming in Perl the most because it's like a puzzle where you're constantly trying to optimize what you're doing. I've seen people use tons of variables or less obscure syntax, but I think that it's really not that great of a thing in the end. I mean, in theory, you're replicating memory by creating more variables and the function call potentially grows, whereas a one liner, for a true veteran of Perl, can easily be deciphered without having to painfully scroll through unnecessary pieces of code. I mean, if you want verbose, code Java or COBOL. Then tell me how readable your code is and how long it took you to get a simple idea out the door.

Neat Perl Tricks

Mon, 30 Jun 2008 03:10:22 -0600

Using qw for an array ref:

[qw(item1 item2 item3 item4)];

Extracting parts of a split list

my ($item1, $item2, $item3) = (split(/s+/, $str))[2,4,5];

Converting An Array To Key-Value Pairs For A Hash

my @list = qw(key1 val1 key2 val2 key3 val3 key4 val4);
my %h = %{+{@list}};

Calling a function inside of a quoted element

Very useful when you don't want to end a quote or heredoc.

my $var = "hello @{[getName()]}n";

Checking if the correct number of parameters are passed into a subroutine

sub func {
die unless @_ == 4;
}

Using A Lookup Table To Quickly Validate If Arguments Exist

Good for checking input.

sub validate {
my %args = (arg1 => 1, arg2 => 1, arg3 => 1, arg4 => 1);
return exists $args{$_};
}

Converting a subroutine's arrayref argument to an array

some_func("arg1", "arg2", ['item1', ['item2'], ['item3'], ['item4']);

sub some_func {
my $arg1 = shift;
my $arg2 = shift;
my @items = @{shift()};
print "$_n" for @items;
}

Dynamic Subroutines With Hashrefs

Nice technique when you want to create callbacks and require that the function calls are a little dynamic (for instance, when you don't know what function you might need to call).

my $h = { progname => 'some_func' };
eval "$h->{progname}('David')";

sub some_func {
print "Hello $_[0]n";
}

Getting Local Time in Epoch Seconds

use Time::Local;
my $sec = timelocal( (localtime)[0..5] );

Efficient File Slurping

open (FILE, $dir) || die $!;
my $file = do { local $/; };
close (FILE);

Getting All Files in A Directory

opendir( DIR, $dir ) || die $!;
my @segdirs = grep { !/^./ } readdir( DIR );
closedir( DIR );

Better Inheritance in Perl

use base(Path::MyClass);

Creating A Basic Constructor

sub new {
my ($class, %args) = @_;
my $self = {};
bless $self, ref $class || $class;
}

Creating A Singleton Instance

Using the constructor from above:

sub instance {
my $class = shift;
strict 'refs';
my $instance = ${"$class::_instance"};
defined $$instance ? $$instance : ( $$instance = $class->new( @_ ) );
}

Ruby on Rails vs Django vs ...?

Sat, 16 Aug 2008 02:46:24 -0600

A long debate about what to teach my friend's daughter led me to give Ruby on Rails a try recently at home while at work I started fumbling around with Django. At first glance, both frameworks are very similar in that they are targeted at agile development for the web, most notably CRUD style development. Both have a powerful scaffolding type of architecture where you create model objects that in turn instantly become editable web objects.

Both also employ scripts that do more heavy lifting for you. For instance, creating applications via the command line as opposed to having to edit files from scratch. Also, both have built in web servers that allow developers to utilize their local environments when creating web applications.

But that's probably where the similarities at the heart end.

Rails focuses more on convention for coding practices. For instance, the model objects expect a certain naming convention and employ columns like "id" to handle the primary key. On the other hand, Django is useful for legacy systems where it can "discover" schemas and quickly adapt itself to more complex scenarios (such as having non-surrogate keys).

I think Rails feels more mature and polished compared to Django. For instance, it instantly builds unit tests for your models (and controllers I believe) whereas Django doesn't do that automatically. Also, Rails has some pre-built, commonly used functions like login screens that you can install.

However, I found Rails to be a bit inflexible because of its design to force developers into using its conventions. Legacy databases would suffer greatly if they didn't follow the database naming conventions for Rails. Also, the scaffolding part, while not having worked with it extensively, seems more appropriate for simple CRUD based systems. For example, it seems that if you have a backend system that requires various administrative menus to populate and control data for lookup tables and such, Rails is a great choice. For scalable websites and legacy applications, Rails might suffer from the lack of flexibility in this area.

My personal preference is simply to stick with my own framework. As well supported as these frameworks are with their communities, my biggest problem is that you're still limited by what the community deems as important. Rails works in a restricted setting but I'm required lately to build more complex applications. For me to port my stuff to Rails makes little sense.

Still though, it's nice being able to try out something different.