Dmitry Ishkov

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 class Mock def initialize(method_name, block = nil ) block||=Proc.new do |*args| args=args.first if args.length==1 yield(args) end self.class.send :define_method, method_name, block end end Examples class TestMock The problem with other mock libraries is that there's too much magic going on and syntax is tricky mock.expect :method, 'return', [:params] ... mock.verify # 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...

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 u...

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 you...