My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Most online developer API services that I've used are set up as if the customer is also the software developer.

That should change.

As the software developer, I don't want to be the owner of my customer's accounts, and I don't want to worry about trying to figure out how to transfer ownership (if your service allows it, that is). Because of that, theres a lot of waste that goes on: wastes of my time, which wastes my customer's or my company's money.

I'm saying "customer" here, but you might substitute that with "the person who really needs / cares about the account," because that person, in my estimation, is rarely the software developer. Unless I'm developing an app for myself, I only care about that API because someone else needs me to. And even when I'm developing for myself, I hope it gets to a point where I need to hire someone to care about it on my behalf, so I can focus on more important things.

The typical signup process for me goes like this: More...

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

When you first introduce someone to source control, things often go smoothly until the first time they have to merge conflicting changes. Then they wonder,
What's the point of this? I thought it was supposed to be easy but it's a PITA.
Two responses on how to combat this immediately come to mind.

The first thing that can help in this situation is to ensure they aren't having to merge useless files. I'm thinking of files here like the CSS generated from SASS: they change frequently but the changes don't affect them one way or the other. (In this case, because the CSS will be regenerated). Another example is a user-specific project settings file.

Two strategies to avoid useless merging are to ignore files (do not have the repository track them) and to automatically use one version of a file or another. Each has it's place.

In the case of a file that needn't be in the repository to begin with -- things like Thumbs.db or .DS_Store -- you should obviously ignore them. In the cases where files should be in the repository, but where you know which version you want all the time, you should consider telling it to always choose one file over another.

If you're using git, .gitignore will help you ignore files, while .gitattributes will help you choose one file over another without specifying it every time. I only wanted to make you aware of this, and Pro Git explains it better than I could, so I'll let you read about how to do it over there.

Thanks to Markus Prinz who helped me find .gitattributes when I didn't know the term I was looking for.

So what's the second thing that helps a newcomer to source control overcome their hatred of merging conflicting changes?

Remind them the alternative is to consistently have their own work overwritten.

Yesterday I got sick of typing rake test and rake db:migrate and being told
You have already activated rake 0.9.2, but your Gemfile requires rake 0.8.7. Consider using bundle exec.
I know you should always run bundle exec, but my unconscious memory has not caught up with my conscious one on that aspect, so I always forget to run rake under bundle exec.

So I wondered aloud on twitter if I could just alias rake to bundle exec rake, but confine that setting to specific directories (with bash being my shell).

Turns out, it is possible with the help of another tool that Calvin Spealman pointed me towards: capn.


I recently got the EEE Box "Nettop PC" (Linux version) and was surprised to find Red Flag Linux as the preinstalled flavor of choice. My goal is to use it as a wireless NAS, but keep it both expandable with external drives and available for use in home automation.

source code for r-house available via github


A quick note for people who get irritated when they forget to push alt/option on the keyboard when they want to boot into another OS on their Macs:

rEFIt might be for you. It changes the boot-up sequence and pauses every time you boot to allow you to select which OS you want to use. It does other things as well, but I haven't used them yet.

Special thanks to Grant, who introduced it to me this weekend before he left for Scotland. I think it's going to be a nice time-saver.


Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner