Posts

Well, that title is a mouthful. It is intentionally verbose so that if anyone stumbles across this issue, they can easily find this article and not spend time (like I did) sifting through source code for an answer. Background Let’s say you are creating a new hook in your development IPBoard 3.x 1. This hook changes the values of a few settings that already exist in the system (for example, disabling Gravatar support). While this setting could be easily changed by an administrator, we want to programmatically change it through the use of hooks. ...

Not enough people give careful thought about ensuring uniqueness across systems when they design a solution. This goes doubly so for off-the-shelf (OTS) software packages. And if the design isn’t well thought out, it is going to be difficult to ensure uniqueness when doing any data migrations. Granted, data migrations are an art more than they are a science. There are always edge cases and invariably something goes wrong that nobody thought about. This is why testing a data migration multiple times should be built into any project plan (and given an extremely large buffer in the budget). ...

I’m currently building my new product, Storigible, and where I get stuck is the marketing component of the website. Specifically, the difficult part for me is getting the design right because I don’t see myself as a designer 1. All of that aside, what I’m writing about today is the usage of shell scripts versus more complex scripts to automate things like deployment. Storigible’s marketing website is a static website served by Amazon S3. I created it this way because the marketing component can be fully decoupled from the application component (which resides at another subdomain). I needed a good way to deploy the website files onto S3, which is basically saying, I needed a good way to upload the files to S3’s server. Deployment isn’t much more than a simple copy when you are dealing with a static website. ...

I attended BSides Vancouver last week (great job everyone!) and Mark Curphey had a good talk (Modern Software is Like Lego & WTF Don’t People Use Secure Headers?) containing a statistic on how few websites use secure headers. His company even came up with a Web-based tool to find which websites contain secure headers. I love this idea but I found it lacked in one area: testing sites not publicly addressable on the Web. There are many more internal websites that could be sniffed or exploited inside company networks. So I went about writing a tool called tinfoil that allows anyone to check servers within their network. ...

I’m writing up a new gem called Tinfoil that tests whether web servers support secure headers. Since this is a command-line interface (CLI) for a Unix-based system, I have a hard time testing the CLI in Ruby’s built-in Test::Unit framework. The problem is that the CLI outputs directly to STDOUT and STDERR, polluting my test output when I run them. The problem to this was solved by capturing stdout and stderr and redirecting them for a short time while the test runs. I got it from this StackOverflow answer, and I have added another method for capturing stderr. ...

I just completed a set of interviews with a company for a technical lead position 1. At the last interview I got a bit quiet at the end which I explained to the interviewer was because my brain has now spun up and I’m starting to think about ways to fix some inefficiencies I heard about in the previous interviews. In each interview I made notes along the way about how I’d fix the issues, and I feel it is a tragedy to not allow part or all of this information to be used by someone 2. ...

I’d like to play a little game with myself and enumerate each common interview question that I’ve received over the past few years. By writing these questions and answers down, it affords me two things: (1) to have the time to think about an answer instead of quickly blurting out something half-baked while having interviewers stare at me, and (2) to say the things in a manner that is not always available in the interview setting. ...

The phrase “Don’t call us, we’ll call you” is an old saying that stems from the theatre industry in regard to auditioners facing rejection. I’m going to co-opt this phrase and twist it a bit into how companies that interview candidates hold all the cards and act in a manner consistent with information asymmetry. I recently interviewed for a senior managerial position doing something akin to DevOps for a startup. I asked a number of questions about the type of work and such, very technical and job-specific in nature. I then asked about some things that appeared in the job description (see section “Job Description”). The interviewer (who was new to the company herself) said that she didn’t know the answer and that I should forward the questions to the in-house recruiter with whom I spoke with earlier. It seemed like a totally reasonable response, so I whipped up an email later that night and sent it off the recruiter. ...

I am in the process of consolidating a number of websites that I use into a smaller set of servers. This is partly being done to reduce costs as well as support less resources, but it also provides me with a chance to try out new things. In particular, I wanted to test out a load balanced architecture that will work within any VPS environment. Before I begin provisioning “real” servers and having companies bill me, I wanted to test that my ideal architecture works. I’m using the word “real” here to denote servers that will be public-facing and acting in a production-like capacity, as well as incurring billing charges. ...

I mentor Computer Science students at my alma mater and one of them recently asked me if I could provide some tips about interviewing. It is a question that comes up repeatedly, so I finally wrote it all down and I’m sharing it here so that others can learn. I gathered these tips from interviewing on both sides of the table (or phone connection) numerous times, some ending well and others not so much. Enjoy! ...