Here we go. I'm on a new host, new blogging software, starting from scratch.
You can read all about it over here.
I'll keep this up as a place to vent when I encounter a disturbance in the force.
http://mpwilson.com/
- Mike
(Oh yeah, that whole "MadWilliamFlint" thing? Yeah, just scratch that. All of a sudden after five or so years it became old.)
Thursday, April 03, 2008
Tuesday, April 01, 2008
Monday, March 31, 2008
Ferriss
I cannot highly enough recommend the Four Hour Workweek book. It's full of wonderful ideas on breaking away from the day to dayness of life if you're up to the challenge. Tim Ferriss has an incredible ability to get outside of the world's workings and live his own life.
He also has a website, a blog, for lack of a better term. The site has been equally full of good information both in the posts themselves and in reference areas around the site.
On each of the posts (near as I can tell, having spot-checked it a bit in retrospect) there exists a byline:
"Written by Tim Ferriss"
Well today there's a post written by Tim Ferriss (possibly) confessing that the last year of posts have indeed not been written by him, that he's outsourced pretty much the whole thing. I've been had.
And herein lies the problem.
97% of what Ferriss has to say is plain old great out of the box, innovative lifestyle thinking. But he crosses a line I simply can not abide.
I've wondered on this and other occasions about that motivation. Why should I care after all?
When push comes to shove, I get to pick the qualities I value in people I respect and look up to, and while he's flirted with this line more than once, this pushes him over the edge for me.
I can't trash him or his work. It's innovative and wonderful.
But I won't be back to the site. I don't care if you're going to teach me to fly, be honest about it.
I'll not be made a patsy.
He also has a website, a blog, for lack of a better term. The site has been equally full of good information both in the posts themselves and in reference areas around the site.
On each of the posts (near as I can tell, having spot-checked it a bit in retrospect) there exists a byline:
"Written by Tim Ferriss"
Well today there's a post written by Tim Ferriss (possibly) confessing that the last year of posts have indeed not been written by him, that he's outsourced pretty much the whole thing. I've been had.
And herein lies the problem.
97% of what Ferriss has to say is plain old great out of the box, innovative lifestyle thinking. But he crosses a line I simply can not abide.
I've wondered on this and other occasions about that motivation. Why should I care after all?
When push comes to shove, I get to pick the qualities I value in people I respect and look up to, and while he's flirted with this line more than once, this pushes him over the edge for me.
I can't trash him or his work. It's innovative and wonderful.
But I won't be back to the site. I don't care if you're going to teach me to fly, be honest about it.
I'll not be made a patsy.
Sunday, March 30, 2008
Fannie Farmer Cookbook (full text)
The Fannie Farmer cookbook is awesome. Check it out:
This classic American cooking reference includes 1,849 recipes, including everything from “after-dinner coffee”—which Farmer notes is beneficial for a stomach “overtaxed by a hearty meal”—to “Zigaras à la Russe,” an elegant puff-pastry dish. Bartleby.com chose the 1918 edition because it was the last edition of the cookbook authored completely by Farmer.
Saturday, March 29, 2008
I know I know, I need a hobby
One of the things that I think way too much about is the sort of disposable culture problem that's grown out of advances in industrial and economic progress. We don't make things any more. We don't FIX things any more and it saddens me a bit.
So Friday night (that would be yesterday) I decided to try my hand at making butter. Not a big deal, just get some heavy cream, a smidge of salt, put it in the kitchen-aid and go for a bit, right?
Actually yeah. It's the weirdest thing. I let it go for a bit (20 mintues?) and all of a sudden the sound the thing changed and it was making this weird sloshy noise.
I walked over to it and damned if there wasn't a big wop of butter sitting in a pool of what turns out to be buttermilk (neat! who knew?)
You have to work the butter a bit to get the rest of the water out of it, but that was easily accomplished with a big zip-lock freezer bag. (Kneading butter's not my idea of a good time. Though I have to say I could really see where it would be part of one. >;-)
So now, for two pints of organic heavy cream (I tend towards organic milk products. I'm not an environmentalist. I just think it tastes better enough to pay more.) I have about a pound of butter and two cups of buttermilk, which is rather more than I expected.
I did the math and realized that, not only do I have a better result than store bought. It's an interesting novelty and, get this...
IT'S FUCKING CHEAPER TO MAKE BUTTER YOURSELF THAN IT IS TO BUY IT!
Yes. Even with the "organic" premium compared to plain old non-organic butter. Add in the price of buttermilk (which I use in baking ALL the damn time) and this is just win/win/win.
You're welcome.
I'll amend this post with more details if anyone's interested.
So Friday night (that would be yesterday) I decided to try my hand at making butter. Not a big deal, just get some heavy cream, a smidge of salt, put it in the kitchen-aid and go for a bit, right?
Actually yeah. It's the weirdest thing. I let it go for a bit (20 mintues?) and all of a sudden the sound the thing changed and it was making this weird sloshy noise.
I walked over to it and damned if there wasn't a big wop of butter sitting in a pool of what turns out to be buttermilk (neat! who knew?)
You have to work the butter a bit to get the rest of the water out of it, but that was easily accomplished with a big zip-lock freezer bag. (Kneading butter's not my idea of a good time. Though I have to say I could really see where it would be part of one. >;-)
So now, for two pints of organic heavy cream (I tend towards organic milk products. I'm not an environmentalist. I just think it tastes better enough to pay more.) I have about a pound of butter and two cups of buttermilk, which is rather more than I expected.
I did the math and realized that, not only do I have a better result than store bought. It's an interesting novelty and, get this...
IT'S FUCKING CHEAPER TO MAKE BUTTER YOURSELF THAN IT IS TO BUY IT!
Yes. Even with the "organic" premium compared to plain old non-organic butter. Add in the price of buttermilk (which I use in baking ALL the damn time) and this is just win/win/win.
You're welcome.
I'll amend this post with more details if anyone's interested.
Labels:
Baking,
DeathOfCraft,
diy,
HomeMade
Memelet of the day
"Good Intentions are the easiest thing in the world to fake because you don't ever have to show results."
- Me
- Me
Friday, March 28, 2008
Me again
I'm having weird DNS issues again, so I think I'm coming back to this site for a while.
I'm actually in the midst of writing a piece of blogging software. I can't believe I'm actually going to do this after all this crap. But I'm so sick of NOTHING doing quite what I want.
When push comes to shove, the real feature set I'm interested in is almost entirely in the generation of the post html itself, which was a big "a ha!" for me. This means that what I'm really creating is a rich blog posting tool; but one that has deep knowledge of the full site itself and can do some interesting cross-referencing tricks.
Like Radio Userland but without the suck.
Stay tuned!
I'm actually in the midst of writing a piece of blogging software. I can't believe I'm actually going to do this after all this crap. But I'm so sick of NOTHING doing quite what I want.
When push comes to shove, the real feature set I'm interested in is almost entirely in the generation of the post html itself, which was a big "a ha!" for me. This means that what I'm really creating is a rich blog posting tool; but one that has deep knowledge of the full site itself and can do some interesting cross-referencing tricks.
Like Radio Userland but without the suck.
Stay tuned!
Labels:
blogging,
diy,
Programming
Wednesday, February 20, 2008
Not the real blog
It just occurred to me that my blogger profile, which I use to comment all over the place, points here. It really shouldn't and I"ll fix that at some point. But if you're here 'cause you clicked through for more about me, go here: The Universal Church Of Cosmic Uncertainty
Tuesday, August 14, 2007
Mic check, mic check...1..2....1..2...
I figure since blogger is now google's, that posting from google docs to a blogger blog ought to be relatively painless eh?
I figure since blogger is now google's, that posting from google docs to a blogger blog ought to be relatively painless eh?
It'll do for now
Yeah, see this may just be the thing to do from now on.
Sure blogger is minimally functional. But it least it's functional.
Sure blogger is minimally functional. But it least it's functional.
Tuesday, December 19, 2006
ugh
4 shots of Pitrone
2 Pepperfucker shots
1 shot of Cuervo
4 pints of Magners
2 greasy burgers
1 order of fries
Makes for a grumpy and not particularly productive mikey
2 Pepperfucker shots
1 shot of Cuervo
4 pints of Magners
2 greasy burgers
1 order of fries
Makes for a grumpy and not particularly productive mikey
Monday, December 18, 2006
Sunday, December 17, 2006
Do The Simplest Thing That Won't Work
(or: Holy Shit, Mikey Drank The Kool-Ade)
My current employer is the only one I've ever worked for that has taken the process of software development seriously.
By that I mean that they understand it's a complex thing and have gone out of their way to seek out the people and ideas that really make it work instead of some management consultant derived crap-ass methodology involving nothing more than reams of "deliverables" with no real attachment to the product or process at all. (read: cmm,ss,uml,omt,etc...)
So we get guys in from Object Mentor and such places to sell and teach us about the various permutations of Agile programming and Xp.
Most notable is the practice of Test Driven Development. A few years ago I was hanging out on the One True Wiki, detecting the murmurs of TDD. I started applying it, or rather, trying to apply it. ...err... painful.
Eventually though I got the point. But wasn't quite motivated enough to do it on my own, especially without any kind of tools.
It's all about the tools.
So on Thursday I had the pleasure of getting a brain dump by sitting down with Mike Feathers from Object Mentor as he dragged me, kicking and screaming into pulling nunit into a...get this... C# .net GUI, to test code that heavily relies on 3rd party gui components, by instantiating those components (without a live interface) and driving them through code-based calls, rather than through normal gui clicks and typing.
This is something that other ... what do you call those, consultants? *shrug* have come to XPify us have been stumped by.
The end result is usually along the lines of "Well... split as much of the code out from the gui as you can, and test from there down." Made sense to me. Hell, I'm a network systems programmer. I don't even like LOOKING at guis, let alone programming them.
But we succeeded. By 3:00 in the afternoon, I was able to write a couple basic tests surrounding a new gui-based feature I was adding.
Now...
By 5:00, the fact that I had 5 such features to add, all mildly (though not substantially) different made everything perfectly clear.
I started by taking the tests, copying them and renaming them. Then the matter of refactoring the tests came up. I spent the first few hours of Friday cleaning up these tests into the front-end tests themselves and a bundle of support code.
This, my first serious foray into TDD, resulted in taking a piece of work that was no less than 3-4 days and squnching it down to 8 hours of working on tests, and 3 hours of working on logic. The result has a MUCH higher confidence rating than I could have gotten without the tests. NOT "would have", COULD have.
So let me zoom back in to the process for a second here...
The degenerate idea is that if you're going to write a piece of code, write a test first. You write the test (such that it fails) then you make it pass, then you evolve the code through evolution of the tests.
It occurs to me now that in evolving the tests that what you want to do at any given time is add a test that is "The Simplest Thing That Won't Work", then solve it with the far better known expression "The Simplest Thing That Will Work".
By switching back and forth between these two practices, you develop not only a body of code that you know works; but through the tests, a body of code that is fundamentally adaptable to new requirements and structural changes because it is anchored in the tests.
Plus, it forces you to constantly examing what it is you think you're trying to achieve and making sure you're on track with it. In addition to actually being functional proofs that the code works, the tests say "This is what I'm working on Right Now" at all times.
Until you've done it, this all seems like a bunch of crap. Maybe you've been burned enough to get to the point where "yeah, testing all my code seems like a good idea." But almost invariably what I hear (and swore up and down for a very long time) is "but the OVERHEAD!?! Shouldn't you be spending that time doing work?"
The answer, which I'm only going to briefly touch on here is that you don't have the faintest idea what work you're doing if you don't test. The work you're doing is "Build a house" and you're trying to figure out where to put a 2x4.
I'm a C++ programmer. I've been a C++ programmer since very soon after C++ existed. I love the language. It's low level, flexible and powerful. Plus, it's truly arcane in a way that appeals to my sense of order.
One of the things about C++ I love so much is that it's a thin evolution on top of c. When you write C++ code you know exactly what it's doing and when. There's no guesswork, no nonsense about garbage collection, who owns that reference, none of that crap.
As such there's a level of security that comes from writing your own libraries in it from the ground up. "I KNOW what this is and what it does." It's tough to beat with the fuzzy scripting languages, virtual machine environments, and all that. There's too much going on under the hood. Too many unknowns. (and don't DARE tell me "those details don't matter".)
I've a pet theory that I've developed in the last 36 hours about this: That this level of security is the source of a vast amount of bad practice in the software development world. Most notably the "Not Invented Here" syndrome, which really comes down to "I didn't write it, I don't know it, and in the time it takes me to learn it well enough to be as comfortable as I want with it, I could write it myself and know it better anyway."
The surprise of Test Driven Development (see, there was a point to that sidebar ;) is that having a body of 34 tests left me feeling secure about the quality of my code in a way that I did not at all anticipate. In the worst case, the WORST case, I have a bad test or I'm missing a test.
So from here I'm not sure where to go on my own stuff. Should I start pulling down pyunit, cppunit, junit, etc? And instrument all my code? (I have hundreds of thousands of lines of code.)
I actually think that might be a good idea. I have huge libraries that I've developed over the last couple decades. But as I've moved from interesting project of the moment to interesting project of the moment, my familiarity with these things has atrophied to the point where I look at the source directory and the few test programs I've got and I get this kinda fuzzy... "Yeah, but how well did that actually WORK?" feeling (resulting in "Not Invented Here" syndrome on my own code *sigh*)
Perhaps some of these projects and big ideas would be more tractable than I thought at the time if I could lock down the code under a comprehensive suite of tests.
*rolls up his sleeves and heads out to pick up a couple cases of diet dew*
My current employer is the only one I've ever worked for that has taken the process of software development seriously.
By that I mean that they understand it's a complex thing and have gone out of their way to seek out the people and ideas that really make it work instead of some management consultant derived crap-ass methodology involving nothing more than reams of "deliverables" with no real attachment to the product or process at all. (read: cmm,ss,uml,omt,etc...)
So we get guys in from Object Mentor and such places to sell and teach us about the various permutations of Agile programming and Xp.
Most notable is the practice of Test Driven Development. A few years ago I was hanging out on the One True Wiki, detecting the murmurs of TDD. I started applying it, or rather, trying to apply it. ...err... painful.
Eventually though I got the point. But wasn't quite motivated enough to do it on my own, especially without any kind of tools.
It's all about the tools.
So on Thursday I had the pleasure of getting a brain dump by sitting down with Mike Feathers from Object Mentor as he dragged me, kicking and screaming into pulling nunit into a...get this... C# .net GUI, to test code that heavily relies on 3rd party gui components, by instantiating those components (without a live interface) and driving them through code-based calls, rather than through normal gui clicks and typing.
This is something that other ... what do you call those, consultants? *shrug* have come to XPify us have been stumped by.
The end result is usually along the lines of "Well... split as much of the code out from the gui as you can, and test from there down." Made sense to me. Hell, I'm a network systems programmer. I don't even like LOOKING at guis, let alone programming them.
But we succeeded. By 3:00 in the afternoon, I was able to write a couple basic tests surrounding a new gui-based feature I was adding.
Now...
By 5:00, the fact that I had 5 such features to add, all mildly (though not substantially) different made everything perfectly clear.
I started by taking the tests, copying them and renaming them. Then the matter of refactoring the tests came up. I spent the first few hours of Friday cleaning up these tests into the front-end tests themselves and a bundle of support code.
This, my first serious foray into TDD, resulted in taking a piece of work that was no less than 3-4 days and squnching it down to 8 hours of working on tests, and 3 hours of working on logic. The result has a MUCH higher confidence rating than I could have gotten without the tests. NOT "would have", COULD have.
So let me zoom back in to the process for a second here...
The degenerate idea is that if you're going to write a piece of code, write a test first. You write the test (such that it fails) then you make it pass, then you evolve the code through evolution of the tests.
It occurs to me now that in evolving the tests that what you want to do at any given time is add a test that is "The Simplest Thing That Won't Work", then solve it with the far better known expression "The Simplest Thing That Will Work".
By switching back and forth between these two practices, you develop not only a body of code that you know works; but through the tests, a body of code that is fundamentally adaptable to new requirements and structural changes because it is anchored in the tests.
Plus, it forces you to constantly examing what it is you think you're trying to achieve and making sure you're on track with it. In addition to actually being functional proofs that the code works, the tests say "This is what I'm working on Right Now" at all times.
Until you've done it, this all seems like a bunch of crap. Maybe you've been burned enough to get to the point where "yeah, testing all my code seems like a good idea." But almost invariably what I hear (and swore up and down for a very long time) is "but the OVERHEAD!?! Shouldn't you be spending that time doing work?"
The answer, which I'm only going to briefly touch on here is that you don't have the faintest idea what work you're doing if you don't test. The work you're doing is "Build a house" and you're trying to figure out where to put a 2x4.
I'm a C++ programmer. I've been a C++ programmer since very soon after C++ existed. I love the language. It's low level, flexible and powerful. Plus, it's truly arcane in a way that appeals to my sense of order.
One of the things about C++ I love so much is that it's a thin evolution on top of c. When you write C++ code you know exactly what it's doing and when. There's no guesswork, no nonsense about garbage collection, who owns that reference, none of that crap.
As such there's a level of security that comes from writing your own libraries in it from the ground up. "I KNOW what this is and what it does." It's tough to beat with the fuzzy scripting languages, virtual machine environments, and all that. There's too much going on under the hood. Too many unknowns. (and don't DARE tell me "those details don't matter".)
I've a pet theory that I've developed in the last 36 hours about this: That this level of security is the source of a vast amount of bad practice in the software development world. Most notably the "Not Invented Here" syndrome, which really comes down to "I didn't write it, I don't know it, and in the time it takes me to learn it well enough to be as comfortable as I want with it, I could write it myself and know it better anyway."
The surprise of Test Driven Development (see, there was a point to that sidebar ;) is that having a body of 34 tests left me feeling secure about the quality of my code in a way that I did not at all anticipate. In the worst case, the WORST case, I have a bad test or I'm missing a test.
So from here I'm not sure where to go on my own stuff. Should I start pulling down pyunit, cppunit, junit, etc? And instrument all my code? (I have hundreds of thousands of lines of code.)
I actually think that might be a good idea. I have huge libraries that I've developed over the last couple decades. But as I've moved from interesting project of the moment to interesting project of the moment, my familiarity with these things has atrophied to the point where I look at the source directory and the few test programs I've got and I get this kinda fuzzy... "Yeah, but how well did that actually WORK?" feeling (resulting in "Not Invented Here" syndrome on my own code *sigh*)
Perhaps some of these projects and big ideas would be more tractable than I thought at the time if I could lock down the code under a comprehensive suite of tests.
*rolls up his sleeves and heads out to pick up a couple cases of diet dew*
Sunday, October 01, 2006
Nothing to see here anymore
The REAL blog is back online. Nothing to see here. All posts of substance have been migrated.
Subscribe to:
Posts (Atom)

