small medium large xlarge

27 Feb 2017, 03:37
Craeg Strong (2 posts)

I am the CTO of a boutique IT consultancy in NYC. I recently read this book with interest: it exactly matches the tech stack we are helping one of our clients to adopt. I think there are some ways that the book risks turning off or otherwise not attracting an important part of its potential audience: front-end developers.
I apologize if some of the below comes off as a rant. The effort required to write a book of this size and scope is incredible. I applaud the author for doing this.

  1. Intended for Rails Experts The author starts out developing a Rails GUI the “old-fashioned way” using server-side Rails (embedded ruby pages). To a Rails expert this is good, because they first get to see a familiar solution and then see it refactored to use client-side JavaScript (Angular2). However, to anyone who is not already a RoR expert this may be confusing. Why describe two completely different ways of accomplishing the same thing? I think this section should include a caveat up front explaining that the beginning part is intended for experienced RoR developers only, and if the reader doesn’t fit that description they should probably skip ahead to the part where the author covers the AngularJS2 approach.

  2. No Rails API Also, the author uses traditional Rails rather than Rails-API, possibly because of the ERB example up front. In my opinion the book misses a great opportunity to introduce Rails5 API, a much leaner choice that was designed precisely for this type of tech stack (e.g. integration with JavaScript frameworks like Angular2). In my opinion, Rails API is a great new feature offered by Rails5, and it is a shame to ignore it when it could be such a great fit.

  3. Old Version of Angular2 The version of Angular2 being shown in the book is 2.1, while the latest version is 2.4.8. I understand that it is hard to keep up with rapid changes, but for a brand-new book I think it is very important to make an effort to upgrade on a regular basis. There are several parts where the author has to write extra code or make a workaround that is obviated by newer versions of Angular2.

  4. No Angular CLI I believe the author misses an opportunity by choosing not to use the Angular CLI to generate the front-end app. Can you imagine writing a Ruby on Rails app without using “rails generate”? The Angular CLI is an amazing feat of engineering, it saves a huge amount of time, and it feels familiar to a Ruby on Rails developer. I am skeptical about the didactic approach of showing a beginner every nuance and detail up front. I believe presenting a large amount of complexity all up front risks turning people off. I personally prefer to show my students or readers the quick and easy way, and then gradually peel back layers of the onion, to show what is really going on underneath and how they can customize it as needed. Angular CLI and Rails CLI both fit that paradigm well.

  5. No TypeScript On page 83, the author says “Angular2 is written in TypeScript, which is a superset of JavaScript… There are many advantages to this…However, the conceptual overhead of learning a new language on top of a new front-end framework is too much.” I believe the author presumes a lot here. Imagine a Java programmer saying: “We are upgrading from Java7 to Java8 but we decided that learning about lambdas was too hard, so we will skip them.” Imagine a C# programmer saying: “We are upgrading to the latest version of .NET, but the new C# async and await features are too confusing, so we are not going to use them in any of our parallel code.” The fact is that TypeScript is JavaScript, with a small amount of syntactic sugar and a few important and powerful additional capabilities. (Fun Fact: Microsoft actually invented TypeScript). Why do new capabilities get added to any programming language? Answer: to solve problems that many programmers face, and to reduce the lines of code that have to be maintained. I believe that the author introduces several problems as a result of this choice, including:

    • Most of the JavaScript examples are more verbose than they could be.
    • The examples in the book look significantly different than those that a beginner is likely to find online when they google for solutions, since the vast majority of Angular2 code uses TypeScript.

I would have felt better had the author said something like: “I am going to make a very unusual choice, that is different from the way Angular2 is typically used, in order to prove to the reader that it is possible to use Angular2 with “Plain Old JavaScript” (ES5) By contrast, the way the author stated it, it sounds like he is ignoring the last two years of (what many people consider game-changing) improvements to the JavaScript language (e.g. ES6 and TypeScript). That is in my opinion an unusual choice for a book whose purpose is, after all, to introduce a new technology based on JavaScript.

  1. Missed Opportunity to Introduce Cucumber and CucumberJS On a positive note, the author writes unit test for all aspects of the application, both front-end and back-end, and shows how the tests can all look and feel very similar even though they may test multiple languages including Ruby, JavaScript and SQL. I would have loved to see the author go a step further and introduce Cucumber testing for acceptance tests. In understand that the Pragmatic Programmer series of books are written by and for developers, but I think there is a missed opportunity to at least mention important practices like customer-centric design and acceptance testing.

  2. Missing Discussion of Trade-offs between Materialized Views vs Caching Tools On page 181 the author discusses Complex Queries with Materialized Views. I think it is great that the author explains some of the powerful features of PostgreSQL, but unfortunately the author dismisses the alternative of using a tool like Redis or Memcached or Elasticsearch without any discussion. It would be great if the author could share some of the reasons for selecting one approach over the other based on his experiences, so we could learn from his perspective. For example, I found the following reddit article that describes some of the tradeoffs between the two approaches:

“When I’d use Redis instead of Postgres’ materialized views: * If I wanted to relieve load on my database server. Easier to scale Redis out than to scale out a RDBMS. * If I wanted to cache something that isn’t relational data from Postgres, or something easily handled by Postgres’ FDW (foreign data wrappers)  * If I was frequently writing to this data, didn’t need those writes to be ACID compliant, and I want those writes to be immediately available.  * If I wanted the cached data to automatically expire after a while, since Redis makes this easy   When I’d use Postgres’ materialized views instead of Redis: * When the data comes from inside Postgres or a FDW.  * When the materialized view is updated due to stuff that happens inside Postgres, particularly if I want to share this logic across multiple applications.  * When I’m not concerned too much about the view affecting the scalability of my database server… it’s not huge amounts of data, and I’m not reading/updating it hundreds of times per second.”

Perhaps these should be broken into seven separate topics.
I realize the above is opinionated. The author is perfectly within his rights to disagree with any/all of it. Happy to chat over email, if that is a better place than this forum: Cheers

27 Feb 2017, 13:10
David Copeland (491 posts)

Thanks for the interest and the comments. It was really hard deciding on the canonical reader for this book, and in the end I went with someone who knows enough about Rails to basic things and wants to do more with the tools they have.

To address a few of your points:

  1. Rails Experts - the book clearly advertises itself as an expert-level book, though I still feel it doesn’t require that much expertise. Knowing a bit of Rails should be sufficient. The intro says “If you’ve created a simple Rails app, and you know what controllers, models, views, migrations, and tests are, you should have no problem understanding the Rails code.” I stand by that, and have experienced many front-end developers, with no Rails experience, having no trouble editing ERB.
  2. Rails API - That would make much of the book’s code not work at all. Rails API simply removes things from the middleware stack. It is not a microservices framework or anything like that—it’s merely a performance optimization. Making the book’s example app work on top of Rails API would require a fundamental re-think of the auth system since none of it would work without Rails views. That is a ton of complexity for no real benefit, IMO.
  3. Old Version of Angular - The print version will have the latest, but as I wrote the book, point releases of most JS libraries tended to break everything. I’m sure the book’s versions will be out of date as soon as it’s in stores :)
  4. Angular CLI - This has been in alpha or beta since I’ve been writing the book and is only now in RC. We don’t tend to release books about beta versions of software, because things change. I’ve had major breaking functionality added to point releases while writing this, so keeping things working with beta software would be infeasible, and result in a book that doesn’t work when shipped.
  5. TypeScript - we went back and forth on this. Angular has intended to support JavaScript (and Dart), so we felt this was reasonable. Most developers coming to this stack know JavaScript and have a ton to learn already. My hope was that it would make Angular and it’s complex conceptual overload more approachable since you don’t additionally have to learn a new programming language.
  6. Cucumber - This would be yet another thing to have to learn, with really marginal benefits. And, unlike unit tests, cuke-style tests are far from widely adopted. It doesn’t add much to a devs ability to get things done. Personally, I’ve found these sorts of tests to be a nightmare to deal with and grind a team’s testing to a halt at even moderate scale, so I would recommend avoiding them at all costs.
  7. Materialized Views vs. Caching Infrastructure - The idea is that you can get more out of your existing data store and avoid setting up more infrastructure. From the book: “While there may be a case made for caching, Postgres gives more options than your average SQL database to speed up searches, which means we can get a lot more out of a straightforward implementation before complicating our architecture with additional data stores.” It didn’t seem useful to do an analysis of ES or Redis vs Materialized Views. The reader is left with the ability to understand the performance of their code, and a way to do caching without any new code libraries or infrastructure. Much like how Bootstrap is not a replacement for a real designer, I don’t think the reader would expect Postgres to take the place of a high-performance caching system. But you can get a helluva lot farther with it than might be obvious from just the vanilla Rails way of treating a database.

Anyway, appreciate the comments and feedback; hopefully this gives more insight into the decisions I made when choosing what to include vs. exclude—I’m opinionated as well, as you can see :)

28 Feb 2017, 15:22
Laura (47 posts)

I am not qualified to comment but I agree with Craig on a few points. I started learning modern internet technologies about a year ago and liked the first addition very much. With the second edition I realised that I need learn Angular 2 and TypeScript. I don’t really like learning yesterday’s technologies. TypeScript is a very easy language for anyone who knows JS or any other language. Also I did not like Webpack set up using webpack-rails gem.

Replacing the Rails Asset Pipeline with Webpack and Yarn

I noticed that AngularJS is used instead of Angular 2. It is confusing because the authors of the framework stress that AngularJS and Angular (2) are two different frameworks. It would be more correct to replace AngularJS with just Angular.

Overall the book is very good but could be excellent.



01 Mar 2017, 13:37
David Copeland (491 posts)

Thanks for the note about “AngularJS”. The print edition will refer to it as “Angular”.

re: webpack-rails. I did see blog post you cited when setting all this up. The setup in there is pretty brutal. The setup for the book is bad enough, and webpack-rails takes some of that pain away by initializing with a decent webpack config that will also work on production, but without having to teach the reader the ins and outs of webpack.

Typescript is the same - setting that up is another thing that can and will go wrong and break (literally every instruction in this book about JavaScript tooling has been broken at least twice by point releases in transitive dependencies—I feel for people making a living in this ecosystem who don’t even have at least Rails). So, we had to simplify, and TypeScript seemed like a decent cut-point.

06 Mar 2017, 04:35
Craeg Strong (2 posts)

Thanks for such a thoughtful, comprehensive response! Some follow-ups:

  1. Rails Experts - What I meant here was the book is intended for Rails back-end experts rather than JavaScript front-end experts. I don’t claim to be either one, but I am more of a ReactJS and AngularJS expert than I am a Rails expert. Therefore, I found the Rails-centric point of view surprising (and a little bit off-putting). It would be great if there was some sort of language on the back cover and intro that explains this book is intended for the Rails developer who wants to extend themselves to become a full-stack developer and start learning about modern JavaScript frameworks.

  2. Rails API To (somewhat unfairly) paraphrase your response: “I didn’t use Rails API because it would require me to rewrite some of my examples” Yup. From my experience working in NYC and discussing with my buddies at various wall street firms, JWT (JSON web tokens) is becoming a common approach to authentication. But even if cookies are used, there is no reason either approach can’t be implemented perfectly well using Rails API. In fact, I would argue that if you show an example of how this could be done using a JWT approach (new and rapidly-gaining-adoption) it could increase the appeal of the book. There are a number of tools that make developing separate front and backends easier such as the json-server NPM and postman. I personally believe that as adoption of micro-services architecture increases, separation of front-end from back-end and use of technologies such as RailsAPI will increase significantly.

  3. Old Version of Angular Yes, agreed. Working as a JavaScript front-end developer is tough due to the pace of change. However, the rate of progress shows no sign of slowing

  4. AngularCLI “we don’t tend to release books about beta versions of software” I find this statement quite strange. Actually this is precisely why I tend to read books– to learn about cutting edge technology. This quite often requires authors to work with pre-release versions of software. That is one reason why we readers appreciate you authors so much! BTW, I agree with your points about how painful webpack is to configure (largely due to its incredible power and breadth of capabilities) AngularCLI completely hides webpack configuration and supports some very sophisticated conditional loading (only loading rarely-used pages and their dependencies as needed/on-demand) auto-magically with near zero effort. This is cool stuff!

  5. TypeScript OK. I will agree to disagree on this one. I understand your point. I would urge you to rephrase your disclaimer though, since I believe typescript actually makes Angular much easier to use. I came to TypeScript cold with 10 years of JavaScript, but I admit that I have used statically typed languages Java and C# in the past, and that probably helped reduce my learning curve. The main thing is I like how much less code I have to write. I also like how the IDE can auto-complete more often.

  6. Cucumber I concede your point here, this is not a book about Cucumber. I just love the technology! Too bad your experiences have not been good, would love to chat with you offline sometime about that.

  7. Materialized Views I see your point here, and I like the fact that you are leveraging the power of PostgreSQL. It is a great technology. It would be awesome if you could also add an example of using Redis since (from what I understand) it is so commonly used with Rails, but again, I understand you have to cut material somewhere or the book will be 1000 pages long

06 Mar 2017, 13:29
David Copeland (491 posts)

I take your points—writing a book is about making tradeoffs and leveling up as many readers as we can. It’s not always easy.

A few things to follow up on your comments:

  • Rails API/JWT - I don’t think it’s necessarily better to build an app the way you describe. Auth is vastly simpler to implement and get right the way to book does it, if you assume there is no existing SSO-type system to piggy-back on. By doing API-only you complicate your overall application architecture and development process, because you now have two things to manage. This also means that integration testing becomes much more difficult and you have to invent solutions that Rails gives you more or less out of the box. You should argue yourself into a dual-app solution, not out of one. The thesis of the book is how much you can achieve by keeping things simple and working within your existing toolchain.
  • Angular CLI/Beta - The book was written against Angular 2’s beta and RC versions, to target a release when 2.0 was official or soon after. This made the book take longer to write as I had to rewrite the Angular stuff twice due to breaking changes in point releases. We hoped to also target Bootstrap 4, but it’s still in alpha, after almost a year. It’s simply impossible to a) know what tools currently in alpha will actually be embraced and be viable and b) target a release for all of them to be officially released at once. At some point we have to ship the book or it will never be done.
  • Cucumber - just want to renew my point that you should never use cucumber unless forced :)
  • Redis - The main thesis of the Postgres stuff in the book is just how much you can do without standing up new infrastructure (this is the main theme of the book - look what you can do with what you already have set up). It might not be explicit in the book, but each piece of infrastructure you have to manage—even if cloud/Saas based—is a debt and has a higher-than-you-might-think carrying cost. You mention that Redis is “commonly used with Rails”, but this is for background jobs using Sidekiq or Resque, not for caching. Using the same Redis instance for both background jobs and caching is a recipe for disaster, so to use Redis for caching, it doesn’t matter if you have a Redis set up for Sidekiq already—you must still bear the cost of a new piece of infrastructure (not to mention all the code complexity by having to throw our Active Record and roll your own read/write layer to the data store). Certainly materialized views will only get you so far, but they get you way farther than e.g. MySQL, and don’t require you to set up, monitor, and pay for, a new database.
27 Mar 2017, 21:19
Matthew Welke (4 posts)

Hi David,

I just wanted to provide some feedback on Craig’s points from my perspective, that of someone with a good amount of Rails knowledge who wants to add front end frameworks into my work.

For me, the way you’re writing the book is perfect. I don’t want to learn how to make an Angular app connect to a Rails app using API mode only. I don’t want the Angular app to live completely on its own. If I did, I would learn about making a Rails API, and also how to make an Angular app, and then glue them together.

Your book satisfies a nice niche. It explains how to add Angular to an existing Rails app, or how to leverage some of what Rails can do for you to get the best of both world (even if it does involve tighter coupling).

I like the fact that we don’t bother with Redis or Elasticsearch. I would rather learn about those concepts separately and add them in myself if needed. I like that you kept it simple to let the two stars of the book shine - Rails and Angular.

The one thing I do agree with him about is the Typescript thing. I get the idea of using JavaScript to avoid having to learn another programming language. But we’ve seen by now (unfortunately just one month before release date) that Typescript is easy to learn, especially for those who already know JavaScript, and is by far the best-supported language to use with Angular. It often simplifies the use of Angular compared to using JavaScript, meaning any extra effort spent learning Typescript things would likely be offset by the easy of not having to use extra JavaScript things to get it working.

Looking forward to the release. :)

27 Mar 2017, 23:39
Philip John Basile (1 post)

love the book. try to squeeze ng4 in there.

28 Mar 2017, 11:51
David Copeland (491 posts)

Thanks for the comments, I appreciate it.

The book is being updated for Webpacker and Angular 4 (which, despite being two versions new and promising breaking changes, seems to work fine with the book’s code).

28 Apr 2017, 13:51
Jon Guenther (2 posts)

Recovering C#/ASP.NET developer sits back, munches on popcorn, and reads with interest.

You must be logged in to comment