At the last Intel seminar I participated in, James Reinders, the Chief Software Evangelist & Director of Software Development Products at Intel, made a great comment when asked a question. “Intel has no opinion yet on that matter. I’ll give you my opinion, which usually becomes Intel’s”. I love this statement for it exemplifies our differences: I keep my opinions to myself, his become press releases.
As you might know, RADVISION participated in the Intel Developer Tools seminar, where they focused on the new Intel Parallel Suite tool that was just released. They asked me if I could speak at the event because of my success with the tool in its beta form, as well as the success I had with the post I later wrote about it (89 unique visitors. I’m getting pretty good at putting my hands on those unique IP addresses…J ). Before I was able to give them an answer, my boss answered for me, and without further discussion, I was off to the seminar.
Agenda
The seminar was all about multi core parallelism. An introduction was given by James Reinders regarding this new approach in programming, and about how Intel can help us developers achieve parallelism through the usage of their various tools. We had a 3 hour demonstration session on those tools, with live results on “before” and “after”. We also had some very… YAWN… interesting… z..zzz…zzzz… marketing presentations.
That said, a few lectures got my full attention, and I would like to elaborate.
The Academic Perspective
This lecture was given by Dr. Ami Marowka from Bar-Ilan University. The full name of the lecture was “Pitfalls and Issues of Multi-Core Programming: OpenMP vs TBB; The Academic Perspective“. First of all, he dramatically claimed, that parallel programming is very very hard (as if calling pthread_create() is that complicated. Right?). It is a revolutionary approach, very different from serial programming. As a professor, he claims that Israeli Universities do not teach this and if someone wants to learn, their only option is to be taught by an expert in the field, while on the job.
The second section of his lecture focused on what OpenMP and Intel’s TBB, can and cannot give us. As an example, he showed us a very simple code snip that can never be parallelized as-is by both approaches:
for (i =1; I < 10; i++)
a[i]= a[i-1] + 7;
As this is a case of data dependency, one cannot parallelize this code section because the result of one operation is dependent on the data calculated in a previous step.
He then showed some benchmark results of a comparison between OpenMP and TBB, suggesting that for most cases, TBB is better. This was interesting, as OpenMP defines compiler directives. If Intel implements OpenMP on their compilers, Why is that different from their TBB? I will get back to that later.
Anyway, I hope some students took good notes on his lecture, so I can copy them before the semester exams… Oh, wait; I’m no longer a student!
Parallelism Roadmap
The second interesting session was at the end of the day, again given by James Reinders, about the possible future parallel tools being developed by Intel. He spoke about vTune as the tool for the experts (planning to make it even more complicated), why they won’t integrate its technology into the parallel suite. “If I need to explain someone what ‘cache’ is, I don’t want him to use vTune. He probably needs to use the new suite” - his words. Good thing I know what it is. He explained a little bit about Ct which looks very promising, then switched to the chip domain, explaining a bit on Nehalem, Larrabee and Atom, and basically showed us Intel’s plan to rule the world.
The Main Event - My Lecture
This was a RADVISION presentation, and aside from Intel, we were the only other company speaking at this conference. Sagi Subocki, one of our product managers, was first to present an overview to our solution and then about our optimization experience. After that, he called me to the stage to give my lecture…
I don’t want to talk about it. I’m still recuperating. It was the scariest experience of my life: 200 people staring at me… I said I won’t talk about it. You can see it yourself:
We made such a good impression, that the guys from Intel came to visit us in our office the next day. After the necessary introductions, I gave James Reinders the lecture I had the other day, only in English, and then shared some of my insights regarding the parallel suite, like what was missing, what can be improved, etc. He was kind enough to give us a glimpse at Intel’s software group roadmap for the next couple of years.
Getting back to the TBB/OpenMP comparison, he said that it is indeed very strange In his opinion, TBB should not be better than OpenMP, but rather just another approach to parallelism engineering. So this still remains a mystery that might forever plague us. He did indicate that there is a huge performance gap between the MS OpenMP implementation and the Intel one, in favor of the latter.
My Conclusions
The obvious and more acute one: there are far too few females in the software engineering industry. Out of 200 participants in the seminar, I think only 10 of them were women. And it was kind of sad that there was not a single female lecturer.
Parallelism is here and is not going anywhere. Even Atom will become multi-core eventually (”not promising anything”, cautions James). We will have to start thinking differently. Parallel optimization will be part of the regular software release cycle, just like the rest of the tools of our trade.
The guys in Intel are doing a great job. I Never realized how big their software tools business is: IPP, TBB, vTune, MPI libraries, Ct, and much more.
Evangelist? In the holy land??
All in all, it was a very interesting experience. Can I go back to coding now? Please?
In a previous post, I linked to Dan Teasdale’s design lessons, as learned from “Rock Band“. In this post, and in the next few posts, I will analyze Dan’s ideas for game development, and try to apply them to development in general.
The first principle Dan mentions is “The One Question“.
Decisions, Decisions
Software development is a series of decisions. The Product Manager, customer and/or Project Manager (or equivalent) can provide requirements, statements of work, high-level design, even low-level design, but the person doing the actual coding is still left with many decisions:
How to initialize?
How to destruct?
Which events should be synchronous?
Use more or less parameters?
What should be the exact call flow?
What to do in an error case? Handle automatically or consult the user?
All these decisions could annoy your customer, but they could also make him love you forever. Do you know the feeling you get when something works just as you expect it to? It’s a Zen kind of feeling, of being one with the universe. You want that for your customer.
Dan Teasdale’s method for achieving this is called “The One Question”, meaning that instead of micro-managing every decision your team makes, you present them with a question that defines the essence of the product. Then each decision a developer makes is inspected in light of the One Question, as the result has to fit the question best.
The example Dan makes is related to the development of “Rock Band”:
“Is it an authentic band experience?”
Big Rock Endings - yes
Powerups - No
Back from the Brink - yes
Guitars on Fire - No
Solo Bonuses - yes
Minigames - Big No.
And Now for Development In General
Can one question, the “One Question”, really define something other than a game? Can it define an SDK - something that means different things for different developers?
The best way to test this is by trying to ask the One Question regarding our new and shiny BEEHD product:
Is this a high-end (video) phone experience?
I put ‘video’ in parenthesis because people may not have much experience with video phones, but we definitely know what to expect from our phones. And we know high-end experience from a low-end one. Different people may have different ideas as to how a “high-end video phone experience” should be, but this is true also for ideas of what a “rock band experience”.
Let’s try to make some decisions in view of the One Question we just asked:
Simple, easy to understand state machine - Yes
Low-level configuration - No
Automatic error recovery - Yes
Interactive operation - No
Smooth video - Yes
Delay - Big No
Surprisingly, this seems to work very well.
Now, what about SDKs? Let’s try to ask a question defining the essence of our Diameter stack:
Can it be used to build a robot army and take over the world?
Extreme question, I admit, but my first thought was of Star Wars, where Obi-Wan goes: “these are not the droids you are looking for”…
Pffft, Clones. This would not fly with my robot army. Every robot on the planet should be able to authenticate and authorize (or deny) and droid certificate. And they should do it quickly and reliably. So let’s make some example design decisions:
Multiple levels of APIs - Yes
Automatic error handling - No
Network error resilience - Yes
Static resource usage - No
Expandable in every possible way - Yes
Jedi Mind Trick prone - Big No.
It works well for SDKs too. This could potentially replace the classic product manager interface for answering every little design question. And it also relates well to Agile programming, if you’re into that. This would also be a good guideline for QA - test this like it’s going to go into a robot army, test that as if it’s a high-end communicator.
The One Question paints a big red target for where you want to go. Some developers may still miss the mark, but it will get everyone aiming for the same direction.
This isn’t a link blog, but I think this link should be shared, and I don’t have a Twitter account. So without further ado, here is Dan Teasdale sharing Design Lessons Learned From Rock Band - make sure you download the slides (that’s where the beef is). I started reading it because I love Rock Band, but Dan brings up issues of design, redesign, software development cycles, management, communities and dealing with the unexpected that are much more universal than game design. It’s a long slideshow, so I’ll let you digest. My Impressions of it, especially on “The One Question”, in a later post.
Have you ever been to Japan? My experience was very strange. Everything seemed familiar at first glance, but when I tried something - walk the streets, ride the train, buy at stores, use the washrooms - I realized that nothing is as it seems and everything is different. So different it might just as well be another planet - complete with strange glyph writing, unexpected underground passages, and strange stuff for sale. Remind me to tell you about the half Santa*.
A Japanese experience
Why am I bringing Japan into this techie blog? Because of software porting. Porting software from one operating system to another is much like visiting Japan: everything seems familiar - same concepts, same services, same methodologies. But when you try to use them, you realize you’re not in Kansas anymore. Take Integrity, for example. We just finished porting our SIP stack to Integrity 5.0, and by “we” I mean Igor Novoseltsev, our resident expert. I sat with him to chat a bit about his experiences and lessons.
When I say, “porting the SIP stack”, I actually mean porting the Common Core, our OS abstraction layer. All of our products use the Common Core layer to access the network, use threads and locks, allocate memory, log, for standard data structures, etc. It saves a lot of time and effort, especially when porting. Once the common core is ported, there is only a minor effort to port any of the products that use it.
Integrity OS
Integrity is an operating system developed by Green Hills Software (GHS). It is a real-time operating system for embedded systems, designed with reliability and security in mind - this is achieved by using hardware memory protection to protect tasks from accidental errors or malicious tampering. It is proudly non-compatible with existing “80’s” operating systems (I think they’re dissing MS Windows), having been designed from the ground up. Luckily, that does not stand for “an unfamiliar set of APIs”, since Integrity supports the POSIX standards, common to many UNIX systems.
As our SIP stack contains an OS abstraction layer we call “common core”, and our common core already supports the POSIX APIs and was compatible with Integrity 4.0, we recently embarked on a mission to port it to Integrity 5.0, the latest release of the Integrity OS. Why? Because a customer asked for it, of course.
GHS provided us with the operating system files for the embedded system and their equivalent to the Microsoft’s Visual Studio IDE, Multi. Unfortunately for us, we usually use make files to compile our projects on non-windows systems, and we were reluctant to create and maintain a workspace for Integrity - having too many build systems isn’t a lot of fun.
Of course, the compiler and linker allow command-line activation, and although it was documented, there were some options and flags (used by Multi) which were undocumented. We asked for a little help from Green Hills representatives here in Israel, which were very responsive and provided us with sample make files, allowing us to compile our SIP stack and run it on the provided simulator.
Now all we needed was to try it out for real.
Going Embedded
The first rule of embedded operating systems is, and anyone who has worked on those will tell you that: it’s not over until it the board runs. Simulators have come a long way, but nothing can simulate the nooks and crannies of an embedded, real-time OS running on the actual hardware. However, it is also true that nothing is as frustrating and time consuming as trying to setup some new embedded system that just won’t do what you want.
The board we used was an Atmel ARM-based board (AT91SAM9263). We tried to bring it to life, only to discover, after a few frustrating days of work and with the help of the excellent Atmel support, that the Integrity version we had supports the AT91SAM9261, which, of course, is non-compatible with its -3 variant.
Again, GHS support came to our rescue and provided us with a compatible version, yet we discovered (in the documentation) that the only way to configure the board was with some device called a probe, or with a data-flash card. We had neither, nor the available time to order any (the customer was waiting), and so we decided to move from the Atmel board to a TI DaVinci board - we had a few of those due to the BEEHD project.
Unfortunately, things didn’t go smoothly there either. Again, documentation insisted that we have to use a probe to burn the kernel on to the board. And so GHS came through for us once more: they invited us to their offices, where they can burn the OS on to the board for us.
And so we drove over, with the board in hand, only to discover that the exact version we used was not supported. No surprises there, as we got it straight from the TI presses. (We and the TI homies are like this - you can’t see, but I’m making the thing with the fingers right now. See picture for details). But, as it is brand new, no support yet.
But while we were there, we saw another Atmel board lying around, and we were, like, “can you lend us a data-flash card?”, and they were all, like, “we don’t usually do that”. And so, to make a long story short, we drove back to our office with an Integritized data-flash card.
From there it was easy to bootstrap U-Boot to the card and setup a TFTP server that will get our binary application, copy it to the correct memory location (0×2000000) and run it. The wonderful assistance from the AT91 SAM Portal community (supported by Atmel) and the U-Boot project didn’t hurt as well. Another few days of work and we had it eating from our palm, that is, running SIP. Customer happy, sale done, money in bank, nice PR to show for it (a PR is the sales equivalent of a T-shirt, isn’t it?)
So, What Did We Learn From All Of This?
Green Hills Software has a wonderful support team here in Israel. Thanks again, guys.
Atmel has a great support team as well. With the amount of products they provide worldwide support for, it is nothing short of miraculous.
Community sites are great for mental and actual support.
Document everything as you go. The next programmer to try the same thing will run into the same problems, so why not save him some of the bother? Here’s what we now have on Integrity: Integrity for ARM Howto (566.96 KB)
I’m probably late on the wagon with this, but I just discovered that standardized protocol interfaces are fast becoming commonplace - and I’m not talking about the network-side interface, I’m talking about the application-side interfaces, also known as APIs, or should I say open APIs.
APIs used to be a matter of taste and design, pride and prestige; they were known to make or break an SDK. All this is about to change, as APIs are being standardized, and SDKs from different vendors will be interchangeable as your network card or USB mouse. Add to this the low cost of general-purpose processing units (GPPs) and you will understand why software is taking over traditional hardware roles (think about washing machines and cars).
Am I taking this too far? I may be late, as I said, but I’m afraid I’m dead on target.
Wikipedia Ride
First, a little disambiguation: web 2.0 has been with us for a while, with its service description language, remote procedure calls, Open APIs, you name it (and I’m not linking to the Wikipedia definition of these. If you don’t know any, just Google it up). I’m not talking about these. I’m not talking about network communications at all.
I’m talking about good old software libraries. I’m talking about a very specific form of Service-oriented architecture. I’m talking about Component-based software engineering and Modular programming, but not quite. I’m talking about a form of the old COM, KPart and Bonobo. I’m talking about, ladies and gents, what OKI, OpenInterface and many others are trying to do as I write these very lines: full encapsulation, reusability and interchangeability of any software component.
We’re still not there, of course, but it’s completely within reach. Look at how hardware is getting along just fine with the “plug-and-play” concept. I could go to any store, pick up any hardware, plug it into any computer, install a driver (which the OS does automatically for me in most cases), and in 99% of the time it will work like a charm. So why isn’t software like that, apart from (aforementioned) sporadic examples? It is all for the lack of one, agreed, open, standardized, application-programming interface.
We VoIP developers are used to having a standard under us, but will we adapt that easily to having a standard above us, in our connection to the application?
VoIP Industry Implications
Let’s pretend for a moment that we have such a standard. Answer these questions, please:
Standardized or Proprietary?
SIP or H.323?
In-house or outsourced?
Open Source or Commercial?
The answers are, by order: both, both, both and both.
Why would you settle for anything else? Especially if you can develop over the very same interface, first a proprietary proof of concept, then some basic SIP you whipped up, adding an open source H.323 when you branch out to the enterprise market, and replacing them all with a commercial implementation when your company grows. And when a new protocol arrives, you will just add that below your existing code.
A unified API may seem unreasonable when you consider that each service provider has its own set of requirements and limitations. I think that it is unreasonable, economically, to think that this can continue for long. Sure, there are advantages and specifics for each protocol type and implementation variant, but for mainstream make-a-call scenarios, a unified API is feasible. There will be some pushing and pulling between different power groups until the standardized API will be stable, and there will be some gaping holes allowing non-standard operation, but we’re used to that from the network protocols standards. Moreover, protocols learn from and imitate each other, so a novel functionality in one is likely to be mimicked in another. The developers of protocols will have to design protocol stacks that will be adaptive to many environments, perhaps specialized flavors of their toolkits to different environment.
It’s hard to guess the effect this will have on the industry. It will require more extensive testing, and some rethinking of the design, especially error handling. It will probably push the whole “strict protocols” thing straight out the widow. I expect script protocols to become big, since they solve many issues of implementation variants. I think system security will be better, but it would require more maturity on the part of users.
Eventually, I think every user (and his mother) will become a part-time system integrator, selecting between components on the fly. It will be like installing a mouse, keyboard or mp3-player*. If one SDK doesn’t work, the user will replace it with another that does. SDKs will eventually become a consumer product, part of the whole ecosystem of service mash-ups (and yes, I do believe service mash-ups won’t be just for know-it-all geeks very soon).
Whoever plays best with others will probably win.
* As a matter of fact, I think the main difference between inserting a USB device and connecting a card to the motherboard is the user-friendly plastic in the former and the use of a screwdriver in the latter. For some reason, people associate screwdrivers with technical expertise.
Google broke our RSS feed. FeedBurner, which we are using now, is being moved over to the Google “platform”, which caused some problems involving their MyBrand service, Yahoo Pipes and a bunch of other minor inconveniences. Don’t know, don’t care. Remember what I said once about strict decoding and all that stuff? I lied. That might be good for signaling, but for the media, for something that humans are supposed to be consuming in the end, accept anything that you can make remote sense of, in hopes that the human in the end would be able to receive it, or maybe realize that something is wrong and try to fix it from his end.
Well, we’re back. We managed to fix what needed fixing.
As it was, people didn’t get the feed for a couple of months. Therefore, I’ll review what you missed.
TODO or not TODO, That is the Question
One of the customers went over our code, and found many TODOs in the code. That made me think: from the client’s side, isn’t checking for TODOs in our code a little bit counter-productive? The direct result would be that we will remove the comments from our code, and will be more likely to forget about them. When a programmer writes a TODO comment, it could mean one of several things, not all bad.
Commenting Can Be Bad For Your Soul
Following the post about the usage of TODO style comments, I asked the developers here at RADVISION to send me stories about inappropriate comments that they found in code. A wicked funny post, plus a guide for writing your own bad comments.
By the way, I also wanted to write an additional post about assertions, but Miško Hevery from Google’s Testing Blog beat me to it.
Why I Won’t Work For Joey DeVilla
Joey DeVilla writes about Captain Chesley “Sully” Sullenberger, and drives his point home with his recommended interview question: “What do you do in your spare time?” I don’t code, Joey, and I want my employees to have interesting hobbies.
“Hello, I’m a Slave” “And I’m a PC”
While your PC may be the grease lightning of computers, it usually can’t handle multiple, intensive memory, disk and network accesses. That’s where the Slave Computer, or SC, comes in, to aid the PC, the Primary Computer. This post covers some uses and utilities for a Slave Computer.
About The Intel Threading Tools, Our SIP Stack, and Me
I asked Ofer Goren, a software engineer in the SIP Stack team, and one of those given the optimization task, to write a few words on multi-core optimization. Spoiler: they increased calls per second by 50% (!), to 94% core utilization.
[I knew that our SIP team was working for a while on multi-core optimization. So when there were signs of oil there, with some very promising results, I asked Ofer Goren, a software engineer in the SIP Stack team, and one of those given the optimization task, to write a few words on the process. You might even appreciate the work we do here for our customers, toiling around with analysis tools.]
“Hardware is cheap, programmers are expensive” says Jeff Atwood. So it’s better to spend your money on hardware, and not on optimizing your code. I wish we could say that to our customers and my boss, but he has this nagging habit of asking me to do things. Like, well, optimizing our code. More specifically optimizing it to this new multi-core technology. Hmpfff.
Therefore, over the past several months, multi-core optimization was my main focus. After identifying areas that can be optimized for scaling our SIP Stack performance to the level of CPU cores in use, we decided to put some effort into it. Hence the coming SIP Developer Suite version (5.5 GA2) will include code changes aimed to optimize multi-core performance in such environments.
I will describe in short what tools we used, why, and how they helped us with the task at hand.
What and Why
So the “what and why” questions were quite easy to answer. It was an obvious choice to look for some tool running on MS-Windows. After all, most of our development is done in a Windows environment before being ported to other operating systems, our IDEs and debugger run on Windows, and for me, at least, working with GUI is easier (sorry, but emacs is better than vi). We already had an installation of Intel Thread Profiler and Intel Thread Checker. In an incredible coincidence Intel approached us, suggesting we become part of the beta program for their next generation threading tools. Need I say more? I guess the choice was made.
How
So we installed the new tools, and started playing with them a little. After some fooling around, an eye-opening window appeared:
Wow. Out of 204 seconds of CPU run time, almost 60 seconds are spent on doing… nothing??? It just waits there? On a freaking Mutex?! Heads will roll, I thought to myself. Let’s see who’s to blame:
Hmmm… we had several suspects, but it seemed that this “HandleIncomingRequestMsg” was just lying there, enjoying life, smoking (which is bad for you), while blocking everybody from doing their job…
I was interested to know if the legacy Thread Profiler tool agrees with those observations. The Profiler tool makes you work harder to get the same information, but I realized they share the same understanding: some cores are getting paid for no work at all! I knew we had to do something with this code.
To get a feeling of the extent of the issues at hand, Intel’s thread profiler can give an easy to read picture of CPU utilization by giving the concurrency level of the program running. The higher the right bars the better.
In the image above, you can see that most of the time, the test executed uses a single thread only, while the rest of the threads are idle. You can drill down from this view to your heart’s content and spend hours looking at your code.
And that’s how we identified potential areas that can be optimized, one at a time, focusing time on the largest bottleneck.
What I Learned
I was kinda clueless at the beginning of the process. I was told to optimize the code for multi-core CPUs. Well, great, how the heck should I do that? I just work here, remember?! So the Intel Tools came to the rescue.. It told us everything we needed to know, in my all-time favorite GUI way, identified potential areas to work on, and gave us a methodical way to scale up and improve our code (Yeah, right. As if I wrote THAT code…). The work done improved performance on all architectures, not just Wintel. What can I say? They’ve got my vote.
My takeaways here are quite simple: when locking objects for a multi-core application that needs to scale:
Make the locks you use as granular as possible (multi-level hashes, locks on objects and not on arrays, etc.). Bear in mind that while you do that, you increase memory usage and resources, so there’s a tradeoff here.
Locks should be as short as possible. If you lock large pieces of code - you’re going to pay for it. with your time and with the cost of Intel’s tools
The Bottom Line
We started with 65% core utilization. After several months of work, we increased calls per second by 50% (!), to 94% core utilization. So if someone asks me, the Intel threading tools are the right thing for you. Smoking, in case you missed it, is not.
I’m now maintaining and developing code that was out of my hands for a long time, and I found an interesting phenomenon I call “bad medicine”. The developer in charge of the code while I was gone knew something was wrong, but could not figure out how to fix it. So he added a crutch here and a splint there to keep the sick code “breathing” and quickly moved along.
Let me rant a bit about my experience with Programmer Joe and his bad medicine.
1. An Unhealthy Dosage: Code replication
Why, I wondered, would Programmer Joe copy a large code piece only to do some minor changes in it? Only half way through refactoring the code, I realized the answer: Old P. J. didn’t understand the code enough to be fix it inline, so he just copied it and tweaked it until it worked the way he wanted. Nice work, Joe. Customers love increased footprint and a healthy dosage of repeated bugs.
2. The Splint: Data out of place
There were definitions inside the code file that were moved to the header file. That was weird, even for Joe. These weren’t functions made public, you see, these were data, large arrays of data, defined as “static const” and moved to the header file. Again, I figured the footprint-conscience customers must love Joe, but why, why, why?! I moved the data arrays back to the code where they belong, and recompiled to reveal the errors - in our sample code. Now, if your own sample code needs you to move data to the header file, you know something is wrong, but you should also know that what you are missing is an access function. Actually, there was an access function, only Joe didn’t know it.
3. The Crutch: Constants from heaven
Knowing what arguments to pass to some function can be tricky. How lucky was Joe, then, to find such a handy definition:
#define ARBITRARY_NUMBER (5)
Ah, wait - it was the other way around, wasn’t it? This time Joe felt responsible enough to make it obvious, other times constants just appear out of thin air. Joe couldn’t be bothered to find the real value to pass, so he found a value that works - most of the time, at least. Now, every time I see some obscure definition out of place an alarm goes off in the back of my head.
Repeatedly in programmer Joe’s code, error codes were returned for various reasons: Data was not there? Return an error. Wrong state? Return an error. Don’t know what to do? Unexpected input? Feeling sad? Return an error. Not always wrong, of course, but actually attempting to handle the problem might work better.
What’s worse, is P.J. returning an error to a caller that’s not interested: a timer pops, the function encounters an error, so Joe decides to return an error. The timer engine doesn’t care, of course, so the error is never handled. An attempt to do something, even if it’s notifying the layer above or even log the error, would have worked much better.
5. Prayer and Positive Thinking: Holy code
Joe finished his sacred work and felt much better; the sanctity of the code was not harmed. He only had to duplicate some data, and reverse half of what the “holy code” did, but the code itself was not touched. Joe said another little prayer for the health of whoever wrote the code years back and went on with his life.
Holy code is the hardest to catch, but it’s really worth the while. You have to look back through the versions and see what code was left untouched - no code is that good. It is more likely that that piece of code was sanctified, and any bug in it was undone before or after it.
So are YOU Programmer Joe too?
If you’re given someone else’s code, and you need to maintain it, please: MAKE SURE YOU KNOW WHAT YOU’RE DOING BEFORE YOU START MUCKING AROUND!
See, while your PC may be the grease lightning of computers, with its quad-core dual CPU configuration or what-have-you, it usually can’t handle multiple, intensive memory, disk and network accesses. That’s where the Slave Computer, or SC, comes in, to aid the PC, the Primary Computer.
I first discovered the miracles of the PC-SC configuration about a year ago, when I got my new laptop. It was fast and all, but as my version control software was installed and configured on my old PC just the way I like it, I decided to keep using it there, and started using remote desktop from my new laptop for all my version control and bug tracking activities.
This turned out to be a huge success, since version control operations are “heavy” processes, that can take a long time to run, and offloading them to a different computer meant I could run them while I keep working on my new, and now vacant, PC.
The next step was to get the old CRT monitor, plug it to the “slave” computer and put it on my desk, alongside my new LCD screen, so I could view both computers at once. I also connected the SC to my speakers, so playing music while I work was also “diverted” to the SC, leaving more CPU to the PC.
Clearing the Desktop Clutter
This is all very well from a CPU point of view, but it wasn’t very comfortable when it came to elbow room. Two monitors, especially when one is an old CRT, tend to clutter your desktop. Add to that the two keyboards, two mice, and you suddenly get a wierd “computer lab” experience.
The double input devices had to go. I downloaded and installed “Synergy” (for free!), which allows me to use a single mouse and keyboard as inputs for multiple computers through the network. As a bonus, the clipboard is also “shared” with the input devices, allowing me to copy-paste from one computer to the other - alas, just text, not files.
Next came the desktop search software. Google Desktop Search, which I was using, was conflicting with the McAfee’s antivirus I am using, causing increased disk access and CPU load. Trying the Microsoft and Cupernic desktop search solutions proved unsatisfying (they did not index shared mailboxes), so I was back with GDS, only this time, installed on the SC. The conflict was still there, but I didn’t really care about it anymore - let them sort it out overnight. This revealed another advantage to the PC-SC configuration, especially when your PC is a laptop - the SC can keep working overnight, while the PC hangs out with you at home.
Dual Display? I Can Do Dual Display.
This worked well for several months, but when I showed it to one of my coworkers, he immediately asked if I could use both screens working on a certain application. No, I started to explain, these are different computers, so they can’t share a display. So, he said, you can’t open your Gantt chart over two screens for easy editing, or expand your mail reading pane to the other screen, or the search results on one screen and code editing on the other, none of these, right? Wrong.
After a little search (and thanks to Wikipedia’s multi-monitor entry), I found a piece of software called “MaxiVista” (30$ for the standard version). It adds a new display adaptor that is connected to the remote computer through the network, and it can take over the other screen on demand, resulting in a multiple monitor experience. Now I work with my PC-SC, and whenever I need more screen real estate, I take over the slave’s screen and expand my applications to it.
What’s next For My Slave?
So what did I have so far?
Used my old desktop as a Slave Computer (SC), connected to a screen of its own.
Used Synergy to use a single set of mouse/keyboard/clipboard to control my PC and SC.
Installed Google Desktop on the SC instead of my PC to offload all my search activities
Installed MaxiVista to use both displays for my PC if needed
Now I wonder what else I can delegate to the SC. Gadgets are an obvious choice, setting up the SC as a HUD or a dashboard. Maybe I could use it for remote compilations. Maybe I’ll call a couple of hard pipe-hitting niggers to go to work on the Holmes here with a pair of pliers and a blowtorch. You hear me, hillbilly boy? I ain’t through with you by a long shot. I’m gonna get medieval on your ass.
Captain Sullenberger (I’m not really comfortable calling him Sully) is a flight fan. His spare time activities, for all of his life, revolved around model planes, gliders, aviation, etc. - you get the picture. Joey sums up: “obsessions are one of the greatest telltale signs of success”. His favorite employee will be, taking after Captain Sullenberger’s curriculum vitae:
As a boy, he built model computers and network servers.
As a teen, he took professional programming courses and programmed for open source projects.
He was a network security consultant for a major company.
He’s worked with university professors to improve teaching methods and create new “secure programming” courses.
He runs a consultancy called Safety Reliability Networks, which helps companies improve their safety, performance and reliability.
<YAWN>
Pilot vs. Programmer
I’ll get right down to the main difference: a pilot is alone. A programmer works on a team. Well, that and the human lives at stake. In fact, I myself ask the very same question in interviews, and for me, “Programming” is not the right answer. When that person comes to work in the morning, I want him unwound and relaxed, not still thinking about his pet projects at home. When I eat lunch with him, I want to hear about his hobbies, not talk about work. My list of ‘good answers’ includes:
Building model ships
Study WWII history
Painting
Role playing games
Amateur acting
Gym
Spending time with family and friends
All of them, by the way, I heard in interviews. I also heard the answer “Programming”. I tried to find out if there is something else, if perhaps he said that because he thought that’s what I wanted to hear. He was all about programming, only programming. He was a good programmer, but I knew it would be hard for me to work with him.
More than my personal preferences, diverse teams work better. Teams need Doers, Thinkers and Carers. Teams need different perspectives and different modes of operations. Teams need people who are interesting and nice to work with, because when you care about the unique personality of each team member, you get your very own dysfunctional family of a team.
Going Embedded
