The Less gem has been superseded by less.js, which runs on the server with Node.js. More, the "official" Less plugin for Rails, hasn't been updated since June 14, 2010.
In light of all that, what is the recommended way to use Less with Rails these days? I suppose I could always just use client-side JS for this, which everyone seems to be embracing. But I'm not crazy about relying on client-side JS just to transform a stylesheet, especially considering that I'd like to degrade gracefully. I realize that Less.js is considered very fast, but as a matter of principle, I don't want my CSS to be utterly dependent on the browser's JS engine.
Assuming I want to compile Less server-side, what is the best practice these days for use with Rails? I know you can run Less using Node.js, but I'm looking for nice Rails integration such as we once had with More.
I'm looking for something that will work on Linux and Mac. Ideally, it would be a gem or a Rails plugin, not a standalone app.
Update: I'm looking into whether The Ruby Racer can be used to embed Less.js into a Rails app. Does anyone have opinions on that?
Update 2: This question is really old, but for anyone who's still interested, I just wanted to point out that Rails 3 comes with SCSS integration out of the box. SCSS is a LESS competitor, and I'm quite happy with it.
Try out less.app for Mac OSX. http://incident57.com/less/
Use it on your local dev to generate the CSS.
My only complaint is that the parsing sometimes gets tripped up on IE specific CSS rules that are invalid CSS but were handled fine by the more gem.
Also it doesn't handle the less partials (_file.less) that more does.
Bryan here, developer of Less.app
You can handle ANY IE-specific code in Less just by using the escape function, which takes a string. Thus, you could write: e("filter:alpha..."); in your LESS file and it will compile to the expected IE-specific (though non-standard) CSS.
See Lesscss.org for more info. The bit about the e() function is all the way at the bottom of the docs.
May be not helpful at all, but the approach we currently use (PHP/node dev) is client-side .less during development, and delivering compiled .css on deploy, using lessc. That can be integrated into build scripts or commit hooks, no bundled magic :)
Related
I have just started using 3.0.7. I am about 2 weeks of development in.
I was wondering if I should keep building for 3.0.7 or switch to 3.1 before I have too much code to port over? I like most of the new features (my only fear is not having good error messages when I use coffeescript), so I'd like to code towards the latest and greatest if it's relatively safe.
The javascript standards look interesting, and the attr_accessible fix sounds like it's very much appreciated.
Is Rails 3.1 compatible with all the gems out there though?
Also, if I go the 3.1 route, is hard or easy to migrate my project towards it? How might one go about that?
I guess this is a lot of mini yet related questions. I'd really appreciate some answers. Thank you.
I think if you want to ride on Rails 3.1 you should do it :). As for me I have some projects on Rails 2.3.5, 3.0.5 and would like to port them on Rails 3.1 but there is to much code there :). So don't be afraid and go to the fresh stuff (unless your code overflow :) ).
Rails 3.1 are pretty stable for now (I didn't have much problems with installing and using it)
If you're only two weeks into a project then it makes sense to stay on the edge and move to 3.1.
The way I'd do it is clone my project to a new dir (you're using git / similar version control, right?), change the Rails version in my Gemspec, run tests and play around to see what got broken (if anything). Based on the results you can figure out whether the effort is too great.
Regarding gem compatibility, hardly anything is compatible with all gems out there. Since you're two weeks in, you probably know which gems you use. Test like I suggested and you'll have an idea whether it's compatible with what you need. If you're using popular gems, then they'll most likely be updated to work with 3.1 soon enough.
is it worth the change from Rails 2 to 3 if im starting to work on a new application? are all the plug-ins and gems available for 2 now available for 3 as well? im used to developing and learning on Rails 2 and I'm afraid of switching over.
Thank You
You can check if the plugins you use work with Rails 3 here. Personally I'd say, if all the plugins that you use work with Rails 3 then you should upgrade, there are some nice changes in Rails 3 that are worth using.
I just started a Rails project a few weeks ago with Rails 3, and I've been quite happy so far.
Some gems/plugins don't quite work yet. For example, Selenium and friends seem to be a little behind, though after trying a few plugins I finally got it working fine through Capybara. In_place_editing isn't working out-of-the-box for me (I suspect because of Rails 3), though there are alternatives and it's not complex at all. And I had some trouble with factory_girl, though apparently there is a version for Rails 3 now.
But in general, most plugins I've tried seem to be working fine at this point. Maarons has already pointed you at RailsPlugins.org if you want to check for a specific plugin.
Finally, there are bunch of things that are just better in Rails 3 (see the release notes). I used Rails 2 for a smaller project a while back, and using Rails 3 now, I was pleasantly surprised by the new routing (much less confusing), and the added bundler support (makes deploying much less scary).
Since you're setting up a new project, I'll also mention that I've been quite happy with Ruby 1.9.2 (as opposed to 1.8.7). Check PragDave's blog post for some major changes. The only thing that I recall needing explicit tinkering was the debugger -- just use the ruby-debug19 gem and you'll be fine.
Fear isn't a good enough reason not to switch.
There are quite a few plugins that only work on Rails 3, so I'd recommend starting a new project with 3, if you're starting now.
I would expect this question the other way around :)
If you are starting a new application then I'd say always try to go for the latest stable versions unless there is some really good reason not too.
Not only does it save you the trouble of migrating at a later stage (which in a likely hood will happen sooner or later), but you get to improve on a personal level as well by learning something new. And the later is something I find very important. If it's not challenging, it's not fun, and if it's not fun, then it's not gonna be good (for me at least).
As for all plug-ins and gems being available, probably not but the ones that are still being develped and improved will be if they are not already.
You will have to switch eventually, so this is a good time. Why waste time on something you will have to change sooner or later? Rails ecosystem is quite responsive, and most plugins and gems are already 3.x compatible. Many have even deprecated 2.x support.
I'm totally new to Ruby but not to programming. All I did was going through try ruby and reading differences from other few languages I know better (mostly PHP and some Python). So I have no idea how Rails differ from Ruby and maybe this is an absurd question.
Anyways...
I don't want (or am able) to install Ruby on my machine and I'd still like to build a single working source file. Is it possible to have an online compiler of some sort? If so, how?
If I write a Rails web site (comprised of either one or many files) using any given host (that far I know I can), would I be able to use that same code with very minor modifications and just run as a Ruby app? Again, how?
(new) What about the other way around: a Ruby app turning into a Rails web page? Easy to do?
I really hope for a "yes" on them all, but I doubt on the 1st and not so much on the last. :)
There are online "IDEs" you can use to try out ruby:
http://ideone.com
http://codepad.org
But mind you that Ruby on Rails is a framework written in Ruby and those sites don't have RoR installed. Also note you that a Rails app has many, many files.
If you have the same code and same server configuration (version of ruby, database, plugins, etc.) you should only need minor modifications to the config file.
Ruby on Rails is on Ruby. So whatever works on Ruby should work just fine on RoR with minor modifications. However, you'll probably want to rewrite the app to take advantage of many of the features RoR provides.
I'm one of those developers who isn't using TextMate with any of his Ruby/Ruby on Rails work. My particular loyalty in this arena lies with vim. What are your favorite tips/tricks for using vim with Ruby and/or Ruby on Rails to make you as efficient as possible when working?
Most important
Get a copy of rails.vim it is awesome on millions of levels. Read the doc. There are way too many tips, :Rview customer, :RSmodel foo, :Rinvert, gf, :Rextract, :Rake and the list goes on and on. You will probably want NERDTree as well for easy navigation (which you can access using :Rtree)
Second most important
Follow tpope on twitter (the author of fugative, rails.vim, haml.vim, vividchalk theme, cucumber.vim and so on), he seems to be posting new related to Rails vim plugins quite regularly (be it syntax highlighting or git integration).
You might want to checkout my ruby/rails specific vimfiles.
Its a useful starting point and has many useful Ruby/Rails plugins bundled and configured.
The one thing that really sucks about Textmate is that it doesn't run on Linux. My vim/gvim config is the same on Mac, Windows and Linux. Same fonts, same themes, same plugins and same customizations.
I mostly use Textmate for snippets and quick evaluations for posting here.
I wrote an in depth guide on using Textmate features (especially Rails related features) in VIM. It's very relevant to this question.
http://www.jackkinsella.ie/2011/09/05/textmate-to-vim.html
I don't use vim, instead, I'm like those millions of developers using Textmate. Nevertheless, a colleague does use vim/gvim.
By looking at him work, one of the things I wish I could do in Textmate is the ease of working on multiple files at the same time. Basically, you can easily manipulate multiple windows, which is quite handy.
Is it even worth it?
I'm working on assessing a legacy code base for a client -- the source code has been largely untouched since 2007 and it's built with Rails 1.2.3.
My Rails experience began at version 2.1 -- the code is fairly stock/scaffold like and devoid of meaningful tests -- I was curious to even see if I could get it running locally -- but, I'm not even sure where to start. Right off it doesn't even know what 'rake db:create' means. Ha!
Is it going be a major pain to even getting it running in 2.3.5? Should I bother?
Would love to hear your thoughts.
Thanks
If you're going to be actively developing the site, then yes, it is worth sinking the time into the project to bring it up to date. A lot has happened since Rails 1.2 which will make development a much more pleasant experience. Life without named scopes or RESTful resources is really difficult. If you're just patching the odd thing here and there, it may be worth leaving it mostly as-is and just dealing with the eccentricities.
Since 1.2.3 is just prior to the releases building up to 2.0 where a lot of warnings and deprecation notices were introduced, you could have quite a chore.
Some things to keep an eye out for:
Migrations are now date-tagged, not numbered, but are at least backwards compatible
Many vendor/plugins may not work, have no 2.x compatible version, or need to be upgraded
The routing engine has changed, and the name of many routes may have changed, so see what rake:routes says and get ready for a lot of search-and-replace
I did this for a client with a smallish site. First, version control is your friend. Make sure you have the entire codebase committed.
Next, the basic recipe is as follows
Tag the current source
Update to the next release of rails (you'll have to google for the release announcement). My app was frozen, so I just had to freeze to that version
rake rails:update to update the config, scripts and js
Diff your working copy against the version in your scm. Make any changes necessary for the app
Update any gems/plugins if necessary
Start the app, exercise and test. Look for deprecation notices
When it all looks good, commit to scm and tag
Lather, rinse, repeat
For my client's app, it was much easier than I thought.