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 :)
It does sound a little off. "M'a t'en crisser une", "M'a t'en calisser une", and "M'a t'en sacrer une" all sound fine. I'd use "tabarnak" to finish the sentence: "M'a t'en crisser une tabarnak!"
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.
Came here to say this. I bumped my head hard on this part of the text - the whole point of using a cliche is that it's immediately understandable. When I come across an incrementing loop that doesn't use a cliche variable like "count" or a function that doesn't return "return" it increases my mental tax. The nice thing about using a variable like "count" or "return" throughout your function is it's immediately intuitive what's going to happen with this variable.
Yep, I started it before that. I'd love to lessen the dependency on Babel/Webpack as much as possible.
I'm still using async/await, ES6 modules and some other more experiment ES-next features, so I think it will be awhile before Babel/Webpack can be completely removed. Of course, I don't really have to use those features. :-)
If the babel/webpack builds happen before deployment to Lambda, I'm not sure it really matters at this point... once we see Node > 7 or so drop, with ES6 module support, it might then be time to consider dropping babel, but it's going to be around a while, and still nicer in a lot of ways than alternatives.
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.
There might be a really clever hash you could build, but it's actually a somewhat complex problem. Finding an overlapping range between two entities is easy... finding it for n-entities is a bit more difficult particularly if you want to do it efficiently. I can imagine a couple of answers.. you can build a lookup table (which makes sense if the time resolution is low enough) and then find gaps in it.
It's actually a pretty good interview question if your going to ask a whiteboard question. It has lots of answers depending on requirements. You can get into parallelizing it for speed. It's more of a practical problem than most and you can implement it basically any language.
Also not on weekends, or outside hours during the week, also not at lunch time, though it may be 'free', also not 5PM, who's paying attention to a meeting then?
(just examples of what i might consider when setting up a meeting manually)
It is still just bitwise if you model the time slots e.g. like one bit stands for 5 or 1 minutes and then look for some contiguous 'free'-block in the result
Okay, how do you find a string of N 1's in a very long bit pattern? What's the space and time complexity of your solution? (hint: you can do a lot better)
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).
