Rob Richardson

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

If celebrating software maintenance is something you want to do, you should check out the Legacy Code Rocks conference MenderCon on May 16th! I’ll be giving the opening keynote: “Community Is Just as Important as Code” Registration link is in the comments.

25

2 Comments

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21

The "Scout Rule" is derived from the Boy Scouts' motto: "Leave the campground cleaner than you found it." In the context of software development, it emphasizes the idea of leaving the codebase better than it was before you worked on it. It can be translated as: "Always leave the code cleaner than you found it" Here are some suggestions: - If you notice mistakes in the surrounding code fix them right away - If the class/method is getting bloated, think about refactoring - If you come across outdated comments you should update, delete, or mark them as outdated - Clean up unused methods/variables/classes Over time you can make this a habit, so it becomes easier. https://lnkd.in/dvMdHBFG

21

1 Comment

In other news today, Delta Lake UniForm is now Generally Available. No more data silos, interoperability FTW! UniForm allows you to use a single table format for your lakehouse, getting the top-of-the-line performance and features of Databricks and Delta Lake, but being able to access the data using *any* engine that supports *any* of the common lakehouse formats Delta Lake, Iceberg, or Hudi.

45

If Not React, Then What? Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering. Code that runs on the server can be fully costed. Code that runs on the client, by contrast, is running on The Devil's Computer. As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site's lifetime. Stacks based on React, Angular, and other legacy-oriented, desktop-focused JavaScript frameworks generally take the opposite bet. "Our product stack has bet on React and the various mythologies that the cool kids talk about on React-centric podcasts. You're asking us to rethink the whole thing. Which silver bullet should we adopt instead?" JavaScript remains at least 3x more expensive than equivalent HTML and CSS, byte-for-byte. The choice isn't between JavaScript frameworks, it's whether SPA-oriented tools should be entertained at all. For most sites, the answer is clearly "no". Sites built to inform should almost always be built using semantic HTML with optional progressive enhancement as necessary. Sites that have content that changes more frequently should look to "classic" CMSes or tools like WordPress to generate HTML and CSS. Blogs, marketing sites, company home pages, public information sites, and the like should minimise client-side JavaScript payloads to the greatest extent possible. They should never be built using frameworks that are designed to enable SPA architectures. Managers and tech leads that have become wedded to frameworkism often have to work through a series of easily falsified rationales offered by other Over Reactors in service of their chosen ideology. Note, as you read, that none of these protests put the lived user experience front-and-centre. "...it works for Facebook" To a statistical certainty, you aren't making Facebook. Your problems likely look nothing like Facebook's early 2010s problems, and even if they did, following their lead is a terrible idea. "...React is industry-standard" This is, at best, a comforting fiction. At worst, it's a knowing falsity that serves to omit the variability in React-based stacks because, you see, React isn't one thing. It's more of a lifestyle. Across more than 100 consulting engagements, I've never seen two identical React setups. There's nothing standard about any of this. It's all change, all the time, and anyone who tells you differently is not to be trusted. And if you don't mind me asking, how's that "CSS-in-JS" adventure working out? Still writing class components, or did you have a big forced (and partial) migration that's still creating headaches? https://lnkd.in/efB4PR-A

3

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

A recent significant development in release management I think flew under the radar for many: the Abseil C++ library's adoption of a "live at head" policy as its recommended method of depending on the library. What the maintainers mean by "live at head" is to "depend on and build the latest snapshot of Abseil," which implies that every commit to the head of the repo is to be considered a production release to be compiled in. The head of the main branch is the current release, period. The project is also tagging LTS releases every six months with support of two years pledged but also state there is nothing special about those tags, that it's just a snapshot at that point in time. Despite recommending against depending on their LTS releases, they are providing this for who the live at head policy doesn't work. Abseil release management: https://lnkd.in/egFchD4f --- #ReleaseManagement #Cplusplus #SoftwareEngineering #VersionControl #LiveAtHead #Abseil #OpenSourceSoftware #SoftwareDevelopment #LTSReleases #SoftwareUpdates #embedded #software #Cprogramming #CplusplusProgramming #C

1

Hardly a hot take at this point, but if your dev team is not using Trunk Based Development, you really should be. Here's why: https://lnkd.in/ehb5yJ7Y

22

Serverpod continues to strengthen its lead in the Flutter server space with release 2.2! Being used by well known international companies as well as small startups across the world is a testament to its ease of use, power, and scalability. #flutter #makesbackendeasy

8

A quick Domain Join Hardening reminder - The removal of the NetJoinLegacyAccountReuse registry key is scheduled for August (See linked doc). If anyone is using it, this is a gentle reminder to deploy the alternative methods documented in https://lnkd.in/eHSKBWDt

171

2 Comments

The future of engineering design and coding is about here. Imagine simple text prompts that assist your software engineers in designing and coding complex systems, saving thousands of hours and months of work. Getting a smart code base and avoiding the dreaded Tech debt. I see Pledgecircle using AI engineer to assist with our 5 zero-to-one components system designs. It's a new world to build.

3

I've been thinking a lot lately about how dogmatic software engineering is/has-become/always-was(?). I see so many so-called "best-practices" applied on projects that turn into utter disasters. I think I've got a way of reframing software engineering so we can actually have productive dialogs about what actually matters and what is actually harming our projects. If you are an experienced software engineer or project manager, take a look. I'd really like your thoughts and an open discussion on this topic.

5

I haven't seen this but I believe it. Via James Higginbotham Anyone else seeing the term "OpenAPI" used in contrast to GraphQL and gRPC, rather than the term "REST"? I'm seeing this more and more. Keep in mind that what I'm seeing isn't comparing OpenAPI to GraphQL's SDL or gRPC's IDL. Rather, this is a label being assigned, like REST, as an API that isn't GraphQL and isn't gRPC. Reply and let me know if you are seeing this as well.

13

6 Comments