Sent this to the [CouchDB users list][email] just now; duplicated here for others to see or comment
Hi, all. Sorry to be distant from the community recently. No excuse.
I thought I might share December stats from one of Apache CouchDB's most well-known deployments and killer apps: the Node.js npm registry.
Hoje um colaborador da lista sobre Teste de Software [DFTestes] (http://br.groups.yahoo.com/group/DFTestes/) perguntou em uma thread sobre PhantomJS qual era a difernça entre Smoke Test e Acceptance Test. Ai resolvi responder. Como a lista é somente de acesso aos usuários registrados, estou colocando um resumo, na minha ótica, a diferença entre eles:
Dentro de um contexto ágil nós temos uma separação clara do que é smoke test e o que é teste de aceitação.
Smoke Test: conjunto de testes (bem menor do que o conjunto de teste de aceitaçaõ, que vai configurar posteriormente em uma regressão) com o intuito de validar se os pontos maisimportantes da aplicação continuam funcionando após as alterações.
Teste de Aceitação: São os testes funcionais que conhecemos. Em um contexto ágil eles são chamados de aceitação ao invés de funcional, pela ótica que adotamos a estes testes, que vão tanto validar a aplicação funcionalmente como validar também da ótica de um usuário (fazer uma venda completa, por exemplo). Este
Attention: the list was moved to https://github.com/vitorbritto/dev-list
This page is not maintained anymore, please update your bookmarks.
Recently, I decided to organize my bookmarks. So, like a good fellow, I am sharing with you. I hope you enjoy!
This is a curated set of conventions and best practices for Stylus, an expressive, dynamic, robust and advanced CSS preprocessor. Frustrated with there not being a set of conventions set in place (that could be easily found), I set forth to find out on my own.
| function toJSON(node) { | |
| let propFix = { for: 'htmlFor', class: 'className' }; | |
| let specialGetters = { | |
| style: (node) => node.style.cssText, | |
| }; | |
| let attrDefaultValues = { style: '' }; | |
| let obj = { | |
| nodeType: node.nodeType, | |
| }; | |
| if (node.tagName) { |
#Composition is the Goal
I see several discussions now that vacillate around on encapsulation qualities of Shadow DOM and the flavors thereof. It's all my fault. I stuck encapsulation into the problem statement of the spec. I even glued the somewhat irrelevant term functional encapsulation on top of it. What a dork.
It was a couple of years ago, when one of my colleagues read the spec and noted: "Dude, it's like your story and whatever, but the way you tell it, Shadow DOM is not about encapsulation. It's about composition". The world went blank around me. I was blinded by insight.
My hipster colleague was right, of course. Encapsulation is just a tool. Composition is the goal.
This is why the people who'd never used Shadow DOM in real life get really hung up on the details of encapsulation, while those who actually use Shadow DOM stare at them quizzically.
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com, example2.com, and example1.com/images on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
| $ ffmpeg -i input.mp4 -vcodec h264 -acodec mp2 output.mp4 |