- Dependency Injection and the Art of Services and Containers - KnpUniversity (course)
- Journey to the Center of Symfony: The Dependency Injection Container - KnpUniversity (course)
- Dependency Injection - Anthony Ferrara (video)
- Entenda de uma vez por todas o Container do Laravel - Ravan Scafi (video)
- Entenda de uma vez por todas o Container do Laravel - Ravan Scafi (slides)
- Dependency Injection - Guilherme Blanco (slides)
- PSR-11 - Container
- PSR-11 - Container Meta
- A ocorrência de bugs no código não são legais e a necessidade de correções em produção menos ainda.
- É recomendável programar de forma profissional utilizando testes.
- É importante escrever código cuidadosamente projetado e que seja possível adicionar novas funcionalidades com confiança.
- A ferramenta padrão de facto para testes em PHP é o PHPUnit.
- Getting Started with Headless Chrome
- The power of Headless Chrome and browser automation (Google I/O '18) (►)
- Headless Chrome and browser automation with Eric Bidelman (►)
- Web Scraping with Puppeteer, NodeJS and Shopify (►)
- Chrome 59: Headless Chrome, Native Notifications on macOS and the Image Capture API (►)
- Chrome Puppeteer talk at JSMontreal (►)
- Lighthouse, Headless Chrome, and Puppeteer (GDD India '17) (►)
- Distributed crawler powered by Headless Chrome (★)
CORS (cross origin resource sharing) is a mechanism to allow client web applications make HTTP requests to other domains. For example if you load a site from http://domainA.com and want to make a request (via xhr or img src, etc) to http://domainB.com without using CORS your web browser will try to protect you by blocking the response from the other server. This is because browsers restrict responses coming from other domains via the Same-Origin-Policy.
CORS allows the browser to use reponses from other domains. This is done by including a Access-Control
headers in the server responses telling the browser that requests it is making is OK and safe to use the response.
Header | Description |
---|---|
Access-Control-Allow-Origin: |
Allow requests from `` to access t |
- Modernizando a Arquitetura de sua Aplicação (►) - Palestra que ensina como evoluir uma aplicação estruturada para uma aplicação com uma arquitetura mais robusta e utilizando diversos princípios OO e boas práticas de desenvolvimento.
- tonicospinelli/developing-for-business - Projeto que mostra a evolução da aplicação da palestra anterior commit a commit.
- Create your own PHP Framework - Excelente tutorial que ensina a criar o seu próprio framework a partir de uma aplicação estruturada utilizando boas práticas de programação.
- Crie o seu Próprio Framework - Versão traduzida do tutorial 'Create your own PHP Framework'.
- Por que fazer testes?
- saber se o software está funcionando de maneira automatizada
- não elimina os testes exploratórios feito de forma manual
- manter custos de desenvolvimento em níveis saudáveis
- ajuda na qualidade interna do código (design e arquitetura do código)
- saber se o software está funcionando de maneira automatizada
- Como avaliar a qualidade dos testes (se estão bem feitos)?
- corretude - se o teste não está gerando um falso positivo
- adequação do tipo de teste - se o teste é o mais adequado para a situação
- Existem diversas discussões sobre qual deve ser o tamanho de uma função.
- Mas algo mais importante é se perguntar: "Quando devemos envolver um código na sua própria função?"
- Algumas pessoas se guiam por:
- tamanho - uma função não deve ser tão grande que não caiba na tela
- reuso - qualquer código utilizado mais de uma vez deve ser colocado em uma função, caso contrário, deve ser deixado inline
- Uma abordagem interessante é separação entre intenção e implementação.
- Se você tiver que se esforçar ao olhar um fragmento de código para entender o que ele faz, o código deve ser extraído para um função e a função nomeada.
- Quando você ler o código novamente, o propósito da função ficará explícito sem a necessidade de entender o seu funcionamento internamente.
- Qual é o problema com a arquitetura das aplicações atuais?
- Um projeto, na maioria das vezes, é começado pequeno, por uma pessoa e sem saber como será a sua evolução.
- Pode acontecer de novas pessoas entrarem no projeto e não conhecerem as regras que guiam a aplicação.
- Um dos princípios de organização é o MVC ou Model View Controller.
- No MVC a regra de negócio fica na Model, os templates na View e a mediação é feita pelo Controller.
- O MVC não é suficiente para manter uma aplicação com código compreensível durante muito tempo.
- A ideia de utilizar MVC veio de frameworks e a maioria das aplicações estão acopladas de alguma maneira a frameworks.
- Um projeto é iniciado normalmente (1) escolhendo um framework, (2) instalando um esqueleto, (3) removendo códigos de demonstração, (
Os exemplos de implementação estão disponíveis no CodePen em https://codepen.io/marcelgsantos/pen/EQRqKP.
- Pode-se definir o background com uma cor sólida ou gradiente.
- Recomenda-se a utilização de um gradiente ao invés de uma imagem.
- O gradiente é quando uma cor varia para outra.
- Pode-se controlar vários aspectos de um gradiente como a direção e os pontos de mudança da cor.
- Utiliza-se a propriedade
background-color
para definir uma cor sólida. Por exemplo:background-color: red
. - Utiliza-se a propriedade
background-image
para definir um gradiente. Por exemplo:background-image: linear-gradient(red, orange)
.