I can see the value where you would need to fire email alerts from different parts of your stack, and have a central place to control and config them.
What happens next, for example, when you need to send alerts from frontend events? Or from other non-Rails parts? Duplicate code and logic?
Every email client in the world except Gmail (yes, including Outlook) supports, to some extent, CSS in tags in the head section of HTML emails. Gmail is the only client in the world that does not, and only supports inline CSS.
As such, while being a very popular client both on the Web and on Android devices, Gmail forces anyone who wants to send HTML emails to try and find workarounds, in order for emails they send to look good across all clients and devices. In effect though, there's no real solution for sending an email that looks good across all devices, while not resorting to very small-fixed-width emails, if you wish them to look good (and then making them not look good on big screens, Web and desktop clients).
And while other clients have their quirks (like Outlook using Word rendering engine), almost everything is possible to achieve with them, including responsive HTML email designs, because they support CSS in the head section of the HTML. Just as a comparison, iOS supports CSS to a maximum degree, including media queries, a fact which makes email templates easy to code and handle, and brilliant to view across iOS devices.
I hereby call upon Google to get with the program, and start supporting non-inlined CSS in emails. If AOL and Yahoo can do it, you can too.
I think the discussion comes down to which option you ultimately prefer -- 1) be in full control of your stack, having only yourself to criticize, and having to deal with all the devops action that comes with it, or 2) let heroku deal with the underlying while you focus on your app, as their promise suggests, and suffer (also financially) from time to time due to faults like this.
Everyone has their own reasoning on this decision, and that's ok. I think that the voices here saying "I won't start my project on heroku because of this" are not thinking this through. I think that for any project starting up, focusing on app rather than infrastructure is much more important than routing issues.
I'm not bashing them, I'm only saying it merely shows that although event/action tracking is a great approach, "traditional" traffic analytics are still needed.
I'm not a rubyist, and I can see how this can be nice for ruby developers, but IMHO, if you need javascript - use javascript.
Why add another layer of complexity and error proneness?
What happens when a different js programmer needs to review your code? Or when you need to write some Node.js code and forgot all about syntax?
"The main motive is to have a decent standard library for JavaScript" - jQuery works just fine.
Clearly jQuery isn't providing a lot of the things they are looking for in a standard library, as it is focussed on DOM manipulation and Ruby.js attempts to provide core types like Enumerables and Time.
I've never considered jQuery as a standard library, more of an interface for the DOM, especially considering that 99% of it is at most 2 steps away from the DOM.
Prototype, Underscore, jQuery, Coffescript, .... RubyJS - nobody love pure JS, when you've got a chance to write nice code(short and descriptive) - why don't use this ability? And about "different js programmer needs to review your code" - if you don't know smth then you need to study it. That's a fundament of programming world(probably not only programming))
Untrue. The ES5 standard contains most of the features required for any application (my main issue being the Date prototype which could easily be improved).
jQuery, Prototype and afaik Underscore helper functions have been wrote when the standard wasn't ready. Now that it is, developers should start using them.
This is js, just extended with some extra functionality. No different than jquery, underscore, etc. I don't see any reason for the harsh criticism, remember js is a very dynamic language that's in constant flux... We're not coding in C here.
Actually, even without jQuery, the native library for strings, arrays and numbers is usually more than enough. I might have needed something like `capitalize()` once or twice but would probably not include a whole library just for that.
Agree to disagree. The JS native library is incredibly rudimentary by "modern" standards. Even something as basic as comparing two arrays requires either hand rolling a solution or reaching out to a separate library.
A thousand times this. Javascript as a modern language for non-web things is not mature at all. The amount of date/time, string, and hash utility functions that JS simply does not have is staggering.
From what I have read today, the current poker bot programs do a lot of work in advance, and just follow decision trees when to raise, call and fold along that tree. They already know how they will bet with J10 suited before the flop when they are the first to act before the game starts.
The real challenge is the number of permutations of that, which raise memory requirements into the petabytes range. Not to mention multi-player games, and the no-limit version where betting gets more complex.
Not sure if having high-cpu instances at your disposal helps during game play.
