sjohnr's rant pages

STFU Problem Solving

2011-02-01T17:42:00.000-08:00

You are an idiot...

STFU Problem Solving (otherwise known as "Shut the !@#$ Up Problem Solving" is a technique that lazy no-good completely inept barely-technical wannabe-good-programmer manager types employ to screw their team members over in order to get executives off their back so they can keep on doing nothing useful and making money while doing it. It usually comes with a lot of buzz-words, worthless analysis, copy-and-paste descriptions from the websites of open-source technologies barely worth their weight in crap, and a lot of sunshine-up-your-@$$ bull**** about how it'll solve every problem under the sun, without any thought as to how it solves any problems whatsoever, let alone the one that actually needs solving. It's almost always synonymous with under or over-architecting through in-place hackery and bastardizing of existing code to the point where it is barely recognizable, not that it ever was in the first place because your code sucks and you're an idiot to boot.

As an example, can someone PLEEEEEEEEEEEASE enlighten me as to how the technology that Google uses to index search results in html pages can be of ANY use for inline processing or distributed caching. If you can split up backend batch processing of large vats of data (such as 4 PB of html pages), such a technology might be of considerable use. The distributed nature of such a technology is useful for splitting up those vats of data into smaller vats. But processing data inline, using such a distributed file-system to organize totally independent processing engines, and using the distributed nature of said file-system to maintain the option to somehow consider those data-sets "contiguous" is completely asinine and serves no purpose whatsoever.

And the best part about such ideas is the no-talent waste-of-space worthless two-face lying no-good sack of crap that they came from. A manager type leader who can't help but lie through their teeth every chance they get. For instance, acting as though an open dialogue about the inherent flaws of most half-@$$ed open-source technologies is completely appropriate until the day you are overheard by someone important in the company, and it turns out you should've shut the crap up a long time ago. This type of two-faced act demonstrates with great transparency the true nature of such an individual and the fact that most of the promises made by them were empty and the statements made by them were complete hokum. It really puts in perspective just how stupid successful people can become, especially when their sole concern becomes rising in the ranks at the expense of everything meaningful, whilst telling lies and destroying hope at every turn.

You. Are. An. Idiot.

To www Or Not To www

2008-08-28T00:17:00.000-07:00

You are an idiot!

Are you kidding me? The author of this article at yes-www.org completely misses the mark, as well as all (or at least most) of the commenters. Why are all the "experts" actually idiots? Anyway...

First, I would like to say that I completely agree with the statement made by the author. http://www. should always be at the beginning of a root domain URL (http://www.example.com). The reason has nothing to do with protocols, however. Nor does the reason have anything to do with hosts (at least not strictly speaking). First, let's examine some ridiculous claims about this debate.

The main reason I argue for leaving the www. in URLs is that it serves as a gentle reminder that there are other services than the Web on the Internet. Some of these, such as FTP and DNS, users typically use transparently without even realizing it. Others, such as e-mail, users access through separate applications. Even so, I know of many users who will claim with a straight face that e-mail is not part of the Internet.

This is just plain wrong. http://www. has nothing to do with protocol. When using a web browser, people intend to browse the web. Therefore, http:// is completely unnecessary, in terms of entering an address. However, www has nothing to do with the protocol. Web is presented as http protocol requests. www is a concept indicating a network. As several comments on this post stated, if you want something other than http:// then enter it!!! (ftp://example.com)

I think you just made my argument for me, and betrayed your lack of knowledge of how the Internet works. :) First off, www is not a “subdomain,” it’s a “host.” Second, how do you intend to disambiguate the HTTP server and the FTP server, which may well be located on different hosts?

This too is just plain wrong. I love it when people are quick to point out others' ignorance when they themselves possess unsurpassed ignorance. Of course, their ignorance is based on arrogance, so that must not really count, right? *ahem*

We are talking about URLs here people!!! Remember what that stands for? Uniform Resource Locator. URLs are easily memorable names that are translated to IP addresses via DNS. The concept of a subdomain is simple. A top level domain (com, org, net, etc.) is prefixed with a domain name (example.com, something.org, etc.). This domain name--as a URL--can have many subdomains (images.example.com, mail.example.com). In terms of URLs, these are subdomains.

However, a URL is translated to an IP address, so images.example.com could--but is not required to--be a different address (or host) from mail.example.com.

As for http://www. in the URL, the reasoning for its use is simple. If a site is using subdomains, it would be consistent for the root website (under http protocol, duh--no one cares about this fact for this debate) to be at the subdomain www. Why, you may ask? Historical reasons? No! And yes!

Historically, the www subdomain indicated a website on a domain, or the host on a network serving the website represented by a domain (www.pepsi.com). Today, it could indicate a root website or a root/default host (www.google.com vs. mail.google.com). Therefore, for consistency if nothing else, www should always be in the URL! So the question remains, do we force our users to remember/understand/use http://www??? Absolutely not!!! What a waste of time and effort by everyone involved. Redirect, for the love of God! If someone visits http://example.com, they should be 301 redirected to http://www.example.com.

Finally, another extremely good reason to use www as a subdomain involves shared hosts and multi-faceted websites. If you have a brain, and you're using a shared host (or even a home-grown server for that matter), you organize your websites properly. For example, let's say you own example.com and something.org. In your html root directory (where all html content is stored and served from), you ought to have two folders, like this:

example/
something/

Most likely, example.com is not the only site/host/domain you will use for example.com. You will likely have blog.example.com or images.example.com or something! But of course, you have a site at example.com itself (that is, on the default subdomain www.example.com). So your folder structure should be like this:

example/
- www/
- images/
- blog/
something/
- www/

Your organization scheme should map one-to-one with your subdomain scheme. And for consistency, you should always be using subdomains (ie. www, images, blog). Notice how all of these subdomains are web related. If you happen to have other hosts using subdomains, everything will still play nice (mail.example.com). See?

If you disagree with me, you're an idiot.

Javascript Inheritance, v3

2008-02-28T21:52:00.000-08:00

Apparently, I'm an idiot. Ironic isn't it? You're not the idiot anymore. Anyway, my javascript inheritance, methodology #4 below doesn't actually work. Go figure. I recently re-read Doug Crockford's inheritance in javascript article and realized that his solution had the missing salt I needed. I'll post the code soon, once I can figure out if it's actually foolproof.

Yeah yeah, laugh it up. I am!

Javascript default parameters

2008-02-17T21:03:00.000-08:00

I for one absolutely hate the feature of untyped languages that forces only one method signature to be defined. Not necessarily the part where there's only one signature, so much as the inability to define parameters as optional. In php, one can specify certain later parameters to have default values. If omitted, those parameters will default, allowing the function to perform as expected. In javascript however, as in perl and other untyped languages, the developer must deal with this issue when defining the function, documenting it, and then calling it. This is just absolutely unacceptable. It allows for sloppy coding on either end, and the ability for "loose" functions which take ridiculous combinations of parameters which are so unintuitive as to render the function utterly useless. Still, it can be done clean enough for some likes, but it could be handled so much better.

For this reason, I decided, through inspiration and necessity, to engineer a helper for this issue. It can be used as a utility of the Function global object, or refactored to be applied to the Function prototype. It is largely the same either way. To make the function short, I'm using a prototype-like utility function, $A, which casts an array-like object into a proper array.

Function.default = function(__method) {
 if (!arguments.length || arguments.length < 2) {
  return __method;
 }
 
 var args = $A(arguments).slice(1);
 return function() {
  return __method.apply(this, $A(arguments).concat(args.slice(arguments.length)));
 };
};

As a note, if the caller or function enhancing code itself is passing the wrong number of arguments, the function will perform as if the wrong number of arguments was passed to the original function. Which, as we all know, is the developers fault, not mine.

function fn(var1, var2, var3) {
    alert(var1 + "::" + var2 + "::" + var3);
}

var fn2 = Function.default(fn, "test", "test2", "test3");

fn2(); // all defaults are used
fn2("a", "b"); // last default is used
fn2("a", "b", "c", "d"); // final argument ignored, as expected

var fn3 = Function.default(fn, "test");

fn3(); // first default used, final two parameters undefined, as expected

Javascript Inheritance, examples

2008-02-09T19:11:00.001-08:00

Ok, so here we are. We've seen the code to actually achieve true object orientation in javascript, albeit a simulated variant of the paradigm, but still, there it is. Now, as most developers think their stuff is the right, I had neglected to see who has thought like I had, "What if javascript really simulated OO, not just gave you a cheap knockoff," (see methodology #3 below).

In an attempt to rectify said foolish ambition, I decided to do a little research. I probably haven't done enough yet, but I found several articles dealing with this exact topic. The site twologic has two (one, two), as well as dean edwards, and of course, douglas crockford. Now, I'm really sorry to say it, but none of these examples really comes close. I mean, twologic has done a decent job of making the super calls accessible, but making it first for prototype was a really bad idea, since it can be made much simpler from scratch.

Examples

Now for some examples of use. Here is a somewhat classic example, using our favorite subject on basic object oriented principles, the animal.

var Animal = function(name, sound) {
 this.sound = sound;
};
Animal.prototype = {
 makeSound: function() {
  alert(this.name + " says " + this.sound);
 }
};

var Cat = function() {
 this.superclass("Cat", "meowwww!!!");
};
Cat.prototype = {
 makeSound: function() {
  this.superclass.makeSound();
  
  alert("... meow?");
 }
};

var Dog = function(owner) {
 this.superclass("Dog", "woof!");
 this.owner = owner;
};
Dog.prototype = {
 makeSound: function() {
  alert("I wuv " + this.owner);
  
  this.superclass.makeSound();
 }
};

Object.inherit(Cat, Animal);
Object.inherit(Dog, Animal);

var cat = new Cat();
var dog = new Dog("Bob Dylan");

cat.makeSound();
dog.makeSound();

As you can see, there should be a fair amount of familiarity with this if you come from most any background, I assume. However, fellow java programmers will recognize it rather quickly. The only real difference is the need for this which is a basic javascript requirement, and superclass instead of super which was just a whim (or perhaps influenced by some library, like YUI, I dunno...).

At any rate, I hope you can see the differences between my implementation, which is completely intuitive to programmers familiar with other oo languages, and everything else, which at present, doesn't seem to go the full distance for one reason or another. Also, you should notice my implementation is very small, and makes twice as much sense to anyone wishing to learn from the code.

Any time now, I may be told I'm quite out of line, or have made some dumb mistake... if so, I'll simply edit this post and claim I knew it all along.. Until then, check out my site for the developing base of clean code just like this, and please leave comments so I know what you're thinking.

Javascript Inheritance, v2

2008-02-09T09:24:00.000-08:00

In an earlier post, I presented a mechanism for simulating javascript inheritance. It was, of course, incorrect. I tested the implementation and believed it to work, but found out shortly thereafter that I was wrong. However, this leads me into a discussion about javascript simulated inheritance, and a presentation of the correct solution also.

Inheritance, methodology 1

There are several approaches that exist to simulate inheritance, ranging from simple and effective, to extremely complex. This first method is quite simple, and is a feature that, were it in formalized object oriented languages in some form, would be quite useful, though possibly destructive in regards to the standard oo features.

This method involves simply copying properties (namely functions) from one object to another. This can be used to temporarily enhance an instance of an object, or to perform "mixins" of one function group into another function group. The mixin feature would, in a formalized oo language, be referred to as multiple inheritance. It is of course mostly impossible to do in said languages because of its implications on polymorphism. Here is the borrow mechanism in javascript.

Object.borrow = function(destination, source) {
 for (var key in source) {
  destination[key] = destination[key] || source[key];
 }
 
 return destination;
};

Inheritance, methodology 2

The second method resembles the first, except that it specifically targets the prototype of two existing classes (constructor functions).

Object.augment = function(destination, source) {
 for (var key in source.prototype) {
  destination.prototype[key] = destination.prototype[key] || source.prototype[key];
 }
 
 return destination;
};

Inheritance, methodology 3

The third method involves something slightly more complex, for much grander results. This approach is what I consider to be the most popular and classical implementation of javascript simulated inheritance. It is known by most as constructor chaining. In my opinion, this is actually a convenience around constructor chaining, since you could do that without any implementation at all. In fact, the real heart of this implementation is creating a class (constructor function) whose prototype is in fact an instance of another class. Using the instanceof operator would yield expected results when operating on an instance of the child class. However, the constructor chaining feature is provided for simple convenience, and doesn't add anything to this implementation.

Object.extend = function(destination, source) {
 var obj = function() {};
 obj.prototype = source.prototype;
 
 var proto = destination.prototype;
 destination.prototype = new obj();
 destination.prototype.constructor = destination;
 for (var key in proto) {
  destination.prototype[key] = proto[key];
 }
 
 destination.prototype.superclass = source;
 
 return destination;
};

Inheritance, methodology 4

The final method is where I've attempted to go, and had at first failed miserably. This final attempt has yielded the true implementation I was looking for, though it contains one very small but disappointing drawback.

First, you should notice immediately that this implementation allows for more than just constructor chaining (which is always via the Function.prototype.call or Function.prototype.apply methods in the ECMAScript standard). In fact, this implementation does all of that for you, and so in my opinion truly simulates inheritance, where the other implementations were just a hearty attempt to bring (in)convenience to something that was already altogether inconvenient in the first place.

Unfortunately, this approach does call for one stipulation. The function called superclass is added to the prototype of the subclass, which is analogous to the super keyword in java. This function MUST be called as the first thing the subclass constructor does, or else nothing works that you intended to work with inheritance. Well, that's not completely true, but the true features of this implementation would not be present. This is because javascript scoping is terribly painful, and there would be no way to bind a superclass function to being executed in the scope of a subclass without access to the instance of the subclass. This instance can only be obtained at instantiation time, or sometime thereafter. Apropos, an instance of the subclass will be dynamically added to the superclass variable, and all dynamically bound functions of the superclass will be called in the scope of this subclass variable when called using the superclass variable from the subclass. *whew*

Object.inherit = function(destination, source) {
 var obj = function() {};
 obj.prototype = source.prototype;
 
 var proto = destination.prototype;
 destination.prototype = new obj();
 destination.prototype.constructor = destination;
 for (var key in proto) {
  destination.prototype[key] = proto[key];
 }
 
 var constructor = function() {
  this.superclass.subclass = this;
  this.superclass.prototype.constructor.apply(this, arguments);
 };
 
 destination.prototype.superclass = constructor;
 destination.prototype.superclass.prototype.constructor = source;
 
 for (var key in source.prototype) {
  destination.prototype.superclass[key] = (function(__method) {
   return function() {
    return __method.apply(this.subclass, arguments);
   };
  })(source.prototype[key]);
 }
 
 return destination;
};

Javascript Snippets Project

2008-02-03T13:39:00.000-08:00

On my website, I've recently launched a project to catalog and collect all worthwhile enhancements and snippets to the javascript scripting language. The project is first and foremost an effort to clean and standardize these modules to be more useful on a piecemeal basis, for those who need a solution to a common problem but don't want a whole library. Also, the project could serve as a fundamental grounding for those who are learning javascript, and want to learn how to accomplish common tasks using functional and object oriented programming.

This section is powered by php using a flat file structure to store the backend posts. Eventually, the javascript section will include mixin documentation for each post, as well as a comments section. Since I'm currently not using a db for my site's backend (I'm using rss feeds from blogger and flickr), I may not get around to this for a few. Not that it will be hard to add a db, but I wanted to see how many much dynamic content I could add to my site without a db. Check it out now!

Javascript Inheritance

2008-01-30T21:36:00.000-08:00

Today, as I was working on developing an inheritance hierarchy based chain of classes in javascript, I realized just how truly possible OO was. Of course, it remains the world's giantest (yep, I know it ain't a word) hack. But, that being said, it's still cool.

Now, I can't take 100% claim for this, as I borrowed small segments of inheritance implementations from several javascript libraries, namely prototype and YUI, as well as the O'Reilly Definitive Guide to Javascript. However, this implementation is much better than all of those. To set it up, here is an example of use:

var C1 = function(var1) {
 this.var1 = var1;
};
C1.prototype = {
 test: function() {
   alert(this.var1 + " is in C1");
 }
};

var C2 = function(var1, var2) {
 this.superclass(var1);
 this.var2 = var2;
};
C2.prototype = {
 test: function() {
   this.superclass.test();
   alert(this.var1 + " + " + this.var2 + " is in C2");
 },
 stuff: function() {
   alert("stuff is just a regular function");
 }
};

Object.extend(C2, C1);

var c1 = new C1("arg1");
var c2 = new C2("arg1", "arg2");

c1.test();
c2.test();

Doesn't that look familiar? Reminds me an awful lot of OO in a real OO language, like java. Here you go!
(edit: See "Javascript Inheritance, v2" above for the correct implementation.)

Object.borrow = function(destination, source) {
 for (var key in source) {
   destination[key] = destination[key] || source[key];
 }

 return destination;
};
Object.augment = function(destination, source) {
 for (var key in source.prototype) {
   destination.prototype[key] = destination.prototype[key] || sour$
 }

 return destination;
};
Object.extend = function(destination, source) {
 var obj = function() {};
 obj.prototype = source.prototype;

 var proto = destination.prototype;
 destination.prototype = new obj();
 destination.prototype.constructor = destination;
 for (var key in proto) {
   destination.prototype[key] = proto[key];
 }

 var constructor = function() {
   this.superclass.prototype.constructor.apply(this, arguments);
 };

 destination.prototype.superclass = constructor;
 destination.prototype.superclass.prototype.constructor = source;
 for (var key in source.prototype) {
   destination.prototype.superclass[key] = source.prototype[key];
 }

 return destination;
};

Object Orientation v. The World, Round 1

2007-12-16T12:27:00.001-08:00

*ding* Announcer: Begin round 1!

You are an idiot!

I recently read an article attempting to bash the hype out of OO, and kill it for good. Of course, the guy was born in 1750 BC or something, and hasn't even bothered to update his knowledge on recent advancements in programming and data technology in 15 years or so.

Even so, it was a decent read, and had many astoundingly good observations about the differences between OO, and say... relational paradigms. However, these arguments did little to promote his pet paradigm, that of procedural. Granted, his real aim was to bash OO regardless of what that happened to promote. Furthermore, he wasn't able to provide anything that fixed problems with OO but provided all its benefits.

The first interesting observation about procedural programming that has come into my head involves the primitive idea of a class, versus any combination of concepts to achieve something similar in procedural. The idea of a struct comes close to producing what has been perfected in classes for data encapsulation. Programmers very typically grouped their data into structs for transfer and ease-of-use. Similarly, function groups, typically organized in a physical file structure, sought to make functions or subroutines easy to use and manage.

I am convinced that a reasonably intelligent procedural programmer from the '70's, locked in a room for 20 years, would come out with OO as his "revelation" for time spent; of course only to be introduced to the real OO which was invented by ambitious procedural programmers who were sick of having sucky code organization and very little programmatic power.

Unfortunately, you talk to an older programmer who wasn't locked in that box, and had no interest in paying attention to advances in computing for those 20 years, and he will scorn OO because... well... because it's different! He'll use arguments like the Object Relational Impedance Mismatch to claim that OO just plain sucks. You are an idiot!

On that note, here's something to chew on: If the gap between OO and relational paradigms is so vast and irreconcilable, then why are technologies like JPA (Java Persistence API) so incredibly successful. People have for many years doubted the ability of Object Relational Mapping to be of much use in bridging the chasm. However, with an incredibly well written mapping technology, the gap seems to have been successfully bridged. Proponents of old school relational algebra claim that the power of this paradigm has been lost. Interesting... So, when my ORM tool uses joins (probably in SQL) to create a beautiful object graph from my Object Model using its mapping metadata, and I can traverse my object graph in OO without any loss in the power behind Set Theory, that would be... what? A lucky break?

Furthermore, the advances in persistence and ORM technology create a very interesting case for the success of OODBMS's. From the application point of view, and even from a scalability point of view, the data source powering my application is an OODBMS. This, of course, has DBA's hopping mad, because they don't have a job anymore. No longer will the application rely on proprietary features of an RDBMS vendor to provide essential functions like security, concurrency control, and transactions, to name a few. They claim that we waste the power in those vendor products, by implementing them on top of our application technology.

This isn't a case for high-level layer confusion. No, this is a case of proper technology advancement. All the concepts embedded into state-of-the-art RDBMS technologies have paved the way for properly bridging the gap between relational and OO, by moving said features from the DBMS to the application, and leaving the RDBMS to be simply a persistence store, optimized to deal with disk access only when needed for scalability optimization. The first 20 years of DBMS work were on perfecting that very issue. And now that those products also support concurrency, transactions, etc. you're sad to see those functions re-engineered into a more applicable layer of the application. Hmm... touch luck. If you're a dba, I'd say you ought to get more than a business degree, and move on with your less-than-average life.

The Need for Separation, Part 2

2007-08-15T20:07:00.000-07:00

As mentioned previously, a framework of sorts is the solution for adding power to the servlet controller + jsp view approach. To free the developer up from managing urls, and allowing them to have units of controller logic automatically tied to corresponding views (html, xml, txt, csv, etc.) is a decided improvement in application design. In the realm of rapid application development and agile programming practices, the ability to free the mind of these cumbersome tasks, with a standard organization structure improves the ability of the programmer to provide maintainable applications quickly and in a cost-effective manner.

The Front Controller

The cornerstone of an MVC framework is the front controller. This approach requires commitment to using one, and only one, entry point into the application for a given client type. For instance, a web browser client would be given access to every page of a web application through some standard url, like /MyServletController or /index.jsp.

The reasoning behind this approach is simple. First, it gives the software, and therefore the programmer, the ability to handle url management internally, instead of externally. Any mechanism for decomposing and rationalizing urls is available to the programmer. This eliminates the need to maintain url mappings. Also, in the context of agile, it allows for the rapid deployment of web components, with no more administrative tasks required than adding an <a> tag pointing to pages in the module component. The url would be automatically translated by whatever code sits behind the front controller, and control of the application can be routed to the appropriate module or component for processing--in a word, "automagically." In the servlet world, the request object gives the front controller the power to later forward control to a jsp page for view processing, so both the controller logic and the view logic can be handled in independent sections of the application.

Without further ado, let's see an example of a front controller servlet. This example uses (at this point) mystical java classes to do most of its' work.

public class DispatcherServlet extends HttpServlet
{
    /**
     * Processes requests for both HTTP GET and POST methods.
     *
     * @param request servlet request
     * @param response servlet response
     */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
        ServletContext context = getServletConfig().getServletContext();
        WebController controller = new WebController(context, request, response);
        
        // dispatch the request to the "framework"
        String view = controller.dispatch();
        
        // forward control to the jsp view for processing
        request.getRequestDispatcher(view).forward(request, response);
    }
    
    /**
     * Handles the HTTP GET method.
     *
     * @param request servlet request
     * @param response servlet response
     */
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
        processRequest(request, response);
    }
    
    /**
     * Handles the HTTP POST method.
     *
     * @param request servlet request
     * @param response servlet response
     */
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
        processRequest(request, response);
    }
}

Next article: The Controller

The Need for Separation, Part 1

2007-08-04T16:31:00.000-07:00

In the first article in a series, dealing with MVC separation using the Java Platform, Enterprise Edition, we will explore available technologies in Java EE. Then, we will see how using them without structure causes immense problems in the exact type of application Java EE was built for: big ones!

The Problem

Core technologies for presenting dynamic web pages in Java EE are Servlets and JSP (Java Server Pages). For the sake of this article, I will assume familiarity with both technologies. Two organization structures of these technologies is naturally apparent.

Straight JSP

The first approach in the context of a large application is to manage a number of jsp pages, which make use of java beans and scriptlet code to make calls to java classes in the main portion of the application. These types of calls and code will be sprinkled throughout the jsp, whose predominant purpose is to put together the html response to a client request. As mentioned before, this is in the context of a large web application. When dealing with a simple, small, and relatively static web application, this organization structure is easy to use, and typically doesn't present a large maintainability problem. As soon as the application grows beyond a few pages, it becomes largely difficult to keep this sprinkled logic mixed with html organized. If you analyze an application built this way, you should also immediately be aware of the poor form and design of the application. Also, the urls in the application are strongly tied to the file organization, which is a particular problem for the purposes of search engine optimization.

Servlet Controllers

Since jsp is simply a page that is compiled into a servlet, saving the programmer the hassle of managing html through println() calls, the second obvious approach is to use servlets to perform these calls to the main portion of the application (where the "business logic" lies). Once the calls to the business tier of the application is complete, the programmer can pass some variables to a jsp "view" using the request object provided by the servlet container. This is a decidedly better organization for an application, because you no longer have the unwieldy mix of logic and presentation code. This practice of separating presentation from logic is a common and well understood practice by many programmers. The use of templating engines in several scripting languages like php is testament to the popularity of this approach. In fact, the modern version of jsp was created for just such an approach, and would explain the ability for a servlet to forward control to a jsp page.

The problem with this second approach is not obvious until the front end (the web tier) is being built. Each servlet needs a url mapping in an xml file before it can be used to serve responses to client requests. This presents several technical challenges. First, while the mapping capability means that urls can be freely formatted and remain unrelated to the underlying file structure, the maintenance of these urls is not particularly desirable, as not just url patterns (groups of urls) need to be maintained, but every url in the entire application. What's worse, each url mapping needs a corresponding servlet mapping, so the url can map to a servlet, and the servlet can map to a physical java class.

The Solution

The popularity of MVC frameworks is testament to the success of stacking a little bit (or a lot) of code on top of a language to provide automated functionality. No matter your disposition on frameworks, some sort of magical functionality needs to take place in order for the manual process of mapping urls to resources to go away. Unfortunately, this magical functionality is one step farther than the Java EE specifications have gone. It's easy to see why it would be ineffective to provide this at the api level. The Java EE specifications already provide (or specify how an app server should provide) a world of automatic functionality in the form of containers, factories, persistence management, etc. To force a given organization on the code would be to destroy the power of the programming language itself, and ruin the chances of innovation for future generations of programmers.

Next article: The Front Controller.

Java MVC Tutorials

2007-08-02T07:36:00.000-07:00

Over the next few weeks, I will post several tutorials investigating and demonstrating transforming the Java Platform, Enterprise Edition (Java EE, previously J2EE), into an MVC platform.

I will do this without the use of currently available (and rather unpleasant) MVC frameworks--like Struts, Spring, and JavaServer Faces--and with very little code. I will also demonstrate the need for such an organization to a java project, and why Java EE out of the box (unless using an additional framework) does not provide a ready MVC organization. If this isn't enough, I will also show how to incorporate several common web best practices into this MVC structure using standard technologies in the Java EE APIs. Stay tuned!

Why ORM?

2007-05-01T10:22:00.000-07:00

Why ORM (Object-Relational-Mapping)?

You are an idiot!

I am getting sick and tired of having this discussion. You think you know something about how things work, but you're not facing the facts. If you honestly believe that using a completely procedural approach to database programming is a good idea, even in a web-based system, you are absolutely wrong! If you think that scalability issues when hitting 100,000 users has anything to do with what database layer you're using to serve a simple page, you are absolutely wrong! Let me break it down.

Scalability Concerns

High number of records

A page that will serve a high number of records in a single load, now or in the future, must be designed as such. It is not a complicated task to understand that a page may be used to view 25+ records, at any given time. If this is the case, very simple standard approaches should be used to solve the problem. Pagination is your solution. The page will scale as well as can be expected, and will not run into load issues (large amount of html data transfer), and certainly will not have memory issues, that arise simply because of the technology being used to hold data.

High number of users

This is simply a hardware concern. If your system expects very large numbers of users, a page that loads one record, but is hit 100,000 times a second, will have scalability issues on the environmental side, not the software side!

Batch processes

Any process that will do heavy lifting and operate on high numbers of records, without the use of block processes and where the concept of pagination does not apply, scalability will be of concern. In these cases, the high learning curve of using an ORM versus procedural approaches will come into play. The programmer simply needs to understand how to bypass the ORM in order to use procedural approaches, and the batch process operating on hundreds or thousands of records will perform fine. Alternatively, you can hydrate objects one at a time, and discard them once used. This will scale your memory footprint much better, and will likely make moot the issue of time scalability for hydrating those objects.

Why does a batch process usually scale badly in an ORM based system? The process of loading thousands of hydrated objects into memory suffers from the law of diminishing returns. You get less benefit for more work performed, and as memory gets eaten up holding all the objects in memory, the process slows down.

Why doesn't this concern come into play with high numbers of users, and low numbers of records? Because a request serving one record will load an object, use it, and discard it just as quickly as the request can be processed. The only scalability concern you will face, as discussed above, is hardware and environmental scalability. This leads us to the conclusion (even without the need for benchmarking, which has been done, BTW) that discarding objects and allowing for memory management of the PL to take its course, will allow an ORM to be used in most situations with only minor adjustments to the approach and tactics.

Conclusion

Using an ORM has astronomical benefits to code organization and programmatic power in systems, including web-based ones. Forcing procedural programming to be used in web-based systems will destroy your organizational power, making your code a complete mess, and only gains you the ability to ignore learning how to use an ORM. You will not have a system that is any more scalable than the system written by a properly versed ORM programmer. Comparative analysis in all other areas of these same systems will indicate that the ORM based system kicks your programs @^%$*, so shut up, idiot!

Flickr Widget

2007-04-24T11:55:00.000-07:00

I thought I'd be nice and post a flickr widget I developed in response to the fact that other flickr widgets really sucked.

Here's the code for mine, to start things off:

<script type="text/javascript">
function jsonFlickrFeed(json)
{
  document.writeln('<ul style="margin-bottom: 0;">');
  var tpl = '<li><a href="{link}"><img width="150" src="{media}"/></a></li>';

  for (var i = 0; i < 5 && i < json.items.length; i++)
  {
    document.writeln(
      tpl.
      replace('{link}', json.items[i].link).
      replace('{media}', json.items[i].media.m)
    );
  }
  document.writeln('</ul>');
}
</script>
<script src="http://api.flickr.com/services/feeds/photos_public.gne?id=33268241@N00&format=json" type="text/javascript"></script>
<a id="flickr_www" href="http://www.flickr.com"><strong style="color: rgb(57, 147, 255);">www.flick<span style="color: rgb(255, 28, 146);">r</span>.com</strong></a>
|
<a href="http://www.flickr.com/photos/sjohnr/"><strong style="color: rgb(57, 147, 255);">my flick<span style="color: rgb(255, 28, 146);">r</span></strong></a>

The important thing is really the url to the json feed for your flickr site. Mine is: http://api.flickr.com/services/feeds/photos_public.gne?id=33268241@N00&format=json

The id in the url is not too logical, so check your flickr site (look for the "Feed" link at the bottom for the id parameter of the url).

Also, the link to my flickr site is http://www.flickr.com/photos/sjohnr/ so change that link in the code to point to your site.

Otherwise, I'll let you figure out how to customize the other portions of the widget, since it's not that hard.

Demo

www.flickr.com|my flickr

Symfony plugin - sfDateTimePlugin

2007-04-19T09:51:00.000-07:00

I submitted my first plugin to symfony. It's a very sexy date manipulation library, which trumps even the pear date library as far as I can tell. It has a long list of nice features, which I will formally type out later. The sfDateTimePlugin is currently available on the symfony wiki, and pending validation in the pear channel.

[b] and [i] versus [strong] and [em]

2007-03-29T21:29:00.000-07:00

I think it has finally reached critical mass. The concept of separating presentation from content is a widely accepted practice. So why do we have  and ?

I imagine a few will like a rehash of this concept, just for the sake of discussion, if nothing else.

The driving force behind separation of presentation and content, and the phenomenon known as the semantic web, come from a singular source: accessibility. But what does accessibility mean or entail?

Thinking of accessibility is useful even if our audience does not consist of blind folks using screen readers. Accessibility is a driving force that can be used to help us forge a new path towards a cleaner, more efficient web. Accessibility as a concept reveals weaknesses in any non-compliant website in such a way that it has become useful as a synonym for compliance. Therefore, if you approach designing a website's source code from the perspective of it being read by a screen reader, you will be able to write compliant and semantic websites from the start, and your content will have meaning outside the scope of a modern visual web browser. This is an good and important start.

So back to the point. Why  and ? If we examine the trends of the w3c in defining new web standards over the last four to eight years, you will notice that tags that add semantically meaningful information to documents have been introduced, while tags that only specify presentation have been purged from the standards. The  tag is the best example of this. In the late 90's, the web was so cluttered with horrendous html documents that were so bogged down with presentational markup that they were virtually useless, not to mention unmaintainable. The new standards have saved us from a slow and horrible fate, and for that we are thankful.

However, the final two truly presentational tags,  and , are still around and in high use. What makes them different, and why haven't they gone away? If you examine how a person would go about designing a document that has lots of bold and italic text that should not be read with emphasis in a screen reader, you will begin to see the usefulness of these tags. You can theoretically imagine that  and  are simply synonyms for the longer and messier  and . Since they are so absolutely useful, they have been allowed to remain in the standard, though they are likely going away in XHTML 2.0, which may make this entire thing a moot point. Even so, as long as they remain, one could argue that they can and should be used for presentation, since they are about the only presentational tags imaginable that don't clutter up and bog down your document.

Basically, keep accessibility in mind when designing documents. Imagine how you would want your document read in a screen reader, and you will come out ahead. If you have trouble with  and  tags, just use css. The only trouble that you could come across is making your styles too specific. For example, if I wanted to replace  and , I may make some css styles like:


span.bold {
  font-weight: bold;
}
span.italic {
  font-style: italic;
}

To do this, however, would make your document pretty stupid. If you insist on using this approach (which is certainly your prerogative, and not a bad idea at all), you could do something like this:


span.attention {
  font-weight: bold;
}
span.notice {
  font-style: italic;
}

By doing this, you would be declaring that you have visually impactive sections of your document that are still simply text, and shouldn't be interpreted as anything else, except visually. However, one could still argue that maybe you should have just used  and  in the first place, but there are always reasons you don't want that semantic baggage in a certain situation.

Why phpDoc?

2007-03-28T16:28:00.000-07:00

Ok. So this one is just personal. Most people don't have a problem with phpDoc, and don't argue against using it–at least not that I'm aware of. But I'm lucky. I know some of the rare few.

Before I begin, let me just say that this rant is totally inspired by the fact that people need to be more open-minded. I don't want to point fingers, as this blog is public and I wouldn't want to alienate those that I know of whom I'm referring to, but c'mon people! We really need to be less haughty and ditch our I'd-like-to-pretend-I-know-tons-just-because-it-makes-me-feel-better attitudes. And by "we" and "our" I mean "you" and "your." Now, let's begin.

You are an idiot.

You knew it was coming. I just really get annoyed by this whole closed-minded thing that I seem to get the blunt end of all the time. It is so ridiculous to look at a piece of software, notice that there is one piece of functionality that–on the surface–seems to be missing that you think ought to be there, and freak out and create a de facto doctrine banning it from use and scorning those who do use it. There are so many more sides to any argument for the clincher to be a one-issue, end-of-discussion coffin-nailer.

Now, in response to your question, I must ask one of my own: "Why the frak NOT!?" If you don't document your code using a JavaDoc like syntax, WTF are the rest of us supposed to do with your code. We have no idea what's going on, and can't see what the individual pieces of code are supposed to be doing. More importantly, of course, there's no way to tell what the "big picture" is.

The point I'm trying to make is this: JavaDoc makes absolute and perfect sense, and there's not a &*%# thing you can say to change that fact. If you insist on being ignorant, that's your choice but I don't want to hear about it, and it had better not affect me.

Even if I never intend to generate documentation using the phpDoc tool, I am going to use JavaDoc like comments in my code. There's no other way to comment functions, classes, includes, defines, and pages any better, so why would you not do it. Furthermore, why would you try and define some alternate syntax, which sucks, and will eventually lead you back to JavaDoc anyway. Remember, machine readable is the key here, and JavaDoc is absolutely machine readable. You can do anything you want with it.

It's like when you try to develop your own tool for doing anything that has already been done, thinking: "I'll just code my own. In house is better, and I know how to program, so how hard can it be? blah blah blah..." No!!! Everything you try to do is going to lead you back to the tool that you were trying to replace in the first place. If you want a framework, use a framework, don't try and invent your own. It's been done already, and you're not coming up with new concepts, so just stop trying! There's not a $&%# thing you are doing that will be an improvement if is all you're trying to accomplish is getting a certain type of functionality working. If you actually had good ideas that had never been done, maybe it is worth it to "roll your own" XYZ functionality, but when it's been done before, use it! I'll say it again: Stop trying!!!

Symfony Templating

2007-03-18T11:53:00.000-07:00

A common problem that needs solved in any web application environment is templating. There are numerous templating engines available for web languages, and php is no exception. The need to create templating engines is driven from two things:

Traditional c-syntax code mixed with html is unreadable (usually).
It is a good practice to separate your logic from your presentation.

Of course, #2 is only the first step in creating an MVC based project, where the "view" is just one of three layers of the application, and by its nature separates logic from presentation. However, even without MVC, templating engines have provided some relief from issue #1 and usually provide a means for solving issue #2.

A common gripe against symfony is its lack of templating engine. Symfony instead uses php as a templating engine. So how can this possibly be a good idea?

First, it is important to note that issue #1 is strongly tied to a lack of awareness of the alternate syntax provision in php. Traditional c-syntax code for basic constructs is as follows:


if ($x > $y)
{
// ...
}
foreach ($ar as $elem)
{
// ..
}

You get the picture. The alternate syntax, which in my opinion only makes sense, and therefore only exists for use embedded in html, is as follows:


if ($x > $y):
// ...
endif;

foreach ($ar as $elem):
// ...
endforeach;

Or, embedded in html:


<?php if ($x > $y): ?>
<strong>X</strong> is greater than <strong>Y</strong>
<?php endif; ?>

<?php foreach ($ar as $elem): ?>
<strong>Elem:</strong> <?php echo $elem ?><br />
<?php endforeach; ?>

Second, a common illusion among programmers who only have a basic understanding of the "view" layer of an application--or in a flatter php project, simply the "template"--is that absolutely no logic can be performed at the view level. These purists will sometimes even object to looping over values in an array, claiming such logic cannot be present in a "logic-less" view layer. You know what I'm going to say.

You are an idiot.

The goal of separating presentation from logic is to isolate all work that is performed in translating user requests to state information manipulation, and then retrieving state information to hand over to the view layer for display. There is a large amount of "logic"--that is lines of code to do "stuff"--involved in displaying state information (data) in the view. For this purpose, symfony (and likely several other frameworks and packages preceding symfony) has defined a standard format for the view layer to package all of its logic up in a clean, reusable, and extensible way. These are referred to in symfony as "helpers."

Helpers simplify and standardize the amount of code that needs to be placed in the template itself, so that there really is very little logic visible. However, in these helpers, all kinds of things can go on that is strictly related to rendering the display of an application. Symfony bundles a plethora of helpers that perform common tasks, such as generating <a> and <form> tags (which also gain standard url routing provisions through the helper system), <select>, <input> and other form element tags, <img> tags, javascript code and ajax functionality, as well as including chunks of reusable template code, etc. Several community contributions provide additional helpers that clean up other common messy tasks, such as generating pagination links, creating standardized CRUD record navigation, or simplifying new techniques for integrating hot-off-the-market best practices into your application.

Since symfony has adopted a pure php templating methodology, these helper functions are exactly that, pure php functions. Sometimes, the helpers plug into symfony to make use of various tools provided by the framework, but other times the helpers perform simple string manipulating and literally augment built-in php functions. Typical templating engines have the ability to directly call php functions disabled, and therefore have to implement their own helper systems, which are not reusable outside the templating engine. Symfony helpers, except for ones that specifically use symfony tools, could be repackaged in the php world at large with minimal effort.

The result of solving issues #1 and #2 in this way result in templates that look like the following:


<span><?php echo link_to('home', '@home', 'class=nav-link') ?>


<?php foreach ($users as $user): ?>
User #<?php echo $user->getId() ?>: <?php echo link_to($user->getName(), 'user/view?id='.$user->getId()) ?><br />
<?php endforeach; ?>

Imagine what that would have looked like in a flat php world. Even in a templating engine...

Personal Blog

2007-03-17T14:25:00.000-07:00

Hey all. I've set up a personal blog elsewhere. I've decided to make this a technical blog only, so I won't post any personal messages here whatsoever.

Someone Noticed!

2007-03-16T19:08:00.000-07:00

Finally someone commented on a symfony snippet of mine. I've been posting fairly nice code regularly, but nobody says a thing. At least a few of the snippets have high ratings... Anyway, it's pretty sad when I care very much about such things, but you know, I want to be noticed for more than my violin playing (though that's nice too). I'm a darn good programmer!

Anyway, that's all.

Why symfony?

2007-03-16T07:57:00.000-07:00

You are an idiot.

Er... Maybe I need a new one.

Get a frickin' clue!

Symfony does two things, which are themselves inextricably bound in origin.

Implements MVC in the most logically productive way possible.
Provides tools to use every productive best-practice available on the web today.

Symfony is currently the best php framework available for obvious reasons. If you ask anyone what the best (or at least the coolest) framework out there is, everyone says Ruby on Rails. So why is Rails successful? Best practices up the wazoo! If you don't buy into best practices for programming, then you need to read my last post, and assume every derogatory comment is aimed at you. In fact, I'll put some of it here too.

Get a frickin' clue! You are an idiot.

Programming, web development and computer science are continuously evolving fields and require constant innovation in order to be useful and complete. There are several absolutely amazing best practices out there that speed up development ten-fold, and most old-timers (anyone who rejects good ideas because someone younger thought of them first) ignore this fact. Instead, such people assume the web hasn't changed and that they have the capability to create all of the stuff they need to be successful off the top of their retarded heads. Reinventing the wheel is for no-talent losers from podunk land.

This is arguably the worst mistake a programmer can make, ignoring all of the work by hundreds of thousands of developers who have spent countless hours putting their past experiences into the public arena as improvements in the form of libraries, packages, and frameworks.

Symfony has succeeded in packaging all of the best practices from several successful frameworks including Struts, Ruby on Rails, Mojavi, and many others.

Now, the final question relating to this would be "If these other frameworks are successful, why symfony?" These frameworks have several good features, but have drawbacks in the way they are used, or they are missing other essential features. Symfony has been thought out so well, that every single iota of functionality in the package is in harmony, the code quality is beyond excellent, and it packages every best practice available without suffering from scope-creep and project bloating.

90% (plus) of the reasons why flat php projects are difficult to manage is taken care of in symfony, allowing the programmer to think about things that really matter. The impossible header/footer issues (including redirecting after outputting part of it) are dealt with through the decorator process. Templating has a helper function system for providing complicated logic that belongs strictly in the view layer, while keeping the templates themselves free of logic. The naming coventions for helpers especially are logical, and blend into harmony with the php function naming conventions, making it feel a native part of the language. The framework makes a small memory footprint, due to autoloading classes on demand. A feature available in the framework isn't loaded unless you use it. Configuration is completely granular, and all symfony configuration is available at every level of the project from global on down to an individual action. The enforced project structure and naming conventions allow for free functionality, and force you to adhere to logical organization that is difficult to bungle (though you'll find a way, idiot). The ability to add your own standardized helper functions, configuration handlers, extended core classes with custom functionality, logic in the model layer, cli tasks, code generators, execution filters, proprietary classes, plugins, multiple layouts, reusable code fragments in several varieties, layout zones, etc. gives your project the customized edge while maintaining strict organization, code quality, and standards. The documentation is extensive, and the source code makes almost perfect logical sense without an ounce of familiarity.

Why symfony? That's why, you idiot.

Why MVC?

2007-03-15T20:20:00.000-07:00

You are an idiot.

The fact that you are asking me that question indicates two things:

You have not done your homework.
You are either not a developer (in the true sense, not the hobby one), or you are an ignorant, closed-minded fool of a Took... er.. developer!

Now, that feels better... So let me attempt to answer your question.

MVC (Model-View-Controller) organization of a software code-base has one singular purpose. To make your sucky, wannabe, look-at-me-ma-I'm-a-developer project stop sucking quite so badly.

Is it possible to have a non-MVC web-based app not suck? Sure, but there's this little thing that we in "the biz" like to call "best practice" that argues this point for me. Look at every successful framework being written for the web. Every single one is using MVC.

"But I separate my code into templates and logic, isn't that the same thing?"

You are an idiot.

If your project does not talk to a database, or some other persistent storage repository, then be my guest and ignore MVC. It won't help you. However, for most of us, separating out the templating code is a good start, but not nearly enough. Not convinced? Let me give you the "hello world" introduction to MVC.

I have an employee table in my database. Every time I print an employee's name, I print first_name + ' ' + last_name. What an incredibly simple thing to do. But I do it A LOT! So where do I put the generalized function to perform this repetitive task for me? I know! I'll create a class (or script) to store useful functions that I use a lot, and I'll just put it wherever other such classes/scripts go (these would sometimes be referred to as "includes"). If I get lots of these types of functions, I'll just start creating classes/scripts whose name reflects the types of functions contained therein. I must be a genius! Nobody's ever thought of that before.

You are an idiot.

The second you start just throwing general functions into a bin (more like a vat) of crap, the next guy to come in and modify your code will disagree on its category and move it, rename it, not know where to look for it, or add unrelated functions next to it. Now you're pissed because you're the team lead, but you have to go in and enforce your proprietary conventions (really just preferences) for how such things should be organized. Then he's pissed because you didn't like his idea. Before you know it, your project sucks! It's disorganized, and has no guaranteed structure, or the structure you started with doesn't reflect the needs of the project six months later.

Back to our example. What if (and please try to ignore the Object-Relation Impedance Mismatch problem for this discussion) I had a class that represented a record from the employee table. Clearly, I have some way to access fields from the table (now data members in the class) in some standardized way, like getMyField() / setMyField('er...'). So, instead of getFirstName() + ' ' + getLastName(), I have getName().

Apply this example to the six million different situations where you need logic performed that explicitly involves the database and its contained data, and the only way to organize this type of code is to put it into a model layer in your project.

Why MVC? That's why, you idiot.

New Blog

2007-03-15T20:18:00.000-07:00

I just created this blog. Do you know why? Because, dangit, blogs are for ranting, and I need to rant...