3 ms·

> I started using Rails probably at 1.0 > I've been doing web development since 1994 > some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP

by yebyen 8y ago

> I started using Rails probably at 1.0 > I've been doing web development since 1994 > some CGI programs in C, CGI.pm (Perl), Struts (Java) and occasional PHP I said junior developer, didn't I? :) and also mentioned that this was my first ("permanent") job (after college)? Getting to know what's in a web framework, is exactly the learning curve I'm talking about. People complain about magic in Rails. I just wrote an ERB view "index.html.erb" and declared an empty method "index" in my controller. Add in a route definition, and now somehow they are all connected. What is actually happening? Why does that even work? If you've never used any web framework before, that's inscrutable magic. If you know what a correctly designed controller method looks like (it should maybe fetch some values, then render a view... and probably nothing else) then it's obvious. Getting over that hurdle is ... definitely not the kind of shit my first boss hired me to do. I'll say again, most of my assignments for the first year had nothing to do with "on a web page."

busterarm 8y ago
The magic isn't really magic if you have a basic understanding of how Active Record works, which really just means you know SQL and what kinds of queries all of those named relationships and parameters generate. This is like the critical piece to groking Rails and we minted too many "Rails developers" who don't know this. The only missing piece then is how internet requests are routed. Basic knowledge of how HTTP and TCP/IP work. My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even. If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.
- yebyen 8y ago
  I read your first paragraph... but then I read the rest of what you said. Having read the whole comment, I'd say that is spot on. I knew some SQL, but didn't start with Active Record. We used SQL client libraries to connect to our SQL database, which didn't have a Rails app built onto it until well into my second year. I did all of that, except for the implementing ActiveRecord and the meta-programming. So I didn't really do any of that. We didn't have a production Rails app until it was clear that I was gaining proficiency, and I'd be sticking around long enough to get a handle on how to manage it. (I didn't write most of it. And we avoided metaprogramming pretty much at all costs.) We had a production Microsoft Access app (no really, VBS in Access 2000), with a MySQL server on the backend, along with tons of perl, bash, and ruby to glue the important parts together. There was a Java app that handled the web side of things. I don't think I'll ever work in a place like that again! But it was the path I took, and now I work on pretty much exclusively Rails.

by yebyen 8y ago

busterarm 8y ago

The magic isn't really magic if you have a basic understanding of how Active Record works, which really just means you know SQL and what kinds of queries all of those named relationships and parameters generate. This is like the critical piece to groking Rails and we minted too many "Rails developers" who don't know this. The only missing piece then is how internet requests are routed. Basic knowledge of how HTTP and TCP/IP work. My stance on this (and how I did it as a junior) is to have someone implement a toy implementation of Active Record's basic relationships using Ruby meta-programming and to implement a basic request-response server. This is part of the curriculum of some bootcamps even. If your junior developer can't do this, they shouldn't be touching your production Rails application. Your immediate goal on hiring them is to train them to be able to do this.

yebyen 8y ago
I read your first paragraph... but then I read the rest of what you said. Having read the whole comment, I'd say that is spot on. I knew some SQL, but didn't start with Active Record. We used SQL client libraries to connect to our SQL database, which didn't have a Rails app built onto it until well into my second year. I did all of that, except for the implementing ActiveRecord and the meta-programming. So I didn't really do any of that. We didn't have a production Rails app until it was clear that I was gaining proficiency, and I'd be sticking around long enough to get a handle on how to manage it. (I didn't write most of it. And we avoided metaprogramming pretty much at all costs.) We had a production Microsoft Access app (no really, VBS in Access 2000), with a MySQL server on the backend, along with tons of perl, bash, and ruby to glue the important parts together. There was a Java app that handled the web side of things. I don't think I'll ever work in a place like that again! But it was the path I took, and now I work on pretty much exclusively Rails.