Agreed, I'm quite sensitive to the scrollbar size when I land on a new article, and in this case I almost closed the window, thinking this would take the whole day to read :)
Also agreed. I will use single-letter variables like "c" or "x" occasionally for lambdas or anonymous functions, but that's about it. "lambda x: not x" in python - anything longer I think should be descriptive.
Agreed with you. Perhaps if you're using temp or tmp, something could be done better, but I see no harm in using the others. If you're counting things, a variable named "count" sound perfectly reasonable to me.
Interesting. Had a google interview not too long ago, and this was exactly the question asked to me - how would you design an algorithm to find overlapping free time from person X, Y and Z. I guess they got more practical with their questions over the years.
Great realization. I'm in a similar boat. On the upside, 30 is still quite young, there's lots of time to do other stuff and slow things down ever more.
Montreal is not known for its tech scene. Scrolling through this page, I can immediately identify:
- the "startups" that are a 1-guy team doing "disruptive-PASS-agile-SCRUM" consulting
- large, partially government-backed monsters where money is burnt and not much is produced
- the students who just built their first social photo-sharing app, wondering why they can't find any funding
I've heard of them from others or was offered jobs there - there isn't a lot to choose from around here. Salaries are low as the city is cheap. There are also good companies in that list (some great ones even), but I'd say it's pretty inflated.
I work remote for a US company with its headquarters in Europe, it's the best arrangement possible, I'd recommend it for others (paid USD, half-day overlap with coworkers = lots of time for quiet coding, trips to Europe often to catch up with team).
I used to try and reason with ES settings on production, for about a year or two. Something would invariably break, unless you spend time with it every day, checking configurations and monitoring performance.
We use the AWS ElasticSearch service, and while it does not provide the same flexibility, it's been fantastic for us. No configuration files, no weird restart behaviour, no thread pool madness - it just runs. You can upgrade your instance sizes seamlessly and it integrates well with other AWS parts (ex: cloudwatch).
> My ground rule is that anything I easy_install will go into env, and env will quite often be (re)built on a separate machine that matches my target environment. So I treat it as a disposable folder, and it’s never committed to any repos.
Was wondering, do you pip freeze > requirements.txt? I don't see the file in there, but I assume that's what you mean since you mention that none of the env folders make it into version control.
On a semi-related note, I used to have tons of projects like this a year ago, and having moved most of our python code to AWS lambda, our repos have shrank to maybe 25% of their original size. Granted it's not fabulous if you need to run a JS app on top of your Bottle framework, but we used to have a lot of small services here and there, the provisioning and deployment was so much work.
This is an unfortunate title for this post. AWS released API Gateway sometime last year, and this makes it sound like a caching layer behind API Gateway, to access S3 files.
Unfortunately it seems like the argument is mainly semantic then - I find it reasonable to think that "pedantically instructs the programmer how to properly do what’s requested, even though it obviously know what is meant" is pretty much a detour to say it's not good, it's implied.
I just don't see why DHH needs to do this - ruby has so many things that make it stand on its own.
Did you read the quote? He very exactly says that python is bad in comparison - by using a concrete python vs ruby example.
If this was a passing mention on some blog post, I'd be inclined to believe you, but this post is not like any other. It's a descriptive update of the current rails "doctrine". When I ask you "why is your X so great" and you tell me immediately "look at how bad Y does", I'm inclined to think you're not feeling very secure about X.
This is easily described with a contrast to Python. [...] Ruby accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously know what is meant (since it’s displaying the error message).
When you're trying to convince me that your programming language is great because another one is so much shitter in comparison, you're on the defensive and basically telling me you don't trust your own stuff. Especially when this is at the top of your article.
By the way, python handles your example very gracefully in comparison to other REPLs (for instance, node spits out a cryptic, but expected traceback on exit/quit)
Living in Montréal, I'm happy to see this article. The highways / traffic situation is horrible here, but I will point to one example in particular.
Getting to the airport: there is no way to get to the airport easily. There is a dedicated bus line that might get stuck in traffic for 10$, or you pay 35$ for Uber, or 50$ for a normal cab (which also might both get stuck in traffic). You need to plan at least 2 hours from your house to get there, often 3 hours in advance for your flight. I've taken the bus dozens of time, and you can see the faces of the poor passengers, realizing they thought 1h to get 20KM away would be enough.
I go back and forth to Amsterdam and the difference is embarrassing. I get to Schiphol, hop on a train (every 5 mins), it costs 5 euros and I'm at Central Station in 15 minutes.
Not sure how "not liking something" equates getting things wrong, but I agree with most of what the author mentioned.
Using 'x' or 's' for a short lambda makes no difference. 's' could be anything, like 'x'. Unless you're specifically using django, there's no point in renaming _. Agreed with you on the argument lists and exceptions.
Great point. Also, the pipeline you mention removes many risks related to the 'common' mistakes mentioned in the article (scaling, monitoring, provisioning it all done for you - or almost).
We're using gateway -> lambda -> dynamodb, and there are a tons of gotchas and small things that AWS need to iron out, especially with gateway -> lambda.