Recent Posts (page 63 / 69)

by Leon Rosenshein

WAT?

I was working on the Infra dashboard yesterday and had a problem with one of my <script> tags. There's some bug somewhere that was translating

 <script type="method">
    if (Math.random() &lt; 0.05) {
      document.getElementById('logo').src = '/static/other.png';
    }
</script>

to

 &lt;script type="method">
    if (Math.random() &lt; 0.05) {
      document.getElementById('logo').src = '/static/other.png';
    }
  &lt;/script>

And of course, that didn't work. Turns out that there's a parsing bug somewhere and removing the type="method" from the <script> tag makes it work. My first reaction to figuring this out was Wat? According to XKCD there are 10000 people who will learn about Wat? today. If you're one of the lucky 10000, enjoy

by Leon Rosenshein

Languages

We’re all multilingual. We speak C, C++ (yes, they are different languages, not dialects), Python, Go, Java, Javascript, Matlab, Assembler, and many others with varying fluency. And that’s good and proper. Using the right tool at the right time is one of the marks of a craftsperson, just as much as the ability to do quality work with the available tools is. Master craftspeople not only know which tool to pull out of their toolbox, they also stay aware of new tools and methods being developed. InfoQ recently published their Programing Languages Trend for 2019. The list and commentary are interesting for themselves, and even more interesting is some of the back story about why people are starting to use those languages. Understanding the problems the different languages are trying to solve can give you a whole new perspective on whatever problem is currently top of mind for all of us.

And, on an unrelated note, I was looking through some of the repos we have and noticed that many of them have .envrc file in the root and was wondering what that was for. I took a look inside one and there was this comment

#!/bin/bash
# Users of direnv can run `direnv allow .` here to automatically update the
# PATH.
# enter this directory or any descendent. <https://direnv.net/>

and suddenly a light went off. I’ve been struggling to deal with multiple repos across ATG and Prime with different (and often incompatible) versions of their toolchains and wondering what to do about it, and there’s the answer. direnv. I think I can even get it to handle switching versions of arc for me as I switch repos, but I haven’t dug that deeply yet. Check out direnv.net. As the kids say these days, 10 out of 10, would recommend.

by Leon Rosenshein

Platforms

For most of my career I've been working on platforms, From Flight Simulation to 2/D3D geospatial visualization to infrastructure. One of the keys to building platforms (or for anything really) is customer value. A long time ago a marketing instructor told me that developers build features, but customers buy benefits. Those two are very closely related, but they're not the same thing. When you're building a platform they intersect at your API. It doesn't matter if it's possible to do everything your customer wants with the API, it has to be easier for them to use the API now, not in 6 months or after a climbing a steep learning curve. If your API doesn't provide value then your customer will figure out a way around it, build their own internal API, and leave you stuck supporting it. This is true at every layer, from the OS to the UI.

So how do you build APIs that not only provide value now, but are extensible so you can keep adding features without pissing off your customers. There are many language specific things you can do. From optional parameters with default values to versioned input/output structures that your API later decodes (as an aside, did you know that most Win32 APIs take, as an input structure, some base type then check the size of the structure to determine the version?) you can isolate your customers from your internal implementations/choices.

But those technical details, as important as they are, aren't really the answer. The key is to understand that users of your APIs are customers, and treat them that way. That means that (within reason) the customer is right. As William Gibson said, "the street finds its own uses for things". If they find a new use for your API figure out the problem they're solving and help them solve it.

Treat your API as a contract and honor it. Make it simple to understand and do what your users expect. Make it hard to misuse. Don't surprise them with side effects. Don't leave things in a half-baked state. Think of the "Verbs" your API supports. REST makes it obvious. CRUD is just a set of verbs.

Bottom line, make your customers want to use your API, not roll their own.

by Leon Rosenshein

Kaizen

I've seen people wearing t-shirts have the Kanji for Kaizen on them. If you're going to wear the shirt you should know what you're saying. According to the Googles, Kaizen translates to "Improvement". That's simple enough, and a worthy goal, but when you connect the term to Toyota it brings in an additional level of meaning, the Toyota Production System, or The Toyota Way. It's about culture and culture change. It's about expectations. It's about empowerment and obligations. At Toyota it was embodied by the Andon cord and this story:

When asked if they intended to give workers on the assembly line the power to stop production the answer was "No, we intend to give them the obligation to stop it whenever they find a problem."

by Leon Rosenshein

Monoliths vs Microservices

MIcroservices are all the rage. Prime is all-in on microservices, moving from RT-API to thousands of microservices (there are more services in the Prime call graph then there are engineers). They're an answer, but are they the answer? Before you can answer that you have to decide what your goals are, and what the payoff threshold is. At a high level things like separation of concerns, reduced fragility minimizing unintended side effects and reducing developers learning curves are good things. Microservices are an approach to that. Of course, like any other choice there are consequences and trade-offs. Shopify had a monolith that grew organically over time, and at some point they realized it was slowing them down. Instead of being trendy they took a different approach, the Modular Monolith, As the blog shows, microservice or modular monolith, it really comes down to graphs and interfaces. If you can get that right and enforce it you'll have an enduring architecture you can grow with. 

by Leon Rosenshein
by Leon Rosenshein

Following The Vision

On a related note, one of the most important parts of architecture is being able to explain your architecture/design to others so that they can follow the vision when you're not looking. If you don't do that you have at best a bottleneck, at worst an architecture that doesn't match what gets built. There are lots of ways to communicate architecture, and one of the keys is tailoring the content to the intended reader. Here's a list of ways to communicate architecture.

by Leon Rosenshein

Architecture is just software design at scale

If you're ever interested in a 15 minute speech about why let me know. Happy to spend time over a coffee (or 2 or 5) talking about how the difference between code design and architecture (or different levels for that matter) is just a matter of scale. For a quick overview, here's Uber's own Gergely Orosz talking about it.

by Leon Rosenshein

Is It Useful

Customer Journeys, User Stories, Personas, Use Cases. All different ways of trying to ensure that whatever you are building is actually useful for the customer. Whether you're putting together an architecture or a team, they're a good thing to keep in mind.

by Leon Rosenshein