Re:A tour of the Clojure landscape
by bitsai on Sunday January 30, 2011 @10:26PM
(#2160152)
I really appreciate this. Even though I'm a daily reader of the Clojure mailing list, some of these projects were completely new to me. For instance, I knew about Ring, Compojure, Enlive, and Hiccup, but I'd never heard of Sandbar before, which looks like a very useful piece of the puzzle.
Have you considered refreshing this 'map' periodically and/or adding this to either the Clojure website or wiki? I think that'd be a nice way to help people stay abreast of useful up-and-comers.
The vast majority of Clojure projects all seem to live on github. So, perhaps one way of picking out important projects with one/few contributors could be by looking at projects with high numbers of forks or watchers?
Re:A tour of the Clojure landscape
by ericlavigne on Sunday January 30, 2011 @10:39PM
(#2160174)
I will definitely create an auto-refreshing version eventually. For now, though, I'm trying to stay focused on my original goal. As I mentioned at the top of the article, I'm trying to create an entire directory of Clojure libraries. That directory will tell you about the relationships between libraries and help you to find specific libraries that could help your project. There could also be a list of featured projects, which will deliberately be spread all over the network of projects.
For now, I need to focused on improving my calculations, fetching all the data I need (what I showed in the article is just the tip of the iceberg), and finding better ways to infer relationships between projects.
Re:A tour of the Clojure landscape
by bitsai on Sunday January 30, 2011 @11:09PM
(#2160235)
Right, I didn't mean to distract you from the original goal :) The directory would be very, very cool to have as well. Sticking with the watcher/forker theme, perhaps the overlap between two projects' watchers/forkers (either in raw numbers or as a fraction of the total) might be a way to gauge their relationship?
Can't wait to see what you come up with. Best of luck!
Re:A tour of the Clojure landscape
by ericlavigne on Sunday January 30, 2011 @11:14PM
(#2160247)
I was imagining using the number of watchers and forkers as a measure of popularity. Looking at overlap based on WHO is watching/forking sounds like a better idea. Thanks for the suggestion.
Re:A tour of the Clojure landscape
by pan69 on Sunday January 30, 2011 @10:55PM
(#2160207)
Is there something like this for the Ruby/Rails ecosystem?
Starting out with Ruby/Rails can be quite daunting, not so much because of the language or the framework but because of the ecosystem with it's many third-party tooling.
Re:A tour of the Clojure landscape
by yaxdotcom on Sunday January 30, 2011 @11:12PM
(#2160245)
The large ecosystem is one of the biggest benefits to Ruby/Rails development but, yes, it can be difficult to determine which third-party project is best supported or most popular. I'd have gotten lost long ago if it wasn't for Christoph Olszowka's "The Ruby Toolbox" site [1] with its grouping of projects by category and sorting by GitHub watchers, forks, and recent activity. Take a look if you don't know about it already.
Have you considered refreshing this 'map' periodically and/or adding this to either the Clojure website or wiki? I think that'd be a nice way to help people stay abreast of useful up-and-comers.
The vast majority of Clojure projects all seem to live on github. So, perhaps one way of picking out important projects with one/few contributors could be by looking at projects with high numbers of forks or watchers?
http://disclojure.org/
http://www.reddit.com/r/Clojure/
http://planet-clojure.org/
http://www.clojurls.com/
http://www.delicious.com/clojurebot
https://github.com/languages/Clojure
(forgot)
For now, I need to focused on improving my calculations, fetching all the data I need (what I showed in the article is just the tip of the iceberg), and finding better ways to infer relationships between projects.
Can't wait to see what you come up with. Best of luck!
Starting out with Ruby/Rails can be quite daunting, not so much because of the language or the framework but because of the ecosystem with it's many third-party tooling.
[1] http://ruby-toolbox.com/