Posted by robby about 11 hours ago
A week ago today, we launched the new PLANET ARGON web site. That went great! Then, late last week, Jeremy Voorhis and I announced that we were working on a top-secret project, Refactoring Rails. Thought that was it? Guess again.
OHIO TO OREGON
We are exicted to announce that this Saturday, Jeremy Voorhis will be catching a flight from Pittsburg to Portland to come and join the PLANET ARGON Core Team. We’ve been working with this highly talented individual on several recent development projects and it only seemed natural that he play a more active role in PLANET ARGON. So we asked him to pick up, move to Portland and join the team here. Well, Jeremy took us up on the offer and is preparing for the big move as I type this.
PDX.rb += 1
Portland Ruby Brigade, expect to see a new face at the December meeting!
And if you think this is the last of our accouncements… well, stay tuned…
UPDATE: Yes, this means that Jeremy will join us out West to work with Ruby on Rails all-the-time!
Posted by Curt Hibbs about 14 hours ago
First there was News.com/ZDNet,
then there was PCMagazine’s Digital Life,
and now eWeek.com has both a article
on Ruby on Rails and an interview
with its creator David Heinemeier Hansson!
Just like the old adage says, when it rains, it pours...
Posted by about 14 hours ago
The Typo theme contest just got beefed up quite bit. Site 5 has offered a 15” Powerbook for the wining theme and a 12” iBook for number too. That’s on top of the truck load of other prices.
If you have any sliver of design skill in your bone, you’d be well advised to participate in this content. Oh, and the upshot is that Typo gets a legion of cool new themes out of it too. See, everybody wins!
Posted by Doug Alcorn about 14 hours ago
Just wanted to pass on some kudos to the Typo team. I had been running an older stable release version 2.5.3 and just upgraded to the Subversion trunk. The whole process was very smooth.
When I upgraded Rails on my server to 0.14.2, ecto quit communicating properly with my blog. I had seen some traffic about compatibility between typo and the latest Rails and decided to just upgrade all the way. The whole process only took about 10 minutes or so. The migrations went extremely smoothly; much better than last time.
Another motivator for upgrading to current is category based RSS feeds. My understanding is the Planet Typo is going to be fairly focused on typo. So, I wanted to add something to the content without cluttering it up with cute kid stories.
This blog post was brought to you by the word “smooth” and the number 3.
Technorati Tags: Planet, subversion, typo
Posted by Doug Alcorn about 15 hours ago
Adam Greenfield of Site5 has setup Planet Typo to aggregate blogs of Typo. It’s running the newly released rails planet. If you have any suggestions for who’s blog should be included, send them to admin@planettypo.com.
Technorati Tags: Planet, typo
Posted by Jonathan Weiss about 16 hours ago
The winner of the FreeBSD logo competition is Anton K. Gural.
Jun Kuriyama announced the winner on announce@freebsd.org.
The details can be viewed here. The first reactions on the mailing lists are divided.
Personally I have to adjust to the new logo, but the longer I look at it the better it looks.
Posted by about 18 hours ago
eWEEK has another cool article on the growth of Ruby on Rails. Including comments from ActiveState and JBoss. Good stuff.
Posted by tobias about 19 hours ago
The typo theme contest is going in overdrive move. Thanks to the wonderful guys at site5 the prizes now include a 15” Powerbook and a 12” iBook joining the ranks of the IPod nano and all the other great stuff.
What are you still waiting for? Crank out those amazing themes!
Posted by Curt Hibbs about 20 hours ago
Hot on the heals of yesterday’s news that Ruby on Rails
had broken into the mainstream media with articles on News.com
and ZDNet,
I just found out (via Riding Rails)
that PC Magazine’s Digital Life TV program recently featured Ruby on Rails.
You can download the video
(135MB) and watch the segment that begins about 7 minutes and 20 seconds into the program.
Posted by dhh about 22 hours ago
Robert Scoble has an honest and poignant analysis of why the Microsoft suite of tools just doesn't cut it for web-application development at the moment.
One example of how we feel this with Rails is by how hard it is to retain a maintainer for the SQL Server database adapter. None of the developers that have been or are working on it are in it for the long term. It's just that they need it while they either migrate their shop over to open-source alternatives or find a new job that doesn't force them to use Microsoft tools.
Naturally, that's a pretty self-selected pool of talent. And its very easy to adopt the view that nobody interesting are using Microsoft for the web anyway. That Microsoft is for medium-sized businesses full of sales people and techies past the expiration date. Surely, that isn't so.
But the reason that this is even a viable caricature comes from that fact that Microsoft is now entirely optional. No part of the stack needs Microsoft. Not on the client, not on the server. And I think that's a pretty tough challenge for a company that used to be a necessity. You have to compete very differently when you're just one choice out of many instead of the only show in town.
To be frank, I don't ever see the good times coming back for them. Microsoft will have to move to higher grounds. Get out of the infrastructure race. Like Apple did. There is no dominant future for the Microsoft tool chain for web development in sight. But I doubt the company will acknowledge that before it's game over.
Posted by Jesse Andrews 1 day ago
Scoble has an interesting post about how Google is disruptive by not worrying about making money. His point is about the differences in the internal structures, but I find it interesting that the differences come down to one point - what they tell their developers.
Google makes its money primarily off it advertising business, deliver via search and integrating with external content. All other areas they are willing to lose money to build the brand - as Scoble put it: "Google tells its engineers to go and come up with cool services without thinking about monetization strategies they say theyll figure that out later."
Microsoft makes its money primarily off two products - Windows & Office. Last time I read, every other product loses money. Microsoft has stated that they are willing to lose money to build the brand and compete in new markets (*cough* xbox & msn, among others *cough*).
Both lose money on non-core products but want to build their brand. Both say they will make money on new products eventually. The only difference seems to be that Google tells its engineers build something cool, figuring out the money thing can be done later by others. Does this mean Microsoft puts stress on its engineers to produce financially successful products instead of awesome software. Otherwise why would Scoble characterize Google's methods as disruptive as up until this point the strategies are very similar. There may be complex reasons why Microsoft cannot allow its developers to ignore fiscal concerns (such as legal constraints due to previous anti-trust violations.) Even though, the overall message may be that Google and Microsoft are executing the same strategy but the attitude makes all the difference.
My company just built a Ruby on Rails interface on top of Small Business Account (Microsoft's answer to Quickbooks). SBA didn't include timers, widgets or a web interface. Before we settled on building a xml-rpc server to connect to SBA, we experimented with connecting directly to the SQL database. The database schema is horribly complex! The diagram we produced looks closer to the design of an intel chip than an accounting database. While the product is much better than Quickbooks, it appears to have been created by developers without passion. Freeing developers from worrying about fiscal worries helps them create great software.
Come on Bill, I remember when you thought it was being cool that mattered.
Posted by Jesse Andrews 1 day ago
Scoble has an interesting post about how Google is disruptive by not worrying about making money. His point is about the differences in the internal structures, but I find it interesting that the differences come down to one point - what they tell their developers.
Google makes its money primarily off it advertising business, deliver via search and integrating with external content. All other areas they are willing to lose money to build the brand - as Scoble put it: "Google tells its engineers to go and come up with cool services without thinking about monetization strategies they say theyll figure that out later."
Microsoft makes its money primarily off two products - Windows & Office. Last time I read, every other product loses money. Microsoft has stated that they are willing to lose money to build the brand and compete in new markets (*cough* xbox & msn, among others *cough*).
Both lose money on non-core products but want to build their brand. Both say they will make money on new products eventually. The only difference seems to be that Google tells its engineers build something cool, figuring out the money thing can be done later by others. Does this mean Microsoft puts stress on its engineers to produce financially successful products instead of awesome software. Otherwise why would Scoble characterize Google's methods as disruptive as up until this point the strategies are very similar. There may be complex reasons why Microsoft cannot allow its developers to ignore fiscal concerns (such as legal constraints due to previous anti-trust violations.) Even though, the overall message may be that Google and Microsoft are executing the same strategy but the attitude makes all the difference.
My company just built a Ruby on Rails interface on top of Small Business Account (Microsoft's answer to Quickbooks). SBA didn't include timers, widgets or a web interface. Before we settled on building a xml-rpc server to connect to SBA, we experimented with connecting directly to the SQL database. The database schema is horribly complex! The diagram we produced looks closer to the design of an intel chip than an accounting database. While the product is much better than Quickbooks, it appears to have been created by developers without passion. Freeing developers from worrying about fiscal worries helps them create great software.
Come on Bill, I remember when you thought it was being cool that mattered.
Posted by dhh 1 day ago
Early detractors of the Rails approach with application skeletons and component generators dismissed the framework at large under reference to "code generation". The thinking went that all Rails was really doing was creating a boilerplate mess that might give a quick taste of productivity, but would rapidly turn into a sour soup of mud.
Like those wizards of yesteryear that would ask you a bunch of questions through multiple screens, generate a ton of code you didn't understand, and then leave you stranded when a bug arose or extensions were needed. Needless to say, no sane software developer would be interested in bringing those dinosaurs back from the grave.
So the argument almost played itself. Rails is all code generation, code generation is bad, therefore, Rails is bad. Only one problem: What Rails is doing with its generators lie far enough away from the horror stories of the past to go under the same name.
The problem is that the code-spewing wizards gave the whole field of code generation a bad name. That in and of itself is certainly a shame. There are a lot of good forms of code generation (see the excellent Code Generation in Action for examples). But I admit that the term is somewhat tainted and its not really representative to what we do in Rails anyway.
Enter Structure Generation. See what we do in Rails is a lot less about generating lines of code and a lot more about generating structure. Herding the programmer down the path of conventions. Creating the right directories, the right files, and calling them the right names. It's conventions on rails.
Allow me to demonstrate:
$ ./script/generate model post
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/post.rb
create test/unit/post_test.rb
create test/fixtures/posts.yml
$ cat app/models/post.rb
class Post < ActiveRecord::Base
end
$ cat test/unit/post_test.rb
require File.dirname(__FILE__) + '/../test_helper'
class PostTest < Test::Unit::TestCase
fixtures :posts
def setup
@post = Post.find(1)
end
# Replace this with your real tests.
def test_truth
assert_kind_of Post, @post
end
end
$ cat test/fixtures/posts.yml
first_post:
id: 1
another_post:
id: 2
As you can see, the actual code for the model is two puny lines of code. The important part is that the file is automatically put in the proper place, app/models/post.rb, and that it correctly descends from the proper super class. You don't have to think about how Rails is laid out, the convention is following from the use of the generator.
The second part is of course that this creates stub files for testing. This looks like code generation, but its really not. The code is not meant to keep. It's only there to explain the structure of how tests are supposed to work. Giving you an immediate sense of how to create your own test cases. So its nearly void on content, but rich in structure. Same goes for the fixtures. They're not there to keep, but to give an example of their usage.
But the effect of this is quite significant. It means that right after creating the model (and the corresponding database table), you can run your tests using rake test_units. The structure is in place, now you fill it in with your own content.
Structure generation drastically lowers the learning curve by teaching the conventions through code instead of documentation. It sets you up to succeed, to get the "hello world" (or, "I rule!") experience out the gates. Which will make you actually interested in putting in that content of your own.
Generating the model class is the simple example. We've just added script/generate plugin, which takes the same approach to we used for application development and applies it to framework extensions. I expect to see a whole new class of framework extenders pop up now that the structure is not a barrier to entry.
Structure generation is how dynamic languages that don't need the old-school code generation can still use automation. The domain-specific languages killed the need for the boilerplate, but anyone can still need a guiding light to where things go. Structure generation does just that.
Posted by tobias 1 day ago
A Little tidbit from the rails mailing list:
In Shopify there are over 30 tables which store a shop_id. The Shop
object is figured out at the beginning of each request by looking at
the incoming domain of the user.
Product.find(:all) becomes shop.products.find(:all)
Product.new becomes shop.products.build
Since rails 0.13.1 we support calling class methods over associations.
This is actually a direct extraction out of shopify and makes such
databases much easier to handle.
class Product < AR:B
def self.search(q)
find(:all, :conditions => "title LIKE '%#{q}%'")
end
end
Product.search(“snowboard”) will search in the entire database as
normal but shop.products.search(“snowboards”) will only search the
products with the appropriate shop_id.
This same change which allowed this also makes dynamic finders work on associations. shop.products.find_by_type(‘snowboard’) returns the expected results .
Posted by PJ Hyett 1 day ago
I'm going to use Subversion as an example. I had a question about a compilation error regarding the Ruby SVN bindings and was unable to locate an answer by searching through the mailing lists.
I proceeded to look around hoping for a help forum or something of that nature. They do have an IRC channel at freenode, but IRC help is always pretty unreliable, especially with such a specific problem like I was having.
So, the only thing left is posting a question on the mailing list. Unfortunately, mailing lists are a pain in the ass:
- Send subscription email to the listserv
- Wait for reply
- Send confirmation email
- Post a question, wait for responses
- Receive 100 emails from list that you don't care about
- Figure out solution to problem
- Unsubscribe from list
- Receive another 20 emails before listserv unsubscribes you
Am I the only one that thinks this process is ridiculous? I think every open source project should have a web forum in addition to a mailing list for situations like this.
Note: I like mailing lists, they have their place, but the process should be streamlined for people to ask the occasional question (if no other solution is available). Yes, I know it could lead to more spam, fortunately, there's a lot of smart CS people to figure it out.
Posted by bsag 1 day ago
photo Drop is a polished gem of an application that does one thing quickly, stylishly and without any fuss. It allows you to create droplets onto which you can drag and drop image files in order to perform a number of different modifications. It acts as a front end for the command line tool sips [...]
