ceslami's comments

You make a good point - luck plays some a role. That said, where I think we got lucky was finding a good "community fit" (Step 1 from the article). It was up to us to execute well on the rest :)

In terms of audience size, I would expect smaller audiences to yield smaller results. Despite that, I think the message of the post is that building an authentic relationship with a community means you can grow alongside them over time. This means continuous feedback, new ideas, etc. All stuff that's useful to us as technologists and entrepreneurs!

Good eye, thanks! Fixed.

> Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective?

An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.

Tell your story!

You're not wrong, but you can use that technique and benefit from Dependency CI too.

Typically, you can define your dependencies in a file specific to a certain package manager. NPM uses `package.json`, RubyGems uses `Gemfile`, etc.

It is a reasonable practice to "vendor in" your dependencies, as you suggest. But given the declaration of your dependencies in some manifest file, Dependency CI can give you valuable insights.

For the sake of discovering a middle ground between our arguments, let's look at an example of a >$1B company running Rails: Github.

Most of Github's stack is Ruby on Rails, with specialized components/sub-systems written in C. This is a common theme amongst companies that use Rails or Python at scale.

There's a reason why people keep those languages around. Its the same reason why they tend to be used for MVPs: the tool gets out of your way so you can focus on solving the hard problems of your domain. The longer you can preserve those ergonomics, the better.

> if you get far enough and need to scale

Alright -- I'll bite.

Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with.

Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday.

Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty.

In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words.

But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.

Pretty much the same as in any other language. When you want to guarantee that there will only ever be one instance of an object.

It is a useful pattern for managing data synchronization (ie, if I only ever have one instance of a User, I know another instance won't mess up its state accidentally.)

Your economics are unique compared to typical SASS, for example. The LTV of a Youtube channel subscriber is basically $0.

Fantastic concept and execution.

I would note that by the time this sensitive code hits Github, its already too late. Criminals who mine PII/secrets use the Github event firehose to analyze code pushes in near-realtime.

It would be great to integrate this code as a pre-commit hook, so that code doesn't even get into the tree if its sensitive.

Tern.js is pretty solid and is compatible with a bunch of popular editors. Nothing in the IntelliJ family though. I have enjoyed working with it in SublimeText.

http://ternjs.net/

korzun is explaining why it was a good decision for Alibaba to pass on Snapchat.

Yahoo made $9.4B on $BABA because of how revenue-driven their core businesses have always been.

Is Webpass the SF ISP that is partnering with Artemis to deploy a test network of pCells. The idea of everyone who shares the connection clocking the speed of the undivided pipe sounds a lot like Artemis' technology.

I have never heard of a Marketing API. What do you mean?

The products are marketed very differently and have different features. Google Wallet is explicitly hoping to replace your wallet, focusing on loyalty cards, NFC payment, online shopping, and fraud monitoring, in addition to simply sending money to friends.

On the other hand, Square is positioning Cash as a dead-simple way to send money to friends, whether or not they've download the Latest Social Micro-payments App™. Its plumbing. Long run, they are obviously gunning for cards-on-file to support their merchant tools, where they make money hand-over-fist.

Who knows...Square Cash might expand into something that resembles what Google Wallet is today. They seem to be starting with the basics.

Besides that, Google Wallet is available in all 50 states, while Square does not allows residents of Hawaii and Tennessee to send money (only receive it).

I, and many others, want to use this in production. Is the API solidified, as per version 2.0.0?

There's nothing stopping you from doing that with a pinch of javascript.

What do you mean by "put my Amex into my phone once...and let apple handle it"? Is this a component of Passbook or something?

what?

Not everything has to be an overthought, standard UI element. It adds a bit of Fun, and is harmless in its consequences.

It would be nice to be able to undo though.