andreineculau

I understand the simplicity angle. https://github.com/elasticdog/transcrypt has been around for a long time and strikes that balance very well in my opinion. And it's just a bash script that can also be committed so the git repo is atomic.

You've got nothing to worry

Been doing it for more than a decade and yet to get in trouble. Not one issue. Doing it consistently for my teams as we decrease cognitive load (developing on macs but targeting unix). Others would confirm https://news.ycombinator.com/item?id=17943202

Basically software will either use absolute paths i.e. wants to use your OS version for a dependency like grep, or will use whatever grep is in your $PATH and stick to safe invocations regardless if it's BSD/GNU or if it's version x or y

How do these stack up to https://www.timescale.com/ ?

KATT https://github.com/for-GET/katt is the same concept, but following the pattern matching philosophy. Written in Erlang, available as a CLI tool as well but needs the erlang runtime installed.

Code example: https://github.com/for-GET/katt/blob/master/doc/example-http...

Disclaimer: I'm one of the authors, thus biased, but the reason I'm mentioning KATT is that the low barrier of entry for captures and asserts makes it a nice requirement tool for non-techs to write complex API scenarios.

Erroneous send out by Apple according to https://www.macrumors.com/2022/07/28/apple-erroneously-sendi...

That's because there are no arm runners on GitHub actions. So you now emulate arm, thus slow.

You can add hosted arm GitHub runners or register arm hosts for docker and see down to earth build times.

This 100!

I'm happy to see dagger, because it is something that I have been working with since 2016, and ended up creating

https://github.com/ysoftwareab/yplatform

It uses well-tested software (GNU Make, Bash, Homebrew, Docker) and there's not much to learn really.

  * Incubated at Tobii (eyetracking, Sweden),
  * it has been used for several projects of different sizes,
  * tested on 12+ CIs !
  * tested on macOS, Linux and Windows (WSL) !
  * tested on 8+ Linux distros !
  * comes with prebuilt Docker images !

Early integration with VSCode. And much more. Just read the README :)

Happy to help anyone integrate it.

I second that. DiffMerge every day for almost 10y

For diffing yes but for merging... I have never gotten myself to use anything but DiffMerge. And now with their rewrite and price tag... Never ever.

When you say everything contained in the project, you forget that there's more to life than just node/javascript. Just two silly examples: you cannot run/deploy your API backend without docker/kubernetes/aws-cli/etc, nor your mobile app even if it's in JavaScript (react-native).

The only way to keep to node/javascript is if you only develop libraries (a website that doesn't get deployed -> still on library level).

Nowadays there's Windows Subsystem for Linux. There's no excuse not to successfully run "Linux" scripts on Windows.

I've been running very complex build systems via https://github.com/ysoftwareab/yplatform (disclaimer: author here) since 2016 on Linux, Mac and Windows without a problem.

I have never bumped into that article before, thanks for that.

I did implement though that uniform interface in https://github.com/ysoftwareab/yplatform

https://github.com/ysoftwareab/yplatform that this a notch higher (disclaimer: author here)

As others have mentioned on this thread, the problem is not just "use Makefiles instead of package.json scripts", but quickly ending up with duplicate Makefile content and then supporting more than just one language. It's inevitable.

PS

for those that don’t know, npm’s “scripts” functionality as we know it today was not “designed”, but it was simply a byproduct.

First introduced as an internal functionality for lifecycle support https://github.com/npm/npm/commit/c8e17cef720875c1f7cea1b49b... on 1 Mar 2010

and later extend to run arbitrary targets https://github.com/npm/npm/commit/9b8c0cf87a9d4ef560e17e060f... on 13 Dec 2010

This is the entire design backstory https://github.com/npm/npm/issues/298 .

Needless to say that GNU Make’s equivalent (or any other build system) is not to be found in npm’s scripts.

This is exactly my experience which lead me to create https://github.com/ysoftwareab/yplatform - with a consistent make interface https://github.com/ysoftwareab/yplatform/tree/master/build.m...

PS: quite feature complete but not yet well marketed so to speak. I'm actually recording an asciinema session this week in order for a visitor to grasp quicker the mentioned benefits.

From GNU Make webpage:

> GNU Make is a tool which controls the generation of executables and other non-source files of a program from the program's source files.

What is idiosyncratic is to think Make is first a command runner, and only after a file generator, and complain that it is doing a poor job at the former when it clearly says it is focusing on the latter.

I read the "idiosyncrasies" section on the just README and they are all performance related targeting file generation. All of those can be learned in one minute, as part of "I'll always find Makefiles in the wild, it's good to know the basics".

Funny but I've also done this. Thanks for sharing!

Depending on the context, if you don't want this in git history, and want to handle git submodules, there's also git-archive-all https://github.com/roehling/git-archive-all (if you like shell scripts, it is using bats for testing - it was the first time I heard of it)

> Professionalizing the role of maintainer

My 2c are that the problem is there, not specifically to OSS. The whole industry is looking down on maintenance and maintainers.

Keeping things working might not be a great career, but it's equally important as creating new stuff, and guess what: some people don't want to create but like to debug and maintain.

A parallel might be drawn with the right to repair electronics. When we will get back the culture of repairing stuff, then we will value more the act of repairing. Because now, it's an art of repairing that very few afford.

I've also been having bash as a strict req for tool language. As you say there are 1% or less cases where you can benefit from using smth else but that's 1%! My team had js as the main language and that's what we had that 1% in. Mostly no-deps scripts but where deps where needed we could hack around npx to install the deps on-demands. I would use deno today for that actually.

But! Almost nobody gets it. If you're into operations: "here we write our tool chain in Python". If you're into dev: "here we write our tool chain in js/go/php/etc/etc Bash would just be a +1"

+1??? You still need to write bash, or shell in general, for orchestration of build/ci/cd pipelines. If someone thinks that in 2021 they can escape learning shell, they are out of their minds. So no, it's not a +1.

Bash is the language that is not only available quite everywhere but it's also the one that allows you to write oneliner solutions https://twitter.com/andreineculau/status/1466107915450916867... and move on.

As devs we should spend 10x more on solid foundations that work as many of us, for as many years to come, than we do on hip-new-thingie-that-promises-to-fix-all-my-problems. It's as if we took the regex joke and our brains could only comprehend: I'm never using a regex. Keep it simple? Never.

Thought about that last year. You wouldn't have your solutions public but any chance?

I can double down on that. I have developed a pattern to use any language (but we used js/python) to generate cloudformation templates. This has started in 2016, long before CDK. The idea originated in GCP's docs where they present both jinja and plain python as a way to generate iac.

I often got asked "what about terraform?" Yes, what about it? It is a +1 in our stack, lagged (maybe not now) behind cloudformation releases, it still doesn't give you the benefits of a proper programming language, let alone one that many are familiar with, and we will not have a multicloud problem in the foreseeable future. So yeah, what about it?

In retrospect, there is a negative. The industry is brainwashed so looking for a new job becomes: but do you know terraform? Completely overlooking whether one could simply learn it :) it ain't rocket science

A chatbot as an interface to NLP + searching a comprehensive FAQ ==> yes please! So basically improve on Google search by adding your own ontology.

But otherwise, please no. Who ever liked calling a service and click 1, 1, 9, ... ? Then why apply it to the web?

Unfortunately most pay big money to chatbots but they don't want to invest anything into building an FAQ. Mind-blowing. In 9/10 cases, I game the bot to take me to "special case, need to contact human support" as soon as possible. Because that's what many do - hide support behind the chatbot, no phone, no email, no contact form being made public...

> For one, it's closer to a proper programming language as opposed to straight up data interchange format. Sure if you write it in YAML than you can take advantage of variables but YAML's syntax for variables is pretty gross.

So what is stopping you from using "a proper programming language" to generate the json/yaml cloudformation template?

This is what you see in GCP docs from day one. On AWS, they brainwashed everyone in this corner of "static template with parameters", so that you can "reuse" a template to build your custom stack. It's great for "look what I can do, mom" (but I have no idea what it's doing) but nobody sane would ever trust a 1-km long yaml/json and deploy it. So if you anyway have to inspect it, why not make it easy to inspect? Split into modules, add docs, etc = code to run.

I have no idea how we switched from random scripts to "reusable" random scripts (ansible &co) to random static configuration and then the cherry on top: "reusable" random static configuration. Insane. Abstractions on top of abstractions.

CDK is on the right track, but even there it's a mess, again for the sake of hiding complexity: constructs and deployment. Where did One thing well and Keep it simple stupid go? :)

Thanks! It's always nice to read HN threads and get "better" (subjective maybe) alternatives than the original post

I never thought I'd ever be defending Microsoft, but 2nd screenshot 1. tells you why 2. tells you that once Teams fully supports Safari, this workaround will not be necessary.

Given that the API is the product, their API style leaves many things to desire.

Concrete example:

Account details https://nordigen.com/en/docs/account-information/overview/pa... : alright, I send in a bank account ID, and get back some "application/json". What exactly I get back? You have to check another page with zero context https://nordigen.com/en/docs/account-information/output/acco...

As a techie, giving up my info https://news.ycombinator.com/item?id=28035602 to them is a big no-no given the above knee-jerk reaction.

Or: thanks for revealing a possible improvement on hckrnews ;)

I'm all for not using Kubernetes (or any other tech) just because, but seeing their website giving 500.. I can't help but feel all the k8s' laughter. :(

Google Cache doesn't work either https://webcache.googleusercontent.com/search?q=cache:YECd_I...

Luckily there's an Internet Archive https://web.archive.org/web/20210720134229/https://ably.com/...

I haven't read it all but this could be great material as a git-mindset booklet for a team. Great to see someone taking the time to put down common sense notes about working with git, rather than yet another dry "this is how git works" or "this is how you should use git (because i told you)".

Why? Because it glorifies the pattern of copy/pasting.

Your argument goes like: some biking commuters already bike too fast in crowded places, so what harm will it do to incentivise them to put an engine on their bikes so they can go even faster, even on hills?