Bruno Tavares bltavares

Ember Glimmer está em desenvolvimento a muito tempo, e tem vários reports e apresentações Exemplo bem interessante de como uma mudança “boring” (engine de renderização), quando bem anunciada, pode engajar a comunidade. As pessoas ficam interessadas em mudanças, principalmente melhorias, e quem está fazendo fica motivada de entregar as melhorias pra muitas pessoas engajadas Exemplo: ganhos de velocidade com frequencia de release, sneak peak de mudanças no processo de entrega do app que vão dar mais PRs no mesmo tempo, anuncion de otimizações de processamento que ainda serão lançados… https://blog.emberjs.com/2017/04/05/emberconf-2017-state-of-the-union.html#toc_introducing-glimmer-js https://blog.emberjs.com/2017/10/10/glimmer-progress-report.html

Rust Keynote fantástica https://www.youtube.com/watch?v=J9OFQm8Qf1I Esssa outra também é legal, é a keynote do ano seguinte: https://www.youtube.com/watch?v=FSrQX4uYuOM

Lugar:

Data:

Endereco:

Empresa/Nome do contato:

Preparacao

Escolher e combinar lugar - Geralmente 50 - 60 pessoas, mas aparecem umas 20

https://www.youtube.com/watch?v=p7nGcY73epw O material deles eh bem legal, tem essa em especifico introduzindo o conceito de abstracao em computacao
https://www.youtube.com/watch?v=x9pxbnFC4aQ Apresentacoes sobre abstraction, sem muita coisa de programacao especifica, mas bem densa
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
Material do Bret Victor - Recomendo muito esse autor, tem varias apresentacoes legais sobre computacao e aprendizagem:
- http://worrydream.com/dbx/ (Historia dos computadores e abstracoes criadas)
http://worrydream.com/LearnableProgramming/

Proposal for more tooling to allow for custom testing harness:

Initial - rust-lang/rfcs#816
Extension to RFC - rust-lang/rfcs#2318

Newest coolest tools

Ei pessoal, queria trazer uma outra idea que eu acompanho faz bastante tempo de organização e arquitetura, já que vocês estão mechendo nisso.

Eu acompanho o pessoal do Elm faz um tempo, e acho que eles tem uma perspectiva interessante, apesar de descordar com alguns pontos. A proposta de do [Elm Architecture] é bem simples na idea que funções alteram estados e views refletem o estado. Eu vejo como uma maneira bem similar a idea de separar o comportamento que os HOCs trouxeram, mas com menos libs.

O pessoal tem uma proposta um jeito bem diferente de pensar, de [limitar fazer components reusáveis], trabalhar com funções e modelos fortes, crescer o app sem se preocupar muito com a separação.

Não é um problema de arquitetura bem resolvido, tem várias pessoas, [fora do core](https://med

	#!/bin/sh
	#_(
	DEPS='
	{:deps {seesaw {:mvn/version "1.5.0"}}}
	'
	exec clojure -Sdeps "$DEPS" "$0" "$@"
	)

	(ns cockpit.core
	(:require [seesaw.core :as ss]

	github.com/hashicorp/terraform
	├ bytes
	├ fmt
	├ io
	├ io/ioutil
	├ log
	├ os
	├ os/signal
	├ path/filepath
	├ runtime


	workflow "automated on PRs" {
	on = "push"
	resolves = ["cljfmt"]
	}

	action "cljfmt" {
	uses = "bltavares/actions/[email protected]"
	args = ["autofix"]
	secrets = ["GITHUB_TOKEN"]

	(ns playground.core
	(:gen-class))

	(defn -main
	"I don't do a whole lot ... yet."
	[& args]
	(println "Hello, World!"))

	(defprotocol Componente
	(start! [component])