Wherein I recap the things I’ve done and learned this year as a software developer (mainly at work). I’ve fixed many bugs and uttered many curses. Through it all I’ve constantly strived to make the code a better place.
Amazon Web Services
Video encoding instances Launch/Start when there’s a backlog, and Stop/Terminate when there’s not. Said goodbye to Amazon SQS for job queues, and hello to Redis. Hello consistency and speed.
There’s a quirk with Android that renders a partial wake lock useless if you want to poll the accelerometer while the screen is off. The workaround is to acquire a screen-dim + acquire-causes-wakeup wake lock. The screen turns on while you’re polling, but that’s the only solution I’ve found.
I’ve implemented the workaround in my GPSing project. Hopefully this won’t cause a drastic change in battery usage.
The data hoarder in me is making an appearance. Been tracking my GPS coordinates more consistently for the past few weeks, but InstaMapper on Android is less than ideal for the task. Geoloqi as well. They consume too much battery. I’d rather not have to turn them off when I’m going to stay put for a while – I don’t enjoy fiddling with my phone in public.
Last weekend I began a project of my own that uses the accelerometer to determine when GPS should turn on.
Writing code that works with time seems easy. But there are many time pitfalls.
Non-coders can skip this article …
You’ll be vulnerable if the following are true:
You’ve got a webapp that accepts user input You use strip_tags() or similar to sanitize fields You don’t explicitly remove less-than or greater-than characters from those fields (PHP’s strip_tags won’t remove a partial “<script” tag) Values from two or more of these fields are printed close to each other in the output HTML, with little or no markup between them The fourth item is tricky … The markup between the field values must not contain any quotes (the quotes would prematurely close the script tag injection attempt).
If you get confused by non-simple Git workflows, this howto on git forking, branching, etc should help.
Oh thank god! Branching I understood, but was clueless when it came to pushing up a specific branch.
Rebasing too … reminds me of how we badly need a separate dev environment at work. Ugh.
In all, a wonderful tutorial that helps you play along with others while programming.
Building upon Joel’s post on Unicode, here are some real-world tips relating to character encodings.
Use them by name
Always explicitly specify which encoding you want (perhaps UTF-8). Don’t assume the language or library/tool you’re using will make the right decision for you. If you value your time, don’t ignore this recommendation, otherwise you’ll likely spend lots more time patching things up in the future.
A tale to drive this home
Got to use node.js for a work project recently. We needed an FTP server with special user authentication that would run custom code after a file was uploaded. There was one node.js FTP server implementation on github, so I forked it and started rounding out the basic functionality. My fork is here.
The first significant change I made was to encapsulate the data connection logic. File lists and file contents are transferred over the data connection (FTP commands and responses over the control connection).
Been powering through Embedded Linux Primer. A few high-level things I’ve learned:
initrd is old, initramfs is new initramfs uses a CPIO image (a type of archive that was new to me) to hold the initial filesystem contents Using TFTP to boot from a remote kernel and ramdisk sounds like fun, not to mention provides great flexibility for debugging. It’s not so hard to add extra items to the kernel config menu Learned some ins and outs of Das U-boot, and that support for using RAM has to be initialized by the bootloader otherwise you can only use stack memory.
Didn’t expect to find any books on our outing yesterday, but I had a pleasant surprise. Last week I finished my previous book on embedded Linux, which was a great case-study-esque intro, and Embedded Linux Primer will likely be a wonderful follow-up. Some of the chapters that caught my eye:
Storage Considerations Systems on Chip Bootloaders Device driver basics Filesystems Busybox Development tools beyond gdb: cscope, strace (and others) Kernel Debugging Techniques Open Source Build Systems udev Test-Driven Development for Embedded C was a surprise as well.