They should've made it 1920x1200. 1680x1050 is great on a 15" screen (assuming that you have a OS that you can easily adjust the text size i.e. gnome). I'd want to see a higher resolution on a 17" screen.
It's like saying "All real cars need a 1000hp engine and 30k tires, because all non-TOY cars need to go 200mph in 8 seconds", when all I want is a freaking car to get me to work every day. Or perhaps I want a truck to go camping with or move some stuff.
Do all real world, non-TOY applications have thousand of tables? Is the database the bottleneck in all real world, non-TOY applications? You seem to think so.
And why don't you think Rails can handle data sources other than a relational database? It does perfectly fine.
I don't understand why you think Migrations are configuration files. What makes something a configuration file? What makes something not a configuration file?
The vast majority of web apps out there DON'T need to scale beyond one machine. Rails uses the exact same approach for scaling (share nothing) that Yahoo, Google, Live Journal, etc use.
Rais provides *excellent* support for unit, functional, and integration tests. You can prove the software does what you want it to do.
It's funny you knock on agile stuff. Tests are good. Giving the customer something that they actually want is good. That's all agile methodologies attempt to do.
Rails enforces (or at least STRONGLY encourages) clean separation of code responsibilities. Combine that with smart code generation (of unit tests, directory structures, skeleton files, etc), easy unit testing, the elegancy of Ruby, and yeah, it saved me. As a pet project, I rewrote the bulk of http://www.gamefest.com/ from scratch in two weeks using RoR, including importing the data from the osCommerce site.
I know that there is much better PHP code out there than what's in osCommerce, my comment wasn't about PHP. It was about osCommerce and its difficulties.
The first version of Gamefest was done in Miva, but this was just after they switched to a compiled version, and I had a hell of a time customizing anything.
In defense of osCommerce, though, I was able to get http://www.gamefest.com/ up in and going in maybe two weeks after switching to osCommerce (and away from Miva merchant).
So, it does allow for a quick and easy store. It was just that customizing it was hard (back then -- perhaps stuff has changed since 2003/04).
Shopify -- http://www.shopify.com/ -- is looking interesting now as well, and is also built using Ruby on Rails.
But I last used osCommerce back in it's 2.2 days (t o build http://www.gamefest.com/ ). Doing modifications to the PHP / mysql code was absolutely painful. Horribly painful. There was hardly any separation of logic from the presentation. It was all a jumbled mess.
Slashdot Mirror
How does user-level software depend on the type of filesystem used at all?
Microsoft's BSOD is also viewed by 500,000 people daily, but I don't think I'd want that credit on my resume...
If it's too small, you should be able to scale things up. I thought OS X's UI was resolution independent by now.
Enable gcc's C99 mode.
They should've made it 1920x1200. 1680x1050 is great on a 15" screen (assuming that you have a OS that you can easily adjust the text size i.e. gnome). I'd want to see a higher resolution on a 17" screen.
I bet gnucash will be backported... (so you'd just need to add a backport apt repository and you're set to go).
Nope, for the past 7 years main() returns an implicit 0 if there's no return statement.
This has got to be the stupidest post I've read in a long time.
He's being sarcastic.
Hm. What type of an application would max out an optimized and tuned postgres running on a 32 core machine with, say, 16 gigs of memory?
I haven't been constrained by Rails's SQL generation yet.
And you didn't answer my question. When does it *really* matter?
It's fairly rare that you're going to need to scale the database beyond one machine. So, I'm not too worried about it.
Say that's true. When does it matter? And how does Rails prevent you from changing it?
I rarely use SQL in my Rails apps. Pretty much only need it when I need to optimize something, which doesn't happen too often.
I mean, Jesus Christ.
It's like saying "All real cars need a 1000hp engine and 30k tires, because all non-TOY cars need to go 200mph in 8 seconds", when all I want is a freaking car to get me to work every day. Or perhaps I want a truck to go camping with or move some stuff.
Do all real world, non-TOY applications have thousand of tables? Is the database the bottleneck in all real world, non-TOY applications? You seem to think so.
And why don't you think Rails can handle data sources other than a relational database? It does perfectly fine.
I don't understand why you think Migrations are configuration files. What makes something a configuration file? What makes something not a configuration file?
You're free to use a different ORM with the rest of Rails if you're not happy with AR.
And oddly enough, the AR pattern has worked perfectly fine on non-toy applications.
The vast majority of web apps out there DON'T need to scale beyond one machine. Rails uses the exact same approach for scaling (share nothing) that Yahoo, Google, Live Journal, etc use.
Rais provides *excellent* support for unit, functional, and integration tests. You can prove the software does what you want it to do.
It's funny you knock on agile stuff. Tests are good. Giving the customer something that they actually want is good. That's all agile methodologies attempt to do.
How, precisely, does Ruby not support Unicode? What can't you do in Ruby wrt Unicode that you want to do?
Rails enforces (or at least STRONGLY encourages) clean separation of code responsibilities. Combine that with smart code generation (of unit tests, directory structures, skeleton files, etc), easy unit testing, the elegancy of Ruby, and yeah, it saved me. As a pet project, I rewrote the bulk of http://www.gamefest.com/ from scratch in two weeks using RoR, including importing the data from the osCommerce site.
I know that there is much better PHP code out there than what's in osCommerce, my comment wasn't about PHP. It was about osCommerce and its difficulties.
What's PCI Compliancy?
The first version of Gamefest was done in Miva, but this was just after they switched to a compiled version, and I had a hell of a time customizing anything.
In defense of osCommerce, though, I was able to get http://www.gamefest.com/ up in and going in maybe two weeks after switching to osCommerce (and away from Miva merchant).
So, it does allow for a quick and easy store. It was just that customizing it was hard (back then -- perhaps stuff has changed since 2003/04).
Shopify -- http://www.shopify.com/ -- is looking interesting now as well, and is also built using Ruby on Rails.
But I last used osCommerce back in it's 2.2 days (t o build http://www.gamefest.com/ ). Doing modifications to the PHP / mysql code was absolutely painful. Horribly painful. There was hardly any separation of logic from the presentation. It was all a jumbled mess.
Then I discovered http://www.rubyonrails.org/ and life is now good!