(even if you're not interested in building a new language, learning about programming languages and their design decisions increases our understanding of them and, hopefully, our proficiency with them)

What is Eiffel? Is it another language that lives solely in academia? Is there anything particularly interesting about it?

It's a static, strongly typed language, and...the rest of its characteristics you can read about on Wikipedia.

From a historical perspective, it's interesting to see some of the key features in Eiffel make their way into Java and Ruby, and to see which features didn't.

For example, Eiffel has a notion of abstract classes, except they're called "deferred" classes and use the deferred keyword. Ruby has no abstract classes, though you could simply make the constructor throw an exception, I suppose.

More interestingly, Eiffel supports multiple inheritance, but neither Ruby nor Java do (though Scala supports something similar). How does it evade the diamond inheritance problem? Eiffel doesn't support argument overloading, like Java does; so if two parent classes have the same method, it won't compile. Instead, you have to resolve the name conflict by renaming one or both of the conflicting parent methods in your subclass.

Like Java (1.5 and later, at least), you can't override a parent method without explicitly stating it, except instead of with an @Override annotation at the site of the override, you declare the override at the start of the class with redefine.

Like Scala, Eiffel holds the Uniform Access Principle close -- Eiffel lets you redefine an argument-less method in an ancestor as an attribute in the current class.

Like Scala, Eiffel has a void type, and it is a descendant of ALL reference types, which allows you to pass void into any function expecting a reference type.

Unlike Ruby, Java, and Scala, the only structuring tool is a class -- no interfaces, mixins, traits, interfaces, or modules.

Like Java, Eiffel has a notion of a once routine. Java's equivalent is the static initializer block (static {}). Ruby has a similar pattern, using ||=, to initialize a value once. (Scala also has a notion of lazily evaluated methods/attributes)

Unlike Java, Eiffel does not allow you to cast an object to another type (though you can always try to assign one object to a variable of a type and it will 'cast' it).

And so on. If this piqued your interest in the ancestor of two big languages of today, check out the tutorial. The first 2-3 chapters are a bit dry and apparently a little self-absorbed in places (it's not just a language, it's a process! they say), but still a good read/skim.

Anyway, here's what the institutions said:

Originally this was going to be a more exciting post...but I guess I was too optimistic

On the bright side, it makes me happy to be a customer of Vanguard's, now. Their response was the only one that wasn't simply "thanks, we'll forward that to the appropriate party". Even though their answer was pretty much "no", it came back quickly and concisely -- it took only like two hours turnaround, whereas most of the others took 2-3 days.

Also, Bank of America/CapitalOne/Chase sort of piss me off in that they *require* you to use their crappy internal messaging system, even for interacting with the company in as mundane a way as this. Not only that, but I wasn't even notified when they'd replied. Am I really supposed to sign into my bank website every day to check for messages?

Does your bank plan on supporting OAuth? Let's raise the awareness a bit so we can get even more cool online tools for managing finances!

Flat-file

Example: plain ol' PHP

PHP, at its simplest, doesn't have any separation at all -- you can, if you choose, have all the programming/form-processing logic in the same file that renders the output to the browser.  While simple, if you're creating a full website, this can be cumbersome and confusing.

Component Paradigm

Example: Java EE/JSF

Each page is an Application (code).  Each Application has an Application Layout (html).  Each Application Layout has a number of slots.  The Application has logic that designates what Pagelets go into what slots, and what layout a particular Pagelet should use.  Each Pagelet (code) has a number of layouts (html), only one of which is rendered per request.  When the request is in the Application stage, there is only one thread, and the application puts into the request object most of what the pagelets will likely need (pagelets can do computations and service requests themselves too, of course, but it's hard to share the results between pagelets)

Phew.  So the cool part about this design is that the pagelet components are (in theory) reusable.  Additionally, all of the pagelets can be executed in parallel, which (since Java uses native threads) can result in major performance improvements.  The application doesn't need to designate the pagelet-slot mappings in code -- it can be configured in XML (lovely...).  On the other hand, since the pagelets are executed in parallel, this makes flushing content to the browser before the page is done rendering somewhat challenging.

I haven't explored enough to tell, but it looks like Java's offerings are heavily component-biased, with solutions like Tapestry that look potentially interesting.

MVC

Examples: Ruby on Rails, Merb, Ramaze, Sinatra (sorta), CakePHP, CodeIgniter

The request is mapped to a particular method in a class, with this class being called the Controller.  This method performs some computations required for display, then renders the View, which consists of a template typically wrapped in a layout (another template that provides the header and footer).  The template can include other shared templates, called partials in Rails-speak, but are generally just template includes.  Models are essentially wrappers for database objects (see ORMs).  Models aren't really specific to MVC -- any time you're calling a method instead of writing out a SQL query by hand you're probably using a model (or a utility class -- but that would be sucky).

In conclusion...

What other stuff out there, good or bad, exists or could exist?  I'm planning on exploring, at least with my mind and possibly with code, what some of the other alternatives are.  Anyone have any experience with other web design patterns that would like to share?

1. Do as much of the models as possible in this first pass, skipping validation but including schema stuff
2. Stick a couple things into the controllers that I think I'll need
3. Build out some of the views, giving them some basic styles
4. Revisit the models to add validation, helper methods
5. Build out the rest of the views, give them real styles
6. Muse about specs, then give up before starting
7. Put more stuff into the controllers
8. Iterate on random components until you're done

Needless to say, I'm getting to the point where my lack of organization kills my mini-projects before I hit step 4, sometimes even sooner than that.  So I'm going to try a slightly more...conventional (or widely suggested, at least) approach:

1. Create controllers with just enough information so that your pages will display.  No setting variables yet or other logic!
2. Fill out the views with as much HTML and fake data as you need.  Site have a sign-in page?  Leave a link to "force sign-in" the user that simply sets them to an authenticated state.  All it should do is set a session variable
3. Spec out the models.  Don't check for validation yet, just check for core functionality, i.e. there is a User table, the first user has a name of Foo and email of bar@baz.com, etc.
4. Fill out your model code so that the specs pass -- this includes migrations with sample data (these can be removed in a later migration).
5. Spec out your controllers/views.
6. Fill out your controllers/views so they pass specs.
7. Do the rest of the little things that need doing, like validation, error messaging, authentication, styling, etc.
8. Revel in having finished a project.

Hopefully I'll get further than step 3 this way! I'm going to try to focus more on content/frontend instead of getting bogged down in the backend, and I want to actually write specs.

Any comments/suggestions?

The process: for a given page (say, a search page), pull the data out of the database that you need in the controller and then output all the raw data as XML needed to generate the page in the template.  For a search page this would be the search results, the user's name (if signed in), etc.  Then you have your XSLT stylesheets.  Since this is all client-side, each one you have generates a request.  If you have one stylesheet that renders the initial page, and that stylesheet requires 4 other stylesheets...well, you have 5 requests right there just to display the page.

These other stylesheets should be mostly static, I'd hope.  In my mockup I didn't have to make any of them dynamic, but then I wasn't trying to do anything super advanced.  Anyway, Thin is smart enough to send 304s for the unmodified XSLTs, so at least that's good...

Other notes: one can do server-side rendering, but that's not the point of this exercise -- I want to do pure non-Javascript client-side rendering.  Unfortunately this also rules out XSLT 2.0, which was only finalized in January 2007 and would probably ease some of the pain.

Anyway, time for Code!

Code

Adding HTML elements based on data

...is a pain.  See here for my solution of preserving dropdown selections after a search (i.e. you search in a particular category and that category shows up in the dropdown on the end page).  Grotesquely verbose?  Why, yes it is!  I don't think there's a better way, either -- it would be acceptable to have a function that outputted XHTML instead of a template, but I think that's that's a 2.0-feature only.

Changing values based on data

This one isn't quite so bad, actually.  As with the previous example, though, you'll notice that you can't pull data in from the query parameters -- it has to be pulled in from the XML.  The original request has access to the query parameters, immediate requests could have access to the query parameters (since the original request url is passed in to immediate requests as the referrer), but non-immediate requests couldn't have any access to the query parameters at all whatsoever.

So what does this mean?  All data needs to be in the XML.  Not just product search results and personalization data, but also what the search query was, what the category was, what the sort order was, etc. if you plan on displaying any of that information.  Ugh!

Preserving query parameters in links

Guess what, more fun!  Check this out.  This is for pagination of search results -- all parameters needs to be preserved except for the page, which obviously changes.  Since this time the data needs to be stored in the attribute of another tag, we have to capture the template call into a variable first.  Cool, huh?

If anyone knows of a better way to do any of this with XSLT 1.0, please do let me know.  I am quite the novice and am just posting my discoveries thus far.  No guarantees of completeness.

Other issues

Javascript/jQuery

I was trying to figure out how to pull data from the original XML sheet via JavaScript, but it seems that JavaScript only has access to the rendered XHTML.  I could do an AJAX call to re-fetch the XML sheet and operate on that, but that seems silly to me.  I've tried looking for a cross-browser non-plugin solution but I don't think jQuery offers anything in this way.

Discussion

In regular HTML, you have HTML, CSS, and JS -- typically referred to as Structure, Display, and Behavior.  But really, HTML is typically structure and data combined, plus elements of display.  XML+XSLT is nice in theory because it explicitly breaks up structure/display and data.  But how much does that really buy you?  On modern MVC-style web frameworks, the controller passes data to the view/template so that the data can be rendered.  But with XML-XSLT the controller renders XML so that the client can transform that XML using the XSLTs you provide.  What's the point of emitting XML when you could just emit XHTML?  Frankly, data and structure don't *need* to be separated -- if you want just the data, then you need to set up a web service.  Frameworks like Ruby on Rails make this trivial.

So I guess the main benefit of separating data and structure the way XML and XSLT does is it means for the same XML, you can have different sets of XSLTs.  But wait...actually, you can't.  You embed the references for stylesheets for the XML file IN the XML file itself, i.e. the XML file says use this XSLT to render me.  So...if you want to switch XSLTs, you have to modify the XML file, which means you have to make the XML file content dynamically generated, which means you might as well use a fully-featured templating language on the server side.

Conclusion

XML+XSLT may have its uses, but general web applications is not one of them...

Read on for some of the initial questions you should ask yourself, and what to do next.

Questions

Is it useful?

No, really, would anyone use it?  Would you personally use it?  Would people like you use it?  Who is your audience?  Would they use it? ... ask them?

Is it sufficiently useful?

Is the problem this application aims to solve painful/time-consuming/hard enough that people will actively search out an application that does what yours does?  If they have any problems with your application, how probable are they to going back to what they were doing before?

Is it unique?

If it's a great idea, there's a fair chance someone has thought of it before.  Put in a solid 20 minutes (or more) of searching for a product that does what you want to make.  Pretend that you already made your product -- what terms would you use to search for it, besides the name?

Is it sufficiently unique?

So your idea is original -- but is it really original?  A social networking website with one additional feature is not sufficiently unique.  A news aggregation website with customizable themes is not sufficiently unique.  A script that performs the same stuff as another script but is 5-10% faster is not sufficiently unique.

Is the project small enough that you can do it with the team you have?

The team you have may be just yourself, it may be 3 guys, may be as high as 5 guys.  Can you make the project a success with the team size (and members) you have?  Can you finish the project with the team you have?

Is it fun?

No, really -- this is a key factor in whether you'll be able to stay mentally and emotionally involved in the project.  Do you think you'd enjoy working on it?  Spend 10 minutes staring at the ceiling or jotting down some ideas while thinking about the project.  Reduce and translate the ideas to the smallest number of features that you'd need to make a "1.0" version of the project.  Will it be fun to implement those features?  Or will it start to seem like real work after only a few minutes of development?

What next?

Are all of the above questions answerable with an emphatic "Yes!"?  Then continue on to the below steps...

Plan more!

Odds are you haven't written anything down yet.  Go ahead and do it, and do it by hand -- not to set it in stone, but rather I've found that to get my creative energies going you have to write it down.  And put it to paper because a) you write slower than you type, and so this forces you to think more about what you're writing and what you will be writing next, and b) paper has fewer email notifications and instant messages popping up...

Bounce your idea

Reduce your game plan to something succinct and organized, then pitch it to friends, families, coworkers, and members of your target audience.  Do they think it sounds useful?  Would they use it?

Sit on it

Any time you make a big decision, it usually helps to sit on it for a while.  Pick a length of time -- 1 day, 3 days, a week -- during which you only plan.  No coding!  It's hard to think through general flow and architecture when you're making it up as you go along.  Then spend another day or two where you don't even plan about it.  Just let the ideas float around in your head.

Stay in the game

How to keep focused -- in the next post!

So here's the problem. You want something like this:

$(function(){
  $("a").click(function(){
    GM_xmlhttprequest({url: "http://www.google.com/", method: 'GET'});
  });
});

or something, right? But that doesn't work because by the time the $'s DOM ready event fired, Greasemonkey is gone. So what do you do? Well...keep Greasemonkey around, but in a limited capacity. Okay okay, here's the code:

var ajaxQueue = [];
var processAjaxQueue = function(){
  if (ajaxQueue.length > 0) {
    for (ajax in ajaxQueue) {
      var obj = ajaxQueue[ajax];
      // http://diveintogreasemonkey.org/api/gm_xmlhttprequest.html
      GM_xmlhttpRequest(obj);
    }
    ajaxQueue = [];
  }
}
setInterval(function(){
  processAjaxQueue();
}, 100);

function gmAjax(obj){
  ajaxQueue.push(obj);
}

So now you call gmAjax instead of GM_xmlhttprequest (with the same argument) and it'll get fired off within the next 100ms. Neat huh? And if you're worried about security (which you should be) -- I've tested this myself, and gmAjax isn't acccessible anywhere outside of the Greasemonkey sandbox. Huzzah, mission accomplished.