Utility Git Bash Shortcuts

Big hat tip to sartorial exemplar John Fair for putting me on to this idea and sharing his set of default aliases.

If you use git bash for your typical interaction with git (and probably you should if you don’t because it behaves the same on all git platforms), adding a few shortcuts can dramatically cut down on the typing you need to do.

Open a git bash prompt.  From the prompt, open ~/.bashrc in your favorite editor.  Then paste these aliases into that file.

alias st2='/c/progra~1/sublim~1/sublime_text.exe'
alias fsi='/c/progra~2/mid3a6~1/v4.0/fsi.exe'
alias s='start '

#Change to base directory
alias ctb='cd /c/mysandbox'

#Git status--use this one all the time
alias gs='git status'

#Git checkout -- another one I use all the time
alias gche='git checkout'

alias ls='ls -alp '
alias ga='git add '
alias gb='git branch '
alias gche='git checkout '
alias gcom='git commit '
alias gcam='git commit -am '
alias gl='git log '
alias gpl='git pull '
alias gm='git merge '
alias gd='git diff '

You may notice that I have a shortcut for my favorite editor (Sublime Text 2) as well as an alias to bring up a F# Repl too.  I also have a utility alias to change to the root directory of my current development work.

Windows Live Writer 2012

Thanks to Scott Hanselman, I’m now writing this post with Windows Live Writer 2012.  For all of its miscues over the last couple of years, every now and again, Microsoft comes up with some modest piece of software which really hits it out of the park.  Live Writer is one such piece of software and I’m glad to see the Microsoft took the time to release a new version.

You’ll need to download the entire Windows Essentials 2012 package to get LiveWriter 2012 but it’s a minor inconvenience.

CodeStock 2012

First of all, kudos to Michael Neel and everyone that put on CodeStock.  This was my first time attending CodeStock and to see such a well-run conference is always a pleasure. I know from experience that there’s a lot of work that goes in to making things run that smoothly.

I got to attend a few very interesting sessions.  Mike Falanga’s session on using F# and MongoDB for analysis of large datasets was very interesting.  Daniel Mohl’s session on F# and Web Development was also good—and it was really nice to meet Daniel in person and get a chance to gab with him a bit.  There were a few folks from the Nashville area at the conference and they must have some major-league brain power out that way.

Also Rob Gillen’s talk on how buffer overflow attacks work was both fascinating and a bit scary. I can just imagine how many unpatched vulnerabilities there are running around in all the publicly deployed sites I regularly depend on.

Finally, here’s the slide deck for my F# Shell Scripting Talk.  I’ll edit this post later to share sample code.  I’ve posted the slide deck as a PDF file to maximize the number of people that can see it.

Note: Thanks to Dennis for pointing out to me that I got the name of the presenter for the buffer overflow attack talk incorrect. 

The Mythical Enlightened Employer

I was having a conversation with a fellow developer the other day and we we chatting about the lack of foresight of many firms regarding functional programming.  This naturally led to a discussion of how chaotic many workplaces are. This, of course, led to the old saw—if you don’t like where you’re working, look elsewhere.  I’ve heard this advice repeated often—if your current job isn’t doing it for you, look around.  There’s a dream job out there somewhere. 

I have to say that I’ve been writing software and working in IT for nearly 25 years and if there’s a place where things are truly at an enlightenment level north of CMM Level 1, I’ve yet to find it.  I use CMM Level 1 simply as shorthand for the level of controlled chaos which seems to prevail almost everywhere.  Perhaps they should change the name from CMM Level 1 to “Typical Workplace.”

The thing is, talking to my fellow software developers, the complaints about unrealistic deadlines, software death marches and so forth are so common that I really wonder if the “enlightened employer” actually exists.  I used to work for a firm that was once upon a time voted on of the best places to work in the country for IT and I knew several members of a team that worked 60 hour work weeks for a few months, at least, and were never compensated with either bonus pay or comp time—and the product still shipped late by the way. I’ve heard rumors about Google (I mean who hasn’t in the IT world?) but given the number of “Why I Chose To Leave Google” blog postings one begins to wonder if even that bastion of enlightened software development is just a myth too. 

I want to make a suggestion to those who feel that the pasture is greener on the other side of the fence.  Seriously consider if you can’t make the pasture greener under your own feet.  If you really cannot improve things in your own workplace (and certainly there are some truly benighted places in this world) then move on.  Otherwise, maybe you can transform your own company into the Mythical Enlightened Employer that we all seek.

Git It Anywhere

Just a quick tech tip: if you have Skydrive (or GDrive or Dropbox or . . . .) you can get Git on any machine you have to use without having to install it on the machine.  Here’s how:

1. Get the Portable Git package
2. Create a directory on your cloud drive for Git (I use utilities\git but I cannot think of any reason to prefer one to another.)
3. Unzip Portable Git into that new directory

Tada!  You can now access Git any place you can access your cloud storage.  Of course, this may not allow you to push up to your Github repository but it will still allow you to have version control on any machine from which you can access the cloud.

R. I. P. Cousin Tony

On Saturday last I learned that my dad’s cousin, Donald Anthony Cornacchio had passed away.  It’s never easy to put in words how we feel about someone we’re close to and Tony (I always called him Tony—no one called him “Donald” that I know of and I think he hated to be called “Donald”) was more like an uncle to me than a distant cousin. 

I’m not exactly sure what happened to him but I get the notion that he was suffering from cancer and it finally got him.  I know that must sound strange—saying I was close to my dad’s cousin and then saying “but I don’t know exactly how he died.” It’s because for the last several years he’d lived in Indiana far away from the rest of my extended family.  Life has a way of drifting people apart I guess.

I’ve only had a few people hang a nickname on me in my life.  My uncle Giovanni and my cousin Louie Sardy used to call me “Onion”.  I liked that because it made me feel a bit less awkward at a time in my life when I often felt like I was on the outside looking in.  In college my roommates called me “The Latin Lover” which was a joke because I never had any dates.  But I laughed along with them because I knew they weren’t trying to be mean but rather it was the kind of good-spirited teasing that friends do to each other.  My cousin Ann-Marie calls me “Frau” after “Frau Blucher” in Young Frankenstein. We both find that movie immensely funny even after having probably watched it 40 times between the two of us.

A good nickname is sort of a special friendship between people; let the rest of the world call you what they like—to me you’re . . . the nickname.  We’ve got a nice safe friendly space here and that nickname is the password for you and me.  I think I heard Smokey Robinson (whose real name is William) relating how his favorite uncle had given him the nickname “Smokey” because he was self-conscious about the light tone of his skin.  A nickname can help to smooth the rough road of life sometimes.

Cousin Tony had a nickname for everyone he liked.  My dad was “Bounce”—I always thought that Tony had given dad that nickname but I learned a few years ago that my dad got that nickname when he was in high school.  And he called me “perfesser” (I know that’s not spelled right but that’s how Tony pronounced it.)  For some reason Tony always thought that I was a smart guy.  If I live to 100 I will always smile when I think of Tony calling me “perfesser” because Tony didn’t put on airs and he didn’t pretend to like people if he didn’t like them so when Tony gave you a nickname it was a sign of genuine affection.

The other thing that I will always remember about Tony was his given name.  I was complaining, as I often did when I was younger, about how annoying it was to be named with such an odd name as “Onorio”—how much teasing I took.  Tony said something to me like “Do you think you’re the only one who ever had anyone make fun of his name?” and he proceeded to relate to me that kids had cruelly called him Donald Duck and other names not quite so nice.  As an adult it’s hard to imagine being hurt by that kind of name calling but as a kid that kind of thing really hurts And knowing that my cousin Tony had suffered that too made it hurt just a little less—I felt just a little less excluded.

I am going to miss Tony because rather than seeing a little know-it-all and telling me (as he rightly might have) to stop being such a know-it-all, he gave me a great nickname and he made me feel pretty special. 

I could go on and on about Tony because even though he may have told you otherwise, Tony was a great person.  At some point it seems that trying to reduce a person’s life to a few sentences maybe cheapens things.  I hope that we’ll all be together again someday and I can tell Tony thank you in person. 

Einstein’s Riddle and Closed Questions

There was a question posted to Stackoverflow about an implementation of the solution of “Einstein’s Riddle” in F#.  Here’s the text of the question, which I include in case the text of the question is later altered:

I’m looking for Einstein’s Riddle solution using F# and I’ve found only Einstein meets F#.

Is F# suitable for this problem and are there any other implementations?

After a bit of discussion and debate, the question was closed.  After a bit more discussion, the question was reopened.  It’s currently well on its way to being closed again. This is nothing that unusual for Stackoverflow.

What I found quite interesting and a little bit troubling was a thread of tweets on Twitter about who closed the question and why it was closed.  Perhaps I misunderstood the tweets in question but it seemed that people thought the question was closed partly because it concerned F#. One person implied that one of the people who voted to close the question had no right to do so because he’s never answered an F# question and therefore can’t know anything about F#.

Now this is solely my opinion, of course, but I think the question should be closed, F# or not.  The reason is the second sentence.  “Is F# suitable for this problem and are there any other implementations?”  If he had stopped after the first question, I would have been fine with the question being left on Stackoverflow.  However, think about that second sentence “Is F# suitable for this problem” – well, I don’t know.  Define suitable and then we’ll talk.  F# is suitable for lots of stuff but if you need to build a solution on the JVM then no it’s probably not suitable.  If you need to interface with lots of native DLL’s on Windows, there may be more suitable approaches.  If you’d like very succinct, short code then probably Prolog is more suitable. This strikes me as a terrific example of an open-ended question.  Without additional context it’s impossible to give a definite answer. And the second part “are there any other implementations?”  Well, yes, I’d be willing to bet there are.  Which language?  Why do you want to see the code—I mean I doubt this is something for work so why do you want to study it?  Again, hard to answer without additional context.

To my mind the second sentence is rather an open-ended question no matter how you interpret it.  And the Stackoverflow FAQ pretty clearly asks people not to ask open-ended questions: “Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page”.  Now the FAQ is not the received word of God but it is a sort of contract that the people paying to run the site ask all of the users to honor.

Frankly I have to say that I’m a little disappointed with my fellow F# developers who seem to think that someone is going through and closing questions solely because they touch on F#.  It takes five votes to close a question—one person with a grudge is only 20% of the way there–and I don’t think implying that someone has a personal grudge against F# is really helpful or productive.

Don’t get me wrong; I have nothing against open-ended discussion questions.  I do have a problem with people posting such questions on Stackoverflow when the people running the site have repeatedly asked members not to do so.

Now some of you reading this will think—fine delete the second sentence.  But that’s not quite the same thing as fixing a typo now is it?  If the original questioner would remove that second sentence I’m sure no one would be voting to close his question.  But that should be his decision.

As I say, I’ve got nothing against open-ended discussions—love them in fact.  But when someone provides a great service to me for free and they ask me to please avoid a certain behavior it seems a bit ungrateful for me not to avoid it.

And please fellow F# developers—dial down the paranoia a bit please?  Hypersensitivity to any whiff of anti-F# feeling isn’t really helping us to get the word out about a great language.

You Might As Well Use Globals

I’ve seen a relatively common anti-pattern in Object-Oriented development, although to be fair, I’ve seen something closely akin in non OO languages as well.  The following C# code is a demonstration of the issue:

 

using System;

public class C
{
    private int _m;

    public C(int myInitialValue)
	{
        _m = myInitialValue;
	}

    private void f()
    {
        if (_m > 0)
        {
            _m = 1;
        }
        else if (_m <= 0)
        {
            _m = 0;
        }
    }

}

Can you spot the problem?

The problem is the constructor and the f function using the class variable _m directly.  What could be wrong with that, I hear some of you asking?  A few things:

1.)  Let’s say I need to use the functionality of f somewhere else.  I now need to take _m with the code. Big deal I hear you saying—I need to remember to copy a variable.  Now pretend that f accesses not just one member variable but that it accesses three or four member variables.  To say it in a little more technical way, there’s now a coupling between f and _m (and any other member variables we might use within f).

2.) By referencing _m within f but not passing it in f’s parameter list, I’ve made f a bit less of a black box.  And I’ve modified _m but it’s not obvious outside of the function; I have to look at the contents of f to see that _m is modified. Again, with only one variable this is probably not a big problem, but consider the case where I’m referencing 3 or 4 member variables or maybe even more.

3.) Now consider the case where we need to guard the values put into _m or I need to transform the value in _m when I read it.  No problem, you say, simply add an inspector and mutator to the _m member variable.  And that would be great but it wouldn’t fix the problem in f because f is accessing the member variable directly.

Basically all of the problems that convinced people that using global variables is a bad practice are present in this way of using class level member variables.  The irony is that developers who’ve grown up with the dogma that global variables are a very bad practice which should be avoided at all costs think nothing of writing code like this. 

Now, as I often point out to people, we’re discussing engineering not religion; very few things in engineering are absolutely always right or always wrong.  However I cannot think of many cases where direct access to a member variable in a class is a better approach than either passing the value explicitly as a parameter, returning the new value explicitly or accessing the member variable via an inspector or a mutatator.

Why The Defaults Matter

I often think of why I feel that it’s important to have a functional language—not just write code that’s pseudo-functional in an imperative language.  As I think this through, I wanted to record some of my ideas on the subject.

Even the best developers I’ve known are almost always inclined to take the defaults.  I mean if the default string type is ASCII then you’re very unlikely to see Unicode strings in the app unless someone specifies that this is needed.  This is not laziness; it’s simply that these developers have other issues to concentrate upon.

Why is this important?  Simply this: I’ve come to realize that default mutability is an accidental complexity–in the sense that Fred Brooks used that term in his “No Silver Bullet” essay.  Don’t misunderstand what I’m saying–mutability is necessary and appropriate.  But having all values in software mutable by default is an invitation to lots of unexpected side effects.  And this is why I really believe that functional languages will continue to gain in use.  Functional languages are immutable by default.  Impure functional languages (OCaml, F#, Clojure, and Scala among others) do allow a programmer to specify mutable quantities where it’s appropriate due to performance considerations but they default to quantities being immutable–and that’s why they’re important.  If things default to being immutable, developers will learn to work with immutable quantities and become accustomed to them in the same way they’re now accustomed to thinking in Objects.  People seem to forget that 30 years ago, OO was as much an academic discipline as Functional is now.

Every developer knows they should mark quantities as constant (or final or readonly or whichever keyword expresses immutability) but most do this only as an afterthought and they do it incompletely.  Default immutability could eliminate a whole class of side-effect errors and therefore reduce errors in our code by a large fraction of all errors present. The issue is not the question of does “const correctness” (for lack of a better way of phrasing it) make software less error-prone; the issue is getting developers who are always under impossible deadlines to use constants by default.  Languages that default to constant, immutable quantities are a large step in that direction.  This is why functional programming is important and this is why you’re going to inevitably see more and more developers gravitating toward these functional languages.

The Tech Support Effect

At a few points in my career I’ve worked in tech support.  It’s an experience I heartily recommend to every developer.  Every developer should spend at least a month or two supporting software because it helps you to understand the sorts of issues our tech support people deal with.  I really believe that too many developers, and I include myself in that group, don’t appreciate how truly valuable good technical support people are.

An interesting thing happens to many support people of long-standing.  They get a very negative impression of the software they’re supporting.  This is simple and understandable because all they hear most days are complaints about the software.  People don’t call tech support to tell them “Hey the software is working great!”  Even if 99.9% of the software is working exactly as it should, the .1% will be the part that customers call about. For lack of any better name for this phenomenon I call it the “Tech Support Effect”—that long term cynicism that sets in from hearing complaints and negativity day in and day out.  

I think the same thing happens in other areas of life as well.  The news can really depress a person quickly because the parts of our economy that are working aren’t the parts that get reported upon.  Gas may reach $5/gallon soon but no one in the news will tell you that the Europeans would be dancing for joy if gas were only $5/gallon over there.  Of course they have better mass transit but that’s another discussion. The 999 people who safely negotiate some dangerous turn on a freeway don’t make the news; it’s the 1 person who fails to make the turn that gets shown at 6 pm.  It’s easy to get a very skewed view of things.

And I definitely think this happens in software development.  We see the failings of our own software so often that we can really get down on ourselves and start to think of ourselves as idiots.  We can forget that many of us turn out thousands of lines of code that works substantially as it should when we’re shown a line of code where we forgot a semi-colon and that caused a problem for a customer.

The point is this; don’t fall for the Tech Support Effect in your own life.  All of us have things in our life we could wish would be better.  But every once in a while if you think of all the good things you’ve already got it can help to put the negative in perspective.