olebedev

I use iced, the idea behind is great - elm architecture. However, the attitude of maintainer that doesn’t bother to be involved in discussions in their discord and merge behemoth size changes with no review makes me think more and more if it’s a good choice.

I recently started looking at the xilem which is also elm architecture inspired abd being developed openly and with proper engineering practices, however it is at very early stages just yet.

This reminds me of dokku which is a great drop-in replacement of heroku for non-mission-critical web projects.

I don’t use it anymore since I use NixOS to have it all in infra-as-code paradigm but dokku triggers nostalgia of good old time when completely was at manageable levels.

No, we are not.

Right, then I am not surprised at all. I am looking at his github account now, his status is « твой софт — гавно» (direct translation: « your software — shit»).

To me it's a clear message that the author doesn't respect anybody. Also, it seems applicable to potential projects people will build using that Huly tool?

I guess my question would be -- how on earth it's possible people trust authors like this and commit into using product built by them?

As a person with russian background I am laughing on the name of the project. With all the respect to the effort, I can’t take it seriously.

The «хули» (direct transliteration to huly) means “what a hell” or actually a bit spicier “what a f@ck”. This phrase is common for russian tradies who don’t bather to know anything but where is the nearest bottle shop and how much time left til the end of work shift.

The name reminded me PizData project from the russian speakers.

What. A. Joke.

Hi, this looks awesome, thank you for exploring Nix capabilities, that is a great piece of software.

I am curious, what drives you using docker if images can be broken down into Nix packages?

Don’t get me wrong, the project looks really cool, and it’s a bit of a hassle to write orchestration using NixOS configuration utilising systemd.

Reminds me of aussue++[1] from a few years ago.

[1] https://github.com/zackradisic/aussieplusplus/

It’s too much of a hassle to move from it now, since I have alot on my plate and they don’t support any other GUIs (a classic vendor lock).

I have planned it for the second half of this year though.

Here we go again! I have been using it 15 years ago.

I am a user of Hey and what I can say is the UX is dreadful. I am seeing spinner way more than I can handle, really.

I assume this proposal is to moving backwards.

Instead we would need to sort of data on client and full-body client app, doesn’t matter if it’s for web, ios, android. And the data should be given back to us - users.

The problem with that is that services like Hey become a true commodity and doesn’t lock users by keep exclusive access to their data anymore. So it’s to be figured out what is the new business model.

Everything is setup with free plans and almost everything is automated via GitHub Actions.

Also, it recognises you as an owner and allows you modify the site.

Running a migrations on a server is far, far different to running it on every users' device. The sheer scale of it is different.

Well, it’s not only just that. Among the other things, some of the application instances would be outdated but still need to work, so you would need to support _all_ the DB schemes you have ever had for your app.

Yeah, sounds a bit overwhelming for users, but my point here us that we would need appropriate tooling to be offered to end users so they are not get lost (quickly lol).

I think we will end up with something like permissions grants (including granular JS APIs available for the website, as we do for the location, camera APIs etc, at the moment) per website and convenient tools built-in browser that allow you create/re-use patterns so you don't actually interrupted by this strictness too much.

In this article I would like to show how you can organize your golang web project with live code reloading. It scheme can be easily extended and will allowed to write couple of line in bash to get what you want.

Features: on the fly crop and resize for image/png and image/jpeg mimetypes cache strategy, based on HTTP Last-Modified header additional metadata for each file & aggregated statistic for it forced HTTP Content-Disposition header with the file name, for download links(only if flag is specified, see below) buckets(MongoDB collections) as separation level file listings for buckets, queried by metadata or without