Corrigindo erros após instalação do Nginx no Mac OS X
@Velhinho
Recentemente tive dificuldade, para fazer o Nginx funcionar no meu querido Mac OS X. Apesar de basicamente não existir problema durante a instalação, somente após o termino dessa, tive algumas dores de cabeça. Mas, como o problema agora já consta resolvido, vou compartilhar com vocês a solução que adotei.
Introdução
Senão for do seu conhecimento, o Nginx, é um Servidor e Proxy Reverso HTTP de Alta Performance. Óoo, como soa bonita essa frase 
!
Porém os motivos em adotar esse servidor foram de alguns artigos da comunidade, como esse da Caelum (por Fábio Kung) e esse daqui também da Boox-box (por Marco Gomes), comentando sobre a baixa quantidade de Memória e CPU que esse servidor consome.
Assim esse foi o motivo da minha pessoa, querer utilizar o Nginx desde o desenvolvimento, passando por qualidade até chegar com aplicação em produção.
A instalação
Nem precisei pedir ajuda do Tio Google, pois no Twitter mesmo já recebi comentários sobre o Nginx + Passenger… Então, vamos ao que interessa!
Para saber como efetuar a instalação básica do Passenger com Nginx, basta seguir esse Screencast:
Quick Time: http://www.modrails.com/videos/passenger_nginx.mov
Feito isso não somente o meu Mac OS X, como o seu também, deve executar sua aplicação Ruby em segundos (isso mesmo Nginx é muito rápido).
Porém, nem tudo é satisfação. 
Piada boba essa.
DNS error – cannot find server
Foi esse o primeiro erro que tive de resolver, após configurar a minha primeira aplicação Ruby.
Agora sim, mais do que nunca, o Tio Google me indicou o post de um rapaz da comunidade Ruby BR (só que agora não me lembro o link, então depois coloco por aqui). Esse artigo diz que eu preciso editar o arquivo de Hosts do Mac OS X, conforme abaixo.
# Via Terminal
sudo mate /etc/hosts# No querido Textmate
# Modificar essa linha
127.0.0.1 localhost# Para essa daqui
127.0.0.1 localhost my.application
Feito isso: Problema Resolvido! 
Na sinceridade, somente um bug corrigido.
HTTP 403
No meu caso esse erro, não foi resolvido utilizando o comando Unix conhecido, por Chmod. O problema, não tinha nada a ver com essa solução.
Acontece que o Nginx executa-se com “um usuário próprio”, na qual esse não tem previlégios no sistema de arquivo fora de sua alçada (leia-se /opt/nginx/html) então é preciso informar isso no arquivo de configuração do mesmo.
E somando isso, mais o Gist do @MauricioJr, o problema foi resolvido (e finalmente) da seguinte forma:
# Via Terminal
sudo mate /opt/nginx/conf/nginx.conf# No querido Textmate
# Modificar essa linha
# user nobody; << Isso mesmo a linha esta comentada# Para essa daqui
user my_user_mac my_group_mac;
E pronto o problema esta resolvido. No meu caso o item my_group_mac, substitui por admin e o item my_user_mac para andre.
Conclusão
Sempre tente corrigir um problema através da Documentação, mas se esta não estiver clara (para você), informe a sua dúvida (específica) em algum Grupo de Usuários.
Bom é isso caro leitor.
Quem escreveu foi o André Moreira.
Obrigado pela visita e até o próximo post.
Programador Feliz Escreve Testes
@Velhinho
Atualmente tenho estudado Ruby e todas as facilidades que existem em volta dessa linguagem.
Algo que me chamou muito atenção e me fez balançar a relação que tenho com Java hoje Foram das Pessoas que escrevem código em Ruby, existir um sentimento muito forte, sobre ser Agile.
Aonde dentre esses aspectos da Agile, mais especificamente na Extreme Programing o ponto que mais gosto é de escrever testes antes de programar uma funcionalidade.
Um pequeno cenário
Eu escrevo testes é claro. Seria loucura programar em plena atualidade Sem testar o meu código!
Mas o pouco que já pude notar, das Pessoas que escrevem código tanto em PHP como em Java. É mais ou menos a seguinte situação:
Você esta vendo essa especificação (fluxogramas e afins)? Já esta tudo documentado, então é Só Escrever o Código, pra fazer isso funcionar. Não precisa testar nada!
Simplesmente fico e torço o nariz!
Você pode até pensar, que Eu sou “louco” em “gastar tempo” escrevendo Testes enquanto programo.
Além de achar esquisito demais, em Eu tentar trazer Você para esse lado da força
Mas brincadeiras a parte! Vou pedir para Você, humildemente ler as seguintes postagens e ficar mais abismado com os comentários do Phillip Calçado:
Pois é chato passar por situações, na qual colegas programadores comentam:
Você esta maluco??? Não tenho tempo para ficar testando meus códigos!
Velhinho a minha felicidade como Programador fica
Sabe, realmente essa bronca que Algumas Pessoas tem por testar código, não é melhor caminho da highway!
Então venho aqui, para repassar essa idéia a você. Isso mesmo apenas repassar!
Por onde começar?
Esses dias via Twitter, um colega postou uma apresentação sobre Testes, mas muuuito boa! Conforme slide a seguir, você precisa ver.
Demonstra Testes em Ruby, porém sem preconceitos (se tiver é claro)! Alias, como Carlos Brando costuma dizer a melhor linguagem de programação é o programador.
Ufa! Quantos slides. Mas bem interessante.
Depois de assistir os slides (não tive o prazer de estar no local) resolvi listar aqui, uma fatia das ferramentas para Teste, nas linguagens que costumo programar.
Primeiramente TDD, que nada mais é do que Desenvolver Orientado a Teste.
Com Java
Com PHP
Com Python
Com Ruby
E não que os próximos itens descritos, sejam um complemento. Mas encaro como sendo uma segunda alternativa ao TDD. Temos assim o BDD, que é Desenvolver Orientado a Comportamento.
Com Java
Com PHP
Com Python
Com Ruby
Agora é só você começar a escrever seus testes!
Bom é isso caro leitor.
Quem escreveu foi o André Moreira.
Obrigado pela visita e até o próximo post.
Como aprender Java?
@Velhinho
Após alguns meses afastado do blog, por causa de uma maratona de cursos que vinha fazendo aos finais de semana, estou na área novamente para comentar que o blog ainda existe
Como atualmente estou atarefado em um projeto, não terei cabeça pra falar sobre Design Patterns. Mas em breve volto a destrinchar esse assunto.
Tema de hoje
O assunto da vez é Como aprender Java. Que surgiu após alguns colegas, que desconhecem essa maravilhosa linguagem Orientada a Objetos, ficarem falando:
- Poxa vida André, gostaria de programar em Java também. Mas como é muito difícil, nem me aventuro.
Obs.: Linguagem maravilhosa é ótimo
Primeiramente vamos deixar claro o seguinte. Java não é simplesmente mais uma linguagem de programação! Java ultrapassa esse paradigma, pelo menos Eu encaro dessa forma. Através disso nós temos na verdade Plataformas muito abrangentes e distintas de desenvolvimento, quando falamos em Java.
Apresento a você (resumidamente é claro) algumas siglas que fazem os pilares do que Java é hoje:
O Java SE, aqui temos o Core dessa Gente Grande, que constitui de uma Java Virtual Machine (vulgo HotSpot ou se preferir JVM) que irá interpretar e executar o código que você escreve, compilador que ira gerar a partir dos seus arquivos .java, arquivos .class que serão executados pelo HotSpot e uma extensa API. Logo é por aqui que se inicia a sua aprendizagem! Para instalar vide esse link da JDK.
Obs.: A JVM é sem dúvida uma maravilha, agora não estou exagerando
Temos também o Java EE, que além de integrar o que existe de disponível na Java SE, essa plataforma foi pensada exclusivamente para aplicações que envolvem diversas camadas e conforme especificação roda em um Servidor de Aplicações (mas não necessariamente) e também possui sua própria API. Onde na minha opinião é a plataforma mais interessante de utilizar. Para instalar vide esse link da SDK.
Por último, não menos importante temos o Java ME. Pois é através desse que conseguimos escrever Aplicações Embarcadas (se você achar esse nome um pouco esquisito, vale apena dar uma conferida nesse podcast). Ou seja tudo quanto for dispositivo/aplicação especifica, por exemplo: Celulares, PDAs, Eletroeletrônicos e afins. Podemos aproveitar das diversas APIs (CLDC, MID Profile, CDC, Foundation e etc…) que compõem o Java ME e escrever soluções que também funcionem fora de um computador seja ele desktop, notebook ou server.
Agora olhando para tudo isso acima, realmente Java não é uma Ilha (:-0 puts que trocadilho chinfrim) e sim um mundo das melhores tecnologias disponíveis no mercado, escritas em Java. Como por exemplo o RPC e o WebServices.
Agora que já temos uma breve noção sobre em qual lugar Java pode ser aplicado. Vamos nos atentar em como aprender essa extensa Linguagem de Programação.
Livros
Toda faculdade (pelo menos aqui em São Paulo, Brasil) sempre aponta como material base, o livro Java Como Programar, do famoso Deitel, que nessa postagem se encontra em sua 6ª edição.
Afinal de contas, gostei de Java por causa desse livro também! É claro que cheguei a estudar outros livros como:
- Programando em Java 2 – Teorias e Aplicações
- A Arte do Java
- Aplicando Lógica Orientada a Objetos em Java
- Programação Orientada a Aspectos em Java
Mas nesse livro do Deitel, você passa praticamente de capitulo em capitulo, sempre lendo e relendo assuntos relacionados ao Core do Java. Ou seja, como costumo brincar, você aprende Java na marra ou reforça a cada capitulo o que já aprendeu
Agora falando (um pouco) sério, todo iniciante deve se preocupar em aprender os tópicos: Classe, Atributo, Método, Objeto, Estrutura de Controle, Array, Herança, Polimorfismo, Exceção, Recursão, Pesquisa, Ordenação, Estrutura de Dado, Formatação de Saída de Dado, String, Caractere, Expressão Regular, Generic, Collection, Thread, Socket e JDBC.
Pois o cidadão sabendo isso ele depois pode partir para outros temas relacionados ao Java. Pois como citado anteriormente é apenas o básico-do-básico!
Apostilas
Se você não quiser comprar algum dos livros citados aqui, você pode assim digamos, baixar versões genéricas do mesmo em websites (underground) espalhados por aí. Lembrando que o material encontrado sempre será em inglês. Então para os que não tem muita intimidade com o idioma do Tio San, pode procurar por apostilas escritas em bom é claro português e de graça!
Obs.: A leitura de versões genéricas são de sua e única responsabilidade :-O
Uma das apostilas que costumo sempre recomendar, são as da Caleum. Que é de uma escola que fica localizada aqui em São Paulo e em mais duas outras cidades (Rio de Janeiro e Porto Alegre).
É claro que apesar do conteúdo das apostilas serem bons, se você quiser, pode pagar pelo curso e ter aulas com ótimos instrutores. Além de aumentar seu networking com os alunos, instrutores e cia.
Agora chega de propaganda e vamos as apostilas:
Estude ambas do começo ao fim, primeiramente a FJ-11 e depois a CS-14 e com certeza você estará preparado para após a leitura e entendimento dessas apostilas a dizer:
- Agora sim sei como programar em Java.
Grupos de Usuários
Algo que você notará ao estudar, trabalhar e continuar a conhecer Java é de que sempre existiram pessoas que defendem fervorosamente essa Linguagem e/ou alguns aspectos da mesma. E saiba que você também pode dar sua contribuição para esse grupo.
A seguir deixo uma listagem de algumas comunidades Java que costumo visitar:
Portais
Como falei existe bastante gente interessada na utilização de Java. A seguir mais uma lista que deve constar em seus favoritos:
Blogs
Então, nem preciso comentar 
- Ricardo Ferreira
- Camilo Lopes
- Cláudio Miranda
- Diego Plentz
- Edgar Silva
- Phillip Calçado
- Guilherme Chapiewski
- Igo Coelho
- Java Bahia
- Luca Bastos
- Rafael Carneiro
- Rafael Ponte
- Tiago Peczenyj
- Zona J
Metodologias de Desenvolvimento
Agora essa parte não vale somente para Java, mas sim para Programação em sí. Quando possível, aplique metodologias como XP em seu ambiente de trabalho. Pode ser outra metodologia similar, sem problema algum. Mas tente fugir (o quanto possível) do modelo Waterfall.
Pois lidamos (e sempre lidaremos) com pessoas, que precisam (e sempre necessitaram) de software funcional! Então que tal deixá-las felizes?
Bom é isso caro leitor.
Quem escreveu foi o André Moreira.
Obrigado pela visita e até o próximo post.
Padrões de Projeto – Introdução ao GoF
@Velhinho
Continuando o assunto sobre Padrões de Projeto. Hoje será a vez de falar de uma turma que é muito influente, no ramo de desenvolvimento de software. Mais conhecida como a Gangue dos Quatro.
Mas antes, vamos falar de dois outros personagens
Mr. Kent
Mr. Ward
Na década de 70, dois conhecidos programadores Kent Beck e Ward Cunningham perceberam que os conceitos mencionados pelo Cristopher (o professor do post passado), resolveriam muito dos problemas relacionados a programação de sistemas de computador. Logo aplicaram as teorias do Cristopher, através de uma linguagem de programação largamente utilizada naquela época.
Falo aqui do SmallTalk, a mãe do que hoje conhecemos por
OO (apesar de alguns detestarem)
Mas e o GoF surgiu dessa época, certo?
Não! Avançando algumas décadas, na nossa maquina do tempo, foi na décadacde 90 que o quarteto Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides
. Escreveram o conceituado livro: Design Patterns: Elements of Reusable Object-Oriented Software.
E após isso ficaram conhecidos como a Gangue dos Quatro ou no inglês
Gang of Four. Logo temos aí o motivo da sigla do que hoje conhecemos por GoF Patterns.
A estrutura do GoF
E com essas quatro feras no time, a quantidade de padrões que a turma do GoF levantou, não foram poucas. Temos nada mais, nada menos do que 23 maneiras de resolver alguns problemas e esses estam estruturados em 3 categorias, que são conhecidas por:
- Creational Pattern
- Structural Pattern
- Behavioral Pattern
Se bem que, se formos vasculhar hoje na Internet e nas livrarias, vamos identificar outros padrões, além da quantidade já citado anteriormente.
Então vamos falar brevemente sobre cada uma das estruturas:
- Creational Pattern, nos auxilia em resolver problemas na criação dos nossos objetos.
- Structural Pattern, foca nas associações existentes entre nossas classes e objetos.
- Behavioral Pattern, temos por último esse que trata dos problemas de divisão da responsabilidade entre as nossas classes e objetos.
O que veremos a seguir?
Nos próximos posts veremos na pratica a utilização de cada pattern. Por enquanto deixo aqui a lista dos 23 e mais alguns patterns que fazem parte da família GoF.
Creational Pattern
- Abstract factory
- Factory method
- Builder
- Lazy initialization
- Object pool
- Prototype
- Singleton (sem comentá)
Structural pattern
- Adapter
- Aggregate
- Bridge
- Composite
- Decorator
- Extensibility
- Facade
- Flyweight
- Proxy
- Pipes and filters
- Private class data
Behavioral pattern
- Chain of responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Null Object
- Observer
- State
- Strategy
- Specification
- Template method
- Visitor
- Single-serving visitor
- Hierarchical visitor
Bom é isso caro leitor.
Quem escreveu foi o André Moreira.
Obrigado pela visita e até o próximo post.
Padrões de Projeto – A Origem
@Velhinho
O título desse post, que tentarei explicar se desdobrará durante vários artigos. Deixarei esclarecido que esse tema será abordado de forma mais pratica possível. Deixando de lado alguns pontos demasiadamente teóricos, para literatura indicada via link, no decorrer de cada post.
Logo a minha intenção nessa série de artigos (futuramente) será de detalhar os seguintes tópicos, relacionados a Padrões de Projeto: nome do padrão, problema levantado, solução proposta, quando implementar e respectiva conseqüência.
A Origem
Essa discussão é nova? Devo “perder tempo” estudando isso? Então vamos lá!
Um pouco de história. Padrões de Projeto ou no inglês Design Patterns, teve como precursor o professor austríaco Cristopher Alexander. Alias a Áustria esta de parabéns, nesse país de algumas cabeças pensantes existiram muitas contribuições para humanidade. Mas, cá entre nós qual foi a contribuição do Cristopher? A do Conceito sobre Padrões de Projeto!
Graças a iniciativa nos anos 70, desse professor emérito, que escreveu livros como: Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language. Entre outros que podem ser conferidos em livrarias por aí… O Cristopher mostrou a “nós programadores”, a porta de entrada, de uma maneira interessantíssima de resolver problemas, adotando padrões.
Antes de prosseguirmos, uma pergunta:
- Para você o que caracteriza um Padrão de Projeto? (Não vale pedir ajuda do Tio, apenas diga alguma característica que venha a mente)
Agora vamos lá, voltar aos anos 70 e compreender um pouco sobre essa história. Naquela época se da a entender que o arquiteto Cristopher precisava de uma linguagem padrão, para auxiliar ele e seus colegas de trabalho a projetarem, construírem e repassar esse conhecimento de uma forma que terceiros compreendessem e executassem tais métodos.
Assim podemos acreditar que após muitos projetos de arquitetura entregues, um pleno estudo sobre o que poderia ser e não ser padronizado, foi que Cristopher identificou as seguintes características, que passariam a abordar o conceito sobre Padrões de Projeto, que são:
Encapsulamento
Conseguir separar uma solução em partes, tentando isola-las ao máximo.
Tornando assim a solução do problema, a mais flexível, de fácil
modificação e futuras implementações possíveis. Nota: nada de criar soluções engessadas!
Generalidade
Tornar que um padrão seja o meio para determinada solução de um
problema. Ou até mesmo em caso de uma ocorrência, “desse padrão” não
facilitar ou deixar deselegante a solução do problema. Podemos
aproveitar a teoria do mesmo para propor uma nova solução e como
conseqüência um “novo padrão”.
Equilíbrio
Podemos entender por equilíbrio, a utilização do padrão propriamente
dito aplicado em um projeto. Ao proceder dessa maneira, deixamos para
traz todo dilema que envolve: porque determinada tarefa e mais
problemática dessa forma? Será possível melhorar essa lentidão do
processo… Entre outras questões que são comumente levantadas, enquanto
o problema não é solucionado. Ou seja, enquanto não encontramos o padrão
adequado. Nota: até agora essas características são bem sustentáveis, logo no decorrer das demais, estará mais do que comprovado, que a adoção bem aplicada de padrões é um bom caminho.
Abstração
Esse termo abstração pode parecer meio complexo. Mas na verdade ele
auxilia no simples ponto de extrair ao máximo um problema levantado. Ao
em vez de focar no problema por um todo, focamos apenas no essencial,
naquilo que dá inicio a problemática. Durante o projeto, conforme surja
alguma necessidade é claro, podemos abstrair digamos, um nível a mais a
complexidade de determinado “artefato”.
Abertura
Tal como falado anteriormente no item Generalidade. Quando Cristopher
acrescenta o item Abertura como sendo uma característica em Padrões de
Projeto. Nada mais ele esta confirmando, caso seja necessário, no decorrer do caminho depararmos com uma incompletude em determinado padrão, podemos complementa-lo e deixar tal padrão mais detalhado. Não necessariamente construindo um novo padrão, mas sim buscar melhorar e/ou complementar um padrão já existente.
Combinatoriedade
E pra finalizar, o austríaco citado até o momento, nada mais quer dizer
no item Combinatoriedade, “de que o todo é mais do que a simples soma de suas partes” mencionadas até esse momento. Falando mais tecnicamente, podemos entender que existiram relacionamentos entre os Padrões de Projeto do nível mais baixo com os padrões de nível mais alto. Concluindo assim o conceito sobre quais são as característica envolvidas em Padrões de Projeto.
Então é isso galera. Espero que tenha conseguido transmitir, nesse singelo artigo, um tema que considero importante para “nós”. E assim ressaltar que nós como programadores, não analista de sistemas e nem tão pouco digitadores, devemos também dedicar um tempo a assuntos como esse discutido aqui.
No próximo artigo falarei sobre o Padrão de Projeto GoF e (tentarei) mostrar os seus respectivos diagramas de classe (ou código mesmo). Afinal de contas UML serve muito bem pra isso. Mas devemos lembrar que GoF não é a única (coletânea) padrão, existem outros como: GRASP Patterns, J2EE Patterns, Testing Patterns, Optimization Coding Patterns, Robustness Coding Patterns, Organizational Coding Patterns e etc…
E velihnho o importante mesmo é saber quando utilizar cada pattern, senão, ao em vez de resolver um problema, acabamos duplicando a problemática do mesmo.
Bom é isso caro leitor.
Quem escreveu foi o André Moreira.
Obrigado pela visita e até o próximo post.
