vchynarov
The US is a difficult and long process to get a green card. Other English-speaking countries aren’t necessarily better: Australia seems similar in terms of being a natural resource extraction economy with insanely high real estate prices. Same productivity and salary concerns with the UK.
We had a different problem, where our monolithic app used both Postgres / Redis for different use cases and worked relatively well. However - it was a lot easier to shove new functionality in the shared Redis cluster. Because Redis is single-threaded, one inconsiderate feature that does bulk reads (100K+ keys) may start to slow down other things. One of the guidelines I proposed was that Redis is really good when we're reading/writing a key, or small fixed-cardinality set of keys at a time, because we have a lot of random things using Redis (things like locks and rate limits on popular endpoints, etc).
However, in your case, I'm guessing Redis shines in the case of a naive single-key (IP address) lookup, but also doesn't do well with more complicated reads (representing your range query representation?). Cool write up overall, I don't have a deeper understanding of how SQLite performs so well when compared to a local Redis instance, so that was unexpected and interesting to observe.
Many popular podcasts just have guests who are obviously trying to promote a new Netflix special or book.
He stutters and the outcome isn’t that polished but if you can adapt to that his podcast feels very authentic.
I remember reading most of the book and skipping a couple of chapters. While the results and ideas are great, I feel most of the chapter is the historical background, Ie “Tversky and I were doing this in the 60s …” It could be heavily reduced and still get the point across.
IE let's say you have a graph question that requires either BFS and DFS. You're a competent engineer who both recognizes the applicable algorithm and could reasonably implement it from scratch.
Some problems then have additional constraints such as adding bounds-checking (if searching inside some sort of "map") and checking visited nodes. The engineers who've grinded leetcode have muscle memory ready to regurgitate code for those conditions.
Competent engineers are able recognize these and implement them, but that lack of muscle memory wastes vital time for the interview. (Yes, those seconds are never a real constraint in the day-to-day).
I made a dedicated Twitter account to track the progress of this petition: https://twitter.com/norussiancloud
My petition requests US political and cloud business leaders to remove their services from the Russian market.
The following is a non-exhaustive list of which companies I'd like to stop offering services to Russia: - AWS, Microsoft Azure, Google Cloud Platform - IBM Cloud, Oracle, Rackspace - Cloudflare, Akamai, Fastly - Cisco, Juniper, F5, Palo Alto Networks
Today I just want to get at least 100 signature on the petition.
Starting next week, I'll reach out to my network to find people who work at these companies to share this message with leadership.
Posts and work groups are actually a generally good way for scalable work communication - and leaving a public and searchable record. This doesn't replace Google docs and wikis, but serve as another layer to organize them. (I promise this doesn't lead to needless bureaucracy, that still happens but not because of Workplace).
I'm currently putting together a design document (very simple system and still high-level) to ensure my idea is communicated concisely and unambiguously.
The main motivation is I'll have a refined reference to point people to so I don't have to worry about repeating context to all possible stakeholders.
"The Lies of Locke Lamora"
I found this book because I just finished playing Dishonored 2 and I wanted to read a book with a dystopian steampunk alternative-Victorian vibe.
The events take place in a gritty, corrupt city of waterways and canals controlled by different factions. The factions represent either the legitimate nobility or the extensive underground criminal empire. A charismatic leader of a small young group of thieves and pickpockets comes up with an epic, layered con that will break sacred agreements and make him enemies with everyone - and pulls it off.
I dedicate a few days a month to being absolutely phone-free. The key point is I'm allowed to use Reddit/IG but I have to use a laptop/desktop to access them. This method requires a key ingredient: three ziploc bags.
I wrap both my work phone (when not oncall) and my personal phone in three nested ziploc bags and put them in a drawer. This acts as a great deterrent most of the time.
I've started doing this on/off since last December. Each month I aim to have at least like 6+ completely phone free days. This isn't to say I still don't have bad days where I'm completely addicted to my phone, but overall I feel so much better with this habit.
My therapist who deals with other software engineers has mentioned me as a positive case study for people with similar problems :)
Anecdotal data point: For a while, AT&T had an North-America wide plan for $~40/45 for month with 10G LTE with the rest being 3G. I kept this in Canada because there would be nothing close to this there - it was cheaper to use the American service.
I've always used my own phone with prepaid plans and the cheapest plans in Canada are awful compared to the cheapest plans in the USA. I also lived in the GTA, not some remote village.
Are you seriously comparing SF living to Waterloo living? There's a reason it's 1/4 the price. It's a running joke between every single undergraduate student with significant experience in SF that we want to get out of Waterloo.
LRT opening up? That's a joke. How exactly is the LRT going to help the startup scene?
Trump is well-known for being extremely against NAFTA.
However, if you intend this as an argument against general software project management, I must disagree. (See: "He introduced us to ‘Jira’, a word that strikes fear into the soul of a developer.")
Lately I've had the opportunity to work at a place with very forward-thinking, progressive, and helpful PMs and generally good organizational structure.
I like our approach and here is why:
* We are not afraid to change things. This might lead to some temporary disagreements between technical leads and PMS, but EVERYONE in the team has transparency into the process, and an opportunity to voice an opinion.
* We taking scoring tickets very seriously. I've been at places where everyone on a team might vote on a ticket, even if they cannot appreciate the true scope of it. Here it's different. For instance, we have seen that in the last couple of weeks, our velocity was unusually high. This might indicate we are scoring tickets too highly, and from what I've seen of my own work, I'm inclined to agree.
I've had a length interview with a PM who spent some time afterwards telling me about his metholodogies (I gladly listened.) When given the choice between Gantt charts which have cliffs (indicating poor future planning and rushing to get things done last minute) and nice step-ladder charts, we see why PMs prefer things the way they do.
Sometimes it gets in the way of just writing code sure. But with good organizational structure, especially in a mid-size company that has upcoming deadlines and business features to ship, we identify priorities quickly while still being aware of things like reducing code debt.
This is (Canadian) RBC - Direct Investing.
In addition this particular fund also significantly outperformed other ETFs during 2008-09.