Best products from r/rails

We found 53 comments on r/rails discussing the most recommended products. We ran sentiment analysis on each of these comments to determine how redditors feel about different products. We found 49 products and ranked them based on the amount of positive reactions they received. Here are the top 20.

Top comments mentioning products on r/rails:

u/tabolario · 2 pointsr/rails

Hi and sorry for the late reply! The first thing I'll have to ask is what environment are you deploying into, a manually configured virtual machine/bare-metal machine, Heroku, Ninefold? Each of these environments have different (sometimes vastly different) considerations when it comes to deployment of any application. In general though, here's some things that will apply that will apply to any good deployment process (some of what's below echoes /u/codekitten's reply):

  • Remove ALL credentials from your codebase: I can't stress this enough, and even for a simple project it's a good habit to get into early on. It's been enough of an issue that there are even dedicated tools to help people remove hard-coded credentials from their codebases. A good resource to explain both this, as well as the general concept of storing environment-specific configuration data outside of your codebase is this section of the Twelve-Factor App website. Personally, aside from things like tokens that Rails uses internally like Rails.application.config.secret_key_base, I will always use environment variables coupled with something like dotenv or direnv to also manage the configuration for my local development environment.
  • SSL and HSTS: IMHO there is no (good) excuse nowadays to serve a web application over HTTP. Once again, even for simple projects it's a good habit to get into and a good thing to learn. If you're hosting your application on Heroku, all Heroku application subdomains (i.e. rxsharp.herokuapp.com) will respond to HTTPS, but it's up to you to ensure your user's will always use SSL. Rails has the force_ssl setting to do this automatically for you, which you should have turned on in all of your production and production-like environments, but you should also be using HSTS to ensure that your users always visit your site over SSL (force_ssl performs a permanent redirect to https://rxsharp.herokuapp.com but does not set the HSTS headers). The gem that I use most often to take care of setting these headers for me is secureheaders, which also helps you configure a number of other security headers like Content Security Policy headers.
  • Continuous Integration: Let me expand a bit on /u/codekitten's item for passing tests to say that you should have a system in place that will automatically run all of your tests each time you push to your repository and holds you accountable when things break. Continuous integration is a huge topic that I won't dig too much into here, so I'll just point you two two indispensable books on the subject: Continuous Integration: Improving Software Quality and Reducing Risk, and Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Conceptually, you will learn almost everything you need to get started and thensome on the topic from those two books. Once you get your CI configuration in place, you will get in the wonderful habit of always making sure your build passes locally before you push to your repository. A good CI script will:
    • Run static analysis tools like RuboCop and Brakeman
    • Run all of tests
    • Notify you when a build fails and when it gets fixed
  • Automate Everything: One of the most important things to learn about deployment early on is automation. Apart from initiating the deploy (and arguably even initiating the deploy itself), everything about your deployments should be automated to the fullest extent. There are several tools in the Rails world that most people use to accomplish this, most notably Capistrano and Mina. If you are using a platform-as-a-service like Heroku or Ninefold, see the documentation for one of those on how to automate various aspects of your deployment process.
  • Deployment Smoke Testing: In my experience working in the Rails world, it seems that not a lot of people automate their post-deployment verification, even though it's very easy to do! It can be as simple as having a post-deployment hook that uses curl to hit a status page on your site that returns the currently deployed revision, and rollback the deploy if it receives an error. It can also be as complex as running a suite of RSpec examples that utilize something like Serverspec to assert the state of each one of your application servers (obviously this one doesn't work as easily in environments like Heroku). In the end, the important things here is that you automate EVERYTHING when it comes to your deployments.
  • Database Migrations: First of all, don't forget to run them! If you're using something like Capistrano to script your deployments, the command to run a deployment that includes a database migration is cap production deploy:migrations, not cap production deploy. On Heroku, you need to run them manually after you deploy using something like heroku run rake db:migrate. One further topic here that I highly recommend you explore is that of zero-downtime migrations. A great introductory article on these is Rails Migrations with Zero Downtime over at Codeship.

    These things are all general items that belong near the top of any checklist for deployment (Rails or otherwise). Hope this helps!
u/AeroBag · 2 pointsr/rails

It's never too late, I too started when I was 27. My advice is to meet others, both starting out like you are and very experienced. Also reach out to companies you like, Ruby/Rails speakers, even DHH answers emails he gets. But don't go for the bootcamps. They cost an arm and a leg, don't teach you anything you can't learn by yourself and are very demanding (i.e. 60h/week).

A bit about me, to show you it's perfectly possible to get where you want to be:


I had some basic knowledge like you did but was very much outdated on most stuff web (last time I did HTML was when tables were a good way of laying your page out...)

I had 4 months where I couldn't work so I decided to put this time towards turning my life around and getting proficient enough to get paid to write webapps.

I started with M. Hartl's tutorial and this book: http://www.amazon.com/Agile-Development-Rails-Facets-Ruby/dp/1937785564/ but I was quickly overwhelmed.

So I took a step back and spent some time to learn Ruby first with rubymonk, the Ruby Koans and by asking a lot of questions on #ruby @ freenode. The people there were very helpful and I found this IRC channel to be crucial in my learning.

At the same time, I was getting up to speed on CSS and HTML with treehouse. Although their acting is a bit annoying at times because you feel a bit like a child and the things they teach are a bit outdated, you still can get a solid grasp on CSS and HTML in a few weeks.

Then I tried diving into Rails again. And again, it was too much. I was getting frustrated because a lot of things in Rails are automagical and you don't really understand where they come from.

I was fortunate enough to have a very active Ruby/Rails meetup group in my city. It took a few missed meetups to build up the courage to finally show up. There, I discovered that they were planning to run a railsbridge event where, for one weekend, volunteers assemble classes of about 10 persons and teach you Rails. There were 3 levels, complete beginner, intermediate and advanced. I took the intermediate class (which was actually an intro to Rails) and it gave me enough ammo to finally get on with M. Hartl's tutorial.

Over that weekend, I also met another guy who was also getting started with Rails. We eventually did the edX course together: https://www.edx.org/course/engineering-software-service-uc-berkeleyx-cs169-1x, helping each other out and doing the required "homework" together. Railscasts were also helpful. It hasn't been updated in a very long time now and probably won't be ever again but some of the stuff is still very relevant. The pause button is very helpful because Ryan explains quite a lot of stuff over a short period of time.

By going regularly to the meetup, I also befriended much more senior devs who I could come up to with questions. One of them knew of a junior position at a startup that needed to be filled and asked me if I was interested. And this is how I got my first paid job as a developer.

The takeaway is this: don't hesitate to reach out. Most people in this field love what they are doing and are very happy to give you some of their time either by giving advice, recommending you for a job etc. The key is motivation. If you can put 4-5 hours a day for the next 6 months, you can definitely get to a point where you have enough knowledge to be a junior dev. Don't forget to build things in the process and put them on Github.

Good luck!

u/jasonswett · 3 pointsr/rails

> I am a relatively new to development

If you're new to development, it's hard enough just to learn Rails by itself. In addition to the Rails concepts (e.g. ActiveRecord, view rendering, etc.) there's Ruby, databases/SQL, servers, HTML, CSS and JavaScript. Even if you're already comfortable with all those things, it's pretty hard to throw testing into the mix. When I first got started my question was, "What do I even test?" Do I write unit tests? Integration tests? View tests? Controller tests?

My advice would be to forget about Rails for a little bit and just practice testing Ruby by itself for a while. Then, once you're comfortable with testing Ruby, it will be easier for you to go back and try to write some tests in Rails.

> What is your recommendation on if I should focus on rspec vs minitest?

A person could make technical arguments for either. Deciding which testing framework to use depends on your objectives. If you're teaching yourself testing to become a more marketable developer, then I would definitely recommend RSpec. Almost every Rails project I've worked on (20+ production projects) has used RSpec. Having said that, it's less important which tool you choose and more important that you have a solid understanding of testing principles. I personally chose RSpec and I'm glad I did.

Here are some testing resources I often come across:

Growing Object-Oriented Software, Guided by Tests (awesome book, highly recommended)

Rails 4 Test Prescriptions (just started it, seems good so far)

Working Effectively with Legacy Code (super good book and more relevant to testing than it might seem like)

Everyday Rails Testing with RSpec (haven't bought it yet but seen it recommended a lot)

Destroy All Software (just bought it today, seems good so far)

Lastly, I myself created what I call a Ruby Testing Micro-Course designed to make it easy for people like you to get started with testing. Feel free to check that out and let me know what you think.

u/NilsLandt · 14 pointsr/rails

Smaller business logic frameworks would be mutations and ActiveInteraction.

They would replace the operations (and parts of reform) of TB.
Personally, I wouldn't use either of them over TB, they still add complexity, but don't offer too much over self-written stuff. YMMV of course.

If you want to start simple: create POROs for your "operations" with 2 public methods - initialize and run (or call, execute, apply, process etc.). Put your logic in them, create / execute them in your controllers.
Call them services, workflows, procedures, operations, scenarios, whatever.
try to put no persistent state in them - let them do their thing, return some sort of result (true / false, model / nil, small result object).

This fulfills a number of your criteria: it shouldn't slow you down much at all, it's simple, fairly maintainable and easily unit testable.

If you would like to research a different approach, look into DDD. The Arkency book should make for a good start, with the original DDD book giving quite a bit more background information.

> I'm not coding SPAs, so I still need awesome logic for Views / Presenters.

If you liked the Cells from TB, you can use them without using the rest of TB.
If you want something simpler, use a decorator like draper with ERB or Slim.

u/dr_g89 · 3 pointsr/rails

I don't know if there is a rails for node developers but they definitely come from two different perspectives on application development. Having written apps in both ecosystems I can say you'll be hard pressed to write an app faster with any framework other than rails, that being said it is convention over configuration and you need to do things the rails way to get results. If your looking for a starting place, there is a book called Agile Web Development with Rails 4 ( link: http://www.amazon.com/gp/product/1937785564 ). Its written in part by one of the inventors of the framework and is definitely worth the read. If your more familiar with NoSql I'd also recommend checking out mongoid, its an ORM for MongoDB and RoR and its pretty robust.

EDIT: While ruby and javascript have similar syntax ( if you can look past the curly braces and semi-colons ), learning about using ruby before starting with rails will be very helpful. Ruby is a wonderful language with a relatively easy learning curve but it does have its own idoms and caveats that are unique to it.

u/thibaut_barrere · 6 pointsr/rails

It's hard to provide a full answer just based on available information, but roughly you have many different ways to achieve what you have in mind.

Some families of ways to handle this:

  • ETL (Extract Transform Load) -> extract from CSV, during the process transform / clean / remap any field, if you don't do incremental reload you could also dedupe in the transform step, then load a "clean dataset" into either Postgres, ElasticSearch, etc
  • ELT (Extract Load Transform) -> extract from CSV, dump right into ES or PG (mostly unchanged), then modify there (or query a "temporary dataset" to do a sort of ETL, clean / filter etc, and pour the data into a more "final" destination in the same datastore

    What's the most adequate way to do this depends on various factors:

  • Do you want to deduplicate inside a single CSV (which can be achieved in memory before loading), or cross-CSVs (in which case you need a business key, with unique constraint, and do "upserts", or at least verify if you must drop the rows by checking id presence before)
  • Do you have many different CSV formats or are them quite different? (if they are quite different, it's often more easy to go ETL, to have a very flexible & well tested way to verify the mappings & conversions etc)
  • Are the outputs mostly largely similar with a bit of different fields, or mostly completely different?

    Finally, here are some tools which can help:

  • My own gem https://www.kiba-etl.org (which I use both for ETL & ELT scenarios)
  • Ruby Sequel https://github.com/jeremyevans/sequel (which is actually used by my upcoming Kiba Pro offer for database related tasks)
  • pgloader https://github.com/dimitri/pgloader
  • embulk http://www.embulk.org/docs/

    If you are into this for the long term, it can be worth reading a book that I often mention, which is the ETL book by Ralph Kimball. While quite old, it provides interesting patterns.

    Happy to detail this more if you provide more input!
u/evilduck · 3 pointsr/rails

Every dev could have an account and personal RVM or Rbenvs installed and whatnot for publically demoing an idea on an alternate port or just to monitors logs or whatever (just be mindful of their resource usage if that's something you want), but sudoers should be limited to people you have confidence in maintaining the system. The more vital uptime is, the less people who should have system access (maintain a trail of responsibility).

Capistrano should be a sufficient starting point for a straightforward single Rails app being deployed to a VPS. I would opt to run the app under it's own user account and manage your Ruby version through RBenv and not bother dealing with installing new Rubies (and gems) system-wide and the permission issues that comes with. Passenger supports running a site as a specific user, and you just have to set the Ruby path when configuring.

You can give everyone you want to allow to deploy to production their own private SSH key for the 'deployer' account and turn off password logins for that account entirely, and then everyone can deploy without needing to hand out a single set of credentials (and you can revoke access to anyone who becomes a problem by removing their SSH key from the deployer account and keeping the ./.ssh directory owned by a different admin user).

There's actually entire books dedicated to this topic though, and it's hard to give blanket advice since it's so contingent on your app's design, the mutual trust in the developer's abilities, etc. When you start having scheduled tasks and queues, and background jobs deployment configuration can get pretty hairy (which is why people love PaaS solutions).

u/yarhouse · 2 pointsr/rails

My primary books were Beginning Ruby: From Novice to Professional and Beginning Rails 3. Not to say these are the best and only books you'll ever need, but they are what I wanted in a text book; thorough, step by step application build in each one, online updates, code examples available for download. Really a great resource to get me started and I felt confident in my abilities by the end. At the very least I could understand what was happening in a system and be knowledgeable enough to know how to ask for help from other developers.
Because I had strength in HTML, I dabbled in a php book (PHP Objects, Patterns, and Practice ) as well that helped me understand some other core programming concepts.

u/djcp · 2 pointsr/rails

That article is specifically about legacy apps, and as such the good examples can be a little out of date. For instance:

class User < ActiveRecord::Base
scope :active, -> { where(active: true) }
scope :by_last_login_at, -> { order(:last_login_at) }
end

would just be:

class User < ActiveRecord::Base
def self.active
where(active: true)
end
def self.by_last_login_at
order(:last_login_at)
end
end

in a more modern codebase. Also, I think it's perfectly fine to use sql outside of models when you've extracted a bit of functionality into a service object. I think the nuance here might be articulated as "don't use sql in controllers, views, or other places it doesn't belong."

I agree with most of it, especially "extracting rake tasks to classes". If you're in the habit of extracting service objects to define interactions between things, you can frequently use these to make writing rake tasks easier, too and vice-versa.

Random things:

We created Hound as a hosted style checker, and I'm pretty fond of our guides.

I've worked on projects where we ran rubocop as part of a default rake. Took some care and feeding but it was handy.

You might also check out bundle-audit and brakeman.

Codeclimate does some very clever static analysis to find issues too, very worth it.

If you're looking for info about design patterns, I love Design Patterns in Ruby.

u/OtavioHenrique · 9 pointsr/rails

I advise you to learn ruby first, it will be good for your understanding, rails is a huge framework that helps the developer a lot, but on my opinion, know Ruby is a key for pretty understanding Rails.

I usually recommend eloquent ruby: https://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professional/dp/0321584104

But the are a lot of good books.

Some free content:

https://launchschool.com/books

https://www.ossblog.org/study-ruby-programming-with-open-source-books/

Some Udemy courses are good too.

u/purephase · 3 pointsr/rails

I don't think you need it explained from a Rails point of view. Ruby is an OO language, and Rails simply exploits that.

You need to learn proper design patterns in Ruby (which apply to most OO languages). Sandi Metz's Practical Object-Oriented Design in Ruby is pretty much the gold standard for Ruby and very readable.

It's based heavily off of Martin's Agile Software Development, Principles, Patterns, and Practices.

After that, you can look into SOLID but, in Ruby-land, I think the single responsibility principal coupled with the rules laid out in Metz's book (summarized here) is a good place to start.

Also, it's worth noting that if you have good test coverage it makes re-factoring much, much easier.

Good luck!

u/acconrad · 3 pointsr/rails

Extract properties into a class, so if you have a class like User and it has a series of address properties, create an Address class and extract those properties out into your new class and make sure it belongs_to :user. Then, if other types of classes need something similar (such as a Billing object), you can use the same class and have that belong to that object as well.

As far as naming, feel free to use whatever you want, though it might be best to use province instead of state since the word "state" in programming means something different, not to mention a province generally covers that same kind of location as a US state does (in fact I'm pretty sure under the hood Google Maps API handles it this way as well). Also make sure you store zip codes as a string since many countries use letters in their zips and US zip codes use a dash to include localized neighborhoods or PO boxes.

I'd pick up a book like Refactoring (Ruby ed.) which covers this pattern and a whole lot more.

u/kanjibandit · 2 pointsr/rails

How well do you know Java? I suspect you may be overestimating the time to it will take you to get comfortable in Ruby. Learning your first language is always harder than the second, because you're really learning two separate things: 1) how to program, and 2) the language syntax. The second time around, it's largely just a new syntax. Most of your knowledge of how to code will transfer. True, Ruby will introduce you to new concepts, but I think you'll find them rather more like new superpowers than like new obstacles.

Specific recommendations:

For Ruby, I like the book Eloquent Ruby

For Rails, I like Michael Hartl's Rails Tutorial

For fun and practice, look at Ruby Koans

u/AdvancedPizza · 2 pointsr/rails

This. The tests and charity model look good, but the website controller has too much logic and is tricky to follow. Beginning on line 9, there are 4 nested ifs / unless, which could be improved.

This would be something that should be refactored into a number of smaller methods inside a model like models/donation.rb or something alone those lines.

I highly recommend Practical OO Design in Ruby by Sandi Metz. Her talks and writing are excellent and approachable and can applied in a number of contexts.

u/rodreegez · 1 pointr/rails

I second the comment to learn SQL really well. Also regular expressions come up frequently enough to be worth learning a bit about. Some familiarity with data structures is worth picking up, and getting a grasp on some common design patterns is well worth the time.

On the last point, I’d recommend Design Patterns in Ruby and Refactoring Ruby

Hope that helps.

u/[deleted] · 3 pointsr/rails

can't go wrong with the RSpec book as a great starting point. great intro to cucumber too.

xUnit Test Patterns: Refactoring Test Code is a good read as well, though slightly more academic. a good substitute if you don't have the time is writing a shit load of tests and fully understanding what your assertions do.

also, stop testing the framework. nothing screams "amateur hour" like this:

describe Message do

it { should respond_to(:name) }
it { should respond_to(:email) }
it { should respond_to(:body) }
it { should respond_to(:phone) }
it { should respond_to(:subject) }
it { should respond_to(:sweet_honey) }

end

u/DanielKehoe · 2 pointsr/rails

My book series Learn Ruby on Rails is aimed at beginners, with background and explanations that are missing from other books on Rails. See the good reviews on Amazon but you can get Book One for free on my website or free from Leanpub or Softcover or Google Play. Maybe someone else will comment if they've read it.

u/kristophmatthews · 3 pointsr/rails

Hi there, I recommend this book: Rails 4 Test Prescriptions. https://www.amazon.com/Rails-Test-Prescriptions-Healthy-Codebase/dp/1941222196 It is the best book on testing I've ever read. In my experience, understanding how to write tests was not difficult. It was getting into the habit of testing, and understanding when to write tests and when not to that was a challenging art form. Hope this helps.

u/tjdracz · 5 pointsr/rails

To go further with Rails, it's a good idea to go further with Ruby. Some of my favorites:

Rails AntiPatterns

Metaprogramming Ruby

Practical Object-Oriented Design in Ruby

Everyday Rails Testing with RSpec

u/Nitrodist · 2 pointsr/rails

The Working Effectively with Legacy Code book is fantastic for bringing legacy code under test and then being able to refactor from there without breaking functionality.

Around 80-90% of the examples in the book can apply to ruby based projects with the remainder being C/C++ or other language specific problems (header files, being an example).

Just as important as the techniques explained in the book is the philosophy it espouses of bringing the code under test.

u/R3V3147i0N · 0 pointsr/rails

Rails Antipatterns by Chad Pytel and Tammer Saleh:

http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814

It's a little bit outdated, as it was written for Rails 3, but there's a lot of good stuff in that book.

u/oldbrownshoe08 · 1 pointr/rails

I've enjoyed the xUnit test patterns book. It's all about fundamentals that span languages and frameworks.

http://www.amazon.com/gp/aw/d/0131495054

u/acdesouza · 2 pointsr/rails

Do you know: Growing Object-Oriented Software, Guided by Tests?

It's main language is Java. But, the technics can be easily applied to Ruby environment.

https://www.amazon.com/dp/0321503627

u/jaryl · 1 pointr/rails

Well I've designed countless systems just like you did, then I wised up. You will too one day, just probably not very soon =)

You are building abstractions for the sake of having them. I won't offer you any pointers or counter arguments anymore, read this, then review your code:

http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330

u/saeglopur · 1 pointr/rails

I felt the same way coming from a C++/Java background where I started with a blank text file and just started writing my program. Rails felt too magical and I wanted to know how it works! Well the answer is you need to get Agile Web Development or [The Rails 4 Way] (http://www.amazon.com/Rails-Edition-Addison-Wesley-Professional-Series/dp/0321944275) and just start reading. They explain how every single line of every single default file in a Rails project works.

u/stefanmielke · 1 pointr/rails

Actually it's in USD, not BRL. As I said, it is not the amazon.com.br store I am looking, it is the amazon.com.

In the br store it's R$ 7.99 (link)

u/inflx · 3 pointsr/rails

I always see people jump into Rails before they get into Ruby. Or, worse, they think that Rails is a language.

The latter makes me barf. Specifically, the kid I interviewed who assured me that Rails was indeed a language.

http://learnxinyminutes.com/docs/ruby/ and then read POODR http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330

Then you should jump into Rails.