Always open to human e-mails too
394 karma · joined November 5, 2014
Always open to human e-mails too
Open source has changed the life of so many, from so many situations. We should be proud of our industry. Together we built something beautiful
> “The billionaires of the world who want to flee increasingly high-regulation and high-tax countries are very welcome to come to Argentina, the new land of freedom,” Adorni said.
How true is this in practice? Argentina's income taxes are not low by any standard (35%), capital gains are not zero (15%), and there is a wealth tax if you hold foreign assets.
I happen to be Argentinean, and got out of the country around 2 decades ago because of the trouble and practical taxation when working remote for foreign companies.
I definitely like what this article says, but it doesn't seem to hold true at the moment? That said, I might be missing something, as I've been mostly detached from Argentina's economics and politics for a long time now.
You deploy using a Dockerfile, or Docker Compose.
Definitely suggest you give it a shot. The free plan is a no-brainer for the performance you get. We are on the team plan at https://www.sourcemeta.com
Assuming they bet on Claude getting much better at coding over time, couldn't they themselves cover their own needs with technology that they built themselves?
Is some sort of autonomy over technology they use somehow the goal here?
12 jobs per PR for up to 30 minutes running Linux, macOS, and Windows jobs on LLVM, GCC, and MSVC in static and shared builds with also some sanitiser configurations.
And consider across projects we might send dozens of PRs per week.
Right now it's somehow all fully free on GitHub Actions. I wonder what the same would cost on i.e. CircleCI
As somebody not very familiar with CAD/3D printing, etc how hard is it to produce it myself (couple units for personal use)? What would be the average cost? Did anybody do it?
No complains from it so far. People get it, book with success, and I run those calls on Proton Meet, which also proved to work pretty well.
There have been research in that area (i.e. https://link.springer.com/chapter/10.1007/978-3-030-34146-6_...) but usually the input set is too small or biased.
As a JSON Schema TSC member, I consulted with various organisations on large scale JSON Schema use, which is where things get truly interesting (>8000 complex interconnected schema data models) though all of them are sadly closed-source.
I'm a member of the JSON Schema Technical Steering Committee, and been making a living consulting with companies making use of JSON Schema at large. Think data domains in the fintech industry, big OpenAPI specs, API Governance programs, etc. The tooling to support all of these use cases was terrible (non-compliant, half-baked, lack of advanced features, etc), and I've been trying to fix that. Some highlights include:
- An open-source JSON Schema CLI (https://github.com/sourcemeta/jsonschema) with lots of features for managing large schema ontologies (like a schema test runner, linter, etc)
- Blaze (https://github.com/sourcemeta/blaze), a high-performance JSON Schema C++ compiler/validator, proven to be in average at least 10x faster than others while retaining a 100% compliance score. For API Gateways and some high-throughput financial use cases
- Learn JSON Schema (https://www.learnjsonschema.com/2020-12/), becoming the de-facto documentation site for JSON Schema. >15k visits a month
Right now I'm trying to consolidate a lot of the things I built into a "JSON Schema Registry" self-hosted micro-service that you can just provision your schemas to (from a git repo) and it will do all of the heavy lifting for you, including rich API access to do a lot of schema related operations. Still in alpha (and largely undocumented!), but working hard to transition some of the custom projects I did for various orgs to use this micro-service long term.
As a schema and open-source nerd, I'm working on my dream job :)
A lot of people are familiar with web technologies, therefore using something like Electron is way easier for them. That makes a lot of sense.
However, from an end user point of view, Electron (while potentially easier to developer with for a large pool of developers) doesn't feel native. You can tell you are running a web app inside that doesn't obey the OS conventions, the standardised OS shortcuts, looks different than the rest, etc. It's like it doesn't quite match and all the muscle memory you have for working with other native apps (mainly for keyword-heavy users like myself) just doesn't work, making it a frustrating experience. Plus many (not all!) Electron apps are super heavy weight and feel slow when you contrast them with other truly native apps.
Overall, I think you will see a lot of people that don't really mind Electron, but many do. I think it largely comes down to whether you want to develop a desktop app faster yourself, or deliver a desktop app that would satisfy almost every user out there (which might be harder to build).
And BTW, this is coming from somebody that worked a LOT with Electron, as the original author of Etcher (https://github.com/balena-io/etcher), plus I led the Desktop Team at Postman (https://www.postman.com, which is arguable one of the worst Electron apps out there, mostly due to really bad early architecture/business decisions) for a while. I tried everything but I gave up on it. It can never even be a good enough approximation to a native experience that many users expect.
In any case, great job with GitQuill. It does look pretty cool and I wish it was a native app!
100%. That's why I said "at least" and it's the feeling I have with Electron too. Electron apps (nor Qt ones) do not really feel native, and in that case, better to either go full native (so it doesn't feel like an imperfect approximation) or just deliver a web app that you can use on a browser?
The in-between ends up in a gray area that never feels quite right. But I agree it is in part a matter of style and expectations.
Though I also agree the Win32 look is terrible and outdated. GTK and Cocoa on Linux and macOS are really great and good looking native technologies. I've seen more and more projects target GTK on Windows instead of Win32 for this reason.
I work on high-performance stuff as a C++ engineer, currently working on an ultra fast JSON Schema validator. We are benchmarking against AJV (https://ajv.js.org), a project with a TON of VERY crazy optimisations to squeeze out as much performance as possible (REALLY well optimised compared to other JavaScript libraries), and we still get numbers like 200x faster than it with C++.
Quick questions for everybody here:
- How do you develop your apps right now, mainly cross-platform ones? QT? Would you enjoy a C++ cross-platform framework that binds directly (and well) to Cocoa?
- Are you using Electron? If so, would you appreciate premium modules for Electron that bring a lot more "native" Cocoa functionality instead of reinventing the wheel in JavaScript?
What would you wish a book on modern desktop app development would cover?
> Was wondering if JSON BinPack is a good serialization format to sign json documents?
Not sure what you mean by signing but let's connect. I would love to learn more. Can you find me on LinkedIn and/or e-mail?
It is still a heavy work in progress, but if anybody here is suffering from expensive Iridium bills, I would love to connect and discuss to make sure JSON BinPack is built the right way!
> By the way, in your dissertation you don't mention RapidJson, nor json.net, nor simdjson. Is there a reason why you didn't compare them?
My research was focused on space-efficiency more than parsing performance, so I didn't talk about that problem. However the long-term goal is that by using JSON BinPack's binary encoding, you should have a better time parsing it, as you don't have to deal with the JSON grammar.
Do you do JSON Schema validation too?