I was at the statehouse on Friday because my wife is someone to be admired. Being there, I got to watch a bunch of people from all walks of life: teachers, professors, students, and politicians. I noticed two in particular.

More correctly, I noticed one half of that pair, a middle manager. In some small talk this person gushed about a boss to me (a nobody in the scheme of things) and I noticed this person had modeled personality traits on the boss in question. The boss has some traits to be admired, and some not. But the pointless traits were the ones I noticed being mimicked: taste in coffee, dress, and oddly enough speech patterns.

I admire many of my coworkers for various reasons. But I had to ask myself in light of this, how should I model myself after those I admire and seek to emulate? Does college football make me a kick-ass people person? Those aren’t the behaviors that begat the qualities I want for my own.

Back to my wife. She is one of the smartest people I’ve ever met. I admire her personability, her persistence, her compassion, and her organization among other fine qualities. But one of her defining character traits is, “likes pink.” This doesn’t mean I’m putting pink into my wardrobe. It does mean that I’ve started to work on my own professional development while she is hard at work, I’ve started to take an interest in other people, and I’ve kept my stuff in its place. Honestly, I still have much improvement in these areas, but the point is simple. Seek to understand how the people you admire got that way, and that will gives you tools to truly improve yourself, not merely parrot it.

There are few things in life better than humus and pita chips.

There are few things in life are as insidiously addictive as brain-crack, the idea not executed. These ideas sit in your brain festering, growing malignantly, until there is no hope of you ever achieving them like the “perfect utopia” they have become.

I bring this up because I had 2 in particular that where starting to rattle around in my brain like horrid clattering moose (moose clatter, right?). I’m a junkie for computer languages, and when Rick Minerich mentioned Irony recently followed quickly by a project manager asking about writing a testing DSL, I started to feel that tumor grow in my delicate, delicious brains. I should write a language. Then it split in twain. There is no reason to have a programming language, even a DSL, without an editor that understands it. I’d need a Visual Studio plug in to make that work. And those are hard, right? Besides, I would want to do it right and reuse the parser built for the first to syntax highlight the second. Uh, oh. I now have an idea for the perfect DSL framework rattling around in my skull.

The problem is, I only have enough room in my brain for a handful of things at any given time. So, I took the weekend to clean house. The idea is not to get something perfect. I just want to get it done enough to say, “I did that.” And now I can get to sleep tonight. My DSL isn’t for supporting your important work, it is for proving I know how to do it.

First lesson learned: Irony has crappy and out of date documentation. Every example I’ve seen uses API calls no longer in the library. In addition, most focus on how cool the internal DSL Irony uses for creation of the language grammar. And it is cool. But some of us missed the last mile. I’m not going to solve that issue here. I did, however, post my weekend exploration to github. Enjoy!

Second lesson learned: VS 2010 isn’t that hard to extend, once you know where to look.

Third lesson learned (again): I can’t spell. I had set the file extension to “circles” when I was using a file called “circle”. That means my plugin wasn’t triggering Saturday, so I had a Ukulele break and came back to it this afternoon.

Fourth lesson learned: Visual Studio lies. It gave me an error when my extension crashed about ActivityLog.xml but I couldn’t find it. I had to enable -log at the command line for the extension. Then it was easy.

Fifth lesson learned: a full grammar sucks for syntax highlighting. Effective syntax highlighting requires robustness because it should work, not only on a full program, but on a program as it is being typed. See the screen shots to better understand.

I’m not “finishing” this project. It has done what it was meant to do, serve as a prof of concept sketch that I can refer to later. Enjoy!