Confirming the report of the other two posters, Neverwhere was originally written as a six-episode miniseries for the BBC. It's not without its charm, but the book is better. (The effects for Islington were good, but the Beast was a bit of a let down.)
I saw it at a local authorless book signing to promote Neverwhere's release. (And I still got an autographed copy.)
There's been a persistent rumor of a Neverwhere movie, but it seems to be overdue...
That's exactly it. If TransGaming can attract 20,000 monthly subscribers, it'll be a big sign to game publishers. "There are enough people out there who want to play your game on their own platform that they've paid extra money to make it possible."
I can't see how this is bad for Linux gaming in general. Maybe Loki and Tribsoft have publishers beating down their doors, saying "Please port my game so we can sell a few thousand more copies in three months!" That's probably not happening.
TransGaming's subscriber base could really legitimise Linux gaming in the near future. I wouldn't be surprised if that helps the porters in the long term.
Would you settle for a mapping of Direct3D calls to Mesa's and GLX? Transgaming is working on just a beast. It's distributed as a Wine patch, and has been improving.
These are server products, where the statistics you give are for desktop market share. Things are entirely different in the land of web server operating systems.
The poster who pointed out the relatively new O'Reilly OnLAMP site hit the crux of the matter, in my opinion. Tim O'Reilly's more interested in driving and promoting promising new technologies than creating them. (I suspect that's why the company has invested in Digital Creations, the people behind Zope.)
On the other hand, the Python, Java, and Perl advocacy (with books and conferences) are dedicated to promoting existing technologies. Either way, it seems that Tim's focus is on evangelizing good technology.
I tried to avoid the term 'apprenticeship' because it might bring to mind unpleasant connotations, and because it assumes that all people being mentored are less capable programmers than their mentors.
Interestingly, the Perl 6 community has had a similar proposal since I wrote this article. The objective there is to get capable programmers familiar with Perl internals. It's possible to help out beginning programmers, too, but someone who already knows how to code fairly well could get into the guts of the regex engine or optimize pp_hot.c better with guidance from someone who's already been there.
(OT Sig comment: If I could pick a guitar mentor, it would be Michael Roe.)
Hey, I'm trying to understand it. (It's working well for me on one project.)
I would consider delivering software on time to be maximizing business value. I also wouldn't be surprised if managers *expected* software to slip release dates and go over budget.
And programmers know this, and pad their estimates. And managers know this, and cut the estimates. Repeat until you get something about as absurd as what exists today in many shops.
On the other hand, you're right about contracts being different in XP shops. My eyes glazed over in that chapter, but I do remember it.
Jon Udell had a similar idea at least two years ago (see his book, Practical Internet Groupware).
There are plenty of programs out there that can work well with just an HTML+JavaScript interface, especially if you have a small database (even a DB_File!) on your machine, and an interpreter for a scripting language like Perl or Python.
I'm curious to see whether it does anything more than Jellybean can... there's something compelling about a tiny local web server with the power of mod_perl and a simple interface that lets you build persistent, network aware applications that can replicate data between clients. With XPCOM, it's certainly possible to write a nicer interface than one that only has HTML Form widgets and some onClick handlers.
The important thing to remember is that all of the recommendations fit together. You can take just one (simple design, comprehensive unit testing), apply it to your work, and see some benefit. If you use all of them together, the interactions will give you more benefit.
If you avoid the tenets of 'simple design' and 'reduce complexity', you'll have lots of trouble testing things. You'll spend lots of time debugging complex interactions between components.
However, if you decouple things, test aggressively, and use simple and sane interfaces whenever possible, you'll have less difficulty. It's not a magic bullet, but simplicity really is a virtue in this case.
Finally, the idea that change is always more expensive in the future is a very pervasive belief in software engineering. I'm not so sure. I can't back it up, but I'm willing to bet that projects like the Gimp, Mozilla, and even Apache have spent or will spend more on their ground-up rewrites than they would have spent refactoring and simplifying. (Heck, I'd pay money to get a set of unit tests with a web browser!)
I have no way to prove that. Then again, that CS professor who said "It will cost more to change things in the future" couldn't prove it either, and I know he'd never worked with requirements that changed every two months.
At least in the software I'm writing where I can use XP, it's helping.
--
Re:Linus should have his own action-figure line
on
Linus Talks About 2.4
·
· Score: 1
You're in luck, there are already action figures for Linux, Woz, maddog, Larry Wall, and others. Nitrozac's way ahead of you.
I haven't worked all the way through Linux Programming Unleashed... if there's a review there, it won't be smiley happy. Look back to the second or third of the Learning Linux articles for some harsh comments about a book that got stuff wrong.
I don't take the scores too seriously, though. I take off points for stuff that's obviously wrong, stuff that's hard to read, and stuff that doesn't fit the focus of the book. Beyond that, you're just reading a summary based on my opinions. They're free, non-fattening, and if Hemos sends me a copy of Teach Yourself and Other Assorted Idiots Perl 6 in 24 Minutes, I'll rip it up. Just for you.
According to Jeff, there's already a second edition of this book planned, with additional goodies on performance tuning (including information on non-core patches from... SGI? can't remember). It sounds like that book will cover Apache 2.0.
I'll certainly be reading the second edition this time next year.
It's been that way in all of my reviews for at least the past six months. Call me wishy washy if you like, but I didn't care for the simple, black and white "What's Hot and What's Not?" the other phrases suggested.
The image that's supposed to come to mind is, "Okay, that all sounds nice. Now why might I not want to buy or read this book?" Sometimes I point out flaws in books, but most of the time I try to clarify things that don't show up in a quick perusal. ("Hey, this book on the Gimp doesn't talk about plugins! I thought it would.")
Besides, I don't often review books I don't like. I don't have the spare time.
The bulk of the new material came from Guelich and Birznieks. They credit Gundavaram for some updated material, but he apparently didn't provide enough to write a new author preface.
As for the examples, I've flipped through approximately half of the new edition, finding nothing that you described. The provided code is mostly short and sweet. The e-mail addresses used in the e-mail chapter examples are all fake, too.
As for the affiliate payments, no one ever tells me if anyone makes any money off of the referrals. I don't care, either. They send me 10 pounds of fresh bacon every month if I like the books or not. Don't just take my word for it, though, flip through the book at your local bookstore on your own. Not everyone looks for the same things I do.
If you mean Perl 5.6, the current stable version, the 3rd edition of Programming Perl covers it in abundant detail. Expect that review to be posted sometime in the next couple of weeks.
The 4th edition of the Camel will cover Perl 6, which is still in the design stages. Don't expect even a beta release for a year.
That feature already exists. All stories with blurbs longer than the paragraph on the main page (including editorials and book reviews) have a link which excludes comments. Simply click on the link titled "x bytes in body".
I've had to deal with enough "technical recruiting" companies that they're not getting off the hook. If businesses really cared about the kinds of workers they were getting, they'd do more than call up Rent-Warm-Bodies Technical Staffing and say "We'll pay you $500,000 to get us some people."
The recruiting companies don't care about good matches, additional skills, or paying decent wages with benefits. They want to place people fast and collect the difference in pay.
The companies that use the recruiters don't want to pay for benefits, hire people for the long term, invest in training, or spend the time it might take to find the right person for the right job. They want to pay someone else to do all of that for them.
What the unfortunate workers run into is that they have little training, less pay than a real employee, poor benefits, and an extra layer of management to deal with. Why should they work hard to keep the company strong when they see no benefits like stock options, employee recognition, or raises and bonuses?
Want a fun week? Put a resume with hot techie buzzwords up on some web site and see how many "placement services" jump at you. Then try to get some details about the job. Heh.
You see, each GUI in the world actually presents a fiction to the user, e.g., files are "documents" that are stored in "folders" which can be "moved" to the "trash".
That's a very striking point. As Dilger points out, that original interface made sense because the target audience for such a GUI was business workers already familiar with real files, real folders, and real trash cans.
Expecting college students (who probably don't have much work experience in a paperful office) to have an existing knowledge of such things is a problem: The fiction has to be learned.
It doesn't make sense to base the interface metaphor on experience and knowledge the users don't have! You wouldn't expect a city kid to know how to milk a cow, or a bushman to drive a city bus, without some training.
The problem is, users end up learning this metaphor as if it were the truth of things, and not just a convenient mental model to explain the bare metal underneath.
I say, if you're going to have to teach something from scratch, find a better metaphor based on something the users already know, or stick to teaching the actuality of things. Don't maintain the cargo cult repetition of ritual without understanding.
(Yes, this issue is near and dear to me. I've mentioned A GUI for Gurus before, and i'll keep mentioning it until someone builds it. Maybe the Entity folks...)
Slashdot Mirror
So if you DON'T want them to use it, just stick in a tag.
In other words, if I don't want IE 6 adding smart links to any of my web pages, all I have to do is opt out on each and every?
Please pardon me if I'm still less than thrilled.
--
I'm as shocked as you are. What next, companies named 'omphaloskepsis', 'agilent', or 'diastema'?
--
That's okay. I got nausea after playing the original Doom, so it's not like there isn't prior art.
--
Confirming the report of the other two posters, Neverwhere was originally written as a six-episode miniseries for the BBC. It's not without its charm, but the book is better. (The effects for Islington were good, but the Beast was a bit of a let down.)
I saw it at a local authorless book signing to promote Neverwhere's release. (And I still got an autographed copy.)
There's been a persistent rumor of a Neverwhere movie, but it seems to be overdue...
--
If you set $\ (or $OUTPUT_FIELD_SEPARATOR if you use the English pragma), you can use whatever you like, including \n.
My guess is Perl 6 will make this a property of filehandles... seems good to me.
--
That's exactly it. If TransGaming can attract 20,000 monthly subscribers, it'll be a big sign to game publishers. "There are enough people out there who want to play your game on their own platform that they've paid extra money to make it possible."
I can't see how this is bad for Linux gaming in general. Maybe Loki and Tribsoft have publishers beating down their doors, saying "Please port my game so we can sell a few thousand more copies in three months!" That's probably not happening.
TransGaming's subscriber base could really legitimise Linux gaming in the near future. I wouldn't be surprised if that helps the porters in the long term.
--
The *original* node was in fact Brian Eno, as far as I know. (It was in the distributed versions of the source at least through the 0.3 series.)
However, node_id 1 is reserved for the nodetype node, at least since release 0.9. I just verified this with the source on my dev box.
nate sure had no idea way back when.... and there's so much more that can be done with the Engine
--
Would you settle for a mapping of Direct3D calls to Mesa's and GLX? Transgaming is working on just a beast. It's distributed as a Wine patch, and has been improving.
--
These are server products, where the statistics you give are for desktop market share. Things are entirely different in the land of web server operating systems.
The poster who pointed out the relatively new O'Reilly OnLAMP site hit the crux of the matter, in my opinion. Tim O'Reilly's more interested in driving and promoting promising new technologies than creating them. (I suspect that's why the company has invested in Digital Creations, the people behind Zope.)
On the other hand, the Python, Java, and Perl advocacy (with books and conferences) are dedicated to promoting existing technologies. Either way, it seems that Tim's focus is on evangelizing good technology.
--
I tried to avoid the term 'apprenticeship' because it might bring to mind unpleasant connotations, and because it assumes that all people being mentored are less capable programmers than their mentors.
Interestingly, the Perl 6 community has had a similar proposal since I wrote this article. The objective there is to get capable programmers familiar with Perl internals. It's possible to help out beginning programmers, too, but someone who already knows how to code fairly well could get into the guts of the regex engine or optimize pp_hot.c better with guidance from someone who's already been there.
(OT Sig comment: If I could pick a guitar mentor, it would be Michael Roe.)
--
Have you seen The Lain?
Not only has he seen Serial Experiments: Lain, he lent me his copy so I could see it. CowboyNeal is a seriously nice guy.
--
Rob's working on Animefu, Hemos does work on Everything 2, and Nate's the brains and looks behind Everything In General.
What keeps CowboyNeal busy when he's not keeping Slashdot running, or mixing some tasty tunes in his recording studio?
--
Hey, I'm trying to understand it. (It's working well for me on one project.)
I would consider delivering software on time to be maximizing business value. I also wouldn't be surprised if managers *expected* software to slip release dates and go over budget.
And programmers know this, and pad their estimates. And managers know this, and cut the estimates. Repeat until you get something about as absurd as what exists today in many shops.
On the other hand, you're right about contracts being different in XP shops. My eyes glazed over in that chapter, but I do remember it.
--
Jon Udell had a similar idea at least two years ago (see his book, Practical Internet Groupware).
There are plenty of programs out there that can work well with just an HTML+JavaScript interface, especially if you have a small database (even a DB_File!) on your machine, and an interpreter for a scripting language like Perl or Python.
I'm curious to see whether it does anything more than Jellybean can... there's something compelling about a tiny local web server with the power of mod_perl and a simple interface that lets you build persistent, network aware applications that can replicate data between clients. With XPCOM, it's certainly possible to write a nicer interface than one that only has HTML Form widgets and some onClick handlers.
--
First of all, thanks for the comments.
The important thing to remember is that all of the recommendations fit together. You can take just one (simple design, comprehensive unit testing), apply it to your work, and see some benefit. If you use all of them together, the interactions will give you more benefit.
If you avoid the tenets of 'simple design' and 'reduce complexity', you'll have lots of trouble testing things. You'll spend lots of time debugging complex interactions between components.
However, if you decouple things, test aggressively, and use simple and sane interfaces whenever possible, you'll have less difficulty. It's not a magic bullet, but simplicity really is a virtue in this case.
Finally, the idea that change is always more expensive in the future is a very pervasive belief in software engineering. I'm not so sure. I can't back it up, but I'm willing to bet that projects like the Gimp, Mozilla, and even Apache have spent or will spend more on their ground-up rewrites than they would have spent refactoring and simplifying. (Heck, I'd pay money to get a set of unit tests with a web browser!)
I have no way to prove that. Then again, that CS professor who said "It will cost more to change things in the future" couldn't prove it either, and I know he'd never worked with requirements that changed every two months.
At least in the software I'm writing where I can use XP, it's helping.
--
You're in luck, there are already action figures for Linux, Woz, maddog, Larry Wall, and others. Nitrozac's way ahead of you.
--
I haven't worked all the way through Linux Programming Unleashed... if there's a review there, it won't be smiley happy. Look back to the second or third of the Learning Linux articles for some harsh comments about a book that got stuff wrong.
I don't take the scores too seriously, though. I take off points for stuff that's obviously wrong, stuff that's hard to read, and stuff that doesn't fit the focus of the book. Beyond that, you're just reading a summary based on my opinions. They're free, non-fattening, and if Hemos sends me a copy of Teach Yourself and Other Assorted Idiots Perl 6 in 24 Minutes, I'll rip it up. Just for you.
--
According to Jeff, there's already a second edition of this book planned, with additional goodies on performance tuning (including information on non-core patches from
I'll certainly be reading the second edition this time next year.
--
It's been that way in all of my reviews for at least the past six months. Call me wishy washy if you like, but I didn't care for the simple, black and white "What's Hot and What's Not?" the other phrases suggested.
The image that's supposed to come to mind is, "Okay, that all sounds nice. Now why might I not want to buy or read this book?" Sometimes I point out flaws in books, but most of the time I try to clarify things that don't show up in a quick perusal. ("Hey, this book on the Gimp doesn't talk about plugins! I thought it would.")
Besides, I don't often review books I don't like. I don't have the spare time.
--
The bulk of the new material came from Guelich and Birznieks. They credit Gundavaram for some updated material, but he apparently didn't provide enough to write a new author preface.
As for the examples, I've flipped through approximately half of the new edition, finding nothing that you described. The provided code is mostly short and sweet. The e-mail addresses used in the e-mail chapter examples are all fake, too.
As for the affiliate payments, no one ever tells me if anyone makes any money off of the referrals. I don't care, either. They send me 10 pounds of fresh bacon every month if I like the books or not. Don't just take my word for it, though, flip through the book at your local bookstore on your own. Not everyone looks for the same things I do.
--
If you mean Perl 5.6, the current stable version, the 3rd edition of Programming Perl covers it in abundant detail. Expect that review to be posted sometime in the next couple of weeks.
The 4th edition of the Camel will cover Perl 6, which is still in the design stages. Don't expect even a beta release for a year.
--
That feature already exists. All stories with blurbs longer than the paragraph on the main page (including editorials and book reviews) have a link which excludes comments. Simply click on the link titled "x bytes in body".
--
I've had to deal with enough "technical recruiting" companies that they're not getting off the hook. If businesses really cared about the kinds of workers they were getting, they'd do more than call up Rent-Warm-Bodies Technical Staffing and say "We'll pay you $500,000 to get us some people."
The recruiting companies don't care about good matches, additional skills, or paying decent wages with benefits. They want to place people fast and collect the difference in pay.
The companies that use the recruiters don't want to pay for benefits, hire people for the long term, invest in training, or spend the time it might take to find the right person for the right job. They want to pay someone else to do all of that for them.
What the unfortunate workers run into is that they have little training, less pay than a real employee, poor benefits, and an extra layer of management to deal with. Why should they work hard to keep the company strong when they see no benefits like stock options, employee recognition, or raises and bonuses?
Want a fun week? Put a resume with hot techie buzzwords up on some web site and see how many "placement services" jump at you. Then try to get some details about the job. Heh.
--
You see, each GUI in the world actually presents a fiction to the user, e.g., files are "documents" that are stored in "folders" which can be "moved" to the "trash".
That's a very striking point. As Dilger points out, that original interface made sense because the target audience for such a GUI was business workers already familiar with real files, real folders, and real trash cans.
Expecting college students (who probably don't have much work experience in a paperful office) to have an existing knowledge of such things is a problem: The fiction has to be learned.
It doesn't make sense to base the interface metaphor on experience and knowledge the users don't have! You wouldn't expect a city kid to know how to milk a cow, or a bushman to drive a city bus, without some training.
The problem is, users end up learning this metaphor as if it were the truth of things, and not just a convenient mental model to explain the bare metal underneath.
I say, if you're going to have to teach something from scratch, find a better metaphor based on something the users already know, or stick to teaching the actuality of things. Don't maintain the cargo cult repetition of ritual without understanding.
(Yes, this issue is near and dear to me. I've mentioned A GUI for Gurus before, and i'll keep mentioning it until someone builds it. Maybe the Entity folks...)
--
It came out at TPC 4.0 this summer. There'll be a Slashdot review soon, I promise. (Hey, even *I* deserve a vacation.)
--