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.
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 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 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.
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 10 years ago.
Improve this question
Hey all you ruby on railers...
I'm just a newbie as of right now.. currently work on my first rails project at work.
I'm going to be taking some time on my own time to dig deeper and I was wondering what the best strategy is to go about front-end development of a rails app.
is it better/easier to have a workflow like the following
1. Concept / Idea
2. Wireframe, Mockup
3. *** Design front-end of the app
4. Rails development
5. template all the views
or is it better to do it flipped?
1. Concept / Idea
2. Wireframe, Mockup
3. Rails development
4. Template all the views
5. *** Design front-end of the app
Maybe neither of these?
How do you go about your ruby on rails workflow.
I'm a complete mashup of developer / designer
But most of my inspiration comes from having an idea, then designing designing it, then doing all the front-end
What are some thoughts ideas for better rails workflows when you know exactly what you want the front-end of the site to look like.
This can work either way. Different companies -- or even different projects in the same company -- can reach success with different approaches.
That being said, I have a pretty strong preference for the following approach:
Concept / Idea
Wireframe, Mockup
Design front-end of the app
Template all the views
Rails Development
Basically, I usually describe it this way:
First, do the design to the point of having mockups and images laid out by a designer.
Have a UI specialist convert that to HTML/CSS (or HAML/SASS or whatever)
Do the rails implementation behind the html.
These steps will normally overlap -- and that's OK. You should start some basic development prior to getting everything eles final. But the more you have the design done ahead of time the better.
Note that this approach doesn't mean design the entire site in detail before anything else is done. It means that once you've decided to do some coding, do the design for that bit first. You'll want to implement things in small chunks and iterate as you do the development. Implement things in small chunks, but try to get the design for those pieces done before you start coding.