Seeping Matter

My inbox is overflowing with emails from people asking, “Matt, how can I be more like you?”

Honestly, that is only sort of true.  Some of the emails say, “Lose 30 pounds in 12 minutes!”  And some say, “I am the prince of Nigeria!”  And some say, “I am lonely and looking for a purely physical relationship!”

More honestly, that pretty much comprises the bulk of the email I receive.  Nobody has actually asked how to be more like me, strangely enough.  But that day is surely coming, and since I am a computer scientist, or at least since USU says so, I could start with a list of books that you can read if you want to become a true nerd and rule the world the way I do, which is to say, not.

(So, in fairness, I haven’t actually read all of these or owned them. There are some that I haven’t read, but I read one like it; those are marked in blue. There are some that I haven’t read but think I should; those are marked in gray. There are some that where I read one like it, but I want to read that particular one – they are bluish-gray. And I didn’t list the probably 40-50 CS books I own or have owned and read that are not shown here. So cut me a break.)

Math and English

First off, in order to be a good software engineer and computer scientist, you have to be a good mathematician and a good writer.  Sorry.  You simply can’t be a competent software engineer without a solid mathematical background, and you can’t be an effective one if you can’t figure out how to express your ideas clearly in writing.

Learning to Program

Your next step is to learn basic programming concepts.  In my opinion, you should learn two languages at this point:  Python and C.  Python is a good beginning language, very easy to create real applications, easy to learn, and very versatile and useful in the real world.  C is the fundamental systems programming language.  Knowing Python and C will allow you to program just about anything and gives you a good fundamental background.

Computer Science Fundamentals

Having learned how to write basic computer programs, now is time to get into the science of computer science.

Programming Technique and Methodology

How to write software well.

General Programming

Two other languages you might want to know are C++ and Java.  C++ is much maligned, but widely used, especially for systems applications, games, and other high-performing software applications.  Java is an abomination in every sense of the word.  But it is also very popular and good to know.  If you are going to learn Java, you should also learn JNI, so you can get from Java back to C and get some real work done.

Systems Programming

If you are going to do systems programming, you’ve got to know the specifics of how to program to the environment in question.  It’s worth noting here that the UNIX books basically cover POSIX, which applies not only to UNIX but BSD, Linux, and Mac as well to varying reasonable degrees.  I’ve also included an internals book for the big three platforms (Windows, Linux, and Mac).  And if you are going to program for Mac, you will probably want to learn another language: Objective-C.

UNIX/Linux
Windows
Mac OS X

Other

Every good software engineer should clearly understand open source; hence The Cathedral and the Bazaar. You will find you are missing out on a number of inside jokes if you don’t read The Hitchhiker’s Guide to the Galaxy. And everyone should read The Code Book, simply because it is so interesting.

Image Credits: amazon.com and barnesandnoble.com

The movie “French Kiss” with Kevin Kline and that one chick is one of me and Amber’s favorite VHS movies.  (In our house, there are three time periods to movies – DVD movies, VHS movies, and pre-VHS movies.  No Blu-Ray yet.)  I like it, but the reason is not because it is a romantic comedy with that one chick in it.  And the reason is not because it says “French” in the title and I’m trying to suck up to my boss, Luis, who lives in France.  No, I like it because it has some really, really funny Canadians in it.  Like Strange Brew!

No.  Actually, not.  But it is a pretty funny movie.  And there is this part, which is not funny, where Luc is explaining to that one chick about what makes wines different from each other – that they take in elements from their environment that contribute to their unique flavor and texture.  For example, if you spill some wine in the dirt, and then scoop it up with your cup and drink it anyway, you will probably get some dirt crumbs in there, which changes the texture from “smooth” to “gritty” and just tends to get you even more drunk than you were before.  And that’s why I don’t drink.

Anyway, I was thinking about that today, and how similar that is to software engineers.  See, software engineers, also, take in elements from their environment that make them unique.  In fact, an easy way to say this is that software engineers who live in one part of the world are better than software engineers who live in another part of the world because of their superior geography.

For example, you might have one software engineer, let’s call him Steve.  He might live in an peninsula that is called a valley, surrounded on three sides by ocean, with real estate that is unreasonably expensive.  Or you might have another software engineer, let’s call him Bill, who lives in a place where it rains all the time, in the land of Nirvana and Alice In Chains and Soundgarden and Pearl Jam and Starbucks.  Or another guy, named Nathan, who lives in an area with tight roads that wind all over creation, also with expensive real estate, elitist professional sports teams, and where nobody ever pronounces the letter “r”.

Compare these people to someone named Drew, for the sake of argument.  This guy, also a software engineer, lives in an area with big mountains, lots of Mormons, and secret sand dunes where someone exactly like myself can go riding motocross bikes.

Anyone can see that there is simply no way Drew will ever be able to measure up to the likes of Steve, Bill, and Nathan.  I mean, just take into account the geographic considerations!  How can big mountains ever hope to make you the kind of software engineer you could have been if instead you had been surrounded by ocean or Soundgarden?  The simple answer is:  they can’t.  I mean, be serious.  This, my friends, is the effect of geography on software engineers – geography can make the difference between you being really excellent and simply mediocre.  Secret sand dunes are really amazing, but they obviously cannot make you into the kind of software engineer you could have been if instead you were to replace those dunes with expensive real estate.

I manage the Mozy Windows Client engineering team, and not long ago I sent out a meeting request that began thusly:

Guys,
We shipped 1.12, which means we are awesome, and shipping 1.12 and being awesome is something worth celebrating.

Now, before all you fairer readers get offended, I’m allowed to address my local team with “Guys” because all of them happen to be men, which is NOT the case with my extended team (hey Seattle peeps).

Anyway, I took my team to the movie today to celebrate releasing Mozy 1.12, and being awesome.  Most of my team chose to see “Taken,” but Pancho preferred to see “Race to Witch Mountain,” and since I didn’t care and didn’t want Pancho to be alone, I went to see that movie with him.

And it wasn’t bad.  For one thing, it has The Rock in it.  The Rock’s screen name is Dwayne Johnson, and he is one of the greatest actors ever, where “greatest” means “biggest and strongest.”  In case he reads this blog, let it be known:  The Rock, you RULE!  Freaking RULE!  Please don’t beat me up!

However, I hadn’t realized that you would have to know so much about the computer game Starcraft in order to understand “Race to Witch Mountain.”  And this may also make the movie more geeky and make more geeky people want to watch it.  Plus, probably a lot of them will wonder why the movie seems to be poking fun at the space alien convention – but that is another story.

Anyway, here’s the lowdown:

• Sara and Seth are aliens from outer space.  But they don’t look like aliens.  This means they are obviously Terrans.
• When everyone consults with a space alien expert, he describes aliens as “praying-mantis-like.”  It is apparent that he is only familiar with Zerg aliens, and assumes that since Zerg are aliens, therefore all aliens are Zerg.  Which is a reasonable assumption to make, although anyone familiar with Starcraft knows how false this is.
• There is also another alien.  Now I don’t mean to spoil the movie, so let me just say he’s an assassin trying to kill Sara and Seth, and that is pretty much the whole plot.  I probably spoiled it.  Eh.  Anyway, by the end of the movie it is quite clear that this alien is a Protoss.

So if you are thinking about going to see “Race to Witch Mountain” (which you should, so The Rock doesn’t hunt you down and beat on you), you should read about Starcraft first – and then you’ll be ready to fully enjoy the movie.

Oh, and by the way – if you know C and C++ and are awesome, you should talk to me about working at Mozy.

Mozy is hiring.  I mean, Decho is hiring.  Decho is the silly name given to replace the awesome of Mozy.  We still call it Mozy, we can’t help it.

Anyway, we’re hiring.  Specifically, my team, the client team, is hiring.  And since Mozy decided to make me the manager of the Windows client team, that means I’m participating in the interviews.  This is stressing me out, because I feel like I am deciding the fate of people.

The process of getting hired at Mozy (arrgh, Decho) goes something like this:

• Apply and submit a resume.
• If we like your resume we will do a phone interview.
• If you do well in the phone interview we will bring you in for on-site interviews.
• If you do well in the on-site interviews we will assign you a homework assignment.
• If you do well on the homework and you are the best candidate we have for the position, there’s a decent chance you’ll get an offer.

Development work at Mozy is primarily done in C++.  Objective-C on the Mac side.  Pretty much you have to know C and C++ and/or Objective-C to get a development job, unless you want to work for the web team, using Ruby.  But those guys are kinda weird.  They sit on a different floor in the building and everything.  We’re not talking about those guys.

So during the phone screen, we ask you to rate yourself on C++.

We explain the rating scale like this:  0 means you are my father, waiting for this computer fad to go away, and you haven’t really heard of C++.  1 means you wrote Hello World in C++ once, and might be able to do it again today.  On the other end of the scale, 10 means your name is Bjarne Stroustrup, or maybe Herb Sutter or Andrei Alexandrescu.  9 means you have written books on C++; 8 means you could write a book on it, or teach courses on it.

Please, people.  Do not flatter yourself on the C++ scale.

I interviewed with Google once, over the phone.  They asked me this same question with pretty much the same scale, except they made no mention of my father.  I told them I was a 6 or a 7.  And I actually have taught courses on C++.

Lately we’re asking people this question and invariably we’re getting people saying, “Oh, based on that scale, I’m a 7 or an 8.”  Even kids in college.  Now I’m not saying that kids in college can’t be a 7 or an 8 – just, keep in mind, we’re not seeing a lot of true 7′s or 8′s among experienced professionals.  I’m just sayin’.

When you say in your interview, “I’m a 7 or an 8,” what you are telling me is this:  “I know C++ better than you.”  Now, you don’t probably know me personally, so hey, maybe you are better.  All I’m saying is, you’d better be ready to prove it when we bring you on-site.

For example, you’d better know at least most of this stuff:

• How to define a template class
• How to correctly define the assignment operator for a class
• How to overload the insertion and extraction operators for a class you define
• How to iterate over an STL vector
• Whether ++i is better, worse, or the same as i++, performance-wise, and why
• What methods the compiler will create for you if you don’t create them yourself, and the implications of this
• How to indicate in your developer contract whether a class is meant to be subclassed, which methods are overrideable, and how you insist that only subclasses can be instantiated
• How to specify default values for parameters

If you are a 7 or an 8, you probably should have read most of “The C++ Programming Language” and/or “Effective C++” and/or “Advanced C++” and/or a number of equivalents.  Having read “Design Patterns” would certainly help, although lately those have kinda lost their glimmer and so I don’t weigh on those like I used to.

Also:

• What const and mutable mean

Yeah.  const.  Don’t be like the self-proclaimed C++ expert I worked with at Enterasys Networks, who told the whole company he was the go-to guy for C++ questions, who, when asked, “Why does it say const after this method declaration?” replied, “Oh, they just do that a lot in C++; it doesn’t mean anything.”  Yeah.  Don’t be a doofus.

Don’t try to impress me by saying you are a 7 or an 8 if you aren’t.  Really – you don’t have to be a 7 or an 8 to get a job at Mozy (Decho…hrm).  If you say, “Oh, I’m probably a 5,” that tells me you are a good, solid C++ dude (or dudette, whatever) that knows how to write decent C++ applications.  You’ll probably get asked to come in for an interview anyway.

When we bring you in, it is my job (and Cody’s) to figure out how much of C++ you really know.  We will start out at the point you specified and go from there.  If you are really a 5 or a 6, but you said 7 or 8, you will feel like we’re being very brutal on you.  Hey, you are the one who said you knew your stuff.

Oh – one more thing.  Some of you experienced hires don’t think you should have to go through all of this to get a job with us.  Well, we make the rules.  Every one of us that works there has gone through it.  If you think the rules of Monopoly are dumb, nobody’s gonna think bad of you if you decide not to play.  But if you want to play but not follow the rules, well, don’t be too surprised if people take issue with that.  If you’re gonna try to work at Moz – uh, Decho, at least for my team, just go through the process like everyone else.

Okay, I feel better.  Whew.  Oh, and by the way, if you really are a 7 or an 8 (or better), I have a link for you.

After spending a bit of time last week dealing with thread safety issues and a queue in C++, it only seems appropriate to blog a bit about it.  (Obviously, the information below would also apply to a stack or probably any other container type.)

Suppose you have a very common multiprocessing scenario:  two threads, one of which is producing work to be done, and another which is consuming the work to be done and performing the work.  You can accomplish this in a pretty straightforward fashion with:

• A queue
• Mutexes to prevent concurrent queue access
• A condition variable to tell the consumer when there is work to do

Originally I thought about creating my own container class for this.  Then part of my brain resisted.  “Quiet, engineering part of Matt’s brain!” it exclaimed.  “You’re just trying to do that because it seems Interesting!”  So I shut down that idea and pushed on trying to use a standard STL queue.  However, after I had to deal with some concurrency issues over and over, I realized that, at least this time, the engineering part of my brain was right.

So I set out to create a threadsafe queue.  The idea was that it would feel a lot like an STL queue, and would implement thread safety under the covers for you – so, for example, a simple call to q.empty() would automatically lock the mutex for you, see if the underlying queue was empty, then unlock and return the result.  So, essentially an STL queue wrapper class with automatic mutex locking, right?  It should be easy!

Well, you’d think so, until you get to an implementation of pop().

To see why this matters, first we should establish what we expect out of a threadsafe queue in C++:

• It should feel like an STL queue.  This means that it should have similar semantics and API if possible, and also, it should be a template.
• You get out what you put in.  Not a handle to what you put in; exactly what you put in is what you get out.
• Thread safety should be handled automatically – the user shouldn’t have to deal with thread safety.

An STL queue “pop()” isn’t as simple as it sounds.  The concept of “pop” is actually performed like this:

    std::queue q;
    ...
    if (! q.empty()) {
        int v = q.front();
        q.pop();
    }

Popping an empty queue has strange consequences; in fact, on my machine, it segfaults.  You’d think the queue would be resilient to that behavior but it isn’t.  Also, you have to get the item off the front in a separate operation from actually removing the item.  This is so you can store anything in the queue – pointers, reference objects, etc. – and obtain the item in the front of the queue and know it will survive long enough for you to do something with it.  You pop() the queue after you are finished with the item.

That’s all fine but it makes our threadsafe queue a bit of a problem.  Suppose we decide to follow strictly the STL queue API.  In that case, we’d perform an “if not q.empty(), then q.front() and q.pop()” dance.  We have to assume that each of those three actions is legal on its own though, and we surely can’t release the lock after each one.  So that would mean that the user has to obtain a lock on their own, to be used outside of the whole three-step dance, which breaks one of our rules, namely, that the user shouldn’t have to deal with thread safety.

Okay, so what if we abandon the need for strict adherence to the STL queue semantics, and instead just implement a pop() method that does everything?  Now we can hide the thread safety management from the user.  But now we have a different problem.  How do we know whether the value we get back from pop() is a legal value?  How do we know whether it came from the queue or whether the queue was empty and there was nothing to pop()?  We need some way to check to see whether the value coming back is valid, i.e., whether there was something in the queue to pop beforehand.

There’s a couple of ways to do this, but none I like.

• If the return value were a pointer (or an iterator), we could check for NULL (or end()).  However, we don’t necessarily know that.  If the class is a template, and if we always get back what we put in, we can’t know whether the return value is a pointer or a value or a reference.  True, we could cast the return value to a pointer type – but then, not only are we not returning what we put in, but we are getting into a rather scary situation where the user is required to massage the data before it can be used properly.  And we lose type safety.
• We could return a std::pair<bool, t> where t is the type used to populate the queue.  Not as scary as the casting solution before, but still with the problem where the user has to massage the data, and the return value isn’t strictly what was put in (although it is contained in the pair).
• We could throw an exception if the container is empty, but an empty container isn’t exactly an exceptional case and is probably not a good ethical candidate for throwing an exception.
• We could stop using the STL queue and create our own queue with more reasonable semantics.  However, although I’m not necessarily in love with the STL queue, I’m also not convinced I can do it better, at least not convinced enough that I want to spend the time to do something that already exists.
• We could do away with making the wrapper class a template and instead make it implementation-specific.

Since I don’t know for sure that I will need my threadsafe queue for anything other than a very specific data type I have in mind right now, I chose the last option.  This is the agile way – I’ll meet today’s requirements today, and trust that I can refactor the code to meet future requirements when they show up.

So now everything works great, except doing the wait on the condition variable, which normally looks something like this:

    mutex m;
    condvar cv;
    m.lock();
    if (q.empty()) cv.wait(m);
    v = q.pop();

Yeah, here I am, managing thread safety outside of the queue again.  I really should put this into my threadsafe queue also; except I would need a method something like waitThenDo(action) where action is a function pointer or some other callable.  I hate how that makes my code look though.  And at this point, with the waiting done as shown above (roughly), my code is working, so I’ve stopped caring.

But if you have a great solution to this problem, I’d love to hear it.

Yesterday the Linux Developer Network published an article I wrote on GNU Autotools. I originally wrote this article when I worked for Novell’s Developer Services organization.

If you are interested, you can go here to see the whole list of all the articles I wrote for Novell.

EMC has created a new subsidiary company, named Decho. The new company was created from Mozy and Pi, so I’m a part of this new company. The name “decho” is derived from “digital echo,” referring to your cloud-stored data as “your digital echo” in the cloud. Decho is a cloud-computing company.

So, Matt. What do you think of the new name?

Decho should be a really fun new venture. The competition is formidable – Google, Microsoft, Amazon, IBM, Apple – in fact, formidable is a bit of an understatement. But I do really believe that there is a market for a platform-neutral cloud computing solution that makes its money by keeping your data safe, secure, available, and private, and not by mining your data for other profit ventures.
I’m on the Decho train. I’ve done this ride before, and I have no reason to think anything other than that this will be at least as successful as the last fully-owned-subsidiary-spinout company I was a part of before in my career, named Volera.

Yes. What about the name?

Well, Mozy is already a very successful product. We have over 1 million customers, as I understand it, and we’re continuing to grow.

Alright, but let’s talk about Decho. What about the new name?

Yes, Mozy is a great place to work. We’re in a brand new building, there are many very cool people there, and even Alen Peacock works there. We have our own Rock Band setup on a high-definition TV in the breakroom, which is generally stocked with a variety of snacks. And it is great to work on a product that you know is being used by people all over the world – and should be used by pretty much everyone.

The name! What about the name?

Mozy’s technology is truly incredible. The backups happen pretty much automatically. The data is stored in a very safe and very secure fashion. You get unlimited backup for only $4.95 a month. What’s not to like?

I’m asking about the name. What do you think of the name?

I really like the name. Mozy is a nice, short word, that means nothing, is hard to pronounce wrong, and just eminates the awesome. I’m totally on board the Decho train.

Not the Mozy name. The Decho name. What is your opinion of the name?

Err, what? What was that? Uh … ok, sorry, I have to go now.

What we know so far:

What we know so far:

• A computer is a unique invention in that, through programming, it can be customized to solve many different kinds of problems.
• Programming a computer simply means to provide a computer with information.
• In order to program a computer we have to translate our ideas into a language it can understand.
• Computer language is just a code comprised of sets of electrical switches turned on and off.

In this post we’ll talk a little bit more about the information given to a computer. Basically, information given to a computer falls into one of two categories:

• Data
• Instructions

Data means a quantifiable description of something. Here are some examples of data:

• G – a single character
• True – a truth value (often called a boolean)
• 5 – a number
• Hello – a word
• AAPL, IBM, MSFT – a list of stocks
• 6’2″, 215 lbs, peppered hair, blue eyes, skinny ankles – a description of myself

We can see that data can be really simple or really complex. No matter how trivial or complex, data is really just a quantifiable representation or description of a thing.

Instructions are simply operations that we perform on data. Here are some examples of operations:

• Add two numbers together.
• Invert a boolean value, i.e. make something that was True into False.
• Reverse a string, i.e. make “Hello” say “olleH”.
• Add another stock to the end of a list of stocks.

No matter how simple or complex an instruction is, remember, it is just an operation being performed on data.

Amazingly, that is all that a computer program really is – performing instructions on sets of data. When we start out, we will use very simple kinds of data and very simple instructions, like adding two numbers together. These simple examples will primarily be using data and instructions that are defined by the programming language itself. Later, we will learn about defining our own instructions and our own data. For now, remember: every piece of information in a computer, and in a computer program, is either a piece of data or an instruction. Don’t complicate it!

As we discussed in the last post, programming a computer is the process of manipulating the computer to do what you want it to do – to make this generic invention into a specific invention for your task. Programming a computer is nothing more than telling it what to do. So the tricks of programming are:

• Giving the computer clear instructions so it will do what you want
• Translating those instructions into a language the computer can understand

A computer is very much like a well-trained dog: A computer will always do exactly what it is told, if possible. You may be thinking that this is not correct. Actually it is completely correct. Unless what you want the computer to do is impossible (like divide a number by zero), a computer always does what it is told. Where the confusion comes in is that often a computer is not told to do what we thought we told it to do.

What is sometimes frustrating by a computer is that it does a poor job of understanding intent. It takes every instruction literally; it cannot interpret what you really meant to say. So one of the challenges in computer programming is in learning how to express ourselves clearly so a computer will do exactly what we tell it to do.

That’s only half the battle, give or take. Translating those instructions into computer language is the other half. So what, exactly is the language of a computer?

To understand this, let’s digress a bit and talk about Paul Revere’s midnight ride. Prior to April 18, 1775, Paul Revere and Robert Newman had come upon a code whereby Newman could communicate to Revere the movements of the British troops. They agreed to communicate via lanterns: one lantern if the troops were moving in by land, and two lanterns if the troops were moving in by sea.

Let’s use a zero (0) to indicate a lantern that is turned off and a one (1) to indicate a lantern that is turned on. Here is the complete code that Paul Revere and Robert Newman agreed to:

The first code is the obvious choice – no lanterns means nobody is coming. The second and third codes are just reverses of each other. Since Mr. Revere could not determine positionally one lantern from the other, holding up either lantern by itself in either of Mr. Newman’s hands had to signal the same code – coming by land. And, of course, two lanterns meant they were coming by sea.

If you understand Paul Revere’s code, you can comprehend how computer language can be based on switches. In Paul Revere’s code different combinations of switches, or lanterns, being turned on or off meant different things. Other than having different codes, computer language is essentially the same.

The smallest piece of computer information is called a bit, and it represents the state of one switch – off or on. We use the same notation as we just described – a zero (0) means off and a one (1) means on. The smallest logical grouping of bits is called a byte. On most computers today a byte is eight bits. For example, the byte 01000001 could be used to represent the letter A, 01000010 could represent B, etc.

Most of the computers we used in the late 90′s were called 32-bit machines. This refers to the size of an instruction – 32 bits. Most newer computers today have instructions that are twice as big – 64 bits. For example, on the computer I’m typing on right now, it uses 64 bits – 64 switches – to encode every instruction and every piece of data.

Fortunately for us, we don’t have to actually learn the computer’s language, the zeroes and ones a computer uses to understand data and instructions. We instead learn computer programming languages – like C or Python – and let tools translate our instructions, written in a programming language, into ones and zeroes the computer can understand.

And that pretty much leads us into the last point of this topic. In this series of posts we’re going to learn to program using two different programming languages, C and Python. Each language has a different approach to giving instructions to the computer.

The second language, Python, is what is called an interpreted language. We write code in Python, and then we tell the Python interpreter to interpret our code for the computer to tell the computer what to do. This is kind of like going to the market in a foreign country, with a friend that speaks our language as well as the foreign language. As we walk through the market, we tell our friend to communicate a message to the shop owner, and after having done that, the friend relays back to us the results of our communication.

The first language, C, is called a compiled language. Programs written in C are given to a compiler, which translates the program directly into machine language and makes a runnable application out of it – something the computer itself can run on its own. This is like telling our friend exactly what we want from the market and having the friend compile together all our instructions at home first. Then the friend goes directly to the market and does what we wanted.

Both types of languages, compiled and interpreted, offer two different approaches to the problem of converting our instructions into computer language. Later we’ll cover advantages of each approach. For now, the key is to understand what it means when we say that a program is compiled or interpreted.

So we’ve learned basically four things:

• In order to get a computer to do what we want we have to give clear instructions.
• In order to get a computer to do what we want we have to speak to it in its own language.
• Computer language – instructions and data – is basically comprised of codes represented by groups of switches that are all in certain states of being on or off.
• Computer programming languages are translated into computer language, either via compilers or interpreters.

We’ll start learning to program soon. Stay tuned!