Ruby and Rails are the single reasons why my previous startup worked out. We had a small engineering team and had to move incredibly fast. Without the magic we wouldn’t have been able to ship at insane speed. I tattooed the ruby logo on my arm as this was an absolute life changer for me. Having financial freedom now lets me spend so much time with my kids. I’ll be forever grateful.
Building GitHub with Ruby on Rails
311–320 of 332 posts
Re: Building GitHub with Ruby on Rails
#312Earlier quoted context omitted.
One thing I just cannot wrap my head around is Ruby/Rails metaprogramming and attribution of things (as in "where this method/class/macro comes from?"), especially with so many authors trying to do something to the pre-existing stuff, including the standard library bits. Like, a lot of times I see some baz.foobarify() I have really hard time understanding where the heck that comes from. RubyMine makes wonders and con…
https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger... is ruby gold for this kind of stuff. As a Ruby developer, probably one of the most impactful "quick tips" I've ever picked up is this: foo.method(:bar).source_location That is wildly useful when debugging/figuring out where the actual code for some method is at runtime.
[flagged]
Re: Building GitHub with Ruby on Rails
#313Are there other languages where the dominant web framework changes so much? Will Rails ever be "done"?
[flagged]
Re: Building GitHub with Ruby on Rails
#314Earlier quoted context omitted.
Similar backstory. Back when I used Rails as a young dev I remember loving it but thought it all felt a bit parochial somehow, like they didn’t really get where the web was going. Now I realise they were just not interested in hype and other bullshit, they never get sucked into the latest scalability trends like I always did, they never cared about being first and trendy, and that’s why Rails is still there and still…
Yea it's funny how it worked out. I felt similar. I was chasing the latest trends, frontend frameworks, databases. They weren't, and now we're back where we started with sending data from the server and submitting forms. I'm less likely in my career to stray away from whatever the old heads came up with. For instance the new thing is putting server/database calls in server side React components. But something tells m…
[flagged]
Re: Building GitHub with Ruby on Rails
#315I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers". Rails was such a huge part of my professional career. Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years. The most exciting thing to come out of this ecosystem recently is…
I wonder why so many went this path. When I started with Ruby like 15 years ago it was just another language to learn, but in the end I just stuck with it.
I still build in Rails. And even thought I tried alternatives I don't think anything is as stable and fast (for me) to create things.
Rails is love
Re: Building GitHub with Ruby on Rails
#316And as I have said before but worth repeating again, Rails is perhaps the only open source framework that is being battle tested in development at scale. It may not be the fastest ( or in fact quite slow ), but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework. I wonder if Eileen Uchitelle will bring this practice to Shopify as well? Edit: It seems [1] S…
> It may not be the fastest ( or in fact quite slow ) Web is not CPU bound, it's memory and network bound. Rails can run huge traffic perfectly fine if you know how to code for performance (e.g. caches, async with Kafka etc.) Ruby had also pretty significant speed improvements in the last years.
This! Having served multiple thousand users at once from a cheap $15 DO box the thing about rails performance is just how you built it.
The tools are there, you just need to understand and use them.
Re: Building GitHub with Ruby on Rails
#317Ruby and Rails are the single reasons why my previous startup worked out. We had a small engineering team and had to move incredibly fast. Without the magic we wouldn’t have been able to ship at insane speed. I tattooed the ruby logo on my arm as this was an absolute life changer for me. Having financial freedom now lets me spend so much time with my kids. I’ll be forever grateful.
I totally feel you. Ruby & Rails are part of the reason I work way less than most of my peers for the same amount of money or more.
Being able to built publish ready things, alone, within only weeks instead of months is a total life changer if you like building things
Re: Building GitHub with Ruby on Rails
#318GitHub running off the main branch is fascinating, and initially sounds mad, but makes so much sense. Assuming they have very high test coverage, running against mainline Rails isn't really any different to having the fork they had before, but they have more influence on future development. It must also be a massive boon for the Rails ecosystem to have such a large property running off the head. Doesn't anyone know o…
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
My advice is to set up things as best you can right from the start, to make upgrading a relatively painless process.
For example:
- Good test coverage (particularly for critical points of your application) including CI pipeline
- Use dependabot or similar to make sure you get alerts for any critical updates (like security patches)
- Practice good dependency "hygiene" - only add a dependency when you really need it, and do vetting to ensure it's well-supported, has been updated recently, etc.
- Regularly audit and remove dependencies - when a library author declares they are sunsetting their project, plan on a replacement (even if that is, worst case, a fork). Remove dependencies which are no longer used in your code.
- Separate out your development/testing/production dependencies
- Use a good dependency manager: for example in Python, use Poetry or pip-tools or similar, rather than manually updating requirements.txt files yourself
- Update early and often: other than dependabot make it a maintenance task to check for updates at least once a week. Use managers, scripts etc to make this as easy and painless as possible.
Obviously if you are inheriting a legacy project you have to deal with the cards you are dealt, but these are a good target to move towards even with an old codebase.
Re: Building GitHub with Ruby on Rails
#319Earlier quoted context omitted.
I can't think of a single website that's real time and server rendered
I do not have examples with me. But anything built with Elixir Liveview will be server rendered and will also be real time, with some gotchas though. https://github.com/phoenixframework/phoenix_live_view
Its not exactly server rendered, though. After the first page view all the server is rendering are json graphs of dom diffs to be applied by the client application. If you use the routing features then technically its an SPA.
Re: Building GitHub with Ruby on Rails
#320Earlier quoted context omitted.
It takes a significant chunk of time for any approvals or change requests to show up in the desktop UI, if ever, without just manual refreshing. This is not a niche observation, fwiw. It's a common complaint.
Ah, responsive as in "responds quickly", not responsive as in "renders appropriately for different viewports". We need more words!
I think I used the wrong term, sorry! Solo dad + software dev = brain slowly melting away.