redact207

I'll never be comfortable with any tool for that automatically generates schema changes, as I'm just never sure at what point it decides to delete parts of my prod db.

All of my migrations are dumb DDL statements rolled up into a version. I know exactly what the final state is as it gets run and used when integration testing, staging etc.

It's boring but pretty bulletproof. I can rename a table and be confident it'll work, rather than some tool that might decide to drop and create a new table.

I can also continue to use SQL and not have to learn HCl for databases. This is useful when I want to control how updates are done, if I want index updates to be done concurrently Vs locking the table.

It depends on your retirement goals. Some people prefer the "financial independence" aspect in order to have the freedom to do or work on things they're interested in and brings them happiness rather than for the sake of just money.

I feel your pain. I'm a .net guy who transitioned to typescript 5 years ago.

If I may, could I suggest Firebase as something to consider? It has automatic offline sync over indexdb, and you can subscribe your app to data changes to sync all devices etc.

It takes about a day to get your head around how it works, and given your use case you probably just need the Hosting, Firestore + Auth modules.

I use it a lot now in my side projects and it has been life changing in terms of taking away all of the boilerplate code and letting my just write app code.

When she does it, take the juice away and say it's for drinking, not spitting. Explain why spitting is unacceptable to you.

If she goes crying to her mother, her mother should back you up.

She can have her juice back once she agrees to drink it and not spit it. If she does it again take it away for a longer time and repeat.

Physical violence is not needed, you don't treat adults that way, children are people too.

May I ask how you discovered those two profitable niches? Did you already have contacts working there that just told you about it or did you go about hunting it down somehow?

Jq makes life easier. I'd say for complex output, using filters is more readable than using awk to extract random positions of substrings

I think you're underestimating your talents. A technical writer with a development background, when applied correctly, is a powerful force.

You have the ability convey complicated concepts in a concise manner. You can do so much with that. Is there something in your tech world that you're interested in, that's hard to grasp, that you could start your own blog/YouTube/ebook/course with? Perhaps you'll become the goto expert on it.

I often wonder how the oracles in our industry get to where they are, and everyone starts and persists - often for years - before being recognised as such. Small consistent progress over a long period of time is what makes an overnight success.

I don't quite agree with much of this article. It paints the industry with a broad brush and not everyone has had the same experience - least of which me. The article starts:

> The shift from building applications in a monolithic architecture hosted on a server you could go and touch, to breaking them down into multiple microservices, packaged up into containers, orchestrated with Kubernetes, and hosted in a distributed cloud environment, marks a clear jump in the level of complexity of our software. Add to that expectations of feature-rich, consumer-grade experiences, which are secure and resilient by design, and never has more been asked of developers.

Comparing the most complicated way to build and run an app with something that isn't as complicated is just a straw man. Today you can still build a simple, monolithic app and deploy it into a completely managed service. All the points raised address certain problems:

  - microservices - sliced out of a monolith when complexity or scalability becomes difficult
  - containerisation - deploy an app with all of its dependencies down right down to the OS
  - orchestration - ensure reliability when pods/tasks fail, rolling updates, commoditize hardware 
  - distributed cloud environment - remove the need for on-prem, or have the ability to elastically scale without monthly VPS commitments
  - secure & resilient by design - apps that make money should have good uptime, not leak data

None of those are mandatory for all apps - it's pick and choose as and when you get the need. But also what is the alternative provided from "years ago" when things were seemingly simpler?

  - microservices - ever tried keeping velocity when building XMLSOAP based apps?
  - containerisation - write a bunch of ansible scripts or maintain disk images that can be sent to server fleets with bash scripts, else more scripts to apt-get/apk install stuff. On windows before package managers? enjoy shipping zips and exes with your code.
  - orchestration - scripts?
  - distributed cloud environment - build your own datacentre if you're big enough, lease out some racks if your not and have a systems team maintain them, patch them, RAID stripe disks and swap out dying infrastructure; or sign up to managed VPSs and raise a requisition order each time you want a new server that'll take a week to go through.
  - secure & resilient by design - a lot to do for a 6-9s uptime; so just lock down your release process with a ton of bureaucracy and approval gates by different teams. not releasing is great to improve uptime SLAs.

I don't have a good impression of the "good old days". The complexity was always there, it was just managed by different teams.

The real question is should a software developer need to know and work across all of these things, or are people who no longer have "systems management" job move into DevSecOps and augment a software team?

Can this ever be answered?

Everyone has their own personal circumstance and reasons for wanting to work in the office, home or hybrid. Ultimately employees will choose what suits them and given nowadays a lot of companies offer the choice of remote, will see people shift if that's what they want.

Remote will become an accepted and standard way of working, and I hope local communities will benefit and thrive from having a local hub of workers.

Decent list and a nice way to educate whilst pitching your product.

A lot of these points are applicable outside of Fintech. If you have any type of data that if leaked could ruin your business then it's worth a look over.

woah, you guys have any openings?

I find people hate/are ok with ORMs based on how they're used.

If you're using it to ad-hoc query your db then it's understandable you'll hate it - a leaky and poor abstraction over sql. Probably a bad fit.

Projects where I've seen it work well is when most of the logic is in the app with per row/per aggregate changes. In these apps it's only used for the "object relational mapping" side of things - ie to marshal types to/from db rows.

I've never found auto-migrations in ORMs good for anything less than a 1 day project - it's a world of hurt.

I'm a fan too, but as the seasons roll on it's hard to believe the guys are shocked or embarrassed about anything they do at this point. It's starting to feel like the scripted reaction vids from instagram

The thing that made my code 1000% more readable has been code reviews with a team that gives a damn.

When reading their code I'll add feedback to parts I don't understand (why do we need this cache invalidation, why do we use a worker pool here instead of throttling requests etc).

I find that questioning sits in the back of my mind when I write code - almost like a pair coder - to the point that I try to preempt questions like this by adding it as a comment.

Similarly for anything that's publicly accessible like public functions/properties/interfaces/classes, my goal for codedoc comments is to prevent the consumer (me or my team) from having to open the code to see what it does and how to consume it. If they can use it with just intellisense then it's a win.

Just like code readability and design, I'm seeing comments as another tool to communicate intent that can't always be communicated by code alone.

Is this basically just an apple flavoured meringue?

To quote the author: "it depends"

If when something happens needs to fold into your business logic then by all means go for it.

If you're moreso doing it as an audit then logging out the event with it's context is going to be more useful.

We're just at a point in the economy where it doesn't make sense to hold on to cash. It's just completely losing its value thanks to a long sustained QE.

People are just putting their money into anything as a hedge - real estate, stocks, crypto, gold. Until the value of the at can be sustained and inflation comes back, it's unlikely much else will change.

Thanks I'll probably use this. I often want to get a static uuid - usually for adding as static data in a test.

Funnily I find that the new and the shiny is a rebranding of the old and the stable. The difference is a new language + name + platform. I think this is an endless cycle as we see new developers come in and discover old concepts in new frameworks.

Once you've been through a few of these cycles it's easy to get jaded and burnt out, which is when older Devs may push back on the new. I don't think it's because they're changed adverse, just that they doubt the benefit of doing something they already know in the flavour of the month framework/language.

I'm guilty of all of this and have been through several burn outs. Nowadays I accept that everything will always be changing, and to keep an open mind to avoid dismissing things that are truly revolutionary.

The DDD books are such a godsend when approaching complex business domains and how to build software for them. I wish they taught that stuff back at college rather than all the curriculum stuffers.

"switch expressions", "text blocks". I haven't used Java for 15 years but it's one of the most mature languages out there. I'm surprised it's only just getting these pretty standard features now.

Blockchain can be useful outside of crypto, or even leveraging crypto for anything that needs trust.

Example: you might take a fingerprint of a recorded interview and save that to a block chain. When you distribute the interview the receivers can verify it hasn't been tampered with based on the fingerprint and when it was added to the chain.

This way you don't need to trust the source of the video or the person giving you a fingerprint, as that's stored immutably.

I think you're being downvoted because you're implying monoliths don't require an engineering culture and that microservices are a silver bullet in getting systems built correctly.

I've seen good and bad in each approach. It's certainly possible to enforce good SOCs and proper boundaries in monorepos, and also possible to plough a system into the ground with microservices.

They're all just tools in your toolbox and both have a part to play in modern development.

this just sounds like eventual consistency which can form part of a perfectly optimal design

One great thing about not enforcing FKs is that it makes integration testing a lot easier. You can load just the data you need to test with, and none of the FKs need to point to rows that exist that aren't within the testing scope.

This approach isn't for everyone. It works well with DDD where aggregates form contextual table boundaries and is eventually consistent by default.

This was a great read, thanks.

I've used svelte for one site that ended up being a good fit. Ended up using Sapper to build out the static site and was pretty impressed with the load times

I've used Jenkins in a few places, right back from when it was Hudson. Back then I was amazed at the concept of CI in general so it was pretty great.

Over the years I've worked with most of the major players, most recently Gitlab CI. The one thing that makes it hard to go back to Jenkins is the poor quality of the plugin ecosystem. So many are abandoned or buggy that any upgrade comes with a breath and a prayer.

I'm probably gone for good. Appreciate everything they did for the industry but there are more robust choices around.

I find it sadly ironic that the industry that's responsible for most emissions and actively influences political position in this country to put profit before the environment is the one that this zero emissions car is being targeted at.

With that said, bravo on the implementation and using the 79 as a very solid platform. The sales pitch of the article doesn't sound very compelling though, so I wonder how much success they'll have. Until they can hit a cost parity with diesels, it could be a bit of a slog.

Try just getting a traditional "Kopi C" with some Kaya toast, that's probably your sugar needs for a day. Then add in the sugar-water soaked fruity, plus the added sugar in most hawker food and you're not exactly on a stunning diet.

I lived there for 5 years and my word it was tough to cook for yourself. Lucky I lived near a wet market, but otherwise your choices aren't greay