It’s been a pretty momentous few months for me at Reonomy. Like I mentioned in my 2015 in Review post, it’s been the most professionally fulfilling job I’ve had, and looks on track to be the gig I’ve kept the longest (currently Adobe, where I was for about 2 years).
On that note, in February, I got promoted to Engineering Lead, and started work with direct reports. In July, I got promoted again to Director of Engineering, and now manage most of the engineers. The move from software engineer who spends most of their days “in the weeds” to one who mostly manages people is one of the more culturally loaded narratives in our profession, so here’s some reflections/thoughts having been in this now for about 6 months.
I referred previously to the desire to maybe build my own business one day, and here are two ideas that I don’t entirely hate (which, if you know me, is a rare thing).
I’ve decided to take another shot at this page. While the ole’ poop-colored serif site was nice, now it’s time to make things MODERN 👽
Here are two screenshots of the old one for posterity’s sake.
I wrote an entire page about what this migration entailed, and will have it there as a static page. Check it out.
Updates to come, maybe!
The following is a cross-post with the Reonomy blog. It was made to soar and look good there, but figured I’d put it here since it’s still my writing. 😛
These days, we do things a bit differently in the company, as do I personally. I use Kotlin with Dropwizard and a host of slightly different techniques than in the example project. Nonetheless, hope it’s helpful to someone!
Hi Comrades! I’m Pablo 😄
I was responsible for writing the server layer for a new product under a tight deadline. I ended up writing it in Java with Dropwizard, and thought I’d share where I hit a pitfall or two in implementing the server to have certain features not specific to the domain logic of our app.
If you’re considering implementing your next REST service with a powered-up deployment of Dropwizard, read on!
(follow along with the example project demonstrating these integrations!)
Let’s blog blog this one, and talk about what my life is like for a bit. Like it’s LiveJournal again! Those were the days. Here’s my 2015 in review and hopes for 2016; a brief, incomplete, mostly incorrect list.
The following is cross-posted with the Ghostlight blog.
It’s not common knowledge, but Ghostlight is written in Erlang. This is slightly bananapants. Here are some thoughts and reactions to this choice, now that I’ve done substantial work on it.
I took and TA-ed my college’s Computer Security course, where we did things like write malware and put it on VMs, or sillier projects like port knocking. Who knows what they’re doing now.
Anyways, I always had one idea for a virus I wanted to write to maximize chaos:
Every n hours, the virus finds two files on the filesystem that have identical filetypes. Then, it swaps the files, but also swaps their filenames. Let’s see this in action:
# Find two files of similar types, then do something like:
mv $File1 $HOME/secret/gigli_ben_afflect_j_lo.mp4.tmp
mv $File2 $HOME/Videos/wedding_video.mp4
mv $HOME/secret/gigli_ben_afflect_j_lo.mp4.tmp $HOME/secret/gigli_ben_afflect_j_lo.mp4
What this does is: over time, the user’s filesystem will appear identical by most human measurement (the ‘Movies’ directory will contain a bunch of video files, with the same names as it’s ever had), but when if and when the user ever tries to open/use it, it contains something else entirely. In the example above, when the owner wants to watch Bennifer’s Gigli, they’ll see a wedding video instead. When they want to watch their wedding video, they’ll get Gigli. Do this slowly, across the entire filesystem and any filetypes.
I never even wrote a prototype, but when I considered doing anything like that, I always envisioned keeping something like a ‘transaction table’ so it would be easy to roll back.
Statement: I am plenty happy to use Java in a large number of contexts.
BANG! BANG! BANG!
Yes, I’ve read what jwz and Paul have written about it. In fact, I largely agree with all of it.
No, I’m not unqualified to say that. I’m not a defensive graduate from a so-called JavaSchool, I graduated from a pretty renown program. Like many engineers I often doubt my ability, but I’ve made it on the winning end of the Google Interview, and have written side projects in Erlang, Go, Racket, and Ruby. No company has ever fired me for technical ability or lack of contribution (one laid me off when they stopped making software); most have worked hard to keep me. It’s very, very hard to evaluate engineering ability but for the most standard (often bullshit) metrics, I pass.
I acknowledge that even in the game Java is playing, C# often does it better. I’ve never had the opportunity to use C# given it’s close association with Windows and the CLR; no firm I’ve worked with was using those, and when I choose technologies for my side projects, I usually use more obscure ones.
But frankly, I’ll go further and say it’s a damn good choice for many modules/projects.
Let’s break it down…
Today on Twitter is #talkpay, where we do what’s common in many countries (but taboo here) and talk openly about our salary experiences. While I’ll tweet my numbers, here are some other thoughts on salaries, tech, and pay.
(More about #talkpay here)
And the final part!! Part 1 covered architecture, and Part 2 covered libraries. Let’s finish this pup up!