languagehacker

I'd be curious whether there's any security concerns on this one. Could an attacker craft a message that gets access to execute commands into a client terminal?

First thing I tried was `apt-get install emacs` and it hung on downloading. Editor preferences aside, I assume any nonstandard package will have the same problem. Interesting idea, but apart from trivial glue you may not need more than a container or unikernel for anyway, I'm struggling to understand a practical use case.

The dude who made LyricWiki basically had a successful acquisition to Wikia, which is great because the legal trouble that wiki had was needless and profligate. This is one case where the creator had the best outcomes by parting ways with his creation.

I worked there when it was Wikia. I'm disappointed that the APIs have been hobbled, that the name became something so honestly lame, and that you can't even view images with mobile ad blocking on. It really is about moats and enshittification, which is sad because the communities put a lot of hard work into their content.

I don't think mocking is an anti-pattern. Using only unit tests and then mocking everything probably is.

Mocks have a perfectly viable place in testing. They help establish boundaries and avoid side effects that are not pertinent to the logic being tested.

I would reference the testing pyramid when thinking about where to be spending time in unit tests vs. integration tests vs. end to end tests. What introduces risk is if we're mocking behaviors that aren't being tested further up the pyramid.

I listened to the audiobook, and Paved Paradise covers most of the arguments made far more succinctly.

I just read Paved Paradise as well as The High Cost of Free Parking. This seems like the current gradual trend towards reversing the hidden subsidy for drivers, first by giving them less affordances at remarkably low prices or for free.

A few folks in the comments have mentioned a couple of times that it doesn't make sense to make a policy like this without supporting transit. I believe the argument would be that not creating induced demand will provide market effects to encourage the use of transit, which would then create greater demand for improved transit.

Similarly for housing, the well substantiated claim from modern urban planners is that we've been prioritizing housing for cars well beyond housing for people, and the best solution for that is to overturn minimum parking requirements and unbundle the cost of parking from the cost of housing.

Personally, I still find these opinions somewhat counterintuitive. The weirdest part about it is that it all posits that the solution to a centralized planning problem is market solutions, and it's coming from people you'd expect to have the opposite opinion. However, what we've had in terms of transportation clearly doesn't work for people and for the environment, and the last 20 years of "Shoupism" has shown some serious promise in terms of reversing the trend.

An article like this is the sort of thing the developer with the least interpersonal skills drops into Slack the day after someone's presented a transformation plan that has been researched, vetted, piloted, and roadmapped because they don't want something to change, and they didn't read the top two paragraphs before scrolling down to the part with all the capital letters. Good on the author for helping that person remove all doubt.

I caught a YouTube about this recently that I really enjoyed. "Why North America Can't Build Nice Apartments (Because of One Rule)" https://www.youtube.com/watch?v=iRdwXQb7CfM

This doesn't seem like a good idea when it comes to consistently hardening an access layer. You mean I get to double the ops maintenance cost of my existing service by adding a new one? You mean I need to figure out how to set up RBAC, rate limiting, logging, and error handling in two places instead of just one?

By and large, opinions in API design has suggest against directly mirroring table structure for quite some time. The reasons are many, but they include things like migrating data sources, avoiding tight coupling with the database schema, and maintaining ultimate control over what the payload looks like at the API layer. Just in case you want to do something dynamic, or hydrate data from a secondary service. And if you still want to generate you response payloads like they came straight from the database, there are plenty of code generation or metaprogramming solutions that make providing access via an existing API layer quite simple.

This solution seems simpler only because it ignores the problems of most practical service-oriented API architectures. If end users need a direct line to the database, then get your RBAC nailed down and open the DB's port up to the end user.

"let people enjoy things"

I really enjoyed this podcast about the issue: https://www.stitcherstudios.com/shows/verified-dust-up.

They've known about this issue for a long, long time and decided to just change who they sell it to from wealthy, "discerning" people to groups of lower socioeconomic status. This will be a tarnish on J&J's reputation for a very long time.

Cute animation, but I find it hard to say that the confetti animation is useful

> I also haven’t really bothered with project management tools like Poetry, since I think you can use virtual environments and pip and be just fine.

/me close window

I've said this before, but Automattic's catalogue of products reads like an elephant graveyard of past internet fads.

I view an acquisition like this as a relative death knell, but only insofar as we have seen unified messaging attempted time and again only to fail due to combinations of social pressures and anticompetitive technical choices. Beeper will be absorbed into another also-ran messaging platform that won't be able to compete with whatever communities already have critical mass.

However, as far as exits go, it sort of seems like the best possible outcome for the folks at Beeper, so congrats.

My computational linguistics professor in grad school (who went to do do NLP research at Google) always said, "Do the dumb thing first!"

My favorite painter! I highly recommend Caravaggio: A Life Sacred and Profane by Andrew Graham-Dixon. That and the Derek Jarman film (as referenced by others) provide valuable insight into his grandiose and self-destructive behavior, along with the patronage system that allowed him countless second chances until he managed to burn every bridge available to him. Michelangelo Merisi teaches us a great lesson on the precariousness of talent mixed with recklessness.

The other folks commenting that it depends on your costs are spot-on. The following are important data points for getting your economics right:

0) Advertised SLA. What uptime and response time are you guaranteeing your customers?

1) Minimum cost of the platform (i.e., no traffic). From here, also determine what full utilization looks like in terms of max number of API calls within your advertised SLA.

2) Cost of platform at scaled utilization based on load projections. This is where you can figure out how to make money when negotiating committed or volume-based pricing for specific customers.

3) The overall human cost of building and maintaining the platform. Don't forget that you're not just covering the price of running the platform, but the time that you and possibly others have put into it. The last thing you want is for success to force you to make your platform more expensive because it's grown past the available sacrifices a single person bootstrapping an application can make. You'll be able to retain and delight customers better if your pricing model accommodates a mature business that supports actually paying someone a salary from the get-go.

Here's my take as a person with two linguistics degrees, one of which had a big computational focus on historical change:

The person who constructed the languages eschewed using the literary influences because he didn't believe that the phonemic inventory would be consistent over tens of thousands of years due to prior information that we have about diachronic change in language families.

What he fails to take into account is the fact that the wide availability of audiovisual distribution of language has a conservational effect that we've not really seen before. So for instance, while there is a large variety of English dialects in the US, "Broadcast English" and "General American" are quite stable and broadly available.

What they've done with the constructed languages of Dune would be like if they made a new Clockwork Orange movie without any of the Nadsat dialect. It robs something from the original text, all so a hobbyist can make something internally consistent that he's personally satisfied with and that may be marketed to future consumers. That sucks.

Fermented foods have probiotic benefits, and your gut is often called the second brain, so why the heck not

Ah great, I've been trying to make my Python look more like Scala!

In all honesty, Return's docs call out how problematic if-else chaining is, and then proceeds to replace it with chained lambdas. How is that better?

I'd go as far as to say that we can avoid a lot of the null coercion stuff with proper encapsulation, but that is basically saying, "We can solve Python's FP challenges with better object design," and I understand how that may sound like nails on a chalkboard to some.

If this helps you write the kind of code you and your peers want and can understand, who am I to judge?

Check out the Vonnegut YouTube link in the doc's references. Talk about the original master class.

Bummed this isn't a language model based off of Gene Rayburn from The Match Game

Lots to disagree about here, but I'd prefer to treat the moral of this story as, not all the same people will thrive in a small company after it's hit a growth inflection point. This is okay! Without some of those folks who are willing to go broad and wear a lot of hats, companies can't get to where they need to be to start growing in the first place.

The responsibility of leadership and managers in this situation involves creating venues where early, impactful employees can be adequately rewarded without becoming impediments to their personal growth or the growth trajectory of the company. Imagine how much less burnout the author would have felt if the stock situation didn't keep him locked into the company far beyond when he didn't feel welcome.

I've worked at enough places where early contributors white-knuckled their way through changing values until the first possible liquidity event, or just left a big financial upside on the table because they couldn't make the numbers and their sanity work at the same time. These "growing pains" result in burnout, poor quality and communication from individuals we've previously trusted as veterans, and a tumultuous culture with conflict between the old guard and new layers of management.

I believe we can minimize the friction on both sides by significantly increasing the exercise period for stock options, prioritizing hiring growth in duplicative roles for individuals showing early signs of culture clash and disengagement, and empathetic coaching that names the problem (terminal burnout) and includes resources for teams or companies that better fit that person's disposition.

I'm not sure that this is the right use of the term "binding". Maybe more of an SDK?

Disappointed no one has mentioned Dune here yet

Cold-blooded software seems like a great idea in spaces where the security risk and business impact are low. I can think of a lot of great hobbyist uses for this approach, like a handmade appliance with Arduino or Raspberry Pi.

The ever-evolving threat landscape at both the OS and application level makes this unviable for projects with any amount of money or sensitivity behind them. Imagine needing to handle an OS-level update and learning that you can no longer run Python 2 on the box you're running that project on. Fine for a blog, but calamitous for anything that handles financial transactions.

I was hoping this might have some reference to the movie Society, but in the end I learned why they called it "shunting". I'll call that a net positive.

Here I was expecting them to say "use PASETO". Suggesting that we use cookies instead is wild.

A few important things to consider:

Lumping all of the medications in question into a single study is disingenuous, and seems biased towards concluding their ineffectiveness.

All three of the drugs in question have different mechanisms of action, which means that they will have a different effect on people with different brain chemistry. My read here is that if everyone takes all three and a placebo, performance may be enhanced in one case, but the remaining three cases can make the study come across as conclusive that on the whole, this course of treatment is ineffective.

Not a lot of detail on the placebo and why it performs so much better, but I'm curious about the "nocebo" effect and subjects' prior exposure to the non-placebo dosage. In other words, is the feeling of being on a new "smart" drug too distracting to successfully take the test in question for the first time?

The sample size is incredibly small at only 40 people, and skewed in terms of population. These were self-selecting individuals who responded to campus advertisements. This has been the modern critique of psychological experimentation in academia for decades, and I find it a little disparaging that we still have to suffer through it. I wish the HRB would ban things like campus advertisements as a means of recruiting test subjects -- we all really ought to know better by now.

While the sequencing of studies on each individual helps to avoid some amount of sequence-based confounding variables, and the spacing of seven days between studies allows for a pretty decent return to homeostasis, the number of study participants is still too low to be conclusive. I'd need to see this study get repeated numerous times, at a larger scale, over individuals with a more consistent neurological history to be considered conclusive.

I don't entirely buy the efficacy of working on individuals without any history of psychotropic medication or illicit drug use -- remember that this will rule out participants who have taken things like fluoxetine -- ruling out nearly 20% of adults in many countries -- or slightly skirted Australia's drug laws. These are people answering an ad on a college campus, likely for compensation. I don't think it's likely that all the subjects truthfully self-reported.

If anything I'd expect the neurological variability of a fully unscreened or undiagnosed population to make it really truly hard to measure these drugs effectiveness. Given the mechanisms of action, I'd expect that the likely 20% of subjects with undiagnosed depression and additional likely 5% of individuals with undiagnosed ADHD would really throw a wrench in any conclusive numbers.

I'm not trying to say that smart drugs are the answer to performing better at work. In fact, I'd expect a good night of sleep to make a bigger bump in these kinds of test scores. But I found the BPS is really jumping to conclusions based on what looks to me like very flimsy evidence.

Testing on people is hard, but publishing summaries of articles that don't entirely stand on their own and drawing authoritative conclusions is incredibly easy.