30 September 2013

Flexible Mock

Hey, I've been posting too many abstract shit lately, how about some code?

So here's my simple Mock class and tests for it (to show how it works).


class Mock
  def initialize(method_name, block = nil )
    block||=Proc.new do |*args|
      args=args.first if args.length==1
    self.class.send :define_method, method_name, block


class TestMock < MiniTest::Unit::TestCase
  def test_mock
    fake = Mock.new :some_method do
    assert fake.some_method == 'value'

  def test_mock_single_parameter
    fake = Mock.new :some_method do |p|
    assert_equal fake.some_method(2),  4

  def test_mock_many_parameters
    fake = Mock.new :some_method do |p1, p2, p3|
    assert_equal fake.some_method(2, 3, 4), 24

  def test_lambda_parameter
    fake = Mock.new :some_method, lambda {|p| p*2}
    assert_equal fake.some_method(2), 4

  def test_access_to_local_variable
    fake = Mock.new :some_method do
    assert_equal p1, 2

The problem with other mock libraries is that there's too much magic going on and syntax is tricky

    mock.expect :method, 'return', [:params]
    # or
    mock.should_receive(:method).with("A", 1, 3).once
In more complex examples it gets hard to express what you want and remember syntax. I prefer more control, that's why my decision is to create object with custom method. In this method you can do whatever you want.

Another good thing of this approach is property of Proc to maintain context where it was called (look at the last example). This eliminates any need for internal verification via "mock.verify" since you can do it outside.

p.s. syntax highlighting I used can be found at github: highlight.js

26 September 2013

Thoughts on programming podcasts

Do you remember any movies or pictures about the "Gold Rush" in America? When thinking about getting knowledge today I imagine exactly that: a man with a sieve filtering out a lot of dirt just to find a tiny golden nugget. It's not like there is a website where you can go and read all the facts that YOU don't know but should. Acquiring knowledge is a work of going through a lot of information and finding missing parts for your puzzle. I probably sound like an obsessed person but that's because I am obsessed.

Today I going to talk about one such dirt-gold source, namely podcasts. I've been listening to a lot of these lately and, honestly, 95% is useless crap:

  • things that you do know
  • things that you don't need to know
  • things that you aren't ready to know

But every now and then you stumble upon something brilliant so a 5% that's left make all the difference. Following suggestions will help you to get the maximum out of it:
There's no use if you aren't paying attention, so save them for "activities" like waiting in line for a doctor, public transport, driving, cooking and etc.
You should make notes of what you've learned. It has the following benefits:

  1. the very activity of trying to summarize information makes you understand it better;
  2. I find it motivating when you can go back and look at the gist you've written;
  3. retrieving information from your memory noticeably facilitates further memory consolidaton.

Finally I will throw some podcasts I listened to:

  1. Changelog - news and discussions on hot topics
  2. Coderpath - stories about programming life
  3. Giant robots smashing into other gians robots - not particulary useful, but fun
  4. InfoQ - not really a podcast because often it's hard to follow idea without provided PDF slides by hand. Otherwise really good website, covers lot of topics
  5. JavaPosse - topic titles sound good, but terrible audio quality
  6. Pragmatic bookshelf - authors about their books
  7. Ruby Rogues - my favourite, best podcast on Ruby
  8. RubyShow - dense with useful info
  9. Ruby5 - short news
  10. SE Radio - very different topics, more enterprise than agile focused
  11. The Dev Show - fuuuuun
ps sorry but I really suck at placing commas in English =(

25 September 2013

Software construction == fighting bugs

This summer during obligatory in Russia military training I've read the famous Code Complete book by Steve McConnel.

Most of the information was either already known to me or somewhat outdated. But after I turned over the last 900th page and closed the book I felt the "Aha!" moment.

Most of the practices you do during software construction are aimed at the eliminating bugs and mistakes: code reviews, pre requirements, planning, refactoring, pair programming, testing and in a way even comments.

Let's be honest: building stuff from the blank page is easy, not willing to throw away the project after half a year behind you and a ton of bugs atop of you IS hard.

That is why TDD is very practical. At first having to write that extra code feels like a pain in the butt, but the amount of time you save later on debugging is golden.

Software project just like many other things isn't a sprint, it's a... camping, so take time to put goodies in your backpack, you have a long journey ahead of you.