I toyed around with using my command-line Google interface and noticed a couple serious flaws. I fired up the source code and cleaned it up a bit.
- Still very lightweight and simple
- You can now open a URL that was listed in a previous page
- If you change your query term, the page number correctly resets itself to Page 1
Well I started blogging here about half a year ago primarily because I had quit a very bad-fitting job and started to pursue other work; my blog was intended to help me refocus on my hard skills set and also put a little bit out on display. I didn’t get very far at all, though, just about three weeks or so, before I found an almost dream job. No job is perfect but my current job now is still the best job I’ve ever had, hence no real need to be a show-off (or a wannabe, for that matter).
But I also started blogging here to dump tech thoughts. And that’s the more "pure" reason for blogging anyway, one that motivated me almost equally.
I was using LiveWriter here. No, not PowerBlog, which I built by myself over the course of two or three years and now, two years after having walked away, I look at it with a cringe and a blush. Recently I fired up the PowerBlog source code in Visual Studio on Windows Vista. Crash, bang, boom, I spent at least a couple hours trying to refactor naming convention clashes (like "WebBrowser", which also showed up in System.Windows.Forms in .NET 2.0) and other issues, but ultimately I couldn’t win. R.I.P., PowerBlog v2. Maybe I’ll rewrite you from scratch someday, a v3, in .NET v3.
But LiveWriter is a cleaner version of what PowerBlog tried to be. It lacks a lot of features PowerBlog had, like a grid list of all posts not unlike Outlook Express (indeed Outlook Express was a huge design inspiration for PowerBlog), but LW has something PB didn’t have and that I had always planned to add but never even started: image insertion and management. LW took a step further and applied automatic resizing and effects. Great. I like it.
I guess what stalled the blog here was the fact that I got a laptop, but LiveWriter had been set up on my desktop PC, which served as a web server (for tinkering), a Windows XP Media Center Edition server for my XBox, and a file server for all my personal junk and backups from present time to years past. Later I got another computer, a dedicated gaming / music workstation for the living room, which took over my big 20" LCD screen. Now my "home server" had an old CRT and was being ignored in the back room not really doing much except serving recorded TV to my living room over the LAN.
I could have installed LiveWriter on my laptop, and in fact I did, but I discovered that my drafts were not kept on the server. I’d have to synchronize the drafts. And I didn’t figure it was worth the time to mess with it, and that I should just sit down at the "back room PC" if I want to blog.
Never happened. Very recently I tried Remote Desktop, but LiveWriter has an almost fatal incompatibility with Remote Desktop: it invalidates the entire screen (causes the screen to re-paint itself) with every keystroke, which means that for every letter typed into Live Writer I would have to watch the screen go blank for a split second. A-[blink]-n-[blink]-n-[blink]-o-[blink]-y-[blink]-i-[blink]-n-[blink]-g-[blink]-!-[blink]
So now some months have passed sinced I was really blogging and I’ve been queuing up a lot of things, mostly small, that I would have liked to have blogged about, even if only a brief mention. Not long ago, I upgraded my back room home server to Windows Vista, with a fresh installation, giving me a clean slate. So today I finally sat down and came up with a solution.
The problem: I have three computers, and would like to blog using any one of them. I don’t want to blog using a web interface, I prefer to use a Windows application. But I also want my drafts and post history to be kept in that windows app. PowerBlog handled this, but it was so permanently alpha I would not bother to attempt using it. LiveWriter is good enough, although at some point I want to post code blocks and LiveWriter is too limited at formatting options
The solution was to synchronize my three machines for LiveWriter drafts and history. Fortunately, the Drafts and post history of Live Writer are kept as flat files in the user profile directory. Since all three computers are running Vista, all three keep their LiveWriter files here: C:\Users\Jon\Documents\My Weblog Posts. I could just edit the registry and point LiveWriter to use \\mediacenter\c$\Users\Jon\Documents\My Weblog Posts as the application "home" directory, but I thought that would be too severe and prone to too much LAN chatter. I thought about using a tool I had written that used .NET’s FileSystemWatcher to synchronize files, but decided it was too much trouble and doesn’t take into account file changes while one or the other computer is shut down or offline. I could xcopy the files with a batch file, but Microsoft SyncToy seemed to be a better quick solution, for ease of implementation. Robocopy would have done just as well as SyncToy, I suppose, but I thought of SyncToy first.
On both of my living room computers (the gaming / music workstation, and the laptop) I pointed SyncToy to C:\Users\Jon\Documents\My Weblog Posts as the left directory, and to \\mediacenter\c$\Users\Jon\Documents\My Weblog Posts as the right directory, with the synchronization type flag set to Synchronize.
Then on both computers I created a SyncAndRun.bat file:
"C:\Program Files\Windows Live Writer\WindowsLiveWriter.exe"
This essentially synchronizes to catch up my blog posts, then runs Live Writer so I can do my blog thing, then synchronizes again to push out any blog changes.
Then I dragged a shortcut to the .bat file to my Quick Launch toolbar. I changed the shortcut icon to use the WindowsLiveWriter.exe icon, and changed the shortcut file name to "Synchronize and Run Windows Live Writer".
There! 🙂 Now everything is perfect. I can hop onto any of my three home computers and start blogging away. Everything will be in place.
Microsoft is hinting in this article, Automatic Updating of Visual Basic Applications, a practice that should enable COM DLL access without registering the DLL.
I knew about this already but this has me thinking. Over the last year and a half I have been working heavily with a CRM product that supports dynamic deployment of application plug-ins via a database BLOB record. The plug-ins are "self-contained" in that they introduce scripted content, not binary content. This is changing with the new release, however, which supports .NET Extensions.
One of my disappointments with .NET Extensions, however, is that .NET is not appropriate in the COM-based world that the product is. VB6 COM DLLs are far more appropriate. But the problem with VB6 COM DLLs is that they must be registered. That fact has caused the product development team to hesitate with supporting custom COM DLL deployments (except in very special circumstances, namely the OLE-DB provider extensions).
So I have a little pet project in mind that I might consider tackling. It consists actually of two components:
- A command-line tool (with an optional GUI front-end) that will take a COM object, push it through the .NET SDK’s RCW generator, but then wrap that output (the COM object and its Interop file) into an "auto-install" assembly, embedding the COM object as a resource. This containing assembly would then auto-extract and expose the COM object through the CLR.
- Another command-line tool that will take a managed assembly with its CCW and generate a native DLL with the CCW-wrapped managed assembly embedded into the DLL.
Someone at my former place of work (a certain S. Carnie) came up with an astounding solution after a few nights’ work of not only making a C# / VB.NET managed assembly a true COM object by wrapping it in a C++/CLI DLL–but also packaging up all the dependencies of the managed assembly (even the debug database!) and stuffing it all into one DLL for easy deployment. When a COM client calls upon this wrapper, the embedded resources are extracted and loaded and then called upon. This is why I love software!!
The catch with his solution is that AFAIK (I still have not examined his public source code) the COM interfaces were predefined. I would want to accomplish the same thing but not make them predefined. Essentially, I would want all public members of the CLR assembly to be COM-exposed in the native DLL.
This would likely entail some code generation and auto-compilation, in which case it wouldn’t be a small project. Even so, I know it’s doable, and I tend to wonder why Microsoft didn’t already do it.