At the moment, the position has only been posted to HN, though it should be up on the site and other job boards today. It just opened up, so I was eager to get it posted in this thread.
711 karma · joined February 1, 2011
Frontend Engineer
We're one of the oldest PaaS's out there, with support for PHP/Ruby/Java/node.js and both AWS and Azure. Earlier this year we launched a brand new user experience from the ground-up -- a new website and a completely new client-side interface. As a Frontend Engineer, you'd be working primarily on the latter.
The UI is written using angular.js served up by a lightweight node.js api proxy server. We use mocha/selenium web driver for our tests and only accept green builds via travis to be merged to master. Through our "eybot" on slackhq, we deploy stable code to production multiple times a day.
The UX engineering team at Engine Yard consists of 3 UI designers and 4 engineers (including myself). We're spread out across 8 timezones (Dublin through San Francisco), so experience working in a distributed team is key.
You'll get:
* Competitive salary
* Full medical, dental and vision benefits
* 25 paid days off per year
* 401(k)
* We take care of your phone bill
* Paid travel to conferences
* A passion for writing great software to solve real problems for real people
* Demonstrated experience building complex client-side applications in
JavaScript, preferably with angular.js
* Experience working in a distributed team
* The strong belief that a feature isn't finished until it's tested and, where
appropriate, documented
* A fantastic sense of sarcasm
* Ability to travel occasionally (at least once or twice a year)
* Somewhere between UTC and UTC-8
* Thorough understanding of git
* Experience building REST apis
* Experience with multiple languages (and an understanding of their tradeoffs)
* Previously worked at a startup
So it's more like `python -m SimpleHTTPServer` than the node http module.
We have tests in place to help stop regressions, but sometimes seeing a change in action can really help to put the corresponding code in context.
Most of my team uses hub, but you can check out a pull request easily enough with git:
git fetch <remote> +refs/pull/<pull-request-number>/head
git checkout FETCH_HEADThe same goes for angular-resource, angular-cookie, angular-scenario, and the newly created angular-route. They are all versioned along side the main library, so use 1.2.x as the version for all of them.
There are many other forms of radiometric dating, though. Uranium-lead dating has proven relatively accurate for periods of time between 1 million to 4.5 billion years ago.
Note: I'm not a geologist. I remembered that carbon was only effective for a few thousand years from a geology course I had in college, but all of this information is actually taken from articles on wikipedia: http://en.wikipedia.org/wiki/Radiometric_dating
Our 2005 Honda CRV is approaching 120,000 miles, and both myself and my fiancée telecommute.
Edit: Especially given my short response, I think it is important to reiterate how much I am not a lawyer.
See http://en.wikipedia.org/wiki/At-will_employment and specifically the "Statutory exceptions" section.
Consider this:
The link A | A sublink of B
Some Link B --> | Another sublink of B
A link C | And again a sublink of B
| Jez, B has a lot of sublinks
I wouldn't be surprised if the authentication process was taking long enough that a decision was made to add some sort of "loader" like this to make it appear like the extra time was absolutely necessary from a security standpoint.
It's a bit of a lazy decision from a UX standpoint, but it isn't entirely uncommon either: when you notice some action is slow, slap an animation in front of it.
At Engine Yard, we're building new technologies that allow our customers unprecedented control in managing their mission-critical application architectures in the cloud. We believe that the best platform for our customers is one that provides them the flexibility to run any software, on any servers, and on any infrastructure provider that they want.
We're looking for a frontend developer that wants to be instrumental in building highly-functional, client-side interfaces that bring that vision to life.
I'd love to hear from you if:
- you enjoy writing JavaScript and have significant experience building complex user interfaces with one or more open source frameworks such as Angular or Ember
- you are eager to make an immediate contribution in a small distributed team of talented engineers and designers
- you appreciate the ruggedness of prototypes, the power of promises, and the beauty of functional programming
- the idea of building a client-heavy frontend that interfaces with one or more REST apps seems natural to you
- you understand the software stack and have probably done your fair share of backend development in your career, but it just doesn't excite you like building the customer-facing aspects of software
- you love to build awesome things and are not afraid to show it
If you have any questions about this position, feel free to contact me directly (check my profile).
Check out the official job description and/or apply for this position at http://hire.jobvite.com/j/?cj=oPEaXfwk&s=HN
To the contrary, I thought the theme of his post was specifically that he didn't know how Instagram's new policies would effect personal privacy, and that lack of understanding concerns him. When pondering the implications, he even goes as far as to ask whether a worrisome, fictional scenario was even a possibility rather than insisting that it would happen.
Where do you think he expressed a sense of entitlement? He's not a user of Instagram, so I didn't get the impression that he thought Instagram owed him something.
I think his whole post is a lead in to an excellent point: in the "social web" in which we all interact daily, we are seeing more and more that you don't have to use a service in any way in order to be affected by the decisions that services make about its own users' privacy. All entitlements aside, it is becoming increasingly difficult to maintain control over your own privacy when the details of your life are extracted not as a result of your own deliberate decisions but by the decisions of others.
Opinions about whether Wil Wheaton is a self entitled geek aside, I hope we can all agree that that is a point worthy of consideration.
Client: https://github.com/epixa/chuckt
Server (node): https://github.com/epixa/chuckt-node
The project is still very new, so I haven't finished the tests nor documentation, but the readmes on those repos have information about installation and usage.
Is it the prevailing opinion in the startup community these days that building up personal debt and letting your relationships fail are worthwhile parts of starting a company, or is this, as I suspect, just a sad story about misaligned priorities?
I don't mean to attack any premise of the story; I'm honestly curious what startup founders think of this article. I personally have no goals of huge buy-outs nor IPOs, but I would like to start my own business some day. I can't imagine being willing to give up my significant other to focus on the business, and I would hope that about the time I start thinking about using personal credit cards to finance the company I also stop and realize that the company is dead already.
I sincerely don't know what I'm suppose to take from this article, but I have the feeling based on some of the comments in this thread that the parts I find important are not the same parts that others find important.
A couple of suggestions:
1. The person/model used for the primary image/ordering system looks miserable. "Look, you can get your own custom shirt, but it isn't going to make you happy" doesn't exactly seem like the message you're trying to send here! A smile would go a really long way. Also, the cropping around the hair makes it look a little less professional. I'm not a designer, and I'm sure it is difficult to get something like that perfect, but I think it is worth the effort given how prominent the photo is.
2. The photos of the t-shirts themselves make the t-shirts look like they're low quality (specifically, really thin). I'm not a huge fan of white shirts in general, but I definitely don't want any t-shirt that I can actively see through. Sure, your "gallery" model may be attractive, but it doesn't look very professional (nor does it speak highly of your shirts) if you can see her bra through the product.
3. I feel like the "About, delivery & more" link should really link to the "About" section. I was a little confused when it jumped down the page and I was just staring at some random "suggestions" which, in my case, were not interesting. There's nothing wrong with the suggestions, I just don't think they should be more prominent than "About".
4. I'm on a 27" thunderbolt display, and the marketing material in your bottom tabs is taking up less than half of the bottom of my screen when I am scrolled down as far as I can go. That's not the worst thing in the world, but I would rather scroll down than just change the bottom 40% of my screen when I click "tabs".
5. I'd want more information about the product, the company, and possibly you before I order anything. If you're trying to sell quality, then a full page talking about how damn awesome your shirts are would go a long way to converting me to a customer. And after you sold me on the product itself, I still wouldn't feel safe ordering anything from an unestablished company with no business address, almost no information about the people behind it, and no contact means other than email/twitter.
All in all though, it is cool to see what you can accomplish in only four days. Best of luck.
I think we can all get behind the idea that the ongoing "which framework is better" debate is often pretty ridiculous. Different frameworks are clearly better suited for different tasks.
But I can't really get behind the author's stance that it is wrong for people to have preferences (even strong ones) about which javascript frameworks they like to use.
For one, while every framework likely has different strengths, that isn't the same thing as all frameworks actually being good. It is very possible that an intelligent person with great intentions could write a framework that simply falls short of other frameworks in so many important regards that you can't really consider it "good". It is also possible that a framework will have such a niche use that most people would not benefit from using it.
Additionally, while not every project has the same sorts of requirements that could be satisfied with a single javascript framework, most are. Most apps that are being built in the startup community these days are basically little more than user interfaces to some REST api. Some may take it a step further and go "realtime" by using web sockets, but the application doesn't differ significantly from a REST based equivalent. If multiple frameworks set out to solve common problems, then I don't think it is ridiculous at all to compare them and maintain a preference.
One way or another, I think we can all agree that the title "Client-Side Frameworks Suck" is total link-bait that does not adequately describe the article itself. To be fair though, I did not watch his talk, so it is very possible that this title better describes the contents of the talk itself.
The office "christmas party" from the white collar mega-corp where you work is usually a big hit because of its free booze. After you win your game of adult <whatever sport you play>, the team goes out for pub food and drinks. When you invite a bunch of people over to watch <some important event>, you usually supply sandwiches, pizza, wings, booze, etc.
Heck, I can't remember the last time I've actively set up a meeting with someone that wasn't over a cup of coffee or a beer, and I don't own a startup or live in an area that even remotely resembles the common hubs for startup culture in the US.
People are just unhealthy, and in social situations, it is usually important to cater to the needs/expectations of the masses rather than the few.
I'm not sure if the list comprehensions feature has made it past the mailing list though.
Github is an impressive company that has, so far, blown away its competition in many aspects. The fact that they have been self-bootstrapped up until this point and that they are profitable to boot is a testament to Tom's incredible leadership and their absolutely exceptional team.
Tom has made it abundantly clear that he is not against venture capital. He just thinks it is starting off on the wrong foot if you try to build your company with the expectation of relying on venture capital from the start.
So he's taken Github to profitability, and in four years they've all managed to transform the way most of us collaborate online. That is a profound achievement, but those responsible for such a radical change aren't generally the type to sit idly by on the backs of their previous accomplishments.
They want to do bigger and better things with Github. They're not quite done trying to change the world. Now they are not only profitable, but they have substantial capital to invest in further innovations.
With 0 dollars, a couple of guys built something amazing. I can't wait to see what they can do with 100 million.
You do mention this in addition to "proper hashing", so I'm sure you recognize this as well, but I think it is important to emphasize secure hashing practices before any talk of securing your app's login endpoint itself.
A personal example: I fly a few times a year, and I always check my flight status at the specific airline's website. I haven't really looked into other options because I've held a "if it ain't broken, don't fix it" attitude, and it is a simple enough task. But if I were to use an app like this, suddenly I have a huge added incentive to search for my flight statuses on google.
I don't mean to imply that this is a bad thing. To the contrary, I think it is a smart business decision that adds a lot of value to all of the integrated google products for the user. I just found it interesting when I was trying to decide what the "value" was to google for a product like this.
#1: You cannot plan for the unexpected
When you quit your job to start a business, you're planning to lose your existing salary. If you've planned well, your living expenses (food, rent, utilities, etc) are known, so you can plan for them.
You don't plan to get sick or hurt, and even if you did, it would be very difficult, if not impossible, to accurately estimate how much it will cost you to get better. You pay for health insurance to help you pay for the unexpected, so its value is inherently volatile.
#2: You cannot "go back" if the unexpected bites you
If you're looking to start a business, chances are you are highly skilled, personable, and/or ambitious. These are all traits that lend themselves to being abnormally hirable, so if things didn't work out the way you had hoped, you can likely get back into the workforce with a similar salary from when you left. And if that doesn't work out, you still have a better shot than most at a myriad of other job opportunities that at least pay you something worth working for.
If you get sick and you have insufficient health insurance, there are very few ways to get around it. If you were diagnosed with cancer a day after you quit your job, and your current individual provider was unwilling to provide all of the necessary treatment, you're out of luck. That's the ball game. You can't just back out of your startup venture and go back to work to fix the problem.
#3: You can die
Your salary can affect your quality of life, but with personal and societal safety nets, you're not going to die just because you're poor.
The U.S. has no safety net that ensures you will be provided with all of the care you need to not die even from curable or treatable conditions. Medicaid is about the closest thing to such a net, but it doesn't cover every person nor every thing. No personal safety net will help you here either (unless you know a few billionaires that have enough of an interest in you being alive).
This is a huge issue for me as I value my health above all but my family (certainly leaps and bounds above my career aspirations).
I haven't looked very much into this, but I'd be very intrigued to hear how U.S. startup founders address or mitigate the risks associated with health insurance in their early-stage ventures.