51–60 of 99 posts
Earlier quoted context omitted.
Really? A Ph.D. in education? I'm not even sure what that would produce. Maybe a post-post-modern _why.
Start watching Alan Kay talks. He explains.
I'm not that jazzed about the idea of reminiscing about a Smalltalk. How about instead of making esoteric references, you just say what's on your mind?
This is a thread, not a bibliography.
Earlier quoted context omitted.
Right now, find a company doing something bad ass with HTTP and then make Mongrel2 blow their socks off. Then repeat it again and again until I've got something. Either that, or getting a Ph.D. in Education.
What's your sales pitch for mongrel2 against things like Unicorn & Passenger. The new features of mongrel2 seem awesome (particularly multiple protocols over the same socket) and given the success of mongrel, I think we all have high hopes for mongrel2. But I'm curious what your thoughts are on what the "killer apps" are for mongrel2 that make it the superior solution to the alternatives.
> "killer apps" are for mongrel2
You just said it. Bypassing any connection limitations on the browser.
Earlier quoted context omitted.
That kind of programming to me is fun. The most boring type of programming possible in my opinion is front end web development.
Personally, I cannot stand the type of programming which is encapsulating a bunch of "BUSINESS LOGIC" in code. I.e. "apply this much tax unless we are in florida or new york, then apply this much. except on the day after christmas..." or even worse, "restrict these parts of the site to the accounting department, except for gary because he's in fiance, too" etc.
Same thing with programming. If you are given enough freedom to do the job right, and you can find a way to motivate yourself, there are no bad programming jobs.
Zed Shaw himself has bragged about a system he wrote which does the kind of business logic you mention -- except by his description it's a meta-programming system that can add rules almost as fast as they can think them up. That sounds like some sort of constraint solver, which is among the fanciest kind of programming around.
Earlier quoted context omitted.
Google says something like that for every job. From what I know about SREs, the "programming" you do is basically shell scripts to automate sysadmin stuff. Programming, sure, but the most boring type possible.
Yeah, SREs don't do all that much hard-core programming, but they need a skill that's almost harder: the ability to quickly evaluate whether a change is likely to bring the system down or otherwise cause reliability problems. SREs get consulted very often by engineers for questions like "Do we have enough capacity to burn 15% more CPU for the next week?" or "Is this change likely to cause an unacceptable risk of serv…
On the contrary, some of the code I've seen written by SREs has been among the most delicate, finely tuned, and "hard core" (by my definition) I've seen.
Earlier quoted context omitted.
Right now, find a company doing something bad ass with HTTP and then make Mongrel2 blow their socks off. Then repeat it again and again until I've got something. Either that, or getting a Ph.D. in Education.
What's your sales pitch for mongrel2 against things like Unicorn & Passenger. The new features of mongrel2 seem awesome (particularly multiple protocols over the same socket) and given the success of mongrel, I think we all have high hopes for mongrel2. But I'm curious what your thoughts are on what the "killer apps" are for mongrel2 that make it the superior solution to the alternatives.
Earlier quoted context omitted.
Yeah, SREs don't do all that much hard-core programming, but they need a skill that's almost harder: the ability to quickly evaluate whether a change is likely to bring the system down or otherwise cause reliability problems. SREs get consulted very often by engineers for questions like "Do we have enough capacity to burn 15% more CPU for the next week?" or "Is this change likely to cause an unacceptable risk of serv…
"SREs don't do all that much hard-core programming" On the contrary, some of the code I've seen written by SREs has been among the most delicate, finely tuned, and "hard core" (by my definition) I've seen.
It's not required, but that pedantic nature seems to help make a good sysadmin.