Jon Phenow

My FeeLLMs

Mon, 14 Apr 2025 20:10:00 GMT

I’ve remained largely quiet about the surge of LLMs in software engineering, apps, and the broader world. I’ve held back because I think I have largely repetitive quandaries, qualms, and quips. For whatever reason, I’ve decided now is the time to write about it.

This post is largely a ping pong between my anxieties about LLMs and my conflicting feelings of anxious optimism.

I’m worried about the work that was stolen to make LLMs go. Unfortunately, it seems unlikely we’ll be returning Pandora to her box. I don’t think that means we should give up on doing better to upgrade our understanding of licensing works that wind up in LLMs. As much as possible, I prefer to avoid supporting folks that do things like read the entire internet regardless of licensing then complain when they believe someone… stole “their” IP. While LLM companies made magnificent leaps forward, I’m not convinced they had to ~steal from people to make such progress.

I’m excited by the forced progress on things like energy production, though I don’t feel much hope over our ability to either burn less or sufficiently convert the majority of our burning to renewables. Something about a guy named Jevon. So far the most I feel I can say about this is that it’s just a discomfort like that tag in my shirt I can’t find that’s scratching my skin. I suspect the longer term effects are greater than any of us can conceive yet. In reality some of the energy side-effects are likely already here but don’t affect my day-to-day grievances.

I listen to the Center for Humane Technology’s podcast, and they’ve been circling on an insidious concern around LLMs that has stuck with me: the unknowns around what this will do to us and our brains. While I’m concerned about the potential for lost jobs and a world unprepared to deal with it, I’m perhaps more concerned for the accidental reliance on it for things like critical thinking, research. I try my best to hit [tab] on Cursor when it’s things I believe to be skippable - things that are not my primary focus that could just be done, and are simple enough. But much like the algorithmic feeds, it’s hard to fully grasp what this will do to society and how we exist in a world where many people are already dubious of our ability to think critically. I offer no answers, only anxieties. It could just be a mild discomfort I have now, or it could slowly destroy us inside. It’s also the kind of thing that’s hard to fend off as any single individual.

Frustratingly, I find it immensely useful to let it do some of the things ([tab] on Cursor) that increasingly feel below what I could be focusing on. I get a little bit of a boost when I feel like it worked or got me 95% of the way without making me work as hard as I would have without it. It remains to be seen whether my feeling is the emotional response to getting the robots to do something for me or whether it actually allowed me to do something faster then put more focus elsewhere. I suspect it’s a little of both.

For whatever reason, this also feels like a moment to pontificate about what might be missing from LLM tools for software engineers. I see roughly 3 very broad angles that LLMs can help with in software engineering practices: new projects, existing projects, and operating a project.

A lot of the tools out there are good and seem focused on “new projects” (Lovable, Replit, Bolt.new, v0 [Vercel]) but I’ve had issues mostly with ongoing conversation, token limits, winding up in a back-and-forth with the LLM to get something right.

There are good tools out there for “existing code” (Cursor, Co-Pilot). As an experienced engineer, I find these the most useful. I have a project, I understand it, I want to point the LLM around to do things or just provide a snappy autocomplete to the work I already understand well.

The third angle: “I have code, I need something to make it run somewhere, stay running, etc.” is one I haven’t seen much of yet. There are probably lot of good reasons for that. My guess is that it’s harder to do well enough that we’re willing to let something go accidentally run our cloud bill or do something with less human oversight. The first two tools generally have a place for a human to interact. I’m not sure this third does or the interaction moments are very different from the first two.

I think something roughly groundbreaking Could be finding a way to get the third thing running, then finding a way to tie together these three things into one “build, iterate, and run software.” Then again, I’d like to have a job in 5 years so forget what I said, definitely don’t use LLMs for software.

In all seriousness though, I’ve found some use for LLMs in my day-job and side-projects. And while I try to keep up with an annoyingly fast-paced profession, I’ve found I do have to keep an eye on the software they’re creating. I believe they simply aren’t ready for unattended software building yet, and I suspect they won’t be until we can find more annoying ways to put the right context in front of them.

P.S. This post is a bit stream-of-consciousness and fails to go as deep as I’d like on anything in particular. I hope I’ll find some time to bring some more depth to each of these points as I get back into the habit of writing.

What are you most concerned about? Excited about?

I'm back (2025)

Sat, 12 Apr 2025 01:00:00 GMT

Hello again.

I’m getting back into writing.

I probably won’t write consistently. We’ll see if I write something beyond the first few ideas I have.

I’ve always had a hard time deciding when I’ve had a thought worth writing down, and also sharing. I’ve found that it’s useful way to work through some thoughts, though. It really helps me to get something ready to share. It forces me to think about how I actually feel, how to present it, and whether it’s something I should rethink, research, or just let go.

So, I’m “back”.

Was I here before?

I’ll have bad insights, experiences, and once in a while I might have a thing I’m actually glad I shared. Good luck with everything in between.

I doubt I said this on a blog ever so here’s a bit about me in 2025:

I’ve been a software engineer since around 2008
I’m a husband (as of 2019)
I’m a dad (as of 2023)
I like building things that are useful for people
I have strong beliefs about how people should treat each other and how should and do systems affect that
I have strong beliefs about how people should treat the planet and how systems should and do affect that

I don’t know what I’ll write about. I’ll write about software I’m learning about, working on, or using. I’ll probably write about life. I’ll maybe write about things that I need to externalize in order to explore an idea out loud. I’ll write about what I feel like writing about.

I’m not sure how much I love the old posts I had. I almost removed them. I’m going to leave them up for now. Like tattoos, they illustrate where my head was at during different times.

Cheers and, if you’re reading this, welcome.

Be good to each other.

When Product needs to get Technical

Wed, 12 Jun 2019 15:25:41 GMT

When Product needs to get Technical

In a company with a Product team, the Product managers have one focus: Your products. Everything to do with what your company is producing and selling is what they deal with. That means anything from setting up your Support team to understand the functionality to cooperating with Development to build it, from sanctioning Marketing to Sales preparation and training. They’re generally managing the product from an idea perspective: what is it solving, what exactly are we building and supporting, who is the product targeting. Each of the deeper caveats like “how is it built” are a conversation between Product and the other appropriate teams, like Development. I’d like to specifically explore the Product and Development relationship.

Now would be a good time to step back and paint a picture of what I’ve seen so far. A few people build a company around

Developing a Writing Plan

Wed, 12 Jun 2019 15:25:40 GMT

You just have to start. As in anything, your idea doesn’t mean anything until you start working with it. You can roll it around in your head all you want, thinking about all of the lovely ideas you have, but it doesn’t mean anything will its bouncing around up there. While you hold it in your head you could forget any minor epiphanies you have, you can’t share it with others to focus the argument or discover other useful directions it could take. You won’t have learned anything. A fleeting thought is as useful as that time you thought about that great idea that could fix the world then instead hid in your house, looking at Reddit. You didn’t help anyone, not even yourself, by just thinking about it.

Let’s take writing as an example. Decide what your purpose for writing is. I’ve recently decided that I would like to write to be more timeless and widely applicable. Its not an extraordinarily fresh idea, nor is its essence something I haven’t attempted. That doesn’t matter though, I have a theme that I’m aiming at for now. That theme will most likely change over time. This way, though, while I’m putting down notes about what next to write about, I can use this as a guideline for what to focus on. What to focus on within each article or whether that article belongs at all.

The first theme that you focus on will not be your last. Using myself as an example again, I started writing years ago. First, it was about my travels as a kid in school, mostly used while I was travelling abroad to communicate back to family and friends what I’d been up to. That died after a while (or after I inevitably had less interesting life stories to write about). I eventually returned to talk about the minute details in code that I had figured out, or understood about something fairly specific. A lot of the posts were in code. As I grew up as a Software Engineer I recognized less and less when a particular obstacle was worth penning a blog post. The writing days died again. Finally, in a most recent attempt, I was writing about the slightly more abstract concepts and critiquing them using pseudo-code examples. Again the writing died after a short period.

You could argue the first two themes were eventually going to die, by my own hand if not by time’s. The last theme, where I considered writing about abstract concepts using some more concrete examples, had a little more meat to it. That’s all well and good, but none of the themes are why the writing died. They died because I didn’t make it a priority.

Ultimately to be successful at something it has to become part of your part of your week, part of your day, maybe even part of every hour. For my endeavor, I’ve decided to carve out exactly 30 minutes into my every-day schedule. That might mean puking words out into a notebook to grow an idea, talking through it with a friend and writing notes down or editing. This time is devoted to the actual act of writing. Get those initial, rough ideas down is important. Speaking realistically, though, you won’t (and shouldn’t) use all that much of the words from these vomit-sessions. These bits of time are for two things: creating a habit of expressing yourself and your thoughts in words, and for finding general ideas that you feel you can talk out-loud about.

Forming that habit will be enough to evolve your writing, your thinking, your style. The habit of writing every day won’t, in and of itself, produce a publishable blog — if that’s what you’re into. Its a huge start, though.

When you’re writing and writing to write you eventually realize a few things. A lot of your initial ideas suck. A lot of the ideas that don’t suck aren’t distilled to what you really want to talk about. It doesn’t flow well into an understanding of the idea you’re trying to get across to your audience. When you write every day and make a similar habit to read back over things, pick the good one, do some editing, trimming, external research, peer review (if possible), you might actually have something.

Its hard. Accomplishing anything like this is hard. But if it were easy you wouldn’t learn anything, nor would your readers.

Doctor Who comments on ISIS and Domestic Mass Shootings

Wed, 12 Jun 2019 15:25:40 GMT

S09E11 @32:18

Focus is a Limited Resource

Wed, 12 Jun 2019 15:25:40 GMT

Focus is a difficult thing to achieve. Sometimes it happens by accident because you’re generally interested and driven. That interest and drive can come because of the specific topic or task, but often times a concerted effort is required to actually focus and get a thing done. I’m here to tell you that its entirely possible to find focus regardless of interest.

In the past few months I started working remotely for a company. This wasn’t a big shift for me, at first. My previous company was pretty flexible, which gave it sort of a hybrid feeling of remote and in-office. The initial months of working with this new company were powered by pure excitement of working for a different company, with new people and new ideas. Luckily the most recent months and weeks are still filled with an awesome company, great people and fun, challenging ideas. Something is different though, my mood and and output changed for a brief time.

Crossing the finish line

Wed, 12 Jun 2019 15:25:40 GMT

In Software Engineering code that is running in production is infinitely more valuable than anything you have built that isn’t yet deployed. That is to say you could have this amazing new twist on a feature that’s beautifully written and well tested, but it doesn’t mean anything until its been deployed to your customers. Up until its deployed its just vapor. Nothing more.

Horseshoes & Hand Grenades

Wed, 12 Jun 2019 15:25:40 GMT

“Close only matters in horseshoes and hand grenades,” I first heard from my grandpa many years ago. Many things are binary, true or false, complete or not-complete. Almost completing a task is the same as not completing that task. There is no gray area, and stop letting yourself think there is. It seems like a pretty harsh sentiment but I think there are real lessons to learn from thinking this way.

Analogy time: think about completing things in terms of a marathon. In a marathon you run 26.3 miles. There’s a start line and an finish line. If I run 12 miles, and my legs give out, I did not run a marathon; I ran 12 miles and failed. If I run those same 12 miles, pass out, get some food and finish the marathon, then I ran a marathon. Every day I train, I’m working towards being able to run a marathon. That progress is all moot if I never run the marathon. Each mile during a marathon, every minute put towards that race is only progress if I complete it.

This applies to software projects as well. Working on code for hours then never committing your code is not progress. It might be fun for your brain or it might help you find new solutions, but that’s not necessarily progress towards your ultimate goal. Opening a pull request isn’t progress. If the pull request results in a discussion that ultimately results in a definitive answer, it could be considered progress. Opening pull requests without ever making a decision about them is like constantly training for a marathon you never intend to run.

There’s a few ways to train yourself to efficiently work towards your goals. (what is this? talk in the intro about what exactly we are getting at, why progress is important)

Work on tangible things

You should be able to quickly grok your goal and know exactly what it is with all its caveats. Something like “I will be able to run a marathon in under 4 hours” is great, but not “train for a race.” What race? How far is the race? Am I running? Biking? The definition of what you’re working towards is one of the most important things; it defines your progress, failure, everything.

Have a timeline

Goals can’t go on forever. The timeline is there to help you push yourself a bit, evaluate if you’ve succeeded or not and adjust your future goals. Without a timeline you’re just lying to yourself about what you’re “focusing” on.

Be realistic

In order to be realistic I try to find a baseline goal to understand the status quo like “run 10 miles this week.” Knowing that I can do that, stretch a bit and plan to run 13 miles next week. Understanding the baseline allowed me to decide if I should push on further or if I should keep trying to be successful at 10 miles.

Evaluate

Use the basic guidelines you setup for your goal to measure whether or not you’re successful, or heading towards success. Once a goal is set I like leave it there until the end-date to keep progressing towards it, but if you evaluate and you’re clearly going to fail, maybe re-evaluate your goals and priorities then and there.

Failure is ok, but move on

Admit failure when it happens, doing so allows you to move on and try again, maybe being more realistic. Its not the end of the world, but clearly something needs to change to be successful next time.

People have been saying a lot of these things for years now. I remember hearing some of this in High School and thinking it sounded silly to even talk out-loud about, because “duh.” For me, though, I thought a lot of it was obvious when someone said it, but once I actually applied some of this to how I think about work and personal goals I felt the difference. At least now I’m starting to get a clearer understanding of my abilities and can make smarter decisions about my personal priorities in life.

EVALUATE/DELETE

A few years ago I decided to train for and run the Minneapolis half marathon. So I Googled half marathon training and landed on Hal Higdon’s guide. I lined up my calendar to finish my training on the correct day, picked up a pair of Saucony shoes for distance running and off I went. Over the following three months, I spent much of my time keeping up with the training schedule. I did pretty well, if I do say so myself. On the day of the race I had a friend drop me off near the start-line just a few minutes before the gun. Standing at the start line for a longer race is really pretty energizing. It’s hard not to ponder the work you’ve put in in the last few months, and everyone else is feeling the same way. There’s a lot of excitement. A few minutes go by, then another 10, then 15. About half an hour after the race was supposed to start Team Ortho, who runs a lot of local race events, cancelled the event due to the looming storm. This storm was apparently particularly alarming for this race due to the close proximity of the Mississippi river to the route. Well crap, months of training and a lie of a participant T-Shirt.

Shortly after this failure of a half-marathon, some friends convinced me to direct my training towards a Full marathon. Some re-jiggering of the training schedule, find some new routes and back on track. As the training schedule became more difficult to fit into a day so did my work schedule. One thing led to another and I wound up injuring myself a few weeks before the race. I screwed myself this time. I didn’t end up running the race. Yet again, months of training and I was still not a Marathon runner.

There’s no such thing as an almost-marathoner. There’s just people who’ve run marathon and people who haven’t. In terms of marathon races its more or less a badge of honor to be able to say you’ve done it. You endured that work and felt the pain and excitement of that journey. There are stages to the journey you need to take though. Let’s think about this in terms of a software project: my code is finished, mark it as complete. Something’s wrong though.

/end with becoming a marathon runner

An Introduction to HTTP Signing

Wed, 12 Jun 2019 15:25:40 GMT

In the world of APIs, we’re exchanging data that we care about. The data may contain sensitive information or maybe you just want to trust the data hasn’t been tampered with. Mechanisms like TLS give us some sense of security in that you’re interacting within an encrypted transport system, but perhaps you need more validation that incoming data hasn’t changed or that the client app is who they claim to be. This is especially important for things like Personally Identifiable Information or Financial data. We can get this added sense of security using a somewhat newly drafted standard called HTTP Signatures. Using this standard, as its currently drafted, you can verify that data for an HTTP Request hasn’t been altered during transport and you can use this information to gain confidence in who sent the request to your server.

“HTTP Signatures” is currently in the draft stage of becoming an IETF standard. Forewarning that its current draft status means that it’s still subject to changes or it could not make its way to being a full standard. The concepts and general idea, though, I think are fully worth considering. Even if it weren’t to become a standard — you could apply these concepts and permit their use using your API and provide libraries for clients to use.

Signing your HTTP requests is important in high priority areas specifically because TLS (and SSL) have been known to have vulnerabilities over the years. You should absolutely use the latest TLS when possible, because its still a good first step. If you’re concerned about the integrity of the data entering your system, though, you should always consider extra avenues with which to validate incoming data. Specifically, HTTP request signing can help you ensure that data hasn’t changed during the transport of the request from client to server. Let’s get into some specifics about the standard to better understand.

Request signing parameters live either within the `Signature` header or the `Authorization` header (prefixed with “Signature ”). For the purposes of this post I will refer to the `Signature` header. Within that header there are four parameters we care about:

keyId

The `keyId` is used to identify the client connecting to our server. This would be used, in your server, to locate the credentials that will be used to sign the data. Perhaps you have a `clients` table with an identifier (matching the `keyId` that would be provided) and a set of credentials that are used to create the signature.

Example:

keyId=“chat-app”

algorithm

The `algorithm` signifies which signing algorithm was used for the request. so that both server and client are on the same page as to which algorithm will be used to verify the data. A signing algorithm uses cryptographic standards to generate a digest from the data we want to ensure hasn’t been tampered with.

Example:

algorithm=“hmac-sha256”

headers

The `headers` parameter is optional at this point in the standard’s draft, though I personally think you should always list them. Listing them enforces that both client and server are aware of the order of headers and will protect you from issues due to unanticipated middleware, or something of that nature, rendering your request verification invalid. Each header must be lower-cased and separated by a single space. A special identifier “(request-target)” is generated by concatenating the lowercased Method, a space and the path pseudo-headers (for more on this see Section 2.3.1).

Example: assuming we wanted the route information and the date header verified:

headers=“(request-target) date”

signature

The `signature` parameter contains the actual message digest; the message digest being the encrypted data that we will validate on the server as having not been tampered with. The signature body (the not-yet-encrypted data) is created by collecting the key and value of the `headers` specified and joining them, in the order specified, with newlines. Here’s some pseudo-code to illustrate what happens to get the digest from the body:

algorithmFunction = getAlgorithm(algorithm, getCredentials(keyId))
base64(algorithmFunction(signatureBody))

That is to say that we must get an encryption function (using our algorithm parameter), use our credentials from the Key ID to encrypt that data, then Base 64 encode that digest.

Example: If we were to use the RSA keys provided from the draft’s test samples, specify `headers=“(request-target) date”`, with a request:

POST /foo?param=value&pet=dog HTTP/1.1
Host: example.com
Date: Thu, 05 Jan 2014 21:31:40 GMT
Content-Type: application/json
Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Content-Length: 18

Our `signature` parameter would look like:

signature=“KcLSABBj/m3v2DhxiCKJmzYJvnx74tDO1SaURD8Dr8XpugN5wpy8iBVJtpkHUIp4qBYpzx2QvD16t8X0BUMiKc53Age+baQFWwb2iYYJzvuUL+krrl/Q7H6fPBADBsHqEZ7IE8rR0Ys3lb7J5A6VB9J/4yVTRiBcxTypW/mpr5w=”

Ultimately, a Signature header would look something like:

Signature: keyId=“chat-app”,algorithm=“hmac-sha256”,headers=“(request-target) date”,signature=“ATp0r26dbMIxOopqw0OfABDT7CKMIoENumuruOtarj8n/97Q3htHFYpH8yOSQk3Z5zh8UxUym6FYTb5+A0Nz3NRsXJibnYi7brE/4tx5But9kkFGzG+xpUmimN4c3TMN7OFH//+r8hBf7BT9/GmHDUVZT2JzWGLZES2xDOUuMtA=”

Verification

Verification is somewhat straightforward if you take a look at the pseudo-code above for how to create the signature digest. If you’re using a symmetric signing mechanism, like HMAC Sha-256, then you just build the signature the same way the client did and compare the signature values. If they match then the signature is verified. For asymmetric mechanisms, like RSA, its a bit more involved. The client will have signed their data with the private key. When it reaches the server you’ll need to Base64 decode the signature, then verify that using a the corresponding public key.

Libraries

HTTP Signatures aren’t a terribly complex concept, but that doesn’t mean you should have to go write the whole system every time you’d like to consider including it in your API workflow. We decided to [[[Open Source]]] a set of libraries for multiple languages to help encourage people to try the almost-standard out.

Please try them out, submit issues/pull requests or simply [[[tell the world]]] to check it out — we’d love to spread the word.

So What?

We think that a final check as to the integrity of request/response data is important, especially in scenarios where user data is heavily involved. This mechanism provides a standardized, but flexible framework with which to work in. At Highrise we’ve been using this system successfully between some of our internal services to verify the origin of data as well as the integrity. once the system is in place its little more than after thought and is something that’s simple to monitor for failures. In world full of security issues, lets take as much care as we can in protecting our users and ourselves.

Thanks for reading! I work at Highrise building a simpler CRM. If you liked this and want to hear more about software, products and the like let me know on Twitter!

New Politics and The Art of Exploitation

Wed, 12 Jun 2019 15:25:40 GMT

Creating Mutli-File Templates for Visual Studio (Mac)

Wed, 12 Jun 2019 15:25:40 GMT

At Highrise we ended up rewriting our mobile app using Xamarin — with some use of Xamarin Forms. There was a lot that went into that decision so I recommend this as a starting point to understand how we wound up using Xamarin and C# at a company known to work on Ruby:

Embed placeholder 0.006131318380667938

We’ve gone through a few stages of developmental enlightenment while building this app (these apps?). A description of these stages deserves it’s own series of posts, but I’ll do a quick overview to provide the background it takes to understand.

Custom file templates for Visual Studio (Mac)

Wed, 15 Nov 2017 20:18:19 GMT

Photo by [Juan Di Nella](https://unsplash.com/photos/OUgLA2unwtg?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

Recently, we’ve been doing a little restructuring of our Xamarin-based mobile apps. We wound up with a stricter pattern for building out views and their elements. Coincidentally, that’s providing faster development and more freedom to focus on the meat of making the app work really well. With the new structure, we have a more standard way of building things. As that common pattern has became more obvious, though, we’ve wanted a first-class way to encourage a common style of adding to the app. Rather than truly enforcing it, though — and boxing ourselves in — we decided to make the most desirable path the easiest. We want to provide snippets or file templates to make new development as easy as possible within our internal framework. The simplest starting point is to just provide templates that are available when you create a new file in Visual Studio. Let’s talk about the research it took to create our own custom file templates for Visual Studio for Mac, how we actually created and distribute them internally, and finally, where I think Visual Studio for Mac could improve the state of things.

Side note: The Story Time is a lengthy explanation of my journey to a solution, not the solution itself. If you really just want a small guide to Custom Multi-File templates on Visual Studio for Mac, skip on down.

Story Time

Before we get into the specifics of how we built our custom templates, I’d like to discuss the work it took to learn enough to write our own custom templates. Not to disparage Microsoft, or complain about the work — as an explanation of what it took and what I’d like to help improve in the future.

The first thing I do in a situation such as this is hit Google with “Custom File Templates for Visual Studio.” Great, here’s a bunch of useful and relevant looking links — jackpot:

Too bad all of these are for either Visual Studio Code or Visual Studio for Windows. I learned over the course of trying to implement these templates, that the Windows version of this is entirely incompatible with the Mac version of how you’d add custom file templates. That was somewhat frustrating to realize, but I can understand. Things have changed a lot in this part of Microsoft recently and it’s hard to keep everything straight all the way down to documentation. So moving forward, we’ll have to be sure to scope our searches to Mac.

I was convinced, when I walked into this, that custom file templates would be like a solution configuration item or something. Perhaps there’d be an option to provide a few working templates via configuration and voila. Through my reading, it quickly became apparent that on the Mac Visual Studio, you create a full-fledged Extension and distribute that. That seems heavy handed, but I wasn’t about to walk away from this without custom templates.

Eventually I found my way to this Stack Overflow question which references the MonoDevelop Extension documentation. While reading through everything it became useful to know that Visual Studio for Mac is a continuation of Xamarin Studio which is (I think?) a superset — or perhaps just a distribution with extensions — of MonoDevelop. Once on the MonoDevelop documentation, things start to make a little more sense. Reading the docs, it looks like I’ll need to install this Addin Maker Extension to Visual Studio, create a new solution, then follow the steps in these docs.

It’s at this point, though, that I realize the documentation, on Microsoft, on Xamarin, and on MonoDevelop all reference how to add a Command tool — which seems to basically execute some arbitrary code and place it in the active editor. That’s not what I want. Further reading shows a way to create Project Templates — which for some time I pursue, only to realize that they are truly project templates, not file templates. At this point I had been hoping it would apply to both situations.

I’ve seen enough to realize that it’s time to go looking in the source. In the Addin Maker Extension source, since it’s an extension of its own. After some digging, I come across their File Templates in their Addin Manifest (don’t worry about fully understanding this yet, I’ll expand on actually creating an Addin in the next section). This is all well and good, but the files they reference in the manifest (like Templates/FileTemplate.xft.xml) are no where to be found. I’m not fully versed in how this project works, so pocket that for a little later. Looking back at notes, I was able to recall a forum post on Xamarin’s Forums that linked to an example in MonoDevelop itself. Finally, an example of the Manifest format for my use case as well as the template format.

So after pursuing implementing the distilled version of what I learned above — I had some final things to implement. I wanted to create 3 files in my template: A Xaml page, its code-behind, and a matching PageModel. Since we’re thin on documentation here, I found and perused the Schema definitions to learn that we can specify multiple files for a template — success! But how do I recreate the Xaml/Code-behind behavior that’s so automatic within Xamarin tools? At this point I recall, also from notes, that we have access to some of the Addins installed on the computer (which is missing some of the manifest and template definitions — otherwise all of my searching would have stopped here, a while ago). Opening /Applications/Visual\ Studio.app/Contents/Resources/lib/monodevelop/AddIns/Xamarin.Forms.Addin/Templates reveals details about how to build templates that include Xaml and code-behinds. There, we’ve got it. I’d link to the source of this, if I could find it anywhere.

On top of building the templates, we have to somehow distribute this extension. The main things I know: I don’t want to distribute this publicly, since it’s somewhat specific to us, and I want it to be simple to both distribute and stay up-to-date. Once again, during my short explorations, I wasn’t able to track down much on how to host your own repository. To get this over with, for now, I’ve decided to create a script that packages up the `mpack` (extension file) and pushes it to our Github releases on the Extension’s project page. Once published, we just need to tell developers to download it and install it from file. This is less than ideal, but I’ve already sunk more time into this than I had hoped.

The point of the above simply to illustrate that this was harder than I expected. It’s not meant to just be me complaining about the state of the art, it’s a note that this is what it took me to achieve what I set out to do. If that results in further interest to improve the system, or simply the documentation — Awesome! It’s meant to help remind myself what I’d like to help improve.

Microsoft is doing a ton lately — that’s one of the reasons Xamarin and the tooling around it was so attractive when we set out to decide how we’d build our mobile apps. They’ve got deep changes going on in the core of how .NET operates, Visual Studio Code is changing things, Roslyn is changing things, Visual Studio for Mac (and consequently Xamarin) is changing things, .NET Core — the list seriously could take me the rest of the day to write-up. So much of what’s going on seems to be aiming at better standardization across the board — everything is operating on a different history, different scale. Things are converging and diverging at the same time because of the speed and breadth of what’s going on.

It’s all a mix of exciting, confusing, frustrating, and fun. I hope that Microsoft reaches a point where some of these things standardize in the next couple of years. I don’t say that with a bad taste in my mouth — I say that because that simply be amazing to use and would change the face of software as we know it, I think. That’s a cool future to look forward to.

How To

Enough of the soap-box, let’s talk about how to actually get some file templates. For our example, let’s build what I mentioned above: a template that comes with a Xaml page, with code-behind and separate PageModel class. Open Visual Studio for Mac, Open the Extensions Menu, and install the Addin Maker:

Create a new IDE Extension solution:

Open Properties/AddinInfo.cs and change the values to whatever you’d like. I do this because otherwise I forget and end up installing a bunch of oddly named extensions. This way we can better identify it as we work on it. Next, open Properties/Manifest.addin.xml and change it to:

<?xml version="1.0" encoding="UTF-8"?>
<ExtensionModel>
     <Extension path="/MonoDevelop/Ide/FileTemplates">
         <FileTemplate id="FunPageTemplate" file="Templates/FunPage.xml" />
     </Extension>
 </ExtensionModel>

Next, create a Templates directory at the top of the project (not solution). We can now define the template configuration. In Templates/FunPage.xml we’ll explain the whole template:

<?xml version="1.0"?>
<Template>
     <!-- Template Header -->
     <TemplateConfiguration>
         <_Name>Fun Page with PageModel</_Name>
         <_Category>Fun Pages</_Category>
         <Icon>md-html-file-icon</Icon>
         <LanguageName>C#</LanguageName>
         <DefaultFilename>MyPage</DefaultFilename>
         <_Description>Creates a Fun Xaml Page and a paired PageModel.</_Description>
     </TemplateConfiguration>

     <!-- Template Content -->
     <TemplateFiles>
         <File name="${Name}.xaml"
               DefaultExtension=".xaml"
               AddStandardHeader="False"
               BuildAction="EmbeddedResource"
               CustomTool="MSBuild:UpdateDesignTimeXaml"
               SubType="Designer"
               src="./FunPage.xaml"/>
         <File name="${Name}.xaml.cs"
               DependsOn="${Name}.xaml"
               AddStandardHeader="True"
               src="./FunPage.xaml.cs"/>
         <File name="${Name}Model.cs"
               AddStandardHeader="True"
               src="./FunModel.cs"/>
     </TemplateFiles>
 </Template>

Note the use of the Name variable in the File definitions, as well as the attributes on the xaml file that explains the properties we’re used to seeing in Visual Studio. The src path is relative to this XML file, so inside of Templates/ we’ll create a FunPage.xaml , FunPage.xaml.cs , and FunPageModel.cs . To keep the example going, I’ll put in each of those files, respectively:

<?xml version="1.0" encoding="UTF-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"      xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="${Namespace}.${EscapedIdentifier}">
   <ContentPage.Content>
   </ContentPage.Content>
</ContentPage>

---

 using System;
 using System.Collections.Generic;

 using Xamarin.Forms;

 namespace ${Namespace}
 {
     public partial class ${EscapedIdentifier} : ContentPage
     {
         public ${EscapedIdentifier} ()
         {
             InitializeComponent();
         }
     }
 }

---

 using System;
 using System.Windows.Input;
 using System.Collections.Generic;
 using Async = System.Threading.Tasks;

 using Xamarin.Forms;

 namespace ${Namespace}
 {
     public class ${EscapedIdentifier}Model
     {
         public ICommand ViewContentCommand { get; }

         public ${EscapedIdentifier}Model() { }
     }
 }

At this point, you should be able to build with Release configuration. You can then find the mpack (the file you can install to Visual Studio to get your template) in bin/Release/net461/<your-addin-name>.mpack .

I don’t love relying on Visual Studio for building, since at some point I’d like to fully automate build and private distribution. To prep for that a little, I converted this to work better with msbuild and push to Github, so let’s go over that.

The project csproj didn’t work for me out of the box, so I deleted the CustomCommand section and added:

<Target Name="AfterBuilding" AfterTargets="Build">
  <Exec Command="'/Applications/Visual Studio.app/Contents/MacOS/vstool' setup pack <your-project>.dll" WorkingDirectory="$(TargetDir)" Condition="'$(Configuration)' == 'Release'" />
</Target>

Be sure to change <your-project>. This is the command that takes the dll from the build and generates the mpack necessary to make your poject work like an extension. Now to build the project we can just run:

msbuild /t:Restore
msbuild /p:Configuration=Release

Finally, I wanted to use our Github Project’s releases to share the mpack with the team, for now. If you have the [hub](https://github.com/github/hub) command, you can use this little script I created to “release” your built code to Github:

And that’s it for an extension that provides Multi-File Templates to Visual Studio for Mac. Now, adding more should be a piece of cake. Next, let’s chat about my wishlist for how some of these things improve to make things simpler for the next person.

Improving the State of the Art

Part of the reason I wanted to tell the story of how I found the information it would take to solve the problem, was that it felt like a lot — more than I would have expected. I haven’t been a full time IDE user in some time, but I expected one of the benefits to be simple sharing of templates within a solution to promote keeping things standard.

That being said, shoving the solution to that problem into extensions makes enough sense — adds the amount of power you might want, and it’s not that complicated once you know the “right” things. In the end it was just hard to track down the “correct” information for this problem— it seems like tribal knowledge at the moment.

Taking the extension critique a step further — extensions are traditionally installed and updated from the Extension gallery. The gallery allows you to specify new repositories. However, I haven’t found a way to easily create our own extension repository that can be somewhat private. And really, I don’t actually care to force them to be “private,” they’re just wildly specific to our project. In my specific case, I don’t even need a repository available on the internet. I just want a solution-wide set of templates (or extensions, I suppose) that you just “get” when you’re developing on that solution.

Finally, as I’m sure almost everyone would love, it’d be simply amazing if there was deeper overlap between the Mac and Windows Visual Studios. Code would be kind of neat as well, but that is a wholly different thing, as far as I’m aware. It might even be silly to suggest that they could overlap with the Code app.

I do want to finish by expressing how, at the core of all of this, the power and extensibility that exists today is almost unfathomable. That’s one of the reasons I was a little surprised I had trouble finding the necessary guides to get going — it feels like this should be a huge feature, given attention and deeper effort to promote the open community. As soon as I had the necessary pieces for my use-case, several open source ideas came to mind. I look forward to pursuing those ideas and trying to add to the improvements I mention above.

Cheers Microsoft and everyone involved that created the tools and libraries that made it possible at all.

Do you have Visual Studio for Mac Extensions you can share with us? I’d love to know what community or open source tools exist as examples that I simply didn’t come across.

Follow me on Twitter for more rantings or check out my website for more info.

Sierra broke my keyboard modifier keys and I refused to wait for a fix

Fri, 23 Sep 2016 17:41:08 GMT

I’m addicted to staying up to date on software. I seem to do this to myself because of a healthy mix of personal and professional curiosity with a sprinkle of masochism. The latest update to Apple’s Desktop Operating System — titled Sierra — dropped this week and its actually been pretty stable. For years I had issues with my code for days or weeks after a major update, but that seems to have improved in the last few updates. That’s not to say there are no issues though:

Plugged into a display, my computer won’t wake up without opening the laptop lid
Logitech mice are barely functioning
Keyboard key modifiers have stopped working

I’m a heavy keyboard user — I barely use a mouse at all — so that last bullet point is really tough for me to deal with. First let’s talk about what the keyboard modifiers are for. I work remotely so a lot of the time I’m working on my Macbook, using the builtin keyboard. However, sometimes I work at home with an Apple Display and an external Keyboard. I prefer a mechanical keyboard, which tend to have the more common Windows/Linux key layout. A Macbook keyboard looks something like this:

Whereas the more common layout looks more like this:

Note the that the Windows button (bottom left) acts as basically the same key as the Mac’s Command button. In Mac world, the Command button is heavily used, though. So the Alt (option) and Command (Windows key) are flipped between the two keyboards. This is a problem because my muscle memory has me used to the Command button being next to the space bar and the Option key being to the left of that.

So before Sierra, you would follow the instructions here and move on with your life. It was a supported configuration out-of-the-box from Apple. Well, that menu still exists but the functionality seems to have broken. So, the Engineer in me went looking for a couple rolls of duct tape, because I’m not about to change my workflow.

After some searching I came across Karabiner. This let’s you remap keys and do somewhat complicated things. It has a whole application and user interface. Rather than deal with a new user interface, I simply installed the little tool that remaps keys on the fly from here. With that I configured my key mapping in “~/.karabiner.d/configuration/karabiner.json”:

{
  “profiles”: [
    {
      “name”: “Keyboard”,
      “selected”: true,
      “simple_modifications”: {
        “caps_lock”: “escape”,
        "left_command": "left_option",
        "left_option": "left_command"
      }
    }
  ]
}

Sweet, 🍰 (Piece of cake). I returned to work as normal. Later in the day I moved to my front-porch to work and was immediately discombobulated as my Macbook keyboard was now messed up (reversed Option and Command). I could edit that config each time I switch keyboards, but that seems fairly tedious. With a little bit of research, I found a Github issue complaining about the same thing (thanks again, Internet) which referenced a tool called Hammerspoon. Hammerspoon allows you to plug-in to certain OS events like USB device changes. This’ll work great. After installing Hammerspoon, I needed another keyboard configuration as well as a simple way to swap them:

// new karabiner config
{
  "profiles": [
    {
      "name": "Macbook Keyboard",
      "selected": false,
      "simple_modifications": {
        "caps_lock": "escape"
      }
    },
    {
      "name": "External Keyboard",
      "selected": true,
      "simple_modifications": {
        "caps_lock": "escape",
        "left_command": "left_option",
        "left_option": "left_command"
      }
    }
  ]
}

-- ~/.hammerspoon/init.lua
local usbWatcher = nil
local home = os.getenv("HOME")

function usbDeviceCallback(data)
  if (data["productName"] == "QuickFire Rapid keyboard") then
    if (data["eventType"] == "added") then
      hs.execute(home .. '/.hammerspoon/karabiner-switcher 1')
    elseif (data["eventType"] == "removed") then
      hs.execute(home .. '/.hammerspoon/karabiner-switcher 0')
    end
  end
end

usbWatcher = hs.usb.watcher.new(usbDeviceCallback)
usbWatcher:start()
```![](./asset-5.png)

Look at that little Lua function that checks the keyboard being plugged in. You’ll need to make sure that “productName” matches _your_ keyboard. I got the product name by plugging in my keyboard, going to System Preferences > Keyboard > Modifier Keys and check what your keyboard name is in that keyboard dropdown. Note that “~jonphenow/.hammerspoon/karabiner-switcher” is just a little script I wrote to switch the Karabiner config around. This hasn’t been written yet, so let’s do that:

#!/usr/bin/env ruby

require ‘json’

select = ARGV[0].to_i

filename = ”#{ENV[“HOME”]}/.karabiner.d/configuration/karabiner.json” file = File.open(filename) data = JSON.parse(file.read) file.close

data[“profiles”][0][“selected”] = select == 0 data[“profiles”][1][“selected”] = select == 1

json = JSON.generate(data)

file = File.new(filename, “w”) file.write(json) file.close


Then you’ll need “chmod +x” that file so it can be executed. I’m partial to Ruby to so I whipped that up quick, but this would be just as easy to write in another language. Basically all it does is take an index of an array and flip a boolean on the configuration. Now, select the Hammerspoon menu item and “Reload Config” and you should be able to switch between keyboards at will.

With a little bit of tinkering I’m back to my normal workflow with keyboards, now if someone would write a Logitech mouse driver real quick, that’d be 👌 by me.

---

If you enjoyed this, hit the little ❤️ and let me know [@jphenow](https://twitter.com/jphenow).


export const _frontmatter = {"title":"Sierra broke my keyboard modifier keys and I refused to wait for a fix","description":"I’m addicted to staying up to date on software. I seem to do this to myself because of a healthy mix of personal and professional curiosity with a sprinkle of masochism. The latest update to Apple’s…","date":"2016-09-23T17:41:08.046Z","categories":["Keyboard","Tech","Technology","Mac","Apple"],"published":true,"canonical_link":"https://medium.com/@jphenow/sierra-broke-my-keyboard-modifier-keys-and-i-refused-to-wait-for-a-fix-46a548ace044","redirect_from":["/sierra-broke-my-keyboard-modifier-keys-and-i-refused-to-wait-for-a-fix-46a548ace044"]}

Get your head out of your ass

Tue, 02 Aug 2016 02:24:33 GMT

Hold up. You’re still using MySQL? That’s hilarious. Droll even. Let me explain all the reasons you should no longer be using MySQL.

Everyone is using other databases like Postgres, Cassandra, Mongo, Redis, the list goes on.

If you want to attract talent, you should be using more exciting technology. Exciting technology brings the talent that can work with it and create scalable systems.

Third parties like Heroku are making it hilariously easy to use these newer, hotter databases.

These other databases obviously outperform MySQL in features, recent market share and sometimes performance.

I know a lot of people that have been successful with things that aren’t MySQL, so you should check them out and dismiss every fact, practice and battle-tested knowledge you have on the technology.

Based on everything I know about software I can definitely make blanket statements about technology and how it applies to your situation. Having seen a few product life-cycles I can say, definitely, that there are global truths with the trade.

/endsatire

Absolutes are for the Dark Side

People make jabs at the technology or patterns used for projects all the time. Some of it is constructive, some of it isn’t. People who don’t have a stake in the actual project or an understanding of its context provide as much utility as a bloated, orange butternut squash.

Saying something like “wow, why wouldn’t you be using (AWS) Lambda for that,” shows that they have no understanding or respect for the history of the decisions that led to the current state. It also disrespects the fact that not everyone reads Hacker News every morning and evening obsessing over the hottest tech that will be under-supported and disappear in a year. Similarly not everyone has the same background or understanding of “what’s available.”

So talking more constructively is somewhat straightforward. Put half a thought towards how one might receive a condescending remark about the choices made and consider rewording your assertion.

More important than projecting your thoughts onto someone else’s situation, though, consider that perhaps they’ve solved the situation better than you can in a tweet, because of the having-context-and-already-did-it thing. Or perhaps this technology has been around for a few years and they’re using the tools available to them. If that’s the case, some projects reach point where swapping technology or patterns just because its what the kids are doing, would in fact be counter-productive in terms of the business making money.

We Software Engineers have a knack for forgetting about the balance between producing things that return dollars and bickering about the current technology we’d like to work with. As a born and bred Software nerd I can say that I fall victim this all too often, but let’s not forget why we’re here.

Don’t get me wrong I love the new things out of the Tech world to play with and potentially use on my projects: React, Schemaless, Lambda, we’re living in an interesting time and they’re all terribly interesting. I wouldn’t be a Software Engineer if I weren’t the least bit curious to try them and catch some news as things evolve over the years.

No, I love the technology. Perhaps, though, sometimes myself, Tech people, Software people and the like have to remember that a new product out of Amazon, Facebook or Uber doesn’t warrant the distaste of battle-tested systems that already solve our problems for the product that already exists and can (or does) make us money.

Thanks for making it through my mini-rant. Please follow me on Twitter!

Feeling Safe Across Data Centers

Wed, 29 Jun 2016 15:15:32 GMT

The Single Server Room

In a perfect world all of your servers are hard-wired to each other in a room. There would be one opening with which the world connects to your little slice of the Internet. That way all of your cross-service communication into databases, infrastructure and other services happens within the single set of servers all directly connected.

In the modern world we often have to reach across the Internet to access services and applications. This can be an awkward feeling and presents some unique problems. However, there are a few techniques and patterns you can use to make it a little less frightening. Let’s talk through some of the bigger concerns and what you can do about them.

Security

One big reason reaching across data centers, even for first-party systems, can be an issue is the matter of security. There’s a base level of security you lose sending data and commands across the Internet where anyone can glance at your requests and try to decode the data or alter what’s being sent. All someone needs is a basic understanding of networking, attack techniques like Man-in-the-middle and perhaps Wireshark to unpack your cross-service request, see sensitive data, tinker with the request and send an altered request to the final destination. Fear not, however, there are some standard techniques to mitigate this risk:

1. SSL

Always communicate over SSL when you’re sending requests back and forth over your systems. This is a straightforward, standard way to secure communications between two services or entities on the Web. Under the hood, SSL uses Public/Private Key encryption to secure the body of a request between two entities. Reddit, Facebook and all of your financial institutions use SSL (HTTPS) to communicate with your browser, and likely when they communicate between internal services. Its become far easier and cheaper (free) to get SSL for your services as well thanks to organizations like Let’s Encrypt.

2. Request Signing

While communication over SSL is somewhat secure, it can fail. Or perhaps you don’t need SSL to prevent snooping, but you do want to ensure the data wasn’t tampered with. At Highrise we decided to utilize a drafted standard that is being worked on currently under IETF, which outlines a method for signing a request. This means you can use an encryption algorithm and set of keys that you configure to define a formal verification for the content of your request. Let’s say I want to ensure that the Digest, Authentication and Date headers were specifically never altered. By following this protocol I would: Set up the request, retrieve the signature (using signing keys) for the specified headers, add the signature to the request and execute the request. This standard allows for specifying what keys you used to sign the request (via a KeyId parameter), which headers were signed, and which algorithm was used to do the signing. The recipient server can use this information to verify the contents of those headers were not altered during transport. The details of this freshly forming protocol go a fair bit deeper and are worth understanding. There will be a followup post directed at this topic shortly.

These two protocols give us a stronger confidence in the things being sent over the wire to other services.

Reliability

Speed of accessing external services due to network fluctuations as well as actual downtime are facts of a cross-data-center world. Obviously, both types of issues can compound themselves and start making whole services virtually unusable. You often won’t be able to stop these things from happening so you have to prepare for them. Let’s talk about four mitigation techniques:

1. Local caches, Avoid making requests

Caching or intelligently deciding when to request across services can cut down on the number of actual requests you need to make. Things like eTags can help with this as well as expiration headers or simply not requesting data unless you absolutely need it to accomplish your task. If the thing didn’t change from the last time it was requested let the client reuse the data it already has.

2. Timeout Retry

I mentioned earlier that slow responses from external services can create a compounding problem for your system. You can mitigate this risk by planning for it to happen and wrapping specific patterns around your communication. Specifically, set reasonable timeouts when you make external requests. One problem with timeouts is that you can’t tell if it ever reached the server. So you should plan to make your endpoint idempotent whenever possible. Idempotent endpoints make retries simpler as well, since you can just keep hitting the endpoint and expect no unexpected change. Finally, you maybe should slow down rescheduling the request to give some time for a system to recover or avoid hammering the service. This is called exponential back-off.

At Highrise, certain important requests have a timeout like 1 second. If the request fails it will be retried 3 times before it stops trying and starts messaging our team about issues. Each time it will schedule the job to retry further out: 3 seconds after failure, 9 seconds after failure and 27 seconds after failure, because of the exponential back-off algorithm. In cases where something is, for instance, sending an email via an external request, idempotency is a very serious concern so that you avoid sending the exact same email 3 times because of retries. You can accomplish something like that with a key that the server uses to decide if that operation has already been accomplished.

3. Circuit Breakers

Circuit Breakers paired with timeouts can help you both better handle full-service degradation and provide a window for recovery. A Circuit Breaker basically lets you define a set of rules that says when a breaker should “trip.” When a breaker trips you skip over an operation and instead respond with “try again later please,” re-queue a job or use some other retry mechanism. In practice at Highrise, we wrap requests to an external service in a circuit breaker. If the breaker trips due to too many request timeouts, we display a message to any users trying to access functionality that would use that service, and put jobs on hold that use that service. Jobs that were in-flight will presumably fail and be retried as usual. A tripped breaker stays tripped for several minutes (a configured value) and thus keeps us from hammering a service that may be struggling to keep up. This gives Operations some breathing room to add servers, fix a bug or simply allow network latency to recover a little.

4. Upcheck

Upchecks, Health-Checks and the like are very useful to get a basic understanding of whether you can reach a service. Libraries standardize some of this for you so you don’t have to think much about what to provide. Really what you want is to understand whether you can reach the service and if its basic functions are operational. Upchecks paired with a circuit breaker can help decide whether to show a maintenance page or to skip jobs that won’t work at the moment. These checks should be extremely fast. At Highrise for our first-party, external services we check once on each web-request for the livelihood of a feature about to be accessed. Again let’s say we have an external emailing service. If someone goes to the email feature we wouldn’t check at each email operation, in the code, that the service is up. Instead, we would check at the beginning of the web request if the email service is up. If it is up continue to the feature, if it isn’t display a basic “down, please try later” message.

Act like it isn’t yours

When it comes to external services, even if you wrote it, you have to act like you have no control of it. You can’t assume any external service will always operate normally. The reality is you have limited control, so you have to design a system that explains issues to your users as they happen and mostly recovers on its own. Protect what you can control and avoid requiring humans to repair issues like this. The more your computers can recover on their own, the more you can worry about the next feature, the next user or the next beer.

I’m a Software Engineer at Highrise (@highrise). Follow me on Twitter to tell me what you think, as well as find more ramblings about Software and the world by me @jphenow.

Balance Driven Development

Fri, 20 May 2016 13:58:50 GMT

I mentioned in my last post that I would talk about my opinions on TDD, so here it is. Kicking it off, I will explain what TDD is, how it’s meant to work. Then I’ll explain what some people have said about it and talk about what I believe the real benefits of TDD are. Finally, I’ll walk through whether I think it’s worth using and explain my use of the practice. Oh, and I’ll also provide a disclaimer as to what the heck possessed me to pile onto this already well-discussed topic.

TDD stands for “Test Driven Development.” At its core, it’s a development practice; a way to approach writing code. The rules of how to practice TDD are fairly simple at their surface. Say you have a new function that you need in order to accomplish a task: write the smallest test you can imagine, run the test, watch it respond with a failure, write the smallest possible amount of code to make that test pass, repeat until the necessary functionality is complete. With that process there are a number of benefits that people reference.

The main benefit I see TDD-promoters reference is test coverage. Since, with TDD, testing is part of how you write code, you just get more tests that are very well tied to the logic inside your functions. That test coverage paired with ongoing use of the practice tends to make new development less frightening because you have pretty high confidence that your code is covered and will alert you to unexpected behavior changes.

One counter-argument to the test coverage benefit is that the immense depth at which you’re covering your code in this type of practice results in brittle tests. Growing the test code at a rate faster than your app code can increasingly make it difficult to make changes to your app without spending many more hours rejiggering your tests. So, while you maybe have higher confidence in your app at one point, by the time you’ve redone much of your testing, due to feature additions, you’re in kind of a ¯\_(ツ)_/¯ state. So much so that by the time you’re done getting the tests green, you can’t tell if you’ve fixed the tests properly or if you just made them look green.

As Software Engineers we like to find processes and tools that allow us to remove blame and responsibility from the human. We want the computer and process to protect us and keep us in a safe zone. I think both of the above arguments are trying to achieve that same end of some kind of safe zone. TDD, in terms of the testing benefit that’s often referenced, would like to keep us in a zone of constant “yes it works.” The anti-TDD position explains a world where the process potentially slows down our ability to progress and potentially hurts our confidence in new functionality due to lots of changing tests.

One of the tricks with the name TDD is that it implies that tests are the benefit, when in fact they’re simply a vehicle for development. I actually liken tests from the TDD process to CO2 — they’re there to move things forward and useful for that but otherwise need to be cleaned up after their purpose has been served. That is to say that a lot of tests I write during a TDD exercise are meant to be deleted at the end. I tend to use those TDD tests to help write new tests that are intended to live on with the app for regression and documentation. They often even look very similar, but now I’m writing tests to lasts rather than tests drive development. These are fundamentally different mindsets.

I’ve mentioned that TDD is more of a vehicle for development. The effect TDD can have on the design of your code seems to be the most overlooked benefit of the practice while still the most important, in my mind. When I’m writing code without some sort of test I just add things and out comes the functionality. I’m worried about how easiest I can get the feature done. When I’m writing it from the perspective of a test I’m writing as if I’m a user of the code that I need. That means that my mentality for what needs to be written is altered. I’m basically defining the API that I can test and understand. This is much different than writing a bunch of things that technically work but then having to explain that API from the reverse — in order to write the tests.

With code/API-design and test coverage being the main arguments for or against TDD lets talk about what I do. I tend to think that when there are two big camps of people shouting for or against an idea the truth or the best path lies somewhere in the middle. I think some of what you can learn about your code for future testing and for understanding design is an enormous win. I don’t feel that my longer-term regression tests come from the practice, though. So after working with TDD for quite some time, I now lean on it as a tool in by toolbox. Generally, I remove those initial tests and move on with life. One thing I will give TDD is that the design mentality around understanding what your external API looks and feels like has ultimately changed how I write code, regardless of whether I’m actually living by the practice. Now, when I write code I tend to sketch up an API of what I’d expect to use, then I aim to fill that in. The same idea as TDD in terms of thinking from the other end, with less rigidity.

So what should you do? If you’ve never tried it, don’t just listen to me or to the others on the all-knowing Internet. Try it! I still think its a practice worth doing for a little while, if only to understand it yourself and develop your own opinion. Your opinion may be different than others’ and that’s ok. If it helps you make cool things or enables you or your company to make money, then that’s awesome; keep doing that.

I recognize that I’m beating a proverbial dead horse. Everyone and their mother has already written about their feelings on TDD, I even recycled a lot of those same arguments here. I decided to publish my own post on the topic because I feel like I’ve found a place somewhere in the middle of the argument. I think a lot of people tend to focus on picking sides and I wanted to explain that I think you can use it as a tool; a tool in your belt. It doesn’t have to be your whole world, but if you prefer that tool over another, great!

Also, in the last month, several people have asked about my feelings on the topic so I figured I’d compile my feelings in this format for reference.

Thanks for listening. I work for Highrise HQ building a better CRM. If you liked this, you might check out my Twitter for more silly opinions and feels on tech and society.

Failure as Progress

Wed, 18 May 2016 14:36:35 GMT

Failure has a negative connotation and reasonably so; it literally means that the thing you set out to do did not happen or happened incorrectly. Looking at each step and being distressed by failure is not only a drag, it’s unproductive. Altering your perception and response to failure can make life an entirely more enjoyable and fruitful endeavor.

SpaceX is a private Space Explorations and Technology company. Basically, they launch fancy rockets and eventually want to take us to Mars for colonization.

To make a Mars trek a reality, they have to bring the cost of a ticket down to the point where they can sell to non-millionaires. Rockets today are virtually disposable. They’re launched, debris falls to the ocean and that’s it. One big way to lower the cost of a trip could be to make rockets actually reusable. Reusable rockets are more akin to how we think of Airplanes now. Landing a large needle-shaped rocket isn’t that simple a task though. They have to correct for the speed, angle, wind conditions, everything. By my count, they’ve attempted 12 propulsive landings, 3 went famously, with others having varying levels of success. Many were considered successful simply for the fact that they were able to collect a ton of data and correct their systems for the next flight.

We are not expecting a successful attempt this time around but we are learning — John Federspiel (Lead Mechanical Design at Space X)

Space X didn’t set out to make a rocket landing possible, work for several years and output a rocket that can land upright out on the ocean. They worked for several years using what they know as a launchpad to new questions and experiments. They measured at every step and used those measurements to make decisions about the next mission. The key to the progress is to “commit to failing in a new way.”

In order to succeed, or fail enough to succeed, you first need to define it. One of the biggest mistakes I’ve seen is when a project has significant work done without understanding what the ultimate goal is. You’re simply chipping away at something, but you have no clue what. In order to fail at a thing or succeed and move on, you have to have a tangible goal post that you’re working towards with a definition of “it worked.”

A concrete example of this is writing; let’s say I’d like to write more. I’ve told people I’m trying to write more and initially I did. A month or two went by and someone asked, “how’s the writing going?” and I responded, “It’s going ok.” And that’s the end of it. What’s wrong with that? Well, aside from it not really going at all, I had no measurable concept of whether writing was going well. I had no baseline to measure against.

In an alternate universe, when I’ve decided to improve my writing, I write up that I’d like to output one post per week and publish somewhere at least once a month for the next 6 months. This time, when a friend asks how my writing has been going, I can loosely compare my actual writing to my goals and decide whether I’ve been failing at writing. If I have been failing I can adjust my expectations or better define my goals.

The time boxing of a goal is also important. If you have a supposed infinite amount of time to succeed or fail, then you never fail. You’re really just in a constant state of in-progress until you “succeed” which, aside from being unrealistic, doesn’t teach you anything because you don’t get to learn from any sort of failure.

In Software Engineering there’s a well known development technique called TDD — Test Driven Development. Rather than writing code and then testing it, you write a test and then write the code that makes that test pass. One reason people find it useful is that finding proof that your code works comes fairly naturally.

As an Engineer, TDD sounds a little backwards; maybe I don’t know exactly what I need to write so how should I know what test to write? TDD implies that if you’re writing code before you know what you need then you haven’t thought about your problem. This act of defining success for your code forces you through the motions of understanding what you need to learn from the code, what isn’t there now that I need to be there? TDD can instill a sense of constant failure. You write a test that will fail, watch it fail, make it not fail. It provides a quick understanding that a big red “F” isn’t a bad thing, now we know something, definitively, that we didn’t know before.

The problem with success-sans-failure is that you don’t know the range of possible failures, yet. I prefer to have failed at some point along the way because at least then you’ve picked up some more concrete understanding of the problem at hand. You might call SpaceX a Stellar example — do enough of what you know is feasible while trying to experiment with things that will fail initially. Learn from acceptable amounts of failures while succeeding enough to stay afloat.

When I was a Junior Software Engineer I feared some of the changes I was making. I feared them not working properly and I feared critiques, initially. I came to learn that all the critique, the failed tests, even errors in production were just a fact of progress. Remove the fear and jump in the deep end, learn. Its a lot more fun and you’ll find that you understand everything far better than if you had spent 10 times the amount of time trying to just “get it right.”

I’m a Software Engineer at Highrise. We build a Simple CRM. Check out my rants and recommendations on Twitter.

A couple footnotes for the curious. In regards to any research I did on SpaceX, most of the inspiration and some of my basic understanding comes from Wait But Why. Do check them out, but if you’re curious about the SpaceX article, specifically, check that out here. There’s also some great stuff in their latest (5/6/2016) launch stream video. My count of launches is listed in their well-groomed controlled-descent Wikipedia article. I have some feelings about TDD but I didn’t want to muddy the point of the article with those feelings. I will write more explicitly about TDD (because I feel left out) but if you are interested, some assessments of the practice are worth checking out by c2 (more of a collection) and some opposing viewpoints from David Heinemeier Hansson.

Technical Debt: A Game of Perspectives

Mon, 14 Dec 2015 23:04:55 GMT

Credit: unsplash.com

In software we like to use puns and metaphors — mostly to be cute, but sometimes it gets a point across. “Technical Debt” as a term, luckily for its creator Ward Cunningham, is both cute and useful.

A system has Technical Debt if it incurred faults along the road to completion. These faults may be shortcomings in the design, infrastructure, test coverage or stability. The shortcomings may result in a brittle system, slower future development, numerous bugs, performance issues, the list goes on. Both engineers and product managers want these things to be resolved; however, the two groups see things very differently. Those two perspectives can look like a black-and-white conflict, but it’s really more of a spectrum and a conversation.

Technical Debt has varying levels of importance. People have varying levels of interest or priority they would place on this Technical Debt due to their role or perspective on the issue. From an engineering perspective, we see less bugs, faster code on a reduced-Debt horizon. From a product perspective they might feel the time needed for Debt work reduces new feature releases and current bug work. Neither perspective is necessarily wrong. Since both parties have different directives, perspectives and priorities, a common language needs to be found in order to have a productive discussion on the topic Debt.

Flavors of Technical Debt

Technical Debt has emergency debt and reasonable debt. Think credit card debt versus a mortgage. Just like money Debt, Technical Debt is on a sliding scale of urgency. The placement on the scale is also a moving target depending on what’s currently being worked on or what will be worked on in the future. The placement on the scale is also skewed by your perspective within your team: technical lead, junior engineer, product manager, project manager, etc.

Let’s talk a bit about where the Debt comes from before we get in depth on perspectives and scales. Let’s say a project is distilled to the people working on the project, a timeline, and feature-set to be built. Whenever the combined result of people and time doesn’t equate to complete feature-set a few choices must be made: add more people, change the timeline or change the feature-set. The Mythical Man Month tells us adding people is a questionable decision depending on where in the project you’re at. Let’s say you manage to find a way to keep the timeline and the feature-set. Generally that brings in a fourth component to our project distillation: design integrity. If you lower the quality of the internals of your system, or leave out any future consideration, you may be able to hit this date with other given requirements. You will inevitably end up spending resources paying down this Debt, with interest, in the future.

The Parties that Care

Earlier, we talked about varying perspectives. In an organization you might see departmental roles like Engineering or Product. Personal perspectives will often come into play. Infinite things may play into each person’s understanding process. Let’s focus on the Engineering and Product relationship.

I’m an Engineer. Over the recent years I’ve been called a Junior Engineer, Senior Engineer, Tech Lead and part of Architecture teams. At each stage I saw things differently and so did the people around the table. I was able to use my past perspectives to mix up my thought process but I had a current role to play. As a Junior I was concerned about code style, how to get today’s bug done. As a Senior I was concerned about the quality of code coming in from the others around me, trying to set up design patterns for others to follow. I was constantly trying to invest time in bettering our code, making it more failsafe. As a Tech Lead I was explaining options we had as a team for how to build things, where the cost/benefit lay and helping the team implement those. Each role offered a new perspective, formed from a mix of what my role’s function was and what information I had at my disposal. The core decision process of an Engineer is seeking an efficient, stable and maintainable application.

I am not a Product Manager. However, Product Managers are often described as the CEO of their product. Their main goal is to, with the resources afforded to them, build a business around the product. They’re ultimately responsible for the business failure or success with regards to their product. Oftentimes engineers have a hard time getting the time they feel they need to get the Debt paid down on choices they made because of pressures from the Product department or above. Their goal is to build a successful business; not a science project, not a piece of art — the dollars in and the dollars out are what matter.

The vastly different interests of these two parties may seem tedious, but it’s very useful. You need the differing perspectives to push and pull the business in the correct direction at the correct time. Technical Debt is an example of this. Even a pragmatic engineer will occasionally obsess over the specific design of some framework or library. They’ll analyze style details, or maybe just over test their code. On the contrary, a product manager would rather see progress, features that can be added and posted on the marketing website. “When’s that next feature available? Is it shipped yet? Can I have it an hour ago?” they ask. Their role trains them to ask for the next thing or how quickly can that last bug be fixed. It can be hard to explain to a product manager that, if there are options, why the longer-route or why that bug really is worth the expense.

Paying it Down

In order to argue productively about whether or not Debt is worth spending time on, you need to be able to describe the benefits or downfalls in more measurable terms. That puts the entire discussion on a level playing ground for managers and even other engineers to discuss. I may want to fix a rat’s nest of code. If I then post in Slack that I’m going to spend some time on this, some might “get” it, but others might wonder why. I could argue “it’s crappy and hard to work with,” but what does that really say? Instead, approach the assertion that we need to spend time on this Debt with something more tangible: “We use this library for all of our permissions across this platform, it takes up 2 people’s time to explain how to use it, there’s a bug reported every 2 weeks and it has performance issues that fundamentally hinder our platform’s speed.” That’s a lot of things wrong with some imaginary system and suddenly everyone understands that we have a mini fire. We just said that if we invest some time and energy into a new solution or refactored solution we could move faster as a business. Developers could work faster, not be taken away for periodic bugs and the system could run faster.

Use your ability to describe the measurable benefits of investing in Technical Debt to decide if it’s worth investing in at all. Fixing an ugly area of the system because it feels gross is not worthy of your time. It’s not only silly, it’s irresponsible. As far as you know, that part of the system works right now. Your “prettier, better” version that doesn’t measurably change something for the business is fundamentally scary because it’s not in production, might not work and has potential to cost more than never touching it.

Checks & Balances

Everyone needs to think about the fact that other people have different perspectives and motives. It’s not bad that they do — in fact that’s intentional, it keeps you in check. It may force you to spend more time reasoning about an argument. That time may allow you to realize that it’s not worth bringing up or give you insight into others’ reactions. It’s a superpower of sorts. One day I’ll find a way to talk in the dirt about how an engineer can avoid or fix their project’s Technical Debt infection. I know it’s a topic lots of people want concrete answers to. There is no silver bullet that I’ve found, though. You can end up with Technical Debt by over-designing a system too. With some experience it comes down to a mix pragmatism/YAGNI and forethought/design patterns.

Other cool people write about Technical Debt too.

I am a Software Engineer at Highrise.

Find out more about me at http://jphenow.com.

Locking down with Duo

Mon, 23 Nov 2015 21:41:45 GMT

At Highrise we’ve been really busy improving our CRM product. Usually our focus is directly on additions or tweaks for our customers. Currently, though, we’re also working on streamlining internally — in this case the net effect being a better, swifter support experience. Before we can add heavier admin functionality for our back-office, we need to ensure that it’s very locked down, so one of the things we’ve added internally is 2-Factor Authentication.

To avoid reinventing the wheel we decided to use a service to fill in some of the gaps. We chose Duo, which removes most compatibility concerns since it’s a fairly flexible API that does the hard work for us. Duo has a suite of APIs available to make the addition of 2-Factor Authentication secure and simple. They even have Ruby libraries. Those libraries are just repositories, though, and not registered as gems. There’s also a Third-Party library that is a gem that covers only one aspect of their API (the Web Flow). These options mean: deal with the libraries as non-gems (copy, or manage in non-traditional fashion) or use a gem that covers only one API topic. We opted to build out a full solution into a single gem, test it and Open Source it.

Thus, I give you duo-api. Duo-API is a dependency-less gem that works on Ruby all the way back to REE/1.8.7 and all the way up to latest. It provides the ability to sign and verify requests for the Duo Web Flow as well as connect to any of their APIs.

With this addition and some of the code presented in our Example we can now build out some of the more complex and sensitive admin functionality with peace of mind.

Pull Requests welcome!

I build software for Highrise — a more delightful CRM. Check us out!

By the way if you haven’t read about our awesome Support staff, check out Chris Gallo’s Advice From The Future.

If you’re curious about more bite-sized commentary from me, I’m sometimes chatty on Twitter.

46 hours

Fri, 13 Nov 2015 05:58:01 GMT

365 days in a year. There’s 52 weeks somewhere in there. Each week with 7 days. Every day has 24 hours. In 1 week we have 168 hours to spend. 168 hours to work, to wrap up in each others arms, to better ourselves. It seems like so much time. All this time we have and I’m not getting everything I’d like out of it. I want to learn more, write more and strengthen some of my personal relationships, maybe make some new ones. All this time we have and I don’t know where it goes. If we could only find a little more. Sadly, for now, Time is a limited resource to us all. Let’s take a quick audit of where our precious resource is spent to understand what we have to actually working with.

On each day we, hopefully, sleep somewhere between 6 and 9 hours a day. I was always told to shoot for 8 hours, let’s roll with that. The average full-time employee in the US works 46.7 hours a week, let’s round up to 47 for a bad week. The average commute time is about 30 minutes in the US, so 1 hour for both directions, per day. Finally, let’s take out 2 hours per day for normal things like hygiene, eating breakfast/dinner and normal little tasks. That leaves us with 46 hours in a week to do whatever we want. 46 hours sounds lovely, that’s like an entire weekend!

He felt strangely good about having the more mundane things figured out. The rent and utilities were paid for, house supplies and the necessities like food and medicine were in a brown paper bag. Everything was finally in order. Time to let loose.

Feeling good about being so responsible with his initial spending, he jumps right into the good stuff. A couple beer orders, several clicks on Amazon and a few Playstation games later, our hero grows tired and decides to call it a day. He wakes up to find that he’s tight on cash somehow. The rest of the money had been spent.

Soon, he realizes he can’t run out and enjoy his time with friends. They want to spend money at bars or the next Bieber concert, yet he has no money with which to join them. They grow tired of lending him money when they know he doesn’t need it. They know he just spends it poorly. Many of his friends fall off and lose interest in him.

This continues for some time. Eventually he sees the pattern and decides to change. He becomes more careful with his spending over time. He begins approaching the decision process differently. He evolves.

Our hero now, when faced with decisions, thinks. If it’s absolutely necessary, just do it. If it’s not, think for a moment. “What is the product of my decision?” he thinks. He may be doing anything from climbing out of debt, to small things like spending a little on looking nicer, to not spending so much on the newest trinkets. The product of those things may be any number of things like financial stability or feeling less pressured to chase the latest thing. Just thinking for a moment changed everything.

46 hours to watch movies, play video games and get that side-project off the ground. Knuckle-Crack — let’s get to it. After a few movies and getting sucked into Netflix we’re down a few hours. On to some video games to get brain function back. Let’s grab some beers. Ok, several hours of Super Meat Boy and Destiny later, it’s feeling like other types of brain cells are gone. That’s ok, we still have something like, 20 hours. Well, slept too late after the beer and staring at the screen. We’re actually closer to 12 hours now. Let’s get started on that side-project work. This is feeling difficult after everything else, accidentally ended up sitting and staring for a bit. Now there’s about an hour or two for side-project stuff. Yikes. Where did the time go? Is there anything we can do about it?

People often talk about money in vague terms. Podcasts like Open Account are trying to change that by talking more explicitly about numbers and a decision process with people who have hit bad times and good times. I’d like people to start doing the same with their time. We should take a moment to think about how we spend our time. There’s no need to pick up a project management tool and start booking all of our precious free-time. No. We just need to take a moment to reflect on time spent and evaluate the next step.

I have a few things that I consider when I’m thinking about my free time. I’m working on becoming more well read in a few specific topics, while simultaneously hoping to write about those topics and perhaps someday make those topics part of a living. These things while trying to keep up relationships with family and my best friends, stay healthy and become more financially stable. Take a moment to understand what you care about and spend your time like you care about those things.

P.S. You should follow me on Twitter where I pretend like I can talk about Software, Science and other non-controversial topics.