If your company (or yourself) makes money using Lucee… you should throw them a bone

G'day:

A few weeks back, right in the thick of the crap about all these Log4J vulnerabilities, I was talking to a few people about the necessity and the effort involved in Lucee getting their situation sorted out, vis-a-vis dealing with outdated library dependencies they had. They were lucky to be safe from the Log4J thing… but only serendipitously-so because they'd not been able to prioritise moving off a really old version of Log4J (which didn't have the problematic code in it yet). They just didn't have the resources to do anything about it, when considering all the rest of the work that kept coming in. The crux of it was that they can only afford so much paid-for dev time, which means tough decisions need to be made when it comes to deciding on what to work on.

To their credit, they've now removed the old version of Log4J from the current version of Lucee 5.x, as well as in the upcoming 6.x, replacing it with the fully-patched current version.

I had a private chat with one of the bods involved in the behind-the-curtain parts of Lucee's going on. Initially they were berating me for being unhelpful in my tone (we agreed to disagree on that one. Well: we didn't agree on anything, on that note. We just moved on), but then got to talking about what to do to sort the situation out. They explained the lack of help they were getting on the project, both in the context of volunteer devs, but as well as lack of €€€ to be able to pay the devs that dedicate their time to the project. I said "you need to get something like Patreon!", and they quickly pointed out that they'd told me about this already, and indeed included the link to it that very conversation.

https://opencollective.com/lucee.

I had only glanced at the page, and had not clocked it wasn't just some page of their own website going on about donations, and I was also completely oblivious to the fact that "Open Collective" is a thing: it is indeed a Patreon-a-like thing.

Cool. Good to know.

This also got me thinking. It sux that people are so happy to use things like Lucee for free, whilst lining their own pockets. Even worse when things don't go their own way, or they need something done, and expect it to just magically appear for them.

It also occurred to me that whilst I personally don't use Lucee to benefit me (although I indirectly do, I know), I sure work for a company that has built its software on Lucee, and is doing pretty well for itself. And I'm the one who's supposedly stewarding our development effort on Lucee, so I was being a bit of a hypocrite. I was not happy with myself about that. I needed to wait for some dust to settle at the end of the year, and then I forgot for a week, but today I bounced the idea of becoming a Lucee sponsor to my boss (the one with the cheque book), and he took zero convincing that it was the right thing to do. He was basically saying yes before I'd finished my wee speech explaining why we really ought to.

And this is the thing. Fair dos if you're just a dev working in a Lucee shop. Like me, you might think it's not on you to put money their way. Or just can't afford it (also like me). But what you could do is mention it to yer boss that it's maybe something the company could do. The bottom rung of the corporate sponsorship is only US$100/month, and whilst that's not trivia for an individual: it's nothing to a company. Even a small one. It's also a sound investment. The more contributions they get, the more time they will be able to spend making sure Lucee is stable, improving, and moving forward. It's more likely a bug that is getting in your way gets fixed (I am not suggesting anyone starts lording "I sponsor you so fix my bug" over them; I just mean there'll be more dev work done, which means more bugs will get fixed). It's actually a good and sensible investment for your company as well. And if it's a sound investment for your employers: it's a sound investment for you too, if you like to continue getting a salary, or move on to another CFML shop after yer current gig. And all you need to do is ask a question.

So: call to action. Here's what I'd like you to do. If you work in a Lucee shop and yer not already sponsoring Lucee: grab that link I posted above, and drop yer boss a line and go "hey, we get a lot of benefit from these guys and it's probably the right thing to do to chuck a bit of money their way. We won't notice it, but it'll really help them". It's easy to sign up, and it's just a zero effort question to ask.

You'll feel better about yerself if you do.

Righto.

--
Adam

Reading "It's probably time to stop recommending Clean Code"

G'day:

Slightly lazy article, this one. This is basically some thoughts I jotted down in the Working Code Podcast Discord channel. Then I decided there was almost enough there to make an article, so why not drop it here too.

In the most recent episode ("057: Goals for 2022"), the team mentioned they'd seen/read an article about Clean Code: "It's probably time to stop recommending Clean Code".

Right. So that flies in the face of what my usual position is on Clean Code: every dev ought to have read it, and it should strogly influence one's code.

But, OK, I'm open to an opposite opinion so I read it. Here's what I said on the Discord chat:

I read the "It's probably time to stop recommending Clean Code" article and a lot of the comments until they all got a bit samey.

I wanted to disagree with the article, but I found a bunch of it fair enough. However I think there was a bit of false equivalence going on with the author's analysis in places.

It seems to me that their issue was with the code samples (which, TBH, I paid little attn to when I read the book), which were pretty opaque at times, and not exactly good examples of what the narrative was espousing. It was a few days ago I read it, but I don't recall them having specific issues with the concepts themselves?

I s'pose the writer did raise a vocal eyebrow (if one can do that) regarding the notion that the cleanest method has zero parameters, and each additional param increases the smell. They recoiled in horror at the idea of every method having zero paramaters, as if that's just ridiculous (which it is, but…). But I also think they then used that as a bit of a strawman: I don't think Martin was saying "all methods must have zero params or they smell therefore don't have parameters or else", he was just defining a scale wherein the more params there are, the more the code is likely to be smelly. A scale has to start somewhere, and zero is the logical place to start. What else was Martin gonna say: methods should aim to have one parameter [etc]"? No. That's more daft. Zero is the right place to start that scale. I don't think that's bad guidance.

I also think they didn't seem to "get" the guidance about flag parameters. Whether that's Martin's fault for not explaining it, or their fault for not getting it: dunno. It's not really a "apportioning blame" thing anyhow. I just didn't think their disagreement with it had much merit.

Oh and there was also some stuff about only using Java for code examples, and it was all OOP-centric and nothing about FP. To me that's kinda like condemning Romeo + Juliet as a work because it doesn't mention Hamlet even once.

I also kinda wondered - given I don't think the article really made its case - whether there was some sort of "it's trendy to put the hate on RC Martin these days" going on. But... nothing demonstrable in the content of the article to suggest that's accurate. However I was not the only person left wondering this, based on the comments.

(FWIW I think Martin's a creep, always have; but it's simply ad hominem to judge his work on that basis)

---

So. Should we still be recommending Clean Code? Is it's guidance "right"?

I think - as with any expert guidance - it's great to take verbatim when you are new to said topic, and can't make an informed opinion on it. And as one becomes familiar with the situations the guidance addresses, one might begin to see where things are perhaps grey rather than black or white. But one needs to have the experience and expertise first, before deciding to mix one's own shades of grey.

For my part: my advice stands. If one is unfamiliar with Clean Code as a concept, then one really ought to read it. Once one is familiar with it, then - fine - consider thinking about when its advice might not be most appropriate. Perfect. That's what you ought to be doing.

Simply seeing guidance on "black" and going "I don't even know what 'black' is so I think 'white' is better. I know about 'white'" is just a dumb-arse attitude to have. Learn about black, understand how it's not white, and then once that's nailed, start deciding when things might better be grey.

---

Anyway, I know there's not much context there: I don't quote from the article I'm talking about at all. But I think you should go read it and see what you think. Don't take my word for anything, Jesus.

And I will reiterate: if you have not read Clean Code, do yerself a favour and go read it. Don't worry that Martin's not flavour-of-the-month social-awareness-speaking these days. I really do think most of the guidance in Clean Code is worth knowing about.

There were a coupla other books recommended in the comments. I'll not recommend (or otherwise) them myself until I've read them, but I have a bit of a reading queue ATM.

Anyway, this article was lazy as fuck, wasn't it? Oh well.

Righto.

--
Adam

Work with me here

G'day:

Update

This role has been filled.

I mean literally: come work with me. Here.

We're expanding our dev team, and I'm looking for a new dev to join us.

This could be a really good opportunity for someone doing CFML development who would like to move away from CFML and pick up a new language, whilst being paid to do so. You know how I shifted from CFML to PHP several years ago? The opportunity to shift to a new language whilst in my same role was the best thing that ever happened to my in my dev career (even if it was just to PHP, it was still excellent to pick up another language professionally). Well: second best after the initial opportunity to shift from systems engineering to development in similar circumstances. Seriously: even if yer in a solid / comfortable CFML dev role now, think about this.

We currently have a CFML app running on Lucee and the CFWheels framework, and over the next coupla years we are going to be porting this to Kotlin on the back-end; and after that my plan is to re-implement the front-end part of it as its own front-end app using vue or react or angular or whatever the flavour of the month is for client-side app development by then.

The CFML app will be running in parallel during this time; we will be shifting pieces of its functionality to the new back-end in a piecemeal fashion, so we do need both solid CFML skills for that side of things, and either pre-existing Kotlin knowledge, or just a desire to learn Kotlin on the job. I myself and the other devs on the project will be picking Kotlin up as we go.

The official job description is here: Senior Application Developer UK, but the important bits are as follows:

• Strong object-oriented CFML experience.
• Strong experience with test automation (eg: unit testing).
• Strong experience maintaining and building on existing legacy applications.
• Strong experience designing and developing new web applications / web services.
• Thorough knowledge of design principles such as MVC, SOLID and a good understanding of common design patterns.

Other stuff that is going to be important to us:

• Experience with CFWheels.
• Experience with TDD practices.
• Familiarity with Dockerised development environments.
• Experience with or exposure to Kotlin for server-side development.
• Experience with another language over and above CFML for application development.
• Preparedness to learn Kotlin on the job if no previous experience.
• Familiarity with Agile principles, and experience delivering value in an Agile fashion.

If yer a reader of this blog, you know what I'm like with these things. And they are important to me in this role.

Why Kotlin?

We wanted to go to a statically-typed language, to help us tighten-up our code. I didn't want to do native Java, but there's something to be said for the Java API, so there was a lot of appeal in sticking with a JVM language. I've dabbled inconsequentially with Groovy and love it; thinking it's where CFML could be if Macromedia had done a better job with CFMX. But whilst a lot more popualr than CFML, Groovy's popularity still ain't great. Another consideration is we've been burnt being platformed on a very niche language, and don't want to repeat that (another reason for CFML devs to think about taking an opportunity to jump!). We thought about Scala, but I talked to an industry pal (won't drop their name here), and they convinced me it's a bit heavy for web development, and suggested I look at Kotlin for another language in the same space. I had thought it was only for Android dev, but it's made good headway into the server-app space too. It's got the backing of Google and is stewarded by JetBrains, so it seems solid. It rates well in various language popularity lists. The code looks bloody nice too. It's got a coupla decent-looking MVC frameworks, and good testing libraries too. And it was these last things that swung me, I have to say: language, framework, and testing: I had a look at them and I want to program with them. But I also have a responsibility back to my employer to make a decision which we'll be able to reliably work with for a number of years. I think Kotlin ticks all these boxes. Oh and being a JetBrains project, it's integration into IntelliJ is first class, and IntelliJ is an excellent IDE.

Back to the role…

Logistics-wise this is a remote-first position. The rest of the dev team is remote, around the UK. We have an office but I've never set foot in it. But if you want to work in Bournemouth, there's a desk for you there if that's your thing. The non-dev ppl in that office are all nice :-).

Secondly, we are only able to hire employees who are able to live and work in the UK without visa sponsorship (don't get me started about the UK leaving the EU, FFS). However if you are on the East Coast of the States or elsewhere in Europe or similar sort of timezones, we could consider a strong candidate provided they have the ability to invoice us for services, on a contract basis. We will not consider timezones further afield than that, I'm afraid: I want the whole team to be on deck at the same time for at least half the day (and during their day's normal working hours). It is a fulltime role.

We are likely to have another new starter joining in March, and in the mean time I am going to be aiming to kick the Kotlin project off in our next sprint. First task: get a Kotlin dev environment container created. I think. I think that's a first step. This is how early in the project you will be joining us :-). I intend the application to be 100% TDD, continuous delivery, etc. And delivering something to prod every sprint.

With all this talk about the opportunity to pick-up Kotlin, it's important to be be mindful that all this time the CFML app will still be the app making the company money and paying our salaries, so there will be requirement to work on this as well: new features, enhancing and (cough) fixing existing features. Initially the job will be 100% CFML and 0% Kotlin, but I intend for those percentage to start swapping around as soon as we can, so by some point in 2023 it will be 0% CFML and 100% Kotlin.

If you want to have a chat about this, you can ping me in the CFML Slack channel (if for some reason you're a CFML dev reading this and not already in here, you can join via cfml-slack.herokuapp.com). Or you can send yer CV through to the email address on the job spec page I linked to above. I'm not interested in talking to recruiters for now, just in case you are one (and reading this?). For now I'm only wanting to talk to people in the dev community directly.

Righto.

--
Adam