Haha yeah… since when is this a major website? Not even in the top 100K… (alexa)
Sharing buttons make it easy for non tech users to interact with your content on desktop. The alternative for them is to open a new tab with the social network they use, and paste your link. You lose the people who are too lazy to do this (a large chunk of your audience, don't fool yourself into thinking your content is so amazing that people can't wait to share it).
The history of the term "lurker" was very interesting to me.
I am an active member of the shoe community NikeTalk, and lurkers are almost a daily subject on that site. Lurkers in a way are actually looked down upon from active community members (not me personally), since they get quick access to helpful information on shoe releases without out having to share anything to help others. If they saw this rule of thumb, it would probably be serious fuel to their fire.
One of the tricky things for me has been in the handoff from HTML template developers to CMS integration developers. The way we currently have things setup, the developers doing the CMS integration no longer have the ability to make small/quick changes to the main CSS file. It actually has to go back to the HTML developers for the revision, recompile the CSS, then back to the CMS developers.
A lot of it is environmental issues. Currently the codebase for the CMS developers is managed by global TFS repos. While the pure HTML templates are done by each local office in SVN repos. Good times.
what are the issues/implications of "just check out the subrepo directly into the superrepo, and rely on .gitignore in the superrepo to keep them seperated"?
When making a new checkout, you have to check out and keep the subrepo in sync manually. That is, unless you're using a dependency manager, which you probably should, as it will give you almost all of the advantages of submodules without their disadvantages.
Agree, I send millions of Push Notifications via Parse and I am also quite worried. I love their interface and documentation so I really don't want to switch.
It is tricky. Maybe we have more work to do. If you sign up for a single Stripe account you get a set of credentials. You drop those in to process against us. That's one payment gateway token. Say you you Stripe but also want to offer PayPal as a payment type. That's one for Stripe and 1 for PayPal (essentially two stand alone payment gateways) Ok, that's pretty vanilla. Ok, now you want to add Dwolla. That's a 3rd.
Second example. Say you are in the US and you do all your processing via Auth.Net. That's one token. Now you open a local office in Australia and want/need to process locally (say PIn Payments) That's a second token. Now you expand to the UK and use Sage Pay there (third token)
Final example. You're building the next Shopify or Freshbooks. Each of your customers will do their own processing and need their own merchant account. Each of those customers equates to one payment gateway token.
So a stand alone commmerce site with one gateway for credit cards and support for Dwolla and PayPal as a payment type = 3 tokens. The Uber model - where in each country you set up a new processor - probably equals 4 - 10 tokens. And then next Shopify = 100's to 1000's of tokens.
It is good you clarified this here as it wasn't clear to me and though I had before now settled on using spreedly-core, due to my not understanding that bit, I quickly began thinking I may need to evaluate other options all again. But no need with this explanation.
Why don't you paste the exact explanation/examples that you have given here in the pop-up that comes up when we mouse over 'pay as you go' in your new pricing page.
Thanks for the explanation. Those are the use cases I was kind of thinking, it just didn't seem 100% clear in the pricing page, especially when my use case would probably just be one or two tokens.
I was confused by this initially too. I think it's just "token" that throws me off. I know what a gateway is, so maybe just saying "25 Gateways" or "$10/Gateway" instead of "gateway token" might be better? Just my initial thought.
The problem we run into there is someone supports 8 gateways (for example) but has 500 customers with 500 individual merchant accounts. They might come away with the impression they just need to pay for 8 gateways. So those folks understand this but we do end up seeming overly complicated for someone who doesn't have that complex use case.
The one that immediately comes to mind is Information Architects."
Welp.