If you haven’t heard (touching too much grass?), Bun has been making some waves in JS-land with it’s big 1.0 announcement. It’s been fun to watch the reactions. Jessie Frazelle had a tweet that went tech-twitter viral, describing a feeling that many were thinking. How did such massive change come, seemingly, out of nowhere (relatively speaking of course; Bun was public about it’s work for the last year). I’ve been thinking about it a lot, and tweeted a thread/diatribe about “The Innovator’s Dilemma” and how it applies to the current Bun vs.

Introduction What does it mean for a Software Engineering team to be effective? Productive? Happy? Impactful? This has been on my mind a lot as I’ve stepped into management in this part of my career. I’ve begun to collect my thoughts into this post. Many of the ideas apply to projects of any kind, but some of the advice I’ll give will be tailored specifically to software projects projects and teams.

What does it mean for a software application to be good? Here’s my ranked ordered list of “good software” attributes: Solution: Provides a service or solves a problem, and does it well Design: Cohesive, intuitive interface Quality: Minimal bugs and defects; good performance Delivery: Continual, helpful updates Solution and Design: What we don’t control The Solution and Design are the most visible and obvious parts of “good software”, and when the chips are down, they can make up for tons of issues to a shocking degree.

Introduction A few upsides come with adopting an opinionated framework like Ruby on Rails. One of them is having a clear pattern to the layout of a project’s source code directories and guidance on where specific code should live. This reduces the friction of creating new code modules and provides guideposts for navigating the code base. Human brains like patterns, and organizing your code into clear patterns helps developers find their way; both the newly onboarding devs and the grisled veteran devs.

Originally published on the Test Double blog here In discussions of React application architecture, React Context is often brought up as a way to implement “State Management” yourself. Some really great blog posts exist that provide techniques for implementing that exact thing like “Application State Management with React” by Kent C. Dodds. This technique can be useful for specific, one-off cases but less so for an entire application architecture. An article by Mark Erikson, maintainer of Redux, titled “Why React Context is Not a “State Management” Tool (and Why It Doesn’t Replace Redux)" provides some excellent arguments and marshalls other great articles as reference.

Originally posted on the Test Double blog here As a consultant who has worked with React since 2014, I have been fortunate to see and work with many dozens of production React codebases. In that time, I’ve noticed many patterns of use (and pain) that crop up even between very different applications. I also, regularly, get asked about the React ecosystem more generally and what things I’m excited for (or dreading).

Originally posted on the Test Double blog here Introduction A common situation when writing React components is needing to render a particular component only under certain conditions. There are many ways to accomplish this, but the route you take often has nuanced implications or differing utility based on the current state of the code/component/system. Let us consider the case of a component that requires some prop data to render. The following are two, general tactics for handling missing prop data:

Originally posted on the Test Double blog here Introduction React is an amazing library. Over the last 5 years it has transformed the landscape of frontend development and spawned an incredible ecosystem of tools, libraries, and patterns. Over that time, React has changed quite a bit. As React has evolved, so too have our applications, tools, and approaches. This year (2019), React went through one of its biggest changes with React v16.

Introduction If you want to get new-agey and deploy a GraphQL API in a serverless architecture, what’s the best way? You can make that work with API Gateway but it’s a little cludgey and normally results in implementing a super Lambda function that contains all your GraphQL resolver logic. Lucky us! AWS has a GraphQL specific API proxy called AppSync. Last month, I did an article overviewing AppSync and concluded I would try it out on an upcoming project.

Introduction I have built several production web applications using React and Redux and generally have had an excellent experience with those technologies. One of React’s greatest assets IMO is it’s ability to integrate into all kinds of stacks and setups but still play nice with the other kids. That was something that impressed me back in Spring 2014 when I first used React. We got React running in the jQuery spaghetti code of a massive, legacy Ruby on Rails application with incredibly little effort and huge productivity benefits to the team.