ctroein89

Good error messages are hard. You want to tell the user what to do, but if you knew that the error could be thrown, you probably should have been gracefully handling the problem. You don't know what information is useful to a hacker and you don't know how your error will be propagated. Meaningful errors at one level ("incorrect parameters passed" when calling an API) is perfectly useless at another level ("incorrect parameters passed" when interacting with a React UI). And if you respect all of the above, at some point you'll end up with an error message that basically says "I can't tell you what, why or how something went wrong, but it did."

We still default to Objective-C in our SDK. We still support iOS 11, and I don't think we've been bothered enough by Objective-C to check which versions of Swift can be used on the versions of iOS that we support (I last checked a couple of years ago when we supported iOS 8, where the compatibility matrix was a problem for us). However, the examples are in Swift, and we're using Swift wherever the language doesn't matter. iOS's Objective-C support and Objective-C/Swift interoperability is good enough that there aren't business pressures to switch, and the code isn't changing frequently enough that refactoring to Swift would save us in overall time/effort.

That being said, we are going to refactor from Google's Closure Compiler to TypeScript on the JS side of the project: surprisingly, we've seen more discomfort with developing with Closure Compiler than we've had complaints with developing with Objective-C.

Objective-C is a really neat, old language. Initially I was very gungho about switching to Swift, but all of my pain points are with the Apple APIs that we're accessing (and not Objective-C itself). If Objective-C had dot-syntax for calling methods, some more modern typing, and the less verbose Apple APIs, I would have been very happy sticking to Objective-C.

Twitch should have offered a merchandising business via Amazon. It feels like Twitch should have understood how their streamers make money, and ensure that all of that monetization happens via Amazon in some way shape or form, whether that’s a print-on-demand business or facilitating product placements.

Video is expensive, and streamers don’t like ads.

Amazon has for years been saying that they think that Twitch is under monetized. In their minds, 20% of watch time could be ads, just like regular TV. Streamers don’t like ads: it kills the vibe when your audience gets a 2 minute timeout. So streamers aren’t running enough ad breaks, and try to support themselves via memberships, merch and other alternative monetization methods. And for some, Twitch is only advertising for the real money-maker on another site. So Amazon doesn’t get the ad money they think they should get, and they only get a cut of memberships.

So then it’s a question of how many servers and engineers are needed to support Twitch, because that will determine profitability.

Mechanical ventilation refers to just using fans. The comment you’re replying to is suggesting that heat recovery ventilators (HRV) be used to transfer heat from the warm exhausted to the incoming outside air via a heat exchanger (or cools incoming outside air in hot climates). It reduces the need for heating or cooling while still getting fresh air into the building.

That distance is London to Stockholm by road, which is going to be unfathomably far for most Europeans. Maybe that could be a road trip across the full length of Norway or Sweden, but generally that’s a once-in-a-lifetime multi-country road trip that one will want to enjoy.

I’ve travelled London to Stockholm before, and the only reason to do it is to travel with a family pet. Otherwise flying or taking the train will be faster, and cheaper.

While you are not wrong, those requirements are the same for all houses.

Not every house needs triple-pane windows and R25 insulation in the walls, sitting on a 8-ft deep basement, with a steep roof pitch for snow to slide off of. Generally, you want to cut corners, because building to code in New York would be overkill in Texas.

You could have unique plans for each climate zone, but then the slope of the land and the shape of the lot also matters. Ideally, you'd want to be situated on a southward facing slope, beneath the road, so you could have huge windows towards the back of the house to taking in winter sun, natural insulation from the hill, and smaller windows facing the street. If you can't, you'll have to compromise on something that makes the house less pleasant to live in and/or harder to heat/cool.

At this point, we might actually have 100 distinct home designs, for each climate zone and slope. If you're lucky, these standard might actually be compliant with zoning for your lot, and maximize the allowable use of the lot. Every town is different, and who knows what silly rules your town requires.

At this point, you still need a design that local builders know how to build. Builders talk about "communities of practice", where they know how to build a certain way in response to how all of the other contractors in that area will also build, so that a subcontractor doesn't ruin another subcontractor's work. If you hire builders to build in ways they're not familiar with, they'll make mistakes. Most mistakes will be fine, but they could add up to failing to meet the code or standard for which the house was designed.

Ideally, you want to find an architect and a builder who have worked together before, to design and build the kind of house that you want using the techniques appropriate for that design, with the builder having crews of subcontractors that he/she has worked with before. If you've reached this point, you might as well take the extra step to building the perfect house for you, and customize it just a little more.

I love my DF64. I found it on sale, and informed my wife that it'd be her Christmas and birthday present to me: totally worth it. Even with a $100 DeLonghi EC155, the difference from the grinder is incredible.

Sweden abolished inheritance taxes because the cost of enforcing the tax was greater than the taxes raised, and was passed by a left-wing coalition. At the time, it was considered a success of social democracy to not need inheritance taxes (and in fact, everyone, including the law, referred to dödsskatten - the death tax). 20 years isn’t ready enough time for wealth to consolidate like that via inheritance alone, and similar countries (like Norway and Germany) are seeing similarly rapid raises in their Gini Indexes for wealth, without chances to their inheritance tax systems. Something is broken in Western economies, but unfortunately, inheritance taxes in Sweden aren’t the problem.

Ironically, this tells me some... awkward things about how the author relates to their kitchen.

It also says a lot about how the author relates to restaurants, where a faster dishwasher is a selling point. Faster is separately important from throughput, because if it the takes 3 hours to run the dish washer, that’s a lot of plates that need to be washed and stacked all at once for a restaurant, and a lot of dishwashers needed to handle that volume.

and no build server

Personal experience is that a build server normalizes deviance. "But it works on the build server" we used to say, as, with time, it become harder and harder to build locally. "Just fix your environment!" we used to say, when it was the build system that was actually at fault. "It's all so fragile, just copy what we've done before!" we then said, repeating the mistakes that made the build system so fragile.

Eventually, the build system moved into a Docker image, where the smells where contained. But I'm still trying to refactor the build system to a portable, modern alternative. If we hadn't had a build server, we'd have fixed these core issues earlier and wouldn't have built on such a bad foundation. Devs should be building systems that work locally: the heterogeneity forces better error handling, the limited resources forces designing better scaleability, and most importantly, it prevents "but it works on the build server!".

I have two heat pump window air conditioners installed in my apartment, with cooling, heating and resistance electrical heating: https://www.frigidaire.com/Home-Comfort/Air-Conditioning/Win.... The problem is that the tech is so poorly advertised, that I had to double-check the specs on manufacturer's website that this model was, in fact, a heat pump. Most people don't know that heat pump window units already are an option.

I'd love for NYC to mandate that ACs must function as heat pumps: the additional parts are cheap, and as America's largest market for window AC units, the NYC market would force competition for much cheaper heat pump window units.

For all their faults, Games Workshop is really a miniatures company that has a ruleset, rather than games company that sells plastic models. I recall seeing a statistic that the majority of their customers don’t regularly play, and a shocking number have never played a game. Those customers are buying models because they think the models are neat, and are deriving fun from the act of assembling and painting.

From that perspective, the business is as sustainable as Star Wars or Marvel: as long as this Thor offers a better fantasy than generic Thors, the brand will last (and accumulate the advantages of a deep, lasting history), and therefore will outlast competitors.

It’s reasonable to have tickets that are “is this API interesting to us?” or “how do clients use this new system?” It’s not a “problem”, and there aren’t definite goals. The task is open-ended, and it’s ultimately up to the developer’s judgement to decide that they are done.

To define terms, “the problem” is the issue faced by the client or the customer. The task isn’t the problem. A team should tackle tens or hundreds of tasks while still learning to understand the full problem. This is the motivation behind iterative processes like Scrum.

The author’s message is that if you don’t fulfill all 50 requirements _at all times_, you don’t even deserve to be a software developer (not even a junior). I disagree. I think I get the message that these rules are trying to send, but I think they are, as a whole, unreasonable in a professional, business environment. Everyone should be a product engineer, but being product-focused necessitates speculative activities that exist for no other reason than figuring out the boundaries of the problem being solved. And those activities need to be repeated as the problem is being solved, to evaluate if the problem is correctly understood. Someone, whether that’s a junior or a senior, needs to be spending time doing things that aren’t articulateable so that everyone else can articulate exactly why they are working on their current tasks.

As I become more senior, I’m starting to appreciate all of the tasks that don’t go onto the sprint board and aren’t articulateable. They exist because I need to know enough about Product’s or Account Management’s job to communicate with them, and I won’t know what exactly “complete” is until I’ve reached completion on those tasks. That’s part of the job, and I reject any list of rules that leaves no space for those activities.

1. I can articulate precisely what problem I am trying to solve.

6. I have a Plan B in case my solution to my current problem doesn’t work.

9. I can clearly articulate unknowns and risks associated with my current problem.

These rules imply one of 3 things about the author:

* That author only encounters problems that have been fully solved before

* The manager gives zero weight or value to discovery

* The manager expects the whole project to have been fully specified before starting

Yikes, that's toxic! I think it's important that engineers have the mindset of understanding the problem, but that means that figuring out the problem is part of the work! Which then means that engineers should definitely have periods where they don't understand the problem, where they don't have a Plan B yet, and don't know what the unknowns are, because they can't know what the solution will be until they've started the work.

Drafty houses are not healthy houses: timber needs to be able to dry out to stay rot-and mold-free, but draftiness is associated with weakened immune systems and therefore poorer health. The draftiness rule only holds for older houses constructed before insulation, where the draftiness is needed to counteract the cool, stone/brick basement collecting moisture. A modern house design for insulation should be tight and mechanically ventilated, both for the maintenance of the structure and for human health.

As a cross-platform compatibility layer

We use docker in this way for work, and it’s merely okay. We use docker to bundle the environment (which changes rarely) separate from the code and build system (which changes often). For this, docker has been great for 95% of all our internal users: way more than a makefile helped, but the remaining 5% were a huge pain. The most recent issue was the in-docker user having a different id from the local user, which isn’t a problem on macOS but is on Ubuntu.

At the point where docker made sense as a compatibility layer, it was trivial to convert the whole system into a service running on Kubernetes.

Mind expanding a little on your complaints about Helm? I’ve only used Helm as a templating solution (and even then only to differentiate between local, staging and production), so I’m curious what problems I have to guard against.

The thing is, just like a car can travel on any road a computing device can execute any software. Apple deliberately breaks this functionality.

But in this analogy, the hardware is the road, not the car. The road is the literal platform on which everything else runs. And Apple's argument is that they aren't quite building a "road", they're building a bespoke people-mover system that they continue to maintain (like the Boring Company's Las Vegas tunnel system).

Just to nit-pick the analogy some more, real cars don't run on just any road. Roads have weight limits, height limits, and speed limits (and most places make it illegal to drive significantly slower than surrounding traffic, effectively creating minimum speed limits). John Deere builds golf carts that aren't permitted on highways, and Scania's trucks too heavy for some bridges.

The better analogy here is that if a German band plays a concert in the UK, they still need to pay UK taxes on their ticket sales. Even if the band is incorporated in Germany, the portion of the tour that occurred in the UK is still subject to UK taxes.

Additionally, most European countries permit duty-free sales to foreign citizens in normal stores under the right conditions (often via requiring a passport to be shown at purchase, and via refunding the taxes at airport when leaving the country). This arrangement works because, it's generally required that travelers pay customs on arrival to their home countries on goods purchased abroad anyway. That being said, I've just learnt that the UK has killed their duty-free sales system as of 2021 [1], which is just stupid.

[1] https://www.executivetraveller.com/news/uk-to-axe-duty-free-...

Microsoft and Playstation also allow for cross-platform play

Sony explicitly didn't allow for cross-play until 2 years ago [https://kotaku.com/sony-is-finally-allowing-cross-play-on-th...], even though it was technically possible before then [https://www.engadget.com/2017-06-24-rocket-league-cross-netw...]. In fact, the only reason Sony opened up to cross-play is due to pressure to stay competitive with rival platform Xbox. This was a take-it-or-leave it situation, but Sony was too big to leave. Nothing changed until Sony caved to social pressure.

If the argument is that Apple is a unique kind of device that Apple has a monopoly over, it would hard to argue that Sony and Microsoft don't enjoy the same monopoly powers. On the other hand, if argument is that it's easy enough to switch from Playstation to Xbox, then how is that different from buying a new phone?

In fact, I would bet that Epic sued Apple not because it's more monopolistic, but because they want to set a legal precedent that they can then apply to Playstation, Xbox and Switch, without threatening Epic's core business on consoles.

For carpentry, 12-inches-to-a-foot isn't actually that useful, since wood is never the nominal size. For lumber, nominal sizes are measured assuming that sawing and planing remove no wood, but sawing and planing will remove about 1/4 to 1/2 an inch in each direction. That means that you can't stack two 2x4 to get an exact 4x4, and you can't use dimensional lumber to fill a nominal 1 foot gap without cutting.

Carpentry, both the house-building and furniture making kinds, have adapted by emphasizing tricks to measure lumber without rulers. That means starting with more wood than needed, and cutting down to make pieces fit.

Has anyone actually done that, or are you speculating?

There are videos on YouTube of people using Xbox game streaming, but it requires setting up a VPN at home which presumably few people do.

Edit: with the Stadia launch, I'm currently working on setting up a Raspberry PI as a VPN server to try this myself.

If you are looking for specific games and already have a Switch for portable gaming, I would suggest that you buy an Xbox One S All-Digital Edition during the Black Friday sale, which I've seen announced for $150 [1]. That's on par with Stadia's hardware costs, doesn't need a subscription for single player games, and has a much larger library of games.

[1] https://www.onmsft.com/news/you-can-grab-an-xbox-one-s-all-d...

Remember, for years, Xbox One has allowed for local streaming from Xbox One consoles to Windows 10 PCs via the Xbox app over LAN, which gives Microsoft's Project xCloud the benefits of: * significant experience with the fundamental technology, * no new special hardware required (they can tweak existing Xbox One hardware), * a much larger library of games currently available for download (for consumers who want to switch to a local console), and * an existing Netflix-of-games program via Game Pass (for consumers interested in pure subscriptions)

As-is, Google just happens to be first-to-market in the current generation of on-demand game streaming options. But we've seen this technology before, and I could get the same results with a high quality VPN set-up to connect to a Xbox at home.

It's not the patent system that's causing this, it's a very complex network of regulatory and institutional capture including Medicare, PBMs, insurance companies, insurance regulation, and drug regulation. All other western countries also have patents but don't have the same drug price problems. These problems are showing up even in generic drugs now.

I think this comment comes off as misleading, so I'm going to fill in with knowledge gained from a past career. The regulatory environment didn't create this set-up, and it's not really institutional capture. We've gotten here through the market finding it's own Nash equilibrium.

For the most part, American drug coverage is driven by traditional American employer-based insurance or by insurers who make the majority of their money via employer-based insurance. Medicare provides general drug coverage via Medicare Part D, but Part D is optional for patients, and administered via traditional insurers. For some specialty drugs, Medicare provides drug coverage via medical coverage, but those prices are specifically set based on the average prices paid by commercial insurance. I can't recall how specifically Medicaid handles drug coverage, but it's not a large enough segment of the population to distort the market by itself. Therefore, consider the playbook for a drug manufacturer looking to maximize profits:

The playbook for a drug manufacturer looking to maximize profits in Europe looks like this: * In northern Europe, price your drug based on some value per QALYs as outlined in national regulations * Most of the rest of Europe, assemble a team analyze the bidding and tendering rules and devise a pricing structure around those rules

The relationship between different tendering systems might be complex, because some countries may require that they get the lowest price offered to any of their neighbors, while others are willing to grant complete exclusivity in a class in exchange for more favorable pricing (ie, beating out similar but different competitor drugs). You're going to need a team of specialists to navigate the terrain, but fundamentally the principles are simple.

By comparison, the playbook for a drug manufacturer in the US looks like this: * Raise list prices noticeably * Negotiate with insurers for formulary access in exchange for rebates * Offer co-pay assistance programs for patients * Next year, repeat

List prices are essentially just the starting positions in the US, and are essentially made-up. Insurers will negotiate for rebates, in exchange for not requiring prior authorizations or setting high co-pays or coinsurance. Prior authorizations are generally effective at dissuading doctors from prescribing a certain drug (because it's more paperwork), but the efficacy of prior authorizations goes down as competitor drugs also require prior authorizations (or if there are no competitor drugs). From the manufacturer side, the only way to circumvent prior authorizations would be have pharma reps help fill out that paperwork, but that's illegal for multiple reasons (as I understand it, this one of the crimes that brought down Insys Therapeutics).

Co-pays are generally less effective in dissuading prescribing by doctors. That's because co-pay assistance programs let drug manufacturers cover the patient copays, a) makes the drug manufacturer look good in front of the end consumer, and b) let's the drug manufacturer price discriminate based on patient income after-the-fact. An insurer could choose the nuclear option and ban any drug that has co-pay assistance, but that's a heavy-handed method not popular with patients or employers (especially if the manufacturer structures the co-pay assistance as a separate charity).

Insurers will respond by banding together behind PBMs. The PBM will get a cut of the rebates that they negotiate, so higher prices will make it easier to negotiate with them. Medicare drug coverage is split between being run by traditional health insurers via Medicare Part D (most conventional medications), or having prices set as fixed discount on average prices via Medicare Parts A, B and C (most specialty drugs). Medicaid will be the same way, with a steeper required discount. The drug manufacturer can think about Medicare and Medicaid after thoughts.

Additionally, the drug manufacturer knows that costs will ultimately be passed to employers. While insurers and PBMs need to negotiate for those rebates, they don't need to negotiate that hard since the cost will ultimately be passed onto insurers. As long as the PBMs are negotiating a better deal for insurers than what insurers would have gotten on their own, everyone in the negotiations will be happy with the rebates.

Fundamentally, rising prices are a result of the system being stuck in a Nash equilibrium that's extremely favorable to drug manufacturers that understand the game, which means raising prices.

As a side note, we're starting to get integrated health systems (where the insurer and hospital network are the same company) a side effect of hospital systems consolidating, that can buck this trend. In general, the average working American sticks with the same employer-provided insurance for less than 2 years, since they'll either switch jobs or their employer will shop around for cheaper insurance. Because they tend to dominate specific locales, the integrated health systems tend to stick with patients longer, and therefore have much stronger incentives to find cost effective care for their patients than traditional insurers.

The distinction between Jewish and non-Jewish whites has been contextually important when discussing the history of discrimination in college admissions. The original move towards subjective ranking of applicants was in part a way to limit the number of Jewish applicants: https://www.businessinsider.com/the-ivy-leagues-history-of-d...

I've learnt that for "What you release together, you should version-control together", the phrase "released together" needs to be defined as "what gets globally updated at once". If you provide anything for customers to implement, you cannot update those globally at once (because you need the customer to update), and should think about using a multi-repo set-up.

My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.

Another thought about semver: a bugfix requires only a minor version bump, but IMHO this could also be breaking if people were relying on the buggy behavior. I see the value of semver, but I guess it will always be a too-neat abstraction over something that is inherently too complex to communicate in a simple version string.

I find this approach to versioning and bugs problematic, because public APIs are about the contract with the user. It's hard to work with contracts with undocumented portions. If my API says that the behavior is supposed to be one thing, and in certain cases its different, my obligation is to bring the behavior to be consistent with what my API documentation says it's supposed to do. I feel like any other position would be a slippery slope into arguing that any change in behavior needs to be considered a breaking change, and therefore there's no such thing as a patch version change.