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 < MiniTest::Unit::TestCase def test_mock fake = Mock.new :some_method do 'value' end assert fake.some_method == 'value' end def test_mock_single_parameter fake = Mock.new :some_method do |p| p*2 end assert_equal fake.some_method(2), 4 end def test_mock_many_parameters fake = Mock.new :some_method do |p1, p2, p3| p1*p2*p3 end assert_equal fake.some_method(2, 3, 4), 24 end def test_lambda_parameter fake = Mock.new :some_method, lambda {|p| p*2} assert_equal fake.some_method(2), 4

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

From time to time I feel like a web crawler. So here's all the resources I've found, by categories. Today it's Ruby. Here we go... API: apidock.com ruby-doc.org api.rubyonrails.org Guides and tutorials: guides.rubyonrails.org sitepoint.com/ruby net.tutsplus.com/category/tutorials/ruby tutorialspoint.com/ruby-on-rails outdated Interactive tutorials: codeschool.com/paths/ruby rubymonk.com codecademy.com/tracks/ruby Screencasts: railscasts.com asciicasts.com destroyallsoftware.com/screencasts peepcode.com/screencasts rubytapas.com Quizzes: rubykoans.com codequizzes.com puzzlenode.com projecteuler.net codekata.pragprog.com Podcasts: rubyrogues.com/episode-guide learn.thoughtbot.com/giantrobots rubyshow.com/episodes ruby5.envylabs.com/episodes 5by5.tv/changelog The Freelance show Online courses: edx.org/course/uc-berkeley/cs-169-1x/software-service/993 edx.org/course/uc-berkeley/cs-169-2x/software-service/1005 Talks: con

If you do testing, then, like me, at one time you probably came up with a question "How do I test private methods?" . The tricky part about private testing in static languages like java, is that you can't access private methods from outside. There are couple of ways to test private methods. You can do it through reflection, you can easily find libraries which ease the syntactic pain. Or you can make it package-private, this way you can use them in your tests, but users of your library still can't see it (though it can turn your own package into a tangled mess). And both things are WRONG! And many people know it. Go to stack overflow and you will see lot of upvoted results, how it is "implementation detail, don't test it". In my opinion, you should test this kind of methods. If you closed your IDE/Editor of choice and opened Google, then chances are it's important enough to have a unit test. Do you smell it? I certainly do... And it's comi

Ok, I've had this on my mind and up my ass for some time. Today around you there's too many technologies, programming languages and frameworks! I remember my school days and passion about Pascal and Delphi, all the assignments in information technology class, the way I would optimize these little quizzes... A lot of great memories. But then I went to university, got familiar with C#, and things started boggling me. Is it used in real life apps? What's beyond C#? Where can I find work and what skills do I need? And really at that time for there was no answer to the question "What do I do next?" . And so my mind kind of stranded off programming. University classes were useless and had not a single hint of real life applicability. So there's was no use in studying hard. All I did is studied just enough pass next exam and then play computer games and football. However, as I got lazy and dispassionate, another thing really have blossomed - The Internet!

Greetings, guys and gals (who am I kidding?) , guess what, now I have a blog! As of now now it looks kind of ugly and... empty. But it seems you can fully customize it (even javascript). On the other hand I'm too lazy and empty is good. There's Russian saying: "Conciseness is a sister of talent" ...on this note this post shall end .