In the early days (2013-14?) of Stripe, I was responsible for maintaining my company's integration.
I still remember how one day there was a message on the announcements newsgroup about how the size of a key was increasing, only three or four days before the we'd start seeing the change in API responses. Dealing with this needed a database migration that I would need more time to schedule, and I sent back a polite-but-direct response to the generic posting email expressing my disappointment with how little notice we received.
A couple minutes later a Google Chat bubble pops up from some guy named gdb (aka Greg Brockman), who I subsequently learned was Stripe's CTO. He apologized, asked why the timeline was tough for me, and when I explained it, immediately set something on my account so that the migration would be delayed by a couple weeks.
8 years later I remain impressed by that level of customer connection from a senior executive, and the technical excellence that allowed them to special-case delay my migration.
This is also being done[1] in Canada, in a project that started as a way to use the byproducts of the normal milk-making process in a way that didn't cost farmers anything.
I've had better experiences with DataGrip, but if I wasn't at a place that would pay for proper tools, DBeaver is an OK substitute. Neither, though, have the big thing I want in an analytical SQL workspace:
Simple charts
A whole lot of my work ends up with a three- or four-column table with one column of buckets, and the other being counts of how many things ended up in that bucket. I'd love a view where I could render that into a line or bar chart as a sanity check, and have it update in real-time as I change my query. Instead, I end up having to constantly copy/paste into Excel and do it there.
Yes, I should be using a proper BI or visualization tool for real reports. But sometimes I just need a quick line chart to show that yes, that one count is going in the right direction.
>> the campaign should have people in charge of security
OK, but most don't.
Money is a very limited resource in campaigns, and almost all campaign managers will choose to spend it on direct mail and ads over hiring someone for IT security. Their thinking will go "this organization is only around for a year or two, and if we don't win then it won't matter what our IT issues were", and their colleagues in the world of professional campaigning will agree with them. If we're lucky - and I hope we are - the DNC/RNC will have a hotline and national support team for IT security that campaigns can call, but it'll get swamped fast.
Local campaigns don't do enterprise IT. Local campaigns buy G Suite and some old laptops, and leave them sitting around campaign offices in which plenty of not-well-known people come and go. They'll likely be administered by either a contractor hired to set up the offices, or by a friend of one of the early paid employees who "knows computers". While simple changes that individual users can do aren't as through as what you get with a proper security administrator, they're much more likely to get done.
If you're a local[0] campaign and a nation-state actor wants to attack you, they'll probably be successful - but anything you can do to tilt the odds in your favor (like this guide) will help.
[0] Senate campaigns will generally have a small IT team who can do most of the enterprise-level management things mentioned. National campaigns will have a well-staffed IT team to do all this and more.
I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter.
Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets.
When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA:
* Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing.
* Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options.
* Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted.
In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.
Remember that you're not a developer anymore, and that the way you contribute to the team isn't coding. You're moving from a role that focuses on concrete contributions, to a role that focuses on creating leverage so that others can contribute better.
Your job now is to manage the state of the projects you're working on, and enable the developers on your teams. If you're coding, you're almost certainly not doing that to the degree you could be. The new job will be difficult. Change is hard, new skills are hard, and there are days you'll want to just go code something because it's easier to do and more fun.
Don't do it.
Your priorities are enabling your team and making sure that everyone knows and is on board with the state of your projects. In your new job, the way you succeed isn't by putting out code - it's by your projects and teams succeeding.
Make sure you like the sound of these priorities; if you don't, you should probably reconsider the change of roles.
Lastly, make sure that you understand what you're accountable and responsible for. Project managers don't (by default) have people responsibility, but at your company they might. Same question about doing product ownership, agile coaching, tactical team leadership, reporting, etc.
If you end up using CloudFormation, don't write the JSON directly. Your programming language of choice should have a wrapper that maps objects to CloudFormation JSON - do your thinking there, use all the features your language offers, and consider the JSON you dump out at the end as an artifact you deploy (which happens to be readable). For Python, this is https://github.com/cloudtools/troposphere - I can't vouch for how accurate other languages' versions are, but I've never had a case where Troposphere didn't generate the right JSON for what I asked it to do.
CloudFormation is also nice in that it has access to a few API features which Terraform doesn't - specifically wait-conditions, automatically rolling-back updates when there's a problem, and a lot of the magic around UpdatePolicy/rolling deploys (although that doesn't work the way one would expect - a story for another day).
Having said that, Troposphere is pleasantly readable and has nice docs. The cross-platform integrations (for example, CloudFlare) add to the "just works" feeling. Some things are a pain to do in Terraform due to its strictness around being declarative and not having conditionals (e.g. having production and development environments that are similar, but not exactly the same), but there are some well-known hacks around them.
It also takes a very strong position around failed updates: it'll stop mid-change, tell you something's broken, and have you fix it. In the same situation, CloudFormation would roll back the changes to the state you were in before you started. Which one of those two failure modes you prefer is up to you. There are also some issues around having passwords and the like in your statefiles when you use RDS. You can avoid this if you go whole-hog into the HashiCorp stack (TF + Vault + Consul + etc.), but it's bugged me.
Lastly, If you're going to build something big and complex in TF, I suggest you do some reading of Charity Majors' rants on TF (https://charity.wtf/tag/terraform/). She has probably already run into the problem you're going to have.
So which would I use? Depends. If I want to create the same environment in a bunch of places (which also includes blue/green deploys), TF. If I want to do more complex things than that, CloudFormation.
We use https://github.com/atward/aws-profile/blob/master/aws-profil... to do pretty much the same thing, although without the $PS1 hacking. Our rule is that a user's default profile should always be the "control account" (on which they have permission to do nothing except STS and AssumeRole), and that they need to use this wrapper and explicitly specify a profile for all "real" API commands. This also works nicely with MFA.
Having this built into TF would be nice, but there are enough tools out there that don't support AWS role-jumping that I suspect we'll end up using that wrapper for a long time.
2-3 months of light work (it was the summer), in Toronto circa 2011.
I had zero professional experience, and bad grades. I knew that for my first job coming out of school, a lot of places would ask for a transcript...so I pointed most of my energy at places where the HR process seemed lax enough that I'd get to talk to developers (who could advocate for me) before I had a conversation where grades would come up.
At the start of my search, the Star/Globe had an insert with "Canada's Top 100 Start-Ups" - I cold-emailed all the ones in there which seemed interesting. A few got back to me, and one of the ones that did is where I'm still working.
As someone on the other side of the table now (at a ~25-dev shop), some things I think about when I'm considering new grads:
* I'm looking at passion, which I use as a proxy for long-term potential upside. You likely won't be a valuable contributor for 6+ months while I get you up to speed on my domain and what real-life professional programming is like. Some new grads can have an immediate impact, but most of those will have already been hired by Google/FB/etc. before they even think of my company. Convince me that you're the one I should be placing my bet on.
* If your CV talks about a mobile app you built, have it installed on your phone so I can play with it. If you talk about a web app, have it bookmarked and walk me though it. If you have one of those you're not excited to show me, I'm going to assume it's bad or you didn't finsih it (so don't mention it). If you don't have one of those and you're a new grad, I'm going to wonder why not. These don't have to be sophisticated; what you're showing me is that you're excited about technology, and can apply it in a non-academic, non-forced context.
* Show that you can communicate well. We're going to be spending a lot of time teaching you stuff, so I'm going to be probing to make sure that you can absorb it all (emotionally and socially).
* Don't focus that much on your specific tech stacks, aside from enumerating them. I'll assume your experience is of limited/academic depth only, and that you don't have much real-world experience. Don't boast that you know Scala when you used it for a project and a co-op term; focus on selling that if I need you to learn OCaml, you'll be a quick study.
Lastly, re: meeting engineers at meetups etc. - don't forget about follow-ups. Maybe the person you had a positive conversation with was just being polite...but it's more likely that they just forgot about the conversation. Send them an email a few days after to remind them you exist.
AWS support has said that ELBs will continue to accept connections (and use the correct backend) for at least an hour after the CNAME stops resolving to a particular IP.
If you're putting a lot of volume though Stripe, all those things are possible.
Notwithstanding Stripe's SaaS-y "all pricing and deals are public" branding, they definitely have a BD team who can set you up with more direct contacts for certain types of questions, different rates than are publicly posted, and APIs that aren't public (to name a few things).
I'm a hue PyCharm fan, but if this is true then vim and Sublime must be barely usable. Python, it's great at...but open a big JS file and it...will...take...forever...to do the JS syntax highlighting, if it ever finishes. CoffeeScript is even worse, and almost always crashes.
It's always a little weird, because I have no performance issues anywhere else in it, and it's got ~7GB of RAM it could use.
Stripe's terms say that "Marijuana dispensaries and related businesses" are prohibited. You're certainly not a dispensary, but reporting software designed and advertised for one sounds like a "related business" to me.
On a (for example) £7M house you would have paid £750K Stamp Duty, or if sold though a corporate transfer, £35K of tax on the shares and £36K/yr ATED - so holding it for less than twenty years would have been a deal, assuming no other possible savings from the corporate option.
Up until last summer (when the Government won a case letting them change the law), having your expensive house owned by an offshore corporation was the canonical way to avoid a particular type of UK tax called Stamp Duty.
When you buy a property, you have to pay Stamp Duty [1] on the value it's sold at. Stamp Duty uses marginal tax brackets, and the highest one (for the portion of the transaction over £1.5M), is 12%...so it adds up if you're buying a large house.
Given that the tax rate for buying "shares in a foreign company that has a share register in the UK" is a flat 0.5%, the scheme was that you set up the house as the only asset of an offshore corporation registered in the UK, and instead of selling someone the house, you sell them the shares of the corporation. The buyer can now inhabit the house at their leisure (since they own the company that owns it), but the direct ownership of the house didn't change - so no Stamp Duty was triggered.
There are likely other tax benefits to having your expensive house owned by a numbered corporation, but Stamp Duty is/was a significant one.
The biggest thing to remember when dealing with PCI DSS is that it's not the law.
Your PCI obligations come out of a commercial agreement that you have with your processor, which comes out of commercial agreements they have with VISA/MC/et al. That's not to say that it's not a well-defined standard that you're going to end up having to follow in some way, but rather that statements like "Both Litle and Recurly flat out say that you need SAQ A-EP" have more wiggle-room than it would sound like, depending on the rest of the deal you're presenting them with.
If you're a Level 3, I'd argue the goal should be to keep yourself on SAQ-A - the methods of which are pretty well-understood now. Pick a vendor which has a tokenization service designed to be hit from JS (they all work the same way at their core - download JS which contains an implementation of RSA and a public key, browser-side encrypt the CHD using that, send it off, get back a token). Put your payment form inside an iFrame which is served from a PCI-compliant host (like S3). Once tokenization is complete, send the token from inside the form back out to the containing page using postMessage or in the querystring.
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
Will they change PCI DSS again to remove the iFrame rules? Maybe, but given the speed the PCI council moves at (and the warnings they give before changing things), I'd deal with it then.
Lastly, if you're thinking of building a service which white-labels credit card processing and sells that processing as a service which your customers can then resell...don't forget about PCI PA-DSS
Can you highlight a few of the reasons you love it, in comparison to HipChat? When we ended our trial month and announced we were going back to HipChat, the biggest reactions was "OK".
Do you find them that much better? We're a small HipChat-using company who moved three teams over for a month, and the communal response was "eh?". It's no-doubt prettier and easier to write integrations, but for the core competency of chatting, the two were very similar (and most people preferred the native HipChat apps to the Slack browser one). It's big selling point for us was integration with Google Docs, and in testing we found that it didn't work that well.
It's also 3.5x more expensive. In absolute terms that's not much (<$400 a month), but no one could point to $400 of incremental value in it. If we fully embraced it and turned off emails for those teams, would we see it? Maybe, but we'd still need emails to deal with external vendors, and there's no way that we'd get non-developers to see it as an email replacement.
If you're experimenting, use `git config --global credential.helper 'store'` to set git to store your credentials in a plain-text file. Then (if you're on GitHub), generate a personal access token (https://help.github.com/articles/creating-an-access-token-fo...), and then use that as the password - once you've entered it once, it should be stored and not prompted for again.
I still remember how one day there was a message on the announcements newsgroup about how the size of a key was increasing, only three or four days before the we'd start seeing the change in API responses. Dealing with this needed a database migration that I would need more time to schedule, and I sent back a polite-but-direct response to the generic posting email expressing my disappointment with how little notice we received.
A couple minutes later a Google Chat bubble pops up from some guy named gdb (aka Greg Brockman), who I subsequently learned was Stripe's CTO. He apologized, asked why the timeline was tough for me, and when I explained it, immediately set something on my account so that the migration would be delayed by a couple weeks.
8 years later I remain impressed by that level of customer connection from a senior executive, and the technical excellence that allowed them to special-case delay my migration.