Baccarat is an interesting card game that you’ll find at many casinos. The objective of the game is to correctly predict whether the bank or player will win a hand.
In Baccarat the scoring for a hand is very simple, add up all the cards at their face value with face cards being worth 10 and only count the total in the ones column.
6 + 7 + J = 23 = 3
A + 4 = 5
The highest possible hand is 9 and whoever has the highest hand wins. If the player and banker have the same hand, it is a tie.
I won’t go into the details of how the number of cards are drawn is determined, but if you are interested you can find that information on Wikipedia. Basically, you end up having pretty close to a 50 / 50 chance of either the player or banker winning a hand. (Of course the house edge still is about 1.06% in the best case.)
The interesting thing about Baccarat though, is that despite the odds, despite common sense, despite the understanding that the game is completely random, people will still sit there and record every single hand and score trying to use it to look for patterns to predict future results.
These poor deluded souls actually think they are measuring something on these score cards, as if what happened in the last hand will in any way affect what will happen in the next hand.
After many years of trying to find the secret formula for measuring software development activities,I’ve come to the conclusion that trying to measure just about any aspect of software development is like trying to measure the odds of a future Baccarat hands based previous Baccarat hands.
Why we want to measure software development
It’s understandable why we want to measure software development—we want to improve. We want to find out what is wrong and fix it and we want to know when things go wrong.
After all, who hasn’t heard the famous quote:
“What gets measured gets improved.”
Don’t we all want to improve?
Somehow we get stuck with this awful feeling that the opposite is true—that what doesn’t get measured doesn’t get improved.
And of course we feel guilty about it, because we are not doing a good job of measuring our software development practices.
Just like the avid Baccarat gambler, we want to believe there is some quantifiable thing we can track, which will give us information that can give us the edge.
Sometimes the reason for wanting to measure is more sinisterpractical, we want to evaluate the individuals on our team to see who is the best and who is the worst.
If we could figure out how to measure different aspects of software development, a whole world of opportunities open for us:
- We can accurately give customers estimates
- We can choose the best programming language and technology
- We can figure out exactly what kind of person to hire
- We can determine what kind of coffee produces the best code
How we try
I’ve been asked by many managers to come up with good metrics to evaluate a software development team.
I’ve tried just about everything you can think of:
- Lines of code written
- Bugs per developer
- Bugs per line of code
- Defect turn around time
- Average velocity
- Unit test code coverage percentage
- Static analysis warnings introduced
- Build break frequency
I’ve built systems and devised all kinds of clever ways to measure all of these things.
I’ve spent countless hours breaking down backlogs to the smallest level of detail so that I could accurately estimate how long it would take to develop.
I’m sure you’ve probably tried to measure certain aspects of software development, or even tried to figure out what is the best thing to measure.
It’s just too hard
No matter what I measure or how I try to measure it, I find that the actual data is just about as meaningless as notebook full of Baccarat hands.
One of the biggest issues with measuring something is that as soon as you start measuring it, it does start improving.
What I mean by this is that if I tell you that I am going to start looking at some metric, you are going to try and improve that metric. You won’t necessarily improve your overall productivity or quality, but you’ll probably find some way—intentional or not—to “game the system.”
Some managers try to get around this issue by just not telling the team what they are being measured on. But, in my opinion, this is not a good idea. Holding someone accountable to some realistically arbitrary standard without telling them what, is just not very nice at all, to put it mildly.
But really the biggest reason why it is too hard to measure aspects of software development, is thatthere are just way too many variables.
- Each software development project is different
- Each feature in a project is different
- Software developers and other team members are different
- From day to day even the same software developer is different. Did Jack’s wife just tell him she was cheating on him? Did Joe just become obsessed with an online game? Is Mary just sick of writing code this week?
- As you add more unit tests the build time increases
- Different team members go on PTO
- Bob and Jim become better friends and chat more instead of work
The point is everything is changing every day. Just about every aspect of software development is fluid and changing.
There is not one metric or even a set of metrics you can pick out that will accurately tell you anything useful about a software development project. (At least I have never seen one at any software development shop I’ve ever been at on consulted at.)
If you were building widgets in a factory, you could measure many qualities about that widget making process, because much of it would be the same from day to day, but with software development, you are always exploring new territory and a 1000 different variables concerning how you are developing the software changing at the same time.
Measuring without measuring
So am I basically saying that metrics in software development are completely worthless and we shouldn’t bother to track anything?
No, not exactly.
What I am saying is that trying to use metrics int the same way that we measure the average rainfall in a city, or running pace improvement by looking at its average over time, doesn’t really work in software development.
We can track the numbers, but we can’t draw any good conclusions from them.
For example, say you track defects per lines of code and that number goes up one week, what does it mean? Any number of things could have caused that to happen or it could just be a totally random fluke. You can’t really know because there isn’t a knob you can turn and say “ah, I see we turned up the coffee bitterness factor to 3 and it resulted in more bugs.” Instead there are 500 knobs and they all changed in random directions.
So, I am saying don’t look at how the numbers of any particular metric are moving from day to day or week to week and expect that it means anything at all, instead look for huge deviations, especially if they are sustained.
If all of a sudden your average team velocity dropped down to almost nothing from some very high number, you won’t know what caused it, but you’ll know that it is much more likely that there was one single knob that got cranked in some direction and you’ll at least have some idea what to look for.
You really have to treat the software development process more like a relationship than like a factory.
I don’t have a series of metrics I use to evaluate my relationship with my wife or my friends. I don’t secretly count how many times my wife sighs at me in a day and track it on a calendar to determine our relationship quality factor.
Instead what I do is talk to her and ask her how things are going, or I get a more general idea of the health of the relationship by being involved in it more.
Team retrospectives are a great way to gauge the temperature of the team. Ask the team members how things are going. They will have a pretty good idea if things are improving or slowing down and what the effectiveness level is.
Measure not, but continuously improve, yes
So kick back, don’t worry so much. I promise I won’t tell Six Sigma that you aren’t using metrics.
Instead focus on continuously improving by learning and applying what you learn. If you can’t notice enough of a difference without metrics, metrics wouldn’t have helped you anyway, because the difference would just be lost in variance anyway.
Finalizando a série de slides, é apresentado o estudo de caso (fictício) da WCM e algumas soluções de automação do PDI. Apenas relembrando, o material com os exercícios foram publicados no post da 1a aula.
Na 2a aula do tutorial são mostradas as principais técnicas de manipulação de dados e fluxo de controle, além de apresentar algumas técnicas de transformação dos dados. No fim, é mostrado como validar e tratar erros com o PDI. O roteiro e o material para os exercícios foram publicados na 1a aula dessa série.
Nesse semestre eu reduzi a zero o número de aulas nas faculdades onde ensinava. As atividades no MCT e no doutorado estão tomando todo o meu tempo de trabalho e ficou inviável continuar lecionando. De qualquer forma, vou começar a publicar nesse espaço o material dos últimos cursos e disciplinas que ministrei. Minha intenção inicial sempre foi produzir um conjunto de apostilas para servir de apoio aos meus alunos, mas por enquanto vou publicar apenas os slides das aulas.
O primeiro conjunto de slides é sobre um tutorial do Pentaho Data Integration. Esse material foi mostrado na cadeira de Banco de Dados para Suporte a Decisão, do Prof. Robson Fidalgo. Fiquem à vontade para criticar e sugerir modificações no material.
O roteiro dos exercícios encontra-se disponível nos slides abaixo:
As bases de dados dos exercícios podem ser baixadas aqui.
A nova versão do Ubuntu foi lançada no dia 10/10 pela Canonical. Como sempre faço a cada seis meses, me preparei para passar um dia inteiro recompilando drivers e instalando as novas versões de algumas aplicações. Fiz um backup de quase 120 GB e comecei o processo de atualização. Da última vez, tive que fazer uma instalação limpa, pois vários drivers de meu HP Pavilion dv5 apresentaram problemas de incompatibilidade com a versão do novo kernel.
Para minha grata surpresa, o processo de atualização rodou rápido e sem apresentar praticamente nenhum problema. A nova versão, 10.10, mostrou-se muito estável. O único problema foi a recompilação de alguns módulos do VMWare Player que apresentou a mensagem “Unable to build kernel module – See log file…” durante o processo de inicialização. A falha foi resolvida com o patch fornecido por Matt Rudge (acesse o procedimento aqui).
Na minha última atualização de versão, meti o pau na Canonical pela falhas, mas dessa vez tenho que parabenizá-los pelo excelente trabalho feito.
Vale a pena dar uma olhada na apresentação de Glenn Vanderburg na última Lone Star Ruby Conference. Apesar do título provocativo, a palestra mostra uma visão bem prática sobre como métodos ágeis podem ser utilizados para produzir software com qualidade e sem estourar o orçamento. O vídeo da apresentação (em inglês) pode ser acessado clicando aqui.
O post abaixo, publicado no TechCrunch, explica parte de minha decisão em trocar o meu velho (e bom) HTC S621 por um Samsung Galaxy rodando Android. A lista de aplicações disponíveis no Android Market é imensa, e a maioria é gratuíta.
Consistent with its previous findings, Google’s Android Market has by far the largest share of free applications available compared to other mobile app store, but the gap is also widening.
In July 2010, 60% of all applications on Android Market were free of charge, representing an increase of 3% since May 2010 when it was 57%.
As you can tell from the graph below, that share is more than double the share of free apps on other mobile app stores, with the exception of Palm’s App Catalog (albeit barely).
The share of free applications is smallest on Windows Marketplace for Mobile (22%), followed by the Apple App Store for iPad (26%) and RIM’s BlackBerry App World (26%).
(click image for full size)
Let’s take a closer look at the prices of paid apps across mobile application stores.
Distimo posits that the average price of the 100 most popular apps in Android Market and Palm’s App Catalog is higher than the average price of the entire catalogue of applications.
While the average price of all applications is only 16% higher in the Apple App Store for iPad than in the App Store for iPhone, the average price of the 100 most popular applications is nearly three times as high in the former.
More than 60% of applications are priced below or equal to $2 in the App Store for iPhone, Android Market, Nokia’s Ovi Store and Palm’s App Catalog. The proportion of applications priced
below or equal to $2 is much lower in the App Store for iPad and Windows Marketplace for Mobile.
Notably, it seems prices of apps for iOS devices are on the rise. The proportion of paid applications priced below $1 on the Apple App Store for iPad and Apple App Store for iPhone has decreased in both in July 2010, from 30% to 25% and from 49% to 45%, respectively.
(click image for full size)
(click image for full size)
Para tentar tirar um pouco da poeira do blog, replico aqui o post de Matt Might sobre como manter uma atividade de escrita mesmo fazendo um PhD, trabalhando e cuidando da família.
“I don’t have time,” is the worst excuse not to blog.
Yet, I hear it often from fellow academics.
My advisor from grad school recently asked, “How can you write tons of papers and grant proposals, teach your classes, advise students, take care of your family and still have time to blog? Where does that time come from?”
Embedded in his question is an assumption that blogging has to take time.
Were this true, I couldn’t recommend it Ph.D. students or pre-tenure profs.
The secret to low-cost academic blogging is to make blogging a natural byproduct of all the things that academics already do.
- Doing an interesting lecture? Put your lecture notes in a blog post.
- Writing a detailed email reply? “Reply to public” with a blog post.
- Answering the same question a second time? Put it in a blog post.
- Writing interesting code? Comment a snippet into a post.
- Doing something geeky at home? Blog about what you learned.
I’ll save an argument for the benefits of academic blogging for another post. For now, I’ll argue that those benefits need not be high to overcome the cost.
Read below for my efficient blogging strategies.
Tip 1: Lecture as post
A favorite gripe of junior professors is that teaching is a waste of their time.
Excellence in teaching buys no credit for tenure at many universities.
(Of course, putrid teaching can derail a tenure case.)
Teaching is an opportunity to convert lecture notes into blog posts and external evangelism. The conversion usually polishes a lecture too.
It’s hard to teach a class without creating lecture notes.
Why not write those lecture notes as a blog post?
- First-class macros in meta-circular evaluators.
- A lambda-calculus interpreter in C++ templates.
- Compiling Scheme to C.
- Compiling Scheme to Java.
Tip 2: “Reply to public” as post
Many of the academics that “don’t have time to blog” seem to have plenty of time to write detailed, well-structured replies and flames over email.
Before pressing send, ask yourself, should this answer be, “Reply,” “Reply to all,” or “Reply to public”?
If you put effort into the reply, don’t waste it on a lucky few. Share it.
Of course, “reply to public” is not limited to email. A few of my recent posts started on Quora. If I still used Usenet, I bet the same would be true there.
- This post.
- 3 qualities of successful Ph.D. students.
- Greasemonkey scripts for Apply Yourself.
- Why guaranteed file compression is impossible.
Tip 3: Advice as post
I hear some questions with alarming repetition. To name a few:
- What is grad school like?
- How many years does a Ph.D. take?
- How can I get into grad school?
- How should I structure a thesis proposal?
Any question asked more than once is a candidate for a blog post.
- The illustrated guide to a Ph.D.
- HOWTO: Get into grad school.
- A thesis proposal is a contract.
- Productivity tips for academics.
Tip 4: Vented steam as post
My colleague, Suresh Venkatasubramanian, claims that the need to vent steam is his preferred reason for posting.
Blogs are a way to safely let it out, assuming appropriate diplomacy.
- The CRAPL: An academic-strength open-source license.
- American Airlines sucks.
- Why peer reviewers should use Tor.
Tip 5: Blog as code repository
I used to be great at starting coding projects, but terrible at finishing them.
That changed when I started posting code on my blog.
Posting my code on my blog forces me to do three things:
- It makes me refactor my code into a clean design.
- It makes me comment my code sufficiently.
- It makes me search for the most concise solution.
I’ve stopped rewriting code, because I reuse the code I post on my blog.
At the same time, I’ve picked up months-old projects and continued them.
Now when I write code, I look for ways to turn parts of it into a blog post.
- Matching regular expressions with derivatives.
- A nonblocking lexing toolkit based on derivatives.
- A pipelined nonblocking webserver in Scala.
- A reference implementation of k-CFA.
Tip 6: Blog as long-term memory
There are lots of things I used to know, but forgot.
When I find myself relearning something for the second time, I write a blog post on it, so that I won’t have to relearn it again.
I often write these up as a HOWTO.
- HOWTO: Make cat 5 network cables.
- HOWTO: Rip a DVD.
- HOWTO: Create an online book catalog.
- HOWTO: Fix mold and allergy problems.
A few more tips
I have a few miscellaneous tips for busy academic bloggers:
- Don’t blog before a deadline.
- Don’t post too frequently.
- Don’t feel pressure to post with regularity. Twitter and RSS can alert your readers.
- Don’t spend too much time on a post. It doesn’t have to be as polished as something you submit for peer review. I don’t even spell-check.
- Do store up posts if you have free time. Release when you’re busy.
- Don’t submit your own work to social news sites. If you write well enough, others will do it for you.
- Don’t feel the need to have comments. I get plenty of constructive, meaningful interaction with my readers over twitter and email.
Academic blogs I like
- Dave Herman’s The Little Calculist. I point this out to my students as a great example of grad student blogging as note-taking. (Dave recently finished his Ph.D., but he’s given this blog to himself and to the community forever.)
- John Regehr’s Embedded in Academia. John’s posts are much more polished than mine, and they’re entertaining, educational and thorough as a result. His posts are great outreach and service to the field. He nails the post-tenure associate professor blog perfectly.
- Suresh Venkatasubramanian’s geomblog. Suresh’s blog is a great mixture of field-specialist and pan-academic writing. There’s something worth knowing in every post.
- Daniel Lemire’s blog hits topics ranging from his own research interests to broader academic concerns. He thoughtfully compresses many of his posts into small, bite-sized form.
- Dick Lipton’s blog does a major service to theory of computation, because he spends time writing engaging, thoughtful and accessible articles. Dick does the esteemed yet friendly full professor blog well.
Após quase um mês de aulas no doutorado do CIN, percebi o quanto estou enferrujado em alguns princípios básicos de cálculo. Durante a minha graduação cursei 4 disciplinas de cálculo, 3 de álgebra e 1 de estatística. Mesmo assim, senti uma dificuldade enorme em acompanhar as primeiras aulas – em grande parte, pelo tempo que passou entre a graduação e o meu novo contato com o mundo dos números. Mas o principal motivo foi o simples fato que nunca precisei utilizar esses conhecimentos na minha carreira como analista de sistemas. Esse assunto veio à tona quando li o post de Alan Skorkin falando exatamente sobre os problemas que estou enfrentando agora. Vale a pena dar uma olhada.
You Don’t Need Math Skills To Be A Good Developer But You Do Need Them To Be A Great One
A little while ago I started thinking about math. You see, I’ve been writing software for quite a few years now and to be totally honest, I haven’t yet found a need for math in my work. There has been plenty of new stuff I’ve had to learn/master, languages, frameworks, tools, processes, communication skills and library upon library of stuff to do just about anything you can think of; math hasn’t been useful for any of it. Of course this is not surprising, the vast majority of the work I’ve been doing has been CRUD in one form or another, that’s the vast majority of the work most developers do in these interweb times of ours. You do consulting – you mostly build websites, you work for a large corporates – mostly build websites, you freelance – you mostly build websites. I am well aware that I am generalising quite a bit, but do bear with me, I am going somewhere.
Eventually you get a little tired of it, as I did. Don’t get me wrong it can be fun and challenging work, providing opportunities to solve problems and interact with interesting people – I am happy to do it during work hours. But the thought of building yet more websites in my personal time has somewhat lost its luster – you begin to look for something more interesting/cool/fun, as – once again – I did. Some people gravitate to front-end technologies and graphical things – visual feedback is seductive – I was not one of them (I love a nice front-end as much as the next guy, but it doesn’t really excite me), which is why, when I was confronted with some search-related problems I decided to dig a little further. And this brings me back to the start of this story because as soon as I grabbed the first metaphorical shovel-full of search, I ran smack-bang into some math and realized exactly just how far my skills have deteriorated. Unlike riding a bike – you certainly do forget (although I haven’t ridden a bike in years so maybe you forget that too ).
Learning a little bit about search exposed me to all sorts of interesting software-y and computer science-y related things/problems (machine learning, natural language processing, algorithm analysis etc.) and now everywhere I turn I see math and so feel my lack of skills all the more keenly. I’ve come to the realization that you need a decent level of math skill if you want to do cool and interesting things with computers. Here are some more in addition to the ones I already mentioned – cryptography, games AI, compression, genetic algorithms, 3d graphics etc. You need math to understand the theory behind these fields which you can then apply if you want to write those libraries and tools that I was talking about – rather than just use them (be a producer rather than just a consumer – to borrow an OS metaphor ). And even if you don’t want to write any libraries, it makes for a much more satisfying time building software, when you really understand what makes things tick, rather than just plugging them in and hoping they do whatever the hell they’re supposed to.
The majority of developers will tell you that they’ve never needed math for their work (like I did a couple of paragraphs above ), but after musing on it for a while, I had a though. What we might have here is a reverse Maslow’s hammer problem. You know the one – when you have a hammer, everything looks like a nail. It is a metaphor for using a favourite tool even when it may not be best for the job at hand. Math is our hammer in reverse. We know the hammer exists but don’t quite know how to use it, so even when we meet a problem where our hammer would be the perfect tool, we never give it serious consideration. The screwdriver was good enough for my granddaddy, it was good enough for my daddy and it is good enough for me, who needs a hammer anyway? The trick with math is – people are afraid of it – even most programmers, you’d think we wouldn’t be, but we are. So, we turn our words into a self-fulfilling prophecy. It’s not that I don’t need math for my work it’s just that I don’t really know it and even if I do, I don’t know how to apply it. So I get by without it and when you make-do without something for long enough, after a while you don’t even notice it’s missing and so need it even less – self-fulfilling prophecy.
Here is some food for thought about something close to all our hearts – learning new skills. As a developer in the corporate world, you strive to be a generalizing specialist (read this book if you don’t know what I am talking about). You try to be decent at most things and really good at some. But what do you specialize in? Normally people choose a framework or two and a programming language and go with that, which is fine and worthwhile. But consider the fact that frameworks and to a lesser extent languages have a limited shelf life. If you’re building a career on being a Hibernate, Rails or Struts expert (the struts guys should really be getting worried now ), you will have to rinse and repeat all over again in a few years when new frameworks come along to supersede the current flavour of the month. So is it really the best investment of your time – maybe, but then again maybe not. Math, on the other hand is not going away any time soon. Everything we do in our field is built upon solid mathematical principles at its root (algorithms and data structures being a case in point), so time spent keeping up your math skills is arguably never wasted. And it, once again, comes down to really understanding something rather than just using it by rote – math can help you understand everything you do more deeply, when it comes to computers. Infact, as Steve Yegge said, what we do as programmers is so much like math we don’t even realise it.
What/Who Makes A Difference
You don’t believe me, then consider this. Most of the people who are almost universally respected in our field as great programmers are also great mathematicians. I am talking people like Donald Knuth, Edsger W. Dijkstra, Noam Chomsky, Peter Norvig. But then again these guys weren’t really developers, they were computer scientists, so it doesn’t really count right? I guess, but then again, maybe we shouldn’t really talk until our output in pure lines of code even begins to approach 10% of what these people have produced. Of course, you can be successful and famous without being a boffin, everyone has heard of Gavin King or DHH. That’s kinda true (although it’s an arguable point whether or not many people have heard of Gavin or DHH outside their respective niches), but “heard of” and universally respected are different things, about as different as creating a framework and significantly advancing the sum-total of human knowledge in your field (don’t get me wrong, I respect Gavin And David, they’ve done a hell of a lot more than I have, but that doesn’t make what I said any less of a fact). How is all of this relevant? I dunno, it probably isn’t, but I thought I’d throw it in there anyway since we’re being introspective and all.
The world is getting filled up with data, there is more and more of it every day and whereas before we had the luxury of working with relatively small sets of it, these days the software we write must operate efficiently with enormous data sets. This is increasingly true even in the corporate world. What this means is that you will be less and less likely to be able to just “kick things off” to see how they run, because with the amount of data you’ll be dealing with it will just grind to a halt unless you’re smart about it. My prediction is that algorithm analysis will become increasingly important for the lay-programmer, not that it wasn’t before, but it will become more so. And what do you need to be a decent algorist – you guessed it, some math skills.
So, what about me? Well, I’ve decided to build up/revive my math skills a little bit at a time, there are still plenty of books to read and code to write, but I will try to devote a little bit of my time to math at least once in a while, because like exercise, a little bit once in a while, is better than nothing (to quote Steve Yegge yet again). Of course I have a bit of an ace up my sleeve when it comes to math, which is good for me, but luckily with this blog, we might all benefit (I know you’re curious, I’ll tell you about it soon ).
Where Do You See Yourself In 5 Years
So, is all this math gonna be good for anything? It’s hard to say in advance, I am pretty happy with where I am at right now and so might you be, but it’s all about potential. End of the day, if you’re a developer in the corporate world you don’t really need any math. If you’re happy to go your entire career doing enterprise CRUD apps during work hours and paragliding or wakeboarding (or whatever trendy ‘sport’ the geeky in-crowd is into these days) during your off time then by all means, invest some more time into Spring or Hibernate or Visual Studio or whatever. It will not really limit your potential in that particular niche; you can become extremely valuable – even sought after. But if you strive for diversity in your career and want to have the ability to try your hand at almost any activity that involves code, from information retrieval to Linux kernel hacking. In short if you want to be a perfect mix of developer, programmer and computer scientist, you have to make sure you math skills are up to scratch (and hell, you can still go wakeboarding if you really want ). Long story short, if you grok math, there are no doors that are closed to you in the software development field, if you don’t – it’s going to be all CRUD (pun intended)!
O Digg é mais um grande nome da Web 2.0 que acaba de migrar os seus (gigantescos) conjuntos de dados do mundo relacional para o modelo “pós-relacional”, esse último conhecido como NoSQL. Eles se juntaram à empresas como Google, Amazon, e-Bay, LinkedIn, Twitter e Facebook, com o objetivo de prover níveis de performance mais adequados para as consultas realizadas em bases de dados monstruosas, típicas de aplicações da Web 2.0. Para ter idéia do problema, imagine uma consulta na base de 2 PB (dois Petabytes) do e-Bay sendo feita online por um conjunto de centenas ou milhares de usuários simultaneamente. Imagine agora fazer um join com essa quantidade toda de linhas em tabelas de um banco relacional.
A estratégia do Digg está descrita em dois posts no blog do serviço. O primeiro fala sobre as dificuldades de escalabilidade da infraestrutura de banco de dados, baseada em uma solução mestre-escravo particionada um servidor MySQL. O texto mostra um exemplo de um a consulta com join que levava 14 segundos para ser completada. Após a migração para um datastore não-relacional, baseado no modelo distribuído do Cassandra, a mesma consulta pôde ser realizada em menos de um segundo. O segundo texto fala sobre a migração completa dos principais serviços do Digg usando o Cassandra e ainda lista as principais contribuições da equipe de desenvolvimento para o projeto.