Jump to list of specific experience.
I’m a CarletonU 2010-2016 software engineering graduate. I’ve been studying or working since 2009, using Python and Linux since 2010, and using PostgreSQL/Flask/Git/etc. since 2015.
I started programming in 2008 during my TIK20 course with teacher Pierre Nault, in OOTuring, an object-oriented Pascal derivative designed and implemented at QueensU way back and reasonably widely used in CS courses in Ontario back when ON had grade 13, though we only used it imperatively and without user-defined functions. My first real program was an okayish Pong clone with far too much duplicated code. It worked though. It was fun for a bit.
In 2010, when I entered software engineering at Carleton, I decided
lugging around a heavy 4400 CAD MacBook¹ on campus and late at night
wasn’t the best of ideas, so I got a EEE 1015 PEM and learned Linux the
hard way, and installed Arch on it, pre-systemd². I then thought
it’d be a great idea to buy another one, plug
kids-these-days-haven’t-heard-of-it-jfs
on a RAID 6 of 8
consumer-grade drives into it over only two USB ports on the same
controller and run a server off it. The rest is history:
Learnt Vim the hard way… in the middle of assignments. No Cream. Just getting the point and practice… starting in the middle of the longest SYSC 1005 assignment.
Parachuted into a student-run computer lab, cleaned out old hardware, replaced failed hardware, and eventually just burned out trying to clean up the spam and legacy, or then QEMU/KVM bugs, all while managing a school workload.
TODO: dwm, openbox
¹: Which I still have by the way! Take that macOS! The hardware far outlived the software. It still runs Snow Leopard (10.6), not ≥ 10.7 where they removed Rosetta and my PowerPC only games stopped working.
²: But not SysV-style init scripts. Take that SysV Debian fanbois. Also, people shouldn’t write boilerplate init scripts but sysadmins AND programmers definitely should be writing service configuration, so stop talking about SysV but rather s6 and this was obvious ages ago.
Specific Linux experience
- Yes, I compile my own kernels. It’s no big deal. It’s less trivial
to go over all of
make nconfig
and figure out what is applicable to you, or the context of what isn’t out of curiosity.
Specific Python experience
- Code reviews for everybody, repackaging and slightly tidying research ML code for production, etc. Also, finding your typical OWASP Top 10 bugs, even if it’s less XKCD-worthy CWE-23 path traversal or CWE-78 OS command injection, or generally polluting S3 keys when you had prefix-based IAM rules on them.
- BeautifulSoup back when it was much cooler and there was less HTML 5 and BS so permissive parsing BeautifulSoup mattered.
- Flask
- SQLAlchemy
- FastAPI
- Pandas, Matplotlib
- More than half of stdlib, at least once, including the bits you might not have known about because typicals don’t read the stdlib docs front to back when they’re bored.
Specific Cloud experience
I was an AWS Certified Solutions Architect (SAA-C01) in 2019, and in general was responsible for our AWS usage.
- Had my AWS Certified Solutions Architect (SAA-C01) in 2019.
- CloudFormation, IAM, RDS, ElastiCache, S3, Lambda, etc. experience.
- Ran primarily DBs and ML inference APIs.
Comments on the experience
- We’ve mostly moved off it.
- I still prefer AWS for ABAC IAM rules over GCP, or its better PostgreSQL and Redis (as of this writing, with Redis 6 and its native TLS termination and ACLs, or just out of the box sharding and replication with failover).
- I still prefer the AWS CLI, CLI docs, plus its inclusion in many standard Linux repos.
I’ve built medium-small Rails and Express.JS apps, MVPs, internal APIs in Python, etc. on Heroku.
- Native language buildpacks or container stack experience. Much of the other features. There’s not that much to cover in the non-enterprise tier.
Comments on the experience
Buildpacks were great, until we had to accomodate macOS users who aren’t UNIX and shell script understand-ers and their then mediocre package management (still mediocre), sometimes broken toolchains, get
rbenv
or random and then unmaintainedwkhtmltopdf
builds.In general, dev envs should be reproducible… for the sake of poor Linux users who have to then debug macOS’ troubles.
Nice. Out of the box implementation of concepts like release phases (nice for DB “migrations”—a hateful term), review apps, development→staging→production pipelines with almost NO code, unlike elsewhere for much more or far later to the game (e.g., GKE
appctl
), and much more.When I see Heroku, or what it was in the last few years of 2020, I am reminded of the vision of GitLab vs GitHub, of not just repos and perhaps issues and Jekyll wikis, but recommended and standardized CI/CD, *a template employee handbook, auto Kubernetes deployments and review apps, not just Python dependency scanning but more, DAST, etc.
Downsides:
- Tiered pricing structure, unlike AWS and GCP where most of what you care about (except some extended security things) is immediately available.
- The DB offerrings either are just right for your size… or you’ll outdo them on AWS or GCP.
- The builder has quirks (e.g., exec bits lost on git clone).
- The builder doesn’t auto-cache your layers (8 minute rebuilds instead of 3-4).
- Env vars only, no proper secrets.
- Release phases can’t run with different env vars, so you can run your migrations with a higher PG role, but use a lower privilege one at runtime. Why should the app normally run under a user that can Bobby Tables, or in general?
- Logs are primitive (text only, no JSON parsing, no metrics from logs), and no retention.
- No custom alarms, metrics. Pretty much nothing that a modern fancier shoppe would have running on a real Kubernetes.
- Managing credentials at all via env vars, rather than tamper-resistant injected credentials such as AWS EC2 Instance Profiles or GKE Workload Identity.
Some of these may not apply to Heroku enterprise, but it’s not like there’s much to see there publicly.
I’m one of the responsibles for GCP at my employer, and in general am the one reviewing security or taking some minor or not org-wide aspect and improving it.
- Compute Engine, AppEngine, GKE, plus the basic boring things like IAM, Cloud Storage, etc.
Comments on the experience
- Much nicer Kubernetes offering; I’m done with EKS.
- Overall better app dev platform than AWS unless you tweak more than you ought, and I really mean that.
- Doesn’t have the entire collection of eclectic AWS offerings, from Snowball to Snowmobile, Outposts, Ground Station, and more.
- I also wish that there wasn’t Anthos for expensive servers where 18 USD is a drop in the bucket, but also Anthos for IoT + K8S DaemonSets + device firmware updates with recovery strategies + device configuration (e.g., site-specific WPA creds) updates with recovery; rolling out application updates to the fleet isn’t the same problem as updating the image. No, I’m not considering Kubernetes for MDM—mobile device management.
- A featureful and usable logging and graphing dashboard.
- OpenTelemetry practically free
- Better roles out of the box because they can be folder or project-scoped, though I still think parametric or tag-based (à la ABAC) roles would occasionally be nice.
- Snapshot debugger and out of the box profiler, for all of GKE, AppEngine, and Cloud Run.
- The CLI still doesn’t do 2FA itself or secure
session/refresh token storage. The AWS CLI could use TOTP on
sts assume-role
, or--profile
for years. - Redis 5.x as of this writing, not 6.x
- No SES equivalent, a proper no-mailbox service account mail sender tied to GCP IAM, not the specific user oriented GMail API with OAuth2 as the user rather than an NPE, and not the limited Google Workspace SMTP relay.
Node, Ruby, POSIX Shell, and everything else
- TODO: lots of POSIX sh.
- I can’t use
sed
’s Turing completeness, sorry. - I’ve used just enough Haskell to appreciate monads
for require error-handling in-type-system, proper enums (i.e.,
data
), parametric and typed (!!) regular expressions, strong typing with type inference, correct by construction types and interfaces, and somewhat programmable type systems (or at least the idea thereof, and expressing nontrivial constraints). - Some Pl/PgSQL, but definitely good coverage of just non-procedural SQL in PostgreSQL.
- Yes, I can nontrivial AWK, and once in a while do so.
- I did Perl, briefly. Not again, thanks.
- I did COBOL for 2 days to help my neighbour. The worst of everything in language design. Buy the Springer/Apress book if you want to learn it, not your prof’s slides.
- I did Ruby on Rails for 3 years, and no pure Ruby.
- I’m rusty, but can definitely still do it again. I will miss Python comprehensions, function/method references, generally better online or CLI docs, first class docstrings, and a few more aspects.
- Much to be learned in DSL design and all the other shorthands that Ruby land is so fond of.
- Oh, and Monokai/Molokai looks better in Ruby than in Python in Vim.
- I did Java yeaaars ago in school. I can still
review your Android app, build it with
gradle
, do laborious human code linting, and generally comment on class design or why you used low level encryption primitives rather than less error-prone like libsodium, or why not just use a proper device-integrated (i.e., hardware crypto using keychain, stock UI components or workflows) framework.- Monokai looks decent here too.
Other systems
Experienced macOS end-user, but anybody should be able to figure that out. This is software engineering, you’re expected to! Same with the macOS 7 (or was it 8?) that I started on as a child. I’m long out of touch with the new APIs or the general development landscape, but I’m sure I could figure it out. Just expect me to daily bemoan the lack of a dynamic window manager.
I don’t use Windows if at all possible. I can only not waste too much time for basic tasks when using it, am too late to the game to be good at it in my programmer/engineer career, and am uninterested in getting good at the platform with which I have serious issues.
The buzzword list
Only list all the tech and tools you use for entertainment: