knuckle_cake

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.

https://gist.github.com/674726

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.

(Enh) .width() and .height() now report the width and height of hidden elements (#7225)

This makes me so happy I could cry.

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.

My co-founder is black.

Only x86, though. x64 isn't there yet. http://arewefastyet.com/?machine=4

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.

We're using OmniAuth and it works wonderfully. It beats dealing with JanRain/Gigya for a single signon solution.

Maybe this is a good time to toss up the half-finished 6502 simulator I have kicking around.

IE once was on Unix. Let the circle complete.

http://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX

a javascript/web worker/canvas/svg/heatmap toy

http://github.com/xxx/heatmap

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.

We know what his views are. It's more interesting whether he tells the truth about them publicly or not.

Looking into said IRC clients, they all look to use regexps like I'm also doing. buh.

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?

I'm writing a monitor for an emulator I'm working on, so your first example is what I am doing.

I was wanting for something that lets me add commands, with aliasing, and arguments (maybe with optional regex validation) - e.g. breakpoint add $BEEF, etc. Writing a DSL is one solution and will probably end up being the way I go once I take a second iteration at this. Right now I'm just using regex parsing, but I only have a few commands I need to worry about now.

cmdparse is frustratingly close but makes a few assumptions that you want to parse ARGV or something that looks like it.

I think you should continue working on it. If nothing else it builds your personal code library up. I'm not sure how many apps in general use ncurses anymore, but I don't think it's going anywhere.

I'm actually developing a console-based ruby app right now. What would have been useful for me however is something to easily work with a REPL (including commands, subcommands, etc.) without a) having to drop into a full IRB session b) any assumptions that I want to parse an ARGV-like line with --long-switches and whatnot. I don't.

cmdparse is the closest, but still isn't good enough.

Thanks for doing the work on your project. Open-source authors don't get thanked often enough if their project isn't used by millions.

While I don't have enough Django experience to give suggestions on that front, you can use BigTable if you want to move to Google App Engine, though the drawbacks may outweigh the benefits when dealing with an established app.

That said, I did recently make this choice for a Ruby/Sinatra app I'm working on, and ended up going with MongoDB due to conveniences like MongoMapper more than anything else (I wanted to enforce a partial schema without having to resort to silliness like customField1, customField2, etc.) I'm pleased with this choice so far, though plan to look at Redis again in the future when I need something lighter in weight for storage.

I prefer webrat ( http://github.com/brynary/webrat ) for this type of testing if I'm using Ruby. You can use a browser if you want, or just run browserless for tests that don't rely on javascript.

This phenomenon hit me hard when I was learning to play Poker back in the day.

Empty jQuery sets are truthy. The page gets this doubly wrong when it says an empty list is returned (instead of the 'Array-like' jQuery set.)

Check the length property of a returned jQuery set if truthiness really matters.

tl;dr: Author has hurdle updating app to Rails 3, so Rails has now jumped the shark.

thanks!

I've now gemified it for use in Rails apps without having to hit a separate site. It emits data URIs at the moment only, so no IE love yet. I had immediate need for it.

http://github.com/xxx/placeholder_image

JSON.parse will also choke on the out-of-spec JSON. If your AJAX interactions stop working with jquery 1.4, it's your AJAX that is broken :)

The one time I've run into this 'bug' in the past was on a site that used lots of javascript plugins, more and more of which are coming with their own CSS files nowadays.

Of course you can concat them together, but that adds a maintenance burden in the future whose size can vary wildly.

At the very least, there is a documentation bug here. The reason for this seemingly arbitrary limit should be documented by MS.