Author: Gary W. Keller, Jay Papasan
I am a bit wary of self-help books as I usually feel I either fully trust them or won't get anything of use (and that some are mere money grabbers). Thankfully, this title is not one of them. It is "only" about focusing your energies, work efforts and even lifestyle one one thing at a time, plus creating a plan to achieve "the one thing" that really drives you, and then proceeding towards that ultimate goal by applying some efficiency techniques.
At around 220 pages, it both contains some really interesting tips, advices and tactics, but also lots of bloating, small stories which sometimes are given a (at least for me) fragile interpretation to adapt to that "one thing seeking" and sometimes multiple paragraphs going in circles around a single concept. It is not bad, and maybe is just that I prefer more condensed information, but my general feeling is that the book could be half the size.
That said, you might fully or partially agree with the topics exposed but I think that there are some good ways of increasing your focus to achieve more.
Just a quick post to remark that this week I gave a talk at Python-Madrid local meetup, and the topic I chose was Python type hints and static typing using MyPy.
Although I explained more in detail most slides, I tried to make them so even without listening to me they carry some understandable content. If anybody is interested on reading them, the direct link is https://slides.kartones.net/027.html (as usual on my slides.kartones.net section).
I wish to repeat the talk again and I even sent it as a proposal for a London Python-related event so fingers crossed :)
Update: This blog post about gradual programming explains very interestingly my point of why Python type hints are interesting as a "gradual typing". I highly recommend you to read it.
Rate Limiting is something that most projects get as a feature late, but that the earlier it comes the better for everyone. Any non-trivial service you use will have rate limits, whenever is a soft limit ("your XXXXX service can only handle Y operations per second on your current pricing tier") or a hard limit ("any table on the database cannot have more than 12k columns per table"), and this is good, because unbounded resources are points of failure. Without restrictions on an HTTP API, you're not only allowing abusive clients to DOS the platform, you're also risking any internal developer mistake to take it down, any big process (like a batch update or a yearly report).
So basically we can agree that every system should have resource limits. There are many different ways to put them in place, but commonly either the software you build (e.g. Python services) will use some component(s) (or implement their own), or use features of the web servers to limit certain type of actions based on some criteria.
Recently at work we wanted to build an internal REST API that would perform small tasks like Google Cloud Tasks (where you queue a task and when dequeued it calls an HTTPS endpoint and you're the one in charge of executing the task on one of the instances behind that hopefully load-balanced URL). To simplify the scenario, let's say we wanted to perform lots of jobs that individually should execute quickly but if massively batched could hurt a database. The best way to avoid problems is making hard for them to happen, so I wanted to put a limit to the amount of requests that the endpoint can receive, so the resources "breathe" enough to never reach too high values.
A good summary of choices regarding rate limit algorithms can be found in the following article: https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm/
For example, to us didn't mattered much if we implemented a fixed or sliding window algorithm, we don't need that much precision, but one aspect was important: It had to be distributed, because the hosts are load balanced and sometimes there are few instances, but other times there are around a dozen, so leaving 2 tasks per second with 12 instances consumes more resources than when having 3 and could cause system instability. We prefered to be more accurate with load/usage predictions, so that ruled out alternatives like implementing rate limiting at Nginx.
Checking Python libraries the main requisites were for the chosen one to be distributed and easy to use (a decorator being the best option). After some digging, the winner was django-rate-limit, which offered:
The library implements one of the two official Redis recommendations of building a rate limiter pattern with INCR so it was good enough and race conditions small enough to not pose an issue.
We already have it working and I even did some quick django tests and confirmed everything works as expected.
As a fun fact, as the library requires Python 3, this was the main reason that I decided to give a try to migrating ticketea.com to Pyton 3.
Today I wrote a new blog post at ticketea's engineering blog, this time about how we migrated ticketea.com to Python 3 in two weeks.
It was an interesting task, and I think went well because "ignorance is bliss", as I hadn't used Python 2 I wasn't biased by fear nor knew the real reach of possible failures, so I just went on, fixing every single error and testing and testing and testing again until all looked fine, and then more tests.
Some libraries already had Python 3 branches (outdated but with quite some work done) and QA helped me so the merit is not mine alone, but I'm quite happy with the result and it is a pleasure to focus on just Python 3.6 (plus now we can start adding type hinting and other fancy stuff).
Fun fact: All of this originated with the desire to add rate limiting to a new (internal) API I was building. I will actually write here a small blog post about rate limits because I found two very good links with nice explanations and I think can be of use for others in search of similar features.
Apart from hearing podcasts frequently (e.g. commuting to work), reading books and lots of RSS and articles (it is hard to take out the FOMO anxiety, but I'm now below 100 feeds), I discovered a while ago that subscribing to some weekly newsletters provides me with nice summaries of topics in different areas. I might read all the articles, or maybe just give a quick glance of what's new.
At the time of writing this blog post, I'm subscribed to the following newsletters related with tech:
I'm open to suggestions of additional (tech) sources so feel free to drop me a comment ;)