Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Are there good criteria for creating a gem instead of creating another class in the lib folder?
I have worked with a couple of Rails projects, and the codebase tend to be monolithic. I want to to start modularising, but I cannot convince the team and myself from which point we start with creating independent libraries.
For instance, creating a gem for a three-liner class sounds an over-engineering. On the other hand, it seems reasonable because at least that would be 6 lines when comes with tests, and the code might grow further. Also code pieces which does not belong to MVC should not be in the app to be strict in the craftsmanship, but I am not sure yet.
Can you share your experience of your Rail projects, other sources, like books or blog articles, or lessons from projects of other languages?
I use to extract gems for different reasons:
the code solves a common problem and might be helpful to others (open source it)
you want to reuse the code in different apps, even if these apps do not exist at the moment (e.g. api integrations to internal services)
is the code reused in totally different areas of my codebase (that is an indicator that it is independent from my app)
if there is not only one class, but multiple files that depend on each other
IMO it is not about lines of code. It might makes sense to extract an one liner, if it solves a common problem and might help others (think about code extensions in active_support, most of them aren't very complex). And on the other hand it might not makes sense to extract a class with 100+ lines, when it solves only a very specific problem in domain.
If I wanted to break up a monolithic app, I would not look into the lib folder. I would look at the app itself, and would try extract bigger parts into smaller services.
Creating a gem for a 3 line class is over-engineering. It will create more overhead than it's worth. Look into engines as well but premature modularization and/or optimization can make a bigger mess than a concise monolithic app IMO.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I would like to have more information and concrete cases how bad is JS.ERB in a Rails application.
I have something in mind:
Lack of flexibility
Complexity
Mix Javascript + Ruby ( possible + HTML) code
The worst thing about this is that javascript is supposed to be client side language and building it server side seems at least awkward.
Apart from that, you will get a major performance hit if you are not able to precompile your assets - every request for javascript file in production server has to get through your rails application to render erb correctly. (If your .js.erb files depends on variable, request related values). If you avoid js.erb files and have .js files only, those files are completely static and can be served directly by the server without touching your application at all.
There are naturally couple of exceptions - I personally allow myself to use erbized javascript files to avoid hardcoding urls or other application constants. For me, the rule of thumb is - if erbization doesn't stop you from precompiling and will make your code cleaner and more resilient, just go for it.
Naturally there are some reasons not to do the above as well - in the ideal world I would love my server side application to be pure API consumed by another, pure static js application. Using erbized javascript is an extra obstacle from splitting your app in half when it grow too much.
js.erb is generation of javascript with ruby, right? To me this has an obvious "code smell", of code generation. Whenever someone resorts to using one (more familiar) language to generate another (less familiar) language, I would question the quality of the generated code. In this case a javascript guru would probably look a the generated code and be thinking "WTF?, why would someone do __ this way?". There are probably going to be a lot of things that work, but are not how an experienced javascript developer would do it. This can lead to performance issues, maintainability issues, and just plain bad code.
Just my opinion.
Warning - Highly Opinionated answer to follow. Moderators will probably delete!
I can't agree more, in fact I am a bit of a nut about this, and have been using react.rb to get all of our views into straight ruby, no JS, ERB, at all.
My specific reason beyond what you mention is this: The mental power it takes to constantly shift between different languages is huge, and largely taken for granted by developers. We just don't notice how much energy its taking. In otherwords we have become like frogs in the pot of water, and we keep making our programming lives more complex with all these languages and sublanguages (we were programming in 5 different languages in one site) and while you get used to it, once you stop, and stick to one language (ruby in our case) you just say whew!
While I have no specific study to prove this, I think its just a form of multitasking which is a known evil. i.e. https://www.psychologytoday.com/blog/brain-wise/201209/the-true-cost-multi-tasking
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been working on a large website with Ruby on Rails for more than 2 years now and found it really convenient and easy to code a web application or service. Now I want to build a really thin web service: no DB, no front end 1-2 controllers with 2-3 actions each.
When I invoke rails new, it sort of "scaffolding" a large application structure, there is any way to get the default large structure replaced for a small service suitable structure with rails? (btw, If you think I don't need to use rails for such a project you're welcome to explain why. )
I was just going to upvote some comments, but we try not to answer in comments, so I'll try to synthesize the relevant points:
Rails' infrastructure is designed to accomodate a fairly complex app, and is probably overkill for the sort of simple app you're talking about building. This matters because Rails embraces Convention Over Configuration, and the conventions are geared toward larger apps.
Here's a couple of examples (not an exhaustive list):
Rails separates routes into their own file, with individual controller classes for interacting with each type of resource. If you have only a handful of pages in your app, this can be more structure than you need.
Although you can tell it not to, Rails assumes by default that you want to use ActiveRecord (and that you have a database for it to talk to). It also assumes you'll want model classes, and that there's both enough of them and they're complex enough that they need their own directory of individual files.
The Rails Asset Pipeline is great for dealing with lots of complicated assets that require extensive preprocessing. It's also kind of a pain in the ass.
There are a number of Ruby-based microframeworks that are likely better suited to the sort of app you describe. Sinatra is probably the most widely used. It makes few assumptions and is consequently lightweight, allowing you to establish whatever design patterns you want in your app. There are also bunch of others that might be worth considering.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been really getting into Ruby on Rails. I want make great apps that don't just function well but look really nice as well, and I'm worried I might not pick the right front-end language to compliment RoR development. My question is how do you simultaneously prepare for both back-end and front-end? Summer is coming up and I'm already enrolled in a few RoR classes, but am trying to choose some great front-end courses as well. Appreciate any guidance
Sam --
TLDR; Know HTML and CSS like the back of your hand. Spend time learning intermediate and advanced javascript. Its libraries are powerful, its frameworks provide a rich client experience, and its not going away anytime soon.
I've been a RoR developer for two years. When I was first learning Ruby, and coding principles in general, its common to want to learn and learn all kinds of different stuff. While it's tempting, I would suggest the opposite -> Hyperfocus.
Rails is a robust framework, spend some time with it. I will agree that Rails views are very bare bones and I do not like the way they organize javascript and stylesheet logic. It is very loose. But, unless you're building a huge app, organizing .js and .css files isn't super important.
As far as looks go, html and css are the backbone. There's literally a javascript library for everything you could want to do from a UI/UX perspective, so focus on intermediate/advanced js. That will make opening doors to robust client side js frameworks like angular, ember, and backbone much easier down the road using Rails as simply an API.
Lastly, one of the hardest things to find in the industry is a great designer who can also code, or a great software engineer who can also design. If you really care about UI/UX get some books on fundamental web design principles; they go a long way.
Well, I encourage you to first code a few apps with the default rails stack and after that start to poke other front end options with rails as back end api.
Stay comfortable with rails first, has a lot of good tools and is enough for most of the apps you may want to build, mainly on the first stage of your learning path.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I just started with Ember.js and I can't seem to find a legitimate reason to use it in any kind of project, except for maybe a stand alone HTML5 application (not a website). That's just my opinion and know lots of people make use of it for good but isn't duplicating the ORM code on the client side a bit of boilerplate ?
There's a lot of discussion on "why Ember" elsewhere, so I'll keep this sorta short...
Ember and many of the other client-side MVC frameworks are best suited for applications that need to manage complex state changes between UI elements and their underlying data. Once you get to a certain level of sophistication on the UI, it becomes harder and harder to manage with data- attributes and jQuery dom finders. You can compare and contrast implementation of a sample application using different frameworks here: http://todomvc.com/
Ember is not duplicating the ORM layer. It does not do the actual persistence or integrate with your database, map the columns to the attributes, etc. It might feel similar in that you have JS objects that look similar to your models, but they serve a different purpose. They are meant to be data objects for your UI; almost the same as if you were going to produce JSON representations of your model for an API consumer; except these models can have behavior and can be bound to the UI (via controller) so that the UI stays in synch when the model data changes.
There's some good advice and opinion on Ember here (code syntax is outdated): https://github.com/trek/trek.github.com/blob/4bc36e47a9017bead7cbfd769d6dc87b57c8808d/_posts/2012-08-30-advice_on_and_instruction_in_the_use_of_emberjs.md
The Ember info out there (esp here and with the data interface) is a little difficult to navigate because a lot of the syntax has changed. This transition guide can help: https://github.com/emberjs/data/blob/master/TRANSITION.md
The Ember tutorials out there are also tricky because almost all of them assume that you are building an app from scratch and want your entire app to be based on Ember. This is a valid use case, but if you manage and maintain an existing app it's hard to visualize how to fit Ember into what you already have.
This tutorial has some good end-to-end info: http://hashrocket.com/blog/posts/setting-up-an-ember-app-with-a-rails-backend
This gist has some good ideas on how to incorporate ember into an existing Rails app: https://gist.github.com/eccegordo/7277817
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We are a little team working on a Rails 2.3 project. A short description: this project has currently
460 000 lines of Ruby, CSS, JS and YML (including some plugins and libraries)
350 ActiveRecord classes (only the project's classes)
some Rspec tests in the recent classes and controllers (not enough)
45 required gems
A database with 2 Go data.
The project is divided in approximately 15 'modules' (not as Rails module), with each module talking to others modules. This project exists from several years, and has been improved and maintained with several people, not necessary Rails experts.
The current main problem is that several parts of the code are difficultly maintainable, are unoptimized and not enough 'thoughful' (there is hack everywhere). The CSS files are nearly unreadable.
Our team is cogitating about refactoring this project. We have a few solutions :
Create a new project from scratch, and include functionnalities one by one. The advantage of this solution is that we have all the facets of the projects, and we can take prettier decitions about code design. An other advantage is that we can update to Rails 3. A lack of this method is that we have to maintain 2 projects in parrallel, when we have to include new functionnalities.
Update existing code, module by module. The advantage of this solution is that we keep only one project to maintain. But there is several lacks... How to go from an old module to a new module ? How to proceed between the new and old class names ? How to know where old code is inused and must be deleted ?... and even more.
Does anyone already have done a big refactoring like this ?
Does anyone have experience feedback about this ?
Does anyone have an other solution ?
Thanks for reading !
The answer here really depends how much autonomy you have and how much time you can devote to the refactor. With a project of this size, almost certainly you can't just stop all work and devote 100% of your time towards the cleanup ROR 3 migration (cough cough, migration!).
If my assumption is correct, then my advice would be to tackle this in small chunks using the second method (e.g. update existing code). In addition to what you've outlined, I would encourage a few other things:
Write tests before you refactor a piece of code. This will help you be confident that you're not introducing problems (emphasis on the help... some breakage is of course possible).
Where possible, consider breaking modules into separate, independent gems. This will help you to track external dependencies and figure out where all 45 of those external gems are getting used. It will also help limit the scope of your tests.
Frankly the second method is much safer for your job as a developer, since it allows you to improve the codebase while simultaneously responding to other business needs. If a portion of the refactor is going too slowly, you can also just stop and pick up elsewhere, since the rest of the codebase is still intact.
Refactoring is a lot of work, and will take a long time and a lot of thought.
In comparison with a totally new project, the problem is that you have to maintain a working project, and probably will have to support some bug fixes and feature requests as you go.
on the other hand you have a much better understanding of the problem you are solving, and you can use the existing software as your defacto "functional spec"
identify the Interfaces between your "modules", by listing each inter-dependency.
Clean up these "interfaces" if necessary
Formalize interfaces by Writing unit tests to test the input and output of each module
create totally new modules as drop in replacements. architect from scratch, and do your ruby upgrade here. Make sure your new modules pass the same tests as your old modules.
If necessary (as an interim solution) wrap various incompatible sections to get them working together. this may be slow, but it's a stopgap.
good luck.