daotoad

It's essentially the same advice given to writers. Read a lot and write a lot.

If you can get access to review work by folks on other teams that do more coding, that would be a good start.

From there, you need to allocate time to looking at changes closely. Don't just accept things at face value. Ask basic questions like "why is that there?" and "what does that really mean?" and hunt the answers down. Code consistency can mean many things, formatting and variable casing are the obvious things, but also things like how method names are constructed (e.g. when do you use "get" vs "fetch" as a prefix), are concepts named consistently (is "business hours" always spelled "business hours" adjusted for casing or is it called things like "hours" or "biz hrs" in some places.

I look for three big things: * technical soundness - does the code do what it says it does? * ontological soundness - are the concepts used well defined with clear boundaries and do they play well with the conceptual framework of the rest of the application? * semantic soundness - is the meaning evident? does the code do what you'd expect? How hard is it to reason about what the code does when it is called?

I view writing code as a primarily communicative activity. So, I evaluate it based on how well the ideas it embodies are structured and how well it communicates those ideas.

Now apply that same logic to how we write our numbers. Duodecimal notation makes very clean multiplication tables and makes arithmetic easier to learn.

I'm a twelve maximalist. Let's convert SI to duodecimal prefixes. One kilometer should be 1728 meters (of course that's 1000 in duodecimal). One centimeter should be 1/144 of a meter.

I keep hoping for a chance to welcome some highly composite overlords.

Not as long as I am forced to use VS Code.

Even if the only thing fig adds is easier set up and integration and consistency of setup between users that could be enough to justify the cost.

Saving an hour of engineering time spent fiddling with your CLI config every year makes this a good value for a business.

I may be full of crap, it's been over 15 years since I worked on this stuff. You have been warned.

The systems I worked on used multiple deep discharge, cold weather hardened lead acid batteries.

Deep discharge batteries have an important distinction from automotive batteries. They tolerate significantly more deep discharge cycles but can't produce as many amps. If you're just trickling a more or less steady amount of power into some electronics, you don't need massive amounts of cranking amps that an auto battery provide.

Solar PV and battery tech have definitely improved quite a bit since then, so were I now building these same installations, I might do something entirely different. But "back in the day" your advice of "buy another battery" was more or less exactly how we handled charge rate limitations.

There are some really handy databases with detailed insolation data available for sizing your solar projects. https://nsrdb.nrel.gov/ is one place to find this stuff.

Years ago I worked on environmental monitoring systems for snow and ice management. One of the things I did was help spec out solar systems for remote installations in Alaska and Canada.

The basic issue was "How much sun will there be in a typical summer?" combined with "How much power can we store in our batteries?" and "How much power can we draw from the lead acid batteries without them freezing?" (who knew that a discharged battery freezes at a lower temperature than a charged one? I sure didn't).

It's a pretty straightforward process, actually. The company I worked for had a pretty detailed spreadsheet to help with bids, but essentially you: 1. look up the insolation data for the install site in one of the databases with that info (like https://nsrdb.nrel.gov/) 2. compute rate of loss over time for your installation (power consumption +_self-discharge) 3. look at the battery datasheets to determine how much you can discharge the battery at any given time based on anticipated temperature ranges 4. work out what your tolerances are for temperature and insolation variability

Usually there would be a couple of options that were in the cost sweet spot where you had a bit more solar and bit less battery or vice versa. Some of these sites were up around the arctic circle, so battery was pretty important in those cases, since you're looking at months without appreciable sun combined with low temperatures.

This wasn't even the major part of my job, but it was a small company and I wore a lot of hats.

Speaking as an American the bit that seems over the top is the ""5, 1, or 0 meters" bit. It comes off as condescending. At least from another American. I've known a few Germans and this sort of comment seems much more acceptable to them. I think it's seen as "this is my reasoning, with it you can better evaluate the validity of my request".

Simply saying "please stop touching my luggage" is what I would expect. Adding any reasoning or explanation increases the emotional stakes and gives more places for people to infer subtext.

I appreciate the directness of simply backing your request with clear assertions as to why it is reasonable. Despite this, it does feel a bit odd to hear.

If you like `z`, you should check out my `tutu`.

https://github.com/daotoad/tutu

I go to Cash and Carry (well, they've renamed it about 15 times in the past few years, so it's actually US Chef's Store or something dumb like that) for wholesale pricing on meats.

Costco near me is pretty much the same price per unit category as grocery stores unless I go to their special wholesale outlets. Costco has better quality and variety that the standard grocery options though.

Pork loin (the stuff boneless chops are made from) is really lean and is pretty inexpensive, cooked properly, it can be delicious. But it can really easily dry out.

* Brine your meat before cooking to help it retain moisture

* Cook the minimum amount possible

* Try low and slow methods like

  * Sous vide

  * reverse searing

* Butterfly the roast and make a roulade or bake chops on a bed of seasoned rice or stuffing

* Cut into chops and pound until thin, bread and fry to make scallopini, schnitzel or katsu

* cut into thin strips and use the Chinese "velveting" method to prepare for use in various stir-fry type dishes

If I go to a massive conglomerate store, Albertson's, Fred Meyer, etc, those are the sort of prices I expect.

When I go to the restaurant supply store, I can get bulk packages for $1-$2 a pound. Granted, these are often big, but not massive.

Prices today: Tenderloins are a really good deal at $2.59/lb for around 2 pounds and can be easily separated and frozen. Pork loin(boneless, minimal trimming needed) is $2.25/lb for a 10 lb roast and can be trivially sliced into excellent chops and packed up for later. If you want to cook up some cochinita pibil, a picnic cushion with bone and skin is $1.69 for a 10lb average pack. Bone in shoulder butts are $2.05 for ~ 19lb package.

It's bit more work and more trimming, but cutting a beef strip loin or boneless ribeye into steaks nets out really well. I'll buy beef loin, trim it for a yield of 75% steaks with 15% in usable beef cubes and the rest in fat and silverskin. I render the fat and cook the nasty bits for the dog. If I only count the steak as yield, my $8/lb loin gets me NY strip steak at ~$11/lb and a bunch of free stuff. You just have to be willing and able to drop $140 on beef, cut it, pack it, and store it. It's less than two hours of work to make all the steaks and render the fat.

Based on all the love people are expressing for "Shorts" here, I feel like the feature should be renamed "Pants".

This joke only makes sense if you understand UK-type English.

Two things I hate about youtube these days are:

1. Subscriptions are essentially useless. The UI focuses entirely on recommendations and doesn't show me videos from channels I am subscribed to unless I actually dig into the `library/subscriptions` UI.

2. Shorts. Shorts are everywhere and I don't want to see them, ever.

In summary, the platform is turning into a way to force-feed me content that I am not interested in. If I wanted that, I'd sign up for tiktok.

(EDIT: Fixed formatting)

I have terrible luck with Spotify and Siri. These kinds of specific requests fail.

I tried it with your prompt and Spotify started playing the whole album. Which is better than my usual outcome. Of course, it took three tries. The first two times Siri said it was going to play and nothing happened.

Usually I don't even get the same artist or album I ask for. Admittedly, I stopped trying a few months ago, so maybe they've improved things a bit lately, or maybe I just got lucky.

How do you get Siri to actually work with Spotify?

When I try to use it I get consistently laughably bad results. `Play songs by Albert King on Spotify` yields something like "Playing songs by R Kelly on Spotify". No, thanks.

Even when I ask for songs, albums, or artists I have saved in my library, Siri invariably finds something else entirely unrelated to play.

What's really frustrating is that this used to work reasonably well for me.

I got a similar Brother in 2020 after my Epson inkjet MFC became unusable. The Brother is reliable, simple, and was cheap, even when printers were thin on the ground. Before the latest in a series of Epson inkjets, I had a Brother laser that lasted from 2000 to 2010, when it died in flood--if it hadn't gotten soaked, it would probably still be kicking.

In the time between the Brothers I had a long period of no printer and two different Epson MFCs. The last was, in some way brilliant. It had a sheet feeder for the scanner, it did duplex printing, and the print quality was excellent. It even had separate tanks for each color of ink. But man the tanks were tiny and expensive. It seemed like you'd print 3 pages before it would need yet another tank. And you couldn't print black and white if the magenta tank was empty. But that notwithstanding, it was a pretty great printer. Until it wasn't. It started failing to pick up random sheets of paper mid print job. Then it would fail to pick up any pages at all unless you adjusted the paper tray just right, then it just stopped being able to feed paper 4 times out of 5. Then it stopped working completely. I cleaned the rollers over and over, it helped a little. But it just got worse and worse. Nothing made it better.

Supply chain shortages and pandemic printer buying sprees meant that I had few options. I made the choice to just get the cheapest, simplest laser printer I could find. If I really needed an MFC, I could get one later. Turns out I didn't need it. I scan things with my phone camera now. It's good enough for documents. I rarely need to do more than a few pages. I wasn't printing much color nothing that really needed it.

They way the thing is working, I figure there's a solid chance I could be good until 2030.

For book chapters this is probably fine, but if there's any chance you might have a lot of things to deal with at once, you probably want to manage a pool of promises.

You might be okay in normal usage, but if a backlog accumulates, you could find yourself consuming all available resources and self destructing over and over.

I've tried it and do not recommend it.

I agree 100%.

I've worked on some big TypeScript code bases that make heavy use of sort of FP the article promotes; dealing with stack traces and debugging the code is incredibly painful. Jumping around between 47 layers of curried wrapper functions and function composers that manage all state mostly in closures is a real drag.

Until the tooling is better, I can't recommend these idioms for real work.

TBF, there is a kind of beauty to the approach and as you really dig into it and understand it, it can feel like a revelation. There's something addictive about it. But any feeling of joy is obliterated by the pain of tracing an error in a debugger that isn't equipped to handle the idiom.

> no amount of legislation will change that

Programs like SNAP, the earned income tax credit, subsidized child-care, and refundable tax credits for children have an immediate impact. Legislation could also provide a universal basic income.

If that's too pink a set of approaches to reduce the impact of poverty for you, governments can also subsidize development of new housing and invest in infrastructure upgrades that draw folks with higher incomes into a community. This works best if you are in a metropolitan area. In rural communities, it's not uncommon to pour great sums of money into courting large employers, giving them land or tax free status for extended periods.

Hell, if your goal is just to get a grocery store, pour on enough subsidies and someone will show up to collect that money.

We need to write code that is optimized for communication and clarity. We have a number of tools we can use to craft communicative code.

1. Variable and function names. These should be descriptive and never deceptive. For example, I've seen metric tons of code like this `const json = makeSomeApiCall(params)` where the contents of `json` is a the decoded response data and not a JSON string. This code is deceptive and obfuscatory. But if you write `const decodedFooResponse = makeSomeApiCall(params);` then you are accurately describing what the value is. This is particularly import in untyped/loosely typed languages where the value of the variable could be anything.

2. Code structure and layout. When writing prose, we achieve clarity through structure. Code is no different. Keep related things together. Avoid run-ons. In other words, write code that has smallish functions, with smallish interfaces, it's easier to reason about how the code will behave. Avoid unnecessary mutation of values--repeated mutation of the same value is particularly pernicious. Use white space to create visual separations of distinct ideas. Use abstraction and encapsulation to keep code focused. Avoid deeply nested conditionals, flattening the tree whenever possible. And a million other strategies that can all help.

3. Tests. Tests can be documentation, but they certainly aren't always. They also aren't convenient documentation--what they offer isn't going to show up in your editor when you inspect a method. Unit tests are a nice way of recording verifiable expectations for behavior. But if the test code is complicated or poorly organized, all it does is compound the misery of working on a messy codebase.

4. Comments are distinct from documentation here. Comments are little side notes like "this implementation is a bit of a hack. It is brittle because .... but we decided to keep it because X. See someURL for contemporaneous discussion." They tell us why a thing is the way it is or about some sort of risk or unexpected detail.

4. Documentation is absolutely a part of making code understandable. These docs are primarily going to be used in an IDE/editor when viewing function signature data. Ideally you can write JavaDoc/TSDoc/POD or similar inline docs. Examples are worth their weight in gold.

We should be using all our tools to write communicative code. We don't need every technique for every line or block, but over the scope of a package or project, we should judiciously employ them all. Every line added comes with a concomitant maintenance cost--we must ensure that every line we add is worth that cost.

I got my first Zojirushi rice cooker over 20 years ago. The only reason I'm on my second is that my ex-wife claimed it in the divorce, she's still using it. I'm still using my "new" 12 year old model.

My understanding is that a star is a star regardless of what is or isn't in orbit.

A sun, however, needs to have planets to be a sun.

I'm pretty sure I've said this on previous mentions of htmx, but I'll say it again: this reminds me of the old SPF framework youtube published.

http://youtube.github.io/spfjs/

SPF was a bit more focused on being easy to merge into an existing server side app.

I am glad to see this and hope it has some legs. It could help free us from the need to write every UI in JavaScript(ish).

The reason was shared hosting. Most of the really good Perl options for application building used mod_perl which did not play well in shared hosting environments. If you could find a host, you were still somewhat at their mercy for getting modules installed, which was a huge pain in the neck.

Conversely, PHP was trivial to set up for safe shared hosts.

The end result was that Perl hosting was expensive and had a higher barrier to entry than PHP.

Fortunately the insanity of "standard" units has everyone used to memorizing silly facts like boiling is 212 and there are 5280 feet in a mile.

If you're used to that, it's easy to remember that C = (F-32) * 9 / 5.

Excessively complex DSA questions are not very useful for me as an interviewer. I prefer to offer a fairly simple test problem that has room for elaboration. For example, when evaluating SQL skills, looking how the candidate would model mapping between companies and stock ticker symbols is instructive. You can start with a simple flat table, extend to one to many relationships, discuss when normalization and denormalization make sense. You can keep elaborating this, too--add in multiple exchanges to get many to many, and so forth. This lets you see how the candidate evolves a design in the face of changing requirements, which is critical.

These kinds of questions are great for leveling an applicant. How a junior dev answers these questions will be very different from what a senior dev has to say.

JetPens actually has a guide for this, too: https://www.jetpens.com/blog/The-Best-Lefty-Friendly-Pens-an...

You might find this presentation interesting: https://thenewstack.io/perl-programmer-pioneers-coding-by-vo...

It is the Secretary's job to (have their department) write regulations. Regulations are the implementation of the specification laid out in law. When the law is ambiguous, regulators have to choose an interpretation.

Congressional paralysis is definitely a problem, but until we have a major change in either Senate rules or political paradigm, we not see any improvement on that front.

If you accept that the law is ambiguous and that the current Secretary of Labor is effectively making law by choosing an interpretation, you must also accept that the existing regulatory structure also derives from a choice made by a previous Secretary of Labor who effectively made law by so doing so.

Your argument does not provide any basis for preferring one interpretation over another.