Friday, March 12, 2010

Quotes from 97 Things Every Programmer Should Know

I thought it would be a collection of super-duper, mega wise unpalatable truth, but in reality it was the set of truisms, cliches and platitudes. In brief, I'm disappointed. There of course exists some interesting advices (<20), mostly applicable for very young developers.

Here are examples of the most useful:

Giles Colborne

When you get stuck, you look around. When users get stuck, they narrow their focus. [...] It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.

[...] Spending an hour watching users is more informative than spending a day guessing what they want.

Filip van Laenen

  • Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.
  • Use static code analysis tools to scan the code for unwanted antipatterns. If any are found, break the build.

Rajith Attapattu

Many incremental changes are better than one massive change. [...] It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures at a time is easier to deal with, leading to a more manageable approach.

Mattias Karlsson

Be gentle during code reviews. Ensure that comments are constructive, not caustic.

[...] Code reviews will flow more easily if the team has coding conventions that are checked by tools. That way, code formatting will never be discussed during the code review meeting.

Jon Jagger

Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition.

[...] Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself?

[...] Deliberate practice is about learning--learning that changes you, learning that changes your behavior.

Mike Lewis

Don't be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project.

Alan Griffiths

[...] the hard part [of the programming]--the thinking--is the least visible and least appreciated by the uninitiated.

Johannes Brodwall

When I start a new project from scratch, there are no [compiler] warnings, no clutter, no problems. But as the codebase grows, if I don't pay attention, the clutter, the cruft, the warnings, and the problems can start piling up. [...] If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, that person will just ignore all the warnings, including the significant ones.

Warnings from your build are useful. You just need to get rid of the noise to start noticing them.

Dan Bergh Johnsson

Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository.

Daniel Lindner

You need to give your project a voice. [...] The idea of XFDs [Extreme Feedback Device] is to drive a physical device such as a lamp, a portable fountain, a toy robot, or even a USB rocket launcher, based on the results of the automatic analysis. Whenever your limits are broken, the device alters its state. In case of a lamp, it will light up, bright and obvious. You can't miss the message even if you're hurrying out the door to get home.

Jon Jagger

Lack of visible progress is synonymous with lack of progress. [...] It's best to develop software with plenty of regular visible evidence. Visibility gives confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental.

Linda Rising

[...] in all the years I've taught and worked side by side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult, the solutions should be just as difficult for everyone.

Giles Colborne

Another way of avoiding formatting errors is to offer cues--for instance, with a label within the field showing the desired format ("DD/MM/YYYY").

[...] Cues are different from instructions: cues tend to be hints; instructions are verbose. Cues occur at the point of interaction; instructions appear before the point of interaction. Cues provide context; instructions dictate use. In general, instructions are ineffective at preventing error.

Uncle Bob

A professional programmer does not pass that responsibility off on others.

[Professionals] take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right.

Alex Miller

When I was first placed in a technical leadership role, I felt that my job was to protect my beautiful software from the ridiculous stream of demands coming from product managers and business analysts. I started most conversations seeing a request as something to defeat, not something to grant.

At some point, I had an epiphany that maybe there was a different way to work that merely involved shifting my perspective from starting at no to starting at yes. In fact, I've come to believe that starting from yes is actually an essential part of being a technical leader.

Wednesday, March 10, 2010

gem 1.3.6, Ruby 1.9 and FreeBSD

Кстати о rubygems. Для несчастных владельцев gem'ов, кои требуется тихо класть на rubygems.org, версия gem, которая идет в комплекте с ruby 1.9.1 лишена команды push. А без нее

% gem push pkg/глюкало-0.1.3.gem

не скажешь. Чтобы эта счастье там появилось, требуется обновить rubygems командочкой gem update --system. Это все не является тайной, но выполнивши указанную командочку под FreeBSD и набрав gem list, мы получим:

*** LOCAL GEMS ***

(пустой список)

Караул! Куда делись все мои инсталлированные gems?

В начале этого года в freebsd-ruby мяли неверность gem path выглядевшую как /usr/local/lib/ruby19/gems/1.9. В порту появился патч, исправлявший ее на "правильную" /usr/local/lib/ruby/gems/1.9. После ручного обновления rubygems, gem path снова сбрасывается на кривую /usr/local/lib/ruby19/gems/1.9. Именно ее пытается прочесть новая версия и, конечно, не находит там ни единого установленного gem'а.

То есть, чтобы направить rubygems на истинный путь, вам придется руками подредактировать файл /usr/local/lib/ruby/site_ruby/1.9/rubygems/defaults.rb. Патч:

--- defaults.rb.orig  2010-03-01 14:13:23.000000000 +0200
+++ defaults.rb       2010-03-01 14:13:38.000000000 +0200
@@ -20,10 +20,6 @@
         if defined? RUBY_FRAMEWORK_VERSION then
               File.join File.dirname(ConfigMap[:sitedir]), 'Gems',
                                 ConfigMap[:ruby_version]
-    # 1.9.2dev reverted to 1.8 style path
-    elsif RUBY_VERSION > '1.9' and RUBY_VERSION < '1.9.2' then
-      File.join(ConfigMap[:libdir], ConfigMap[:ruby_install_name], 'gems',
-                ConfigMap[:ruby_version])
         else
               File.join(ConfigMap[:libdir], ruby_engine, 'gems',
                                 ConfigMap[:ruby_version])

Теперь наберите:

% gem env | grep -A2 PATH

и убедитесь что все работает как надо.

podgraph

If you are like me--a person who hates to fire up wysiwyg editors (or even worse--an editor in a browser) to make a blog post, then you may like a tiny Ruby program called podgraph.

It parses an XHTML file and creates a proper MIME mail from it. "Proper" means that if you have included some local images in your html, they will be encoded and bundled with the mail as inline images (see RFC2387).

After creating the mail, podgraph can automatically send it somewhere, probably to your mail-to-blog gateway.

To install podgraph 0.0.1, make sure that you have Ruby 1.9 on your machine and type as root:

# gem install podgraph

For the help, type:

% ri Podgraph

History

As starting a brand new blog at posterous.com, I came up with an old problem: how to post to <my lousy blog> from Emacs? There is no working posterous client for Emacs (at least I don't know any), but thank g-d we can use just html emails for simulating that.

A long time ago before joining to Ruby camp, I fell in love with python's reStructuredText. It gives me an ability not to struggle with damn html tags but to write blog posts in (more or less) human readable text and then convert it to lame html.

So, at the present time any posting to posterous looks like this:

  1. Editing (in Emacs) file.rest.

  2. Typing gmake in the directory with file.rest. Makefile:

    PODGRAPH := ~/lib/software/alex/podgraph/trunk/bin/podgraph
    #PODGRAPH := podgraph
    
    .PHONY : clean html
    
    XHTML := $(addsuffix .html,$(basename $(wildcard *.rest)))
    
    all: html
    
    .SUFFIXES: .rest .html .sent
    
    .rest.html:
       rst2html -o koi8-r < $< > $@
    
    .html.sent:
       $(PODGRAPH) $<
       touch $@
    
    html: $(XHTML)
    
    clean:
       rm -f *.html
    

    Which brings to me file.html.

  3. Previewing in the browser the result: firefox3 file.html.

  4. Typing gmake file.sent--and podgraph suddenly creates the MIME mail and delivers it to posterous.

Btw, the whole process tested only on FreeBSD. I don't see any possible Linux quirks here, but if you'll find some, don't forget to tell me.