adamkl

The Mitsubishi Outlander PHEV is very good (and is available without a wait). It differs from some of the other PHEVs in that it is really an EV (with 2 electric motors) and uses the gas engine primarily as a generator. This means it drives like an EV (no transmission, no power bands, just smooth acceleration at all times). A downside is that when running on gas, it's not as efficient because of the losses of going from mechanical energy to electrical energy back to mechanical, but I regularly get 70-80km on a charge, so the engine only kicks in on long weekend trips.

Related: https://www.destroyallsoftware.com/talks/boundaries

Also related: https://www.manning.com/books/grokking-simplicity

If you like these notes, you should read the (very good) book:

https://www.manning.com/books/grokking-simplicity

That’s my point. FP can be as simple as that, and applied to any codebase. It’s all the extra stuff (which is good) that typically “defines” FP that scares people away, and keeps them from seeing the utility of a simple, pure function.

Perfect is the enemy of good. I’ll take any percentage of pure functions that I can get.

It’s true that people don’t do it, because of language conventions, but there is no barrier to entry when it comes to writing functions (or methods in these languages) that operate solely as transformations of inputs to outputs. You then orchestrate these “pure” functions with simpler side-effectful methods that handle the external dependencies (data fetching/writing etc).

There’s no pushback because of “strange” FP patterns, code looks just like normal imperative code, but the tricky logic can be isolated in pure functions. The push back is only because of the strong OOP conventions.

I’m my opinion, how to win would be to push for more logic in stateless functions, full stop.

This can be done in any language without introducing “foreign” FP patterns and instantly makes code easier to understand and test.

Agree, but it helps to remember that it’s a product of its time. Feels like we’re overdue for a similar piece poking fun at Node/JavaScript and all of its foibles.

I've always enjoyed this one: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

I always enjoyed this one:

https://aphyr.com/posts/353-rewriting-the-technical-intervie...

Much higher level than a System Analyst. Enterprise Architects often work directly with the CIO/CTO to shape an organization’s long term technology strategy (i.e. 5+ year time horizons).

The idea being, they are supposed to be “architecting the enterprise”.

Enterprise Architecture is a very different discipline from software development (and even solution architecture), and are usually found in non-tech organizations (i.e. banks, insurance companies, etc).

EA is focussed on evaluating the business processes and technical solutions that make up the operations of a large scale organization. They try to identify and remove redundancy (e.g. multiple billing systems) and ensure the solutions in place (custom internal, or vendor purchases) are fit-for-purpose from technical, business, and strategic standpoints.

It’s very far removed from the practice of software development (since the correct solution, from an EA standpoint, might just be to stitch together a handful of vendor systems and do away with custom development completely).

I've found this essay to be a good shortcut to Lisp "enlightenment" without having to put in the effort of actually learning/using Lisp:

https://stopa.io/post/265

The term for this that I have come across is "stratified design" and goes back to the book Structure and Interpretation of Computer Programs by Abelson and Sussman. I have no idea why this approach isn't more well known (especially compared to typical "layered" design approaches) as the benefits are so great!

https://medium.com/clean-code-development/stratified-design-...

It was a general comment about frameworks. It’s possible to have a framework that includes all the “batteries” but has idioms and conventions that promote simplicity and maintenance.

Rails chose idioms and conventions that prioritize speed at the cost of complexity. The “included batteries” are not the problem.

I like that quote, but it's the Rails idioms and conventions that make hairballs, not the fact that it includes a bunch of batteries.

Sounds like “create-react-app”. A bunch of libraries and configurations wrapped up in a “golden-path”.

Provides the “easy” for 95% of usecases and an “eject” button that unwraps everything and puts it under you control for the last 5%.

Agree. There is a lot of value in the "easy, batteries included" solution which is why Rails gets so much love from the start-up community. The problem always seems to be that the same things that makes Rails easy to get started with (cough ActiveRecord cough) also make it easy to create foot-guns in the future (provided your start-up lasts long enough to get to that point).

Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.

Late to the party here, but what you propose is not being cheeky.

Rich Hickey (Clojure creator) himself has a similar, interesting, and compelling take on time and mutability [0]. This perspective is the underlying basis of Datomic.

[0] - https://youtu.be/ScEPu1cs4l0

Reading this makes me think of "stratified"[0] design, which I think is a good example of abstraction done right.

[0] - https://medium.com/clean-code-development/stratified-design-...

This is great!

I’m a big fan of Clojure and it’s REPL-driven workflow, but most of my day-to-day work is in JavaScript.

I’ve tried to use Quokka [0] in the past to recreate the REPL experience, and while it’s a good tool, it’s just not the same.

Really looking forward to trying this out!

[0] https://quokkajs.com/

I guess if the concern is around atomically committing to the DB and event stream at the same time, you could hang the event stream off the DB using change-data-capture to populate the events.

Ultimately, whenever you are pushing data between systems you can end up with inconsistencies which why it’s important to clearly define systems of record.

It is possibly that you could get inconsistencies between systems, but you mitigate that with durable event streams (e.g. Kafka) and by ensuring that each data entity in your enterprise has a system of record that can be used to resolve conflicts.

This is really not that different than using ETL jobs to move data about, but taking a streaming approach vs a batch approach.

I like the idea of using “fat” events as a means of data integration between systems.

Calling them RESTful events is a good term as I’ve pitched in much the same fashion. Every time a system responds to a create/update/execute request, drop an equivalent message into an event stream. Initially these can form the basis of a streaming ETL to whatever systems you use for analytics, but as new internal systems are brought online (e.g a new CRM system to help sales manage all the leads signing up for your successful product) the integration is already there, waiting. Just add a new consumer to the existing stream.

Overtime, you end up with a “data mesh”. If you look past the marketing of the term, it’s basically just means each application in your company should publish both sync (for real-time usage) and async (for data sharing between systems of record) interfaces.

You beat me to it by seconds!

Lots over overlap here with Clojure’s Extensible Data Notation (edn).

Over the years javascript has really evolved into a multi-paradigm kitchen-sink of a language, and because of its nature and evolution, there really isn’t such a thing as “idiomatic” JavaScript or widely agreed upon approaches to architecting a system.

From what I’ve seen, the architecture of a particular Node.js system is highly dependent on experiences of the team members that first built it. It could a hexagonal/DDD using a framework like Nest.js (the Spring Boot of JavaScript) or take a more FP approach using Express and looking more like Clojure/Ring. More often then not though, Node.js applications lack any sort of predictable structure because for a lot of teams, JavaScript is their first, and only, experience.

Long story short, I’ve been doing Node.js for 5-ish years now, and I have yet to come across what you are looking for. Every team/codebase is a unique snowflake in some way. Your best bet is to leverage the experience you have in Java/Clojure because JavaScript will be able to support 90% of whatever approach you decide to use.

Said lectures on YouTube: https://www.youtube.com/playlist?list=PLSE8ODhjZXjbohkNBWQs_...

A great way to learn more about the inner workings of databases, and entertaining too.

Another choice quote (from one of his lectures):

“There’s only two things I care about in life:

1. My wife

2. Databases

I don’t give a f#ck about anything else”

I remember using Buzz back when I was in university around the turn of the century. Lots of great memories with that one.

I came across an excellent modern alternative when my kids started getting into electronic music. It’s called SunVox [0]. Still under active development and runs on just about anything! Lots of fun!

[0] https://warmplace.ru/soft/sunvox/