JimmyL

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.

[1] https://www.cbc.ca/radio/asithappens/as-it-happens-friday-ed...

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.

From the Stripe list of prohibited businesses [1]:

Marijuana dispensaries and related businesses

Some of these rules come from Stripe itself, some come from the networks they work with.

[1] https://stripe.com/us/prohibited-businesses

Very true, but ATED is cheap.

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.

[1] https://www.gov.uk/stamp-duty-land-tax/overview

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.

Do all that, and you're fine to stay on SAQ-A (https://www.pcisecuritystandards.org/documents/Understanding...):

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.

Please remember how insecure this is.

It would be trivial, which is one of the problems with A-EP when you look at it from the POV of someone who knows something about web security.

As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding...:

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')

The main thing to remember about the deadline today is that what's changed is the forms needed for certification. If you're already certified, nothing changes today - but when you do your annual re-certification, you'll need to use the 3.0 forms (and not the 2.0 ones). Until such point, you're still certified and compliant. If you're not yet already certified, you'll need to use the 3.0 forms; this is what most people are referring to.

With that in mind, this discussion only applies (right now) to sites who have never yet filled out a PCI form. For sites which have, it only applies when their annual re-certification comes up.

So for those sites which have to certify against 3.0, can they run on a PAAS and take payments? It depends, specifically on how the credit card number is entered. The general rule of thumb is that if the form in which the number is entered is delivered by the host (the PAAS), you'll have to use SAQ A-EP (which is extensive, and you don't want). if the form is delivered by the vendor (like Stripe) and injected into the page, you can still use SAQ A (which is small, and what you want).

How about Stripe? I'm not sure if they've released a PCI 3.0 version of Stripe.js yet, although they clearly will. Likewise, I'm not sure about the others, but I think it's safe to assume that they'll release versions similarly (the techniques to do this are well-known).

Lastly, I'm not a QSA, and this isn't advice.

When a merchant signs up with WePay Clear, do they actually have full WePay accounts they can log into (which would have a WePay-branded experience)?

If you don't count the days, how do you make sure that people are taking/compensated for the statutory minimum - or do you mean "we count the days, but we don't say no just because your count is above a specific number"?

It depends on the jurisdiction, but a lot of the "guideline amount + tracking" philosophy is driven by the law (and financial accounting).

For example, here's an except from some guidelines around the Ontario Employment Standards Act:

Employers are required to keep records of the vacation time earned since the date of hire but not taken before the start of the vacation entitlement year, the vacation time earned and vacation time taken (if any) during the vacation entitlement year (or stub period), and the balance of vacation time remaining at the end of the vacation entitlement year (or stub period).

So at least in Ontario, your employer is legally obligated to record your vacation time each year, and on demand, produce a report on it. There are also rules around when an employee has to take their vacation by, for example:

The vacation time earned with respect to a completed vacation entitlement year or a stub period must be taken within 10 months following the completion of the vacation entitlement year or stub period. The employer has the right to schedule vacation as well as an obligation to ensure the vacation time is scheduled and taken before the end of that ten-month period.

Since Ontario is also a jurisdiction with legally-mandated vacation time, at any point in time the vacation that an employee has accrued but not yet taken (or has rolled over from another year) should also be recorded as a liability on a company's books, since it could be forced to pay out the equivalent vacation pay (if the employee leaves, for example). The obvious way to get around this - and I've seen it done in a few places - is to pay everyone their full statutory vacation pay every year and then not count the vacation days taken, but that's basically giving everyone a 4% raise, and isn't even an option in some jurisdictions.

All of this is to say that unlimited and untracked vacations may not even be a legal option everywhere, regardless of what we think of them.

These are from the first day of talks and a few of the tutorials. The second day is going on now, so they should be online in a day or two.

I'm not sure it would have (without trying it), but it certainly would have kept you in the game for a bit longer since I'm a-OK with EMR jobs for my analysis (or presumably being able to download those files and load them into my own Hadoop cluster).

I recently tried Keen.io for a project I'm working on, and it didn't work out - the metrics I was looking for were too complex (eg. the average lag between signup and the third time a user does a particular action) to do natively, and the suggestions for how to get that working in Keen (doing some calculations on the event data before sending out) I wasn't interested in.

Having said that, the guys at Keen were great to work with as I was sorting this out. The email I sent to their generic "contact us" address with some data modelling questions was answered promptly by one of the founders with solutions which, while I didn't like them, were interesting and would have worked out. They were also generous in letting me crash through the initial free quota while I was figuring out if the thing worked out for my use.

So while I didn't sign up as a paying customer with them (and I've stopped sending them events), it was among the most pleasant interactions I've had with a prospective analytics vendor in a long while - well done guys!

I went though sendwithus zero as an unknowing participant in the experiment, and it sucked.

At the time, the company I was working at was looking for a service exactly like this - a service where our app could just fling events, and then we'd do all the logic to control what emails got emitted on the basis of those events on the external service (and A/B test them). One of our "growth hacking" guys found SendWithUs somehow, and introduced us. We had a few calls with them - the service seemed like it had potential, and we got beta access to it...which was really sendwithus zero, but sending basic email.

We got most of the way though setting up an integration with them, but every time we asked when the A/B testing framework - which was what sold us on the product - was coming online, we were told "it's coming soon, it's what we're working on right now." So we held on for a few more weeks, and gave them some time...but nothing came of it. I was skeptical at the time that they were actually building it, even moreso having read this.

The positive side is that while we were being strung along by sendwithus, we found Vero (https://www.getvero.com/). They're not perfect either, but we've been on them for 6-8 months, and they've done well for us. They're responsive to our issues, are willing to Skype or chat when we try and develop some sophisticated campaigns on their platform, and have (or so it seems) rejigged their roadmap a few times to add in small features that we ask for. ExactTarget is still a more full-featured package, but I'm happy with the price/value of Vero.

So well done, guys. You've got an interesting story about how you bootstrapped your business, and you're evidently doing OK. I wish you the best, but I can tell you that you won't be getting my business (or my recommendation) - at the time I thought you were small and were actually on the cusp of delivering what you had promised us worked; now I see that we were just one more data point for a feature set that you never planned on having ready when you claimed.

If you've got a good story - like this one - hacking government bureaucracy requires only one thing: getting your local elected representative involved.

Not because they're particularly dedicated to helping out constituents, although many are, but because it's great for re-election. A good congressional district staffer could take this, write up a few letters "from" the Congressperson to whoever's in charge of the person in charge of JPAC, send a release to the local cable channel, and get a pretty good local firestorm going on the issue to shame the DoD into some action. This may not get the investigation going, but it will get some progress...which will be good for the petitioner (since they got some official attention they wouldn't otherwise have), and good for the Congressperson (since they'll be able to highlight this in their newsletters and when they're running for re-election as someone who "gets results"). District staffers live for things like this; take advantage of it.

Pro tip if you have something where you're going to use this strategy: make it as easy and as obvious as possible what you'd like your representative to do. Want them to send a letter to a particular official? Attach a copy of the letter you've already sent that official. Want them to make a call? Include all the information you have about the person you tried to call, their supervisor's information, and the talking points you would have used had you been able to make it. Keep your issue morally black-and-white, and make it very easy to understand how doing X will result in something concrete and simple that the representative can consider an accomplishment. You're competing with a whole host of other interests who want some of this representative's district time, so make it very clear why what you want is easy to do, morally right (according to the morals of the majority of your district), and simple to understand & be convinced of.