Hermit Dave

Great to see that CDDO / GDS have updated their guidance page on the use of Progressive Enhancement on UK Government services 😍 https://lnkd.in/esuSVb29 Keep fighting the unnecessary bloat that JavaScript has brought to the modern web! ✊ #a11y #accessibility #webperf #progressive #enhancement

95

7 Comments

I've started a long-deferred read through of Team Topologies, which speaks to some of the problems I was talking about recently around the ways "utopian" software development maxims can fail when they encounter the "topos" of an organisation's incentive and communicational structure. There's a thought-provoking section on John Sweller's 1988 breakdown of "cognitive load" into three categories ("intrinsic", "extraneous", "germane"). The thought it provoked in me was that I tend to disregard the burden of the "intrinsic" when looking for ways to reduce "extraneous" load (ways a codebase and development environment distracts me with boilerplate and arbitrary irregularity) and gain traction over "germane" problems (those particular to the domain we're working in). For me, leveraging advanced language features to eliminate boilerplate and build out a little embedded DSL that can express the problems I care about is an obvious win - I often refer to Paul Graham's maxim that you should first create the language you want to solve your problem in, then solve your problem in it. The problem with this is that it can shift extraneous load into intrinsic load, by requiring programmers who were comfortable with repetitive constructs using basic language features to familiarise themselves with much more advanced features (and the DSL's idiomatic usage of them) for the sake of eliminating what may seem to them to be quite harmless repetition. This suits me personally, because I like having an advanced model of a programming language in my head and using it creatively, but one isn't accounting properly for the distribution of cognitive load if one doesn't also take "intrinsic" load into account. I think of Golang as an intentionally low-intrinsic-load language - it has a small kernel of features, and is structured in a way that discourages higher-order abstraction over those features. If in doubt, write another for-loop! By comparison, I remember Scala adoption at TIM Group being an intensely painful experience for some of my colleagues, because it introduced so many constructs and type-level features that could be used in so many colourful ways. While I was elated by its endless opportunities for minimising extraneous load, they felt the burden of ballooning intrinsic load, and the frustration of being temporarily deskilled by the change of fundamental environment. The real art is to leverage small changes of technique and perspective, that will fit comfortably in everybody's head, to chisel away at extraneous load, until they feel that the nuts-and-bolts of their tasks are simpler than they have ever been.

12

We have TDD and BDD and DDD … I’d like to respectfully suggest another acronym CDD - CI Driven Development. Unfortunately this isn’t IMHO a good thing. I’ve worked in several places now where CICD has taken over and there are extremely complex pipelines and corruptions of code to ensure that there is comprehensive a complete coverage of every possible scanning, testing, analysis, and checking … but in the pipeline ONLY. What those that push CDD forget is that developers need to run/reproduce these checks locally! I recall a video of a talk given by Daniel Terhorst-North some time ago where he suggests running builds manually to check that you still understand what is going on. I think this excellent advice has been completely ignored and swamped by vastly complex GitHub actions or GitlabCI script, mountains of Groovy code, huge docker compose files. I would submit that your CI should simply call Make targets (or similar commands for the relevant build tool). CI scripts should be simple. Aim for build scripts that help a developer run things locally really quickly - make test should whizz through unit tests for example. Also can we PLEASE stop assuming everything is x86: we live in a world with at least two major architectures and a third on the rise: multiarch builds should be the norm!

80

56 Comments

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

I gave a talk at the most recent London Ruby User Group (#LRUG) on how experienced programmers solve problems, and what that means about how we think and communicate as human beings: https://lnkd.in/eBzTM53t I am really proud of this talk and care deeply about this subject; I'd love if you could give it a watch! (slides available here: https://lnkd.in/eXX89qXe)

38

Playwright really is brilliant. And its VS Code integration is just incredible. It's stuff like this that has finally made me - after nearly 15 years of using it - make the switch away from Vim. Being able to generate Playwright test code directly in my editor by clicking around in a browser? Incredibly useful. Takes so much of the pain out of writing e2e tests. Any tips for getting the most out of Playwright testing? I'm finding I'm writing very long tests to completely cover an end to end flow. Is it also worth using it for smaller more "unit test" like things? Say by running it against Storybook?

5

Why does the software industry call the measure of output in development "velocity" but then track it with a scalar rather than a vector? I realise I'm not the first person to ask this question, and in another example of trite observations: the software industry is crap at naming things. I proffer that the answer is because very few people are intentional about what is the right thing to build, what 'right' means, and therefore how to set a direction. 💬 Just keep paddling everyone! What do you mean, which way? Just make sure you're paddling as fast as you can! 💬

70

41 Comments

Today's #weekendbuild series on my blog still has same topic from previous experiment to read and process 1 million rows of CSV but now using PHP. Using PHP it took around 2 - 3 seconds for reading and processing all the data which has less performance compared with Go in previous experiment (<1s). Several key findings: 1. Use plain array to hold the value of thousands or million records will caused OOM. Workaround was increase the "memory_limit" setting in PHP. 2. Instead of increasing memory limit, we could use PHP generators to hold values and it will use less significant memory. 2. Increasing "memory_limit" is basically bad practice and we should avoid it at. We should focus on optimize the application instead. Full Story:

40

3 Comments

Testing, every software engineers favourite subject (maybe). If you're writing Terraform code you might not be aware of the huge amount of testing capabilties available right in the product today. Don't worry, we've got you covered! Really enjoyed putting this piece together for the BlakYaks tech blog that covers all the HCL testing features, including the awesome native test framework. Hope you find it useful. #Terraform #IaC #testing #SDLC #HCL #cloudnative

23

I'm observing a team writing code as an ensemble without TDD. I am selfishly delighted in the confirmation of how valuable TDD is to me as I use it. The team is implementing a new function that's doing list of list manipulation and returning something. They are all over the place with naming things, creating objects, streaming, mapping, flattening maps, return object, variables, naming...so many squirrels. Too many squirrels to even really focus on "what's the simplest first thing we could do?" TDD is so much more than writing a test first. It's a framework that helps me focus, prioritize, structure, and order my thoughts. Test Driven Development is an immensely helpful design and focus tool. I should also note, that I am beginning of working with this team and meeting them where they are. #codelife #devlife #TDD #testdrivendevelopment #unittesting #designthinking #problemsolving #structuredthinking #focus #mindset #toomanysquirrels #codingchaos

282

56 Comments

I’ll be there, learning from the sessions and sharing ways to progress and enable your engineers, from beginning beginners, through fluency, to mastery. Joining me?

2

I first started doing TDD over a decade ago, soon after I joined the BBC. At that time, it was something they mentioned as a requirement for engineers joining the organisation, and I had never really done it although I had heard of it. So during my month long notice period before I started working there, I read up on the technique and practiced it. Luckily for me, one of the first resources I found on the topic was Ian Cooper's excellent talk, "TDD Where did it all go wrong" (see an updated version of that same talk here: https://lnkd.in/eQRnFNza) In that talk, he recommends writing tests in a way that you don't test internal implementation details, with the goal of the tests being able to help you make changes over time, which is the opposite of what many test suites give you. I still remember one of the first experiences I had with the technique, where I was pairing with a very experienced developer on some complicated logic - I don't remember the exact feature now, but I remember it was quite involved, and we tackled it test first, writing tests that tested behaviour and not internal implementation details. I remember we got to the point where all the tests were passing and the feature was complete, and we decided to try to refactor the internal code, because although it worked, it was messy even to us and we'd only just written it. And I remember the pleasure we both felt at the time when we were able to take this messy implementation, and very quickly and with very high confidence, were able to transform the implementation into something far simpler and readable. We had the tests running in real time on one screen and the IDE with our code on the other. Whenever we made a change to our code, the tests would run in a second or two. This meant that if we broke a behaviour that mattered, we found out in seconds, and if we'd done something that worked, we also found that out in seconds. I took this experience and continued doing TDD from that day on, and my experiences have been the same ever since - consistently seeing huge return on my investment, seeing features work first time, forcing me and whoever I'm working with to properly clarify requirements at the start because we need them for our tests. Breaking the problem down into first solving the issue and then having a separate step to just clean and tidy up is very liberating. Every place I've worked since then, I've continued doing TDD and I've shown the value to countless developers on completely different projects and contexts. TDD is the reason I'm never stressed, always feel confident that things will work and also why I get frustrated at the industry so much, because this technique works beautifully and it should be a standard by now.

756

105 Comments

A decade of research busts the myth that high-performance software delivery isn't for the regulated. Read my latest article on The New Stack now! 👉 https://lnkd.in/e3bMJ2tM #DevOps #SoftwareDevelopment #ContinuousDelivery

15

9 Comments

📝 New post on my blog “What's new in ECMAScript 2024” There are a lot of great features added to the specification this year, but some of them are very nuanced and outside of the commonly used set of tools by day-to-day app makers. I did my homework, and I tried my best to explain them all using simple practical examples. Enjoy reading and have a good week folks. https://lnkd.in/e35kw_zk #javascript #ecmascript 

2

https://lnkd.in/eZgicJZb Wow. I have found something that describes very thoroughly some things that I want to address and my feeling in general about TDD and testing, coverage and more. The only thing I have in mind that an answer to all of this is, indeed, to make programmers think like testers. Make them testers, if you like, because no QA would write your simplest, shortest and cheapest tests for the developer -- either you make QA people write the code (which I am not against but not often and more tangentially), or you make programmers to write good tests, which is something I advocate for. Anusha Manohar Javali Nara Ângelo Yao Nilseu Padilha Edmund Crowley O Callaghan Nakul Rathi Vipin Kumar Garg Hemanth Meenakshi Sundaram John Conroy Ashok Kumar Movva

9

2 Comments

Working with code that you didn't write can be tricky enough as it is. With strict concurrency checking and Swift 6 right around the corner it makes sense to both: - ensure we don't run into issues when importing modules we didn't write - others don't run into issues when using modules that we wrote We can use the @preconcurrency attribute to this. Learn more about this attribute here: https://lnkd.in/eKuDXsbV

16

I don't often post things like this but I'm seeing a lot of misinformation around TDD and it not working or is a failure. I've been responsible for implementing or pushing TDD for over 15 years now and have gone through various different frameworks, and methods. When I joined SRL there was a growing bug problem, and zero worth unit, integration, or UI tests. Over the last three years Martin Thorne, Steve Pugh, Olufemi Adesina, Kathryn Beggs, and latest recruit Maude Williamson have worked diligently to create Unit, Integration and Cypress UI frameworks in place. The coverage for each is on average over 80% and continues to improve. It is the responsibility of developers to test their own code and is often the first line of defence against poor requirements. We're now averaging +1 bug/month reported from clients, and usually these are P3, P4s, or disguised scope creep. Simply put TDD DOES work - but as with any skill if you've not got genuinely experienced people then it's going to be a mess. *Ahem* Agile my eyes are on you.

19

1 Comment

Test Driven Development (TDD) is an essential tool for ensuring high quality and speedy development. But can we really understand the value of TDD if we haven't been burned by NOT practicing TDD?

10

2 Comments