I found the documentation extremely lacking last time I looked at Swift 2 or 3 years ago. Any changes there?
Or perhaps there's somewhere outside of Apple's own docs I should have been looking?
The feeling of reading through those crazy JVM stack traces with classes named "hudson" from the Jenikins prototype... I shudder! Well done for pushing through it all!
But, since this particular set of data is so well-defined, and unlikely to change, roll your own is maybe not crazy.
I think that's the trick here. A relational database lets you do a whole bunch of complex operations on all sorts of data. That flexibility doesn't come for free - financially nor performance-wise!
Given:
engineering chops
a firm idea of the type of data
a firm idea of the possible operations you may want to do with that data
then there's a whole range of different approaches to take. The "just use Postgresql" guideline makes sense for most CRUD web systems out there. And there are architecture astronauts who will push stuff because they can, not because they should.
Every now and then it's nice to think about what exactly is needed and be able to build that. That's engineering after all!
I think you've done a fair summary that deconstructed the simple narrative of "evil corporation steals from the poor". Well, for me it did ;)
to me this clearly looks like a "different culture" problem.
That is a key point. To me it is surprising that a developer of such supposed seniority was not aware of (or doesn't care about, or is so pushed for time, or just insensitive to?) the culture differences. That surprise made me jump to conclusions, leading to outrage and frustration.
Deep in my soul I believe Microsoft really is an evil corporation that steals from the poor.
But in this specific instance, your summary made me think of Hanlon's razor.
(they're somewhat unpredictable too - wait what? Why are you downvoting that?! 😂)
I had nothing but positive reaction the the dotnet and MAUI communities.
Ha yes know exactly what you mean. The ActivityPub system I've written (from where you'll receive this reply) just drops any Like/Dislike activity altogether!
I am giving a talk next week about making the most of the Fediverse
The spirit of link aggregations sites and forums in general is to share ideas and foster discussion.
This post is promoting an event. There are no ideas and there's nothing to discuss.
Perhaps wait until after you've given your talk and then share a link to a recording/transcript of it?
"A failure to plan on your part does not constitute an emergency on my part."
Wow now that is a quote I'm going to steal. Wondering if "A failure to understand on your part does not constitute an emergency on my part." has the same punch or is as relevant... anyway, thanks for sharing!
Long answer: I did this on a production system about 2 years ago.
The system was using MySQL, which was served from 3 virtual machines. Nobody took responsibility for that MySQL cluster, so outages and crazy long maintenance windows were normal especially as there was no DB admin expertise. The system had been hobbling along for 3 years regardless.
One day the company contracting me asked for help migrating some applications to a new disaster recovery (DR) datacentre. One-by-one I patched codebases to make them more portable; even needing to remove hard-coded IP addresses and paths provided by NFS mounts! Finally I got to the system which used the MySQL cluster. After some digging I discovered:
The system was only ever configured to connect to one DB host
There were no other apps connecting to the DB cluster
It all ran on "classic" Docker Swarm (not even the last released version)
My ex-colleague who I got along really well with wrote 90% of the system. They used a SQL query builder and never used any DB engine-specific features. Thank you ex-colleague! I realised I could scrap this insane not-actually-highly-available architecture and use SQLite instead, all in a single virtual machine with 512MB memory and 1vCPU. SQLite was perfect for the job. The system consisted of a single reader and writer. The DB was only used for record-keeping of other long-running jobs.
Swapping it over took about 3 days, mostly testing. No more outages, no more working around shitty network administration, no more "how does the backup work again?" when DB dumps failed, no more complex config management to bring up, down DB clusters. The ability to migrate DB engines led to a significant simplification of the overall system.
But is this general advice? Not really. Programming with portability in mind is super important. But overly-generic programs can also be a pain to work with. Hibernate, JDBC et al. don't come for free; convenience comes at the cost of complexity. Honestly I'm a relational database noob (I'm more a SRE), so my approach is to try to understand the specific system/project and go from there. For example:
I recently saw a project that absolute didn't care in the slightest about this
and used many vendor specific features of MS SQL all over the place
which had many advantages in terms of performance optimizations.
Things I would want to learn more about:
were those performance optimisations essential?
if so, is the database the best place to optimise? e.g. smarter queries versus fronting with a dumb cache
are there database experts who can help out later? do we want to manage a cache?
Basically everyone always advises you to write your backend so generically with technologies like ODBC, JDBC, Hibernate, ... and never use anything vendor specific like stored procedures, vendor specific datatypes or meta queries with the argument being that you can later switch your DBMS without much hassle.
Things I would want to learn more about:
how many stored procedures could we be managing? 1, 100, 1000? may not be worth taking on a dependency to avoid writing like 3 stored procedures
is that tooling depended on by other projects already?
how much would the vendor-specific datatype be used? one column in one table? everywhere?
does using vendor-specific features make the code easier to understand? or just easier to write? big difference!
I'm sure Microsoft has some good devs that are a net benefit to the open source projects they use, but this is not one of them.
Found the guy who created the FFMpeg ticket on LinkedIn. Job title: "Principal software engineer at Microsoft", saying they are "A detailed, analytical Software Engineer with Eighteen years of experience". 18 years?! Fuck me dead...
Found the guy who created the FFMpeg ticket on LinkedIn. Job title: "Principal software engineer", saying they are "A detailed, analytical Software Engineer with Eighteen years of experience". 18 years?! Fuck me dead...
Super interesting. It's a discussion from a point of view I hadn't considered before: how bandwidth has increased much more than CPU performance of web apps. I felt this in a way as my main computer until recently was a mini PC with the an Intel i5-5250U processor. Despite my Internet connection going from a 10mbps link to a 300mbps link, and pings dropping from 25ms to <5ms, browsing the web on the device became unbearable.
I imagine part of the challenge going forward would be the hordes of programmers brought up on designing UIs using a DOM, and all the associated tooling.
My prediction is the situation could be similar to how today many text-only programs assumes a terminal-like device. Terminals have been obsolete for years but I personally feel it's a ball-and-chain on text UI development. The web document model could persist long after web browsers are a kind of "terminal" to load and render web documents.
So-called "backend" I was OK with. HTTP is well-specified. It's a too general of a protocol what it's being used for, so you're stuck implementing the same stuff over and over again. When using SMTP or NNTP you realise how much work the protocol does for you when building systems on top of it.
But "frontend"... Jesus talk about abusing something that was never designed to be used like it is. Total nightmare in my opinion! UIs which are totally inconsistent in appearance and behaviour has somehow become the norm!
Spreading awareness of using git how it's actually designed to be used is cool to see.
I'm not clear on how I'd send patches to a repository hosted with ayllu. For example with the repo ayllu, they list codeberg (to which you can't send patches) and sourcehut (which uses lists.sr.ht). So... is ayllu really "email-based"?
Can anyone else see any other way to communicate via email?
As someone who never did much web development, I was... surprised... at the amount of tooling that existed to paper over this issue. The headaches which stood out for me were JavaScript bundling (then you need to choose which tool to use - WebPack but then that's slow so then you switch to esbuild) and minified code (but that's hard to debug so now you need source maps to re-reverse the situation).
Of course the same kind of work needs to be done when developing programs in other languages. But something about developing in JS felt so noisy. Imagine if to compile Java or Rust you needed to first choose and configure your own compiler, each presenting their own websites with fancy logos adorning persuasive marketing copy.
I don't see much points in your page, when something like MDN is available,
Yeah this is a thing that started to irritate me when I was working on JS projects.
So many articles written all describing stuff - not always correct - that is answered by reading standard documentation.
I just kept MDN, Node, React docs open all the time. But working with existing code I kept needing to deal with copy & pasted stuff from blog spam.
but I don't think I've ever gotten a job from LinkedIn, now that I think about it.
Yeah that was it for me. I got loads of messages from recruiters but they were really low effort communication. I even put in things like "INCLUDE THE WORD GLENDA IF YOU READ MY PROFILE" near the top of my profile/experience section. Out of the hundreds of messages, I'd say fewer than 10 actually wrote "GLENDA"!
The conversations I did end up having were shitty anyway. Essentially I think the world got software fever over the past few years and it's only just recently cooling down.
People going into recruiting without any people skills, let alone industry knowledge.
Companies desperate to hire people for no reason, including people who just did that "Quit your job and start coding!" nonsense.
I found the documentation extremely lacking last time I looked at Swift 2 or 3 years ago. Any changes there? Or perhaps there's somewhere outside of Apple's own docs I should have been looking?