What The F?

Northwood's Inn

2012-01-05T07:54:00.000-08:00

I am not often inspired to write food reviews. This is a typical case of a passive, unpasionate desire to do so. I find I have so little enthusiasm that I don't even wish to expend the calories to lift a finger to the task. Luckily I have Swype on my Android phone so in fact, I do not even need to lift a finger to write a word.

And yet I am writing this review of my inexplicably not forgettable experience at Northwood Cafe.

It was a long day, which began at 4 am as we loaded the kids into the car for our pre-planned trek out to Pasadena for the Rose Parade. Aside from the slight delay due to my intestines playing a cruel joke on my colon causing me to make an emergency pitstop at Dennys for relief, it was a smooth get away.

Arrival was painless despite warnings of draconian parking accommodations; we paid our $15 and parked half a block from the parade route. We got the 4th row of seating and we brought fold out chairs, it was perfect! We even saw that somebody we knew was in the front row. A cafe on the corner provided hot cocoa and coffee and despite the apparent owner's slight gruffness, everyone else was super nice and accommodating. Almost makes me want to move to Pasadena.

The smell of bacon wrapped hotdogs throughout the parade set me up for some good eating which we were saving for lunch time. We ended up waiting until getting to the park to see the floats up close, and I ended up with a pretty respectable mexican carnets taco plate which I wolfed down. The only importance of this is to illustrate that my taste buds were working correctly.

On the way home, after a nearly perfect day of family fun, we decided on one last hurrah: having dinner out. Our first attempt, a random restaraunt spotted from the freeway, the San Antonio Winery, resulted in a conciliatory bottle of Moscato D'Asti because they told us on the phone they were open for dinner still.

Still high on the days events and armed with the joy of a free bottle of wine we settled on "that place with the snow covered roof next to the Elephant Bar that we've never been to". Some things just remain better when you've never experienced them.

On entering, we were greeted with a very pleasing faux log cabin style decor with tiffany styled lamps and still replete with almost garish christmas decor. The kids loved throwing peanuts on the floor and took this simple pleasure to its logical ends.

We ordered potato skins for an appetizer. Unfortunately between these and the salad which consisted only of iceberg lettuce and ranch dressing, I was not appetizer. Potato skins always seem like such a tasty proposition; what could be better than a slice of potato with skins that are covered with cheese and bacon and chives? Yet I've never had a good potato skin at any restaurant. On that account, they delivered exactly what I expected.

Now, I love corned beef and pastrami sandwiches; the classic ruben is my favorite. There's nothing better in this universe. Not being super hungry I opted not for a steak or fried chicken but for what I thought might be a tasty sandwich.

In terms of flavor, I would have to say, this is a case where the whole flavor is actually somehow less than the sum of its ingredient parts. It is a sad day when corned beef on rye is this bland. Oddly, there were not condiments on it, nor were any offered. No mustard, no thousand island, no secret or public sauce of any kind. Being tired I didn't consider this discrepancy until I'd eaten half of it.

The bread was also curiously not toasted, which I had assumed it would be. If it had been toasted, that would have made the tough crust a little crispy, but without it, the bread was too chewy to eat without tearing it apart in bigger than desired bites.

I've had many sandwiches that approach having too much meat on them, but this is a logarithmic function. You can never have too much corned beef. This sandwich errs on the side of not having enough, combined with a third slice of bread to drive the point home.

In bored desperation I tried a piece of cheesy bread, but it seemed more like a slice of wonder bread with a little bit of burned butter and maybe some kind of hint of cheese on it. Even then, it didn't taste particularly burned, which would have at least added some kind of flavor, if not good.

To sum up my experience, I would have to say, this was the best not bad place I've been to in a while. I neither enjoyed nor hated my meal. I am completely ambivalent. So much so that I would be remiss in not reporting my lack of a strong opinion either way.

Update: the other half of the sandwich, after micro waving and adding mustard, was actually improved. this is wrong in so many ways I can't even begin to explain.

Politics, shmolitics...

2011-11-10T10:22:00.000-08:00

I know I shouldn't be spending time on this while at work, but, I cant take it anymore...

Christmas tree tax? Really?

I have to say, this is the most asshat thing I've heard in a long time.

And by that I am referring to the asshats who are using this to make Obama look bad when he has NOTHING TO DO WITH IT.

And by asshats I am referring to stupid republicans, whom I've about had it with (I prefaced that with stupid because I know there are smart, reasonable republicans out there, as well as ignorant democrats, to be fair)

This is NOT a tax. Its not being imposed by the government. The government gets NOTHING from this. This is a voluntary charge created BY the christmas tree industry in order to raise money for their own marketing efforts. By comparison, the milk industry does the same thing so they can pay for all those "Got milk?" commercials. But nobody ever claimed the president was imposing a milk tax! They simply work with the government to collect the fee, but it is voluntary.

And isn't this EXACTLY how things should work? The private sector decides to cooperatively do something to benefit themselves (even among competing suppliers) and has the government assist them in a minimal way.

The people claiming this is another involuntary tax should know better - they are either IDIOTS or ASSHATS who are lying to us.

HP: "I want to be like Apple! No, I want to be like IBM! No, I mean.. like Google!

2011-08-22T16:52:00.000-07:00

HP: what the hell is wrong with you?

You spend a billion plus bailing out Palm and then a year later you toss it all way, blowing out a huge stock of devices for cheap after just a few months on the market, killing a couple devices just reaching the market, angering lots of people including HP executives who even had no idea they were about to get shanked by Leo...

You wanted to be like Apple, which at first sounded far fetched but somewhat reasonable considering how big you were. If you put in the dollars and stuck it out, and put WebOS into other devices (I had dreams of digital cameras running WebOS with installable apps for image processing..) you might have had a chance.

But you decided to chuck it all, including your successful PC business. I guess you wanted then to be like IBM when it sent its PC business away to Lenovo.

Then you buy Autonomous and claim that WebOS isn't dead. You want to be a software company now. I guess that's served Google well (funny that they are now buying Motorola..).

Maybe it was the right thing to do though. Assuming you do the right things next.

How about this. Put WebOS into printers and cameras and then get developers to make interesting apps for these devices. Get somebody, anybody, to take a chance and put WebOS onto a phone and/or tablet.

Even better, "port" WebOS to run on top of Android so you can make a phone that runs Android apps as well as WebOS apps (particularly Synergy, the card UI, the notifications, etc) and get HTC or somebody to make a phone with it.

Even better, make WebOS a cross platform development system where you can develop apps for WebOS and run them on Android, iPhone, Windows Phone, etc. Heck, buy out Appcelerator or Phonegap or something. You said you wanted to be a software company now..

Please, do something. I am not looking forward to abandoning my Palm Pre and getting and Android because its "the only viable option"...

I'm going to lose it..

2011-08-12T00:12:00.000-07:00

If I have to deal with another so called software developer who cannot handle the basics.

Please, don't call yourself a developer if you cannot do the following (or, when told about it, go "hey wow thats great I never learned about that, I will start doing that, thanks!").

* Use SVN (or Git, or Mercurial, or CVS, or something).

If another developer wipes out my commits by committing his code over mine (not even sure how this can happen) and then when told about it has no idea what went wrong or how to fix it I swear I am going to napalm your house with marshmallow cream.

* Say that you understand MVC and then proceed to make a single model with all the database queries for all tables in seemingly random order with random method names.

* Give a daily simple update about what you going to work on, what you have completed, and if you have any issues you need help with.

Look, I dont expect you to understand what Scrum is or Agile this or that, but all I'm asking is for a simple 5 minute update in the morning. I'm trying to help, not micromanage. I understand, you're a programmer and you think you are a virtuoso artiste and you cannot be tied down whatever. Its just a simple informal update. Would you rather I gantt chart out every task and put a due date on everything?

* Estimate tasks.

Ok, look, really, I understand. This sort of thing strikes angst and apprehension in the souls of creative people. But come on, any decent programmer can at least tell if a task is "an hour", or "half a day" or "A day" or "more than day". If you can't tell me that much, then break down the task more. Furthermore you don't have to kill yourself to meet the estimate. The great thing here is that if you at least try to estimate, and then complete the task, you can go back and think about it and learn from it and compare your estimate to your actual time. And then improve it for next time.

Pretty Pictures

2011-04-04T22:00:00.000-07:00

I've always known this, but probably most of my life I forget that its true, and that is the fact that I am first and foremost a builder. Or perhaps more accurately, I'm a conceptual architect.

But I waffle between being a low level builder and a high level architect. Because I am good at and I appreciate the finer details of the lowest level constructions. I could design the threads on a screw if needed. I could engineer a simple Lego brick, and marvel at the tolerances they achieve with just plastic, and be blown away by the perfect set of ratios between bump size and spacing, thickness, etc - the things that are what make Lego bricks so much better than other kinds of bricks.

But I wouldn't want to actually design and engineer bricks. Instead I look at them and consider what could made with them.

I like to invent new little constructs. But, even before I can go through the sometimes mundane process of actually implementing said mechanism, I've forged ahead to conceptualizing an entire system built around this core idea. And then I think about what that system might be used for. Stars appear in my eyes.

Because I am torn between the low level and the high level, sometimes I get nothing done, because I know I don't have the time to engineer all the lowest level stuff and therefore I cannot get to the higher level stuff.

Now of course, most people fantasize about being "at the top".. being a rock star, but not a studio musician; being an Architect of buildings but not a construction worker; or a Novelist over a columnist of a small newspaper. And they think they can go right to the top. I'll admit, I've thought this as well, with all of the above.

I never spent the time to master the guitar, or culinary arts, or creative writing, though I've dabbled in all these things. But I have spent excessive amounts of time studying computers, programming and hardware design, over a good percentage of my life. Because that is my passion.

I've learned that my ultimate job is not as a programmer, but as an architect of systems, with the knowledge of how it all works at a low level. Knowing that I could, if needed, implement every part of it, given unlimited time and resources.

Unfortunately, a lot of this work looks like you are just drawing pretty diagrams and charts. Which I've been doing since I was a child. And nobody understood what I was doing then, either. Here's to hoping I can find my calling of conceptualizing and producing complex systems, IE, making pretty pictures.

Its all in the technique

2011-04-01T10:00:00.000-07:00

I've found the secret to making fantastic bread at home. Specifically, those oh so just right baguettes with a crispy outside and a tender, airy inside.

Let me tell you. Its not about the ingredients. Because the ingredients are simple: flour, water, yeast and salt. But you can't just throw it all together and mix it up. Of course, everybody knows this, right? You have to knead the dough, let it rise, etc.

But even thats not enough. After all the research I've done, I found the best technique is the one I developed on my own after doing it over and over. And its based on the experience of how the dough feels as I work it.

What I find works is that you first of all need to understand that its going to be sticky. I keep the dough in the bowl and just keep mixing it, with a spoon. As it comes together I start to knead it, still with the spoon (I tried once with my hands at this point and wound up coating my hands with hard to remove goo), starting to fold it over more than mixing. It will start looking less sticky and more dough-ball like, and then you can start hand kneading still in the bowl. It gets less sticky as you knead.

Then something else happens, as you knead the ball.. it gets harder. Soon the surface will start to look like its tearing instead of being smooth. So, let it rest for 10 minutes. Then start again. I found I could never get a good kneading all in one go like recipes usually say. So I knead for a few minutes, then let it rest. Do this 2 or 3 times until you really get a smooth ball.

Then let it rise until doubled. Knead it a couple times and let it rise again.

Then, split into pieces. With each piece, flatten it, then roll it up, and pinch the seam together. Stretch it out long as you do this. Then flatten again, and roll up again. By now it should be a long baguette shape. I like to do the slashes at this time, and then let them rise in the pan until pretty puffy.

To bake, get the oven really hot. Spray the loaves with warm water. Spray some in the oven too. Pop those suckers in and cook, spraying occasionally, until good and brown.

So anyway, whats the point of all this?

Because you can't program all day. And a good baked bread is F*cking amazing.

And because programming is the same way. You may think you know all about object oriented programming or the latest framework or fad language or whatever, but without good technique you're still going to produce crap. And sometimes, good technique can only come with experience and from making mistakes and learning from it.

Facts vs Fiction

2011-03-24T14:46:00.000-07:00

I don't think I've done a blog before with a picture. So here goes. This could be titled "Lifecycle of a software feature" or "User Stories, what are they good for?"

HP to WebOS: go forth and multiply

2011-03-11T09:11:00.001-08:00

So HP buys Palm.

Then HP announces, finally, new phones and a tablet with WebOS.

Then they say they're going to put WebOS onto all their computers.

Now, people are saying they are being copy cats and this is a dumb move. Now I don't know about anyone else but I have no idea what they really have planned. Its way to soon to say if this is a bad idea or anything.

I've seen this idea compared to Apple with their bootcamp for running Windows on their machines. On a technical level they will probably achieve this in much the same way. But they'd be doing it for totally different reasons. Its not a copy cat idea at all. They're not doing it to sell more computers because they have a niche product and their trying to get it into markets it wouldn't sell to. HP sells plenty of pc's with the most popular OS already.

There's two ways I see them implementing this. One, is dual booting. And this would be done so that you would have the option of a fast, lean, simple system you could boot into for getting on the net or media applications or whatever. It would be interesting to see this as embedded into flash ram, allowing you to start up your machine in a low power mode needing no hardrive etc. Every laptop they sell could also be like a TouchPad.

The other is as an application running under windows, which could allow again simple media display and sync options to your phone, Touchpad etc.

Yes, this has all been tried or announced before by other companies but nobody's really pulled it off well. But HP has the ability to do it, mostly because they sell an assload of PC's already, and printers, and cameras, etc. If they put WebOS onto all these devices and integrate a seamless experience.. wow! That could make Apple look pretty stupid.

And they've already pretty much said they want to copy Apple's success, and why not? But thats not the same as being a copy-cat. Thats just good business sense.

O Schema, Schema, wherefore art thou Schema

2011-01-31T13:00:00.000-08:00

I have been grappling with this issue for years now. And it is this: how to unify data representations across display (you know, the part the user gets to see), code (the fun part we deal with) and the storage (cumbersome things like databases, files, etc). Or in other words, Views, Controllers and Models.

One of the issues here is where do you define the data? Sure you can transform the data from one place to another, but where is the canonical definition of the data? DBA's want this to be in the Schema of a SQL database. Programmers have a different idea: it should be embodied in code objects which are then propagated to the database. That seems wonderful at first (unless you are a DBA) because then the code can convert both ways; it can generate/update the DB Schema and it could generate Views for display. I had toyed ways of defining the schema in code...

But the problem here is that SQL databases are very egotistical. They know exactly what they are, what they can do, and where, and don't really like that being changed on a programmer's whim. And they already have this very thorough mechanism for defining that data and the relationships therein. Why try to duplicate that in code and go through the contortions necessary to convert object definitions into schema definitions (never mind the subsequent object to data remapping needed)?

If you're working with a SQL database, then you should just accept that the database is the owner of the data schema. You should make your changes there, and have it propagate "upward" to the code.

If you want your code to be the boss of the schema, then consider using a schema-less (NoSQL) database. These are like the savants of databases: they dont know what they are storing and don't care, they just do it fast. That leaves the schema definition to the code.

So what's the point? Just that you should know and accept where your schema is. Use the right tool for the job. yadda yadda.

Apps, schmapps!

2010-12-28T11:47:00.000-08:00

I keep hearing about how the poor Palm WebOS phone doesn't have many apps. People got excited when they hit 1000 apps, and now 5000 apps (which they hit before, but that was including apps not on the official app store, like it matters.. at least you can get apps without having to have them blessed by an egomaniacal parent company).

Then I hear about Windows Phone 7 already reaching 5000 apps in just a few months, as if that somehow really means something about the quality of the phone or apps. And of course, iPhones have like a billion apps now (I know its not really a billion but the way the Apple people sling around the hyperbole you'd think it was).

And as we all know, quantity is directly related to quality...

So, yeah. Look at all those apps. How many fart soundboards do we need? If you actually went through all these apps on all these phones and removed the stupid and pointless ones, and then picked maybe the 1 or 2 best examples of the numerous apps that do the exact same thing, how many actual useful unique apps would you end up with on each platform? Would the ratio remain the same between platforms?

I have an iPod touch and a Palm Pre phone, and I have maybe 10 apps installed on each. You would think with the number of apps available on each that I would have maybe 10 on the Palm and 500 on the iPod. Or 1 on the Palm and 50 on the iPod since everybody knows the Palm has no good apps. And yet, thats not the case.

So I say, Apps, Schmapps! Its not all about apps. Now excuse me while I download the 11th different fart app for my Palm.

ORM, ODM, Nom nom!

2010-12-15T22:55:00.000-08:00

So there's Object Relational Mapping, which I've already discussed and decided is just not the right way to do things. Recently when looking into NoSQL systems (particularly, MongoDB) it occurred to me to wonder what the ORM equivalent was? Turns out its ODM... Object Document Mapping, since MongoDB deals with documents rather than tables and relations.

Which made me think some more. What do ORM and ODM have in common? What are we really doing here? Maybe there is something more generic going on, that transcends objects and relations and documents.

In typical MVC frameworks, the Model uses ORM to do its thing... the ORM pretty much IS the Model.

So really we are talking about Model being mapped to a Data Store. A model is an object usually, but couldn't a model just as rightfully be just an array? Couldn't it be a set of objects and/or arrays? Could a model be an arrangement of bits on a disk platter? And the data store, that could a relational database, a document database, a flat file, or just an object or array, etc. See where this is going?

The ultimate simplification here is just a Model to Model Mapping. Where the model can be an array, an object, a data store, a remote api call, etc. And a Model is just one way of looking at some data. It is what its name says. Its not data, its a model of data.

When you use ORM, or ODM, what you are doing is transforming data from one form into another. And there's a lot of places where data is being transformed, not only just when you go to persist the data. When your system accepts data from a web form, its transforming it (which includes validation and filtering, requirements checking, etc). When you make an API call you might transform that data into multiple chunks of data which are passed to objects which then further transform that into a form persistable in a database. And so on.

This I think really is much more in the spirit of what a model was supposed to be in the original MVC concept. Its not supposed to be (just) a wrapper around a database. Its meant to present a conceptual data construct to the user, something that makes sense to the user, not something dictated by the requirements of some (to the user) arcane internal representation.

Project Management sucks

2010-09-11T22:09:00.000-07:00

Why does every project management system suck?

Clearly, something is wrong. There are so many of these bug trackers and project management systems and such and they all suck. And people keep making more of them all the time, and they all suck, in more or less the same ways. Why? Because none of them are really that much different. So everybody thinks they can invent something better. Including me.

So here's my take on how it should work. Lets keep it as simple as possible. First of all, whats the main goal here? I'll tell you. The main goal is to Get Stuff Done. The main goal is not to spend all your time shuffling around tasks, doling them out to your underlings, revising estimates, making pretty diagrams, and getting all pissed off at everyone when a milestone is missed. No, the main goal, the only important goal, is to Get Stuff Done. And your client doesn't give a monkey's ass how you do it, he just wants you to Get Stuff Done.

So, the first and primary purpose of a good project management system is to help you Get Stuff Done. Its a Stuff That Needs To Get Done manager. So why the need to create artificial walls around the Stuff? You've got projects, tasks, bugs, task lists, milestones, etc. No! Its just Stuff. A project (and you probably have several) is your top level Stuff. Under that is more Stuff (tasks). You might let the client enter Stuff (bugs). You'll probably want to group Stuff with other Stuff its related to (tasks lists). And you'll want to Get Stuff Done in a timely manner so you might group Stuff and put a deadline on it (milestone).

Here's the important part of what I am getting at. You may want to move things around, and arrange them in different ways for different purposes. So, you may enter in all this general stuff you need to do, and then later break down each of those into more detailed lists of stuff. Or not. In every system I've seen you need to decide which Stuff needs to be a list of more items (a task list) and which are the lowest level tasks. And then you are stuck with that. Same for bugs. You can't say hey, this task here, its really 4 other things that need to be done. And this bug, its going to need to be turned into 3 tasks, one of which goes into milestone whatever, and 2 into this other task list.

You shouldn't have to add the whole task list to a milestone, you should be able to assign whatever sub tasks you want to whatever milestone you want. You should be able to group your Stuff by multiple other Stuff (milestone, similar tasks, section of website, etc).

Then there's the second fundamental purpose. Now here's a concept that may be alien to many people. It's a quantifiable unit known by most people by the common and usually pejorative term "work". A project management system needs to keep track of Stuff That's Been Done, IE "work", or more importantly, Stuff That's Going To Be Done. You know, that thing which causes angst and annoyance in every programmer.. the dreaded Time Estimate. The evil overlord Project Manager needs to have some idea how long its going to take to Get Stuff Done, and he needs to know When Stuff Is Done. You know, Estimates and Work Completed.

And that, really, is all the Project Management System needs to do. Keep track of Stuff, Stuff To Be Done, and Stuff That's Done. Stuff, Estimates, and Work.

I'm making it moronically simple because let me tell you, people dont use the project management systems because they suck. Or if they do, it gets in the way and slows them down and doesn't really help. I've tried a dozen different systems in the last year and they all suck, nobody uses them correctly, nobody *wants* to use them, and we all do most of our collaborative work through fucking email! All the really important Stuff about the projects I am working on is in my email! The client's expectations, the 'user stories' that develop when I have to ask the client what the fuck is this supposed to do, estimated times from other programmers that I then have to painstakingly transcribe into the project management system (which doesn't take less than a day for the estimated time... duh?).

So a project management system that doesn't suck has to be braindead simple to use, and completely unrestrictedly flexible. Because programmers don't have time to fuck around with it, and the project managers need to be thinking at a much higher level than dicking around with every little detail of every little task. It needs to somehow integrate with email and even messaging systems because realistically thats where we all do the most collaborative work. It should probably be open source, or at least have a completely robust and simple API that you can plug into so you can integrate it with whatever other systems you are using (source control, build systems, etc).

So that's my beef for today.

Now if I wasn't so busy bashing my head against our current project management system and trying to coordinate several projects and developers, I might try to develop this myself.

And that's probably the real reason for the suckage. Those of us that really need it and know how it ought to work are just too busy to do anything about it.

Palm + HP = world domination

2010-07-04T12:14:00.000-07:00

Palm: "Hey HP, what do you want to do today?"
HP: "Try to take over the world.."

HP: "Palm, you are pondering what I'm pondering?"
Palm: "Uh, I think so, HP, but where will we find a duck and a hose at this hour?"

So its done deal, Palm is now HP. And I think its great. I think its more than great, I think its a brilliant move on HP's part and the best possible outcome for Palm given its situation (and maybe even if they hadn't been on a downward slide).

HP has confirmed continuing WebOS on multiple devices, like tablets and netbooks, and we're assuming new handsets. HP hasn't been super successful with its PDA's and smartphones, WebOS will allow them to truly differentiate themselves, as well as possibly offering a superior product.

But that's boring.

What I think is truly interesting is the idea of integrating WebOS across other devices beyond what Apple or Android are doing. Like printers. Or digital cameras. Particularly interesting to me is the idea of apps for these devices. As far as I know, there are no printers or cameras that support apps.

I can imagine all sorts of apps you could have on a digital camera, for image manipulation, photo album management, etc. Same thing on a printer. How many times have you wanted your printer to do something it couldn't? We'll maybe there's an app for that!

I imagine a whole range of devices, all with standard UI's and web accessible from each other (how many absolute shit web management screens have you had to deal with from printers, routers, etc?). If they play this right it could be fantastic.

I'd buy a WebOS based digital camera. Especially if had a facebook app to upload and manage my photos.

Why are people dumb?

2010-04-28T19:30:00.000-07:00

I was going to title my previous entry "why are people dumb?" but I thought I might give some sort of benefit of the doubt to the client, taking their reasons at face value and assuming it made some sort of sense on some level even if I disagreed with it.

So, I thought I'd look into it. Maybe I am missing something obvious.

They had gotten the idea for the return data format from the Bing maps API. They told me that's how Microsoft does it, so that's how we're going to do it. Ostensibly this was to keep things consistent, to somehow make things simpler for the front end designer;though as he explained further he seemed to believe it was somehow necessary to define Javascript variables in this fashion in order to find the data.

I let it go. The customer is always right, or something like that.

But after looking at the data returned from Bing, using the wonderful Firebug extension, and comparing it to the JSON data we're now returning, I noticed two small problems. First, our data does NOT look like the Bing data; and two our data does NOT look like the Bing data. I realize that technically speaking that's only one problem, but it's such a big one that I thought it was worth mentioning twice.

And by big I mean, its not a big deal to format the data this way (its just redundant and less efficient); its a big deal because they are trying to emulate something they clearly do not understand but think they do. They also clearly do not understand JSON or Javascript.

We're returning strict JSON data, while Bing is returning Javascript code. So now, what we have as JSON data: {"Return" : ... } is their interpretation of the Bing API: function 123456778() {return: }.

Now, I don't know exactly why Bing is doing what they are doing. Perhaps they have good reasons. It seems bad to me, but what do I know? Well I do know that we are now implementing something dumb, based on a wrong interpretation of something that very well might be badly implemented itself (do we really want to emulate a Microsoft way of doing things?). Thats just dumb.

Why do people complicate things?

2010-04-21T15:20:00.000-07:00

So I am developing this backend code API using REST principles. I had defined a standard format for the JSON return data and documented it on our Wiki. It looked something like this:


{
  "Error" : 4,
  "ErrorText" : "Failed Validation",
  "ValidateError": {
      "Field 1" : false,
      "Field 2" : false
  }
}

This clearly is an error response, which I would have returned with an HTTP 400 status code. Its a validation error, and its listing the fields that failed validation. Simple, direct, to the point.

A success response might look like this:


{
  "Devices" :
  [
    {"Id: 42, "Name" : "Nissan"},
    {"Id: 2, "Name" : "Volvo"}
  ],
  "Page" :
  {
    "Count" : 2, "Offset" : 0, "Total" : 2
  }
}

And its returned with an HTTP 200 status so I know without parsing anything that it was successful (See REST). It contains a list of devices, and paging information so I know that I got everything and don't need to request additional pages (not strictly needed in this example, but you get the idea).

So far, so good, I implemented this in all my methods.

Then they come at me with "we need to standardize the API signatures". Oh, you mean the response data from the methods? Yeah I already did that, its in the Wiki. Then I get an email with their proposed changes. It looks something like this:


{
  "Return":
  {
    "Type" : "device.list API 2.0",
    "ResponseSummary" :
    {
      "StatusCode" : 0,
      "ErrorMessage" : "Everything is hunky-dory!"
    },
    "Results" :
    {
      "Devices" :
      [
        {"Id: 42, "Name" : "Nissan"},
        {"Id: 2, "Name" : "Volvo"}
      ]
    },
    "Page" :
    {
      "Count" : 2, "Offset" : 0, "Total" : 2
    }
  }
}

I guess I should be lucky they at least used my Page format. So, I respond back. I ask them what the point is of having the initial "Return" element. Is it ever going to be something else? No? Then why? "Oh we want to be able to always reference it the same way, you have to have something in the root of the response to look for.." Er.. ok. Why then do you need "ResponseSummary" and "Results" if those are *always* going to be in the returned data? Oh, we want them grouped together for easier reading, its cleaner and simpler.

Duh?

Well maybe its a good thing. I mean, its good that I can see in the JSON data it has a ResponseSummary and a "Results" all wrapped in a "Return".. now I can see that this totally random blob of data is actually a Return from something, and within that are Results, because otherwise I might not know what it is! And the Type is good because now I know what resource this is coming from. I mean, its not like I know what resource I was accessing when I get this data, right? And there are so many other things besides a Return I could be getting. And not all Returns have Results, right? And ResponseSummary, what a work of art this is! This lets me know what StatusCode and ErrorMessage are! I would be completely lost without this organization!

Oh, wait.

Lets be honest..

2010-04-11T16:42:00.000-07:00

So.

Everybody is having a collective orgasm over the iPad. Not sure why, really.

And then they announce iPhone OS 4.0. This is cool because it finally gives people multitasking, which other phones (Palm, Android) have had for a while now. And why did it take so long to implement? It didn't. Its just that now they are going to allow it for all apps, and not just their own (Apple) apps. This is under the guise that multitasking might have made the iPhone seem unresponsive or somehow muddy the experience of the iPhone before, and only now is it good enough to be allowed (we all presume this means an even faster iteration of iPhones to be released with it, and blocking usage of multitasking on older devices).

Now, think about the above. There was no technical reason for multitasking not to be there -- because their own apps used it. They simply disabled it for third party apps. Why? Essentialy because they didn't trust developers to use it well. OK, I get that not every developer is that great, and a bad app would make the iPhone look bad because people can't separate the experience. But apple reviews all the apps before allowing them on the store, right? So couldn't they just reject the ones that don't multitask well?

So anyway, reading the new apple license agreement you get the part about how you can't use any other framework or language on top of what apple provides. And people complain. And some people defend the action. And Steve responds. And supposedly the reason is the same as for the multitasking; that such alternate frameworks would result in bad quality software. OK, granted, such frameworks and languages probably aren't as efficient at run time as coding directly in objective-c using the Apple APIs (though that could probably be debated), and for the users of those frameworks they would possibly be limited in using any new Apple APIs until their framework supported it. But again, why is this a problem? If the apps are all reviewed before being released to the app store, why the draconian limitation? If the app sucks, they can just reject it. If the app doesn't use a new iPhone feature but another one does, competition will ensue.

So that doesn't leave a lot of logical reasons for the limitation. Except the obvious one. Apple doesn't want competition, period. The real thing these frameworks enable that Apple doesn't like is cross platform development. They don't want people making an app for the iPhone, no matter how good it is, and then pushing a button and having an Android version too. No sir, that wouldn't make the iPhone look good (well, it wouldn't make it look *better*).

I'm sure they've put up with these frameworks for as long as they cared to, and are now just figuring they are big enough to be able to tell them all to go fuck themselves because they don't need the help anymore. Mostly, it seems like they want to give a big huge middle finger to Adobe, and all the little guys are going down with them.

Come on Apple. Are you really scared? Is this really necessary? Seriously?

Intellectual High

2010-03-22T08:00:00.000-07:00

I will admit that I am addicted to intellectual pursuits.

And as they say, the first step is admitting you have a problem.

I love to learn new things. I also love to figure things out and come up with novel solutions to problems. Not to mention constructing things after I've done all the learning and the figuring.

And the reason is probably rooted in the actual physical sensations that I feel each time I reach a goal or a new plateau in my understanding of something. I am totally addicted. It may be the only thing I am actually addicted to.

I've done my share of other physical pursuits, from riding motorcycles to experimenting with certain substances; and I have my daily rituals which I prefer not to do without, like drinking coffee. But none of these things are addictive. I can do without them, and have for periods of time. Including quiting smoking, one of the most addictive habits you can have. And of the things I've stopped doing, it was never hard to do. I just simply decided to stop (smoking).

If I wanted to, if for some reason I had to, I could give up coffee. Or sugar. Or whatever. But I could never give up learning new things. I could never stop identifying problems and searching for the solution. I could never stop constructing things, whether they were physical machines or data models.

And you know why? Because of that physical feeling you get when you've accomplished something. If you've experienced it, then you know what I am talking about. That little twinge, in the back of your neck that travels down your spine and gives you butterflies in your stomach. That euphoric feeling, that epiphanic moment that just sends a delightful little chill down your body, that warm and fuzzy feeling.

Its the best drug there is. Its what keeps all the creative people going, I think. I know it does it for me.

Pass the margarine, please.

2010-03-17T23:20:00.000-07:00

Has someone sent you this email recently? That one with the scary stuff about margarine being bad for you and you might as well eat plastic? Well here's a great response to send your well meaning friends:

Ya know, a simple Google search and about 10 minutes of researching the results and you will find that a lot of this is not true and this email has been circulating for 7 years. When it was written, it was not known that the thing that made margarine bad was the trans fatty acids contained in it. Since that time, most margarines and other food items (like french fries) have been reformulated to not contain trans fats. Margarine today can actually have much less fat than butter, containing no bad trans fats, and never did contain bad cholesterols; in fact some margarines made from healthy oils can actually reduce your cholesterol! A good margarine by all accounts is probably much healthier than butter (and you can find actual scientific studies to support this).

Also, its simply not true that margarine was invented to fatten turkeys. Its also older than 100 years.. in fact it was invented expressly as a butter substitute over 140 years ago. In fact pretty much every statement in this email is just plain false.

And comparing it to plastic because its one molecule different.. come on. Learn some basic chemistry and you will discover all kinds of things that have very similar molecular structures but are completely different in practice. This means nothing! Hell, Water is only one *atom* away from being Hydrogen Peroxide, should we stop drinking water?

A much more useful thing is not be irrationally afraid of any one particular thing, but to understand that as with all things in life, moderation is key! Too much of anything is bad. If you are eating so much margarine and other fats, sugars, and such things that we all know aren't particularly good for you, then your not saving yourself by switching from margarine to butter; your real problem is that you are simply eating too much bad stuff! Moderate it.

This seems like a really great example of the common phrase "a little knowledge is a dangerous thing" -- which itself is a very misunderstood quote which is paraphrased from the following:

"A little learning is a dangerous thing
Drink deep, or taste not the Pierian spring
There shallow draughts intoxicate the brain
And drinking largely sobers us again"

So the next time you get one of these scary sounding reactionary emails, do yourself a favor and spend a few minutes to research it, learn a bit more, don't just accept everything you read, and don't just forward it along and propagate nonsense.

Personally, I just learned a few things about margarine that I didn't know before. And I will continue eating small amounts of it because, frankly, I like margarine!

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?