So, you had perfectly running tests. You were happy with nose.
Then (maybe you mounted a volume over to a VirtualBox guest, or you copied your code to another filesystem), disaster, now nosetests is unable to find any tests (reporting 0 tests to run).
You tried everything. You renamed the tests. You printed shit inside the test file, to no avail.
Well, check the test files permissions: if it’s xecutable, nose won’t consider them tests…
screen /dev/tty.usbserial 38400
I recently gave grunt an extensive test run, on a number of (relatively varied) WebItUp and Roxee projects, in order to evaluate its use for our clients and internal projects alike.
Indeed, grunt is appealing, at least for “web” projects (and most projects are “web” nowadays, for the better or worse), at least more appealing than rake/make/poisonake – web projects that ought to perform the same well identified build operations over and over again (hint-ing, test-ing, karma-ing, uglify-ing, you-name-it-ing).
If you don’t know what docker is yet, you may read this.
In a word, docker is to linux containers what the meat and beer is to the idea of barbecue (sure, you are free to try without, but, hey, why not try ferret legging while you are at it? :-)).
Linux containers provide a lightweight virtualization mechanism. While you do have less isolation than with traditional virtualization technics, you consume a lot less resources and can “boot” way faster.
Then Docker provides tools to manipulate and setup containers easily, and to “describe” requirements and software deployment operations.
I never, ever, bitch on the internet. This is an exception.
I started writing this as a comment on a recent Beyond the Code blog post – though what I would like to say sometimes goes OT to the original post, and… Posting my comment (twice) ended-up with a blank page, pending POST, and 405 on the subsequent GET. Maybe somebody tripped on the lizard tail there and disabled comments, in a truly open-web fashion?
Either way… This has been bugging me for quite some time, and I need to get it out of my system in order to get back to useful stuff.
Having to refactor such codebases, written under the influence, may require a cheat sheet to quickly spot firefoxisms, and there doesn’t seem to be a good list out there.
So, let’s try establishing that list. If something is not there, add a comment on that post.
The purpose is not to list what might work, and where – just what is not standard among Firefox features (and using non-standard features is pretty bad, right?). In other words, what should just be avoided / removed, in a web context aiming at being cross-browser.
Non-standard for Strings
Non-standard stuff for Objects
Non-standard for Functions
Non-standard for Arrays
Various non standard stuff
Just found Kangax great list.
AMD? The hardware company?
- refactoring code is a dangerous task
- large codebases have unclear dependencies
- code tend to quickly become unmaintainable and unclear if not written very carefully
- lazy-loading of additional code is not trivial to do right
Apps that want a custom title bar on OSX usually have a NSBorderlessWindowMask on the NSWindow, with the drawbacks of:
- Not being able to switch workspace by reaching the edge of the screen
- Not being able to minimize to dock on double click (if the user activated the setting in the pref panel)
But it’s possible to fix #2.
The trick is pretty much how to access the user preference:
NSString *const MDAppleMiniaturizeOnDoubleClickKey = @"AppleMiniaturizeOnDoubleClick";
NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
bool shouldMinimize = [[userDefaults objectForKey:MDAppleMiniaturizeOnDoubleClickKey] boolValue];
And voilà. The rest is piece of cake: catch double click on your custom header, check the value of shouldMinimize, then call minimize on your window.
We implemented it successfully in Roxee (QT).
Credit goes to user NSGod on stackoverflow.
Applications on Mac that wish to have a “custom” title bar can go two roads.
The easiest IMO (and the one that allow seamless integration with the app body itself) is to go Qt::FramelessWindowHint (or NSBorderlessWindowMask).
This is what we do – and I’m pretty sure this is what Rdio does as well.
Usually, that means you have to implement moving yourself (and probably resizing as well).
There is one caveat: there is no Cocoa programmatic way (AFAIK) to make the app switch workspace (this is usually triggered when moving an app to the current space edge, and waiting a bit).
So, our Roxee client fails here…
Spotify works ok (but I’m pretty sure they don’t do NSBorderlessWindowMask, but rather have a custom title bar).
And Rdio fails, just like us.
At least, we are not alone.
And I would be glad to hear about any solution to this that doesn’t involve messing with private Cocoa API…
Rdio guys know about this