Hacker Newsnew | past | comments | ask | show | jobs | submit | shawncampbell's commentslogin

Location: USA (currently splitting time in CO and MD)

Remote: Yes

Willing to relocate: Yes

Technologies: JavaScript, PHP, SQL, HTML, CSS, jQuery, Vue, Node.js, Liquid; PostgreSQL, MySQL, MongoDB; REST APIs, Postman, Swagger; Linux, macOS, Cloudflare, DigitalOcean; Git; Agile, Lean; Jira, Slack; Adobe Suite (Photoshop, Illustrator, etc.); WordPress, WooCommerce, Shopify; Google Analytics, Klaviyo, Mailchimp/Mandrill; many more.

Résumé/CV: https://docs.google.com/document/d/18vMEQyPgNusqCiWQYsRc5eJs...

Email: talktoshawn@gmail.com

Summary: Looking to join a product-oriented team as a PM. I have over 15 years of experience in leading cross-functional teams to develop and optimize digital platforms. Known for a data-driven approach to product development, strong communication skills, and the ability to align business objectives with user needs. Proven track record in managing complex projects, driving customer-focused solutions, and facilitating collaboration between technical and non-technical teams. Exploring full-time or part-time options, W2 or 1099.


ETC. Time, etcetera. I like that. There's something poetic about it.


As of Dec 12, 2023 at 04:42 PM (eastern?) the Status Page now reports "Merchants may encounter error messages when operating store admin — What happened? Some merchants may experience errors when trying to access/operate the Shopify admin. We are investigating and will keep you updated."


Nothing reported on the status page at this time. Frontend stores seem to be up, but the Admin seems to be down for all stores. Even partners.shopify.com is returning an nginx 504 Gateway Time-out.


"The issue has been identified and a fix is being implemented." (Nov 30, 2023 - 17:28 UTC)


I'm unable to log into the Cloudflare Dashboard. I receive a 524 error during the 2FA step.


I was able to log in around 17:45 UTC


The 1 in 3-2-1 would ensure you have a copy offsite as well.

https://www.uschamber.com/co/run/technology/3-2-1-backup-rul...


How far offsite? Like, across the street? In another town? Out of state?

Does a small-town newspaper expect to be raided by law enforcement and build a disaster recovery plan around that, or a tornado?

They don't call it "The Long Arm of the Law" for no reason.


One would have to think about it and investigate. Say, they might confiscate your laptop with thunderbird and your mail archive but they probably wont delete your webmail account or forbid you from using it. At least I imagine if the point is to gather information it doesn't include deleting it or taking control of it? If they really want to delete your things I imagine one could create an append only webservice.

Preserving some things (without hiding anything) is better than nothing.


Well, if your attack vector is local law enforcement, then in a different jurisdiction would be a good start. Working your way further and further toward whatever makes it most annoying for them to get to.


I recommend to parties I work with that are at risk from these sorts of events to keep their BCDR (business continuity disaster recovery) data corpus at risk in European datacenters owned by European companies. Can be as simple as rsyncs or blob storage backups, or active infra always running, depending on budget and organizational needs and maturity.


> on August 8th, our Security Operations team was made aware of a customer who claimed their password had been reset, without their initiation.

> One of the first discoveries was a non-DigitalOcean email address that appeared on a regular email from Mailchimp on August 7th.

> Soon after we discovered an issue with our Mailchimp account on August 8th, we initiated contact with Mailchimp, both via traditional support channels and other escalation methods. On August 10th, we had our first actionable response


> both via traditional support channels and other escalation methods

I wish our industry could just be honest that many meaningful escalations have to happen via discriminatory back-channeling, contacting friends, family, former co-workers, ANYONE who might have an in with the organization.

Its discriminatory because if you don't know someone you can be SOL.


Mailchimp/Mandrill have specially bad customer support and business user experience. At one point they closed the account of a company I was working at without any previous notice and without any recourse. They just sent a blanket email "Your account has been suspended". They left us scrambling for an alternative (we had both transactional and marketing email). We happily migrated to SES for transactional email and SendGrid for marketing.

I no longer recommend or use Mailchimp.


My issue with SES is that your account may be placed in a Sandbox with no explanation other than to delete your account.


This is because of fraud. Everyone either does this, or enables the fraudsters. The only third option is to get rid of email, except the fraudsters would just move on to the next thing.

Assume that you’ll have availability problems with email and engineer with that in mind.


Claiming that you either need to ban users without recurse or suffer from enabling fraudsters is why people start feeling like corporations don't have any human employees anymore. If you care about your customers, you could absolutely reach out and verify if the user you are about to/have blocked is a fraudster or not, and then act accordingly.

The reason most just say "You're banned, bye" is because they don't want to do that work, and subsequently don't care about their users one bit.


They ban thousands of accounts per day. Every day. If you can solve this problem you will have discovered a license to print money, so by all means try. But the problem is much harder than you are making it sound.


On the other hand, how many do you think would reach out when they get blocked? Most actual fraudsters wouldn't. Of those that do, you can take a look at what they are sending and quickly see if they are actually doing fraud or not.

I could say the same thing to you, you're making it sound harder than what it is. But if you're set to the mindset of saving money, I understand minimising work makes sense.


> Most actual fraudsters wouldn't.

Of course they do. It’s just email/twitter/telegram/WhatsApp, and fraudsters are literally professional messaging automators. They open support cases, email execs, I have seen cases of them paying call center workers to call support lines and complain. Fraud is a serious business run by serious people, many of whom have a decade plus of experience.

You cannot attempt to stop fraud with manual effort if you operate at any kind of scale. Full stop.


  > Assume that you’ll have availability problems with email and engineer with that in mind.
That goes for all dependencies, not just email. And not just third-party dependencies either.

If PyStorm died today, I could carry on in VIM. I could rebuild my entire architecture on DO if AWS sours. If git takes a dump, I have four machines from which I could copy the code and migrate to e.g. mercurial. And if I get hit by a bus, my code is well documented and testable.


> Its discriminatory because if you don't know someone you can be SOL.

Thanks for explicitly explaining that part. Now that you've put it that way, it's a pretty apt term but I probably wouldn't have been able to figure out because that term is usually used for things like gender, race, etc. and my brain immediately jumped to that. Maybe I am just stupid, but sometimes it shouldn't be that hard to understand what people mean and it helps to be more explicit.


Good opportunity to talk about it. An awful lot of people are extremely solitary. I’d wager this is more of a problem than racial discrimination because:

- Lonely people aren’t visible, by definition,

- Solitude increases racism, so it would be worth solving,

- They often end up creating companies and being one’s boss.


Related discussion from time of presumed incident 4 months ago

https://news.ycombinator.com/item?id=30914492


From the status page:

> As of approximately 23:40 UTC, our Engineering team is investigating multiple failures with DigitalOcean services, including our Cloud Control Panel, API, events such as creation of all resources, and WWW endpoints failing to resolve. We are starting to see recovery but are still investigating root cause and users may continue to experience elevated errors. We will post another update as soon as further information is available.

Some of our DigitalOcean resources (including the DO dashboard) were unavailable for approximately 10 minutes, though everything seems to be fully operational now.


We appear to be down again.


And we're back about 5 minutes later.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: