WebRTC is still in its infancy, but developers are already building cool apps around WebRTC's real-time video chat. Codassium is one such app that combines WebRTC video chat with a code editor for better way to conduct remote interviews, review code or do some remote pair programming.

It’s still going to be some time before WebRTC technology starts to deliver cool apps, but even today developers are quickly moving from the realm of cool WebRTC experiments, like the Mozilla/Google phone call demo, to useful apps like Codassium.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many native apps with web-based alternatives that work on any device.

Codassium uses WebRTC to bring together WebRTC-based video chat and Mozilla’s Ace code editor. The result is what Wreally Studios, creators of Codassium, call “a better way to conduct remote interviews.” Of course Codassium could be used for more than just interviews — think code reviews, remote pair programming or even just discussing code with remote employees.

To use Codassium you’ll need to be using a web browser that supports WebRTC — recent versions of Firefox and Chrome will both work. Head on over to Codassium, click the Start button and allow the site to access your camera and microphone. Once the video chat and Ace editor load, just click the Invite button and send the resulting link to the person you’d like to work with.

Social coding website GitHub is personalizing its "Gists" feature -- little snippets of reusable code you'd like to share with others -- changing the URL to include your GitHub username, rather than just a random, anonymous number.

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..

Open source is about building on the work of others and not having to reinvent the wheel. But if you can’t find the code you need then you’re stuck reinventing the wheel. Again.

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.

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.

]]>http://www.webmonkey.com/2012/12/github-update-makes-gists-more-powerful/feed/5Video: Parsing Horrible Things with Pythonhttp://www.webmonkey.com/2012/11/video-parsing-horrible-things-with-python/
http://www.webmonkey.com/2012/11/video-parsing-horrible-things-with-python/#commentsThu, 08 Nov 2012 21:26:15 +0000Scott Gilbertsonhttp://www.webmonkey.com/?p=59883The “horrible thing” in developer Erik Rose’s talk from this year’s PyCon is the Mediawiki syntax, but that’s just a jumping off point for one of the best overviews of data parsing that I’ve run across. If you’ve got a project that involves parsing, or are, like me, considering one, this talk is a must-watch. […]

The “horrible thing” in developer Erik Rose’s talk from this year’s PyCon is the Mediawiki syntax, but that’s just a jumping off point for one of the best overviews of data parsing that I’ve run across. If you’ve got a project that involves parsing, or are, like me, considering one, this talk is a must-watch.

This is PyCon, so much of the talk focuses on parsing in Python, but there’s plenty of broader, dare I say, “parsing philosophy” that make it well worth a watch even if you don’t end up using the specific Python parsing libraries Rose mentions.

No programmer wants to turn simple code into a Dickens novel of comments, but all to often we end up producing code which, years later, reads like the Voynich Manuscript. The best commented code seeks the middle ground.

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.

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.

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.

If you’ve ever worked on a large programming project you know all about the joy of trying to read other people’s code. And of course that’s how everyone else feels about reading your code. That’s why formal programming style guides exist — to help bridge the gap between individual styles.

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.

Five years ago the hotness in web development was showing what you could create without resorting to Flash. Now it seems the same is true of JavaScript. While we’ve nothing against JavaScript, the increasingly powerful tools in CSS 3 mean that JavaScript is no longer a necessity for building cool stuff on the web.

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.

Catch a sneak peek of Mozilla Thimble, an easy-to-use online code editor. Just type some HTML in the left panel and you'll instantly see the results in the right panel. Thimble also has plenty of hints, tips and suggestions for those just getting started with the web's lingua franca.

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.