I've had to do some investigation of VS2005 recently at work, and I'm reminded of just how easy Microsoft can make things. It's really a nice environment. Much better than VS2003, which isn't entirely bad itself. But the decision to use it at home would represent a submission to the Microsoft juggernaught. A well-paying, life-easing master it is, but make no mistake - it shares first place with no one.
But my thoughts always stray back to mono. I can use mono on Linux, which is quickly becoming my favorite OS. I can also use mono on my Macbook, which is the only laptop we own (currently). And I can still use mono on Windows as well, for those times when I must again get paid.
The note I set on Windows Messenger at work sums it up: Linux+mono for freedom, or Windows+VS for plush, thumb-sucking ease? However will I decide...
Thursday, August 30, 2007
Saturday, August 18, 2007
User-Mode File Systems - Not for Me
I mentioned in my previous post that I was thinking about user-mode filesystems as a way to write runtime- and language-independent APIs. Well, I've deciided I don't like the idea.
The single word that killed it was this: discoverability.
An API implemented as a file system would be difficult to "discover", even if you knew those files were provided dynamically by software. Here's what I mean.
1. It wouldn't be very self-documenting.
It would be difficult to learn about the API without seeing the documentation. A good API should be possible to learn and use (at least, at a basic level) without any formal help. And it always helps if the API conforms to some industry "norm" of organization. Config files and input/output redirection are very common in some operating systems. But manipulating files and folders that map to database records or domain objects is an unheard-of concept, and any pattern of mapping would be necessarily home-grown.
2. It would be hard to find the providing code.
Part of the point of user-mode file systems is that they're indistinguishable from the "regular" file system. It's hard enough to tell where one ends and the other begins. Finding out what software is "providing" which branch(es) of the folder hierarchy could be very difficult, especially if the user doing the research doesn't have administrative access to the server.
3. (I can't think of a good third point here, which I feel would strengthen the post. But I'm sure that as soon as I click "Publish Post", I'll think of a good one. So this is just a placeholder until then.)
User-mode file systems tempted me with the ability to write an API that didn't involve a wordy protocol (like web services) or have the limitations of data-level access. But I realize that currently accepted API mechanisms (especially web services) offer benefits that overcome their drawbacks. File system APIs will need to mature with a good set of best practices before I can accept them for my use.
The single word that killed it was this: discoverability.
An API implemented as a file system would be difficult to "discover", even if you knew those files were provided dynamically by software. Here's what I mean.
1. It wouldn't be very self-documenting.
It would be difficult to learn about the API without seeing the documentation. A good API should be possible to learn and use (at least, at a basic level) without any formal help. And it always helps if the API conforms to some industry "norm" of organization. Config files and input/output redirection are very common in some operating systems. But manipulating files and folders that map to database records or domain objects is an unheard-of concept, and any pattern of mapping would be necessarily home-grown.
2. It would be hard to find the providing code.
Part of the point of user-mode file systems is that they're indistinguishable from the "regular" file system. It's hard enough to tell where one ends and the other begins. Finding out what software is "providing" which branch(es) of the folder hierarchy could be very difficult, especially if the user doing the research doesn't have administrative access to the server.
3. (I can't think of a good third point here, which I feel would strengthen the post. But I'm sure that as soon as I click "Publish Post", I'll think of a good one. So this is just a placeholder until then.)
User-mode file systems tempted me with the ability to write an API that didn't involve a wordy protocol (like web services) or have the limitations of data-level access. But I realize that currently accepted API mechanisms (especially web services) offer benefits that overcome their drawbacks. File system APIs will need to mature with a good set of best practices before I can accept them for my use.
Thursday, August 16, 2007
User-mode File Systems with Mono
Yet another thing calling for me to waste my time...
I found a post by Miguel de Icaza talking about writing user-mode file systems in Linux using Mono and C#. (For those who don't know, de Icaza heads-up the Mono project for Novell.) The idea is intriguing to me for two reasons.
First, it's just cool! Think about using cd and cp and vim to browse and modify your application's object model, or your email, or your router settings, or whatever else you decide to expose. I don't know how useful it would be, but it sure sounds fun.
Secondly, though, it might actually be very useful. I'm definitely turning into a fan of C# on Linux, with a special interest in the architecture of large applications. I have long known that data-level and protocol-level integration seem to be the best guarantee of interoperability long-term, since they transcend even the language and/or runtime used to implement them. But now there's another option: file-system-level integration. FUSE presents an option for application integration that is both interactive and intuitive. Imagine having all the customers in your contacts database show up as folders under a mount point, with all their properties (name, email, phone) exposed as text files that you can edit or copy between contacts. While actually storing the data in the file system is probably unwise (although ReiserFS could change that), using FUSE allows the "file system" metaphor for interaction with your indexed, multi-user database.
I'll have to give it a try at home (since I have nothing else to do ;-) and post my conclusions later.
I found a post by Miguel de Icaza talking about writing user-mode file systems in Linux using Mono and C#. (For those who don't know, de Icaza heads-up the Mono project for Novell.) The idea is intriguing to me for two reasons.
First, it's just cool! Think about using cd and cp and vim to browse and modify your application's object model, or your email, or your router settings, or whatever else you decide to expose. I don't know how useful it would be, but it sure sounds fun.
Secondly, though, it might actually be very useful. I'm definitely turning into a fan of C# on Linux, with a special interest in the architecture of large applications. I have long known that data-level and protocol-level integration seem to be the best guarantee of interoperability long-term, since they transcend even the language and/or runtime used to implement them. But now there's another option: file-system-level integration. FUSE presents an option for application integration that is both interactive and intuitive. Imagine having all the customers in your contacts database show up as folders under a mount point, with all their properties (name, email, phone) exposed as text files that you can edit or copy between contacts. While actually storing the data in the file system is probably unwise (although ReiserFS could change that), using FUSE allows the "file system" metaphor for interaction with your indexed, multi-user database.
I'll have to give it a try at home (since I have nothing else to do ;-) and post my conclusions later.
Monday, August 13, 2007
Life with Three Kids
Carrie sent me this. It's an excellent taste of what having three kids can be like:
http://yonkogirl.blogspot.com/2007/06/life-with-three-kids.html
Movie Review: Facing the Giants
Our pastor is going through a sermon series on the book of James. Possibly at his suggestion, our small group watched Facing the Giants in lieu of a lesson last night. Here's my review:
Short version: LOVED IT!!!
Long version:
Acting: It's true that it wasn't all that great. However, the only time it annoys is during the first 15 minutes. That's when the plot is waiting on character development before it can get rolling.
The plot: Truly amazing. Yes, parts of it are too predictable, twists notwithstanding. But it's still enjoyable to see how the plot develops, and it is a great feel-good movie. However, the movie's best strength is in showing how faith and works meet. Coach Taylor's message to the team is that if they give their very best, praising God regardless of the outcome, God will honor the effort.
A pivotal moment early in the movie (no spoiler here) is when Taylor blindfolds player Brock Kelley and has him give his best effort doing the "death crawl". Brock thinks he's trying for the 50-yard line, which is 20 yards farther than he believes he can go. He ends up realizing he is capable of much more when he focuses only on doing his best.
The entire movie is an excellent lesson in putting your faith into action, and in how God wants your very best - no less, and no more. My only regret is that it shows Coach Taylor as an effortless leader. He clearly struggles with faith, but appears to have no trouble at all communicating his vision - there is no "giving your best" shown in his effort to lead and teach his players. Still, I managed to sense that struggles can be intellectual as well as physical, and that "leaving it all on the field" doesn't just mean physical exhaustion.
Overall: VERY highly recommended, especially for those struggling with job decisions or with issues of faith vs. works.
Short version: LOVED IT!!!
Long version:
Acting: It's true that it wasn't all that great. However, the only time it annoys is during the first 15 minutes. That's when the plot is waiting on character development before it can get rolling.
The plot: Truly amazing. Yes, parts of it are too predictable, twists notwithstanding. But it's still enjoyable to see how the plot develops, and it is a great feel-good movie. However, the movie's best strength is in showing how faith and works meet. Coach Taylor's message to the team is that if they give their very best, praising God regardless of the outcome, God will honor the effort.
A pivotal moment early in the movie (no spoiler here) is when Taylor blindfolds player Brock Kelley and has him give his best effort doing the "death crawl". Brock thinks he's trying for the 50-yard line, which is 20 yards farther than he believes he can go. He ends up realizing he is capable of much more when he focuses only on doing his best.
The entire movie is an excellent lesson in putting your faith into action, and in how God wants your very best - no less, and no more. My only regret is that it shows Coach Taylor as an effortless leader. He clearly struggles with faith, but appears to have no trouble at all communicating his vision - there is no "giving your best" shown in his effort to lead and teach his players. Still, I managed to sense that struggles can be intellectual as well as physical, and that "leaving it all on the field" doesn't just mean physical exhaustion.
Overall: VERY highly recommended, especially for those struggling with job decisions or with issues of faith vs. works.
Subscribe to:
Posts (Atom)