For most developers working on a web application useful enough that people actually want to use it, a time comes when they need to start thinking more about how to make it faster. There are several good books (and videos) on how to go about this for web applications in general. There’s also pretty good advice for optimizing Python applications (like this, which covers some of the profiling tools I mention below). For getting performance data from a live site, you probably want to use something like New Relic, which can give you a lot of useful information with relatively little performance impact. But sometimes, you’ve already figured out that the code which serves a particular URL is slow, and you just want to optimize that (preferably in a local test server without needing to hook up a lot of external services to it, so you can quickly measure before and after performance data). Continue reading
Dear QA-self from the past,
This is your QA-self from the future writing to give you a quick pep-talk. Right now you do not have access to the Website’s Database so information that could take you a matter of moments to obtain end up taking way longer because you don’t have permissions to a run a simple query. You also have no control over your Test Environment or what gets deployed to Production. You’re frustrated because changes you aren’t aware of keep sneaking in. The good news is that things will be opening up in the coming years when you start working on Safari Flow. You’ll have access to your Website’s Database and can deploy builds yourself to the Test and Production Environments as needed.
At the Ampersand conference, Nick Sherman talked about responsive typography — where typographic displays change to respond to the viewing conditions — and how we can use face detection in the browser to serve up the right size type for a reader. He showed us a nifty responsive-typography-via-face-detection demo, and he demoed his size calculator, which allows us to serve up an appropriate type size based on viewing distance.
When Liza Daly, our VP of Engineering, announced this year’s “Blogathon” (30 days of employee-sourced blog posts), I was intrigued and excited. I’ve never written for a blog before and I really wanted to participate.
As much as I was thinking about it, I still couldn’t come up with a topic. For example, I love to bake and I really wanted to find a way to mix my discovery of “just the right amount of time to bake Twix Stuffed Brownies” into a pithy commentary on the importance of testing before release.
This post will describe my experience porting a nearest-neighbor web service from Python to Go. Rather than discussing Go’s language features or best practices, which I am not qualified to do, I will try to entertain you with an in-the-trenches look at the porting process. We will enjoy some first-blush encounters with Go programming from a Python programmer’s perspective, such as:
- Dev environment
- Third-party libraries
- Performance profiling
This is a question that many software companies will ask themselves when it comes to testing their code. To answer this question we need to discuss what automation is, and then discuss possible solutions.
What do you think when you think about automation? Most people think that it is record and playback. Fairly, this is where some software automation tools started, but this type of testing is very limited. If the workflow of an application is dynamic, the playback scripts running against them are very fragile and prone to error. A lot of effort goes into determining if the application was at fault or if it was the scripts.
If you are a developer, you might think that automation is very similar to unit testing. That is also fair, since both types of testing can use similar tools. However, the goal for unit testing is usually to test the smallest testable part of code, and each test is designed to run in isolation.
If you are in Quality Assurance and do not have an in-depth technical background, you could be staring down a deep rabbit hole. Automation tools have come a long way in order to provide the modularity and flexibility needed to test a dynamic application. Automation for functional testing of software needs to be modular; however, scripts need to work together to test the workflow of the application. It also needs to be flexible enough that if the workflow changes, major overhauls are not needed. As well, if multiple people will be creating scripts then they need to be stored on a server or in a repository and not on a local machine.
Buy vs. build
The draw of licensed products is that some of the technical aspect is already done. A licensed product provides a framework that includes logging, reporting, and a structure for the scripts. The drawbacks of a licensed product are the potential costs, the use of proprietary scripting languages. Moreover, limited configuration options can restrict flexibility to some degree.
The draw of open source products is that the up-front cost is minimal, if any, and flexibility is optimized. However, the technical aspect of implementing open source tools can be that rabbit hole I mentioned earlier. When attempting to use open source automation tools, you will soon find that you need several components to make tests run.
First, you need the driver that drives a web browser or application. A good book to read to get familiar with one of the more popular open source automation engines, Selenium, can be found here Selenium 2 Testing Tools Beginner’s Guide.
Next you will need some type of test runner that finds test case classes within your scripts in order to run them. One of the popular test runner applications is TestNG. Tips on how to use TestNG with Selenium can be found here Time for action – using Selenium with TestNG from TestNG Beginner’s Guide.
From here, you will want to have a utility that can parse logs and output meaningful reporting. You will probably want to set this up with some scheduling to run automatically at certain times. You will also need to decide on which programming language to use for the framework and for the scripts. Putting all of these components into place is part of building the framework.
With all of this in mind, I will say that automation takes dedication and commitment by the company. It is not a part-time task that a QA engineer can perform when they are not manually testing on other projects. In most cases, it will be best to either purchase a licensed tool to get the built-in framework, or commission a developer to build one with requirements coming from the QA personnel that will be creating and maintaining the scripts. Functional Automation Testing is not a silver bullet that can be built and left to its own devices. However, careful planning and dedication to this type of tool will pay off. If done correctly it will provide a good sense of stability in your application.
If you’re hiring people to write programs, you should work on a program with them.
This advice is nothing new but is too easy to ignore or botch. Switching my interviews to live coding on a real program is the single biggest hiring improvement I’ve ever made. It was helpful enough that I don’t think any of these concerns should stop you from doing the same:
- Should there be a written test?
- If so, how tricky should we make it?
- How many days do they need to complete it?
- Should they do it on a whiteboard to prove how good they are with markers?
As an engineering team, we’ve worked very hard to develop a culture that rewards programmers who learn to understand the business and our customers, and who make good choices about the right code (and quality) for the problem.
A lot of advice about coding tests comes from companies very different from ours. Instead of working on problems at the bleeding edge of distributed systems or category theory, we work on websites that delight and inform other programmers (and regular folk) with books and videos. That means that most of what I have read from others about interviewing sounds completely contrary to what we do. Instead of favoring a candidate that can plow through a ton of homework, I want someone with enough experience to ask the right questions and challenge shaky assumptions. Instead of picking someone who can write algorithms on the board, I want someone who can use their tools effectively and has great habits.
All this distaste for traditional interviewing methods meant that I was ripe for a change when I sat in on a CTO roundtable at an unconference a few years ago. The theme that emerged was hiring and I was fortunate enough to hear a few very good folks talk openly and honestly about the techniques they used. One shared some very clear lessons about how to do coding interviews and out of that I’ve built my own approach. Here’s the mechanics behind it.
Ada Lovelace met Charles Babbage as an eighteen-year-old at a party thrown to show to the best of London society Babbage’s Difference Engine. The Engine was fantastic new device that — using the latest Industrial Revolution skills of precision machine tooling — for the first time allowed for automation in the performance of complex calculations.
Babbage was designing the next version of his calculating machine, The Analytical Engine, and asked Lovelace to translate a description he had received from Italian mathematician Luigi Menabrea discussing the principles behind it. The original work was a little over eight thousand words; Lovelace appended her own notes, extending the translation to over twenty thousand words. In the process she described a method for calculating Bernoulli numbers, creating what is now recognized as the first algorithm intended to be processed by a machine.
The Analytical Engine took its lead from the Jacquard Loom by performing its tasks according a series of punch cards, which would be widely used to program computers well into the 20th Century. As planned, it:
incorporated an arithmetic logic unit, control flow in the form of conditional branching and loops, and integrated memory, making it the first design for a general-purpose computer that could be described in modern terms as Turing-complete.
Unfortunately, the Analytical Engine was never built in Babbage’s or Lovelace’s lifetimes. Ada died when she was thirty-six, probably the victim of misguided blood-letting by 19th century doctors. Babbage worked on various designs until his death in 1871, but an actual working specimen engine was not completed until 1991 when the UK’s Science Museum built a version (weighing 2.6 tonnes and consisting of 4,000 separate parts) using materials only available to Babbage himself.
Ada is certainly not forgotten though. She is immortalized in the name of the Ada programming language, and each year October 15 is recognized as Ada Lovelace Day, “an international celebration of the achievements of women in science, technology, engineering and maths.”
These days, being a font geek is the hip, happening thing to do. Everyone seems to have a favorite font typeface, and everyone seems to hate Comic Sans. The ability to install hundreds — if not thousands — of fonts on your computer makes playing with typefaces accessible to anyone. Then there are type geeks, who are also often typographers by trade (because let’s face it — if you’re this obsessive about type, you might as well make it your main occupation in life). Typographers rarely have one favorite typeface, although they can usually expound at length on the superiority of Helvetica over Arial. Instead, different typefaces are designed to do some kinds of work better than others; they also evoke different feelings and connotations. Type is a tool for design, and it’s a really, really powerful one at that.
Sadly, up until recently, the world of type design and the web were frustratingly separate — there just wasn’t support for using most fonts on the web, let alone fine typography. Designers were limited to a handful of web-safe fonts which, while mostly worthy workhorses (except for Arial. Let’s never use Arial again, m’kay?), dramatically limited the degree of typographic expressiveness one could achieve when designing for the web. These days, the advent of online font services such as Typekit and Google Fonts has completely changed the landscape, and web designers have (re)discovered type. For those of us who were trained as print designers, it’s like coming home, a bit.
That’s why I was incredibly excited to attend the Ampersand Conference last week. It was held at the Times Center, which is a very nice space in which to have a conference. Despite (or perhaps because of) it being a one-track, single-day event, the Ampersand schedule was packed with interesting-sounding talks. Usually, despite interesting-sounding topics, you expect most of the day to be full or decent, but unremarkable talks, and to have one or two highlights that really blow everyone away. Well, I’m happy to report that Ampersand exceeded those expectations. Each and every talk was interesting and engaging in its own way (from super cool proofs-of-concept work to wacky and offbeat personal/professional narratives) and there was a distinct earnestness about all the talks, which is reminiscent of some of the things I’ve heard about the xoxo conference. Some highlights:
Type as Brand, Brand as Type by Michael Johnson
Michael Johnson of Johnson Banks opened the conference with a rumination on the growing role of type as a key component of identity design work on the web. Johnson’s presentation did great double duty: it chronicles the progression of the state of the art in web typography from its meager beginnings to the recent flourishing of typographic expression online, while highlighting the absolutely critical role that typography has in developing the visual aspects of a brand identity. He’s been kind enough to post a transcript of his talk here — it’s well worth a read.
Putting the Fonts into Webfonts by Jonathan Hoefler
We’ve been using web fonts at Safari, most notably on Safari Flow, so we’re pretty familiar with the offerings from Google and Adobe. But Jonathan Hoefler’s presentation of Hoefler & Frere-Jones’ new web fonts service, Cloud.typography left a lot of us kind of in awe. His talk was impressive both because of the service’s rich typographical features, and because Hoefler managed to make what could have otherwise been a pretty dry product pitch into a deeply engaging survey of the state of the art in web typography. He’s doing it again this week, at the NY chapter of AIGA.
The Future of Responsive Typography by Nick Sherman
Nick Sherman has been writing really insightful things about typography on the screen and how it relates to readers’ eyes in the physical world. His talk on responsive type fed off of this theme, from the trials and tribulations of font hinting, to the vagaries of compensating for size and resolution-related issues when designing and displaying typefaces on screens.
Jen Lukas: On Icon Fonts & Working with Designers
Jenn Lukas walked a roomful of designers and typographers through what collaborating with developers looks like from the dev’s point of view, highlighting some crucial best practices along the way, with a major detour through a survey of her experience when researching icon fonts. Her liberal and wry use of animated gifs and cat macros (not to mention a radical sandwich metaphor throughout her slide deck) ensured that no one succumbed to the dreaded mid-afternoon slump.
In all, a great way to spend a Saturday (If you’re a type geek, that is. If not, YMM definitely V).