Gabriel de Oliveira Barbosa manobi
| 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) { |
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.
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!
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
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.
- Zero downtime
(tl;dr DOM builders like [domo][domo] trump HTML templates on the client.)
Like all web developers, I've used a lot of template engines. Like most, I've also written a few of them, some of which even [fit in a tweet][140].
The first open-source code I ever wrote was also one of the the first template engines for node.js, [a port][node-tmpl] of the mother of all JavaScript template engines, [John Resig][jresig]'s [micro-templates][tmpl]. Of course, these days you can't swing a dead cat without hitting a template engine; one in eight packages on npm ([2,220][npm templates] of 16,226 as of 10/19) involve templates.
John's implementation has since evolved and [lives on in Underscore.js][underscore], which means it's the default choice for templating in Backbone.js. And for a while, it's all I would ever use when building a client-side app.
But I can't really see the value in client-side HTML templates anymore.
| /* | |
| Escape JSON | |
| */ | |
| var escapeJSON = exports.escapeJSON = function(json) { | |
| var escapable = /[\\\"\x00-\x1f\x7f-\x9f\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-\u206f\ufeff\ufff0-\uffff]/g; | |
| var meta = { // table of character substitutions | |
| '\b': '\\b', | |
| '\t': '\\t', | |
| '\n': '\\n', | |
| '\f': '\\f', |
Hi. My name is Sadayuki "Sada" Furuhashi. I am the author of the MessagePack serialization format as well as its implementation in C/C++/Ruby.
Recently, MessagePack made it to the front page of Hacker News with this blog entry by Olaf, the creator of the Facebook game ZeroPilot. In the comment thread, there were several criticisms for the blog post as well as MessagePack itself, and I thought this was a good opportunity for me to address the questions and share my thoughts.
To the best of my understanding, roughly speaking, the criticisms fell into the following two categories.
| A list of features that we want to see in CouchDB. Needs to be voted on so that it can become a priority queue. | |
| User Facing Features | |
| ==================== | |
| 1. Conflicts are the rule, not the exception | |
| All previous versions of CouchDB hide conflicts by default (selecting | |
| an arbitrary but consistent winning revision). Expert users can find | |
| and resolve conflicts. |