HN user

kyle6884

85 karma
Posts4
Comments25
View on HN

NAPA Auto Parts | REMOTE (US/CA) | https://www.napaonline.com/accessories

NAPA Auto Parts is seeking a fully remote Ruby on Rails developer. You’ll be working on a smaller team that is rapidly building a new division within NAPA Auto Parts - think startup inside BigCo. We are seeking someone who will take equal pride in our streamlined workflow, agile development, creative approaches, and entrepreneurial spirit.

This position calls for a self-motivated person capable of independent work (though code review and pairing will happen regularly, you'll be on your own most days). The role involves back-end automation of workflows & data exchanges using various APIs and file formats - JSON, XML, SOAP, EDI, CSV, etc. You’ll also assist in building and enhancing many of our consumer-facing & support system Rails apps.

Tech Stack: Rails, React, Redux, Postgres, Redis, Ubuntu, Gitlab, Chef, Sendgrid, Klaviyo, Twilio, Braintree

Apply here: https://jobs.jobvite.com/careers/gpc/job/oi6Ghfw5

Genuine Parts Company | REMOTE (US/CA) | https://www.napaonline.com/accessories

Genuine Parts Company (NAPA Auto Parts) is seeking a fully remote Ruby on Rails developer. You’ll be working on a smaller team that is rapidly building a new division within NAPA Auto Parts - think startup inside BigCo. We are seeking someone who will take equal pride in our streamlined workflow, agile development, creative approaches, and entrepreneurial spirit.

This position calls for a self-motivated person capable of independent work (though code review and pairing will happen regularly, you'll be on your own most days). The role involves back-end automation of workflows & data exchanges using various APIs and file formats - JSON, XML, SOAP, EDI, CSV, etc. You’ll also assist in building and enhancing many of our consumer-facing & support system Rails apps.

Tech Stack: Rails, React, Redux, Postgres, Redis, Ubuntu, Gitlab, Chef, Sendgrid, Klaviyo, Twilio, Braintree

Apply here: https://jobs.jobvite.com/careers/gpc/job/oi6Ghfw5

This may work nicely for a subscription business where you have 2 weeks to identify problematic orders. But what about everyone else? Should we silently fail on orders where a customer accidentally mistyped their CC#? Imagine all the extra work involved when you could have had them fix it on the spot.

Completely agree with fweespee_ch. Major CC processors such as Authorize.net, Braintree, etc. offer fraud protection measures but in our experience they do very little to prevent even a remotely-capable fraudster. Typical features offered are IP Velocity & regional IP (useless when the fraudsters spin up thousands of amazon servers), # of transactions per hour (not too helpful when your business already does hundreds/thousands of transactions a day), CVV and AVS credit-card response codes (ends up blocking more legitimate orders than fakes and the fraudsters typically already have this information anyway), etc.

you could add an additional URL parameter via pushState and ensure that you're defining the canonical tag only to the main data pages. You could also define the new parameter in webmaster tools and tell googlebot to ignore it

Another Chicagoan here, I'm actually the exact opposite. I'd much rather have my package sitting in the lobby of my apartment than going down to Michigan Ave, dealing with a bunch of tourists, and waiting in line to pick up, idk, a big box of paper towels because I'm too lazy to go to the grocery store?

This. Search for a product in google shopping and multiple merchants will be clustered around one product image that is chosen from 1 of the merchants. That's the main reason, but it also avoids the ugliness of an ebay search where seemingly every other merchant has bright/bold text claiming free gifts or other such offers.

Agreed, if the average-user only knew how prevalent this is. We're an e-commerce site and constantly feel in the minority for not buying links exactly like JCP did. Almost all of our top competitors do the exact same thing and have gotten away with it for as long as I can remember. The only reason we don't is being too afraid of the supposed "wrath" that doesn't ever seem to come to them (that is unless you can get a NYT article written about it).

Not to mention link building via satellite site networks. A competitor of ours has hundreds of keyword-niche sites that link back to their URL but also link to several other legitimate domains on each page. How could Google penalize the domain responsible without penalizing sites that have nothing to do with it?

The Stack Overflow article seems to address the subject of content being scrapped and republished which is certainly a big issue. What about the equally concerning issue of the overwhelming amount of "fluff" content published with the sole purpose of passing anchor text weight back to a domain? Is anyone else noticing an exponential growth of these types of sites recently or is it just me?

Hey moultano, what about specific sites within an industry that abuse big time with doorway pages and link farms? How can we report that to you? IN SERPs these domains are technically relevant to the search-term, but only show up high in the results because of their deceptive practices.