marklarPRO

Joined 9/28/2016
marklar PRO said over 2 years ago:

Thanks for the screencast. Do you know whether puma-dev works with foreman?

kobaltz PRO said over 2 years ago:

You may not need foreman with puma-dev since it will automatically start up your Rails app on the first request.

marklar PRO said over 2 years ago:

I use my procfile with foreman to start redis and resque, would these automatically start with puma-dev?

kobaltz PRO said over 2 years ago:

Puma-dev wouldn't automatically start those services. It will just start the Rails app.

marklar PRO said about 1 year ago:

>I don't think that I would add the complexities of Webpack in a application just for Stimulus. This would be my preferred route in an existing application.

Would you be able to expand on the added complexities of Webpack (through webpacker)? I was planning on switching from sprockets to webpack based on the advantages discussed in this article: https://rossta.net/blog/from-sprockets-to-webpack.html

kobaltz PRO said about 1 year ago:

On an existing established application, you would be adding extra dependencies for a micro framework. While Webpack would have long running benefits in the application, I wouldn't necessarily add it into one just for this. If I was tasked with refactoring the app and clean up a bunch of javascript files, vendor assets, etc. then I would consider adding it in.

marklar PRO said about 1 year ago:

Thanks for taking the time to reply. When you refer to adding extra dependencies, are you referring to the webpacker runtime dependencies of activesupport and multi_json (as well as the webpacker gem itself)? I'm still just trying to completely understand any webpack baggage before making the switch.

kobaltz PRO said about 1 year ago:

It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system

marklar PRO said 12 months ago:

FYI, here's a blog post you may have seen where the author had great difficulties using webpacker: https://www.codementor.io/help/rails-with-webpack-not-for-everyone-feucqq83z

kobaltz PRO said 12 months ago:

I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.

marklar PRO said about 1 year ago:

Thanks for taking the time to reply. When you refer to adding extra dependencies, are you referring to the webpacker runtime dependencies of activesupport and multi_json (as well as the webpacker gem itself)? I'm still just trying to completely understand any webpack baggage before making the switch.

kobaltz PRO said about 1 year ago:

It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system

marklar PRO said 12 months ago:

FYI, here's a blog post you may have seen where the author had great difficulties using webpacker: https://www.codementor.io/help/rails-with-webpack-not-for-everyone-feucqq83z

kobaltz PRO said 12 months ago:

I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.

marklar PRO said 12 months ago:

FYI, here's a blog post you may have seen where the author had great difficulties using webpacker: https://www.codementor.io/help/rails-with-webpack-not-for-everyone-feucqq83z

kobaltz PRO said 12 months ago:

I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.

marklar PRO said 11 months ago:

Thanks for the great episode. I know you mentioned that once you've got it all set up it is quite similar to doing system tests (as system tests use Capybara) but are there any plans for an episode on getting set up with system tests, differences between what was implemented in this video (feature tests), and best practices?

marklar PRO said 11 months ago:

I just realised that episode 100 covers the difference between feature tests and system tests.

marklar PRO said 11 months ago:

I just realised that episode 100 covers the difference between feature tests and system tests.

marklar PRO said 10 months ago:

Would you be able to share some sample code for your solution to this?

marklar PRO said 9 months ago:

Do you know if it's possible (or advisable) to use ActiveStorage with Rails 5.1.6? In the Rails guides it states:

After upgrading your application to Rails 5.2

http://guides.rubyonrails.org/active_storage_overview.html#setup

So I wonder whether it would be ill advised to add ActiveStorage as a gem to 5.1.6.

kobaltz PRO said 9 months ago:

I haven't tried adding it to an "older" version of rails. It does seem to be fairly decoupled from Rails as its own gem.
Though, one weird thing that they do which is a little strange that could prevent this from easily working is in the ActiveStorage gemspec.

  s.add_dependency "actionpack", version
  s.add_dependency "activerecord", version

It has this reference to version which is in the main branch's RAILS_VERSION file. If you reference a 5.1.6 tag, the ActiveStorage gem wouldn't exist. You may need to clone the repo and manually adjust it. This would inherently add a level of technical debt as you would have to migrate any bugfixes/security patches/enhancements to your branch.

marklar PRO said 9 months ago:

Yikes, it sounds like it's not the best idea for a simple plug and play solution with 5.1.6 then.

Thanks for taking the time to reply and thanks for the great video.

marklar PRO said 9 months ago:

Yikes, it sounds like it's not the best idea for a simple plug and play solution with 5.1.6 then.

Thanks for taking the time to reply and thanks for the great video.