Raganwald

These are just easy to understand examples. I don't know any Rubyists who would actually define these methods in exactly this way. If you look at the Ruby StdLib, you'll see that, most of the time, libraries implement operators in a way that is consistent with the spirit of canonical methods. For example, in Unix, a network socket is abstracted in a way that is similar to a file. You read/write from it in similar ways. This is an abstraction pattern. Ruby also has patterns. Lots of them, actually.

For example, many Ruby objects accept a block. The ampersand unary operator is used in a particularly common pattern that interacts with methods where a block would normally be passed.

Imagine you have an object that is implemented as a collection of items; like a collection of query results, wrapped in an object. Let's also imagine you want to call a method on each of the items. In Ruby there are two simple ways to do this. The example below uses an Array, upon which many common patterns are based [1].

1) Using a simple map function, which passes the receiver as an argument to a block:

["Hello", "WORLD!"].map { |x| x.downcase }
#=> ["hello", "world"]

2) Using the unary operator of the Symbol class to pass a proc:

["Hello", "WORLD"].map(&:downcase)
#=> ["hello", "world!"]

The second example uses a pattern combining #map from Array and #to_proc from Symbol. This looks like magic the first time you see it, but it's actually pretty simple to follow when you look at the…

1. Minor 'typo': Mix and match charts types and maps to tell beautiful data with your data.

2. I'm not sure what 'story' means in this context. While it sounds good, it makes me uncertain about what Vizbi is and the landing page doesn't really help pin it down. For example 'with or without code' doesn't clarify it.

3. Don't misunderstand me, I love creative prose and the turn of the phrase. But when I look at a tool, I want to know what it does and why I should care.

4. I hit the Vizbi page and the headline is two statements which are not clear about what it does and why I should care. Most of my screen is wasted on a picture of hands and a laptop on a desk: it's completely irrelevant to my interests.

5. Don't misunderstand me, I love graphic design. But here it seems to exist for it's own sake. Just tell me about the product.

6. Since Vizbi tells stories, tell me the story with Vizbi...this is showing me what it does. http://weblog.raganwald.com/2008/05/show-dont-tell.html

Good luck.

Here's another idea: Since your friend is coming out in 9 months anyway and there's so much risk involved in trying to sneak in a programming book, he should probably spend his time developing another equally useful skill: writing well.

As many other successful programmers have noted (Spolsky, Yegge) and demonstrated, effective communication, especially through writing, is a very useful and necessary skill for a programmer. So, maybe you should send him just some good books on writing well.

In general books, I can think of Strunk and White, On Writing (by Stephen King). But some examples of good writing about programming could also help:

The Best Software Writing (edited by Spolsky)

Joel on Software (the best articles from his blog)

Steve Yegge's blog posts (others might disagree but I think he is an excellent writer).

Paul Graham's essays

raganwald's old blog - http://weblog.raganwald.com/

James Hague's blog - http://prog21.dadgum.com/

Rands in Repose - http://randsinrepose.com/

Thank you Reginald. You always make me think, more reliably than any other writer about software. You pose interesting questions and have interesting viewpoints and discussion related to those questions. I hope you feel proud about this ability, because you should.

I also appreciate that you have chosen to publish your writing more in a blog format just like on http://weblog.raganwald.com instead of the GitHub experiment, I never really got into reading your stuff there.

As for the question posed, I believe I'm biased towards invention. I would prefer to work in a research department in a company or in a small company that have a business idea (partly) based on research. I hope I'm wise enough to avoid NIH, that is not really inventing anyway, so it's not as much fun as real inventing. (Working in a university seems to come with too much bureaucracy for my taste, but I do like the teaching part.)

Completely agree with you.
In "My Favourite Interview Question"[1] The author asks:
How would you design a Monopoly game?
He goes on to say that with 'basíc' OOP you can model the elements: dice, buildings.

But What about the rules? One of his suggestions is to look to the Strategy, Visitor, and Command patterns.

But I disagree. I want to model the rules using Prolog!
That is what prolog is great at.

So can please the next high level language standup?
I just want:
top of the line OOP (Smalltalk)
constraint programming (prolog)
functional (haskell)
And Design By Contract (Eiffel)

And no... I'm not asking for the kitchen sink language [2]

Is simply that this concepts aren't exclusive and all of them helps us to better model reality.

[1]http://weblog.raganwald.com/2006/06/my-favourite-interview-question.html
[2]http://zedshaw.com/essays/kitchensink.html

> For those that don't know, Fizz Buzz is less an aptitude test and more of an attitude test.

The articles which popularised FizzBuzz as an interview question stated as a categorical fact that most computer science graduates or programmer candidates (one article even said 199/200!![2]) cannot do FizzBuzz[1,2,3] and were absolutely recommending it as an aptitude test.

I personally think this whole thing was simply untrue back in 2007 (or at the very least incredibly overstated) and we are paying the price for it with ridiculous 15-stage interviews as a paranoid response to some urban legend from ~20 years ago.

[1]: https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/ [2]: http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html [3]: https://blog.codinghorror.com/why-cant-programmers-program/