Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.
1,261 karma · joined October 30, 2008
Furthermore, one of the primary goals of the project was to make something more privacy-conscious than Facebook, and so far they show they have a development process that pays less attention to access control than any Rails app I'm aware of.
SQL for everything else.
Also, see wycats post: http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-orie...
As wycats pointed out in a post earlier this year (http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-orie...), the reason you don't need to explicitly call #call on methods is that Ruby is designed for the common case of calling methods. In addition, it's uncommon to even explicitly use #call or #[] on Procs since calling them is built into the language via yield.
http://news.ycombinator.com/item?id=1088737
Also, although I've only skimmed mhartl's book, it looks great and has already been updated for Rails 3: http://railstutorial.org/book
And for the edge rails guides (Rails 3): http://edgeguides.rubyonrails.org/
"safer than erb / haml, etc"
Are you are referring to auto-escaping strings? If so, in Rails 3, this is on by default, and for Haml without Rails it's a simple setting.
Edit: to the downvoters, what is your argument that he either a) isn't totally out of line or b) is relevant to the development of Rails or the Rails ecosystem despite his nearly complete lack of open source contributions (http://github.com/gdonald)?
The title here is "You stay classy, Rails," yet there is a single unnecessarily rude response from a Rails core member in response to criticism, followed by a bunch of inflammatory posts by a guy who apparently is just an immature troll who doesn't speak for anyone but himself.
I found chef to have a bit of a learning curve, especially when running your own chef server. I actually gave up using the server after a while and manage my servers (between 5 and 10, depending on what I'm working on, plus a bunch of one/two-off servers for client work) using chef-solo. Now that they offer a hosted server service, I might start using that, but I'm pretty content with chef-solo, roles and a minimal json config file on each server.
Chef has been a bit of a moving target during its development, so it's been hard to keep up with. This goes both for chef itself (although, presumably the API will be more stable after it hits 1.0) as well as the cookbooks. I kind of dread pulling in the changes from main cookbook repo because it's tough to know whether some change to a cookbook will negatively affect your config.
It doesn't necessarily save time up front; it takes more time to write a bug-free cookbook than do an apt-get install and edit some configs. But over the long run it makes it much easier to understand your server config. Rather than having long-forgotten edits to hidden config files, you have a solid record of exactly what your server config is.
To add to that list: http://railstutorial.org/book
No, it's not. http://news.ycombinator.com/item?id=1459119
Even though 2 hours seems like a lot, because of what it is (focusing the mind, learning to not overreact to external stimuli, stability of the mind), it makes people able to be very highly productive throughout the day.
- <input id="password" autocomplete="off" tabindex="2" type="text">
+ <input tabindex="2" type="password">
I'm looking forward to trying it out next time I'm working. Resist the temptation to add too much stuff; you're on the right track so far.Once you've dived into it deeply, then you actually have an understanding of what's going on when you do regular sittings.
$stdin.read.split.each do |w|
puts w if w.match(/ing$/)
end
or as a single 57 column line: $stdin.read.split.each { |w| puts w if w.match(/ing$/) }
we can also use the match operator: $stdin.read.split.each { |w| puts w if w =~ /ing$/ }
I'm inclined to assume that the other language examples are also suspect.SimplyHired - PHP: 10726 to 15993, Rails: 2553 to 3823, Django: 328 to 926
Startuply - PHP: 280 to 488, Rails: 121 to 230, Django: 35 to 66
StartUpHire - PHP: 458 to 549, Rails: 119 to 152, Django: 9 to 25
Itay Talgam: Lead like the great conductors: http://www.ted.com/talks/itay_talgam_lead_like_the_great_con...