StyleDocco generates documentation and style guide documents from your stylesheets.

Stylesheet comments will be parsed through Markdown and displayed in a generated HTML document. You can write code examples inside GitHub Markdown code fences (```) or prefixed with 4 spaces in your comments, and StyleDocco both renders the HTML and shows the code example.

The document is automatically split into new sections when it encounters a level 1 or 2 heading. Read more about the heading syntax in the Markdown guide. Only comments at the beginning of new lines are included, so to exclude something from the style guide, put some whitespace before the comment.

If your project includes a README file, it will be used as the base for an index.html. StyleDocco will also add some default styles to your documentation, but they are easy to modify to make it fit with your project.

StyleDocco will automatically compile any SASS, SCSS, Less or Stylus code before it is applied to the page.

1. Getting started
1.1. Description
1.2. Following along
1.3. Getting the data
1.4. Fixing the files with sed
1.5. Piping
1.6. Output redirection
1.7. Putting it together
2. Examining the data
2.1. Cutting up the data with csvcut
2.2. Statistics on demand with csvstat
2.3. Searching for rows with csvgrep
2.4. Flipping column order with csvcut
2.5. Sorting with csvsort
2.6. Using line numbers as proxy for rank
2.7. Reading through data with csvlook and less
2.8. Saving your work
2.9. Onward to merging
3. Adding another year of data

OAuth is an open protocol that aims to standardize the way desktop and web applications access a user's private data. OAuth provides a mechanism for users to grant access to private data without sharing their private credentials (username/password). Many sites have started enabling APIs to use OAuth because of its security and standard set of libraries.
This tutorial will walk you through the necessary steps for creating a Google Chrome Extension that uses OAuth to access an API. It leverages a library that you can reuse in your extensions.
This tutorial uses the Google Documents List Data API as an example OAuth-enabled API endpoint.

http://jashkenas.github.com/coffee-script/
defunkt 7 days ago

http://gembundler.com/
defunkt 7 days ago

http://www.postgresql.org/docs/9.0/interactive/index.html
defunkt 7 days ago

http://devcenter.heroku.com/
defunkt 7 days ago star locks

http://www.freebsd.org/doc/handbook/
defunkt 7 days ago star mrtazz

any others?
defunkt 7 days ago

http://vowsjs.org/
pvande 7 days ago

Maybe it's just because I'm new to it but I'm still a fan of http://developer.apple.com/library/mac/navigation/#section=Resource Types&topic=Reference
zackola 7 days ago

it's a freaking huge api but they do a good job organizing it.
zackola 7 days ago

@zackola I really still have difficulties finding my way through that.
pvande 7 days ago

I also find http://railsapi.com/ indspendible, but you kind of have to know what you are looking for.
zackola 7 days ago

http://documentcloud.github.com/backbone/
zackola 7 days ago

I've always like Prototype's API docs.
pvande 7 days ago

http://mwbrooks.github.com/dominator.js/
pengwynn 7 days ago

http://flask.pocoo.org
number5 7 days ago star kennethreitz, passy

http://api.jquery.com/
number5 7 days ago

@number5: Do you actually like api.jquery?
kneath 7 days ago

That site fills me with so much rage. I would probably end up in the hospital of http://jqapi.com didn't exist
kneath 7 days ago star myfreeweb

Flask is hands down the best documentation I've ever seen.
kennethreitz 7 days ago

http://flask.pocoo.org/docs/
kennethreitz 7 days ago

@kneath I use jqapi for local browsing though :)
number5 7 days ago

i hadn't looked at flask before, but I love the Forward. Thats the kind of thing so many projects need.
steveivy 6 days ago star kennethreitz

http://readthedocs.org/ -- solid documentation host
justinlilly 5 days ago star kennethreitz, xoebus

This is coming along nicely: http://relishapp.com/rspec
jamesmartin 4 days ago

This repo contains all my notes about git. I started writing them for my own understanding, almost like cheat sheets, but they may be useful for others also.

Git is a Distributed Version Control System. Most VCSs you know (like CVS, Subversion, Clearcase, Perforce, and VSS) are centralised. A Distributed VCS allows you to make frequent, local, commits to checkpoint your work while you're still perfecting the code -- you cannot do this with a centralised VCS.

Basics

If you...

have no idea what git is and wonder what the fuss is all about, and why it's become so popular, see this article, which I wrote for LFY (July 2008 issue)

want a basic intro to the most important concepts behind git, see this presentation

know something about version control, and are trying to understand why git is so powerful, spend some time on this presentation.

need a quick refresh of the terminology once in a while, read this.

if you're itching to get started, but have become overwhelmed by having to understand git itself and how it fits with ssh or http etc., read this -- I've been told it is quite helpful :)


Note that the presentations are meant to be interactive, with someone talking through the slides, but have enough detail that you can read them yourself if you like.

Beyond the basics

If you know a little about git and/or have attended one of my talks, you can follow the links below.

(c) Copyright Sitaram Chamarty, sitaramc@gmail.com, licensed under the Creative Commons Attribution Sharealike license.

subdirectories:
0-installing
1-basic-usage
2-command-line-usage
concepts
other-stuff
the-list-and-irc
tips

This document is a guide to the AppleScript language—its lexical conventions, syntax, keywords, and other elements. It is intended primarily for use with AppleScript 2.0 or later and Mac OS X version 10.5 or later.

AppleScript 2.0 can use scripts developed for any version of AppleScript from 1.1 through 1.10.7, any scripting addition created for AppleScript 1.5 or later for Mac OS X, and any scriptable application for Mac OS v7.1 or later. A script created with AppleScript 2.0 can be used by any version of AppleScript back to version 1.1, provided it does not use features of AppleScript, scripting additions, or scriptable applications that are unavailable in that version.

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.

The Text_Wiki package allows you to transform text structured using Wiki rules into any defined target output format, such as XHTML, RTF, LaTeX, and so on.> Note: The current release only supports XHTML and plain-text output. RTF, LaTeX, DocBook, and so on will be added as the codebase stabilizes and matures.Text_Wiki achieves this level of flexibility by using one class for each part of the transformation process:

*
one class for parsing each markup rule (e.g., bold, code, wikilink, etc)
*
one class for rendering each general format (e.g., XHTML, DocBook, RTC, etc)
*
one class for rendering each rule in each formatText_Wiki comes with its own set of markup rules (see the ]]), but you can write any rules you like to match whatever style you're used to. Text_Wiki draws its default rules from a number of codebases, most notably WikkiTikkiTavi and coWiki; while no code has been directly copied from those codebases, they were indispensible in learning how to process Wiki text.

Here is a collection of mailing list postings made by various people describing how they use git in their workflow.

*

maintain-git by Junio C Hamano <gitster@pobox.com>

Imagine that git development is racing along as usual, when our friendly neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you "how to" do it.

*

rebase-from-internal-branch by Junio C Hamano <gitster@pobox.com>

In this article, JC talks about how he rebases the public "pu" branch using the core GIT tools when he updates the "master" branch, and how "rebase" works. Also discussed is how this applies to individual developers who sends patches upstream.

*

rebuild-from-update-hook by Junio C Hamano <gitster@pobox.com>

In this how-to article, JC talks about how he uses the post-update hook to automate git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/.

*

recover-corrupted-blob-object by Linus Torvalds <torvalds@linux-foundation.org>

Some tricks to reconstruct blob objects in order to fix a corrupted repository.

*

revert-a-faulty-merge by Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com>

Sometimes a branch that was already merged to the mainline is later found to be faulty. Linus and Junio give guidance on recovering from such a premature merge and continuing development after the offending branch is fixed.

*

revert-branch-rebase by Junio C Hamano <gitster@pobox.com>

In this article, JC gives a small real-life example of using git revert command, and using a temporary branch and tag for safety and easier sanity checking.

*

separating-topic-branches by Junio C Hamano <gitster@pobox.com>

In this article, JC describes how to separate topic branches.

*

setup-git-server-over-http by Rutger Nijlunsing <rutger@nospam.com>
*

update-hook-example by Junio C Hamano <gitster@pobox.com> and Carl Baldwin <cnb@fc.hp.com>

An example hooks/update script is presented to implement repository maintenance policies, such as who can push into which branch and who can make a tag.

*

use-git-daemon
*

using-merge-subtree by Sean <seanlkml@sympatico.ca>

In this article, Sean demonstrates how one can use the subtree merge strategy.

Actions Run During a Typical Request

These actions are run when a logged-in user opens the home page in Version 2.9.

1. muplugins_loaded
2. load_textdomain
3. update_option
4. plugins_loaded
5. load_textdomain
6. sanitize_comment_cookies
7. setup_theme
8. load_textdomain
9. auth_cookie_malformed
10. set_current_user
11. init
12. widgets_init
13. load_textdomain
14. parse_request
15. send_headers
16. pre_get_posts
17. posts_selection
18. wp
19. template_redirect
20. get_header [first printed output to the browser]
21. wp_head
22. wp_enqueue_scripts
23. wp_print_styles
24. wp_print_scripts
25. loop_start
26. the_post
27. loop_end
28. get_footer
29. wp_footer
30. wp_print_footer_scripts

A regular expression is a domain specific language for matching text. Naively we could write a small program to match text, but this is error-prone, tedious and not very portable or flexible.

Instead we use regular expressions which describe the match as a string which (in a simple case) consists of the character types to match and quantifiers for how many times we want to have the character type matched.

For example normal letters and digits match literally. Something like \w will match word characters, where \s will match whitespace characters (space, tab, newline, etc.). The period (.) will match any character (except newline).

The basic quantifiers are the asterisk (*) to specify that the match should happen zero or more times, plus (+) for one or more times, or a range can be given as {min,max}.

This alone gives us capabilities like finding words (\w+) or finding an image tag with an alt argument (<img.*alt=".*">).

Matching longer text sequences is one thing, but often we are interested in the subset of the match. For example, in the above example we may want to replace the alt argument text. If we enclose part of the regular expression with parentheses, we capture that part in a variable that can be used in the replacement string. The format of the replacement string is described at the end of this section, but to refer to the first capture, we use $1, $2 for the second etc.

So to change the alt argument text we could search for (<img.*alt=").*(">) and replace that with $1Text Intentionally Removed$2.

20 Regular Expressions
20.1 Introduction
20.1.1 External Resources
20.2 Regular Expressions in TextMate
20.3 Syntax (Oniguruma)
20.4 Replacement String Syntax (Format Strings)
20.4.1 Captures
20.4.2 Case Foldings
20.4.3 Conditional Insertions
20.4.4 Escape Codes

A snippet is a piece of text that you would like to insert in your document. It can include code to run at insertion time, variables (like selected text), tab stops/placeholders for missing information (which you can tab through after insertion) and perform transformations on the data which you enter in the placeholders.

7 Snippets
7.1 Plain Text
7.2 Variables
7.3 Interpolated Shell Code
7.4 Tab Stops
7.5 Placeholders
7.6 Mirrors
7.7 Transformations

Writing your own Wordpress plugin is not that difficult if you are a web developer with basic PHP skills. The only thing you will need, coupled with your PHP skills, is some direction, some resources, a little information on how WordPress expects your plugin to behave and, most importantly, a great idea.
If you are a newbie, don’t be put off or daunted by all the code, ultimately a plugin is only program, a set of functions, that adds a specific set of features and services that can be executed in different sections of your WordPress site.
This article covers Wordpress Plugin Development, from tutorials, useful resources, how-tos, guides and some cheat sheets.

Style guides are a great way to ensure user experience consistency when developing an application and a way to communicate user experience standards across an organization. They can be application specific, platform specific, and may encompass enterprise-wide standards. A style guide can help make the development of user interfaces more efficient and help ensure good user interface design practices.

See the related blog post: Under jQuery's Bonnet

I was sick and tired of having to scroll through a raw copy of jQuery everytime I wanted to view a method's implementation... so I decided to have a go at creating a faster, more usable interface which would allow me to quickly traverse each method's source. It's dead simple. Type in a jQuery method name (then wait a bit) and the corresponding source will show up.

It even works on internally defined functions (and anything really), so try typing 'buildFragment' or 'rscript'...

I think the most important thing we can do in the open source world (far more important than releasing new cool software) is to improve the quality of the documentation of existing software. Software without documentation is pretty much useless. Software with bad documentation is slightly better than useless, but still nearing uselessness. Software with some good documentation but which has incomplete documentation is better than useless, but only for some period of time: you can't keep telling yourself "I'll do it later" or outsource the job of documentation to some mythical "community": it's a chicken and egg scenario. Writing documentation is part of your job description as a programmer.

The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and is not a tutorial on how to manage a Unix filesystem or directory hierarchy.

FHS Development

The mailing list is available to discuss interpretations of the FHS document and of possible future changes and additions. All proposals should be submitted as bugs on bugs.freestandards.org using the "FHS" component). To be regarded seriously, proposals should include a unified patch to the sgml source (create the attachment after you've opened the bug, please do not cut-and-paste patches into comments).