Saturday, April 18, 2009

My 1st Song

In an effort to learn Haskell I wrote this. It has so far been very rewarding, except for the damage it has done to my hands.

I was a little bit unsure if I should put it out there, because it really isn't up to standards (no tests, no way to actually view results, very poor GA implementation). I guess I felt if it's predicated with the fact that it was basically a learning experience then that caveat is enough.

Sunday, March 8, 2009

Did You See The Words

Somebody went and implemented Doc Test in Haskell. So my commenting rant is a bit weakened. Although this is more an answer to how then to why (which I understand is the rational for comments). I also wonder how well this would work in a language like Java (I suspect it would not).

As I work my way through Real World Haskell, I'm attempting to write my own project (as a bit of proof to myself that I am learning it, not just reading). At first I wanted a randomized list of strings, no biggie, just sort with a random element in your comparison function. Actually that's not good enough, so i pilfered some. So I needed some list of random numbers, back to the book because I don't know how to use IO features. Eventually finding a nice example brought it together. Until I found that said pilfered shuffle function need a list of randoms bounded by their place in the list (or at least that's what I could glean in my very cursory look).

On the Kinesis front:
After about a week, maby week and a half, I was finally comfortable enough with it to not have to think about what I was typing. However it was still a challenge to hit the control keys. So feeling ab it guilty about the price i had them send it back; I almost wanted keep it, the expensive price (even though I wasn't paying I just couldn't rationalize). So instead their going to get me a couple of cheaper keyboards (Logitech Wave, MS Natural 4000). Maby I'll go ot a chiropractor as I've been recommended. For people thinking about getting one:

  • The documentation says you'll be comfortable in a 3 hours, and at your origional speed in 3 days; Maybe i'm getting old and slow but I was not comfortable by any streach after 3 hours

  • The function keys are awful (very small, rubbery).

  • Eclipse hot key combinations do not work well with this keyboard

Thursday, February 26, 2009

The bravery of being out of range

I always thought the idea of flow (as introduced to me by DiMarco's peopleware), was somewhat at odds with pair programming (or at least XP's pair programming all the time). How can you get into flow with somebody talking to you (maybe if context is maintained then you don't get pulled out?). In anycase pairing is difficult, and i've only really done XP style pairing (all the time, only pairing) once, for maby a couple of months. I've only met one person who did full XP all the time (and they started a company to do just that, the company went tits up, that's all i know about it). Oh actually I met Kent Beck once -- he's probably done full XP (I was drunk - OOPSLA 2000 was excellent).

Extreme Pairing Experienced

Today i had two distinct pairing experiences. For most of the day I paired with the easy guy. We got reasonable amount done, all of it tested. I would qualify that as all of it well tested. If the tests break you've ether broken it, or changed the intent; you haven't added a method. So I was pretty pleased when other co worker easily frustrated guy (actually he's a decient guy, I just find hima awful to work with). He'd asked for an explination of some code I'd written (I presume he wanted to verify that it wasn't breaking something he was working on). I haven't quite sat down, and already he's huffing over some peice of code, what i understand is a tisk. So I start to explain the code i've added. Not five words in he's looking at something else and huffing. He aplogizes and we go off to look at the class i've added. We do have a rule that all of our classes should be commented (I staunchly disagree that this is necessary -- as noted in previous posts, but i try to conform to the team's guidlines). I'd missed the comment on this. So before he even trys to understand, he starts writing a comment at the top of the class "No comment". I've dealt with this guy for awhile, my response. Get up and walk away. Okay not the most mature response in the world, sometimes you have to put some distance between yourself and people that antagonize you, so you don't tell them that they should lick your balls and asshole. We continued our little spat when he came over and asked what was going on, I explained my frustration, he told me he wouldn't ask for help, i responded "good". What a wonderful and helpful exchange.

Thick Face, Black Heart

I've had problems with this guy for awhile. I can't think of critisim that would be constructive. I've attempted to look at what my conributions are to the problem, I can't see what they are (probably too close to the problem).

Wednesday, February 25, 2009

Bring the keyboard pain

Good News Everyone

Typing can be hard on the old digits. So I convinced work to buy me a
Kinesis Advantage. Runs about 350CAD plus tax; I feel a little pressure to appreciate it (not that there necessarly is any pressure). After a day with it (the documentation says you should be at ~80 after 3-5 hours) I find it awful. How can this be? It comes highly recommended.

Obligitory editor/IDE comments

As it turns out I don't spend much of my time typing letters. I use eclipse at work with java. I spend most of my time pressing Ctrl+Space, arrow keys, and various combinations of meta keys. It's kind of pathetic really. In my efforts to learn Haskell I've found the auto-nag/syntax completion have become a real crutch. This is one crutch I don't know if I'm willing to let go of. I've heard lots of respectable programmers claim that vim/emacs are supperior programming tools, but I've yet to work with anybody that was so proficient with them they could beat somebody who had a command completeing IDE. Especially with a verbose language like Java. For Haskell I use vim as an editor; it was easiest to setup, and came with syntax highlighting. I tried emacs but vim worked with more features right away, and really I'm not interested in fighting with an editor when I'm learning a language.

Outcome
I'm going to give it at least to the end of the week, because I don't want to let go of this dream of RSI free life, and apparently there's a 30 day return policy. Maybe I need to stop feeling guilty.

Full disclosure: this was typed on a Logitech DiNovo edge (quickly)

Thursday, February 19, 2009

A Code Commenting State of Mind

I've long held the opinion that you write code for the people coming behind you. You hope you can give them something they look at an understand. Sometimes even aspiring to elegance. So I believe the following isn't written to avoid typing.

Commenting is Overrated


Useless comments diminish comment value

In my mind this is the major problem. Comments are seen as a way for people to communicate about a piece of code. Language can be more semantically dense, therefore make it easier to communicate intent. So doing this more can only be good right? I don't think so; I think there are places you are doing odd things where it makes sense to have comments. Comments everywhere mean these valuable comments go ignored. For example:


public Integer sum(List integers) {...}

is as valuable as:

/**
* Calculates the sum of a list of integers
* @param integers - a list of integers
* @return an integer which is the total value of all integers added toger
*/
public Integer sum(List integers) {...}


Commenting often means boilerplate


"Since comments are so communicative we should comment all our code". "All our java has javadoc, it's part of our code style, also we put our braces here". Leads to unnecessary comments that pollute the code base with irrelevant information:


/**
* Determines if cake is a lie using cake context's
* @param whereCakeWasMentioned a collection of cake contexts where cake was metntioned
* @returns boolean - a boolean true if cake is a lie, false otherwise
*/
public boolean isCakeALie(Collection whereCakeWasMentioned) {...}


Ok so a better comment would be:

/**
* Determines cakes lie potential using ratmans lie detecting algorythm http://...
**/

My argument would be -- if ratman's algorythim is that complex then either

public boolean isCakeALie(Collection whereCakeWasMentioned) {
...
ratmansCakeAlgorythim(...);
...
}


or:

//ratmans algorithm http://..
public boolean isCakeALie(Collection whereCakeWasMentioned) {


If ratmans algorithm is worth mentioning an extracted method will communicate that part of it, or a very minimal comment. When forced to write boilerplate comments for everything, the top most (and useless comment), will be produced.

Code is executed comments are not

While comment maybe appropriate in it's original context, maintaining a comment adds to work load, taking away time from ensuring the method name is communicative of intent and function. Time spent making well crafted comments could be spent making more understandable code. Code must be read to understand it's function, the comment not necessarily so.

Context changes from programmer to programmer

A commenter can not determine the context of the programmer. Should the commenter to explain language features (i.e. regex, bit shifting) that are somewhat distinct from the rest of the language. Does the commenter need to explain patterns (i.e. this follows MVC).




I came to this opinion while working on/with a Smalltalk to Java xmlrpc framework. In our Smalltalk code the comments were few and far between, so when I got to a method and saw a comment I'd often read it if the code wasn't obvious.It's value was made higher because it didn't happen often. The context was almost always something bizarre was going on, and often related to the domain. So my creed became:

If you have to write a comment to explain a method, there's a good chance your method is too complicated. If you're doing something odd that needs explanation then a comment may be appropriate.


This has been written before however, and with a less biased stance at C2 Wiki.

Wednesday, February 18, 2009

The pros and cons of agile development

I got out of school, with an expectation of days of UML and big O notation coming to be part of my day, aside from the coding. I was surprised at how little of both there was. I was also surprised at the number and awfulness of meetings I had to attend. I learned that being a programmer meant long hours of coding, deadlines that were always set too short. Bosses that set deadlines artificially short because they knew that people would fill up the time given to them.

Then XP came along, and i bit. A humanizing development process, that emphasized less documentation, more code. Any process which includes that must be worth something, I'll check out the TDD, unit tests, continuous integration, paring, on site customer, office layout.

So I helped introduce these concepts to the place, one of my peers was the champion really, but i helped. My next job i continued, more TDD, more unit tests, full on paring. I found it did work really well. I've since switched jobs twice more, introducing these concepts in the last job, and joining a full scrum team at the current job.

I should be like a pig in shit right? I've surrounded myself by people who are trying to work towards what I've made one of the focus' of my career.

I'm not. I find it dogmatic. I'm in the church of scrum and that is the only true way.

Most of the unit tests, I find don't work well. They are brittle as hell because people want a test for everything, and end up testing that method X got called. Task break downs must be small; anything greater then a day estimated is too big. The product backlog is used as a cudgle to beat developers who provide anything more, and give product owners the absolute least.

These aren't the real problems though. The real problem is inflexibility; an ironic lack of agility. Not every developer works the same as every other developer, some like big tasks, like one thats going to take a couple of days (remember flow), having a unit test for everything is damn difficult (i suspect there is a point of disappearing returns), the product backlog is not a contract.

I had the honour of talking with Dave Thomas (the OTI one) once at oopsla. He was trying to help companies become agile, and told me the key was finding what worked for the team.

What's bizarre about this, is we hold retrospectives, this should have come up, and it probably has. However nothing has changed because we have angry zealots on our team. It's unfortunate that for a real attempt to be made at a process there often has to be somebody who's willing to push in this way. The champion i mentioned at the first place was a zealot, I myself probably was as well (I don't think I am now).

So I've identified the problem, but I think I've run out of enough Give A Crap to do anything about it.