Andreas Lyngstad's Profile

I love railscasts, but not this episode. I think it is wrong that "testing is out of the scope of this episode". You should have had tests at the start of the refactoring and ran them instead of going to the browser all the time.

It is about the mind set.

A lot of times we need to get some tings up in a hurry, and skip testing (because it is out of the "scope of things").

I guess almost all rails developers in the world watch railscasts. So, railscasts has a responsibility to show the "right" work flow.

I understand that the episode is a bit long. But it would be better and shorter if you skipped the sign_up form and did TDD on the PasswordForm.

Rails has to move in this direction.

If not it'll get obsolete in no time. With competition from meteor, backbone and all the other js frameworks, people start asking: "Why do I need this bloated Rails stuff?" The whole convention over configuration is a double-edged sword. Users shouldn't (and therefore don't) know about the trivial (but hard to solve on you own) questions.

For example Rails solves crsf with one line in the application_controller. Many other frameworks requires more configuration and because its hard to understand that leads to solutions like "- just disable crsf". In rails you don't have to think about the trivial stuff, just make your application.

The browsers to day is no longer dumb terminals. So, we have to make them work more trough javascript and JSON. Rails have to make better conventions for better handling JSON and open connections if we want to keep it relevant. If we keep on mainly sending rendered HTML down to a (stupid) web browser, rails soon be the old hog.

This episode shows that still it is to much configuration. The rails core team should make decisions. Code should be simple like this

keep_open(messages)

I agree. But for me railscasts is more a "Hi, check this new gem and learn how to use it in 10 minutes" series. While Gary Bernhardt's screencasts is more like "So, you think you know how to do standard rails stuff, well let me blow your mind" Alert => mindblowing: burn your controllers. They both are great but for different reasons.

Just for fun wat

I really like this approach. I hate when the models get to fat ("ball of methods"). Many times they have to deal with tings that should not concern them. I use the lib folder and add workers for the complex controllers. One advantage is that you can run tests isolated form rails and tests get really fast.

If you like to see more screencasts on refactoring, go to destroyallsoftware
We call it rails porn (Yes, it's really that good!)

Sorry, Ryan for promoting another paid rails screencast series here, but I think that it's more complementing than competing with you.

This looks really great. I will test it. Its a lot less magic than turbolinks.

+1 for TESTS!!! I found this to be quite hard to test. The complexity grows when you have an authentication system on top of the subdomains.

Thanks! Spent hours on making precompiling work. I also had problems with errors in external js files like the ckeditor. Had to fork the git and correct the errors to complete the precompiling.

I never worked with backbone.js, but it seems to me that rails is a bit heavy when you skip most of the rails functionality. Would it not be better to use sinatra or even not use ruby at all? I guess you could use node.js?

testing backbone.js tutorial

Thanks Ryan for all the work on these screencasts.

As I am stuck on windows 7 for a lot of reasons, I feel a bit left out this week.

If you add a status boolean in the friendship table you can do away with the invert_friendship assosiation

+1

For trouble on windows

On my windows 7 box I had to do

$ bundle exec guard

could not use

$ guard

Yeah! read that on twitter too. Go to bed next time you get sick, we can wait. Hope you feel better.

Thanks! Great episode. I would really like to know more about the benefits of unicorn over passenger. I've found some info in the comments on the github unicorn site.

Matt Freels says
Unicorn can restart your app without any lost requests or stalls.
Passenger drops your app and its workers, and then lets the next request bring the new version up.

I would say the biggest difference is that where Passenger is opinionated and fairly all-or-nothing, Unicorn gives you more transparency and control over its configuration (while still nicely managing workers).

Question is where is passenger ok to use? It seems easier to set up? (or is it?)

You'll get problems when you add more then only one at a time

Looking at railscast.com on github, it has not been committed to since 11.08.2011. Are all this PRO features exluded form the open source railscast repo?

second that too

WOW! what a cast! I also want to see this.

Thanks! I was also getting the :3000:3000. This fixed it for me too.

On windows there is an exe installer. On mac and linux the install prosses is well documented here and here go to wiki on the last one