hootener

Probably has a thing or two to do with today's date...

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."

'Good ole boy' healthcare companies abound

Ugh. Tell me about it. The old guard in tech around here has led to some real hair pulling moments for me.

I think we're headed for a schism, though. Can't wait.

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

[1] http://nashvillesoftwareschool.com/ [2] https://angel.co/nashville

- maintain consistent dev/test/prod environments

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 :).

[1] http://www.statpower.net/Steiger%20Biblio/Steiger&Fouladi97....

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!

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

[1] https://slack.com/

It's a marketing play.

I hope there's no one in this thread naive enough to think otherwise. Of course it's a marketing play. That doesn't mean it can't benefit you.

Your initial point concerned vendor lock in and how this was a cheap way for companies to impose it. My response to that was "lock in to whom?" due to the diverse hosting providers on offer. Granted no mom and pop VPS provider is amongst the perk list (to my knowledge), but you have a several serious options to choose from.

In terms of my company the perks provided did anything but impose vendor lock in. I put parts of my infrastructure where it made the most sense for our business. This actually ended up being multiple providers amongst the list of those offering perks. If anything the benefits on offer from TechStars (and YES other accelerators that join these incentive programs) led to a more diverse and robust infrastructure setup which I hope will benefit us more in the long run.

But yes, fine, I acknowledged in another response lower down on this page that I should have qualified my original statement. The perks on offer were a game changer for my business because it gave us the freedom to choose providers and technologies that made the most sense for the product. For us this was crucial at an early stage and benefitted us immensely. I would assume our company was not necessarily unique in this regard, but perhaps I'm wrong.

In either case, who cares? You either were or weren't going to join TechStars or some other accelerator because the accelerator's terms made sense for your business when weighed against the benefits. Perks are just that...perks. Not fundamental lynchpins upon which you hope to run your business. My only initial argument was these perks are substantive and helpful, and shouldn't be dismissed outright. Apologies if that initial argument was not well-formed enough to get that point across to you effectively.

Some of those perks (maybe even all of them) are not things TechStars paid for.. they're things that other companies chose to give away to startups in an accelerator (of which TechStars is one).

Of course they aren't. Many are conditional against being enrolled in an accelerator. However, like I said in a previous post, the linked article relates to turning down TechStars. Full stop. Not turning down TechStars for some other accelerator that offers many of the same perks.

This is a serious question: if Amazon (and Microsoft, SoftLayer, Paypal, and others) setup a program for startups, give the services to startups, and pay for those services from their own pockets... What did TechStars do to earn a share of the credit for those programs?

They were a participating accelerator in that program, that's all (to my limited knowledge).

In relation to these perks being "game changers" it isn't about TechStars having better perks than Accelerator X, it's about TechStars allowing me access to benefits I didn't have before joining an accelerator that ended up being enormously helpful to my startup.

The "game changer" in my company's case was the peace of mind that comes from knowing that for a full year we can shave at least $5k/mo (once again quoting the BizSpark credit here for convenience) off of our operating expenses. That's a technology hire for us in the city where we are based. So, for us, it means a lot.

I apologize because I obviously colored my original statement through the lens of my company's own experience.

This statement:

but some of the things offered by TechStars are game changers

should have been qualified by stating that it was coming from personal perspective. So, in the short term, these perks meant a lot to the technological freedom of my company based on our technology needs and the other places we could put those savings to work based on our business needs at the time. For my business, the perks made a difference and were a big help early on, they may not do anything for your business or others.

List them.

They're linked in the parent to my original reply.

Let's just call this what it is.. cheap way to lock start-ups in your infrastructure

Whose infrastructure? Perks come from Amazon, Microsoft, Softlayer, Rackspace, Digital Ocean, and others. That's a pretty wide swath of hosting providers, but I guess if you want to run your business from a couple of boxes under your desk, you're on your own.

For most early stage startups, hosting costs represent extremely low % of expenses.

Cost is relative. $5k/mo for a year (citing the BizSpark Plus credit directly here) can make a big difference early on when you're pre-revenue. In the case of TechStars, this is particularly true if you decide not to take the convertible note.

Not really a reason to pick techstars over another program

When was this a debate about picking techstars over any other program? The article relates to picking nothing as opposed to joining TechStars. I think these perks are a little harder to come by when you turn an accelerator down for the no op as opposed to "I picked accelerator B instead of accelerator A".

I'd tell you that if you wanted to do an apples to apples comparison of accelerators we should save that for another thread lest we get too off topic, but that hasn't stopped others in this thread from turning the article into a TS vs Other Accelerator debate, so why should it stop you?

I know it's easy to view perks as window dressing, but some of the things offered by TechStars are game changers for a business's tech teams, particularly in the early stage.

Granted, these perks do eventually go away and you have to have ample business justification for technology costs. But at the outset it's a godsend to know your business has the financial headroom to address any early technical challenge.

Benefits like web hosting / services credits allow all that financial hassle to get out of the way in the early game so you can just focus on delivering the best product possible.

Based on earlier reports of Justin.tv's streaming architecture[1], I'm going to say no.

Granted, that article is old, but I think a pretty serious investment in physical infrastructure has been made by Justin.tv/Twitch. So I'm more willing to believe they're still leveraging some variation of this architecture rather than AWS.

[http://highscalability.com/blog/2010/3/16/justintvs-live-vid...]

This is my general rule of thumb, but bear in mind it's only my approach. I'm not even going to claim that it's good. Just that it works for me...

Is it source or configuration? Then its external to the container, either mounted at runtime of the container (typically always true for source code) or injected into the image at build time through the Dockerfile. Application source is almost always mounted, things like nginx/apache configuration files are nearly always injected during the build process.

I prefer this approach because my source is decoupled from the image, and if another developer wants a dev setup free from Docker, he/she can do so.

I prefer the source I use for config files because it allows me to keep the dockerfile, the configuration files for various services, and a readme all beside one another in source control. This allows other developers to get a basic idea of the container's configuration (if they so desire), and also modify that configuration if they want to tweak/alter a setup.

I see the configuration file approach being potentially a bad idea, but with the small group I currently work with, we're all fairly comfortable making configuration changes as necessary and communicate those changes to others effectively. I don't know how well that approach would hold up at scale.

I would do the same thing with static sites and files, I think. Why? The static site isn't the part of the system, it's the product that should be executed on the system. Therefore, at least in my opinion, it should be as decoupled from that system as possible.

But, like I said, this is just my philosophy. I'm sure someone else will have an equally valid but totally opposite approach.

I'm not terribly proud of my ownership of that site, though I did try to run it with something of a conscience: never called for gossip, voluntarily removed 30,000+ posts, etc.

I think these facts are commendable, and I'm glad you at least made attempts to prevent outright hostility (I'm assuming you removed particularly incendiary messages).

Ultimately it isn't the technology of sites in this space that I'm really curious about, it's more the motivations and intentions of those that create apps in this space. It's easy to paint such creators as vile and or devious individuals looking to exploit the worst of people to make a buck. In reality, I don't want it to be that simple...at least not everytime. So, I guess I'm most curious as to your motivations and expectations for CollegeACB when compared with the actual outcomes.

You mention usurping JuicyCampus, which had its fair share of negative criticism. Was your goal to replace/compete with JuicyCampus or was this an unfortunate side effect?

What drove you to sell the site? Was your intent to turn a buck or did the content and the way the site was/is used eventually turn you off on being associated with it?

Hindsight is 20/20, and you mention not being proud of owning CollegeACB. How did you feel about it at the time, when the site was enormously popular?

Agree with you XFCE in Xubuntu. I just can't force myself to like Unity, stock Debian is ugly, and LXDE on Lubuntu looks flat out terrible on my 1080p monitors. Just a smeary blue and silver mess.

I don't think XFCE is perfect, but it ticks the important boxes for me. So much so that I just use it out of the box now rather than rolling my own from a vanilla OpenBox install (a fun exercise, btw).

"That's because you aren't a software engineer, and if you are saying so then the feelings of being an impostor are entirely warranted."

At face value this assessment feels very unfair. Where do you draw the line? Experience -- is a year not enough? Deliverables -- is YumHacker not enough? Education -- is it lack of formal training that separates the engineer from the coder?

Is it the ability to build non-trivial software systems that makes a software engineer? And we should rely on whose definition of "non-trivial" to assess her engineering ability in that case?

I'm not saying you're wrong in stating she isn't a software engineer, but I doubt you possess the knowledge of her ability required to make such an assessment with any degree of validity.

Aside from some statistical reporting quibbles, I think this is a good write up. The authors essentially arrive back to a design that's been leveraged for RSS feeds for ages (e.g., Google Reader, Feedly, etc.) This isn't a bad thing since the design was ultimately data driven.

No shame in doing the experimental legwork to determine that the old way is the best way (in Prismatic's specific case).

"not people seeking the shelter of Google, McK, Bain, etc."

It seems that by leaving such companies to form startups, such individuals would represent the very definition of 'risk-taker'...

I'm probably just going to show my ignorance, here...but why doesn't container linking solve this problem?

Could you not run multiple docker containers/services behind a single nginx or apache container on a production server? Then the nginx container basically gets one of your public IP addresses, and you use linking to that container to provide it with knowledge of the other running processes' IP addresses (each within their own container, of course). In that way, you have one public facing container which has knowledge of the other containers and can use the information provided through -link to configure the nginx server to route requests appropriately. This requires a bit of bash script / sed command line hackery to update your nginx configuration to accommodate the changing IP addresses of the other containers on restart (unless you can set them by hand now using Docker, we still don't), but once you get it setup you never have to think about it again.

Like I said, maybe I'm just showing my ignorance, but something like the above scenario is how we get around hosting multiple services with limited public IP addresses available.

I've had to write output save file formats for various projects on several occasions, and it never occurred to me to take this approach.

Thanks for sharing this, it's one of those ideas that (to me) seems so brilliant in its simplicity that I probably would've never thought of it.

Any hiccups in the day-to-day work using this approach? I'm just trying to get a better idea of the workflow since I'm very seriously considering applying it to my next project.

The issue really isn't me tracking my own changes. In that case, version control does great. The problem is adoption by collaborators, particularly for PIs that don't want to take the time to sit down and learn something new.

The problem with Word's track / review features isn't necessarily that they're good, it's that they're so entrenched in academic writing (even in the sciences), that attempting to do anything else gets zero traction from most PIs and collaborators. Even PIs that use LaTeX themselves are hesitant to collaborate using it because of the extra friction it introduces as compared to Word's track/review tools.

As much as I hate to admit it, I think the only way to migrate some collaborators away from Word and to LaTeX in a collaborative setting is to basically duplicate Word's track/review/comment features and incorporate them into a LaTeX-based system.

Word's comment and review tracking system is more intuitive.

This. The first person that makes a LaTeX comment and track changes system as intuitive as Word's can have all my money. No, the comment and todo LaTeX packages don't count. There's just too much resistance in getting someone to go through the LaTeX install process just to use packages in a syntax they don't want to take the time to learn.

It's extremely rare to get a student to fork and make pull requests to this template on github, even more version control savvy CS students.

Of all the students I've had email me with problems, a vast majority just grab the repo as a zip and never contribute back. Bummer.

Awesome, I'll keep an eye out for it

Great work, James. I think I'll fork this code and give it look-see.

I manage the dissertation/thesis template for my department on github. The assembly and dissemination of this template is a purely student-run effort. Typically the task of managing it gets passed to a new student when the previous manager graduates.

The problem I've found with managing it this way is that I'll invariably get a slew of emails from students throughout the semester wanting me to troubleshoot their LaTeX installs to make the template work. 99% of the time the problem is on their end, 1% of the time it results in something that actually improves the template somehow. It would be awesome if I could just point them to your service where a hosted (and guaranteed to work) version of the template resides.

Can I just shoot you a github link[1] to get it incorporated or is there some other process I should go through? (e.g., would you prefer me to send you a zip? I figure what's the point since it's already on github, but if you prefer that approach I can get you a zip)

[1] https://github.com/hootener/LaTeX-Vanderbilt-Dissertation-Fo...

Ben Shneiderman toured my laboratory a couple of months back. He actually took the time to sit down and use and discuss some of the UI stuff I was developing as part of my PhD research.

I'm sure he doesn't remember it, but those 15 minutes were extremely beneficial to me. He's a super humble, brilliant scientist and designer. I have the utmost respect for him.