This is not an Octocat. Image: GitHub.

The change means that you can easily get to a list of all your Gists by heading to https://gist.github.com/<username>/.

Gists, which started off as a simple way to dump and share snippets and short pieces of reusable code (something akin to the older Pastebin), were recently upgraded to be full-fledged Git repos behind the scenes. That means Gists are automatically versioned, forkable and usable as Git repos, complete with diffs.

Now that Gists are considerably more than just Pastebin-style code snippets, it makes sense to offer users a quick and easy way to get to their Gists from anywhere thanks to a memorable URL.

The newly personalized Gists come with an automatic URL redirect. So if your Gist used to live at https://gist.github.com/4731290 it will now be redirected to https://gist.github.com/luxagraf/4731290. As some GitHub users point out on Hacker News, there’s a flaw in GitHub’s system that means anyone can register a numeric username and cause a Gist to redirect to the wrong page. Hopefully GitHub will fix that in the near future..

GitHub’s Octobi Wan Catnobi. Image: GitHub

To help you find exactly the wheels your project needs, code hosting giant GitHub has announced a new, much more powerful search tool that peers inside GitHub repositories and offers dozens of filters to help you discover the code you need.

The new search further cements GitHub’s place as the go-to source not just for publishing, but also discovering, code on the web.

While GitHub’s new search lacks the web-wide reach of more general code search engines like Google’s once-mighty Code Search (now a hollow shell of its former self), it’s likely to return more useful results thanks to some nice extras like the ability to see recent activity and narrow results by the number of users, stars and forks.

GitHub’s advanced search page now supports operators like @username to limit results to just your repositories (or another user’s repos), code from only one repository (repo:name) or even code from a particular path within a repo. You can also limit by file extension, repo size, number of forks, number of stars, number of followers, number of repos and user location.

While the advanced operators make a quick way to search, there’s no need to memorize them all. The new advanced search form allows you to craft your query using multiple fields, while it displays the shorthand version at the top the page so you learn as you go.

Under the hood GitHub’s new search is powered by an ElasticSearch cluster which live-indexes your code as you push it to GitHub. The results you see will include any public repositories, as well as any private repositories that you have access to.

The GitHub blog also notes that, “to ensure better relevancy, we’re being conservative in what we add to the search index.” That means, for example, that forks will not be in search results (unless the fork has more stars than the parent repository). While that may mean you occasionally miss a bit of code, it goes a long way toward reducing a problem that plagues many other code search engines — the overwhelming amount of duplicate results.

GitHub’s more powerful search has turned up one unintended consequence — exposed data. It’s much easier to search for anything on the site, including, say, usernames and passwords. As it turns out many people seem to have everything from SSH keys to Gmail passwords stored in public GitHub repos. There’s a discussion about the issue over on Hacker News. The ability to find things like exposed passwords isn’t new, but the new search tool does make it easier than ever. Let this be a reminder of something that’s hopefully obvious to Webmonkey readers — never store passwords or private keys on a public site. And if you find someone doing that, do the right thing and let them know.

For more details on everything that’s new in GitHub’s search page, head on over to the GitHub blog.

Image: GitHub.

Social coding giant GitHub continues to crank out the hits. The company recently made it easy to create new files through its web interface and now GitHub has launched a completely rewritten version of GitHub Gist.

Gists are a way to dump and share snippets and short pieces of reusable code — too short to bother creating a full-fledged Git repository, but something you’d like to save and share nonetheless — covering roughly the same use case as something like the much older Pastebin. Or at least that used to be the case.

The new gists are considerably more powerful. The rewrite actually turns gists into full Git repositories, so they are automatically versioned, forkable and usable as Git repos, complete with diffs.

Gists are also now searchable — complete with the ability to filter searches by language — and there’s a new Discover page as well.

Like normal GitHub repos, gists now offer the Ace code editor with its syntax highlighting and automatic indenting. While the Ace editor is nice, my favorite way to create gists is through editor plugins like this one for Vim, this one for Emacs or this one for Sublime Text 2.

The Voynich Manuscript was very poorly commented. Image: Wikimedia

We’ve written before about the value of writing your README before your code, but what about when it comes to the actual code? Terse one-liners? Paragraph-long descriptions? How much is enough and when is it too much?

How to comment code is a perennial subject of debate for programmers, one that developer Zachary Voase recently jumped into, arguing that one of the potential flaws with extensive comments (or any comments really) is that they never seem to get updated when the code changes. “We forget,” writes Voase, “overlooking a comment when changing the fundamental behavior of semantics of the code to which it relates.”

Voase thinks the solution is in our text editors, which typically “gray out” comments, fading then into the background so we can focus on the actual code. We ought to do the opposite, he believes: Make the comments jump out. Looking at the visual examples on Voase’s post makes the argument a bit more compelling. Good text editors have configurable color schemes so it shouldn’t be too hard to give this a try and see if it improves your comments and your code.

Another approach is to treat comments as a narrative. Dave Winer recently mentioned comments in passing, writing about the benefits of using an outliner to handle comments since it makes it easy to show and hide them:

Another thing that works is the idea of code as a weblog. At the top of each part there’s a section where each change is explained. The important thing is that with elision (expand/collapse) comments don’t take up visual space so there’s no penalty for fully explaining the work. Without this ability there’s an impossible trade off between comments and the clarity of comment-free code. No manager wants to penalize developers for commenting their work. With this change, with outlining, that now works.

Winer has an example you can check out if you’d like to see it in practice (and a screenshot of how it looks in the actual editor). Winer is also a proponent of what he calls Narrate Your Work, publishing a running story of his work.

Donald Knuth, author of the seminal book, The Art of Computer Programming, advocated a similar narrative approach with what he called Literate Programming. Literate programming seeks to weave comments and docs out of a “literate” source.

Then there’s the opposite school of thought that says your code should always be so clear and so obvious as to never need comments. See Slashdot for quite a few people advocating this approach, most of whom we suspect have never had to go back and read through their code again years after it was written.

The best way to comment your code is up to you, but whichever path your team decides to follow the best advice is to make sure you take the time to actually have a plan for comments. The most useless comments are haphazardly written, which also makes them unlikely to be updated when the code changes. There are as many approaches as there are programmers; just make sure you actually settle on one and stick with it. Down the road, when it’s time to update that older code you’ll thank yourself.

Image: GitHub.

Code sharing giant GitHub has rolled out some significant changes to the site’s notifications system, making it easier to keep track of interesting projects without being notified of every single change.

GitHub has always made it easy to “watch” a project, which means you’re notified whenever there are any updates. Now the company has added another level of watching, dubbed “stars,” to the mix. As GitHub’s Kyle Neath writes on the company blog, “stars are a new way to keep track of repositories that you find interesting.”

When you star a project you can keep track of it, but you won’t be notified of every change. Think of starring a project on GitHub as a more casual way of watching, the equivalent of bookmarking it for later. To make it easier to do that, every repo now has a star button next to the familiar watch button.

The big difference between watching and starring a project comes down to notifications. If you are watching a repository, you will receive notifications for all discussions — project issues, pull requests, comments on commits and any other comments. If you’re not watching a repo you’ll just receive notification for the discussions you participate in.

The other main thing worth noting is that any repositories you were previously watching can now be found on your stars page. If you want to go back to watching them, you’ll need to change them over yourself. There’s also a new auto-watch feature; when you’re given push access to a repository GitHub automatically adds it to your watch list.

GitHub has a few other changes rolling out along with the new stars feature, including improved notification e-mails. Be sure to check out the GitHub blog for the full details on everything that’s new.

Wooly, the CSS Sheep Image: W3C

There is no right or wrong style of writing code, but there are styles that are easier to read and share with other people. Search the web and you’ll find formal guides to writing readable JavaScript, Python, Ruby and countless other popular languages, but one language that doesn’t get as much attention is CSS.

Developer Nicolas Gallagher wants to change that. To do so Gallagher has put together Idiomatic CSS, a style guide for how to format, organize and craft quality CSS that anyone can work with. Here are the general principles of the project:

“Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.” — Idan Gazit

• All code in any code-base should look like a single person typed it, no matter how many people contributed.
• Strictly enforce the agreed upon style.
• If in doubt use existing, common patterns.

Idiomatic CSS follows in the footsteps of Rick Waldron’s Idiomatic JS, which does the same thing for JavaScript.

If you’ve made the leap to a CSS preprocessor like SASS or LESS, fear not, Idiomatic CSS has you covered as well. Preprocessor syntax varies and Idiomatic CSS offers examples in SCSS, but the more general rule, “your conventions should be extended to accommodate the particularities of any preprocessor in use,” apply to others as well.

Wrangling CSS on large projects can be a pain, but if you take the time to create a set of conventions and ensure that everyone sticks to them it becomes a much more manageable task. If you’ve got experience and insight to share, head on over to the Idiomatic CSS GitHub page and contribute your knowledge.

Stopwatch in CSS 3, no JavaScript necessary. Image: Screenshot/Webmonkey

The latest JavaScript-free demo we’ve run across is this very cool stopwatch demo made using only CSS 3, no images or JavaScript necessary. Now before you dive into the code and get all Karl Van Hœt on us, yes, there is a script used to handle CSS prefixing, but the actual stopwatch doesn’t require it to work.

But what caught our eye even more than the JavaScript-free stopwatch demo is the tutorial that accompanies it. The tutorial — which is one part screencast and one part code dump — is part of Code Player, which helps you learn how to do things by showing you the code as it’s written. It’s an interesting tutorial method, one we haven’t seen before.

Watching code being written isn’t for everyone, especially beginners who might not be able to easily follow what’s happening, but it’s well suited to those that already understand the basics and just want to see how some particular function was written. It also provides an interesting look at how other developers work, which in turn might teach you a new trick or two.

The Code Player offers a variety of playback speeds depending on how fast you want to run through the tutorial, and there’s a timeline scrubber for pausing and rewinding any bits you miss. Our only complaint is that Code Player forces focus in the browser; when you try to click another tab or do something in the background Code Player steals focus back immediately.

If learning something new by watching someone else type sounds intriguing, head on over to the Code Player site. And don’t worry if the stopwatch demo has no appeal for you, there are plenty of other tutorials to choose from.

Editing Webmonkey.com in Thimble. Image: Screenshot/Webmonkey

Mozilla Thimble is a new web-based code editor, part of the company’s recently unveiled “Webmakers” project. Thimble is designed to give novice webmakers an easy-to-use online tool to quickly build and share webpages.

You can check out Thimble over at the new Mozilla Thimble website. Keep in mind that Mozilla hasn’t formally launched Thimble; the company is still testing, fixing bugs and iterating the app.

Thimble is slightly different than other online code editors you may have tried, putting the emphasis on teaching HTML to newcomers rather than catering to advanced users. Thimble offers side-by-side code editor and code output panels which help new users see immediate results. Type an <h1> and you’ll immediately see a headline. The instant feedback is not only helpful for spotting and fixing errors, but encouraging for those just starting out since you can see what you’ve created right away.

Thimble is very purposefully not aimed at veteran HTML junkies, but for those just learning how to write HTML — which is the focus of the Webmakers project — Thimble is one of the friendliest, easiest-to-use code editors we’ve seen.

Thimble can also load pre-made project templates to help users get started with some content that’s ready to build on. Currently the featured projects section of the Thimble homepage is still awaiting content, but among the coming projects is a tutorial on editing and creating your own Tumblr theme, as well as others from Mozilla’s various Webmaker partners.

To help new users get their Thimble-created projects on the web Mozilla has also bundled a publishing function directly into the editor. Once you’ve got your Thimble page looking the way you’d like it, just hit the “Publish” button and Thimble will output and host your page, offering up a URL to share with friends and another to edit your page if there’s something you need to change.

Students: Step into your summer office. Image: Lost In The RP/Flickr

Past participants have helped improve everything from popular web frameworks to browser add-ons and even operating systems. Summer of Code is also not a half bad way to get yourself on Google’s radar — the company looks at the results of the program to help it “identify potential recruits.”

Summer of Code has served as a launchpad for quite a few new open source software projects as well as helping to jumpstart work on existing favorites. This year’s roster includes some 1,208 students who will spend the next 12 weeks writing code for 180 different open source organizations.

With 208 proposed projects, there’s a pretty good chance that some Summer of Code improvements will be rolled into your favorite open source projects later this year. Among the things we’ll be keeping an eye on are Metalink’s various efforts to improve the download capabilities in Firefox and Chrome. Eventually Metalink wants to bring error recovery/repair for large downloads to everything from Chrome to wget.

Other promising projects include several efforts to help improve OpenStreetMap, the so-called “Wikipedia of maps,” as well as Code for America’s various projects, some new features for Git and an ambitious plan to bring Pylint into the modern world of Python 3.

For more info on this year’s Summer of Code, head over to Google’s Summer of Code website, which has details on all the various projects and participants. You can also get updates from the Summer of Code page at Google+.