Michal Hantl

Sepsal jsem svůj pohled na to, co dělá člověka programátorem. Je to napsáno v pořadí od základních dovedností po ty “méně obvyklé”.

Rád si počtu, jaký je váš názor, nebo v jakém pořadí a které schopnosti jste si osvojili vy. Napsal jsem to rychle, takže pokud najdete chybu, opravím.

- schopnost vyjadřovat algoritmy v programovacím jazyce
    - zkušenosti s řešením "podobných" problémů v daném jazyce
    - zkušenosti s řešením "podobných" problémů v nějakém jazyce

- debugování
    - uvědomovat si, jaké mohou nastat případy exekuce,
      které vedou k nesprávnému chodu = logické uvažování a hodně zkušeností

    - být schopen nějakým způsobem ověřit co kód dělá a najít bug
      = používat breakpointy, nebo průběžné výpisy během exekuce k nalezení bugu

- schopnost minimálního ovládání objektů
    - zkušenosti s řešením "podobných" problémů pomocí objektů v daném jazyce
    - zkušenosti s řešením "podobných" problémů pomocí objektů v nějakém jazyce

- číst knihy o programování

- programovací cyklus
    - TDD, BDD
    - primitivní naprogramuj / zkontroluj cyklus

- proces
    - umět dodržovat vybraný proces programování - agilní, racionální, ..

- mistrovství programování: schopnost opravdového objektového programování
    - znát design patterns a umět je aplikovat
      = zkušenosti => vidět design patterns
    - znát postup refactoringu po částech pomocí testů, nebo bez nich
    - znát a umět aplikovat PrinciplesOfOod ("SOLID" principles)

SRP	The Single Responsibility Principle
	A class should have one, and only one, reason to change.

OCP	The Open Closed Principle
	You should be able to extend a classes behavior, without modifying it.

LSP	The Liskov Substitution Principle
	Derived classes must be substitutable for their base classes.

DIP	The Dependency Inversion Principle
	Depend on abstractions, not on concretions.

ISP	The Interface Segregation Principle
	Make fine grained interfaces that are client specific.

- nekonečný úděl programátora
    - učit programovat ostatní
    - řešit neobvyklé úlohy
    - neustále se něco učit

Možná jste si všimli, že tu chybí “chodit do práce”, nebo “přispívat k open source projektu”. Jednak se to mírně předpokládá a pak se to mírně rozpouští v některých již popsaných dovednostech. Šlo mi především o vyjmenování skillů, které je si třeba osvojit.

Za komentáře předem děkuju.

It it possible to run jetty from JRuby and plug your Rack app into jetty through JRack.

You will need some jars (jruby, jetty, jsdk) and following code.

Whats awesome is that i can then reload my app every request and not even have to restart the server.

Thanks to Nick Sieger and original poster of the solution for rails http://www.trampolinesystems.com/blog/machines/2008/11/27/rails-22-jruby-jetty-win/

Writing test for lost code is a great way of thinking about writing tests. Thinking this way helped me to improve the value of my tests significantly.

Here is how i got the idea:
I was writing class to write some stuff to disk based on folder and filename.

class FileStorage
  def write file
    #create folder on disk for file
    #write file on disk
  end
end

I also wanted similar class for doing it into memory (hashtable).

class HashStorage
  def write file
    #create hash container
    #set propper value
  end
end

I quickly realized: “Hey! I can use the thest i wrote for filestorage to write this new HashStorage!” I wanted it to do the same thing so why not reuse the test i had? Sounds like a good idea.

So i began writing the new HashStorage when i realized that the test wasnt as good as i expected

• For some tests i needed to do more work, than just small amount.
• The order of tests as they go in the source code didnt match the order of steps needed to be taken in order to implement the same behaviour in new class being written.
• The test depended on knowing some details about the implementation of the first class, not just interface.

Those are very very serious flaws, that one should avoid in normal TDD. But I didnt see the problem before i started reimplementing the behaviour. I thought my tests were okat because they passed and tested the behaviour of each method.

While doing TDD or testing in general. Write the tests in such way that in case of your code gets lost, you can reimplement it all quickly.

This has a huge impact.

Let me explain the the flaws and how to avoid them in examples.

For some tests i needed to do more work, than just small amount.

When some test methods take long time to implement, they need to be broken down. The time between the last green and the next green makes a great difference. As with each of the steps you know you are on the right path and motivated.

When you have a test that is not fine grained, it takes longer to implement the same behaviour. You need to keep more stuff in your head at once, so you make mistakes. And the worst part is: when the test is red, you don’t know exactlyu which part of the code doesnt work. Because the test method just tests the output for given input and there is stuff in between that needs to be tested too.

The order of tests in code is not the order in which you implement the solution

Look at the code. The test methods should be arranged in such way that you can implement your cat by fullfilling one test after another. (When you loose your cat’s source code)

class MySuperCatTest < Test
  def test_bring_shoes
   #...
  end

  def test_walk
   #...
  end
end

But here we test bringing the shoes before we even know that the cat can walk!

You may not lose your cat’s source code, but there will be time when you read the test again and having implementation-wise chronology is a time saver.

The test depended on knowing some details about the implementation of the first class, not just interface.

This really makes life a draaaag. I don’t think thats riiight.

When i was implementing HashStorage, i immediately saw then i cannot get away with File.exists? in my tests. This was not obvious before to me. But here the test knows too much about the implementation.

The solution to this was to realize that the FileStorage should tell me if the file exists, or not. After i rewrote the test to ask FileStorage if the file exists and such i could use this test to test two different implementation of the same behaviour whis is really cool.

So whats new about this technique? Nothing. We are told from the start that

The test should be

• free from the details about the implemetation
• fine graded
• in order of implementation (in TDD)

The hard thing is to really see where i crossed the line or not. Having a metaphore that i should write the tests so i can reimplement the implementation if the source gets lost clearly shows me, where the line each principle lies.

Thank you and please share your thoughts.

I’ve been using GWT for some time now and here is my GWT to Javascript comparison.

JavaScript + your favourite library

+ In JS I don't type so much.
+ There is no compilation time.
- Source code management done by hand.
+ Ninja style programming.
- I might not like other ninjas' code.
- No standard library.

Java + Google Web Toolkit

+ With Java i learned to type faster.
+ There are no compilation errors (with eclipse).
+ You dont need to compile if youre okay with using IE as your browser.
+ One file per class, automatic inclusion of code into html.
+ Automatic code minimalization (can be turned off).
+ Common set of Java practices.
++ Automatic refactoring (with eclipse).
+ Ported classes from java to rescue.
+++ Can use client code on server if using google appengine.

If you are making a JavaScript heavy app, use GWT

I love JavaScript, but this is obvious. GWT gives you awesome power and the tools you need.

Be sure to give yourself time to adjust to GWT and Java style programming. Keep yourself happy, get slowly used to compilation and be sure that the reward for learning this technology is worth it.

After a week of learning GWT I had a small crysis. In next two days all I learned sucked to me and now I am comfortable developing in GWT. Its a change from all the scripting i’ve done and every change needs time.