Sunday, October 31, 2010

HTML centering is crappy

There, I've said it. All you Web Designers know it too, even those of you who've spent your short careers proclaiming the goodness of all things CSSey.

Look, I just HATE that in order to center a DIV in HTML I have to write something like the following:

#mydiv {
width: 500px;
height: 400px;
margin-left: auto;
margin-right: auto;


I mean, does anyone still think this kind of garbage is good enough? SERIOUSLY?

I've just had it with seeing otherwise intelligent people drinking the cool-aid. Down that path lies madness.

Look, here's the thing in a nutshell: the designers of the original CSS specs punted with formatting. They knew they had a good thing going by riding on the backs of nascent Web browser vendor's products, and just tried to jury rig something that would kind of sort of fit what was already there.

After all, if it ain't broke, don't fix it.

The problem was not that it was broken -- even with decades of industry precedents, HTML formatting was a giant experiment. The problem was not that they didn't fix it: creating novel markup that works for a large audience and then inventing formatting models for that markup that make sense, is not a trivial task.

No, the real problem is that Web Designers continue to talk up CSS as if it were the best thing since sliced bread, even while pumping out ill-conceived code that fossilizes the worst parts of the HTML layout model.

Centering DIVs using margin: auto is idiotic. As professionals, we should demand that our tools and languages directly express the intended functions, not work only as accidental side effects.

Maybe it doesn't mean much when we're just talking about some marketing fluff, but not everyone making HTML is selling something. Today's products are tomorrow's garbage, but our memories, our stories, and our learning... this our legacy people! It aught not to be entrusted to languages that don't say what they mean.

There Be Monsters

It is a convenient self-deception to think that the stories we tell ourselves -- the dreams and horrors of our fiction -- are not real.

Our fictional constructs are more real than we think, in some cases more real than were imagined by their authors.  Angels and demons exist, and they are us.

Our fictions are all around us, hidden in plain site. One need only tilt a little sideways to see the gleam of the unseen facets of the reality you missed.

Our culture is rife with obscure references, many lost in the mists of time, to cataclysmic events and ideological paths that led into or out of darkness.

In our zeal to challenge dogma, our modern sensibilities tend to reject the lessons learned, when jettisoning the moral valuations.  We should understand that  people and institutions with scars are rarely the monsters of a story.

Consider our modern mythos, with ancient and current phenomen that fit the archetypes: Zombies, Vampires, and cultural destruction stories by disease are no mere fictions. 

Look sideways at "I Am Legend" and you see a surprisingly literal interpretation.  There is an obvious warning about genetic engineering. Yet the warning is too late: reality is already over halfway through the plot, at least of the first act.

The Black Plague is no doubt one of the seminal events with respect to end of the world fiction. But we now have millions of people persistently infected with mutant strains of African viruses, only temporary treatments in hand, and a desperate hunger for solutions by those victimized by the ongoing epidemic.

Sean of the Dead had another sidelong look at the genre too. If you lived, loved, and lost to a chance happening of a virus, are you morally any better or worse than those who shuffle through the world in a virtual living death of consumerism and TV addiction?

Zombies and Vampires are not fake. They are here now. They are us.

And it isn't just monsters. Science Fiction stories often posit the existence of parallel worlds, of lives played out almost the same -- save for one not quite inconsequential turning point.

It is really the height of hubris to believe that, out of the billions of lives on the planet today, and out of the many tens of billions more in the past, your own life circumstances and genetics are so unique as to be an utterly distinct story and set of characters.

Are you a unique individual? No doubt. But there are others with almost your looks; almost your personality; almost your family and job; almost your history.

Parallel worlds are not imaginary. They are here now. They are our ancestors, our contemporaries, and our children. 

So the next time you see a silly science fiction movie, enjoy it. But when you want to enjoy it again, take a sidelong look. It may reveal the story in a whole new light.

Let the right one in

Ever listen to the lyrics in modern music?

Chances are, you have never taken the time to find out what thoughts you are accepting into your mind as you listen to cheery tunes on the radio or commercial TV.

Next time you hear a catchy tune, try reading the lyrics out loud. Without the music or melodies. See if you can stomach the messages you have letting in.
I'm a slow motion accident
Lost in coffee rings and fingerprints
I don't wanna feel anything but I do
And it all comes back to you
Some may fancy that simple commercial speech has little impact upon us. Yet those who watch TV incessantly, do more than waste away a half-hour at a time. They let things in that suck away their very souls.

Saturday, October 16, 2010

git flaw or feature?

Overall, git is a no-nonsense distributed software version control tool. So no-nonsense that it omits virtually all metadata one might use.

Like project names, for instance. Follow almost any tutorial on GIT, and by the end you won't be able to use a shell command to determine the name of your project.

You can guess the name based on your source tree directory. It just doesn't exist anywhere as an authoritative field in the SCM.

Generally, git avoids metadata and methods to set or display such metadata. One exception is the "description", an obscure file that lives under your .git/ folder.

According to one blog post, if you don't fill in the "description" file, pushing your repository to a remote location will fail with the error

! [remote rejected] master -> master (hook declined)

error: failed to push some refs to ‘ssh://username@hostname/~/projectname’


Well, that's no fun.

I want to update my setview shell scripts -- originally written for Tom Lord's tla/arch (the original dvcs) -- and the spartan metadata probably means the scripts will have do to much more handholding than I'd like.

Setview provides compartmentalized shell environments, emulating the workflow of the ClearCase command of the same name: think of it as an organizer for your local repositories. For Ruby developers, it is a shell environment analog to RVM.

Sunday, October 10, 2010

Static Types are Costly

One of nice things about scripting languages is that they don't force you to putter away time setting up gratuitous static class hierarchies. When was the last time a real customer said "what I really want is a large number of class libraries".

That just isn't the value that customers are buying. In most cases the customer has a new business they want to enact, or an existing process they want to improve upon, and for you to facilitate that with whatever skills you are bringing to bear.

Proponents of static typing will argue that a language like Java protects you from certain important classes of bugs.

What no one has considered yet is the error injection rate arising from having to put time in to writing code just to satisfy the static type checks. The time would be better spent writing test cases.

Overall, static typing slows the development process down. You cannot build the structure without the scaffold, and in Java one ends up building scaffolds for the scaffolds, which at run-time are indeterminately deep.

Ordinarily the static source depth stops after a couple of levels, just below a massive library like Spring. But the run-time indirection is much deeper than the static typing would suggest; all the reflections and inversions result in error messages that are wildly difficult to connected back to the static sources.

That too, is an uncounted cost of doing business with Java.

Latent bugs in PHP

Static typing misses the more subtle bugs arising from legal but damaging expressions. For instance, the C language allowed assignments in conditionals, a "feature" which gave rise to terse code and the following hard to spot bug:

if (c = 1) {
printf("This condition will always evaluate as true.")
}


After looking at code for many hours, it is easy to forget that == is the comparison operator.

I recently discovered the same bug in a PHP script. Some features are not worth having in the language and are a risk in and of themselves.

Saturday, October 9, 2010

The emotional booby trap

The emotional booby trap is when your spouse escalates a minor issue your life into a major emotional disagreement, just in time to turn a very pleasant day into a sullen, painful nightmare. 

Often the EBT involves an impeccable choice of timing for the dropping of the trigger, but it need not involve both spouses. Indeed, one spouse may simply be left in a state of shock by the sudden deployment of irrationality.

The EBT is worse than garbage dumping in that you don't see it coming. Where EGD is a chronic malaise, EBT is acute, sudden, and unanticipated. 

After an emotional booby trap is sprung, it feels as if my happiness has been sabotaged. She seems to have a desire to throw strawman problems up, just to create more drama in her life. 


And then, after the dust settles and the day has been wasted on sullen moodiness, she is acts as if nothing has been lost. But a little piece of my soul is taken, each time.

Emotion Garbage Dumping

Emotional garbage dumping is what your spouse does to you when he or she doesn't actually want to cope and process his or her feelings, just vent. Venting is OK sometimes, but often it is just a way people use to avoid thinking.

Getting tired of being an emotional dumping ground.

Some of us gravitate toward being problem solvers. We look for ways to process the garbage, manage it, recycle or renew it.

Problem solving gets us into trouble with our spouses, because we're expected to sit quietly as it rises around us. We inspire anger and bitterness by trying to help.


In garbage dumping, you are used, the intellectual equivalent of a vibrator. Please don't ask me to listen if you aren't interested in hearing my thoughts.

Thursday, October 7, 2010

Beware of Java Toxic Shock Syndrome

If you are a programmer and find it increasingly difficult to breathe, you may be experiencing anaphylactic shock from exposure to The Java Programming Language, a known allergen.

Signs and Symptoms
Allergic reactions to Java are increasingly common. Symptoms range from minor head scratching to headaches, generalized muscle pain, tightness in the chest, dizziness, and a feeling of being unable to take in enough air. 

Long term exposure to Java is thought to contribute to adrenal exhaustion due to excessive stress levels.

Treatment Options
Some people experience complete rejection and find it necessary to trade their IT careers for lifestyles absent of spurious programming constructs. Pie baking and teaching are among the careers pursued after a Java allergy is determined.

Others with less extreme reactions may find that regular use of a non-allergenic language helps clear their systems of the foreign toxins. Well-tolerated alternatives include Python with Django, and Ruby on Rails; some programmers may find Haskell useful in certain cases.  Once the cruft of Java is reduced the allergy symptoms dissipate, allowing them to breathe more clearly. 

Notes
Be careful about choosing alternative languages based on Java. Some are just Java packaged as pills with a sugary coating, while others are more thoroughly buffered.  To avoid allergic symptoms, the language must be designed to withstand breakdown so that the Java core passes through the gut undigested.  Scala and Grails are two systems purported to provide a high degree of protection against Java toxicity.

Monday, October 4, 2010

git

Every git source tree contains a subdirectory image of the repository.

  • unless it is cloned elsewhere, removing your source tree will also blow away your repository
  • Tom Lord's arch was the tool that started the distributed version control craze
    • arch puts its repositories in a separate location; this can be replicated w/ git by setting up a remote repository and cloning it locally for daily work
    • as an aside, many git fanboys fail to credit Lord for his seminal work. Lord did not get the renumeration or credit he deserved for the innovations he introduced with arch. 
On OS X, use homebrew or macports to install git:

brew install git


Clone an existing repository by finding its uri (check github.com as a popular location)


git clone git://git.kernel.org/pub/scm/git/git.git mygitdir


You won't need to include the "mygitdir" argument unless you want to rename the local source tree.



cd mygitdir
git pull # or pull --rebase


The --rebase option forces git to reapply your local commits to the pulled tree, allowing you to resolve merge conflicts one by one.



git add dirname
git add filename

git status


Git status can tell you what it thinks has changed, and the state of your local source tree relative to that of the remote repository you cloned.


git commit -a


A commit does nothing to propagate the changes to the cloned repository. It sets the point at which you want your local changes to be versioned, and lets to edit a comment for that commit point.


git push


A push propagates the changes back to the cloned repository.



git stash


Stash lets you postpone dealing with merge conflicts; typically you might to a git status, git stash, git pull, and git stash apply, then work through any merge conflicts.

There are many other options. These seem to be the ones I've used most often.

Saturday, October 2, 2010

writing_mode(:terse); A Haiku Form for Technical Blogging

I find myself skimming over other people's writing. It contains too much useless chatter, good for emotional play but a block to rapid information retrieval.

So as an experiment I will make some of my posts ultra terse. Motivated by minimalist technical writing strategies and agile methods, the result will heavily depend upon the domain and working context to make sense.

Some heuristics to start

  • omit emotional fluff
  • don't write like to speak; omit crutch phrases, guarding language and verbal padding 
  • control ego; avoid personal pronouns whenever feasible
  • no paragraphs; use two sentence chunks at most 
  • grammar to serve, not rule: omitted verbs, sentence fragments, and imperatives are OK 
  • cite references; break up or omit ideas that require explanation
  • whitespace and bullets to provide visual breaks
  • avoid self-indulgence in story telling and tutorial guidance

Summarize. If it takes longer than a few minutes to write, it is probably too long to read.


Refine. The result should have a brain-feel akin to an enjoyable haiku. 


Soyez sages, les enfants!