Move down 10 or 15 on iphone and shift point side of arrow over 1 or 2 px. See iphone for visual.

So, I had a folder named /icons that was being ignored because of this:

Icon?

Related:

• Remove weird OS X specific .gitignore rule which behaves very unexpectedly
• Git Tip: Ignoring Icon\r in .gitignore

I guess the solution is to do this instead:

Icon^M^M

GitHub recently pointed all gh-pages demo pages to a new TLD of .io.

Example:

http://registerguard.github.io/grunt-boiler/demo/

Update the demo links to use the new TLD.

http://bower.io/

Jean-Luc Picard was born to Maurice and Yvette Picard in La Barre, France, on July 13, 2305, and dreamed of joining Starfleet.

A dash is added at end.

Fix:

 [↥](#table-of-contents)

Just replace space for  .

Related: #44

Just to show how one might go about including a demo in their repository.

Also, make sure your app has a MANIFEST for setup.py to be able to
install non-python files (e.g.: your templates) when you install it
without the -e option. Look at the distutils docs for more details

Discussion here.

Also noticed that the + in this file was not liked by pip install.

Might be good to include a few examples of GitHub's <hr> styles.

5 dashes:

4 dashes:

3 dashes:

2 dashes:

1 dash:

5 equal signs:

4 equal signs:

3 equal signs:

2 equal signs:

1 equal signs:

5 asterisk:

4 asterisk:

3 asterisk:

2 asterisk:

**

1 asterisk:

5 underscore:

4 underscore:

3 underscore:

2 underscore:

__

1 underscore:

_

Other?

Some good cheats here:

https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

Something a little more robust, like:

Copyright © [FIRST LAST or BUSINESS] [FIRST YEAR]-[CURRENT YEAR]. All rights reserved.

Unauthorized use and/or duplication of this material, without express and written permission from the owner, is strictly prohibited.

This is pretty dope right here:

https://github.com/darcyclarke/Front-end-Developer-Interview-Questions

## <a name='toc'>Table of Contents</a>

  1. [Original Contributors](#contributors)

####[[⬆]](#toc) <a name='contributors'>Original Contributors:</a>

Table of Contents

1. Original Contributors

[⬆] Original Contributors:

https://github.com/gulpjs/gulp

Their read me has centered image:

<p align="center">
  <a href="http://gulpjs.com">
    <img width="98" height="194" src="https://raw.github.com/gulpjs/artwork/master/gulp.png"/>
  </a>
</p>

I think I now prefer having a changelog in the README.md.

This is the format I think I prefer:

https://github.com/mhulse/bueller

Another example would be Grunt plugin style:

https://github.com/gruntjs/grunt-contrib-clean

Succinct:

Contributing

In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using grunt.

Also succinct, and a nice alternative to having (or on top of) a README.md:

Release History

• 0.4.0 Removed automatic parse, added ability to add ini or json style src files
• 0.3.0 Automatically parses .env files now
• 0.2.1 fixed npm install
• 0.2.0 grunt 0.4.0 support, simplified
• 0.1.0 Initial release

Found here.

Link to "closed" milestones.

https://github.com/FortAwesome/Font-Awesome#changelog

Related: #36

For example:

DEVELOPMENT	PRODUCTION

... of course, change the endpoints to something in the gh-boiler repo.

Note: When there's three or more QR codes, the size needs to be tweaked. 200x200 works better when 3 in a row. Wondering if 200x200 should be the default size?

Generic:

sitemap.xml
sitemap.xml.gz*~
.svn
.cvs
*.bak
*.swp

Wordpress:

# http://www.stumiller.me/what-should-be-excluded-in-a-wordpress-gitignore-file/
# Migrate to this type of setup: https://github.com/markjaquith/WordPress-Skeleton

wp-config.php
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
wp-content/backup-db/
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
wp-content/cache/*
wp-content/cache/supercache/*
wp-content/cache/
wp-content/backups/

Maybe I should just focus on non-project-specific ignores?

… in the copyright section of the README. UTF8 is good.

Add YML to space list. Basing this issue one Jekyll page:

http://jekyllrb.com/docs/configuration/

Do not use tabs in configuration files

This will either lead to parsing errors, or Jekyll will revert to the default settings. Use spaces instead.

... and not just the repo.

This change makes more sense when there's multiple demo pages to link to (it's odd to duplicate the QR code 3 times, for example, and have it point to one endpoint).

I like this: https://github.com/FortAwesome/Font-Awesome#versioning

Check out the template here:

https://help.github.com/articles/dealing-with-line-endings

Example:

<img align="right" height="260" src="http://gruntjs.com/img/grunt-logo-no-wordmark.svg">

Live example: https://github.com/gruntjs/grunt/blob/master/README.md

For quick copy/paste for small projects.

Whoa, this is cool:

https://github.com/blog/1184-contributing-guidelines

Awesome example:

https://github.com/sapegin/jquery.mosaicflow/blob/master/Contributing.md

Copy/paste here for future quick reference:

How to contribute

I love pull requests. And following this simple guidelines will make your pull request easier to merge.

Submitting pull requests

1. Create a new branch, please don’t work in master directly.
2. Add failing tests (if there’re any tests in project) for the change you want to make. Run tests (usually grunt or npm test) to see the tests fail.
3. Hack on.
4. Run tests to see if the tests pass. Repeat steps 2–4 until done.
5. Update the documentation to reflect any changes.
6. Push to your fork and submit a pull request.

JavaScript code style

• Tab indentation.
• Single-quotes.
• Semicolon.
• Strict mode.
• No trailing whitespace.
• Variables where needed.
• Multiple variable statements.
• Space after keywords and between arguments and operators.
• Use === and !== over == and !=.
• Return early.
• Limit line lengths to 120 chars.
• Prefer readability over religion.

Example:

'use strict';

function foo(bar, fum) {
    if (!bar) return;

    var hello = 'Hello';
    var ret = 0;
    for (var barIdx = 0; barIdx < bar.length; barIdx++) {
        if (bar[barIdx] === hello) {
            ret += fum(bar[barIdx]);
        }
    }

    return ret;
}

Other notes

• If you have commit access to repo and want to make big change or not sure about something, make a new branch and open pull request.
• Don’t commit generated files: compiled from Stylus CSS, minified JavaScript, etc.
• Install EditorConfig plugin for your code editor.
• If code you change uses different style (probably it’s an old code) use file’s style instead of style described on this page.
• Feel free to ask me anything you need.

Awesomeness.

gh-boiler

Add:

[CNAME]
insert_final_newline = false

As the CNAME file won't work if newline.

Found this link today:

https://github.com/serbanghita/Mobile-Detect/issues/new?body=Please%20specify%20the%20User-Agent.%20Go%20to%20http://is.gd/mobiletest%20and%20copy-paste%20it%20here.

... and this one too:

https://github.com/serbanghita/Mobile-Detect/issues/new?title=New%203rd%20party%20module&body=Name,%20Link%20and%20Description%20of%20the%20module.

Looks like:

Pretty cool!

Add a "submiting an issue" link in the README with the above linkage (to this repo's issue tracker of course).

Like:

Browser tests:

• MAC Snow Leopard:
  • Firefox 16.0.1, Safari 6.0.1 (8536.26.14), Opera 12.02 (1578), Chrome 22.0.1229.94
• PC Vista:
  • Firefox 16.0.1, Chrome 22.0.1229.94 m, Safari 5.1.7 (7534.57.2), Opera 12.02 (1578)
  • IE 9.0.8112.16421, IE 8.0.6001.18702, IE 7.0.6002.18005
• PC XP:
  • IE 6.0.2900.5512.xpsp_sp3_gdr.120504-1619
• iPhone (Retina 4-inch):
  • Safari (simulated)
• iPhone (Retina 3.5-inch), iOS 6.0:
  • Safari (simulated), Safari, Chrome 21.0.1180.82, Opera Mini 7.0.5.45389
• iPhone, iOS 6.0:
  • Safari (simulated)
• iPad (Retina), iOS 6.0:
  • Safari
• iPad, iOS 6.0:
  • Safari (simulated)
• iPad, iOS 5.1.1:
  • Safari

While I like what I've done in the latest version of the .gitattributes file, I'm thinking it might be best to go back to just using:

# https://help.github.com/articles/dealing-with-line-endings
# http://davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/
# https://github.com/Danimoth/gitattributes

* text=auto

... as that's pretty much all that's needed when starting a new project. Everything else is icing on the cake.

Maybe I should ask the folks over here:

https://github.com/Danimoth/gitattributes

... about adding a "catch all" .gitattributes like:

https://github.com/mhulse/gh-boiler/blob/911c38eff61617e2545eb5493de11d04d1656749/.gitattributes

My question: If I have * text=auto, do I need to specify that for all the other * text=auto entries? Considering that the latter is what happens if things are not defined, it seems like specifically defining * text=auto is overkill. That's why I removed those lines from this commit:

https://github.com/mhulse/gh-boiler/blob/201a28d69914123d9737e13f380cb9aa82441774/.gitattributes

For a django app.

Example:

Install using pip:

$ sudo pip install -e git+https://github.com/registerguard/django-dox.git#egg=django-dox

Add 'dox', to your installed_apps setting.

Put this in your URLs:

(r'^pages/', include('dox.urls')),

Run:

$ sudo service apache2 restart

... or:

$ touch apache/django.wsgi

... or whatever you need to do to reload things.

Lastly:

$ python manage.py syncdb

... and you're ready to go!

Enjoy your Django Dox today!

It caused me some headaches when working with Jekyll. I see no reason why the non-gzipped version of a sitemap.xml should be ignored (unless it's going to be auto-generated???).

Removing it.

Check out:

http://choosealicense.com

... don't miss:

http://choosealicense.com/no-license/

And this:

https://github.com/blog/1530-choosing-an-open-source-license

I want to add more options to this repo for the above type of stuff.

https://github.com/registerguard/gh-boiler/blob/master/.gitignore#L44-L46

Add to readme.

Love this:

https://github.com/jchristopher/attachments/blob/master/README.md

Great way to keep a README organized (depending on project).

Like:

https://github.com/gruntjs/grunt/wiki/Contributing

Submitting pull requests

1. Create a new branch, please don't work in master directly.
2. Add failing tests for the change you want to make. Run grunt to see the tests fail.
3. Fix stuff.
4. Run grunt to see if the tests pass. Repeat steps 2-4 until done.
5. Update the documentation to reflect any changes.
6. Push to your fork and submit a pull request.

https://help.github.com/articles/dealing-with-line-endings#platform-mac

Like here: https://github.com/FortAwesome/Font-Awesome

Good idea to link changelog to milestone for that version/release.

I kinda like that file name better than CHANGELOG.md. Having both in this repo would work for me.

Example:

https://github.com/yui/pure/blob/master/HISTORY.md

Need to add WIKI entry, or something, on my preferred style.

Make it generic, like the CONTRIBUTORS.md file.

This:

## vX.X.X
#### Mmmmm [D]D, YYYY

Shoulde be this:

## vX.X.X

#### Mmmmm [D]D, YYYY

It's a small change, but makes sense if I have multiple dates under a version heading. Also, the styles push it down anyway, so there's no reason to have the two so close together.

Syntax section should be a part of the contributing header.

So I can easily package apps.