beliu

In addition to asking them to write some code, we also have each member of the team interview them onsite to get a sense of how they'd interact as a member of the team. The challenge does take a few hours, which is longer than a typical phone screen or single onsite interview, but because it lets us focus on getting to know the person onsite rather than go through a gauntlet of whiteboarding interviews, we think it actually saves time for everyone and is a win-win. Obviously, every candidate is different; we think of this not as a rigid template, but a better default option than whiteboard interviews. Thanks for your thoughts!

We're trying a different approach at Sourcegraph. In addition to looking at a candidate's prior work in open source if available, we ask them to complete tasks that approximate the job as closely as possible (i.e., coding on a computer): https://sourcegraph.com/blog/programming-interview

Would love to hear people's thoughts and feedback!

Check out Sourceboxes. They are automatically linked (with jump-to-def), and you can embed any function/type or file range. (I'm one of the creators of Sourcegraph and would love to get your feedback!)

If you haven't already, check out srclib, an open-source cross-language cross-editor code analysis library designed to support things like editor plugins: https://srclib.org/. I'm one of the creators and would love to hear your thoughts.

Author of the post here. Would love to hear people's thoughts on this approach and your own methods of diving into open-source projects!

Yep, Kythe is the open-source version of grok. It's awesome, and the srclib team is in touch with the Kythe team at Google to build on top of their analysis libs (for C++ and Java).

Long term vision is to get rid of the "my editor X doesn't support language Y" problem as well as build a lot of other multi-language analysis tools on top of it. Shameless plug: if you care about developer productivity, join us!

On the topic of having one IDE that just works for multiple languages/platforms, you should check out srclib (https://srclib.org), an open-source language analysis tool (I'm one of the creators) that abstracts away the language-specific parts of IDE support so that IDEs/editor plugins can hook into one API and automatically get support for a bunch of different languages. This way, you don't have to build MxN plugins (M editors, N languages) to support all combos of editors/languages people might want to use.

The currently supported languages are Go, Java, Python, JavaScript, and Ruby, so this wouldn't work yet for iOS, but Objective-C and Swift are high on our priority list. Editor plugins exist for Emacs, Sublime, and Atom. Would love to hear anyone's feedback from trying it out.

We're shooting for sometime soon; it's high on our priorities list, and we'd love to find partners to help test out the feature. Want to shoot me an email at beyang@sourcegraph.com?

Check out Sourcegraph: https://sourcegraph.com. It semantically analyzes code, makes it searchable, and lets you find usage examples of how others use it. One of the features we're planning to ship soon is commenting on pieces of code.

Because Sourcegraph understands the code at a semantic level, we can tie comments to a specific function/class/module and show the discussion history even as the specific lines of code change over time. Right now, we do comments for code reviews, but want to add this for any existing version of the code. I'm one of the creators of Sourcegraph and would love to hear any feedback/suggestions the HN community has to offer!

We just added godoc integration to Sourcegraph, so you can use that for now! Godoc + tooltips + jump-to-def + usage examples.

See this, for example: https://sourcegraph.com/github.com/gorilla/mux/.godoc

This is a great point. The quality of the tooling around a given language/ecosystem has a huge impact on the productivity of people working in that ecosystem.

See also https://srclib.org/, a library with similar goals to Kythe supporting a different set of initial languages (including JavaScript, Python, Ruby, Java, Haskell, and Go) with editor plugin support for Emacs, Sublime, and Atom. (Disclaimer: I'm one of the authors.) The dynamic languages, and JavaScript in particular, are hard to support well. Libraries like tern.js make it doable, but life would be much easier with stronger static guarantees from the language itself. For now, it's a very hard problem, but there is so much to gain from Intellisense-level tooling around JS.

It's hard for me to say without more details about your specific problem. srclib does provide a Data field where information like method signatures is typically emitted, so you can compare the signature for the C# method with that of the Java one, but I'm not sure if that includes the other attributes you need to know for your problem.

If there's a lot of custom logic, then it might be better to write an ad hoc tool that checks the AST of the Java against the AST of the C#. srclib and I think also Kythe are designed for building tools that want to be language-agnostic, rather than digging into specific language behavior.

Kythe seems like an awesome project, and kudos to Google for releasing this in the open.

For those interested in code analysis and dev tools, another library you might want to check out is srclib (I'm one of the authors). srclib is an open-source polyglot code analysis library designed for editors and code explorers. Its mission, supporting a common language-independent schema to support building better language-aware tools, is closely aligned with Kythe's. There's documentation and a succinct description of the problem we're trying to solve at https://srclib.org.

srclib currently supports Go, Java, Python, JavaScript, Ruby, Haskell, and soon PHP. There's a simple command line API that editor plugins can call, and currently there are srclib plugins for Emacs, Sublime, and Atom. srclib also powers https://sourcegraph.com.

I'm looking forward to seeing where Kythe goes and hopefully integrating Kythe and srclib. I think this is a huge step forward toward better tools for programmers. Just ask anyone who works/used to work at Google about the quality of their internal dev tools vs. the outside world. Thanks to the Kythe team for sharing this with the world!

dcsommer (author of proxygen) gave a great talk about this at the last Sourcegraph open-source meetup. Here's the video: https://www.youtube.com/watch?v=-yxQIRl6Qic

We generate the pages dynamically. When code gets pushed to a repository indexed by Sourcegraph, we re-analyze it, which means that the location of definitions/references changes and the stats about who uses what change, too. This happens fairly often, so it's easier just to generate pages dynamically.

If you want to get an idea of our site architecture, you can check out https://sourcegraph.com/github.com/sourcegraph/thesrc. (It's a link aggregation site (thesrc.org) that pulls from HN, Reddit, and a few other places and only displays links with programming-related content.) We made it to share some patterns we found useful for building a web app in Go, and the interfaces and structure mirror how Sourcegraph.com is designed. There's also a talk here if you're interested: http://www.youtube.com/watch?v=7zYXhhrRn2E.

Author of the post here. I totally agree that comprehensive tests are still necessary. The blog post/talk don't cover this, but we actually have both kinds of tests - unit tests to test components in isolation and end-to-end tests that hit functionality from the front-end all the way to the DB.

In our experience, unit tests are useful because they run quickly (so you can run them literally every time a file changes), and let you much more quickly figure out the root cause of a failure. To us, the ability to run tests in a few seconds vs over a minute is important, because we want the dev feedback loop to be as immediate as possible. Just as we would hate waiting on slow compile times, we also hate waiting on slow tests.

That having been said, we also run comprehensive end-to-end tests before pushing changes to the site to ensure everything works properly. We think both are important to ensuring site quality and keeping the dev cycle efficient.

One of the authors of srclib here. Python has been incorporated (and should be installed if you update srclib and run the toolchain install script). The website hasn't been updated to reflect this, however. Let us know if you run into any issues!

Check out the Sourcegraph Chrome extension: https://chrome.google.com/webstore/detail/sourcegraph/dgjhfo.... It links Python code on GitHub (though it doesn't have the cool feature of inlining a results box on Google searches)

(note: I'm one of the creators of Sourcegraph, would love to hear any feedback!)

Péter Szilágyi, creator of Iris, gave an excellent talk about it at FOSDEM this year: https://archive.fosdem.org/2014/schedule/event/iris_decentra...

Co-creator of the Chrome extension (and the site backing it) here. Would love to hear any feedback people have from trying it out! https://chrome.google.com/webstore/detail/sourcegraph/dgjhfo...

Searchcode is awesome and super snappy. It's great to see more tools being created to make open source code more accessible and useful.

Sourcegraph is hiring programmers.

We are a team of 4 in San Francisco building a better way to search and explore code. Sourcegraph indexes 100,000s of open source libraries. It lets you browse fully linked code, see live usage examples of how other projects and people are using a given function, and quickly find documentation. Check it out for yourself at https://sourcegraph.com.

We're looking for programmers who are passionate about open source and who can jump into any part of our codebase and make a strong contribution to our product.

As a member of our team, you will engage with users, design and implement new functionality (front-end, back-end, language analysis), help drive product direction, contribute to open-source libraries, and evangelize our product and mission.

Come help us improve the state of our own craft and make code more accessible and open. Shoot us an email at hiring@sourcegraph.com with your resume and background.

Neat project, thanks for sharing!

We've been working on another code search engine for open-source: https://sourcegraph.com/. Our approach is a little different -- we parse and index things at a programming language level. This has the benefit of being able to list usage examples of a function or jump to a definition (i.e., smart IDE-like behavior). Obviously, one drawback is having to implement language-specific support; right now Sourcegraph just supports Python, Javascript (node.js) and Go.

Would love to hear people's feedback on either approach!

For other examples of code search, check out: Ohloh: http://www.ohloh.net/, Krugle: http://opensearch.krugle.org/, and Google code search (or what remains of it) https://code.google.com/p/chromium/codesearch

Co-creator of Sourcegraph here. Just FYI, in addition to usage examples, we also display the documentation and fully-linked source code (so you can jump to definition, etc.)

Sometimes the documentation tells you exactly what you need. Sometimes you want an at-a-glance example. And sometimes you might want to dive into the source to figure out what's going on. Whatever it is you're doing to understand a piece of code, we want to make it as easy as possible.

Thanks for the feedback!

assert is commonly used as a function, but in this case, it turns out to be a module as well. You can see this by clicking on that module link; you'll go to a page that shows assert.js and see that module.exports is assigned to the ok function (which you can click on to jump to its definition). Other attributes are also defined on module.exports, however, so you can see that you can not only do "assert(condition, message)" but also "assert.equal(condition, message)", "assert.notEqual(condition, message)", "assert.deepEqual(condition, message)", etc.

You're right, auto-generating docs is not easy! Javascript turns out to be one of the toughest languages to do this for, and we have a long way to go. The properties tab doesn't seem very useful on that page. We're pushing a new change to the UI that will hopefully make this page clearer and more useful in the near future. Please send any more feedback our way!

Supporters of heavy documentation seem to emphasize its value in communicating functionality to other programmers, whereas opponents seem to emphasize the hassle of writing it and keeping it up-to-date.

I think a key to documentation that is both easy to understand and easy to maintain is to have good usage examples of the code. They are a very straightforward and concise way of conveying both 1) what something does and 2) how to use it. I like to say, "the right usage example can be worth 1000 words of documentation."

Check out https://sourcegraph.com (disclaimer: I am one of the creators). It parses/analyzes the code to identify function calls, type references, etc., and uses that to show you how a piece of code is used. Currently supports Python, node.js, Go, and Ruby. Would love to hear anyone's feedback!

If you want an example of Go "truly" running on embedded devices, check out Gatt, a Go package for building Bluetooth Low Energy peripherals.

https://github.com/paypal/gatt

A writeup of their talk at GopherCon: http://gophercon.sourcegraph.com/post/83731231041/bluetooth-...

See also: https://camlistore.org/ (unlike Dat, doesn't target datasets, but more generic user data, like photos and files; more Dropbox than npm). It has a pretty cool blob model, exposes a FUSE interface, has a slick photo-browsing UI, and integrates with S3 and (I think) Glacier.

Gobot looks really slick. Here's a link to our liveblog of their talk today at GopherCon. All the code examples for their demos (Game of Life using Spheros, AR Drone with LED light, AR Drone controlled by PS3 controller + EEG device around the pilot's head) were under 100 lines of Go code. Can't wait to play around with this.

http://gophercon.sourcegraph.com/post/83843443678/gobot-go-p...

Author of the post here. Happy to answer any questions I can, and FYI, we (Sourcegraph) are liveblogging all of GopherCon at http://gophercon.sourcegraph.com. Let us know if you have any questions or find it useful!