Home About Eric Topics SourceGear

2010-07-19 20:13:45

Veracity Technology Overview

When I encounter a new piece of software, I usually ask, "What's in it?"

Tools and technologies we've been using to build Veracity

C

The core library and the command-line app are written entirely in C.  Some folks won't like our coding conventions.  I'll probably do a whole blog entry sometime to ((apologize for) && (defend)) the liberties we've taken with the C preprocessor.

JavaScript

jQuery

On the browser side of things, Veracity is a web app written in JavaScript using jQuery.

SVG

Burn down charts and other web graphics are done using SVG.

JSON

Veracity uses JSON all over the place.  All serialized structures in the repo are JSON.  Database records and templates are JSON.  We have a bunch of C code for parsing JSON, writing JSON, and dealing with JSON-like data in memory.

SQLite

We use SQLite in several places as a more scalable disk format, and also as an index.

Mongoose

The Veracity command-line app has an embedded web server for personal use.  It's based on Mongoose.

Curl

The client side of push/pull is done by calling libcurl.

UTF-8

ICU

Early on in the Veracity project, we did a lot of work to make sure that stuff was done right with respect to Unicode.  Our preferred encoding is UTF-8.  The ICU library from IBM has been helpful in a number of places.

REST

The Veracity web API is very RESTy.  And of course, everything serialized over the network is in JSON. 

CMake

Our build system is CMake, with which we have a love/hate relationship.  We love it because it generates makefiles, Xcode projects or Visual Studio solutions.  We hate it because its language makes Forth look sane.

CTest

We have a huge suite of automated tests.  CMake's integrated test stuff actually works pretty well.  Just run 'ctest' at the top level directory.

SpiderMonkey

A lot of our tests are written in Javascript.  We have a command-line executable called 'vscript' which is basically the Spidermonkey Javascript engine glued to the main Veracity library.

Continuous Integration

Our CI system system rebuilds from scratch and runs the main tests after every checkin, on Mac, Linux and Windows.  Results are published to an internal web page and sent to the team by email.

Scrum

The more we use Scrum, the more I like it.  We're patient with ourselves.  We just try to get a little better in our Scrum practices each iteration.

gcov

lcov

Nightly builds run the entire test suite with code coverage done by gcov.  Our current coverage level is 81%.

vcdiff

For binary deltas, Veracity uses the algorithm described in RFC 3284.  (Actually, the use of binary deltas is currently turned off by default, so if you notice that repositories seem big, that's why.  All the plumbing is done.  We're just not using it yet.)  Anyway, we've got our own implementation of vcdiff.  We may consider switching to Google's open-vcdiff at some point if its performance is better.

zlib

For simple non-deltified compression in repo implementations, Veracity uses zlib.

Valgrind

When coding in C, valgrind is indispensable.

Shark

I do most of my coding on the Mac, so I use the Shark profiler.  Very cool.

emacs

vim

Eclipse

Visual Studio

bash

gdb

Every developer on our team chooses their own tools.  We have a good representation of most of the major religions.

Firefox

Safari

Chrome

Similarly, every developer chooses their own web browser.  I'm not sure what feelings to have upon noticing that nobody is using Internet Explorer.  It seems so wrong.  And yet, so right.

A few notable things we'll probably be using later

.NET

Even though Veracity was not built fundamentally on the .NET platform, we are committed to providing excellent support for Windows developers.  Visual Studio integration is a high priority.

Java

Similarly, we didn't use Java to build the core libraries for Veracity, but we plan to deliver excellent integration into the Java world, including an Eclipse plugin.

IIS

Apache

The embedded web server is fine for personal use on the desktop, but large teams will want to run a real web server for their central repository.  We designed for this case early, but have not yet implemented something like an IIS plugin.

A few notable things we are NOT using (and maybe never will)

C++

Here's another blog article I need to write.  Basically, we only considered two choices:  C, and the C-like subset of C++.  We chose plain C.  I just wish the Microsoft C compiler supported C99.

Flash

Silverlight

GWT

We seriously considered other ways of building our web apps.  We ended up choosing basic HTML/CSS/jQuery/Ajax.  No regrets, but I sometimes wonder how things are going for people using GWT.

NSPR

APR

Sorry folks, in an apparent fit of NIH syndrome, we wrote our own portability layer. And I am completely unrepentant.

XML

JSON won.  What can I say?  I just like curly braces a lot more than angle brackets.