I've used both stripe and braintree to build payment processing services that do hundreds of thousands of dollars in transactions per month.
I can't really tell you which is better because it really does depend on a lot of variables that may be unique to your business (e.g., where you intend to operate, the payment methods your target customer base is comfortable using -- hint: it's not always credit cards and paypal, how you intend to bill).
Since I've got more experience with braintree, though, I can comment on some aspects of its use specifically -- primarily their drop-in UI, which has frustrated me at every turn.
Their drop-in is probably one of the most frustrating pieces of technology I've ever integrated into a website. Not because it's poor, necessarily, but because it only feels about 80% complete. The user experience is really frustrating at times. Some examples:
* Last I checked, payment method removal wasn't possible in the drop in - you have to integrate their API specifically for that.
* Choosing what payment method you want can be really confusing due to the card number / email address obfuscation they use in the drop in. For example, if you have two paypal accounts, selecting between one of the other is difficult when they're listed as p----@paypal.com and p----@paypal.com. The same thing happens if you use multiple credit cards of the same issuer (two Visas for example). Simply allowing the user to set a card name in the ui (e.g. "Personal Visa" vs "Work Visa") would mitigate this problem.
* It currently isn't possible to set a Coinbase account as the default payment method in the Drop-in. Despite the Drop-in supporting Coinbase fully in every other way. So there's another reason to incorporate the API.
* Lack of other major payment methods. With BrainTree you get Venmo, Coinbase, CC, Apple/Android pay, and Paypal. Depending on your customer base, you could be woefully under-serving them. As my current business grows, we're now looking into incorporating other processors to use alongside braintree to support things like gift cards, ACH transfers, Amazon Payments, etc. This may just be unique to my industry, but I can't stress enough to do your homework ahead of time and understand how your customers expect to pay you.
* I get numerous reports from users of being unable to pay using paypal through the drop-in if they don't have a credit card attached to the paypal account. I've contacted BrainTree numerous times about this and have yet to get a definitive answer as to why this is the case. Additionally, if a credit card is connected to the paypal account, the withdrawal comes from that and not the paypal balance. If you want to frustrate your user base, let them use their paypal account but not their paypal balance...
As I've typed this, I realized it's a pretty ranty indictment of BrainTree. On the whole it isn't a terrible service. Uptime is good, money goes in, comes out, and my business keeps on running. It's not a bad service, I just have a lot of drop-in frustration. I kind of hope I get a reply that says, "The BrainTree drop-in does all this, you're just using it incorrectly."
I'm a Nashville-based software developer, so maybe I can lend some color to parent's comment.
Parent may be speaking about the Nashville Software School[1]. Very recently it has been turning out some great talent in the 0-2 yrs of experience range.
The rest of this post is pure anecdote from the perspective of someone that has hired tech workers in Nashville, both full time and contract.
We seem to have a decent (but not enough, never enough) supply of junior devs (0-2 yrs experience). Really experienced talent seems more elusive. I believe that it's here, I just think most of it is employed already.
Additionally, the tech scene here is a little strange. There's an ever expanding pool of web folks (e.g., Rails, Node, etc) and a surprising amount of more Enterprise experienced developers (e.g, C#, Java) that arose as result of all the HealthTech hiring that's been going on the last several years. So veteran (e.g., 7+ years) software developers I've encountered seem to skew toward Enterprise.
There's some startup activity here[2], and we're seeing some larger non-healthcare outfits set up shop in Nashville (e.g., Warby Parker, Lonely Planet). The technology scene here is really starting to come together, but it's by no means a Silicon Valley, NYC, Boston, or even Austin yet, really. It's getting there, but we're still a ways from seeing Music Row's inevitable transformation into Silicon Row ;)
Interesting, thanks. I was working for a healthcare startup (almost but not entirely a contradiction in terms) that was painfully, painfully enterprisey, so that certainly could have been part of our experience.
We weren't looking for juniors, either, which complicated things.
We're pretty heavily invested in Docker. To this point, it's really nice knowing that all the developers are operating in consistent environments.
An additional bonus is that using Docker makes it really easy to propagate infrastructure changes to the rest of your team for use in development. And, more importantly, know those infrastructure changes are consistent across local dev setups.
As an example, I recently incorporated Sphinx search into a project we were working on. I didn't want to require devs to install Sphinx on their own machines and get it up and running for search to function properly. I also didn't want devs to have the overhead of running Sphinx for search on their local boxes unless they were actively working on something related to search. Basically, I wanted search to be optionally configured to run on startup.
I used a DockerFile to setup Sphinx in its own container, pushed the DockerFile to a Tools source repository we use, and then incorporated the build and running of that container into our startup scripts (just some simple orchestration stuff for the local machine written in bash). Now, if a dev wants a containerized search mechanism they run a simple bash script to build that container, then run another command to spin up our dockerized web app with a connection to a running sphinx search container. We do this for all of our services: mysql, redis, sphinx, the web app itself, and anything else we might need.
As an added bonus, all the Docker CLI work and orchestration of our application is easily hidden behind a shell script. If a dev wants to run the webapp, they simply run: app server dev. If they want the app with search they run: app server dev search from the command line. Developers never need to know what's going on under the hood to get their job done. From their perspective, it just works.
> For me the take away is that non-trivial independent replication of results still stands as the gold standard for experimentation.
Agreed. Too bad funding agencies rarely if ever give you the money to do it :(.
The takeaway here is that statistics is arguably one of the most nuanced quantitative fields out there. It's really easy to shoot yourself in the foot, particularly with p-values.
I think every statistical test has its place, but my personal favorite lambasting of p-value testing is Steiger and Fouladi's 1997 paper on non-centrality interval estimation [1].
As an aside, Steiger was my graduate statistics professor several years ago, and probably the primary reason I know this paper even exists. If you enjoy the harsh treatment of significance testing in the paper, just imagine hearing it straight from the horse's mouth during lecture :).
I think you've hit the nail on the head, here. WebRTC is really great for a handful of people. Implementation using some third party was never the difficult part, but scale was and is still a total nightmare.
I'd love to see WebRTC done by a service provider in a highly scalable way, so I can stop relying on RTMP (and typically embedding a flash player to support it) to deliver live streaming audio/video on a large scale.
As someone who has only leveraged WebRTC through third party providers (e.g., OpenTOK, etc.), I have no idea the complexity of what I'm asking for. Perhaps it's boil the ocean difficult, but it sure would be nice to have!
Yeah, I don't think that it is boil the ocean difficult but there is definitely some complexity there.
I have been working on a scala WebRTC server, but I am not sure if it would really work at a large scale
Here was my basic approach:
An end user creates a PeerConnection with a Publisher node and starts sending a MediaStream using a string identifier.
Then another user can create a PeerConnection with a Subscriber node using the same identifier.
The Subscriber node then makes a request to the Publisher to make another PeerConnection to a Registry that exists on the same node as the Subscriber.
The replicated MediaStream can then be attached to the Subscriber.
Since the replicated MediaStream is in a Registry, any additional subscribers can attach the MediaStream on the same node as well.
There is a vagrant file that brings up the whole system at the root of the project (using docker). I have not tested it recently on anything other than ubuntu.
I've been working on exactly this. It's not horribly difficult if you've got experience building media servers, but it is tedious, because WebRTC has so many more moving parts than eg, RTMP, and the tooling is not very mature yet. Not to mention WebRTC itself is still a bit in flux (eg, ORTC).
Unfortunately, until IE and Safari support WebRTC, then RTMP is really still the best way to do low-latency streaming and video chat in the browser. Additionally, most RTMP server software will scale out to hundreds of clients out of the box.
This is what caused me to abandon HHVM for plain ol' PHP around a year ago. I was running it in Docker containers and the memory leaks would regularly crash my containers if left unattended for more than a couple of days.
It was quite frustrating because I noticed some definite performance gains (e.g., ~2x faster page loads, etc.), but ultimately opted for PHP's stability.
The benefit to running all this in Docker is that I can swap HHVM back in relatively easily (unless it's changed really dramatically over the past 10 months or so). Your comment has me tempted to give it another shot!
We do this, but use a sliding scale. The middle of the scale is what's locally considered to be a fair salary and fair equity compensation for whatever role we're hiring for. The equity / salary offered at each end of the scale tends to fluctuate depending on the impact of the role.
So far it's worked out well. I think potential hires like the flexibility because it lets them optimize for larger short term gain (a higher salary) or a potentially larger long term gain (more equity if the company sells, IPOs, etc.)
Anecdotally it tends to make negotiations easier for us. We basically end up presenting the entire solution space we're willing to offer for the ''what's my salary and equity'' problem. With the extents known, negotiations tend to settle around some point within that solution space. Your mileage, of course, may vary, though.
I wonder with these arrangements, is there any pressure or implied pressure on people to accept a larger equity amount? Similar to the issue with unlimited vacation time.
The one time I got that kind of offer, I got a lot of pressure from the hiring manager to take the most equity possible. They basically insinuated that doing otherwise was disloyal -- although, they cloaked the message in a super-positive tone, saying something like, "we are always really stoked when new hires choose the most equity possible because they believe in the mission". I know those words might sound squishy but trust me, there was no ambiguity about what they meant.
In retrospect I wish I had taken the higher salary.
I'm not sure what you're after with paid HipChat (e.g., video/screen sharing, >5GB file uploads, etc.), but Slack[1] might get it done for you for free. Probably still not ideal depending on what you want, but a potential alternative nonetheless.
