Un blog en cursiva

dezembro 6th, 2011

Este año mi hijo único estuvo aprendiendo muchas cosas en la escuela. Uno de los objetivos era aprender a escribir y leer en letras corridas, en cursiva. No me acuerdo exáctamente cómo era en mi época, pero sé que aprendí a escribir en cursiva en los primeros años de primario.

Bueno, de todas formas, mi chiquilín aprendió primero a escribir con letras de imprenta. La metodología exhigía que después de dominada esa forma de escrita, ahí sí los niños podrían aprender a escribir en cursiva. Los tiempos cambian y nosotros debemos ver todo de forma distinta, de a poco.

Creo que eso de la cursiva puede desaparecer con el paso del tiempo, pero sigue siendo algo importante para practicar y dominar. Mi hijo hace tres años que escribe, pero en cursiva nunca se puso a practicar. Hace pocos meses en la escuela empezaron a practicar a diario la cursiva. A mí me pareció muy bueno. Eso ayuda los niños a tener más control sobre los movimientos, ayuda incluso en la productividad. Imagínense escribir una redacción en media hora sin cursiva. Todo se vuelve más lento…

Llegamos en un punto donde mi hijo no veía mucha ventaja en aprender a escribir en cursiva. Eso a lo largo se podría volver en un problema, puesto que la escuela lo exigía. Entonces allá en casa, yo y mi mujer tuvimos una idea que nos pareció interesante, y después se confirmó suficiente para animarlo al pequeño. Hace tiempo el chiquilín me veía trabajando con programación informática. Todas las semanas estoy trabajando en algo, sea por un proyecto propio, sea por un trabajo encomendado. Aparte llevo unos buenos meses manteniendo mi blog personal, aunque aún no le estoy dando el tiempo que merece.

Bueno en suma, al chiquilín siempre le gustó la idea de tener un blog personal para él tambíen. Algo suyo, donde él pudiese escribir y publicar contenido proprio, de acuerdo a los intereses de un niño precoz de 7 años de edad. No tuvimos dudas en proponerle un cambio: él se dedica a dominar la cursiva y nosotros le preparamos un blog. Bueno, su blog ya está en línea y va muy bien: con posts regularmente publicados y propaganda de boca a boca en su escuela, en seguida va a alzar vuelos más altos, quizás.

Después de todo me pareció irónico todo eso, y me puse nostálgico. Antiguamente los niños aprendían cursiva de inicio. Hoy aprendemos a escribir como las máquinas (computadoras) y después en cursiva. Antiguamente los niños aprendíamos a mantener un diario, hoy es un blog. El mundo cambia y nosotros también debemos hacerlo. Bueno, mi generación tuvo que aprender a escribir en línea después de grande. Nuestros hijos ya tienen la oportunidad de participar de toda una vida en línea desde chicos (y deben hacerlo bajo supervisión de sus padres).

Si volvemos un poco más atrás en el tiempo, mi padre creció con una radio de madera en la sala su casa. Después de adulto tuvieron su primera televisión negra y blanca. Muchos años más tarde los colores invadieron las pantallas de la televisión. Internet para personas naturales sólo apareció cuando yo era adolescente.

Pienso que todas las generaciones precisan en un momento adaptarse a las nuevas tecnologías que empiezan a formar parte de nuestro dia a dia. Todo evoluciona y nosotros debemos mantener la mente abierta a los buenos cambios. A esos que nos permiten mejor calidad de vida. Pero siempre tenemos que luchar para mantener las antiguas cosas buenas. La letra en cursiva es una de esas que vale la pena practicar siempre. Allá en mi casa todos tenemos blogs, y todos escribimos en cursiva.

Links interessantes sobre padrão MVC

outubro 21st, 2011

Estou a algum tempo investindo horas de desenvolvimento no framework em PHP, denominado CleanGab. Esse framework está implementando o padrão MVC clássico, com camadas de controle, modelo e visão. O CleanGab também está implementando uma versão própria de JSTL para o PHP.

No CleanGab, além de proporcionar a navegação, a camada de controle estabelece a ponte entre as camadas de modelo e visão. Durante meu embasamento conceitual, buscando forças e inspirações para desenvolver esse framework, encontrei dois links muito bons a respeito de MVC, os quais compartilho com vocês:

O padrão MVC na teoria e prática

http://warp.povusers.org/programming/mvc.html

MVC: história, teoria e uso

http://amix.dk/blog/post/19615

Este último explica o conceito, mas também entra em questões de implementação usando Ruby on Rails.

Abraço e até a próxima.

Infográfico 20 anos do Linux

agosto 22nd, 2011

A imagem abaixo mostra a evolução do Linux em números. Em 2011 faz 20 anos que Linus Torvalds enviou a mensagem “Hello everybody out there….I´m doing a (free) operating system” convidando programadores a ajudá-lo na empreitada de criar um Sistema Operacional gratuito e livre.
Imagem ilustrando 20 anos do Linux
Fonte: http://gigaom.com/2011/08/16/20-years-of-linux/

Pensar em arquitetura e framework na pré-venda de software

junho 24th, 2011

No dia a dia de uma fábrica de software, por vezes nos deparamos com algumas questões práticas referentes à construção do produto de software. Uma das questões mais cuidadosamente tratadas é a escolha de uma arquitetura e de um framework.

Esse é o alicerce para qualquer sistema, porém às vezes não conseguimos despender o espaço no cronograma suficiente para essas questões, depois que o projeto inicia. Isso é natural, visto que o alicerce nunca é visto pelo cliente e pela área comercial da nossa empresa. Certamente a arquitetura e o framework escolhidos refletem na robustez e eficácia do produto de software, mas arquitetura e framework não são facilmente percebidos pelo cliente.

Eu acredito que devemos pensar em arquitetura e framework da solução desde um primeiro contato de apoio e pré-venda.

Imaginemos o cenário: a área comercial efetua a prospecção de um novo cliente para um projeto de software. A área técnica é acionada para prestar um apoio na pré-venda. Neste momento a área técnica já deve realizar um levantamento prévio de aspectos culturais e infra-estruturais do cliente, no intuito de escolher uma arquitetura adequada para o novo software. É aqui que devem ser revelados os primeiros requisitos.

Com base nos levantamentos realizados em uma sondagem prévia, a área técnica já consegue preparar-se para o futuro projeto de modo mais consistente. Ou seja, a área técnica deve aproveitar para recolher informações desde um primeiro contato com o cliente, de modo a obter com o máximo de antecedência informações que subsidiem os passos iniciais do projeto:

  1. Definir a arquitetura do sistema – baseada em requisitos não funcionais (cultura ou infra-estrutura do cliente);
  2. Avaliar frameworks para a construção do sistema – baseado na arquitetura escolhida
  3. Escolher um framework dentre os avaliados

Neste ponto posso estar parecendo exagerado. A equipe precisa preocupar-se com a arquitetura e o framework do sistema desde um primeiro contato com o cliente? Resposta: Sim. Temos a obrigação de estar um passo à frente. Cada vez mais, nós os profissionais de T.I., precisamos nos aproximar da área comercial da nossa empresa e do nosso cliente. Apoiar a área comercial e ajudar o cliente a resolver seus problemas é um conceito-base para o bom profissional de T.I. hoje em dia.

Dito isso, uma segunda questão que deve surgir é a seguinte: Não é desperdício pensar em arquitetura e framework antes de fechar o contrato, antes de ter o projeto na pauta de desenvolvimento? A resposta é um redondo NÃO. Desperdício é ficar esperando de braços cruzados que o projeto chegue a nossa fila de trabalhos, para depois pensar como ele pode ser construído.

Se a equipe pretende receber projetos bons, trabalhar com bons padrões e progredir em boas práticas, deve sim aproveitar cada oportunidade para estudar, avaliar e comparar soluções em arquiteturas e frameworks.

Acredito que o melhor momento para pensar em arquitetura e framework é na pré-venda de um projeto de software. Depois que o cliente fechou o contrato com a nossa empresa, geralmente temos um cronograma apertado e, consequentemente, menos tempo para pensar no alicerce do sistema. O cliente e a área comercial precisam ver logo o sistema sendo construído. É um fator humano: precisamos ver para crer.

Fazendo uma analogia com a construção civil: quanto antes tivermos definido o melhor alicerce, de acordo com o terreno em que será construído o prédio, mais rápido poderemos começar a levantar as paredes.

Falando em evitar desperdício de tempo, ao mesmo tempo que devemos pensar em certos aspectos do projeto no momento de uma pré-venda, também precisamos evitar que toda a equipe esteja envolvida nesse penso. É recomendável incentivar que todos os membros da fábrica de software tenham a oportunidade de pensar em arquitetura e frameworks para um possível projeto a ser assumido, mas que apenas um ou dois profissionais sejam alocados para essa atividade por vez. O trabalho realizado em apoio a área comercial também deve ser considerado como parte das atividades diárias de uma fábrica de software. Essa visão é condizente com a realidade do mercado e é cada vez mais requerida pelas empresas de ponta.

Qualidade em pauta: smoke test e sanity test

março 30th, 2011

Neste post pretendo descrever, sob o ponto de vista de um analista de sistemas, duas atividades que considero muito importantes para uma entrega de software bem sucedida. Tratam-se de duas atividades realizadas pelo pessoal da qualidade de software (Q&A): Smoke Test e Sanity Test.

Smoke Test
A origem do nome Smoke Test remonta do início da indústria de hardware. Traduzindo para o portguês, seria “Teste de Fumaça”. Após montar os componentes eletrônicos, ligava-se o equipamento na tomada. Se não surgisse fumaça, o equipamento tinha sido bem montado e os componentes estariam funcionando. Transportando esse conceito para o desenvolvimento de software, smoke test é um conjunto de testes básicos realizados pelos testadores para saber se o software que está sendo liberado possui algum problema saliente em suas funcionalidades mais básicas. É realizada uma navegação completa no sistema para verificar se tudo o que já funcionava antes segue funcionando corretamente.

Sanity Test
O sanity test ou “teste de sanidade”, é realizado quando um novo build com revisões pequenas é gerado. O objetivo do sanity test é garantir que os problemas resolvidos (listados no release notes) estão realmente corrigidos. Além disso, o sanity test garante que as correções entregues não geraram novos bugs. A suite de testes do sanity test é encarado como uma atividade anterior aos testes de regressão completos, ou mesmo em substituição a este quando a entrega é de baixa criticidade.

Links separados para leitura
Seguem alguns links interessantes que separei sobre smoke e sanity test.

  1. geekswithblogs.net – apresenta os conceitos de cada atividade, bem como uma tabela comparativa dos dois.
  2. softwaretestinghelp.com – confronta os dois tipos de testes de forma direta.

Dois princípios para uma boa compra na Internet (o básico e o fundamental)

outubro 19th, 2010

A motivação para escrever este post foi minha recente leitura de notícias e e-mails relatando golpes em comércio eletrônico. É um problema que vem aumentando junto com o próprio comércio eletrônico no Brasil.

A pouco tempo atrás, o mercado brasileiro de comércio eletrônico estava exclusivamente formado por grandes portais. Hoje os grandes ainda concentram a maior fatia do mercado. No entanto, observa-se o surgimento de novos sites, comercializando produtos de empresas pequenas e médias. Eu mesmo estou tendo a oportunidade de trabalhar em dois projetos atualmente. Um deles de uma cadeia de lojas de shopping centers proeminente em Porto Alegre e Caxias do Sul, mas que em termos de Internet está começando a explorar um novo mercado. O outro cliente vende máquinas de porte industrial, e enxerga na Internet a possibilidade de expandir seu mercado consumidor.

Na medida em que os empresários empreendem novos rumos na Internet, seja para apoiar ou expandir seus negócios, proliferam-se as ofertas para o internauta, na qualidade de cliente qualificado. Para o consumidor, tornou-se muito fácil escolher seu produto na Internet. Não é necessário perambular por várias lojas, em busca do melhor custo benefício. Basta navegar por alguns sites e fazer sua própria comparação na tela do computador. Na Internet, o cliente pode estar em contato com os produtos desejados de forma muito mais simples, prática e rápida.

No entanto, existe o outro lado da moeda. A ausência de uma loja física pode mascarar problemas de idoneidade, logística e atendimento do lojista. Infelizmente não podemos definir com total precisão se uma loja virtual é ou não a melhor escolha para fazer a compra, mas podemos sim minimizar os riscos, com dois princípios básicos fundamentais:

  1. Transparência das informações – verifique se o site possui todas as informações necessárias para descrever o produto, tais como características físicas, técnicas, preço, formas de pagamento, prazo de entrega. Pense que em uma loja convencional você não compraria determinado produto se não soubesse dessas informações todas.
  2. Canal de comunicação com o Cliente – verifique se o site disponibiliza canais de comunicação bem estabelecidos: e-mail, formulário de contato, telefone, chat (citando os principais exemplos). Acima de tudo, é interessante testar esses canais de comunicação antes de uma compra. Pergunte, questione sobre o produto, coloque na mesa suas dúvidas e no final faça sua avaliação: as dúvidas foram esclarecidas? O pessoal do site soube dar um bom atendimento?

Nos próximos posts vou falar a respeito de investigar a identidade de uma loja virtual. É um processo simples mas ajuda a apoiar o consumidor eletrônico na escolha pela loja idônea.