27 ms·

Running GitHub on Rails 6.0

703 points by edmorley 7y ago

lucisferre 7y ago
Perhaps an unpopular take, but what is described in the first paragraph as "smoother, easier and faster" than ever seems to refer to an upgrade process that has been going on for over a year. > As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. > Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits. Once our build for Rails 6.0 was green, we’d merge the pull request to master, and all new code that went into GitHub would need to pass in Rails 5.2 and the newest master build of Rails. Realistically how many hours of work went into this upgrade process then? Edit: I should add I think it really is wonderful that Github contributed so much to the new release and was so involved. I'm just not sure that it is realistic or even ideal for the average Rails consumer to upgrade in this manner.
- AlchemistCamp 7y ago
  > how many hours of work went into this upgrade process then? It's hard to say, but I generally agree with upgrading regularly instead of waiting until you're so far behind that it's an ordeal.
  - atonse 7y ago
    Agreed. The problem happens with convincing your clients to pay you to do so. I have a client that I've been telling for 2+ years to upgrade from Rails 4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+ years of upgrades and it's a huge headache. And at the end of it, if I've done my job correctly, the app will look identical.
    - bdcravens 7y ago
      I would point clients to the Rails support policy, and have the same support policy. https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html
    - KurtMueller 7y ago
      Rails at least has upgrade guides and a script that allows you to upgrade the app. It helps to go from one point relase to the next. I also find the Railsdiff web app helpful in comparing changes from one release to another. It's definitely not perfect or pain free though. I also hope you have a good test suite :). Good luck.
    - ksec 7y ago
      I have been wondering, if it is possible to charge client on yearly upgrade. Or Maintenance fees on a Framework / Security bases. Try to sell it to them like iOS update, you get security update from each framework upgrade. And should this not be a easier sell?
  - aflag 7y ago
    It sounds nice to keep up. But I'm not sure if it's more efficient or not. Do you know about any study on this?
- stevenwoo 7y ago
  That's a good question, but I also appreciate that a company with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they should have said they could have waited but if one has the developer resources, it's better to be proactive instead of waiting for an official release and all of the sudden try to upgrade and run into a lot of unforeseen issues.
- runako 7y ago
  > Realistically how many hours of work went into this upgrade process then? Rails 6 is not a month old yet. What this describes is co-development, over the last year, of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project: > We were able to achieve this level of stability for the upgrade because we were heavily involved with its development. This is not representative of a traditional upgrade.
  - FanaHOVA 7y ago
    And that's for GitHub, the #65 most visited website in the world, just to put it in perspective.
- ulisesrmzroche 7y ago
  This is a big app. It’s a lot different than upgrading toy apps. Is the average rails consumer just making toys?
  - Axsuul 7y ago
    Are you basing the average on one person's experience?
- technoweenie 7y ago
  > Realistically how many hours of work went into this upgrade process then? Eileen wrote about the actual process a year ago when GitHub upgraded from Rails 3.2 -> 5.2: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...
- kenhwang 7y ago
  I just did an upgrade from 4.2 to 6.0 and the process was definitely much smoother than previous Rails upgrades, suspiciously so. Glad people are working on improving the upgrade path because it used to be rather painful.
  - dzader 7y ago
    I just recently did an upgrade from 4.2 to 5.2 and was expecting a lot of pain - turned out it was incredibly simple and pretty much painless. Awesome to hear others are having the same experience!
- dwheeler 7y ago
  It's probably not realistic for the average Rails consumer to constantly run tests against master. Indeed, that's probably true for every framework, not just Rails. But it's definitely excellent for some sites to test against their framework's master branch. If nothing else, that greatly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users). You should have a test suite anyway, so modifying your CI to also run against the master of a key upstream may not be as bad as you think.
- mokkol 7y ago
  While they were upgrading, Github added a lot of their own core features into Rails itself. Like multiple databases supported by default, parallel tests for a much faster test suite. Github didnt just upgrade their Rails version, they upgraded Rails itself partly.
aflag 7y ago
I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a while?
- beaniebabies 7y ago
  I also update the npm packages for a small website weekly. It's much easier fixing a few occasional breaking changes than waiting for a year and then having a massive headache since nothing will compile/work anymore.
- timdorr 7y ago
  Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don't have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error prone. It's worthwhile to keep up to date. It's probably not worthwhile to upgrade ASAP after a release, but you don't want to wait too long.
- rhizome 7y ago
  I tell you what, say what you will about having plenty of warning, but right now I'm big-bang-ishly updating an app to 5.2 and I'm mired in quicksand due to the death of both bourbon/neat (removal of the most interesting functionality) and paperclip.
  - jrochkind1 7y ago
    I agree that conflicts/integrations between dependencies tend to give more upgrade pain than conflicts with local code and a single dependency. I think probably exactly how often to upgrade all your dependencies on what schedule... depends on the particular product and organization and resource-richness. What Github's did, upgrading Rails _daily_ to the latest non-release master... sounds really attractive if you can do it, but I suspect most people can't. A step on the way would be just `bundle update`ing daily and making sure to keep up with always having that passing and deployed. (Although in Github's case I don't think the actually deployed with dependency on unrelased master). I don't actually really even do that, def haven't automated it (although it occurs to me it would be simple to automate on travis or probably equivalent).
IfOnlyYouKnew 7y ago
Rails 6 really is a well-rounded update. It seems the new trend goes towards "bare-bones" http servers, but I'm insanely productive in a Rails app, even if it's one I have not worked on before. I've seen quite a lot of "Rails-hate" over the last view years, and it can only be coming from people who never got to experience the world that was web development before Rails: Every project had it's own, usually quite creative, structure. There'd be configuration values in `config.inc.php`, but also in `configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by establishing a standard folder structure, DHH probably made web devs everywhere twice as productive. I also think its reputation of being too restricting isn't entirely deserved. As but one example: I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others. So here' to hoping for another 6 good releases at least!
- _hardwaregeek 7y ago
  It's also interesting how people have gone backwards in terms of convention. As far I know, there's no standard convention for JavaScript server layouts (maybe server.js, but I've seen stuff in index.js or main.js). Likewise there's no standard way to plug in servers like Rack. Or a standard ORM in the JS world. I figured conventions would come with maturity but the JS world is getting mature and yet there's not many conventions
  - eropple 7y ago
    Rack is cool, but the modern approach seems to be more decoupled web servers. You rarely see multiple business-logic Rack servers in a single process anyway though; Rack servers outside your primary business logic tend to be used more like Express middlewares in Node (which are very conventional at this point). And the standard entry point for a NodeJS package is "whatever is defined as the main property in your package.json." Do otherwise at your peril.
  - baroffoos 7y ago
    I found this to be true when building a SPA. On rails I am already told the best place to put things but on the JS side its just "do whatever you want" so I try something and find out later that it wasn't a great way to do things so I am just wasting my time working out the best way to organize a project. I also have to deal with index files that just import every single component for the frontend when on rails this kind of stuff is auto generated.
crispyporkbites 7y ago
Rails is so productive and powerful these days that if you’re building a web app you need a really, really good reason not to use it
- bureaucrat 7y ago
  How is Rails compared to Django?
  - creyes 7y ago
    Different philosophies. I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. There are gem's out there that support almost everything you want to do and if there's not there are resources from people who have had to solve similar problems.
    - hnarayanan 7y ago
      And by the same token, outside the context of "web stuff," Python generally has wider set of domain-specific packages (e.g. ML) you can easily incorporate into your web app.
    - staz 7y ago
      > Rails has a much bigger ecosystem and more developers than Django does. [citation needed]
    - qudat 7y ago
      > I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. Going to have to disagree with you there.
  - chipotle_coyote 7y ago
    More similar than different in a lot of ways, but I suspect the differences come out of their background. Rails was originally developed by a consulting company for both client work and their own apps, so it really emphasizes rapid development -- it pushes convention over configuration very hard, had database migrations from its first version (Django didn't get those for years, etc.). Django came out of a newspaper (the Lawrence-World Journal), and seems really optimized for building custom CMSes -- there's nothing I've found in any other system that's truly like Django's admin console, for instance. (Another sign of its newspaper heritage: it's the only template language I've ever seen whose date filter has extensions to match Associated Press style!)
antimatter 7y ago
It's been a long time since I've looked at Rails. Is there anything similar to Railscasts (free or paid) but up to date with latest Rails features?
- Hates_ 7y ago
  GoRails (https://gorails.com/ https://gorails.com/) is probably the most similar to Railscasts but which covers more up to date features.
- ezekg 7y ago
  There is https://gorails.com/ https://gorails.com/, which I'd highly recommend.
- geospeck 7y ago
  Drifting Ruby is another one https://www.driftingruby.com/episodes https://www.driftingruby.com/episodes
- dcchambers 7y ago
  I used https://www.railstutorial.org/ https://www.railstutorial.org/ when I learned Rails - the Author is updating it to Rails 6 (Draft now available: https://news.learnenough.com/ruby-on-rails-6th-edition-draft https://news.learnenough.com/ruby-on-rails-6th-edition-draft)
- wastedhours 7y ago
  Alongside the excellent recommendations for GoRails in the other comments, also look into the host's other Rails projects: Jumpstart Pro [0] as a template and Hatchbox for easy deployment. This corner of the Rails ecosystem is really nice, positive, and easy. [0] https://jumpstartrails.com/ https://jumpstartrails.com/ [1] https://www.hatchbox.io/ https://www.hatchbox.io/
SnowingXIV 7y ago
Running two production applications on 5.1.5. It works swimmingly and I rarely need to touch it except for some additional feature requests or tweaks. Is it worth the headache of upgrading to 6.0? I'm looking at the change log and deprecations and nothing stands out as an issue but I think I still need to do 5.1.5 to 5.2 then to 6.0. Not to mention I'm not going to utilize any of the new upgrades.
- cullenking 7y ago
  Keeping your app up to date if you have any significant quantity of third party gems, is really nice. Meaning, if you need to upgrade, it's easier to stay on top of it than it is to pull an app from say, 4.2 to 6.0. This becomes particularly problematic a few years down the road, for security updates.
  - SnowingXIV 7y ago
    That's the other concern, right now all the gems play nice together without issue. It's possible that some of the older gems are supported under 5.x and haven't made the required changes for 6.0.
    - bluedino 7y ago
      It's like upgrading Wordpress. Some plugin that the client LOVES doesn't work with teh newest version of WP because it's been abandoned.
- rhizome 7y ago
  Always upgrade by minor revision, since that's where the additions, deprecations, and removals happen.
- ufmace 7y ago
  I'd say it's worth doing, unless you intend to spin down the app entirely in a couple of years, just for the sake of security updates. You don't want to be in a situation where there's a vulnerability announced, and you can't pick up a fix without updating 6 versions, with all of the headaches that brings. It's worth devoting a few % of time here and there to bumping everything to the latest version and fixing any issues that come up, and maybe trying to move things that had been using external gems to any new internal processes that cover the same tasks.
sellingwebsite 7y ago
My comment on one of the previous discussions: I don't want to start a flame war here, but I think Rails (and gem ecosystem in general) is a better choice than Django, at least for SaaS apps. These are all my personal opinions, take it with a grain of salt. Having said that, here we go: * Authentication - it is a pain if you'd like to deviate from the standard Django User model (using username to login instead of an email). I don't like Devise either. * Asset pipeline, even though it is not updated anymore (sprockets) and partially replaced by the webpacker, is still better in Rails * Configuration spread across multiple files, by environment, instead of a single config.py file * Sidekiq has a better API compared to Celery. Also, Celery's default broker is RabbitMQ, not Redis. It is really hard to find managed RabbitMQ hosting, for Redis there are plenty * Mailer previews, small but quite useful utility * Better security by default: Rails comes pre-configured with a bunch of security headers[0]. * Testing - Minitest and Capybara is just a joy to work with. * I prefer ActiveRecord over Django ORM * Rails isn't afraid to deprecate things and move forward. This isn't the case with Django, which is big on backwards compatibility. I don't like it, since it puts into a disadvantage folks who are starting new projects. Different strokes for different folks, I suppose I could go on and on, but I remember struggling a lot with Django/Celery when building a SaaS app. I decided to switch to Rails and haven't looked back (Rails has its warts as well). YMMV [0] https://guides.rubyonrails.org/security.html#default-headers https://guides.rubyonrails.org/security.html#default-headers EDIT: Added last point about backwards compatibility
- yagodragon 7y ago
  Is rails really that good? I feel so confused and paralyzed trying to find a modern backend framework. I've almost settled to Python+Django because it enforces good practices,has great tools like Django Rest Framework and Python is a language with huge application field. On the other hand, laravel and rails have so strong communities and feel more modern (for example, integration with front end frameworks). Django just seems left behind. So the question boils down to this: Should I invest my time learning django in 2019?
  - sellingwebsite 7y ago
    ça dépend. I am only familiar with Django and Rails, can't comment about Laravel. If you are building a basic CRUD app, definitely stick with Rails. If you are doing some kind of CMS or need machine learning pipeline, go with Python. A warning about Ruby/Rails: some folks have moved on to shinier languages/frameworks and as a result there are lots of unmaintained gems (gems are 3rd party libraries in the Ruby world) out there. For instance, I needed a curl wrapper written in Ruby. Nothing worked for me so I ended up forking Ethon [0]. I am hesitant to send PRs, since I doubt that they will get merged. Now I am maintaining two codebases at once. I will probably rewrite it from scratch at some time. A warning about Python/Django: dependency management is kind of a mess [1]. See linked discussions [2][3][4][5]. [0] https://github.com/typhoeus/ethon https://github.com/typhoeus/ethon [1] https://xkcd.com/1987/ https://xkcd.com/1987/ (Add pipenv and poetry to the mix) [2] https://news.ycombinator.com/item?id=20672436 https://news.ycombinator.com/item?id=20672436 [3] https://news.ycombinator.com/item?id=18612590 https://news.ycombinator.com/item?id=18612590 [4] https://news.ycombinator.com/item?id=17607083 https://news.ycombinator.com/item?id=17607083 [5] https://news.ycombinator.com/item?id=13459740 https://news.ycombinator.com/item?id=13459740
ezekg 7y ago
I've actually been having some trouble upgrading from 5.2 to 6.0. I initially tried upgrading to 6.rc1 but hit a few road blocks, then tried 6.rc2 and just had too many odd errors and I eventually put that on the back burner. Maybe I'll go back and revisit, but I had tests failing that I wouldn't initially expect to fail, such as random unicode errors, broken mailers, and some odd 404s. I may try to upgrade to 6.0, but also kind of feel like waiting until 6.1 is out may be a better option. (I don't think GitHub talking about their 'smooth update' is fair, given they've essentially been upgrading to 6.0 since 5.2 released.)
deleted 7y ago
[deleted]
thrownaway954 7y ago
I have to wait for the MicrosoftSQLServer Adapter to be upgraded before I can upgrade :(
pizza234 7y ago
I wish they would be so keen on migrating to MySQL 8.0 as well :-) Their (amazing) tool Gh-ost is broken on MySQL 8.0, which suggests that they're still based on 5.7. It's a big issue for my company (and I guess for any mid-sized company), since at mid-sized companies the schema is likely big enough to have slow migrations, but not big enough to have fancy replication topologies. For such cases, there's nothing like Gh-ost :-)
- geerlingguy 7y ago
  So far I haven't seen many people switching to MySQL 8... almost every example and app I've seen in the wild is on 5.6 or 5.7, or switched to MariaDB (or more infrequently, Postgres).
  - pizza234 7y ago
    Well, if we put it this way, the same could be said of Rails 6. I understand their plans of course, and that's why I expressed it as wish. Regarding MariaDB or PostgreSQL, can you enumerate/detail the app you've seen switching? Is it the, say, 1/2% area of all the projects? 5%? Probably, in the low one-digit percentage, there are switches toward anything. I'm somewhat skeptical any non-trivial projects undertaking this kind of change. GitLab (to mention a large one) didn't really switch, as they were supporting both.
    - qiqitori 7y ago
      When you install 'mysql'/'mysqld' in Debian or RHEL7+-based distros, you get MariaDB... So staying with MySQL and not "switching" to MariaDB is a lot more effort. (MariaDB is a fork of MySQL and the binaries and everything even have mysql in the name so everything just works. I'd assume there might be some divergence in newer features, but I haven't noticed anything in that regard.)
- caseyf 7y ago
  You've probably considered it and selected gh-ost instead but pt-online-schema-change from Percona Toolkit works great with 8.0
phodo 7y ago
How does one connect a rails 6 app to a python tensor flow (inference) model?
- aledalgrande 7y ago
  Using a client to connect to a prediction HTTP service would be my choice (Flask app?). Otherwise if you want to you can do something with the backticks, which will run a shell process from Ruby and get the return value: `python3 predict.py <input>`
- nurettin 7y ago
  Like you connect anything to anything else. You use a myriad of Inter-process communication techniques from memory maps to named pipes to socket protocols to databases.
- GolDDranks 7y ago
  You deploy the Python model to a backend service and expose a simple HTTP-based API, maybe using Flask? You should preferably keep the web part and heavy lifting separate.
- ssaunier_ 7y ago
  As suggested, encapsulate your prediction model in a web service, then calling it from Rails would be a good way to go. An other way is to use something like Faktory (https://contribsys.com/faktory/ https://contribsys.com/faktory/) on top of Redis. You push jobs from Rails and then you pull them from Python to execute. Then Python can enqueue another job with the result which gets consumed by Rails (async callback).
juliendc 7y ago
I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app. I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box. The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers. Hope they will ship many more releases!
- tsotpsstt 7y ago
  Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems. It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.
  - freehunter 7y ago
    I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.
    - dzader 7y ago
      Yeah, I am extremely excited about this - small sample size but I've worked on a handful of rails apps and I seem to always need a WYSIWYG editor and could never find one I really liked - glad to see it better incorporated!
EsssM7QVMehFPAs 7y ago
What about security? Constantly pulling unreviewed code just because it passes unit or e2e tests does not sound like the ideal choice to me.
- _bxg1 7y ago
  Presumably this was only in their testing environment, not production.
- wlll 7y ago
  Code that gets merged into Rails master is reviewed by the Rails core team.
  - jrochkind1 7y ago
    And indeed how much of that code gets significantly _more_ review after it's merged and before release? Some of it. But yeah, I don't think they were releasing based on unreleased Rails master. Just running CI, and keeping it passing.
_bxg1 7y ago
Wow, didn't know a company this recognizable was still using (and embracing!) Rails. Pretty cool. Also helps explain the fact that they've stuck with a mostly server-side-rendered app, despite it being a fairly complex tool.
- HatchedLake721 7y ago
  Why “still” and “stuck”?
  - jaimex2 7y ago
    ignorance
- jrochkind1 7y ago
  The perceived performance of Github as I use it as good as any site I use and better than most, so to the extent that's a consideration in client vs server rendered (and it probably should be a big one), it seems to be working.
- jdance 7y ago
  The new sites with their own implemented loading bars are just super annoying to use. Sometimes they just stall and look stupid. State is bad! Stateless page loads work! Dont use SPAs unless you do something that looks like a desktop app! Please!
- shantly 7y ago
  > Also helps explain the fact that they've stuck with a mostly server-side-rendered app, despite it being a fairly complex tool. Probably why it's remained tolerably snappy and light on resources while the "SPA" world so rarely delivers the same.
- _bxg1 7y ago
  People are so sensitive about this. I wasn't suggesting that server-side rendering is bad, only that they're going against a trend. Settle down.
xvilka 7y ago
They should sponsor also the proper JIT in Ruby, will improve the speed drastically. Not the current generation of C code then compiling it with GCC, this is a joke.
- steveklabnik 7y ago
  I'm not sure who is working on JIT stuff in Ruby, but GitHub does employ people to work on Ruby itself, notably Aaron Patterson.
- jashmatthews 7y ago
  It's very easy to criticize and very hard to do better within the same constraints. Vladimir Makarov from the GCC team built the prototype. This was not the result of inexperience but a pragmatic choice. As a side note, JRuby has had a production ready JIT since 2015.
- save_ferris 7y ago
  How I dream of more serious sponsorship in the ruby community. I think people underestimate how much python shops are suffering right now over the V2 to V3 transition. I recently turned down a gig that was basically just going to be upgrading python services for the next several months. I've personally preferred much of ruby's tooling and package management to Python's, and I've always hoped that bigger money would come into the community. That said, Ruby has done incredible, not knocking the accomplishments of the community in any way.
  - cutler 7y ago
    What happened to IBM? A few years ago they were all in on supporting Ruby. Next I heard they were betting the company on Swift.
    - save_ferris 7y ago
      No idea, but nothing really planned out as far as I’m aware. It’s great to see companies like Github, Stripe and Shopify make major contributions to the community, but having a relationship like Google and Guido have would’ve elevated the community to another level.
aledalgrande 7y ago
If you are struggling to find a way to subscribe to the blog, I found the Atom feed: https://github.blog/subscribe/ https://github.blog/subscribe/ It is not linked anywhere I can see on the main page.
jinushaun 7y ago
Sounds like they upgraded directly from a custom fork of 3.2 to 6.0, but if you read the article, they upgraded from 5.2 to 6.0. Not as insane as 3->6, but 3->5 is still pretty insane.
thebiglebrewski 7y ago
Eileen is a legend! Amazing work over there!
breatheoften 7y ago
Why do people like coding in a system where you can cmd-click on almost nothing to get to any useful information about what the code does ...?
- save_ferris 7y ago
  Because (good) ruby is elegant enough to be self-documenting and informative on its own without needing go look somewhere else to figure out what it does.
  - jrochkind1 7y ago
    I think you get those command-click references via static analysis for ruby in, uh, RubyMine? Some people swear by it. For just that reason. I have never used it. I am willing to consider that maybe if I did, I'd come to like it so much I'd never want to do without it. (There was a point I didn't think I needed syntax highlighting, now I know I read/understand code so much quicker with it, at least in ruby). Does VB Studio maybe give you it for free too? Not sure. Not sure how good these features are. Can't say why I and I think the majority of ruby devs don't try em.
- dvogel 7y ago
  Considering MacOS share of developers is around ~30%, most developers can't cmd-click :) Seriously though, there's whole camps of developers who don't use an IDE. Some people are just more productive keeping a model in their head and relying on other tools (test, linters, repl experiments) to safeguard against their own misunderstandings. Source: https://insights.stackoverflow.com/survey/2019#development-environments-and-tools https://insights.stackoverflow.com/survey/2019#development-e...
- codeisawesome 7y ago
  No idea why you’re being downvoted grey on a legit question. I’ve seen at least one project where it’s unreasonably hard to introspect rails code even using IDE tooling.
- baroffoos 7y ago
bigwheeler 7y ago
A front page Rails-related post that doesn’t have a single comment about rails scaling issues, 8 entire hours after submission?! It’s a good time to be alive!!
- wastedhours 7y ago
  Very hard for people to complain about scale when the post's coming direct from GitHub!
developer2 7y ago
I'm going to stick my neck out as someone who has refused to even consider Rails over a span of many years, for one simple reason: it permits session fixation. If a client's cookie says "I am session token 'abc123'", it will create that session id out of thin air. As in, it will create that session id without it having had to be generated previously. Your memcached/redis does not have an entry for session 'abc123', but Rails will happily create it. The developers who allowed this situation to occur should not be permitted to be employed in our industry. Yes, it's that bad and I am that serious. You can, not kidding, set your cookie's value to ANY VALUE YOU WANT, and the codebase is entirely willing to unconditionally create that session with whatever value the attacker chooses. Hint: if a client sends session id "abc123", then you should check for the existence of that session id. If the key is not set, you either a) show an error page, or b) create a completely new session id, ignoring the client's requested session id. It is NEVER, EVER, EVER... I am saying __NEVER__, __EVER__ acceptable to create a session id based on client-provided data. And yet, this is what Rails does out of the box. Edit: Downvote me more, I don't care. The fact is that Rails' developers are amateurs. Rails is insecure out of the box. That is a fact.
- excid3 7y ago
  The countermeasures to session fixation are covered in the official Rails guides: https://guides.rubyonrails.org/security.html#session-fixation-countermeasures https://guides.rubyonrails.org/security.html#session-fixatio...
  - developer2 7y ago
    Why is that an opt-in option? No codebase should ever be willing to create a session id (any db/cache id/key) based on request details. The fact you have to opt in to a very basic security measure is, once again, a joke. Let's be clear: by default, Rails is willing to assign a client any session id based on its own request?!?! Based on the other reply to my comment... no I'm not OK. I am not OK with Rails' pathetic attempts at the most basic level of security. Rails' developers are fucking amateurs. I'm sorry, but that's pure fact. Rails' developers don't know the first thing about the HTTP protocol. NOBODY EVER CREATES A DB/CACHE KEY BASED ON THE VALUE OF A CLIENT-PROVIDED COOKIE (or unvalidated GET/POST). Anyone who argues against this should be permanently banned from IT/Technology. Just... fuck off... you have no clue.
dzonga 7y ago
unpopular opinion, but the reason people chose node.js is because for some dense folks like me it's easier to reason about and understand how everything works. the tooling is abysmal compared to rails, django & laravel. but at least I know how my app works from top to bottom. you take a productivity hit in your first node.js project but after that you would've collected / curated your own personal tools/libraries. and hell yeah spinning an api that does whatever you want is easy as hell. much respect to dhh though
- moksly 7y ago
  I’m not sure your opinion is unpopular, but I have a hard time following your logic. Isn’t part of why a solid and curated framework makes perfect sense (and make you more productive) exactly that you don’t have to understand everything that’s going on? I have a decent understanding of what lies beneath linq in C# for instance, but that’s because I’m curious by nature and not because I had to know it to utilise it. I mean, I guess you could argue that people should know what’s going on, but the truth is that 90% of software development doesn’t require you to, if you pick the right tools. I think this is a primary reason node.js never really picked up. No one wants to spend time building and maintain the wheel when you can get a trusted entity to do it for you. You may find the part about node not picking up odd, but if I look at job-listings for my entire country there is almost zero postings for a node backend.
- danmaz74 7y ago
  If that's your concern, you can learn how the internals of rails (or django) work. Not being forced to do that doesn't mean you can't do it regardless :)
- bradstewart 7y ago
  But by the time "you would've collected / curated your own personal tools/libraries", you could have learned how Rails works.
adreamingsoul 7y ago
I loved working with Ruby, and RoR. All my completed side projects used RoR. Ironically, I do have a couple incomplete side projects that used NodeJS. I never understood why RoR recieved so much hate in the tech community, or from CTOs. Glad to see a prominent service like Github continue to use RoR.
- danmaz74 7y ago
  Every successful project is going to get hate from somebody; if anything else, those who don't like some of the choices of said new successful project will be worried to be forced into them, and some will react finding any possible reason to stop the momentum.
dvcrn 7y ago
This is very interesting. In my bubble I thought the trend was going away from full fledged batteries included frameworks and more towards “hand pick your few specific libraries” with Go, Java and what not. Looking into the comments here, I guess I as wrong. It’s refreshing to see a big company writing about Rails
- fogetti 7y ago
  It was also just a year ago when Stripe released a static type checker for Ruby: https://sorbet.org/ https://sorbet.org/ Only haters think that Ruby and Ruby on Rails is dead end
- aantix 7y ago
  When the pieces are isolated, integration becomes a big portion of the development work. It's one of the reasons that Rails makes so many choices/opinions for the developer upfront. DHH discusses the costs of integration in this interview. https://devchat.tv/ruby-rogues/rr-428-arming-the-rebels-with-rails-6-featuring-david-heinemeier-hansson/ https://devchat.tv/ruby-rogues/rr-428-arming-the-rebels-with...
hoaxgaming 7y ago
Nice
tomerbd 7y ago
Long live rails! And this is from a java-spring developer.
nickjj 7y ago
Every time a Rails link appears on the home page it's filled with a bunch of technical reasons on why Rails is good and then there's a bunch of posts about how other frameworks might be better. These are healthy discussions IMO. But I think a lot of people overlook that one of the main reasons why Rails is so good / popular is that you get to see posts like the one we're looking at: Running GitHub on Rails 6.0 There's not too many other frameworks where there's a really strong track record of it running really popular sites (github, shopify, basecamp, airbnb). Not only are they popular, but they are well done sites that are pretty tech friendly. It just gives a sense of confidence that it will work for your small / large app and you don't get that with most other frameworks. Knowing that billions of page views have been through the framework irons out so many edge cases. Both bugs and performance issues, and you often get that perk on day 1 when a new release is out because it's already been running on basecamp for months (and maybe other big sites too). I mean check out this quote from the article: > GitHub engineers sent over 100 pull requests to Rails 6.0 to improve documentation, fix bugs, add features, and speed up performance. Combine that with the Rails approach of batteries included and you know that the core of your app is in good hands. You can't really go too wrong by using it along with a few well maintained gems.
- k__ 7y ago
  True. dev.to runs on Rails too. Currently I'm looking into AWS Amplify, which tries to be the Rails of serverless. Building a serverless app as you would build a monolithic app sounds intriguing to me.

703 points by edmorley 7y ago

Perhaps an unpopular take, but what is described in the first paragraph as "smoother, easier and faster" than ever seems to refer to an upgrade process that has been going on for over a year. > As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. > Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits. Once our build for Rails 6.0 was green, we’d merge the pull request to master, and all new code that went into GitHub would need to pass in Rails 5.2 and the newest master build of Rails. Realistically how many hours of work went into this upgrade process then? Edit: I should add I think it really is wonderful that Github contributed so much to the new release and was so involved. I'm just not sure that it is realistic or even ideal for the average Rails consumer to upgrade in this manner.

AlchemistCamp 7y ago
> how many hours of work went into this upgrade process then? It's hard to say, but I generally agree with upgrading regularly instead of waiting until you're so far behind that it's an ordeal.
- atonse 7y ago
  Agreed. The problem happens with convincing your clients to pay you to do so. I have a client that I've been telling for 2+ years to upgrade from Rails 4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+ years of upgrades and it's a huge headache. And at the end of it, if I've done my job correctly, the app will look identical.
  - bdcravens 7y ago
    I would point clients to the Rails support policy, and have the same support policy. https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html
  - KurtMueller 7y ago
    Rails at least has upgrade guides and a script that allows you to upgrade the app. It helps to go from one point relase to the next. I also find the Railsdiff web app helpful in comparing changes from one release to another. It's definitely not perfect or pain free though. I also hope you have a good test suite :). Good luck.
  - ksec 7y ago
    I have been wondering, if it is possible to charge client on yearly upgrade. Or Maintenance fees on a Framework / Security bases. Try to sell it to them like iOS update, you get security update from each framework upgrade. And should this not be a easier sell?
- aflag 7y ago
  It sounds nice to keep up. But I'm not sure if it's more efficient or not. Do you know about any study on this?
stevenwoo 7y ago
That's a good question, but I also appreciate that a company with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they should have said they could have waited but if one has the developer resources, it's better to be proactive instead of waiting for an official release and all of the sudden try to upgrade and run into a lot of unforeseen issues.
runako 7y ago
> Realistically how many hours of work went into this upgrade process then? Rails 6 is not a month old yet. What this describes is co-development, over the last year, of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project: > We were able to achieve this level of stability for the upgrade because we were heavily involved with its development. This is not representative of a traditional upgrade.
- FanaHOVA 7y ago
  And that's for GitHub, the #65 most visited website in the world, just to put it in perspective.
ulisesrmzroche 7y ago
This is a big app. It’s a lot different than upgrading toy apps. Is the average rails consumer just making toys?
- Axsuul 7y ago
  Are you basing the average on one person's experience?
technoweenie 7y ago
> Realistically how many hours of work went into this upgrade process then? Eileen wrote about the actual process a year ago when GitHub upgraded from Rails 3.2 -> 5.2: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...
kenhwang 7y ago
I just did an upgrade from 4.2 to 6.0 and the process was definitely much smoother than previous Rails upgrades, suspiciously so. Glad people are working on improving the upgrade path because it used to be rather painful.
- dzader 7y ago
  I just recently did an upgrade from 4.2 to 5.2 and was expecting a lot of pain - turned out it was incredibly simple and pretty much painless. Awesome to hear others are having the same experience!
dwheeler 7y ago
It's probably not realistic for the average Rails consumer to constantly run tests against master. Indeed, that's probably true for every framework, not just Rails. But it's definitely excellent for some sites to test against their framework's master branch. If nothing else, that greatly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users). You should have a test suite anyway, so modifying your CI to also run against the master of a key upstream may not be as bad as you think.
mokkol 7y ago
While they were upgrading, Github added a lot of their own core features into Rails itself. Like multiple databases supported by default, parallel tests for a much faster test suite. Github didnt just upgrade their Rails version, they upgraded Rails itself partly.

aflag 7y ago

I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a while?

beaniebabies 7y ago
I also update the npm packages for a small website weekly. It's much easier fixing a few occasional breaking changes than waiting for a year and then having a massive headache since nothing will compile/work anymore.
timdorr 7y ago
Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don't have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error prone. It's worthwhile to keep up to date. It's probably not worthwhile to upgrade ASAP after a release, but you don't want to wait too long.
rhizome 7y ago
I tell you what, say what you will about having plenty of warning, but right now I'm big-bang-ishly updating an app to 5.2 and I'm mired in quicksand due to the death of both bourbon/neat (removal of the most interesting functionality) and paperclip.
- jrochkind1 7y ago
  I agree that conflicts/integrations between dependencies tend to give more upgrade pain than conflicts with local code and a single dependency. I think probably exactly how often to upgrade all your dependencies on what schedule... depends on the particular product and organization and resource-richness. What Github's did, upgrading Rails _daily_ to the latest non-release master... sounds really attractive if you can do it, but I suspect most people can't. A step on the way would be just `bundle update`ing daily and making sure to keep up with always having that passing and deployed. (Although in Github's case I don't think the actually deployed with dependency on unrelased master). I don't actually really even do that, def haven't automated it (although it occurs to me it would be simple to automate on travis or probably equivalent).

IfOnlyYouKnew 7y ago

Rails 6 really is a well-rounded update. It seems the new trend goes towards "bare-bones" http servers, but I'm insanely productive in a Rails app, even if it's one I have not worked on before. I've seen quite a lot of "Rails-hate" over the last view years, and it can only be coming from people who never got to experience the world that was web development before Rails: Every project had it's own, usually quite creative, structure. There'd be configuration values in `config.inc.php`, but also in `configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by establishing a standard folder structure, DHH probably made web devs everywhere twice as productive. I also think its reputation of being too restricting isn't entirely deserved. As but one example: I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others. So here' to hoping for another 6 good releases at least!

_hardwaregeek 7y ago
It's also interesting how people have gone backwards in terms of convention. As far I know, there's no standard convention for JavaScript server layouts (maybe server.js, but I've seen stuff in index.js or main.js). Likewise there's no standard way to plug in servers like Rack. Or a standard ORM in the JS world. I figured conventions would come with maturity but the JS world is getting mature and yet there's not many conventions
- eropple 7y ago
  Rack is cool, but the modern approach seems to be more decoupled web servers. You rarely see multiple business-logic Rack servers in a single process anyway though; Rack servers outside your primary business logic tend to be used more like Express middlewares in Node (which are very conventional at this point). And the standard entry point for a NodeJS package is "whatever is defined as the main property in your package.json." Do otherwise at your peril.
- baroffoos 7y ago
  I found this to be true when building a SPA. On rails I am already told the best place to put things but on the JS side its just "do whatever you want" so I try something and find out later that it wasn't a great way to do things so I am just wasting my time working out the best way to organize a project. I also have to deal with index files that just import every single component for the frontend when on rails this kind of stuff is auto generated.

crispyporkbites 7y ago

Rails is so productive and powerful these days that if you’re building a web app you need a really, really good reason not to use it

bureaucrat 7y ago
How is Rails compared to Django?
- creyes 7y ago
  Different philosophies. I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. There are gem's out there that support almost everything you want to do and if there's not there are resources from people who have had to solve similar problems.
  - hnarayanan 7y ago
    And by the same token, outside the context of "web stuff," Python generally has wider set of domain-specific packages (e.g. ML) you can easily incorporate into your web app.
  - staz 7y ago
    > Rails has a much bigger ecosystem and more developers than Django does. [citation needed]
  - qudat 7y ago
    > I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. Going to have to disagree with you there.
- chipotle_coyote 7y ago
  More similar than different in a lot of ways, but I suspect the differences come out of their background. Rails was originally developed by a consulting company for both client work and their own apps, so it really emphasizes rapid development -- it pushes convention over configuration very hard, had database migrations from its first version (Django didn't get those for years, etc.). Django came out of a newspaper (the Lawrence-World Journal), and seems really optimized for building custom CMSes -- there's nothing I've found in any other system that's truly like Django's admin console, for instance. (Another sign of its newspaper heritage: it's the only template language I've ever seen whose date filter has extensions to match Associated Press style!)

antimatter 7y ago

It's been a long time since I've looked at Rails. Is there anything similar to Railscasts (free or paid) but up to date with latest Rails features?

Hates_ 7y ago
GoRails (https://gorails.com/ https://gorails.com/) is probably the most similar to Railscasts but which covers more up to date features.
ezekg 7y ago
There is https://gorails.com/ https://gorails.com/, which I'd highly recommend.
geospeck 7y ago
Drifting Ruby is another one https://www.driftingruby.com/episodes https://www.driftingruby.com/episodes
dcchambers 7y ago
I used https://www.railstutorial.org/ https://www.railstutorial.org/ when I learned Rails - the Author is updating it to Rails 6 (Draft now available: https://news.learnenough.com/ruby-on-rails-6th-edition-draft https://news.learnenough.com/ruby-on-rails-6th-edition-draft)
wastedhours 7y ago
Alongside the excellent recommendations for GoRails in the other comments, also look into the host's other Rails projects: Jumpstart Pro [0] as a template and Hatchbox for easy deployment. This corner of the Rails ecosystem is really nice, positive, and easy. [0] https://jumpstartrails.com/ https://jumpstartrails.com/ [1] https://www.hatchbox.io/ https://www.hatchbox.io/

SnowingXIV 7y ago

Running two production applications on 5.1.5. It works swimmingly and I rarely need to touch it except for some additional feature requests or tweaks. Is it worth the headache of upgrading to 6.0? I'm looking at the change log and deprecations and nothing stands out as an issue but I think I still need to do 5.1.5 to 5.2 then to 6.0. Not to mention I'm not going to utilize any of the new upgrades.

cullenking 7y ago
Keeping your app up to date if you have any significant quantity of third party gems, is really nice. Meaning, if you need to upgrade, it's easier to stay on top of it than it is to pull an app from say, 4.2 to 6.0. This becomes particularly problematic a few years down the road, for security updates.
- SnowingXIV 7y ago
  That's the other concern, right now all the gems play nice together without issue. It's possible that some of the older gems are supported under 5.x and haven't made the required changes for 6.0.
  - bluedino 7y ago
    It's like upgrading Wordpress. Some plugin that the client LOVES doesn't work with teh newest version of WP because it's been abandoned.
rhizome 7y ago
Always upgrade by minor revision, since that's where the additions, deprecations, and removals happen.
ufmace 7y ago
I'd say it's worth doing, unless you intend to spin down the app entirely in a couple of years, just for the sake of security updates. You don't want to be in a situation where there's a vulnerability announced, and you can't pick up a fix without updating 6 versions, with all of the headaches that brings. It's worth devoting a few % of time here and there to bumping everything to the latest version and fixing any issues that come up, and maybe trying to move things that had been using external gems to any new internal processes that cover the same tasks.

sellingwebsite 7y ago

My comment on one of the previous discussions: I don't want to start a flame war here, but I think Rails (and gem ecosystem in general) is a better choice than Django, at least for SaaS apps. These are all my personal opinions, take it with a grain of salt. Having said that, here we go: * Authentication - it is a pain if you'd like to deviate from the standard Django User model (using username to login instead of an email). I don't like Devise either. * Asset pipeline, even though it is not updated anymore (sprockets) and partially replaced by the webpacker, is still better in Rails * Configuration spread across multiple files, by environment, instead of a single config.py file * Sidekiq has a better API compared to Celery. Also, Celery's default broker is RabbitMQ, not Redis. It is really hard to find managed RabbitMQ hosting, for Redis there are plenty * Mailer previews, small but quite useful utility * Better security by default: Rails comes pre-configured with a bunch of security headers[0]. * Testing - Minitest and Capybara is just a joy to work with. * I prefer ActiveRecord over Django ORM * Rails isn't afraid to deprecate things and move forward. This isn't the case with Django, which is big on backwards compatibility. I don't like it, since it puts into a disadvantage folks who are starting new projects. Different strokes for different folks, I suppose I could go on and on, but I remember struggling a lot with Django/Celery when building a SaaS app. I decided to switch to Rails and haven't looked back (Rails has its warts as well). YMMV [0] https://guides.rubyonrails.org/security.html#default-headers https://guides.rubyonrails.org/security.html#default-headers EDIT: Added last point about backwards compatibility

yagodragon 7y ago
Is rails really that good? I feel so confused and paralyzed trying to find a modern backend framework. I've almost settled to Python+Django because it enforces good practices,has great tools like Django Rest Framework and Python is a language with huge application field. On the other hand, laravel and rails have so strong communities and feel more modern (for example, integration with front end frameworks). Django just seems left behind. So the question boils down to this: Should I invest my time learning django in 2019?
- sellingwebsite 7y ago
  ça dépend. I am only familiar with Django and Rails, can't comment about Laravel. If you are building a basic CRUD app, definitely stick with Rails. If you are doing some kind of CMS or need machine learning pipeline, go with Python. A warning about Ruby/Rails: some folks have moved on to shinier languages/frameworks and as a result there are lots of unmaintained gems (gems are 3rd party libraries in the Ruby world) out there. For instance, I needed a curl wrapper written in Ruby. Nothing worked for me so I ended up forking Ethon [0]. I am hesitant to send PRs, since I doubt that they will get merged. Now I am maintaining two codebases at once. I will probably rewrite it from scratch at some time. A warning about Python/Django: dependency management is kind of a mess [1]. See linked discussions [2][3][4][5]. [0] https://github.com/typhoeus/ethon https://github.com/typhoeus/ethon [1] https://xkcd.com/1987/ https://xkcd.com/1987/ (Add pipenv and poetry to the mix) [2] https://news.ycombinator.com/item?id=20672436 https://news.ycombinator.com/item?id=20672436 [3] https://news.ycombinator.com/item?id=18612590 https://news.ycombinator.com/item?id=18612590 [4] https://news.ycombinator.com/item?id=17607083 https://news.ycombinator.com/item?id=17607083 [5] https://news.ycombinator.com/item?id=13459740 https://news.ycombinator.com/item?id=13459740

ezekg 7y ago

I've actually been having some trouble upgrading from 5.2 to 6.0. I initially tried upgrading to 6.rc1 but hit a few road blocks, then tried 6.rc2 and just had too many odd errors and I eventually put that on the back burner. Maybe I'll go back and revisit, but I had tests failing that I wouldn't initially expect to fail, such as random unicode errors, broken mailers, and some odd 404s. I may try to upgrade to 6.0, but also kind of feel like waiting until 6.1 is out may be a better option. (I don't think GitHub talking about their 'smooth update' is fair, given they've essentially been upgrading to 6.0 since 5.2 released.)

deleted 7y ago

[deleted]

thrownaway954 7y ago

I have to wait for the MicrosoftSQLServer Adapter to be upgraded before I can upgrade :(

pizza234 7y ago

I wish they would be so keen on migrating to MySQL 8.0 as well :-) Their (amazing) tool Gh-ost is broken on MySQL 8.0, which suggests that they're still based on 5.7. It's a big issue for my company (and I guess for any mid-sized company), since at mid-sized companies the schema is likely big enough to have slow migrations, but not big enough to have fancy replication topologies. For such cases, there's nothing like Gh-ost :-)

geerlingguy 7y ago
So far I haven't seen many people switching to MySQL 8... almost every example and app I've seen in the wild is on 5.6 or 5.7, or switched to MariaDB (or more infrequently, Postgres).
- pizza234 7y ago
  Well, if we put it this way, the same could be said of Rails 6. I understand their plans of course, and that's why I expressed it as wish. Regarding MariaDB or PostgreSQL, can you enumerate/detail the app you've seen switching? Is it the, say, 1/2% area of all the projects? 5%? Probably, in the low one-digit percentage, there are switches toward anything. I'm somewhat skeptical any non-trivial projects undertaking this kind of change. GitLab (to mention a large one) didn't really switch, as they were supporting both.
  - qiqitori 7y ago
    When you install 'mysql'/'mysqld' in Debian or RHEL7+-based distros, you get MariaDB... So staying with MySQL and not "switching" to MariaDB is a lot more effort. (MariaDB is a fork of MySQL and the binaries and everything even have mysql in the name so everything just works. I'd assume there might be some divergence in newer features, but I haven't noticed anything in that regard.)
caseyf 7y ago
You've probably considered it and selected gh-ost instead but pt-online-schema-change from Percona Toolkit works great with 8.0

phodo 7y ago

How does one connect a rails 6 app to a python tensor flow (inference) model?

aledalgrande 7y ago
Using a client to connect to a prediction HTTP service would be my choice (Flask app?). Otherwise if you want to you can do something with the backticks, which will run a shell process from Ruby and get the return value: `python3 predict.py <input>`
nurettin 7y ago
Like you connect anything to anything else. You use a myriad of Inter-process communication techniques from memory maps to named pipes to socket protocols to databases.
GolDDranks 7y ago
You deploy the Python model to a backend service and expose a simple HTTP-based API, maybe using Flask? You should preferably keep the web part and heavy lifting separate.
ssaunier_ 7y ago
As suggested, encapsulate your prediction model in a web service, then calling it from Rails would be a good way to go. An other way is to use something like Faktory (https://contribsys.com/faktory/ https://contribsys.com/faktory/) on top of Redis. You push jobs from Rails and then you pull them from Python to execute. Then Python can enqueue another job with the result which gets consumed by Rails (async callback).

juliendc 7y ago

I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app. I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box. The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers. Hope they will ship many more releases!

tsotpsstt 7y ago
Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems. It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.
- freehunter 7y ago
  I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.
  - dzader 7y ago
    Yeah, I am extremely excited about this - small sample size but I've worked on a handful of rails apps and I seem to always need a WYSIWYG editor and could never find one I really liked - glad to see it better incorporated!

EsssM7QVMehFPAs 7y ago

What about security? Constantly pulling unreviewed code just because it passes unit or e2e tests does not sound like the ideal choice to me.

_bxg1 7y ago
Presumably this was only in their testing environment, not production.
wlll 7y ago
Code that gets merged into Rails master is reviewed by the Rails core team.
- jrochkind1 7y ago
  And indeed how much of that code gets significantly _more_ review after it's merged and before release? Some of it. But yeah, I don't think they were releasing based on unreleased Rails master. Just running CI, and keeping it passing.

_bxg1 7y ago

Wow, didn't know a company this recognizable was still using (and embracing!) Rails. Pretty cool. Also helps explain the fact that they've stuck with a mostly server-side-rendered app, despite it being a fairly complex tool.

HatchedLake721 7y ago
Why “still” and “stuck”?
- jaimex2 7y ago
  ignorance
jrochkind1 7y ago
The perceived performance of Github as I use it as good as any site I use and better than most, so to the extent that's a consideration in client vs server rendered (and it probably should be a big one), it seems to be working.
jdance 7y ago
The new sites with their own implemented loading bars are just super annoying to use. Sometimes they just stall and look stupid. State is bad! Stateless page loads work! Dont use SPAs unless you do something that looks like a desktop app! Please!
shantly 7y ago
> Also helps explain the fact that they've stuck with a mostly server-side-rendered app, despite it being a fairly complex tool. Probably why it's remained tolerably snappy and light on resources while the "SPA" world so rarely delivers the same.
_bxg1 7y ago
People are so sensitive about this. I wasn't suggesting that server-side rendering is bad, only that they're going against a trend. Settle down.

xvilka 7y ago

They should sponsor also the proper JIT in Ruby, will improve the speed drastically. Not the current generation of C code then compiling it with GCC, this is a joke.

steveklabnik 7y ago
I'm not sure who is working on JIT stuff in Ruby, but GitHub does employ people to work on Ruby itself, notably Aaron Patterson.
jashmatthews 7y ago
It's very easy to criticize and very hard to do better within the same constraints. Vladimir Makarov from the GCC team built the prototype. This was not the result of inexperience but a pragmatic choice. As a side note, JRuby has had a production ready JIT since 2015.
save_ferris 7y ago
How I dream of more serious sponsorship in the ruby community. I think people underestimate how much python shops are suffering right now over the V2 to V3 transition. I recently turned down a gig that was basically just going to be upgrading python services for the next several months. I've personally preferred much of ruby's tooling and package management to Python's, and I've always hoped that bigger money would come into the community. That said, Ruby has done incredible, not knocking the accomplishments of the community in any way.
- cutler 7y ago
  What happened to IBM? A few years ago they were all in on supporting Ruby. Next I heard they were betting the company on Swift.
  - save_ferris 7y ago
    No idea, but nothing really planned out as far as I’m aware. It’s great to see companies like Github, Stripe and Shopify make major contributions to the community, but having a relationship like Google and Guido have would’ve elevated the community to another level.

aledalgrande 7y ago

If you are struggling to find a way to subscribe to the blog, I found the Atom feed: https://github.blog/subscribe/ https://github.blog/subscribe/ It is not linked anywhere I can see on the main page.

jinushaun 7y ago

Sounds like they upgraded directly from a custom fork of 3.2 to 6.0, but if you read the article, they upgraded from 5.2 to 6.0. Not as insane as 3->6, but 3->5 is still pretty insane.

thebiglebrewski 7y ago

Eileen is a legend! Amazing work over there!

breatheoften 7y ago

Why do people like coding in a system where you can cmd-click on almost nothing to get to any useful information about what the code does ...?

save_ferris 7y ago
Because (good) ruby is elegant enough to be self-documenting and informative on its own without needing go look somewhere else to figure out what it does.
- jrochkind1 7y ago
  I think you get those command-click references via static analysis for ruby in, uh, RubyMine? Some people swear by it. For just that reason. I have never used it. I am willing to consider that maybe if I did, I'd come to like it so much I'd never want to do without it. (There was a point I didn't think I needed syntax highlighting, now I know I read/understand code so much quicker with it, at least in ruby). Does VB Studio maybe give you it for free too? Not sure. Not sure how good these features are. Can't say why I and I think the majority of ruby devs don't try em.
dvogel 7y ago
Considering MacOS share of developers is around ~30%, most developers can't cmd-click :) Seriously though, there's whole camps of developers who don't use an IDE. Some people are just more productive keeping a model in their head and relying on other tools (test, linters, repl experiments) to safeguard against their own misunderstandings. Source: https://insights.stackoverflow.com/survey/2019#development-environments-and-tools https://insights.stackoverflow.com/survey/2019#development-e...
codeisawesome 7y ago
No idea why you’re being downvoted grey on a legit question. I’ve seen at least one project where it’s unreasonably hard to introspect rails code even using IDE tooling.
baroffoos 7y ago

bigwheeler 7y ago

A front page Rails-related post that doesn’t have a single comment about rails scaling issues, 8 entire hours after submission?! It’s a good time to be alive!!

wastedhours 7y ago
Very hard for people to complain about scale when the post's coming direct from GitHub!

developer2 7y ago

I'm going to stick my neck out as someone who has refused to even consider Rails over a span of many years, for one simple reason: it permits session fixation. If a client's cookie says "I am session token 'abc123'", it will create that session id out of thin air. As in, it will create that session id without it having had to be generated previously. Your memcached/redis does not have an entry for session 'abc123', but Rails will happily create it. The developers who allowed this situation to occur should not be permitted to be employed in our industry. Yes, it's that bad and I am that serious. You can, not kidding, set your cookie's value to ANY VALUE YOU WANT, and the codebase is entirely willing to unconditionally create that session with whatever value the attacker chooses. Hint: if a client sends session id "abc123", then you should check for the existence of that session id. If the key is not set, you either a) show an error page, or b) create a completely new session id, ignoring the client's requested session id. It is NEVER, EVER, EVER... I am saying __NEVER__, __EVER__ acceptable to create a session id based on client-provided data. And yet, this is what Rails does out of the box. Edit: Downvote me more, I don't care. The fact is that Rails' developers are amateurs. Rails is insecure out of the box. That is a fact.

excid3 7y ago
The countermeasures to session fixation are covered in the official Rails guides: https://guides.rubyonrails.org/security.html#session-fixation-countermeasures https://guides.rubyonrails.org/security.html#session-fixatio...
- developer2 7y ago
  Why is that an opt-in option? No codebase should ever be willing to create a session id (any db/cache id/key) based on request details. The fact you have to opt in to a very basic security measure is, once again, a joke. Let's be clear: by default, Rails is willing to assign a client any session id based on its own request?!?! Based on the other reply to my comment... no I'm not OK. I am not OK with Rails' pathetic attempts at the most basic level of security. Rails' developers are fucking amateurs. I'm sorry, but that's pure fact. Rails' developers don't know the first thing about the HTTP protocol. NOBODY EVER CREATES A DB/CACHE KEY BASED ON THE VALUE OF A CLIENT-PROVIDED COOKIE (or unvalidated GET/POST). Anyone who argues against this should be permanently banned from IT/Technology. Just... fuck off... you have no clue.

dzonga 7y ago

unpopular opinion, but the reason people chose node.js is because for some dense folks like me it's easier to reason about and understand how everything works. the tooling is abysmal compared to rails, django & laravel. but at least I know how my app works from top to bottom. you take a productivity hit in your first node.js project but after that you would've collected / curated your own personal tools/libraries. and hell yeah spinning an api that does whatever you want is easy as hell. much respect to dhh though

moksly 7y ago
I’m not sure your opinion is unpopular, but I have a hard time following your logic. Isn’t part of why a solid and curated framework makes perfect sense (and make you more productive) exactly that you don’t have to understand everything that’s going on? I have a decent understanding of what lies beneath linq in C# for instance, but that’s because I’m curious by nature and not because I had to know it to utilise it. I mean, I guess you could argue that people should know what’s going on, but the truth is that 90% of software development doesn’t require you to, if you pick the right tools. I think this is a primary reason node.js never really picked up. No one wants to spend time building and maintain the wheel when you can get a trusted entity to do it for you. You may find the part about node not picking up odd, but if I look at job-listings for my entire country there is almost zero postings for a node backend.
danmaz74 7y ago
If that's your concern, you can learn how the internals of rails (or django) work. Not being forced to do that doesn't mean you can't do it regardless :)
bradstewart 7y ago
But by the time "you would've collected / curated your own personal tools/libraries", you could have learned how Rails works.

adreamingsoul 7y ago

I loved working with Ruby, and RoR. All my completed side projects used RoR. Ironically, I do have a couple incomplete side projects that used NodeJS. I never understood why RoR recieved so much hate in the tech community, or from CTOs. Glad to see a prominent service like Github continue to use RoR.

danmaz74 7y ago
Every successful project is going to get hate from somebody; if anything else, those who don't like some of the choices of said new successful project will be worried to be forced into them, and some will react finding any possible reason to stop the momentum.

dvcrn 7y ago

This is very interesting. In my bubble I thought the trend was going away from full fledged batteries included frameworks and more towards “hand pick your few specific libraries” with Go, Java and what not. Looking into the comments here, I guess I as wrong. It’s refreshing to see a big company writing about Rails

fogetti 7y ago
It was also just a year ago when Stripe released a static type checker for Ruby: https://sorbet.org/ https://sorbet.org/ Only haters think that Ruby and Ruby on Rails is dead end
aantix 7y ago
When the pieces are isolated, integration becomes a big portion of the development work. It's one of the reasons that Rails makes so many choices/opinions for the developer upfront. DHH discusses the costs of integration in this interview. https://devchat.tv/ruby-rogues/rr-428-arming-the-rebels-with-rails-6-featuring-david-heinemeier-hansson/ https://devchat.tv/ruby-rogues/rr-428-arming-the-rebels-with...

hoaxgaming 7y ago

Nice

tomerbd 7y ago

Long live rails! And this is from a java-spring developer.

nickjj 7y ago

Every time a Rails link appears on the home page it's filled with a bunch of technical reasons on why Rails is good and then there's a bunch of posts about how other frameworks might be better. These are healthy discussions IMO. But I think a lot of people overlook that one of the main reasons why Rails is so good / popular is that you get to see posts like the one we're looking at: Running GitHub on Rails 6.0 There's not too many other frameworks where there's a really strong track record of it running really popular sites (github, shopify, basecamp, airbnb). Not only are they popular, but they are well done sites that are pretty tech friendly. It just gives a sense of confidence that it will work for your small / large app and you don't get that with most other frameworks. Knowing that billions of page views have been through the framework irons out so many edge cases. Both bugs and performance issues, and you often get that perk on day 1 when a new release is out because it's already been running on basecamp for months (and maybe other big sites too). I mean check out this quote from the article: > GitHub engineers sent over 100 pull requests to Rails 6.0 to improve documentation, fix bugs, add features, and speed up performance. Combine that with the Rails approach of batteries included and you know that the core of your app is in good hands. You can't really go too wrong by using it along with a few well maintained gems.

k__ 7y ago
True. dev.to runs on Rails too. Currently I'm looking into AWS Amplify, which tries to be the Rails of serverless. Building a serverless app as you would build a monolithic app sounds intriguing to me.