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 unmaintained
wkhtmltopdf
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: