Ugh. Yeah, looks like someone submitted my post over the weekend. A shame, since I know lots of folks who just check HN during the week will miss out on participating.
I don't check HN on the weekends. Didn't know it was frontpaged. As such, I'm gonna just assume that "interesting" was genuine and not sarcastic -- have a good day!
I'd love to hear how you're handling the ECS part of this. From the experimentation I've done, it's not just a matter of telling ECS to update the service unless you're running 2x the number of container instances you need -- it won't pull resources out from the existing service revision in order to spin up the new ones.
Certainly can be worked around, but it's a little annoying.
> If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service, one task at a time. The service scheduler creates a task with the new task definition (provided there is an available container instance to place it on), and after it reaches the RUNNING state, a task that is using the old task definition is drained and stopped. This process continues until all of the desired tasks in your service are using the new task definition.
You're going to get some downtime with #2. I'm not sure about #1 because I don't understand how something like an API service could be run without error'ing out that the port it's trying to bind to and forward is not available. So I'm not sure how it would ever reach the running state.. but I haven't experimented going about it that way. I can handle the small amount of downtime.
Thanks! Yeah, those were the ony options I was aware of, but the "provided there is an available container instance to place it on" issue is a problem due to port availability, and I was looking for zero-downtime deploy options.
This may be nitpicking, but I really liked the marketing material here, aside from this phrase:
"Do you need a way to divide your resources across multiple projects[...]"
It's a pet peeve of mine that so many processes and tools use the phrase "resource" in place of person. It may not have been what was meant by "resources" here, but that's how it reads.
How about:
"Do you need a way to manage multiple projects[...]"
or...
"Do you need a way to divide your time between multiple projects[...]"
I think talking about "resources" is very standard for project planning. I'm a resource at my job and I have no problems with that.
I think that you obviously have to be sensitive of how you use this and context. For example, I once overheard a manager say "my resources are working on it this weekend", which to me betrayed a lack of compassion and dehumanized the team.
That's a really good point. We were trying not to be too sales-pitchy and just get across why we love Matterhorn and how it can help you with your projects. I think the word resource was a bit of misplaced "marketing-speak" that went into the final version. Taking your recommendation on board :)
Really happy to see the 1.0 milestone reached. I've enjoyed my time with Elixir. It's really approachable, and made a lot of Erlang/OTP concepts start to click for me in ways that they just hadn't, before.
Syntactically, it's a pleasure to use as a long-time Ruby guy, which I suppose is no surprise given José's presence in the Ruby community.
However, all of this aside, what makes me the most excited about Elixir is José, himself. It's been my experience that when a language/framework has a BDFL, something of that person gets infused into its community. Anyone who's interacted with José will tell you he's an incredibly friendly, humble, and downright thankful person.
Elixir is set up for success in so many ways, but the community aspect is the one we just can't afford to ignore.
I had some limited experience with Go, and some limited experience with elixir, but I walked away feeling like Elixir is better for making distributed systems. I guess the learning curve for Elixir is way higher if someone has no experience with functional languages, but the benefits are probably greater as well.
If I wanted to quickly prototype some highly concurrent service, I'd probably use Go. If I wanted to engineer something that is incredibly scaleable and fault tolerant, I'd probably use Elixir.
The C-ish-syntax and procedural nature of Go is likely to give it more mindshare in the programming community, however, and that can't be ignored.
There actually are good, obvious reasons to prefer Elixir to Erlang. Syntax is actually significant to productivity. For one quick example, Erlang requires you to terminate statements with either a comma, or a period, depending on whether it's the last statement in the section. If you move code around, you need to go back at the end and fix the commas and periods. Typically, this happens in the form of an error message, which leads to a tedious extra step that happens to me maybe 15 times a day when working with Erlang. That problem doesn't exist in Elixir. There are quite a few other nice things too. Elixir increases productivity in real ways.
Erlang and Elixir play very well together. I imagine Erlang shops "moving to Elixir" will be in the form of Erlang shops hiring people with Ruby experience and letting them use Elixir so they can get up to speed faster.
May be. It also may be that I have a lot less attachment to superficial syntactical similarity than lots of other people seem to -- I see lots of objections to languages not based on substance but based on the lack of familiar superficial structure, and that's not something that's really bothered me (one advantage, perhaps, of having learned -- even if only at a fairly superficial level in some cases -- several languages with radically different syntax in grade school), so "it superficially looks familiar" isn't bypassing, for me, a stumbling block lots of people seem to have.
In any case, yeah, I'm not saying that my personal Erlang vs. Elixir response is anything more than my personal response (or that Elixir isn't valuable; its certainly something I'd like to find time to explore more deeply and I think it has a lot to offer.)
Syntax is the least of your worries when learning a new language. Elixir isn't Ruby. Some new projects may be developed in Elixir but it will never supplant Erlang.
>Some new projects may be developed in Elixir but it will never supplant Erlang.
I vastly prefer Erlang syntax to Elixir's, but IMO it's way too early in the game to say this. In the unlikely event that the people who were attracted to Elixir because they couldn't handle Erlang's syntax can manage to grasp OTP, I imagine that Elixir would ultimately kill Erlang dead. An Erlang that has the same power and expressiveness, runs on the same VM, and is completely compatible - but looks like Algol - would be an irresistible force.
I posted about it then (http://erniemiller.org/2013/06/19/my-happiness-formula-me-js..., but the thought at the time had been that it would be nice if prospective employees published something along the lines of things that contributed to their contentment with work.
This was eventually intended to be presented sans ratings in a little browser plugin, for recruiters and the like to score themselves honestly against the criteria, and a little bit of math would yield a compatibility rating on a click.
It wouldn't take long until such a thing evolved into a more full-featured resume such as this. I like the idea.
This is a promising start. I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.
It still feels a bit DSL-centric from the examples I've seen thus far, and haven't dug into things to see what the generated Ruby looks like -- but if it's anything close to simple, this is something that has a chance to become an important part of the Ruby ecosystem.
If nothing else, it's great to see things like this because they provide concrete example code for discussions that (IMHO) need to happen.
For a while, I thought Sinatra was taking that role? It might be interesting to think about what people are looking for that's neither Sinatra nor Rails, or why Sinatra didn't live up to what people were hoping (if people think that).
Sometimes I think some of this is just utopian grass-is-greener thinking. While there are _many_ things I'd do differently in Rails if I had the choice (some but certainly not all of which the Rails core team probably agrees with, if they had the chance to start over)...
...I think some of the "the thing we need is something _lighter weight_ than Rails" thinking is basically wishful thinking. When you start with something lighter weight, you (being me) generally find you need more than it offers, and then you've got to go finding your own things to do those things, and when these extra third party things end up not as high quality as you'd like, or end up abandoned by their developers, or you end up spending many hours re-inventing a wheel you're sure someone else has already invented.... either the 'lighter thing' ends up gaining weight, or you end up wishing it had.
Doesn't mean I agree with all of Rails choices about what to include, or how to architect it. But I think people under-estimate how challenging it is to hit the sweet spots, as if Rails core team just lacked the will or intelligence or proper understanding or something, none of which I think they lack. Still, certainly alternatives are great, testing grounds for other possible ways of doing things are great, the more different things we see, the better all of our architecting and coding gets, that's the only way to learn.
For any project worth talking about Sinatra is too skinny. Basically you have to hack your routing in about the same way you do with Node's Express, enumerating the bindings between routes and methods. Obviously there are clever ways to do it but you end up reimplementing the resourceful routes of Rails.
Another problem is that you really want to use ActiveRecord to access the database. Anything else it too painful. So you end up creating AR models and you have to manually include them.
Finally there are views. I won't even enter into that.
Soon you end up with a worse engineered Rails. I've been using Sinatra only for serving API requests for small projects. I won't touch it for anything else.
I've built large projects with Sinatra. I've done the same with Rails, many times. The idea that you can't build something substantial with Sinatra is hogwash.
It is not a given that Active Record -- I presume you mean the pattern -- is necessary, but AR is available in Sequel, which is the usual choice of ORM when build with Sinatra. (In addition, Sequel has myriad additional benefits over Rails' ActiveRecord, particularly if you want to use raw SQL.)
Views in Sinatra are not much different to Rails, so whatever issue you have, I'm unclear what they are.
If you end up engineering a worse Rails then, as they say, you are doing it wrong.
As I mentioned, I use both, and you can achieve the same results with either. They are both, in effect, rack stacks these days; they simply have different conventions, one more opinionated than the other.
Sinatra is the perfect REST API server language for a client application. Given the way apps are going these days, I'm not sure why everyone isn't building single-page web apps that put 90% of the responsibility on the client and use only simple JSON communications with the server for persistence or authentication.
One of the problems with always doing things the 'Rails Way' is that people start thinking there are no other ways. Plenty of people build significant apps with rich and engaging interfaces with much lighter frameworks than Sinatra even.
Rails autoloading "just happens". If you're doing explicitly require/require_relative, even on the results of Dir.glob(), the application explicitly specifies what will be loaded, and when. For my part I find that much cleaner.
I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.
This is why I prefer to use Ramaze. It feels more natural if you're already used to coding in Ruby. It also supports the evolution of development from lightweight to complex sites without having to switch frameworks.
Hi all. Arel committer here. This is a very cool application, and I really enjoyed attending (and helping answer questions) at Cameron's RailsConf talk.
That being said, I've become increasingly convinced that constructing queries with Arel is a fun exercise, but ultimately not terribly worthwhile for those of us who are just writing applications.
There are three reasons I can think of that people write their queries with Arel:
1. Construction of queries with a large list of predicates taking advantage of Enumerable#inject and Arel's closure under composition without mucking about manipulating strings.
2. Unease about whether or not code is protected from SQL injections when written using more traditional methods.
3. Achieving database independence.
In the case of #1, there are some situations where this may make sense, as a convenience, however, there are ways to ensure data is properly quoted. Not least of these is using things like prepared statements or the pg gem's "exec_params" method. This means that the goals of #1 and #2 can be met in an arguably more readable way by composing strings and param substitution.
In any case, it's #3 that I regularly hear people advocate as the reason they write their queries in Arel. My problem with that is that database independence is a myth.
Oh, I don't mean that you can't write some subset of queries that will work on any database you like, nor that you can't abstract away some of the differences on the surface of things like limiting result sets, pagination strategies, and so on. In fact, this is where Arel shines and a big part of why it's being used by ActiveRecord in the first place.
But I don't believe it makes much sense for typical app developers to attempt to write their queries in Arel in the attempt to achieve database-independence because most of the things that Arel can do for you in that regard are already exposed at the ActiveRecord level, with possible exception of the case-insensitive matching via ILIKE in PostgreSQL.
I've come to believe that database-independence is something you will only achieve if you aren't doing anything interesting with your database, and you're trying to treat it as a dumb data store. This is what ActiveRecord would prefer you do -- you see this guidance in things like validations, callbacks, and the like. That doesn't mean it's the best of ideas.
Turns out that relational database management systems are really good at managing relational data, and to treat them as a dumb place to store your bits is to miss out on a lot of that power. Along with ORMs has come some degree of learned helplessness when it comes to the harnessing of that power.
So, before you write your next query in Arel, ask yourself whether or not you're really gaining anything by doing so. It's probable that the idea you're trying to express would be more clearly and concisely expressed by showing the SQL you're going to run.
Again, none of this is intended to take away from how cool this app is -- just don't go replacing every single query in your app with Arel equivalents, okay?
If you really must have this, you can get it already with Relation#merge. If you're just referring to using one query as a subquery in another, this is available in ActiveRecord directly without needing to drop to Arel. In fact, unless you're meaning something very different than what I am interpreting, there's nothing Arel's buying you over ActiveRecord::Relation in this regard.
Not the kind of thing I would normally submit to HN, but I think the activity I hope it spurs and its relevance to folks in our industry merited the submission. We'll see if anyone actually agrees.
In fact, that's kinda the point. Each candidate should be evaluated on the unique experience they bring to the table. Trying to create the illusion of a level playing field by standardizing on generic code challenges in interview exercises is just that, an illusion.
