hansgru

#CLJ-183, #CLJ-188, #CLJ-186, #CLJ-178, #CLJ-165, #CLJ-129, #CLJ-77 to mention just a few.

> Did you check out the meteor package "spiderable"? It might need to mature a bit but it might do the trick

Of course I did :). It's not usable at all :). It's also not reducing the initial loading time (very high for any public webpage).

There are many (important IMO) feature requests for LaClojure in the Issue tracker. Any plans to implement at least some of those?

> That is entirely false.

In mainland Europe this is entirely true.

Even more, this has implications not only when searching for jobs or gigs, but also on the social/personal level: the stigmata and marginalization that comes with it it's incredible here.

I now lie about my previous failed startups.

They said the same thing about Iceland too :).

> I don't understand the local vs global dependency thing. What does NPM do differently from Maven?

As others have pointed out, NPM as a default is using "local" dependencies, (something I couldn't achieve with Maven easily).

"Local" means that the dependencies are in a sub-directory of the project, and that the transient dependencies are in sub-sub-directories too if needed.

With NPM, for us some of the implications of this are the following:

- being "self contained" I can check in a VCS and tag it "completely" or just zip it and send somewhere else, where it can be built "as it is", even on CI machines or production machines that have no Internet connection, nor do require a company internal Maven server.

- bugs and issues with building are reproducible. The "it builds on my machine" doesn't happen anymore. (Just search the different Apache mailing lists of how often this happened even in those open source projects). We had this problem very very often - to the point where several projects were migrated to ANT again.

- the availability of public Maven Repos, their mirrors and their sync is just bad (sometimes it's the corporate firewall/proxy the problem), so builds just fail all to often. Many companies don't use internal Maven Repo Mirror

- none where I worked had one, nor could we convince the management to finance one.

- very often (even visible in open source projects that build with Maven), there are some dependencies (maybe not from the start of the project, or maybe only temporarily) that are not available in the official repos, so need to be manually added. Doing this in a sub-directory is much easier, and it needs to be done only once, so others will just use it.

These are just a few issues that NPM seems to have been solved nicely (or just not having them because of of the "local" defaults).

Of course, there are also disadvantages of this "local" approach (like the redundant disk space usage - where the global one is very efficient), but from my experience all these disadvantages pale compared to the problems and frustration Maven brought in many projects that adopted it.

> Maven is broken by design

It might be, but it still has it's merits. It was one of the first, and many other improved tools can't work without it's repositories.

I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency diagram that I find useful, even if I don't use Maven for something else in a project.

Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.

> Did your side project become your main source of income in 2013?

No. My side projects are just my main source of expenditures so far :).

> Any idea how fast it is? GitHub have put a considerable amount of effort into a very fast implementation.

From my tests, is usable. I'm using in the intranet, and have an installation with 20 users and 15 repos so far, with ~100MB each at the moment.

However, this project is not targeted as a GitHub replacement (massive hosting with many huge repositories), but toward small teams that need a UI and simple admin for their Git repos and aren't allowed (or don't want) to use an existing cloud service, or don't have the budget for the GitHub Enterprise.

All projects using the default Twitter Bootstrap styles look very alike :). One could of course using one of the many Bootstrap UI Builders generate a totally different look, but so far nobody volunteered :).

> I was just wondering about theoretical consequences of cloning UI/tool of a successful company software with the reason of the tool/interface being too expensive.

The UI was not cloned either :). The UI is a Scalatra template (Twirl) and a Twitter Bootstrap style. It could be customized in any possible way and look the user would wish, but so far the developers are concentrating on the basic features.

> It would be a great way of learning Scala.

For me it is :). I started to learn Scala after finding this nice project. Since it was so easy to install it (just copied the WAR file in a running Tomcat) it made me curious enough to give Scala a try and also to buy the Scalatra book too :).