My Hardest Lesson

I’m developer first. I write code. This is what I love.

This blog post is however about something different. It’s about a thing I am doing in parallel. It does not take too much of my time, and yet is the thing I am the most proud of: people management. And about hardest lesson I learned:

People management is just communication

Being a good manager is about asking right questions. You ask customer (your boss, higher-up manager):

• What do you need?
• Why do you need that?
• What are your priorities?
• Is this new thing more important than what we are doing right now?

You get answers and tell them to your developers:

• Our customer needs this:…
• The rationale behind this is:…
• Current priorities are:…

Now it’s time to ask developers:

• What is your opinion on this? Do you have better idea?
• Are you willing to do that?
• How long will it take?
• Do you have enough free time?

Then you go back with those answers to customer. There is little more to managing people, mostly trust and teaching.

Full control is overrated.

Aspects in Ioke

My recent hobby project (dnd - a console-based TODO list) is written in Ioke. I am surprised how easy is to learn Ioke and how fast it is possible to achieve great results in this language. The problem is that it's so powerful, it's easy to get out of chosen path and end up in bushes without even noticing.

This problem is especially important now, when I'm exploring the language - and most of the code I write changes too fast to be easily harnessed by tests. Without tests in the picture I must rely on simple println to actually see where I'm going.

Adding print statements throughout the code is boring and cumbersome and I'm a lazy person. Ioke has great support for aspects so why not use that?

The best way to see where the program is going is to inspect what cells are called and what do they return. Ioke provides pointcuts for those two events, you can create and add methods to them using before and after methods available on all objects.

When you want to log method call you write something similar to:

object before(matching: :anyFromSelf) << macro("called #{call receiver}:#{call message name}(#{call arguments})" println)

Similar, when you want to log method's return you use after

object after(matching: :anyFromSelf) << macro("returned #{aspectResult asText}" println)

This is all nice but a more useful thing is an Object that wraps everything nicely and provides simple call graph:

CallInspector = Origin mimic do(
  nesting = 0

  entering = lecrox(
    "#{"| " * nesting}+called #{call receiver}:#{call message name}(#{call arguments})" println
    nesting ++
  )

  leaving = lecrox(
    nesting --
    "#{"| " * nesting}\\returned #{aspectResult asText truncate}" println
  )
  
  instrument = method(+objects,
    objects each(object,
      object before(matching: :anyFromSelf) << entering
      object after(matching: :anyFromSelf) << leaving
    )
  )
)

You can use it in your code with:

CallInspector instrument(YourObject, AndAnother)

The most recent version of CallInspector is available on gist.

Praca: Programista Ruby on Rails

Poszukujemy doświadczonego programisty Ruby on Rails.

Wymagamy doskonałej znajomości

• Ruby oraz Ruby on Rails,
• języka angielskiego,
• BDD (ew. TDD)
• git,
• semantycznego XHTML,
• Linux/Unix

Mile widziane

• znajomość CSS
• znajomość Haml
• doświadczenie w projektach Open Source, najchętniej bazujących na RoR

Warunki zatrudnienia

• faktura lub umowa zlecenia
• dowolne godziny pracy
• profesjonalny zespół
• praca zdalna
• wymagamy ok. 160h pracy w miesiącu

Płaca

Do negocjacji, zależna od umiejętności, pomiędzy 30 a 50 PLN/h

Rekrutacja

Napisz krótki e-mail i dołącz CV (wraz z odpowiednią klauzulą, patrz niżej)

Podstawą do rozmowy będzie jakość kodu. Przygotuj próbki swojego kodu wraz z testami. Najlepiej jeśli będzie to opublikowany kod OSS. Jeśli nie posiadasz takiego, wybierz istniejący projekt OSS bazujący na Ruby/RSpec. W nim zaimplementuj nową funkcjonlaność lub popraw istniejący błąd w oparciu o BDD.

Chętnie pomożemy Ci zarówno w wyborze projektu jak i konkretnego sposobu rozwiązania problemu.

CV powinno zawierać klauzulę: Wyrażam zgodę na przetwarzanie moich danych osobowych zawartych w mojej ofercie pracy dla potrzeb niezbędnych do realizacji procesu rekrutacji zgodnie z Ustawą z dnia 29.08.1997r. o ochronie danych osobowych

Kontakt

• email: rekrutacja@ragnarson.com
• jabber: bragi@ragnarson.com

Enterprisey

Does look familiar to you?

I would rather be watching forrest

...I mean, I'd rather be writing my specs.

Look how smart I am!

Update: Original problem was solved with hirb. Good job Gabriel!

Recently I was analysing data on production server. Problem domain I worked with is quite complex and consists of several different models. Rails provides great tools to easily cherry-pick interesting data using named_scope, conditions, includes, through. I ended up with a list of records I wanted to inspect.

I worked using console, through screen. List was too long to use 'pp', scrolling with screen is also not too great. What I needed was a simple table with a few columns (and not full list of model's properties). Something among the lines of:

+----+----------------+-------+-------------+
| id | job_posting_id | state | published_at|
+----+----------------+-------+-------------+
| 1  | 20             | del   | 2008-01-01  |
| 2  | 23             | del   | 2008-01-01  |
| ...| 24             | act   | 2008-01-01  |
+----+----------------+-------+-------------+

Recently I have noticed Ruport which at glance looked like a perfect tool for a job. But it wasn't.

After a few hours of skimming through examples, documentation, and even a book (now free as in beer! - recon that) I failed to find a single concise example of how can I achieve my goal.

Rather, Ruport authors assume that you will be willing to use their CSV loading code, or maybe their acts_as_reportable plugin and surely rewrite half of your application, including record selecting logic, possibly ignoring any goodies Rails provides in this area.

Now do not get me wrong. I'm not saying that Ruport is a bad software. I actually have no idea if it's good or bad. But it does not provide quick solution for the simplest case possible.

Both documentation and API focus on how great Ruport is and how great it manages your reports. It fails to show how Ruport can easily aid you in your daily tasks.

It's a perfect example of Ruport's authors 'Look how smart I am' approach. Personally I prefer to use software which is written in 'Look how easy it is' manner.

Update: While looking for solution to my problem I encountered official ruport discussion group. To post there you need to apply for membership, which I did. After two days my admission was rejected... Good job in helping your users, guys!