Archive for August, 2010

First Impressions Of The Ruby Community

48 commentsWritten on August 31st, 2010 by
Categories: Opinions, Ruby

It's been about 3 weeks since i've started my Ruby journey. Obviously, i still have a lot to learn. And in order to keep learning, i'm subscribing to more Ruby-related blogs and i'm starting to follow more Ruby-related folks on Twitter. At the same time, i'm gradually unsubscribing from a lot of .NET blogs and have even un-followed some people on Twitter that i only followed for .NET related stuff.

The biggest difference that i've noticed so far is that the Ruby community is pretty much a lot like what the ALT.NET community always wanted to be. As far as i can tell so far, knowledge is being shared all the time. And this is generally done in good spirits without negativity or flamewars (save a few exceptions obviously). People genuinely seem to care about helping other people out and making sure that everyone improves. I privately contacted a few Ruby people out of the blue. They don't know me, and i didn't know them. I just happened to stumble upon their blogs or twitter profiles and i figured "what the hell... i'll just bother them with some questions". And you know what? Every single one of them has responded in a remarkably friendly way.

When i asked them about interesting resources to follow as a newbie Rubyist, they all gladly shared their suggestions. When i thanked them for it, they all replied stating that i should feel free to contact them if i had any more questions about whatever Ruby related. Seriously, can you imagine the few .NET heroes that we have responding to questions through email from people they don't even know like that? I can't. Hell, i know most of them don't respond like that. The few that do are still trying to earn their MVP award or are too worried about renewing their MVP status.

Now, i'm not saying that all is well in the Ruby/Rails world and that there are no arguments or that there isn't any negativity or anything like that. Because the negativity and the arguments are definitely there. The thing is, it just seems to happen at a much lower frequency than it does in the .NET world. Granted, the .NET world is probably one of the most unfriendliest of all but still, the difference is striking IMO.

A part of me hopes that i'm wrong about this and that in the end, there isn't really a substantial difference between the ruby community and the (previously ALT).NET community. Then again, another part of me hopes that what i'm seeing so far is indeed true and real. If only because that would mean that what i consider to be the ideal developer community indeed exists somewhere.

To summarize the difference: i'm sure some of you remember the infamous "Rails Is A Ghetto"-rant. Well, from what i can tell so far... if Ruby/Rails is a ghetto, then .NET is the trailer park.

Book Review: The Ruby Way, Second Edition

8 commentsWritten on August 31st, 2010 by
Categories: Books

The second book i read in my ongoing Ruby journey is the second edition of The Ruby Way. While i don't think it's as essential as The Ruby Programming Language (you can read my review of it here), it is a very useful resource to the beginning Ruby programmer. As good as it is, it certainly has a lot of flaws as well.

At over 800 pages, this book is obviously big and heavy. That in itself is not necessarily a problem, but i wasn't happy with the actual binding of the pages. Flipping through them just doesn't feel right and i often felt that i had to be somewhat careful with a page if i didn't want it to be torn out of the book by accident. And it really wouldn't take that much effort for that to happen. If there is one book that's an ideal test case to make you seriously consider switching to an iPad/Kindle for your reading, then this is probably it.

Luckily, the content of the book does make up for the shoddy physical reading experience. This book covers a lot of topics, which is not only a great way to introduce the beginning Ruby programmer to a variety of possibilities, but also a welcome reference to keep on your desk if you quickly need to look up how to do something. It starts off with a short review of the Ruby language, and then works its way through a variety of topics, most of which are covered very thoroughly. You really will learn everything there is to know about strings, regular expressions, numeric types, symbols, ranges, dates and times and enumerable types (arrays, hashes, sets, ...). At this point, you're about 320 pages into the book with another 450 or so to go. Those first 9 chapters are probably also the only part of the book that will at one point be read by everyone who bought this book, either while reading cover-to-cover or when you're looking for something specific later on.

The next topic that is covered is that of IO and Data Storage. Again, this is covered pretty extensively because you'll learn all about typical file management operations, as well as how to do marshaling of objects. There's also a brief part on dealing with databases but it's so short that it really would've been better left out altogether. You'll see how to connect and interact with a few of the well known databases in a pretty low-level manner, but really though, hardly anyone still deals with databases in that way. It probably would've been better to point to some higher-level data access frameworks, since the people who are going to deal with a database in such a low-level manner are probably more than capable of figuring out how to do so without referring to a book that only briefly lists a few things that you can do for basic stuff, but nothing important.

The next chapter covers Ruby's OOP and Dynamic features/capabilities and it's a good 80 pages long. It goes through some of the topics a bit too quickly for my taste, but that's alright since the next book on my reading list is Metaprogramming Ruby which is sure to whet my appetite for dynamic goodness. It does again cover quite a lot, but if you've read The Ruby Programming Language already, you won't really find anything new here.

Next up is an overview of some of the graphical toolkits that you can use with Ruby. This is a chapter that ultimately doesn't bring any value since coverage of a single toolkit is probably enough to fill an entire book already. The examples shown for each of the toolkits in this chapter are obviously short and offer no more than a quick look at how you'd interact with a certain toolkit. Well, in my case it inspired me to come up with a decent event syntax for Ruby, but that's about it. It probably would've been better to leave this chapter out, and just refer to these toolkits in an appendix or something.

The book then switches to a topic that i'd been looking forward to: Threading. While Ruby does offer some constructs to deal with threading, it's a far cry from what you might be used to in .NET. I was also surprised with the lack of attention paid to asynchronous operations, but then again, there just might not be that much interest in asynchronous programming in the Ruby world. This is definitely something i need to look into more as i continue on my Ruby journey :) . Another downside to this chapter is that some of the examples are a bit simplistic, and in some cases, aren't quite thread-safe. If you read this chapter, focus on the discussion of what you can do with Ruby from a threading point of view, but please don't reuse any of the code in your own code because you will end up chasing race conditions because of it.

The next 2 chapters deal with scripting, system administration and working with certain data formats (xml, rss, images, pdf). Depending on what you need or what you're working on, this could be pretty interesting to you. The book then switches to the topics of testing and debugging. This isn't really covered in-depth and as such, this too would've been better suited for an appendix with some links to online resources or dedicated books on these subjects. After that it gives another quick overview of packaging and distributing your code. This chapter also would've been better off being dropped since i had to package and distribute some Ruby code today and i found more useful and relevant information online than i did here.

The book then starts focusing on writing code again, but this time in the online world. First you'll learn about low-level network programming in a chapter that is dedicated to the topic. After that, there's a chapter about Ruby and webdevelopment and it kinda suffers from the same problems as the GUI toolkits chapter did. It lists a few of the options, of which at this point only Rails still seems to be popular but it can't really tell you anything in-depth about it. Once again, a summarized version of this chapter would've been better fit for an appendix. Finally, you'll learn about Distributed Ruby which is illustrated with an example.

The book then closes with 2 more chapters, one covering some Ruby development tools, and finally, some words on the Ruby community.

This is by far the longest book review i've ever written, but then again, this book is huge and i did have a lot to say about it. Its biggest flaw (apart from the shoddy physical reading experience) is that it tries to cover too much, and because of that, a lot of the stuff that is covered is basically pointless. Ideally, this book would've been limited to the first 11 chapters, followed by the chapters on threading and networking. The stuff about databases, web frameworks, GUI toolkits, etc... should've been covered in succinct appendices which should just point the reader in the right direction since there's no way one single book can cover all of it anyway.

I know this review might come over as hard on the author and the content, but i really did like half of the book a lot. The other half however prevents me from starting this post with 'Recommended Book' or 'Highly Recommended Book' instead of 'Book Review'. Hopefully, the upcoming 3rd edition (which should be out sometime next year) fixes some of these flaws so this book can reach the potential that it certainly does have. In the meantime, i will keep this book on my desk as a reference. About 500 of these 800 pages do contain a lot of great stuff that's gonna save me a lot of time after all.

Why Agile In The Enterprise Generally Doesn’t Work

13 commentsWritten on August 29th, 2010 by
Categories: Opinions, work/career

I just came across the Manifesto for Half-Arsed Agile Software Development thanks to the wonderful world of Twitter. I'm gonna shamefully copy the text of the manifesto from the original website:

Manifesto for Half-Arsed Agile Software Development

We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value:

Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation as long as that software is comprehensively documented

Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely

That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right.

As funny as this is, it's really quite sad as well. I don't think i'm going out on a limb here if i say that the large majority of us have seen and experienced this with a striking similarity. And i think i know why. I've only spent time in two 'enterprise' companies but from what i've heard from a variety of people, it's pretty much the same deal in most of them. Simply put: the typical enterprise culture leads to widespread incompetence, the majority of which is hidden from higher levels of management which eventually results in an environment where it is virtually impossible to work in an efficient manner. Whoa, i kinda dropped a bomb there didn't i? Allow me to explain why i believe the above statement to be true.

I believe the root cause of all of the typical problems in the enterprise world to be the Peter Principle. In the enterprise world, a large group of employees is typically interested in climbing the corporate ladder. Some of them will get promoted because they did a great job. If they do a great job in their new position, they might be promoted again. Eventually, most people will end up in positions at which they perform at a level that is no longer good enough to ever be promoted again. Quite (very?) frequently, those people produced more overall value for the company in their previous position than they do in their current position. Unfortunately, none of them (save the occasional exception) will ever go back to that previous position. As good as those people were in their previous positions, they are simply incompetent for the job they're currently doing.

Not only is it bad enough that you've got a lot of people who are too incompetent to do their job to a satisfactory level, you have to keep their superiors in mind as well. After all, they are the ones who promoted them. And they have superiors too. And you can safely assume that very few of them will be willing to own up their mistake in judgment to their superiors. That is, if they even realize that they made a mistake. Either way, either the incompetence is not noticed (which only points to more incompetence one level up) or it is actively hidden. Brushed under the carpet for nobody to notice. Obviously, that can't be good for the quality of the work that is supposed to be done at every level of the hierarchy below this one. Problems will show up in pretty much everything that gets done by the lower levels. Rules, policies and guidelines are put in place to combat these problems and to try to keep the situation under control.

This in turn leads to decreased motivation, which is especially deadly for those who do have the skills and talent to right a lot of wrongs. You're either losing time and efficiency because of people who no longer care, or because of people who simply can't do what they're supposed to do. Some will persevere, only to be promoted until they too are part of the problem. And the others will leave and prefer to work for smaller companies where everything seems to go "a lot smoother and easier".

With that in mind, go over the manifesto again and ask yourself the following question: how could it possibly work in such an environment?

‘eventpublisher’ Gem Now Available

No Comments »Written on August 28th, 2010 by
Categories: Ruby

For those of you liked the EventPublisher module that i've been talking about recently, it's now available as a gem. The code is hosted on github under the MIT license and you can download/install it with the following command:

gem install eventpublisher

After that, you just need to add the following to your ruby files in order to use it:

require 'eventpublisher'

Compiler|Interpreter Warnings Are Important Learning Opportunities

5 commentsWritten on August 28th, 2010 by
Categories: Code Quality

When i first started to write C# code, i payed a lot of attention to compiler warnings. I wanted to avoid them at all costs. And with that i don't mean suppressing them, but preventing them from being issued in the first place. I learned quite a few things from actually trying to understand why a certain compiler warning was issued, instead of just ignoring it like so many other developers do. In fact, when it comes to C#, i'd recommend turning on the Treat Warnings As Errors option on each project since i've never come across a C# compiler warning that you couldn't avoid. And in practically every single case, avoiding the warning led to better code. When writing C#, i've never seen a single warning that was pointless. There might be a few esoteric ones that aren't worth fixing, but the vast majority of us will never run into those. So do yourself a favor: if you get a compiler warning, make sure you understand why the warning was issued, and fix your code based on what you just learned while researching the warning. There simply is no reason not to do so, unless you happen to bump into the few cases where it really doesn't matter but those cases will be far and between. In fact, i'd bet that only people like Ayende will run into them while us mortals never will.

So, how do i feel about warnings in the context of my ongoing Ruby journey? I have so little experience with Ruby that i can't state that every single warning should be avoided. But i am of the opinion that you should at least be aware of every warning, and investigate whether or not you should modify your code to avoid it. Today i wrote my first Rakefile which automatically runs all of my RSpec tests for my EventPublisher module and one of the options of the SpecTask was to enable warnings from the Ruby interpreter. I was actually surprised that i hadn't yet ran my Ruby code with warnings turned on. Maybe i was just too busy being impressed with the whole Ruby + TextMate package. Anyways, i turned on the warnings, ran 'rake' and watched a few warnings show up, much to my disappointment. Well, i was disappointed at first because i thought the code was in good shape but then i figured "ok, this is no big deal... i just gotta fix my code and i'll learn from it". And i did learn from it. The first one was a simple RSpec assertion that i wrote which looked like this:

    it "should know about the subscribed method for the correct event" do
        @publisher.subscribe :first_event, method(:first_event_handler)
        subscribed = @publisher.subscribed? :first_event, method(:first_event_handler)
        subscribed.should == true
    end

This generated the following warning: warning: useless use of == in void context

I looked into it, and learned that when using RSpec, the last line should've been written like this:

        subscribed.should be_true

You're probably thinking "now that's a tiny difference and not really worth it". And you'd be wrong. While the resulting modification in code is indeed minor, i learned about RSpec's Matchers and how they work. And that knowledge is gonna help me in future code.

I also had the following piece of a code:

            define_method getter do
                event = instance_variable_get variable

                if event == nil
                    event = Event.new(symbol.to_s)
                    instance_variable_set variable, event
                end

                event
            end

When i wrote it and saw that it worked, i was pretty happy. But it turns out that this code causes the interpreter to issue the following warning:

warning: instance variable @first_event not initialized

In this case, @first_event was the value of the 'variable' variable, which is why the warning looks like that when the code is actually executed. So again, i looked into it, and learned that i should've written that code like this:

            define_method getter do
                if !instance_variable_defined? variable
                    event = Event.new(symbol.to_s)
                    instance_variable_set variable, event
                end
                
                instance_variable_get variable
            end

Moral of the story? Do not ignore compiler/interpreter warnings. They are there to help you improve not only your current code, but also your future code. That is, if you're willing to pay attention to them.

Note: if you have experience with a variety of C/C++ compilers from back in the day, i can imagine that your opinion differs greatly from mine. However, i'm not talking about C/C++, so please keep the context (not to mention the decade...) in mind before you start typing a reply about how warnings in C/C++ could easily be justified depending on the compiler you were using ;)

« Older Entries

Meta

Recent Posts

Categories