DEV Community: wildgeodude

Software Engineering Vlog | Working at Pinpoint

wildgeodude — Tue, 31 Aug 2021 08:45:58 +0000

I'm a full-stack engineer, working for a SaaS startup called Pinpoint!

In my spare time I enjoy videography - I read a book called Show Your Work and thought it'd be worth becoming a documentarian and sharing some of the things I do!

If you prefer reading > watching, I've also written about my experiences, day-to-day, at Pinpoint:

https://domsamphier.com/posts/software-engineer-day-in-the-life

Software Engineer Day in the Life @ Pinpoint (UK startup)

wildgeodude — Mon, 28 Jun 2021 07:01:04 +0000

Originally posted here

Whether we blame self-improvement, snoopiness, comparison, curiosity, entertainment, aspiration, or whatever, a lot of us can't help but peer earnestly into the lives of others. Be it a biography, a blog, a podcast or a vlog, we like storytelling, knowledge sharing and chronicling through personal experiences and anecdotes - the lure of candour and relatability entices audiences to find out more, straight from the horse's mouth.

Detailing the routine and minutiae of an average twenty four hours seems to be a generally popular way for ordinary folk to share the realities of their everyday encounters. So, does a day in the life of a software engineer really always tend to involve chic urban offices, sleek vertical monitors, and complementary canteen delectables?

Current Location? Jersey

No, this isn't Seaside Heights, nor can I see the Manhattan skyline from my garden. This is Jersey 1.0, a sunny spit of land located in the English Channel, renowned for its iconic golden cows, postcard perfect beaches, and of course its rather mysterious status as a leading international finance centre.

Company? Pinpoint

We're a SAAS company in the HR tech space. We deliver all-in-one talent acquisition software designed to make finding, engaging and hiring the right people simpler.

Office or Home? Both.

Over the course of the last year, working from home (WFH) as a topic has well and truly entered the public consciousness, en masse. I am pro-WFH pandemic notwithstanding, I think workers should absolutely be given this option, wherever possible. Many of us at Pinpoint have been WFH, or remote, long before the world was overwhelmed by the covid contagion - nobody minds where you're based, as long as the job gets done.

The Pinpoint office reflects our acknowledgement that everyone's preferences vary when it comes to working environments. As such, a great deal of thought has gone into workplace design here. However, there's also nothing quite like the comfort of your own home. I flick between the two quite regularly as I like the change of scenery.

Sum up a typical week day? Busy, inside work and out.

There's no sugarcoating it, this isn't an ordinary 9-5 job, and working here certainly won't be for everyone. This is a fast-paced high growth startup with steep expectations to push for the highest standards in every situation. Sometimes its overwhelming, as targets appear excessively optimistic, and you realise that everyone around you is a workaholic. However, we're all here, and we continue to attract incredible talent, because of the shared desire to do interesting work and build something we can be proud of.

06:45 alarm, 15 minutes to drag myself out of bed. This is undoubtedly the most difficult part of my day, I hate it. Read or watch some YouTube for a bit. I've decided I'm working from home today.

07:30 by now I've moved an entire 2 metres, and I'm sat at my desk. Typically I'll start by looking at open pull requests ready for review, or address changes requested on any of my own. If everything is however perfect - disclaimer: it won't be - move on to today's tasks.

09:30 morning standup with the rest of the engineering team. For the uninitiated, the purpose of this everyday meeting is basically to allow developers to communicate their daily commitments and identify any issues. We're all usually working on the same codebase, so it's helpful to co-ordinate our efforts such that we don't end up treading on one another's toes. It's also generally just a good opportunity to collaborate and/or chat with the entire team.

10:00 - 13:00 prime uninterrupted work time - there really isn't much more to it than that. Without delving into the specifics, this involves coding new features, addressing bugs, testing & documenting code, and of course trawling through Stack Overflow trying to figure out why Uncaught TypeError: undefined is not a function.

13:00ish time to get out and exercise. Cardio doesn't just reduce the risk of lifestyle diseases, apparently it's also supposed to improve brain function and memory. Be that as it may, I've just got to get some fresh air after staring at a screen for ~5 hours.

14:30 - 18:00 take some food back to my desk and get back to it. Poor sleep hygiene and that damn circadian rhythm absolutely will affect my afternoon productivity - burning the midnight oil has its pros and cons. More of the same work for the next few hours.

18:00ish depends on the day & weather, but usually head to the gym for an hour before meeting some others to go and do something from the following array: activities = ['paddleboarding', 'surfing', 'fishing', 'swimming'] Terrible programming humour aside, Jersey's coastline is difficult to beat.

22:00ish i'm back home and fed. I tend to spend the remainder of the evening addressing any loose ends from work that day. Or, I might just fall asleep reading or watching Netflix, because I'm a human being. Usually lights out by midnight.

No day is ever actually the same, and circumstances change, but this probably as predictable as an average twenty four hours in my working week gets right now. The workload is large, however the active lifestyle I crave isn't compromised - I wouldn't stay here otherwise. Some days are just more challenging, occasionally the evenings are much later, and sometimes the job eats into your weekend. Welcome to life at a startup.

Application config in a single-row table

wildgeodude — Wed, 14 Apr 2021 07:11:08 +0000

Originally posted here

Here’s the scenario: I am building a fairly straightforward web application that grabs some data from an external API and displays it various ways on a dashboard. Essential to the process of making this particular data retrieval possible is the existence of an api key. This single key unlocks the API and all of its captivating curiosities for my app.

Other than actually accessing this data, one of my additional requirements was the ability to conveniently change the API key whenever I wanted, without having to dive into the application’s codebase. How can I do this?

I’m using Ruby on Rails, but this should prove to be fairly inconsequential. Sure, there are ways to handily and safely store application-wide configuration (like API keys) in Rails specifically, such as slotting them directly into the codebase like this:

# config/environments/production.rb
config.mailchimp_api_key = “ABCDEF”

Or I could use encrypted Rails secrets, and store something like an api key in the config/secrets.yml file, which could then be accessed like this:

Rails.application.credentials.dig(:facebook, :api_key)

The problem with both of these solutions is that they are not dynamic - if I want to update the key I’ve got to manually go into the codebase to change it, test it, then re-deploy the app. It’s just a bit of a faff, and I wanted to eliminate the dependence on somebody with access to, and knowledge of, the app’s codebase.

So, I decided to store the key in a database table - truly groundbreaking stuff. Let’s dig into why this simple solution works really well, and how you can go about implementing it.

I’ve gone with the Single Row Table (SRT). It’s relatively self-explanatory: it’s a table with a single row in it. In my case, this table is called app_settings, and its columns store an assortment of application-wide configuration, including my all-important API key. I can now perform ordinary read/write operations as I would with any other table. However, the difference here being that there’s only ever one row (or record) in the table itself. It might look like this:

id	encrypted_api_key	encrypted_api_key_iv	...
1	asD2-f21Fa-126d-a	$bRs23Gjg82dsGDsF	...

Carrying this out in Rails is very straightforward - I can’t see how it could be much more complicated in any other web framework:

Using the attr_encrypted gem I followed the documentation’s short instructions to create a model called AppSetting (with a corresponding migration to create the app_settings table), along with an encrypted attribute/column for my API key.
To ensure I only ever create and use a single record on this table, I needed an interface that only performs queries on this particular row. I added this class method to the AppSetting model, which calls Active Record's handy 'first_or_create' method:

def self.current
   first_or_create
end

From this point onwards, any time I use the AppSetting model, I do so in conjunction with the current class method, e.g Services::Api::Request.call(api_key: AppSetting.current.api_key). Importantly, I now have the means to easily update the api key through the app’s user interface using any old form.

There’s every chance you’re reading this trying to determine whether or not a single-row table just sounds a bit strange. I also sat there similarly deliberating and searching for what I hoped might be a “cleaner” way of doing it. I came across one other popular and viable solution: the Entity-Attribute-Value (EAV) table (also sometimes described as the Name-Value-Pair table).

EAV works very simply by defining a row per configuration value: you would create a table with a column for a setting name and a column for a setting value. In the context of my requirements, the table might look like this:

config_option	value
encrypted_api_key	asD2-f21Fa-126d-a
encrypted_api_key_iv	h4fhSDFDFasQ2

EAV’s appeal is obvious: you access a table in which each of your config options has its own row in the format of the familiar-looking key value pair. My decision to roll a Single Row Table however was very simply based on the fact that the general sentiment on developer forums seemed to favour SRT over EAV. I seized the opportunity to dip into the analog tool-belt and jot down a pro’s/con’s list. I’ve shared this below to help you pick or plan your response to the rare-sighted “editable application-wide config” conundrum.

Single Row Table Pro’s

Put plainly, it’s just easy. It’s quick to implement, it feels familiar and it just works.
Each config value is stored in its correct data type - i.e the encrypted_api_key column is a string, and refresh_seconds is an integer.
If your requirements change such that your app-wide config need now apply to individual entities instead (for instance a User or a Company), it’s very simple to add a foreign key to your app_settings table, and you’re sorted. Moreover, it’s simply nowhere near as straightforward to do this if you’re using an Entity-Attribute-Value table.

Single Row Table Con’s

Additional config options require database schema changes. I’ll need a new column if I want to add a Twitter api key for example.
The table can become very wide if there are lots of config options.
Not very easy to keep track of exactly when config values are added/updated on this row.

Entity-Attribute-Value Pro’s

It’s also quite straightforward to implement and use.
Adding a new config does not require a database schema change, they’re just rows.
The table schema is very narrow.
Easy to track when you add/update a config option if you add created_at & updated_at columns to your table.

Entity-Attribute-Value Con’s

Everything is “stringly typed”: your value column might therefore potentially contain config with a multitude of inherent data types (JSON, string, integer, decimal) but all have to be stored as a string (the column’s field type).
Even if you decide to solve the above by adding multiple type columns to store your various config options under their correct data type, you’re widening the table and will be left with lots of empty or NULL values on your records, like this:

config_option	string_value	int_value
encrypted_api_key	asD2-f21Fa-126d-a	NULL
refresh_seconds	NULL	20

This is bad because it forces you to deal with your data pessimistically in your codebase - i.e as though a given value for a record potentially doesn’t exist.

In reality, this problem likely won’t surface very often for you. That said, it’s certainly a talking point for anyone looking to add in some editable application-wide configuration for their app(s). The take away and TL;DR here is that SRT and EAV are seemingly the most popular solutions.

Ways to become a software developer (YT)

wildgeodude — Fri, 02 Apr 2021 23:56:27 +0000

Here I talk about what I think are the three primary ways to become a software engineer:

https://www.youtube.com/watch?v=vW0drdiKY9o&t=14s

My Developer Origin Story

wildgeodude — Tue, 23 Mar 2021 10:27:31 +0000

I really do like the phrase “developer origin story”. For starters, the shades of Marvel simply cannot be ignored (superpowers pending). Secondly though, it’s fun to speculate whether or not people in other occupations similarly recount how they started out - know of any stimulating “toll booth operator origin stories”? There seem to be a few common routes into professional software development, and I don’t suspect I will break the mould with my narrative.

I do not have a STEM background, and I certainly never considered becoming a programmer when I was growing up. I got a degree in history, and in England, this means you can actually still expect reasonably good job prospects, as long as your university is a member of the Russell Group, of course. So with that in mind, either I (over) paid a coding bootcamp to swiftly remodel me into the superstar engineer that my city both needed and deserved, or I must be one these self-taught developers.

Given I used to see no point in spending money unless it was for skiing or for sustenance, and couple that with my shortage of enthusiasm for even more schooling, I basically realised that my best option was to embrace my inner autodidact by picking up a book and opening up an internet browser. To be honest, I think that most programmers will, in some way, shape or form, allude to a similar awareness for their own progression. Self-discipline is pretty much the bare minimum required to become a proficient developer. Applying oneself and being resourceful isn’t just a route into software development, it’s a mantra for success in the field, lasting an entire career.

Towards the end of 2018 an opportunity presented itself for me to start writing software professionally. As it was put to me, not unreasonably: there was a provisional job offer if I was able to teach myself web development fundamentals and practicably demonstrate my understanding, within three months. Simple. So, I got to work and did just that. Up until this point, I had explored elementary programming in python - I remember reading Automate the Boring Stuff and Python Crash Course. So I had to essentially forget all of that, pick up some ruby, and get started on unlocking the secrets of the rails framework. I was encouraged to begin with Michael Hartl’s popular tutorial (which at the time was free), but beyond that I was really left to my own devices.

So what did I actually do for three months? I started an inexpensive Team Treehouse course on the basics of the ruby language. Having already partially covered beginner programming in python, I didn’t spend too long on this - I don’t even think I finished the course, I just wanted to get started on actual web development with rails. This is where things got more challenging.

I followed the Hartl tutorial once through, and I remember finding it quite overwhelming - there was lots to it and I often wasn’t satisfied just accepting many of the abstractions and particularities that constituted the “magic” of the rails framework. For instance, I initially took umbrage at the wonderfully simple-looking Action View Form Helper, largely because I just didn’t know what was going on under the hood. Note I have since come to terms with why this Helper is, well, helpful. At the time though I was frustrated because I wanted to know exactly how and why it worked, and as a novice I didn’t really know where to begin trying to unpack it.

After spending a few weeks fiddling around with rails, reading blog posts, watching youtube tutorials, and generally just not really understanding how most of the framework worked, I stumbled upon Launch School, specifically their free e-book Demystifying Rails. This was the “Aha” moment for me - that book made everything click. Launch School describe themselves as the “slow path for studious learners”, with a focus on demonstrating how abstractions work from the bottom up. I found this teaching style incredibly useful, and it enabled me to piece together exactly how rails worked, sans magic.

It’s one thing learning about web development, but I still had to prove my mettle. My prospective employers asked me to design and build a rudimentary web app. I’d be lying if I said I’m gutted I cannot find any trace of this project. I remember a few of its trademark selling points. Instead of using the Devise library like everybody else, I thought it would be much better to run with my own authentication system - this shows initiative you see. There was a Post model because of course there was, and it might have been mobile responsive. In short, it was woefully bad. It helped me secure that job though.

Becoming a software developer is an achievement I am proud of. Two years ago I had no professional programming experience. These days the code I write is consumed by end users all over the world. If there’s a message here, it’s that dedication and no small amount of patience is necessary to break into software. If you possess both of these and are able to apply yourself, you will make it.

Originally posted at https://domsamphier.com/posts/developer-origin-story