cheradenine_uk

Hehe "shenanigans" ;-)

The truth is, most things can be made to work - though there are various trade-offs ("shenanigans") involved.

e.g: In my current project, there's a bit that loads large-ish files, parses/converts the data, and loads them (order of tens of thousands of rwos) into SQL tables.

For reasons that best escape me - since after the files are parsed the entire dataset is _literally_ in memory, instead of doing a bulk sql update there- and then, thousands of messages are enqueued to be consumed by a practically unlimited number of lambda functions that then... bomb out as the SQL database hits it's connection limit and keels over.

I guess those shenanigans have better buzzword compliance!

I know, right?

It's also perfectly possible to split those things up, and to have them share the same database.

This causes microservice extremists' heads to pop off..

I think my point is more that you end up having to pay the costs (of Rx-style APIs) whether you need the scalability or not, because the libraries end up going down that route. This has sometimes felt that I'm being forced to do work in order to satisfy the fringe needs of some other project!

And sure, if you are living in a single-threaded environment, your choices are somewhat limited. I, personally, dislike front-end programming for exactly that reason - things like RxJS feel hideously overcomplicated to me. My guess is that most, though not all, will much prefer the loom-style threading over async/await given free choice.

This.

Writing the sort of applications that I get involved with, it's frequently the case whilst it's true that 1 OS thread/java thread was a theoretical scalability limitation - in practice we were never likely to hit it (and there was always the 'get a bigger computer').

But: the complexity mavens inside our company and projects we rely upon get bitten by an obsessive need to chase 'scalability' /at all costs/. Which is fine, but the downside to that is the negative consequences of coloured functions comes into play. We end up suffering having to deal with vert.x or kotlin or whatever flavour-of-the-month solution is that is /inherently/ harder to reason about than a linear piece of code. If you're in a c# project, the you get a library that's async, and boom, game over.

If loom gets even within performance shouting distance of those other models, it's ought to kill (for all but the edgiest of edge-cases) reactive programming in the java space dead. You might be able to make a case - obviously depending on your use cases which are not mine - that extracting, say, 50% more scalability is worth the downsides. If that number is, say, 5%, then for the vast majority of projects the answer is going to be 'no'.

I say 'ought to', as I fear the adage that "developers love complexity the way moths love flames - and often with the same results". I see both engineers and projects (Hibernate and keycloak, IIRC) have a great deal of themselves invested in their Rx position, and I already sense that they're not going to give it up without a fight.

So: the headline number is less important than "for virtually everyone you will no longer have to trade simplicity for scalability". I can't wait!

I think a lot of people are missing the point.

Go look at the sourcecode. Look at how simple it is - anyone who has created a thread with java knows what's happening. With only minor tweaks, this means your pre-existing code can take advantage of this with, basically, no effort. And it retains all the debuggability of traditional java thread (I.e: a stack trace that makes sense!)

If you've spent any time at all dealing with the horrors of c# async/await (Why am I here? Oh, no idea) and it's doubling of your APIs to support function colouring - or, you've fought with the complexities of reactive solutions in the Java space -- often, frankly, in the name of "scalability" that will never be practically required -- this is a big deal.

You no longer have to worry about any of that.

I feel similarly - though I think it's more the case that Java considers things a lot longer and considers the implications before simply adding them.

Java needed string interpolation forever before _finally_ getting something. There are parts of C# that I think are going to look like a good idea at the time, but turned out not so great. Extension methods is one, and async/await is another. In fact, if Project Loom ever, finally, actually ships it'll make the whole c# code colouring thing look like the abomination that it is.

No mention of the _disadvantages_ I see; specifically

- efficiency is related also to /flow/ temperature. Which is much lower than the gas boiler it might replace - so you need big emitters (large radiators, Under-floor-heating) - and good insulation

What might make 100% sense in a new build where you can design for these factors, but be awful in many existing homes.

And worse, people take it all at face value and don't think for themselves.

A lot of the "clean" stuff is completely out of date. It might have been justifiable to insert umpteen independent layers (ooh.. Data Objects -> Domain Objects -> UI objects; mapper mapper mapper!) into your software in the early 90s when everything was a monolith and there were such things as "database teams" and "business rules teams" in order to insulate those parts of the software from each other.

In the age of uServices where the boundary is the API and the context is completely self-contained, it's not just a bad idea it's an actively malignant waste of time.

I worked in a UK company where someone went "I'm leaving, and I'm not giving you the 3 months notice".

Management consulted with lawyers, who basically said yes, you can hold them to that contract, but no, it's not worth it as you'll basically have to pay them whilst they're either un-cooperative or you place them on garden leave.

He left after a month, though those bridges were quite burned!

Quite.

A "small business app" would be far too expensive to build to "NASA" Standards, and furthermore, it would be wholly unnecessary to do so. Think opportunity cost.

I have worked in places where, basically, there was so much money pouring in that the drive to actually ship anything had all but disappeared. Thus the 'axis of perfection' took over: Build the perfect shining crystalline entity, no matter the cost. Rebuild your own tools, even where good, liberally licensed FOSS alternatives already exist. Etc.

I found the latter environments too frustrating to cope with, as I found "making code look nicer" did not lead to an existentially satisfying week.

It very much _does_ happen in the UK, though rarer than it ought.

I've even seen the police crack out light meters to fine boy racers with overly tinted windows.

I have yet to find a better monitor than the Dell U3011, which is essentially the same unit as my previous 3008WFP (which itself there was a 3007wfp before it), which means it's a design that's been available approaching 15 years.

30" 2560x1600; c. 100ppi.

I run the numbers on all the Ultrawide, 4K, whatever hotness and I end up knowing I'll fit less vertical lines on the screen.

BS.

I've run skunkworks projects in every single organisation I've worked for, and it's vastly easier today to 'pad out' the way "Agile" is practiced these days than it was in the past.

This entire article reeks of "I'm angry at VOE, who you will know who i, so I'll take a general position and construct specific cases where it doesn't work".

It's totally disingenuous to claim that if I'm liable, say, to think less of you for working at Oracle that I'm incapable of distinguishing whether your circumstances (say: healthcare, green card, having been taken over) are a factor - compared with, say, accepting a job offer there.

As the VOE put it (paraphrased):

"If you work at Oracle, will I think less of you? YES! Of course I will. Your name is on the flag supporting <despicable behaviours>, But: You don't have to think anything of that. Why is my thinking less of you a problem for you? Unless, maybe, that's your conscience?"

See also: https://apenwarr.ca/log/20201121

It's _exactly_ like that - and I've asked a fair few questions on DIY forums and the answer is, invariably, "you should hire someone to do that".

It's even worse in the UK if you mention gas. If you so much as mention a boiler you'll be pounced on by the cartel inventing their own legislation.

You can go 2 ways, neither of which are hard.

You can file your accounts (which are trivial for a micro entity) directly with Companies house, or, when you do your CT600 corporation tax return (which is the 6 or so numbers) there's a checkbox marked "also file to companies house".

You absolutely do not need an accountant.

You also get a great deal of time (extra on your first year) between year-end and when you have to submit, so there is no panic.

If you're interested, you can always check out the code to GNUcash;

IIRC it has a SQL Schema that can be imported into most databases.

https://wiki.gnucash.org/wiki/SQL

UK based, so YMMV.

Moved from self-employed for the odd side gig, to UK LTD co, to VAT registered UK LTD co.

The "business services mafia" will like to frighten you into believing you have to drop hundreds of £ on their services - plus £120/yr for an accounts package, more for payroll, business banking, etc.

Because your mind is too tiny to comprehend the ways of the priests. e.g: Don't ever ask a question in a business forum, you'll get swamped with the clergy telling you the question implies you're definitely going to prison because you're going to get it all wrong.

Do not believe them.

It is perfectly possible - perhaps even 'easy' - and if you understand the basics of double-entry accounting, all entirely learnable without too much effort. And best of all, you can do it almost for free!

Don't drop hundreds per year on Xero, use https://www.quickfile.co.uk. Cost: £0 (upsell on receipt scanning, but I don't use that). Does VAT, with electronic submission. I literally don't understand why you'd spend money on Xero - the extent to which it's advertised over here is insane; you're just paying for TV advertising.

Payroll (and all the tax calculation): Free, for up to 3 users. https://www.shapepayroll.com

Business banking: Tide. 20p/per transaction (no monthly fees!)

The hardest parts are - discipline of entering the transactions and not letting them build up - in the UK, understanding capital allowances vs depreciation - when doing payroll how to split the payments into the correct accounts (shape does the sums, you have to account for it correctly) - Make sure you pay all your HMRC bills - Doing the year end as a micro-entity (the CT600 corporation tax return) is actually surprisingly easy, and amounts to putting numbers in about 6 boxes.

By all means pay for all of this stuff if it isn't of interest to you. For me, as I intend my co to run long after I finish working, I didn't want to have annual fees for services that I really wouldn't be getting the use out of.

As my old boss would say: "Why would I push that rock up that hill".

This is spot-on.

I'm used to small, get-things-done environments (startups, small dev shops).

Transitioning to working within a much more "corporate" environment (not that the actual dev team is any bigger) I struggled with the endless gatekeeping and bureaucracy because it was impeding us ... getting stuff /done/.

Once you realise they're not optimising for that goal, I feel less frustrated and have scaled back my efforts accordingly.

Want to do everything via PR, and have andless code-janitoring stylistic bollox ? Fine, I'll do that - but I'm not going to chase you to close it.

Want to spend hours in planning guff and pointless retrospective naval-gazing? Great, I can join the call on mute and get on with something else.

About 10-15 hours actual work per week is fine. "Office Space" is just as true today as it was when it was filmed.

Yes, this is a hard problem. Not even partitioning by tenant will always help you.

This is fundamentally equivalent to database ACID constraints, and the other modes described are great in the same way that if you're able to relax some of the ACID constraints in your code (say, by not being SERIALIZABLE), you get in return nice things (like reads never deadlocking).

If you can't know if message N will change the outcome of processing message N+M, then you have to resolve that before you can proceed - as surely as a serializable database will wait for the outcome of transaction N before being able to proceed with N+M.

This nonsense seems rife.

A few years ago, my co. was acquired, and they wanted to change our contracts.

New contract had a clause: You cannot do any work - paid or unpaid - without the companies' express permission.

So, like, I can't fire the starting gun at the village 3-legged race without your say-so ?

Cue the usual "oh it's standard we never enforce it" BS. Entire team refused to sign. Eventually it got struck.

They similarly wanted to wheedle in 24/7 support rota into my contract. I simply crossed it out (annotated with a witness signature in the margin) and returned. Never heard about it again.

I meant euros.

And thousands includes hundreds of thousands, which is indeed the case here.

Oh ,and while I'm at it, literally everything is defined twice, once in an interface, once in an implementation.

Even though there are no other implementations.

Why? Seems to boil down to "our language / environment / DI system / mocking framework is incapable of working unless you do it this way.

Yet more cognitive and implementational waste.

Shout out for asp.net core projects, where every frickin' class looks like:

class MyService {

  ILogger<MyService> _logger

  MyService(ILogger<MyService> logger) {
    this._logger = logger;
  }

}

Making it a monumental PITA to use without the associated Jungle: The chosen DI framework. Why is the ILogger generic? Because of the DI framework, so it can create a logger that corresponds only to this type.

We're literally writing code to keep the framework happy.

SO MUCH THIS.

It's ironic to me that the "Hammer Factory Factory Factory" post was recently doing the rounds again.

I have recently been working with a client whose "senior" dev swallowed some books with opinions on "quality" wholesale and uncritically.

Thus in the simplest project, implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc.

Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE.

This isn't quality. It's the antithesis of quality. Devs have to understand a whole load of abstractions just to get simple things done. But the author is proud of his tower of 'best practice' - blissfully unaware that adding the simplest feature is now hundreds of lines of code, where one would suffice. This is burning through, literally, thousands of euros of dev time.

I can't read all of the article because paywall, but H2 is a very very bad solution for heating and transport, but could have applications elsewhere.

Paul Martin is very good on this subject. Check out https://www.linkedin.com/pulse/distilled-thoughts-hydrogen-p... and the associated artcles (paticularly on heating).

Sadly it's likely the Economist Journos have been captured for a nice long lunch by the 'big oil' proponents of blue hydrogen as a "transitional" technology (which, not co-incidentally, keeps them in business and doesn't turn all their pipelines into stranded assets).

Why would anyone pay this?

What next, a "cutlery" charge at a restaurant?

I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

Yeah, right?

Don't get me wrong, I've found a lot of Holub's content to be great. I'm something of a fan in some senses, as it's given me a perspective to question some of the utter guff prevalent in the agile space (particularly wrt. things like Scrum and Story points). I don't buy some of it - things like cost of delay - but I'm always interested to hear more and I'm prepared to change my mind on it.

But.

Much like Dawkins, he ought to stay off twitter, as he comes out with crazy-town absolutist statements (like: if your organisation doesn't do X, then it's fundamentally beyond all redemption and you should just leave).

A recurring theme is there in that list, particularly (20), which is - to paraphrase - "give all your money to the agile team, then go away and you have no right to question what they're doing in any way, shape, or form - you just trust them to 'do the right thing' as they're the experts". No line management, no project management, nothing. Go away and leave me alone.

Now put that in context of a self started project that took nearly $15K, listed no significant risks "hey I already have most of this content anyway", has no external dependencies to blame and... completely failed to deliver. How can I take any of it seriously when the supposed expert can so utterly fail to practice what they are preaching?