Hoje, 3 de dezembro de 2015, é lançado o PHP 7. Após mais de 11 anos, a comunidade PHP dá nova vida à mais nova versão de uma das principais plataformas de desenvolvimento para a Web. E esse lançamento é digno de comemoração por vários motivos.
Tudo começou quando Nikita Popov, um dos principais desenvolvedores do Core do PHP, analisando o código do HHVM, adaptou algumas mudanças do código da ferramenta do Facebook para o PHP e chamou esse projeto de “phpng”. A performance imediatamente surpreendeu os outros desenvolvedores, e ali estava colocada a pedra fundamental do que nos está sendo apresentado hoje.
Além de melhorias brutais na performance de execução, principalmente nas operações de baixo nível, há um sem número de melhorias na plataforma e na linguagem de desenvolvimento, deixando também o PHP preparado para novas melhorias.
Uma das novidades foi amplamente discutida pela comunidade antes de ser introduzida. A declaração de tipos para parâmetros e retornos de funções e métodos. Foram meses de discussões até que chegamos a um modelo no qual os desenvolvedores PHP podem dar ainda mais controle para seu código.
Entre outras novidades podemos mencionar: suporte melhorado para sistemas 64 bits, Erros agora são tratados parecido com Exceções, remoção de diversas funcionalidades legadas e o suporte para classes anônimas.
Tudo isso graças à comunidade forte que o PHP tem, com testadores, tradutores e usuários mundo afora. Principalmente graças aos nem sempre reconhecidos Desenvolvedores do Core do PHP, que têm feito um trabalho memorável.
Ah, para saber mais sobre o PHP7, acesse o site oficial: http://php.net.
Eu tenho tendência a desenvolver cistos sebáceos. Já fui operado algumas vezes disso, para extraí-los.
Duas bolinhas, uma no lóbulo de cada orelha. Eu sabia: mais dois cistos. Nada alarmante, mas precisava ser operado. Consulta, cirurgia marcada. Lá fui eu.
Cirurgia ambulatorial, sem nenhum drama maior. (Às vezes passo mal nessas circunstâncias corriqueiras. Eu e agulhas não nos damos muito bem.) Saí eu do hospital com curativos em ambas orelhas, visíveis, indisfarçáveis. E voltei para a empresa em que eu trabalhava, uma editora.
Essa empresa pertence à denominação (hoje eu a chamo de seita) em que eu me congregava na época. A maioria quase absoluta dos funcionários também pertencia à denominação, e seus diretores eram os grandes líderes dela na América do Sul. Éramos, aos nossos próprios olhos, o melhor tipo de cristão que havia.
Ao encontrar com meus colegas, recebi três tipos diferentes de reação. Grande parte dos que comentaram alguma coisa disseram: “Ih, tá usando brinco!” Depois, um único colega me disse: “Puxa, você permitiu que furassem sua orelha na porta, como o escravo de Deuteronômio. Agora, você pertence para sempre ao Senhor!” Eu mesmo nem havia pensado nessa passagem, mas a relação com ela me alegrou.
Fui trabalhando durante o dia. Mais tarde, tive uma reunião rápida com o diretor, um dos tais grandes líderes. Sua observação? Nenhuma. Absolutamente nada. Como se fosse a coisa mais comum do mundo eu ir trabalhar com pontos e esparadrapo nas orelhas.
Essa situação me faz pensar no modo como nos relacionamos com os irmãos, e creio serem três os modos, ilustrados por cada uma das reações.
Talvez a maneira mais comum com que nos relacionemos com nossos conservos, os outros redimidos pelo Senhor, seja mundana, segundo a carne, superficial. Fazemos comentários que qualquer pessoa faria, falamos sobre assuntos da moda, fazemos piadas de gosto duvidoso, criticamos e zombamos de maneira descuidada. Muitas vezes, parece-me que a única forma de alguns filhos de Deus terem assunto para conversar é depois de verem um capítulo da novela ou assistido a um filme ou lido o jornal do dia. Para muitos, a grande maioria talvez, é difícil conseguir ter Cristo de forma viva e real como o centro e o ambiente de seu contato com outros filhos de Deus.
O segundo comentário, ligando minha cirurgia à consagração testemunhada pelas orelhas furadas no umbral da porta, indica-me a maneira correta de nos relacionarmos com outros a quem nosso Senhor redimiu. A Palavra tem de ser nosso ambiente, Cristo tem de ser o assunto e o limite, Sua glória tem de sempre ser respeitada. Isso não significa, é óbvio, que tenhamos de sempre estar citando versículos ou falando de assuntos “espirituais”. Significa, sim, que devemos estar permeados pela Palavra de tal modo que, de modo sábio e espontâneo, saibamos ligar todos os fatos a ela e, a partir deles, apresentá-la.
“A boca fala do que o coração está cheio” é verdade indiscutível revelada pelo Senhor. Se a primeira idéia que nos vem à mente é de brincos, é sinal evidente de que o coração está cheio de determinados conceitos. A boca não consegue falar de outra coisa.
Por outro lado, se a reação espontânea é relacionar tudo à Palavra, é sinal de que ela ocupa um bom lugar no coração, determinando, assim, o que a boca vai dizer. Somente desse modo poderemos ver em cada situação uma oportunidade de falar algo de Cristo, de Seu amor ou de Sua justiça, de Sua vida ou vinda. Do contrário, faremos apenas comentários bobos que qualquer incrédulo faria. Melhor seria ficar calado.
Precisamos de gigantes pequeninos!
Há a última reação. E ela foi a que mais me chocou, escandalizou mesmo. Poucas coisas ferem mais os filhos de Deus do que a indiferença por parte de outros cristãos. Há quem deseje ser tão espiritual, ou que quer que outros pensem que é, que, para alcançar isso, supõe ser necessário viver isolado deste mundo, indiferente às pessoas, avesso a reações muito “humanas”. Não sei se aquele líder fingiu alguma coisa, mas, no mínimo, refreou sua curiosidade – sim, uma característica humana, de gente que ainda está deste lado da eternidade! Há algum problema em perguntar a alguém: “Que é isso na sua orelha?” Seria menos celestial?
Esse mesmo líder, quando meu pai faleceu, falou comigo sobre o trabalho, mas nada disse, uma palavra sequer, sobre o que havia acontecido. Nem o mais tradicional e burocrático “meus pêsames” saiu daquele homem espiritual, maduro e equilibrado. Capaz de lidar com assuntos complexos do governo da seita, mas incapaz de se enternecer com alguém que havia ficado órfão de pai. Estranho, muito estranho.
Somos seres humanos. Sim, redimidos pelo sangue de Cristo, salvos para habitar com Ele pela eternidade na glória, povo escolhido de Deus, propriedade exclusiva de Deus – mas ainda seres humanos. Ainda gente de carne e osso, emoções e dores, sofrimentos e dúvidas, angústias e medos, sonhos e carências. Ainda não somos anjos. Ainda sofremos todas as limitações da carne. E ainda precisamos de gente que nos compreenda e se interesse por nós.
Não estou falando aqui de desequilíbrios emocionais, como a autocomiseração, a síndrome do ninguém-me-ama. Mas refiro-me a necessidades comuns, pés-no-chão, como: um ombro para chorar, alguém com quem rir ou orar, um amigo para ouvir um desabafo. Não precisamos de gigantes espirituais inatingíveis, que assustam por sua inacessibilidade, por seu padrão tão alto que, em lugar de atrair outros, repele-os. Precisamos de gigantes pequeninos, gigantes que se humilham, poderosos homens de Deus capazes de sentar no chão e chorar com os que choram e se alegrar com os que se alegram. Não é esta a ordenança bíblica?
A igreja primitiva atraía as pessoas por ser humanamente celestial e celestialmente humana. Ela não era desencarnada, indiferente, fria. Mas era muito viva. Ela se importava com mulheres que pediam comida e era comovida com a necessidade de irmãos pobres. Vemos como o apóstolo Paulo era preocupado com gente. Basta ler Romanos 16 para ver a maneira tão humana e cheia de vida com que ele fala de muitos irmãos. Este é o evangelho!
Um dos autores publicados por aquela editora em que eu trabalhei disse que não devemos ter amigos na igreja. E acrescentou, sem disfarçar o orgulho, que nunca trocou um presente ou uma brincadeirinha sequer com outro irmão, ao lado de quem serviu por 18 anos. Sinto muita pena dele. Triste alguém que nunca teve amigos, mas apenas irmãos, cooperadores, esposas (teve duas) e filhos. Pena ter desperdiçado muitas oportunidades de presentear alguém a quem amava. Que tolice não ter trocado um gracejo com alguém em quem confiava.
Não quero ser como esses homens espirituais. Quero, antes, o evangelho que torna o homem a plenitude daquilo que Deus concebeu que ele fosse. Quero um evangelho cheio da Palavra de Deus e de amigos, de troca de presentes e de boas risadas. Quero um evangelho que me autorize a perguntar: “Irmão, que é isso na sua orelha?” e a lhe dar os pêsames e abraçá-lo quando estiver triste pela morte do pai. E isso sem fazer com que eu seja menos espiritual, menos santo ou menos consagrado.
(Francisco Nunes, 20.12.04, publicado originalmente em 15.11.07, atualizado e republicado em 3.12.15. Este artigo pode ser distribuído e usado livremente, desde que não haja alteração no texto, sejam mantidas as informações de autoria, tradução, revisão e fonte e seja exclusivamente para uso gratuito. Preferencialmente, não o copie em seu sítio ou blog, mas coloque lá um link que aponte para o artigo.)
Este artigo é um texto sobre a importância do projeto PHP the right way, que já foi traduzido em várias linguagens. Para os programadores mais jovens, é um texto orientador que pode abrir diversos caminhos e antecipar muita coisa que está por vir na sua vida profissional, então não tenha vergonha de ler mais de uma vez, procurar materiais de apoio e até mesmo cursos baseados nesse conteúdo para entender melhor essas possibilidades, que cobre de padrões de codificação até virtualização, cache e automação.
A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original.
Albert Einstein
Antes de falar sobre esse guia e seu conteúdo, quero parabenizar os estudantes da linguagem PHP, que, apesar de sua fama e muitas vezes desvalorização, conseguem visualizar seu valor e agilidade. Uma dica que posso passar é: sejam inconformados; enquanto estiverem desenvolvendo um projeto, busquem alternativas e melhores práticas para os próximos. Todas as dicas presente no PHP the right way são aplicáveis em outras linguagens, e recomendo fortemente o estudo de mais de uma linguagem em paralelo aos iniciantes no PHP, de preferência uma fortemente tipada. Seja curioso, mas tenha foco na produtividade, pois não adianta conhecer 10 frameworks, 20 ferramentas e no final do ano não ter suas ideias implementadas.
O que é o PHP the right way?
PHP the right way é um projeto que fornece informações atualizadas sobre boas práticas e ferramentas disponíveis na linguagem PHP, uma referência fácil de ler, que introduz os desenvolvedores no cenário de forma rápida, sem informações obsoletas.
As informações disponíveis são ótimas para os iniciantes e os desenvolvedores com certa experiência. Não se trata de uma receita, mas um guia de sugestões que conta com múltiplas opções, sendo considerado um documento vivo que continuará sendo atualizado.
Boas práticas de codificação
De maneira genérica, o projeto aborda três temas diferentes: guia de estilo de código, que fala sobre as PSR e padrões de codificação, práticas de codificação, que envolve padrões de projeto e alguns recursos essenciais, além dos destaques da linguagem como namespaces e SPL.
Muitos ignoram os benefícios dos guias de estilo de código, principalmente quando se trabalha sozinho, mas, quando se trata de trabalho coletivo, a falta da padronização pode gerar inconsistências e muitas dores de cabeça entre os colaboradores, então acostume-se com os guias de estilo de código.
Gerenciamento de dependência e DI
Gerenciamento de dependência é algo relativamente recente no PHP quando se diz respeito às dependências de um projeto específico. Graças ao Composer, podemos especificar quais componentes são usados pelos nossos projetos, e uma lista das opções disponíveis pode ser encontrada no Packagist. Além de gerenciar as dependências, o Composer trabalha no gerenciamento das configurações, armazenando as versões usadas de cada componente, o que possibilita aos colaboradores replicar o ambiente do projeto.
Uma opção para as dependências do sistema/ambiente como um todo é o PEAR, que conta com uma lista de pacotes disponíveis.
Segurança
Na seção de segurança, o projeto foca na existência de pessoas ruins prontas para invadir suas aplicações, sendo então importante tomar medidas para reforçar a segurança, indicando o texto da OWASP, que lista problemas de seguranças conhecidos e como se proteger contra eles, uma leitura obrigatória.
Além dessa indicação, é abordado o uso de senhas no PHP, sugerindo o uso da função password_hash(), que utiliza o BCrypt internamente – o algoritimo mais forte suportado pelo PHP hoje.
Para fechar, também são indicados o uso e os benefícios dos filtros de dados e outras práticas.
Servidores e publicação
Nesta seção, diversas opções de servidores e plataformas de publicação são apresentadas – os tempos mudaram, não temos apenas o servidor local e a hospedagem como opções amarradas, as plataformas de publicação hoje são ótimas para criar aplicações com escalabilidade, um diferencial principalmente para prestadores de serviço.
No texto, os iniciantes terão ciência de que o Apache tem concorrente e diversas ferramentas de automação estão disponíveis – do Phing ao Travis CI. Está na hora de avançar e aproveitar as tecnologias e os recursos disponíveis.
Conclusão
Para os iniciantes da linguagem PHP que estão procurando uma direção técnica sobre recursos e ferramentas que empresas sérias de software usam em seus projetos, o PHP the right way é uma ótima fonte de conhecimento. Estude e tenha domínio dessas ferramentas e tecnologias, procure aplicá-las em seus projetos pessoais e levá-las para suas empresas, colabore para mudar a visão da linguagem com a qual você trabalha, criando projetos estruturados e automatizados.
O objetivo deste artigo foi meramente disseminar o projeto e seus benefícios, cobrindo apenas alguns pontos do conteúdo oficial – não deixe de acessar o projeto para conferir o texto na integra.
A criação de websites é uma tarefa quase indispensável em várias empresas e a capacidade de as criar e/ou fazer a sua manutenção é uma mais valia para qualquer programador. A nova linguagem HTML5...
Você faz um front-end impecável, mas ao transformá-lo em um tema WordPress, o carregamento fica lento, os plugins não funcionam e ocorrem milhares de outros problemas? Saiba que você pode não estar utilizando seus scripts corretamente no WordPress.
Não se prenda ao termo! Neste post vamos usar “scripts” para qualquer JavaScript ou CSS que você queira adicionar ao seu tema ou plugin.
Ao adicionar um novo script na sua aplicação, você deve fazê-lo da forma adequada para que o WordPress cuide de todo o processo, não usando código desnecessário e impedindo conflitos entre sua aplicação e de terceiros (plugins).
O problema
Imagine que você está desenvolvendo um tema usando jQuery. Mas ao mesmo tempo você vai usar alguns plugins que também usam o jQuery. Se você simplesmente adicionar diretamente o jQuery na sua página, sua aplicação vai estar carregando o jQuery que você adicionou e o dos plugins.
Nada bom, né? Sem contar que cada um pode estar usando uma versão diferente, gerar conflitos e aí o buraco fica mais fundo.
A solução
O WordPress possui uma série de funções que permitem a você controlar o enfileiramento (enqueue) de scripts da sua aplicação. Com elas você pode adicionar, remover ou até mesmo registrar um script para uso posterior.
Ao desenvolver um tema, você precisa adicionar a função wp_head() antes da tag </head> do seu tema e a função wp_footer() antes da </body>. Dentro dessas funções é que a mágica acontece, como veremos mais a frente.
Como de costume no WordPress, as funções são simples e bastante auto-explicativas:
Acompanhe todos os comentários do código para não ter dúvidas.
// Identificador para o script
$handle = 'my-script';
// Caminho para o arquivo
$src = get_template_directory_uri() . '/js/my-script.js';
// Array com os identificadores das dependências deste arquivo
$deps = array();
// Versão do arquivo
$ver = '1.0.0';
// Imprimir no footer? Caso seja false, imprime no head.
$in_footer = true;
// Enfileira um script
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
// Desenfileira um script
wp_dequeue_script( $handle );
Para CSS é tudo bem parecido e mudam apenas o sufixo das funções e uma opção.
// Identificador para o script
$handle = 'my-style';
// Caminho para o arquivo
$src = get_template_directory_uri() . '/css/my-style.css';
// Array de identificadores das dependências deste arquivo
$deps = array();
// Versão do arquivo
$ver = '1.0.0';
// Atributo media da folha de estilos. Ex.: screen, print, all
$media = 'screen';
// Enfileira um style
wp_enqueue_style( $handle, $src, $deps, $ver, $media );
// Desenfileira um style
wp_dequeue_style( $handle );
Você deverá usar estas funções no hook wp_enqueue_scripts, que é responsável por todo gerenciamentos de scripts públicos do seu WordPress (os que aparecem no front-end).
<?php
/*
* Insira no functions.php ou em um arquivo separado.
*
* Não existe uma action específica para styles (wp_enqueue_styles).
* Você deverá adicionar todas as funções aqui mesmo.
*/
function theme_scripts() {
// Suas funções de enqueue vão aqui.
}
add_action( 'wp_enqueue_scripts', 'theme_scripts' );
O WordPress já possui também vários scripts embutidos por padrão e para usar qualquer um deles, basta usar a função adequada com o identificador do script.
Uma das recomendações é sempre dar prioridade ao uso desses scripts que já vêm embutidos (sem colocar jQuery no braço, hein galera!) pois assim garantimos que não teremos problemas com a maior parte dos plugins do repositório do WordPress.
Poderíamos, por exemplo, adicionar o jQuery como dependência de my-script.
<?php
// Identificador
$handle = 'my-script';
// Caminho para o arquivo
$src = get_template_directory_uri() . '/js/my-script.js';
// Array com o identificador do jQuery embutido por padrão
$deps = array( 'jquery' );
// Versão
$ver = '1.0.0';
// Imprime no footer (boa prática)
$in_footer = true;
// Enfileira o script
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
Ou até mesmo enfileirarmos os dois (seguirá sempre a ordem de chamada das funções).
<?php
// Um plugin já registrado pode ser enfileirado, usando apenas o seu identificador
wp_enqueue_script( 'jquery' );
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
Ambos os casos farão com que o WordPress adicione uma tag <script> para o jQuery e outra para my-script. E caso algum outro plugin já esteja usando o jQuery, o WordPress cuidará de adicioná-lo apenas uma vez.
Você também pode registrar ou desregistrar um script ou folha de estilo que ficará disponível para ser usado a qualquer momento por qualquer plugin ou tema.
Os parâmetros são os mesmos da função de enqueue:
<?php
/*
* Ao registrar um script, você poderá
* enfileirá-lo usando apenas o seu identificador.
*/
wp_register_script( $handle, $src, $deps, $ver, $in_footer );
wp_enqueue_script( 'my-script' );
// Desregistra o script
wp_deregister_script( 'my-script' );
E combinando o uso dessas funções com as tags condicionais do WordPress, você pode melhorar muito a performance das suas páginas. Você pode criar folhas de estilo específicas para cada template e carregá-las somente quando for necessário.
<?php
if ( is_page() ) {
// Essa folha de estilos será carregada apenas nos templates de páginas
wp_enqueue_style( 'my-page-style' );
}
Bem tranquilo, né?
Apenas tome cuidado para não exagerar! Não saia criando uma folha de estilos para cada página. Lembre-se que usar o cache dos navegadores é sempre muito importante, além de ajudar a reduzir custos em alguns casos.
Também vale fazer uma análise da aplicação e pensar um pouquinho em Atomic Design para componentizar melhor seu CSS.
by DEMIR SELMANOVIC, LEAD TECHNICAL EDITOR @ TOPTAL
Using modern DevOps Tools like Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, etc. does not mean that you are applying DevOps principles. DevOps is a way of thinking.
A alma desta Revista e do Departamento de Seleção Acadêmica da UERJ se chama Elisabeth Hadad Murad – e esta frase se encontra no presente do indicativo para melhor indicar que Beth Murad, como é mais conhecida, se encontra viva, vivíssima!, na memória de todos aqueles que já trabalharam e conviveram com ela.
Infelizmente, seu coração parou de bater há poucos dias. Entretanto, suas risadas, suas críticas e suas observações “na mosca” continuam soando à nossa volta. Podemos nos lembrar, como se a ouvíssemos agora, de receber uma bronca exagerada por deixarmos a questão sem comando, seguida de um elogio igualmente exagerado, por resolvermos prontamente o problema apontado.
"Coitados!!!!!!!!", escrevia Beth, sempre com muitos pontos de exclamação, quando a questão criasse mais problemas de compreensão e solução do que o necessário para os candidatos. Rapidamente percebíamos que o comentário pletórico não implicava nenhum tipo de "maternalismo" mas sim todo o contrário, apontando antes para os nossos mais ou menos inconscientes abusos de poder.
Para Beth, um instrumento de avaliação não deveria pretender mais do que justamente avaliar aqueles que são examinados. Se este singelo objetivo é atingido, um benefício adicional se consegue: a avaliação se torna igualmente um instrumento privilegiado de aprendizagem, e não apenas para os examinandos: os examinadores aprendem também com as suas próprias questões, como nós sempre aprendemos muito com as nossas provas – claro, depois de destrinchadas e reformuladas pela Beth.
“Professor é quem de repente aprende”, já nos disse Guimarães Rosa, através do professor Riobaldo Tatarana. O professor que aprende com suas aulas e provas não precisa usar umas e outras para impor seu pequeno poder sobre os alunos, ou para impressionar os seus pares com seu alto nível de exigência – na verdade, na maioria das vezes, exigência desmedida e descabida.
As provas em cada disciplina e o exame vestibular em geral não discriminam nada, isto é, não avaliam nada se são apenas ou muito fáceis ou muito difíceis. Toda avaliação deve comportar tanto diversos níveis de dificuldade quanto extremas clareza e economia nos enunciados e nos textos escolhidos. Estas condições formam o que Beth sempre chamou de “prova cidadã”, explicitando a necessidade política de considerar sempre como cidadãos de primeira classe todos os nossos alunos e todos os candidatos a alunos da nossa universidade.
A coordenação, as concepções e as orientações de Beth Murad garantiram a condição de referência nacional à seleção vestibular da UERJ, ainda mais valorizada depois do império do ENEM. Destaca-se com frequência a organização impecável, sem quebras de sigilo ou anulação de questões, mas ainda mais importante é o exemplo público de respeito máximo à avaliação, à aprendizagem e, principalmente, aos candidatos e aos futuros alunos da universidade.
Esta universidade em que estamos pouco se dá conta da importância pedagógica, acadêmica e política do seu exame de seleção. Por isto mesmo, pouco percebe a extensão da perda que todos sofremos. Que este pequeno tributo ajude a nos lembrarmos disso, reconhecendo a importância de Beth Murad, sempre tão discreta, para a constituição da alma da própria UERJ.
A tarefa de programar está se tornando cada vez mais comum, porém ainda existem muitos fatos que as pessoas não conhecem sobre programadores e a programação em si. Acompanhe comigo o conteúdo deste artigo que apresenta 15 fatos pouco conhecidos sobre a programação.
Assim como outras atividades intelectuais, a tarefa de programar e de como as pessoas aprendem a programar computadores é muito estudada. De fato, com cada vez mais pessoas aprendendo a programar, independentemente da linguagem, ferramenta ou plataforma utilizada, é natural que poucas pessoas realmente saibam de certos fatos importantes já bem conhecidos sobre programação e desenvolvimento de software.
Do ponto de vista acadêmico, as áreas de engenharia de software e educação apresentam diversos pontos muito interessantes obtidos por meio de experimentos cujos resultados são apresentados em teses de mestrado e doutorado ou papers da área. E com base nesses resultados escolhi os fatos a serem citados neste artigo, junto com as devidas referências. Ou seja, se você, leitor, ficou com vontade de saber mais sobre cada um dos pontos discutidos aqui, recomendo fortemente procurar a referência completa para mais informações.
Com base nesse contexto, vou apresentar 15 fatos importantes e que, infelizmente, são pouco conhecidos por quem programa. Mas antes faço um aviso: esses fatos apresentam resultados de pesquisas experimentais e empíricas que possuem contextos específicos. O que quero dizer é que existe certa margem para discussão da aplicabilidade e generalização, porém conhecer o que já foi estudado e descoberto é importante e, no mínimo, pode instigar a discussão e o quão perto da realidade do leitor estão essas informações.
1) Programadores demoram para pedir ajuda quando têm problemas
Este é um fato relacionado à maneira como as pessoas aprendem a programar, pois basicamente o ensino segue a linha de aprendizado da matemática: um pouco de teoria, um ou dois exemplos e muitos exercícios. Esse formato leva os aprendizes a tentar muito nos exercícios e, muitas vezes, tentando resolver tudo sozinhos sem pedir ajuda.
Essa atitude não é ruim e é até recomendada, mas é preciso saber até que ponto deve-se deixar de tentar e pedir alguma forma de ajuda.
2) Programadores possuem uma tendência a reportar de forma incompleta seus problemas
Este fato é relacionado a pesquisas da área da psicologia, indicando que quando uma pessoa tem algum problema ela não fornece todas as informações completas sobre os problemas, especialmente quando ele é o responsável de forma direta ou indiretamente.
Esse resultado já foi comprovado experimentalmente com programadores, e uma das principais justificativas é a seguinte: reportar de forma completa um problema é visto como sinal de fraqueza que pode levar a algum tipo de julgamento de habilidade e proficiência por quem está ouvindo o relato. Essa situação é muito mais comum quando se trata de um erro básico de principiante.
3) Programadores procuram outras formas de ajuda antes de falar com colegas de trabalho
O fato de a comunicação com outras pessoas não assumir a prioridade quando um programador precisa de ajuda está relacionado novamente à sensação de julgamento que outras pessoas fazem ao saber da dificuldade.
Não obstante, sites como o StackOverflow floresceram explorando esse tipo de comportamento por meio da agregação da ajuda com diversos conceitos de comunidade para desenvolvedores.
4) O progresso na programação pode ser classificado em quatro fases
A classificação do progresso de um programador é importante para auxiliar diversas métricas envolvidas no desenvolvimento de software, além de ajudar gerentes de projeto e outras pessoas a avaliar como anda o projeto como um todo.
Além disso, é importante saber em qual fase de progresso o desenvolvedor está para, entre outras atitudes, oferecer algum tipo de ajuda para que ele não fique muito tempo emperrado em um local específico a ponto de atrasar alguma entrega. Uma classificação interessante identificou (de forma automática) quatro possíveis estados de progresso:
5) Programadores encontram barreiras superáveis e insuperáveis
Este fato pode parecer óbvio, mas ele é muito importante de ser detectado, uma vez que uma barreira de programação pode levar sérios problemas de prazo, moral da equipe e confiança.
Uma das principais dificuldades de se detectar barreiras e classificá-las está no fato de que essa informação pode ser subjetiva. Ou seja, perguntar diretamente para o programador se ele está com alguma barreira superável ou insuperável já afeta o resultado, pois ele nem sempre pode ser sincero. Há também algumas implicações em termos de ego e moral, apenas pelo fato de identificar esse tipo de barreira na programação,
6) São 6 os tipos de barreiras relacionadas à programação
Além da classificação de barreiras de programação superáveis e insuperáveis, há um estudo muito interessante que caracterizou cada uma das possíveis barreiras de programação. Para ajudar a entender as barreiras, os pesquisadores evidenciaram frases comuns em cada uma das classificações abaixo:
Design: “Eu não sei o que o computador deve fazer”.
Seleção: “Eu sei o que fazer, mas não sei o que usar”.
Coordenação: “Sei o que usar, mas não sei como combinar o que preciso”.
Uso: “Eu sei o que usar, mas não sei como usar”.
Compreensão: “Pensei que sabia usar X, mas ele não faz o que eu esperava”.
Informação: “Compreendo o que aconteceu, mas não consigo checar”.
7) Programadores passam aproximadamente 30% do tempo navegando no código-fonte
Quem programa sabe que a maior parte do tempo é gasta dentro de uma ferramenta de edição de código-fonte. Contudo, o tempo é divido entre as tarefas de edição do texto representado pelo código-fonte.
De acordo com um estudo muito importante, descobriu-se que aproximadamente 30% do tempo de trabalho de um programador não são gastos editando o texto (incluindo, alterando o excluindo), mas sim navegando entre diversos arquivos com códigos-fontes. Essa navegação envolve pesquisa, observação, coleta de informações, memorização e outras atividades. Ou seja, dá para dizer que a programação é uma atividade cuja terça parte é apenas contemplativa.
8) Produtividade de programadores remotos é menor que a produtividade de programadores locais
Esta afirmação sobre produtividade é polêmica, especialmente no momento em que se fala cada vez mais em home office, trabalho remoto e projetos globais de desenvolvimento de software. De qualquer maneira, existem evidências concretas baseadas em diversas métricas de software que, de fato, programadores remotos não produzem tanto quanto programadores que estão no mesmo local.
Faz sentido pensar dessa maneira se analisarmos os outros fatos desta lista, como a preferência pela falta de comunicação com outras pessoas. De fato, a comunicação informal é um dos principais fatores que influenciaram o resultado dessa pesquisa, pois pedir aquela dica no encontro durante uma pausa para o café é muito importante de acordo com que foi apurado.
9) A maioria dos programadores é masculina, branca e jovem
Esta afirmação sobre a diversidade de programadores não veio exatamente de uma pesquisa acadêmica, mas sim de Adda Birnir, que é a fundadora do site de recrutamento e seleção Skillcrush. Essa declaração foi apresentada no vídeo “Is CODE the most important language in the world?”.
Atualmente, é muito comum destacar minorias na programação, especialmente a baixa quantidade de mulheres. Contudo, como certos dados mostram, esse não é o único grupo de possui baixa representatividade na programação, e isso pode ter uma implicação séria quando falamos em código de aplicações que precisam lidar de forma adequada com certos grupos de usuários.
Referência: declaração da Adda Birnir sobre diversidade de codificadores no vídeo “Is CODE the most important language in the world?”.
10) As principais mensagens de erro, erro em tempos de execução e erros de compilação e o tempo médio para resolvê-los
Mensagens de erro, problemas de tempo de execução e erros de compilação são muito específicos para cada linguagem. Para destacar alguns casos, cito a tese de mestrado da pesquisadora Suzanne Marie Thompson, pois ela analisou uma grande quantidade de programadores Java em diversos cenários e coletou muitos dados interessantes sobre isso. As tabelas abaixo contam um pouco da história sobre erros e tempo médio para corrigi-los.
Apesar de o estudo se concentrar em um contexto muito específico (aprendizado da linguagem Java), é possível fazer um paralelo com outros cenários e situações, e comprovar que realmente boa parte dos erros mais comuns é replicada por programados em diferentes contextos.
Tabela 6.2. Erros mais frequentes (Java) e tempo médio de execução.
Tabela 6.12. Frequência de erros de execução em Java (runtime).
Tabela D.1 Principais erros de compilação (Java) e tempo médio para resolvê-los.
11) A manutenção de software consome mais de 50% do esforço
A manutenção de um software envolve a manipulação de código legado, assunto que já abordei antes. Porém, desta vez, cito um estudo que fala sobre esforço e que mostra como resultado que a divisão não é igual entre a criação e a manutenção.
No estudo que citou esse valor de mais de 50% de esforço, há uma ótima discussão sobre evolução do software no sentido da sua manutenção e das tarefas necessárias para tanto. Com certeza vale a pena dar olhada uma nessa referência antes de tomar aquela decisão sobre começar do zero ou trabalhar com uma base de código existente.
12) A manutenção de software consome entre 40% e 90% dos custos
Uma das principais regras de quem trabalha com negócios diz que é muito mais caro conseguir um cliente novo do que manter um cliente já existente. Contudo, de acordo com pesquisas da área de engenharia de software, a realidade é um pouco diferente quando se fala de código: manter um código em funcionamento por meio de tarefas de manutenção pode chegar a custar até 90% de todos os custos do projeto.
Essas estatísticas são bem genéricas e foram obtidas em um contexto muito particular das 487 organizações estudadas nessa pesquisa, sem contar que o estudo é de 1980. Certamente existem diversos fatores a serem considerados, mas ao menos existe um ponto de partida para analisar cursos e discutir sobre esse aspecto quando se fala de manutenção de software.
13) O trabalho de manutenção de software é dividido em 4 tarefas básicas
Ainda falando sobre manutenção de código-fonte, um estudo que influenciou muito a comunidade de engenharia de software classificou por meio da análise de resultados de questionários as principais práticas da manutenção de software. Quatro práticas foram identificadas:
Melhoria: envolvem mudanças de funcionalidades.
Adaptativa: são mudanças no ambiente para adaptação a requisitos
Corretiva: atividades para a correção de erros
Preventiva: melhorias para evitar problemas futuros
A classificação das práticas de manutenção é muito importante para auxiliar medições, organizar e rastrear bugs, agrupar funcionalidades em novas versões e gerenciar o trabalho de programadores.
14) Custos da correção de defeitos após a implantação são 10x maiores do que na fase de construção, e 100x maiores do que na fase de design
Este fato é um clássico da área e motivou a evolução dos processos clássicos de desenvolvimento de software até chegarmos ao que temos hoje. O principal ponto aqui é a identificação de custos elevados quando não se dá a devida atenção à construção e design do software.
15) Revisão de código pelos pares consegue descobrir até 60% dos defeitos
A revisão de código feita por outras pessoas, seja na modalidade de pair programming ou não, é realmente efetiva. Existem diversos estudos sobre isso, mas um dos principais indica que até 60% dos defeitos podem ser descobertos (mas não necessariamente corrigidos) quando mais de uma pessoa revisa o código-fonte.
Esse estudo é relativamente antigo e pode-se dizer que ele é um dos principais influenciadores de técnicas envolvendo processos ágeis (Agile) e outras formas de desenvolver software cujo principal foco é nas atividades, etapas, organização e outras habilidades não tão técnicas quanto a programação.
When you talk about Web frameworks, many developers think about MVC frameworks. However, most Web applications need also libraries of common utility packages for general purposes unrelated with MVC.
Read this article to learn how to build a PHP utilities framework to address general PHP application needs that you can use or take ideas to build your own general purpose framework.
O pobre cristão, consciente de sua fraqueza, ignorância, miséria e mesquinhez, é extremamente tentado a ter inveja dos outros, pois que parecem ter “mais do que o coração poderia desejar”, enquanto os desejos do coração dele são negados, e aquilo que ele busca tão zelosamente continua a fugir de sua posse.
Os filhos de Deus estão oprimidos, extremamente oprimidos…
por suas corrupções inatas,
por suas inúmeras derrotas,
pelo esconder-se da face do Senhor,
pelas acusações de Satanás,
pelas obras dos ímpios,
pela frieza do coração deles,
pela insinceridade de suas orações,
por suas vãs imaginações.
O grande erro cometido pela maioria dos filhos de Deus está em esperar achar neles mesmos aquilo que só deve ser encontrado em Cristo.
“Mas vós sois Dele, em Jesus Cristo, o qual para nós foi feito por Deus sabedoria, e justiça, e santificação, e redenção” (1Co 1.30).
Com o lançamento do PHP 7, surge a oportunidade de podermos, de certa forma, melhorarmos algumas práticas que vínhamos executando.
Neste post estão reunidas algumas “manias” que é melhor deixarmos de lado para poder aproveitar tudo que de melhor o PHP tem a nos oferecer.
1. Não utilize funções mysql_*
Finalmente chegou o tempo em que não seremos mais apenas orientados a não utilizar as funções mysql_*. No PHP 7 essas funções foram retiradas, o que significa que você terá que mudar para as funções (muito melhores, por sinal) mysqli_*, ou então utilizar alternativas melhores ou mais flexíveis como PDO ou um ORM.
2. Evite desperdício de código
Em outras palavras: não escreva código inútil que desperdice o desempenho. Na verdade, a velocidade no PHP 7 aumentou tanto que pode esconder alguns problemas na arquitetura da aplicação. Não se satisfaça com o desempenho da sua aplicação só porque o PHP 7 a tornou mais rápida.
Como desenvolvedor, você deve sempre cuidar da sua aplicação para que carregue apenas os recursos necessários, otimizar trechos de código (principalmente quando são críticos), escrever consultas a banco de maneira eficiente, utilizar cache quando possível e assim por diante.
3. Não utilize a tag de fechamento do PHP no final dos arquivos
Se você der uma olhada nos códigos de frameworks ou de grandes aplicações, como o WordPress, você verá que a tag de fechamento do PHP é omitida. Na verdade, o Zend Framework Coding Standards proíbe que você faça isso. Essa tag de fechamento não é obrigatória e quando você a omite no final do arquivo, está tendo certeza que nenhum espaço em branco será adicionado no final do arquivo (o que pode gerar erros).
4. Não passe por referência se você não precisa
Algumas vezes a passagem por referência é útil e necessária, mas em muitas outras vezes só torna o código mais difícil de entender e de tentar prever o resultado.
Aparentemente, algumas pessoas pensam que isso torna o código mais rápido, o que, de acordo com esta referência (em inglês), não é verdade.
Um exemplo de o porquê as referências são ruins no PHP é no que diz respeito às funções shuffle() ou sort(). Em vez de retornar o array aleatorizado ou ordenado, as funções modificam a variável original, o que pra mim não faz nenhum sentido.
5. Não faça consultas a banco em um loop
Realizar consulta ao banco de dados dentro de uma repetição é um gasto desnecessário. Gera uma sobrecarga de processamento que não se justifica, já que você pode atingir o mesmo resultado, de maneira mais rápida, realizando consultas fora da repetição. Quando caímos numa situação em que isso é necessário, muitas vezes é mais sensato realizar uma consulta e construir um array de dados e então iterar sobre esse array, sem a necessidade de ficar consultando o banco.
6. Evite utilizar * em consultas SQL
De fato esse é um problema mais do banco de dados, mas como muitas vezes nós escrevemos consultas dentro do código PHP, creio que vale a pena. De qualquer forma, evite utilizar os wildcards (caracteres coringas) em consultas SQL, especialmente se suas tabelas possuem muitas colunas.
Especifique exatamente as colunas que precisa e recupere apenas elas. Isso ajuda a diminuir a utilização de recursos do sistema, protege seus dados e torna as coisas mais claras.
Ainda no assunto SQL, saiba as funções que estão disponíveis e teste a velocidade o máximo que puder. Quando calcular médias, somas ou coisa do tipo, dê prioridade para as funções SQL em vez das funções do PHP. Se estiver em dúvida sobre o desempenho de uma consulta, teste-a e tente outras variações – não esqueça de usar a melhor.
7. Não confie nos dados de entrada do usuário
Não é sábio confiar nos dados que o usuário insere na aplicação. Sempre falo sobre isso quando o assunto é segurança. Sempre filtre, sanitize, escape, cheque e esteja preparado para problemas advindos desses dados. Dê uma olhada na minha palestra sobre segurança e programação defensiva. Existem três problemas específicos com a entrada de dados do usuário: os desenvolvedores não levam em consideração todas as possibilidades existentes, os dados frequentemente estão incorretos e esses dados podem ser intencionalmente maliciosos.
Um sistema bem projetado consegue proteger-se disso tudo. Sempre utilize funções como filter_var() para verificar a validade dos dados e prepará-los para utilização com um banco de dados. Nesse caso também é interessante utilizar um ORM e/ou Prepared Statements, que vão adicionar uma camada de filtragem à aplicação.
8. Não tente ser esperto
Seu objetivo deve ser escrever um código elegante e que expresse suas intenções o mais claro possível. Você pode conseguir melhorar aquele 0.01 segundo em cada carregamento de página se encurtar todas as variáveis para apenas uma letra, utilizar seletores ternários em diversos níveis e outras “espertices”, mas isso não é nada se comparado ao tanto de dores de cabeça que você estará causando a você mesmo e a todos ao seu redor.
Nomeie suas variáveis apropriadamente, documente seu código e opte pela clareza mais do que pela brevidade. Melhor ainda, utilize uma orientação a objetos padronizada que, mais ou menos, se documenta sozinha e evita um monte de inserção de comentários.
9. Não reinvente a roda
PHP já está por aí faz um tempinho e os sites por mais tempo ainda. É grande a probabilidade de que, qualquer coisa que você precise fazer, alguém já tenha feito antes. Não tenha medo de pedir ajuda. O Github é seu amigo. O Composer é seu amigo. O Packagist também é seu amigo.
De loggers a ferramentas de manipulação de cor, de debuggers a frameworks de teste unitário, das APIs do Mailchimp ao Twitter Bootstrap, tudo está disponível ao pressionar de um botão (ou digitar de um comando). Use!
10. Não negligencie as outras linguagens
Se você é um(a) programador(a) PHP, é uma prática padrão saber algo de HTML, CSS, JavaScript e algum banco de dados (é o mínimo)! Quando você tem um bom domínio nessas linguagens, é hora de aprender JavaScript novamente. JavaScript não é jQuery. Você deve conhecer a linguagem para utilizá-la de maneira eficiente.
Eu recomendo aprender tudo que puder sobre PHP orientado a objetos. Pode salvar sua vida e fará você programar melhor de maneira exponencial. Também abrirá porta outras linguagens como C# e Java, pois serão muito mais fáceis de aprender se você tiver a POO no seu cinto de utilidades.
Avance mais em conhecimento ao aprender sobre gerenciadores de pacotes, scripts de build, CoffeeScript, LESS, SASS, YAML, template engines e outras ferramentas fantásticas. Recomendo também que você estude frameworks (existem várias opções boas por aí, como Zend Framework e Laravel).
Quando já estiver se dando bem com tudo isso, o que acha de aprender Python, Ruby, Ruby on Rails, desenvolvimento pra Android, iOS e por aí vai? Você deve deixar seus preconceitos de lado. Pode achar que isso não serve pra você porque está fora da sua zona de conforto, as coisas que você precisa pro seu emprego. Mas é justamente esse ponto! Cada linguagem possui algo útil e um pouco a mais de conhecimento não faz mal a ninguém. Não é por acaso que os melhores programadores PHP que conhecemos possuem conhecimento em outras linguagens de programação.
Tudo pronto? Que venha o PHP 7!
Espero que tenham gostado do post e que, de certa forma, possa ajudá-los a melhorar suas práticas de desenvolvimento.
Não deixem de comentar e de sugerir modificações e postagens aqui no blog.
Um abraço a todos e fiquem com Deus.
Rafael Jaques
Mais de 300 profecias das Escrituras hebraicas (Antigo Testamento) confirmam que Jesus é o Messias esperado por Israel e anunciado por seus profetas.
Gênesis
1. O Messias nasceria da “semente de uma mulher” [Gênesis 3:15a, Lucas 1:34,35].
2. O Messias derrotaria Satanás [Gênesis 3:15b, 1 João 3:8].
3. O Messias padeceria ao reconciliar os homens com Deus [Gênesis 3:15c, 1 Pedro 3:18].
4. O Messias seria descendente de Sete [Gênesis 4:25, Lucas 3:23-38].
5. O Messias seria descendente de Sem [Gênesis 9:26, Lucas 3:23-36].
6. O Messias seria descendente de Abraão [Gênesis 12:3, Mateus 1:1].
7. O Messias seria descendente de Isaque [Gênesis 17:19, Lucas 3:23-34].
8. O Messias viria para todas as nações [Gênesis 18:18b, Atos 3:24-26].
9. O Messias seria descendente de Isaque [Gênesis 21:12, Lucas 3:23-34].
10. O Messias seria como um cordeiro de sacrifício [Gênesis 22:8, João 1:29].
11. O Messias seria sacrificado no mesmo monte em que Deus testou Abraão [Gênesis 22:14, Lucas 23:33].
12. O Messias abençoaria todas as nações [Gênesis 22:18, Gálatas 3:14].
13. O Messias seria descendente de Isaque [Gênesis 26:4, Lucas 3:23-34].
14. O Messias seria descendente de Jacó [Gênesis 28:14a, Lucas 3:23-34].
15. O Messias viria para todos os povos [Gênesis 28:14b, Gálatas 3:26-29].
16. O Messias seria descendente de Judá [Gênesis 49:10a, Lucas 3:23-33].
17. O Messias seria Rei de Israel [Gênesis 49:10b, João 1:49].
18. A autoridade do Messias se estenderá a todas as nações [Gênesis 49:10c, Judas 1:25].
19. O Messias seria a “videira” [Gênesis 49:11, João 15:1-5].
Êxodo
20. Nenhum dos ossos do Messias seria quebrado [Êxodo 12:46, João 19:32-33].
Números
21. Nenhum dos ossos do Messias seria quebrado [Números 9:12, João 19:32-33].
22. O Messias seria Rei de Israel [Números 24:17, João 19:19].
Deuteronômio
23. O Messias seria Profeta [Deuteronômio 18:15, Mateus 21:11].
24. O Messias seria Profeta [Deuteronômio 18:18a, Mateus 21:11].
25. Deus falaria por meio do Messias [Deuteronômio 18:18b, João 12:49].
26. O Messias seria feito maldito para redimir o homem [Deuteronômio 21:23, Gálatas 3:13].
27. O Messias seria cultuado por anjos no seu nascimento [Deuteronômio 32:43, Lucas 2:13-14].
Rute
28. O Messias seria descendente de Boaz e Rute [Rute 4:12-17, Lucas 3:23-32].
1 Samuel
29. O Messias seria exaltado por Deus com poder e força [1 Samuel 2:10, Mateus 28:18].
2 Samuel
30. O Messias seria descendente de Davi [2 Samuel 7:12-13, Mateus 1:1].
31. O Messias seria o Filho de Deus [2 Samuel 7:13-14, Mateus 3:16-17].
32. O Messias seria descendente de Davi [2 Samuel 7:16, Mateus 1:1].
33. O Messias viria para todos os povos [2 Samuel 22:50, Romanos 15:8-9].
34. O Messias seria a “Pedra” [2 Samuel 23:2-4a, 1 Coríntios 10:4].
35. O Messias seria como a “luz da manhã” [2 Samuel 23:2-4b, Apocalipse 22:16].
1 Crônicas
36. O Messias seria descendente de Judá [1 Crônicas 5:2, Lucas 3:23-33].
37. O Messias seria descendente de Davi [1 Crônicas 17:11-12a, Lucas 3:23-31].
38. O Trono do Messias seria eterno [1 Crônicas 17:11-12b, Lucas 1:32-33].
39. O Messias seria o Filho de Deus [1 Crônicas 17:13-14, Mateus 3:16-17].
Salmos
40. O Messias seria rejeitado pelos gentios [Salmo 2:1 Atos, 4:25-28].
41. Líderes políticos e religiosos conspirariam contra o Messias [Salmo 2:2, Mateus 26:3-4].
42. O Messias seria Rei [Salmo 2:6, João 12:12-13].
43. O Messias seria o Filho de Deus [Salmo 2:7a, Lucas 1:31-35].
44. O Messias declararia que Ele era o Filho de Deus [Salmo 2:7b, João 9:35-37].
45. O Messias seria ressuscitado e coroado como Rei [Salmo 2:7c, Atos 13:30-33].
46. O Messias pediria a Deus por Sua herança [Salmo 2:8a, João 17:4-24].
47. O Messias receberia autoridade sobre todos [Salmo 2:8b, Mateus 28:18].
48. O Messias seria o Filho de Deus [Salmo 2:12a, Mateus 17:5].
49. O Messias rejeitaria aqueles que não creram nele [Salmo 2:12b, João 3:36].
50. Crianças dariam louvor ao Messias [Salmo 8:2, Mateus 21:15-16].
51. Ao Messias seria dada autoridade sobre todas as coisas [Salmo 8:6, Mateus 28:18].
52. O Messias seria ressuscitado [Salmo 16:8-10a, Mateus 28:6].
53. O corpo do Messias não seria exposto à corrupção [Salmo 16:8-10b, Atos 13:35-37].
54. O Messias seria exaltado à presença de Deus [Salmo 16:11, Atos 2:25-33].
55. O Messias viria para todos os povos [Salmo 18:49, Efésios 3:4-6].
56. O Messias clamaria a Deus [Salmo 22:1a, Mateus 27:46].
57. O Messias seria desamparado por Deus [Salmo 22:1b, Marcos 15:34].
58. O Messias, angustiado, oraria sem cessar [Salmo 22:2, Mateus 26:38-39].
59. O Messias seria desprezado [Salmo 22:6, Lucas 23:21-23].
60. O povo zombaria do Messias, meneando a cabeça [Salmo 22:7, Mateus 27:39].
61. Escarnecedores diriam do Messias: “Confiou em Deus, livre-o agora” [Salmo 22:8, Mateus 27:41-43].
62. O Messias teria consciência de Seu Pai desde a mocidade [Salmo 22:9, Lucas 2:40].
63. O Messias seria chamado para o serviço de Deus desde o ventre [Salmo 22:10, Lucas 1:30-33].
64. O Messias seria abandonado pelos discípulos [Salmo 22:11, Marcos 14:50].
65. O Messias seria cercado por espíritos malignos [Salmo 22:12-13, Colossenses 2:15].
66. O coração do Messias iria se partir, fluindo sangue e água [Salmo 22:14a, João 19:34].
67. O Messias seria crucificado [Salmo 22:14b, Mateus 27:35].
68. O Messias teria sede [Salmo 22:15a, João 19:28].
69. O Messias teria sede um pouco antes de Sua morte [Salmo 22:15b, João 19:30].
70. O Messias seria cercado por gentios na Sua crucificação [Salmo 22:16a, Lucas 23:36].
71. O Messias seria cercado por inimigos na Sua crucificação [Salmo 22:16b, Mateus 27:41-43].
72. As mãos e os pés do Messias seriam transpassados [Salmo 22:16c, Mateus 27:38].
73. Nenhum dos ossos do Messias seria quebrado [Salmo 22:17a, João 19:32-33].
74. O povo fixaria os olhos no Messias durante a crucificação [Salmo 22:17b, Lucas 23:35].
75. As vestes do Messias seriam repartidas [Salmo 22:18a, João 19:23-24].
76. Sortes seriam lançadas sobre a roupa do Messias [Salmo 22:18b, João 19:23-24].
77. O ato expiatório do Messias possibilitaria aos crentes serem Seus irmãos [Salmo 22:22, Hebreus 2:10-12].
78. Os inimigos do Messias tropeçariam e cairiam quando viessem por Ele [Salmo 27:2, João 18:3-6].
79. O Messias seria acusado por falsas testemunhas [Salmo 27:12, Mateus 26:59-61].
80. O Messias bradaria: “Nas tuas mãos encomendo o meu espírito” [Salmo 31:5, Lucas 23:46].
81. Haveria planos para matar o Messias [Salmo 31:13, Mateus 27:1].
82. Nenhum dos ossos do Messias seria quebrado [Salmo 34:20, João 19:32-33].
83. O Messias seria acusado por falsas testemunhas [Salmo 35:11, Marcos 14:55-59].
84. O Messias seria odiado por muitos sem motivo [Salmo 35:19, João 18:19-23].
85. O Messias emudeceria diante dos acusadores [Salmo 38:13-14, Mateus 26:62-63].
86. A auto-oferta do Messias substituiria todos os sacrifícios [Salmo 40:6-8a, Hebreus 10:10-13].
87. O Messias diria que as Escrituras testificam Dele [Salmo 40:6-8b, Lucas 24:44].
88. O Messias viria para fazer a vontade de Deus [Salmo 40:7-8, João 5:30].
89. O Messias não ocultaria Sua missão da congregação [Salmo 40:9-10, Lucas 4:16-21].
90. O traidor do Messias seria um amigo com quem Ele partiu pão [Salmo 41:9, Marcos 14:17-18].
91. O Messias falaria com uma mensagem de graça [Salmo 45:2, Lucas 4:22].
92. O trono do Messias seria perpétuo [Salmo 45:6-7a, Lucas 1:31-33].
93. O Messias seria Deus [Salmo 45:6-7b, Hebreus 1:8-9].
94. O Messias agiria com retidão [Salmo 45:6-7c, João 5:30].
95. O Messias seria traído por um amigo [Salmo 55:12-14, Lucas 22:47-48].
96. O Messias ascenderia ao céu [Salmo 68:18a, Lucas 24:51].
97. O Messias daria dons aos homens [Salmo 68:18b, Mateus 10:1].
98. O Messias seria odiado por muitos sem motivo [Salmo 69:4, Lucas 23:13-22].
99. O Messias suportaria acusações, por amor a Deus [Salmo 69:7, Mateus 26:65-67].
100. O Messias seria rejeitado por Seu povo [Salmo 69:8a, João 1:11].
101. Os irmãos do Messias não creriam Nele [Salmo 69:8b, João 7:3-5].
102. O Messias se enfureceria pelo desrespeito para com o templo [Salmo 69:9a, João 2:13-17].
103. O Messias suportaria acusações, por amor a Deus [Salmo 69:9b, Romanos 15:3].
104. O coração do Messias iria se partir [Salmo 69:20a, João 19:34].
105. Os discípulos do Messias O abandonariam na Sua hora de necessidade [Salmo 69:20b, Marcos 14:33-41].
106. Ao Messias seria oferecido fel e vinagre [Salmo 69:21a, Mateus 27:34].
107. O Messias teria sede [Salmo 69:21b, João 19:28].
108. O campo do oleiro ficaria desabitado [Salmo 69:25, Atos 1:16-20].
109. O Messias falaria em parábolas [Salmo 78:2, Mateus 13:34-35].
110. O Messias estaria à destra de Deus [Salmo 80:17, Atos 5:31].
111. O Messias seria descendente de Davi [Salmo 89:3-4, Mateus 1:1].
112. O Messias chamaria a Deus de “Meu Pai” [Salmo 89:26, Mateus 11:27].
113. O Messias seria o “primogênito” de Deus [ Salmo 89:27, Marcos 16:6].
114. O Messias seria descendente de Davi [Salmo 89:29, Mateus 1:1].
115. O Messias seria descendente de Davi [Salmo 89:35-36, Mateus 1:1].
116. O Messias seria eterno [Salmo 102:25-27a, Colossenses 1:17].
117. O Messias seria o criador de todas as coisas [Salmo 102:25-27b, João 1:3].
118. O Messias seria acusado por falsas testemunhas [Salmo 109:2, João 18:29-30].
119. O Messias oraria por Seus inimigos [Salmo 109:4, Lucas 23:34].
120. O traidor do Messias teria uma vida curta [Salmo 109:8a, Atos 1:16-18].
121. O traidor do Messias seria substituído [Salmo 109:8b, Atos 1:20-26].
122. O povo zombaria do Messias, meneando a cabeça [Salmo 109:25, Marcos 15:29-30].
123. O Messias seria Senhor [Salmo 110:1a, Mateus 22:41-45].
124. O Messias estaria à destra de Deus [Salmo 110:1b, Marcos 16:19].
125. O Messias seria um sacerdote segundo a ordem de Melquisedeque [Salmo 110:4, Hebreus 6:17-20].
126. O Messias estaria à destra de Deus [Salmo 110:5, 1 Pedro 3:21-22].
127. O Messias seria a “pedra” rejeitada por Israel [Salmo 118:22, Mateus 21:42-43].
128. O Messias viria em nome do Senhor [Salmo 118:26, Mateus 21:9].
129. O Messias seria descendente de Davi [Salmo 132:11, Mateus 1:1].
130. O Messias seria descendente de Davi [Salmo 132:17, Mateus 1:1].
Provérbios
131. O Messias seria oriundo da eternidade [Provérbios 8:22-23, João 17:5].
132. O Messias ascenderia e desceria do céu [Provérbios 30:4a, João 3:13].
133. Deus teria um Filho [Provérbios 30:4b, Mateus 3:16-17].
Isaías
134. Israel teria um coração endurecido contra o Messias [Isaías 6:9-10a, João 12:37-40].
135. O Messias falaria em parábolas [Isaías 6:9-10b, Mateus 13:13-15].
136. O Messias seria descendente de Davi [Isaías 7:13-14, Mateus 1:1].
137. O Messias nasceria de uma virgem [Isaías 7:14a, Lucas 1:34-35].
138. O Messias seria Emanuel, “Deus conosco” [Isaías 7:14b, Mateus 1:21-23].
139. O Messias seria Deus [Isaías 7:14c, João 12:45].
140. O Messias seria uma “pedra de tropeço” para Israel [Isaías 8:14, Mateus 21:43-44].
141. O Messias ministraria na Galiléia [Isaías 9:1-2a, Mateus 4:12-17].
142. O Messias seria uma luz para os gentios [Isaías 9:1-2b, Lucas 2:28-32].
143. O nascimento do Messias [Isaías 9:6a, Lucas 2:11].
144. O Messias seria o Filho de Deus [Isaías 9:6b, Lucas 1:35].
145. O Messias seria o “Maravilhoso Conselheiro” [Isaías 9:6c, João 7:46].
146. O Messias seria homem e Deus, o “Deus Forte” [Isaías 9:6d, João 10:30].
147. O Messias seria o “Pai da Eternidade” [Isaías 9:6e, Apocalipse 1:8].
148. O Messias seria o “Príncipe da Paz” [Isaías 9:6f, Colossenses 1:20].
149. O Messias seria descendente de Jessé [Isaías 11:1a, Lucas 3:23-32].
150. O Messias cresceria em uma família pobre [Isaías 11:1b, Lucas 2:7].
151. O Messias cresceria em Nazaré [Isaías 11:1c, Mateus 2:21-23].
152. O Messias teria o Espírito de Deus sobre Si [Isaías 11:2a, Mateus 3:16-17].
153. O Messias teria o Espírito de sabedoria [Isaías 11:2b, Lucas 2:40].
154. O Messias teria o Espírito de entendimento [Isaías 11:2c, Lucas 2:40].
155. O Messias teria o Espírito de conselho [Isaías 11:2d, Mateus 7:28-29].
156. O Messias teria o Espírito de fortaleza [Isaías 11:2e, Mateus 8:27].
157. O Messias teria o Espírito de conhecimento do Senhor [Isaías 11:2f, João 7:29].
158. O Messias teria o Espírito de temor do Senhor [Isaías 11:2g, Hebreus 5:7].
159. O Messias teria um intenso entendimento no temor do Senhor [Isaías 11:3a, Lucas 2:46-47].
160. O Messias não julgaria com base em aparências externas [Isaías 11:3b, João 7:24].
161. O Messias julgaria os pobres com justiça [Isaías 11:4, Marcos 12:41-44].
162. O Messias seria descendente de Jessé [Isaías 11:10a, Lucas 3:23-32].
163. O Messias viria para todos os povos [Isaías 11:10b, Atos 13:47-48].
164. O Messias teria a chave de Davi [Isaías 22:22, Apocalipse 3:7].
165. O Messias derrotaria a morte [Isaías 25:8, Apocalipse 1:18].
166. Outros ressurgiriam à vida na ressurreição do Messias [Isaías 26:19, Mateus 27:52-53].
167. O Messias seria a pedra de esquina [Isaías 28:16, 1 Peter 2:4-6].
168. O Messias curaria o cego [Isaías 35:5a, Marcos 10:51-52].
169. O Messias curaria o surdo [Isaías 35:5b, Marcos 7:32-35].
170. O Messias curaria o coxo [Isaías 35:6a, Mateus 12:10-13].
171. O Messias curaria o mudo [Isaías 35:6b, Mateus 9:32-33].
172. O precursor do Messias viveria no deserto [Isaías 40:3a, Mateus 3:1-4].
173. O precursor prepararia o povo para a vinda do Messias [Isaías 40:3b, Lucas 1:17].
174. O Messias seria Deus [Isaías 40:3c, João 10:30].
175. O Messias seria como um pastor [Isaías 40:11, João 10:11].
176. O Messias seria o servo de Deus [Isaías 42:1a, João 4:34].
177. O Messias teria o Espírito de Deus sobre ele [Isaías 42:1b, Mateus 3:16-17].
178. O Messias agradaria a Deus [Isaías 42:1c, Mateus 3:16-17].
179. O Messias não chamaria atenção para Si próprio [Isaías 42:2, Mateus 12:15-21].
180. O Messias teria compaixão de pobres e necessitados [Isaías 42:3, Mateus 11:4-5].
181. O Messias receberia orientação de Deus [Isaías 42:6a, João 5:19-20].
182. O Messias seria guardado por Deus [Isaías 42:6b, João 8:29].
183. O Messias seria a nova aliança [Isaías 42:6c, Mateus 26:28].
184. O Messias seria uma luz para os gentios [Isaías 42:6d, João 8:12].
185. O Messias curaria o cego [Isaías 42:7, Mateus 9:27-30].
186. O Messias seria oriundo da eternidade [Isaías 48:16a, João 1:1-2].
187. O Messias seria enviado por Deus [Isaías 48:16b, João 7:29].
188. O Messias viria para todos os povos [Isaías 49:1a, 1 Timóteo 2:4-6].
189. O Messias seria chamado para o serviço de Deus desde o ventre [Isaías 49:1b, Mateus 1:20-21].
190. O Messias seria chamado pelo nome antes de nascer [Isaías 49:1c, Lucas 1:30-31].
191. As palavras do Messias seriam como uma espada aguda [Isaías 49:2a, Apocalipse 2:12-16].
192. O Messias seria protegido por Deus [Isaías 49:2b, Mateus 2:13-15].
193. O Messias seria responsável pelo juízo da humanidade [Isaías 49:2c, João 5:22-29].
194. O Messias seria o servo de Deus [Isaías 49:3a, João 17:4].
195. A obra do Messias glorificaria a Deus [Isaías 49:3b, Mateus 15:30-31].
196. O Messias seria afligido pela incredulidade de Israel [Isaías 49:4, Lucas 19:41-42].
197. O Messias seria o servo de Deus [Isaías 49:5a, João 6:38].
198. O Messias viria para trazer Israel de volta para Deus [Isaías 49:5b, Mateus 15:24].
199. O Messias seria o servo de Deus [Isaías 49:6a, João 12:49-50].
200. O Messias seria uma luz para os Gentios [Isaías 49:6b, Atos 13:47-48].
201. O Messias seria desprezado [Isaías 49:7, João 10:20].
202. O Messias falaria com sabedoria dada a ele por Deus [Isaías 50:4, João 12:49].
203. O Messias não seria rebelde à vontade de Deus [Isaías 50:5, João 12:27].
204. As costas do Messias seria açoitada [Isaías 50:6a, Mateus 27:26].
205. O Messias teria a face esbofeteada e cuspida [Isaías 50:6b, Mateus 26:67].
206. O Messias direcionaria firmemente a face para Sua missão [Isaías 50:7, Lucas 9:51-53].
207. O Messias seria justificado por Sua retidão [Isaías 50:8, 1 Timóteo 3:16].
208. O Messias colocaria a confiança em Deus [Isaías 50:8-10, João 11:7-10].
209. O Messias seria o servo de Deus [Isaías 52:13a, João 9:4].
210. O Messias seria grandemente exaltado [Isaías 52:13b, Filipenses 2:9-11].
211. A face do Messias seria desfigurada por meio de pancadas violentas [Isaías 52:14, Mateus 26:67-68].
212. O sangue do Messias seria derramado para fazer expiação por todos os pecados [Isaías 52:15, Apocalipse 1:5].
213. O povo do Messias não creria que ele fosse o Cristo [Isaías 53:1, João 12:37-38].
214. O Messias cresceria em Nazaré [Isaías 53:2a, Mateus 2:21-23].
215. O Messias teria a aparência de um homem comum [Isaías 53:2b, Filipenses 2:7-8].
216. O Messias seria desprezado [Isaías 53:3a, Lucas 4:28-29].
217. O Messias seria rejeitado [Isaías 53:3b, Mateus 27:21-23].
218. O Messias teria grande dor e tristeza [Isaías 53:3c, Lucas 19:41-42].
219. Homens evitariam associações com o Messias [Isaías 53:3d, Marcos 14:50-52].
220. O Messias teria um ministério de cura [Isaías 53:4a, Lucas 6:17-19].
221. O Messias carregaria e suportaria sobre Si os pecados do mundo [Isaías 53:4b, 1 Pedro 2:24].
222. Pensariam que o Messias tivesse sido amaldiçoado por Deus [Isaías 53:4c, Mateus 27:41-43].
223. O Messias suportaria a punição pelos pecados da humanidade [Isaías 53:5a, Lucas 23:33].
224. O sacrifício do Messias proveria paz entre Deus e o homem [Isaías 53:5b, Colossenses 1:20].
225. As costas do Messias seriam açoitadas [Isaías 53:5c, Mateus 27:26].
226. O Messias seria, para toda a humanidade, o ?carregador-dos-pecados? [Isaías 53:6, Gálatas 1:4].
227. O Messias seria oprimido e afligido [Isaías 53:7a, Mateus 27:27-31].
228. O Messias estaria calado perante seus acusadores [Isaías 53:7b, Mateus 27:12-14].
229. O Messias seria como um cordeiro de sacrifício [Isaías 53:7c, João 1:29].
230. O Messias seria preso e atormentado [Isaías 53:8a, Mateus 26:47-27:31].
231. O Messias seria julgado [Isaías 53:8b, João 18:13-22].
232. O Messias seria morto [Isaías 53:8c, Mateus 27:35].
233. O Messias morreria pelos pecados do mundo [Isaías 53:8d, 1 João 2:2].
234. O Messias seria sepultado no túmulo de um rico [Isaías 53:9a, Mateus 27:57].
235. O Messias seria inocente e não cometeria injúria [Isaías 53:9b, Marcos 15:3].
236. Não haveria engano na boca do Messias [Isaías 53:9c, João 18:38].
237. Era a vontade de Deus que o Messias morresse por toda a humanidade [Isaías 53:10a, João 18:11].
238. O Messias seria uma oferta pelo pecado [Isaías 53:10b, Mateus 20:28].
239. O Messias ressuscitaria e viveria para sempre [Isaías 53:10c, Marcos 16:16].
240. O Messias prosperaria [Isaías 53:10d, João 17:1-5].
241. Deus ficaria plenamente satisfeito com o sofrimento do Messias [Isaías 53:11a, João 12:27].
242. O Messias seria o servo de Deus [Isaías 53:11b, Romanos 5:18-19].
243. O Messias justificaria o homem perante Deus [Isaías 53:11c, Romanos 5:8-9].
244. O Messias seria, para toda a humanidade, o “carregador-dos-pecados” [Isaías 53:11d, Hebreus 9:28].
245. Por causa do Seu sacrifício, o Messias seria grandemente exaltado por Deus [Isaías 53:12a, Mateus 28:18].
246. O Messias entregaria a vida para salvar a humanidade [Isaías 53:12b, Lucas 23:46].
247. O Messias seria ajuntado com os malfeitores [Isaías 53:12c, Lucas 23:32].
248. O Messias seria, para toda a humanidade, o “carregador-dos-pecados” [Isaías 53:12d, 2 Coríntios 5:21].
249. O Messias intercederia a Deus em favor da humanidade [Isaías 53:12e, Lucas 23:34].
250. O Messias seria ressuscitado por Deus [Isaías 55:3, Atos 13:34].
251. O Messias seria uma testemunha [Isaías 55:4, João 18:37].
252. O Messias viria para prover salvação [Isaías 59:15-16a, João 6:40].
253. O Messias seria o intercessor entre Deus e o homem [Isaías 59:15-16b, Mateus 10:32-33].
254. O Messias viria a Sião como o seu Redentor [Isaías 59:20, Lucas 2:38].
255. O Messias teria o Espírito de Deus sobre ele [Isaías 61:1, Mateus 3:16-17].
256. O Messias pregaria as boas-novas [Isaías 61:1-2, Lucas 4:18-21].
257. O Messias viria para prover salvação [Isaías 63:5, João 3:17].
258. O Messias seria achado por um povo que não O buscava [Isaías 65:1, Mateus 15:22-28].
259. O Messias seria rejeitado por Israel [Isaías 65:2, João 5:37-40].
Jeremias
260. O Messias seria descendente de Davi [Jeremias 23:5, Lucas 3:23-31].
261. O Messias seria Senhor [Jeremias 23:6, João 13:13].
262. Crianças morreriam durante uma tentativa de matar o Messias [Jeremias 31:15, Mateus 2:16].
263. O Messias nasceria de uma virgem [Jeremias 31:22, Mateus 1:18-20].
264. O Messias seria a nova aliança [Jeremias 31:31, Mateus 26:28].
265. O Messias seria descendente de Davi [Jeremias 33:14-15, Lucas 3:23-31].
Lamentações
266. O Messias seria golpeado na face [Lamentações 3:30, João 18:22].
Ezequiel
267. O Messias seria descendente de Davi [Ezequiel 17:22-24, Lucas 3:23-31].
268. O Messias seria descendente de Davi [Ezequiel 34:23-24, Mateus 1:1].
Daniel
269. O Messias ascenderia ao céu [Daniel 7:13-14a, Atos 1:9-11].
270. O Messias seria altamente exaltado [Daniel 7:13-14b, Efésios 1:20-22].
271. O domínio do Messias seria eterno [Daniel 7:13-14c, Lucas 1:31-33].
272. O Messias viria para dar fim aos pecados [Daniel 9:24a, Gálatas 1:3-5].
273. O Messias seria santo [Daniel 9:24b, Lucas 1:35].
274. O Messias seria anunciado ao seu povo 483 anos após o dia exato do decreto para a reedificação da cidade de Jerusalém [Daniel 9:25, João 12:12-13].
275. O Messias seria morto [Daniel 9:26a, Mateus 27:35].
276. O Messias morreria pelos pecados do mundo [Daniel 9:26b, Hebreus 2:9].
277. O Messias seria morto antes da destruição do templo [Daniel 9:26c, Mateus 27:50-51].
278. Uma visão do Messias em estado glorificado [Daniel 10:5-6, Apocalipse 1:13-16].
Oséias
279. O Messias seria o Filho de Deus [Oséias 11:1a, Mateus 2:13-15].
280. O Messias seria chamado do Egito [Oséias 11:1b, Mateus 2:13-15].
281. O Messias venceria a morte [Oséias 13:14, 1 Coríntios 15:55-57].
Joel
282. O Messias ofereceria a salvação para todos [Joel 2:32, Romanos 10:12-13].
Amós
283. Deus faria com que o céu se escurecesse ao meio-dia [Amós 8:9, Mateus 27:45-46].
Miquéias
284. O Messias nasceria em Belém [Miquéias 5:2a, Mateus 2:1-2].
285. O Messias seria o servo de Deus [Miquéias 5:2b, João 15:10].
286. O Messias seria oriundo da eternidade [Miquéias 5:2c, Apocalipse 1:8].
Ageu
287. O Messias visitaria o segundo templo [Ageu 2:6-9, Lucas 2:27-32].
288. O Messias seria descendente de Zorobabel [Ageu 2:23, Lucas 3:23-27].
Zacarias
289. O Messias seria Deus na forma de homem e habitaria entre o Seu povo [Zacarias 2:10-11a, João 1:14].
290. O Messias seria enviado por Deus [Zacarias 2:10-11b, João 8:18-19].
291. O Messias seria descendente de Zorobabel [Zacarias 3:8a, Lucas 3:23-27].
292. O Messias seria o servo de Deus [Zacarias 3:8b, João 17:4].
293. O Messias seria sacerdote e rei [Zacarias 6:12-13, Hebreus 8:1].
294. O Messias seria recebido com alegria em Jerusalém [Zacarias 9:9a, Mateus 21:8-10].
295. O Messias seria visto como Rei [Zacarias 9:9b, João 12:12-13].
296. O Messias seria justo [Zacarias 9:9c, João 5:30].
297. O Messias traria salvação [Zacarias 9:9d, Lucas 19:10].
298. O Messias seria humilde [Zacarias 9:9e, Mateus 11:29].
299. O Messias seria apresentado a Jerusalém montado num jumento [Zacarias 9:9f, Mateus 21:6-9].
300. O Messias seria a pedra de esquina [Zacarias 10:4, Efésios 2:20].
301. A rejeição do Messias faria com que Deus removesse Sua proteção sobre Israel [Zacarias 11:10, Lucas 19:41-44].
302. O Messias seria traído por trinta moedas de prata [Zacarias 11:12, Mateus 26:14-15].
303. Trinta moedas de prata seriam lançadas na casa do Senhor [Zacarias 11:13a, Mateus 27:3-5].
304. Trinta moedas de prata seriam usadas para comprar o campo do oleiro [Zacarias 11:13b, Mateus 27:6-7].
305. O corpo do Messias seria transpassado [Zacarias 12:10, João 19:34].
306. O Messias seria um com Deus [Zacarias 13:7a, João 14:9].
307. Os discípulos do Messias se dispersariam [Zacarias 13:7b, Mateus 26:31-56].
Malaquias
308. Um mensageiro prepararia o caminho para o Messias [Malaquias 3:1a, Mateus 11:10].
309. O Messias apareceria subitamente no templo [Malaquias 3:1b, Marcos 11:15-16].
310. O Messias seria o mensageiro da nova aliança [Malaquias 3:1c, Lucas 4:43].
311. O precursor do Messias viria no espírito de Elias [Malaquias 4:5, Mateus 3:1-2].
312. O precursor do Messias converteria muitos à eqüidade [Malaquias 4:6, Lucas 1:16-17].
(Autor desconhecido. Recebido por e-mail há alguns anos.)
(Este artigo pode ser distribuído e usado livremente, desde que não haja alteração no texto, sejam mantidas as informações de autoria, tradução, revisão e fonte e seja exclusivamente para uso gratuito. Preferencialmente, não o copie em seu sítio ou blog, mas coloque lá um link que aponte para o artigo.)
Uma das reclamações mais repetidas dos professores em geral,
de literatura em particular, é a de que os seus alunos não leem nada. A
reclamação procede?
A minha resposta é: “não procede”. Aceito que muitos alunos
não leiam a maioria dos textos que seus professores exigem que eles leiam, mas
isso não significa que eles não leem nada.
Sabemos há muito que todo discurso que se repete configura
sintoma de outra coisa. A repetição esconde essa outra coisa, mas ao mesmo
tempo a revela. Claro, é mais difícil percebê-lo quando é o nosso próprio
discurso que se repete, mas façamos um certo esforço.
Quando um professor diz que os alunos da sua turma não leem,
comete uma generalização apressada. Na verdade, ele só pode afirmar que os
seus alunos não leram os textos que ele mandou que eles lessem. Para sustentar
sua reclamação, seria preciso ainda averiguar se eles também não leram os textos
que todos os demais professores daquele período mandaram que os mesmos alunos
lessem.
Parece-me que a maioria dos alunos lê alguma coisa, fazendo
suas opções de acordo com sua possibilidade de tempo, de acordo com sua
necessidade de atender primeiro os professores de mão mais pesada, e de acordo com
seu próprio gosto. Além disso, muitos alunos querem e precisam ler outras
coisas, diferentes daquelas que os professores exigem. As melhores leituras são
as leituras autônomas.
Estou há várias décadas na profissão, mas não me lembro de
uma discussão séria a respeito de um limite razoável para a quantidade de
leituras, de provas e de trabalhos de que um aluno daria conta. No caso
específico do nosso curso de Letras na UERJ, em especial quando noturno, esquecemos
facilmente que muitos de nossos alunos trabalham 8 horas por dia em profissões
que nem lhes permitem ler, nem veem com bons olhos essa atividade, que tão de
perto lembra o ócio ou o lazer.
Como ser “exigente” é uma qualidade muito apreciada em nosso
meio, cada professor se considera mais exigente quanto mais leitura exija de
seus alunos. Entretanto, somos bem pouco exigentes, me parece, quanto a nós mesmos
e quanto à avaliação da circunstância que nos envolve e aos alunos. Não
percebemos, por exemplo, que alguns alunos até leem, mas não entendem o que
leem, o que deveria aumentar a nossa responsabilidade de professor.
Cabe-nos sempre, desde a classe de alfabetização até o
doutorado, ensinar a ler. Para fazê-lo, precisamos: dar o exemplo, lendo junto
com os alunos, em sala; oferecer leituras que levem o aluno a níveis cada vez
mais complexos de compreensão. No fundo, dizer que os alunos não leem nada
equivale a afirmar que nós ensinamos, eles é que não aprendem.
Ora, se os alunos não aprendem nada, é porque nós não lhes ensinamos
nada – acaciano, diria o conselheiro que motivou a criação do adjetivo. Logo,
se os alunos não leem nada, é porque os professores não ensinamos esses alunos
a ler coisa alguma.
Por que essa obviedade não é óbvia? Talvez porque o professor,
esmagado pelas múltiplas exigências da profissão, devidamente somadas ao
desrespeito social crescente, se sinta bastante ressentido: nem seus queridos
alunos o respeitam!
O lugar do professor é sem dúvida um lugar de poder, mas o
poder do professor é cada vez menor. Sentindo seu poder progressivamente
diminuído, reduzido às vezes a proporções liliputianas, o professor não
comemora o fato de que alguns alunos sempre leem o que ele pede, preferindo
generalizar o mal estar a partir daqueles que não leram porque não quiseram,
porque não puderam, ou porque não conseguiram. Escolhendo ver apenas por lentes
negativas, o professor reclama repetidamente das consequências do problema, o
que bloqueia e recalca a reflexão mais calma sobre suas verdadeiras causas.
No instituto de letras em que trabalho, alguns alunos se
organizaram para pedir disciplinas de prática artística da escrita. Ao
contrário de outros faculdades de artes, como música, teatro ou dança, no curso
de letras alunos e professores somos fortemente desestimulados a “fazer”
literatura, como se essa prática atrapalhasse o estudo “sério” da disciplina.
Ora, muita gente escolhe o curso de letras antes porque
gosta de escrever poesia e ficção, menos porque quer ser professor algum dia.
Se o desejo de escrever literatura dessa gente for devidamente recalcado, não é
absurdo pensar que ao final todos se transformem em professores frustrados,
naturalmente aptos a descontarem sua frustração em quem, senão nos alunos futuros?
Reparem que não mudei de assunto. A primeira reação de
alguns professores àquela demanda dos alunos foi recorrer a uma variante da mesma
reclamação que abre o meu artigo: como esses meninos e meninas querem escrever,
se não leem nada do que a gente manda eles lerem?
Já disse que essa generalização é apressada e equivocada.
Acrescento que a concepção de leitura que subjaz ao comentário é mecanicista e
atrasada. Ler muito não leva necessária e mecanicamente a escrever. Ler muito
leva, no máximo, a ler muito. Já disse há décadas, num livro chamado “Redação
inquieta”, que o ato de ler é metonímia da vontade de entender o mundo,
enquanto o ato de escrever é metonímia da vontade de mudar o mundo.
Querer entender o mundo, e mesmo entendê-lo, não implica nenhuma
vontade de mudá-lo. Querer mudar o mundo, no entanto, parte do entendimento
prévio de que as coisas não deveriam permanecer assim. Em outras palavras: ler
não leva necessariamente a escrever, mas escrever supõe necessariamente leitura
– não necessariamente a nossa leitura, que fique claro (até pela repetição insistente
do mesmo advérbio). Em outras palavras: quem quer escrever o quer porque já leu
o mundo, já leu textos, já leu livros, ainda que não aqueles que lemos ou que
mandamos os alunos lerem.
Em nossas sofisticadas teses, comentamos embevecidos “a
poética da escrita como leitura” em autores como Cervantes, Machado, Borges,
Clarice e tantos outros, sem estabelecer nenhuma relação disso com a nossa
prática pedagógica. Ora, a leitura analítica, filológica, acadêmica, é uma
leitura válida, mas não é a única leitura possível. Se ela se torna, ao
contrário, a única leitura admissível, torna-se também uma leitura excludente,
autoritária e, em última análise: chata pra caramba.
Sabemos que as adaptações de um texto literário para outra
linguagem, como a dos quadrinhos, da televisão ou do cinema, implicam leituras
refinadas. O que fez Luiz Fernando Carvalho, ao trazer “Dom Casmurro”, de Machado
de Assis, para a televisão, na minissérie “Capitu”, senão uma belíssima leitura
do romance?
Ora, por que nós não pedimos aos nossos alunos que releiam
literariamente os textos literários, transformando-os em crônicas, contos,
poemas, peças, esquetes, músicas, desenhos, quadrinhos, imagens, sites, quiçá
pequenos filmes? Decerto porque a avaliação desses trabalhos fica mais difícil.
Entretanto, toda avaliação é por definição injusta. Logo, a nossa prioridade
deve ser antes ensinar melhor do que avaliar melhor.
Como disse o escritor e cartunista Ziraldo, uma vez: “ler é
melhor do que estudar”. Eu o parafrasearia, com o mesmo espírito polêmico,
dizendo que “escrever é melhor do que ler”, simplesmente porque: escrever já
implica ler, e ler melhor.
I have gone through an interesting small size C code package for QR encoding at https://github.com/swex/QR-Image-embedded. Its logic is contained in two small files: QR_Encode.h (3.7KB) and QR_Encode.c (61KB). Then it is sun-shiny Saturday morning as I manage to add in-memory monochrome bitmap construction (1 bit per pixel) and wrap the whole package as PostgreSQL extension module. I share it at qrcode.tar.bz2.
Build
Please modify PG_CONFIG = /opt/pgsql/9.4/bin/pg_config in Makefile as necessary. Then make and make install.
Installation
Connect to a database then invoke sql command CREATE EXTENSION qr;
Usage SELECT qr('QR Code with PostgreSQL', 0, 0, 4);
Arguments:
Text to be encoded.
Error correction level (0 to 3).
Accepted model number (0 to 2).
Scale 4 means: a dot in QR image will be 4 pixel width and 4 pixel height.
It returns byte array representing monochrome bitmap. You can save it as a file or directly render it to HTML page.
Posted by Elie Bursztein, Anti-Fraud and Abuse Research and Nicolas Lidzborski, Gmail Security Engineering Lead
We’re constantly working to help make email more secure for everyone. These efforts are reflected in security protections like default HTTPS in Gmail as well as our Safer Email Transparency report, which includes information about email security beyond just Gmail.
To that end, in partnership with the University of Michigan and the University of Illinois, we’re publishing the results of a multi-year study that measured how email security has evolved since 2013. While Gmail was the foundation of this research, the study’s insights apply to email more broadly, not unlike our Safer Email Transparency report. It’s our hope that these findings not only help make Gmail more secure, but will also be used to help protect email users everywhere as well.
Email security strengthens, industry-wide
The study showed that email is more secure today than it was two years ago.
Here are some specific findings:
Newer security challenges and how we can address them
Our study identified several new security challenges as well.
First, we found regions of the Internet actively preventing message encryption by tampering with requests to initiate SSL connections. To mitigate this attack, we are working closely with partners through the industry association M3AAWG to strengthen “opportunistic TLS” using technologies that we pioneered with Chrome to protect websites against interception.
Second, we uncovered malicious DNS servers publishing bogus routing information to email servers looking for Gmail. These nefarious servers are like telephone directories that intentionally list misleading phone numbers for a given name. While this type of attack is rare, it’s very concerning as it could allow attackers to censor or alter messages before they are relayed to the email recipient.
While these threats do not affect Gmail to Gmail communication, they may affect messaging between providers. To notify our users of potential dangers, we are developing in-product warnings for Gmail users that will display when they receive a message through a non-encrypted connection. These warnings will begin to roll-out in the coming months.
All email services—Gmail included—depend on the trust of their users. Partnering with top researchers helps us make the email ecosystem as a whole safer and more secure for everyone. Security threats won’t disappear, but studies like these enable providers across the industry to fight them with better, more powerful protections today and going forward.
[This work was made possible thanks to the contribution of many Googlers including Vijay Eranti, Kurt Thomas, John Rae-Grant, and Mark Risher.]
Redes definidas por software (SDN) e Internet das Coisas (IoT) são importantes tendências tecnológicas que certamente afetarão o futuro das redes. Como tal, elas acabam atraindo a maior parte das atenções do setor em geral. Não há motivos para não dedicar algum tempo à considerações e ao planejamento de tendências de ponta como essas, que estão surgindo ou por surgir no horizonte, algo inteligente a se começar a fazer.
No entanto, em retrospectiva, existem problemas muito mais concretos que afetam as redes empresariais que ainda precisam ser abordados para que se possa manter a empresa funcionando sem problemas. Especificamente, nuvem, traga seu próprio dispositivo (BYOD), IPv6, VDI (Virtual Desktop Infrastructure) e tecnologia sem fio são importantes tendências que afetam as redes hoje e que ainda não foram totalmente solucionadas pela maioria das organizações.
A seguir, apresentamos um resumo dos principais desafios que cada uma dessas tendências apresentam e sugestões de como os engenheiros de rede podem superá-los.
Nuvem
Os engenheiros de rede enfrentam hoje três principais desafios relacionados à nuvem.
O primeiro é a segurança. É fácil para os engenheiros de rede caírem na armadilha de pensar que, como não são diretamente responsáveis pela segurança do provedor de serviço de nuvem, não podem mais ser responsabilizados em caso de uma violação relacionada à segurança dos dados de suas organizações enquanto estiverem em trânsito para o provedor de nuvem ou a partir dele. Seria um erro.
Isso também está relacionado ao segundo principal desafio da nuvem em relação às redes: falta de visibilidade da movimentação e do comportamento do tráfego de dados depois que deixam o firewall. Embora isso tenha implicações de segurança, não saber como o tráfego está sendo roteado e otimizado pelo provedor de nuvem também tem implicações significativas tem termos de desempenho.
O terceiro principal desafio da rede decorrente da nuvem está relacionado à largura de banda. Planejar as necessidades de largura de banda de serviços de nuvem conhecidos já é difícil o suficiente. Por exemplo, no contexto da passagem para serviços de e-mail baseados na nuvem, o Microsoft Office365 restringe a quantidade de dados de e-mail que pode ser migrada de cada vez. Assim, se você tiver três (ou 300) terabytes de dados de e-mail, a migração não poderá ser feita em um final de semana. Ainda mais difícil é planejar o desconhecido – uso do armazenamento online pelos usuários finais, compartilhamento de arquivos e outros serviços baseados em nuvem sem o conhecimento da TI. É claro que isso também tem repercussões na segurança – serviços de nuvem gratuitos ou “freemium” estão se tornando mais um aspecto do fenômeno da TI das sombras.
Infelizmente, não existe uma solução mágica quando se trata de superar esses desafios. Para reforçar a segurança, a melhor coisa que os profissionais de TI podem fazer é compreender e ter muita clareza quanto aos riscos de segurança mais preocupantes, aos regulamentos de segurança corporativa que precisam ser seguidos e às certificações de conformidade que devem ser obtidas com relação à segurança dos dados. Em seguida, eles devem trabalhar com o provedor de serviços de nuvem para, em conjunto, criarem um plano que atenda a tais requisitos. Isso também pode incluir a mudança da definição de “borda da rede” e adicionar ferramentas que aumentam as informações sobre as novas áreas, como adição de coletores de logs de segurança às conexões da WAN, voltadas para a Internet.
Quanto ao desempenho, simular a experiência do usuário é um bom começo. O NetFlow e a inspeção profunda de pacotes também podem ajudar em determinadas circunstâncias. Para conter os problemas de largura de banda (e segurança) de serviços de nuvem não autorizados, é claro que serviços específicos podem ser bloqueados em toda a empresa, mas os administradores devem garantir que contam com a adesão da gerência, além de oferecer serviços alternativos – afinal, existe um motivo pelo qual os usuários finais buscaram o serviço de nuvem na “sombra”.
Traga seu próprio dispositivo (BYOD)
Não mais considerado um privilégio opcional, agora os funcionários de organizações de qualquer porte esperam poder conectar os dispositivos pessoais de sua escolha às redes de suas organizações de alguma forma. Assim, o BYOD trouxe consigo toda uma gama de desafios para o departamento de TI desde que começou a ganhar popularidade nos últimos anos. Agora os administradores de rede devem pensar em cada funcionário como pelo menos dois dispositivos que se conectam às redes e sistemas da empresa – provavelmente ainda mais –, o que pelo menos dobra a preocupação com a segurança, com a complexidade da rede em geral e com o volume e a densidade das conexões. De fato, ambientes de rede já complexos são submetidos a uma pressão ainda maior à medida que os usuários acessam serviços tanto dentro quanto fora do firewall da rede, estendendo recursos que podem não ter sido provisionados corretamente.
Para superar esses desafios, os engenheiros de rede precisam de ferramentas de inspeção de pacotes, bem como de soluções de monitoramento de largura de banda ou SNMP. Também é importante rastrear e gerenciar os endereços IP dos dispositivos, bem como monitorar os recursos que esses dispositivos estão acessando para garantir que o desempenho dos aplicativos ainda seja rápido e eficiente e, ao mesmo tempo, ficar de olho em anomalias que possam indicar uma violação. Idealmente, você deve buscar uma visão holística de todos esses recursos, também conhecidos como pilha de aplicativos.
IPv6
A transição iminente do IPv4 para o IPv6 vem gerando uma discussão contínua há anos: os endereços IPv4 da Internet estão se esgotando e não está imune à obsolescência; já o IPv6 facilitará em grande medida o gerenciamento dos serviços de rede e assim por diante… Apesar disso, os endereços IPv6 ainda representam apenas uma pequena porcentagem da Internet de hoje. E provavelmente a adoção continuará lenta – principalmente devido aos custos associados à transição.
No entanto, os administradores de rede não devem se enganar com isso, já que é altamente provável que o IPv6 já esteja habilitado e operacional em muitas organizações – saibam eles disso ou não. E isso pode criar “redes das sombras” de dispositivos habilitados para IPv6 não gerenciados que podem representar riscos significativos à segurança – os pacotes IPv6 permanecem relativamente desconhecidos e não monitorados, e dispositivos que usam endereços IPv6 podem conter falhas de segurança, que podem passar despercebidas pelos administradores de rede. Além disso, até mesmo os endereços IPv6 conhecidos podem causar maior tensão nas redes ao tomarem mais rotas, muitas vezes inesperadas.
Para superar esses desafios do IPv6, os administradores de rede devem primeiro tentar simplificar todo o processo de gerenciamento de endereços IP – tanto para IPv4 quanto para IPv6 –, a fim de eliminar conflitos e interrupções da rede, rastrear ativos críticos, garantir a segurança da rede e fornecer relatórios baseados em uma grande variedade de parâmetros, que incluem o status dos endereços IP. Também é importante identificar e documentar dispositivos que já oferecem suporte a IPv6, mapear o espaço IPv4 existente e o espaço IPv6 proposto e documentar os dispositivos que precisam ser adicionados/substituídos para proporcionar suporte a IPv6.
Por fim, verdadeiros firewalls de aplicativos podem desenredar a conversa de dispositivos de forma mais sorrateira, colocar o gerenciamento de endereços IP sob controle e preparar os equipamentos de rede para o IPv6. Também podem classificar e segmentar o tráfego de dispositivos, implementar uma qualidade de serviço eficaz para garantir que o tráfego crítico de negócios tenha reserva dinâmica e, logicamente, monitorar o fluxo.
VDI
O principal desafio enfrentado pelos engenheiros de rede quando se trata de VDI é a mudança no fluxo de dados da empresa: máquinas físicas executam áreas de trabalho virtuais, com cada uma delas exigindo mais acesso a servidores, e-mail ou aplicativos, quando como acontece em muitas empresas que usam VDI, um cliente de softphone é introduzido. A adição dos dados de voz aos aplicativos de área de trabalho pode dificultar para os administradores de rede manter o fluxo correto dos dados e gerenciar o tráfego das áreas de trabalho virtuais dos funcionários.
No gerenciamento de um ambiente de VDI, o monitoramento da rede cruza-se tanto com o monitoramento da virtualização quanto com o dos aplicativos. É vantajoso para os engenheiros de rede saber se as sessões virtuais dos usuários estão funcionando sem problemas e se estão sob controle. Muitas das ferramentas e técnicas para lidar com o BYOD podem ajudar também neste caso – em especial, a visibilidade de ponta a ponta da pilha de aplicativos.
Tecnologia sem fio
A tecnologia sem fio não poderia ser mais madura. Na verdade, ninguém mais quer pagar para cabear um amontoado de cubículos. O baixo custo de compra e gerenciamento de equipamentos sem fio faz dele a solução óbvia para quase qualquer ambiente, mas cria desafios relacionados à adequação da intensidade do sinal, ao gerenciamento de endereços IP e aos canais para mobilidade física. A habilitação da tecnologia sem fio também pode sair rapidamente do controle, fazendo com que grandes ambientes sem fio criem um novo tipo de problema. Um cliente da SolarWinds que cuida da TI de uma grande universidade descreveu essa experiência com a tecnologia sem fio da seguinte maneira:
De repente, você está rastreando 187 mil dispositivos. Diferentemente de um escritório, onde a maioria dos usuários perambula entre mesas e salas de conferência de modo previsível, eu tenho milhares de estudantes que se deslocam majestosamente pelo campus como uma manada de gnus cruzando o Serengueti.
O que é preciso para superar de uma vez por todas os desafios associados à tecnologia sem fio são ferramentas como gerenciamento de endereços IP, mapas de calor sem fio, rastreamento de dispositivos de usuário e pontos de acesso sobrecarregados. O problema é que, tradicionalmente, o custo de muitas dessas ferramentas é excessivo, mas há novas opções que estão abrindo as portas à implementação dessas tecnologias.
Conclusão
Os engenheiros de rede devem refletir sobre como e quando suas organizações podem fazer a transição para a SDN. Eles devem planejar como lidarão com a IoT e com a onda de conexões de todos os tipos que ela traz consigo. Mas não devem se esquecer dos problemas que afetam suas redes hoje. A maior parte deles apenas começou a lidar com os desafios impostos à rede pela nuvem, BYOD, IPv6, VDI e tecnologia sem fio. Com as sugestões descritas aqui para ampliar essa abordagem, suas redes estarão prontas para enfrentar o futuro.
Mensagem do anunciante:
Compre SSL e concorra à R$10.000,00 em produtos Site Blindado. Participe agora. Certificado Digital SSL
Há algum tempo, quando eu perdi um commit usando git reset –HARD <commit-id> (shit happens), eu decidi que era hora de estudar o GIT novamente. Este artigo não tem a intenção de trazer coisas básicas sobre GIT, mas algumas coisas que descobri nessa minha pesquisa e que provavelmente você (ainda) não sabe.
Para recuperar um commit do reset – HARD, basta usar git reflog.
Diff entre branches: se você quiser checar qual é a diferença entre duas branches, você pode simplesmente digitar: git diff branch1..branch2.
Mostrar um commit procurando por regex: usando git show :/consertos, você pode achar o último commit cuja mensagem contenha a string que passou. Neste caso, consertos.
Para dar um checkout em uma branch, rebase e merge para master, basta fazer esta mágica: git rebase HEAD feature && git rebase HEAD @{-2}.
Git stash: se você não pode fazer um commit porque você ainda não terminou o seu trabalho, e alguma coisa urgente apareceu, você pode usar git stash para salvar aquelas mudanças e comitar suas tarefas urgentes, e então git stash pop para trazer suas coisas de volta.
Aliases: está cansado de digitar checkout milhares de vezes? Vá em frente e: git config –global alias.co checkout. Agora, você pode fazer checkout para master usando: git co master.
Renomeando uma branch local: com git branch -m nome-antigo nome-novo, você pode facilmente renomear um branch local.
Busca por um autor: você pode procurar por um commit pelo autor usando git log –author=Matheus.
Status com opções: a maioria das pessoas apenas usa git status, mas você pode passar argumentos para mudar a forma como o status atual é mostrado. Com o git status –sb, você terá um output como estes:
## master
M Gemfile
M Gemfile.lock
M app/controllers/home_controller.rb
M app/views/home/index.html.erb
Aqui estão algumas das fontes que eu usei para o artigo:
by ARMINAS ZUKAUSKAS, FREELANCE SOFTWARE ENGINEER @ TOPTAL
Every once in a while PHP developers are charged with tasks that require them to extend the functionalities of legacy projects, a task that often includes building REST APIs. Building a REST API for PHP-based projects is challenging, but in the absence of proper frameworks and tools, it can also be a particularly difficult goal to get right. In this article, Toptal engineer Arminas Zukauskas shares his advice, with sample code, on how to build a modern structured REST API around existing legacy PHP projects.
It's no surprise that more and more people, from all kinds of backgrounds, are deciding to learn to code. But, each person who tackles the task is soon faced with an unpleasant reality: Learning to program is hard. Contrary to expectations, the feeling of "I don't get it," may persist unabated long into the journey, making once bright-eyed beginners feel hopeless, lost, and ready to give up.
The moral of the story is this: Be prepared. The path to programmer paradise is a long one, and without the right mindset at the beginning, it can quickly lose its appeal. In this article, I'll attempt to give you some guidance on what to expect on your journey, how best to go about it, and what tools and resources you may find helpful along the way.
Trabalho em equipe e muitas reuniões. Falando assim, até parece alguma receita famosa para o sucesso de uma empresa. Mas, na prática, esses dois são quase rivais. Tudo porque a reunião que deveria ser o ápice do compartilhamento de ideias e descoberta de soluções acaba se tornando um evento que toma horas e nem sempre [...]
O Philipe Fatio publicou um belo, longo e bem exemplificado artigo demonstrando como configurar o cliente psql para usar sua linha de comando para interagir com o PostgreSQL. (via phili.pe - “PostgreSQL on the Command Line · Philipe Fatio”)
Posted by Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard Emily Schechter, Safe Browsing Program Manager and Menace to Malware Ke Wang, Safe Browsing Engineer and Developer of Defense
You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.
To demystify these warnings, we’re launching a Site Status section in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.
The new Site Status section of the Transparency Report replaces our previous Safe Browsing diagnostic page. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host unwanted software. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via Search Console; if you use Google Analytics, we’ll also warn you there if your site has malware on it. (Webmasters, check the help center to learn how to remove malware from your websites.)
We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the Transparency Report to experience it yourself.
Tom Lane just posted a terrific piece of advice about how to find what's causing an error you don't know the source of, which is worth quoting:
What I would recommend is that you get the data onto a non-production machine where you can play around a bit more. One thing you could do then is run a build with debug symbols, attach to the backend process with gdb, and set a breakpoint at "errfinish". Then provoke the error, and capture a backtrace from the call to errfinish. That would greatly narrow things down, though it might not be enough to isolate the bug immediately.
I normally like to have debuginfo packages installed even on production machines so I can do this sort of thing quickly.
Another thing you can try in a non-production environment is to run your test case against a build with assertions enabled and see if it trips an assertion failure. That's often a quick way of finding where problems are occurring.
Há algumas de suas virtudes que nunca seriam descobertas se não fossem as provações que você experimentou.
(C. H. Spurgeon)
Uma fé provada é uma fé fortalecida. Por meio das provas aprendemos a conhecer nossas próprias debilidades, mas também a fidelidade de Deus, Seus ternos cuidados, mesmo nas dificuldades que nos envia, para que possamos atravessá-las com Ele.
(John Nelson Darby)
Deus, envia-me para qualquer lugar, desde que vás comigo. Coloca qualquer carga sobre mim, desde que me carregues, e desata todos os laços de meu coração, menos o laço que prende o meu coração ao teu.
(David Livingstone)
Muitos de nós estão buscando seus próprios objetivos, e Jesus Cristo não pode servir-se de nossa vida. Se nos entregamos totalmente a Jesus, não temos mais objetivos próprios.
(Oswald Chambers)
Confie nisto: o trabalho de Deus feito da maneira de Deus nunca sofrerá falta de recursos.
(J. Hudson Taylor)
Não coloque a leitura da Bíblia de lado até encontrar seu coração aquecido… Deixe que ela não apenas o informe, mas o inflame.
(Thomas Watson)
Quem entregou Jesus para morrer? Não foi Judas, por dinheiro; nem Pilatos, por medo; nem os judeus, por inveja; mas o Pai, por amor!
Today we will talk about Content Security Policy and how it can help your to improve security of your web applications.
What is Content Security Policy?
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.
Usage example
In many cases many web applications do not need CSP, if they do not store and show some HTML/CSS data that user inputs. But in case when your web application should show some custom user content (html pages with css, some files, etc), you need to have good filter engine, which will remove any inline JavaScript code (<script> tags, onclick from <a> links, etc). For example, if you build web mail client, you cannot remove all HTML from email tags, because email will be broken and customer will not be happy to read broken email. So you need to prevent JavaScript inline code injection by this HTML email for hackers with any posibility.
How to use it
Instead of blindly trust to everything that a server delivers, CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content, and instructs the browser to execute or render only resources from those sources. Even if an attacker can find a hole through which to inject script, the script won’t match the whitelist, and therefore won’t be executed.
For example, if we trust cdn.example.com to deliver valid code, and we trust ourselves to do the same, let’s define a policy that only allows script to execute when it comes from one of those two sources:
The "default-src" is the default policy for loading content such as JavaScript, Images, CSS, Font's, AJAX requests, Frames, HTML5 Media. See the Source List for possible values
script-src
'self' js.example.com
Defines valid sources of JavaScript
style-src
'self' css.example.com
Defines valid sources of stylesheets
img-src
'self' img.example.com
Defines valid sources of images
connect-src
'self'
Applies to XMLHttpRequest (AJAX), WebSocket or EventSource. If it is not allowed, the browser emulates a 400 HTTP status code
font-src
font.example.com
Defines valid sources of fonts
object-src
'self'
Defines valid sources of plugins, eg <object>, <embed> or <applet>
media-src
media.example.com
Defines valid sources of audio and video, eg HTML5 <audio>, <video> elements
child-src (old version frame-src)
'self'
Defines valid sources for loading frames
sandbox
allow-forms allow-scripts
Enables a sandbox for the requested resource similar to the iframe sandbox attribute. The sandbox applies a same origin policy, prevents popups, plugins and script execution is blocked. You can keep the sandbox value empty to keep all restrictions in place, or add values: allow-forms allow-same-origin allow-scripts, and allow-top-navigation
report-uri
/report
Instructs the browser to POST a reports of policy failures to this URI. You can also append "-Report-Only" to the HTTP header name to instruct the browser to only send reports (does not block anything)
Source List
All of the directives that end with “-src” support similar values known as a source list. Multiple source list values can be space seperated with the exception of “*” and “none” which should be the only value.
Source Value
Example
Description
*
img-src *
Wildcard, allows anything
'none'
object-src 'none'
Prevents loading resources from any source
'self'
script-src 'self'
Allows loading resources from the same origin (same scheme, host and port)
data:
img-src 'self' data:
Allows loading resources via the data scheme (eg Base64 encoded images)
domain.example.com
img-src img.example.com
Allows loading resources via the data scheme (eg Base64 encoded images)
*.example.com
img-src *.example.com
Allows loading resources from the any subdomain under example.com
https:
img-src https:
Allows loading resources only over HTTPS on any domain
'unsafe-inline'
script-src 'unsafe-inline'
Allows use of inline source elements such as style attribute, onclick, or script tag bodies (depends on the context of the source it is applied to)
'unsafe-eval'
script-src 'unsafe-eval'
Allows unsafe dynamic code evaluation such as JavaScript eval()
Usage example
As you can see we can combine all this values for “Content Security Policy” header and create most flexible rule for our app. Let’s create a little example. I am using Rails app with global gem to make it work with “Content Security Policy”. First I create global yml file with configuration (config/global/content_security_policy.yml):
After restarting of the Rails app you should see “Content Security Policy” header in any HTTP response from your app. If someone will try to inject JS code in your app (onclick in link), it will get such JS error:
Subresource Integrity
Many sites uses a content delivery network (CDN) to serve static assets such as JavaScript, CSS, and images to our users. The CDN makes web browsing faster by delivering assets from data centers that are geographically close to the end user and by using hardware and software that is optimized for quickly serving static assets. The compromise of a major CDN could be devastating to the security of the hundreds of thousands of sites that depends on it. If our CDN were to be compromised, it could be used to serve malicious JavaScript to all our users, rendering our many XSS mitigations and transport security useless. Content Security Policy is invaluable for protecting against traditional XSS attacks, but it provides no defense against an attacker who can control assets served from whitelisted sources.
To prevent this type of attack, you can use Subresource Integrity browser technology. The website author includes an integrity attribute on JavaScript and CSS tags, specifying the cryptographic digest of the resource being loaded from the third party. When the browser fetches the resource, it computes the file’s digest and compares it with the value from the integrity attribute. If the values match, the resource is loaded. Otherwise, the browser refuses to load the resource. Example:
If you are using Rails with sprockets-rails gem (version >= 3), you can add integrity key to your javascript_include_tag helper to activate this feature:
More info about Subresource Integrity you can read in this article.
Browser Support
CSP is designed to be fully backward compatible; browsers that don’t support it still work with servers that implement it, and vice-versa. Browsers that don’t support CSP simply ignore it, functioning as usual, defaulting to the standard same-origin policy for web content. If the site doesn’t offer the CSP header, browsers likewise use the standard same-origin policy.
Header
Chrome
FireFox
Safari
Internet Explorer/Edge
Content-Security-Policy (1.0)
25+
23+
7+
-
X-Content-Security-Policy
-
4.0+
-
10+ (limited)
X-Webkit-CSP
14+
-
6+
-
As you can see in this table, CSP have good support for major browsers. Internet Explorer 10-11 and Edge have partial support for CSP via the X-Content-Security-Policy header, but even then they only appear to support the optional “sandbox” directive. More info on caniuse.
Summary
Content Security Policy can provide the additional security layer for your apps against XSS and data injection attacks (XSS is in third place in the ranking of the key risks of Web-based applications under the 2013 OWASP).
That’s all folks! Thank you for reading till the end.
A shell Linux permite aos utilizadores realizarem as mais diversas tarefas. Apesar de nativamente estarem disponíveis já vários comandos, os utilizadores podem também instalar ferramentas adicionais que poderão facilitar determinadas acções. Hoje deixamos aqui...
Most Postgres operators and informed users are aware that it uses MVCC for storage. One of the main drawbacks of this versioning mechanism is related to tuple reuse. In order to reuse the space, VACUUM must complete a cycle on the table. Unfortunately this isn’t always possible to “optimize” for larger tables. How so?
If a large table needs to have a calculated column added, or some other bulk query updates a large portion of its content, a large fragment of the table is now empty space. This can be painful in a warehouse scenario, but it can be even more disruptive if a table that once fit in memory is now causing endless disk paging on a transaction-heavy system. It can mean the difference between a server being driven into the ground by IO requests, or one that runs smoothly with an order of magnitude more requests.
Take, for instance, a product mapping table:
DROP TABLE IF EXISTS product_map;
CREATE TABLE product_map
(
map_id SERIAL PRIMARY KEY,
product_id INT NOT NULL,
vendor_id INT NOT NULL,
product_code TEXT NOT NULL
);
INSERT INTO product_map (product_id, vendor_id, product_code)
SELECT a.id, b.id, 'P' || abs(100000 - a.id)::TEXT
FROM generate_series(1, 100000) a(id),
generate_series(1, 10) b(id);
ANALYZE product_map;
This architecture is fairly common when mapping vendor product codes with internal tracking numbers. The approach inoculates us from vendor dependency or collisions caused by two vendors using the same ID system. These tables don’t tend to be very large, and here is how Postgres sees ours:
In this case, we have a million mappings with ten vendors and a made up string product code. Imagine for a moment that a few vendors changed their code systems, or we made a mistake loading the table. Now we need to update a large portion of the table. To simulate this, here’s an update statement that will modify half of the rows to have different product code values. We’ll also check the size of the table following the update.
UPDATE product_map
SET product_code = 'D' || abs(50000 - product_id)
WHERE vendor_id > 5;
SELECT pg_size_pretty(pg_relation_size('product_map'));
pg_size_pretty
----------------
75 MB
This is where our story begins. The table is now 50% larger than before, but contains the same number of rows. This won’t affect index usage, but any query that reads the entire table is in trouble. Not only does this slow down VACUUM, but even something as simple as a daily report would have to work that much harder to summarize the contents of this table. Ad-hoc jobs will also take longer to complete.
This is fine with our measly million row table, but imagine a content map instead of a product map. Every book, song, movie, or piece of media supplied by an outside source could have multiple entries in this table. That inflates our row count into the tens or hundreds of millions. If 50% of that were empty space due to a bulk operation, we could be in trouble.
This kind of thing happens every day. If a company doesn’t have a Postgres DBA, it might take them by surprise when a nicely running system becomes a stuttering monstrosity because they changed some data the previous night. Not only is VACUUM using disk cycles trying to keep up with maintaining a multi-million row table, but the table no longer fits in memory and is causing massive IO thrashing.
The only permanent escape is to fix the table. There are two mainstream ways to accomplish this that are supported by SQL syntax. We can either CLUSTER the table by reorganizing it by one of the indexes, or use VACUUM FULL to rebuild it. Here’s what the table looks like after using CLUSTER on it:
CLUSTER product_map_pkey ON product_map;
SELECT pg_size_pretty(pg_relation_size('product_map'));
pg_size_pretty
----------------
50 MB
There, back to normal! Sadly there are some major caveats to using this approach:
Both methods require an exclusive table lock for the duration of the process.
Both are serial processes.
This is primarily a concern because such an exclusive lock prevents even reading the table until the command completes. If there’s no available maintenance window to accommodate potentially hours of locking a table, that’s a huge complication. That drawback alone could prevent fixing the table in all but the most dire of circumstances. This also makes Postgres look bad to anyone who just wants something that works; MySQL doesn’t have such a caveat after all.
This is all related to how the commands actually function. Here’s a quick summary of what’s going on:
Create a copy of the table as an empty framework.
Copy the active table rows from the old table.
Create each index.
Atomically rename the table to replace the old one.
They do all that work behind the scenes so it resembles a single operation. Most of these steps are either destructive or modify the underlying table structure in some way. So long as the table is in flux, it’s not safe to use it. So, we wait. We wait for the rows to be copied. We wait for the indexes to be recreated based on the new page locations. We wait.
The problem is that the index creation step is serial. If there were six indexes, Postgres would dutifully create each, one after the other. That’s something that could be done in parallel, but not in current versions of Postgres. So if we have a table with one hundred million rows and four indexes, that could be several hours of rebuilding, during which, the table is completely unusable.
Enter pg_repack, a fork of the older pg_reorg project. It boasts the ability to reorganize a table without an exclusive lock. As an added benefit, it can rebuild indexes in parallel, drastically reducing the time spent on this step. Now we have an external tool that not only allows us to do maintenance after bloating a table, but finishes quicker too.
This is particularly relevant with operations that can’t be streamlined. The UPDATE statement we used might be followed up by an INSERT for example. Well, VACUUM doesn’t work in transactions, so we would have to fragment the job to specifically use two separate transactions separated by an explicit VACUUM. Yet the very nature of an RDBMS makes this an undesirable approach. Transactions and atomic operations protect data integrity, yet we have to manually circumvent this in order to avoid unnecessary table bloat.
Having a non-invasive maintenance tool like this is critical to Postgres. So critical that whatever magic it uses should be part of the core engine. MVCC, despite its benefits, makes maintenance an integral part of operating a Postgres database. When performing that maintenance becomes invasive, disruptive, or requires circumventing normal operation, people notice. It’s one of the few remaining hurdles to mass adoption Postgres still faces.
Without a postgres DBA on staff to get a project beyond these issues, the perception becomes that it’s a pain in the neck to use. Unfortunately, Postgres DBAs are in short supply. That is, after all, why I’m writing these articles.
A alma desta Revista e do Departamento de Seleção Acadêmica da UERJ se chama Elisabeth Hadad Murad – e esta frase se encontra no presente do indicativo para melhor indicar que Beth Murad, como é mais conhecida, se encontra viva, vivíssima!, na memória de todos aqueles que já trabalharam e conviveram com ela.
Send to Kindle
