Nessa apresentação, Caio tentará passar um pouco do seu conhecimento adquirido em sua carreira. Interagir com diferentes profissionais, participar de diferentes projetos e também mesclando a vida pessoal e profissional, aprendeu uma perspectiva diferente do que é ser desenvolvedor Front-End e o conhecimento necessário para tal.

1. Vamos lá.
Mapa de aprendizado Front-End.
13.02.2019

2. 🙏🙌

3. Um pouco sobre mim.

4. http://ameliabusinessdirectory.com

5. http://ameliabusinessdirectory.com

9. http://ameliabusinessdirectory.com

10. http://ameliabusinessdirectory.com

14. Knowledge Share.

15. Knowledge Share.
● Pessoas com diferentes experiências.
● Nivelar e treinar equipe.
● Formatos e horários.
● Apoio da empresa.
● Dever de casa no github.
● Livre x guiado.

16. O objetivo desta palestra não é tentar explicar tudo,
mas ser uma inspiração para que você pesquise e
se aprofunde nos pontos que quiser.

19. Mapa de aprendizado Front-End.

20. 12 seções.
● Computador e Programação.
● Internet e Network.
● Requests e Servidores.
● Browser, HTML, CSS e Javascript.
● Fluxo de renderização.
● Performance.

21. Quando se aprende algo, uma das
melhores coisas é conectar esse
conhecimento com o que já está
estabelecido em você.

22. Às vezes, como programadores
Front-End, ficamos isolados em nosso
conhecimento, sem conectar e dialogar
com pessoas de outros ramos.

24. Conectar o Front-End com a vida em
geral e com as outras partes técnicas.

25. Front-End e a vida lá fora.

30. Introdução ao mapa.

33. Um possível caminho até o front-end developer.
1. Programador.
2. Webmaster.
3. Back-end e DBA.
4. Infraestrutura, DBA, back-end e front-end.

34. Agora temos dois conceitos mais ou
menos definidos, computador e
front end developer.

36. Aparelhos • IHC • Navegador • APIs • FE

38. 12 seções.
● Computador e Programação.
● Internet e Network.
● Requests e Servidores.
● Browser, HTML, CSS e Javascript.
● Fluxo de renderização.
● Performance.

42. caiovaccaro.com.br/TechDomain.html

45. Computador e Programação.

47. Computador e Programação.
● Entender o básico.
● Processador, threads.
● Concorrência e paralelismo.
● Memória, estrutura de dados e algoritmos.
● GPU, animações e CSS.
● HD x RAM.
● Compilação.

48. https://en.wikipedia.org/wiki/Thread_(computing)

49. https://en.wikipedia.org/wiki/Pointer_(computer_programming)

50. Rodger Anderson - https://slideplayer.com/slide/4394682/

51. http://cs-study.blogspot.com/2012/11/complete-binary-tree.htm

52. Computador e Programação.
● Entender o básico.
● Processador, threads.
● Concorrência e paralelismo.
● Memória, estrutura de dados e algoritmos.
● GPU, animações e CSS.
● HD x RAM.
● Compilação.

53. Ahmet Cengizhan Dirican and Mehmet Gokturk
https://www.intechopen.com/books/human-computer-interaction/attentive-computing

54. Linguagens de Programação.
● Matemático, Funcional.
● Enterprise, Orientação a objeto.
● Interface gráfica, MVC.

55. No funcional o programa é mais
um fluxo de dados em transformação,
sem muita mutabilidade ou
instruções imperativas.

56. Orientação a objeto, é encapsular as
responsabilidades e imperativamente
instruir as partes a executar
seus métodos.

57. No MVC, separamos dados, lógica e
apresentação em diferentes camadas
com regras específicas.

58. Conceitos básicos.
● Estrutura de dados e algoritmos.
● Garbage collection.
● Código bloqueante e não bloqueante.
● Síncrono e asíncrono.

59. Estrutura de dados e algoritmos são
formas de organizar ou manipular dados
na memória, com diferentes benefícios
para cada caso.

60. Garbage collection é o processo
automático ou manual de limpar
memória que não é mais necessária
no programa.

61. Código bloqueante e não bloqueante, a
main thread do programa executa 1
instrução por vez e aguarda o seu
resultado ou não.

62. Conceitos mais complexos.
● Como funciona um Virtual DOM.
● Por que imutabilidade é muito inteligente.
● Como WebAssembly é super rápido.

63. Internet e Network.

65. https://www.pccwglobal.com

66. Saber um pouco de internet e network
ajuda na hora de debugar problemas de
performance. Muita coisa acontece
antes da renderização do seu código
começar no navegador.

67. Também te ajuda a não ficar refém dos
outros. Como o front-end é o último
profissional na “linha de produção”,
sempre tem gente que tenta empurrar
problemas pro front.

68. Internet e Network.
● ISPs.
● Cliente x Servidor.
● IPs.
● DNS.
● Request x response.

69. Requests e Servidores.

71. Requests e Servidores.
● URLs.
● Protocolos.
● APIs.
● Tipos.
● Servidor e nuvem.
● Linguagens de back-end.

72. https://doepud.co.uk/blog/anatomy-of-a-url

73. RPC possibilita mais de um recurso ou
entidade por chamada. Por um lado é
ruim para cache e acoplado, mas por
outro é uma chamada por view e com
respostas pequenas.

74. example.com/list?offset=0&size=5

75. REST tem um endpoint por entidade,
mas apesar de ser bom para cache e
desacoplado, exige muitas chamadas
por view e com respostas grandes.

76. example.com/list/1234
example.com/user/3

77. A API se correlaciona muito com o
modelo de dados e de negócio do seu
projeto, e se não for bem feita
provavelmente o código será confuso,
com débito técnico e refação.

78. Requests e Servidores.
● URLs.
● Protocolos.
● APIs.
● Tipos.
● Servidor e nuvem.
● Linguagens de back-end.

81. Browser, HTML, CSS e Javascript.

83. Browser, HTML, CSS e Javascript.
● Device.
● Sistema operacional.
● Browser.

85. Browser, HTML, CSS e Javascript.
● Casca, UI.
● Engine interna.
● Engine de renderização.
● Networking.
● UI Backend.
● Interpretador de Javascript.
● Armazenamento de dados.

86. https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

87. Fluxo de renderização.

88. O DOM nada mais é que um conjunto de
classes e objetos, com propriedades e
métodos. A especificação vive no W3C,
com types, interfaces e regras.

89. Fluxo de renderização.
● Engines.
● Parsing.
● DOM tree.
● Layout tree.
● Paint.

90. https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

91. Fluxo de renderização.
● Box model.
● Posicionamento.
● Layers.
● Boas práticas de como escrever HTML e CSS.

92. E o meu framework javascript?
Colabora com a equipe, manutenção e
boas práticas. Tecnicamente não é
estritamente necessário.

95. https://codeburst.io/the-2018-web-developer-roadmap-826b1b806e8d

96. https://frontendmasters.com/books/front-end-handbook/2018/tools.html

98. Performance.

99. Performance.
● Entender o seu projeto.
● Conhecer o que acontece antes da renderização no browser.
● Isolar os problemas.

100. Primeiro é importante estabelecer uma
meta, dependendo do seu projeto e dos
usuários, estabelecer um performance
budget, um orçamento.

101. Pode ser bem simples como o tempo
máximo de carregar uma página ou o
tempo de animações, de interações,
feedback e carregar páginas.

102. https://developers.google.com/web/fundamentals/performance/rail

104. Performance.
● Backend, cache, API.
● Mínimo de informação que você precisa.
● Assets.
● CDN.
● Lazy loading, async e defer.
● Critical rendering path.
● Fontes.

105. Por último você investe tempo em
otimizar o uso de memória no javascript.
É a última coisa que vai impactar o
usuário, a não ser que tenha um memory
leak gigante.

106. Para investigar você usa o developer
tools e usa a aplicação, debugando o
uso de memória nas suas funções e
testando se tem formas mais eficientes
de escrever o código.

107. Conclusão.

108. De baixo para cima,
ou de cima para baixo?

109. Algumas coisas que acredito.
● Não troque seu caráter por dinheiro.
● Trabalho remoto.
● “Don't stay safe. Stay free.”
● Tecnologia não é neutra, seja consciente.

110. Obrigado .
caiovaccaro.com.br