This, That, and the Code

Wyatt (my 2 1/2 year old son) was putting on his boots and I was surprised to see that he’d lined them up the right way (with the arches toward each other).

My first, pessimistic, thought was that he had a 50% chance of getting it right but I praised him all the same.

He then proceeded to face the boots and attempt to put them on with the toes pointing towards his heels.

Lesson learned. Just when you think the interaction couldn’t get simpler, users uncover your assumptions.

Thanks for that one Wyatt

Facebook applications is to OpenSocial  as Amazon’s EC2 is to …… Google App Engine. Google ftw!

Some things I like about it:

•  It’s free to start… the startup bar just got lower again
• Scales up well (from the reading I’ve done)… you just pay more.
• The data is backed up better than a home grown solution because of the the GoogleFS’ redundancy

I’ll be learning it soon. Time to bear down and learn Python.

Just a thought… Has anyone ever applied the ideas of Extreme Programming to Business Development.

I wonder what applying them in the business context would do, or if it makes sense for projects in general?

The following is culled from the XP practices guide and changed to apply to business where possible.

The Planning Process, sometimes called the Planning Game.

The planning process allows customers to define the business value of desired features, and uses cost estimates provided by the company’s employees, to choose what needs to be done and what needs to be deferred. The effect of this kind of planning process is that it is easy to steer the project to success.

Small Releases.

Agile teams give the client a working product, and update it frequently on a very short cycle.

Simple Design.

A product built in an extreme way should be the simplest solution to customer’s current requirements. There is not much building “for the future”. Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in this extreme system it is brought about through “refactoring”, discussed below.

Testing.

Extreme teams focus on validation of the product at all times. Employees develop products by identifying ways in which the product does not match a customer’s need and then design a minimal change to the product that would make it do so. Customers provide acceptance tests that enable them to be certain that the features they need are provided.

Refactoring.

Extreme teams improve the design of the system throughout the entire development. This is done by keeping the process free of duplication, communicative, simple, yet complete.

Pair Programming.

All employees work in teams. Two employees to one position.

Collective Ownership.

Everyone owns all the product designs. This lets the team go at full speed, because when something needs changing, it can be changed without delay.

Continuous Integration (May not be practical with brick and mortar designs)

Quick prototyping is key. And it should be possible to prototype the system at least daily. This keeps all the product developers on the same page, and enables very rapid progress.

40-hour Week.

Tired employees make more mistakes. Extreme teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

On-site Customer.

An extreme project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a product process.

Standards.

For a team to work effectively in pairs, and to share ownership of the products, all the employees need to document designs in the same way, with rules that make sure the product designs communicate clearly.

It’s interesting to see how these rules sound when placed in a Business context.

Here’s a screen shot:

What the hell is the point.  You can do this in flash and have more interactive graphs.  Granted it’s pretty, but so would any custom flash chart, or if you’re not the custom kind, there’s Open Flash Chart.

Seriously people.  jQuery is great for making the client side more interactive, but Flash has JavaScript graphics rendering beat.  It’s faster.  Faster to render and faster in response time.

Don’t even play the “Flash may not be installed card” because I’ll turn around and use my “JavaScript may not be enabled” one.  Every person online today can see youtube videos and so has flash enabled and the web is useless unless you have JavaScript enabled.  So these are not really valid arguments.

Rant complete,

Allain

I just installed the Mint Desktop Linux and I’ve got to say it’s pretty slick.

Seamless so far.  Better UI than Ubuntu and so far it doesn’t have the annoying temporary lockup that Ubuntu and gOS had for me (every 5mins or so the system would look solid for about 5 seconds).

If it doesn’t lock up, I’ve found my new favorite OS.

I just disabled my Facebook account. It’d been a long time coming, but I now think Facebook is mainly a voluntary spam service.

You sign up. You get spammed (App Invitations). The sleazy thing about it is that rather than being spammed by some faceless salesperson, you’re getting spammed by your friends and family.

Sure, one day they may return to their days of being a glorified global contact and relationship database, but I’m not holding my breath.

Adios and farewell.

Tags: facebook, disabled

Without given too much away…

I recently inherited a website written in PHP that uses the CodeIgniter Framework (Which I like).  The problem is that the people who used it to develop the website didn’t appreciate the MVC pattern.

Let me boil it down for you.  The project consists of:

• 1 Controller
• 0 Model classes
• 30 view files in the same directory
• 0 lines of documentation

A real doozey, to say the least.

Since I’m going to be extending this masterpiece, I’ve adopted the following procedure for refactoring it to be more  manageable:

1. Refactor the data access (a mixture of CodeIgniter chained approach and horrible dynamic SQL stuff) into Model Classes
2. Refactor the Controller into Controllers
3. Organize the views into directory structures to make things a little cleaner (optional)

I’ll let you know how this goes.

Blogged with Flock

Piccolo is a Java and .NET library written to allow the construction of arbitrary 2D GUIs; most notably it provides great support for rotation and scaling.

I think it’s seen as a toy project right now by most developers in the business realm (even though it’s a mature library) , but I think there are some pretty slick business applications just waiting to be made with it.

Some examples that I can think of are:

• A tablet PC interface that makes awkward document management using a stylus a thing of the past. I mean why hasn’t anyone created an infinite 2D whiteboard. I mean one in which you could zoom in as much as you’d like or arbitrarily shrink a doodle to make more room around it.
• Maps in which you’re presented with geographic locations map to Remote Desktop Connections.
• A single screen that displays all information stored within a company and through simple navigation can be drilled down into (ala Raskin), but unlike Raskin’s ZUIs I’d compromise and have dialogs open up to edit individual nodes (for simplicity) as opposed to in place editing (as much as I’d like to). Combining this with 3D pushpins, I think it’d work.

I’d like to prototype some of this when I have some time and some real data.

Does this sound neat to anyone else?

Tags: zui, piccolo, java, business

I’d love to never see that dialog box again. Can we make that happen? Would it be worth it?

Abstractly, you can treat all user actions as transformations on an application’s state. Undo is then implemented by either remembering the state before the action, or by knowing how to do the action in reverse (depends on the context). For example, an SVG Program might implement undo on a rotation by just knowing that if you rotate by (360-angle) you get the original shape back, and updating a salary on an employee would require we save the salary somewhere before applying the change. Now, if every action your application provided could be undone then there’s no technical reason (other than cost) that every action, up to the time the application was installed, couldn’t be undone.What would software that allowed for this kind of “Better Undo” look like, and how could it be made useful?

My thoughts:

• If you design your application so that all actions can be undone then users would feel more comfortable using it. All too often on website you’re asked “Are you sure you want to delete ______?” when they could just as easily flip a deleted flag and then purge after a time.
• Contextual undo is probably more important that global undo, since the thing you have selected is probably the thing you want rolled back.
• Sometimes the last action performed is not the thing you want undone. Unless you’re very careful, jumping the undo queue is probably a terrible idea since later actions might depend on the application being in the state after the undone action was performed (that made sense to me). Now, if we were willing to pay the price for this functionality, I think we could do it by associating a precondition for each action that could be checked when we jump the queue. Then for all “future undos” we would have a litmus test to see if it needed to be removed from the set of undos.
• Subversion does this for files I think. It allows you to revert to an arbitrary point in time, or on a file by file basis. What I’m talking about here is something more generic. Maybe using subversion as a backend to a system like this would work though.

What do you think?

One big problem with using JavaScript as the basis for your application is that if a hacker gets clever they can insert their own JavaScript into your trusted page and execute it as though it were yours (XSS).

You could curtail a hacker by modifying the DOM so that the objects they would typically use to perform the hack have been replaced, or modified, so that they are lame. This wouldn’t hurt your code since, if well written, it would save references to the the unchanged objects.

For example you could:

• define an empty function called XmlHttpRequest
• crawl the DOM and remove, or replace, appendChild and other DOM methods making Dynamic script tags impossible to insert.
• _document = document; document = {}; // Making it more difficult to get your hands on the document object

I haven’t heard anyone talk about this before so I’d love to hear what people think.

Thanks,
Allain