It really depends on your general skill level and how deep you are into RoR. But I'll try to give a few generic tips. Coding conventions Ruby and Rails are not just a programming language and a framework. They have an extensive set of rules and best practices that have been proven to work best in the long term. So, first of all, read and learn by heart The Rails Way and Rails Antipatterns (this is a bit out of date - Rails 3 - but still an incredible source of things-to-avoid in RoR). Learn to use rubocop and enable the Rails-specific cops. It will report style issues in your code, as well as methods that need some refactoring to make them easier to follow. And in most cases it can fix them automatically with the -a flag. CodeClimate is another tool (free for open source) to check the quality of your code. It will run a suite of (mostly) open source tools to find style issues and other hotspots in your code. Learn to test This is not just for Ruby on Rails. You should test all of your code. If you still have not, learn the difference between unit and integration tests. Learn to use RSpec and Cucumber. And learn to make testing an integral part of your workflow. Get used to automated tools like Travis. Learn the ecosystem Rails has a huge ecosystem of gems, that has only recently been surpassed by NodeJS packages (which is not necessarily a good thing, given the state of JS). You should understand when it's time to use a gem, and when it may be better to reinvent the wheel. You need to manage authentication? Use devise. Cron job? Whenever. File Uploads? Paperclip (or maybe ActiveStorage) [And so on...] When choosing a gem, learn to check it's health. Check out the number of GitHub stars and forks. Check whether it has an extensive test suite (some gems have a badge with the test coverage). Check whether it has large dependencies (do you really want to add 25 (mostly-unused) gems to your runtime memory?), and that they are compatible with yours. And most importantly check that it is up to date. If the last commit is from 3 years ago, run away. Talking about scalability This is a big issue with Ruby. Today we can assume that RoR can be scaled just like any other programming language. In fact, it's not the language that dictates the scalability of a project, but how it's used. Write thread safe code. Learn to optimise your DB queries and use appropriate indices (or if you wish, why not trying one of those new shiny NoSQL dbs?). Learn to use cache correctly. Finding a good way to expire caches is one of the hardest thing in computer science (a quote from Phil Karlton). The fastest HTTP request is the one not made. The second fastest is the one that doesn't leave the Browser The third is served by a CDN cache The fourth is built from a server cache. And when it's time... Try to move to a Microservices oriented architecture.

Good point! Accessibility should always be kept in mind. It's so sad when you're constrained by timelines and your boss is not interested in that relatively small slice of internet users.

On a pure stylistic point of view, they are pointless and behave exactly like the <div> tag. But, they do have a purpose: to give semantic value to the page content. While a human being can easily distinguish what is the header and what is the footer on a webpage, a computer program will have hard time at making this kind of inferences. Now, you may think that your web page is to be consumed by humans, not programs, and you're probably wrong: don't forget Search Engine bots. By using proper tagging, googlebot (just as an example) will be able to give meaning to what would be otherwise just a pointless div. Google can this understand what is the REAL content of the page, what is navigation, and what is simply appendix.

A point I still have not seen considered by anyone in the Internet, like if I am the only one concerned about this: Without Net Neutrality ISPs are allowed to favourite whomever they want. This also means that they may slow down HTTPS and favour HTTP. While it looks like an extreme scenario, I wouldn't consider this among the less probable. ISPs are known to do obscene things with our connections and data, not even counting the Netflix ransom. They could potentially force a downgrade to HTTP. Why you may ask? With plain HTTP connections they get the possibility of injecting code into websites they do not control (directly). This means that your ISP may inject advertisements, tracking scripts, malwares and god knows what into your daily routine. This may also be incited by "higher autorities", police, FBI, NSA, The President. They would benefit a rollback to HTTP by all means, allowing tracking, censorship and identity profiling. Is this the web you're asking for?

Wow! Is Sizzle still there? I think jQuery is using document.querySelectorAll these days (and falling back to Sizzle when not available)

An IDE is just a very complex Web Application. Learn to make Web Applications. Try with way smaller things. Scale up.

You invited the right person for this question! I'll tell you my story. 4 years ago I was living with with my parents in Naples, southern Italy, where people still think Java and Oracle DB is the new hot thing. (Meanwhile, in the north of Italy, I know for sure there are some companies using RoR - no more than 10 anyway). I was doing a lot of C++, PHP, JS and (oh my gosh) some WordPress development. One day, for no particular reason, I decided to learn Ruby on Rails. For my particular background I found Rails very steep to learn, yet incredibly satisfying. I had no plans at all, and back then I was still a University student. When I felt confident enough I added "Ruby on Rails" on my LinkedIn profile and made sure that some friends upvoted that skill for me. After ~6 months I get this email from a company in Naples looking for Rails developers. And I thought: you're kidding me, no way anyone is using Rails 500 miles from here. So, what did happen? This company started with two Developers, and they were given freedom of choice for the language. They didn't know anything about RoR but decided to give it a try anyway. Fast forward 1 year, they left the company and moved abroad. The company started desperately looking for other RoR developers in the area, and looks like I was the only person in a 400 km radius with the skill on LinkedIn. I got interviewed and hired. You cannot imagine the monsters I had to fight in that code, being developed from two people experimenting with the language while building it. 6 months ago I left that company. I now live in London and have been hired as "Senior Ruby Developer" whatever that means. So, I may have been lucky, but being the only one practicing a skill in a geographic area can be a strong advantage! Also, RoR is awesome. Finally, RoR jobs are usually paid 10 to 20% more than other development jobs, mostly due to developer scarcity - and for the low time to market that Rails provides.

I am not a fan of rails_admin. But it really depends on what the users are ought to do. If your users must use the dashboard to write "posts" for example, rails_admin is an overkill. Writing a controller and some views will take 30 minutes and you can customize them as you wish. If your users are expected to manage a complex e-commerce application, then maybe you could use rails_admin. Do use devise. Do not create two models. Have a single User model, with an admin boolean flag. Control access to the Admin Dashboard with a before_action hook in the Base Controller for the Dashboard itself.

Hipkiss said that we are humans, and he's right. In fact the first computers we tried to build were based on the human-friendly decimal system. Wikipedia knows more. So why didn't we keep on using 10 digits, so easy to understand? It didn't work well. Let's say you were to build one of these computers. You have a copper wire, and you have to transmit, using a single current "shot", a signal that can represent 10 values. You may map no current to 0, up to 10V to 1, up to 20V to 2, up to 30V to 3 and so forth. The problem with this scheme is that keeping the current stable is very hard. Current fluctuates all the time. You would end up make wrong readings so frequently that your computer would be useless. Now, there are ways to improve the signal quality, but your risk of adding more complexity to keep the signal stable, than to do processing itself. So, we have fall back to binary. Approximately 0V is read as binary 0 (there's tolerance up to 0.8V IIRC) and approximately 5V is read as 1 (anything more than 2V, actually). There is a no-fly zone between 0.8V and 2V. Any signal in that area cannot be interpreted reliably. What happens next is implementation dependent. Reboot? Retransmit? Halt?

I don't like bloat. Whenever I develop, I want the absolute minimum of distraction that it's needed to complete a task. I've been through many IDE/Editors (in order of discovery): Visual Studio, NetBeans, the JetBrains suite, SublimeText vi and Atom. I started with C++ and C# and fell in love with VS. When I started working with Ruby, RubyMine looked like the only choice, and for many developers, it still is. For me... it's just too much. I loved RubyMine but,_ _just like all the previous ones, it takes too much time to open, too much to index the project, too many buttons, too many settings. I just want to write code and see it working. I went to SublimeText and now its OpenSource incarnation: Atom. Sometimes, for smaller tasks or even small projects, I do enjoy using vi (beware: too many plugins and you have a bloated vi environment too). For me (and in this moment), Atom represents the perfect balance of essential features and speed that I need when writing code. I can use the command line for anything not strictly required in the IDE, like Git, starting and managing the Rails server and setting breakpoints. (Yes, I know. SublimeText is way faster than Atom when handling huge files. But do you really open 3+ MB files in your daily development job? You're doing it wrong.)