dschwartz88

For people interested in this topic/catching visual regressions take a look at Kontrast

https://github.com/harrystech/kontrast

For anyone interested, Eater did a great job profiling them and their factory [1]. Sun Noodle pretty much owns the entire NYC ramen scene (with the notable exception of Ippudo). They also sell their noodles & kits at Whole Foods and Japanese grocery stores.

[1] http://www.eater.com/2014/7/22/6184305/inside-sun-noodle-the...

I can't wait until there are Sinatra and Rails equivalents for Swift (once they open source the Linux bindings later this year).

Just a heads up, the 90 day out clauses are usually put in there by the company lawyers. The only rule the IRS has is that ISO options flip to NSO after 90 days[0].

Take a look at the Pinterest options plan[1], where Pinterest actually gives you 7 years from when you leave to exercise. Your ISO options just flip to NSO after 90 days.

[0] http://www.mystockoptions.com/faq/index.cfm/catID/36274DB1-D... [1] http://fortune.com/2015/03/23/pinterest-employee-taxes/

This isn't surprising news.

Isn't this one of Apple's main goals in their Activity app (w/ the Apple Watch)? To get around and move for a couple minutes each hour at least 12 times a day? Lots of other fitness bands have done this as well (Jawbone Up comes to mind).

This is an awful oversimplification, but in my experience, there are two different kinds of applications:

- User-centeric (think: an e-commerce site): your costs are going to grow somewhat linearly with your userbase/traffic. Do a load test to figure out how many concurrent users each dyno supports and then model your costs with that in mind.

- Data-centric (think: an analytics platform): your costs are to going to grow linearly with the amount of data points each customer is going to be using. Figure out how many data points a single worker dyno (running 24x7) can process and then model your costs with that in mind.

I realize that this took a huge amount of time, so asking for an open source version of this might be asking a bit much. But, I would absolutely be willing to pay for a SaaS product, or a licensing fee for the code. It's absolutely beautiful, and as someone who does this in a gross spreadsheet, moving to something like this would be unbelievable.

It's been proven these arbitrary restrictions don't actually enhance security. We need to see the TSA move to behavioral analysis for them to actually make a difference.

While I haven't personally used seed-fu, it seems to solve a different problem. There are two main problems we're trying to solve here:

- Having the seeds.rb file mirror the records you need from production. You wouldn't want to to register your User model, since you don't want all your production users. You would want to register a model like Product.

- Being able to easily migrate data on our production systems. Being able to easily migrate (and rollback if something goes wrong) is key to having predictable deploys (for us at least).

It's key to migrate seeds on a "clean" database. Any models you register will be exported from the database into the seeds file, so we usually rake db:reset before running rake seed:migrate on development systems. We actually built this gem almost a year into our current system, so our first bootstrap of this loaded all the records from our production database for the models we needed (products, shipping types, etc.), which gave us a clean seeds file to use on development and test systems.

Another one of the engineers here. While using ActiveRecord migrations will work for production systems, when setting up development or test systems using rake db:schema:load will not actually insert those records. Since rake db:schema:load is simply loading the current schema from schema.rb, you will still have to add those records into seeds.

This seems to be mostly their CDN bill. Not sure, but I don't really consider a CDN as part of hosting fees, more of a general infrastructure fee.

We've been on CircleCI for months now and in addition to being an absolutely fabulous product the support has been astounding. Congrats guys, well deserved.

We have three layers of testing in our suite. Ill go from the bottom up (we happen to be a rails shop so use rspec + Capybara):

1. Model Tests: These are used to validate base business logic. This is for things like totaling up order values, making sure discounts are applying correctly, and making sure taxes are being correctly applied. These in my opinion are the tests you must have. If you're not validating your base business logic theres no way to prove your other testing suites are doing their job. These are done for both Ruby code (rspec) and Javascript code (using Jasmine)

2. Controller/API Tests: These are to validate that different parts of the business logic working together actually do what is intended. When a user places an order lots of things must happen (I need to charge them, I need to send them an email, etc.). These are done in rspec and are a nice way of validating things in an orchestration style API (vs. a REST style API).

3. Selenium/Acceptance Testing: These are super important. These actually automate what a real user is going to be doing on your site. We test both Admin and normal user flows. These are the easiest to write and give some of the biggest wins. These will catch bugs your users are actually going to encounter. Having model and controller tests for something like checkout are necessary but they must be augmented with acceptance tests or else you can't be sure something else isn't holding up your user from checking out.

Our entire test suite runs on CircleCI (love those guys) but could technically be run on almost any platform (we ran Jenkins for a bit too). Hope this helps. Feel free to ask any questions!

Harry's (http://www.harrys.com). Fulltime or Intern. New York City. A bit about us:

We built Harry’s with one simple belief: everyone deserves a great shave at a fair price. As such, we seek to provide our own brand of exceptional shaving products direct to our customers online. We launched on March 13th and have been humbled and flattered by the early customer response, and we're now looking to bring on more talented engineers to help make every one of our customers happy and change the world, one 5-o'clock shadow at a time.

We're looking for outstanding full stack engineers and data engineers who want to solve thorny e-commerce problems in {customer marketing, web performance, customer experience/support, operations, supply chain management} in innovative ways.

Technologies: our web site is built on Rails, we're hosted on Heroku, our data is stored in Postgres, and we write a lot of Python to consolidate data from various sources and analyze it.

For the full stack engineer who thrives on shipping features in the face of complex problems and processes: Our custom e-commerce platform powers the entire business, from the HTML on our homepage all the way down to our supply chain. We’ve got fun problems to work out every day, at every level of the stack, all with the hope to make purchasing and shaving with us the best experience out there. We’re looking for someone genuinely excited by the opportunity to make millions of peoples lives easier and build the Harry’s platform of tomorrow. Your primary responsibilities will include:

* Architect and implement core features of the production website

* Build infrastructure to support various external features and other units of the business

* Think about performance all the time, and proactively make changes to make our platform better

* Determine ways to operate more efficiently (e.g. optimizing our inventory and shipping algorithms)

For the statistically inclined engineer who communicates with data and hacks on data problems:

Data plays an integral role at Harry's, informing every facet of our business. We are constantly working to understand the behaviors of tens of thousands of customers, tailoring offerings to them so that we can make them happy and drive continued demand. To that end, we're looking for a statistically-inclined software engineer who is well-versed in building data systems and wants to use data to inform decisions at Harry's in a forward-thinking way. Your primary responsibilities will include:

* Build infrastructure to automate data collection, storage, processing, and presentation.

* Instrument our website and marketing communications to gather the data we need.

* Test changes we make to our site, emails, packaging, shipping options, -- everything, really -- relentlessly.

* Produce, analyze, and present data to users in a context that allows them to make meaningful strategic decisions.

* Use your sheer intellectual horsepower to figure out and communicate how to better delight our customers.

If interested, email jobs@harrys.com with why you're interested and relevant links (e.g. Github, projects, LinkedIn).

They go on my GitHub. Most as public, some as private. The only ones that stay private are the ones that have some code I worked on for weeks solving a very specific problem that I may use at some point in the future for a business.

Harry's (http://www.harrys.com). Fulltime or Intern. New York City.

A bit about us:

We built Harry’s with one simple belief: everyone deserves a great shave at a fair price. As such, we seek to provide our own brand of exceptional shaving products direct to our customers online. We launched on March 13th and have been humbled and flattered by the early customer response, and we're now looking to bring on more talented engineers to help make every one of our customers happy and change the world, one 5-o'clock shadow at a time.

We're looking for outstanding full stack engineers and data engineers who want to solve thorny e-commerce problems in {customer marketing, web performance, customer experience/support, operations, supply chain management} in innovative ways.

Technologies: our web site is built on Rails, we're hosted on Heroku, our data is stored in Postgres, and we write a lot of Python to consolidate data from various sources and analyze it.

For the full stack engineer who thrives on shipping features in the face of complex problems and processes: Our custom e-commerce platform powers the entire business, from the HTML on our homepage all the way down to our supply chain. We’ve got fun problems to work out every day, at every level of the stack, all with the hope to make purchasing and shaving with us the best experience out there. We’re looking for someone genuinely excited by the opportunity to make millions of peoples lives easier and build the Harry’s platform of tomorrow. Your primary responsibilities will include:

* Architect and implement core features of the production website

* Build infrastructure to support various external features and other units of the business

* Think about performance all the time, and proactively make changes to make our platform better

* Determine ways to operate more efficiently (e.g. optimizing our inventory and shipping algorithms)

For the statistically inclined engineer who communicates with data and hacks on data problems:

Data plays an integral role at Harry's, informing every facet of our business. We are constantly working to understand the behaviors of tens of thousands of customers, tailoring offerings to them so that we can make them happy and drive continued demand. To that end, we're looking for a statistically-inclined software engineer who is well-versed in building data systems and wants to use data to inform decisions at Harry's in a forward-thinking way. Your primary responsibilities will include:

* Build infrastructure to automate data collection, storage, processing, and presentation.

* Instrument our website and marketing communications to gather the data we need.

* Test changes we make to our site, emails, packaging, shipping options, -- everything, really -- relentlessly.

* Produce, analyze, and present data to users in a context that allows them to make meaningful strategic decisions.

* Use your sheer intellectual horsepower to figure out and communicate how to better delight our customers.

If interested, email jobs@harrys.com with why you're interested and relevant links (e.g. Github, projects, LinkedIn).

First off awesome little util.

One Issue: I get an "invalid multibyte char (US-ASCII) (SyntaxError)" on a pretty standard OSX install. May want to think about looking for support for char and replacing with something like "-" for the lines. Once I changed that in source.rb everything worked great.

I'm definitely not a wine "connoisseur" by any means, and don't think cost has much of anything to do with the quality of the wine. I've had some amazing cheap wine, and awful expensive wine. However, to me this article misses the point. The more interesting question to me would be: Can these judges continually figure out if a wine is "bad" or "good". Give them the same two wines over and over again, one being "bad" (Franzia) and another being "good" (Some agreed upon California cab or similar) and see what shakes out. I'd be very surprised if any of the judges couldn't figure out which was worse than the other.

I can see this being unbelievably awesome for the creatives here. People who use FCP or have large PSD/AI Files, now have a portable drive that's just as good as an internal drive.

No. Freaking. Way. I noticed this same exact issue pop up on my New Relic interface. Multiple times a day our app would get H13's, crash, and then restart. Have been trying to get to the bottom of this ever since. Awesome detective work on this. Our app (and tech team) thank you very much!

I think the main issue with this is the status page. It should be hosted off their normal infrastructure, Heroku went through this a year or two ago if I recall correctly. I don't mind downtime with a PaaS (within reason), it's having zero visibility into the problems, what exactly they are doing to remedy them, and what the ETA for the fixes are.

Mailbox and this solve completely different problems. I love Mailbox because it creates the notion that "read" does not mean done (and I can ask it to remind me about stuff). It also makes my email my todo app, which is nice since I only have to have one app. This is a really powerful change to the way i've used email and has made me more way more productive and organized.

SquareOne looks really interesting, and I think it and Mailbox could complement each other, but to me SquareOne is super smart filters for mail, while Mailbox changes the way I use email in its base form.

I sincerely hope not. I think the problem is the way the App Store makes companies race to the bottom in price. Why can't they charge me (and the other 1M users on the waitlist) $1 a month as a subscription fee? I realize things will not even out completely (not all 1M users would pay $1/month), but I really do think it would be enough to sustain a true business. When these companies get bought their true feature set (and thus user base) dies out. Just look at what happened to Sparrow...

Listen I get it. Everyone has their own coding style and what makes it easier for them to read. But, am I really the only one that likes curly braces and semicolons here?

I ran into a lot of these issue (especially onScroll vs. requestAnimationFrame) while creating a Path style scrollbar menu. It's amazing the performance gains you get when you start to model things like a game (animation loop vs event driven animations). Take a gander at the source for all the optimizations I did: https://github.com/Jetsetter/PathScrollbarMenu

Am I the only who is crazy surprised this still happens? New startups have absolutely no excuse since every framework/language has some helpers for users and passwords. Old companies have no excuse because its trivially easy to upgrade users passwords to the new encrypted format.

Good design/product by definition (for the web at least) is the melding of fantastic graphic design with the needs of your business and users. These are not mutually exclusive pieces, they all have an effect on your bottom line. His statement seems very short sighted to me.

Considering the current numbering scheme, 0.9 will be the unstable version of 1.0. Which means 0.9 should give us a very good idea of the final backwards compatible API (hopefully)