Not currently but we have an internal tool that does bi-directional syncing using Postgres's replication protocol and WAL2JSON. It's not quite ready for prime time but we're hoping to get it into people's hands soon.
Ocaml is developing quite well.
I wish we could simplify the readability of the language. Reason comes pretty close to this.
And a nice django clone in ocaml/reason would lead to a lot of traction
As long as the algorithm is open source and the design can be agreed upon by both parties.
You may still need a human to make some decisions that feed into the algo. If not you’re probably not doing anything new in which case an algo is anyway better.
This won’t work in positions where you’re expected to work with ambiguity and bring order out of chaos though I’d be interested to think about how that can be quantified.
It really comes down to being transparent and clear. Humans can do it too, machines can do it better.
It depends on the context. Many of Amazon or Tesla's workforces do low-skill work, and each employee isn't bringing in all that much revenue. For software-only companies, this could indeed be an intersting metric aside from just margins.
The best thing to do in this scenario is to go ahead and interview in a few small companies and startup’s. At least 6 interviews ideally
If you have no professional experience yet apply to companies asking for 1y experience. They are still open to fresh graduates and even if they’re not for that role they could open up an internship opportunity.
Don’t prepare for the first three interviews, just treat them as practice.
Prepare a little bit for the next three.
Internships are great if you want to experiment and see what you like. Do a couple internships in different kinds of roles or industries based on what you’re interested in.
Start interviewing without expecting to get a job or preparing. This will allow you to be less stressed during the interview and you will be able to learn better.
Treat interviewing like learning a new programming language. Start with a hello world.
Author here (I'm a bit late!): indeed Griffe's goal is to be able to support any Python code, natively or thanks to extensions. Thanks for sharing by the way!
https://dbeaver.io/ is an open source tool with community and commercial builds that's quite mature and capable. I don't like SQL or database administration very much so it's become my go-to utility if I need to look at an unfamiliar DB. I've never had any problems with it though I keep a copy of SQL workbench around as it seems to perform better on large projects.
I've been writing SQL for so long it's second nature. I have tried these GUI tools from time to time but for me, nothing beats just writing SQL in a text-mode window. I use emacs and whichever sql mode is appropriate for the database I'm working with.
If I don't understand the data model well enough to know how to write joins to get what I need, I have never found that a GUI helps me very much.
I think one big advantage of GUIs is safety. There's no shortage of people who accidentally typed a bad command in production.
GUIs usually don't let you operate on anything you can't see, so it's harder to do the wrong thing by selecting something without looking at it.
Like with dd, you can type /dev/sdWrongDrive and never see anything about the device. With a GUI you will click a button that says "Root Device: 67GB free of 128GB" and instantly see it is not your blank SD card.
I have not seen a GUI tool of this sort that is substantially safer than a command line tool. If you're letting users do things like deleting or altering production data with any kind of ad-hoc tool, you've got a bigger issue than what the specific tool is.
Judging by meme threads, and comments on them, it seems like unfortunately nobody got the memo that it's a bad idea.
The usual issues are things like a select without a WHERE, least with a GUI, the tool can ideally do a select before any modifications happen, and say "You're about to affect 39482 rows out of 39482 total".
I suppose you could do things like parsing the SQL, figuring out the intent, and generating the select call, and throwing an error if it can't pre-check things on the CLI, but GUIs also have a speed bump effect that keeps the confident power user types from moving faster than their heads, and different expectations.
People seem to expect command line tools not to have layers and layers of confirmations and hoops to jump through, and the people who want this stuff probably prefer a GUI.
Not a tool but Django admin has also a similar concept. You define the models as Python classes and it provides an abstract CRUD user interface. It also supports one-to-one or one-to-many joins, so you don't have to generate or write a CRUD app from scratch.
