Habilitando o mod_rewrite e htaccess do Apache

Saiba como habilitar mod_rewrite e o uso do arquivo .htaccess do Apache

Antes de habilitar o uso do arquivo .htaccess, é importante verificar se o mod_rewrite está habilitado no Apache, para isso, abra o Terminal do Ubuntu, digite a linha de comando abaixo e pressione a tecla Enter.

cd /etc/apache2/mods-enabled

O comando ‘cd’, seguido do endereço de um diretório, serve para alterar o diretório atual. O diretório ‘mods-enabled’, contém uma lista dos módulos habilitados no Apache, verifique se existe ‘rewrite.load’ digitando ‘ls’ e pressionando a tecla Enter. O comando ‘ls’, irá listar todos os arquivos contidos no diretório.

 

Se após exibir a lista com os módulos do Apache houver um arquivo de nome 'rewrite.load', significa que o mod_rewrite está habilitado no Apache e você poderá reescrever URL, caso isto não seja exibido, significa que o módulo não está habilitado, para habilitá-lo digite no Terminal a linha de comando abaixo:

sudo a2enmod rewrite

Agora que já carregamos o mod_rewrite, finalmente poderemos habilitar o uso do arquivo .htaccess. Para habilitá-lo, é necessário editar o arquivo de configurações do Apache, na versão do Apache que usei para criar este tutorial (2.4.7) fica no seguinte endereço:

/etc/apache2/apache2.conf

Abra o arquivo 'apache2.conf' com seu editor de código favorito utilizando o comando 'sudo', para que você tenha permissão de editar o arquivo como administrador, veja um exemplo abaixo:

 

Após abrir o arquivo de configurações citado acima, localize algo parecido ou igual às linhas abaixo:

 <Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
 </Directory> 

Agora, altere a linha 'AllowOverride None' para 'AllowOverride All', salve o arquivo, feito isso o arquivo .htaccess já estará habilitado na configuração do Apache, porém, para que as alterações façam efeito, é necessário reiniciar o servidor Apache, para isso, digite no Terminal a linha de comando abaixo:

sudo /etc/init.d/apache2 restart

Feito isto, o servidor Apache será reiniciado e as novas configurações começarão a ser utilizadas.

 

Fonte: http://rodrigomarques.me/tutorial/habilitando-mod_rewrite-e-htaccess-apache-ubuntu

Dirty Cow - Descoberto um bug antigo no linux

Recentemente foi descoberto um bug no kernel do linux que foi chamado de dirty cow, o bug já foi resolvido porém sistemas que não foram atualizados como: servidores, celulares com android que não tem mais atualização continuam com o bug portanto atualize seu sistema.

Revisitando a Orientação a Objetos: encapsulamento no Java

Façamos uma aposta. Tenho certeza que você, ao ver a classe abaixo, consegue perceber um problema nela:

class Pedido {   public String comprador;   public double valorTotal;   // outros atributos }

Sim. Os atributos estão todos públicos! Isso vai exatamente contra uma das nossas primeiras lições quando aprendemos Java: atributos devem ser privados e precisamos de getters e setters para acessá-los. Vamos então fazer essa mudança no código.

Como não aprender orientação a objetos: o excesso de ifs

Aglomerados de ifs aparecem com frequência, e chegam até a ter um aspecto engraçado. Em alguns casos poder dar a impressão de que estamos usando orientação a objetos, já que cada cláusula costuma envolver a invocação de um método, dependendo do tipo do objeto. Infelizmente, essa sensação é falsa, e chegou até a gerar o conhecido movimento anti if campaign na internet.

Princípios do Código Sólido na orientação a objetos

Quer ver eu te fazer uma pergunta que te fará pensar o resto do dia? Como olhar para um código e dizer que ele é de qualidade? Essa é sem dúvida uma pergunta que todos nós tentamos responder todos os dias.
Como bem sabemos, podemos olhar trechos de código por vários pontos de vista diferentes: o quão complexo ele é (muitos ifs, muitas linhas), o quão coeso ele é, o quão acoplado ele é, etc. Sendo tão difícil pensar em qualidade de código, vamos tentar mudar o nível. Quando que um sistema tem qualidade interna, ou seja, do ponto de vista de código?
Nós gostamos de sistemas que sejam fáceis de mexer. Ou seja, quando o usuário final pede uma mudança, é relativamente fácil de localizar onde ela deve ser feita e, depois de feita, não há propagação de problemas. 
Para que isso aconteça, o código deve estar bem modularizado; cada classe deve ter sua responsabilidade, e as relações entre elas devem estar bem definidas. É aqui que entra a ideia do código sólido, princípios criados por Michael Feathers e popularizados pelo Uncle Bob há bastante tempo.
A brincadeira com o termo “código sólido” vem do acrônimo SOLID. Cada letra representa um dos 5 princípios de orientação a objetos que nos ajudam a manter o código organizado:

TDD

Test-Driven Development

Test-Driven Development (TDD), sem dúvida, tornou-se uma das práticas mais populares entre desenvolvedores de software. A ideia é bem simples: escreva seus testes antes mesmo de escrever o código de produção. Mas por quê a ideia parece tão boa? Ao escrever os testes antes, o desenvolvedor garante que boa parte (ou talvez todo) do seu sistema tem um teste que garante o seu funcionamento. Além disso, muitos desenvolvedores também afirmam que os testes os guiam no projeto de classes do sistema.
Mesmo com toda a indústria gritando as vantagens para quem queira ouvir, ainda existem mitos em torno da prática. O desenvolvedor agora vai gastar mais tempo escrevendo testes do que programando? Escrever testes dá trabalho. Testes manuais não são mais produtivos? TDD deve ser feito 100% do tempo?
Este guia visa responder essas e outras perguntas para você, que é desenvolvedor, gerente, ou está de alguma forma relacionado ao processo de desenvolvimento de software.

A importância do desenvolvimento orientado a teste ou TDD

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).