zpe

Me and my colleagues have benefitted greatly from Sequel Pro over the years. Recent Mojave complaints aside it's been close to perfect. It's eye opening to think we have paid nothing. Maybe companies should look into implementing 1% turnover to OSS. I'm guessing having bi-annual company votes about how to distribute the funding, and communicating this in the recruitment process might offset some/all of the cost.

1. Employing twenty people and making a profit.

2. Per app server we paid less than the cost of a macbook pro. Between 0.001 and 0.0015 USD in hardware costs per thousand ad views, which makes it irrelevant to the company bottom line.

3. Europe, global-ish market.

A few years ago my side project (and my second ever ruby/rails project) unexpectedly became quite popular.

Last couple of years it's been doing about 50,000 (user facing) api requests per second during high load, with almost a million concurrent users. It's 99% rails.

We (me and a second guy) have ran this system on ~10 (cheap) servers, five of which run the actual rails app. The rails app has probably been the easiest component to scale for us. We obviously do some caching - but it's not like our database could live without that caching anyways.

And even though we have been an ad-financed bootstrapped company the hosting/hw costs has been very manageable. There are probably many valid reasons to chose something else than rails, but I wanted to share my experience w.r.t. making it work for our non-SAS needs.

I have no knowledge as to what you think of triple canapés, but I do get a strong feeling of entitlement from you. You also seem to disregard a whole bunch of people(like me for example) that didn't experience as much pain as you. As well as the people that have dedicated their time to write deprecation warnings and documentation, recording videos etc..

Worst case, your app is exceptionally hard to upgrade and I feel for your effort.

We've upgraded a similarly large project and for us the two following mistakes caused the majority of headache:

1) Adapting libraries without regards to long term maintenance. I.e. single person project that he/she does because a current client needs it, without planning on having to take over stewardship of the library or fork it when the person eventually abandons it.

2) Adapting libraries that hook into rails internal apis, without writing this shortcut up as a debt that you might have to pay later when the private api changes.

"no one in the Rails community has the slightest interest in yesterday" I think this is pretty disrespectful. The deprecation warnings and online documentation didn't magically appear. For example this section "upgrading to 3.2" from the official docs: http://guides.rubyonrails.org/3_2_release_notes.html#upgradi...

I'm personally very thankful for all of the hard work the community has done to help us upgrade.

If you have found pieces of the upgrading puzzle that are missing, then please consider contributing back. 2.3 > 3 is the hardest one. It gets a lot easier.

I think he means the best combinations of dishes found.

Looks like typed function to me.

Sigh, another day, another post from you bashing the "ruby community". You got you message accross - ruby sucks, you're migrating to php, good for you! I've read like 15 post from you saying the exact same thing. Please, enough already!