Every year, I speak with a handful of current, former, and potential clients who ask about service-oriented architecture or microservices. The situations all start out with similar intent:

Image processing takes a long time and performs orders of magnitude more operations compared to other areas. Because it’s isolated, we’d like to break it apart so we can scale it independently to handle the growing workload.

Or

We’re growing our team and our monolith isn’t cutting it anymore. It’s difficult to add new features, and services will force the team down a path where they need to properly isolate components.

Or

We’ve got a couple of discrete areas of the application, each of which changes independently. Most of these areas are data-in, data-out, with no persistent state, and fit within a simple request/response lifecycle. Because we expect the complexity to grow, we’d like to extract those to their own applications.

One of these is not like the others, however. Can you guess which?

Services Don’t Address Process Problems

Both the first and third example seem reasonable and well within what I’d encourage a client to explore as an option. While simple, isolated components aren’t the only reason to extract to services, it can make the process easier (both from a mocking and testing perspective, and from a surface-area perspective). When exploring services becomes an attempt to band-aid larger issues, however, I strongly encourage clients to reconsider their choices.

What (seemingly innocuous) process problems get cited most often as reasons why a company wants to move to a service-oriented architecture?

• “It takes a lot longer to add new features because there’s so much code.”
• “The codebase is so large that even code review takes a long time when we add new features.”
• “A small change I made introduced an odd bug in a totally unrelated area of the application.”
• “The code is so complex that our test suite takes hours to run.”

Slowing Feature Development

Feature development often slows down after an initial period of time where everything seems so simple. The team is cranking out features left and right for what could be months on end, and then one day, a feature that was expected to take a couple of hours takes a day. Another feature that the team agreed seemed like it should be a under a week took two.

What gives?

As applications grow, so does complexity (both accidental and essential). Teams that are not rigorous about addressing this complexity begin to run into issues at multiple levels as applications grow. Tests become more difficult to maintain and run more slowly because of growing data dependencies. Side-effects from data modification happen haphazardly and have impacts on other areas of the application.

These are realities of codebases regardless of whether you have a monolith or a group of services. Services may not solve your problem, and they may actually make it worse if the boundaries between services are not correct.

Slowing Code Review

As applications grow, and especially if there are intermingled dependencies, adding new features results in shotgun surgery. What should be an isolated change ends up touching dozens of files. Because of the growing breadth of changes, reviews go from reviewing 50 new lines of code over four files to changing 150 lines of code across twelve. Reviewing code takes longer, developer confidence is reduced, and merging code goes from 20 minutes to 2 hours.

Services may again seem like a good solution; with smaller, isolated codebases, theoretically a single change occurs in one application and the size of the change is reduced.

Even with a well-written and clearly-defined API, if there’s not proper decoupling between systems, what seems like it should be back to “adding 30 lines of code in four files in one codebase” ends up being “adding 30 lines of code in four files to the codebase primarily responsible for the feature, and changing 20 lines across each of the other two services because things aren’t properly decoupled.”

Features Introduce Seemingly Unrelated Bugs

Related to slowing feature development are code changes that introduce bugs in unrelated areas of the application. When multiple parts of an application interact with lower-level components instead of an agreed-upon interface, issues often arise. One simplified example I’ve seen is when a model is using some sort of state machine or status column, and multiple controllers are querying against the model directly. Especially when new states are added and multiple controllers are using NOT IN clauses to filter results, bad data might show up, an incorrect set of customers could be emailed, etc.

This, again, boils down to explicit interfaces and provided mechanisms for interacting with data. Code Climate discusses many options for refactoring ActiveRecord models, and as applications grow, it isn’t appropriate to interact with these models directly, instead relying on query objects, service objects, and other abstractions that enforce appropriate rules and constraints.

Services again feel like an answer: “If I make a change in system A, system B won’t be impacted.” However, subtle bugs often creep in. Debugging across multiple services becomes much more difficult, and verifying bugs requires standing up multiple systems to reproduce.

Slowing Test Suite

As dependencies grow within an application, so do test suite times. Testing behavior at the ends of workflows requires tens or hundreds of records to exist in the database, and mocking service responses to recreate a swath of data without persisting seems like a big win.

With well-defined, agreed-upon interfaces for system interaction at the application level, translating these interfaces to the test harness is hugely important. Instead of using a tool like VCR or WebMock and stubbing API responses, stub at the interface and return real data structures.

Services may result in faster individual suites, but running all suites would likely result in similar speeds. Additionally, confidence is often reduced unless a suite is added to test against multiple services.

Moving Forward

It’s perfectly reasonable to think that services are a solution to these problems. By forcing isolation of different areas of the application through explicit interfaces (HTTP over an API), it seems adding features would become a breeze.

I hear statements like

“We wouldn’t need to worry about side-effects in different systems!”

and

“We can isolate complexity so others don’t have to think about it!”

virtually every time services are brought up.

While this might be true, a team can accomplish this without using services. The biggest factor in what might have a positive impact is not the fact that the code is isolated; it’s that the team has agreed on an explicit interface upon which multiple areas can communicate. All information now has a known set of inputs and outputs (POST bodies, JSON responses) against a very limited set of operations (API endpoints). The same can be achieved by applying these exact principles to existing code and funneling what would be HTTP requests into individual mediators of responsibility (classes and methods, or modules and functions).

In practice, this is not easy. It requires a level of rigor that many teams might not be accustomed to, and in frameworks like Rails, the easiest thing to do might be to modify a value in session or update a record directly without giving it much thought. Over time, dependencies begin to bleed into one another and the result is a tangled mess.

Work against this entropy by considering how areas of the application are meant to interact, and write software to streamline these paths of communication.

Summers in D.C. can be a little brutal — not just the heat and humidity, but the MOSQUITOS. After a very warm winter this year (January and February were both the third-warmest on record), this could shape up to be an unpleasant — and long — mosquito season.

You may be tempted to call a mosquito control company to spray your property. While this might make your backyard barbecue more comfortable, it’s not good for the environment: the insecticides used kill not just mosquitos, but whatever other insects happen to be there, like butterflies, ladybugs, and bumblebees.

“We as humans will not be on this earth for long if we kill all the insects. It’s that simple,” says author Douglas Tallamy, an entomologist at the University of Delaware.

Insects are essential to keeping ecosystems functioning, Tallamy explains. Insects pollinate plants — both in the wild and in agriculture — and they are themselves a major source of nutrition. Insects also break down organic matter when a plant or animal dies, returning nutrients to the soil.

Though mosquito fogging does kill a lot of bugs, it isn’t very effective at what it’s supposed to do, Tallamy says.

“You don’t control mosquitoes in the adult stage because you have to kill 90% of them for that to work. These fogging companies kill between 10% and 50%,” Tallamy says. “So your yard becomes a dead zone without controlling the thing you’re really trying to control.”

To fight mosquitos effectively, you need to interrupt their life cycle at the larval stage, he says. This can be done by setting a trap to attract female mosquitos, then killing their babies with the bacteria Bacillus thuringiensis. The bacteria spores are available in a product called Mosquito Dunks. People often use dunks to keep mosquitos from proliferating in decorative ponds, bird baths, rain barrels, or other standing water.

The bacteria only kill the larvae of mosquitos and other aquatic diptera, such as midges (small flies), but do not harm most insects or other animals. Dunks are considered a “biopesticide” — they use bacteria rather than manmade chemicals to kill mosquito larvae. (Mosquito fogging companies typically use pyrethroids, manmade chemicals that are toxic to a broad range of insects.)

To create our DIY mosquito trap, we’re going to intentionally create an ideal mosquito breeding ground.

What You’ll Need

• A 5-gallon bucket
• Straw, hay, dead leaves, or grass
• Some Mosquito Dunks
• Chicken wire or a mesh bucket lid (typically used in hydroponic growing)

Step 1: Lay The Trap

• Toss a few handfuls of straw, hay, dead leaves, or grass into the bucket, then fill the bucket up halfway with water. Cover the bucket with the mesh lid or wire, to keep pets and squirrels out. (H/t to Jill Spohn of the Audubon Society of Northern Virginia for the mesh lid idea!)

Step 2: Let It Brew

• Put the bucket in a sunny spot for a few days to let the watery mixture fester. “That builds up populations of diatoms and algae — that’s what mosquito larvae eat,” says Tallamy. “That becomes an irresistible brew to ovipositing mosquitoes. The female mosquitoes in your yard will come lay their eggs in your bucket. Nothing’s going to out-compete that.”
• You can wait until you start seeing mosquito larvae in your bucket. Or just wait a few days.

Step 3: Dunk The Dunk

• Put a dunk in your bucket and put the lid back on.
• You’ll need to check your trap periodically to make sure it still has water in it and to check the status of the dunk. The dunks dissolve slowly over time, and should last 30 days, according to the manufacturer. Once the dunk is dissolved, you should add a new one to keep the trap going.

Step 4: Check For Other Standing Water

• Make sure you’re not providing other places for mosquitos to lay eggs: check your gutters, drains, sewers, planters, and anywhere else where water could build up. It only takes a tiny bit of water, and one mosquito can lay 100 eggs at a time. You can put dunks in any standing water you can’t get rid of (or use the smaller Mosquito Bits).

Step 5: Talk To Your Neighbors

• If your neighbor’s yard is filled with old tires collecting water, all your mosquito control efforts will be in vain.

This story was updated to clarify that Mosquito Dunks are considered a pesticide, specifically a “biopesticide.” According to the U.S. Environmental Protection Agency, a pesticide is “any substance or mixture of substances intended for preventing, destroying, repelling, or mitigating any pest.” 

The post Mosquitos Suck. Here’s How To DIY Your Own Trap appeared first on DCist.

[Did the world really need another place to buy trash?]

During the Super Bowl on Sunday, an ad for “Temu” played several times.¹ In it, a woman buys a flurry of products at what I can only describe as disturbingly low prices.

In 2023, a dress should really cost more than $9.

But what exactly is Temu? The ad was not clear. Is it a fast fashion site? Do they sell used items? I couldn’t figure it out, so I visited the Temu website. In a word, that was a mistake. Though the company had spent millions of dollars on advertising during America’s single biggest night of television, their site was the worst kind of spammy garbage. It had pop-up offers, flashing messages, countdown clocks, and a wide variety of very cheap and very crappy products. Once I ascertained that the company was a reseller of all manner of disposable crap, I quickly left, expecting never to return.

The next day, I found myself inundated with their web ads, likely a result of that initial visit to their site. One particular item being advertised really caught my eye, and led me to open Temu site once again. This is the “Creative Silicone Bicycle Tail Lights, Waterproof Bicycle Accessories Suitable For Night Riding”:

🙊 Barvd

Now you might be thinking “Are those…bike nuts?! Truck nuts…but for a bike?”. I urge you to get your mind out of the gutter. No. Of course they are not glowing bike nuts. Perish the thought!

No, that is clearly a lovely upside-down glowing heart, and it’s just in time for Valentine’s Day. For the low, low price of $3.59, you can show your cycling sweetie how much you care, all while helping them stay safe. I can’t think of anything more romantical.

Footnotes:

1. The ad is archived here. ↩︎

Recently, a robot vacuum in England made a dash for freedom. Unbeknownst to staff, it popped over the lip at the entrance, and then took off. That’s a fun little story, certainly, but it was this quip that really stood out to me.

While some readers joked about the robot’s adventures, one feared for its safety in the great outdoors, pointing out that “nature abhors a vacuum”.

If Aristotle knew his work would be remembered almost 2,500 years later, and used thusly, he would surely be proud.

Link: https://www.bbc.com/news/uk-england-cambridgeshire-60084347

In 1995, technologist Clifford Stoll wrote an article for Newsweek entitled “Why the Web Won’t Be Nirvana”. 20 years later, in 2015, that article is more than a little hilarious.