Tuesday, September 27, 2011

"Opinionated" as a Professional Practice

I hear programmers tossing the word "opinionated" around a lot these days.
Usually, it is used to characterize a development library or framework, as in,

Rails is an Opinionated Framework

So why is it that "opinionated" also seems to be used as a euphemism for hard-coding, discrete variables and subroutines, avoidance of data-driven process, or otherwise representing decisions as fixed structures in the code?

An old rule of thumb in engineering is, that the earlier in the fabrication that decisions are fixed, the deeper and more wide-spread is the impact. Regardless of the decision's impact as a cost saving or increase, making a decision early causes a cascade of ripples throughout the system. That's the trouble with being too opinionated: you have already made decisions prejudicially.

Researchers of old used to say that you should build one (or two) to throw away. Perhaps the tendency of programmers to be too opinionated is why. Perhaps it is also why so much of today's hot newest Web coding technologies appear to be legacy code before they even get released.

MacOS X Lion XCode 4 madness

Ah, I'm going utterly insane with frustration. After sitting down two hours ago to start doing some coding, I found that my upgraded Lion system with Xcode 4 has a mysteriously broken command terminal:

MacBook-Pro:~ user$ clear
terminals database is inaccessible
Wha ???

Now, if you go looking at forums, a lot of them are going to say something like "check your TERM" or "try removing your dot files temporarily", or some such. That's misdirection, based on someone hacking together a Linux environment. This is OSX, and I haven't been hacking my environment recently.

Seems that either the Lion upgrade or Xcode 4 screwed something up. An Ubuntu posting on Stack Overflow discusses the cause of the problem, a missing terminfo file (/usr/share/terminfo/78/xterm-256color). I go into Time Machine to investigate, and lo and behold, there is no /usr.

#$@@$%@$!!! 


Mac OSX apparently hides UNIX files. Where's the UI setting for that? Um, well, the folks at Apple decided that magically hiding files should be managed by a magical switch:


MacBook-Pro:~ user$ defaults write com.apple.finder AppleShowAllFiles True
MacBook-Pro:~ user$ killall Finder

(Really, Apple? Why is there no UI? The man page detritus has no indication of what the actual settings are. So much for UI discoverability, but at least some of the info is documented, and thanks to Google and places like Stack Overflow it can be found.)

I go to restore the file, finding it a couple of weeks back. Unfortunately, Time Machine still won't show UNIX directories in its file browser. The original location (/usr/share/terminfo/78) isn't visible as an option. I copy it manually. Stupid.Magical.Finder.

Note to the person on the Xcode 4 team that decided to do the cleaning up: multiply the time wasted that by all the developers you tripped up, and your one mistake probably comes out to hundreds of hours, not to mention the systems that now have crippled terminfo files.

Thursday, September 22, 2011

Nokahuna and That Other task manager

The name of that other task manager is Trello. Even though the name is forgettable, it offers some interesting features. Things like auto-updating, and a very strong visual metaphor.

In contrast, Nokahuna has a kind of 1950s style - the pastel lime green made me think of the worn out Formica of some old diner out in the middle of some old, mostly abandoned downtown.

To be fair, Trello isn't visually stunning itself. But it does offer a more chunky version of the todo list. The metaphor is one of pinup boards with cards stuck to them, and highlighter colors used for labeling. It is not an unpleasant departure from the creamy, everything-runs-together-until-your-eyes-bleed shtick that dominates almost every project management system and todo list manager under the sun.

Unfortunately, in it's current incarnation Trello doesn't work well on my iPad2. There was a "transport unavailable" error on every page... I doubt that the auto-updating feature works as expected... And whatever they did to code up the browser UI, it has jerked up the touch events to the point that every action requires at least two touchdowns to register one.Some things that were pointed out in the welcome board simply did not work, like Drag and drop, or the elusive user manual (um, where is it exactly?)

That brings me to the last feature that seems to be missing: the ability to delete your account. Trello doesn't give you that option. It seems that some users adopted the practice of appending "delete" to their screen names. Maybe that is in the missing manual.

So I turn my attention to Nokahuna. First issue up: the welcome screen offers me (an iPad2 user) to view a Flash based screen cast. Not exactly the best first impression.

The rest of Nokahuna reaffirms my initial style impressions.... This _is_ an old dive. There are no frills in Nokahuna, and for the most art that is a good thing. It is a task list manager, and that is it. Teams with fixed functional roles for people may find the minimalism a little too simple, but I can see the appeal to Agile folks who collaborate as independents or in a tiny cross-functional team.

For visual metaphors, Nokahuna is much weaker than Trello. It is unremarkable and like a dozen other tiny todo list tools I've seen, hacked, or used in the past 20 years. This isn't a remark about the minimalism, but about the absence of pleasant variations and of the tired look to the thing. For all the weird stuff that cropped up on my iPad2, Trello is still more attractive.  A name like Nokahuna raises expectations a little higher, and the visual appeal of a list just doesn't meet that expectation.

Summary: I'm sure both work well enough on a desktop browser. Trello aims at being multi-platform, but doesn't seem to have reached that goal in practical terms. Nokahuna is the more minimal of the two, perhaps too much so; Trello is more feature filled, almost trendy. Minimalism aside, Nokahuna still needs a facelift. 

Wednesday, September 21, 2011

Conundrum, a sample of UTF-8 in Ruby 1.9.2

Posted to Github as this gist.

# encoding: utf-8
# conundrum.rb
alias :λ :lambda
alias :Ω :abort

module Enumerable
alias :⇔ :collect
alias :∉ :reject
alias :∈ :select
alias :∫ :inject
alias :∀ :all?
alias :∃ :any?
end

class Array
alias :× :each
alias :⊠ :each_index
alias :≡ :eql?
alias :∋ :include?
alias :∪ :|
alias :∩ :&
end

%w(a b c).× do |letter| puts letter; end

%w(a b c).∪ %w(x y z) do |letter| puts letter; end

%w(a b c).∩ %w(c y z) do |letter| puts letter; end

a = λ {|s| puts s}
a.call('test')

Ω "It is the end"

I miss my Spaces

I'm sure the NC DOT has its reasons for designing roads that induce drivers to switch lanes constantly or be forced into turn-only lanes. But having a reason is not the same thing as making a good choice or making acceptable trade-offs.

I'm sure Apple has its reasons for removing Spaces from OSX Lion and replacing it with Mission Control. But they went all NC DOT in the process, forcing desktops into a single lane. The result is a system which is more difficult to navigate and less functional than its predecessor.

How can the seemingly simpler Mission Control be harder than the two-dimensional Spaces? Well, Mission Control isn't actually simpler. Like an NC DOT onion-skinned road design, the user is forced to shift their attention from getting to an objective destination, to a forced choice problem of avoiding undesired exits.

Forcing choices on people in an interface is good when the options are potentially equally valued, and you need to determine a preference. Forced choice is a terrible thing when there is no need to determine the preference, or when there is no preference.

Spaces could be used to eliminate the need to search, by using the brain's natural inclination to remember details based on physical location. Mission Control turns the direct access ability of Spaces into a linear scanning process.

I'm sorry, Apple, but Mission Control is a big time FAIL.

Tuesday, September 20, 2011

Interesting Ruby Tidbits

In Ruby,

@@var class variables are shared between the class, its instances, and any extended classes; thus they act like globals within a superclass' hierarchy.

do...end blocks bind at a lower precedence than { .. } blocks; thus,
p a.map {|s|   s*2 }
p a.map do |s| s*2 end

"string"  is equivalent to %(string) and %Q(string), but the latter two allow nesting of quote characters without special escaping

To get a list of user methods from a subclass, use the cls.methods method and subtract the base class method list from the class method list.

If you use the default argument to Hash.new("default"), the value gets shared among all defaulted hash entries, so assignment to any of them will change all of them. Use the block form of default initialization instead: { |h,k| h[k] = "default" }


Friday, September 16, 2011

To Quote or Not Two Quotes, Taht Iz Dah Qvestion

In C, when one needed to insert a special character or ensure a regular character was interpreted as-is, one would use the backslash character (for those of you in Rio Linda, that's the '\', not the forward slash '/'), like so:


\n 
\" 
\\

In Ruby, supposedly you can do the same thing. The exception is that in Ruby, the action of the backslash is restricted within single-quoted strings. That is,

" this is a quote: \"" (length 18) 
' this is a quote: \'" (length 19)


Be mindful of your escaping, you could be escaping too much, depending on the type of quotes you chose. This often caused trouble in our RSpec tests, particularly when Capybara "have_content" matchers were involved.


Wednesday, September 14, 2011

Once Bitten, Twice Shy


Got bitten but the Ruby Constants Are Not Constant bug again. Actually, it was in the same part of code that I'd found it before, only dealing with a portion of a hash a bit more deeply nested.

SOMEHASH = { 
 :elem1 => { 
   :props => [ :a, :b, :c ] 
 }, 
 :elem2 => { } 



hash = SOMEHASH.clone 
  # replaces SOMEHASH[:elem1][:props]

hash[:elem1][:props] = hash[:elem1][:props].shuffle  


I know, you Rubistas are going to say it isn't a bug; that it is just my naivete; that in Ruby, deep structures like nested arrays and hashes contain references to objects that do not change but the objects that are referenced can mutate.

What is happening here is that the anonymous hash (the object pointed to by the key :elem1) is not being copied. Its reference is what is copied. So shuffling and replacing one of its members (:prop1) necessarily changes SOMEHASH[:elem1].

One approach is to freeze the hash, but you'll end up forcing your app to abort when it tries to manipulate values. In our app, we were creating copies of elements and shuffling them. The problem being that our copies weren't really full copies: they contained references to the objects still in our original "Constant" hash.

And Matz might argue that it is not surprising, once you understand the details well enough. But it is still undesirable. I find many aspects of Ruby to be elegant, but not this one.

A more gruesome, brute-force approach is to deep copy the hash by serializing the data to a stream, and marshaling it back into a new hash object. It is a one-liner, but that one line is doing a lot of work in order to copy an hash.

def deep_copy(hash)
  Marshal::load(Marshal::dump(hash))
end

Sunday, September 11, 2011

PHP Considered Inelegant

I'm looking at this year's SparkCon (2011) and noticed that the server had vomited on the sidebar. SparkCon's site apparently uses PHP to parse XML, and the parser threw an uncaught exception:


Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]:
Entity: line 1: parser error :
Start tag expected, '<' not found in /home/sparkcon/www/www/wp-content/plugins/gcal-sidebar/gcal-sidebar.php on line 369


Well, I'm not picking on SparkCon - it looks like a fantastic set of events - but increasingly I'm feeling less and less tolerant of those kinds of fit-and-finish flaws showing up when I'm interacting with a Web site.

Imagine what you would feel like if you were meeting a new business associate to chat at a cafe, and while you were talking they said "hold on...", unzipped, reached inside their undergarments to adjust themselves, scratched around for a while, and then tried to resume with "ok, go ahead".

We are all human, but some people are just more circumspect than others. That's why, intuitively, PHP rubs me the wrong way: inelegance.

Update: I'll give two examples. First, PHP's over-reliance on special characters and strings of special characters as operators in the syntax (from its Bourne shell -> ED/AWK/SED -> Perl heritage); and second, its concomitant reliance on gruesomely ugly idiomatic expressions for expressing trivial relations and operations. Neither of these PHP characteristics adds value to the solutions; both detract considerably from the readability of the code and add excessively to its code length. Since code-length is a correlate of error injection rate, PHP is objectively a worse basis for making an investment in code. 


I'm not sure if PHPs inelegance is entirely justified as a conclusion, but PHP isn't alone. PHP lacks the charming Rube Goldberg contraptions of Ruby metaprogramming, elegant to some but a sham to others. Perl is its ugly older brother, so ugly that it almost goes all the way around the ugly clock with one liners that appear elegant for how tightly they can compress their ugliness. And as bloated as the JVM platform has become, Java was not a particularly elegant language even when it started. JavaScript is like a fractured gem: turn it one way, and it looks elegant, turn it another and the flaws ruin the illusion. And then again, the apparent elegance of a language is not always sufficient to offset poor run-time performance.  PHP is just the scab I'm picking at today.


See also this tongue-in-cheek comparison

Friday, September 9, 2011

Passion Considered Harmful

I had a discussion with a colleague recently, and she was telling me about work in the university. As we parted ways, she quipped that for those university jobs, one really "needed to be passionate about education."

I'm sure that she was serious, and in some ways it is true. I'm also sure that there over 50% of the people working in those jobs who could be said to be less than passionate. Middle-manager dreary even. I've seen those people at work, and the utter banality of their expressions is sometimes just torturous to watch. So naturally I'm a little confused by the apparent contradictions.

My question is, why?

It is important to be committed to what you are doing. My question is why is it necessary to be so passionate that you never stop to think about whether it is important or good. We could save a lot of really worthless economic activity, not to mention heartache and grief, with a little dispassionate introspection.

Should we encourage teens to join the sex industry, since many teens are passionate about sexual activity? Passion is not the source of commitment.

Nor is passion a necessary outcome. I want my doctor to be keenly interested in his profession, to be dedicated and deeply involved in whatever it is that he specializes in. But I don't want him to have an unusual excitement, enthusiasm, or compelling affinity for his mode of treatments above alternative protocols that are equally valuable.

A doctor's attachment to his specialty should not cloud his judgement about your specific situation. Passion is a fog to judgement, a useful motivator but deadly without restraint.

Besides which, people lie about being passionate. They especially exaggerate their passions when it is perceived to affect their job prospects. Sometimes, a pretense of passion can indeed turn into the real thing. Yet the incessant drumbeat for passion has become such a common refrain that it has corrupted and colored the very message it was meant to filter.

Professional actors are paid to present a pretense of passion. Such passion is hollow at best - a clever deception for our own amusement - but it is all too common to find people who can act a passionate role with excellence but have little value for honesty and integrity.

In marriage, passion without honesty, integrity, and commitment is just a precursor to divorce, or worse. Passionate actors poison their relationships.

Passion shouldn't be an acid test. It shouldn't even be the first thing you look for. Look for healthy relationships instead. When you find them, the passion will grow out naturally.

Thursday, September 8, 2011

Marginalizing Your Peers

I'm reading a blog by S. Iannarino, in an entry titled "No Garbage In, No Garbage Out." Now, Iannarino's material is a little above the fold compared to some sales and marketing pieces, but it is still more pop psychology than rocket science. Among the pithy aphorisms and exhortations, Iannarino repeats a few recommendations I've heard often. Just as often, they give me pause.

One of his exhortations is "avoid negative people." Now, on the surface, it seems quite reasonable, even almost natural. An uplifting environment and the comfort of intelligent, positive peers is definitely better. But it has always bothered me a little bit that what the pop-positive-psych-preachers propose to get there, is essentially that we abandon those most in need just so we can protect a personal pie-in-the-sky mental state.

Think that's too extreme? Am I being too negative?

What does this recommendation say about how you should widows, orphans, poor, under/unemployed, sick, those coworkers nobody really knows well, or some minority class of the disenfranchised? No, I'm not writing here of abstract groups who see themselves as victims, but those real people that you contact that actually have stresses and struggles. Their coping mechanisms don't always compensate.

What this advice says, essentially, is "Let them go to Hell, so I can pretend I'm in Heaven."

Selfish rule making like this is one of the reasons why a Sales and Marketing mentality is so bereft of ethical standards, and why honesty, transparency, and trust are so much harder to come by in the business world. By narrowing their own focus based upon their own personal dogma, they marginalize their neighbors.

They are also probably discard the wisdom of more realistic minds. A study I read suggested that depressive tendencies in kids is usually associated with a more accurate self-assessment, than of more up-beat peers.

Put another way, knowledge isn't always as uplifting as it is made out to be. The fruit of the tree of knowledge may have been a way of opening the eyes to good and evil, but it also had the effect of excluding its consumers from a garden of ignorant bliss. Ignoring people who complain may be wise; but conversely you may also be ignoring their wisdom.

There is a place for assertiveness when dealing with people who have trouble coping. But it is not assertive to avoid people just because they challenge your world view, force you to consider risks, account for costs, or consider consequences. No, that is far closer to passive-aggressive cowardice.

There is no particular place in Hell reserved for those who choose to close their own ears to other's sorrows. As Jesus said in the Book of Luke (10:25-29), empathy is required for salvation. So if you're a believer who follows this sort of guidance and marginalizes people out of a sense of protecting your personal belief system, your belief isn't a free get-out-of-hell pass. Even if you're not a believer, there's no magikal taboo protection to be had in that sort of positive psychology.

Don't Abandon. Learn to cope with the negativity. Help others to see past their own limitations, and mentoring those who can accept it by teaching them better coping mechanisms.

Tuesday, September 6, 2011

Running cars on zinc

The federal government has been pushing hydrogen research, and after looking over several research papers I'm astounded at how complicated approaches seem to take all the attention. It is as if people are more interested in playing with science than with solving practical problems.

One concept that caught my eye was an Israeli solar project, which proposed a zinc/zinc oxide/water/hydrogen cycle. Even there, extreme heat is used in the process of reducing water to hydrogen. Six hundred degrees may me manageable, but it isn't really necessary.

But is the zinc process practical? Well, a gallon of gas is equivalent to about 1kg of hydrogen. Hydrogen weighs about 1.01g per mole, so it would take about 990 moles of H to get the power of a gallon of gas. You need one mole of zinc to release two moles of hydrogen from a mole of water, or 495 moles.

Since zinc weighs in at 65g per mole, you'd need 32178g of zinc to liberate enough hydrogen to equal a gallon of gasoline. So now we are talking about 70 lb of zinc in a powdered or slurry form. That's not counting the weight of the water you'd have to consume. The weight of 495 moles of water is about 8910g or 20 lb.

It would take 10 gallons to provide for a typical commuter vehicle. Carrying around a 900 lb tank of zinc and water doesn't seem at all a good trade off to a 10 gallon gas tank. Gasoline itself weighs in at about 90 pounds.

We could do the same sorts of computations to find that aluminum or magnesium would cut the weight by somewhere around 2/3rds, or around 300 pounds, which is certainly more competitive, although either metal would require more energy to reclaim.

Friday, September 2, 2011

Git's Poor Command Line Habits

Tom Lord's Arch, or 'tla', was one of the first open source distributed version control systems. It was widely criticized as having overly long names and convoluted command line interface. Linus's Git has shorter names, but the command lines can be just as perverse.

Take, for instance, the command to set the repository back in time by one commit:


git reset --hard HEAD^


OK, what's up with that? It was not necessary at all to introduce a idiosyncratic tree walking syntax just for Git ?
Seriously??

[edit: not to mention, git reset is as dangerous a command as rm * for pretty much the same reason.]

In Git, the HEAD^ shows the parent of the HEAD commit. But wait, there's more!
Use HEAD^^ to see the parent of the parent of the HEAD commit, if it exists, or HEAD~3 (that's a tilde, '~', not a hyphen) to show the great-grandparent.

There's not a lot of consistency to the various command line interfaces in Git; most of the commands make use of a mix of positional arguments and labelled parameters and options, which can make the commands rather arbitrary and thus needlessly more difficult to remember. The choice of command names is also rather spurious.

Git has some good qualities, and lots of documentation. But lots of programmers keep complaining that they can't remember what that particular command was they were looking for, and it is evident that with Git it is difficult to infer for many of us to infer the proper semantics based on the syntax of the options. It's not us, its you, Git! You're hard to remember!