You're absolutely right. My business co-founder also does QA, can help with some front-end coding, gets feedback from every single one of our users, and is a lightning-rod for time-bandits who want to take us to coffee.
I don't think this goes against the efforts to build a community in satellite locations. The reality is that there aren't many potential acquirers in Vancouver (virtually nil for consumer internet), so one takes an exit where one can get it. The community is helped by the fact now that when startups are raising in the Bay Area we can point to a company that was in the same geography that made a return for their investors.
My first instinct was similar to yours, but Canada is one of those "foreign countries". Sorry, from the hearings, you need to lean into that word more; foreign countries.
Thus, it would probably be more expedient to block a Canadian operation. To say nothing of the integration that already exists. My (Canadian) startup is dependent on playing by Apple's rules from California and exists on a couple Amazon servers in Virginia, so it's not like I can really thumb my nose at US law just because I'm incorporated and operate in BC.
I'm actually really glad to hear it. Though, I wonder about the "rails doesn't scale" mantra, is that really more for active record? In your experience is active record the biggest out of the box bottleneck?
The "rails doesn't scale" mantra was discredited 5 years ago, when people realised that it scales exactly the same way as PHP. Remember, scalability != performance.
We handle a lot less traffic than Shopify (~15-20 million reqs a day) but ActiveRecord isn't a bottleneck and I wouldn't expect to to be [...unless you are talking about something other than the performance of AR as a body of code?]
Instead of "Rails doesn't scale" we should say "Rails runs on Ruby which means that it will consume significantly more CPU and more memory* compared to something else"
In my case, 1 extra server (my estimate) was a small price to
pay for developer happiness.
The issue they have doesn't seem to be scaling, in that RoR is scaling linearly. But if you have hundreds of machines, raw performance saves real money, which means RoR is maybe not ideal for massive deployments and the JVM languages give you more performance on the same hardware. Though unless you're working on a top 50 site I wouldn't worry so much.
From what I read, "rails doesn't scale" is really a misnomer, because there are number of things that can be done to scale rails. I think Haiping Zhao of Facebook made it clear, that it's really just an efficiency problem. Bottom line, rails requires more computing power than jvm for sites like twitter. Which are only a handle of sites.
That seems to be the case. The view/controller layers can be scaled via more machines. Its the database layer that requires synchronization. Thats a universal problem, though.
An app that game out of a drunken discussion with some gay friends about how to establish boundaries with a random hookup. I mostly made it as a gag, but I guess it does solve a real world problem. Irony is that it is the least profitable (free, adless), but has more user engagement than anything else I've made and it hasn't been out a week yet :-P
Definitely agree. Getting Rails up and running on MongoDB is a lot faster than with ActiveRecord on top of some SQL. Especially when your data format is changing quickly, it's nice to just make a few changes in the model rather than having to track migrations.
You realize that this has nothing to do with sql/nosql and everything to do with your chosen framework, right? If, you used, say, a framework that autogenerated itself from your schema at build time, then changing the database would be as simple as changing the database, which is trivial.
I think a lot of our perceptions about technologies are influenced by the things that sit between us and those technologies. A lot of the talk about this particular issue has nothing to do with Relational databases or key/value stores.
Either I didn't get your point or you don't know what what Rails migrations are. Migrations are just a way to "change the database" in a repeatable way.
Right, but the grandparent's complaint was that you had to change your model, then write migrations to match.
In other frameworks, you use your tool of choice to change the database schema, then build the project and you're done. All the "model" stuff regenerates automatically. Thus, schema/model changes have no pain associated with them whatsoever, so there's no particular advantage to using nosql vs sql.
With Rails' ActiveRecord the model introspects the database schema at run time and figures out field changes automatically. What it doesn't figure out is relations and you still have to specify them in both the database schema and the model. Since you're mentioning project build, I suppose you're referring to Java or C# frameworks. Are those frameworks able to generate code for relations as well? (I suppose this requires following naming conventions or setting referential constraints)
Yeah, conventions cover pretty much every case you tend to come across. Got a column called CompanyID that has a foreign key constraint over to the Company table? Perhaps this is a relation... Nice of Rails to make it acceptable to simply ask you to name your stuff in a consistent way so that things just work.
The added bonus of a build step is that you don't need to keep regenerating the same classes and SQL code every page load, but it's not really any different from the programmer's standpoint.
"As China and India continue to evolve, their supply of engineering talent is likely to outpace demand"...Spoken like someone who has never tried to outsource a development project.
I've been hearing this since I started my CS program in 2001, back then I was worried that by the time I graduated the whole north american industry would be hollowed out and I'd have to go to law school. If the engineering sky was falling, it would have collapsed by now.
He is, however, correct about the importance of customer understanding, but that is not at the expense of engineering in any way.
