Monday, December 4, 2006
Friday, December 1, 2006
Thursday, November 30, 2006
Thursday, November 16, 2006
Parrot, as many of you know, is a virtual machine that is intended be a platform for running Perl 6. Actually, the Parrot virtual machine hopes to run many languages other than Perl 6. There is currently beginning implementations of many languages on Parrot including Ruby and TCL. Parrot is different than many other virtual machines that we know of. It is register-based, as opposed to the common stack-based architectures, and it is designed to run dynamic languages.
Listen to hear what Chip has to say about the state of Parrot and what you can do to help out.
Saturday, November 4, 2006
Tuesday, October 24, 2006
Wednesday, October 18, 2006
Check back soon for more contests and book giveaways at Perlcast.
Saturday, October 14, 2006
Users Groups, Conferences, and Workshops
Announcing the 9th German Perl Workshop
The 9th German Perl-Workshop will take place from Wednesday, 21 Feb. 2007 to Friday, 23 Feb.2007 and you are invited to submit proposals for talks or tutorials. We will happily accept proposals for interesting talks related to Perl.
Dates Set for YAPC::NA 2007
The dates for YAPC::NA 2007 have finally been established! The Houston.pm group and YAPC::NA 2007 organizers are pleased to announce that next year's YAPC::NA will be Monday, June 25th through Wednesday, June 27th, at the University of Houston. You can also visit the YAPC::NA homepage at www.yapc.org—America
New Users Group
The Vlaanderen.pm group was formed last month and are beginning to organize at vlaanderen.pm.org
Perl In Print
State of The Onion 10
Larry Wall's State of the Onion 10 is now online on Perl.com. This talk was presented at OSCON 2006.
Perl Review Fall 2006
The Fall 2006 issue of The Perl Review is online and ready for download. Subscribers should have alread received an email telling them all about it. You can even buy TPR on the newsstand now if you shop at Powell's Technical Books in Portland.
In this issue (besides the cover showing the Larry Wall action figure by ArtCard Mike):
- Google's Summer of Code -- Jim Brandt
- pmtools -- Mark Leighton Fisher
- Parrot Magic Cookies -- Jonathan Scott Duff
- Agent-based Programming in Perl -- Guinevere Nell
- ETL Nightmares -- Thomas MacKenzie
- and more!
Google Code Search
Google has released a code search at www.google.com—codesearch
Modules of Interest
Possibly Yet Another Web Framework
Bigtop 0.18 has been released along with some movies demonstrating its capabilities. Bigtop is a language for describing the data of a web application. Usually this data will be stored in a relational database. Once you have a description of your data, you can generate a web application from it. This includes all the pieces you need like: the sql statements ready for feeding to your database command line tool, the httpd.conf you need to Include in the httpd.conf on your system, the modules that will handle the web requests, the models that make the database tables look like classes, etc. Search for BigTop on CPAN to find out more.
The Perl community lost one of its long time contributors, Nick Ing-Simmons, who died of a heart attack on Monday September 25th 2006. Nick was once the Pumpking for Perl 5 and is also a key contributor to the Tk and Encode modules. For more information, please see the Perl Foundation Blog entry at news.perlfoundation.org.
Thursday, September 21, 2006
Conferences, Workshops and User Groups
YAPC NA and EU 2007 Locations Announced
Congratulations to Houston, Texas and Vienna, Austria who have just been announced as the venues for YAPC::NA and YAPC::EU in 2007. Both winning groups faced stiff competition from the likes of Boston, Massachusetts, Philadelphia, Pennsylvania, Lyon, France, and Pisa, Italy.
It's really exciting to see so much competition for YAPC venues. Runners-up need not get discouraged, you already have your proposal for next year!
Pittsburgh Perl Workshop
The Pittsburgh Perl Workshop is quickly approaching. The one-day workshop deemed "Perl at Work" is Saturday September 23rd at Carnage Mellon University in Pittsburgh, P. Register today at pghpw.org. Also when tagging blogs, photos, and other media related to the conference please use the tag "PPW06". And finally, be sure to visit wiki.pghpw.org to keep up with conference happenings and to sign up for post-conference social events.
First Firenze.pm Technical meeting
Firenze Perl Mongers are having a technical meeting on Thursday September 28th. The meeting will be hosted by Dada Spa in Firenze, Italy. Talks include and IPW2006 debriefing, Perl::Tags, and Test-driven programming. If you'll be in the Firenze area on the 28th consider giving a talk or at least stopping by to make the a great initial meeting. More information can be found at firenze.pm.org
The Dutch Perl Workshop 2007
There are rumblings of the organization of a Dutch Perl Workshop in February or March 2007. Please let the organizers know if you'd like to participate in the workshop, especially if you'd be willing to speak. The website for the 2006 Dutch Perl Workshop is workshop.perlpromo.nl.
CPAN::Forum RSS Feeds for PAUSEID
CPAN::Forum has been recently updated. The change that might be the most important, especially for module authors, is that from now anyone can subscribe to e-mail alerts or RSS feeds based on PAUSEID. That includes that author's future modules as well.
If you are wondering what CPAN::Forum is, it is a web forum for discussing Perl's CPAN modules, asking questions, making comments, and helping other users with issues specific to a module. Check out www.cpanforum.com for more information.
CPAN.pm adds support for CPAN::Reporter
As of version 1.87_57, CPAN.pm has support for CPAN::Reporter. CPAN::Reporter is an add-on for the CPAN.pm module that uses Test::Reporter to send the results of module tests to the CPAN Testers project. Consult the CPAN::Reporter POD for details on installation and usage.
cpan6 - moving forward
Mark Overmeer gave a talk at YAPC::Europe 2006 about cpan6. The talk was generally well received has encouraged opening up the debate on CPAN for Perl6 to a wider audience and the beginnings of implementation.
The Perl community is invited to join either the pause6 mailing list for infrastructure discussions and/or the cpan6 tools list for client-side installers and upload tools.
AxKit2 v1.1 Release
The AxKit development team announced AxKit2 version 1.1. AxKit2 is the second generation XML Application Server. AxKit makes content generation easy by providing powerful tools to push XML through stylesheets. This helps ensure your web applications don't suffer from XSS bugs, and provides standardized templating tools so that your template authors don't need to learn new Perl templating tools.
Interfacing with USPS
Business-USPS-WebTools is a new distribution on CPAN that allows you to interact with the US Postal Service's Web Tools. The distribution interfaces with the web services officially offered by the USPS. The current services available include the Address Information services: Address Standardization, Zip Code Lookup, and City/State Lookup. The only catch is that you'll need an account with USPS to actually use the service. Details can be found in the Business-USPS-WebTools POD.
News from P5P
Perl 5.9.4 is out in the wild. It includes quite a few changes, some of which are incompatible with previous versions of Perl. These changes include:
- A bareword argument to chdir() is now recognized as a file handle. Earlier releases interpreted the bareword as a directory name.
- An old feature of perl is that before "require" or "use" look for a file with a .pm extension, they will first look for a similar filename with a .pmc extension. If this file isfound, it will be loaded in place of any potentially existing file ending in a .pm extension. Previously, .pmc files were loaded only if more recent than the matching .pm file. Starting with 5.9.4, they'll be always loaded if they exist.
- The special arrays "@-" and "@+" are no longer interpolated in regular expressions.
- If you call a subroutine by a tainted name, and if it defers to an AUTOLOAD function, then $AUTOLOAD will be (correctly) tainted.
Also, there where four modules added to core:
"Minimal Perl" book has been released
Tim Maher's book entitled "Minimal Perl: for UNIX and Linux People" has just been released from Manning. Its mission is to show readers "How to do the most with the least" while using Perl in UNIX/Linux (and related) environments. For additional details, see MinimalPerl.com and manning.com.
Friday, September 15, 2006
Sunday, September 3, 2006
Thursday, August 24, 2006
Wednesday, August 16, 2006
Randal will be making regular appearances as the Perl News source. You can also hear more from him at the Geek Cruises Podcast.
Tuesday, July 11, 2006
Monday, June 19, 2006
Friday, June 9, 2006
Thursday, May 25, 2006
Tuesday, May 2, 2006
Tuesday, April 18, 2006
Perlcast is back with another interview. This one is with Steve Oualline, the author of "Wicked Cool Perl Scripts".
Welcome to Perlcast. This is your host, Josh McAdams, here with another great interview with a member of the Perl community. This interview is with Steve Oualline, the author of numerous books including the more recent, "Wicked Cool Perl Scripts", published by No Starch Press.
As a bonus, No Starch Press will be giving away a few promotional copies of "Wicked Cool Perl Scripts". To be entered the drawing, simply send an email to perlcast+wicked at gmail.com. That's perlcast, the plus sign, wicked, at gmail.com. Get those entries in by May 1st 2006 to be eligible for the drawing.
Welcome to Perlcast. Today I have Steve Oualline. Steve is the author of "Wicked Cool Perl Scripts". And, welcome to Perlcast Steve.
Thank you very much.
Well, first of all, I guess we'll start by asking, judging from your history of authorship you're a C and C++ programmer, as well as, a Perl programmer. How did you find Perl?
Well, I'm tempted to answer "I just looked in /usr/bin/ and there it was". But, what happened is, is that I'd been looking at scripting languages for a while and Perl seemed to rise to the top for dealing with things you don't want to write a formal program for. And, just want to get something written fast that works and is fairly simple. And the most selectable language to do that.
Well, the book is written assuming that the reader already knows Perl. So how much of a Perl expert should you be to actually use this book?
I think you should have a working knowledge and be able to do the basics. Know how to write a basic program. Know how to download something from CPAN. Which is actually one of the strengths of Perl is you can let somebody else write most of the work and put something together. We don't try into some of the tricky stuff, but just show you how to do the everyday work that you do. It's more of a working-class book than anything else. So if you've done enough Perl that, you know you can write a subroutine, you can do the basics, you can go from there.
There is a huge range of scripts that you cover in this book. And that goes from website management to CGI programming, system administration, games, photos, development, and even a little bit of mapping. Is there any audience in particular that you were trying to address or were you just going for everybody with this book?
I was mostly just trying to show people the wide range of problems that Perl can solve in a way that's rather interesting, because, you know, you've got some things there that, oh it was designed for system administration. Well, we do system administration. But there is so many things that you can put together fairly easily, fairly quickly, such as the time I used it to make maps from my Grand Canyon hike. And, found all that information on the web that could easily be downloaded and displayed. And the real interesting thing now is I've got a two-year old daughter is learning computers and Perl has helped her with the basic keyboard use and now is even taught her now how to find letters on the keyboard. She's working her way up. So, it's just fun.
I thought that was really impressive. The a, the scripts that you had actually written for your daughter that you had in that book. Whenever you went to originally write the book, did you already know that you were going to cover all of that or did it just kind of come about?
Well, I had a number of things that I'd been using it for already and, as for my daughter, that sort of came about during that. She was learning about the keyboard the hard way at that time because she would see me typing and insist on typing and was very upset that I wouldn't let her write the book too. So, we had to get her to play in a nice way with the computer and that's how the, that's how the first script came about. And, now she's on her second one. And we're going from there.
There seems to be quite a few UNIX and Linux specific commands embedded in some of those scripts. Would you consider UNIX to be a necessity for readers of this book?
I would say it is mostly a necessity. You can take some of things, a lot of the things, and move them to Windows, but I designed it with Linux or UNIX in mind. Mostly because, that's where the real adventure comes in. I found that people that are using Linux and Windows [means to say UNIX] are sort of push, they use the technology to push their work forward. And, most of the people I found that are using Microsoft Windows, you're spending your time programming things around the limitations that Windows has set up for you.
In one section of the book you write a comic spider. And, has the website that you spidered changed since writing the book. Because, I know Randal Schwartz had an issue with that. Like, just after he had published a print spider, that the website went and changed like a day after the print.
I don't know because I haven't been using that particular program a lot. I know that they've done some new stuff and some old, those are editorial cartoons and they are constantly changing the artist on that. But the whole thing is designed to show you how you can adjust the spider to pick out exactly what you want. And that was the main thing. And yeah, I expect the people to be able to go down and if somethings not working, to fix it. I mean this is for, the audience I consider are not dummies, they are people that, yes, we don't have everything in there, we don't have slick GUI, this is something that works and what doesn't work, you can tweak it a little bit.
In looking through some of your code examples, I noticed that your regular expressions had just a very interesting and verbose way of commenting them. Where did you pick that up?
I have been in the, working in the area of, what do I want to say, literate, not literate programming, but trying to make programs clear for about, oh, twenty-five years now in various forms and various languages. So I'm always picking up techniques for making things better. And one of the things that happens is, I have learned how to use ASCII to draw pictures and do other graphic things. And so this is a natural fallout of that. Is to have to draw lines to annotate things in order to make something clear. And, regular expressions are a particular challenge because it an extremely compact language for the expressions themselves and you've gotta get something in there to explain it. And that just seemed to be the natural fallout of that.
It's interesting because when I first started working in programming in programming about twenty-five years ago, they said the next great thing that was coming was marrying the word processor to the compiler so that you'd embed graphics and fonts and other things and make your programs look pretty and you wouldn't have to be stuck with this monospaced courier type font. And, I'm still waiting for the day that they do that to make our programs clear because we're still stuck with that silly type font. Till then I'm gonna make due the best I can with all sorts of techniques and that's just one of them. I mean, some other things that I wind up doing are underlining words with equal-signs to make a level-one heading in a, in a comment, or using stars to try to make something look semi-bold. And, just get around the limitations of that silly font we're stuck with.
It is amazing that programmers still are the few people that use plain-text files for everything, so.
On that note, and this is just kind of a side comment. Have you seen or read Damian Conway's "Perl Best Practices" yet. Because he mentions something else there that seems cool also, and that's the x-modifier on regular expressions. I think that mixed with your commenting would be a, you could really explain what was going on.
In a previous book called "Perl for C Programmers", I actually show what happens, what it takes. You take a very messy regular expression and you you comment it my way and then you use the dash-x so that you can comment it the way that Damian has. And, what happens is, is that with my way you get this very very vertical big mess. And with Damian's way, you get this horizontal big mess. And the conclusion I've got is is that, if you're gonna start out with a big mess, even commenting it is still a big mess unfortunately. And, really it has to do with just trying to figure out which better. Either the vertical way that I've done or the horizontal way that can be done with the dash-x. My best is to try to avoid some of those regular expressions if I can help it.
I also noticed that you use CGI::Thin instead of the CGI module. When and why should programmers use CGI::Thing instead of CGI?
What I was looking at was a rather simple interface to the CGI stuff. And, in general I, I tend to not like CGI itself because it is so much stuff stuffed in there. Especially when it comes to the generation of the HTML. I sort of consider that overkill because, if you know HTML, then you can write it directly. And, if you don't know HTML, the functions provided by CGI aren't going to help you. So, why not just, instead of hiding the HTML inside of function layers, just write it yourself.
You also don't need so much of an object-oriented interface for something that is not going to have multiple instances. There is no way in the CGI basic infrastructure to support multiple connections for a single CGI program. It sits there and runs, it does it's job and it stops and that's it. And, that's what you have to deal with. So, I always felt like, that CGI itself was overkill and I was just looking for something that was simple to use, didn't, and fairly fast loading, and that seemed to be the CGI::Thin module.
In your CGI scripts you also always used taint mode. How important is it to actually use that?
I consider sort of the three things necessary for any Perl program, and that is 'use strict', 'use warnings', and if you, if you're running CGI, 'use taint'. And, the taint is of absolute importance because it prevents the user from injecting bad data and just really causing all sorts of problems with your system. Because, a lot of what CGI programs do is pass parameters off to outside programs. Well, if you wind up crafting those parameters, the answers to a lot of the stuff that you have on the form, in a malicious way, you can cause all sorts of trouble. And, so taint mode prevents you from taking anything from the user and passing it directly to a program without checking it for sanity or sanitizing it. And, so it hopefully prevents a lot of problems, and that's why they put it in there, was to prevent this stuff from coming in.
So, it's a basic security check I consider about as important as locking your front door when you leave the house every morning.
There was one thing that I never heard before that I thought was really interesting and that was just a side-bar you had about the history of the carriage-return and line-feed. Was that a true story or was that just for entertainment purposes?
No, that's actually a true story. When I first started working, the first computer I had was connected up with a ASR33 teletype, which was state of the art communications back in 1930. I mean that's when they considered ten characters per second high-speed. And, if you look at the history of that, soon after they first made the telegraph they realized that one of the problems that they had is people had to understand Morse Code and they spent years trying to make things so you didn't need that. And the teletype was one of those that fell out of that and was rather successful. And, the teletype was a mechanical beast. It's a very interesting thing if you ever take a look at it because the keyboard ROM is made out of, entirely out of levers. The shift register that is used to transmit the character looks like a distributor cap on a car. And, it's entirely electromechanical. No transistors in it. And it works if you ever keep it in adjustment, which my boss at the time did. But, he said the teletype is made out of adjustments it's not made out of parts. And I saw what happened once because we had a teletype set up that carriage-return, did a carriage-return line-feed. And, you had to put a null character after the carriage-return or it tried to print a character on the fly going back, actually doing the carriage return you get a blob right in the middle of the page.
One of the scripts you'd done was a regular expression grapher. And, that was just insane how much work it seemed like that took. How long did it take you to write?
I don't know how long it took me write because it was written somewhat piecemeal. I would use redebug to get some raw data for the regular expression grapher and then just graph those nodes. And, although it looks very very complex, the guts of it are fairly simple. It's just that each different type of regular expression has to have different subroutine for graphing it and it just sort of grew over time.
The only thing I remember about that was is that drawing arcs is a real pain in the ass and I've got them wrong about eight different ways before I finally got them right. And this actually goes back to the regular expression commenting you were talking about earlier because if you look through that, one of the things you see is for each one of those nodes where I've got like three or four arcs that are pointing to a regular expression, I've actually tried to draw it in ASCII above the subroutine itself so I could understand what I was doing. And, yeah, drawing, drawing arcs in ASCII is a real fun thing but, I did the best I could.
Impressed me. I was shocked to see that in the book.
And, there at the end of the book there was also, there was a page dedicated to the Electronic Frontier Foundation. Was that your doing or is that the publisher?
I believe that was my doing because I'm a strong believer in what they stand for. And, especially considering some of the silliness that goes on here right now with the criminalizing of what used to be 'fair use'. And, I think that, you know, it gets to the point now where, on this podcast I can tell you that you can encode letters by writing down the alphabet A through Z and shifting the letters thirteen spaces to the right and writing them down. Now that will create an encoding system. I can't tell you how to decrypt that thing, because if I did tell you how to decrypt that thing, I could be subject to five years in jail and have to pay a half-million dollar fine. Because that encryption, even as stupid as it is, actually does protect some copyrighted works. And, it's against federal law to tell me that. Now, any seven year old can figure it out, but you can tell anybody that because it's criminalized. And it just gets, some of the stuff our government does, it's just insane.
So, every once in a while, somebody has to ask the question of the government, you know, "What do you think your doing and how crazy is it?". And, EFF is doing that. Especially in the area that I'm interested in, which is the technology.
Thank you for putting that in the book. I think you've already covered the other question about the book's more about getting the job done than theory. That's definitely a fair statement for this, I believe?
Yeah, I mean, I consider myself not at the bleeding edge and not figuring out all of the little obscure things. I just want to beat down the language and get something done. And, the other books that I've done have the word 'practical' in their name, which is, is pretty much how I'm at. It's just get the job done, get it done as simple as possible and as clear as possible and make it work. I mean I work for a living. I have to deal with this stuff on a day-to-day basis. So, you do the best you can.
I didn't cover that. I know you've mentioned one so far, and that was "Perl for C Programmers". What other titles have you done?
"Perl for C Programmers" is the big one for the Perl users. And, in a lot of cases my books are competing with several books of the same level. "Perl for C Programmers", I consider one of my strongest books because it really takes Perl and approaches it a way I haven't seen other books do. Other books seem to be Perl for Perl programmers, which to me is a little bit hard to learn Perl unless you already know it. Where as mine starts out with an entirely different thing.
The others that I've done in the C and C++ area have been "Practical C Programming", "Practical C++ Programming". One of the latest from No Starch is "How Not to Program in C++", which is one hundred and one broken programs and a couple of working ones. And that one is rather fun because I manage to break "Hello World" in a couple of ways. Well, those pretty much are the main ones. I've got a number out there that are not in print any more which I don't even remember. And, I don't know.
That's all the questions I have about "Wicked Cool Perl Scripts" and is there anything else that you'd like to leave us with?
That's about it. The scripts are downloadable, and the are downloadable from either the No Starch website or my website, which is www.oualline.com.
Thanks once again to Steve for allowing me to interview him and thank you for listening to Perlcast. Don't forget to enter the drawing for a promotional copy of "Wicked Cool Perl Scripts", just send an email to perlcast+wicked at gmail.com by May 1st 2006.
The GarageBand.com artist that is featured in this podcast is A Thousand Cures with the track Motions.
Tuesday, April 11, 2006
Perlcast is back with an interview with Bob Walsh, the owner of Safari Software, moderator of the Joel on Software: The Business of Software website, and author of "Micro ISV: From Vision to Reality".
Once again, Apress will be giving away promotional copies of the book featured in a Perlcast
interview. To be entered in the drawing for one of five copies of "Micro ISV", just send an
email to perlcast+isv [at] gmail.com. Get you're email to me by April 24th 2006 to be entered in the drawing.
- Interview Audio
- Micro ISV: From Vision to Reality
- Safari Software
- Joel on Software: Business of Software
Welcome to another Perlcast interview. This is your host, Josh McAdams, here with an interview
with Bob Walsh. Bob, the owner of Safari Software and a moderator at the popular Joel on Software:
Business of Software website, recently authored "Micro ISV: From Vision to Reality", published by Apress.
The book covers information that enterpenural programmers need to successfuly establish their
own software business.
Once again, Apress will be giving away promotional copies of the book featured in a Perlcast
interview. To be entered in the drawing for one of five copies fo "Micro ISV", just send an
email to firstname.lastname@example.org. That's perlcast, the plus sign, ISV, the at sign, gmail dot
com. Get you're email to me by April 24th 2006 to be entered in the drawing.
A transcription of this interview can be found on the Perlcast.com website if you would like to have
it to follow along or later reference something that was said.
So, let's get to it. Here is the interview.
I'm speaking with Bob Walsh today on Perlcast and Bob is the author of "Micro ISV: From Vision to Reality". Welcome Perlcast Bob.
Well, first off, what is a Micro ISV?
It's a self-funded, one to five persons startup software company. They may be selling a product for the desktop or they may be selling a product for the web. But, the real key there is first off, they're self funded and secondly, they live and die on the internet.
That's where the find their market. That's were people learn about them. That's how they distribute whatever it is that they're making and selling.
It started out as a term coined by Microsoft: Independent Software Vendor. Basically independent of everyone, of them, of Microsoft. And Eric Sink, a few years ago, coined the term Micro ISV to talk about one person startups. But when I think of micro ISV I really think of it as micro internet software vendor, because without the internet the whole economic model of a micro ISV just would not work.
And when you say internet software vendor though, you're not necessarily meaning an internet based software, but more internet as a distribution method than a platform. It could be also the platform, but not necessarily.
It could be and not necessarily, that's true, but most of the time what we're talking about here is the way the software gets from yea to they is via the internet. We're not talking retail distribution here, which makes a whole big difference when it comes to trying to start a software company.
Pretty much all the micro ISVs out there distribute their product primarily via the internet via the internet and people find them via the Internet versus retail operations.
You come from Safari Software and you wrote a book about micro ISVs, so I'm guessing that Safari Software is a micro ISV. This that how you find yourself qualified to write this book?
What happened here is, I started Safari Software about ten years ago. And, I was basically an IT contractor. I had written a lot of software for various Bay-area and other companies. And a couple of years ago we had the dot-com bubble and the dot-com bust and outsourcing and off-shoring. And I found myself working twice as hard for half as much as an independent contractor. So, I decided it was time to write some software commercially for the first time in basically about twenty-plus years of doing IT. And I wrote a program called Master List Professional, which I sell at my website. It's a task-management program.
And I got though writing that and I realized I just knew nothing about marketing this commercial application and all of the things that I really needed to do right for that. Now, before I was in IT I was a reporter. And reporters get assigned to all sorts of things that they have no idea what it is. What they're good and and what I'm pretty good at is going out and finding out the information and reporting it back accurately.
So, this was a book I wrote because I really needed this book to start doing what I wanted to do in life. ANd there simply wasn't any one good book out there that had this information and I was fortunate enough to be able to get the time of a whole lot of different people, both micro ISVs and vendors and people at Microsoft and people not at Microsoft to get good information for this book. So I treated it more like a story that I was going out to go get rather than saying well, I've done fourteen micro ISVs and these are my lessons that I've learned and hopefully they'll be something for you.
The book seems to indicate that open source is not necessarily the best way to go about developing a micro ISV. So how do you feel about an ISV developing open source components and then trying to sell the service? It sounds, definitely from that last answer, like that's probably the backwards way to go.
There's open source in two different ways. This is still an uncomfortable position for a lot of people right now. But, if your going to start a project, and open source project, and make money with that by selling the services around that project, you're going to have a pretty tough row to hoe.
There are few people out there who have done that successfully. Maybe the best example I can think of is the BBPHP people. But, selling open source services hasn't really made a lot of money for a lot of people.
Now, that said, there are more and more people and more and more programmers who look at open source and say "Hey, that's great. I'll use it if the license says I can, wonderful". And open source is having more and more effect on software development as a whole. The problem is when you're a micro ISV you're a one person business and if you're not making revenue, you're not gonna be in business to long. And it's pretty hard to convince people to pay for something that they think is free. It's not free it takes a lot of effort and a lot of creativity and a lot of work on the part of a lot of people for open source to work. But, it just comes down to the idea of you're making a commercial product. There's nothing wrong with the idea of charging for that. You can deliver that software at a lower cost and charge people less than you would if you went the traditional retail route. And that seems to work pretty well for a lot of people today who have started their own micro ISVs.
Whenever developing your software, and you had mentioned marketing so we'll add that into the mix, but, a pretty interface or a more functional application or just an application that you can convince people to buy, which is the most important aspect?
A long time ago I learned that at least the first impression that most people have of software comes from what it looks like. It can be the worlds most robust functionality, but if doesn't look good, you've got one foot in the grave at that point and then everything else is a long slide, or a long climb up trying to convince people that the software is good.
Now, just because your UI looks good doesn't mean that your application is good, but people go by what things look like, at least initially. So I think that really one of the things that you have to do, and this is tough for people who are, you know, hard-core programmers and don't do anything graphically oriented. They don't do graphics per-say. They have to make their application look attractive and that's one of the definite challenges that a micro ISV has.
From that it sounds like you'd say, go as far as paying somebody with artistic flair to actually take a look at your application and make it better.
That would not be a bad idea what-so-ever. The other things that I talk about in the book is that there are open source sources for some really good artwork out there. And, there are also lots of independent graphic artists who do things like icons and screen design and the rest of it. And that is money well spent. I've got a couple of interviews in there, for instance there's one with a guy who runs a small company out of Perth, Australia, which is basically about 4000 miles away from everything else in the world. And, his icons are in Feed Daemon. They're in my application. They're in dozens and dozens of applications.
You know those sort of graphic touches are easy to sort-of ignore when you're thinking about classes and code. But, you have to think about [them] because people go by that impression and a good icon is a good thing to have.
A lot of the software and services that you did mention in the book are closed source or they at least, they cost money. So, we'll think in just the free or not free in the sense of money. And, this is especially true for the SCM systems that are mentioned. So, why not have somebody use CVS or Subversion, which are both open and free, but with the optional commercial support. It seems like a micro ISV would really want to save money where it's possible.
You do, but there's always a trade-off between doing it yourself and getting a product that does the job that you can get help for. Both Perforce and Source Gear let one/two-user licenses for free. Now, their support policies differ but their forums are excellent. And, there's nothing wrong or bad with subversion, but every moment you spend not writing code that ends up improving or in the product is what we used to call overhead, in the business world. It's nice and fine but it just eats away at your bottom line.
So, if you know Subversion and you really feel comfortable with it, by all means. If you don't. If you've never had to deal with source control before, simple is better and the least amount of effort is better and if you find that subversion is just not working for you as an approach, then p4 makes a lot of sense, as does Source Gear's Vault.
There were quite a few very useful things in the book and one of them that I found really useful and a good idea was your code checklist. Would you mind explaining what that is.
You know, most people do things, they do a thing for money, okay. Like, I write code and I write words. Most programmers write code. And, everyone has the need to improve their processes. The idea of a code checklist is there are certain things I will do every time I sit down and code a class. There are some things that I wish I didn't do and those are the things the checklist is there to catch. Just in the same way that when you write something, it's not a bad idea to have a checklist to go over and make sure your writing is good. For instance, let's say you take a blog. If you, every time you post, you've got at least three or four items on your checklist and you just follow those. You will avoid the things that later show up that you wish you hadn't done like misspellings, for instance. And the same way with code, you just make the process that much smoother. Now what those things should be on your code checklist. Each programmer is going to have a different take on that. But I that as just a general rule, the more you improve you're process of what you do that you add value, the more value you produce with less effort, which is a good thing.
Well, until reading the book, I didn't realize how difficult is was to get money from people. How can a micro ISV protect themselves from Internet fraud.
The reality there is, everything is credit card based and you have to decide whether you want to get into the business of doing credit card fraud detection and credit card verification or not. What I've heard from enough people to take it as a good working thumb is if you expect to be doing more than 10,000 dollars worth of sales consistently, it might be worthwhile to go the merchant account than through an authorize.net or, say, Wells Fargo, and to go the more traditional way of doing things.
But, you know, for most Micro ISVs, there first month of sales is not gonna look like $10,000. So, my recommendation there is, you go with a company that already does it. They take a bite out of what you make, but you don't have to worry about those type of problems.
I recommend right now two different companies. Pay-pal, it's owned by Ebay. And a company called 2co or 2checkout.com. 2checkout.com's a little more expensive. They take a little higher discount, as it's called. But there's some advantages to them. Mainly, there are some people out there that just don't want to deal with Pay-Pal. So I use both and I've found them to both be, well, you know, just excellent ways of getting the money. And other people have reported back the same thing. That they both work well. While 2co you actually move the user over to the 2co site to complete the transaction, with Pay-Pal now, you can just pass the transaction to Pay-Pal directly. They [the customer] never have to leave your site.
And, I just don't think as one of the first things a micro ISV should worry about is merchant account and payment processing, per say. Merchant account fees can just eat up your profit pretty quick.
If down the road your making 10,000 a month in sales every month, then it's a good time to turn around and take a look at it again.
You mention that LLC seems to be the way to go when formalizing a micro ISV. Why is this?
It's a question of ease of use vs. liability. Now you can write a piece of software and start selling it on the internet and be fine maybe, let's say, 90% of the time. But for 10% of the time, someone out there is going to say your software caused them a brain tumor, their hair to fall out, their dog to leave, there wife to stay, whatever, and they are going to sue you. We live in a society where people sue other people a lot. You don't want that to happen to you. You want that to happen to a business entity. And this is why people set up business entities like corporation and LLCs. They set it up to limit their liability. To set up... they want some protection from the slings and arrows of outrageous lawyers and they want to separate what is theirs from what is their company. It's a little schizophrenic, I admit. And I've been a corporation, Safari Software Inc., which is a Sub-chapter S Corporation, for ten years. But, in that ten years, the landscape has changed. And now we have LLCs, where you get protection, but it, the paperwork, is a lot less than for a full-blown corporation in the United States. So I think now-days an LLC makes a lot more sense in most states. You, this is one of those things where we're talking state law rather than federal, in the United States and it varies from state-to-state. But don't worry, if you're in California the franchise tax board will get it's 800 dollars minimum from you in either case.
One thing that would, or an interesting interview that you could have had in the book, would have been somebody who did not incorporate or did not LLC and got screwed for it.
It would have, I don't know too many people like that fortunately. The thing about being a micro ISV is you're really a full-scale real business and because the internet makes it possible to reach out and sell what you're doing to people all over the world, that you don't even know, but they find you in a couple of clicks, you have to act like a business. So, you should have your own business accounts. You know, you should definitely, definitely, do that. And you need to track all that and you need to do taxes and you need to do the legal entity, but it, you, it's not that bad. It really isn't that hard to do and bottom-line here is, you can make a lot more than you can working for someone else and you are your own boss.
Well you give examples of what a good micro ISV website should do. What are some of the most common mistakes that you see micro ISVs doing to their websites?
I'd say there's three. First off, they get shy. They've been working on this great widget, code, thing, site, whatever, and suddenly they're about to put themselves out in front of the whole rest of the human population. Or at least the one-billion of them that now use the internet. And they get shy. They don't say what their features are. They don't say what the benefits are. They don't say why people should give them money. What the unique selling proposition is. A lot of them won't say what the price is. That's a big mistake. It's not a place to be shy. It's a place to be proud of what you've done. If you're not proud of what you've done, well that's a reality check and you need to talk to yourself about that. But anyway. But a lot of programmer-designed websites don't do the three things they need to do at the very-very beginning. They don't say, this is an x that does y that unlike z makes it possible for you to do one and two and three better than other a and b's. That's called a unique value proposition or a unique selling proposition, USP. That should be the first thing that somebody sees when they come to your website.
Second thing they should see is your price. You want to charge me three hundred dollars? Well, that's not gonna be as attractive as, say, thirty dollars. And, people aren't going to buy things without knowing the price. So, the second thing really ought to be the price.
I'd say the third thing is, they need to start feeling comfortable about, you as a micro ISV, as a company, you know, they need some information about you. They need some reassurance that you're not some sort of weird scam coming out of some country somewhere else and their thirty dollars, or three hundred dollars, or whatever you're charging, it isn't going to just disappear. Testimonials work well there. Screen-shots that are simple to understand and aren't too small work well there. You need to start talking to them and engage in the conversation where you're explaining both the value of what you are selling and your credibility as somebody selling it.
And these are things that don't come very easily to programmers.
Notoriously bad self marketers.
Well, that was an interesting thing about, you know, your price being three hundred or thirty dollars. It it seems like whenever you're buying from a micro ISV or a company that you've never heard of, that you never seen maybe a commercial or something, you seem to, I don't know, I would be much less inclined to give three hundred dollars than thirty dollars, even if it was a good product. Is there some magical price-point that people tend to let go of on the internet easier?
Well there are some sort-of time-honored truths, that, for instance, twenty-four ninety-five is easier to sell than twenty-five dollars. And twenty-nine ninety-five sells better than thirty. I would say, and this is by no means a rule, this is just kind-of a rule of thumb, plenty of exceptions to it, but if you're selling to consumers, if you're selling to just people in general, you're gonna have a tough time convincing them that you're software is more valuable than say, fifty bucks. Please don't hold me, now I can think of many exceptions to that. You know, some of the games I can think of right now go for more than fifty bucks. But, basically, that's kind-of where that market is.
Now, business, that turns into a different story. If people are using it for their business, you know different scales apply. I think that the key to finding the right price to sell your product is to ask your public and private beta tester what they think.
Which brings up, by the way, the important point of having public and private beta testers. One of the other things that you have to do right to get your software selling, is, besides all of the things that you do to end up with a good product, you've gotta start listening to other people. This is called the market. This is called listening to the market. And the best way to do that is before you start selling your product, you have a public beta where people can download it or use it and try and give you feedback. That feedback isn't, okay, there's a code break over here and we need to fix that. It's, this is a wonderful feature but I wish it could do this because in my line of work we it that way. It's that type of feedback. It's how well you're addressing the problems that people are having out there with your product. That's what comes out in a public beta. And a public beta is just a great way to build a platform for your software or for your website.
As a micro ISV owner you have to provide technical support. As a consumer you've bound to encounter really bad support. So how to micro ISVs handle and mishandle support?
Mishandle it by not doing it. Good tech support is the micro ISV secret weapon of choice. Because, in a world where we all get screwed by big companies, you would be amazed at how people react when they actually hear from the person who wrote the software and they say, "Yeah, that's a bug. Thank you for pointing it out. Be fixed in the next version. Thanks again". People jump up and down when they get that. I do. You probably do too. It is that personal touch that makes a huge difference.
Now, micro ISVs need to honest with themselves and with the market as to how big they are. They are a one or two or three or four or five person operations. They're not GE or Microsoft or Adobe or any of the big companies. But, by reaching out with good tech support, and that basically starts with the process that you use to make sure that you capture every single tech-support incident and address it and know that you've addressed it. Micro ISVs have a real good strong positive connection with their customers. One of the misapprehensions that a lot of programmers who are becoming Micro ISVs have, is that if someone finds a bug in my software, they're gonna hate me. It's gonna be really weird to talk, to deal with as an email or, god forbid, on the phone. And, I just don't want to do that. It's gonna be painful. You know, the reality is, is that everybody understands that software has bugs. What's really matters is that, what are you going to do about those bugs? Are you going to send somebody off into some forum system or, god forbid, a knowledge base, where they'll spend the rest of their life looking from place-to-place trying to figure out what the hell went wrong. Or, are you going to say, "Okay. That's a bug. Thank you for helping me reproduce it. Now I know what to do and we'll deal with it".
Good tech support is a sale-maker, not a sale breaker.
Never battle a customer and yet never tolerate abusive people. So how can you initiate the refund with a hostile customer.
I have a simple rule, if somebody wants their sale back, boom, they've got it. And after they've got it, I'll talk to them, if they want me to. But, you know, in all the sales that I've done, every time someone has said to me, "Oh I hate this software now. I want my money back', and I've said "Okay, great", and boom. They've turned around and usually within the same day, before I can complete the transaction on my side, they say, "Well, no, you're talking to me and I've changed my mind". That's happened in two cases and I think that, you know, it's part of business. Business has returns. You take back the pants. You don't fit in them any more or what have you. And, that's kind of the way business is. Everyone expects to see some of that. The good thing about Pay-Pal or 2co.com is, they make sure that you're not getting ripped-off in the process. Because, there are, like I said before, a lot of credit card fraud things out there and as a really micro-business person, you just don't have the time to get involved in that. You don't want to go there.
On getting you're business noticed you talk about Ad-words, and this is pay-per-click model which can add up expenses fast. And so, for a Micro ISV without a lot of extra money, would you consider something like affiliate marketing to be useful? Sort of like a pay-per-performance or pay-per-sell model instead.
Well, the problem with affiliate networks is they've gotten something of a bad reputation. I would actually step back and say that the problem with affiliate networks is that it's, it has two problems. First off, it's more of a form of advertising than anything else. And, you know, I don't know about you, I hate ads. I really hate, hate, hate ads. They're intrusive, they don't talk to me about what I want. They're in the way. They're just, just drains on me. And a lot of people feel the same way about advertising, at least traditional advertising.
The reason that Google Ad-words works so well is, you go looking for something like a new sit-down mower so you can mow your lawn and you find all this information and over on the side, you've got some ads that are about, well, sit-down mowers. At that moment, when you have decided that you want some information about x, you've got some people raising their hand saying, "Hey. We sell X. Come click on us and see what we've got".
Now, it's true, if you're not careful and you just throw money at Google Ad-words, well, they'll be happy to spend it for you. But, they'll also be happy to intercede into your ad program and give you some really good advertising advice. In fact, they will go so far as to say, "Okay, you pay us three hundred dollars. We will assign a professional to you who will work with you to build a good solid, call it a B-plus, advertising program". They will aline the good terms for you to be clicking on. They will show you how to exclude things you should be excluding. They will help you write the ads and they will show you how to test ad A versus ad B. And they'll do all that for three hundred bucks. Except they'll turn right around and give you three hundred bucks worth of credit on Google Ad-words. So your cost for that expertise is zip. In fact, one of the lesser known facts is they will turn around and do that even if you already are using Google Ad-words. They will turn around, help you for free to do it. It's in their interest. It's in your interest.
Of all the types of advertising out there, I like Google Ad-words best. Now going back to affiliates. The other problem with affiliate marketing is, besides it being traditional marketing, it has gotten this reputation of being sort-of, eh, you know, I'm gonna say kind-of like, Am-way like. A lot of people selling marketing to each other. And the problem is you don't have any control over the quality of the advertising venue that you're in. You're ads may appear anywhere. And, ads of things you may not want to have anything to do with can appear on your site. And I would just say that one of the many things you shouldn't do on your micro ISVs site is have any sort of advertising for anyone else. That means no affiliate ads for other products. And, that means no Google Ad-sense that are selling things that just happen to have words on your site. That's not what your micro ISV website should be about.
Now there's nothing wrong with informally working with other companies, be they big or small. And that's actually a very good thing to be doing. But, the affiliate networks tend to promise a lot and very very seldom deliver any sort of really good result.
The end of the book contains ISV examples for all maturity levels of businesses. Which would you say is a must read?
Well, I would pick Ian Lansman's UserScape as being one that really stands out because he did an excellent job of just very much, in a very planned way, designing his software, including people in his public beta to start building a buzz about that software get feedback about what worked and didn't work. And, in a lot of ways, he is sort of the poster child for how to do it right.
Now, with that said, I'd also point out Profit Desk, because they sell to a market that most people don't think of as being one that micro ISVs can hit, and that's to banks.
The point I'm trying to make here is that there are approximately in the order of about forty to fifty things that a micro ISV has to do right. None of them are particularly hard. None of them are going to tax the mental abilities of anybody who can handle a modern programming language. If you get those things done right, you're going to find that your product fixes a problem that people want to pay you money for to solve. And, that is a good thing.
So, I would say that just about all the twenty-five people, or twenty-six people, here have a little pearls of wisdom, if you don't mind the pun, to share. And, that's why I interviewed them. Because, they're the ones out there doing it and showing how to be successful in what they do.
Beyond just the twenty-five interviews, or more, in the book, you've actually gone further and created a website, mymicroisv.com, to continue on with the learning and helping micro ISVs out. Would you mind telling us a little about that?
Sure. It's a my micro ISV dot com, all one word, and I call it a blog resource site by, for, and of micro Internet software vendors. I've been lucky to get a good number of people who are micro ISVs to post a wide number of topics besides whatever I think you should be reading. And, these topics include things like: how to do a mash-up, by somebody who's actually done a successful mash-up; what are some of the more arcane issues that you may deal with if you plan to eventually sell your micro ISV by a person who's quite successfully sold a couple. So, basically, it's a site that people who want to be micro ISVs or are micro ISVs, I hope will find some very good information on an on-going basis.
There are a considerable number of tips in the book. Is there any tip that you would consider vital to the success of a micro ISV?
I'd say the one thing that you have to do above all everything else, is you have to want to do this. It's not a class assignment. It's not something that some boss is saying that you should do. You need to really want to be a micro ISV to do it because it's gonna be a lot of work. And sometimes it's going to be hard and sometimes it's going to be a drag. And, you need to have that passion about what you're doing to be successful.
One of the reasons that I have twenty-five different interviews in there of twenty-five coming from all sorts of backgrounds and ways of doing things is to show people that they can do it to. And, that's the thing that I really want to impress upon people, is that, you know, if you can write code, if you can solve problems by writing software, you can become a successful micro ISV and not have to work for other people the rest of your life and write the type of software that really gets you excited.
Well that's all I have. Bob, I'd like to really thank you for coming on Perlcast. This was a great interview. And, I guess I'll leave the floor open. Is there anything else you'd like to mention.
Not really, other than please do stop by mymicroisv.com. Also, you might want to stop Joel on Software's Business of Software Forum. And, that is over at discuss.joelonsoftware.com/biz. The business of software, you're going to find a lot of people there who are micro ISVs or want to be micro ISVs and I moderate it, along with Eric Sink, so we keep the quality of the information high and the noise low.
I'd like to once again thank Bob Walsh for taking the time to be interviewd and also thank you for
listening to Perlcast.
Also, it's not too late to take advantage of early registration for YAPC North America. Visit
yapcchicago.org to get details on the premier Perl-focused conference in North America.
The GarageBand.com artist for this interview with Kitty Violet with track "Burn".
Thank you for listening.
Wednesday, March 29, 2006
O'Reilly is also giving away ten editions of the upcoming book "Perl Hacks" through their new Rough Cuts system. To be entered in a drawing for "Rough Cuts", just send an email to perlcast+perlhacks at yapcchicago.org.
Today is Tuesday March 28th 2006 and you're listening to another Perlcast interview. This is your host, Josh McAdams, here with an interview with Audery Tang. Audrey blasted onto the Perl scene with the Pugs project. Aside from that, she maintains over one hundred CPAN modules and is a contributor to numerous open source projects.
As an added bonus O'Reilly will be giving away ten electronic versions of Perl Hacks through their Rough Cuts program. To enter the contest, just send an email to perlcast plus perlhacks at gmail dot com. That is perlcast, the plus sign, perl hacks, the at sign, gmail dot com. Get those emails to me by April 10th for the drawing on April 11th.
And now, on to the interview.
Welcome to another Perlcast. Today on Perlcast I have Audrey Tang. Audrey is very well known for her Pugs fame here in the Perl world, but she also maintains many other modules. I think about a hundred on CPAN also. Well, welcome to Perlcast Audrey.
I guess we'll get started and I'll just ask, for those who don't know, what is Pugs?
Pugs is a project that works on everything related to Perl6 with, many sub-projects... one that parses Perl6, runs Perl6, translates Perl6 to other languages and runtimes. We also work on Perl6 examples, documentations, tests, and, well, everything else.
Currently Pugs is the only Perl6 implementation, but that may change in the future.
If somebody is really wanting to learn Perl6 then Pugs, would be the only way that they could go right now.
Yeah, I think is the case.
Whenever you say Pugs is a Perl6 implementation does it actually just parse the Perl6 language and get that into something that Parrot can run or does it go further than that?
And, besides that we have Parrot and Perl5 compilation targets that are coming along pretty well. But the most exciting thing by far is to write one more of these parts in Perl6 itself so that one day we will have a fully bootstrapped Perl6 compiler and also the implementation runtime already in Perl6 itself. And that will be the ultimate goal for the Pugs project.
So that was one thing that I was going to ask you about: bootstrapping the language. So at one time I think that Perl5 was gonna be used and then at another time C. And now, is it going to be Pugs that used, or Haskell, that's used to bootstrap the language?
So this translation process, this the sugaring process, could be written in Perl6 or Perl5 or Haskell. So think of it as a scaffolding that we've already built in Haskell and we are taking it bit-by-bit off and replace it with pure-Perl equivalents so that one day it can bootstrap itself.
You actually announced this project in February of 2005 and so a little over a year has passed. Are you pleased with the progress?
It was quite unexpected. I mean I started this as my pet project, pun intended, to learn about junctions and multi-methods, the exciting Perl6 features that were at that time quite poorly understood. And then people started submitting patches and writing IRC bots in it and, gasp, deploying it in production. And, yeah, I totally didn't foresee it happen and my life haven't been the same since then. But overall I was very impressed and amazed by our 200 contributors and nearly 10000 revisions in the first year and with Larry Wall and Damian and other people becoming committers and hanging around IRC. I think the next year is going to be even more amazing and impressive.
I noticed that was mention in the Q&A of the Pugscode website that Pugs could be used kind of as a test for ideas in the Perl6 language. So, has that actually happened and has Pugs been used to shape some of what Perl6 will be as far as syntax?
Oh yes, definitely. In #perl6 IRC Freenode, we have Larry Wall and Chip of Parrot and Rafael of Perl5 and a lot of other people who care about the language evolution of Perl5 and Perl6. So I've been experimenting with the ghost writing procedure where we experiment with some Perl6 features in Pugs and discover what works and what doesn't work or make feature suggestions. And because Larry and other design team members are on IRC, so we make a decision right there and get other people to review and then I'll commit it into the synopsis that is the Perl6 language specification. So it is done in a very iterative and very very fast fashion, this feedback loop between the implementation and the language design.
Well after Perl6 does finally arrive, what is Pugs gonna be at that state? Will it still be useful, will it still be around?
I think the Perl6 design team makes a distinction that Perl6 is a language, while in Perl5 you know that it's a pun right? Depending on one bit, whether it's written upper case, where perl5 means the language or it's lower case where Perl5 means the implementation. No matter how you write Perl6, Perl6 is just a language. So, Pugs the project produces, depending on how you count, two or three Perl6 implementations already. And there will be no doubt be other Perl6 implementations in the future. Not necessarily from the Pugs project.
But, yeah, Perl6 will become like C or C++, a language with many implementations and I think that is a very good thing to drive innovations forward.
Why in the beginning did you choose Haskell to implement Pugs?
Because I was learning Haskell?
Well seriously, I think Perl6 and Haskell have many things in common. Perl6's major features such as power parsing with rules and grammar and infinite lists and streams and complex data structure matching and pipe system. All of those things are present in Haskell, if not in the very sweet and sugary and convenient Perl6 syntax. But, they share some very similar underlying semantics.
So by starting with something already resembles Perl6 somewhat, it's far easier to get something up and running very quickly instead of starting from something that is quiet apart from Perl6, which would make things much harder.
Pugs seems like an amazingly intimidating project to get started on, but I'm sure
you need quite a bit of help, so what types of help are you needing right now?
It is really not that hard to start jumping in and hacking because one of our newest and most exciting sub projects is the Perl5 runtime, where we taking pieces of Pugs, the rules parser and emitter and compiler and turn them into CPAN modules that you can use in your existing Perl5 programs.
So for example we just uploaded Pugs::Compiler::Rule, a rules engine written in Perl6 cross-compiled to Perl5 and you can use that in your Perl5 program now. And there will be more modules like that in the future, so if you know Perl5 its really easy and exiting to start hacking Perl5 and Perl6 interoperability. So that you can mix Perl6 and Perl5 in the same programming, running in the Perl5 interpreter.
But, we also very much need English hackers because the synopsis only specifies the look and feel of the language. But, we are writing real Perl6 programs now so we're also in need of specifying the various APIs, the methods of the building objects, and things like that. So we are collecting the various overviews and tutorials and things like that and turn them into a Perl6::Doc launched on CPAN so people can access it with the normal POD tools. So if you know English and/or POD, then that would be an exciting thing to get into.
But, in Pugs we're really language agnostic because our intermediary data structures are mostly in YAML now. And YAML can be loaded and manipulated in any language. So no matter what you are interested area is, like a refactoring browser or a syntax highlighter, you can write it in your favorite language.
Audrey, I really appreciate you coming on Perlcast and telling us a little bit about Pugs. is there anything else that you'd like to tell the audience.
Hmm, let me think about it. Well I think this podcasting is a wonderful idea so I'll probably convert my public talks about Perl6 and Pugs and turn them into MP3 and flash and upload them to pugs.blogs.com. That's the Pugs development journal. So, feel free to check it out.
So, Perl6 is fun and Pugs is fun and just join us and have fun. Thank you very much Josh for the interview.
I would like to once again thank Audrey for taking the time to be interviewed and also thank O'Reilly for their continued support of Perlcast through promotional give always. On that note, remember to get your entry in by April 10th to perlcast plus perlhacks at gmail dot com.
Be sure to check back with Perlcast soon. There are interviews with Bob Walsh, the author of "Micro ISV: From Vision to Reality", as well as, Steve Oualline, the author of "Wicked Cool Perl Scripts", already recorded and awaiting post production.
Also, as some of you know, I'm helping organize Yet Another Perl Conference this year in Chicago. Well, we just opened registration for the conference, which will be held from June 26th to 28th on the campus of the Illinois Institute of Technology. Also, just after the conference we will have three open classes taught by some of Perl's premiere instructors: Learning Perl by brian d foy, Intermediate Perl by Randal Schwartz, and Perl Best Practices by Damian Conway. With the conference costing only $85 and the classes only $200 each, this is one of the best deals in conferences today. Check out http://yapcchicago.org for more information and instructions on registering.
The GarageBand.com artist for this podcast was Feldspar with "Lunatics Audio" from their "Metropolis Mixes" album.
Thanks for listening to Perlcast. This is Josh McAdams signing out until next time.
Tuesday, March 7, 2006
The GarageBand.com artist for this podcast was Ten Story Relapse with
the track "Planting Seeds".
Wednesday, March 1, 2006
In other news, Perlcast has been quite for a while. I've been in the process of swapping out jobs and machines and didn't queue up quite enough podcasts to last the gap. Hopefully I'll have a show up tomorrow. And, don't worry, I have a few more interviews scheduled to happen.
Thanks for listening!
Thursday, February 16, 2006
Friday, February 10, 2006
Thursday, February 9, 2006
The new book, focuses specifically on how system administrators can better manage what they do and what is expected of them so as to get more done, meet expectations, and reclaim the 40 (or at least 50) hour work week. Tom provides tips that can be used by anyone in the technical field, but as a long time system administrator himself, he tuned this book for the needs of our ever so helpful cohorts who keep our systems alive.
Tom also wanted me to mention that he recently started working at Google and that they are hiring... from what I hear, free soda!
Thursday, February 2, 2006
Thursday, January 26, 2006
As an added bonus, The Pragmatic Bookshelf will be giving away some promotional copies of "My Job Went To India". To enter the drawing, just send an email to perlcast-at-gmail-dot-com before February 11th 2006 letting me know that you want to be entered.