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!
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.
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.
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.
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[...]"
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 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.
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.
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?
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.
I did, and that's what I found bothersome. He clearly seized on the "I am special" header and then interpreted the C-level exec comment in terms of that, when the whole point of the "I am special" part was that I'm not. Or, at least, that everyone is unique.
I may have responded harshly, but certainly in kind.
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.
Did you actually read the article, or just the big, bold letters? The point wasn't that I am special. It's that each person is an individual, and a company that doesn't recognize that situations differ and make reasonable accommodations is unlikely to be a company at which I (or many like me, if the comments are any indicator) would enjoy working.
I might write more on the subject at a later time. For now, I'm a bit more (hopefully understandably so) focused on lining up discussions about what's next. :)
Thanks. I find the need to support my family the reason I must push for a great job. I want to both provide the best I can for them, and also to love what I do, so I still have energy left to invest in them at the end of my day.