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!
> 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.
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.
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.
I can't think of a single billion dollar Corp that can run Rails on a few AWS boxes. Time and again companies have rewritten systems from MVP to handle data safer, better, and faster, from Dropbox to Twitch to CloudFlare to Uber to Mail.ru...
Then there are plenty of 7 figure companies that have also had scale issues. Game companies come to mind first and foremost but they're hardly the only ones.
You want to run your marketing website on Rails? Yeah of course. But billion dollar companies on Rails?
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.
Agree, and I say it as an Erlang full-time dev. Chances are you don't need 9 9s reliability and super scalability.
I've heard and seen cases of companies rewriting stuff unnecessarily due to some incompetent people following latest fads. "Oh I read Python has the GIL so we need to switch to Go. Saw on HN everyone is switching" -- cue years wasted in rewriting and destabilizing a solid usable code base.
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.)
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.
Excellent point. I wonder if it would be feasible to put this kind of check in a pre-commit pipeline to prevent it actually getting committed in the first place.
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.
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!