Hyped about json becoming a first class citizen. As an Elixir engineer and daily Jason user it will be great to rely on stdlib functionality. Jason is great, regardless!
I pivoted from C# to Elixir after a former manager (and now friend and co-founder) put me onto it as part of a project we were doing for a high volume eCommerce solution. I did another C# job after and then when the opportunity struck, I dove head first into full time Elixir development. I have no regrets. It feels like any problem I have can be solved with a bit of elbow grease and some proper thinking. Phoenix is a bit too opinionated for my liking, but I can't deny just how much more productive it is for me vs C#/.NET. All 'round, my career is the better for working with Erlang/Elixir.
This is legitimately great! Would love it if there was some sort of session persistence (even if it's just an array in localStorage of countries I've already covered.) that way I could play through all the countries without having to keep the window open. Simple and effective game! Nice job :)
Business logic in the database screams anti-pattern to me.
How do we know who created the rule, edited the rule? How can we reason about the sequence in which these rules are executed based on larger use cases with complex interactions.
> How do we know who created the rule, edited the rule? How can we reason about the sequence in which these rules are executed based on larger use cases with complex interactions.
You are presumably operating inside of a database, a place where the above concerns can be tracked in ~3 additional columns. More complex rule arrangements can be addressed with additional tables & relations. If you are starting from a blank schema, everything is possible. As noted by others here, you either go all-in, or all-out. The middle ground where half the logic is in the database and half is in GitHub is where things get yucky.
Consider the simplification angle. There are some techniques that allow for running entire apps directly out of the database. You might not even need Node, .NET, Go, Rust, etc. Hypothetically, if 100% of the things are in a database, you can simply record the binary log to S3 and have a perfect log of everything over time. Imagine how easy it would be to set up a snapshot of a given environment on a developer machine. Inversely, you could directly ship a developer's machine to production. You can also do some crazy shit where you merge bin logs from different timelines via marker transactions.
The other major advantage includes being able to update production while its live, even if production is running on a single box. I saw a particular PL/SQL install earlier in my career that was utilized for this exact property - production literally could not ever drop a single transaction or stop servicing them. Latency beyond 2 seconds could be catastrophic for system stability. Production could come down, but it had to be all or nothing. Think - shutting down a nuclear reactor and the amount of time you are locked out due to the subsequent safety and restart checklists. You absolutely need a way to safely & deterministically update in-between live, serialized transactions or you can't run your business effectively.
I'd say depends on the complexity of the logic itself. I would never write triggers with any logical branching, but for simple update table B when table A is updated? I definitely see the value in that.
At the point in my life where I read this book, I was a recent ComSci grad, I had already started working and it was clear to me that I needed some framework to understand where I was going. Not just in terms of software, but in general, I needed some north star as far as a process and an ideal to achieve were concerned.
Reading this book gave me exactly that. A clear, understandable framework that explained the progression from understanding how to do something, to being good at doing something, to being a master. While it didn't give me a step by step guide, the lessons in this book gave me ideals by which to work out my own trajectory, whether or not I felt at any given point as though the efforts I was putting in were guiding me towards mastery, but more so than anything, this book gave me patience. I read somewhere that (maybe just in my country, I can't remember) once you've been a software developer for 5 years, you have crossed over the median age of experience in the industry. As a younger engineer, I was impatient, in a rush to do Interesting Work™ and had no appreciation for how whatever I was doing at the current moment was perhaps exactly what I needed to do to get to what was important, which is mastery. That is to say, getting past the point of good to the point of exemplary, not just being a consumer or repeater of skills but a creator of them. I read this book in Year 1 of my software career, I am now in year 5 and I know that because of this book, years 10, 15 and 20 will bring more reward and more joy in deepening skill.
