Thursday, July 2, 2009
Saturday, June 13, 2009
Time to grow-up
This sort of thing is becoming a problem in tech, maybe it's time to grow-up.
From my point of view it's an unhealthy mix of of hyperbole ('rock-star', 'edgy', 'hero'), Adult Swim, and juvenile humor movies (someone at the Paying Day Job seriously commented that 'Van Wilder' is a 'classic' movie).
I'm not big on organized religion but this seems particularly apropos:
Grow-up guys.
From my point of view it's an unhealthy mix of of hyperbole ('rock-star', 'edgy', 'hero'), Adult Swim, and juvenile humor movies (someone at the Paying Day Job seriously commented that 'Van Wilder' is a 'classic' movie).
I'm not big on organized religion but this seems particularly apropos:
When I was a child, I spoke as a child, I understood as a child, I thought as a child: but when I became a man, I put away childish things.
Grow-up guys.
Thursday, June 11, 2009
Daily math
Started reading Goldblatt's "Topoi" this morning waiting for someone to let me into the Paying Day Job.
Just into the Intro but it's quite good.
The book is available online (Cornell I believe), but the formatting is munged and no diagrams, so the hardcopy is nice.
Just into the Intro but it's quite good.
The book is available online (Cornell I believe), but the formatting is munged and no diagrams, so the hardcopy is nice.
The Aging Programmer
I commented on this blog entry this morning.
This sort of thing pops-up now and again with various degrees of success.
One the one hand I've felt some of the ageist pressure, on the other most of the analysis is flawed and overly emotional.
At the end of the day it boils down to what have you done lately and what can you do for me now?
This sort of thing pops-up now and again with various degrees of success.
One the one hand I've felt some of the ageist pressure, on the other most of the analysis is flawed and overly emotional.
At the end of the day it boils down to what have you done lately and what can you do for me now?
Wednesday, June 10, 2009
Appropriate use
Over the weekend I sent a link to MagLev to the CTO of the Paying Day Job.
His reply was
When building things in the real world various materials have an appropriate use. You can use materials inappropriately, however there is usually a price to pay.
In computing we tend to ignore this for a variety of reasons. Generally I attribute this to the plasticity of the media and the fact that there's not a lot of difference between one tool and another.
However, when you pick the slowest language in the Shootout and then couple it with a single-threaded framework (we're frozen pre 2.2) you know that you're not building a system that can handle 100's of transactions per second.
You can build a F1 car on an F-150 chassis, just don't expect to be competitive.
His reply was
Remind me to look at this later when we are focused on tuning the system...to which I replied
Monday this came-up with one of the Architects who brought up the optimization canard.
Putting performance and scalability off to 'later' is not a good idea. Performance and scalability are by design, not a bolt-on.
When building things in the real world various materials have an appropriate use. You can use materials inappropriately, however there is usually a price to pay.
In computing we tend to ignore this for a variety of reasons. Generally I attribute this to the plasticity of the media and the fact that there's not a lot of difference between one tool and another.
However, when you pick the slowest language in the Shootout and then couple it with a single-threaded framework (we're frozen pre 2.2) you know that you're not building a system that can handle 100's of transactions per second.
You can build a F1 car on an F-150 chassis, just don't expect to be competitive.
Saturday, June 6, 2009
RESTful Java
Wednesday, June 3, 2009
Sunday, May 31, 2009
UNIT (uber nerd in training)
This is granddaughter Camryn browsing my tech library... she immediately goes for Stevens' UNIX Network Programming and TCP/IP Illustrated... a solid background in the classics is central to any tech education.
She starts Category Theory next week :-)
Saturday, May 30, 2009
Thursday, May 28, 2009
Tachyon debugger
Saw this old post about odb this morning, makes me think Ruby should have something like it.
I'd call it the Tachyon debugger, which of course brain links to one of the best bad movies of all time.
The neurons are firing on all synapses this morning! :-)
I'd call it the Tachyon debugger, which of course brain links to one of the best bad movies of all time.
The neurons are firing on all synapses this morning! :-)
One editor to rule them all...
Another decent intro to using gvim as your ide. This if for python but would work equally well for ruby.
Toss this in for debugging and you're off to the races.
I love vi, vi loves me :-)
Toss this in for debugging and you're off to the races.
I love vi, vi loves me :-)
Sunday, May 24, 2009
Thursday, May 21, 2009
Wednesday, May 20, 2009
Drunkard's Walk
I put The Drunkard's Walk into my library queue this morning, it got me to thinking about my issues with the current fads (TDD, BDD, Agile, pair, ...) in software development. I'm wondering if our numerous false conceptions about the way things work aren't at the root cause of the problem.
Brains are certainly tricky devices :-)
Brains are certainly tricky devices :-)
Tuesday, May 19, 2009
Testing
We're using RSpec & TDD on this engagement.
TDD is no great shakes, the cart before the horse imo but to each their own.
I am increasingly worried about what specs 'prove' (in the loosest sense) about the correctness of code. And even more about what they say about code as it changes.
I've looked at generating tests (and correctness 'proof') from the AST via RubyParser but even a simple class here has at least several mixins and before/after filters. Given Bob Martin's RailsConf snark about Smalltalk's "death" ("it's too easy to make a mess" (via Ward Cunningham)) that's definitely the pot calling the kettle black.
We'll see where this goes.
TDD is no great shakes, the cart before the horse imo but to each their own.
I am increasingly worried about what specs 'prove' (in the loosest sense) about the correctness of code. And even more about what they say about code as it changes.
I've looked at generating tests (and correctness 'proof') from the AST via RubyParser but even a simple class here has at least several mixins and before/after filters. Given Bob Martin's RailsConf snark about Smalltalk's "death" ("it's too easy to make a mess" (via Ward Cunningham)) that's definitely the pot calling the kettle black.
We'll see where this goes.
Monday, May 18, 2009
Back
Wow, looking at that last post it's been awhile, lots of water under the bridge.
Spent most of last year working on SolarPowerMe (ActionScript, Ruby, Rails, WebOrb). We then took those ideas and simplified them and moved them to Facebook (all Ruby, Rails, and Facebooker)
That didn't pan out so now I'm on a Ruby/Rails contract gig in KC.
Ruby & Rails is fine but really nothing new (for an old Smalltalk guy :-)... I'm working on some ideas that interest me in OCaml... more about those here later.
Spent most of last year working on SolarPowerMe (ActionScript, Ruby, Rails, WebOrb). We then took those ideas and simplified them and moved them to Facebook (all Ruby, Rails, and Facebooker)
That didn't pan out so now I'm on a Ruby/Rails contract gig in KC.
Ruby & Rails is fine but really nothing new (for an old Smalltalk guy :-)... I'm working on some ideas that interest me in OCaml... more about those here later.
Pair programming
I've come to the end of my patience with pair programming.
I can't say whether or not pairing is a good idea in general, for me personally it's a bad idea.
I could be glib and say watching someone else program is about as satisfying as watching someone else have sex... but there's more to it than that.
The communication pairing requires is antagonistic to the deep thinking that programming generally requires (for me). I suppose it's another symptom of the 'multi-tasking' attitude that gives most things (driving, conversation, programming, thinking) such short shrift.
Anyway, on to the next silver bullet! :-)
I can't say whether or not pairing is a good idea in general, for me personally it's a bad idea.
I could be glib and say watching someone else program is about as satisfying as watching someone else have sex... but there's more to it than that.
The communication pairing requires is antagonistic to the deep thinking that programming generally requires (for me). I suppose it's another symptom of the 'multi-tasking' attitude that gives most things (driving, conversation, programming, thinking) such short shrift.
Anyway, on to the next silver bullet! :-)
Subscribe to:
Posts (Atom)