Categories
Uncategorized

Ten Worst PC Keyboards of All Time

10 Worst Keyboards of All Time

PC World takes a look at the 10 Worst PC Keyboards of All Time:

Categories
Uncategorized

RailsConf 2008 Registration is Open

Just got the email: early bird registration for RailsConf 2008 (which is $100 cheaper) is now open. When I was working a nice big company like Tucows, they’d foot the bill, making the decision a no-brainer. Now that I’m at TSOT, which is a start-up, we don’t have those budgets and now I have to think about the bang-per-buck ratio. Are you going, and what factors are you taking into account?

Categories
Uncategorized

“Star Wars” Stills in 1080p

Need desktop images? How about these Star Wars stills in 1080p?

Categories
Uncategorized

At Last, a Computer Peripheral for Those Romantic Encounters

USB Aroma Radio + Speaker

The use of computers as assistive devices for romantic encounters isn’t new: from the “computer dating gone terribly wrong” plotline used by some ’60s and ’70s sitcoms to SolveDating.com (has its developer, who had not yet been kissed at the age of 33 back in 2004, “gotten anywhere” yet?) the likes of LavaLife and eHarmony, we’ve had a handful of dating generations’ worth of software approaches. However, there wasn’t much in the way of romance-assistive computer hardware save for possibly impressing potential soulmates with your Guitar Hero or Rock Band skills. (And no, I don’t count sex-toy peripherals or “teledildonics” — I’m talking romance, not rumpy-pumpy.)

That’s changed, thanks to the USB Aroma Radio + Speaker, a US$30 device that boasts the following features:

  • Radio (for mood music)
  • Speaker (if you’d rather play the “shag tunes” playlist on your computer)
  • Mood lighting (in 7 colours!)
  • A scented oil warmer

USB Aroma Radio + Speaker with cables

Of course, how you lure that special someone into your place/cubicle/airport bathroom stall so you can actually use the USB Aroma Radio + Speaker to set the mood is up to you.

Photo-montage of the USB Aroma Radio + Speaker glowing in different colours
Photo-montage courtesy of Gizmodo.

[Found via Gizmodo]

Categories
Uncategorized

Enumerating Ruby’s “Enumerable” Module, Part 1: “all?” and “any?”

The raison d’etre

While I often refer to the documentation at Ruby-Doc.org, I often find its descriptions a little unclear, lacking in detail and even missing some vital information. In the “do it yourself and share it afterwards” spirit of Open Source, I’ve decided to start working on a series of articles that I’ll eventually compile into a single site to become a useful, complete and better alternative to Ruby-Doc.org’s docs. These articles will appear here on Global Nerdy on an ongoing basis, and I hope you’ll find them useful.

My plan is to start with a module whose methods you’re guaranteed to use in your day-to-day Ruby development: Enumerable, a mixin that adds traversal, search, filtering and sorting functionality to collection classes, including those workhorses known as Array and Hash. My articles on Enumerable‘s methods should fill in some holes Ruby-Doc.org’s coverage (especially for hashes, which gets surprisingly little coverage). I’ll be going through Enumerable‘s methods alphabetically.

In this installment, I’ll cover two of Enumerable‘s methods: all? and any?

all?

  • In plain language: Do all the items in the collection meet the given criteria?
  • Ruby.Doc.org’s entry: Enumerable#all?
  • Expects: A block containing the criteria (it’s optional, but you’re likely to use one most of the time).
  • Returns:
    • true if all the items in the collection meet the given criteria
    • false otherwise

Using all? with Arrays

When used on an array and a block is provided, all? passes each item to the block. If the block never returns false or nil during this process, all? returns true; otherwise, it returns false.

# "feta" is the shortest-named cheese in this list
cheeses = ["feta", "cheddar", "stilton", "camembert", "mozzarella", "Fromage de Montagne de Savoie"]

cheeses.all? {|cheese| cheese.length >= 4}
=> true

cheeses.all? {|cheese| cheese.length >= 5}
=> false

When the block is omitted, all? uses this implied block: {|item| item}. Since everything in Ruby evaluates to true except for false and nil, using all? without a block is effectively a test to see if all the items in the collection evaluate to true (or conversely, if there are any false or nil values in the array).

cheeses.all?
=> true

cheeses << false
=> ["feta", "cheddar", "stilton", "camembert", "mozzarella", "Fromage de Montagne de Savoie", false]

cheeses.all?
=> false

Using all? with Hashes

When used on a hash and a block is provided, all? passes each key/value pair in the hash to the block, which you can “catch” as either:

  1. A two-element array, with the key as element 0 and its corresponding value as element 1, or
  2. Two separate items, with the key as the first item and its corresponding value as the second item.

If the block never returns false or nil during this process, all? returns true; otherwise, it returns false.

# Here's a hash where for each key/value pair, the key is a programming language and
# the corresponding value is the year when that language was first released
# The keys range in value from "Javascript" to "Ruby", and the values range from
# 1987 to 1996
languages = {"Javascript" => 1996, "PHP" => 1994, "Perl" => 1987, "Python" => 1991, "Ruby" => 1993}

languages.all? {|language| language[0] >= "Delphi"}
=> true

languages.all? {|language, year_created| language >= "Delphi"}
=> true

languages.all? {|language| language[0] >= "Visual Basic"}
=> false

languages.all? {|language, year_created| language >= "Visual Basic"}
=> false

languages.all? {|language| language[0] >= "Delphi" and language[1] <= 2000}
=> true

languages.all? {|language, year_created| language >= "Delphi" and year_created <= 2000}
=> true

languages.all? {|language| language[0] >= "Delphi" and language[1] > 2000}
=> false

languages.all? {|language, year_created| language >= "Delphi" and year_created > 2000}
=> false

Using all? without a block on a hash is meaningless, as it will always return true. When the block is omitted, all? uses this implied block: {|item| item}. In the case of a hash, item will always be a two-element array, which means that it will never evaluate as false nor nil.

And yes, even this hash, when run through all?, will still return true:

{false => false, nil => nil}.all?
=> true

Special Case: Using all? on Empty Arrays and Hashes

When applied to an empty array or hash, with or without a block, all? always returns true.

Let’s look at the case of empty arrays:

cheeses = []
=> []

cheeses.all? {|cheese| cheese.length >= 4}
=> true

cheeses.all?
=> true

# Let's try applying "all?" to a non-empty array
# using a block that ALWAYS returns false:
["Gruyere"].all? {|cheese| false}
=> false

# ...but watch what happens when we try the same thing
# with an EMPTY array!
[].all? {|cheese| false}
=> true

…now let’s look at the case of empty hashes:

languages = {}
=> {}

languages.all? {|language| language[0] >= "Delphi"}
=> true

languages.all? {|language, year_created| language >= "Delphi"}
=> true

languages.all?
=> true

# Let's try applying "all?" to a non-empty hash
# using a block that ALWAYS returns false:
{"Lisp" => 1959}.all? {|language| false}
=> false

# ...but watch what happens when we try the same thing
# with an EMPTY hash!
{}.all? {|language| false}
=> true

any?

  • In plain language: Do any of the items in the collection meet the given criteria?
  • Ruby.Doc.org’s entry: Enumerable#any?
  • Expects: A block containing the criteria (it’s optional, but you’re likely to use one most of the time).
  • Returns:
    • true if any of the items in the collection meet the given criteria
    • false otherwise

Using any? with Arrays

When used on an array and a block is provided, any? passes each item to the block. If the block returns true for any item during this process, any? returns true; otherwise, it returns false.

# "Fromage de Montagne de Savoie" is the longest-named cheese in this list
# at a whopping 29 characters
cheeses = ["feta", "cheddar", "stilton", "camembert", "mozzarella", "Fromage de Montagne de Savoie"]

cheeses.any? {|cheese| cheese.length >= 25}
=> true

cheeses.any? {|cheese| cheese.length >= 35}
=> false

When the block is omitted, any? uses this implied block: {|item| item}. Since everything in Ruby evaluates to true except for false and nil, using any? without a block is effectively a test to see if any of the items in the collection evaluate to true (or conversely, if all the values in the array evaluate to false or nil).

cheeses.any?
=> true

cheeses = [false, nil]
=> [false, nil]

cheeses.any?
=> false

# Remember that in Ruby, everything except for false and nil evaluates to true:
cheeses << 0
=> [false, nil, 0]

>> cheeses.any?
=> true

Using any? with Hashes

When used on a hash and a block is provided, any? passes each key/value pair in the hash to the block, which you can “catch” as either:

  1. A two-element array, with the key as element 0 and its corresponding value as element 1, or
  2. Two separate items, with the key as the first item and its corresponding value as the second item.

If the block returns true for any item during this process, any? returns true; otherwise, it returns false.

# Here's a hash where for each key/value pair, the key is a programming language and
# the corresponding value is the year when that language was first released
# The keys range in value from "Javascript" to "Ruby", and the values range from
# 1987 to 1996
languages = {"Javascript" => 1996, "PHP" => 1994, "Perl" => 1987, "Python" => 1991, "Ruby" => 1993}

languages.any? {|language| language[0] < "Pascal"}
=> true

languages.any? {|language, year_created| language < "Pascal"}
=> true

languages.any? {|language| language[0] < "Fortran"}
=> false

languages.any? {|language, year_created| language < "Fortran"}
=> false

languages.any? {|language| language[0] >= "Basic" and language[1] <= 1995}
=> true

languages.any? {|language, year_created| language >= "Basic" and year_created <= 1995}
=> true

languages.any? {|language| language[0] >= "Basic" and language[1] <= 1985}
=> false

languages.any? {|language, year_created| language >= "Basic" and year_created <= 1985}
=> false

Using any? without a block on a hash is meaningless, as it will always return true. When the block is omitted, any? uses this implied block: {|item| item}. In the case of a hash, item will always be a two-element array, which means that it will never evaluate as false nor nil.

And yes, even this hash, when run through any?, will still return true:

{false => false, nil => nil}.any?
=> true

Special Case: Using any? on Empty Arrays and Hashes

When applied to an empty array or hash, with or without a block, any? always returns false.

Let’s look at the case of empty arrays:

cheeses = []
=> []

cheeses.any? {|cheese| cheese.length >= 25}
=> false

cheeses.any?
=> false

# Let's try applying "any?" to a non-empty array
# using a block that ALWAYS returns true:
["Gruyere"].any? {|cheese| true}
=> true

# ...but watch what happens when we try the same thing
# with an EMPTY array!
[].any? {|cheese| true}
=> false

…now let’s look at the case of empty hashes:

languages = {}
=> {}

languages.any? {|language| language[0] < "Pascal"}
=> false

languages.any? {|language, year_created| language < "Pascal"}
=> false

languages.any?
=> false

# Let's try applying "any?" to a non-empty hash
# using a block that ALWAYS returns true:
{"Lisp" => 1959}.any? {|language| true}
=> true

# ...but watch what happens when we try the same thing
# with an EMPTY hash!
{}.any? {|language| true}
=> false

In the Next Installment…

…the collect (a.k.a. map) method.

Categories
Uncategorized

Zed Shaw’s Writeup of CUSEC 2008

Zed’s “Zed playing guitar graphic” laid over the CUSEC 2008 banner

Zed Shaw’s title for his writeup of the CUSEC 2008 conference sums up his opinions: CUSEC 2008 Rocked Hard!. It’s a telling sign when the master of over-the-top condemnation has nothing but praise for your endeavour.

Here’s a quick summary of his points:

  • “The first thing I’d say about this conference, and many of the other small regional conferences is just how well organized they are compared to the professional and larger conferences. The CUSEC organizers are all volunteers from universities, yet they were better planned, had their act together, and really knew how to put on a show.”
  • Montreal however reminded me of what Canada is supposed to be: friendly, cool, relaxed, and open. The sexy French accents helped push this perception, but also the food, the fact that strip clubs were everywhere, the streets were clean, people smiled at me (nobody in Vancouver smiled) and everyone seemed to be having a good time.
  • Tim Bray’s presentation: “It was a decent talk, and I think the audience got some valuable information out of it…I liked Tim’s talk since it was perfect for students starting out, and it dovetailed well with a talk by Dr. Peter Grogono on the same subject.”
  • Kate Hollenbach’s presentation: “What she demonstrated is a way to do simple visualizations using a Python simplification wrapper to most OpenGL primitives. What impressed me the most is she did live demos of large scale 3D visualizations based on information from internet services like Facebook. She did this live right off the internet and it didn’t tank on her. If the project already can survive the demo effect then it’s doing pretty damn good.”
  • Zed’s keynote: “I did my keynote in Factor using a neat presentation DSL that Slava wrote up for another presentation he did. You can grab the source to it here. Then go grab the 0.91 release, put the file in extra/cusec2008/ in the Factor directory, and then just start factor and type: “cusec2008” run to start it. Yes, I make it hard to read through on purpose you bastards. Learn something for a change.” (That crazy Zed, always working that “Magnificent Bastard” persona…)
  • The points from Zed’s keynote:
    • I work at a stupid bank on a cool project.
    • They’re bureaucracy almost crushed the project.
    • They tried to push through a product we couldn’t use due to a major theoretical limitation in how ACLs work: they aren’t turing complete.
    • Steak And Strippers! The sales guy’s dirty bomb.
    • After months of wasted effort on the project and fighting stupid politics we finally implemented something better.
    • This kind of thing makes being a corporate programmer suck, suck, suck!
    • Don’t be a corporate programmer. They demand all of your creativity and trust none of your judgment.
    • But, you’ve gotta eat so if you do become one, here’s how you survive.
    • Then tons of advice on how to survive and be happy until the moron MBAs who know nothing of technology die off and are replaced with people who get it.
  • “Another thing that impressed the hell out of me about the audience is that many of them actually came up and told me they didn’t agree with all that I said. Other conferences I’ve been to people either don’t speak up when a speaker is being an asshat, or if you do challenge the speaker he gets all pissy.”
  • “What blew me away first off is that the audience asked actual fucking questions. I’ve been to so many conferences where half of the shit the audience spews out of their mouth hole after the talk isn’t a question. They state what they think, talk about their own work (which usually sucks), and just don’t ask a fucking question. The CUSEC attendees rocked because they got up, and not only asked great questions, but asked challenging ones that caught a few speakers off guard, myself included.”
  • “CUSEC was full of great independent thinkers and I hope they never lose that. Always question the people telling you how it should be and demand evidence. If some shit head Haskell moron tells you that software should be stateless, then ask him why there’s monads. If someone says that you should be doing more usability, then ask him why his website sucks shit.”
  • At CUSEC the corporate talks were actually useful and given by non-sales people. They did include pitches to hire folks, but not but based on how cool their product was and how interesting the work is. Additionally, I had managed to inoculate most of the students against stupid sales pitches so most of the people trying to recruit had to throw in, “We don’t suck like Zed says other corporations suck.” I was actually also proud since throughout the rest of the conference students would yell out “Steak and Strippers!” whenever it was funny.
  • Jeffrey Ullman’s keynote: “Pretty neat stuff, and since he’s basically the grandfather of google having been their thesis adviser, it was worth seeing.”
  • Idee’s presentation: “The demos were impressive.”
  • Idee’s as a start-up: “Then they mentioned that the two partners actually had 2.1 million of their own money for the “start-up”. That pretty much killed the talk for me. Technically it was excellent, but if you come to me and say you got your business off the ground by a heavy investment of 2.1 million bones then I don’t call you a start-up. A start-up is Woz and Steve Jobs making circuit boards in their garage on nothing. With that much money you’re just a business.”
  • On Slava Pestov’s no-show: “…he whimped out at the last minute and decided to defend his MSc. in Mathematics instead. Loser. No worries though, because I got Slava’s CUSEC speaker’s plaque and plan to take it on a disgusting traveling gnome style tour of NYC before mailing it to him.”
  • Jeremy Cooperstock’s presentation: “It was a kick ass talk about how the current internet can’t handle the required latency for musicians in different locations to perform together.”
  • On Jon Udell’s talk: “One thing I found annoying about Jon Udell’s talk is that, just like all the other RESTafarians, didn’t have a clue about HTTP. He mentioned that you could use ’;’ in a URL to give people hierarchy, but that’s just dead wrong. It’s the exact same problem that Rails ran into, since ’;’ is a path parameter and isn’t part of a file name at all. It’s right there in the HTTP spec that you can’t do it, and part of the grammar even, but REST people don’t have a clue. They think if they can put the char in a file on their modern file system then it can go in a URL. Not true at all since HTTP was built before most modern file systems…I later had the chance to sit next to Jon and chat with him. He’s a smart guy for sure and very nice. Just wish he wasn’t telling kids how to do REST.”
  • Jeff Atwood’s talk: “Finally I watched Jeff Atwood of Coding Horror fame talk about what a lot of other people have said and why you should blog. I completely agreed with everything Jeff said, except for a tiny bit of hypocrisy he didn’t fess up to until asked…Jeff is a great public speaker too. Even though I disagreed with a few of his points I really liked his talk and would see him speak again any time.”
  • Don’t just fucking blog, but write some software and give it away. While the average person can only read a human language, the people you really need to hit with your message as a programmer are other coders. I’d say that’s the best thing I’ve done for myself, not really the blogging.
  • I have a policy of not naming people on my blog since it’s normally a pretty fucked up place to get named. I’ll just keep it short however and say all of the organizers kicked major ass. They were all nice, awesome people that I’d hang out with any day. I’m glad they invited me to the conference and I’d come to the next one any time.
Categories
Uncategorized

10 Secrets to Success

Key on a computer keyboard labelled “Success”

Continuing the recent run of lists of career tips — see What to Do if You’re Laid Off in the 2008 Recession and How to Work the Room — here’s 10 Secrets to Success.

It’s a list on PickTheBrain.com that originally appeared in Investors Business Daily. This list is based on answers to questions they asked “industry leaders, investors and entrepreneurs to understand the traits they all had in common”.

Here’s a simplified version of the list — to see the whole thing, read the article:

  1. How you think is everything. “Think Success, not Failure. Beware of a negative environment. This trait has to be one of the most important in the entire list. Your belief that you can accomplish your goals has to be unwavering.”
  2. Decide upon your true dreams and goals. “Write down your specific goals and develop a plan to reach them…Goals are those concrete, measurable stepping stones of achievement that track your progress towards your dreams.”
  3. Take action. “Goals are nothing without action.”
  4. Never stop learning. “Becoming a life long learner would benefit us all and is something we should instill in our kids. It’s funny that once you’re out of school you realize how enjoyable learning can be.”
  5. Be persistent and work hard. “Success is a marathon, not a sprint.”
  6. Learn to analyze details. Get all the facts, all the input. Learn from your mistakes. I think you have to strike a balance between getting all the facts and making a decision with incomplete data – both are traits of successful people. Spend time gathering details, but don’t catch ‘analysis paralysis’.
  7. Focus your time and money. “Don’t let other people or things distract you.”
  8. Don’t be afraid to innovate. Be different. Following the herd is a sure way to mediocrity.” (It sounds like a variant of my own maxim, “Do the stupidest thing that could possibly work.”)
  9. Deal and communicate with people effectively. “No person is an island. Learn to understand and motivate others.””
  10. Be honest and dependable. “Take responsibility, otherwise numbers 1 – 9 won’t matter.”