I realize it's been a long time since I posted anything in this space. "Surely," you think, "he's been working on fascinating projects. I can't wait to hear about these fascinating projects. Let the cavalcade of fascinating projects begin!" If you are thinking that, you're largely incorrect and you're also a little scary.
While I don't have anything particularly momentous to share, I do plan to share some stuff here in the near future. Before I do that, I must first think of this stuff, then type it up. It's in the pipeline, however, and I give everyone permission to get really excited.
We're tackling a pretty tricky problem at work right now. The application we're making allows the user to enter in an equation that we'll calculate for them. For example, let's say that one of these equations is Field2 from the database * 3 / 20. The user can store these equations in a table for use later on. The hard part isn't storing or retrieving or supplying the right values for the variables, it's evaluating the equation. Here are a few reasons why.
First, the equation is stored as text. A * isn't a multiplication sign, it's a '*', just another character. You have to interpret those characters as operators. That is to say, you have to know that a '*' means multiply. Will you support logs, natural logs, trigonometry? Right away, you're limiting what the user can do, because the only allowed operators are the ones you know to parse.
Second, you have to do something with the order of operations. Going back to the equation I listed before, you have to know that Field2 * 3 / 20 can't be calculated in the way we've outputted it. Instead, the calculations have to be done in a certain order according to the order of operations for us to get the right answer. (One of the few mnemonics that's ever stuck with me Please Excuse My Dear Aunt Sally, for the order of operations).
The order of operations is hard. If you don't believe me, try to come up with a rule of thumb for processing an equation like a^b/d*e^f/g*h^i^j. Where do you start there? You have to start at the right place, or else you'll come up with something distinctly wrong. Even if you know the order of operations, does the user entering the equation? It's possible that you can evaluate the equation correctly and deliver the wrong result, if they got their part wrong.
Assuming your language doesn't just have a magical evaluator that can handle these problems for you, you can apply some pretty far-out theories to problems like this. If you dig the formal language thing, you may want to dive into Parsing Expression Grammar and see what you can do. If you're a classicist, maybe Dijikstra's shunting yard algorithm will work (description is about halfway down that page). Don't let fancy terms like 'shunting yard algorithm' dismay you; it's just a way to transform something into Reverse Polish notation.
What do I suggest? Uhhhmm, I don't know yet. I'm going to meditate on it. I'm going to go to my happy place for a while, crunch the options, and see what makes sense. Right now, I'm leaning heavily towards just taping a Mickey Mouse calculator onto the jewel case when the app ships.
You've been working for months on a project. It's fast, it's slick, and the only feature it lacks is the ability to make waffes. People in the halls are talking about it, and inevitably, word has filtered down to the sales guys. They want to see it. They're not sure what your name is or what you do, but they want to see this app in action. How do you keep from screwing the demo up?
First, do a bunch of bad demos. Analyze what went wrong, and then apply those lessons. However, if you don't have time for that, I insist on sharing my own observations, gathered through my own demos that were both horrendous and glorious.
1. Make sure the app works. That sounds simple, right? In fact, it's almost too simple. If you've spent months working on a package, you know it works and you can navigate it like your name was Magellan. However, just because the software isn't crashing doesn't mean that it's behaving correctly. If it's performing a calculation, check the results in advance. If it's manipulating data, check the results by hand. A demo is a bad time to discover you messed up an algorithm, says a guy who has done it before (in my defense, I'm an idiot).
2. Write a script. If you were doing a demo for a group of mimes, what points would you make to them? Write that down in an easily-readable format; that's your script for the demo. The text should be concise and spaced-out (outlines work great), since you'll only be able to glance at it.
3. Throw in some metrics. If someone isn't a technical person, it could be hard to grasp just what an application does sometimes. To make it easier, share some numbers. "With this code, we can go from processing 10 widgets an hour to 10^78," or "This process is 2718% faster than the current one and could overtake the world in approximately 68 weeks." Don't make the numbers up; you should be able to demonstrate them if asked.
4. Practice. Once the software works and you have your script, run through the demo a few times. Do it for yourself and then do it for others, since that's a lot harder than just talking to yourself.
5. Stick to the script. If you're like me, you get nervous in these situations. Once the demo begins, don't worry about charming off their pantaloons with off-the-cuff zingers about the CEO's aftershave. You've already written what you wanted to say, so just follow that. The demo will be impressive enough without you babbling away.
And there you go. It's a simple process, but one that can definitely help you in looking like 78% less of a horse's ass (remember, people like metrics).
The following entry is written specifically for Google scavengers who are butting heads with the same problem I encountered earlier this week.
I've been on a huge automated build kick lately. Sure, it's cool to be able to generate a build automatically, but it's even cooler to do the build, run the unit tests, and generate all of the documentation. (What would be cooler still would be if it made omelettes at the very end. I'm not to that point yet.) Omelette making aside, I used CruiseControl.NET to integrate all of this, along with Nant for the build, NUnit for the tests, and NDoc for the documentation.
The problem I kept encountering is that I couldn't figure out how to make CruiseControl.NET and NDoc play nice. I had no problem building the app and running the unit tests from CruiseControl.NET, but I couldn't get it to call NDoc to generate our class library documentation. I searched and experimented for hours with absolutely no luck, and finally, I came to a solution that works. The secret is to call NDoc from Nant, NOT CruiseControl.NET. Nant interfaces very well with NDoc; take a look at its
If you're doing continuous integration in a .NET environment and you want to generate all of your NDoc documentation as part of this process, call it from Nant, not CruiseControl.NET.
Praise the Lord and pass the biscuits, I have like two more days of requirements left. I don't know if I've mentioned this or not, but I've been doing requirements nearly exclusively for six months now. It got old very quickly. The temptation to quit was strong. However, two things stopped me from doing so. First, I don't get paid for being pretty, no matter what you people think; I have to actually do what I'm told. Second, I thought of the entire development process as a big picnic. Here comes an analogy!
I like what I do; I think most developers agree. If I were forced into another line of work, I'd continue to code and design in my spare time because I like it. In a way, coding is like a leisure activity for me. For me, an afternoon of that is like an afternoon at a picnic, minus the crappy potato salad.
If it's a one-man picnic, it's pretty easy to arrange. I just make myself a sandwich, put it my picnic basket, and run. However, larger picnics are a little more difficult. You have to find out who's going to be there, what these people want to eat, and how much everyone will eat. You need to find out if the weather will cooperate, and what you'll do if it doesn't. The more people invited to the picnic, the more planning that must be done.
If development is a picnic, then requirements is the picnic planning. For most of us, requirements suck; I won't even accept debate on that issue. However, just like the plans for the picnic, they're needed. The better the plans, the better the picnic.
Imagine organizing a picnic for 20 people. You send out a huge email to all of them naming the date and time. Then, the date arrives and you show up, twenty minutes late with bare hands. "So," you say, "what'd you guys bring to eat?" Your friends promptly rise up and beat you into the dirt with any tree branches within grabbing distance.
Now imagine taking the other path. Imagine that instead of blowing the whole thing off, you invest hours and hours with all of the onerous activities I listed above. You do all of the planning, packing, and worrying. It takes forever and you hate it. Then, the date for the picnic comes. Not only does everyone NOT want to pummel you, they praise you. More importantly, you have fun. You put a lot of thought into your plans and it all comes out nearly flawlessly.
I realized this a few months ago, and it's this idea that's kept me going through revision after revision of my documents. I want this development picnic to be fun, not just for my coworkers but for myself. The only way for me to do that is to step up to the plate when it comes to the requirements. Of course, it hasn't been fun; if it were, people would want to do that instead of the actual picnic. These painful steps have been necessary, though,f or me and for everyone else on the team. And I know that now, having gone through all of this, I will be in a state of bliss for the entire coding and design process. That is, if I'm allowed to participate. If I'm not, I'm going to find a tree branch and get to whackin'.
I haven't posted anything here in a long while because I've been doing nothing but Requirements at work. It's been that way for quite a while. It's gotten so bad right now, if I saw a guy on the street approaching me with a gun, I'd ask him, "You're not going to make me do use cases, are you?" It's hard to be excited about anything, let alone this site, when my brain has smushed into a big, slimy requirements spec.
Anyway, during my hard months on the requirements chain gang, I've come up with something I called my Grand Unified Theory of Requirements. To write it all out would take way too long right now (although I plan to do it later), so I am just going to share the first idea right now. With all due fanfare, here is element 1 of the Grand Unified Theory of Requirements: a requirement is a hypothesis.
When I do requirements, I think of myself as a scientist, trying to formulate an explanation for a phenomenon. The phenomenon was the feature; my explanation was the requirement. What happens to hypotheses? They get tested by someone else. That's what happens with requirements. They get tested first by developers (Is it feasible?), then by testing (Is it well implemented?), and lastly, by the user (Is it what I want?).
Since the requirement will be tested so much, it needs to be clear, and more importantly, it needs to be concise enough that it can easily be tested. A requirement is a hypothesis; yeah, I do agree with that. Where the Bunsen burner comes in, I'm not sure.
Blogs.msdn.com is a pretty good site, in that it displays all of the recent updates to MSDN blogs. However, I've got to think there's something wrong with their code that actually creates this display. Check out the following screenshot I got from earlier today:
There's one disturbing line in that image; see if you can find it. If it's actually true, I guess MS has bigger fish to fry than Longhorn. Where are they getting the plutonium, though?
Woo doggies, after a vacation and a brief illness, I'm back to the vlog. Huzzah huzzah, sayeth the people. Unfortunately, the time away didn't provide me with any ground-breaking insights, like a way to make rhubarb pie from toxic waste. In fact, I had no insights whatsoever until I got back to work and saw an email from my boss that I was due for my annual review. At that very moment, something occurred to me: why on earth do developers need annual reviews?
Reviews are definitely useful. Your boss gets a chance to lavish praise on you, and you in turn get to make completely insane demands for a wall made of plasma tv's in your office. Yes, reviews are good; it's the annual part that makes no sense to me. In my mind, the length of time between reviews should be directly related to how long you've been working as a developer; the shorter you've been there, the quicker your reviews should occur.
When I first started working as a developer, I wasn't very good. I didn't try to eat the keyboard or anything, I just wasn't sure of what I was doing. I got better quickly, though. If I were to measure my usefulness, I'd say it doubled after my first week. After another week, it doubled again. A month later, another doubling, etc etc. Through such geometric growth, I made the hard journey from crapdom to nearly-adequate city.
When I think about how much better I got in that first year, I realize there's no way it could've been recognized or even communicated during an annual review. There was simply too much ground covered. The process would've been much smoother with a series of monthly reviews.
I just finished my second year, and it was much the same. I got much, much better, although my improvement rate was less impressive than that first year. Still, it was too much to communicate in an annual review. Maybe a review every three months would've worked better.
I'm just now getting to my real point. Essentially, reviewing based on time periods seems a little arbitrary. In my mind, we should get reviewed every time we get 20% better. In our field, the learning curve is incredibly oppressive, and it worsens every day. Each time we make an impressive step forward, it should be recognized. If it happens every year, then hey, that's great. Sometimes, particularly when a person is new to the field, it happens a lot more than that, and attention should be paid to these instances.
With regards to measuring and formalizing a procedure like that, I throw my hands up and then lock myself in my closet. It's complicated, definitely. At the same time, though, it's fair and perhaps not totally idiotic.
Last week, I went to the UML and Design World conference here in Austin and I completely forgot to write about it. Allow me to address this grievous error!
I only went to the conference for two days. This was not so much because I was busy, but more because a man can only handle so much UML. Once you subject yourself to an entire day of the stuff, you need some time off, lest you find yourself babbling about class diagrams on the roof of the post office later that evening. But I digress.
Alright, so the first day, the sessions I went to were both led by Robert Martin of ObjectMentor. The sessions were on Mastering Design Patterns and Advanced Principles of Object Oriented Design. The first session was great, with a lot of specific examples and implementations of design patterns, and I think I got a lot out of it. Also, he was a great speaker and a lot of fun to listen to. I also got a lot out of the second session, though not what one might expect. In that session, Mr. Martin presented some interesting ideas on OOD that riled a large part of the crowd. As one might expect at a UML conference, a few members of the audience turned it into a shouting match. The lesson from that particular interlude is to never let myself become one of those people. I'll save my shouting matches for important occasions, like when the cashier at HEB refusing to honor my Hot Pockets coupons.
I then skipped a day, and attended again on Wednesday. Then, I sat in on the Practical Application of User Interface Architecture Design Patterns (Underbakke), Estimating Effort Using Use-Case and UML Class-Method Points (Roetzheim), Documenting and Analyzing Enterprise Architectures (Vilot), and Managing and Measuring Functional Requirements (Herron). Factoring in all of the conferences across the entire universe, that may be the nerdiest slate of classes possible. Honestly, I was a little disappointed with these.
It seemed that some of the speakers were more interested in selling me their product/services or trying to impress upon me their credentials than they were in showing me a good way to solve problems. The exception here was Bobbi Underbakke's session on UI Design Patterns. He presented a really neat methodology for decomposing UI design, and I am glad I attended. The others? Ehhhh. At the very least, I had a really good turkey sandwich between the second and third speakers, so it's not like it was a total wash.
If you ask me, the only downfall to attending a conference like this is how specific it is. Since the topic is so slender, the speaker can lose the audience very quickly when they delve into the very specific. Since the topic is so well defined, any disagreements or debate can veer off into trivia very quickly. To illustrate, I need only ask you to imagine the sort of arguments one might hear at a conference devoted to Smokey and the Bandit 2. It doesn't take too long for those to go from amusing to infuriating.
Nevertheless, I had a good time and hopefully honed the skillset a bit. Even if I didn't, well, there's still that turkey sandwich.
Today at work, I was browsing Slashdot when I saw a story on a self-replicating, rapid prototyping robot. When I read it, I instantly thought back to the Intro to Astronomy course I took in college. Taught by the esteemed Gordon MacAlpine, he devoted a day to crackpot UFO theories. One of them was that advanced alien life does not exist because if it did, space would be filled with these exploratory, self-replicating agents sent out by these other civilizations. I remembered the theory just because it was so bizarre, but I had no idea what the terminology was.
Let's fast forward a few hours. It was only through consultation with well-informed coworkers I was able to stop screaming "AHHH!! ALIEN INVASION!" and start screaming "AHHH!! VON NEUMANN PROBE!" And they say a liberal arts education is wasted on a code monkey. Pshaw!
Two weeks from now, the Paddington Bear and I are going to the UML and Design World Conference being held here in Austin. Wahoo! I've never been to a fancy conference before; I've got the cumberbund at the cleaners now so I'll fit in with the rest of the luminaries. I'll be hitting up Mastering Design Patterns and Advanced Principles of Object Oriented Design in UML on Monday; I'm not sure yet about the other days. If you'll be there, just look for the guy in the aforementioned cumberbund, walk up to him, and give him a bag of money. It's that easy.
The cool thing about it is that we're being sent by our employer to gain skills we'll soon get to implement on our Project Tremendous. I won't get into all the deals of Project Tremendous except to say it's a huge application that we're rewriting. I've been doing the functional requirements on it for months now, so I'm grasping onto any signs of the approaching design phase like the last tatters of life itself. Requirements analysts, I salute you. That stuff is neither easy, nor fun.
Anyway, I'm looking forward to it. Both patterns and UML are interesting subjects, but they're difficult to grasp in a casual setting. That's not to say they're particularly complicated, they're both just abstract concepts that require a lot of attention. Hopefully by devoting several hours to the subject, my design-fu will increase geometrically. Maybe after the conference itself, I'll do a little write-up here. We'll see.
I've seen a few ads out there for igrep, which is supposed to be a search engine specifically for developers. In my opinion, a true search engine for developers would answer answer half of all searches by printing "You're an idiot" and then banning the user from the site indefinitely, while the other half of the searches would return nothing but nude renderings of Princess Leia.
Curious, I went to the site today and typed in a standard, code-geek search term, in this case 'class'. The results aren't pretty; the vast majority of the hits on the first page refer to an HTML tag, not anything related to OOP. Also, not only are all of the results from source code, but they're all from the same site. It doesn't like promising, if you ask me.
I found quantitative proof worse than all of that, however. If I search for 'string', igrep shows me the following stats:
Results 1 - 10 out of 154041 documents matched in 0.441 seconds
Results 1 - 10 of about 97,300,000 for string [definition]. (0.09 seconds)
One tenth of one percent of the matches, and it only took five times as long! Goodness gracious, it's no wonder they're advertising so heavily.
At work, I'm the Visual SourceSafe administrator. You can probably guess what a sweet gig that is; it's roughly as glamorous as being Lead Poop Wrangler at the San Diego zoo. At home, I'm slowly in the process of setting up a development server, and as part of that, I needed some form of source control. Already spending a good portion of my work days screaming at SourceSafe, I knew I didn't need to add that to an already volatile home environment, what with my cat and me. I decided instead to install Subversion.
I had neither used nor installed Subversion before last night, but an observer never would've noticed. The entire thing went really, really easily. In case you ever want to try it out, here's roughly how it broke down.
1. I downloaded the Windows binary from here.
2. I installed from the .msi file. Subversion asked for no configuration information at any time in the process.
3. Confusion sets in. It couldn't be that easy, could it? Don't I need to set up user accounts and what not? To check it out, I downloaded the TortoiseSVN from here.
4. I installed TortoiseSVN from the .msi file. TortoiseSVN also didn't ask for any configuration information.
5. At a loss for what to do, I right-clicked on one of my folders and discovered that TortoiseSVN was already integrated into my Windows Explorer. One of the new options on my right-click menu was to create a new repositoy. I created such a repository in a blank directory and placed a test file in there.
6. Once I had my repository, I created another folder, right-clicked it and went to Checkout. From there, I browsed to the repository on my machine and clicked OK. Suddenly my test file was in the directory, along with a little green check mark next to its name. Way cool.
Subversion just works, which is great after my epic struggles with VSS. There's a lot of configuration options available, but you don't need to mess with any of that before using the service. The only confusion for me was in Step 6, where I was trying to locate my repository. I couldn't figure out the format it was expecting for the path; all of the instructions I read online were incorrect. It's way easier to just browse for it.
Ultimately, it took maybe 10 minutes before a new Subversion fanatic was born. Kudos to all of the developers who played a part in this tool.
I found something very interesting in the NY Times today. On their site, they have a little flash app dealing with class in America. On the first tab, you select your occupation, education, income, and wealth, and it can tell you in what percentile of society you fall. The occupational ranks are ordered by prestige, based on survey responses. It's fun to play around with, and being a curious little monkey, I couldn't help but investigate the prestige rankings of the various techie professions.
The most prestigious position in computing, apparently, is that of database administrator. Not only was it the most prestigious career in computing, but it's the 3rd most prestigious job out of the 447 job titles on the survey (coming in just behind doctors and lawyers). Man, that's almost too wild. Is it only a matter of time before there appears a series of commemorative plates and coins, celebrating our noble DBAs? Someone please tell me that Little League participation rates have plummeted because every boy is chained to his Playschool My Lil Database box, tuning his indexes.
Another thing I found interesting was that there's a pretty big disparity in the rankings between Computer Software Engineer (18th) and Computer Programmer (64th). Ranking ahead of both was Computer Support Specialists, at 9th overall. Didn't we, the collective people of the Internet, agree informally some years back to hate all tech support personnel? Someone is reneging, and I won't stand for it! But 9th overall, wow, that's pretty impressive. Support is both hard and unpleasant, so it's good to see these folks getting some props.
The least prestigious job in the Computer/Math section is Actuary. I don't really know what actuaries do, but going by the rankings, I'll guess it has something to do with lepers.
Going to users' group meetings can have a funny effect on you. A few months ago, I went to a joint meeting of the Austin .NET Users Group and the SQL Server Users Group (ADNUG and CACTUS, respectively). The main SQL Server speaker was this portly, bearded Tasmanian devil of database knowledge. It was really cool to listen to him because the guy just knew everything, and he'd used that knowledge to develop some interesting opinions. I was so impressed, I became really curious about where he worked, thinking it'd be some hotbed of technological breakthroughs. The actual place? The Scooter Store. An interesting gig certainly, and one that only piqued my curiosity. Apparently, the elderly will tolerate absolutely no data loss.
Last week, we bring a fellow in for an interview. Before the interview begins, I get a chance to look at his resume and I see that he's spent some time at the Scooter Store. For the first 15 minutes of the interview, I had ants in my pants as I waited for a chance to ask my question. Finally, I couldn't take it anymore. At the next split-second of silence, I barged into the conversation and bellowed, "Tell me about the Scooter Store! What's your relationship with the round database guru?!"
Thinking about it in advance,, it seemed totally likely that at some point throughout the course of my life, I'd find myself screaming about a motorized wheelchair store. I just didn't think it'd happen so soon.