the.codist{}

Loading The Whole Internet In One Web Page

Sat, 07 Jun 2008 23:26:04 GMT

This content should only have come from thecodist.com.

Texas Rangers

I visit this page on occasion and always wondered why it took so long on my high speed connection to load.

Now I know why.

1.5MB of content. In one page!

220 separate connections.

Many of every kind of file, javascript, flash, gif, jpg, html.

260K of HTML, 52K of CSS, 800K Images, 300K Javascript and 110K Flash.

Total time was completely random, generally 15-20 seconds or so. On firefox I got two javascript errors along the way (so it wouldn't load completely). Safari at least gamely went on.

Who writes this crap? You'd think Major League Baseball could afford better web development (or management, which is more likely the culprit).

Sometimes I think fondly of the first web page and its humble content.

A Tale Of Two Waterfalls

Tue, 06 May 2008 03:09:08 GMT

This content should only have come from thecodist.com.

Before I poke waterfalls with a stick, a couple of stories.

Story, Waterfall One

Project Manager: What are your requirements?

Customer: I want to float on the Niagara river.

Project Manager: What would you like to float with?

Customer: A boat?

Project Manager: What type of boat do you require?

Customer: Maybe a canoe?

Project Manager: OK, sign here and we will build you a fine canoe!

[Later]

Project Manager: Time for the customer acceptance test, please try it out.

Customer: Hey it works great.

Project Manager: OK, project complete, good luck!

[Customer floats down the river, falls over the edge of the waterfall]

Customer: Wait, this isn't what I need!

Project Manager: Sorry, you agreed to it. Request a change order...

[Customer dies horrible death]

Story, Waterfall Two

Project Manager: What are your requirements?

Customer: I want to float on the Niagara river.

Project Manager: What would you like to float with?

Customer: A boat?

Project Manager: What type of boat do you think you might need?

Customer: Maybe a canoe?

Project Manager: OK, we'll try that out first.

[Team builds a canoe, floats it on the river and it crashes over the falls and breaks]

Project Manager: Hmm, that wasn't the right thing. Maybe an enclosed boat?

Customer: Like a barrel, maybe?

Project Manager: OK, for our next iteration, a barrel.

[Team builds a barrel, puts dummy inside, pushes it over the falls, barrel survives but dummy is cracked]

Project Manager: Hmm, that wasn't quite the right thing. Maybe we pad it heavily?

Customer: OK

[Team builds a padded barrel, puts dummy inside, pushes it over the falls, barrel survives and the dummy is OK]

Customer: That's the thing, I'll take it!

[Customer floats down the river, falls over the edge of the waterfall and survives]

Customer: That's exactly what I needed, thanks!

Discussion

Exaggerated stories aside, the fundamental difference between the venerable (and sadly popular) Waterfall methodology (with its pretty pig-name, SDLC) and the more modern iterative approaches boils down to one main point:

"Customers don't know what they want, much less what they need, until they see it."

In all my almost 27 years in this business, I've learned this over and over again. It's very difficult for customers (i.e. the consumers of your software project) to precisely describe their needs sufficiently to provide an exact list of what they need. Most people have a tough time imagining a software solution sufficiently without a concrete example. Generally they must be guided in an iterative manner to come to a decision point; usually they need to actually get hands on with at least a minimal representation of the software in order to "see" whether it will meet their needs.

The Waterfall/SLDC methodology requires that each step in the process be complete before the following step can reasonably start. You can't start development before all the requirements are known and documented. In theory this should be possible; in practice I've rarely seen it happen except in limited circumstances.

I once knew a guy in the Bay Area who specialized in writing SCSI drivers. He was an expert, and basically did the exact same thing, with minor changes, over and over (plus he made enough to spend 6 months every year in Alaska on vacation, but that's another story!). This type of situation, where everything can be specified up front as there are no real unknowns, makes such a rigid process work. If I write a general ledger for the seventh time in my life, I bet there is little different than the sixth time. If all I am doing is some maintenance on an existing application, I would expect that changes could be documented ahead of time.

If I am writing a brand new system (like I am now at work) there are way too many unknowns to do any kind of up front specification and even design. I don't even know how I will accomplish even the most basic requirements until I have spent some time trying approaches. My "customer" the company is not sure what new products and services that might be possible if the new system can be flexible or scaleable enough. We are replacing an existing system, but it has so many problems and irritations that no one wants to simply replicate it. In this environment all we can do it start with a basic set of needs, build enough to see if the basic architecture works (it has to scale 10x at a minimum of our existing one), then examine how it can be expanded as people see what it can do. There is only one way to work with something unknown and that is iteratively.

This is a hard thing to explain to people for whom waterfall is an embedded part of their psyche. Of course it is also hard to tell people why most of our projects are failing as well. Generally the response to failed waterfall projects is more requirements, more documentation, more analysis. When I was at First Command, we had a 15 step (meetings, documents, signoffs) process before any code was actually written. You would think it would keep projects from happening, and it did (on purpose I always thought).

Story, Sabre Corporate Air Pricing

So how does an iterative, customer involved approach work? As an example, take my experience building a customer facing and internal workflow application for the Sabre Corporate Air Pricing group. Back in 2000, this group (who's job was taking information about flight discounts from travel agencies serving Corporations, and programming them into the Sabre Reservation System). They had about 100 or so people who did the work of "coding". They used faxes and emailed documents from the agencies, and managed the workload by the "drop files on chairs" method. Agencies never knew who long it would take, errors were common and corrections took a long time. Meanwhile errors in discounts were caught by the airlines, and Sabre had to eat the penalties (millions of dollars a year worth). Yet Sabre IT had no interest in helping this group automate; they did write a minimal spec for a web app for the agencies but nothing more. So the group finally had enough and hired the consulting firm I worked for to build the agency facing web app.

Since I was the only person who knew JSP (which Sabre had started using) I worked on that app, completed it per the spec, and then asked a simple question: "OK, now you have data coming from the agencies, what are you going to do with it?". IT had no interest in the question, and the CAP group didn't know anything about web applications at all.

At this point in a normal waterfall you would gather requirements and have them sign off on them. Fortunately I was allowed to do my own thing, and together with another engineer, Dave, we proceeded to learn their business sufficiently to see what was needed. I spent a lot of time explaining what a web application could be made to do, and built numerous HTML prototypes to show them what was possible, and as they began to understand, we jointly decided that they needed the public web app connected to a backend workflow system to manage the workload, and connect the work in progress with status visible to the originating agency, and keep a full audit system also visible to all parties. Over sixth months the two of us (with a bit of help from another) build an application with about 70 jsp pages and a complex Oracle database to back it up.

Then IT finally woke up and decided to get involved (by this time the app was working and in production use by a few customers as a beta). They then spent the next 6 months following their own methodology to add the login page. So we spent the extra time adding many more features and getting more and more beta testers using the system (the agencies loved it).

Sabre basically paid for this system immediately as now they could distinguish internal errors from customer errors and no longer had to pay many penalties at all. In the following two years the system was eventually extended to completely automate the process and (sadly) eliminated the entire department to an enormous savings.

All from a simple question and an iterative and interactive approach to the discovery of what the customer actually needed. Sometimes the only way to find out what a customer needs is to build it over and over again until the app and the needs converge. Agile, scrum or iterative; whatever it's called it's the best way to build something new.

Then no one needs to die pointlessly in a waterfall.

Writing Multithreaded Code Is Like Juggling Chainsaws

Wed, 06 Feb 2008 03:24:36 GMT

This content should only have come from thecodist.com.

Writing multithreaded code is like juggling chainsaws; amazing when it works and truly sucky when it doesn't.

Right now at my job I am writing the foundation for a transaction processing cluster in Java, so I'm immersed in lots and lots of threads and interacting applications. When you are processing 8000 of something per second, any problems in your approach or in your choice of frameworks is magnified.

In job interviews, a popular question is "what is the major problem you have to solve in writing multithreaded code?" Generally, if they have read a little about it, they often say "avoiding deadlocks". If they have done a bit of thread coding, maybe in Swing, they might say "protected shared data". Only the truly experienced in complex threaded coding will say "avoiding doing nothing".

What's so bad about nothing? Assuming you can avoid deadlocks (generally not hard if you're disciplined) and understand when to protect data, when working in a complex high speed system you want to accomplish both of those basic requirements without slowing down the real work your threads are doing. In a Swing app, so a couple threads block for a while, or even less of a problem is a few waiting around for something to happen. In a large cluster of servers, having threads sitting around doing nothing is a waste of money. If Google is processing millions of searches daily, and half of their cpu's capacity is basically blocked waiting for some resource, it costs a lot of money and power: instead of 50,000 servers you need 100,000. That a hefty price to pay for poor thread coding.

Sure, my company will probably only use 100, and they could afford 200 servers, but why waste resources just to save a few brain cells.

For example, one of my trials used Jetty on one application, and Apache HttpClient on another. With two worker threads on the HttpClient I was able to process my test transactions. When I increased the worker threads to 7, they fell behind; at 10 it was almost dead in the water. WTF? Doing some debugging (with Yourkit Profiler, very nice) the Jetty side was mostly sitting around waiting, but the worker threads in the other app were mostly blocking (as much of 95% of the cpu time). Ah the joys of threaded coding.

The issue turned out to be a synchronized method in HttpClient that deals with Http Parameters, for each parameter for every call on every thread it would pass through this method, creating a common sync point for all the threads. Something that might seem OK for a couple threads was fatal with 10 threads running full tilt at 1000 somethings per second. The chainsaws can be really brutal.

I finally settled on a couple of technologies that work pretty well, on my developer PC (4 core Core Duo something) I was handling 8000 somethings per second at about 85% CPU.

That's another sign of properly avoided nothing, if you slam your creation with unfettered requests and the CPU rises close to 80-95% then you are seeing proper behavior. In my HTTPClient test the CPU rarely got above 25%; mostly a lot of nothing was going on. This was clear with Yourkit. Nothing is not your friend. Don't stop coding when nothing is broken; that's only step one.

Multithreaded coding in a complex application requires a lot of discipline (never assume anything, test everything), experimentation (there is no one way to make it work) and patience (sometimes lots of negative problems lead you to see the solution). It's not easy and it's not quick (never mind the project manager).

Then again neither is juggling chainsaws; plus the downside is pretty nasty.

If Java Is A Dinosaur, Then I Must Be In The Triassic Era

Wed, 09 Jan 2008 03:12:01 GMT

This content should only have come from thecodist.com.

I keep reading blog posts where people equate Java with Cobol, that it's a dying language not suited for work today, and that people who use Java are generally less intelligent about programming in general. Given that dinosaurs ruled the earth another 50 million years or so after the Triassic period, I'd say Java still has a long useful lifespan.

Not that it's perfect at all, but I've been using Java for almost 10 years now, and compared to my years of C and C++ I am fairly glad I moved on. I've worked for years starting with Basic, then Fortran, Pascal, Assembly, C, C++, Objective-C and finally to Java; I've seen a steady improvement in my ability to be productive with my language and its entourage (frameworks, libraries and communities). Like the dinosaur, every language eventually falls out of favor as new "mammals" appear but rarely does a language die out completely. Like most animals and plants, they survive and even thrive in different environments way beyond the general evolutionary landscape that might otherwise kill them off. How else can you explain Object Cobol?

For me I find I can do almost anything in Java, provided a reasonable set of choices for the environment I am writing code in. I dislike most of J2EE but there are so many better ways that have sprung up to write Java applications unless you are forced to use the worst of breed "standards". It's not the language that kills so much as the accompanying baggage you have to drag around with you. Java may not be a perfect language design (if such as thing can even be agreed on) but it gets my job done.

Not that I intend to sit on my butt and become dinosaur fodder. Scala, Erlang and Haskell are languages I find fascinating to study, although Scala being JVM based makes it more likely to be useful to me. I think of Groovy as a more laid-back Java, and relatively easy to pick up as well for us Triassic Java coders.

Give me any decent language, and I can write any decent program. The difference is always in how long will it take, how reliable will it be, and how well can it be maintained. That is the mark of a good programmer no matter what they use to write with. Of course the choice of language does make a difference, but choosing the right tools for the job is also a mark of a good programmer. Often you have no choice (other than seek alternative employment or become an advocate for change) and you have to work with what you have. There is real skill in writing good code, and real skill in understanding the strengths and weaknesses of your chosen (or forced upon) toolset.

Often a language which requires a great deal of experience and understanding to master leads the average programmer to fail miserably. I'm sorry, writing complex C++ programs is not for a beginner. Even Java can be difficult (such as at my newest job where a whole set of mainframe programmers face the difficulty of learning a new language or having to leave) if you are not familiar with the concepts of OO programming. Is there a market for people who need a simpler language? Of course there is; but never assume mastery of a simple language or toolset means automatically that you can move on to more complex projects, or even assume your basic language choice can itself handle tougher problems. The world is littered with way too many VB/Access apps on an enterprise scale, for example.

So is there something wrong with learning Java, or using Java, or even improving Java? No there isn't, unless you take the approach that you will stop using Java when they pry it from your cold dead hands. It isn't the final stop on the programming roadway but it's a powerful, useful language with an enormous open source community, great tools, and works for a variety of uses.

Face it, there isn't any one solution to writing code, any more than there was when I started in 1981 writing Fortran. No matter what your favorite new language is, someday it will suck and people will laugh at you. So the trick is to work with the best choices available to you, and keep your eyes open for the new mammals on the block.

If I'm still coding in 50 million years I'll probably not be using Java.

Ask Me How Much I Hate XCode and C

Thu, 13 Dec 2007 03:49:18 GMT

This content should only have come from thecodist.com.

In the mid-90's I spent 5 years working exclusively in C++ after years of C. I learned all the ins and out of STL, templates, overloading and the like. Now after 10 years of Java I've spent a little time working with C++ again - working on some game code for WWIIOnline, rewriting my sound code again to support Core Audio in Leopard (and eliminating OpenAL use).

Argh, C++ is so painful to me now, and XCode as an IDE is beyond lame compared to my beloved IntelliJ and even the recently learned Eclipse. Poke me in the eye with a C# stick, it would hurt less.

XCode is the latest generation from Apple, going back to the early days of MPW in the 80's, and then passing through the tools from NEXT. Some days I really feel that the folks at Apple have never worked with a real Java IDE. Other days I feel sorry for them having to carry the baggage of a generation of make files and command line tools around all day. I mean IntelliJ and Eclipse are constantly compiling the Java source while I am typing it in, making it easy for the IDE to spot errors, inconsistencies, provide tips and hints and refactorings on the fly. C++ (and even Objective-C) despite on paper being faster in execution, apparently cannot be compiled fast enough to provide the same level of feedback. With IntelliJ I rarely ever see a compiler error. With Eclipse I rarely even see the compiler at all.

So working in C++ and XCode is really painful for a Java guy like me. Yeah if I was working in Cocoa and Objective-C, it might be more pleasant, but that's not the option here. Even then, in XCode I miss all the help I get from the IDE's that I'm used to. I know people love vi and emacs and swear by command lines but I don't miss the command line these days anymore than I miss the IBM PC XT.

Of course C++ all by itself is a painful language anyway. Sure, I can create the most complicated meta-templated code I'll never understand 5 minutes later but how is that productive? I remember when I first started working on this it took me ages to remember all the requirements for storing objects in a map. Maybe my brain has been too comfortable in Java where putting an object in a HashMap is just that. Maybe the occasional overriding of hashCode() and equals() but nothing much to remember.

Don't get me thinking about memory management. In Java I don't. In C++ you always have to remember when to get rid of stuff. At least in the latest Objective-C they finally added automatic garbage collection. This is the 21st century after all. As Homer Simpson once sang in an episode where he becomes the garbage commissioner "let someone else do it".

I wrote a commercial C++ memory manager in the 90's so I'm well aware of what it takes, and even wrote the whole thing in heavily templated C++, but that was a century ago it seems. Today I'd rather work on the problem at hand instead of futzing with a language and tools that get in the way. Of course for some folks even Java gets in the way (and I understand that as well but it's not a choice for my job yet) but at least it's not C++.

When I read about the newer features being added to C++ I can only think of all the profits the Tylenol folks are going to get. Effective use of C++'s features requires a real dedication to understanding their strengths and weaknesses. It's not a language for occasional use. When I used it everyday it was painful but familiar; today having worked with Java I have a hard time keeping C++ features in my head.

The bottom line for me is I want the computer to do all the heavy lifting, and let me focus on the actual work to be done with as little annoyance and loss of focus as possible. No matter what language or tools you choose they better meet that requirement (for you) or try something else.

Or break out the pain killers.

Apple Is Now Worth More Than IBM!

Tue, 23 Oct 2007 03:42:07 GMT

This content should only have come from thecodist.com.

Amazing, Apple's stock value just exceeded IBM's for the first time in history.

I would have never thought this possible back in 1984.

What Is Experience? (Or Why EJBs Are Like Lobsters)

Tue, 16 Oct 2007 20:04:13 GMT

This content should only have come from thecodist.com.

Dealing with recruiters from both sides of the aisle, you hear a lot of requirements for people with experience. But what is experience? How do you evaluate it?

When I talk with recruiters or sourcers about jobs on the phone or by email they either ask about experience or provide a laundry list of things the customer "needs". Often they appear as a set of technologies and a required number of years "experience". Sometimes they offer a set of these and expect you to fill the a number of years of experience with each. The hope (from the customer perspective) is that this magical collection of experience points will divide "the people we want to talk to further from the worthless scum of humanity".

The expectation is that the number of years of experience in some technology somehow translates into ability, intelligence, and instant productivity. Furthermore a lack of years of experience in some technology is a sure sign of a slacker, a moron, and someone not to be hired. Thus the more technologies that can be demanded from the candidates, along with a requisite large dose of experience in each, will guarantee that a brilliant engineer will leap to the front of the herd, rescue the company's lame IT group, lead everyone into the promised land of IPO richness.

The reality is that listing experience requirements is generally useless as everyone has to lie.

If you ask me how many years experience I have in Java, it's a continuous thing; I can readily say 9 years. If you ask me how many years experience I have in EJB's I can say, eh, not sure. For any technology you use only occasionally (maybe on certain projects) the how many years experience is at best an approximation.

For example, say you ask me "how many years experience do you have eating lobsters?" how do I answer? If I ate one 10 years ago and ate one yesterday, is it two days, two years, ten years? What if I ate them once a month or once a week? How do you measure this? The natural intention is to round up to the nearest year if you are asked in years. What if they want to know in years and months, then what?

Of course the nature of the experience is what really matters, but you can't measure quality with a quantity. If I spent three months writing an app 5 years ago and wrote a whole mess of EJBs, tuned the appserver performance for them, and generally made architecture level decisions, and you spent 5 years writing an app but only called preexisting EJBs (for example Websphere Commerce Server). Who has the better experience? Clearly I do but with only 3 months (1 year) experience I won't even get an interview.

Thus I would have to lie and say "5 years" and thus the customer hasn't really learned anything from the quest for experience. So why ask?

I also find it amusing when people put out the long laundry list of technologies, many of which are marked "required". Often these are written by some HR person or recruiter to whom the names and acronyms may as well be in Chinese, and the number of years required are essentially random. You also get overlaps, as in asking for J2EE and JSPs, which is like asking do you eat shellfish and lobsters? I get the feeling that people look around their company, collect all the technologies they have ever used, stick them into a job ad and expect someone out there would actually know all of them.

I once volunteered to be a Documentum architect and developer at a company I already worked at. I took a few classes and then built a number of applications; it wasn't terribly difficult. After I left the company, every recruiter in the area kept sending me the job ad for my replacement (as they couldn't find anyone); the ad listed all sorts of complex requirements and experiences that were required, none of which I had when I started. The reality of a job is never what's in the ad.

The most important experience is actually in learning new things easily. This industry changes all the time, and hiring people based on some exact laundry list of experience (which is usually lied about) is rather pointless. If you ask for 15 technologies and I know 14 of them, why would I not be a candidate (assuming I'm telling the truth). If I have X years experience overall as a programmer, and have a long list of technologies used (assuming of course I'm not making it up) why wouldn't I be able to learn the few you have that I don't know already? How about asking how I learn something new, or even describe my experience with actually using something?

Thus the quest for experience in job ads is basically pointless, since most will lie, and only the honest tell the truth. Everyone is likely to have experience on paper (Widget Congruence Framework, sure, 5 years) and you have to interview everyone anyway.

So the next time someone asks if you how many years experience you have with EJBs, ask them about lobsters. Who knows, maybe they will buy you one!

Interview Technique: A Topdown Approach

Tue, 25 Sep 2007 01:26:41 GMT

This content should only have come from thecodist.com.

Having spent too much of life on both ends of interviewing people (mostly as the interviewee lately) I've seen and experienced a world of different styles. The intent of a first interview is usually to separate the ditch-digger from the real coder.

Most of the interview techniques suck.

Interviewers often begin with asking the interviewee about programming basics, to describe object-oriented programming concepts, to describe simple language constructs, or the like. The assumption is that the ditch digger doesn't know anything like that. Of course, an experienced programmer might be good at coding but not be able to answer theoretical questions, or be good at complex concepts but spend little time with language or framework features that the IDE takes care of. Basic knowledge is also no guarantee they know how to use it. I once new a guy who aced a Java Certification test but was utterly incapable of writing even the simplest actual program.

So, OK, you say, it's just a phone screen. Now we will make them take tests, talk with some managers, perhaps solve some Pirate Puzzles or even survive a battery of intense interviews from bored (and sometimes cruel) developers. Then we will sort out the tired, the poor and the huddled masses, oh wait, wrong concept. We will then hire the brightest, smartest person in the world!

Yet after all this massive effort on the part of many people in the organization, you still wind up with programmers who are average or worse in delivering real applications.

Clearly finding the right people is more of a crapshoot than most companies would admit to. The one thing you really want to know is "will the candidate be able to write functional code, deliver it in a reasonable time, with good quality and maintainability". Sadly that's the hardest thing to figure out without actually hiring them and seeing how well they do. I do see more people these days doing contract-to-hire.

In my experience on the hiring side, the quickest type of screen to see how well they might function in real development is to pick a random entry in their resume that appeared to be significant, and ask them to describe the requirements, the technologies, the choices, the history and what their precise role was. The assumption is that someone who actually did a real project could describe it in great detail. For me, I can still remember all the details of virtually everything on my resume, since most of them took months (or in couple cases years) out of my life. It's is very hard to riff some random details and fool a competent engineer or even manager. I want to know how intimate do you know something you say you did for a fairly long period of time, even if it's a few years in the past. You may forget the syntax or some method calls, but not something that you spent months doing.

The process of programming is a lot of little details, many of which have to be mastered and reused in most projects, even as the technologies and environment changes. Dealing with managers, requirements, plans, code management systems, testing, QA, debugging, making choices in tools or frameworks all are things you do in most projects but the details change. I want to know how the candidate thinks about the work of programming, and how they have done more so than some intimate details about a language or tool or API. These things change from time to time, the ability to actually deliver does not.

I think very little of the bottom-up approach that many companies take. They focus on weeding out the ditch-diggers and then hope some deliverers survive. I would rather find the deliverers and let the others weed themselves out.

Of course this isn't a perfect solution either, nothing is short of having people work for you for a few months and see if they can deliver. I would rather know that a person can articulate what they have done on projects and understand the process of delivery (which of course means designing, coding, testing, debugging and understanding what to do) and work the interview from that perspective.

After all, no one ever asks a ditch digger to define dirt, they want to know if they can dig it.

Writing A Web Application Framework, One More Time, Again

Tue, 18 Sep 2007 17:52:53 GMT

This content should only have come from thecodist.com.

In the past year I've written two complete java web application frameworks from scratch; one like Wicket, and one (Blogfiche) a more traditional MVAC framework with an alternative syntax to HTML. So why am I building another one?

Am I nucking futs?

The answer is always the search for more programmer productivity, flexibility and reliability. Blogfiche (which runs this blog and other things) has proven itself to be flexible, reliable, and for what I use it for, scalable. Digg and Reddit traffic don't faze it, even though it runs on a shared (and rather overloaded) server. The alternate HTML syntax is fun to use, much less irritating than HTML if you write by hand:

    if(headlines:sizenot0)[
      div(class=articlebox heads)[
        loop(post|headlines)[
          p[a(href={post:url})[{post.title}] span[{post.created:datetime}]]
        ]
      ]
    ]

So why do another one? Mainly I want to be able to build an entire web application without any recompilation, yet still have good performance in production. I am using the solid foundation of my Fiche framework (built on the servlet spec) including its automatic caching of web content. On top of this I intend to support Javascript (Rhino) and Groovy (and anything else interesting) and see what I like better. Although I can use the alternative HTML syntax, I am building a view technology on top of regular XHTML to make it easier to use examples from the web.

Something like:

  <head>
    <title>{title}</title>
  </head>
  <body>
  {if(test)}
    <p>Test</p>
  {else}
    <p>Not Test</p>
  {end}
  </body>

For database support I will continue to use iBatis, if I can properly reload the sqlmaps when they change, or maybe try something new like couchDB, or even build something similar to ActiveRecord. There is a lot of possibilities here; the primary point is to be able to update code and database use without compilation.

I am not trying to replicate PHP or ROR or whatever flavor you might enjoy. Software is an infinitely malleable clay; you don't know what you can do unless you try something.

Again with the why? Why not, I enjoy it, I like productivity, challenges, and I have time while I wait in absolute contractor hell; at least my mind is working and I can avoid going absolutely bonkers waiting on people to make a #@!$#@decision.

A Web Framework In Scala

Tue, 11 Sep 2007 01:59:43 GMT

This content should only have come from thecodist.com.

lift Web Framework

Given how much I love writing frameworks (the one running this blog for example), it's cool to see someone is working on a framework using scala. It's still an early alpha, but it's interesting to see how one can leverage Scala's interesting OO-Functional hybrid language.