There's a map for that | Hacker News Reader

There's a map for that

github.com

305 pointsbencevans73 comments

I'm increasingly thinking that the biggest competitor we have isn't other forum software (who aren't innovating), but Github.

Our startup ( http://microco.sm/ ) is working on improving communities, which most people read as vBulletin, phpBB, Discourse... but my view is simply that if you have a group of people together around some interest (topic, locality, project) that they want to communicate, share, transact at every level.

And that, the fragmented experience of going to Google Maps, Facebook Events or Eventbrite, Wikipedia, review sites, eBay, etc... just to bring the last 5% into a community... well that's frustrating and a poor user experience.

Instead the first 60-80% of the functionality elsewhere should just be in the tool. Where the community already is.

And we're starting with forums and going outward, in every direction (it feels). And here is github, starting with the code, and also heading outward, in every direction.

I've a great deal of love for Github (as a dev, how could I not)... so I wish them well. They're solving things from a dev/work perspective, and we're aiming at consumers/users/hobbies/interests... but still, I've no doubt that we've a lot to learn from them, and when we're up to speed perhaps we can teach them a thing or two.

Whilst I have no insider knowledge, I highly doubt GitHub has any desire to expand outside of the development community.

They already have expanded outside of the development community.

https://github.com/Chicago

I suggested the City of Chicago use Github because it is the only place to put open data that both (a) allows contributions back to the dataset (pull requests) and (b) allows for community feedback (issues and comments).

It's by no means ideal (the building footprints dataset is hidden behind a 2GB compressed JSON blob) but it's still useful and a step in the right direction.

It's still aimed squarely at developers using the data, though. Asking a "normal citizen" to submit a pull request is still a pretty big ask.

People forget this, but even though git was developed for programming version control, there isn't a lot that makes it useful strictly for programming only.

Git is a powerful version control and collaboration system for any plain text (or maybe even binary) files.

There's nothing special about programmers that makes it so they are the only ones that can learn about these tools and use them. With something like TortoiseGit (or Github's app) I can totally see people you would never expect start taking advantage of this.

Authors, mathematicians, research agents, cartographers, government agents (all those legal documents need version control badly), lawyers, etc.

As the world trusts computers with more and more of their files, they might start picking up the tools that programmers have held so dear.

Why not empower them?

Torvalds, in classic Unix hacker fashion, designed git to be so stupid it doesn't care what it's being used for, which goes quite a long way to making it all things to all people.

Similar is how the Linux filesystem code flatly refuses to care about what encoding scheme filenames use as long as the byte 0x2F (ASCII '/') is only used to separate pathname components, the byte sequences 0x2E (".") and 0x2E 0x2E ("..") appearing alone in a component are special, and the byte 0x00 (ASCII nul) is only used to terminate the entire pathname. The kernel is so stupid it only sees byte sequences and only cares about those specific values and sequences; as a direct result, users can use any character encoding which guarantees those values will only be used for their respective purposes, and rely on easily-configurable applications to sort it out.

Here's Torvalds, Viro, and Ts'o chewing out someone who thought the kernel should enforce UTF-8 file and directory names:

http://yarchive.net/comp/linux/utf8.html

I thought ".." was a hardlink to the parent directory created when a directory was created? Hence the kernel doesn't actually have to treat ".." as anything special, since, due to hardlinks, "it'll all work out"?

I hope not, that'd be such a waste

I think the point is that the character encoding scheme can't use "." or ".." for its own purposes because they already have meaning due to filesystem conventions.

I wonder about priorities when I read this. For example, how do I diff two commits via Github? There is a blog post describing this feature:

https://github.com/blog/612-introducing-github-compare-view

However it seems the UI has changed, and the only way I could find to use it was to manually construct the URL.

I'd love for someone to show me some obvious UI I've missed. Diffing is really fundamental for a VCS. I'd much rather Github cleaned up the UI for existing features than added these little flourishes that I can't imagine even 1% of users use.

The main way to get to the compare view is from the branches page:

1. View the branches page: https://github.com/github/markup/branches 2. Click the "Compare" button next to a branch. 3. On the following page there’s a control at the top where you can change the comparison range to compare any branch, tag, or SHA with any other.

Hope that helps!

Why not just do that locally?

Github lets you see the diff for a single commit on their site. This makes sense, because you can use this information to take action on their site, by either approving or denying the pull request.

The only use case for commit-commit diffs that I can think of, though, is if you plan on manually merging them and resolving conflicts, which you cannot do on Github (to my knowledge). There exist many graphical and command-line utilities that you can run on your machine, the same place you will be making those changes.

To me, Github's two jobs are to host reposiitories, and to make it easy to find and view the repositories of others. They do both of these jobs very well, and this map plugin makes Github better at the second in at least some cases. Once it comes time to actually start changing things, though, I get off of Github, and work on the local copy I have with the tools on my machine. Replicating this functionality isn't, to me, what Github is for.

As an aside, if there is a way to manually construct a url, there's a shortcut to getting Github to add it to the UI. A few months ago, someone made a JavaScript bookmarklet to add a search bar to any repository, since the UI for this functionality was so clunky. Because of its popularity, Github added a proper repository-specific search bar.

My site (an AGPL project) tracks a history of versions it has been built with (commit hash plus diff against that commit). "What changed between this version and the last" is the link I want in that feed.

I have to agree.

The fact that you still cannot do side by side diffs on pull requests makes it a less than useful code review tool.

What's the difference between a diff and a side-by-side view of two files? I'd (usually) prefer the former.

It is difficult to follow the code that's been added when all the deletions/diffs get in the way.

I agree. I find that unified diffs work well 90% of the time but when it doesn't it can be crippling. I've attached some screenshots at

http://screenshots.gitsense.com/index.html

that illustrates where side by side becomes a requirement for me. Yeah I can make sense of things with a unified view but the side by side really makes things more obvious.

Note you can find this diff at github at https://github.com/joyent/node/pull/5615/files#L0L80

What program or tool were you using to see the diffs side by side ?

It's from my tool that I've been developing. You can see how the diffing works at

https://www.youtube.com/watch?v=fi7GvcW1NKA

Unfortunately I don't show you how to switch to the side by side view. To do this, you just click on the view toggle button at the top left corner of the diff window.

Nice Work! That sounds similar to Meld. http://meldmerge.org/

Take a look at a pull request on bitbucket. Like this one:

https://bitbucket.org/birkenfeld/sphinx/pull-request/146/res...

Click 'Side-by-Side Diff'. Github has a lot going for it, but bitbucket is the clear UX win as far as reviewing pull requests goes.

I am curious if anyone has any insight as to what GitHub's strategy is with this move?

It seems that they are steadily tracking towards a browser-based cloud IDE. GitHub also seems to be a popular choice for devs hosting their blogs. I wonder if they're hoping to be a more all-round app hosting service?

I wouldn't overthink it, it may have just been for fun, like something that came out of a hackathon or that an intern wanted to do.

Or because of profit ala "powered by mapbox"

I think that's what their move is. Having raised $100 million, they are in a spot where they can aim big.

I imagine their long term vision would be to allow better collaboration for all types of data-based projects (whether code, or geo data, or books).

In the short term, any small project like this that makes GitHub a little cooler is fair game.

I second the call for supporting books. There are already quite a few books being published on GitHub and it seems like an almost natural way to collaboratively write a book that could forever kept up to date. Not sure if anything has been done specifically to support writing a book on GitHub.

I'm a grad student who writes lots of papers in LaTeX with collaborators. We use git most of the time, but git works most painlessly when you tweak it to ignore whitespace and to use word diffs. For example, let's say that my collaborator says "oh, I pushed a new diff" and now I'm curious what he added. Running:

    git pull && git log -p -w --color-words

lets me see exactly which words he added/removed/changed ignoring the fact that he changed all my tabs to spaces in that commit.

Also, if I have a conflict, it's also nicer to use a specialized tool to merge than relying on git's linewise merges.

I imagine github could incorporate some of these tools too.

Thanks for the tip. I'm working on a short non-technical book so I'm hoping to do it in Markdown following the format of The Little MongoDb Book. That book is hosted on GitHub with the Markdown text output to PDF, mobi and ePub. Seems like the simplest way to get to a pretty nice looking book in the major formats.

https://github.com/karlseguin/the-little-mongodb-book

> I imagine github could incorporate some of these tools too.

GitHub allows you to ignore whitespace in diffs by appending _?w=1_ to the URL [1]. They should make this more obvious with a button in the diff interface.

[1] https://github.com/blog/967-github-secrets

The recent Inc. article [1] about GitHub isn't really deep but the end has some insights:

a shift is taking place: "Now we are finding that it's not just about the code; it's about, 'Hey, I want to work on this with you.' That's really eye-opening to us and gets everyone here superexcited. Working with someone else is just an awesome part of being alive. Creating art, creating tools, creating documents, doing homework, anything--it's not limited to programming. I don't see why musicians wouldn't want to work this way, for example."

Take that, and now consider how much a forward-thinking city could do with its data as GitHub adds features like this. I don't think it's about being just an IDE/app hosting service ... it's (eventually) about collaboration/control/revisioning beyond purely software projects.

[1] http://www.inc.com/magazine/201303/will-bourne/2-reasons-to-...

Can this be a vision that is totally disruptive, not now but but 5 (or 10) years in the future?

It looks like GitHub is looking at allowing collaborations between knowledge domains. Within their blog post, it said "People are already using GitHub to store everything from Chicago zipcodes to community radio stations to historic hurricane paths, and we can't wait to see what the community will begin to collaborate on next."

So I am guessing that GitHub is putting a few small services that folks could use with the collaborations. Mapping services is one of them, another could be public transport information services. I think it all depends on what kind of data are being held in GitHub.

Now, if this collaboration idea is spun off to someone like to DropBox where there are truck loads of data in there, we could see some interesting things.

This reminds me of trying to determine the scope of your company.

I remember reading somewhere (probably here) that part of the reason the railroads failed to adapt to cars was because they thought of themselves as railroad companies instead of transportation companies. Maybe github is thinking of themselves as a collaborative work company rather than a collaborative coding company and trying to adapt to that.

And your comment reminded of something similar with Coke. At some point they decided that they weren't competing with other soda manufacturers but for "share of stomach" and started going in that direction by going on an acquisition spree.

I know you're just trying to make a metaphorical comparison with railroads, but the story isn't that simple.

In the U.S., intercity railroads found they could make more money by focusing on freight and leaving passengers to poor Amtrak. If Warren Buffet's acquisition of BNSF is any indication, the private railroads are quite profitable.

The decline of intracity passenger rail in the U.S. has many causes (massive public investment in the Interstate highway system for one). Still, it's worth remembering that auto companies played an active role in acquiring and disassembling streetcar lines: http://en.wikipedia.org/wiki/General_Motors_streetcar_conspi...

Github doesn't have any central direction at all (people are more or less allowed to work on whatever they like), and this is a side-effect: the boring stuff doesn't get worked on, and the fun stuff (like, say, rendering 3d models, or a CLI in the header) gets lots of attention.

I think Github is probably vulnerable to a team that stays focused on the bread-and-butter tools that are actually important to developers.

Reminds me of a TED talk[1] were he ends up discussion the use of git or similar tools in the government.

[1] http://www.ted.com/talks/clay_shirky_how_the_internet_will_o...

Github is becoming, in addition to a place to share code/data, the commandline program between "cat data |" and someone else's eyes.

cat gps_data.txt | github --pretty-maps > the world

I think its really expanding its collaborative focus as it moves from purely coding to "Projects with code". Code itself is (or should be) inherently readable. A great deal of data that code deals with, like GIS data, isn't.

Whatever you think of Github you gotta admit that they are machines when it comes to adding new features to the site, the pace is fast and steady.

I'd love to know where these ideas come from. All the way from the top? Product? Developers with a 20% time window? They've always been innovative and despite size/growth/scale seem to be able to keep that up.

It's more organic than you think. Employees want to see something, so they sell others on and work on it themselves if they can. If they can sell others to help, eventually it can ship. If not, then it atrophies and gets killed before it makes it out to the public.

I wouldn't be surprised if the request came from a user. I've seen a couple features get implemented after suggesting them via the contact form.

> Developers with a 20% time window?

We like to call it 100% time. Work on what you're interested in.

In this case, Ben — who handles a lot of our outreach to government agencies — knew that GeoJSON is something that could be a big deal for open data in government, so he built the feature. There's not much more to it than that.

Cool. I wonder what the conversion workflow --> GeoJSON is like? KPX and CSV and XLS are common over at data.gov.au / data.act.gov.au

GeoJSON is an entirely different type of data. "columns" and "rows" aren't a useful way to think about it; you have to talk about points and closed polygons and their associated metadata instead.

The downside of this seems to be that it discourages users from using the superior format TopoJSON by Mike Bostock, as it outputs in plain .json: https://github.com/mbostock/topojson.

GeoJSON is a feature of Leaflet: http://leafletjs.com/features.html

Leaflet is the library used by Mapbox.

Pretty sure if you add a pull request to Leaflet with code for TopoJSON that Mapbox will get it too and then Github will have it.

We think TopoJSON is a fantastic format and some of us have usedit in recent projects. For example: https://github.com/caged/portland-census

Since GitHub is starting to feel Emacs-like, why not go fully in this direction? Add a "dotfile" repository for everyone to manage their own client-side JavaScript extensions for Github that would be loaded by default. And then let people collaborate, share and create extensions and "configurations". Want a better map? Fork the official one and modify it. And then let others fork from you.

This would make scripting attacks really hard to defend against. They could use something along the lines of Caja, but it's a really hard problem in general (and one they're worrying about, given the gh-pages move to a separate domain)

You could achieve something like that using https://github.com/defunkt/dotjs

Hmm, neat. I've added all the bike sharing networks I can think of to a repo[1], and for all you NY bike sharing lovers, there you go[2].

I don't think I will update it to work in 'real time' because it would not make much sense, but it was fun to play with.

[1]: https://github.com/eskerda/cb-geojson/blob/master/networks.g...

[2]: https://github.com/eskerda/cb-geojson/blob/master/citibikeny...

EDIT: nevermind

https://github.com/bikesharebot/bikesharestats/blob/master/c...

That's fucking sick. Nice work man.

Nice work on pulling this off!

One could question, who would want maps on github? Sometimes one cannot know what something can be used to until being able to actually use it, that should be the whole point on technology.

A lot of folks from the GIS community. As mentioned in the blog post, people will already storing this data on GitHub, now it's simply presented in a nicer fashion :)

And as you mentioned, sometimes just providing the tools empowers the community to do to do amazing things.

I wish they would just make HTML previews work instead of hardcoding specific use cases with 3d models and geodata.

Eg why can't github just let visitors preview this html file: https://gist.github.com/dergachev/5769111#file-index-html

For now, I have to link bl.ocks.org, which is nice but far from perfect. And check out http://htmlpreview.github.io

(I understand that there are security concerns, but I'm sure they can be addressed with an iframe or by clicking an external link)

Well they have a file system(git), now they add ways to interact with data, up until they create a fullblown operating system. Something that Google is already onto with ChromeOS.

Cool stuff - had not heard about the 3D rendering linked in the article either. These are not trivial features to implement or maintain and seem to have a somewhat narrow audience. GitHub has such an amazing team and the core functionality seems pretty complete. I wonder if the "ship code" ethic and loose management structure (both of which I think are great) will inevitably lead to a bloated, feature overloaded product eventually. This has happened so very often in the past to others. So far they have been pretty good at closing down unused features.

This is really cool! However, I would be remiss to not mention that I would love for Github to focus more on Git. I have been using git for about two years, but I am far, far, far from being a git ninja. I suspect that I am not alone based on what I see at stackoverflow with questions tagged "git."

What if they spent their time improving: 1. Github Pulls - Have you seen the hoops one needs to jump through to submit a single-commit pull request? One needs to be extra careful about the workflow.

2. Let me determine the Project/Repo language - How many repos do you have that are labeled Javascript when its really a Python, Ruby or something else Project? Not critical, but seems really silly that I have to wade into the src to determine something like base lang.

3. Make git, itself, more intuitive - Surely if they can add the crazy cool features they've added, making the management of git repos DEAD simple should be a priority. Look at the questions tagged with "git" on stackoverflow and see how many you could devine an answer from using github.

4. Git fast forward - Could github provide an way to see what is going to happen to a repo when issuing git commands? All these cool visualizations online and we have to experiment with git locally seems a bit odd.

Free idea; Gitfiddle. See what your crazy ass commands will do to your repo before you spend the next 4 hours figuring out why you didn't want to do that.

Ie. Find the merge base between your branch and master: ‘git merge-base master yourbranch’ Assuming you’ve already committed your changes, rebased your commit onto the merge base, then create a new branch: git rebase –onto <basecommit> HEAD~1 HEAD git checkout -b my-new-branch Checkout your ruggedisation branch, and remove the commit you just rebased: ‘git reset –hard HEAD~1′ Merge your new branch back into ruggedisation: ‘git merge my-new-branch’ Checkout master (‘git checkout master’), merge your new branch in (‘git merge my-new-branch’), and check it works when merged, then remove the merge (‘git reset –hard HEAD~1′). Push your new branch (‘git push origin my-new-branch’) and log a pull request.

the above from: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-abo...

> Free idea; Gitfiddle. See what your crazy ass commands will do to your repo before you spend the next 4 hours figuring out why you didn't want to do that.

It's really hard to screw things up that badly with git, you can nearly always go back using $ git reflog and $ git reset --hard .

You can't screw it up they says, it so easy they says... well then why this: http://stackoverflow.com/questions/134882/undoing-a-git-reba... and this: http://ocpsoft.org/tutorials/git/use-reflog-and-cherry-pick-... and a gazillion more just for that one command; 'reflog'... type --rebase vs --merge and let your head explode with the rest of us n00bs.

The truth; Git is hard. My opinion, I want to write code and keep it somewhere. I'm not a professional developer and I want to contribute to open source in my free time. That means git || hub, generally. It would be awesome for Github to make git exploration from the browser easier. Yes, I pay github every month and I am happy to do it.

Agree that the git command-line API is harder than it ought to be. My comment was meant to help git beginners that are afraid of exploring for fear of wasting many hours fixing their mistakes; you should consider learning the commands to undo your mistakes before learning other crazy commands.

How do you learn to fix a mistake before you make one? You may have a weak notion of what you need to do... but you don't know until it happens and have a need to git dirty. Further, In my opinion of course, these features are great... but someone is going to make git easy while retaining its power. Git is a nacent technology and while Github is dominating now... there is always room for disruption. They, the people who make git easy, will be the winners. Don't make me think.

Yeah, esp. #2 bugs me SO much. I wish if in a multi-language project, JS would at least be "only 0.1 priority" or something for GitHub when guessing languages.

Even cooler would be if they showed the 2-4 top languages in a repo (depending on screen space), but again preferably with JS/CSS only counting at 10% or something..

Hmm, on Firefox 23.0a2 I just see a white box with nothing there. Usually this means an addon is interfering somehow. But I turned off AdBlock, Ghostery, HTTPS Everywhere, Flashblock and Greasemonkey, which is basically everything, and reloaded, and still nothing. Anyone else?

(Edit: All fixed, thanks Oompa!)

Woops! Small issue. Should be fixed now :)

A little UI feedback if anybody from GitHub is listening:

When you click and hold to move the map, and you scroll the mouse all the way off the map, the map acts like you are continuing to hold the mouse button down, even if you let go of the mouse button. When you return the mouse to the map, it acts like the button is still pressed and the map sticks to the pointer...for which you have to click again to get out.

This is unexpected behavior, especially if you are trying to scroll through more than one screen with repetitive mouse drags. The map scrolling should maintain the same behavior of the mouse button hold even if you scroll off the map.

A terrific feature would be to have the same in gist, embeddable everywhere.

Want to show a place or some directions on your website/blog/... ?

Just create a gist with geojson format and embed it on your blog, as programming blogs embed code gist right now.

Congrats!

I look forward to the day when git is the defacto way to collaborate, and I'm so happy to see that GitHub is leading the way forward. This kind of stuff is great!

Wow. Speaking of Leaflet.js, modern web-technologies are powerful and elegant.

And GitHub is becoming a whole universe. What a wonderful service, idea, design, usability! I am really amused.

Reply on news.ycombinator.com