diegoeis

Data-binding [R]evolution

Leo Balter

BrazilJS 2014

• Data Binding é o processo que estabelece uma conexão entre a interface aplicação e o lógica de negócio
• Com o ES5, já tínhamos alguns métodos fazem com que comecemos a manipular propriedades de objetos e como lidamos com essas propriedades.
• Com o ES6 e ES7 teremos coisas mais interessantes, solucionando mais problemas.
• Os frameworks para data binding estão vindo: polymer, ember.js, react, Angular.JS, Backbone.js, way.js etc.
• O Way é um experimento lançado em pouco tempo, de uma forma de integrar sua interface com seus objeto.
• Data Binding quebra um pouco a linha de programação funcional.

juanplopes

Texto criado pelo amigo Carlos Krämer (github . twitter . facebook) lá no Facebook, reproduzido aqui com a permissão dele.

Jornalista: Candidato, é pavê ou pra comê?

Dilma: Veja bem, nunca foi tanto pra comê quanto no meu governo. Há um ditado.... eu digo, editaram quando eu era o cachorro atrás de uma criança ... que diz que todo mundo que insere, ou melhor, ingere o que é pavê, tem uma satisfação imensa de... como dizem... dobrar a esquina. Mas nós precisamos continuar mudando, meu governo foi ótimo, eu fui eleita para dar prosseguimento ao governo Lula, Lula, LULA. Mas ninguém está mais insatisfeita com ele, digo, com o governo, não com o Lula, do que eu, mas os pessimistas é que estão tornando tudo ruim.

Marina: Eu não acho que é pavê nem pra comê. Nós precisamos aprender a reunir o que é bom em tudo, as melhores

dukex

String.prototype.reverse = function(){	
  return this.split("").reverse().join("");
}

RamonPage

function supports_input_placeholder() {
  var input = document.createElement('input');
  return 'placeholder' in input;
}

hltbra

Slides usados na SCTI 2011:

http://www.slideshare.net/hugobr/quero-serprogramadorcomofas


Eu separei alguns links que eu acho interessante pra quem estava na palestra.
Alguns estão nas referências dos slides, outros não:


* Teach Yourself Programming in Ten Years

porcelli

Intro

Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero... pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.

Com isso dito, vamos lá:

TDD (Test-driven development)

Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste...) em pequenos ciclos.

Meu ponto de vista:

rwaldron

<pre>
# Just Markdown, Yo.

So, I wanted to try to write the simplest webpage possible, [Max Ogden][1]
style. If you have JavaScript, you get something pretty. If not, then you see
[Markdown][2] text, which is fine too.

[1]: http://maxogden.com
[2]: http://daringfireball.net/projects/markdown/
</pre>

rwaldron

(function( exports ) {

  function EventEmitter() {}

  EventEmitter.prototype.emit = function() {
    var type, handlers, args, listeners;

    type = arguments[0];
    args = [].slice.call( arguments, 1 );

davidsonfellipe

#CSS FTW My way to face the challenge: Maintainable + Efficient + Optimized

##General

• YSlow + Page Speed (Performance Rules)…
• CSSLint Rules…
• Don’t use too many web fonts talk to your designer, and explain the impact of loading many sources.

##Tools

mikeal

Children are created, raised, cared for and we hope that they will live a long and proud life only to end long after their creator's has ended. They are their creator's legacy.

Your code is not your child, it is an animal raised for slaughter. Your code will die. It will die before your death. Your code's entire purpose is to die. Your code enables some new function and if successful that new function will grow, it will mature, it will eventually outlive the usefullness you've provided. When successful your code creates value that outlives it and the faster the better. When unsuccessful a mercy killing is most appropriate.

Believing that our code is our children makes us territorial, protective. Nobody is allowed to kill it, only improve it. The idea that our code can be perfect, that it can change to handle so many new concerns leads to the birth of frameworks and plugin systems. These systems brutalize creativity by forcing new value to conform to the standards of our aging children.