Absolutely! All too often we're guilty of saying "open the data because that's what I believe you should do", not "open the data because this is how it will make your life easier" or "open the data because this is how it will help you do your job", etc. It's come from a technologist-centric pull, but it won't succeed until it becomes a bureaucrat-originated push.
Hi, zuzulo. A versioning system would definitely be part of the solution, but there's more than git behind a successful open source project. In my post, I tried to sketch some of the tools that the data world is missing. Even if everyone just slapped the data into git, that implies it's stored in a format that makes it look like source code and so is amenable to diff and patch. What if we add a new column to the database? That affects every row, but should it be stored as a completely new version of the data? There are lots of interesting questions.
Thanks! In a testament to the power of caffeine and good friends, that chapter came together in the space of about four nights. I'd work regular business hours doing editing, then at 9 or 10pm I'd write the XML chapter. I got great feedback and clarifications from Matt Sergeant, Dan Brian, Michel Rodriguez, Adam Turoff, Robin Berjon, and other such Perl XML luminaries.
As you would have guessed if you heard me speak in 2000, I'm not the biggest XML user. I've mellowed since then, but I still don't do a lot of XML hacking. (One of the spare-time hacking things I've while here at O'Reilly, though, is to get our internal database of "what books are at what stage" into XML for easy grepping and reuse).
Of all my work in the 2nd edition of the Cookbook, the XML chapter is the one I'm proudest of. I'm really glad you like it. Thanks!
Was it dropped because of a feud? It's great to be told why I do things:-) I don't remember it that way. The bit we deleted was just not a very useful observation. As you can tell, we tended to drop the parenthetical asides (when we remembered) to try and prevent bloat. My biggest fear was that we'd break 1k pages in this edition...
But I guess it's convenient to think of everything that happens as being the result of a feud and ignore inconvenient facts like the "Schwartzian Transform" name still being mentioned in the long entry on sort function in Programming Perl, 3ed, which Tom also cowrote. Hmm, maybe I shouldn't point that out--now I'll be accused of having a feud with Randal!
If you're going to have thoughts like these, could you please keep them to yourself? Some of us appreciate Allison, Elaine, Elizabeth, Kudra, and the other women in Perl for the great things they've done. I would like them to stay around and do more great things rather than be driven away because every time one of them comes to a conference she's nervously looking over their shoulder wondering which guy is the anonymous coward thinking about her boobs. Comments like yours set up a totally creepy environment for women.
And if Allison doesn't post in this thread, it's not because she's thinking "great, men are finally noticing women's bodies and commenting publicly on them". It's because she's off working on open source.
If anyone wants to talk to me about this at OSCON, I'd be happy to explain more forcefully just how much this coward's comment pisses me off.
Not true. Some simple esearch, would show that we take books in Word, Framemaker, rudimentary TeX, DocBook SGML and XML, HTML, WordPerfect, and Perl's POD format. Our production process ends up with books in XML or Framemaker, so we prefer input formats that can be readily converted into these formats.
--Nat
Editor at ORA
Response from the editor of Essential Blogging
on
Essential Blogging
·
· Score: 5, Insightful
Hi, I'm Nathan Torkington, the editor of Essential Blogging. 3/10. Wow, that stings:-) I'm not sure it's entirely justified, though.
The numeric rating really seems disproportionate, as the reviewer did have some good things to say:
"for a person who is determined to keep a daily journal available on the Internet, it would provide helpful reading material"
"the depth of covered material is surprisingly large for such a narrow topic"
The reviewer appears to think that people are either hackers, or will use LiveJournal (a system we didn't cover in depth in book). I take issue with that.
The primary audience for Essential Blogging is someone who is new to blogging. If you already use a blogging system like Movable Type, you'll learn something from the book (Ben and Mena, the authors of Movable Type, wrote a lot of new material for their chapters), but you are not the primary audience. We even say this in the preface, and the back cover pretty clearly states what's inside: "Essential Blogging helps you select the right blogging software for your needs
and shows you how to get your blog up and running."
Someone new to blogging can read Chapter 1 to learn about the different aspects of a blogging system; the pros and cons of self-hosting vs hosted, desktop vs server; and ultimately decide which web journal system to use. Then they can read the chapters specific to their chosen system to get started, and return when they're ready to customize the appearance of their blog.
While working on the book, I kept my Dad in mind. He's technical, not stupid, and if he wanted to start a blog, what I want him to know about? The audience also explains the screenshots--if you're new to blogging, you don't to know what to expect nor what the possibilities are. Although it's hard for the reviewer to imagine there are people who haven't been hacking web sites and writing their own blogging systems since 1996, such people do exist.
But even people who already blog and are entrenched in a particular blogging system should check out the others. I'm a Movable Type user myself, but it was a real eye-opener to use Radio Userland for a while. The whole approach to software and blogging is different in Radio Userland, and it makes you look at your own setup in a new light. I'm not saying you need to buy Essential Blogging to do this, but such comparisons are a benefit of having multiple systems presented side-by-side in the one book.
About the only thing I agree with the reviewer wholeheartedly on is that it's a shame we don't cover LiveJournal more. When the book was being developed, I didn't see the geek interest in LiveJournal that I see now. Perhaps in the second edition we'll have chapters on LiveJournal.
So to conclude, I sure hope the old saying that there's no such thing as bad publicity is true. I hope the next book gets a real review (more than six paragraphs) by someone who reads the preface:-).
--Nat
(blogs on O'Reilly Network and use.perl, as well as several Movable Type installations for family, and a Blossom blog for work)
Everyone's entitled to their opinion, but I respectfully disagree. I've worked closely with Damian since 1998 or so, and he's never once been disingenuous or greedy. Your idea of his character is the complete opposite of my experience--perhaps a grad student's opinion of their advisor isn't the most unbiased?
As for his contribution to Perl and Perl 6, make no mistake that it's critical. 2001 Damian was a cheerleader who showed people that Perl is still a vibrant fun language. Latin, Klingon, Quantum::Superpositions, and SelfGOL are all part of that.
In 2002, Damian's two main tasks are to back up Larry in the development of Perl 6 (and make no bones that we would not have the Apocalypses we have today without Damian's hard and unsung work behind the scenes) and to produce Parse::FastDescent (which will make thousands of Perl programmers' lives easier and less prematurely-bald:-).
I can't emphasize enough the "unsung" part. Damian is famous within the Perl community for his crazy modules and Vulcan nerve-pinch grasp of the language. But very few people know what he does to support Larry and perl6 development, because he has deliberately chosen to not publicise that work. Every Exegesis is priceless--in the development of the Exegesis Damian invariably finds omissions or contradictions in the Apocalypse, he gets clarifications on real world issues we didn't realize existed in the Apocalypse, and he helps translate the oft-heady Apocalypse into the real world pragmatic code that Perl programmers need.
Damian's an integral part of perl 6. I couldn't stand back and let only one side of the story be told. We now return you to your regularly scheduled "me too" and "First post!":-)
No conspiracy or disrespect--Larry only recently stepped forward to say "you know, if you wanted to save me from the time sink of a day job, I could get through this perl6 thing a whole lot faster." (my words, not his). Dan and Damian have been on the cards since late last year.
Ha! Vacation? No. The travel budget comes from our goal of keeping the people we fund active in the community. That means sending them to conferences like YAPC and OSCON, as well as regular trips to see other Perl Monger groups.
Damian has set the bar very high in this regard--see the start of his 2002 schedule, and read his 2001 diary to see how much he gets around. While I doubt Larry and Dan will be travelling internationally as much as Damian, we do want them to visit user groups outside their home town.
In an ideal world, a conference would pay Larry to be Larry. Unfortunately, you might have noticed that this world isn't ideal. Larry has to pay his own way to conferences, just like everyone else.
We're not granting people money we don't have. We've issued 4-month grants to Damian and Larry, and a 3-month grant to Dan. That's what we do have money for. During the coming months, we'll be fundraising to raise the rest of the year's money so we can make further grants.
As for freeness being an issue, we're actually surprised at how readily people will donate. It's just a matter of having someone on the ground to make the presentation and explain the benefits. Dan's going to be handling that part-time for the duration of his grant, and we expect great things as a result.
So yes, it is bad policy to grant money you don't have. Fortunately for us, we're not doing that:-)
It's real--the checks went out last week. The idea is to get people started on their good work, rather than waiting for however long it takes to raise the rest of the cash. Part of Dan's duties will be to raise the rest of the money. Having someone without the distractions of a day job (I edit books, Kevin runs a company) to handle the corporate fundraising should make the rest of the money easier to raise.
I meant that while Microsoft is funding and
encouraging other languages to compile down to the IL, Sun never seemed to do that with the JVM.
As far as I could tell (and I am the first to
admit that I am on the fringe of the Java world), their main push was to have Java be The Language. I'm interested to hear whether they really did encourage other languages to compile to the JVM.
0) Tsk tsk on those of you who believe everything Microsoft say. When they said they were paying Activestate to make Perl work better on NT, you forgot to translate that back into honest English: they're paying Activestate to implement fork() on NT so that NT can become more like Unix (a slower buggier more crashprone Unix). Yes, Microsoft for "bring up to baseline of minimum acceptable functionality" is "make it work better". Another way of saying this is "make NT suck less for Perl users". Perl is all about making your OS suck less.
1) Perl's version numbering is changing because major changes in functionality (e.g., the introduction of threads and a compiler) were hidden in the thousands decimal point of the version number. Hopefully this new numbering system will make it more obvious that things have changed. It's a small cosmetic change, not technical, but it's something people wanted.
2) Lexical warnings. Perl's philosophy is "there's more than one way to do it". With warnings as they were, there were only two ways to do it: all warnings enabled, no warnings enabled. Now you can say "I know it looks to the compiler as though I only use this variable once, but don't issue a warning". If you don't see yourself wanting to use it, don't panic--unless you explicitly use the new warning doodads, your programs will emit as few or as many warnings as before.
3) Sarathy is a smart smart guy. He's not an NT flack. He's a smart Unix guy who happens to be employed at Activestate because that's about the only place a guy can be hired to work on the Perl internals. He does far more work on the Perl core to benefit everyone than he does Windoze-specific work. If you're going to be at the Perl+Apache+Linux+... uberconference that O'Reilly are organizing, I urge you to seek him out (he won't be hard to find) and have a talk about your concerns. He'll be the first to agree that NT sucks hard.
4) Unicode reading (via UTF8) is implemented as an add-on module, so that only the part of your program that needs to know about Unicode takes any speed hit. It's also simple to turn programs that used to read ASCII text into programs that read Unicode text: just add "use utf8" at the top. We don't anticipate slowdowns anything like those that one Slashdot reader reported in Tcl.
5) The Unicode support only extends to reading and processing text, not to Perl's interaction with the system (filenames, error messages, etc.) I believe that Windows deals with UTF in the same way that many Unices deal with long files: a separate set of OS functions are provided. The Unicodification of Perl is being extended to use these parallel functions, if present. Generalizing this is hard because, like Unix and long files, everyone does it different. That doesn't mean that Sarathy's work precludes this happening for any other operating systems that provide Unicode support like this. In fact, having the first work done will make support for other operating systems easier. And the best bit is that Microsoft are paying for it.
I don't know about you, but I'm all for fleecing Uncle Bill.
Slashdot Mirror
Absolutely! All too often we're guilty of saying "open the data because that's what I believe you should do", not "open the data because this is how it will make your life easier" or "open the data because this is how it will help you do your job", etc. It's come from a technologist-centric pull, but it won't succeed until it becomes a bureaucrat-originated push.
Could you post a link to your thesis? It sounds interesting. Thanks!
Hi, zuzulo. A versioning system would definitely be part of the solution, but there's more than git behind a successful open source project. In my post, I tried to sketch some of the tools that the data world is missing. Even if everyone just slapped the data into git, that implies it's stored in a format that makes it look like source code and so is amenable to diff and patch. What if we add a new column to the database? That affects every row, but should it be stored as a completely new version of the data? There are lots of interesting questions.
As you would have guessed if you heard me speak in 2000, I'm not the biggest XML user. I've mellowed since then, but I still don't do a lot of XML hacking. (One of the spare-time hacking things I've while here at O'Reilly, though, is to get our internal database of "what books are at what stage" into XML for easy grepping and reuse).
Of all my work in the 2nd edition of the Cookbook, the XML chapter is the one I'm proudest of. I'm really glad you like it. Thanks!
--Nat
But I guess it's convenient to think of everything that happens as being the result of a feud and ignore inconvenient facts like the "Schwartzian Transform" name still being mentioned in the long entry on sort function in Programming Perl, 3ed, which Tom also cowrote. Hmm, maybe I shouldn't point that out--now I'll be accused of having a feud with Randal!
--Nat
And if Allison doesn't post in this thread, it's not because she's thinking "great, men are finally noticing women's bodies and commenting publicly on them". It's because she's off working on open source.
If anyone wants to talk to me about this at OSCON, I'd be happy to explain more forcefully just how much this coward's comment pisses me off.
--Nat
--Nat
Editor at ORA
The numeric rating really seems disproportionate, as the reviewer did have some good things to say:
- "for a person who is determined to keep a daily journal available on the Internet, it would provide helpful reading material"
- "the depth of covered material is surprisingly large for such a narrow topic"
The reviewer appears to think that people are either hackers, or will use LiveJournal (a system we didn't cover in depth in book). I take issue with that.The primary audience for Essential Blogging is someone who is new to blogging. If you already use a blogging system like Movable Type, you'll learn something from the book (Ben and Mena, the authors of Movable Type, wrote a lot of new material for their chapters), but you are not the primary audience. We even say this in the preface, and the back cover pretty clearly states what's inside: "Essential Blogging helps you select the right blogging software for your needs and shows you how to get your blog up and running."
Someone new to blogging can read Chapter 1 to learn about the different aspects of a blogging system; the pros and cons of self-hosting vs hosted, desktop vs server; and ultimately decide which web journal system to use. Then they can read the chapters specific to their chosen system to get started, and return when they're ready to customize the appearance of their blog.
While working on the book, I kept my Dad in mind. He's technical, not stupid, and if he wanted to start a blog, what I want him to know about? The audience also explains the screenshots--if you're new to blogging, you don't to know what to expect nor what the possibilities are. Although it's hard for the reviewer to imagine there are people who haven't been hacking web sites and writing their own blogging systems since 1996, such people do exist.
But even people who already blog and are entrenched in a particular blogging system should check out the others. I'm a Movable Type user myself, but it was a real eye-opener to use Radio Userland for a while. The whole approach to software and blogging is different in Radio Userland, and it makes you look at your own setup in a new light. I'm not saying you need to buy Essential Blogging to do this, but such comparisons are a benefit of having multiple systems presented side-by-side in the one book.
About the only thing I agree with the reviewer wholeheartedly on is that it's a shame we don't cover LiveJournal more. When the book was being developed, I didn't see the geek interest in LiveJournal that I see now. Perhaps in the second edition we'll have chapters on LiveJournal.
So to conclude, I sure hope the old saying that there's no such thing as bad publicity is true. I hope the next book gets a real review (more than six paragraphs) by someone who reads the preface :-).
--Nat
(blogs on O'Reilly Network and use.perl, as well as several Movable Type installations for family, and a Blossom blog for work)
As for his contribution to Perl and Perl 6, make no mistake that it's critical. 2001 Damian was a cheerleader who showed people that Perl is still a vibrant fun language. Latin, Klingon, Quantum::Superpositions, and SelfGOL are all part of that.
In 2002, Damian's two main tasks are to back up Larry in the development of Perl 6 (and make no bones that we would not have the Apocalypses we have today without Damian's hard and unsung work behind the scenes) and to produce Parse::FastDescent (which will make thousands of Perl programmers' lives easier and less prematurely-bald :-).
I can't emphasize enough the "unsung" part. Damian is famous within the Perl community for his crazy modules and Vulcan nerve-pinch grasp of the language. But very few people know what he does to support Larry and perl6 development, because he has deliberately chosen to not publicise that work. Every Exegesis is priceless--in the development of the Exegesis Damian invariably finds omissions or contradictions in the Apocalypse, he gets clarifications on real world issues we didn't realize existed in the Apocalypse, and he helps translate the oft-heady Apocalypse into the real world pragmatic code that Perl programmers need.
Damian's an integral part of perl 6. I couldn't stand back and let only one side of the story be told. We now return you to your regularly scheduled "me too" and "First post!" :-)
--Nathan Torkington
--Nathan Torkington
Damian has set the bar very high in this regard--see the start of his 2002 schedule, and read his 2001 diary to see how much he gets around. While I doubt Larry and Dan will be travelling internationally as much as Damian, we do want them to visit user groups outside their home town.
In an ideal world, a conference would pay Larry to be Larry. Unfortunately, you might have noticed that this world isn't ideal. Larry has to pay his own way to conferences, just like everyone else.
--Nathan Torkington
As for freeness being an issue, we're actually surprised at how readily people will donate. It's just a matter of having someone on the ground to make the presentation and explain the benefits. Dan's going to be handling that part-time for the duration of his grant, and we expect great things as a result.
So yes, it is bad policy to grant money you don't have. Fortunately for us, we're not doing that :-)
Nathan Torkington
--Nat
--Nat
Poor choice of words on my part, sorry for the confusion. See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml for a great list of languages that compile to the JVM.
--Nathan Torkington
0) Tsk tsk on those of you who believe everything Microsoft say. When they said they were paying Activestate to make Perl work better on NT, you forgot to translate that back into honest English: they're paying Activestate to implement fork() on NT so that NT can become more like Unix (a slower buggier more crashprone Unix). Yes, Microsoft for "bring up to baseline of minimum acceptable functionality" is "make it work better". Another way of saying this is "make NT suck less for Perl users". Perl is all about making your OS suck less.
1) Perl's version numbering is changing because major changes in functionality (e.g., the introduction of threads and a compiler) were hidden in the thousands decimal point of the version number. Hopefully this new numbering system will make it more obvious that things have changed. It's a small cosmetic change, not technical, but it's something people wanted.
2) Lexical warnings. Perl's philosophy is "there's more than one way to do it". With warnings as they were, there were only two ways to do it: all warnings enabled, no warnings enabled. Now you can say "I know it looks to the compiler as though I only use this variable once, but don't issue a warning". If you don't see yourself wanting to use it, don't panic--unless you explicitly use the new warning doodads, your programs will emit as few or as many warnings as before.
3) Sarathy is a smart smart guy. He's not an NT flack. He's a smart Unix guy who happens to be employed at Activestate because that's about the only place a guy can be hired to work on the Perl internals. He does far more work on the Perl core to benefit everyone than he does Windoze-specific work. If you're going to be at the Perl+Apache+Linux+... uberconference that O'Reilly are organizing, I urge you to seek him out (he won't be hard to find) and have a talk about your concerns. He'll be the first to agree that NT sucks hard.
4) Unicode reading (via UTF8) is implemented as an add-on module, so that only the part of your program that needs to know about Unicode takes any speed hit. It's also simple to turn programs that used to read ASCII text into programs that read Unicode text: just add "use utf8" at the top. We don't anticipate slowdowns anything like those that one Slashdot reader reported in Tcl.
5) The Unicode support only extends to reading and processing text, not to Perl's interaction with the system (filenames, error messages, etc.) I believe that Windows deals with UTF in the same way that many Unices deal with long files: a separate set of OS functions are provided. The Unicodification of Perl is being extended to use these parallel functions, if present. Generalizing this is hard because, like Unix and long files, everyone does it different. That doesn't mean that Sarathy's work precludes this happening for any other operating systems that provide Unicode support like this. In fact, having the first work done will make support for other operating systems easier. And the best bit is that Microsoft are paying for it.
I don't know about you, but I'm all for fleecing Uncle Bill.
Nat