I found TPJ to be invaluable. Sure, a lot of the content could be found through Perl Monks, Perl.com, or any of the other Perl sites I have bookmarked, but that's not the point. TPJ included articles on execution, cool uses for perl, interesting perl projects, and so much more. Fine, TPJ is gone, but I still have the hard copies. Does anyone have Perl Monks mirrored? Does anyone have a backup if they disappear?
A few years ago, TPJ ran an article on Mister House, a home automation suite written in perl. It remains one of the coolest uses for perl I've ever seen. Hell, add Rosie the Robot, and it's The Jetsons ported to Linux. The code existed long before TPJ learned of it, but witht the article, I never would have known. Without TPJ, I never would have known about Home Automation.
Let's try it like this: printing and distribution are the most expensive parts of the magazine business. Eliminate them, and your costs are down to salaries, infrastructure, and profit (yes, profit). If the pdf version of TPJ turns a profit, it demonstrates that publishing in the web to a small audience can work as a business. This opens the door for other publications to do the same. And what's wrong with that?
Whaaaah! Version 1.0 of a new product doesn't have every fucking feature available on every other established competing product plus an SDK so you can write your own.
Yeah yeah yeah, no SDK, no third-party apps. Maybe, just maybe, that's because Danger entered the marketplace all of 72 hours ago. Why is there more software for the Palm? Maybe because Palm have a 6 year lead. If you'll remember, Windows 1.0 was a big pile, Linux 1.0 didn't have what you'd call a complete feature set, and Palm 1.0 wasn't all that amazing either.
Honestly, I've been salivating over the Sidekick for about 3 months. I'm still on the fence about it, but the lack of an SSH client, an SDK, and an interociter isn't going to enter into the decision process.
I met one of the developers on a plane a few months back, and spent the entire flight pestering him with questions. The word is that there will be an SDK, but they were focused on building and shipping the damn thing.
Make sense to me: 1) Build product 2) Make sure product works 3) Release product (meta: marketing types may wish to study 2 & 3, it's not a typo) 4) Build tools for other developers
Wait a few months, and there will be an SDK. The flood of shareware and third-party apps will hit around next Xmas, I'm sure.
OK, here's an idea. Since the diagnostic codes are available, how about an on-board computer that monitors and logs engine data: avg MPH, mileage, temperature, daily usage, etc. The data could be downloaded to a laptop via a USB port, analyzed, and archived.
Imagine: you're doing the monthly check, and discover that your mileage has suddenly dropped 10%. Even before something goes wrong, you could take it to a garage and give them strong diagnostic data.
When the time comes to sell the car, you can provide a day-to-day profile of the car's history: every oil change, fillup, and repair automatically logged. Real examples of winter vs summer and city vs. highway performance.
Seems to me that the technology is already available, and some of the functions are already in place. All that really needs to be done is for someone to hack together an interface. Any takers?
You got a few wrong on #4, which only serves to underline your point. Legal IDs are only required at the top of the hour. Also, you don't have to have anyone there 24/7, but since so few college stations can afford automation systems, there's someone there anyway. Also, college stations do pay ASCAP/BMI, but at a lower rate than commercial stations.
These are simple errors, but they make your point clearer: there are thousands of regulations, most of which incur a fine if broken.
What you're attempting is going to be extrordinarily difficult and amazingly expensive. If you go the comercial radio route, you'll need between $1 and 4 million to get you up and rolling. You said you're in a small college town. Is that a small town in the middle of nowhere that's serviced by one Top 40 station, a Country, and a news station? Or are you withing listening range of a larger city's stations (which still suck)? If the latter is true, the odds are that all the freqwuencies are already taken, and would cost millions to purchase.
First thing you need is a frequency. You'll have to do a formal frequency search to determine if there's space on the dial for another station. If the engineer you hire can find that there's space for, say, a 10 megawatt station operating at 93.5 FM, you've passed the first test.
Odds are, that's not going to happen. I would suggest trying to start a college or public radio station. There's frequencies reserved for these stations at the bottom of the dial: 88-91.9 FM. There may be room there.
OK, you have the frequency. Now you have to jump through all the FCC's hoops. Get a lawyer. You have to prove that you can serve the public interest, and obey all relavent laws. This is a long drawn out procedure, and one I've never personally had to go through.
Once you have all the legal stuff done, you need an engineer. Broadcast engineers are expensive, and hard to find. Think $50-100K a year, no matter where you are. Next, you'll need a transmitter and antenna. Call it $100K. Look for a used one. Another way to go is to find a small Mom and Pop station nearby that hasn't been bought out by Clear Channel and make them an offer.
Time to build studios! Don't skimp. This is where the magic happens. Get gigahertz pcs to run Sound Forge or ProTools. Invest in a good sound effects library, not "300 sound effects on a cd!" from Kmart. Your air studio is going to need a mixing board (10K or so), 2-3 broadcast quality cd players, a cassette deck (for recording shows), and an UberPC to run the whole thing.
A cheaper way to go is to use cart machines (they're kinda like 8tracks), and reel-to-reel tapes, but the price you pay is that you can't automate. That's important.
OK, you built it all. You've got a broadcast studio, an engineer to maintain it, and the tower is up and humming. Now you gotta staff it. Start with sales. You need to bring in a lot of advertising to stay afloat. It's a full time job and then some. You also need someone to do traffic: scheduling ads and billing for them.
Next is the Program Director, and I assume that's you. Brace yourself: it's an 80-hour-a-week job for almost no money. You pick the music, the promotions, hire and fire, and keep all the onair stuff rolling. Plus you'll do an airshift, that's 25 hours a week where you can't do anything else.
If you use an automation system, you can cut your airstaff severely. That sucks, but keep in mind that you have to pay your jocks (minimum wage). 168 hours a week x $5.15 an hour = 865.20 a week on salary for airtime alone. Add production duties, promotional stuff, and you'll be spending $7-8 grand a month on jocks salaries alone. and being as you're in a small town good DJs will be hard to find.
I haven't even discussed music programming, which is a whole other rant. Suffice to say that you are trying to get into a business with a low profit margin and an extremely high cost of entry. If all you want is to have cool tunes for you and your freinds to listen to, try this:
Get an mp3 player for your car with a big-ass hard drive. Run a shoutcast server and broadcast on the net. It's orders of magnitude cheaper, and you can do it all yourself.
You called it, today's Ditherati quote was indeed the line about 'Our products just aren't engineered for security'.
Furthermore, there's a footer in the Ditherati email:
"A special welcome to Slashdot readers -- thanks for subscribing to Ditherati."
You don't need to spend a lot of time learning Perl. And yes, now is a great time. You're in college. That means you have far more time to learn stuff for their own sake than you will on the job.
Buy The Perl Cookbook. It's full of scripts and code samples that will make coding Perl easier and illustrate concepts. I wish I'd bought it the first day I started coding. Life would have been much easier.
I've found that one of Perl's biggest strengths is that you can write small tools very fast. Got an mp3 collection? Perl is ideally suited for sorting and tagging files. If the task is mostly about parsing text, it's a Perl task. Maybe developers don't use Perl every day, but it will make administration and tool writing easier.
As for Perl 6, it's not going to invalidate Perl 5. You won't lose anything by learning now. And when you hit the job market, Perl will be a nice tool to have in your belt. Trust me.
Why not take it one step further? We can bring them down without a DoS attack, and make our point in a way that makes the RIAA look bad.
Instead of slashdotting their webserver, have everyone send the RIAA a mail (or 10) complaining about their actions. A few million emails in a few minutes ought to crash their mail server. When mail starts bouncing, send it again. Make your voice heard!
Then the headline will read:
"Sheer Volume of Complaints Brings Down RIAA's Email System."
No crime is committed, and the RIAA will be hard-pressed to explain it away: "Uh, well, these complaints are all bogus. It's just another harrassment technique. Sure, we got 10 million complaints a day for a month, but it's just a few hackers who registered millions of valid email addresses on thousands of different ISPs. They aren't real."
I work at a multimedia startup in Silicon Valley. If you read that sentence again, you'll realize how tight money is for us. We have 1, count 'em, 1 guy to maintain all our servers, as well as everyone's personal machines.
When I saw the story about SysAdmin Day, I forwarded it up the food chain to the Development Manager, and made the case that our Admin works like a dog, and we'd all be dead in a week without him. Furthermore, Engineering and Sales get tons of kudos every time they do their fucking jobs, but he sits quietly in his cube (and the lab, and the other lab, and all our cubes) solving our problems and making sure nothing ever crashes. And it doesn't.
Now, this is a Silly Valley startup in the midst of Stockalypse Now. We don't have the money to buy him an Xbox, a DVD player, or PDA. What we DID do, was call an all-hands Friday afternoon, to publicly thank him for all the hard work he does for us. With cake and ice cream. It's not much, but we made the effort, and hopefully, we were able to show him that he really is valued and appreciated.
I suggest a class in Real World programming. The goal would be not to teach data structures or code syntax, but how development will be done in the real world.
Week 1:
Monday: Warn the students that they will be facing real-world conditions, and to expect both trouble and chaos. A task is assigned, due next Wednesday. Wednesday: the students are informed that it's really due Monday.
Friday: they're given a new spec for the same project, and told that instead of 10% of their grade, it's worth 20%.
Week 2:
Monday: cancel class with no notice.
Wednesday: Collect the assignments and discuss what happened. Assign a new project due Monday. Tell the students to prepare questions about the project to discuss in a round-table fashion on Friday.
Friday: Lecture about industry trends. Answer no questions.
Week 3:
Monday: Collect the assignments as promised.
Wednesday: Divide the class into groups of four people and assign a project. Demand a project plan on Friday.
Friday: Shuffle the teams. The assignment is still due Monday.
Week 4:
Monday: Collect the assignments.
Wednesday: New project assignment due Friday.
Friday: Collect the assignments.
Week 5:
Monday: New assignment, due Wednesday.
Wednesday: Collect the assignments. Then tell the students the project is cancelled.
Friday: Tell the students that the previous assignment was pass/fail, just so they don't lose hope.
Week 6:
Monday: Discuss the first half of the term
Wednesday: New assignment, to be done on a specific server,and due Friday. Arrange for an administrator to take the server offline at random intervals. It will only come up to stay at 6 pm Thursday.
You get the idea. Don't make the actual projects too demanding, just make the circumstances surrounding the assignments chaotic and difficult. I see this as a class that students dread, one big bag of stress. All through the rest of their college career, they'll remember it with a shudder. After a year on the job, they'll see it as a preview of things to come.
Have your students write a program that will give the alphabetical of a phone number. It's not a monsterously difficult task, but the students will want to complete it because it's useful.
I found TPJ to be invaluable. Sure, a lot of the content could be found through Perl Monks, Perl.com, or any of the other Perl sites I have bookmarked, but that's not the point. TPJ included articles on execution, cool uses for perl, interesting perl projects, and so much more. Fine, TPJ is gone, but I still have the hard copies. Does anyone have Perl Monks mirrored? Does anyone have a backup if they disappear?
A few years ago, TPJ ran an article on Mister House, a home automation suite written in perl. It remains one of the coolest uses for perl I've ever seen. Hell, add Rosie the Robot, and it's The Jetsons ported to Linux. The code existed long before TPJ learned of it, but witht the article, I never would have known. Without TPJ, I never would have known about Home Automation.
Let's try it like this: printing and distribution are the most expensive parts of the magazine business. Eliminate them, and your costs are down to salaries, infrastructure, and profit (yes, profit). If the pdf version of TPJ turns a profit, it demonstrates that publishing in the web to a small audience can work as a business. This opens the door for other publications to do the same. And what's wrong with that?
Yeah yeah yeah, no SDK, no third-party apps. Maybe, just maybe, that's because Danger entered the marketplace all of 72 hours ago. Why is there more software for the Palm? Maybe because Palm have a 6 year lead. If you'll remember, Windows 1.0 was a big pile, Linux 1.0 didn't have what you'd call a complete feature set, and Palm 1.0 wasn't all that amazing either.
Honestly, I've been salivating over the Sidekick for about 3 months. I'm still on the fence about it, but the lack of an SSH client, an SDK, and an interociter isn't going to enter into the decision process.
I met one of the developers on a plane a few months back, and spent the entire flight pestering him with questions. The word is that there will be an SDK, but they were focused on building and shipping the damn thing.
Make sense to me:
1) Build product
2) Make sure product works
3) Release product
(meta: marketing types may wish to study 2 & 3, it's not a typo)
4) Build tools for other developers
Wait a few months, and there will be an SDK. The flood of shareware and third-party apps will hit around next Xmas, I'm sure.
Imagine: you're doing the monthly check, and discover that your mileage has suddenly dropped 10%. Even before something goes wrong, you could take it to a garage and give them strong diagnostic data.
When the time comes to sell the car, you can provide a day-to-day profile of the car's history: every oil change, fillup, and repair automatically logged. Real examples of winter vs summer and city vs. highway performance.
Seems to me that the technology is already available, and some of the functions are already in place. All that really needs to be done is for someone to hack together an interface. Any takers?
These are simple errors, but they make your point clearer: there are thousands of regulations, most of which incur a fine if broken.
What you're attempting is going to be extrordinarily difficult and amazingly expensive. If you go the comercial radio route, you'll need between $1 and 4 million to get you up and rolling. You said you're in a small college town. Is that a small town in the middle of nowhere that's serviced by one Top 40 station, a Country, and a news station? Or are you withing listening range of a larger city's stations (which still suck)? If the latter is true, the odds are that all the freqwuencies are already taken, and would cost millions to purchase.
First thing you need is a frequency. You'll have to do a formal frequency search to determine if there's space on the dial for another station. If the engineer you hire can find that there's space for, say, a 10 megawatt station operating at 93.5 FM, you've passed the first test.
Odds are, that's not going to happen. I would suggest trying to start a college or public radio station. There's frequencies reserved for these stations at the bottom of the dial: 88-91.9 FM. There may be room there.
OK, you have the frequency. Now you have to jump through all the FCC's hoops. Get a lawyer. You have to prove that you can serve the public interest, and obey all relavent laws. This is a long drawn out procedure, and one I've never personally had to go through.
Once you have all the legal stuff done, you need an engineer. Broadcast engineers are expensive, and hard to find. Think $50-100K a year, no matter where you are. Next, you'll need a transmitter and antenna. Call it $100K. Look for a used one. Another way to go is to find a small Mom and Pop station nearby that hasn't been bought out by Clear Channel and make them an offer.
Time to build studios! Don't skimp. This is where the magic happens. Get gigahertz pcs to run Sound Forge or ProTools. Invest in a good sound effects library, not "300 sound effects on a cd!" from Kmart. Your air studio is going to need a mixing board (10K or so), 2-3 broadcast quality cd players, a cassette deck (for recording shows), and an UberPC to run the whole thing.
A cheaper way to go is to use cart machines (they're kinda like 8tracks), and reel-to-reel tapes, but the price you pay is that you can't automate. That's important.
OK, you built it all. You've got a broadcast studio, an engineer to maintain it, and the tower is up and humming. Now you gotta staff it. Start with sales. You need to bring in a lot of advertising to stay afloat. It's a full time job and then some. You also need someone to do traffic: scheduling ads and billing for them.
Next is the Program Director, and I assume that's you. Brace yourself: it's an 80-hour-a-week job for almost no money. You pick the music, the promotions, hire and fire, and keep all the onair stuff rolling. Plus you'll do an airshift, that's 25 hours a week where you can't do anything else.
If you use an automation system, you can cut your airstaff severely. That sucks, but keep in mind that you have to pay your jocks (minimum wage). 168 hours a week x $5.15 an hour = 865.20 a week on salary for airtime alone. Add production duties, promotional stuff, and you'll be spending $7-8 grand a month on jocks salaries alone. and being as you're in a small town good DJs will be hard to find.
I haven't even discussed music programming, which is a whole other rant. Suffice to say that you are trying to get into a business with a low profit margin and an extremely high cost of entry. If all you want is to have cool tunes for you and your freinds to listen to, try this:
Get an mp3 player for your car with a big-ass hard drive. Run a shoutcast server and broadcast on the net. It's orders of magnitude cheaper, and you can do it all yourself.
You called it, today's Ditherati quote was indeed the line about 'Our products just aren't engineered for security'. Furthermore, there's a footer in the Ditherati email: "A special welcome to Slashdot readers -- thanks for subscribing to Ditherati."
You don't need to spend a lot of time learning Perl. And yes, now is a great time. You're in college. That means you have far more time to learn stuff for their own sake than you will on the job.
Buy The Perl Cookbook. It's full of scripts and code samples that will make coding Perl easier and illustrate concepts. I wish I'd bought it the first day I started coding. Life would have been much easier.
I've found that one of Perl's biggest strengths is that you can write small tools very fast. Got an mp3 collection? Perl is ideally suited for sorting and tagging files. If the task is mostly about parsing text, it's a Perl task. Maybe developers don't use Perl every day, but it will make administration and tool writing easier.
As for Perl 6, it's not going to invalidate Perl 5. You won't lose anything by learning now. And when you hit the job market, Perl will be a nice tool to have in your belt. Trust me.
Why not take it one step further? We can bring them down without a DoS attack, and make our point in a way that makes the RIAA look bad.
Instead of slashdotting their webserver, have everyone send the RIAA a mail (or 10) complaining about their actions. A few million emails in a few minutes ought to crash their mail server. When mail starts bouncing, send it again. Make your voice heard!
Then the headline will read:
"Sheer Volume of Complaints Brings Down RIAA's Email System."
No crime is committed, and the RIAA will be hard-pressed to explain it away: "Uh, well, these complaints are all bogus. It's just another harrassment technique. Sure, we got 10 million complaints a day for a month, but it's just a few hackers who registered millions of valid email addresses on thousands of different ISPs. They aren't real."
When I saw the story about SysAdmin Day, I forwarded it up the food chain to the Development Manager, and made the case that our Admin works like a dog, and we'd all be dead in a week without him. Furthermore, Engineering and Sales get tons of kudos every time they do their fucking jobs, but he sits quietly in his cube (and the lab, and the other lab, and all our cubes) solving our problems and making sure nothing ever crashes. And it doesn't.
Now, this is a Silly Valley startup in the midst of Stockalypse Now. We don't have the money to buy him an Xbox, a DVD player, or PDA. What we DID do, was call an all-hands Friday afternoon, to publicly thank him for all the hard work he does for us. With cake and ice cream. It's not much, but we made the effort, and hopefully, we were able to show him that he really is valued and appreciated.
I suggest a class in Real World programming. The goal would be not to teach data structures or code syntax, but how development will be done in the real world.
Week 1:
Monday: Warn the students that they will be facing real-world conditions, and to expect both trouble and chaos. A task is assigned, due next Wednesday.
Wednesday: the students are informed that it's really due Monday.
Friday: they're given a new spec for the same project, and told that instead of 10% of their grade, it's worth 20%.
Week 2:
Monday: cancel class with no notice.
Wednesday: Collect the assignments and discuss what happened. Assign a new project due Monday. Tell the students to prepare questions about the project to discuss in a round-table fashion on Friday.
Friday: Lecture about industry trends. Answer no questions.
Week 3:
Monday: Collect the assignments as promised.
Wednesday: Divide the class into groups of four people and assign a project. Demand a project plan on Friday.
Friday: Shuffle the teams. The assignment is still due Monday.
Week 4:
Monday: Collect the assignments.
Wednesday: New project assignment due Friday.
Friday: Collect the assignments.
Week 5:
Monday: New assignment, due Wednesday.
Wednesday: Collect the assignments. Then tell the students the project is cancelled.
Friday: Tell the students that the previous assignment was pass/fail, just so they don't lose hope.
Week 6: Monday: Discuss the first half of the term
Wednesday: New assignment, to be done on a specific server,and due Friday. Arrange for an administrator to take the server offline at random intervals. It will only come up to stay at 6 pm Thursday.
You get the idea. Don't make the actual projects too demanding, just make the circumstances surrounding the assignments chaotic and difficult. I see this as a class that students dread, one big bag of stress. All through the rest of their college career, they'll remember it with a shudder. After a year on the job, they'll see it as a preview of things to come.
Have your students write a program that will give the alphabetical of a phone number. It's not a monsterously difficult task, but the students will want to complete it because it's useful.