twunde

Assuming that you're not hardcoding anything region-specific, a copy is likely going to be the preferred method since this way you know that the AMIs are the same (ie there's no way that a dependency updated). However there are two complicating factors that may persuade you the other way. Check the cost of cross-region data transfer vs the cost of building your AMI. If your AMI is particularly large, it may make more financial sense to just rebuild the AMI. The other complicating factor is encryption. You _can_ copy an encrypted AMI per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingA..., although perms can be a bit finicky. If you're encrypting something with a region-specific Vault or a HSM, then you'll likely need to rebuild the AMI

Actually, AWS does now support building AMIs and sharing it across an AWS Organization or OU: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-am.... If you're using Packer you want ami_org_arns to share with an org or ami_ou_arns to share with OUs https://www.packer.io/plugins/builders/amazon/ebs#ami_org_ar....

You do still need to create separate AMIs per region though

Don't forget the cases where the companies are deliberately lying to customers. I worked at a company that pretty much lied to its customer's security teams about what they did. Not borderline, but claimed things they didn't do and didn't have plans to implement. This is what the SOC2 audit is for.

I feel sympathetic but anyone that hasn't started prepping for layoffs is simply not reading the writing on the wall, _especially_ at Twitter. Elon Musk has basically said that he wants people working 40+ hours/week in the office or you can quit to Tesla and SpaceX. There have been stories for weeks about large startups having layoffs. Finally, most acquisitions tend to end in layoffs

Minimum, you should be updating your resume/LinkedIn, and you should also look at ways to cut back on costs where possible.

I'm sorry, Twitter assured the company that there would be no layoffs? Isn't that _exactly_ what Elon Musk has been telegraphing with what he's said to the press and at the town hall? Also at this point

Well this sent me down a tangent since I had never heard of this. Per https://www.cga.ct.gov/2001/rpt/2001-R-0858.htm (circa 2001) the only states that require a fingerprint are California, Colorado, Georgia, Texas although apparently Alabama and Florida used to do so. Feels pretty crazy to me

In general APM/observability tools are expensive. The good news is that there are a lot of choices including open source tooling like opentelemetry, sentry, vector.

You can reduce the cost somewhat by sampling traces, and by only shipping logs of Info or above (ie remove debug logs)

The issue with browser extensions is that the main way to monetize them is to steal data or inject adware/malware[1]. The extensions themselves request a lot of permissions, there's minimal security scanning (the only one I know of is https://crxcavator.io/) and often people with successful browser extensions end up selling them to someone who then modifies them to be malicious[2], which means even trustworthy extensions may become malicious at any point. That said, no ublock is not the only safe add-on. The ones you mentioned are safe, but there's probably not enough people asking security/IT about them. What might be an effective approach to get your preferred extensions added to the allowlist is to request the process to add new extensions to that list, and to point them to the risk scores in https://crxcavator.io/

[1] https://www.tomsguide.com/news/28-bad-browser-extensions

[2] https://www.labnol.org/internet/sold-chrome-extension/28377/

This is normal. Senior engineers are productive fairly quickly and can work independently without much or any oversight. Contrast that with junior engineers. They take longer to become productive and even worse require a lot of oversight and training/mentoring from your senior employees meaning that you're dragging down the productivity of your existing employees. Typically you need several senior hires per junior employee. Long-term you should have both, which is why bigger companies invest in training programs, where they hire new grads/bootcamp grads at specific time frames. As an industry we do need to work on how to make junior engineers effective faster.

At a previous company we hired a fair number of bootcamp graduates for our size and we were happy with them. There are a few things that will definitely help improve the experience if you want to hire them.

1. Like all junior engineers they will need help. Make sure that there are multiple senior engineers that are both able and willing to provide guidance.

2. Try to hire from bootcamps that use the same tools that you do. If they've learned javascript and ruby on rails, and you're a python shop start them on javascript work for the first few months. If you're not aligned on the tools you're going to have a bad time.

3. If this is the first junior hire or first bootcamp hire, consider trying to find a bootcamp grad that's been out for a year or so. Ie look for one trying to get their second job in the industry. This will reduce the amount of handholding that you should need to do.

4. Have standardized technical questions or exercises. This will help you find the ones that have really learned their technical skills.

5. Not all bootcamps are equal. When you find one that's producing good candidates, its worthwhile to try and partner with that bootcamp.

Eventually if you continue hiring bootcamp guides you'll end up with a strong learning path for them.

I like to compare bootcamp grads to straight out of college hires. The former are going to be familiar with a set of tools that you're hopefully using including git. They will NOT have a strong background in theory. This contrasts with new grads who have the strong theory, but may not be able to use git and probably don't know the framework you're using. Depending on what you're hiring for, one will make more sense than the other.

Their self-hosted version works well with the caveat that the upgrade process can be a pain and can be buggy. I used their docker-compose open source version which involved downtime to spin down the stack, then spin up the new stack. Considering that there's no enterprise support for on-prem, its nice that it works so well. If you're using their apm/observability you will need to keep an eye out on disk space and memory/cpu after turning it on, we ran into resources issues due to the amount of data we started sending. Otherwise it's rock solid and cost-efficient, we were paying 500ish bucks a month for infra and 1-2 days of dev time for something sentry.io quoted 50,000K/month for. I imagine the kubernetes installer is much less hands on in terms of upgrades. Would use again without any hesitation.

Let's talk about the COBOL job market since I think what you're really asking is whether you can have a stable career writing COBOL. Contrary to the annual articles we see decrying the lack of COBOL programmers and suggesting that becoming a COBOL programmer is a way to get a high salary easily, the actual job market for COBOL programmers is quite different from those of the rest of the software engineering industry. In aggregate, across the United States there are a number of large companies that still use COBOL such as Eversource or Labcorp. Unfortunately, the teams using COBOL typically aren't growing. They may hire 1-2 COBOL programmers a year. This means that outside of a few banking hubs like NYC, you may need to move for your job if they require you on-site. A number of these companies have also outsourced their COBOL jobs and gotten used to paying low salaries for hires. This means that there's a large dichotomy in salary, some pay very little (I think an ex-colleague with 15+ years experience was offered 35/hr) and some are in the 100K+ range. A good example of this is searching indeed for COBOL jobs (https://www.indeed.com/jobs?q=cobol&l=&from=searchOnHP&vjk=f...). There are less than 2000 jobs on indeed across the US, and while the median range looks to be around 100K, many pay very a lot less. As far as I can tell nobody is making anywhere close to FAANG money with COBOL. Take a look at the locations of these jobs as well. If you want to find a job within 50 miles of you, there may only be a few options. Anecdotally, my ex-coworker hasn't worked in COBOL in the last 8 years, maybe even longer.

Now let's talk about a few of the positives. Many of these jobs are relatively stable, especially the government ones. They may also be relatively low-stress and be close to the traditional 9-5. Being paid 100K+ in Albany, NY is good money for the area, potentially on par with being paid 200k+ in SF. Unlike javascript, you won't need to keep investing in learning new frameworks every 1-2 years.

Many colleges/universities have career offices that offer services for alumni switching careers. It's at least worth reaching out and seeing if they can help set up informational interviews if nothing else. If your wife went to grad school for her educational license, it's also worth reaching out to them as well. Other avenues to explore are to talk to members of your church/synagogue/whatever if you belong to one, and/or talk to parents of former students.

Other ideas: - Potentially sell curriculums, etc on teacherspayteachers or alternatives - Apply for jobs with education-industry companies like Scholastic, ed-tech companies

Best of luck!

It's still relatively common to have to swipe cards at gas stations in the US when you're buying gas. And a fair amount of the parking meters may still be on swipe (NYC meters outside of Manhattan come to mind). The places that haven't upgraded are ones with a lot of POS stations to upgrade.

Strictly speaking, having passwords in plaintext is legal but not secure since the HIPAA Security Rule is about protecting PHI. It's also possible that the passwords in their system aren't in plaintext, but customer service has to change the password and they need some way to send you the password. It sucks.

So how do get the company to change this? Your best bet is to contact the executive(s) in charge of compliance and security about this (you'll likely need to do some Googling and/or LinkedIn stalking).

The argument that you want to present to them is that the HIPAA Security Rule requires that a covered entity `Identify and protect against reasonably anticipated threats to the security or integrity of the information` and that in this day and age having passwords in plain text is a reasonably anticipated threat.

Reference: https://www.hhs.gov/hipaa/for-professionals/security/laws-re...

It wasn't clear from the context whether you wanted to mitigate throttled delivery or off-hours delivery. If its the former I responded below to ShrigmaMale. If its the latter, consult your legal team but you'll likely need to ensure that you're marked as type transactional. I wouldn't be surprised if you needed some specific language in your opt-ins. There's clearly a distinction between seamless sending you a text off hours because of an action you did, and say Geico sending a transactional SMS saying your new ID cards are ready.

For time-sensitive SMS, one solution is to have basically a fast queue and a normal speed queue. Essentially have a phone number (or numbers) that are reserved for the fast SMS and only use it for time-sensitive requests like OTP. Everything else goes through a normal speed phone number. Alternatively, if all your SMS messages are time-sensitive, you'll likely want to use several phone numbers and try to load balance requests so that the queue size for each phone number is always small/at or near 0.

There's also an outside chance that your SMS provider may have an option to pay for faster delivery like email providers do. I don't recall seeing that option, but I have to imagine that at least one provider has this.

Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue.

Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case.

With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).

The reason this doesn't work is because of the pressure phone carriers have gotten about reducing the amount of spam phone calls and SMS (from Congress, state governments and regulatory bodies like the FCC). These arbitrary filters on consumer level plans are typically about blocking spam from spoofed numbers and non-compliant businesses. If you think about it, its EXACTLY how email works today. You _can_ try to send millions of emails per a second from your gmail account, but a) your emails will likely be caught by spam filters due to the high volume and b)gmail will notice suspicious activity and shut your account down.

From someone who's done a fair amount of SMS sending here are some things to think about.

- You'll need TCPA compliant opt-ins for US sending. There's a cottage industry of people who look for vendors that aren't compliant and sue them. The fines range from $500-1500 a SMS or call. Sounds like you've already gotten that covered, but definitely go over the requirements with a lawyer that specializes in it.

- SMS is throttled per a phone number. This is throttled at both the provider and the carrier. That means that even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending.

- SMS is pricier than email and even at the highest volumes has a relatively high floor per a text. I think the floor might be $0.004X-$0.005. This is offset by having better response rates that email. And as others have mentioned the providers will give you better pricing as your volumes go up, but you'll need to talk to account reps about that.

- At a certain size (1M+/month?), you can also consider integrating directly with the carriers, although that's a longer process to get set up.

- You'll need to manage SMS bounce/spam rates like you would for email bounce spam rates. You'll end up maintaining a block list of known bad phone numbers

Edited for formatting

As others have mentioned design docs/BRDs, etc generally fell by the wayside with the rise of agile, especially in smaller companies and startups (colleagues from those environments may never have seen a real design document and possibly never had to document anything). However, over the last few years, I've seen many companies moving towards at least light-weight design documentation typically using ADRs https://adr.github.io/ and/or RFCs (https://github.com/rust-lang/rfcs). This is often because without these types of documents, its harder to grow teams as new members must either be taught be a senior member or learn from the codebase, both of which are slow.

As a secondary note, regulated companies may have architecture/network diagrams and disaster recovery plans but these may be located with the compliance documents and not in the general document store that engineers use.

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or not at all. Documentation if it ever existed is likely lost. What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises

If the company is in healthcare or finance, yes. Otherwise the typical answer is no. Most companies just load up on cyber insurance and call it a day. That said, reputational concern, is a big thing for companies. Take Dropbox for example. Early on they suffered several security breaches, and had a bad reputation around security. They've since built out a fairly large security program, in part because bad security can block deals, especially in the enterprise space.

I'll note that there's been more investment in security the last 4-5 years. Most B2B companies do a SOC2, and early on, so there tends to be a baseline of competence.

Basically PDM supports project-specific python package installs. This is different from how python has traditionally worked where it has installed globally for the user running it. Why is this important? Because with virtual environments it's easy to forget to activate a virtual environment and run a pip install or upgrade and clobber your computer or server's python environment. It also avoids the confusing issue where someone updates their PATH variable while in a venv, but then its no longer there after exiting the virtual environment.

If you are in a regulated environment, it's likely because of either compliance or security concerns (I'll note that while Slack has HIPAA-compliant plastered over its website, the last time I checked only the Slack Enterprise was actually HIPAA-compliant).

The reason why the focus was on the first one is because that was the easiest and fastest to do (You only need local officials to sign off on it because its a temporary order and its also the simplest). 2 and 3 need the federal government to organize it, which as a large organization takes some time. 4 and 5 requires figuring out contract terms (who's paying whom, etc). These are much more complex and therefore will take more time. Oh and the tweetstorm was done on a Friday on the West Coast, so it takes some time to get the attention of decision makers on the east coast.

While it can be put into a work contract, its never been in any contract of mine (I assume it is in contracts for union employees and for some executives). Many states do require that companies above a certain number of employees have to give notice, usually called WARN acts (and it looks like Oregon's requires 60 days notice according to https://www.oregon.gov/highered/institutions-programs/workfo...). Employees do need to pay out any unpaid holiday or sick time (which is why unlimited vacation is bad, since you don't get cashed out).

Normally when you get severance, it's in exchange for liability from lawsuits and to prevent bad press and sharing of trade secrets. What this does is make it much harder to sell Treehouse since there's now a fair amount of liability attached.

For anyone who wants to learn what a good authorization system looks like take a look at Tailscale's recent blog post: https://tailscale.com/blog/rbac-like-it-was-meant-to-be/

Really, if you're going to be selling to enterprise clients, you want an attribute-based authorization system. If you need help designing it, talk to your IT/Devops/SRE teams, they'll be able to complain about bad auth systems and what they'd want in an ideal world.

I haven't used Five9 for about 5 years, but even then their tech seemed old. The new thing then was starting to add multi/omni-channel support ie adding chat and maybe email. My guess is that the integration will likely be adding a new video chat option for call centers (ie five9 would do the queuing and then the routing to Zoom). I'd highly doubt that Zoom would spend the time to fully combine the software.

Lastweekinaws just published an article about whether you should get a certificate: https://www.lastweekinaws.com/blog/is-aws-certification-wort...

While this is focused on AWS, the same holds true for Azure and GCE.

And I'll note that if you're at the point where you're getting the expert-level certs, those do stand out and are trusted by hiring managers across the industry.

To be fair about this page, this was used to migrate versions of postgres __prior__ to the introduction of logical replication. Logical replication makes this significantly easier (ie you no longer need the triggers)