Go back two centuries… people said exactly the same about Impressionists. Then afterwards about Modernists. So on, and so forward.
Many artists went nowhere back then, others used their experiments to create masterpieces. It is always relative and it baffles me how some people only think about the masterpieces and big names, without looking the whole timeline.
Besides, generative and AI art are so damn cool :) It is something closer to us developers, but still far (not everyone knows how to implement it).
I guess if the user install, it should be able to play (haven't tried). But, because this would require extra steps, I preferred to just have the ST + VP9 to Firefox. In future versions, I could give an options page where the user can adjust this.
I don't have anything against meme GIFs: they are short and meant to be repeatable, so all good.
But, as I wrote in the post, I came across too many GIFs with demos, tutorials or animated diagrams on GitHub and NPM. This was the motivation to create GIFSane, as sometimes you want to stop in a frame, or go back to check a detail.
> The software engineering world adopted them for a particular use case: recording tutorials and demos.
Besides, the whole thing was done in the name of the hacking spirit hehe Perhaps, one day, GitHub will convert any GIFs/WebM files into video components (similar to what Twitter does).
Yeah, I had the same feeling that MV3 has been rushed and is not 100% ready. The other issue as well is that Mozilla and Google roadmaps are quite different, so you might end-up having to support both MV2 and MV3 for a while at least. And even then, Mozilla will have some different APIs on MV3 (albeit they will be extra APIs when compared to Chrome).
I am looking forward to see the state of things in December 2022.
That is interesting to be fair, I didn't know these APIs. Certainly something to have a look for either replacing WASM or for new projects.
I've considered using some JS libraries that are around for sometime (like https://github.com/buzzfeed/libgif-js), but the challenge of using WASM seemed more interesting in a hacking perspective let's say hehe.
I believe you mean that you can't easily do a "psql ..." or connect using DataGrid and similars, right?
Does this mean that devs need to copy the production database file locally to then inspect it? Or are there tools to connect/bridge to a remote sqlite file?
I think the usual approach would be to SSH into the server and run sqlite3 there. This issue [0] mentions some workarounds for connecting from DBeaver, which I assume would work for other graphical client software. I haven't tried those approaches, they seem pretty hacky and I imagine performance isn't great, but I guess that's to be expected given that SQLite isn't designed for that type of access.
> I believe you mean that you can't easily do a "psql ..." or connect using DataGrid and similars, right?
Yeah.
> Does this mean that devs need to copy the production database file locally to then inspect it? Or are there tools to connect/bridge to a remote sqlite file?
We use "kubectl copy" currently when we want to inspect it, and we haven't actually had to write back to a production file yet. We've explored the "remote" option, but since it's just a file, everything seems to boil back down to "copy locally" then "copy back to remote prod".
It's only a small part of our stack at the moment, so we haven't invested in tooling very much - but I'd be curious if others have solved similar problems.
Ah I see! Yeah, I expected your team would have to copy it locally. I wonder tho, in times of data leaks and whatnot, couldn’t it be dangerous to have lots of PII (personal identifiable information) copied around many dev laptops?
I mean, devs can do the same with Postgres, but it is more for backups instead of purely querying.
I love to see that more projects are using SQLite as their main database.
One thing that I always wondered though: does anyone knows a big project/service that uses Golang and is backed by SQLite? This because SQLite would require CGO and CGO generally adds extra complexities and performance costs. I wonder how big Golang applications fare with this.
Not a "big project/service" but a Go project that uses Sqlite is one of my own, Timeliner[1] and its successor, Timelinize[2] (still in development). Yeah the cgo dependency kinda sucks but you don't feel it in code, just compilation. And it easily manages Timeline databases of a million and more entries just fine.
Interesting project! It seems to be perfect for SQLite, considering it seems to be mostly for reads instead of writes. I wonder if heavy write applications are a bit of a trouble in Golang because of Golang goroutines x C threads model (which I believe SQLite might use?).
But well, it seems arp242 is GoatCounter's developer. Based on the post content, it is powered by SQLite and this is probably a good write-heavy application example. I wonder if there are any blog posts about the SQLite performance for this service.
CGO isnt too big a problem and if it is a real dealbreaker something like https://pkg.go.dev/modernc.org/sqlite will work as it transpiled the c into go and passes the sqlite test suite. I think there is performance degradation with writes but reads are still pretty quick.
Using https://github.com/mattn/go-sqlite3 for a pet project right now.
So far not a single issue with it, I never had to think about any CGO specifics.
As a author of a library that got rewritten by another team in go with a similar rationale, I must say that the Go ecosystem's unwillingness (or inability) to interface seamlessly with other languages seems like its greatest drawback.
Yeah, I used to develop in TI DSP protocol implementations and remote access was impossible back then. Besides, because I had to debug the DSP serial or CAN outputs, oscilloscope and test equipments were big requirements most of the time.
To be fair, if the company was ok, some of those I could have at home. But space would be an extra complicating factor (especially in cities like London hehe).
That is why I've changed to Hugo (from Hexo & Gatsby). It does exactly what is supposed to, it doesn't import any dependencies and it is quite fast. Besides, no runtime is required.
I thought about plain HTML, but writing blog articles with it is a bit of a pain. Hugo was quite the right balance.
Many artists went nowhere back then, others used their experiments to create masterpieces. It is always relative and it baffles me how some people only think about the masterpieces and big names, without looking the whole timeline.
Besides, generative and AI art are so damn cool :) It is something closer to us developers, but still far (not everyone knows how to implement it).