Smudge

only once pushed or merged to a shared branch.

I'm no fan of the system we have, and I agree that it's dysfunctional at best, but my view is that the only thing worse than a two-party system is a single-party system. All of the problems we have with the power structure of the current US system would only be amplified if one party gains full, long-term control of the federal government.

Assuming that there continues to be a system in which I can personally operate, I'm hoping to focus my efforts around promoting positive electoral reform ideas in whatever increments can be gained. Things like ranked-choice voting, campaign finance reform, fair representation laws to counter gerrymandering, etc. My dream would be to see the (de-facto) two-party system turn into a (functioning) multi-party system within my lifetime, with a greater number of smaller parties, better-representing those who voted for them, and who must form coalitions with other parties rather than enacting change unilaterally in winner-take-all scenarios.

Of course, for any of that to work, we need a media environment that isn't constantly amplifying the extremes, and a general populace that is more resilient to extreme forms of propaganda, radicalization, and manipulation.

The ever-widening political divide, which I have observed both in the abstract and in family/friend relationships, is something that I could easily see spelling the end of US democracy. I'm dead serious, and this (well-reasoned) post does nothing to ease my concerns.

I have been particularly anxious about one bit also mentioned in this post -- the upcoming Moore v. Harper ruling that the Supreme Court has added to their docket. It seems that the court's intent is to legitimize the "independent state legislature" theory, which would give state legislatures unchecked power to control the process (and, in turn, the outcomes) of their states' federal elections.

And by unchecked I mean exactly that. It relies on some ambiguous wording in the federal constitution (and interprets it to imply the word "only" where that word is not actually present) to bar state courts from having a say over any of the state legislature's election laws, and it would bar the state's governors from vetoing any such laws. In effect, if a state legislature decides to overrule their state's federal election outcome and appoint their own electors, etc, it would be perfectly legal and entirely un-challengeable for them to do so.

This, in effect, means that US democracy, at least in federal elections (this fringe legal theory does not apply to state laws dictating state elections), will have failed. It doesn't matter who you support - without free and fair elections, there is no democracy. (And of course, the winning side will just say "but there was fraud," and when that fails to be proven they can fall back on, "but actually we're a republic, not a democracy," and rely on their highly-polarized-and-then-gerrymandered states to continue backing them, because hey, we'd rather have single party rule than by ruled by the other side, right?)

I hope I'm wrong, but I suspect that 2020 was the last time that we'll have even a semblance of a free and fair presidential election, at least for a generation or two. From here out, I expect to see the winning party continue to dismantle the engine of whatever remaining democratic processes stand in the way of being able to reap the rewards of controlling all three branches of federal government. Though I suspect they'd rather burn most of it down and keep only the parts that allow them to tighten their hold on power at the state level.

I wish I could see a way out of this crisis. But all I see is the smokescreen of a culture war that distracts everyone from what's really at stake.

You missed the part about regulating.

The point isn't to create a drug free-for-all, it's to reduce the economic incentives that lead to drug cartels.

I made a CLI for controlling macOS's "Night Shift" feature programmatically. It also doubles as a Rust library.

https://github.com/smudge/nightlight

Now I'm working on cross-system compatibility with equivalent features on Windows and Linux.

Having a "brutalist" aesthetic is called out in its README as part of the design philosophy.

Brutalist is a bit of an acquired taste. There are at least a couple different schools of brutalism (this one seems to line up with more of a 90s web aesthetic), but I like to think of it as a kind of intentional ugliness that allows designers to emphasize practicality. You're there to participate in the content, not the pretty boxes around the content. (I dunno if I'm explaining it well or not.)

Well said, and I'm sorry you had to deal with such a heartless reply.

Doesn't really answer your questions, but I'd point out that it's possible that we only hear about these suicides precisely _because_ they are from professions that tend to produce high-profile celebrities. I'd counter your apparent correlation with the fact that apparently suicide among doctors is extremely high:

https://www.washingtonpost.com/national/health-science/what-...

When modeling was done for the Kuwait oil fires, there were two opposing expectations. One was that the fires would cause a kind of "year without a summer" similar to the Tambora eruption in 1815. The other was that the smoke would affect local weather conditions and be rained out within a week. In retrospect, we know that the latter proved most accurate.

But from what I understand, the crucial difference between the two models was how high the smoke would go, and as such the gap between the two models is actually a lot closer than the outcomes would imply. Had the conditions (weather, geography, etc) been ripe for more "self-lofting" of particulates, far more of them may have made it as far as the stratosphere, at which point they would stay in the atmosphere for far longer and would spread much further, without any weather patterns at that altitude to accelerate their return to the surface.

Worth noting that Teller was one of the inspirations for Dr. Strangelove.

Most forest fires don't create strong enough firestorms (if they do at all) to funnel material high enough to have an effect -- most of the ash falls back down in a matter of weeks (even sooner if it gets rained out of the atmosphere). I'd compare nuclear blast firestorms with volcanic eruptions -- we do have a record of eruptions funneling material high enough into the troposphere and stratosphere to have a noticeable, longer-term effect on the climate (over the subsequent months and years).

Most tests have been performed underground. And for an above-ground test to cause anything close to a nuclear winter, you need a lot more material than the bomb itself and the soil beneath it. Tons and tons of debris would need to be shot up into the atmosphere.

So, the theory of nuclear winter depends on bombs detonating over cities and forests, causing massive amounts of debris, and also inducing firestorms that would act as chimneys for even more smoke and particles to be funneled up into the troposphere and stratosphere.

Email is just one example, but maybe a better example is talking to an API that supports some form of idempotency. You don't want to talk to the API during a transaction that involves other related data persistence, but you can transactionally store the intent to talk to that API (i.e. you insert a job into a queue, and that job will eventually do the API interaction). But even in the email case, you can benefit from a transaction:

1) Open a transaction

2) Persist some business/app data

3) Persist a job into your queue that will send an email relating to #2

4) Close transaction

So you've at least transactionally stored the data changes and the intent to send an email. When actually sending the email you probably want something that guarantees at-most-once delivery with some form of cleanup in the failure states (it's a bit more work, as you said).

Nice -- pg-amqp-bridge seems like a clever solution for coordinating the two. It still puts some amount of the queuing load on the DB, but I'd be comfortable with that trade-off if I really wanted to use rabbitmq as the primary queue.

Question though -- Does it guarantee at-least-once or at-most-once on the NOTIFY? (Like, if there is a network blip, will it retry the NOTIFY?) And if it is at-least-once, I assume that consumer apps will have to handle deduplication/idempotency.

Very common in the web context -- you perform some form of relational persistence while also inserting a job to schedule background work (like sending an email). Having those both in the same transaction gets rid of a lot of tricky failure cases.

Firstly, time spent learning is not time wasted!

Secondly, the best way to avoid making painful design decisions is... to make them enough times that you instinctively remember them. There aren't many shortcuts to developing that instinct, so take this opportunity to try and generalize your learnings -- what do you recognize now that you didn't see when you started the project? A healthy amount of retrospection will make you a better engineer, and you'll also get better at identifying uncertainties and risks before you start coding.

Lastly, up-front planning and design documents can only get you so far. They're important, sure, but at some point you'll be down in the nitty gritty details, and you'll need to make unanticipated course corrections. As you gain experience you'll start being able to fill in more of those gaps on your own, but until then, you'll want to loop in other engineers more frequently.

One of the qualities of a senior engineer is that they act as a force multiplier for their team. So as a relatively junior engineer, don't be afraid to make use of your senior engineers! They should be there to support you and make you better, beyond just helping you plan out a project. If possible, pair on some of the trickier parts with them, so that you can see how they'd approach the problem and start picking up on things that might not seem so obvious to you right now.

Hope that helps!

There is a much bigger barrier to entry when it comes to monetizing via product placement and sponsorships. For smaller entities, developing dedicated advertising partnerships is just not on the table.

So if the the ad networks themselves truly are the problem (and as a result adblocking is ever on the rise), it sounds like there is an opportunity for a better, more "organic" solution accessible to the long tail of smaller sites looking for monetization options. Sounds like a tricky nut to crack, as I'm sure anyone who works in the industry would tell me.

The book How Not to Be Wrong: The Power of Mathematical Thinking[1] by Jordan Ellenberg has a segment on this with similar examples (minus the programming bits), tying it in to human psychology and, with surprising insight, the behavior of slime molds. Would definitely recommend reading if you find these kinds of topics interesting.

[1] http://amzn.to/2kHiROT

Hospital-acquired infections have become incredibly common. My grandmother caught a C diff infection after what had already been a very arduous treatment and recovery, and she received basically no support from the hospital that had effectively given her the infection.

Curious about the first one -- was there some kind of conflict of interest? As far as I can tell all you were doing was taking public information already available on the page and disclosing it with a much more visible banner. Was your employer heavily involved in Native Advertising campaigns or something?

Immutable data is very easily shared.

Intuitively the solution kind of makes sense.

M must always be the highest point within the range. A and Z are at the same height and are the lowest point within the range.

Imagine that the hikers are somehow connected (quantum entanglement, etc) such that one cannot physically move up or down if other cannot, and as one moves up and down the other must follow at the same height.

Perhaps a better metaphor would be if the paths are cut into a wall, and you have inserted two pegs that are connected by a horizontal backing bar behind the wall. The bar may move up and down but will always remain horizontal. The pegs can slide left and right along the bar, and up and down along the paths, but must always remain horizontally level.

Now, imagine that whenever a peg reaches a local max or min (peak or valley), a change in vertical direction may also cause a traversal along the opposite size of the peak/valley, thus allowing for forward progression.

While one peg hits a vertical stop and makes horizontal progression, the other peg will simply move up and down along the same segment.

This exercise is obviously not a mathematical proof, but does serve to make the proof feel a bit more intuitive. I'd love to construct such a "puzzle" myself and try it out on a bunch of different contours/tracks.

I think the operating word is "some," not all. We know that UBI will sometimes be misspent. Most if not all aid programs have this problem. That doesn't mean it isn't worth it for those who would put the money to good use.

Basic income doesn't always solve this for someone who is already homeless, but it might still act as a preventative measure, giving someone enough of a financial buffer to avoid homelessness entirely.

Solving deployment is orthogonal to organizing your code. You can deploy multiple products which share the same codebase, and you can also deploy one product which draws from multiple codebases (say, from other gems or npm packages that you also maintain). Regardless of where your code goes, handling distributed releases generally requires agreed upon contracts (e.g. schemas) and proper dependency management during rollouts.

Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented.

Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.

Developers come in many different forms, and I think this kind of "high performer" can be most valuable in an early-stage startup environment, where code quality hardly matters if product-market fit cannot be discovered before the runway ends.

I also suspect that many of these "high performers" are very aware of the technical debt they are adding, and simply prioritize shipping over anything else. To them, the mess is just a fact of software development, to be cleaned up only as can be justified by the needs of the business.

In general I don't actually agree with this view, but I also try not to dismiss it outright. (My counterargument usually involves the fact that technical debt will slow you down in the mid-to-long term, so if there is any expectation of keeping code around, it actually saves the business money to invest up front in code quality.)

Perhaps, with the right kinds of expectations and code review processes, many of the "high performers" to which he refers end up becoming the "low performers" that you see as the cause of most technical debt. People who, in one environment, are able to ship buggy code quickly (and without much consideration) find themselves, in a different environment, spending abnormal amounts of time writing and reworking code in order to get it through a code review process.

He kind of mentions it, but in a very early-stage startup, the ability to deliver MVPs quickly (regardless of code quality) may be seen as a positive trait. Of course, even better is when you can ship quality code just as quickly, but such developers are probably the exception to the rule.

I generally see two reactions to the "one codebase to rule them all" approach (used by Facebook, Google, et. al):

1. Holy god why would you let your code grow to such a massive, interdependent scale? Just release everything separately and versioned so that breaking changes don't affect everyone all at once. The idea of git being a bottleneck is absurd and you are using it wrong.

2. This is a very reasonable, practical approach to sharing code across a company. It reduces siloing and ensures that major refactors can happen in one pass without a ton of coordination. Better to fix the version control system than waste endless resources refactoring millions of lines of code.

Both reaction is valid. Having worked in both styles of codebase, I recognize that there are trade-offs in either case. The optimal solution depends on the project and the team.

Sometimes the path of least resistance--that is to say, the path to getting things shipped and, in turn, making money--is to let the codebase grow organically and worry about cleaning up any messy interdependencies later, once you have a better idea of what code you even need to keep around. In this scenario, it's important to recognize that developer efficiency is going to be an uphill battle in the long run, but if you are proactive about maintenance and tooling improvements then this approach can still be relatively painless.

Other times, especially when you're working on a tried-and-tested product with a clear API and a dedicated team, it can be productive to split it out and let the team manage their own versioning and releases. This becomes especially useful if the product is open source. (For instance, I wonder how Facebook manages its open source releases relative to its shared Mercurial codebase.) In this scenario, developer efficiency is usually less of a problem, as proper use of versioning can ensure faster, more agile updates to each product. But the downside is that your company as a whole can end up in a kind of versioning hell, where every project depends on a different version of every other project, and keeping everything up to date can require a huge amount of coordination.

So, in the end, pick your poison. My reaction, years ago, was more along the lines of #1, but I used to be much more of an idealist earlier in my career.

Seems useful (albeit tongue-in-cheek), but will have to keep my eye on this just in case:

http://isdeadyet.deadyet.lol/

;-)