by Alan Skorkin on March 10, 2010
I use Wordpress as my blogging platform, it's a great tool, has a heap of plugins so you can do much with very little effort, which suits me fine :). As a software development blog I often have code snippets that I need to post and I want these to look good (i.e. formatting, syntax highlighting). This is why I use the WP-Syntax Wordpress plugin. I am not going to go into why it's so great, if you're curious you can check it out for yourself. Suffice to say, it does the job fine except for one very annoying issue. Whenever you have any kind of special characters in your code (which you inevitably do e.g. <, >, & etc.), these always render as their escaped representations. For example if you wanted to write:
if (foo < 5 && bar > 6)
you would end up with:
if (foo < 5 && bar > 6)
Extremely annoying. This only happens if you use the WYSIWYG editor in Wordpress, which is why the plugin FAQ recommends switching off the visual editor and using the source code editor, but that eventually gets to be beyond annoying.
by Alan Skorkin on March 9, 2010
In my previous post on boolean search, we wrote an efficient list (array) intersection function. But, to be honest, I wasn’t very happy with it. Considering the fact that we were using Ruby, it just wasn’t very Ruby-like. So, this time I am going to try and show how that function can be re-written to not only be more Ruby-ish but to also be tighter and easier to understand. In addition I will look at a couple of interesting aspects of OpenStruct, which will lead nicely into my next post on skip pointers (I’ve spoken about covering skip pointers before).
The Ruby-ish Intersection Function
The last time we implemented an array intersection function it looked like this:
def intersect_lists(list1, list2)
final_list = []
current_list1_index = 0
current_list2_index = 0
while(current_list1_index < list1.length &&
current_list2_index < list2.length)
if list1[current_list1_index] == list2[current_list2_index]
final_list << list1[current_list1_index]
current_list1_index += 1
current_list2_index += 1
elsif list1[current_list1_index] < list2[current_list2_index]
current_list1_index += 1
else
current_list2_index += 1
end
end
final_list
endThere is actually nothing wrong with the code itself. It is an efficient implementation. The reason it is efficient is due to the fact that we only need to walk through each of the lists once, in order to produce the intersected list. So if the sizes of our two lists are x and y, the intersection takes x+y operations, i.e. the complexity of the algorithm is O(x+y). If we were writing that function in C, everything would be fine at this point, but we’re using Ruby. What we really want our function to look like is something along the lines of:
by Alan Skorkin on March 8, 2010
Much of the agile process literature is very general. There is a lot of focus on practices and philosophy and empowering teams (nothing wrong with that by the way), but there is also often a lack of practical advice on how to solve the day-to-day problems you run into when working in an agile environment. It is difficult, as every team encounters different problems and even similar problems often have a different root cause depending on the environment. Regardless, I can see a need for a cookbook type of text, but in the meantime I'd like to weigh on an issue that I have seen quite often with agile teams, that of pair programming and the apparent reluctance of many developers to actually swap pairs regularly.
If this kind of thing is of interest to you then remember to subscribe to my RSS feed as I often write about this sort of stuff.
A Novice Agile Team
I don't really want to spend too much time here as the issues in the case of novice agile teams are reasonably clear. It is likely a people or a team dynamics problem. I would look at one of two things:
by Alan Skorkin on March 7, 2010
I find that whenever I get a large data file from somewhere (i.e. extract some data from a database, crawl some sites and dump the data in a file) I always need to do just that little bit of extra processing before I can actually use it. This processing is always just non-trivial enough and I do it just uncommonly enough for me to always forget exactly how to go about it. Of course, this is to be expected, if you learn something and want it to stick you have to keep doing it. It's all part and parcel of how our brain works when it comes to learning new skills, but that doesn't make it any less annoying.
Back to our data file, for me I find that I almost always need to do 3 things (amongst others) before doing anything else with my file.
- delete the first line (especially when pulling data out of the database)
- delete the last line
- remove all blank lines
Don't ask me why but for whatever reason, you always get an extraneous first line and unexpected blank lines (and less often an extraneous last line) no matter how you produce the file :).
by Alan Skorkin on March 3, 2010
Firstly, let me start by saying that I am not recommending you dress up in black pyjamas and go on a killing spree :). With that out of the way, this idea actually came to me when I was reading chapter 4 of Beautiful Teams (I've mentioned Beautiful Teams before). For whatever reason I must have had ninjas on my mind (as you do :)) and thought that it would be interesting to draw some parallels, since ninjas and managers have a lot more in common than the obvious potential scariness factor.
You see, ninjas are not all about killing. Yes, they may be assassins for hire, but they are, in essence, great enablers. They remove obstacles and through their actions make the impossible, probable. They remain unseen, in the shadows, but what they do has a tremendous impact. This is what every manager should be – an enabler. They should concentrate on removing obstacles to enable you to have the most impact as a professional. When there is an organisational obstacle, that you see no way to overcome, they should be able to use their skills and cunning to make the impossible happen. All this should be done without kicking up too much of a fuss. All you would need to do is watch, slightly bemused, as roadblocks, that were preventing you from doing what you needed to do, disappeared almost by magic. That is true management ninjutsu.
by Alan Skorkin on March 1, 2010
From my last two posts about searching (i.e. basic indexing and boolean queries), you might get an impression that writing a search engine is a fairly straight forward process. Infact nothing could be further from the truth. To highlight this I am going to explore one of the issues that I have glossed over previously in a little bit more detail – that of linguistic preprocessing of documents before indexing occurs. This is a massive topic and I have no hope of covering all of it in any kind of detail in just one post, instead I will try and touch on some of the main concepts and issues involved, to give everyone an idea of the scope that even this tiny area of information retrieval can cover.
So, let's assume we have just fetched a document, what exactly do we need to do before we begin indexing?
by Alan Skorkin on February 26, 2010
Ruby on Rails projects usually use MySQL or PostgreSQL for their database, but in the corporate world, Oracle is king. As much as you might like to have a Postgres backend, the powers-that-be have decreed and you must obey. Don't worry though, all is not lost, you don't have to slink back to Java, here is how you can get your Rails app working with an Oracle database. Note: All of this works with Rails 2.3.5, I haven't tried it with Rails 3, but feel free to give it a go and don't forget to let me know how it works out.
Getting Rails To Play With Oracle
Alright, first thing first, I hope you're using RVM, cause it's awesome and will make your life easier. With that out of the way, you need to install two gems, before trying to use Oracle with Rails.
- ruby-oci8 gem – this is the ruby interface for oracle using the OCI8 API. You need to have a version of Oracle installed on your machine for this gem to work, otherwise the OCI8 library will not be available on your machine and this will make your life difficult (i.e. impossible :)), as you might imagine.
by Alan Skorkin on February 25, 2010
Programmers love to work long hours! There I said it, c'mon admit it, your job/boss doesn't make you do it, we do it to ourselves. Alright, I'll concede, maybe not all programmers love long hours, but surely with the amount of overtime that is prevalent in this industry at least half of us must love it. Right?
I can hear the excuses already. "No, no that's not it, we just love working with cool tech and don't want to leave a problem unsolved. It is actually a good thing it's what makes us awesome!"
I say – you're not seeing the forest for the trees. Here is some perspective, you're not doing this for yourself, you're doing it for "the man". Admittedly he might be a nice man, but you don't owe him slavish commitment. Here is even more perspective, how often are you actually playing with interesting problems and cool tech and how many times are you churning out code desperately trying to get something delivered and meet some arbitrary deadline that someone has assigned to you? But hey, you're a business savvy developer, you're helping the company succeed, your manager has explained the financial situation to you – it has to be done, we're relying on you. Well, unless that same manager is right there with you, entertaining you with amusing anecdotes at 2 am, his words are worthless.
by Alan Skorkin on February 23, 2010
I am going to give it away right here in the first sentence, it's the ability to ask for and take criticism. Yeah I know technically it's two skills. Before you switch off and browse away to look at funny cats with bad grammar, I don't mean the ability to say:
"Well, of course I can take criticism, I am hip, I am with-it."
It's like asking people if they are good in bed, it's not as if anyone is actually going to say that they are terrible. And yet most developers (most people) can't take criticism well and even fewer know how to ask for criticism and have it be received without uncomfortable silences.
by Alan Skorkin on February 18, 2010
I was reading Beautiful Teams the other day. In chapter 2, Scott Berkun talks about “Ugly Teams” and weighs in with an opinion on academic scores and how they tell you nothing about a persons aptitude (of course when I say “person”, in my mind that translates to – “developer” :)). I’ve heard similar opinions so many times now that I felt like I had to champion the other side of the argument. Here are some quotes:
“If we go beneath the superficial, perfect grades often mean the perfect following of someone else's rules”
or
“They (good grades) are not good indicators of passionate, free-thinking, risk-taking minds”
or
“The tragedy of a team of perfect people is that they will all be so desperate to maintain their sense of perfection, their 4.0 in life, that when faced with the pressure of an important project their selfish drives will tear the team apart”
or
“Beautiful people are afraid of scars: they don't have the imagination to see how beautiful scars can be”
Chris Roane (3)
apeiros (2)
Dan Kubb (2)
Kevin (2)
Korny (2)
kt (2)
Ahmed (1)
Barak A. Pearlmutter (1)
Bert Willems (1)
Carolyne (1)