Posts

Testing a markdown link (to example dot com) in a post…

David Marchese calls the interview that the NYT published on their daily feed yesterday, "one of the most emotionally intense interviews I think I have ever done…" I think it is one of the most emotionally intense interviews I have ever heard. It is whimsical, profound, and beautiful in many ways. Wow.

Aspen in Avon, Colorado. Also testing multiple image upload.

Avon, Colorado

Added the capability to add photos to a post.

After changing the template on the server, time for the next test! Do hashtags show up in federated social media apps?

Testing my new little posting pipeline:

• Draft in fediverse follow (social?) / mentions / interactions/ posting mobile app. Naming is hard…
• After drafting, the app makes pushes the post to the git repo behind my static website
• The push triggers a build which redploys the page with the new content and send potential webmentions

Let's see how this goes!

Oh, yeah, if this works, it is definitely slow to update… So maybe the apps name is Slowcial?

Trying out these guides to sending webmentions...

Some of the pages I am on right now:

• Sending your First Webmention from Scratch
• IndieWebify.Me
• IndieWeb
• IndieWeb - reply

Ten years ago, I wrote Component-based Rails Applications. Today, on cbra.info, I have this banner: "I consider the CBRA approach deprecated. Gradual modularization based on packages gives us all the benefits of components (and more) for much lower costs."

Gems and engines still play an important role, just not as the path but rather as the destination.

When talking to developers about gradual modularization, one of the questions is, "So... where are we headed?" That is, what is the destination of a modularization journey?

A message I sent to the readers of Gradual Modularization for Ruby and Rails regarding the new update published today.

A message I sent to the readers of Gradual Modularization for Ruby and Rails regarding the new update published today.

In his post When Static Types Mask Code Smells Jared White reflects on a discussion about TypeScript and makes the case that static typing isn't a panacea. It does not fix all your code problems. Indeed, it does not!

🧵 A thread about gusto’s newest #gradualmodularity (nah, I should say #bigrails) open source work: It is all about managing big Rails applications with a lot of people!

There is a lot, so buckle up!

See them all at https://github.com/bigrails

...

This work is part of what the product infrastructure team does at https://twitter.com/gustohq!

If stuff like this is interesting to you, DM me (on twitter) or find me elsewhere and let’s chat!

...

First up https://github.com/bigrails/stimpack! This gem makes organizing your Rails app’s folders such that they work well with packwerk a breeze. Just point it at a folder and all needed autoloading is done for you! Kudos to https://twitter.com/nganpham!

...

We use https://github.com/bigrails/bigrails-teams to create the concept of an engineering team in our codebases as an explicit construct. This can be used to route errors, notifications, deprecations, etc. In short support for breaking down a large app by team. Which brings us to...

...

https://github.com/bigrails/code_ownership! We use this gem to ensure that every file in a codebase has an owner. This way, for example, we can ensure that every error can be routed to a team.

...

With https://github.com/bigrails/danger-packwerk we get to direct support for #gradualmodularization work. This gem contains a danger plugin that will make inline comments on GitHub PRs that add packwerk violations. This helps teams know about and learn about boundary violations and what to do!

...

That danger is https://github.com/danger/danger btw

...

We published a VSCode extension, too! https://github.com/Gusto/packwerk-vscode. This extensions gives you that warm fuzzy feeling of a red squiggly line underneath a constant when you happen to create a privacy or dependency violation in the code you are writing.

...

If you read my book Gradual Modularization with Ruby and Rails, the gem https://github.com/bigrails/package_protections will feel familiar. It is our implementation of the ideas from Chapter 3! It is an opinionated framework for protecting more aspects of modularity than just privacy and dependency.

...

Last but not least: https://github.com/bigrails/modularization_statistics. This gem reports modularization stats to data dog, so you can build yourself a bunch of sweet dashboards that show overall progress. We have it connected to teams, code ownership, and package protections as well.

...

All of these gems have seen herculean efforts by https://twitter.com/AlexEvanczuk to get them built and to get them open sourced.

Hint: Alex will be at https://twitter.com/railsconf next week talking about all of this stuff (https://railsconf.com/program/sessions#session-1321)!

...

Hint hint: a bunch of Gusties will be, including me ;)

The message I sent to folks who bought Gradual Modularization for Ruby and Rails about the publication of Chapter 6!

This post is following https://brid.gy/about#webmentions to publish a tweet automatically. Let's see!

This post is following https://brid.gy/about#webmentions to publish a tweet automatically. Let's see!

Want to generate some quick stats for the size of your Rails app (and likely some of its problems)?

These are the queries I used to generate graphs for some big open-source Rails app for my 2014 RailsConf talk Refactoring towards Component-based Rails Architecture.

How do Ruby 3, Rails 7, and packwerk 2 affect the source code for Gradual Modularization for Ruby and Rails? Let's find out!

Happy New Year!

There is this thing called the law of holes[^1]. It's interesting...

My recent experience of publishing 30 atomic essays in 30 days[^1] failed in one way: I only got 25 articles out. I succeeded in most other ways and will apply my learnings from this time to how I work on and publish Gradual Modularization for Ruby and Rails[^2].

I recently came across a very practical application of the analysis of agile vs post-agile[^1] in a simple observation from a new team member: "It seems like our definition of done is really unclear."

This is an old example, but a good reminder: even instantaneous migrations can bite you in the ass. Be careful.

The cost and benefits of technical migrations are hard to pin down. Discussing them efficiently is also difficult without properly understanding what we are talking about. This article creates a nomenclature to help with this.

I have always felt like I wanted my web content to be on my website. I have also always felt that my website is a pretty lonely and inactive place.

A 2 minute detour in a conversation with my mentor at my work, Gusto (we're hiring... a lot[^1]!), connected the dots on big trends in the software industry that are so foundational, I am embarrassed to say, I missed them.

Go read Stacey Abrams' Lead from the Outside[^1].

All our thinking stands on the shoulders of giants[^1].

Zettelkasten VS Atomic Essays? More like Zettelkasten AND Atomic Essays!

I have tried many to-do list applications and systems. They were all too complicated.

In 1992, Niklas Luhmann, a German sociologist who published over 50 books and over 400 academic articles, published Kommunikation mit Zettelkästen about his use of the Zettelkasten method - explaining how it made him so productive.

6 years ago I read this beast of an article titled "How to Use Evernote for Your Creative Workflow"

There are a bunch of note taking apps that seem pretty hip right now. The most en vogue might be notion and obsidian. I want you to known about a lesser know, open source alternative called joplin[^1].

I still regularly find my screen getting cluttered with random notes, but I am getting better. In fact, just today I deleted the TextEdit app from my mac so I won't use it ever again. Let me tell you why. And, let me tell you how to fix your note taking.

MeetingBar is for you if you use a calendar and you regularly participate in video calls[^1].

Hammerspoon[^1] boasts two things: a truly epic project name and a lua scripting environment that hooks into extensions that allow you to control system functionality in macOS.

Homebrew[^1] describes itself as "The Missing Package Manager for macOS (or Linux)." The program primarily installs command line applications but through its various extensions is, in my opinion, the best way to install and long-term manage applications on a Mac.

Alfred[^1] is a productivity app for Mac. It "boosts your efficiency with hotkeys, keywords, text expansion and more." For anyone who doesn't use the keyboard much to navigate around their system it will take some getting used to. But once you do, whew! Are some things much more straightforward to do!

Some time ago, we had family visiting. Mom, Dad, daughter, son. We were just hanging out for the weekend, took a leisurely stroll to our neighborhood shops to get some breakfast. The choice was burrito or bagel - and coffee. Sticking our purchases into our shopping bag, we headed to the park nearby to have a breakfast picnic.

We played ball, had breakfast, and raced. The sun was out, yet it was a nice fall day . It was good to be outside and be together. We walked under some trees that were turning colors. With the sun out they were brightly golden and orange. Pictures were taken. We ended up sitting in the grass in the middle of all these trees - in the sun.

Out of nowhere my nephew asks: "Can we make a game for my phone?"

Eight months earlier

When we saw each other the last time, we had visited them and the topic of work came up. I mentioned that I build software applications (I called them apps). "Oh, for the phone?" - "Sometimes, yes"

"Can you make games?" -- "I haven't made a game, but I might be able to. We could try to figure it out together, if you'd like." We chatted about some ideas, but attention spans being what they are, we didn't build an app.

Back to today

Because of that question, "Can we make a game for my phone?", we ended up: inventing a game, talked about game mechanics, about load screens. We ended up drawing a couple of wireframes and created an app starter on an simulator. Whether you'll find out game in an app store near you sometime soon, I don't know.

All the conversations that were part of this story were such a fresh perspective on my work, fun, inspiring -- a good reminder why I love the work I do.

If you have read any of my posts about gradual modularity and thought "well this is only interesting for those folks who messed up their (Rails) apps on their own in the first place," read this post. I don't believe that is true: Gradual Modularity can benefit engineers working in most languages and frameworks.

Yesterday's attempt at a concise description of what Gradual Modularity is[^1] fell short of being a definition. Here is another attempt at that.

Test 1 Test 2 Test 3 Test 4 Test 5 Test 6 Test 7 Test 8 Test 9 Test 10 Test 11 Test 12 Test 13 Test 14 Test 15 Test 16 Test 17 Test 18 Test 19 Test 20 Test 21 Test 22 Test 23

The largest software development organizations in the world make heavy use of microservices (or service-oriented architectures) - one kind of modularity that allows organizations with thousands of developers to be productive.

Our options today create a great hurdle for modularization refactoring work

Beyond classes and objects, the most common mechanisms to achieve modularity are libraries (running within the application process and services (running outside of the application process as standalone applications). These kinds of modularity create “perfect isolation.” Perfect in the sense that the functionality of these libraries and services verifiable in isolation.

From the perspective of refactoring towards libraries or services, the perfect isolation property poses a problem: The extraction refactoring needs to create “perfect” isolation, too. That is a daunting proposition for apps that have developed into “balls of mud” (lets say because of an over-eager object-relational-mapper layer - read: basically every Rails app in the world) - things are simply too entangled for this process to be easy.

Gradual Modularity removes the modularization refactoring hurdle

Gradual Modularity removes the need for perfect isolation. Take two parts (let’s call them packages) of an application that we’d like to modularize:

Only partially known dependencies? Only partially defined public APIs? Some usage of private code? Partially clobbered namespaces? Only partially separate databases? All of this doesn't work with services or libraries. It is totally fine with gradual modularity.

For each package we can define and lock in the level of isolation that we’d like to achieve for the moment. Depending on the level, violations are allowed. Violations don’t break the app, instead they are recorded in todo-lists that are checked in with the code.

Gradual Modularity, through allowing partial, leveled isolation and todo-lists for outstanding isolation work, gives developers a toolset to confidently and iteratively refactor towards a perfectly modularized system.

Follow along with me as I am writing a book on Gradual Modularity at https://leanpub.com/package-based-rails-applications

I have found one criticism of gradual modularity that resonates:

Gradual is really just somewhat. This whole idea has no teeth and won't lead to actual change with positive impact.

Let's start with how I use the two terms:

When I say components, I mean individually tested, isolated, explicitly dependent, and composed software parts that are combined to make the functionality of an application¹. In practical terms, components in various languages are Ruby gems, Java Maven projects, or Node modules.

With packages, I am referring to more-or-less individually tested, more-or-less isolated, and composed software that are combined to make the functionality of an application. Packages don't widely exist and they have been introduced to Ruby only a year ago when Shopify open-sourced packwerk².

I pushed for components for a long time: Hear me when I say: Stop. Use packages.

Separating code into components (or services) is a big decision

In order to make components - the same goes for service creation or extraction btw - some big decisions come first: Which functionality should live together? What should its API be? It also comes with a lot of work: Set up a separate test suite. Set up and maintain the new CI/CD pipeline. These decisions and this work is risky: what if we get it wrong?

Software engineers wouldn't put this work in if it weren't worth it though. So why do we do it? To manage complexity. To ensure that the incidental complexity of our application is not too much higher than the essential complexity of our domain.

Don't look back

With packages, you replace the "one big decision" of components with many, many, much smaller, easier, and far less consequential decisions around packages³. That is why packages are a game changer: we can get to the same destination, but we can get there with waaaaay less risk along the way.

ActiveRecord (AR) is the main driver of incidental (read: superfluous) complexity in your app. Do not feed the beast.

Try to hold these two ideas in your head

expect(rand(100)).to be > 0

If you are working with a large codebase, then you are likely dealing with test flakes. Flakes? Tests that, ever so often, report a failure where no relevant change to the system has happened. Google seems to think that a certain amount of flakes is unavoidable[^1] and I agree.

So, I started this thing... "ship 30 for 30"[^1] after seeing a couple of nice posts by Matt Stine[^2]. Really, we haven't even really started yet. The first post is to come out Saturday, but in trying out this editor we're going to use throughout the course on thing struck me: In order for me to do this successfully I will to switch from writing to .. writing NOW.

When shopify released the tool packwerk they did more than just open source a utility they had been working on. They changed how we should think about application modularization.