I know Github.com uses Rails.
But what template language does Github use? And what css framework does Github use?
Yes, Github uses Ruby on Rails.
When asked about the technology stack that they use to Sam Lambert, Director of technology he said:
MySQL is our core data store that we used for storing all data that powers the site as well as the metadata around the users. We also use Redis a little bit for some non-persistent caching, and things like memcached.
C, Shell, Ruby — quite a simple, monolithic stack. We’re really not an overcomplex shop, we don’t intend to try and drop new languages for every small project.
Here's a link to see the projects that power Github.
Edit
The original question was somewhat confusing and seemed to conflate Github with Rails. My answer below aimed to clarify the difference. The changes/clarifications made to the question later (after I posted my answer) have lead to the answer below to no longer respond to the question as (now) posted, but I cannot delete the answer as it has been marked as accepted...
==================================
It's hard to tell from the wording, but I think you're confused about several languages/tools that are found in Rails. Maybe this will help:
Git (http://gitscm.org/)is a version control tool (http://en.wikipedia.org/wiki/Revision_control) used frequently in Rails projects. It's used to manage the source code in your projects (versions, branches with different functions, etc.)
Github (https://github.com) is a place you can store source code that is managed with Git
the default language used in Rails views is called ERB (introduction example here: http://thinkvitamin.com/code/rails-views-erb-part-1/)
rails 3.1 uses Sass to create CSS files by default (http://sass-lang.com/)
Those are the languages you've mentioned having trouble with, and they're a portion of the languages you'll need to familiarize yourself with if you want to use Rails to its full extent.
You can learn more about Rails online (for example: http://ruby.railstutorial.org/, http://railscasts.com/), or with books (http://pragprog.com/book/rails4/agile-web-development-with-rails and http://www.manning.com/katz/ are 2 good books. The first one is easier for beginners, the second one goes into more detail and is for more advanced readers).
It appears github has moved towards converting their monolith from rails into microservices made in other languages. Doubtful rails is completely out of the picture IMHO.
https://www.theregister.com/2018/08/16/github_rails_microsoft/
Related
I have read through Q&A/articles that explain the ideal structure of a Ruby project. I read the RubyGems guides on how to create a Ruby gem. I have just read a Q&A asking at what point a ruby project becomes a ruby gem but I can not for the life of me see the difference between the two. The structure seems to be the same. The files, where they go, everything looks the same to me. Is it how they're used? Can someone please explain the difference between the two to me?
The question that must be answered respect to 'Gemify' or not is: am I writing something that is readily reusable in a different context? If the answer is yes then your application is a candidate for 'Gemification'. If not then generally it is not worth the additional complexity to convert a Ruby project into a Gem.
For example. If one makes a CLI Ruby application that collects mortgage rates from multiple vendors and updates a database then there are two ways this could be converted into a gem.
First: You could generalise the interface/configuration and make it useful as a plugin/add-on/extension to projects written by someone needing the same or similar functionality. So someone could add the gemified version to their project and use it to do the grunt work for them and just make use of the results. This describes the most common use case for gems.
Second: However, you could also extract the framework of your CLI project layout into a generator gem for others to easily create their own CLI project layouts. This is how Rails came to be.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.
I know many Ruby users are using Jekyll but I wonder what the benefits that will bring over RefineryCMS?
Could someone highlights the differences and pros/cons for each.
I'm one of the core developers on Refinery CMS.
The architecture of each project is vastly different. Here's a few things Refinery CMS has:
Web based interface (just go to /refinery to login and edit content)
Visual content editing (but also supports editing in plain HTML)
Stores it's content in a database (MySQL, SQLite, PostgreSQL - your choice)
Suitable for non technical people to edit
Supports Rails 3
Supports localisation in 11 languages (and you can add your own)
Support and docs: IRC, Google Group, Tutorials, API docs, Github repository
I can't be authoritative about Jekyll (maybe mojombo can answer) but it looks like:
Static content editing
Stores it's content in files
Developer focused, not suitable for an end user to edit
Markup based editing
Will load slightly faster as the pages are static
I hope that helps weigh it up. It all comes down to your project requirements.
Well, jekyll is 100% static. All files are generated into static HTML. Jekyll is amazing for small sites that don't really need dynamic content. With jekyll you write the content in your own text editor.
I haven't tested RefineryCMS, but it is more like what you would think of as a content management system with data stored in a database managed through a web interface. If the site is going to be managed by non-tech people, I'll say jekyll is a no-go and that refinery is a better choice.
RefineryCMS is fully Rails 3.0 compatible and they offer great support over IRC. Furthermore RefineryCMS is a fully featured CMS with a localizable interface while Jekyl is not. It all depends on your projects needs.
The best thing to do would be to install them both and play. You will soon see they both serve two completely different purposes. Refinery is a CMS and Jekyll is a static site generator . Jekyll is not built for content management.
What are some of the best practices for OOD with Ruby? Mainly, how should files and code be organized?
I have a project that uses several classes and files and I am just wondering how it should all be organized, grouped and included.
It sounds like you're asking which pieces go in which files.
Is your project a Web application? In that case you would most likely use the system of organization imposed by your framework (Rails, Merb, Sinatra, etc.)
Other kinds of projects also have their own typical structure that you can just follow. E.g. gems are usually set up in a certain way.
If it's a console app, there's no strict rule. Usually people put no more than one class or module in a file. You could have one main file that requires all the others.
Standard OOD concepts apply to ruby. For specifics, maybe this guide will be helpful:
http://www.rubyist.net/~slagell/ruby/oothinking.html