Finally installed the very excellent reCAPTCHA plugin for WordPress. I like it when my posts get comments, I don’t like it when the comments are spam. So, if you look at the comment field on this blog, it’s got the reCAPTCHA interface hanging out, keeping us safe. Also, reCAPTCHA helps decode books. Awesome!
You should post a comment — try it out! 🙂
I was coworking at Stardust today, and we got to talking about Agile Development, and the concept of velocity.
Disclaimer: I hate buzzwords. But, these terms have specific meanings, and although it sometimes sounds cheesy, there really is something to this Agile movement.
Basically, velocity is an Agile concept that is a self-calibrating method for estimating how much work can be done in a unit of time.
The trick is that velocity doesn’t really measure the work done, it measures how much estimated time it takes to fill an actual week of working. The trick behind velocity is that you track (per task) the estimated time of completion, and the total amount of estimated work completed in a unit of time (usually a week). As long as the developers who are on the project are always the same ones handling estimates, if they have a tendency to overestimate or underestimate, it will be canceled out after the first week or two. Make sense?
If you haven’t tried Agile development processes, I strongly recommend it. There’s a game that was created to help explain how Agile/XP works, calld The XP Game. It’s a reasonably entertaining way to learn business stuff (better than a pointy haired lecture!), and doesn’t take long.
I’ve still got lots to learn about the finer aspects of applying Agile/XP, but I’m happy to talk with anyone about these ideas — I might learn something new 🙂
I wanted to cover a nifty-looking service that’s just launched — Gnip.
It’s a simple premise: instead of asking every social networking service what’s going on, Gnip will tell you what’s up (they’ll even POST it to your website). They’re going to be — Atlas-style — lifting a huge weight off of social networking providers. I hope they do well.
Of course, in the interests of disclosure, I know Eric.
I came across an article on BBC talking about advances in health care in the past 60 years. Honestly, 60 years isn’t that long, considering the changes that have occurred were previously unknown to humanity. So, a lot of assumptions about things have to change. Getting in a car accident; getting shot; damage to organs; lots of things are becoming undoable. This increases risk taking, and as every investor knows, increases rewards.
60 years ago, you didn’t have people jumping the Great Wall of China on a skateboard. It’s not that it wasn’t physically possible. They had the wood and bits of plastic back then. No laws of physics have changed. But 60 years ago, no one was able to get to this level without killing themselves.
Athletes have always pushed their bodies to the edge. But it used to be that if you crossed the line, there was no going back. You don’t really get a second chance if you break your neck. Or, at least, you didn’t. Now we routinely have people rehabilitating after a broken neck. We’ve given athletes the ability to take bigger risks, make bigger mistakes, and come back smarter and stronger.
And all these because some doctors figured out a few neat tricks. It’s amazing to see how growth in one area improves performance in another.
I can’t wait to see what’s next. It never was like this before.
I’ve been writing a lot of JS lately, and I wanted to take this opportunity to drop some knowledge right here.
Lots of languages have support for some type of for-each-looping. This is great for looping over associative arrays, and even regular arrays, since it’s a bit cleaner than the standard for-loop. Sadly, Javascript doesn’t totally support this. There is a for-each equivalent in JS, but it’s a bad choice to use, since in JS, everything is an object, and objects can be accessed with different notations — you can either do thing.property or thing[“property”]. This notation should throw a hint as to why looping for-each isn’t the same as other language — if you try and loop over everything in an Array, you’ll also get methods that have been assigned to the Array object. Fortunately, Javascript isn’t totally foolish, you won’t get every single method, but you can definitely get some noise. Here’s Mozilla’s explanation of Javascript for-each:
Although it may be tempting to use this as a way to iterate over an Array, this is a bad idea. The
for...instatement iterates over user-defined properties in addition to the array elements, so if you modify the array’s non-integer or non-positive properties (e.g. by adding a"foo"property to it or even by adding a method or property toArray.prototype), thefor...instatement will return the name of your user-defined properties in addition to the numeric indexes. Also, because order of iteration is arbitrary, iterating over an array may not visit elements in numeric order. Thus it is better to use a traditional for loop with a numeric index when iterating over arrays.
It’s a shame, because a nice for-each is some of my favorite sugar in a programming language. But, I like Javascript enough that I will forgive it for this. I have a suspicion that with some type checking, a more traditional for-each might be possible, but that’s for another time.
I also found the site of a very cool dude, Kent Brewster. Just one example of his awesomeness is found in his article on hardened Javascript. I also really like that he makes notes and lists and saves information; it’s probably one key to his success.
In my eyes, this is a good article about Bill Gates. It’s a little suck-up-y to Gates in a lot of areas, but I really enjoyed one particular quote about halfway through.
Then I met Warren, and I thought, “Oh, wow, this guy isn’t just about buying and selling stocks and businesses. He is thinking about how the world works.” And he asked me questions that I always wanted somebody to ask me, about why hadn’t IBM been able to do what we had done, and how software gets priced, and why does one company have a defensible position. He wanted to understand the dynamics of the industry. To me it was way far away from, “What is your company worth?”
Then he explained to me about how Wal-Mart had not only changed things in its business, but how it had an effect on newspapers because they thought of their advertising differently than individual local stores had. And he talked about how banking really worked in terms of credit risk. The whole time all I could think was, “Hey, I’ll be smarter about running Microsoft after I talk to this guy.” And so I stayed the whole day.
I can think of several ways that this story demonstrates why Warren Buffett is where he is.
I don’t know how much of Buffett’s image is genuine, and how much is PR fluff. But he certainly seems to often demonstrate specific qualities that are good.
When I read about ICANN’s proposal to let anyone register a TLD (top-level domain; the .com, .net, .edu part), I can’t help but think of the number of systems that check email addresses (or domains in general) for validity, and won’t accept any email address that ends in anything but the few most common TLDs.
It would have been better if they had done everything correctly upfront, right? There’s an established standard for emails that
has been around for years describing — in painstaking detail — how to tell if an email address is valid. Surely it’s not hard to do it right, right?
There are two ways to deal with an issue:
It seems that there are characteristics of situations that make one option more appropriate than the other.
Possibly everything starts as “best you can” and eventually moves to “do it right”. When we are babies learning to walk, we don’t consult textbooks on human mechanics; we don’t visit specialized doctors who focus on the angle of the spinal column to the neck; we get up and fall down a lot. It’s a new thing, and any given sequence of steps is a momentary thing, we aren’t still reliant on the series of steps we took years ago.
When considering software, however, the characteristics blend a lot. Software stays around for a while; I read a great quote relating to this:
“Obsolete hardware gets replaced. Obsolete software goes into production every night”
There are easily millions of lines of code that are 30-40 years old that are still used today. That’s definitely a vote to do it right. However, software development is not established — at least, not in the sense of cooking, where professional chefs have existed for thousands of years and the art is well-defined. Software development is still changing. Even the standards I talk about will change as we have new needs. The people who are writing the standards are just doing the best they can!
I suppose most things aren’t clear cut either. The humor of this whole thing is that the decision between “do it right” or “best you can” itself requires you do just make the best decision you can. 🙂
So in the end, is the answer to do things as right as you can, to the best of your ability, and not worry about the rest?
Ran across this story about sending email via snail.
I hope everyone can find some humor in this, but the Computer Scientist in me finds it awesome. It’s non-deterministic email, via snail — almost a Rube Goldberg machine. This system would give total plausible deniability, “but I sent it last month!”
They clearly love James Dean and Betty Boop — the walls are plastered with pictures — so the place has a real classic American-1950s feel to it. And, it seems, in the 1950s, breakfast was delicious.
I had Donna’s Skillet (served to me by Donna herself), which is
Add hot sauce and it’s great. The price is right for the food; $6 for the skillet. They got the food out fast, and kept my iced tea filled, so that does it for me. The service is totally unceremonious, the servers all work together to get it done.
It really seems like a one-of-a-kind, family-owned restaurant. I don’t think they could make another one — there’s not enough pictures of James Dean in the world to open a second place.
If you’re in the area, it’s worth a stop in for a quick simple breakfast. It sure beats the pants off Denny’s.
There’s this idea I’ve had rolling around my head for a while now. I call it the Law of Small Numbers, but it’s not really a law, and it’s apparently not called that either, at least according to Wikipedia.
Basically, it’s that small numbers increase easier than big numbers. It’s an idea that’s become popular with investors — small businesses can double your money easier than big ones. A tiny store can easily double it’s business, WalMart can’t.
Simply put, if you’ve got 2 units, and you increase that by 1, you’ve increased by 50%. If you’ve got 20 units, and you increase by 1, it’s only 5%. That’s the Law of Small Numbers. Maybe I should call it the Law of Increases of Small Numbers.
It’s something that’s popped into my head lately, thinking about gas prices. I’ve been trying to collect some gas mileages in my car, so that I can have hard data to look at. The way I see it, your gas mileage is a function of your gear, and your RPMs. Assuming constant gear (let’s say 4th — you’re cruising). If you are going from 2000 RPM to 4000 RPM when accelerating, you are literally cutting your gas mileage in half. If you can travel 55 MPH at 2000, but 60 MPH at 2500, is it worth decreasing your mileage by 25%? What if the corresponding speed increase only gets you there 90 seconds faster?
On a side note, one of the pages linked from that Wikipedia page discusses the Strong Law of Small Numbers
“There aren’t enough small numbers to meet the many demands made of them.”
I see this as the reason that things always seem to happen in twos and threes, but that doesn’t mean that they’re related.