Yes, and several C/C++ conventions and types seemed to make that a safe choice, for example wchar_t. Let's face it, collectively we really screwed this one up. It's the biggest mistake since Microsoft chose the backslash as a path separator in DOS 2.0.
It was actually IBM's fault: they used '/' to denote CLI args in the apps they wrote for DOS 1.0, which didn't have any concept of directories. From Larry Osterman's blog :
> Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics. So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.
IBM licensed DOS from Microsoft. Microsoft bought DOS from Seattle Computer Products QDOS. That software got its command line switches using "/" from CP/M for compatibility reasons; originally, both CP/M and MS-DOS were available for the IBM PC.
CP/M borrowed the convention primarily from RT-11, the OS for the PDP-11, although it wasn't consistently followed there. Programs on RT-11 were responsible for parsing their own command line args, and not all of them used the same convention.
Inside Windows itself, most APIs accept either forward or backward slashes in paths (even both in the same path) without any special incantation. The problem is mainly at the application level where the whole forward/backward slash thing gets messed up because technically you should accept either one from user input and most app code expects one or the other.
I use most of these methods for caching. I have my own little methods for making cache keys. I use Rails.cache all over the place. I have a couple sweepers. What I really struggle is testing this stuff. You really can't do it anywhere other than an integration test, and they're ugly. I mostly just test the sweepers. Anyone have any nice solutions for testing caching, or think its unnecessary?
I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?
Oh great another ultra thin laptop with a glossy screen that will probably last 1-2 years until you buy another one that is even thinner and the screen so shiny you can use it as a shaving mirror. Give me a laptop that will last me more than 2 years and then I will give a damn.
Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.
I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system.
Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.
GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".