Cedric talks about why he thinks Ruby will never become mainstream. One of the key points I'd like to highlight is:
The lack of powerful IDE functionalities such as refactoring for Ruby (and Ruby on Rails is much worse off) is still a concern and limits tremendously the pool of developers that Ruby can tap into (see below for some elaboration on this topic).
This collaborates with my thoughts written on this post.
Cedric has an interesting post on code reviews strategies and pair programming. I had my chance of doing some sort of pair programming in 2004 to 2005 in my previous job, but by some sort I mean that we only did that when we thought would be easier, not as a development rule. And that was only possible because me and my pair ![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
dserodio believed in the strategy and had the same level of knowledge.
About this practice of code reviews, the ones that are not a requirement to allow the code commit, I'm very found of. I wish this practices were more spread in the companies I've worked on, and I'm not only talking about managers but about the developers themselves.
dserodio believed in the strategy and had the same level of knowledge. About this practice of code reviews, the ones that are not a requirement to allow the code commit, I'm very found of. I wish this practices were more spread in the companies I've worked on, and I'm not only talking about managers but about the developers themselves.
By coincidence today I just had to implement my last post flatten operation of Array Ruby class. What is is funny about it is that when I read Fowler using it as an example of a typical operation of a human interface operation I thought to myself: "Who on earth would need such an operation?" If you don´t know what it does here is a example (Ruby code):
[1, [2, 3], 4, [5, [6, 7], 8], 9].flatten = [1, 2, 3, 4, 5, 6, 7, 8, 9]
And in the end I´ve ended up implementing it myself only a couple of days later of thinking that :)
I am doing some combinations of elements in my current project and my algorithm resulted this kind of collections, that may have elements that are other inner collections. All I needed was this kind of flatten operation, of course I could review my algorithm but this solution required much less effort. I guess the use of this operation is more common than I thought.
Here is the code:
public static Collection flatten(Collection elements)
{
Collection flattened = new LinkedList();
for (Object o : elements) {
if (o instanceof Collection)
flattened.addAll(flatten((Collection) o));
else
flattened.add(o);
}
return flattened;
}
A human interface operation is one that has a very specific usage but even though it is added to your interface against the philosophy of adding only operations of a general need.
By the way, Cedric has recently posted his opinions on human interfaces too.
[1, [2, 3], 4, [5, [6, 7], 8], 9].flatten = [1, 2, 3, 4, 5, 6, 7, 8, 9]
And in the end I´ve ended up implementing it myself only a couple of days later of thinking that :)
I am doing some combinations of elements in my current project and my algorithm resulted this kind of collections, that may have elements that are other inner collections. All I needed was this kind of flatten operation, of course I could review my algorithm but this solution required much less effort. I guess the use of this operation is more common than I thought.
Here is the code:
public static Collection flatten(Collection elements)
{
Collection flattened = new LinkedList();
for (Object o : elements) {
if (o instanceof Collection)
flattened.addAll(flatten((Collection) o));
else
flattened.add(o);
}
return flattened;
}
A human interface operation is one that has a very specific usage but even though it is added to your interface against the philosophy of adding only operations of a general need.
By the way, Cedric has recently posted his opinions on human interfaces too.
