One of the great things about Cucumber and Watir is that it allows you to write functional tests that are decoupled of the UI. By using page objects, the definition of how the UI works is decoupled from the tests themselves. If the UI changes, you only need to update the corresponding page object, and all of your tests still run.
Such tests provide an excellent safety harness in which changes can be made with the confidence of not breaking other features. The only problem is that the tests verify the functionality, but not the visuals of the pages. We were missing the safety harness for CSS changes.
For this purpose I implemented a set of tests that verify the visual appearance of certain core pages. This prevents someone from accidentally making a CSS change that affects other pages as well.
Since these tests are very brittle by definition, I do not recommend having a lot of them. You need to identify a few core pages from your application that rarely change their visual appearance, but which still cover the most important parts of your CSS.
For the impatient, the example code is on GitHub.
Many applications use the current time in their functionality. For example, they can show data for a certain period of time or show the current date within the application. Writing functional tests for such applications can be tedious. How do you write a repeatable test for functionality that only occurs on Thursdays?
For this purpose I wrote TimeShift.js. It is a mock implementation of the normal Date constructor which allows you to set the current time and time zone.
Date = TimeShift.Date;
// => "Tue Jun 01 2010 17:00:00 GMT+0500"
This way you can write repeatable test cases that still depend on the current time.
With the prevalence of smart phone cameras today, they are often used instead of scanners as quick digitization methods for documents. Unfortunately this leads to excessive vignetting (darkened areas at the edges), which makes it hard to print the document legibly.
For simple text documents and line drawings, however, it just takes four simple steps to correct the image. The following describes the steps in GIMP, but the same should apply to PhotoShop and probably other image manipulation software as well.
Software often requires two or three iterations before you get it right. In our case this led to starting a rewrite of our hybrid mobile application. It had been developed over several years by a diverse group of people with varying coding practices, and it was deemed easier to rewrite it than to refactor it into a maintainable state.
Below is the results of our comparison between the three. This is not an extensive functional evaluation (a luxury not available for startups), but instead based primarily on reading the following books:
I can recommend these as good introductions to each language, as each one can be read in a few hours. You may also be interested in Anton Ivanov’s blog post comparing the three with code examples.
Note: The t1.micro instance type has been superseded by the t2 family, which are much better suited for general use. I ran some tests on the t2 family as well.
Amazon t1.micro instances are the most affordable EC2 instance types. Their distinctive feature is that while allowing short bursts of high CPU power (around double that of a m1.small instance), but very soon throttle the CPU usage significantly. Therefore they are well suited for uses where there is low constant load, but periodic bursts of high activity, such as web servers for low-volume sites.
However, Amazon does not provide any specification on the exact method of throttling nor how long you can use full CPU utilization before the VM throttles. I couldn’t find any info on this elsewhere, so I did some testing myself.
Update: I ran the tests longer, and it seems that the amount of CPU time given to a particular instance does not depend on the weekday, time of day or other load.
I have been an avid user of the Gimp for well over a decade now. I started using it in the mid 90’s around version 0.60. I was promoting it to my friends as a great image manipulation tool, and recall laughing at PhotoShop that had only one level of undo at the time.
During that time Gimp evolved fast. I anticipated every next release, and each one seemed to get closer to the functional level of PhotoShop. Somewhere around version 1.2 – at least from my perspective – the only major deficiencies were lack of 16-bit color and CMYK support.
But then the development slowed down. Major releases have been coming out every 1-3 years, but I haven’t noticed much change between them. 16-bit support and CMYK would be supported by GEGL, the do-it-all graphics library of the next-generation Gimp. GEGL’s first release was in 2000, and Gimp has yet to see 16-bit support.
For many years now I have considered the Gimp to be at a dead end. I have the utmost respect for the people who have worked – and still work – on it, and I use Gimp regularly. But it seemed that to pull the next big thing into Gimp was too large an undertaking for a volunteer project.