Os perigos do Compass!

Publicado em Publicado por gserrano

Tenho trabalhado muito com compass ultimamente e para falar a verdade não consigo mais trabalhar diretamente no .css, a estrutura e legibilidade que ele proporciona são excelentes. Mas tenho percebido um problema nos meus códigos que nunca vi ninguém falar antes pelos blogs e afins, bom vamos ao cenário:

Imagine que você tem que fazer a seguinte tela:

No compass você fara algo assim:

a, .address{

 display: inline-block;
 padding: 30px 15px;
 border: solid 1px #c3c3c3;
 margin-right: 10px;
 width: 200px;
 text-align: center;
}

Até então nada diferente de um css normal, mas então o design muda e fala que o endereço agora será negrito e vermelho, colocamos a tag strong no html e vamos la no css estilizar o strong para vermelho:

No compass você fara algo assim:

a, .address{
 display: inline-block;
 padding: 30px 15px;
 border: solid 1px #c3c3c3;
 margin-right: 10px;
 width: 200px;
 text-align: center;
 strong{
  color: #ff0000;
 }
}

Ok, tudo certo, funcionando e minimizado por que temos sempre que pensar em performance certo? Mas espera um pouco vamos olhar o css criado pelo compass:

a, .address{
 display: inline-block;
 padding: 30px 15px;
 border: solid 1px #c3c3c3;
 margin-right: 10px;
 width: 200px;
 text-align: center;
}

a strong, .address strong{
 color: #ff0000;
}

Opa, a strong? Pois é muitas vezes com a comodidade que o compass nos oferece deixamos alguns códigos desnecessários passar e toda aquela nossa preocupação com a performance vai por aguá abaixo, claro que esse é um exemplo simples, mas pense naqueles grandes sites com mais de 20 arquivos .css e cada um com umas 700 linhas cada.

Shellscript para configurar domínio no Apache

Publicado em Publicado por gserrano

Quando você se torna freelancer ou empreendedor a automatização passa a ser um ponto ainda mais importante no seu dia a dia. Cada tarefa automatizada significa aumento de lucro a longo prazo, mais tempo para estudar ou descansar. 

Pensando em automatização, recomendo que você aprenda como usar o GruntJS neste ótimo artigo do Fernahhh.

Eu administro um servidor AWS para meus projetos e projeto de alguns clientes, é um Ubuntu Server com Apache. Configurar domínios, principalmente localmente no meu ambiente de desenvolvimento, se tornou uma tarefa comum e que levava alguns minutos.

A cada novo projeto que vou trabalhar (seja front-end ou back-end) eu aponto um novo domínio para meu servidor local (hosts) e crio um domínio no meu apache apontando para o repositório do projeto. 

Shellscript para automatizar a criação de domínios no Apache

Resolvi utilizar shellscript para automatizar a criação de domínios no Apache. Encontrei um script e adaptei para a minha necessidade.

Este script rece um parâmetro, que é o domínio que será criado.

Exemplo:

sh create-site andafter.org

As ações do script:

  1. Cria os diretórios para o domínio
    1. /var/www/$dominio
    2. /var/www/$dominio/public
    3. /var/www/$dominio/logs
  2. Cria um arquivo de configuração com o nome do comínio em /etc/apache2/sites-available
  3. Cria um link simbólico para ativar o domínio (sites-enabled)

create-site.sh

!/bin/bash
################
# Script for creating Virtual Servers On Apache
# Check for the correct parameters
if [ $# -eq 0 ]; then
        echo 'Você precisa passar o domínio a ser criado como parâmetro'
        echo 'Uso: create-site gssolutions.com.br'
        exit 0
fi
# Assign Variables
SITE=$1
# Create the Directory which will contain your Virtual Site
if [ ! -d /var/www/$SITE ]; then
        mkdir /var/www/$SITE
        mkdir /var/www/$SITE/public
        mkdir /var/www/$SITE/logs
fi
# Create the Config file for your virtual site
echo "<virtualhost *:80="">"> /etc/apache2/sites-available/$SITE
echo    "# Admin email, Server Name (domain name) and any aliases"  >> /etc/apache2/sites-available/$SITE
echo    "  ServerAdmin [email protected]" >> /etc/apache2/sites-available/$SITE
echo    "  ServerName $SITE" >> /etc/apache2/sites-available/$SITE
echo    "  ServerAlias www.$SITE" >> /etc/apache2/sites-available/$SITE
echo    " ">>/etc/apache2/sites-available/$SITE
echo    "  # Index file and Document Root (where the public files are located)" >> /etc/apache2/sites-available/$SITE
echo    "  DirectoryIndex index.html" >> /etc/apache2/sites-available/$SITE
echo    "  DocumentRoot /var/www/$SITE/public" >> /etc/apache2/sites-available/$SITE
echo    "  LogLevel warn" >> /etc/apache2/sites-available/$SITE
echo    "  ErrorLog  /var/www/$SITE/logs/error.log" >> /etc/apache2/sites-available/$SITE
echo    "  CustomLog /var/www/$SITE/logs/access.log combined" >> /etc/apache2/sites-available/$SITE
echo "</virtualhost>" >> /etc/apache2/sites-available/$SITE
echo    "<directory \"="" var="" www="" $site="" public\"="">" >> /etc/apache2/sites-available/$SITE
echo    "   Options Indexes FollowSymLinks" >> /etc/apache2/sites-available/$SITE
echo    "   AllowOverride All" >> /etc/apache2/sites-available/$SITE
echo    "   Order allow,deny" >> /etc/apache2/sites-available/$SITE
echo    "   Allow from all" >> /etc/apache2/sites-available/$SITE
echo    "</directory>" >> /etc/apache2/sites-available/$SITE
# Create the Sym Link to enable your Virtual Site
if [ ! -L /etc/apache2/sites-enabled/$SITE ]; then
        ln -s /etc/apache2/sites-available/$SITE /etc/apache2/sites-enabled/
fi

Se você quiser pode adicionar ao final do script o comando para dar reload nas configurações do Apache.

Ilustra do “apache” é do ~pitx

Como encontrar o PHP.ini?

Publicado em Publicado por gserrano

Já tive problemas para encontrar o PHP.ini no MacOS, eu alterava as configurações do meu arquivo php.ini, reiniciava o meu apache e as mudanças não eram aplicadas.

Já imaginava que era isso, então descobri que eu estava alterando um php.ini que não estava sendo carregado pelo PHP na minha máquina.

Como descobrir onde está o PHP.ini?

Você pode criar uma página que exiba toda a configuração do PHP e exiba em seu navegador, para isso crie um arquivo com o seguinte:

<?
phpinfo();
?>

Coloque o arquivo em uma pasta acessível pelo seu Apache e abra ela no navegador, esta página exibe todas as configurações do seu PHP.

Procure por “configuration file” e lá estará o caminho (path) do arquivo de configuração carregado pelo PHP.

Descobrindo o php.ini no terminal

Se você tem acesso a um terminal pode exibir todas as informações do php.ini direto no terminal, para isso digite:

php -i

E para facilitar a identificação do caminho completo do seu arquivo de configuração do PHP (php.ini) execute o seguinte comando no terminal:

php -i | grep 'Configuration File'<br>

Espero ter te ajudado a encontrar o caminho do php.ini.

Graças ao google os artigos mais acessados do O Desenvolvedor são os que responsem dúvidas simples com respostas rápidas, quer saber mais sobre PHP? Leia também:

O que marcenaria me ensinou de front-end

Publicado em Publicado por gserrano

Fazia tempo que eu queria aprender e praticar algumas coisas a fim de mudar um pouco meu modo de pensar, escolhi meditação, marcenaria e bonsai. Arrumei tempo para estudar e praticar os três. Tentar aprender um pouco mais sobre marcenaria/construção foi um dos fatores que me levou a voluntariar no TETO.

Acho que foi no ZOFE sobre carreira em front-end que o Zeno e o Daniel (recomendo que você ouça todos os podcasts destes caras) fizeram uma comparação entre o trabalho de artesãos e dos desenvolvedores front-end: desenvolver um trabalho único e dedicar-se a entregar o melhor de si em uma “peça”, ou no nosso caso, a uma interface. 

Eu e a marcenaria

Apesar de ainda não saber praticamente nada de marcenaria ela já me ensinou bastante. Sei pregar, sei serrar, sei lixar. Tudo isso mais ou menos, e bem mais para menos.

Comecei a praticar faz pouco tempo e para começar resolvi reciclar, restaurar e pintar um caixote de feira para a Bia transformar em um criado mudo ou em um caixote para guardar coisas. Ela (ou o pai dela) já haviam arrumado o caixote e em um final de semana comprei lixas e resolvi começar.

Caixote de madeira

Quem sabe um dia?

Lixei uma vez e o caixote ficou bem mais bonito do que estava antes. Foi uma hora de calma, café e o cheiro de madeira. E neste ponto comecei a refletir sobre minha ansiedade (este era um dos motivos de eu procurar atividades offline) e fazer comparação com o desenvolvimento web e a marcenaria.

Depois de pouco mais de quase três horas de trabalho e muita lixa gasta, eu poderia considerar o caixote pronto. As partes internas lisas como nunca estiveram, os cantos arredondados (não é piada com front-end) e minhas mãos secas da lixa e pó. O resultado depois disso foi que o caixote ganhou outra cor, quase sem nenhuma “sujeira” externa visível e pronto para receber uma camada de verniz e se tornar parte da decoração de casa.

Já estava tarde, eu estava cansado, fui dormir e retomei o trabalho no dia seguinte.

Não comecei pela pintura, peguei novamente a lixa e vi detalhes que passaram despercebidos no dia anterior. Não hesitei em recomeçar a lixar, a melhorar o acabamento de algumas pontas e deixar tudo mais simétrico. Mais lixa, mais pó e o resultado melhor do que o anterior, repeti o ciclo algumas vezes, desta vez de forma mais rápida. 

Pintura e ferramentas

Satisfeito com o estado do caixote, fui verificar o que precisava para fazer a pintura. Desisti de passar apenas verniz e resolvi pintar a caixa.

Como eu não tinha a base correta para madeira usei uma outra base que, em teoria, deveria funcionar pois era bem parecida com a base para madeira (dizem…). 

Ficou horrível. Estraguei o caixote. 

A madeira “chupou” toda a tinta que eu passava, a cada passada o rolo secava e a madeira adquiria um esbranquiçado apático, bem pior do que quando estava apenas lixada.

O caixote esta lá, esperando para receber a finalização.

O que marcenaria me ensinou sobre front-end

Desde que comecei a trabalhar com o caixote fiquei pensando em escrever este texto e pensando em como paciência é uma virtude importante para um desenvolvedor, seja front-end ou back-end. 

Eu sei que posso entregar um projeto em cinco horas ou este mesmo projeto em quinze horas, e apesar dos resultados aparentarem ser “bem parecidos”, não é bem assim. 

Em meus projetos eu costumo sofrer de uma síndrome chamada “ansiedade de colocar no ar”, principalmente se tratando do And After. Por razões de negócio sou muito mais cuidadoso com o Eu Compraria, mas mesmo assim a ansiedade é uma complicada de lidar e acaba atrapalhando na qualidade e produtividade enquanto estou programando.

Se algo está “quase pronto” era comum três coisas acontecerem por aqui:

  1. Trabalhar mais que 10 horas diárias
  2. Não conseguir focar em outra coisa senão o projeto que quero lançar
  3. Preciso lançar hoje

Identificar o problema é o primeiro passo para lidar com ele, e lixar, lixar e lixar me ajudou a controlar um pouco a ansiedade (provavelmente meditação e estar cultivando bonsais também ajudaram).

Aprendi a ser um desenvolvedor com uma qualidade de entrega melhor do que a que eu estava acostumado, controlo um pouco melhor a ansiedade que sinto em publicar um projeto (text, código, etc.).

Em uma construção de moradia emergencial no TETO
A construção é de um final de semana. 

Que tal participar do TETO?

Quando o objetivo é fazer bem feito não devemos ter pressa, hoje eu foco em fazer o melhor possível no tempo que eu acho necessário, e não no tempo que eu acho mínimo para uma entrega. 

No TETO o primeiro dia é basicamente dedicado a fundação da casa, e temos apenas 2 dias para construir. Antes de começar a codar seu projeto pense em cada detalhe, estruture ele na sua cabeça ou no papel. Trabalhar em um projeto com uma estrutura sólida é muito mais tranquilo e rápido.

Buscar atividades fora do digital podem ajudar bastante a melhorar nossa qualidade de vida e qualidade de trabalho quando tentamos fazer uma relação e aprender sobre a vida, não sobre uma profissão ou atividade específica.

E você, tem alguma experiência parecida com atividades que refletiram na melhora do seu trabalho? Compartilhe nos comentários ou me escreva. 🙂

Como estender os Controllers do Code Igniter

Publicado em Publicado por gserrano

Estender um controller do Code Igniter é uma boa forma de carregar um controller com algumas pré-definições, como validação de usuário, carregamento de bibliotecas ou definições de idioma.

Como estender um controller?

Para estender um controller (ou qualquer outra parte do Code Igniter) o primeiro passo é criar um arquivo que será carregado automaticamente e terá a classe que iremos utilizar.

No meu caso, para estender um controller vou criar um arquivo chamado MY_Controller.php no diretório:

application/core/MY_Controller.php

Dentro este arquivo crio uma classe para estender meu controller, por exemplo:

class MY_AdminController extends CI_Controller {}

E dentro desta classe eu adiciono o que for necessário para o meu controller extendido.

class MY_AdminController extends CI_Controller {
	function __construct(){
		parent::__construct();
		header('Content-type: text/html; charset=utf-8');
		$user = new User();
		if(!$user->getLogged()){
			die('There is only one god and his name is Death, and there is only one thing we say to Death: "Not today"');
		}
	}
}

E no arquivo do seu controller, ao invés de estender o controller você extende o MY_AdminController ou qualquer outro nome que você tenha utilizado.

Você pode ter mais do que uma extensão de controller, no mesmo arquivo de extensão (MY_Controller.php) é só criar uma outra classe e estender o mesmo Controller.

class MY_AdminController extends CI_Controller {}
class MY_App extends CI_Controller {}

Uma outra forma de estender é utilizar os hooks, que permitem um controle mais sensível de onde e o que carregar.

E você, como faz isso nas suas aplicações?