908 karma · joined November 8, 2016
But I will say that until we have a robot that can fold laundry, we won't have a robot that can go into your crawlspace and replace a chunk of crusty old galvanized pipe with copper or pex.
Robots have excelled, so far, in controlled environments. Dealing with the chaos of plumbing in a building that has been "improved" by different people over the course of a century is the opposite of that.
When everything includes software, someone needs to write and maintain that software.
If software becomes cheaper, we'll just use even more of it.
I clicked through because I was hoping to see something related to the book or movies, or even the Jodorowsky project that never materialized.
My webcam sits low on my desk (it's built into a laptop screen that is one of many) so it was almost impossible to look up without it saying "too far" and I had to curl around myself and hunch to get it to maybe register as looking down.
I tried moving the display between monitors and that didn't help much.
If I could calibrate what "straight ahead" is then I could maybe play the game.
Because some checks are expected to be runtime only, it lets you specify types like "Odd integers" by writing a `where` clause.
``` subset OddInteger of Int where !(* %% 2) ```
You can use multiple dispatch to separate dispatch from processing: ``` subset Fizz where * %% 3 subset Buzz where * %% 5 subset FizzBuzz where * %% 15
multi sub fizzbuzz(FizzBuzz $) { 'FizzBuzz' }
multi sub fizzbuzz(Buzz $) { 'Buzz' }
multi sub fizzbuzz(Fizz $) { 'Fizz' }
multi sub fizzbuzz(Int $number) { $number }
(1 .. 100)».&fizzbuzz.say;Or even use inline anonymous subsets when you declare your functions: ``` multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' } multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' } multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' } multi sub fizzbuzz(Int $number ) { $number } (1 .. 100)».&fizzbuzz.say; ```
Raku's type system is one of its features that will show you new ways of thinking about code. I advocate playing with Raku specifically for mind expansion because it has so many interesting ideas built in.
Being real vague here, in order to support a new capability, we need to insert an asynchronous operation in the middle of what has been a synchronous operation. The synchronous operations is done implicitly and explicitly in many, many places in the app (yes I know this sucks, big old codebases are what they are, and you can only refactor so much at one time while continuing to deliver new features).
We have a hard ordering requirement where the new async behavior must be completed before the work can continue.
And it's killing us. What would be a simple case of "call this new function" is spiraling into weeks of work and thrown our planning into question.
Most of the time it's pretty easy to accommodate the contagion. It's a little more work than is ideal, but it is fine in practice because you hit a natural boundary that stops the spread.
But in this case, due partly to tech debt and partly due to deep architectural decisions, it's blocking our ability to move forward in a reasonable amount of time.
We will certainly find a solution, but it's going to be much more expensive to get there than it needs to be.
I learned something today because of it.
For example, the schema.org schema puts quantities, units, and ingredients in a single field. Fail, IMO.
Other issues include things like not being able to group ingredients or procedures.
I don't have my notes on what I thought of each of the ones I've reviewed handy, but here are some I've looked at:
- http://www.formatdata.com/recipeml/
- https://recipemd.org/index.html
EDIT - for clarity, added examples of standards
One of the best flavors I have made was what I called "Spaghetti Onigiri". For that I took a basic American style spaghetti sauce (tomato sauce + ground beef) and simmered it down until it was very concentrated and almost dry. I used that for the filling. Then I took the filled rice ball and rolled it in a mix of grated parmesan cheese, garlic powder, and "Italian seasoning" blend.
Another version I didn't invent is ketchup onigiri. This is made by mixing dried chopped onion and ketchup into cooked rice with small cubes of cheddar cheese. Form it into smallish onigiri and toast in a medium to medium low pan, brushing the outside with soy sauce. I don't remember where I learned it other than some random little Japanese cookbook I picked up Kinokuniya in the late 90s.
A popular standard in my home is to make them with tuna salad. It's probably the most common way we eat them. Just mix your tuna salad to be a bit dryer than usual.
I replied to another thread here with some links to more traditional recipes.
You can make them all sorts of ways. Plain rice around a filling or with rice with stuff mixed in shaped into a ball.
You can also make a more sandwich like variant called onigirazu. This link is for one made with chicken katsu, but you can use any kind of sandwich filling--strongly flavored, savory things like ham work best.
1. a cryptocurrency scheme for funding OSS development[1] is incentivizing spammers to try and monetize NPM spam
2. it's easy to spoof your dependencies with package.json[2]
"dependencies": {
"axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz"
}
They found someone to take on the Cinerama. But the living computer museum was a taller order. Which is tragic because it was an unbelievably cool place. Being able to use a Xerox Alto and an orginal Microsoft Surface (the one built into a table) was a gift. It's sad that this won't be available for others in the future.
The big use case I see for this is to drive automatic generation of changelogs and automatically computing the next semantic version of your project. Which is a very cool idea.
The problem is that unless you carefully write every commit message in a way that makes sense for your product's changelog, the changelog ends up being unreadable garbage.
On top of that, if you're working in a monorepo, any given commit may impact multiple projects. How do you write those commit messages to make sense for three different projects? You'll always wind up with irrelevant crap in your changelog.
This problem gets magnified even further if your team is squashing commits with each PR. This means you can't even keep a discipline of isolating all the changes on a single commit to a single project. Another issue is that you can't use linters on your PR commit messages on github, so your squashed commits aren't verified to be correct.
I still love the core idea and I wish it worked better for my use cases.
Thrilled to have another option to check out.
I was then able to go through my list very quickly and add times to each item.
The one failure I had was when I asked it to add whitespace to visually align the table columns.
The table was, however, converted back into a list when I asked it to turn the text into an email.
It's not exactly punching numbers into a spreadsheet, but it worked pretty well for the simple use case I tried.
This seems like it would be particularly good on a telephone or my watch. In those places it seems like a real game changer in terms of ability to take notes when the keyboard experience is less than awesome.
Have you tried using it to write code? This could be amazing as a IDE/text editor plugin.
It's nice to see someone do something that's not regrettable with AI. So many of the applications we see are horrible. What you've made is brilliant and very far from being just another cursed chocolate factory experience.
It's just cream that's been gently heated for an extended time to denature the proteins a bit. Not all that different in spirit from fresh cheeses (though cheesemakers denature the proteins by acidification or enzymatic methods).
This means you can't add custom operators without subclassing or doing weird crap with proxies.
When RxJS stopped using instance methods to implement operators, it opened up the ability to create custom, domain appropriate operators which I found key to writing comprehensible and maintainable code.
We really need a `pipe` operator, at minimum. https://rxjs.dev/guide/operators#creating-custom-operators
USENET comes from a more innocent time, when few institutions had firewalls, open (SMTP) mail relays were pretty common, and people logged into their systems over telnet.
If you want to patch a bridge, it's gonna cost you. Even if you only need to close down a single lane of traffic for a few hours you are looking at massive expenses for traffic control, coordination with transportation agencies, etc.
For most software it's pretty inexpensive to ship updates. If you're a SaaS company regular updates are just part of your business model. So the software is never actually done. We just keep patching and patching.
In some contexts, it is much more expensive to push out updates. For example, in the 00s, I worked on a project that had weather sensors installed in remote locations in various countries and the only way to get new software to them was via dial-up. And we were luck that that was even an option. Making international long distance calls to upload software patches over a 9600 baud connection is expensive. So we tested our code religiously before even considering an update, and we only pushed out the most direly needed patches.
Working on SaaS these days and the approach is "roll forward through bugs". It just makes more economic sense with the cost structures in this business.
Barring something like fusion rockets or a space elevator, it's going to be hard to really do a whole lot in space.