skore

I see no way to get a hold of that particular soundtrack and searching the web failed me. How did you get a copy? Any tips?

Would also highlight Martin Owens' Video: https://www.youtube.com/watch?v=TMHnyL4cRYA

He has been consistently putting out videos on his process and has been a (the?) main driving force behind the new pages addition.

He's also on patreon: https://www.patreon.com/doctormo

https://en.wikipedia.org/wiki/Ever_Given

vs.

https://en.wikipedia.org/wiki/Evergreen_Marine

"issue" filed. My apologies for the lack of brevity.

https://github.com/build2/build2/issues/135

Very likely, yes. I'm generating my own makefiles anyways, so generating something that build2 could consume should be possible, too.

Would it be appropriate to open a github issue for discussing this further? I would like to share some example for how my current setup is working and having the github syntax available would be helpful.

Very VERY interesting!

The one thing that I'm currently struggling to find information on is dynamic dependency handling (dyndep in ninja terms).

Is that something that build2 covers as well? Any resource you could point me to?

That looks very good! I wonder if I can make it fit my file-based approach.

edit: Yeah, doesn't seem like it.

I will check it out, thank you for the suggestion - what I glanced at seems very interesting.

I've seen it before but discarded it because since my workflow is heavily file-based, I DO need makes capacity as a build system, not just a task runner. Will check it out to see whether that changed.

edit: Yeah, I can't see how I can make it work for a file-based approach.

To me, the core of the syntax is:

    target: prereq | ooprereq
        recipe

At the level of variable handling and so forth, make is slightly annoying but manageable.

Anything beyond that - yeah, I'm with you, a lot of that is terrible.

I just wish someone would RIIR Gnu make.

I use it heavily and think it's extremely underappreciated, so instead of reinventing it, I would like to build on it. But - trying to extend the old C codebase is daunting. I'd even be happy with a reduced featureset that avoids the exotic stuff that is either outdated or no longer useful. The core syntax of a Makefile is just so close to perfect.

(I wrote about some of this in the remake repo: https://github.com/rocky/remake/issues/114 )

6 years into writing my own kind of SSC, based entirely on make.

AMA ;-)

I do understand you're not reading the replies and I'm trying to not make the same mistake that you did, so I'm not responding to the emotional content (which I could, at length, in kind) of your message, but what I think is the meat of your misunderstanding.

I find it odd that you're focussing on making people understand that many in your profession care. It has been my experience that most health care providers… care.

Let's suppose that health care is like any other profession - let's say it's just like programming, something most people understand deeply on here.

We all know programmers who care and programmers who don't care. The best programmers I know are the ones who care, are competent, but also able and willing to have their understanding of the subject matter challenged. They're not married to their craft - they keep the right distance to excel at it.

The worst ones I know are those who care just as much, but are utterly incompetent. The ones who are so deep into it that they literally cannot see any other way. To them, everything is clear and obvious. They're willing, enthusiastic and overjoyed to be working. And they're wrong. There is not a codebase they touch where every hour of work they put in produces ten or twenty times as much work for others, later on.

I think caring about your craft is a force multiplier and it's a necessary one. You don't want a mindless drone who doesn't give a damn about either your health or your codebase, no matter how competent they are. To care means to have a vital part of you engaged in such a way that all that you could bring to the table does get there. But it has to be lightly held and accepting of being challenged.

You care. I get it. But that doesn't mean everybody cares. (Again, really struggling here to not respond in kind with examples of people I have met who clearly did not care.) And even if everybody did care - some people are actually more useless the more they care.

But - it's up to the customers (or patients) to navigate that landscape. There has to be a mutual understanding that all parties involved are just human and can make mistakes. Our understanding of health care moves forward and things that are standard care today had to be invented, sometimes just a few years ago, often replacing things that used to be just as firmly a standard, before. Challenging what is accepted practice should be a healthy part of this interaction.

There's a limit to how many people care. There is a limit to how useful it is that people care. There is a limit to how effective you can be for your patients when you walk around with a chip on your shoulder, thinking that people just don't get how much you care.

Thiel actually lampshades this himself:

Warp drive is in fact hard to take seriously because its basic physics are so far beyond the furthest reaches of our knowledge as to debilitate would-be researchers—not to mention reasonable doubts about the friendliness of faraway foreign species. (Some of them, I assume, are good aliens.)

Ouch, that "Subscribe today" banner should have its fonts either embedded on the page or rendered into paths. Without that, it looks like this: https://imgur.com/a/kxie7Cb

Goodhart's law - "When a measure becomes a target, it ceases to be a good measure."

I used to work for a company that bills their customers for dev hours spent. The software they put together worked fabulously well - in the production of billable dev hours.

Since some people might pay again to see the "improved" version (after some of them likely saw the original version to see for themselves what all the screaming was about) - is this a film industry version of a DLC?

The frustrating thing is - the more you learn about what the OS can do, the more you realize that many programming languages and the applications written in them quite often reimplement large parts of the OS for an astonishingly large portion of their codebase. That isolates developers from learning about the OS in the first place. (They always end up needing to learn about it, anyhow, so it's a bit futile. Now, however, they feel smug about it and pretend like they shouldn't need to learn all this OS stuff.)

I guess developers always implement their own ignorance to a certain degree (and how could they not!? except, you know, spending more time learning their craft). What they don't know the OS can do, they will recreate - often poorly - in their own software. It does get rather comical and the various frameworks that you can subscribe to in modern programming languages repeat the concept, just that now, you're reimplementing things that the language can already do, but in the framework.

My favorite example is the various kinds of "service" patterns, like dependency injection - in many instances that I've seen, you could boil most of its use down to simple function calls. But since global functions are ew, you instead create a service that you inject and then call a method in. Boom, the gods of OOP are happy and nobody is allowed to say: "Wait a minute, if I take a few steps back and squint a little, what you're doing looks surprisingly similar to a global function call."

(And yes, I know, DI is supposed to be about overriding functions, yada yada very few people actually do that and it's often such an organizational hassle with downstream problems that projects eventually resort to put up conventions from doing that most of the time. Anyways - tell that to the people that I've seen implement, I kid you not, a CamelCaseService.)

Yeah, I'm using a preprocessor to generate the makefiles from what is basically blueprints.

Yes! It's basically a built-in stack trace! Permanently written straight to your disk!

It does get unwieldy after a certain size, but that's what I'm building tooling for.

Well, kind of.

I'm using make to build a content graph, part of that is http:// dependencies. The underlying concept is that you can define protocols (https would be one) and then teach my make pre-parser about building them. An example would be:

    myfile.js: https://code.jquery.com/jquery-3.4.1.js local.js
        uglifyjs $^ -o $@

    myfile.js: cache/https/code.jquery.com/jquery-3.4.1.js local.js
        uglifyjs $^ -o $@

    cache/https/%: cache/https/%.head
        curl -Ls https://$* > $@

    cache/https/%.head: cache/https/%.head.force
        rsync --checksum $< $@

    cache/https/%.head.force: FORCE
        curl -Ls -I https://$* > $@

I must say, though, that in my now three years of using (or abusing) make, "just make it another file" is surprisingly often the right next step. In the POST situation, it would simply be a local file that has direct or side-effects attached that do what you're expecting it to do.

Huh, this got me thinking.

How about you just give a UUID to everything in the schema?

The technical challenge with generated scripts (that you could edit by hand, but that just means that you now don't have an automated system) is that they don't understand changes at a deep enough level - they lack the context to see that a table or column has been renamed because they have no understanding of identity.

So - just give them identity.

  Schema at commit 20b1ea23

  03496418-e44c-42a6-a6a4-6563b7ae7bfb users
    25233812-9a95-4bc3-893e-6accb935fa49 name
    2f4c79c3-81b6-42d4-8379-ce5f0ed8ef62 address
    83fc34c8-56c7-49d4-94d0-150cd76204bc password

  Schema at commit c0d07562

  03496418-e44c-42a6-a6a4-6563b7ae7bfb users
    89482484-8205-40ad-a73b-a1bb988dc1d9 firstname
    25233812-9a95-4bc3-893e-6accb935fa49 lastname
    2f4c79c3-81b6-42d4-8379-ce5f0ed8ef62 address
    c9f0d35d-439e-488c-a6d5-7a144c54335c address2
    83fc34c8-56c7-49d4-94d0-150cd76204bc password

  @@ -1,4 +1,6 @@
   03496418-e44c-42a6-a6a4-6563b7ae7bfb users
  -    25233812-9a95-4bc3-893e-6accb935fa49 name
  +    89482484-8205-40ad-a73b-a1bb988dc1d9 firstname
  +    25233812-9a95-4bc3-893e-6accb935fa49 lastname
       2f4c79c3-81b6-42d4-8379-ce5f0ed8ef62 address
  +    c9f0d35d-439e-488c-a6d5-7a144c54335c address2
       83fc34c8-56c7-49d4-94d0-150cd76204bc password

litegraph.js really caught my attention and I'll be looking into using it for a project unrelated to 3d editing. I had been looking for a "general purpose node editor" for a while now but somehow never found litegraph. Let me know if you are interested in hearing feedback on that process.

I'm also looking for something similar to control and edit timelines. Do you have any plans on doing a litetimeline.js?

In general: kudos for having one of the few projects I've come across that is not drowning in dependencies. Very refreshing!

Suggestion: Having a few scenes to try out in the editor would be nice! (Or did I just miss them?)

You do realize that you are writing this comment on a site literally called "Hacker News", right?

(and yes, that is simply their technical blog)

That brings back memories! Installing Rockbox, switching the battery… I also found out later that you could get a ATA-to-CF Adapter and basically switch it to an SSD.

Don't know about counterfeiting, but when I tried to order yubikeys via German amazon, every single one of the blisters looked suspiciously as though they had been tampered with[1]. They were opened juuust slightly on the side - enough to potentially slide the key out and in again, definitely something that you could miss if you weren't paying close attention. I placed a second order and the exact same thing happened. It was quite weird and I've since ordered from yubico directly.

[1] http://imgur.com/gallery/1c8uMFr

It has long been my conviction that tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems. All of those framework-du-jour praises sound to me like people have found The New Great Tool for building a Tower of Babel¹.

Just, you know, have simpler problems?

SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with.

¹ one common tool in the pipeline actually being called babel never fails to amuse me.

I think it's mostly because of PHP frameworks. From my experience with PHP (and, admittedly, not very much experience with Java), I got the impression that a lot of the PHP Framework developers read all the "state-of-the-art" Java literature on how you should build software and then they implemented that in PHP.

They just ignored the fact that Java is compiled which makes all the layers of abstraction less of an issue whereas PHP is interpreted at runtime* hence why there are few high traffic websites on PHP that don't have at least four layers of caching.

* Yes, I know this is getting better with every version, opcache getting a lot of attention in the last few minor releases and all that, but there is only so much optimization you can do with dozens and dozens of layers of factories and services. My guess is that it does a LOT more for "simple" software like WordPress and less for, say, Symfony based projects.

Your skills with the German language are exemplary.

I should hope so, what with the being German and all.

The rest of what you wrote borders, again, on projection and doesn't seem to be a constructive way to tackle the issue that you do seem passionate but not sufficiently empathetic about.

In Germany nobody drinks tap water.

German here - drink pretty much exclusively tap water. Ordering tap water in a restaurant definitely IS frowned upon (the restaurant has to choose putting it on its menu and/or accommodate your request) , but I have yet to meet another German who would take offense at drinking Kraneberger.

I guess there may be regional differences, but it's very clearly not universal.

There was a time before air conditioning when it was possible to heat and cool buildings.

There are a lot of old buildings with thick walls as well as special building styles (like the Fachwerk that we apparently have a lot of, compared to other countries) that deal very well with heat and, I must admit, have a much superior air quality and just overall feeling of climate than any air conditioned building I have experienced so far. Perhaps those are adjusted to a very particular temperature profile, though, and if the climate changes, AC might start to make more sense.

I don't think we have very good experience with installing AC, though. Just an anecdote, but at my $JOB, we're housed in a very "modern" building with light materials, large windows from floor to ceiling, exposure to sunlight from dawn till dusk and a hilariously impotent AC (supposedly fed by an innovative ice storage something or other). The people in charge do a marvelous job of pretending, for years now, that it's a complete mystery why the ac keeps failing to move the needle - at the record heat of 39°C outside, the temperature inside climbs well beyond 32°C. But I guess that makes sense if you were responsible for making as basic a mistake as "building the walls too thin".

As soon as the fatties that need air-con completely take over then that is game over

Aber sag uns doch endlich mal was du wirklich von den Amerikanern hältst, Klaus-Dieter.