This program offers interesting features to a business but not s much for the traveler. Anyone who is spending 25+ nights a year in a hotel is going to be sure to be getting points for those stays. Points == status and status == more convenience when traveling. Beyond earning free nights, there's expedited check-in, private lounges with free food, gift baskets when you check in, etc. The caveat is that to get status most (or all) of your points need to be with the same company. This means most hardcore business travelers are very loyal to <program x>. This travel program doesn't have any kind of loyalty rewards which is a non-starter.
Other downsides of airbnb: booking isn't instantaneous as with a hotel (wait hours or days for confirmation from owner), checkin has to be pre-arranged and requires you get in touch with the owner (i.e. no 3am red-eye check-ins), each place you stay is slightly different amenities versus hotel chains which all have the same brand of pre-wrapped toothbrush when you forget yours. These might seem trivial but when you travel a bunch it's the little things that hurt the most.
Story: I once had to wait for 2 hours to check into an airbnb in SF since the owner was in Africa and his mother forgot to leave his key where he said it would be.
At Georgia Tech we got a very small server space which was used in a few CS classes, it would have been large enough to run hubot. Your university might have a similar setup.
If you've got a static files you could still serve it using Heroku free. Put cloudflare or another CDN in front of it and boom you've got 24 hours of fast responses. Though if it's a static site why do you need Heroku? Kind of like using a cannon to kill a mosquito.
This was removed for architectural reasons. It brought a lot of downtime to the platform and didn't help speed all that much. It's better and faster to cache this type of content with a CDN anyway.
* Explain new technology to customers.
* Simplify technical issues for customers.
Pick a few open source tools that your company uses like http://www.codetriage.com/rails/rails and start reading issues. Eventually you'll learn enough to start helping out.
I bought this game a few years ago. I learned quite a few things about vim. Unfortunately the puzzles in the later levels aren't very clear. I spent hours trying to figure out what on earth they wanted me to do. To me this was counter productive and got less and less fun. I ended up leaving the last few levels unfinished as I felt I got very minimal returns for time invested.
If you're interested in picking up vim, I love it for the first 5 or so levels. After that, not so much. (I currently still use sublime text but do occasionally use vim on servers)
Tenderlove, the super nice guy who submitted that PR is on Rails core. Too bad to hear he's part of the evil visible minority that you just made up in your head.
Austin is amazing! If you're in town stop by an Austin on Rails, great community. There's always friendly folks, companies hiring, and ususally some food.
I think there are a few issues. The first is funding. If you are an engineering manager and trying to ship product, you don't want a 25% faster Ruby VM in 10 years, you want someone to benchmark and optimize existing code in existing products 25% today. I agree that it's a good pay off, cost versus benefit...however the benefit is spread around hundreds and thousands of companies. Google gains marketshare for chrome when V8 gets faster, there's very few companies that get significant advantage explicitly from making Ruby faster for everyone. If you're paying to make Ruby faster, it's also getting faster for your competitors too (if they use Ruby).
There are a bunch of core contributors that are very active. Several of their companies allow them to spend time contributing (most of them are from Japan). Another example is Aaron, he is on Ruby core and his company allows him some time to contribute to open source, so this is sponsorship in a way. I while a company stands to benefit from sponsoring a full time developer, they benefit just as much if someone else sponsors a full time developer. Right now there's not enough companies with either a business incentive, altruism, or interest. Perhaps there are companies out there interested in sponsoring full time devs who just don't know how (and to your point cannot find them) but I think that would be the minority case.
We sponsor Matz, Nobu, and Koichi. Of them Koichi works pretty much full time on speed. He implemented partial generational GC in Ruby 2.1 and incremental GC in 2.2. He also implemented faster keyword arguments https://bugs.ruby-lang.org/issues/10440.
There's actually been a bunch of great performance increases in the past few years in addition to the GC. Optimized method cache invalidation by the late James Golick, frozen string pool for hash keys by tmm1, using vfork instead of fork, etc, copy on write GC. There's also new features, like Ruby's ability to GC symbols that let developers use symbols in more places and spend less time converting back and forth between strings.
So yes, money is a factor. Having employees work on it full time helps. Despite only having 3 full time employees Ruby has made some pretty impressive improvements recently.
This is really really cool. Thanks for posting. I'm especially interested in memory usage right now. I wrote a way to generate load and measure memory impact on your app: https://github.com/schneems/derailed_benchmarks
From `ps` i'm seeing about ~ 200mb RSS usage where rbkit is only showing ~50mb. I wonder what we could do to increase the accuracy here without having to shell out (very slow).
Also as a note if the gem install fails, on a mac I needed to run this:
$ brew install msgpack
$ brew install zeromq
Then it worked fine. Thanks again! Projects like this get me really excited for a future with faster applications and better informed developers.
I've learned to do this, but for me it wasn't obvious at first. At the end of the day if it's my PR, it's my job to provide the supporting evidence as to why that code should be merged and not some other code. If you respond "no you benchmark it" and they never respond, the ticket can sometimes get stuck in limbo.
This happens so frequently to me. I'll Spend an hour running benchmarks and then post a PR. Someone chimes in and says "method x is faster" with nothing to back it up. I have to benchmark again, and then my way is still faster.
You can also run foreman if you're not on Heroku. Put your environment variables in a `.env` file. The environment variables get sourced only to the environment of that process and not to the __whole__ system
> can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system
Heroku does sponsor Matz, Nobu, and Koichi. We hired them and give them a full time salary to work on Ruby.We don't tell them what to work on (i.e. we don't dictate what features or projects get shipped in what versions) it's more like corporate sponsorship. GitHub hired tmm1. Beyond that CRuby has a host of other non-sponsored contributors that contribute code and doc patches as well as set up tooling. You don't need corporate sponsorship for that, you need a passion and some time. You, in fact, could be the very person that sets up this automated system.
I find the attitude of '<company x> should sponsor <thing y>' a bit misguided. While I agree that companies who profit from a OSS should give forwards to OSS, individual contributors are ultimately they only way progress gets made. If you or someone reading this works for a company making money off of Ruby do that thing! Tell your boss you can't deploy on friday afternoon and have to fix a bug in the Ruby codebase. Ship the project on company time, and then boom...your company just sponsored that thing. It's like magic!
Anywhoo, yes finding out what things are blocking the MRI team from adopting a tool/technology and working around them can be extremely valuable. For example Matz has agreed to move the codebase development to github. This would make contributions a bit easier, however there is a blocker. There are a ton of SVN bots and tooling written around the current workflow. Right now the Ruby core team wants to spend time focusing on pumping out C code to fix bugs, improve performance, and progress the language forwards. They don't want to go off into the woods on tooling. These types of projects could be hugely impactful to the team and don't require C knowledge so most Ruby devs may be able to help. I encourage you and others to reach out to the core team to ask them what tooling projects they need and how we can help them. Understanding why someone isn't using a tool/technology is a really good start.
tldr; Good idea, let's talk to the core team about ways to help with tooling.
2.1 has a totally new GC setup (generational GC). It is guaranteed to use more memory (expect 3~5%), but be MUCH MUCH MUCH faster. Typically you can trade off running one less Puma worker to decrease memory usage, and the increase in speed may make up for it. Alternatively you can bump up to 2x dynos, and cut the number of dynos you have in half. If you haven't tried 2.1.3 or above do yourself a favor and revisit. The 2.1.3 patch means memory grows much more slowly.
Also if you didn't see my post on memory profiling: http://www.schneems.com/2014/11/07/i-ram-what-i-ram.html (It got over 40 upvotes on reddit, and like 3 on HN, again...HN what is going on? I've had much less substantial posts make it front page). That post shows you how to remove ~30% starting RAM (by bumping mail version to 2.6.3+) and shows you can profile and remove libraries that are using a ton of memory in your app.
You can also use something like puma_worker_killer (or unicorn_worker_killer) to tame your memory growth if it only balloons over 512mb after a while, but ultimately those two solutions are bandaids.
Ruby 2.0 isn't going to be supported forever and the generational GC is definitely here to stay. Maybe try the 2.2.0 preview (it's on Heroku), it has 3 generations (total) which means much less retained memory and you still get speed performance improvements.
I see most of the bigger production apps using 2.1+ fwiw.
I don't think they're talking about a released build, but rather building it yourself from source (http://madcoderspeak.blogspot.com/2009/06/how-to-compile-rub...) which is what all mac and linux users do. Even the ruby package managers we use (i.e. ruby-install, rvm, etc.) don't have pre-built binaries, they download tagged source files with checksums and run build commands.
If you're still running a Ruby 2.1.0, 2.1.1, or 2.1.2 (i.e. less than 2.1.3) you're missing out on some killer memory optimizations. I saw huge savings in my production app when i bumped from 2.1.2 to 2.1.3.
