datastack

I agree it seems more common. However back-up time and data movement should be equivalent if you follow the algo steps.

According to chat GPT the forward delta approach is common because it can be implemented purely append only, whereas reverse deltas require the last snapshot to be mutable. This doesn't work well for backup tapes.

Do you also think that the forward delta approach is a mere historical artifact?

Although perhaps backup tapes are still widely used, I have no idea, I am not in this field. If so the reverse delta approach would not work in industrial settings.

Exciting!

Yes, the deduplicated approach is superior, if you can accept requiring dedicated software to read the data or can rely on a file system that supports it (like Unix with hard links).

I'm looking for a cross-platform solution that is simple and can restore files without any app (in case I didn't maintain my app for the next twenty years).

I'm curious if the software you were working on used proprietary format, was relying on Linux, or used some other method of duplication.

Nice to realize that this boils down to copy on write. Makes it easier to explain.

Great resource in general, will look into it if it describes how to implement this backup scheme

This sounds more like a downside of single site backups

You can see in step 2 and 3 that no full copy is written every time. It's only move operations to create the delta, and copy of new or changes files, so quite minimal on IO.

Thank you for bringing this to my attention. Knowing that there is a working product using this approach gives me confidence. I'm working on a simple backup app for my personal/family use, so good to know I'm not heading in the wrong direction

In this algo nothing is rewritten. A diff between source and latest is made, the changed or deleted files archives to a folder and the latest folder updated with source, like r sync. No more IO than any other backup tool. Versions other than the last one are never touched again

Nosql doesn't solve the schema migration problem. It just means you don't formalize your schema. But your code will implicitly require a certain schema anyway. Changing the schema means changing the code and migrating data. You'll have to write migration scripts and think about backward compatibility. Same problems as in sql.

Nice, thanks for sharing. Curious what your motivation was for making it. Perhaps include a "why" at the start of the repo. As evidenced by some comments, depending on whether the goal was to write HTML with a lisp compatible syntax, vs, a more concise but simple xml alternative, it creates different expectations. Personally I'm just interested from a parser/ compiler perspective.

Interesting take. Haven't heard the argument before that it saves server costs. Not convinced that this is the case, but perhaps, for a google.

Reflecting, I suppose that businesses relying on Php/Laravel or Ruby are probably still enjoying simple SSR development. I've personally transitioned to Java and then .NET, and haven't seen SSR since. Which corner of software are you in, where you see SSR still being dominant?

that's the point, glad you understood

Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack.

It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering now means something entirely different. It is about running your frontend code on the back end, So you still have the separation, but instead running it on the same machine. Now the same ui code has to be compatible with two different run times. This is much, much more complex than traditional server side rendering.

I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering unless with a lot of Jquery hackery that quickly becomes unmaintainable...

However, I do think that front end technologies are overused, so I agree with the author, And I also think this is objectively a contrarian opinion, considering my initial point.

A thought experiment on a new AI assisted programming paradigm. Your ideas are welcome.

some tasks a developer might need to do besides just building the application:

- copying a database from production to local for bug reproduction/fixes - inserting seed-data into the local database - creating a migration after changing records - applying the migration - rolling back the migration - running a tool to copy configuration from a keyvault - running the end to end tests - generate certificates - set up an ssh tunnel to a remote server or database

All of these things are part of the development process, and cannot be part of the build system. Each of them has their own commands and tools.

All developers need to easily be able to do these things, without asking help each time, or learning the syntax of each command.

One easy way is to stuff all of them in a task runner with simple aliases. Another could be writing a document that you can copy/paste from. I prefer a task runner, since you can memorize the alias and work from the terminal without looking things up.

I guess going with a parameter count that matches existing models makes it easier to compare benchmarks. Perhaps there is another particular reason like required memory, but momentum is probably also significant.

Quick prototype, but already very useful!

Use with your own OpenAPI Key.

Never google a CLI command again :-)

This reads like an AI generated nonsense article.

The difference between hiding a particular problematic tweet and all tweets of an account is important though. It seems Elon refers to the former, while shadow banning refers to the latter. Let's hope it is so.

I love Github. It's been the best thing that happened to promote open-source software collaboration since the invention of version control. Without a centralized place to find and share open-source software, a million products would not exist today.

Not sure why Github itself should be open source. Since microsoft has bought github, I see usability improvements and new features every month. In 13 years of working with it, there have been very few problems with it.

They have carried open source for a decade now, without breaking even. It seems fair to me that they're trying to earn some money with it. So far their plans and offerings are reasonable and there are plenty alternatives.

Interesting to hear your experience. I've been using it for over a year, and I've come to appreciate the (modest) productivity boost that it's given me, to the point that I feel $10 per month is probably worth it.

The completions are often trivial, but they save me from typing them by hand. Sometimes they are trivial yet still wrong so I need to make corrections, wasting some of the gained speed. In total these probably won't save me much time on a day.

However, every couple of days there is one of these cases, where it can do tedious work that really saves time and headaches.

Example: - After writing a Mapper that converts objects of type A to B, I needed the reverse. Co-Pilot generated it almost perfectly in an instant. This can easily save a minute or two, plus the thinking required. - For a scraper, I needed to add cookies from my browser into the request object. Basically, I pasted the cookie in a string, and typed `// add cookies`, and it generated the code to split the string, iterate over each cookie value and add it to the correct request field.

So if a few of these cases can save 10 minutes in a month, I feel it's objectively worth it. Then subjectively, not having the headaches of 'dumb stuff'/boilerplate feels great, and I am glad to spend my energy on the actual hard stuff. I will sign up as soon as their sign up page lets me.

Hi, nice cheatsheet! I've published it on DataStack, where anyone can contribute improvements (like adding columns or corrections).

https://datastack.net/datastack/usb

I can transfer the project to you if you like.

Haha ('￣▽￣) Be sure to check my upcoming library that can concatenate strings!

Cool. Does this work on Windows too?

That sounds like an issue. This initial version is made on Windows, and although the commands are all unix-compatible, the unix file-permissions have slipped past, as on Windows docker runs as the current user.

Would this be easy to fix? Like, determining the current user id, and setting it when launching the command? Or would the host uid need to be mapped to the docker uid, which might be different for each image?

Yeah, I used their official image also.

If all cli tools were available as officially supported docker images, 'dockerized' would probably not need to exist, other than just a bash function (and something else for windows).

Unfortunately it's not the case, and many tools only come in zipped binaries, or must be compiled.

An alternative approach would have been to make docker images for all cli tools, and publish them. But the burden of maintenance would be quite a bit higher, and it would still be unclear for users which images to use for each cli tool.

Indeed, it is just a wrapper script, but I think the value is not in the `docker run` script, but in the preconfigured images.

With a premade list of cli tools, you won't have to figure out which image to use, write your own Dockerfile if there is no official docker image, how to mount the current directory (try that on windows), which extra volumes to mount (for persistence of npx packages, or .aws credentials, for example), and the 'aliases' will be compatible with unix and windows too.

This tool seemed handy to me, as it was basically a packaged version of what I was already doing with many separate bash scripts. I haven't seen those tools you mentioned, but I'll have a look.

Thank you, Whalebrew seems like the tool I have been missing!

Edit: "Windows support is theoretically possible, but not implemented yet" :-(