Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building GitHub with Ruby on Rails

github.blog

Post reply on HN
Print view View original

281–290 of 332 posts

Re: Building GitHub with Ruby on Rails

#281

Post by mdaniel »

ksec wrote: post #243
hocuspocus wrote: post #225

Earlier quoted context omitted.

> but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework. ?! There's at least Spring.

It's been a very very long time I touched anything Java so excuse my ignorance. I know there are many Enterprise, internal Web Apps that uses Spring. But are there any web companies built their SaaS or Consumer Web App on Spring, that is at the scale of Shopify and Github?

I couldn't immediately locate it, but there was a famous example of an Amazon property leaking its Java stack trace but since I can't locate it I also can't swear it contained springframework classes

Re: Building GitHub with Ruby on Rails

#282

Post by sjs »

ecshafer wrote: post #147
wg0 wrote: post #41

Earlier quoted context omitted.

I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django

At Shopify we also are basically always on the bleeding edge of all Rails and Ruby versions. By always moving forward it makes each improvement much smaller

Plus Shopify and GitHub must drive most development of Rails so it’s basically an in-house dependency to some extent. I know that’s simplifying things.

Re: Building GitHub with Ruby on Rails

#283

Post by jacobsenscott »

neon_electro wrote: post #274
jacobsenscott wrote: post #272

Earlier quoted context omitted.

Ruby tells you where methods are defined - it is worth your time to learn how explore ruby code from the REPL - this is the ruby way. For example (I have pry installed, but you can do it without pry) [5] pry(main)> $ user.first_name From: /Users/.../.asdf/installs/ruby/2.7.7/lib/ruby/gems/2.7.0/gems/activerecord- 6.0.6/lib/active_record/attribute_methods/read.rb:15: Owner: User::GeneratedAttributeMethods Visibility:…

Can you point to where this is documented? Thanks for sharing!

https://pry.github.io/ - also a lot of features from Pry have made it into the default IRB these days, but I still use pry. I don't know the equivalent commands in IRB.

Re: Building GitHub with Ruby on Rails

#284

Post by jacobsenscott »

weatherlight wrote: post #280
jacobsenscott wrote: post #269

Earlier quoted context omitted.

Metaprogramming in ruby is not magic. It is fairly simple, but if you come from a language where metaprogramming is difficult or not possible it can seem like magic. Good metaprogramming levels up a language's power in the same way going from a hammer to a nail gun levels up your building power. Creating a DSL in ruby is mostly just creating well named class methods, often that take blocks, and calling them without p…

I've created many DSLs in Ruby. The issue is later debugging said "magic" methods, when said method is throwing an error and you can't find said method in your codebase. Metaprogramming is pretty amazing for gems and DSLs in a limited domain. When I see business logic that has metaprogramming in it, I kinda freak. I know in the future that business logic will change and debugging the very clever code in that business…

I agree that metaprogramming should be used with care, and mostly makes sense in frameworks and libraries, and not application code. But any ruby programmer should take the time to learn how it works - and a few sprinkles of it here or there can make otherwise hard things easier.

Re: Building GitHub with Ruby on Rails

#285

Post by sn9 »

ksec wrote: post #243
hocuspocus wrote: post #225

Earlier quoted context omitted.

> but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework. ?! There's at least Spring.

It's been a very very long time I touched anything Java so excuse my ignorance. I know there are many Enterprise, internal Web Apps that uses Spring. But are there any web companies built their SaaS or Consumer Web App on Spring, that is at the scale of Shopify and Github?

Pretty sure Netflix uses a ton of Spring.

It's one of the most common frameworks in the industry across languages.

Re: Building GitHub with Ruby on Rails

#286

Post by danielheath »

nicoburns wrote: post #88
danielheath wrote: post #49

Earlier quoted context omitted.

Rails has dependencies, but not like node apps; last time I counted create-react-app vs a new rails app, there was nearly 10x as many distinct maintainers with access to push new releases to the default dependency tree. I consider that a better measure of dependency risk than absolute count, since different ecosystems have different ideas about how large a library should be.

Create-react-app isn't really a fair comparison. Create-react-app has ridiculous dependency bloat compared to the norm in the JS ecosystem because it includes every possible option rather than just picking one option in each category. Most serious project using React aren't using create-react-app.

I’m not really familiar enough to contradict you, beyond saying that - as an outsider - it has by far the most visibility in its space.

Re: Building GitHub with Ruby on Rails

#287

Post by mscccc »

doodlesdev wrote: post #268
ativzzz wrote: post #165

Earlier quoted context omitted.

I think it's a tradeoff - rails makes live frontend updating challenging because you need to maintain a separate system to manage that, especially when you have a large app. JS frameworks have this built in, but their backend is lacking compared to rails IMO

GitHub could've used Hotwire [0] but instead they decided to grow a buggy immature in-house solution. [0]: https://hotwired.dev/

Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created.

Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.

Re: Building GitHub with Ruby on Rails

#288

Post by Rafert »

a-user-you-like wrote: post #265
flats wrote: post #234

Earlier quoted context omitted.

RBS ( https://github.com/ruby/rbs ) + Sorbet ( https://sorbet.org ) in Ruby 3!

It’s… not ready for prime time. I’m optimistic that it can get there but right now the tooling is quite immature and the type system flexibility is not there for such a dynamic language as ruby.

Have you tried Tapioca (https://github.com/Shopify/tapioca) with Sorbet? Typing in general has ways to go sure, but I find this combination quite usable in my day to day.

Re: Building GitHub with Ruby on Rails

#289

Post by weaksauce »

CoffeeOnWrite wrote: post #259
hanley wrote: post #241

Earlier quoted context omitted.

You don't have to use `let` in specs. I prefer setting instance variables inside a `before :each` block.

Instance variables, you mean those beloved things in Ruby that cannot be distinguished between not having been defined versus having being assigned the value `nil`? :p

there are many ways to lookup if something is defined or not

    instance_variable_defined?

    defined?
are two common ones

but if you are using something before defining it you are going to crash so that's definitely one way of distinguishing it.

using fetch is another way to provide a default value to something that may have a nil value as a meaningful value.

Re: Building GitHub with Ruby on Rails

#290

Post by int_19h »

jeremyjh wrote: post #95
amrocha wrote: post #47

Earlier quoted context omitted.

Very true, but that's a frontend problem, not a rails problem.

These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.

The upside is that you can link just about anything in GitHub, and those links work consistently and point at the exact right content. This is much less common with SPAs.
Post reply on HN