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!
Welcome back! Part 1 covered architecture, and Part 3 covers testing and miscellany. Here we’ll talk about —
I’m one of a small team of engineers for Sup, now on the Play Store and App Store. Download it! Use it! Every day! Make our founders and their investors happy. The more people are happy, the more likely it is I continue to get paid. I don’t need the money, but the people I owe do.
I wrote the first iteration of the server, but since the beginning of August I’ve worked almost exclusively on our Android client. While I did some very basic Android work in college 4 years ago (cringingly documented in part here) I consider this project, effectively, my first real exposure to Android.
Here’s a little overview of the tech behind the product: some architecture decisions, techniques and libraries that facilitated code re-use, a few gotchas, and resources if you ever want to delve into more Android work. This post is primarily about Architecture; Part 2, on Libraries, is here. Part 3 on other miscellany is here.