I thought this article was funny and to the point: cowboy coding doesn't work.

Removing yet another barrier in my life, I've figured out how to blog from TextMate. A screencast demonstrating how to do this is found here. There were a few issues I have yet to work out:

• I've had some issues with the post timing out on a new post. It makes it there all right. But it doesn't seem to want to handle things very well.
• I have some issues with Typo recognizing my Markdown. I followed the ideas on this post, but that doesn't seem to be it.

If anyone has used TextMate with Typo, I'd love a comment or two. Google doesn't seem to have much to say on the subject tonight.

I just got carried away, responding to "another blog post":http://www.toohardtopronounce.com/code/2009/05/02/on-haml-and-jquery/. I spent enough time on that comment, I thought I'd post it here as well:

When I found HAML at its inception, I found something powerful that I couldn't explain. I told people it was because I didn't have as much noise in my templates, but there was something more powerful about it than just that. I've realized that simplicity is a form of power: it saves me time, but it also begins to unveil meaning to me.

A simple thing embodies the task at hand. The egg-shaped handle for a kitchen utensil, seems to say, "hold me." Quiet HAML seems to say, "shape meaning with me." As a handle is built for holding, I realize that template languages are for structuring. HAML invites me to engage in the meaning of a document by seeing the structure rather than the syntax.

And, I find that using HAML, I adapt my templates more quickly. That's partly because it's much more expensive to change HTML than to write it. HAML is easier to write, but MUCH easier to edit. If I move something with HAML, I don't have to chase down a closing bracket, somewhere else on a page. I just move the content I am working on.

The web is not HTML, it is a universal expression of meaning. We build web applications and pages because we mean something by them. HAML, then, didn't add an abstraction layer, it removed one. It did this by the laws of reduction: shrink, hide, and embody.

Yes, there are those pesky moments when I miss a space, or a tab sneaks into my white space somehow, and all hell breaks loose. I have to go and find out what's wrong before I can move forward. The act of keeping my HAML pristine, however, leaves me with a sense that I actually accomplished my purpose, I presented my meaning in a clean and orderly way.

jQuery seems to do the same. It is not Javascript, and so doesn't try to take over the Javascript space. It humbly offers its services, unless they are otherwise engaged. Non-jQuery objects become jQuery objects with a simple $() wrapper around them. Lists and single items behave in the same ways, so that unnecessary object inspection is hidden away from my code. The selectors simply embody most of the selectors I've already come to know. jQuery doesn't try to add layers, but remove them. It implements server communication through GETs and POSTs with $.get and $.post. It makes it as easy to extend the library as it is to use it. It presents itself as a designed library, rather than just a slipshod collection of methods and features.

When I discovered systems and system archetypes and dynamic models and these kinds of things, I fell in love. I moved to Portland, I ate the stuff up. Life happened since then, and I'm addressing other issues, but I still have this love affair with seeing the integration of elements of a system. When the purpose of a system manifest itself from the whole of its partsm it's like a ballet to me.

An example from my boyhood is the systems that produce amusement parks. Once I could begin to see the forces at play that combined physics, engineering, economics, and the pursuit of pleasure to create an amusement park, that idea was immensely more pleasurable than the rides themselves. As a boy of around twelve years old, the moment of riding a roller coaster was just an interruption from the joy of realizing the systems all around me.

A friend saw some of this the other day. He walked into my office and wanted to talk about how he took some of my ideas from my "UTOSC talk":http://blog.tegugears.com/2009/10/08/utosc-resources to cluster the voters in the Utah Republican Party. He could start to see that there were forces at play behind the votes. These voters had purposes of their own, but as a whole, the system began to manifest a purpose and direction for itself. The structure of the elements of the Utah Republican Party guide its behavior.

I could be wrong, but I think that's why we get excited about classification. Simple linear regression can often draw a line between two classes in fairly useful ways. Neural networks, support vector machines, Gaussian processes, decision trees, KD Trees, all these wonderful inventions begin to tease out the players of a system. We can't always see these things from just the data, and a priori information needs to be asserted, but we live in a world where the common man can work on these things.

"Cherkassky and Mulier":http://www.amazon.com/Learning-Data-Concepts-Theory-Methods/dp/0471681822/ref=sr11?ie=UTF8&s=books&qid=1257704359&sr=8-1 are more exact when they explain that

bq. Learning is the process of estimating an unknown (input, output) dependency or structure of a System using a limited number of observations.

In other words, from observation, we learn how a system might turn inputs into outputs. The knowledge of the properties of steel and the forces of nature (physical inputs) can guide the creation of roller coasters and machines that flip us around in death-defying ways and give us a thrill of a lifetime (system outputs). For the price of a small ticket (our economic inputs), we can share in the accumulation of thousands of hours and millions of dollars to share in those thrills (system outputs).

What's more important, these systems can be generalized, to a point. Disney can create the happiest place on earth in Orlando and Anaheim, yet fall quite flat in Paris. The Harvard business case suggests they didn't react to the observations available to them on that project.

"Cherkassky and Mulier":http://www.amazon.com/Learning-Data-Concepts-Theory-Methods/dp/0471681822/ref=sr11?ie=UTF8&s=books&qid=1257704359&sr=8-1 go further to explain

bq. Under [the] statistical model estimation framework, the goal of learning is accurate identification of the unknown system, whereas under predictive learning the goal is accurate imitation of a system's output.

Those are the first steps in a difficult and rewarding journey through the world of data analysis, as guided by "Cherkassky and Mulier":http://www.amazon.com/Learning-Data-Concepts-Theory-Methods/dp/0471681822/ref=sr11?ie=UTF8&s=books&qid=1257704359&sr=8-1. They pick apart and give us a great context for classification methods. Above, they show us that the statistical model estimation framework wants to point out means and distributions and skew and kurtosis. The machine learning world is more interested in simply knowing what predictive power the observations might have. I.e., it's enough to know what a system does, rather than all about how it does it.

I introduce this book because you may want to actually get somewhere with your work.

Another way to get somewhere is to put classification in the context of the "Laws of Simplicity":http://lawsofsimplicity.com/, a framework from "John Maeda":http://www.maedastudio.com/index.php. The models I describe above reduce a complex systems to a few inputs and outputs. This is the first law of simplicity. We know that the reduced model isn't accurate, but it's more useful than a complete model. It suggests trends and decisions and distinctions, where a complete model looks complex and chaotic and undetermined.

The way things should be reduced, says Maeda, is by SHE:

• Shrink
• Hide
• Embody

When classifying or learning a system, we shrink its parameters. We use "Principal Component Analysis":http://en.wikipedia.org/wiki/Principalcomponentanalysis, "Reconstructability Analysis":http://www.sysc.pdx.edu/download/papers/ldlpitfabstract.htm or other "parsimony methods":http://hunch.net/~jl/projects/reductions/reductions.html to make the problem tractable. A business person or research assistant can't often use a model that takes the coordination and harmony of 92 input variables, but they can work with one with three. If a three-parameter model is still useful, then it should be preferred over more complex models. The methodologies mentioned above propose ways of deciding how much to shrink a model.

Classification can also do a good job of hiding some of the complexity. Consider the structure of a neural network. There are understandable inputs, and desired outputs, and one or more hidden layers in between. Support Vector Machines create a mapping between n-dimensional data and a its model by looking only at the observations near the division between classifications.

Hiding the complexity doesn't mean we don't know that it's there. It means we don't need to see the complexity to accept the Gestalt of a system. From a "wikipedia article":http://en.wikipedia.org/wiki/Gestalt_psychology:

bq. Gestalt...is a theory of mind and brain positing that the operational principle of the brain is holistic, parallel, and analog, with self-organizing tendencies, or that the whole is different from the sum of its parts. The Gestalt effect refers to the form-forming capability of our senses, particularly with respect to the visual recognition of figures and whole forms instead of just a collection of simple lines and curves.

Whether this model of psychology is accurate is beyond debate: it isn't. There is, of course, more going on. It's a model, and is subject to the same constraints any model I'd create would have. But it embodies the purpose of a system. It describes how the complex inputs get transformed into figures and forms in our minds.

Our systems should also embody the main purpose of a system. The purpose that is manifest from observations and results, not our desired purpose for a system. It is this kind of embodiment that shows us that our economic systems are machines for growth and our health care systems are to pit the wills of the strong against the weak.

So, shrinking, hiding, and embodying is a context for reducing a model. It is a context for working on classification systems. Learning to classify systems is a walkable path, one that I'm walking right now, one that I've been gladly walking for quite a while.

I've heard of some of the perspectives successful authors have towards their work:

• Terry Pratchet writes so many words a day, no matter what
• Ayn Rand considers her page her employer, and her job to fill that page irrelevant to how she feels
• Norman Mailer learns and teaches the craft of writing, then only falls back on it when passion falls short
• Billy Collins writes poetry every morning, without judgment
• Gerald Weinberg has a writing system for acknowledging his relation to his ideas, the Fieldstone Method
• Natalie Goldberg makes statements and answers questions

I think about the author perspective because:

I want to write

I think technologists and authors have a lot in common

Let's forget that I want to write. That's a story for another day.

Technologists and authors have a lot in common. Both attempt to capture and express reality. Both often interface their world through keyboards. Neither one gets through this life without first getting approval from others: users, readers, managers, editors. Projects run through their lives, sometimes as express trains, sometimes as promenades. The projects often become the whole reality of both types of people.

And tonight, it's the blocks that are important. The writer's blocks, the slow downs in a developer's productivity.

I think I seek to be my own boss because I've figured out how to deal with these blocks that don't involve the kinds of activities employers like to put up with. For me, I have to be writing code to get out of the funk. So, if the assigned code is stuck:

• I re-write what I wrote, looking for the essence of the system, somehow lost.
• I write tests, getting that competent momentum slowly over a few hours.
• I write open-source software.
• I fill out mind maps, organizing thoughts, associating thoughts, asking questions, making statements, and creating a narrative for my blocked thought process.
• I put a stagnant project aside and come back to it another day,

These are only my more productive reactions to a stuck mind. Checking email, playing games, taking walks, chatting it up with other people, playing Trance music, or watching Hulu are other ways I cope.

This is the only humane approach to software development that I know of. It would be nice to think that I never slowed down for anything. I don't know people that never slow down. I know one that comes close. He's really amazing, cranking out code about 16 hours a day. Maybe someday I'll figure out his secrets. For the rest of us mere mortals, however, the advice and metaphor above is probably the best I can offer today.

When I ask myself what I'd do if I had all the money in the world, I honestly answer that I'd be doing this: solving problems, building teams, writing code, learning, and finding myself awash in interesting things to do. Since this is what I want to do, it's important I figure out how I do it.

I borrowed the idea of the Dreyfus Model from Andy Hunt’s Pragmatic Thinking and Learning. Since I keep asking people where they’re at on a particular skill on that model, I thought I’d outline it in a place where I can reference it. It’s probably good to know in general, because it tends to reduce frustration and focus learning styles by knowing what stage I am on each skill I need to have. The model as I remember it is basically:

• Novice: looking for recipes
• Advanced Beginner: able to work with the reference material nearby, not able to see the big picture
• Competent: Mostly able to work without having to re-architect very often
• Proficient: Able to work at a steady pace, able to self-correct when working
• Expert: People are seeking you out in this field

So, for what it’s worth, there it is.

I just had an incredible experience. I'm working at "Instructure":http://www.instructure.com/, a startup currently working out of the Novell campus. I went to the cafeteria for lunch, and our investor was there. He has been teaching a class on entrepreneurship for the startups here. So, I sat down to lunch with him, and he was joined by a handful of business owners from the class. We got to brag Instructure up a little bit and explain the strategic positioning of Instructure to the group and then hear about the other companies. One company has been making sales, but not a lot of progress. As I stood up to go back to work, the investor was asking someone from that company, "how can we get you from good to awesome?"

Another way I've heard it is, don't suck less. Meaning, it's not good enough to just suck less than the competition, but rather be a standout in the community.

One way we keep from not sucking less is to be active in the community. Otherwise, it's too easy to just code up more hum drum, or have a hum drum expectation for my business life. But if we are involved in our communities, our excellence is asked of us. I've put a lot of thought into that for myself. I think it's kind of like early-morning jogging for athletes, it's how we expose ourselves to new opportunities, challenging situations that seems to make the difference. For me lately, this has meant:

• joining networking groups. I finally joined the "BYU Management Society":https://marriottschool.byu.edu/mgtsoc/index.cfm. I should have done this 7 years ago when I finished my MBA. Today, I want the feedback this group can give me in the networking luncheons they have. I also want to keep my business skills brushed up. Programming in near-seclusion in jeans and sneakers all day doesn't ask me to polish my interpersonal skills, where I could fit in with executives and managers as anything but the hired help.
• participating in local users groups. For me, that's "URUG":http://groups.google.com/group/urug. At URUG, I can share my ideas, and get better ideas from the professionals around me.
• lending a hand. I've been watching "Mahout":http://lucene.apache.org/mahout/, a Hadoop-style machine learning framework. I'm seeing where I can contribute, and I'm learning about higher standards for my work as I go.
• speaking. I've spoken at "MWRC":http://mwrc2009.confreaks.com/, "LSRC":http://lonestarrubyconf.com/index.html, and "UTOSC":http://utosc.com/pages/home/. The more I speak, the more I learn, the higher my standards go for my work.

Anyway, it's a great feeling when I see the progress available through striving a little in this community of ours.

"Andrew Shafer":http://stochasticresonance.wordpress.com/ told me about "HOP":http://radar.oreilly.com/2009/10/pipelining-and-real-time-analytics-with-mapreduce-online.html last night. It's a really powerful concept:

• Take Hadoop's MapReduce interface
• Allow jobs to be run online, rather than batched
• Co-schedule tasks
• Keep tasks running all the time

This speeds up the delivery of the analytics: no need to read and write to HDFS for intermediate steps. This provides real-time analytics. This cleans up the feedback loop between data and analysis by quite a bit.

I can think of a lot of data rich applications that could use this. Wall Street and search tools could really have a hay day with this stuff.

I am interested in anyone who may be using R/Parallel in their work or research. I would love to find some working examples and a community of people that I could learn from. The basics of this project is to take your "R":http://www.r-project.org/ code and be able to run it in a parallel environment.

I have also joined the "REvolution R":http://revolution-computing.com/products/revolution-r.php mailing list, hoping to see what's out there.

I don't have many people that read this blog, but if you happen to know something about these things and come across this article, would you mind posting a few notes before you move on? Thanks.

I've been studying reinforcement learning a bit lately. As I do, I start to see the feedback loops more clearly all the time.

If you look at the deleted scenes on "A Beautiful Mind":http://www.imdb.com/title/tt0268978/, they go more deeply into why John Nash had a tissy fit over losing the game Go. The whole story was that it was mathematically inconsistent. Meaning, the rules he had derived from studying the game couldn't be consistently applied to produce a consistent result, winning. The issue, I suspect, is that he didn't have a complete policy, therefore it seemed inconsistent. John Nash responded to this event by inventing a game more challenging than Go that was complete in his eyes.