The second edition of Rails, Angular, Postgres, Bootstrap is in beta.
There’s a lot of new content, mostly around Angular 2.
The current beta is about 75% complete and includes:
- End-to-end unit testing with PhantomJS
- Making your end-to-end tests work with Webpack
- Angular 2
- Setting up Webpack to serve CSS and JS
- Intro to Angular 2, including routing and unit testing.
- Using and testing Postgres check constraints
- Content-specific indexed (e.g. index on a lower-cased version of a field)
- Materialized Views
- Simple styling with Bootstrap
- Grid-based design with Bootstrap
Angular 2’s setup was painful, but it’s a much nicer framework than Angular 1, and requires a lot less plumbing and decision-making than React (based on my limited experience with React).
The skills you learn in this book will let you solve a wide variety of problems quickly, cleanly, and efficiently, using modern and powerful tools.
Note: if you bought the first edition, stay tuned—I’m not sure what accomodations will be made
In my imagined keynote for Rails 6, I imagined a lot of wacky new features for Rails. My Rails 6 had lots of big changes, and I thought it might be interesting to dig into why I think those changes are useful for Rails.
Getting configuration from the UNIX environment is a hallmark of 12-factor application design, and is a great practice. Problems arise, however, when your code is littered with direct references to it. This is because the UNIX environment is a very poor database, but we need to treat it as a better one.
I gave a talk at RailsConf ‘16 called “Can Time-Travel Keep You From Blowing Up the Enterprise”. The talk is really about scaling Rails on a growing team, and attempts to stop the discussion around “monolith vs microservices” by showing how a team can take hold of its destiny.
It’s also the exact way Stitch Fix engineering evolved, and while we have some large Rails apps, none are the monstrosities I’ve seen elsewhere.
I’ve become re-acquainted with the pattern of testing ActiveRecord classes using stuff like
expect(parent).to belong_to(:child) and I just don’t understand why anyone would ever write a test like that. It provides no value, and the implementation provided by shoulda isn’t actually testing the behavior. It’s testing configuration.