Replying to my own comment, but Chris Eppstein has put up a gist of some differences, both syntactical and semantic, between SCSS and LessCSS. They are very, very similar to each other now, as I thought.
In my experience, no. After generating the CSS, we run it through YUI compressor for the deployed version. Any size differences remaining are measurable in bytes, and the ability to truly refactor our stylesheets more than makes up for that small difference.
We've been using Sass in production since we launched. Love it.
I've not seen any real comparison between LessCSS and SCSS (i.e. the new Sass syntax that became available with Sass version 3.0) There were some real differences before that, but that's not nearly so clear to me anymore.
At present, we've decided that there's no reason to use LessCSS as we already use Haml and there's nothing that Less offers that gives us a reason to switch from recent versions of Sass. I'm not even sure what the differences are now.
One method I've used (with Ruby) is use of FakeWeb, and collecting the various responses from oauth providers to test against. It's the closest I've seen to hitting the real services.
If you're testing javascript, you'll need to use Selenium or something similar.
We married OmniAuth with Authlogic to handle username/password (we're still on Rails 2, so no Devise for us). It wasn't too bad. Handling the validations for users was the tricky part, but Authlogic offers a ton of help in this area... way more than I expected.
I recall a similar service a few years back which went a step further and encoded the text into an image, which allowed the sender to revoke the entire message at a later time.
Google is not finding anything; maybe it's gone now.
That may just be a language barrier. The smart ones will at least listen if you can show them the added costs they'll be paying for nickel features like this.
There is a lot of info here, but it's attempting to focus on too-wide of an audience. The Javascript 101 section would be better left on the cutting room floor (or put into a separate article,) for example.
What is here looks really solid, though there are nitpicks for the pedants to find and gripe about. I am especially interested to see what shows up eventually in Part III.
Big, big kudos to the author for putting everything onto a single page.
I looked at both already. Both assume ARGV-like command strings with --long-switches with no way to get around that without significant rewriting/additional feature work.
Of everything, cmdparse is closest to what I want (by a significant margin,) but it's GPL (not LGPL :( ) so I'm not even sure I can use it in a non-GPL app. If cmdparse were under less-restrictive licensing I would have just hacked it up and released it already. I had already started doing so until I saw the license.
Right now, just writing a DSL is likely going to be my solution. I can bind an irb session to the monitor to keep scope from running away I think. Writing my own command parsing library just isn't interesting enough to me and I don't think I would ever finish it. This itch isn't quite that strong, at least not now.
What I really should do and am going to do later is look into irc clients written in ruby to see how they are doing it. They would probably run into this same problem.
Interesting, but it looks to require irb, heavily pollutes the global namespace with commands, and assumes I want to use --options-with-dashes. This is another 'close, but not quite' example.
The current implementation is that I have a hardware instance (like a CPU) that I want to monitor. To do that, I create a new monitor object, and tell it to monitor the hardware instance, and the monitor will mix itself in from there. It's not good if extra methods show up in the global namespace just for command parsing within a single module of the app. The monitor is just a part of this application, and a part that will not be used often by most users.
Everything I see feels like it's inches from what I really need. So close yet so far :)
Unlearning CVS/svn is the truly difficult part of learning git.
These complaints could only come from someone who has used CVS/svn in the past and expects git to work exactly the same way.
Are there any extant articles of someone who has never used source control at all before having these problems with git specifically and not other SCMs?
https://gist.github.com/674726