We use Percy.io for this and can't recommend it enough. It integrates with your CI workflow, which makes a whole lot more sense to me than waiting until production. (Or to be fair, staging.)
Our one-sentence tagline: We are dedicated to making great software that helps governments and non-profits better serve their communities.
If you've ready some of the recent posts about US Digital Service or 18F, we're doing similar stuff, but from the outside-in, with mostly SaaS products. (Our flagship product, Screendoor: http://www.dobt.co/screendoor)
We're bootstrapped, profitable, and we'd love to find folks who are passionate about this kind of work. Stack is Rails / Postgres / JS -- nothing too fancy, but we're serious about the quality of our code. We're big on open-source, too: github.com/dobtco/
If you're interested in hearing more, email me at adam (at) dobt (dot) co
Ruby Developer to Fix America
Department of Better Technology
Headquarters: USA
http://www.dobt.co
About us
We’re the Department of Better Technology, a Knight Foundation-funded startup that’s digging into the guts of government and trying to fix it with technology.
Job Details
We're hiring a web developer to help us revolutionize the world of government IT. We started this company after being embedded inside government and seeing first-hand the horrors of the technology that these folks have to use everyday. We worked on a project called RFP-EZ that made it super simple to view and bid on government contracts. It wasn't anything amazing -- just a simple Bootstrap site, but just by making this process easier to understand for web firms who don't specialize in government contracting, we were able to save the federal government an average of 30%.
We've been in business for a just under a year, and have already created dozens of success stories - governments who are using our software to save staff time, save money, and provide better experiences for citizens. We're looking to grow our team and help us scale this success to governments across the country.
Experience
We're looking to bring on a developer who fits the following:
You are experienced in Ruby and ideally, Rails
You have strong knowledge of SQL/Postgres
You have a passion for good user experience and are excited about frontend development, too
You are comfortable working with a 100% distributed team
And last, but perhaps most important, you are as passionate as we are about our mission to revolutionize government IT
Our Culture
For many people in the technology industry, DOBT is a different kind of place to work, and a different set of people work here. Usually, they’re people who value time more than they value money. While from time to time, circumstances may call for it, you aren’t going to see a lot of 80 hour weeks, and depending on your time zone you might see some people who clock out at around 6.
You’re probably not going to be in a work environment that has a foosball table, catered lunches, and its own mass transportation either. That’s because we’re a fully remote firm. While some people may opt to work together in the same space, we want people to work from wherever they feel like it. So if you’ve always wanted to live in Japan, now’s your chance.
Diversity
DOBT is an equal opportunity employer. We will not discriminate and will take measures to ensure against discrimination in employment, recruitment, advertisements for employment, compensation, termination, upgrading, promotions, and other conditions of employment against any employee or job applicant on the bases of race, creed, color, national origin, or sex. We are committed in all areas to providing a work environment that is free from harassment.
Wow. I'm surprised at how big they were able to scale, while still pushing most commits directly to master and having a test suite that took 1hr to run.
> Passenger sometimes gets the date wrong when appending the http Date header to responses. This happens when the week-based year differs from the calendar year. It happens because it uses %G to print the year when it should be using %Y (see this commit: 15ed1d4).
Took me a few hours to track this down -- and it's probably affecting a large majority of the Rails apps that are using a Passenger server.
Hopefully getting the word out can save some folks a few hours of banging their heads on their desks.
On one hand: it's cool to read something so "unfiltered".
On the other, If I was a potential client of Dockyard's and saw this, I would run for the hills. This is not the kind of stuff that belongs on a company blog. Or any blog, for that matter.
There's a Rails design pattern where you send an AJAX request to your controller, and it returns a bunch of Javascript that gets eval'd by the page you're on. This is used for say, infinite scroll. You'll click the 'load more' button, the server will render a partial containing your new records, and return something like:
$('#itemsList').append('<li>My new item</li><li>another new item</li>')
So guess what? This is susceptible to XSS-ish attacks.
Let's imagine that instead of a simple list item, this request was returning some sensitive information or a CSRF token. (Egor points to various examples of this.) Normally, executing a GET request from an unauthorized domain will not be allowed because of CORS. This is what prevents me from instructing the users of my website to make an AJAX request to gmail.com, allowing me to see all of their emails.
But "wait", you say, "the content type of this request is application/javascript."
So open developer tools and type this: (using jQuery for conciseness)
> While Trenton and Paterson saw spikes this year, other cities like Newark and Jersey City haven’t seen much of a change.