hansgru

MongoDB vs. Cassandra

None. We use OrientDB http://www.orientdb.org/ (it supports more than one "storage" mode: http://nosql-database.org/ )

On the plus side, it's Java based (without native stuff), so it can run existing production machines where mongo can't be compiled (Sparc, HP, etc).

Another nice advantage is the support for SQL syntax, so for existing teams, the DB people won't feel left out :).

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

Have you tried similar frameworks like Derby (http://derbyjs.com/)? If so, can you compare your experiences?

I tried Derby.js because of one important for me missing feature of Meteor: serverside HTML rendering - required for search engines and also for CMS or content like applications. IMO Derby.js got it right there.

Unfortunately Derby.js is seriously lacking professional documentation of any kind: Meteor already has books and 2 very good and long enough video courses (from pluralsight and tutsplus)

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

Yes, we are using it. UML is quite practical for stuff that needs clarity (so not just for the data model).

We are using even this allot lately: http://drakon-editor.sourceforge.net/ (not UML but good for visual representation of stuff).

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

Do you have any plan on abstracting the Slick driver to allow others DB providers ?

I'm not the developer of the project, but database independence was not requested so far :). I suppose if users will ask it, it will be added. H2 suits however very well all the needs, it has a web based Admin UI that can be simply reused, and it's performance is fantastic: http://h2database.com/html/performance.html

There are already multiple established solutions

Of course there are, but everything I've tried was a paint to setup. GitBucket was the first project that was very easy to setup: in an existing Tomcat (or other container), just drop the WAR file, and everything works. Also no dedicated machine is required for this (I host it along with other applications)

GitHub Enterprise is self-hosted

It is, but it costs more than many small teams can afford.

Are this kind of full clones legal?

This is not a "full clone" but "something like GitHub" but for your own private server.

I understand that the server-side implementation is based on GitHub as a black box

No, it's not. The serverside is implemented in Scala using a JGit as a GIT library for the files and H2 database for saving the metadata.

I need to be sold on why I should use it as a product.

What about self-hosting for public and private repos? (Internet or intranet)?

It's main usage is for small teams and projects that don't want to put theirs source on external servers, nor do have the money for GitHub Enterprise.