Office Monkey

Having spent an undue amount of time in compiler-land over the last four months, I have nothing but respect for a team that acknowledges the shortcomings of their architecture, and so REWRITES IT.

Congratulations on the new release, mono team!

http://tirania.org/blog/archive/2009/Jan-20-1.html

Yesterday, I had a problem to solve. I didn’t want to stay at work until 9pm, waiting for another team’s process to publish a file. (Grossly simplified, but you get the idea). I also didn’t want to log in from home at 9pm in order to wait for it to happen (I did that the night before).

So I used Powershell! Could I have used a batch file? Of course! However, I know with Powershell I can just chain commands together via a semi-colon.
I searched for “Powershell sleep”, and saw immediately that there was, in fact, a Powershell sleep command: start-sleep.

My final commandline:
start-sleep -s 7000 ; GetFileCommand ; msbuild /t:clean,build

And I could just walk away, knowing it would be waiting for me when I got into today.

(That didn’t happen, but it was unrelated to the Powershell issue.)

However, that wasn’t my only use of Powershell yesterday. The MSBuild Project system defines a build through a series of linked .XML files. I uncovered an issue where a particular task wasn’t being completed as I expected. I could, through the wonders of “Find”, locate where I EXPECTED the work to be taking place, but in a 10,000+ line XML file, scrolling upward to find the parent is not entirely pleasant.

So I used code.

I read the XML into an XML object, then found the tag I was looking for. I then got an XML Navigator object for where I was in the document, and walked back up the tree until I found something identifiable (it turned out I was screwed). All told, it took me less time to puzzle out (via get-member) how to do so under Powershell than it would have taken for me to write a real program, or to find it by hand.

Here’s the entirety of what I wrote:
$xmldoc = [xml] [string]::join(“`n”, (gc -read 10kb Native.Build.targets))
$xmldoc | get-member
$xmldoc.GetElementsByTagName(‘Internal_LinkOutputFile’)
$xmldoc.GetElementsByTagName(‘Internal_LinkOutputFile’) | get-member
$xmldoc.GetElementsByTagName(‘Internal_LinkOutputFile’).Item(0)
$xmldoc.GetElementsByTagName(‘Internal_LinkOutputFile’).Item(0) | get-member
$nav = $xmldoc.GetElementsByTagName(‘Internal_LinkOutputFile’).Item(0).CreateNavigator()
$nav
$nav | get-member
$nav.MoveToParent()
$nav
$nav.MoveToParent()
$nav

There was an awful lot of get-member calls, but I didn’t need to know ANYTHING else.

Yay Powershell!

I had a problem with a piece of code last night. An apparent infinite loop without apparent cause. Because I’m working on in-development tools, though, I couldn’t even go to disassembly.

I sat and stared this morning at the offending code, knowing I must be missing something.

I finally went down the hall to grab Nathan (I like Nathan. He’s bright and hard working, and he laughs at my jokes. Good man.). He isn’t as experienced with C++ as I am, but my experience wasn’t helping me. Besides, it was a problem with a bloody for-loop.

Nathan sat down, complained about what I named the function, and then point out the error. Less than two minutes.

Can you see the error?

for (GenericParam* Param = StartOfListOfParams; Param; Param->GetNext())


I feel a little dumb, but vindicated for my position on code reviews, especially for my own code.

Edit 08/11/07 11:28am: Added a space.

I recently transitioned my blog from a LAMP stack at 1and1.com (who I was happy with) to a Windows/IIS7 stack at GoDaddy.com (which was cheaper, and more importantly, Windows-based). At both locations I had multiple domains registered with the same account.
Read the rest of this entry »

On top of the aforementioned SERVER ERROR 500 issue occuring because I didn’t specify a USER_AGENT that matched the white list, I’ve been spending the last week trying to track down exactly why I couldn’t upload a file. I used the stock GalleryRemote program (isn’t sufficient for automation purposes) to test my server, and it all worked fine.

Well, after over a week (admittedly, I’m only poking it on the bus every few days, and only while driving into work), I managed to puzzle out enough from the source code of the Gallery Remote to figure out why my code wasn’t working.

If you’re executing a command, your message must be:
application/x-www-form-urlencoded

However, if you’re trying to upload data, your form must be:
multipart/form-data

Apparently, the system DIES if you try to consistently use one or the other. The former is simpler; the latter provides better performance for binary uploads. Mind you, this isn’t commented ANYWHERE.

I can understand the usage of the former when possible, and the latter when necessary. I can almost understand why no one bothered to mention it (After all, the W3 recommendation for form submission clearly indicates to use both as necessary). However, what I can’t understand is WHY my usage of the latter in all cases isn’t mapped the same way within PHP.

I mean, come on! Regardless of the way the data is submitted, the application platform should, for purposes of the dictionary-based lookup that PHP provides via the $form variable (I think that’s right, I don’t speak PHP), shouldn’t both submission mechanisms be abstracted away unless you want the added complexity?

I’m tired and have a cold, otherwise I would extend this rant into the direction of work. However, you may all count yourselves lucky. For I am going to sacrifice a kitten to my desire to snuggle something cuddly when I don’t feel well, and then I am going to bed. Nice deal, eh?

EDIT (16 Sept 08): Err. Maybe my bad. Turns out that while, by convention, a multipart/form boundary is specified as “———-” + RandomData, the actual usage as a boundary requires it to be prefixed with an additional two dashes. In other words, the actual, in use, boundary should be “————” + RandomData. Which, if you try to just look by eye, is far from visible. Unfortunately, if I had paid more attention to the documentation, the example they give isn’t prefixed by a series of dashes, and it’s far, far clearer. Still could have been explicitly documented (ABNF, anyone?). However, I’m not going to lambast the PHP team; they could have been working just fine all along.

Partially as a learning exercise, and partially because I’m a money grubbing greedy bastard, I’m trying to come up with a clever extension to Microsoft Windows Home Server.

Unfortunately, I already had pretty much everything I needed on the base installation; I had originally installed it purely to have a system I could hook up my parallel printer to. It already supports remote desktop to systems within your local network, as well as remote access to files on the server via secured login. Heck, it even provides dynamic DNS service, complete with chained certificates for secured access. Nice, huh?

I figure most people out there do NOT have WHS installed. Probably have no need for it. So, why don’t you let me know what would make you want a Windows Home Server? If you have one, what feature do you wish it had? If you could have your own personal secured web server, what do you really wish you could do on it?

I’ve spent a few minutes today going back through over two years of posts and tagging them “appropriately.” The new version of Wordpress supports tags, and I’ve always wanted a Tag Cloud (left hand column — see that bit with varying sized pieces of text?), so…

So there have been a TON of updates today. It’s just that none of them mattered.

I could post this to a programming discussion list. However, I’d rather not look like an idiot to anyone who doesn’t already know me to be one, at least at first.

Read the rest of this entry »

I get rather alarmed at work when I’m told that someone’s idiocy is to be expected, as they’re: new, young, inexperienced, poorly trained, etc. I just expect better.

On the other hand, every so often I run across something truly brilliant, and feel humbled (Any book by Don Box). Today, I ran across “Duff’s Device.”

I’d heard of it before, but never bothered to actually look at the code. It’s an optimization for something I rarely have to deal with in real life.

Looking at the code today, I was at first confused by what the big deal was… then saw where the “do” was located, and was struck by the brilliance. Pick up the odd-numbers-out at the start, rather than at the end…

Only click the link if you don’t mind feeling impressed, and feel comfortable in your knowledge of what exactly a compiler does. Assembly language knowledge might help cushion the wtf factor.

#define sizeof(x) rand()
you can do that?
Yup
OMFG!
That’s disgusting!
– qdb

After Jonathan’s post yesterday, I decided that I can pretend to be as wise as he is. So, now I present to you, my list of the first things that come to mind when I’m working:

1. Corollary to Jonathan’s item vi: One of the highlights of Visual C# 2005 (aka C# 2.0) was the support for the “partial” class specifier. While C# improved on C++ (sort of) by ridding the world of header files, type libraries, etc., mandating the use of only a single file for a given class caused problems when things got too complicated. The “partial” keyword easily allows a C# class to be spread across multiple files, allowing code-generated portions to be in the same class, as well as easier editing. (I’m sure VB.Net has the same feature, but I don’t like VB.Net).
2. A #region directive is most useful when you’re writing and editing code. When debugging, it’s mostly useless. When printing out code, it’s useless. But in order to keep subsections partitioned off either when you’re adding a whole lot of related code or when you’re implementing an interface and just want to “close it off” when you’re done, it’s useful. (C# again — would you believe I rarely write C# code?)
3. Learning to use Windbg for your unmanaged debugging is priceless. You’ll lose some ease of use, but it’s:
• Incredibly fast
• apparently more accurate at both symbol location and source location than Visual Studio
• the only thing to use in some cases, so it’s better to be familiar with it early on
• got the best debugging feature I’ve seen in a long time: the “x Function” command, where Function can be a wild-carded search string… say you know you need a breakpoint on some function in some assembly shipped by your team. “x VSTO*!*ReportError” will return every function with a trailing ReportError implemented in every class in every DLL that is named starting with VSTO. It’s just useful.
4. Never presume that other developers understand the difference between class and interface inheritance. Whenever someone starts casting from an interface to a class, begin getting suspicious. Whenever anyone explicitly casts from one interface to another not in a QueryInterface call, assume that that person may be making a mistake. Outside of non delegating IUnknown::QueryInterface implementations, there are very few places where that’s a good idea.
5. The AddRef/Release Factory pattern is a very good one for a reason; ask anyone who’s ever had to track down a bug due to the difference in heap allocation and deallocation (Hi Jonathan!)
6. Cross-thread logic is never as simple as you would like.
7. It’s sometimes better to start debugging by observation, rather than jumping right into the debugger. Two minutes with SpyXX and a single breakpoint told me precisely where a bug lay in our code; a senior developer has spent several hours with no luck.
8. On a related note: if a program isn’t responding to a button press: 1) it’s not handling the button press (correctly, in some cases), or 2) it’s not getting the button press. They’re both reasonably easy to verify with minimal debugging, and knowing which it is saves you hours of time.
9. Debugging a crash that occurs in obvious code (ie, crash on a line: pInterface->Func() with a NULL pointer access violation) is far simpler than inordinately complex code — if it’s the former case the problem is usually right nearby or immediately obvious (the member was never set properly, a QueryInterface call isn’t being verified as having returned S_OK, etc.) The latter case usually will take a great deal of headscratching and puzzling and will eventually lead you to arcane bugs that occur somewhere entirely different — where the stack or thread data is getting royally trashed.
10. Component != class; Interface defined in a header file != IDL / Typelibrary / IMarshal-capable component.

I’m done now. I’m not nearly as coherent as Jonathan, but I’m twice as angry.