hopsoft

SOS mode in Utah also.

As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable.

As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.

Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.

I recently Dockerized a Rails development environment for working on an M1. It’s gone well so far and may provide some guidance for other development workflows (YMMV). https://gist.github.com/hopsoft/c27da1a9fda405169994a0049575...

I think the much touted "NEW MAGIC" will be the thing that does the automatic content refresh.

This is exactly what CableReady was built for... to update the DOM from any Ruby process (in the request cycle or not). It was designed from the beginning to update the DOM from out-of-band non-request based workflows like background jobs.

Just saw that this is on HN. Happy to answer any questions.

the DOM was often used to store state. And this just isn't a very efficient approach.

StimulusJS is a modern approach that uses the DOM to manage state. In my experience it has proven to be quite simple and performant.

https://stimulusjs.org/handbook/managing-state

Interesting point about grassroots vs top down. I think that definitely plays into the equation. Another big part of it is that developers seem to a unique class of workers that don’t seem learn much from those who preceded them. We love to reinvent things, in part due to the snowflake effect & NIH syndrome. The other reason I think the wheel keeps being reinvented in tech is due to the developer workforce essentially doubling every 5 years... also, the sad reality that ageism coupled with very few long term viable career tracks available for software writers pushes a lot of experience and wisdom out of the industry.

I'm not sure any other technology stack would have fared much better.

Consider that 6 years, 2 months, and 20 days passed between Rails 3.2 and Rails 5.2. That's quite a bit of time for the framework to evolve. Then factor in the customizations from several non-framework dependencies and those added by GitHub.

This is an incredible achievement no matter how you slice it.

You’ve setup a false dichotomy. Servant leadership can & should be decisive.

Rails (server side rendering) + Heroku.

Our tools & materials are constantly changing... not to mention that every project is different in various ways (though many developers delude themselves into thinking their project is unique i.e. the snowflake effect). I've found the most success when I stick to tools/patterns/strategies that I've had some degree of success with in the past.

What about Traveling Ruby? I've never used it, but it looks promising. https://github.com/phusion/traveling-ruby

Sounds like Stripe may be a large service oriented system written in Ruby but not Rails. https://www.quora.com/Why-did-Stripe-choose-to-use-Ruby-for-...

Don't confuse your job with your family.

Reminds me of this terrific article from David Brady. https://heartmindcode.com/2013/08/16/loyalty-and-layoffs/

I wrote a script to benchmark some of the diff strategies for anyone curious. https://gist.github.com/hopsoft/ae361319c54bbcb4f8e2

Why? Genuinely curious.

Conway's Law & micro-services help maintain flatter organizations at least in tech focused companies. When disagreements arise & consensus is hard, the various parties can simply introduce a new service boundary & go their different ways.

I do like the access-granted DSL. It seems to address some of CanCan's problems on larger more complex projects. Also... if you prefer a more OO style, I wrote a 50 line authorization lib that has proved workable on some of my larger projects. https://github.com/hopsoft/perm

Here's a very similar tool in Ruby. https://github.com/hopsoft/goldmine

I built a small testing framework with a pry workflow as one of it's goals. It's possible to run the tests in pry mode which drops you into a pry session on test failure. I've used it on several small libs & the test+pry workflow is quite nice. https://github.com/hopsoft/micro_test

Removing the ability to run code on gem install would be quite disruptive. I think that establishing a universal gem signing policy and/or some form of whitelist/blacklist strategy would be a better solution. Consumers need to be able to trust the installations of the tools they use. The same risks apply to any other installation process. Think of how we install RVM or Homebrew.