Browse files

clean up, formatting, freeze candidate

  • Loading branch information...
1 parent 6329417 commit 99f41e7a57771f09201447a60b39fb11df6cb0a4 @timfel timfel committed Jan 31, 2010
Showing with 11 additions and 22 deletions.
  1. +6 −6 bithug/bithug.bib
  2. +1 −12 bithug/bithug.tex
  3. +4 −4 bithug/persistence.tex
12 bithug/bithug.bib
@@ -84,26 +84,26 @@ @misc{haines2009redis
- title={{github}},
+ author={{github}},
- title={{sinatra}},
+ author={{sinatra}},
- howpublished={\url{}}
- author={Free Software Foundation}
+ howpublished={\url{}},
+ author={{Free Software Foundation}}
- title={{Linux Kernel}},
+ author={{Linux Kernel}},
+ author={{ Foundation}},
- author={{ Foundation}},
author={Hirabayashi, Mikio},
13 bithug/bithug.tex
@@ -98,17 +98,7 @@ \section{Project Management as a Service}
we intend enabling Bithug to be used in an academic context and smaller companies,
configuration needs to be easily personalized and highly versatile.
-\section{Technical Stuff}
-\subsection{The Stack}
-Our project split into three major subprojects: Bithug (out actual project), BigBand (parts of Bithug you can use in any Sinatra Project), MonkeyLib (parts you can use in any Ruby project).
-Patched versions of krb5-auth (currently unmaintained) and Ohm.
-Other libraries we use: ...
-Stack is known to work on ...
+\section{Design and Technical Execution}
@@ -178,7 +168,6 @@ \subsection{Using dynamic inheritance as means of configuration}
All our common logic is placed inside AbstractUser. Now, if we include a module in Bithug::User, it is inserted in front of AbstractUser
in the inheritance chain, thus getting called.
8 bithug/persistence.tex
@@ -1,4 +1,4 @@
-\subsubsection{Why no RDBS?}
+\subsubsection*{Why no RDBS?}
Traditionally, databases have focused on storing relational datasets.
Relational storage has the advantage, that data retrieval can be formulated in
a declarative way. These declaration can then be mathematically optimized for
@@ -27,7 +27,7 @@ \subsubsection{Why no RDBS?}
provide migration strategies for setups changing their configurations as well
keeping the mapping general enough to allow easy transitions when implementing
new services.
-\subsubsection{A promising alternative: Maglev}
+\subsubsection*{A promising alternative: Maglev}
Maglev is a Ruby implementation atop GemStone/S, the Smalltalk
object-persistence system. GemStone is an object-oriented database able to
serialize objects in the runtime environment transparently, taking care of
@@ -41,7 +41,7 @@ \subsubsection{A promising alternative: Maglev}
young implementation of Ruby and it does not yet support enough of the features
we require in Bithug, most importantly the CSS-compiled style-sheet language
SASS and the Kerberos authentication plug-in we provide for company networks.
Key-value stores have emerged in the last few years as an alternative to
relational database management systems for some data storage tasks.
Redis, BigTable, and Casandra are just three of the players in this buzzing
@@ -74,7 +74,7 @@ \subsubsection{Key-Value-Stores}
return-on-investment can literally be met by the first customer paying for one
-\subsubsection{The Store of our Choice}
+\subsubsection*{The Store of our Choice}
In the Ruby world, there are lots of alternative KV-Stores to chose from, some of which
are fast and simple to use, others which have a more advanced API but provide
additional features that go beyond a simple hashing KV-Store. Here are a few

0 comments on commit 99f41e7

Please sign in to comment.