Aaron Sumner

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

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 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

There were other examples of this around the web, but none explained _how_ automatic reloading worked in Django. Some implementations felt half-baked. I think this one stands apart. This is also my 70th blog post on DEV 😮 https://lnkd.in/gtC6sBMr

3

2 Comments

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

🛠️ Okay y'all, looking for advice: I'm running a handful of small apps for Build Carolina's Development Studio initiative. These are low-utilization apps for relatively small audiences. I'm leaning heavily on Rails at the moment but expect to bring on some JS-stack projects in the near future (likely Next, but I'm always open to the flavor of the week in JavaScript 😅) Here's what I'm finding for hosting: - I still know Heroku best, but I just don't trust them to not enshittify further. 🫠 Every new app here is a liability when Marc decides he needs another island or whatever. 💰 - I'm using a lot of Render and like their devex philosophy, but their pricing is weird (per-service + premium tiers? Pick one!), the big feature gaps in their platform have gone long-unaddressed, and their support has been poor. 🤖 - I'm experimenting with Fly.io: great pricing, but a weird mix of UI-vs-CLI workflows and segmenting project resources is unintuitive. I feel like I'm going to wake up to a huge bill because I accidentally over-provisioned something here. 💸 I'm curious what other folks are doing for small-scale artisanal app hosting in 2024+. Are we all running our own EC2 clusters? Is everyone just writing Next apps for Vercel? Maybe I'm just an old fuddy-duddy looking for a backend host in a static SPA world. 👴 ❓ Tips/tricks/tales welcome. Where are you hosting your lil' bytes right now?

13

39 Comments

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

20

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

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

🇪🇺 Be part of the conversation on July 11th at 3:00 PM CEST! Our #NonprofitPulse2024 webinar features a rockstar panel discussing the latest nonprofit trends across fundraising, data security, and the development of AI. Save your spot today! #Fundraising #AIforGood #NonprofitTrends

2

‘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

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

Be sure to mark your calendars for this one! #kcdnug #dotnet #questanalytics

3

A question to my friends, colleagues, and Linked-In associations that are full TDD developers. Folks who consider themselves proficient or have mastered TDD. 1. How long did it take you to to become very proficient (e.g. to start thinking fully test first)? 2. Did you have a mentor or some aid that helped you along the way? 3. What kept you going down the proficiency/mastery path? I'll start: 1. It took me about 3 years to make it a habit and for me to truly embrace TDD and find that it could replace "test after" development. 2. I did not have a mentor. I did not have YouTube or trainings. I had constraints about creating automated tests. I had teammates that were similarly inclined (constrained). 3. I immediately saw the value of automated tests. I struggled with test first getting in the way of me feeling productive (because I was not proficient and in the learning/gaining proficiency phase) with test first. I'd start every day test first and quickly transition to test after, because it was getting in the way of my "productivity and programming...damn it I just want to write the implementation!" At the end of the day I'd reflect and most days realize that writing tests after was so much slower. Slowly, my time spent test first increased. At some point I transitioned to pseudo coding my intended implementation (to satiate my need to "just write the damn code and not be bothered with tests"). More time passed and I realized that my pseudo code was an inaccurate crutch, I ditched that too and would start with a test. There was a period of time where I'd start with a test and get lost in implementing more than just making the test pass (cycles of sunk cost fallacy here, until I learned it's ok to delete and write it later - faster, better, stronger). There were periods of time where I'd forget to run the test first to see it red before making it green. Too many years messing around with mocking frameworks before learning better design. Struggles with testing internal implementation details instead of external behavior. A whole bunch of stuff I can't think of now and am probably blocking out. I stuck with it though and yikes, does it pay off. I can't imagine not doing TDD now. Coding w/o it is like running through a vat of molasses. So much time wasted in the debugger and writing things that my evil programmer monkey brain distracts me with that YAGNI. I'm writing and asking about this because last week I attended a conference where I talked with a fellow TDDer who'd heard me mention that it took me 3 years to become fully TDD proficient and he shared a similar story even though he was much younger than myself (I attribute my slow adoption due to lack of a mentor/coach and training aids like Pluralsite, YouTube, Jon Reid live coding sessions). I'm curious about others mileage on this. I'll add that I am currently 100% on board with TDD. I am also 100% always on the lookout for a new and better way to replace it. That's off topic though.

45

70 Comments

Large scale code change verification... without executing the build for each repository. 🚀 This is going to be an essential element of any practical agentic experience of large scale code transformation, but is a super difficult problem in a couple dimensions: 1. If you execute the repository's build (i.e. like CI does) for each code change, you're talking about a ton of compute, especially when you get into the hundreds or thousands of apps. 2. Even if (1) wasn't a problem, knowing HOW to execute a build for an arbitrary enterprise repository is a super difficult problem in its own right. And the consequences: 1. That's why these solutions are so unbelievably expensive per line of code. But when their proprietors are selling you compute, inefficiency is a win for them? 🤷‍♂️ 2. That's why the few solutions that do this kind of thing with agentic experiences are hyper narrow in what build tool configurations they allow. I'll write more on HOW we just achieved this, but it suffices to say there is enough information in the LST to do compile verification on hundreds of millions of lines of code post recipe making a change, and it costs almost nothing in time or compute.

69

5 Comments