6 comments

[ 3.4 ms ] story [ 24.1 ms ] thread
> I understand Pages has nothing to do with source control

Slightly disagree. What I always loved about pages is every commit is on record and auditable by the public. This makes coders accountable for their actions if they introduce malicious code to their users. Take for example:

`something.js` being served from RawGit (https://rawgit.com/). In all likelihood the asset can be trusted because we can inspect the repo where the asset resides and audit it.

The same cannot be said for private GH accounts, because it's impossible to view the source. People actually pay Github money to conceal their source code. Gasp

Wait, do people typically use slugs with uppercase letters in "the real world?"

In the example given, using an uppercase P doesn't even make sense from an aesthetic standpoint.

Yes.

One of my projects on GitHub is "UIImageColors", so if I were to create a gh-pages for it, the link would be jathu.me/UIImageColors.

I can understand your use case, but the need for case insensitive slugs is one I've never had (or wanted). Then again, I tend to use simple lowercase slugs, preferably single word, and hyphenated for multiword. For that project I might use /image-colors.
Well the main reason is not so much for me (I prefer all lowercase too), but rather other people linking the sites. A 404 resulting from something as simple as the wrong case is costly. Users don't try to fix the URL, they just leave!

Also, regarding the UIImageColors, if I'm making a library for a language that follows CamelCase, then it's only appropriate I follow that standard.

I agree with using the language convention within the language but not onto the web.

Ex. The GitHub repo for a (multiword) Python package foo_bar is generally foo-bar. Maybe this is just a convention we follow.

A list of top Python packages for example:

https://github.com/search?utf8=%E2%9C%93&q=language%3Apython...

Edit: It would be interesting to compare data for how repo and slug naming convention varies by language.