My old ThinkPad keyboard rocks: it has a trackpad and a trackpointer, types nicely, has a palm rest, and is generally awesome. It does not, however, have a Windows button: this makes using it under... well, anything... difficult.
I'm currently developing with a company-bought Ubuntu laptop after having used OS X for the last three years almost exclusively. Like Windows and OS X, it pretty much
Today I started receiving the following error when I tried to sftp to my localhost, both from the command line and from the Ruby Net:SFTP library:
$ sftp ftpuser@localhost
Password:
Received message too long 1399157792
Trivial digging revealed that ftpuser's .bashrc script was writing to stdout, which apparently is enough to confuse sftp all 'round. I modified the command it was running to
$ sftp ftpuser@localhost
Password:
Received message too long 1399157792
Trivial digging revealed that ftpuser's .bashrc script was writing to stdout, which apparently is enough to confuse sftp all 'round. I modified the command it was running to
Posted by
Unknown
at
5:10 AM
Struts 2 claims that "actions can be POJOs". Developers find out pretty quickly that not extending ActionSupport means you lose some Struts 2 functionality (primarily I18N and validation).
One source of confusion is what "POJO" means. POJOs don't mean you don't extend a base class. POJOs are classes not directly tied to unrelated libraries, specifications, etc. For example, Struts 1 actions were
One source of confusion is what "POJO" means. POJOs don't mean you don't extend a base class. POJOs are classes not directly tied to unrelated libraries, specifications, etc. For example, Struts 1 actions were
I was unable to log in to the Apple App Store while trying to update Xcode on my MBP.
Here's an Apple discussion thread regarding possible solutions.
What ended up working was signing out, clicking "Store -> Create New Account", accepting the Terms and Conditions, then canceling out of new account creation and signing in again.
While deleting the network interface plist, cookies, etc. was
Here's an Apple discussion thread regarding possible solutions.
What ended up working was signing out, clicking "Store -> Create New Account", accepting the Terms and Conditions, then canceling out of new account creation and signing in again.
While deleting the network interface plist, cookies, etc. was
I was running a specific rspec over and over during a tight development cycle. The way our system was set up it was taking 30+ sec to run a single spec file, which made running them onerous.
We had Spork running at one point, but it wasn't working for me, with a "undefined method 'flush' for nil:NilClass" error (and a couple of others depending on the incantation):
After upgrading Spork (we
We had Spork running at one point, but it wasn't working for me, with a "undefined method 'flush' for nil:NilClass" error (and a couple of others depending on the incantation):
After upgrading Spork (we
Ever write a trivial spec like this:
And get something totally baffling back, like this?
Backstory: Refactoring some pre-written classes to use metaprogramming to create some methods and values. I wanted specs in place before starting the metaprogramming to avoid breaking things.
In retrospect, I should have figured this out sooner. In my defense, I love the Olympics and was distracted. The
And get something totally baffling back, like this?
Backstory: Refactoring some pre-written classes to use metaprogramming to create some methods and values. I wanted specs in place before starting the metaprogramming to avoid breaking things.
In retrospect, I should have figured this out sooner. In my defense, I love the Olympics and was distracted. The
Singletons are evil, and here's why.
Fair enough. Yet they exist, and they're not intrinsically evil--just misused. Can we mock enough to make testing them feasible? Yep, and here's a Contrived Example™ that shows how (and why we might want to).
"Embedded" singletons or utility classes can make testing is problematic. Injected singletons are different; then it's an issue of whether or not it
Fair enough. Yet they exist, and they're not intrinsically evil--just misused. Can we mock enough to make testing them feasible? Yep, and here's a Contrived Example™ that shows how (and why we might want to).
"Embedded" singletons or utility classes can make testing is problematic. Injected singletons are different; then it's an issue of whether or not it
Subscribe to:
Comments (Atom)