Aug 22 2009

Songs in Code

Programming related hashtags don’t make the top trend on Twitter. But last Friday night, when most people are out except geeks, the hashtag #songsincode made it to the top trends on Twitter. As of today, here some of my favorite songs in code.

Songs in Code

  • @juixe: if(self.getLikes().contains(BIG_BUTTS) && !self.canLie()) {other.getBrothers().deny(false); you.getFace().add(ROUND_THING); you.getSprung()} #songsincode
  • @techknow: Rhythm instanceof Dancer == true #songsincode
  • @techknow: 2.times do we_will end; rock_you; face :has => ‘mud’; disgrace you, big #songsincode
  • @anteaya: if “its” === 1999 then party; end #songsincode
  • @cessor: for(int i = 99; i >= 0; i–) { Bottle b = _bottlesOfBeerOnTheWall[i]; b.Pass(); } #songsincode #CSharp
  • @seeflanigan: Love.is_a?(Battlefield) => true #songsincode
  • @stewdio_org: return “that’s” + ( name.indexOf([ “girl”, “stacey”, “her”, “jane” ]) > 0 ? “” : ” not” ) + ” my name” #songsincode #tingtings
  • @malvim: try { me.go(“rehab”); } catch { return “No, no, no!”; } #songsincode
  • @bricriu: if (self.go() { return new Trouble() } else if (self.stay()) { return new Trouble().intValue() * 2} #songsincode
  • @projektdotnet: int main(void){get_your($body_beat); let_your(blood_flow); return 0;} #songsincode
  • @NescioPhone: try { margaritaville.Resolve(“Lost”); } catch (Exception woman) { Trace(this.Fault); } #songsincode
  • @brotzeitbrettl: for(int i=0; i==0; i=1) { we.celebrate(); oh_yeah.allright(); dancing.stop = false; } #songsincode
  • @chiihime: foreach (night in myDreams) { me.see(you); me.feel(you); }; #songsincode
  • @joestump: if (IN_YOUR_ARMS && TONIGHT) { die(); } #songsincode
  • @brentgarner: if($theEnd){$loveYouTake = $loveYouMake;} // #songsincode #beatles
  • @stewartyu: while(money++) { problems++; } #songsincode
  • @dustinfineout: if (time.equals(‘hammer’)) { this.touchable = false; } #songsincode
  • @kevinwo: hold($me, $close++, $tiny_dancer); #songsincode
  • @llemirtrauts: for(var oclock = 1; oclock <= 12; oclock++){rock();} #songsincode
  • @abachman: you.dance if you.want_to?; #songsincode
  • @dbrady: i == sky << eye; i.looking!(@you); i.authorized?(your.mind, :read) == true #songsincode
  • @zarkon: if (you.loves(somebody)) { them.set(free); } #songsincode
  • @llemirtrauts: @paynen [money, show, getReady, goGoGo].forEach(function(value, key) {key + for(value);});!stepOnMy(blueSuedeShoes); #songsincode
  • @jonrimmer: x = ‘Umbrella’; you.Permissions[‘StandUnder’] += self.GetPossession(x + x.Right(4) + x.Right(4) + ‘eh’ * 3) #songsincode
  • @jverdi: while(true) {if(!this.touch()) {echo “can’t touch this”;}}#songsincode
  • @tiemez: while(false){ self.giveYouUp(); self.letYouDown(); self.runAround(); self.desertYou(); } #songsincode
  • @mikemangi: function iWant(){ $rocknroll=’allnite’; $party=’everyday’; keepon($rockn); } #songsincode
  • @librarythingtim: if(!woman) { cry = false; } #songsincode
  • @motherwell: if(you.think(sexy) == true && you.want(myBody) == true ) { you.tellMe(so) } #songsincode
  • @TjoosDude: me.see(you.watch(me.watch(you))); #songsincode
  • @cameronhunter: (function( you ){ return you.getLove().matches(/bad medicine/) })() #songsincode
  • @tower10: @paynen function () { walk(this).way(); talk(this).way(); } #songsincode
  • @eviltabbycat: public interface egyptian {public void walk();} #songsincode
  • @frenchs: int *chicks = (int*)malloc(sizeof (int)); int *money = null; free(chicks); #songsincode #rusty_c
  • @joestump: if (HUMPTY_DANCE) { define(‘TRANCE’, true); do_the_hump(); } #songsincode
  • @paynen: (girls == boys).like(girls.do(boys.like(girls.do(girls.like(boys)))) #songsincode
  • @beenewilliamr: dc -e'[dsm1laxsr]sj[2/ljxlcxq]st[3*1+ljx lcx]sy[d1=qd2%0=td2%0!=y]sc[100P]sw[0P] se[q]sq[d1700!>qdlm%d0=w d0!=esr1+lax]sa28lcx’ #songsincode
  • @skatterbean: if not self.check(): self.wreck() #songsincode (thanks do @dreid for the bug fix)
  • @frenchs: if(!roxanne) { self::turnOnLight(self::RED); } #songsincode
  • @eegiffin: class HotelCalifornia { void checkOut () { canLeave=false; } } #songsincode
  • @ald: try { Britney.Sing(); } catch (Exception ex) { throw new Exception(“Oops”); } #songsincode
  • @herlifeinpixels: while you.find(me, indaclub): me.sipping(bub); if isinstance(you, sexylilthug): you.need = me.got; #songsincode
  • @dhinojosa: assertTrue(heat.isOn()) #songsincode #glennfrye
  • @llemirtrauts: [].push(“ah”).push(“good”).push(“real good”);#songsincode
  • @ara_p: roof.set(“fire”, true); #songsincode
  • @proxymoron: if(wantTo) { we = dance(); } friends = !dance(); if(friends != dance()) { we.remove(friends); } #songsincode

For some unexplainable reason, I found a lot of developers tweeted/coded the song Dude (Looks Like a Lady) by Aerosmith.

Dude (Looks Like a Lady)

  • @davglass: var Dude = new Lady();#songsincode
  • @jrconlin: @davglass Shouldn’t that be: (Lady) new Dude; ? #songsincode
  • @Slow3000: dude.setLook(Looks.LADY); #songsincode
  • @krigsi: LooksLike(“Dude”,”Lady”) #songsincode
  • @ptone: import dude as lady #songsincode
  • @clindh: looks == (lady)dude; #songsincode

I found these three variants of Jay-Z’s song 99 Problems interesting.

99 Problems

  • @brotzeitbrettl: echo count($this->problems) == 99; foreach($this->problems as $p) { echo ($p instanceof Bitch) == false); } #songsincode
  • @peterc: Okay, just one more: # problems.size == 99 && !problems.include?(“bitch”) #songsincode
  • @tome: en(problems) == 99 and “bitch” not in problems

Some songs, in code, by Michael Jackson.

RIP MJ

  • @techknow: dianna.setDirty(true) #songsincode
  • @pud: If (BillieJean.is != my.lover) { BillieJean.justa = ‘girl’; i = 1; } #songsincode
  • @RobertFischer: !my.isLover(billyJean) && billyJean.claims(my.theOne) && !my.isSon(theKid) #songsincode
  • @krigsi: if($Annie = ‘OK’) { SmoothCriminal(Hit) } #songsincode

Aug 16 2009

Retweet July 2009

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and I’ll be sure to follow back.

Software Development

  • Refactoring documentation.
  • The longest possible method name I have seen: getCorrespondingRowIndexInWisePickPopupListForCombobox
  • Why did programmers ever put version/revision control ids in their code? Was that a best practice at that time?
  • I know there is writer’s block, is there such thing as coder’s block? How do you break out of coder’s block?
  • Debug your thinking process. You can remote debug your thinking process, so it is like a outer body hacking.
  • Is your application user friendly or developer friend or management friendly?
  • Reframe the problem instead of trying hacks that break the current mental frame for the problem.
  • Half thought out features, means half thought out specs, means half thought out implementations, means 12.5% of what the end user wants!
  • Most rehash it up, some mash it up, a few smash it up, I fresh it up!
  • Own the source and distribution of the platform you use, don’t let the platform own your data or users!
  • Have you ever had to reverse engineer your own code, your own application?
  • Anyone using MonoDevelop on the Mac?

Product Placement

  • I wish GVoice allowed me to get a phone number in another country. I need a London number.
  • Can you get GVoice to forward to another GVoice number, which forwards the call to the original GVoice number? Will it break the internet?
  • Did Google jump the shark with their announcement of the Chrome OS? Why would they duplicate their efforts between two different OS?
  • Just got a Mac Mini to replace my old HP desktop. They are so small, I want on for my home, office, and car.
  • The new Mac Mini is the size of some old 360GB Western Digital My Book external drives.
  • Why is Go Daddy pimping Twitter with a popup dialog from their Domain Manager?
  • You know what would be nice? If @wefollow had an open API! Also, wefollow is an oxymoron, they don’t follow anybody.
  • Why doesn’t the phone company make it easy for you to give them a phone call? I can’t find their customer service phone number!
  • The worst part is that when you finally get a number, you get several extensions/options except the one you are calling for.
  • When calling the phone company, and finally reach a real person, the first thing they want to do is transfer you to another department.

Business Planning

  • You know how they say that dog owners often resemble their dogs, I think this also applies to business owners.
  • Many small businesses resemble their business owners, especially in terms of organization, quality, and planning.
  • Since when did ‘Don’t worry, be crappy.’ become standard operating procedure for startups? I see entrepreneurs advocating for crappyness.
  • Common advice is to make something people like. I say, instead of making a product/service make demand for that product/service.
  • First earn while you learn, then earn while you sleep!
  • Web 2.0 Distribution of Work: Let end users create the hard stuff.
  • Free is the ultimate bait and switch.
  • Never substitute value with volume.
  • Sometimes the easiest thing to do is to give it a try.
  • The probability of success increases with each time you try…
  • No matter what business you are in, your are in the customer service business.
  • If you shoot for the moon and fail, you get nothing but air. If you shoot for the stars and fail, you might get the moon.

Team Leadership

  • The easiest way to see team dynamics at play is when the team is ordering food.
  • I would rather have other people be pissed at me than me be pissed at myself…
  • You can compromise on schedules and deliverables, but never compromise on happiness.
  • Just like Hollywood people name drop celebrities, techies name drop three-letter acronym and buzzword technology sounding terms.
  • A good leader will ask more questions than he can answer.

Jul 22 2009

Don’t Turn a Code Review Into a Code Rant

In programming circles and when talking about code, I’ve often hear mentioned the Perl slogan “There’s more than one way to do it.” Thinking about the many ways we do it, whatever feature ‘it’ represents, I believe that the root cause of many of the software bugs we encounter are because engineers implement the feature in more than one way, then refactor it down the line, then add new conditions, then forgot how it did what it did. This often occurs because programming is like fashion, each season brings about a set of new best practices and technologies. We update the implementation to adapt to the current best practices, new technologies, and new features and don’t remove old bit rotten code.

Recently I a debate with a fellow engineer whose code I reviewed. As it is often the case, we had some existing functionality which we wanted to update with a feature. Most of the code review revolved around one existing method whose existing code looked something like the following.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

For the sake of this example, imagine that DataRow is a map of data that represents a row of data from a database and contains the meta-data of the columns it contains. The new functionality need to support a DataRow with a less number of meta-data, columns, than normally expected. We called this new feature partial value and so it was initially implemented as follows.

public void setValue(DataRow dr) throws DataException {
  dataHelper.setValue(dr, false, true);
}

public void setPartialValue(DataRow dr) throws DataException {
  setPartial(true);
  setValue(qube);
  setPartial(false);
}

Believe it or not, I had a very difficult and long drawnout debate with the engineer that implemented the above code. In my mind, there is no debate, the above code can be made to improve. In the engineer’s mind, this was good enough for this feature for the time allotted for the the current specifications for this release and for whatever other reason he counjured up.

One of the concerns I originally brought up with the initial implementation of setPartialValue was that if the setValue method throws an exception after having set the partial state to true, then the code will break out of both methods leaving an improper partial state behind. This will cause problems because the partial boolean field will have an invalid state which will caused problems if you the setValue method is called at a later point. Another problem, with this sort of style of programming, is the following scenario. Imagine that instead of a simple primitive boolean the partial property required an object reference that retained a lot of memory and you had the same exception, the memory for that field might not be garbage collected.

The sort of bugs that can be caused by the above implementation lead me to the following rule of thumb: Avoid instance fields. Always question the need for instance property. Try to be a team player and pass the object reference as a parameter down the stack. If you only need this little bit of state information for a method call, pass it as a parameter!

I couldn’t believe we had this much disagreement over three lines. At that moment I felt that code reviews are another form of micromanagement, but then I remembered who is the one that gets called if there is a bug in the system…. Yeah, me! The approach I was advocating did not require a object instance to keep the state of a boolean, which was only used within the context of the setPartialValue method call. In my approach the set/getPartial methods are not needed and it could have been refactored to the following.

public void setValue(DataRow dr) {
  setValue(dr, false);
}

private void setValue(DataRow dr, boolean partial) {
  dataHelper.setValue(dr, false, true, partial);
}

public void setPartialValue(DataRow dr) {
  setValue(dr, true);
}

The engineer countered that it “does not look nice” aesthetically to have a method call with to many parameters, and that we can’t just add parameters to methods whenever we need to pass another value. Touché. To this I responded that four parameters is not a big deal. Even though four parameter will not negatively affect a method signature, lets imagine that a method signature grew to 10 parameters, this can be solved by encapsulating all these parameters to one object. Programming languages such as Ruby use map literal for optional parameters and long parameter method signatures.

In the end, I won the debate but it didn’t feel like a victory. I doubted myself for pushing so strongly for what I know is right, in the end he was doing all the heavy lifting and this was just one small aspect of the feature as a whole. There is a line that if crossed you will be considered a micromanaging standard fascist, but that if you do not enforce you will inherit unmaintainable code. Coding standards goes beyond naming convention and third party libraries. There is a fine line, and you need to walk the line.


Jul 20 2009

Remote Debug Your Thinking Process

Here two tweet snippets of a conversation I had on Twitter about code. The first tweet snippet started from the realization that we can not only debug and optimize code but our thinking process.

  • @techknow: Debug your thinking process.
  • @DavidKaneda: @techknow Can’t — I only have the compiled version.
  • @techknow: @DavidKaneda You can remote debug your thinking process, so it is like a outer body hacking.

This tweet snippet of a conversation I had recently just pokes fun at Microsoft. Even after all these years, Microsoft blue screen of death and the negative perception/meme of Microsoft products provides so much joy to the world in the form of jokes!

  • @techknow: Most rehash it up, some mash it up, a few smash it up, I fresh it up!
  • @jzy: @techknow I trash it?
  • @techknow: @jzy LOL Microsoft Crash IT UP!

Jun 17 2009

97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know is a collection of essays written by a community of software architects. Each essay is about a page or two and drops some soft skill knowledge an architect needs to master. I already made reference of this book in 101 Things Every Software Architect Should Know. In this post I wanted to highlight some of the favorite quotes from the book, some real pearls of software architecture. The reason why these quotes mean something to me is because I have found them to be true through my experience. I hope they right true with you too.

“Fast” is not a requirement. Neither is “responsive.” Nor “extensible.” The primary reason why not is that you have no object way to tell if they’re met.
– Keith Braithwaite

Simplicity through experience rather than generality through guesswork.
– Kevlin Henney

Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
– Dave Quick

A little training goes a long way toward ensuring that everyone is on the same page when it comes to reuse.
– Jeremy Meyer

Software architects love the challenge of big, complicated projects. The potential rewards can even tempt people to artificially expand a project’s scope to increase its apparent importance. Expanding scope is the enemy of success because the probability of failure grows faster than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude.
– Dave Quick

Large projects’ requirements change many times before they’re completed. Important requirements usually remain important as the business changes, while others change or even evaporate. Prioritization lets you deliver the most important requirements first.
– Dave Quick

Reducing the project scope often results in a simpler architecture, and is one of the most effective strategies an architect can apply to improve the odds of success.
– Dave Quick

There is no appeals court for required field or mandatory workflow. … Required fields seem innocuous, but they are always an imposition of your will on users. They force users to gather more information before starting their jobs.
– Michael Nygard

From an architects’ point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system.
– Einar Landre

Things are usually easier said than done, and software architects are notoriously good at coming up with things to say.
– Timothy High

When you try to guess at future requirements, 50% of the time you’re wrong and 49% of the time you’re very, very wrong.
– Chad LaVigne

Screening for specific technical knowledge is definitely part of the process but turning an interview into a certification test will not guarantee success. You are searching for developers with problem-solving skills and passion. The tools you use are sure to change; yoiu need people who are good at attacking problems regardless of the technologies involved.
– Chad LaVigne

If you accept this fact – that the choices you make today will most certainly be wrong in the future – then it relieves you of the burden of trying to future-proof your architectures.
– Richard Monson-Haefel

Choosing a good technology for right now is hard enough; choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now, because anything else will not only be wrong choice tomorrow, but the wrong choice today.
– Richard Monson-Haefel


Jun 7 2009

Google IO 2009: Tech Talks

I, like many 10-5 developers not working directly with ajaxified web 2.0 applications, was not able to go to the Google I/O conference. I don’t feel so bad not going since Google has just released video recordings of over 80+ technical presentations from Google I/0. Most of the technical presentations are pushing Google’s APIs such as Android, Google App Engine, GWT, and Open Social.

As an aid for myself, and maybe other GWT developers, I have organized the pertinent tech talks as follows…

The Myth of the Genius Programmer
A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius. In this talk, we discuss how to avoid this trap and gracefully exchange personal ego for personal growth and super-charged collaboration. We’ll also examine how software tools affect social behaviors, and how to successfully manage the growth of new ideas.

Even Faster Websites
Steve is the author of High Performance Web Sites and the creator of YSlow. In this talk, he presents some of the best practices from his next book, including optimizing CSS selectors, flushing the document early, and discovering why 15% of users don’t get compressed responses.

Bespin and the Open Web
The Bespin project from Mozilla Labs is an experiment in re-envisioning how we develop software. In its current guise as a sometimes-fast web-based text editor shrouded in a horribly incomplete code editing platform, its potential might not be readily apparent. In this talk, Ben and Dion (two of the folks behind Bespin) will discuss the goals of the project, how they got to where we are now, go into implementation details on what it takes to build a bleeding edge application for today’s browsers (and not the ones from 1997) and share some hopes and thoughts on the future.

Big Modular Java with Guice
Learn how Google uses the fast, lightweight Guice framework to power some of the largest and most complex applications in the world. Supporting scores of developers, and steep testing and scaling requirements for the web, Guice proves that there is still ample room for a simple, type-safe and dynamic programming model in Java. This session will serve as a simple introduction to Guice, its ecosystem and how we use it at Google.

Do You Believe in the Users?
Too many programmers have forgotten about the lost art of customer service. All software has users, though most developers have forgotten how to respect them, trust them, or “sell” their software to them in an exciting (but honest!) manner. This talk will focus on anecdotes and strategies for keeping software design uncomplicated, making software fast, and putting usability above programming convenience. We’ll also focus on the importance of keeping a healthy illusion of simplicity, while allowing abstractions to deliberately leak for power-users.