Well, encrypted telepathy might be a bit beyond our tech level this decade, but you do raise an interesting point. If our current email system is essentially useless, we may finally be at the point where we can scrap it and create a replacement that isn't fundamentally vulnerable to spamming. Many of the anti-spam retrofits like SPF are limited by having to retain backwards compatibility. If we're giving that up, we could probably come up with something that works better and is easier to implement
Interesting question: if we don't voluntarily scrap the existing email infrastructure, how long until spam makes it effectively 100% broken anyway?
Years ago I took a great class on technical writing. While the instructor didn't realize it because she wasn't an engineer, the process she described for writing technical documents was nearly identical to the process I used for writing software. This process isn't the best for creative writing, but for more informational type writing it helps a lot.
The usual steps for writing software include get requirements, design, prototype, implementation, testing, alpha release, beta release, etc. There are steps for writing that parallel those: define goal, research (if needed), outline, draft, copy edit, review, proofread, revise, etc. I found that once I understood the process for writing a document, actually writing the content was much easier.
And this essay by Bertrand Russell is a must read: How I Write (especially the next-to-last paragraph).
seems like Linden Labs are the only people unable to make money off of their own creation
Nope. Most people in Second Life don't make any money off of it. There are very few who make significant money there, and a mere smattering who can quit their day job to live off their virtual job. Linden Lab keeps changing the rules in SL to favor the businessfolks who are trying to make money in virtual businesses, but it's slow to build up an economy from scratch. And then there's the problem that when they shift things in favor of the businessfolk, it usually makes the game less attractive to people who aren't there to make money.
Flash memory cells will indeed wear out after some number of writes. This number is typically pretty high, on the order of a million writes. For most file operations that will probably be a higher MTBF than a magnetic disk with moving parts. Any significant problem would be with hot spots, like VM backing store and file system tables. However you can level wear by using cells in a something like a round-robin fashion. Remember that contiguity isn't an issue with flash because there is no seek time waiting for the head to move. There will probably be some challenges in balancing wear leveling against optimizing file system and VM performance, but in the long run flash drives will likely be much faster and more reliable than magnetic disks.
If you don't like it, don't use it. Like every other tool/framework/system ever developed, Rails will work for some and not for others. I've found Rails to be extremely productive and maintainable, but I'm an OOP die-hard and the approach is easy for me to grok.
One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort. The other thing I like is that it provides a clean separation between data storage and business logic. Database programmers seem to hate that approach because it shifts the center of gravity away from the database and toward the web app. This is great for maintainability of application code, but I don't know how well it works for sharing data among multiple apps. I don't know if anyone has gotten ActiveRecord models to support the same level of integration as you can get with multiple apps running off of one database - I think there needs to be more work done to enable that, but I expect to see that work done fairly soon.
The other cool thing about ActiveRecord is the use of metaprogramming, as discussed in the FA. I don't think we'll ever see a Java persistence layer that is as functional and easy to use as ActiveRecord, because the kind of metaprogramming tricks that Ruby enables are so much harder to do in Java.
The AWDR book from Pragmatic includes material on creating an admin interface to the Depot application. I've found that to be a useful starting point for my own efforts. Chad Fowler's upcoming Rails Recipes book also has information on authentication. There are also a good number of auth plugins to be found on the wiki (wiki.rubyonrails.org), though I've found that it's simple enough to roll your own.
Once you've worked out your authentication, it's pretty easy to use scaffolding to create the basics of your admin interface. I will create scaffolds for all my tables in an admin/ module, and include authorization for all access to those scaffold controlers. That's about as much as I want from a standard admin interface - anything more than that will be constraining my app by the assumptions it makes about how it runs.
If you are looking for automation to help control your app in production, check out Switchtower. It is an excellent tool for remotely managing your app's deployment and operation in production.
While lots of hosts offer RoR hosting now (Dreamhost, TextDrive, PlanetArgon, etc.), this article is about developing using RoR, not deploying. Many RoR developers use Macs for their development work, and many of them have converted from using Windows because they've seen how much better the development tools are on the Mac. This article does a great job at showing how to get started doing that development.
My intended headline was "Apple Rewards Top WebKit Contributors with MacBooks". But that was over the 50 character limit for headlines, so I had to tweak my word choice to fit within the limit. It's ugly, I'm embarrassed, but I chose that option over leaving out the word "Top" because I felt it was more important to distinguish that not all contributors were rewarded. I blame the editors!
Agile Web Development with Ruby on Rails
on
Beyond Java
·
· Score: 1
This is the only extant book on Ruby on Rails: Agile Web Development with Ruby on Rails. There are about a half dozen others that will be available later this year, but the Agile book is quite good and sufficent to get you started.
This isn't a new idea, that HIV isn't the cause of AIDS. You get these kind of weird ideas when laymen try to apply "common sense" in place of domain knowledge. HIV is a retrovirus that attacks the immune system, so it has unusual characteristics and effects compared to most other viruses.
A common argument goes that when a person is most sick with AIDS they have a low HIV load, which "doesn't make sense", since in all other viral infections the viral load is high when the infection is acute. However, since HIV destroys the immune cells in which it grows, you can actually see a low viral load as the infection progresses because it has no place left to grow. But by then the immune system is no longer effective at fighting off other infections and the infected person gets very sick.
As for the procedures that were followed, I think researchers have done a very good job at studying HIV and its transmission. However no ethical researcher would intentionally infect a human with a fatal disease, and HIV is specific to humans. SIV (a related virus that infects simians) has also been studied and it's pretty well accepted by now that SIV causes an AIDS-like condition in monkeys, and that HIV is actually the agent that causes AIDS in humans.
In the past I've found the Daleks to be a bit of a joke. But this time round they finally seem like the threat they've always been made out to be. They may look silly, but they are kick-ass, genocidal death machines. Russel T. Davies takes on all the Dalek stereotypes and turns them inside out. At long last, the Daleks are as scary as they were meant to be.
You might want to check out typo, an open source blog developed in Ruby on Rails. From the overview: "Supported databases: Mysql, Sqlite, and PostgreSQL"
The concrete barrier thing was part of Senior Ditch Day, the most wonderful day of the year at Caltech. Ditch Day activities are centered around "stacks", not the usual pranks (called "RFs"). RF stands for either Royal Fuck or Real Fun or whatever other phrase you can find that fits.
Most of the things I love about Ruby are qualities that it inherits from the Smalltalk programming language. Typing objects instead of variables, everything is an object, object-based encapsulation, blocks as objects, polymorphic collections with enumerators, and the overall style of programming. Ruby is the first language since Smalltalk that I could really grow to love. It adds a lot that Smalltalk doesn't have, like regular expression syntax and better case statements, modues and mixins, and easier access to metaprogramming.
In some ways Ruby is a bit too dynamic - one of the strengths of Smalltalk is its simplicity and the predictability of your code. With Ruby it's easy to adopt a programming style that makes it difficult to predict what will happen when you do something in your code. Experienced programmers should be able to avoid those pitfalls, but I worry that some of the features will ecourage neophytes to create code that is difficult to maintain or understand.
You're trying to be funny, but you've got the only comment so far that mentions what I consider to be the most significant thing about Rails - convention over configuration. One reason why Rails development is so fast and often enjoyable is that you don't have to muck about with a lot of XML config files. If you just follow the path of least resistance, things just work out right.
The MVC triad in Rails uses the ActiveRecord class for the model part. ActiveRecord is an ORM (Object Relational Mapping) class that follows a few clever rules about doing the mapping, so most of the time you don't have to repeat your mapping multiple times. If you have a "User" class, it knows to look for a table in the db called "users", and assumes the primary key is an integer named "id". A foreign key to an account record is assumed to be called "account_id". The creation time of a record is assumed to be a datetime named "created_at". All common elements have reasonable defaults, so when you are working on your app, you don't need to spend a lot of time mucking about with config files to specify stuff that is just so fracking obvious that it is a waste of your time to type it.
Rails is not all things to all programmers, but it has certainly hit the sweet spot for a huge class of web applications - database backed interactive sites. The Rails design is good for probably 90% of the sites that I use most.
As for coder jollies, well, it's been a while since I enjoyed programming. With Rails I've regained my enjoyment for programming enough that I'm considering doing that for the main part of my work again.
Yesterday NPR had a segment on Paul English, which included him phoning into support lines of several companies including Apple Computer. A friend of mine works at Apple in the AppleCare department, and I pointed him at the program. After listening, his reaction was, "No, they are only making their call take longer by bypassing the menu!" The human that you reach when you bypass the menu is not set up to help you. All she can do is direct you to an agent who can provide actual help, which is exactly what the IVR menu was doing before you bailed out.
I agree that most IVR systems have serious usability problems. One of my pet peeves is that after I've gone to the trouble of keying in my account number, the human agent makes me recite it, instead of just reading it off her screen. But it gets far worse: if there is a problem with your account balance, some companies won't even let you talk to a human until you've made an automated payment, even if you are calling to sort out that you've already paid and they made an error! There does need to be an escape hatch for issues the IVR isn't set up to handle. But in many cases, using the IVR and getting routed to the right agent is going to be faster than bypassing.
First off, mod parent up. That was a wonderfully cogent explanation.
However, I think there is still a case to be made that drug companies are getting something of a free ride at taxpayers' expense. Sure, they still have to invest money in bringing a drug to market, and paying for the trials to do that is expensive. But they do get a big break by the taxpayer footing the bill for much of the basic research. Perhaps drug companies that market medications based on publically funded research should have to pay back the cost of the research into the fund, so it can be used to pay for further research. That seems like a start at fair compensation for lowering their product development risk by several orders of magnitude.
Ordinary tap water (preferably distilled) is supplied to the fireplace through a pipe or tank...
The manufacturer's site actually specifies deionized water. As we all learned in high-school chemistry, pure water is a lousy electrical conductor. In fact, it's an excellent insulator. Water needs ionic impurities to conduct current, so distilled water can't be used for electrolysis without adding a pinch of salt. I'm assuming that ordinary deionized water has sufficient impurities to allow enough current for electrolysis to occur, but few enough so that the device doesn't get mucked up with the residue.
Your confusing Star Trek with reality...
No, I'm comparing them. The original article confused a rendered mockup with reality. And the parent comment mentioned LCARS, so I expanded on that. I'm not confused all.
If you read Sternbach and Okuda's tech manual for the Enterprise-D, you'll find the LCARS terminals have an interface that includes not only dynamically shifting graphics but tactile feedback as well. All the soft button graphics and okudagrams are fronted by low-power force fields that let the user touch type, feeling the buttons by sense of touch and getting tactile feedback for button presses, slider movement, etc.
The conceptualization of the titan (not god) Atlas bearing a globe on his shoulders is relatively modern - 16th century actually. In classic times he bore the vault of the heavens on his shoulders.
You don't have to sign up for an account or pay anything. Before the end of your free week, you have the option to pay $9.95 once for a basic account, or $9.95/month for a premium. Your credit card is not automatically charged for anything if you don't cancel. The credit card is used to verify identity and age, as Second Life is for adults only. (There is a teen grid for those under 18.)
Slashdot Mirror
Well, encrypted telepathy might be a bit beyond our tech level this decade, but you do raise an interesting point. If our current email system is essentially useless, we may finally be at the point where we can scrap it and create a replacement that isn't fundamentally vulnerable to spamming. Many of the anti-spam retrofits like SPF are limited by having to retain backwards compatibility. If we're giving that up, we could probably come up with something that works better and is easier to implement
Interesting question: if we don't voluntarily scrap the existing email infrastructure, how long until spam makes it effectively 100% broken anyway?
"We must ask the reader to suspend disbelief, not hang it by the neck until dead." --Ursula K. LeGuin
Years ago I took a great class on technical writing. While the instructor didn't realize it because she wasn't an engineer, the process she described for writing technical documents was nearly identical to the process I used for writing software. This process isn't the best for creative writing, but for more informational type writing it helps a lot.
The usual steps for writing software include get requirements, design, prototype, implementation, testing, alpha release, beta release, etc. There are steps for writing that parallel those: define goal, research (if needed), outline, draft, copy edit, review, proofread, revise, etc. I found that once I understood the process for writing a document, actually writing the content was much easier.
And this essay by Bertrand Russell is a must read: How I Write (especially the next-to-last paragraph).
seems like Linden Labs are the only people unable to make money off of their own creation
Nope. Most people in Second Life don't make any money off of it. There are very few who make significant money there, and a mere smattering who can quit their day job to live off their virtual job. Linden Lab keeps changing the rules in SL to favor the businessfolks who are trying to make money in virtual businesses, but it's slow to build up an economy from scratch. And then there's the problem that when they shift things in favor of the businessfolk, it usually makes the game less attractive to people who aren't there to make money.
But where are the Sleestaks? Don't they usually hang out around pylons?
Flash memory cells will indeed wear out after some number of writes. This number is typically pretty high, on the order of a million writes. For most file operations that will probably be a higher MTBF than a magnetic disk with moving parts. Any significant problem would be with hot spots, like VM backing store and file system tables. However you can level wear by using cells in a something like a round-robin fashion. Remember that contiguity isn't an issue with flash because there is no seek time waiting for the head to move. There will probably be some challenges in balancing wear leveling against optimizing file system and VM performance, but in the long run flash drives will likely be much faster and more reliable than magnetic disks.
If you don't like it, don't use it. Like every other tool/framework/system ever developed, Rails will work for some and not for others. I've found Rails to be extremely productive and maintainable, but I'm an OOP die-hard and the approach is easy for me to grok.
One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort. The other thing I like is that it provides a clean separation between data storage and business logic. Database programmers seem to hate that approach because it shifts the center of gravity away from the database and toward the web app. This is great for maintainability of application code, but I don't know how well it works for sharing data among multiple apps. I don't know if anyone has gotten ActiveRecord models to support the same level of integration as you can get with multiple apps running off of one database - I think there needs to be more work done to enable that, but I expect to see that work done fairly soon.
The other cool thing about ActiveRecord is the use of metaprogramming, as discussed in the FA. I don't think we'll ever see a Java persistence layer that is as functional and easy to use as ActiveRecord, because the kind of metaprogramming tricks that Ruby enables are so much harder to do in Java.
The AWDR book from Pragmatic includes material on creating an admin interface to the Depot application. I've found that to be a useful starting point for my own efforts. Chad Fowler's upcoming Rails Recipes book also has information on authentication. There are also a good number of auth plugins to be found on the wiki (wiki.rubyonrails.org), though I've found that it's simple enough to roll your own.
Once you've worked out your authentication, it's pretty easy to use scaffolding to create the basics of your admin interface. I will create scaffolds for all my tables in an admin/ module, and include authorization for all access to those scaffold controlers. That's about as much as I want from a standard admin interface - anything more than that will be constraining my app by the assumptions it makes about how it runs.
If you are looking for automation to help control your app in production, check out Switchtower. It is an excellent tool for remotely managing your app's deployment and operation in production.
While lots of hosts offer RoR hosting now (Dreamhost, TextDrive, PlanetArgon, etc.), this article is about developing using RoR, not deploying. Many RoR developers use Macs for their development work, and many of them have converted from using Windows because they've seen how much better the development tools are on the Mac. This article does a great job at showing how to get started doing that development.
My intended headline was "Apple Rewards Top WebKit Contributors with MacBooks". But that was over the 50 character limit for headlines, so I had to tweak my word choice to fit within the limit. It's ugly, I'm embarrassed, but I chose that option over leaving out the word "Top" because I felt it was more important to distinguish that not all contributors were rewarded. I blame the editors!
This is the only extant book on Ruby on Rails: Agile Web Development with Ruby on Rails . There are about a half dozen others that will be available later this year, but the Agile book is quite good and sufficent to get you started.
This isn't a new idea, that HIV isn't the cause of AIDS. You get these kind of weird ideas when laymen try to apply "common sense" in place of domain knowledge. HIV is a retrovirus that attacks the immune system, so it has unusual characteristics and effects compared to most other viruses.
A common argument goes that when a person is most sick with AIDS they have a low HIV load, which "doesn't make sense", since in all other viral infections the viral load is high when the infection is acute. However, since HIV destroys the immune cells in which it grows, you can actually see a low viral load as the infection progresses because it has no place left to grow. But by then the immune system is no longer effective at fighting off other infections and the infected person gets very sick.
As for the procedures that were followed, I think researchers have done a very good job at studying HIV and its transmission. However no ethical researcher would intentionally infect a human with a fatal disease, and HIV is specific to humans. SIV (a related virus that infects simians) has also been studied and it's pretty well accepted by now that SIV causes an AIDS-like condition in monkeys, and that HIV is actually the agent that causes AIDS in humans.
In the past I've found the Daleks to be a bit of a joke. But this time round they finally seem like the threat they've always been made out to be. They may look silly, but they are kick-ass, genocidal death machines. Russel T. Davies takes on all the Dalek stereotypes and turns them inside out. At long last, the Daleks are as scary as they were meant to be.
"What are you going to do? Sucker me to death?"
You might want to check out typo, an open source blog developed in Ruby on Rails. From the overview: "Supported databases: Mysql, Sqlite, and PostgreSQL"
The concrete barrier thing was part of Senior Ditch Day, the most wonderful day of the year at Caltech. Ditch Day activities are centered around "stacks", not the usual pranks (called "RFs"). RF stands for either Royal Fuck or Real Fun or whatever other phrase you can find that fits.
This Wikipedia blurb on Caltech pranks mentions some of the more well-known RFs. And of course, when it comes to Caltech vs MIT in pranks, Caltech rules!
Most of the things I love about Ruby are qualities that it inherits from the Smalltalk programming language. Typing objects instead of variables, everything is an object, object-based encapsulation, blocks as objects, polymorphic collections with enumerators, and the overall style of programming. Ruby is the first language since Smalltalk that I could really grow to love. It adds a lot that Smalltalk doesn't have, like regular expression syntax and better case statements, modues and mixins, and easier access to metaprogramming.
In some ways Ruby is a bit too dynamic - one of the strengths of Smalltalk is its simplicity and the predictability of your code. With Ruby it's easy to adopt a programming style that makes it difficult to predict what will happen when you do something in your code. Experienced programmers should be able to avoid those pitfalls, but I worry that some of the features will ecourage neophytes to create code that is difficult to maintain or understand.
You're trying to be funny, but you've got the only comment so far that mentions what I consider to be the most significant thing about Rails - convention over configuration. One reason why Rails development is so fast and often enjoyable is that you don't have to muck about with a lot of XML config files. If you just follow the path of least resistance, things just work out right.
The MVC triad in Rails uses the ActiveRecord class for the model part. ActiveRecord is an ORM (Object Relational Mapping) class that follows a few clever rules about doing the mapping, so most of the time you don't have to repeat your mapping multiple times. If you have a "User" class, it knows to look for a table in the db called "users", and assumes the primary key is an integer named "id". A foreign key to an account record is assumed to be called "account_id". The creation time of a record is assumed to be a datetime named "created_at". All common elements have reasonable defaults, so when you are working on your app, you don't need to spend a lot of time mucking about with config files to specify stuff that is just so fracking obvious that it is a waste of your time to type it.
Rails is not all things to all programmers, but it has certainly hit the sweet spot for a huge class of web applications - database backed interactive sites. The Rails design is good for probably 90% of the sites that I use most.
As for coder jollies, well, it's been a while since I enjoyed programming. With Rails I've regained my enjoyment for programming enough that I'm considering doing that for the main part of my work again.
Yesterday NPR had a segment on Paul English, which included him phoning into support lines of several companies including Apple Computer. A friend of mine works at Apple in the AppleCare department, and I pointed him at the program. After listening, his reaction was, "No, they are only making their call take longer by bypassing the menu!" The human that you reach when you bypass the menu is not set up to help you. All she can do is direct you to an agent who can provide actual help, which is exactly what the IVR menu was doing before you bailed out.
I agree that most IVR systems have serious usability problems. One of my pet peeves is that after I've gone to the trouble of keying in my account number, the human agent makes me recite it, instead of just reading it off her screen. But it gets far worse: if there is a problem with your account balance, some companies won't even let you talk to a human until you've made an automated payment, even if you are calling to sort out that you've already paid and they made an error! There does need to be an escape hatch for issues the IVR isn't set up to handle. But in many cases, using the IVR and getting routed to the right agent is going to be faster than bypassing.
Some obvious missing classics:
Forbidden Planet
Silent Running
Powers of Ten (ok, it's a short feature, but still a classic)
And some good ones that are better than ones that made the list:
Aliens
Galaxy Quest
(And if the new Battlestar Galactica series counted it would be near the top of my list.)
First off, mod parent up. That was a wonderfully cogent explanation.
However, I think there is still a case to be made that drug companies are getting something of a free ride at taxpayers' expense. Sure, they still have to invest money in bringing a drug to market, and paying for the trials to do that is expensive. But they do get a big break by the taxpayer footing the bill for much of the basic research. Perhaps drug companies that market medications based on publically funded research should have to pay back the cost of the research into the fund, so it can be used to pay for further research. That seems like a start at fair compensation for lowering their product development risk by several orders of magnitude.
Ordinary tap water (preferably distilled) is supplied to the fireplace through a pipe or tank...
The manufacturer's site actually specifies deionized water. As we all learned in high-school chemistry, pure water is a lousy electrical conductor. In fact, it's an excellent insulator. Water needs ionic impurities to conduct current, so distilled water can't be used for electrolysis without adding a pinch of salt. I'm assuming that ordinary deionized water has sufficient impurities to allow enough current for electrolysis to occur, but few enough so that the device doesn't get mucked up with the residue.
Your confusing Star Trek with reality...
No, I'm comparing them. The original article confused a rendered mockup with reality. And the parent comment mentioned LCARS, so I expanded on that. I'm not confused all.
If you read Sternbach and Okuda's tech manual for the Enterprise-D, you'll find the LCARS terminals have an interface that includes not only dynamically shifting graphics but tactile feedback as well. All the soft button graphics and okudagrams are fronted by low-power force fields that let the user touch type, feeling the buttons by sense of touch and getting tactile feedback for button presses, slider movement, etc.
The conceptualization of the titan (not god) Atlas bearing a globe on his shoulders is relatively modern - 16th century actually. In classic times he bore the vault of the heavens on his shoulders.
You don't have to sign up for an account or pay anything. Before the end of your free week, you have the option to pay $9.95 once for a basic account, or $9.95/month for a premium. Your credit card is not automatically charged for anything if you don't cancel. The credit card is used to verify identity and age, as Second Life is for adults only. (There is a teen grid for those under 18.)