What The F*ck?!?

Hey look, Now I AM different! Just like you!

2009-09-24T23:30:00.000-07:00

So, I went and bought a Macbook Pro.

Yes, after everything I said previously, I am now a Mac user.

But I didn't do it to be cool. Or because Macs are any easier to use.

Here are some reasons why:

Instant sleep and resume. I can close the lid, and it sleeps.. for days! And when I open the lid, its on. Instantly. Every time. I've never seen a windows notebook do that.

Great battery life, without sacrificing performance. Is it 7 hours like they claim? I don't think so. But I still average 4 to 5 hours and thats way more than any windows notebook I've ever heard of.

Unix-ish. Its got a unix derivative (mach) core, which makes it great for a developer person like myself. I use the shell and I use ssh and other command line tools. And its rock solid. Are there any viruses that infect unix? I dont know of any. I am so sick and tired of constantly battling against virus infection on my pc's.

Amazing engineering. As a former engineer, I just appreciate the precision design and manufacturing. Its perfect.

I can run windows in a vm nearly seamlessly.

Installing apps is rarely more than just copying the file into the applications folder.

The expose feature as well as the 2,3 and 4 figure gesture features on the mousepad. Not to mention the huge mousepad.

The sucker just feels and looks good. And that makes me feel good. And that counts for something.

OK, so, here's what I don't like:

Finder: it sucks. To be fair, window's explorer also sucks. But you can replace it with Directory Opus, for which there is no MacOS equivalent. This is probably my single biggest complaint.

The dock: it also sucks. I like the Windows task manager.

There doesn't seem to be as much free software.

I don't like how almost everything is too simplistic, like you can't be trusted to mess with the finer adjustments and options. Then again, now I don't have to worry about all that. Sometimes I feel like the system is treating me like an idiot. But then I've got that nice shell and a unix kernel..

iTunes no longer syncs with my Palm Pre for no other reason than Apple sucks and doesn't want it to work. You know what, I don't give a flying f*ck about the USB consortium or who can use what USB id's and whatever bullshit reason they are giving. I have the right to sync my hardware and there is no technical reason for not being able to do so. Apple, take your head out of your ass. Palm: find another way, please.

So yeah, I am a Mac user now. But I will never have that smug, I'm better than you attitude just because I use a Mac. I have plenty of other reasons already...

Programming is like Cooking

2009-07-06T15:23:00.000-07:00

I like to cook. And I like to program. I dont know if this is a common thing or not but I know at least one other person like myself. There must be something to it. Particularly because of the common phrase "spaghetti programing". And now I come to find that's not the only food analogy that's been coined. I've been missing out!

So, spaghetti code is what you'd expect: meandering code that loops in on itself and becomes a tangled unsortable mess.

But what about ravioli code? Well that's an analogy to object oriented programming, of course!

Then there's lasagna code. This is code that is structured into, you guessed it, layers! Each layer (or tier) is separated by a well defined interface (a noodle).

But the one I like best of all is the Spaghetti with Meatballs coding style. I see this a lot, especially with PHP programming. This is messy, tangled procedural code with a sprinkling of objects thrown in! Because like meatballs, objects make everything better!

Now I'm hungry. I think I want a meatball lasagna with raviolis on top. mmm.

I want to be different! (just like all the other different people)

2009-07-01T12:41:00.000-07:00

Don't get me wrong. I really admire Apple and I think their computers and operating system are pretty cool. Maybe even superior in many ways. And their TV commercials are hilarious.

But I am really getting tired of being looked down on by the Elite Uber-Geeks who think anyone who doesn't use a Mac is a caveman.

And this is from someone who used to be Mr. Alternative Computer guy, in a way much worse than a Mac user (anybody remember Amiga?).

Granted, I do miss my Macbook Pro. I miss the near instant sleep mode and how it can stay in that mode for days before running out of juice. I miss the lighted keyboard at night. I miss how applications are installed just by copying them into the applications folder. And the physical design -- well its a marvel of engineering and design.

And Parallels comes close to making a Mac perfect.

But that's just not enough to make switching worthwhile. Not when a Mac costs so much more than comparable PC hardware (and much more than budget PC's). Not to mention there seems to be a lot less free software. You are apparently expected to be nickeled and dimed (the phrase should be adjusted to account for the premium prices all Apple stuff seems to command over the equivalent non Apple alternative..) for every little application you might want, however small and transient it may be (hello AppStore!).

Apple may be the only practical, real alternative to Windows (the hardware no longer is, since its just a PC in fancy clothes these days) for most people. But if you really want the alternative, something that's truly open and free, the real underdog of the computing world, try Linux or even one of the other really obscure OS's out there.

But if you just want to look like you are hip and alternative, get a Mac, and keep listening to KROQ. The rest of us will be using stuff that makes your Mac look like a bike with training wheels and listening to music that would probably make you cry.

Cheeseburger, fries, and a large orange drink...

2009-05-06T14:34:00.000-07:00

PHP: its like fast food..

You know its bad for you...

You feel like crap after eating it...

But damnit, its right there, oh so conveniently located on the way to work, and sometimes a greasy cheeseburger just hits the spot, even though you know you'll pay for it later in heartburn and much later in high cholesterol and love handles, though right now its really cheap on the wallet.

Its a guilty pleasure.

And while you're sucking down that grease ball burger, you see the local soup and salad restaurant and think "next time, I'll eat right.."

But come the next day and you see that taco joint and...

Egads! Monads!

2008-12-18T12:38:00.000-08:00

There's a whole class of languages you may never have heard of, or at least, you don't know what makes them different. Most of us have been using the "practical", popular languages, like C or PHP or Java or Ruby etc. These are all "imperative" languages. IE, they are nothing more than a sequence of one "do this" after another. They are simple to understand, relatively. But there's a class of languages called "Functional languages". You might think, well, all languages have functions, right?

Imperative languages have a lot of limitations you may not be aware of. One obvious limit is that they are a sequence of actions that have to be run more or less in order. That's a problem when you've got a computer with 2 or 4 or more separate "cores", and you can't easily split that program into 2 or 4 or more separate parts to run at the same time. Another is error handling. Do you output an error? Does your function fail? Do you return an error value? And what about those unit tests you are supposed to be doing. How easy are those to do, when you have to set up a test situation for each function or method you want to test, trying to simulate what might actually exist when the program is really running? Or how about debugging, when you have to track down a problem and there are many places where data is changed and used and you don't know which of those are the problem, or if its something else you don't even remember?

A lot of the problems of imperative languages is due to the fact that their functions (and methods in OO programing) are not deterministic. IE, they do not act like the functions in mathematics. They take arguments and return a value, of course, but they can also do any number of things outside their own scope. Like output text for display. Or change a database record. Or flip a pixel on. Or send a signal down a wire that goes somewhere.. That means that you cannot call the function with the same arguments and expect to get the same result. You also cannot assume that the rest of your program or data hasn't changed. That makes testing hard, and debugging hard. And you have to constantly check for errors and decide if you can go on or not to the next function.

Functional languages do away with that because functions are not allowed to do anything other than return something. They are deterministic. You always know that with a certain input you will get the same output. That makes testing really easy. It also makes debugging much easier because you only have to follow the flow, and no need to worry about what might have been changed somewhere else not in that flow. It also makes it much easier to split a program up into different parts that can be run at the same time (or in a different order) because you can easily tell what functions are dependant on others (or not).

Of course, the only problem is, how the hell do you actually do anything if you can't input or output things? For that matter, how do you make sure things happen in the order you want them to (like outputting words in the right order for a grammatically correct sentence).

Monads!

Just to be annoying, stay tuned for the rest of my thought... as soon as I am finished thinking it..

[language du jour] ON [training wheels]

2008-08-29T15:57:00.000-07:00

Seems like everybody's having a collective orgasm over frameworks like Ruby On Rails and all the countless knockoffs.

I certainly appreciate these systems, they are definitely filling a niche need and are bringing new ideas to the programming table.

The language du jour doesn't bother me. I like to study new languages and see where they can improve things. What bothers me is the near religious followers of each language, going around stating that their language is The Way to nirvana (which reminds me of the song I Am The Way by Loudon Wainright III).

And frameworks don't bother me either. Except for the same religious adherants as above.

Oh, and the fact that frameworks are so limiting. I suppose frameworks have to be, in order to do what they do. You are expected to work within what they've defined - using their design patterns (almost universally using MVC, etc), class heirarchies, etc. The Rails monicker makes sense, because it is pretty rigid.

But I don't want rails. I don't want the programming equivalent of training wheels (which metaforicaly speaking would be better than being on rails..). Because what happens when you grow beyond the training wheels?

I want tools so I can easily build my own vehicle with my own kind of wheels on my own kind of travel surface.

Actually I am thinking something less like rails and wheels, and more like an amphibious multi-legged critter with a jet pack.

Not sure what that is, though, in language terms...

You young whipper snappers...

2008-07-10T12:45:00.000-07:00

You know, I'm really getting tired of the generation of kids today who think they're on to something new with their cutesy abbreviated asynchronous stateless communication methods.

Yes, I am talking about you.

The one with the cell phone tapping out messages in T9 text.

You didn't really think you invented the (or any variation of the) "emoticon", did you?

Maybe you think you are something big because of news stories about how you communicate?

Well, you're not. I have half a mind to beat you over the head with this here 300 baud modem...

You see, back before you were born, even before most of your parents were even able to have a chance at getting laid, we were inventing this stuff.

No, we didn't have computers in our pockets. Back in those days, our computers sat on top of desks, or took up whole cabinets. And our screens were these huge things called CRT's, only we usually called them monitors since there was only one kind. And instead of the internet, we had modems and phone hookups.

We did have that in common, I suppose.. the phone. We weren't limited by tiny keyboards and tiny screens, and we weren't mobile and in a hurry all the time. But we did have to deal with our modems, which were slow. They were measured in 'baud' which came in quantities as small as a few hundred. It took quite a few of them to encode a single letter. It was so slow that most people could read it as fast or faster than it came in.

So we invented abbreviations. We invented "smilies" to denote general disposition... happy, sad, angry, etc. These are the things you call "emoticons" today. We didn't even have icons on our computers at the time. Just text. Sometimes in just one color. Yeah! I know, its hard to imagine.

I remember at the time some people even thinking that we were going to be somehow all emotionally and socially stunted or at least totally disconnected from the rest of society. Granted some of us were (are). But that's no different than the dumb football jock that never grows up and never learns how to be socialy acceptable outside of a group of beer bonging idiots (and I am sure this is the exception among people in sports, as is the uber-nerd that can't get laid to save his life).

But here we are, all grown up. Some of us are billionaires (can you say Bill Gates or Steve Jobs?). Some of us are just relatively normalish folk with normal kids and lives.

So you young whipper snappers out there... don't be so full of yourselves. And don't worry about the old folks who worry about you rotting your brains with texting and mobile video watching. Sure, you are probably letting your brains lay fallow while you f*ck around with technology. But eventualy, out of that, a few of you are going to get your shit together and actually invent something that your kids will take to some extreme level which will cause you to wonder if your kids are going to turn out ok.

Ah, sweet, sweet payback... I can't wait.

A brief history of web design.

2008-06-30T12:28:00.000-07:00

So anyway, I was trying to explain to someone the pitfalls of MVC, and how this design methodology for web development came to be popular, and finally how the modern implementations of MVC are really kinda different than what the inventor of MVC was really shooting for.

Lets start with a brief history:

First, there was HTML and the Mosaic browser to render it (and lynx for command line viewing). Ah, those were the days. It was all static and things were good.

Then somebody got the bright idea that, hey, wouldn't it be nice if we could include other HTML files into an HTML file, output a few interesting system variables like dates, and execute other programs passing their output along? Thus Server Side Includes were born. This evolved, and soon SSI had language contructs like if/then, etc. Much more advanced languages were invented using this style, like PHP and ASP. These "template" languages were designed to be "HTML with embeded code"

Of course, other options were to go the other way around and just run a program that generated HTML. Perl was a natural here. To make things easier, these languages created templating systems where HTML code files could be loaded, and special markers within them could be replaced by content generated by the code. This created a nice separation between the code and the presentation so that visual designers could work on the presentation without so much messing around with the code.

This separation was then emulated by all the other languages, even though they already were essentially implentations of template systems. Why? Because they didn't force this separation. So template libraries were designed that did force the separation.

At the same time, using a database to store your dynamic information and using code to format it into something presentable came into wide use. Now you've got a three tier system... data, code, and presentation.

MVC was a design pattern already in wide use for application development with standard GUI's. It was natural to apply this to web sites... the Model was the database, the View was the presentation, and the Controler was the code that tied it all together.

Instead of a procedural stream of commands to query the database, massage the data, and format it into HTML, you now have a trio of Objects talking to each other: Controler figures out what to do based on the url called, it asks the Model for some data, and then it tells the View to display it.

Now, in theory, you can have one guy design a kick-ass database and a Model to access it, while somebody else does the Controlers and your design guy can create the views (or at least the templates used by the view object).

Except that web applications are not the same as conventional desktop apps.

The first generations of MVC based web apps simply sent the resulting static HTML to the browser for display. Then some jerk had to invent a way to update portions of the HTML being displayed, using javascript, on the browser. And those finicky users wanted things to be faster, so they wanted things like form validation to happen in the browser, and they just loved the speed of only updating parts of the HTML instead of refreshing the whole page.

So now, on the browser, you have MVC again: the asynchronous data requests to the server (Model), the HTML which can be accessed through a series of objects (the View) and the javascript making it all happen (Controler). So now you have to implement parts of your application's Controlers in two places (the models and views on the browser side can be relatively dumb and just ask for stuff from the server). Like form validation - on the browser for speed and convenience, but also again on the server to prevent hackers from F'ing things up.

All of this is leading up to the fact that the modern MVC methodology is not exactly what its inventer had in mind in the first place.

Like a lot of those early computer pioneers, he was really looking at how can we make computers easier to use, and not necessarily how can we make them easier to program.

Originaly, the Model was not supposed to be some abstract mathematical construct that was designed to be efficient for a computer to store and index (ie, a relational database). It was supposed to be an intermediary between how a person thought of the data and how it actually needed to be stored. The View was supposed to be a user maleable canvas on which to inspect and modify that data. The Controler is largely the same, and just coordinated between views.

It may seem like a minor difference, but its actualy significant: the modern model is an attempt at an object oriented abstraction to a database. The original idea of a model was an attempt at an abstraction to a person's mental idea of the data. Instead of the database leading the way, it should be the human leading the way and the computer bending to his way of thinking.

I dont know exactly yet how to do it. But a new method needs to be developed that handles both problems -- making it easier to program, and making it easier for users to use.

In this fanciful system, you would write one bit of code that would generate resulting code to run on both the client and the server so you don't have to duplicate things. It would also let you easily model things the way people expect them to be and translate that into something efficient for the computer to handle internaly.

Instead of the current state of affairs, where the programmer is forced to write largely duplicated code in perhaps different languages to do the same thing over and over, and the user is forced to jump through unintuitive hoops while using the software - mainly because the programmer is too busy with grunt work to be bothered with making anything more than just barely usable (or very usable to him, or anyone with a brain like his, which is very few people)

My god, its full of lines...

2008-06-24T13:43:00.000-07:00

I love graph paper.

I like computers and make a living off programming them. But they infuriate me. They are cantankerous machines that for all their uses have so many faults. Its a love hate relationship.

But graph paper is, well, perfect.

Thats not to say that other papers aren't great too. I am fond of tracing paper (or onion skin for you hardcore users). Parchment is cool too. I don't know if velum really counts.

But graph paper is the ultimate surface for thinking on. It doesn't matter if you are creating a diagram or schematic, a mechanical illustration, a chart or table, a website prototype, or even just code snippets. The occasional purely artistic cartoon (I've mastered Bill The Cat) is even at home.

Of course graph paper requires its mate, a fine pencil, which are hard to come by.

I grew up with graph paper. I have pads that are more than 20 years old. I have some of scribblings by my late father. I know there are some that have been lost over the years but I could probably duplicate them from memory, so clear the images are in my head.

I don't plan to ever stop using graph paper, unless they stop making it. But there are times when I wish I had something even remotely close to the utility of graph paper on my computer. But as far as I know, there isn't anything. Sure, there are lots of applications for creating various sorts of graphs and tables and diagrams, even whole standards for such things like UML. And there are word processors, and desktop publishing programs, and everything in between, and programs to make rapid website development, and drawing programs and collaborative 'whiteboarding' tools ad nauseum.

But nothing that comes close to the simple flexibility of graph paper. Never mind such old school technologies like post it notes, 3 x 5 cards, etc.

Is it that it can't be done? Or is it that its such a simple concept that when people set down to do it, they get carried away with feature creep and "overcomplexification"?

When I first started programming on my Amiga way back in the day, I wanted to create such a program. It would have had basic tools for drawing, text, tables (spreadsheets) etc and would organize documents. I didn't want to have to fire up a paint program just to draw a little picture and then try to import that into a wordprocessor just to add some text to it and then import that into a database so I could find what I was looking for later.

Turns out 20 years later there still isn't anything quite like what I envisioned then. Unless I've missed it.

Now, where's my graph paper..

Steampunk'd...

2008-06-19T13:33:00.000-07:00

Think I have a new interest and hobby: steam punk.

What, you haven't heard of this?

Then you must turn in your nerd card and go hang out with the jocks.

Steam Punk is basically an alternate history fantasy: go back to the 19th century when steam locomotives were hip and everything was made from wood and brass, and then extrapolate modern technology based on that (instead of silicon, plastic, petroleum and nuclear).

If you've got a fascination for turn of the century stuff, this is for you. Old mechanical typewriters instead of computer keyboards. Brass knobs and dials instead of boring plastic buttons and lcd screens. Roll top desks. Tubing, valves, and mechanical marvels.

I've always looked upon this time in history with fascination and feeling like I should have been born a hundred years earlier. I read Jules Verne. I loved the Wild Wild West.

Now imagine blending Steam Punk with: LEGO And Star Wars. I think I just died and went to nerd heaven. If I believed in such things. And if I did, it would be something like that.

MVC is dead! Long live MVC!

2008-04-17T22:17:00.000-07:00

It happens. A TLA (Three Letter Acronym) becomes popular for a time, but eventually, a new TLA rises up and overthrows the previous TLA ruler.

Just like with political leaders and revolutions. But as we all know, the more things change, the more they stay the same.

So the latest TLAs, among others, are RIA and SOA. These are, respectively, Rich Internet Application and Service Oriented Architecture.

What?

OK, an RIA is a web-based application that uses more than just your basic HTML (on the "front end"). Mostly, this means AJAX (ah, an FLA!). Which means more work is being done in your browser, thus speeding things up and making lots of visual flash more doable.

SOA just means a web-application that doesn't just spit out HTML (on the "back end"), but instead spits out some more easily parseable format like XML or JSON and is (hopefully) clearly documented. This lets multiple different other applications make use it, instead of just being displayed by one built in HTML gui.

So what am I getting at? You already know these things? Well, a recent article claimed that MVC was dead because of the advent of RIA-SOA. Model View Controler is a design pattern that goes all the way back to the days of Smalltalk in the 1970's. More recently is has become pretty standard in the design of web-applications.

In the typical implementation of MVC, the Model is generally a class that handles saving/loading information from a database. The View is another class that creates the HTML, and finally the Controler is what glues it all together.

So how does this contrast with RIA-SOA? Well lets see. The RIA part contains code to display HTML (the View), code to get/save information (the Model) which it does by consuming services provided by the SOA, and most likely some more code to handle the interaction (Controler) as you click on things. That's on the front end. On the back end, you have the code that loads and saves from a database (Model), spits back formatted data (View), and defines what you can do (Controler).

It seems to me that, really, RIA-SOA is just MVC-MVC. Yeah, its a higher level concept built on top of MVC because it takes what would normally just run on the back end, and splits it into two parts to put more of the work onto the front end. But to say it kills MVC is, really, kinda silly.

And you can't really simplify it to be M-VC, either. That is, you can't just implement all of the View and Controler on the front end and the Model on the back end. Why? Security, for one. You have to maintain all logic on the back end as well as the front end to prevent somebody doing something bad. Having the logic on the front end is, well, candy to make it look nice.

Now, all of this ignores the fact that the typical, modern implementation of MVC really is not at all what the inventor intended for it to be (see Naked Objects, particularly the forward by Trygve Reenskaug [yes, that is spelled correctly..]).

So, yes, in a way, MVC is dead, long live MVC...

I for one welcome our new OS overlords

2008-03-27T19:00:00.000-07:00

I've been saying it for years now. My first thoughts on the situation was the idea that there could be universal hardware drivers that any OS could use, coupled with a universal binary format that would run on any cpu. With those in place you could have OS's that could run on any computer, and software that could run on any OS.

Mind you, I had this idea back when I was programming my Amiga (and they were still being made...). So this was pre Java, before Linux and before any kind of reasonable emulation or virtual machines.

So here we are today. We have things like Java where you can, in theory, write code that will run on almost anything. We also have lots of interpreted languages that run effectively on almost anything, like PHP, perl, python, Javascript, etc etc.

But what about the os part? Well, we have Linux which does run on almost anything, and we have Windows which runs on only x86 hardware. But Linux lacks the driver support of Windows and Windows lacks the universality of Linux.

Microsoft doesn't seem to be interested in decoupling Windows from the hardware (not that it would be easy, of course, but why bother?) and Linux as popular as it has become may never get to where Windows is.

Never mind other OS's.

Except for one thing. Virtual Machines. This software lets you virtually split up your hardware into multiple simulated machines. Thus, you can run Windows and Linux at the same time. You can run Linux on top of Windows and in theory take advantage of hardware drivers in Windows that arent in Linux.

You are less restricted by having to choose an OS, since you can run many of them at once. At some point, your OS just wont matter any more. What will matter is your Virtual Machine, which will become the new OS. Which is as it should have been all along, because a Virtual Machine is the bare minimum of software required to make the hardware accessible from the software.

Windows may not be taken down by another, superior OS like Linux or MacOS or whatever comes along. It will be taken down by some Virtual Machine OS that lets you use any other OS's you want to use.

And Intel will be taken down when enough software is written in some portable binary format (java? .net? something else?) that makes choice of CPU irrelevant.

Wifi: I'm not dead! 'Ere. He says he's not dead! Yes he is!

2008-03-17T19:05:00.001-07:00

So now people are saying that WiFi, or 802.11a/b/g/n wireless hotspots, is going to die. Why? Because we'll all switch over to using cellular broadband (3.5 or 4G) networks.

Hogwash.

That's like saying we'll all switch to WiFi and that Ethernet will die. And that didn't exactly happen.

Granted, WiFi's explosive growth will probably slow down. But will cellular broadband ever be as cheap as WiFi? Will I be able to have my own cellular hotspot in my home for my own network?

WiFi won't die.

Grand UNIfied Bulletin Board System

2007-10-16T10:54:00.000-07:00

Lately I've been mulling this idea in my head and trying to visualize how it would look.

The issue(s) are thus: I have this blog here. Its cool. It lets people make comments to my blog entries. But it sucks, because nobody (well, hardly anybody) knows its here. Meanwhile all my friends are on MySpace, which IMHO sucks donkey balls. It would be nice if my blogs here could also be automatically blogs on MySpace, because I am not going to take the time to repost them there.

There are other times I may post something onto a message board, when I want to strike up a discussion (as opposed to just barfing my thoughts onto a blog with no real expectation of a discussion about it). Sometimes I may want that to also be a blog entry, but I'm too lazy to cross post it to my blog. And what happens if I did, and then people make comments to both the blog and the message board posting?

Recently there was a thread on the Knoppmyth message board about a problem I and others were having. The solution was found after a while but it was not clear how to apply it, so I helpfully went through the thread and some other threads and compiled a how-to which I posted onto the knoppmyth wiki.

In my previous blog entry, I mentioned a wiki that had become a rather cluttered looking discussion -- it was more like a message thread, but one that could be edited. It was a mess.

On Slashdot, it occurred to me one day while reading a particularly funny comment to an article that this comment will probably be largely lost to obscurity because you would only ever see it if you read through all the comments for that article.

So taking all these thoughts and putting them together I am lead to the idea of a Grand Unified Bulletin Board System. This would embody all the concepts of message boards (which are the web incarnation of the original BBS's from days gone by..), blogs, wiki's, CMS's, Social Networking, and commentary into a unified mashup.

I haven't figured out how it's all going to work, but trust me, it's going to be cool. And if I don't do it, somebody else will. Hopefully this will be a little easier to do than what scientists face with the Grand Unification Theory.

Smells like Code Generation

2007-10-10T22:19:00.000-07:00

Recently I came across a wiki that attempted to discuss the merits of code generation, with the initial postulation that Code Generation is a "Design Smell"... IE, that if you have to do code generation, then there is something wrong with the design of the language you are using.

Code generation is really just another name for a compiler. And we've been using compilers for a long time. A C++ compiler is just a code generator that creates lower level code (C or directly to assembler/machine code) from a description you give it (the C++ code). That's really not so much different than, say, CodeCharge which lets you design visually but stores the definition as an XML file which is then "compiled", IE code is generated on demand.

I don't think anybody that is against Code Generation could possibly say that a C++ compiler is bad.

But look at the progression of compilers. The first compilers were made because people realized that a lot of the machine code they were writing was similar. So they created higher-level languages to represent these similarities as language features that could be compiled to the lower level machine code. IE, a code generator.

So the concept of Object Oriented Programming comes along. Languages like C had no way of expressing this natively. But you could do OOP with C by coding it by hand. And so once again you have these similar bits of code being written all the time. And one day somebody decided, lets represent those patterns with an even higher level language, and C++ was born. Initially, C++ compiled into C which was then compiled in machine code. You would think the anti code generation people's heads would explode at the thought.

Right now we have a generation of web applications being written with just tons of similar code being written. Design patterns like MVC and CRUD and boring but necessary security checks in data forms etc etc. So we have all sorts of code generators, some compiler like, some on the fly, some using frameworks.

What we really need, it seems, is the next generation of languages that expresses these web application requirements as part of the language. Then we can make interpreters and/or compilers. And make that language a standard instead of having dozens of different incompatible frameworks and code generators.

Let the cycle begin again!

Hey homey, I can see your doodle...

2007-09-24T16:01:00.000-07:00

Here's another design pattern/framework idea I hadn't come across before. Its called Naked Objects. Not sure why they call it that, but here it is in a nutshell:

1. All your business logic should be strictly encapsulated.
2. Your user interface should be a direct representation of these objects. IE the GUI should only call upon those objects.
3. The GUI should be generated from the definition of those objects, using code generation techniques or reflection (preferred).

This could be combined with ORM such that you would only define the domain objects and the GUI and Database layers would be generated from that, though this is not part of the definition.

I am not sure how well this would work. It almost sounds like it could lead to the same sort of mis-match that occurs with ORM. What if your objects have much more functionality (say, to support a very robust API) than you want to expose in a default GUI? How would you enable a graphic designer to make cosmetic changes to this auto-generated GUI?

At any rate, it's another interesting concept. And frankly, I like the name.

With a span span here, and a span span there, here a span, there a span, everywhere a ...

2007-09-10T14:20:00.000-07:00

I said it before but I will say it again, because you are all still doing it:

STOP FUCKING using SPAN and DIV tags for EVERYTHING!

Its amazing to me how whenever something new and "better" comes along, that we all just completely stop doing things the "old" way, even to the point of shunning the old ways and ostracizing anyone who still does.

Case in point: the much maligned table tag in HTML. Once the darling of HTML layout and design, its use as such has been replaced by CSS positioning. This is because HTML is supposed to be for representing the structure of your data, and not the layout and display of that data.

So now, like Salt and Eggs before it, the poor table is considered evil.

Have we all forgotten that a table is more than just a display technique, but also a very important form of data structure? Its OK to use a table tag to represent - hey! - a TABLE of data.

Oh, and this goes for you people who want to make everything into an Object! This means languages that are purely object oriented, and trying to force relational databases into object oriented paradigms. Stop it! Sometimes, arrays are good. Sometimes, set theory is appropriate. Procedural programing just hits the spot sometimes (and I'm sorry to break it to you, but even Objects contain procedural code!).

I'm not saying I don't love and use object oriented programming. Its just that I have not forgotten how we got here, and how all the old methodologies are still useful tools. I like my arrays and integers and strings and procedural code as well as my objects.

Now, I am going to eat some eggs with salt on them, cooked in oil, without worrying about my heart exploding... oh yeah, and coffee too.

To generate, or not to generate, that is the question

2007-08-30T16:50:00.000-07:00

I've already admitted to being a lazy programmer, because I use a code generator application. I've already said I am looking for alternatives, looking at open source PHP frameworks like Kohana. But I don't wish to give up the time savings from the code generator.

I wish to be able to create my application with both HTML frontend as well as an API that can be used by AJAX methods as well as external appliacations. I've long ago dissed the SOAP methodology in favor of REST. I'm also giving the finger to the typical ORM solutions. This isn't leaving me with a lot of options.

My current code generator assumes you are starting with an already defined database. This is good from the perspective that the database should be designed first by someone who knows what they are doing, and not by a designer or even a mere progammer.

The problem with every framework or code generation system I have seen is that they start from one point and expand from there. This could be to start from the database and then extrapolate out from that to generate the code and the presentation. Or they might start from the code and then generate a schema to map code data/objects to.

The purpose of all this of course is to reduce the tedium of coding:

Database: CRUD operations, validating and filtering data going in/out of the db, help constructing more complex SQL queries.

Code: validating and filtering external data from forms, external API's, etc, coordinating among many different data sources and assembling them together for output.

Presentation: formatting into HTML, or JSON, or XML, or whatever; consistent look and feel forms connected to the code, validating and filtering data.

Instead of one of these tiers driving the others, it should be instead possible to have them all done independently with some easy streamlined method for connecting them together. This way, the DBA can design his lovely normalized database schema while the designers can create a slick, end-user intuitive GUI. And the poor programmer caught in the middle doesn't have to deal with the impossible disconnect between the presentation and the data abstraction, he can just connect it all up easily and write his business logic to make it all work.

ORM BAD! ARGGHH!!!

2007-07-27T16:00:00.000-07:00

The more I think about it the more I realize two things:

1. True Object Relational Mapping is inherently flawed. Database tables are not objects, nor are records. They cannot inherit from another. They do not encapsulate data with access methods.

2. Lots of systems calling themselves ORM really are not by the strictest definition of ORM. They are Object Oriented Database Abstractions... but that just doesn't have as nice a ring to it. It also doesn't fit in with the politically correct "Everything should be an object" doctrine.

Look, people: Object Orientation is great. But so is procedural programing, arrays and set theory, aspect oriented programing, etc.

What is it that these ORM systems are often trying to solve? In many cases its not "I have a ton of objects I need persisted to a storage medium". I think more often than not, its "I don't want to have to write an assload of code to do basically the same stuff over and over again when accessing my database". They are not so much concerned with what form the data is in, just that they can Create it, Read it, Update it or Delete it. Yes folks, its CRUD. And I think CRUD is set to whip ORM's ass just like REST is beating SOAP and JSON vs XML.

That's not to say that we can't or shouldn't use OO design to create our CRUD code. We just shouldn't be trying to directly map our objects into data.

So, now that we have that out of the way, lets look at the two common perspectives on how this should work:

1. Define the Code first, then generate a database schema to match.
2. Define the database schema first and then generate the code to access it.

A sub part of method 2 is whether to go strictly by the schema itself, or to add a config file of some sort.

The main idea here is be further lazy (ok, its supposed to be to keep the code and schema in sync; in database terms, normalized..) and define the data structure only once. Going with the code first method is excelent if you don't have a database already created. But what if you have an existing DB? What if you have a DBA who makes changes to the database but is not a programmer? What if you have another part your application written in another language and framework? What if you just want to go into phpMyAdmin and tweek the database that way?

Using the schema first method eliminates all those issues, but has some of its own. What if you want to switch to another type of database backend? With the previous method, it could be as easy as plugging in the new database adapter and regenerating the schema. What if your database design (or your database system) doesn't provide enough or the right kind of meta-data to be able to create usable code from? This is where the config file comes in, covering what's missing or non-standard.

A third option is actually possible, wherein the config file takes full control and defines the schema in a code and database neutral form, from which both the code and schema are generated from.

I definitely am ruling out the code first option. I think there are too many problems with this, and databases should really be designed by a database expert. I think bad code is much easier to fix later on than a badly designed database. Especially if you can regenerate much of the code from the database. The third option is great if you intend to target more than one database backend.

Suitable for framing

2007-07-27T12:48:00.000-07:00

I have been looking for a framework to adopt for an existing large project. I have been using a RAD tool (Codecharge Studio, CCS) since the project's inception some years ago. It has treated me relatively well, allowing me to rapidly get the thing working, where it would probably have taken too long any other way.

But over that time I have come up against the limitations of this tool. It works great for what it does.

Which is this: it creates your CRUD pages from an existing database. This is somewhat ORM-ish, as it creates a set of classes that loosly match the MVC concept. And that works great for a lot of things, and its fast.

But these classes are not interoperable. You can't have one interact with another and have them create a SQL JOIN for instance, or even just embed one inside another (say updating one table requires inserting something in another). You also can't easy swap out parts of the MVC structure, like say having a choice of views for HTML or JSON output, or changing the model to one that doesn't interact with the database (lets say the data came from a remote call to another application). Its also hard to make the view more flexible, like having a variable number of columns.

So I've wound up hand coding some of the parts of my app.

Now I will probably still use CCS for some things, like the admin pages, were it works well. But the core of my app needs reworking to support more advanced AJAX style features, more modularity, etc.

But enough background.

What interests me in particular is the database layer, and the MVC structure. The ORM concept (be it model-creates-schema, schema-creates-model, or external tool creates both) is somewhat flawed, at least when it becomes "the end all solution" (see this), but I see it as similar to CCS -- a rapid dev tool that covers maybe 80% of the mundane stuff. The only thing that seems to be lacking really is that the ORM tools only cover the model and database, they don't help you with the view, where CCS does all three.

I would like to see the database layer have multiple options. I see no reason you can't have it support both defining the model first and then asking it to generate a schema, or having it be able to look at the schema and generate the model. Either way, when the application is done, the code should be largely the same. That is to say, the only time code or schema generation takes place is when you as a developer tell it to do so.

Now, on to MVC. From what I can see, it seems like all the PHP frameworks use MVC. Which is to say, that none of them use PAC or HMVC. The main thing here, for me, is that I want flexibility in the layout. I want to put multiple components (MVC/PAC/HMVC triads) on a web page, some of which may be collections of components, and I want a method of specifying arguments to each of them from the URL. The only framework I saw that did this was Claw, which seems to have been abandoned.

So what's the PHP framework for me? I don't know yet.

Take your templates and shove 'em...

2007-05-22T15:43:00.000-07:00

When I first started programing web pages, I used what was and is generally perceived as bad design... I mixed my HTML and code together. Oh, horror of horrors! I quickly learned that this was bad, even though it was oh so convenient at first: what if you have to change all the HTML? This might happen if you wanted to redesign the look of the site, and it would be much worse if you wanted some non-programmer type to do it.

The solution, of course, was (is) templates. The idea here is to separate your logic (the code) from the presentation (html). Never mind that there is already CSS which is meant to separate your html into presentation (css) and structure (html). HTML and CSS belong to the designers and code to the programmers, right? Hence templates.

So. Templates. At first they were simple. Just do your HTML and put in names surrounded by brackets (ex: {page_title}). The code then loads the template, replaces the bracketed items with data, and spits it out to the browser. Simple enough for the idiot designers to not mess up. A little more anoying for the programmer though.

Then somebody realized that, often, there are parts of the page that get repeated, or are enabled or disabled. How do you do that? Well, you come up with another thing called a block, often this is defined as an HTML comment: followed by . This surrounds the part of HTML you want to repeat, or remove. The code looks for these, removes them, and then lets the code decide to put them back in, possibly multiple times. And the designers were able to understand this concept too, and work around it. The programmers got a little more buggered, but figured it was worth the functionality.

Then some designer (and the moron probably thought he was being really clever) asked why he can't somehow determine how many times a block gets repeated, or whether it showed up at all. So some overly enterprising programmer gave him a way to do it: by implementing blocks that could have a condition or loop construct.

Now wait a minute. Conditions and looping? That's programming talk! Then they started implementing functions. Yes, I'm looking at you, Smarty. What the hell? So now the designers are becoming programmers, and the programmers are just getting really pissed off, but they are told it has to be this way, don't you remember how it used to be?

Yeah, I do. I remember when I didn't need an extra layer of crap that forces me to separate things when I could have done it myself, and slows things down. Granted this makes sense if you are doing web pages in C or Java or something, but in PHP?

PHP was originaly designed to do what template systems do today.. make it easy to embed code and HTML. PHP *is* a template language (and you can do the same thing with ASP and other languages). And now we implement another template language inside of it? DUH?

So, lets summarize the differences:

Templates: {variabletobereplaced}
PHP: <?php echo $variable ?>
or using short tags: <?=$variable ?>

Is that really to much harder? And its SO much easier in the code, no loading a template, no setting the variables with some function call. Just assign the variable, and done. If you want to keep your "template" in a separate file, just include it.

Why use anything else when you have DIV tags?

2007-05-18T15:14:00.000-07:00

So I am looking at other people's HTML, CSS and JavaScript at my new job.

And I am noticing cool things, like lots of use of CSS positioning, AJAX, and all that Web 2.0 style stuff.

Only problem is, people seem to have forgotten that there are other tags in HTML besides DIV tags. Its great that we are using lots of CSS to place elements and style them, but have we all forgotten that HTML tags actually serve a purpose?

Tags are meant to give structural information to your data, and CSS is meant to give it a visual look.

So if you've got a table of data to display, why are you using a bunch of nested (or even not nested) div tags instead of, gee, the TABLE element? If you have a list of items, why are you using div tags instead of the UL and LI elements?

Since the catching on of CSS positioning, it seems like everybody thinks tables are evil, because for a long time people used them for getting a visual look and not for tabular data display. But they are not evil. They're just tables. That's like saying hammers are evil because the screw driver was invented and now we don't have to hammer our screws in.

Duh?