OriPekelman

This is really amusing. Because absolutly eveyrone I know vibe-coded this thing. I think the first one was https://github.com/ralt/dns-to-port possibly mine is second (but it is very much a joke so I am not linking it) .. Vercel later did https://github.com/vercel-labs/portless and I would imagine quite a few others. Zeitgeist. Also this does probably mean its kinda useful.

And that none of us can get bothered to "Google" if a thing that does the same thing already exists. Currently vibing, on a train, a spaced repetition thing for my kid - because I needed a specific list of countries - and its faster to create the whole app rather than figure-out how to find one that would do this.

ex-insider here, actually Git is used internally as a database of sorts. And it makes sense for many other reasons not cited. You are guaranteed to be able to access the "database" in a decade or two if you need to restore stuff without having to worry about binary compatibility. For more complex data types you can actually use an Sqlite database you save in a git-note. But this is very much about a very specific use-case. And the last paragraph could have been written less salesy and more "don't try this at home, don't run with scissors kinda message".

So this is kinda the contrary to "use Postgres for everything" vibe. Consider using Git as an actual database if you were considering using Sqlite or simple text files, or consider actually wrapping those with Git because it will give you quite a bit of extra oomph with very little effort.

I personally used git as a database on a project where we had just 200 records. With infrequent changes. Some bulk updates. That needed, for weird reasons, to be synchronized every ~12 months, yeah, and some of the nodes were air-gapped. As far as I know, more than 15 years later this is still running with basically 0 maintenance (other than git being upgraded with OS updates).

Well funny story, some twenty something years ago I actually worked on an election cycle volunteer infra thing in France, and living in Paris which is department 75 and therefore 750xx the prefecture being 75000 I assumed it was neatly hierarchical 75004 won't be far away from 75003 (true)... The French thing being orderly and rational.

I didn't need much precision so truncating seemed an easy way to group stuff.

Oh the surprise. I never again made such assumptions, let's just say I should have gotten a clue from Corsica being 2A and 2B.

For those interested, the practice of debasement actually predates the middle ages by, a lot. By 301 inflation was so bad Diocletian had to put out a price fixing edict. It didn't work. It took Constantine's Solidus (basically solid gold coin - that will stay stable for almost a thousand years) to stabilize the currency. By the early fourth century the denarius that used to have 50% silver contained almost no silver at all (something like 1 to 5%).

Actually looks quite interesting. syntax looks like:

  fun
  | is_sorted([] || [_]): #true
  | is_sorted([head, next, tail, ...]):
     head .<= next && is_sorted([next, tail, ...])

  is_sorted([1, 2, 3, 4, 5])
  is_sorted([1, 2, 30, 4, 5])

a bunch of ways to express blocks, pattern matching and macros. The class facilities also look very nice. other than some indentation it doesn't feel pythony at all (which for me is a good thing!) more like an Elixir feel (cute syntax for some great concepts behind) see https://github.com/racket/rhombus/blob/master/demo.rhm

We are not big on free. We like money :) And people like that we will probably be around in a decade (and won't stop free as soon as we've locked enough people -in). We do have a no-strings-attached free trial ...

Also. As I am excited. Here you go for a one-click deploy .. https://github.com/OriPekelman/express-bun/ Very unofficial. Very.

Oh. Actually got released today .. so we also did https://platform.sh/blog/bun-support-is-here/

Oh its a Friday. Deploying on Fridays is what we do. Here you go ... Bun 1.0 officially deployed on Platform.sh https://platform.sh/blog/bun-support-is-here/ enjoy.

Well, it'a already been out for an hour ? Deploying on Fridays.

Composer is a simple but powerful CMS based on Pandoc, Bootstrap and GNU Make. From Gary of GaryOS. Gotta love the consistency. And gotta love the documentation of GaryOS.

Basically "Information theoretically" compression is a measure of informational distance. So basically if text A and Text B contactenated together, compress better than text A and text C it means A and B repeat more patterns. and are closer. All we need are some distance functions .. in a way you can think about it like Levenhstein distance but that can take into account inputs with very different sizes, repetitions, changes in order big inserts etc...

Reminds me of a mostly joke ruby project I did a decade ago https://github.com/oripekelman/simple_similarity

archive.org seems to side with the story telling of the Founder's counter-claim? January 2021 https://web.archive.org/web/20210128191225/https://withfrank... "We've helped over 350,000 people access financial aid resources" and https://web.archive.org/web/20210222193947/https://withfrank... February "4.25 Million students trust Frank." ... at any rate can't say the due diligence team did a brilliant job there... I mean they didn't bother to look at archive.org?

So, I do a have a war story about something like this, possibly at a worst state. And possibly with somewhat higher stakes (around 400m$/year) at the time. I came in as a consultant with my own "parallel implementation team". In my case I was somewhat lucky because most of the system was composed of batch jobs. They did have "frameworks" with "ORMs" but they had 4 or 5 of them, with many files being pinned to some older version. Which meant that actually there were dozens.

There were thousands and thousands of business rules no one knew why they were there and if they were still relevant. I remember one fondly. If product=="kettle" and color=="blue" and volume=="1l" then volume=1.5l... This rule like many others would run on the millions of product lines they would import daily. And the cutest thing in the system was that if any single exception happened during a batch run... the whole run would fail. And every run would take close to 15 hours (sometimes more).

Not going into details ... But they couldn't afford the run going over 24 hours... And every day they were inching closer.

Similar to OP they extensively used EAV + "detail tables" to be able to add "things" to the database.

The web application itself was similar but less of a time-bomb. It was using some proprietary search engine that was responsible for structuring much of the interaction (a lot of it was drill-down in categories).

Any change on the system had to happen live with no downtime. Every minute of downtime was $1,000 in lost revenue.

The assumptions we had were: 1. At some point the system will catastrophically fail so 100% of the revenu will be lost for a long time. 2. Even if it were possible to rewrite the system to the same specs (which it wasn't because no one knew what the system actually did) such a rewrite would probably be delivered after the catastrophe.

The approach we used was to 1. Instrument the code - see what was used what wasn't. We set some thresholds - and we explained to the stakeholders they were going to be potentially be losing revenue/functionality. And we started NoOping PHP files like crazy. Remember, whatever they did the worse thing they could do is raise 2. Transform all batch jobs to async workers (we initially kept the logic the same) - but this allowed us with 1# to group things by frequency. 3. Rewrite the most frequent jobs in a different language (we chose Ruby) to make sure no debt could be carried over. NoOp the old code. 4. Proxy all http traffic and group coherent things together with front controllers that actually had 4 layers "unclean external" - whatever mess we got from the outside. "clean internal" which was the new implementation. "clean external" and "unclean internal" which would do whatever hacks needed to recreate side effects that were actually necessary. The simple mandate was that whenever someone did any change to frontend code they needed to move the implementation to "clean external". 5. We ported over the most crucial, structuring parts to Ruby as independent services (not really micto-services just reasonable well structured chunks that were sufficiently self-contained). If I remember correctly this was something of the size of "User" and "Catalog browser" the other things stayed as PHP scripts. 6. And with savagery any time we got the usage levels of anything low enough.. we'd NoOp them.

Around a year in there was still a huge mess of PHP around but most of it was no longer doing any critical business functions. Most of the traffic was going through the new clean interfaces that had unit tests, documentation etc. I think that 100% of the "write path" was ported over to Ruby. A lot of reports (all of them?) and some pages were still in PHP.

I don't think anyone ever noticed all the functionality that went away. We had time to replace the search engine with Elastic Search. It wasn't clean by any means but it was sturdy enough not to have catastrophes.

The company was bought by some corp around that time... and they transitioned the whole thing to a SaaS solution. I was no longer involved for quite awhile so I only heard about it later. But we bought them that extra year or more.

So .. as far as recommendations go: 1. Instrument the code (backfire.io !) 2. Find bang for the buck and some reasonable layer separation and do it chunk by chunk. 3. Don't try to reproduce everything you have. Go for major use-cases 4. Communicate clearly that this is coming with functionality loss. 5. Be emotionally ready for this being a long long journey.

Well they have many offerings one of which is a PaaS https://www.ovhcloud.com/en-ie/web-paas/

Evidently any PaaS has to have _some_ opinions on the kind of apps it is going to run. You trade some assumptions against magic (and time you won't spend on making decisions that are very possibly trivial). You could very probably design some pretty complex applications on any PaaS worth its salt.. as long as you accept its assumptions, opinions . But when you do you might very well end up with the only actually achievable form of the original DevOps. Weirdly if Devs actually touch Ops it's probably no longer DevOps ... just people being cheap and asking other people to have two jobs for the price of one...

omg Koalapad. I totally forgot about that. And the very huge banners. and running out of ink after printing just one.

well, self horn here... but that is a basic functionality of https://platform.sh (CPO here). You get per branch full copies of production in isolated staging environments that are very cheap to run. So you just clone production to a specific branch apply whatever changes and grant access to the clone. ..you do need to run production with us for the magic though... and a PaaS is not for all use-cases (specifically when running a SaaS...).

I'd agree with the part of maintaining your own server. like personal one. I promised myself like 5 years ago I'll never be my own (and family and friends..) sysadmin ever again. ... but serverless needless mean tiny programs in nodejs. serverless is basically a super category for what we used to call PaaS simply saying the granularity of what you deploy can be smaller. it doesn't mean it has to be smaller. as far as I am concerned it can also be way bigger than what heroku represents. This is what composability on infrastructure means. It means you have the same interface to deploy a single line of JS... and a service that is itself composed of a couple of monoliths each with its own data backend. The "form of the program" should be dominated by the problem it solves not its deployment target. That is the thing we are trying to achieve at platform.sh where I run product. A uniform interface to a composable infrastructure. We are not quite yet there... this is not a trivial problem. And I don't think that "just ship your machine" Docker style solves this. To be really composable you need both finer grain and higher abstractions. What I mean is that at every level you compose you need to be able to define dependencies (my function requires this version of nodejs and this system lib) my already composed monolith that includes a dependency on MySql and Redis) is a dependency of this static site builder.. at each layer the semantics are very close. But not the same. Just shipping a container eludes these issues and basically reproduces the model of "good old servers" in a way this is contrary to what true serverless has to offer. Which is absolutely not caring at all about the runtime. And caring only about the design of your system such as that it espouses best the form of your problem.

try https://lando.dev/ uses docker under the hood... but simplifies it all to the extreme.

One of the cute things is, that I like Aral. I do, ever since he got mad at PayPal. I like him because he has been steadfast at this while many of the others that started to bang on this problem when it just appeared (2006/7/8) either joined the armies of Mordor .. (Chris Messina?) Or got tired... Distracted.. or are still fighting the fight from the sidelines (Evan Prodromou, Blaine Cook, such lovely people!). So many have just disappeared.

Yeah, his self-aggrandizing can be tiresome. He does sound like a one person cult from time to time. But he has been tireless in saying the one important thing "This fight can be won. Don't let up. It is worth fighting". And that in itself is worth our respect.

Now, I have long come to the conclusion that there are no technical solutions to this. Only political ones. In the sense that at the micro level we need to create the movement of people that care. At the macro level we need to elect the people that pass the laws that break the megacorps or make them into public utilities. It doesn't mean we stop working on the software infrastructure to combat the Evil empire(s). But software alone won't cut it.

Now Aral is not useless on those tlfights either. He keeps talking about them, and talks well.

So, will Site.js make any dent in anything? Quite obviously not. Personally, technically, most of it makes me cringe quite violently.

Could it have had a better chance if Aral was "nicer", humbler, at a bit better at coalition building? Probably.

At any rate, Aral, not being "nice" is no reason to be nasty yourself.

Best of luck Aral, keep up the fight, and thank you for your service.

There was a time my title was CTO, and I'd say to the devs, there is only one function in a company. Sales. Every minute you spend writing tests, is sales. Because at the end there is only one business model. More money in then money out. I'll frame it in a different fashion, often the issue is that developers believe that they are alone with in creating value. And that all of these sales and marketing clowns are just.... What you may probably come to understand is that.... you are a marketing person now! and that this does not make you a lesser person. Yes, you can still code. But your primary function had changed. And over a longer run... it will require you to gain new competencies. So how does a marketing person fit? simply. They are you.

OK. The plot thickens. https://www.phrases.org.uk/meanings/big-fleas-have-little-fl... so .. this is the phrase I remember. Probably the "motto" used by the SF author. Now I remember Peace on earth... and BTW à propos the article cited .. the spy bugs there have very partial vision .. and if I remember correctly they recompose scenes from the multitude of images... I think this is as far as I am going to get. Thank you!

Seriously? I am dry here. Could HN not be useful for once?

OK kids, I need help here. There was a sci-fi novel, probably the sixties, called something like "little bugs have little bugs on them". The premise was basically that.. A cold war where one side puts bugs on the bugs of the other side. Rings any bells? Potentially there were also some aspects of bug driven assassinations... But I am unsure. This thing been bugging me.