Official documentation for Python on Mac OS X

Programming in a startup is much different than programming at a big company. At a startup, not only are you the developer, but you are also the systems administrator for the most part. I've been startupping for three years now, and have had my ass kicked enough times to step back and think that maybe I should learn how to do things the right way rather than try to bludgeon my way through with raw intellect.

These are the things I wish I had known in the beginning, or at least I wish I hadn't been too subborn to learn

I've been coding since I was 8, on a shoebox z80 micro. I'm 36 now, and getting to the end of a masters in computer science, while working a sysadmin/support job. I've wielded everything from a krone tool to rails, and basically lived an extremely techy life.
And I don't much care about any of it any more. I click pretty much by reflex on cool coding blogs, tech-industry press releases, and everything inbetween, and.. the fire is gone. Awesome new programming language? Stunning new web framework? Terribly insightful article on best coding practices? Hardware I would have given my left eyeball for a decade ago? Video game of the decade being released next week?
Yeah, that looks really useful, I guess. Hm, never thought of that. Uh huh, cool. But increasingly, I feel like I'm faking what little interest I do take in these things in order to live up to my self-identification as geek. And on the inside, it feels like I'm reading news and opinions on the plumbing industry instead. New 9/16" reverse-threaded PVC collar-grommets being released tomorrow! Read our special report on advanced grouting techniques for damp environments! Hilarious tales of clueless customers - one guy tried to flush a coconut!
I. Don't. Care. Any. More.
And this scares the fuck out of me. I'm finally getting some qualifications to keep me gainfully (and hopefully more-profitably) employed in the IT industry (and god knows I'm not qualified for any other), I'm finally living the dream... only to find that I'm not actually dreaming of it. It's like hitting puberty and no longer giving a shit about cartoons - except that this is my career and all I've ever really done.
What the fuck? Is this some kind of sick joke? Does this happen to everyone and they just never talk about it? How do you cope with this? Okay, so I'm doomed to as boring a line of work as anyone else, guess I should have seen that coming. But what do you guys care about to take its place?

### Online Tutorials
[Ruby Learning][13]
[Official Ruby on Rails Guides][14]
[Rails Tutorial][15]
[Why's (Poignant) Guide][16] \[Thanks timinman from [HN][17]\]

### Courses
[Engine Yard University][18]
[Blazing Cloud Courses][19]
[Ruby Mendicant University][20]
[Jumpstart Lab Courses][21] \[Thanks Jeff from [twitter][22]\]

### Interactive Tutorials
[Try Ruby][23]
[Hackety Hack][24]
[Ruby Koans][25]
[BitNami][26] \[Thanks Daniel from [comments][27]\]
[Rails for Zombies][28] \[Thanks Gregg from [twitter][29]\]

### Books
[Learn to Program][30]
[Humble Little Ruby Book][31]
[The Rails Way][32]
[The Rails 3 Way][33] \[Thanks Raj from [comments][34]\]

### Blogs
[Ruby Inside][35]
[Ruby Reflector][36]
[Engine Yard Ruby on Rails Blog][10]
[PlanetRubyOnRails][37] \[Thanks jim\_h from [HN][38]\]

### Screencasts
[Railscasts][39]
[PeepCode][40]
[Ruby on Rails 3 Tutorial][41]
[Lynda.com][42] \[Thanks eAlchemist from [comments][43]\]
[Learning Rails][44] \[Thanks eAlchemist from [comments][43]\]
[Learnivore][45] \[Thanks Thibaut from [comments][46]\]

### Podcasts
[Ruby on Rails Podcast][47]
[The Ruby Show][48]
[Teach Me To Code][49]
[Ruby5][50] \[Thanks EppO from [comments][51]\]
[RubyPulse][52] \[Thanks pdelgallego from [HN][53]\]

### Forums
[Rails Forum][54]
[StackOverflow][55]
[Engine Yard Community Site][56]

### Community
[Ruby Meetup Groups][57]
[Ruby on Rails Community][58]
[][58][Confreaks][59] \[Thanks pdelgallego from [HN][53]\]
IRC Channels: [\#ruby][60], [\#ruby-lang][61], [\#rubyonrails][62], [\#jruby][63], [\#rubinius][64]

Dependency injection (DI) in object-oriented computer programming is a technique that indicates to a part of a program which other parts it can use, i.e. to supply an external dependency – a reference – to a software component. In technical terms, it is a design pattern that separates behavior from dependency resolution, thus decoupling highly dependent components.
Developers of software strive to reduce dependencies between components for various reasons. This leads to a new problem, though: How can a component know all the other components it needs to fulfill its purpose?
The traditional approach was to hard-code the dependency. As soon as the database driver was necessary, the component would execute a piece of code that would load a specific driver, configure it, and call the necessary methods to interact with the database. If a second database must be supported, this piece of code would have to be modified or, even worse, copied and modified (violating the DRY principle).
The dependency injection offers a solution. Instead of hard-coding the dependencies, a component just lists the necessary services and a DI framework supplies these. At runtime, an independent component will load and configure the database driver and offer a standard interface to interact with the database. Again, the details have been moved from the original component to a set of new, small, database-specific components, reducing the complexity of them all. In DI terms, these new components are called "service components", as they render a service (database access) for one or more other components.
Dependency injection is a specific form of inversion of control, where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to describe the mechanism more clearly.[1]

AppleScript is Apple's powerful and versatile native scripting technology for Mac OS X. With AppleScript, you can control, and communicate among, applications, databases, networks, Web services, and even the operating system itself. You can make your Macintosh applications scriptable so that users can write scripts to automate operations they would rather not do manually, from simple tasks to complex workflows involving multiple applications. AppleScript Studio enables you to build individual scripts and workflows into rich, functional Aqua-compliant applications, and is useful for rapid prototyping, automated testing, and other kinds of development. By taking advantage of the AppleScript support integrated throughout Mac OS X you empower your users to be creative in solving problems on their own, and you don't have to build a separate solution in anticipation of their every need.

Tools and APIs required to build applications for the iPhone platform using the iPhone SDK. User interface designs for mobile devices and unique user interactions using multitouch technologies. Object-oriented design using model-view-controller pattern, memory management, Objective-C programming language. iPhone APIs and tools including Xcode, Interface Builder and Instruments on Mac OS X. Other topics include: core animation, bonjour networking, mobile device power management and performance considerations. Prerequisites: C language and programming experience at the level of 106B or X. Recommended: UNIX, object-oriented programming, graphical toolkits Offered by Stanford’s School of Engineering, the course will last ten weeks and include both the lecture videos and PDF documents. A new lecture will be posted a week after each class meeting. Subscribe to this course, and automatically receive new lectures as they become available. Released with a Creative Commons BY-NC-ND license.

BWToolkit is an Interface Builder plugin that contains commonly used UI elements and other objects designed to simplify Mac development.

If you’re developing with Rails you’ve probably encountered rake once or twice. This blog post aims to walk you through where rake came from and an introduction on how to use it effectively in your Rails apps.

A Little Bit of History
Rake is the project of Jim Weirich. It’s a build tool. For a good laugh and an even more in depth history check out the "rational.rdoc" from the Rake documentation. Essentially, rake started as an idea for using Ruby inside of a Makefile. Though Jim doesn’t sound convinced from the tone in that document, it is a good idea.

OnMyCommand is a UNIX shell script and AppleScript executor. You can build your own Contextual Menu Item or GUI application.
For more information on building command descriptions see Command Description Manual.
Sources are included with Contextual Menu Workshop. Newest sources are available on request.

Apple’s Cocoa text system is a complicated beast, but also extremely flexible, and with a bit of work, it can be molded to match many working styles. This how-to covers the 2 major ways of customizing the text input system: Default key bindings, and for still more control, input managers.

I’m writing this guide because nothing like it currently exists. There is incredible room for flexibility in customizing the Cocoa text environment, but most users—even power-users—have no idea of the available options. This is mostly because Apple’s documentation is 1) aimed at developers, and 2) often incomplete or ambiguous. Most users have no idea that they can look at a file which describes all of the shortcuts on the system, and that they can easily add their own shortcuts, or replace existing ones with differing functionality.

For instance, one of the most common complaints from new Windows and Linux/Unix switchers is that many of the shortcuts they are used to, such as using the Home and End keys to move to the beginning, respectively end, of a line or document, don’t work as they expect in OS X.

For new users, almost every text box you use is a Cocoa text box (or close enough to act the same as far as we’re concerned) — Safari web form boxes, the text field in iChat for sending new messages, the documents in Pages or TextEdit, the email composer in Mail, etc. Note: Some text boxes are not Cocoa however, so the tricks in this article still aren’t completely universal. Notably, Microsoft Word, Adobe applications, AppleWorks, and the text fields in Camino and Firefox won’t work with this hint.

I expect that all users of OS X can get something out of this guide. I’m starting with the basics, so that new users, unfamiliar with the terminal and the intricacies of OS X can be brought up to speed. But even the most experienced users should hopefully learn something from this article; I know I learned several new nifty things while writing it.

Disclaimer: it is possible, when mucking around with the text system, to send applications messages they aren’t expecting. This can cause them to crash. As long as you stick to standard text selectors, you should be fine, but I’m not responsible if your program crashes because of a binding you add.

This is the Git reference site. This is meant to be a quick reference for learning and remembering the most important and commonly used Git commands. The commands are organized into sections of the type of operation you may be trying to do, and will preset the common options and commands needed to accomplish these common tasks.

Each section will link to the next section, so it can be used as a tutorial. Every page will also link to more in-depth Git documentation such as the offical manual pages and relevant sections in the Pro Git book, so you can learn more about any of the commands. First, we'll start with thinking about source code management like Git does.

GNU cflow analyzes a collection of C source files and prints a graph, charting control flow within the program.

GNU cflow is able to produce both direct and inverted flowgraphs for C sources. Optionally a cross-reference listing can be generated. Two output formats are implemented: POSIX and GNU (extended).

Input files can optionally be preprocessed before analyzing.

The package also provides Emacs major mode for examining the produced flowcharts in Emacs.

A sample of a direct flowchart is available online.

Tool to check your PHP files from parse errors before commit.

This is post #2 of my programmer productivity series.

Before I embark on trying out various productivity strategies, I need to establish a set of metrics that will help me understand what works, and what doesn't.

For now I decided to keep track of two things:

1. My time, using a daily journal where I enter every task I am working on, and the time spent on it.
2. My commits, as well as the lines of code I add / delete throughout my day

If you want to follow along, I am using a simple notebook for my time tracking. I write one task per row, using the following format:

* 09:23 - 09:26 Coffee & Planning today's tasks (3m)
* 09:26 - 10:30 Work on setting up new server (1h 3m)

By writing out the time I start and end my tasks, it's pretty hard to miss an item.