Completa o roteiro

diff --git a/TODO.rst b/TODO.rst
deleted file mode 100644 (file)
index 6e09206..0000000
--- a/TODO.rst
+++ /dev/null
@@ -1,6 +0,0 @@
-TODO
-====
-
-- Completar roteiro de aulas.
-- Gravar screencasts.
-- Revisar conteúdo.

diff --git a/aulas/ambientes.rst b/aulas/ambientes.rst
index a1c2760e6bfb841a25d1fe75f09d8f61b7eeb1c2..49b9b40cc8d5b947c5b3fb94b05b3b2b31cdaed2 100644 (file)
--- a/aulas/ambientes.rst
+++ b/aulas/ambientes.rst
@@ -259,8 +259,8 @@ Roteiro do screencast:
 
 #. Crie a estrutura básica do seu projeto.
 
-2.5 Referências
----------------
+2.5 - Referências
+-----------------
 
 - `Guia Foca Linux <http://www.guiafoca.org/>`_.
 - `Solarized - Ethan Schoonover <http://ethanschoonover.com/solarized>`_.

diff --git a/aulas/devops.rst b/aulas/devops.rst
index 9f03acc3dfc56104473ef5e62650eddcdb4eac53..8605666ee73635ad75dc77956ef336709eec83cb 100644 (file)
--- a/aulas/devops.rst
+++ b/aulas/devops.rst
@@ -12,8 +12,8 @@ Imagens:
 
 * https://upload.wikimedia.org/wikipedia/commons/b/b5/Devops.svg
 
-5.2 Ambientes reprodutíveis
----------------------------
+5.2 - Ambientes reprodutíveis
+-----------------------------
 
 5.2 - Ambientes
 ~~~~~~~~~~~~~~~
@@ -104,8 +104,8 @@ Roteiro do screencast:
 * Mostrar softwares e serviços de integração contínua.
 * Criar um protótipo local e simples de teste e integração contínua.
 
-5.7 Atividades
---------------
+5.7 - Atividades
+----------------
 
 #. Crie um ambiente de desenvolvimento vagrant para o seu projeto.
 #. Experimente o PuPHPet para gerar uma configuração mais complexa de ambiente virtual de desenvolvimento.

diff --git a/aulas/metodologias.rst b/aulas/metodologias.rst
index 3848275465ff563317aa0d11d0994540983a8ecc..98f7a15519c241bd0b04f5f1ef681269750fdec1 100644 (file)
--- a/aulas/metodologias.rst
+++ b/aulas/metodologias.rst
@@ -185,8 +185,8 @@ Imagens:
 
 #. Bônus: esboce um documento simples de escopo para o seu projeto. Ele pode ser um importante guia nas fases iniciais.
 
-1.9 Referências
----------------
+1.9 - Referências
+-----------------
 
 - `Best coding practices - Wikipedia, the free encyclopedia <https://en.wikipedia.org/wiki/Best_coding_practices>`_.
 - `Best practices for software development projects <http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html>`_.

diff --git a/aulas/reinventando.rst b/aulas/reinventando.rst
index 089bb83ce1cdb50143b21cda72629fab7642f9a4..af8e3fb3bb8ee1f30e087ef370902432cc7a50bf 100644 (file)
--- a/aulas/reinventando.rst
+++ b/aulas/reinventando.rst
@@ -4,52 +4,72 @@
 7.1 - Patterns
 --------------
 
-* TDD.
-* Separando código de dados, sobretudo dados sigilosos!
-* Desacoplamento.
-* Filosofia UNIX:
-  * Pequenos softwares/bibliotecas.
-  * Que fazem uma coisa bem.
+7.1 - O que são e por quê usar?
+-------------------------------
+
+* Design Patterns são "formas" de desenvolvimento reutilizáveis e consideradas como boas práticas.
+* A lista de patterns conhecidos é long demais para este curso
+* Daremos alguns exemplos ilustrativos que atendem o nosso critério de simplicidade.
+* São recomendações! Mais importante que usá-las é ter capacidade crítica para determinar quais fazem ou não sentido para o seu projeto.
+
+7.2 - Exemplos
+--------------
+
+Daremos breves exemplos em três campos:
+
+* Design: separação de código de dados, sobretudo dados sigilosos!
+* Metodologia : DDD e TDD: documentar e testar antes, durante ou depois?
+* Implementação: Filosofia UNIX:
+  * Pequenos softwares e bibliotecas (desacoplamento).
+  * Que fazem bem uma coisa.
   * E que podem ser facilmente combinados.
 
-7.2 - Antipatterns
-------------------
+7.2 - Anti-patterns
+-------------------
+
+São o oposto das design patterns: formas de desenvolvimento não recomendadas. Exemplos:
 
+* O mito da pessoa-mês (Lei de Brooks).
 * Hype: cuidado com o ciclo dos modismos!
-* Linearidade: o mito da pessoa-mês (Lei de Brooks).
 * Inferno de dependências.
 * Bitrot: decaimento natural do código!
 
-7.3 - Inventando, reinventando e desinventando
-----------------------------------------------
+7.3 - Documentação: lendo e escrevendo
+--------------------------------------
 
-Hora de converter nosso projeto blogático para uma plataforma com mais funcionalidades!
+* Documente não só para os outros, mas para você mesmo(a) no futuro.
+* Quanto mais próxima a documentação está do código, mais difícil dela se desatualizar.
+* Docblocks / heredocs: podem ser convertidos em documentação indexada, referenciada e navegável.
+* Documente procedimentos enquanto você os realiza.
 
 Roteiro do screencast:
 
-::
+* Concluindo a documentação do blogático, fazendo um commit e um release tag.
 
-  cd ~/projetos/blogatico
-  cp -r ../boaspraticas/_templates/ikiwiki/* .
-  make
+7.4 - Inventando, reinventando e desinventando
+----------------------------------------------
 
-7.4 - Documentação: lendo e escrevendo
---------------------------------------
+* Caso tenha acompanhado este curso desde o começo e construiu nosso projeto/invento "blogático" desde o ínicio, agora você tem um software para documentar seu aprendizado em desenvolvimento. Acontece que ele é bem simples. E se você quiser algo mais completo e que seja uma solução pronta, já disponível?
 
-* Quanto mais próxima a documentação está do código, mais difícil dela se desatualizar.
-* Docblocs / heredocs.
-* Documente procedimentos enquanto você os realiza.
+* Agora é hora de converter nosso projeto blogático para uma plataforma com mais funcionalidades!
 
 Roteiro do screencast:
 
 ::
 
-  sudo apt-get install ttyrec
+  cd ~/projetos/blogatico
+  cp -r ../boaspraticas/_templates/ikiwiki/* .
+  make
 
 7.5 - Atividades
 ----------------
 
+#. Consulte as referências por diversos design patterns e antipatterns. Quais patterns você acha mais interessantes? Quais antipatterns são mais perigosos?
+#. Crie a documentação do seu projeto. Pense que ela será lida por uma audiência bem geral que nunca ouviu falar do projeto e será determinante para que decidam se irão usá-lo ou não.
+
 7.6 - Referências
 -----------------
 
 * `Versionamento Semântico 2.0.0 <http://semver.org/lang/pt-BR/>`_.
+* `On Documentation-Driven Development // Collective Idea | Crafting web and mobile software based in Holland, Michigan <http://collectiveidea.com/blog/archives/2014/04/21/on-documentation-driven-development/>`_.
+* `Readme Driven Development <http://tom.preston-werner.com/2010/08/23/readme-driven-development.html>`_.

diff --git a/aulas/seguranca.rst b/aulas/seguranca.rst
index aae2b361fb97dcab6bfec27c2e55c11f245a88bb..2915480f87e0858a8430b22743c2e7099f182f2f 100644 (file)
--- a/aulas/seguranca.rst
+++ b/aulas/seguranca.rst
@@ -1,27 +1,35 @@
 6. Segurança e privacidade
 ==========================
 
-6.1 - Segurança começa no desenvolvimento
+6.1 - Segurança da informação
+-----------------------------
+
+* Confidencialidade.
+* Integridade.
+* Disponibilidade.
+* Autenticidade.
+
+6.2 - Segurança começa no desenvolvimento
 -----------------------------------------
 
+* Segurança: para fins do nosso curso, é a proteção da aplicação.
+* Privacidade: proteção dos dados em poder da aplicação.
 * Criptografia é só uma parte das práticas seguras.
-* Modelagem de ameaças e testes de penetração: inverta os papéis: e se você fosse o/a atacante?
-* A dificuldade de se encontrar vulnerabilidades.
-* Segurança por isolamento ajuda, mas botar a aplicação dentro de um cordão sanitário protege mais o ambiente de hospedagem do que a aplicação.
+* Obscuridade não é segurança: disclosures são saudáveis no desenvolvimento.
 
-6.2 - Use bibliotecas criptográficas consolidadas!
---------------------------------------------------
+6.3 - Modelagem de ameaças e auditoria
+--------------------------------------
 
-* Erros de implementação são grandes fontes de brechas de segurança.
-* Caso você precise implementar primitivas criptográficas no seu código, use bibliotecas existentes!
-* Encapsule as conexões das suas aplicações em canais criptografados.
-* TLS é o protocolo mais consolidado e adequado, apesar de não ser perfeito.
+* É fácil (e barato) produzir e difícil (e caro) encontrar vulnerabilidades.
+* Modelagem de ameaças (teoria) e testes de penetração (prática): inverta os papéis: e se você fosse o/a atacante?
+* Segurança por isolamento ajuda, mas botar a aplicação dentro de um cordão sanitário protege mais o ambiente de hospedagem do que a aplicação.
 
-6.3 - Princípio das permissões mínimas
---------------------------------------
+6.4 - Exemplo e ameaça e o princípio das permissões mínimas
+-----------------------------------------------------------
 
-* Comece o desenvolvimento com o mínimo de permissões necessárias para a sua aplicação e libere o acesso conforme necessário.
-* Permissões de arquivos são propriedades no sistema de arquivo!
+* Exemplo de ameaça: o(a) atacante tem permissão de escrita no código da aplicação.
+* Mitigação: forneça o mínimo de permissões necessárias para a sua aplicação e libere o acesso conforme necessário.
+* Atenção! Permissões de arquivos são propriedades no sistema de arquivo!
 * Elas não são necessariamente preservadas com a cópia de arquivos entre sistemas!
 
 Roteiro do screencast:
@@ -39,20 +47,51 @@ Roteiro do screencast:
   # Mudando a posse de arquivos e pastas
   chown
 
-6.4 - Criptografia básica
+6.5 - Criptografia básica
 -------------------------
 
-* Assinaturas digitais.
-* Comunicação cifrada.
-* Checagem de integridade de código no git e em geral.
+* Criptografia não é tudo em segurança, porém é o requisito básico e essencial.
+* Ameaça: machine-in-the-middle.
+* Mitigação:
+  * Comunicação cifrada: HTTPS.
+  * Checagem de integridade de código no git e em geral (assinaturas e checksums).
 
-6.5 - Certificados x509 para SSL/TLS/HTTPS
-------------------------------------------
+6.6 - Use bibliotecas criptográficas consolidadas!
+--------------------------------------------------
 
-* `Let's Encrypt <https://letsencrypt.org>`_.
+* Erros de implementação são grandes fontes de brechas de segurança.
+* Caso você precise implementar primitivas criptográficas no seu código, use bibliotecas existentes!
+* Encapsule as conexões das suas aplicações em canais criptografados.
+* TLS é o protocolo mais consolidado e adequado, apesar de não ser perfeito.
+
+6.7 - HTTPS
+-----------
+
+6.7 - O que é
+~~~~~~~~~~~~~
 
-6.6 - Atividades
+* HTTPS: HTTP em cima de uma conexão SSL/TLS.
+* Padrão dos anos 90 e melhorado desde então.
+* Bem implementado: oferece segurança da informação num nível aceitável, porém não oferece anonimato.
+* Mal implementado: só oferece ilusão de segurança.
+* Movimento crescente para tornar HTTPS padrão em todos os sites!
+
+6.7 - Certificados para HTTPS
+-----------------------------
+
+* No HTTPS, a autenticidade é obtida usando uma "cadeia de certificação" provida por autoridades certificadoras.
+* Checagem feita no navegador.
+* É um esquema altamente vulnerável: a qualquer momento o castelo de cartas pode ruir.
+* As alternativas a esse modelo ainda são incipientes.
+
+6.8 - Atividades
 ----------------
 
-6.7 - Referências
+#. Faça um pequeno documento de modelagem de ameaças para o seu projeto. Coloque-o na forma de "ameaça/mitigação". Organize cada par ameaça/mitigação segundo probabilidade decrescente de ocorrência e custo crescente de implementação, facilitando a implementação de cada medida de segurança.
+#. Desafio: caso seu projeto seja uma aplicação web, obtenha um certificado e configure uma conexão HTTPS.
+
+6.9 - Referências
 -----------------
+
+* `Let's Encrypt <https://letsencrypt.org>`_.
+* `Segurança da informação – Wikipédia, a enciclopédia livre <https://pt.wikipedia.org/wiki/Seguran%C3%A7a_da_informa%C3%A7%C3%A3o>`_.