512 karma · joined December 4, 2007
Feel free to contact me: noah at volantio dot com
Volantio is hiring an experienced full-stack developer to help us fix travel tech for airlines.
We make some of the world’s biggest travel sites suck less, by providing technology products to airlines and other travel companies (and drag them kicking and screaming into the 21st century). Everything we do improves the airfare search process for millions of people in at least some little way. One of our airline partners likes what we do so much that they made PriceWatch (one of our products) a core part of their brand identity. Here's an ad spot they put together: https://www.youtube.com/watch?v=RWn8-QbRUKU
We’re a close-knit team and have a variety of challenging work on our plates. A typical day can consist of everything from optimizing the Fare Prediction System in the morning to putting the finishing touches on a CSS animation in the afternoon. Our work spans multiple technologies, cultures, and languages (both programming and spoken!), so we value high quality communication and a continuous process of learning from each other.
We're looking for someone with at least a few years of professional software development experience that wants to work with us. Most of our products are built on the Django framework, with Redis, a Postgres database, Coffeescript, and countless other technologies used as needed. You're not expected to be familiar with everything - that's what the 'continuous learning' is for! You'll be a core member of our team - able to develop the role and technology in a direction that you find exciting as we grow the company.
If this sounds interesting, we would love to hear from you. Please include whatever info you believe is relevant: resume, GitHub profile, code samples, links to personal projects, etc.
You can apply by emailing directly (jobs@volantio.com)
I thought I'd suggest that you remove the underline from all of the lines at the top of the page, as it makes them all appear to be links and reduces readability. They will be just as prominent without that decoration, and it will actually make your sign up link more visible.
You may want to consider moving the sign up link to the entire phrase: "save your meal plans and make a grocery list ". People will probably click on that more often than the non-descriptive phrase "Sign Up". The latter phrase requires additional effort on the part of the user to read to text next to it, remember the sign up link, and make the decision to go back to the sign up link at the beginning of the phrase. It's worth a/b testing.
Interesting site!
For my usual trip each day there are several buses that work for me, and what I was hoping for is a site that centers a map on my location (from my phone gps) and shows me all buses in my general vicinity. I would use this to select a route.
Here is the issue: Whether the Constitution allows police to put a tracking device on a car without either a warrant or the owner's permission; and whether the Constitution is violated when police use the tracking device to keep track of the car's whereabouts.
I lived in it full time for about a year, inspired by Tynan's posts on the subject. However, I've now gone overseas to Bali and left my Winnie parked in Maryland. It's actually quite a bit cheaper to live here and the internet still works fine :) Have you written up anything about your travels?
Is the term 'asymmetric key encryption' meaningful, or did I just make that up?
Asymmetric key encryption is slow, and symmetric is fast, so we use the former to set up the conditions necessary for the latter: If we both have a box and keypair like this, then you can send me your secret phrase using mine and I can send you my secret phrase using yours. Now that we each know both secret phrases and nobody else knows either, we can combine the secret phrases and switch to symmetric. That's how SSL is set up.
With a testing framework, you won't waste time rolling your own. For Java, you could start with JUnit.
TDD is a formalized approach to writing test functions as you work, which you already do, while simultaneously designing your code. There are many sources on it around the internet, but Kent Beck's book took the magic out of it (a good thing) for me: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...
Of course, there are many other specific techniques you can use to test that your algorithms do the right thing, all dependent on what you've made. Regardless, I try to make sure that the a real user gets their hands on an up to date build as often as possible, and they're sure to show me all of the ways that my software is technically excellent, yet in no way solves their actual problem.
The description, from the website: "Robocode is a programming game, where the goal is to develop a robot battle tank to battle against other tanks in Java or .NET. The robot battles are running in real-time and on-screen."
Are you going to also follow his advice and hire two or three different people to work on the the first bit of the project?
I think it's an interesting idea; it acknowledges how likely it is for a software project to fail, or to at least be mediocre. I've always wondered whether large companies might be able to do well with several teams working on the same projects, and a process where one team's code is periodically selected to form the basis of the next version, then everyone else starts from there.
I was in a similar situation as you are; running a small programming team at age 27, with no real commitments. I decided to stay because the opportunity seemed too good to pass up, but I'll never know where I'd be now if I took a risk back then. Over those three years it seemed like everyone I interviewed ran their own project. Many popped back and forth between working as part of a team, and running teams several times in their career, so it's not as special an accomplishment as I'd thought at the time. Now it's three years later, and I've gone part time and started telecommuting so that I can travel wherever I want and have time to figure out what I want to do next. Your choices may vary. Good luck!
He ended up creating his own build system, "tup" < http://gittup.org/tup/ >, based off of it. It also has the property desired in this article that, "No-op builds should be O(1) and instantaneous, and most other builds should be O(WhateverChanged)".
He goes on to explain what else is required to do it correctly.
I understand that Netflix does something like this. They pay salaried employees top dollar, give them choices about what to work on, and demonstrate their trust with policies such as the no-vacation-policy policy. < http://www.slideshare.net/reed2001/culture-1798664 >.
The other 2 chapters in this end section are similar, with one each focusing on raising children and how to structure education.
The goals of our bug tracker are to get bugs fixed and tested quickly, with the main goal of having no known bugs in the system. Specifically, we realized that most tracking systems are optimized for bug archival, whereas we wanted a system which is optimized for getting the bugs fixed, given our environment.
I've found that I have a very strong preference for an empty bug-tracking whiteboard, and the more items on it, the more I feel compelled to fix bugs rather than work on other things. It's great for communication, because you can just go talk about the item on the board. Even the process of marking something off on the board makes everyone else peripherally aware that something changed, so nobody has to check whether there's something for them to fix/test - they know. Often bugs are fixed and tested within the same day they're discovered. If something stays on the board for a while it's obvious to everyone that there's a more serious issue that we need to discuss.