Qualquer um pode aprender a programar

Qualquer um pode aprender programarAprender a programar hoje em dia está cada vez mais acessível. Basta um dispositivo e a vontade de aprender. Neste post vou comentar um pouco sobre algumas novas abordagens que fornecem recursos para quem deseja aprender a programar independente de tecnologia, condição, pré-requisito ou situação do aprendiz.

Há algum tempo atrás lancei meu curso sobre lógica de programação e desde então venho pensando e escrevendo sobre este assunto. Não só isso: também procuro ir além e estudar novas técnicas e maneiras de como ensinar melhor programação para pessoas que estão tendo o primeiro contato com desenvolvimento.

Um dos fatos que notei é a falta de diferenciação em relação ao tipo e perfil do aluno  em praticamente todos os materiais e recursos para o aprendizado de programação. Ou seja, os materiais não levam em consideração alguns fatores de quem está aprendendo com o objetivo facilitar o aprendizado. Pensando nisso fiz uma conexão e lembrei-me de um personagem do filme Ratatouille.

Figura2_PostgerRatatouille

Sem dar spoilers, neste filme há um personagem que repete várias vezes o bordão “Qualquer um pode aprender a cozinhar” ou em inglês Anyone can cook. Foi interessante notar que, no contexto do filme, tal frase age de forma motivadora para alguns e levanta séries preocupações em outros.

Em particular, eu acredito que assim como qualquer um pode aprender a cozinhar qualquer pessoa pode aprender a programar se houverem recursos adequados e dedicação suficiente. Se esta pessoa vai se tornar um programador ruim, mediano ou bom já é outra história, mas pelo menos os conceitos básicos, algumas noções importantes e programas simples para comandar as máquinas e fazê-las obedecerem a nossa vontade podem ser aprendidos por qualquer um.

Mas, como disse no começo do texto, os recursos e materiais especiais para diferentes grupos de pessoas não são muito comuns. Por isso resolvi discutir algumas referências e exemplos interessantes de recursos produzidos por quem realmente acredita que há espaço para que qualquer um possa aprender a programar.

Programação para mulheres

Figura3_GarotaProgramando

Recentemente algumas abordagens foram apesentadas para ensinar programação especialmente para as meninas e mulheres. O que é interessante de notar é como a forma de abordar este assunto muda quando há foco em um gênero específico, em particular o fato dos materiais terem mais cores, imagens e recursos visuais que vão além do texto. Algo semelhante acontece com o conteúdo para aprendizado de programação voltado para crianças e livros específicos para o gênero feminino.

Já escrevi há algum tempo atrás sobre algumas possibilidades de como será a programação no futuro, e pelo que tenho visto, cada vez mais elementos didáticos, independente do gênero vão sendo inseridos não só aos recursos para aprendizado, mas também às ferramentas, ambiente de desenvolvimento e tecnologias utilizadas para programar.

Codificação do jeito difícil

Figura5_HardWayMuita gente pensa que para aprender a programar devemos seguir o caminho mais fácil. Bem, certamente este pensamento é adequado para maioria das pessoas, mas não todas.

Considerando que nem todos preferem seguir o caminho fácil, algumas abordagens se concentram em mostrar o conteúdo da forma difícil ou mesmo complexa para um público que prefere o aprendizado desta maneira. A série de livros Hard Way  é um exemplo disso e não deixa de ser um caminho diferenciado para o grupo de pessoas que não procuram apenas do básico quando estão aprendendo.

Portadores de necessidades especiais

Figura6_EmpowerQuando alguém observa um portador de necessidades especiais usando um computador talvez a última coisa que venha à mente é que ele esteja programando. Do ponto de vista de materiais, anda estamos engatinhando em recursos específicos para quem possui alguma condição física ou psicológica diferente da maioria.

Existem várias vantagens para o aprendizado de programação para quem se enquadra neste perfil. Além de desenvolver habilidades cognitivas e se preparar para uma profissão, existe a fator empoderamento  (empowerment). Este é um conceito complexo, mas vou simplificar dizendo que, no contexto de portadores de necessidades especiais, aprender a programar traz diversos benefícios psicológicos que podem fazer a diferença do ponto de vista social.

Existem bons exemplo de conteúdo específico para o aprendizado de programação voltado para quem possui necessidades especiais. Pesquisando um pouco descobri iniciativas interessantes como projetos para cegos aprenderem a programar assim como recursos para deficientes auditivos (aqui, aqui e aqui)

Outra ideia no mínimo diferente é a programação feita com os pés, algo que até certo ponto pode ser complementado e adaptado para auxiliar as pessoas que programam normalmente com as mãos.

Destaco também estas duas listas (aqui e aqui) de bons recursos e ferramentas com diversas tecnologias de acessibilidade úteis para o uso de computadores que podem auxiliam que está programando neste contexto.

Terceira idade

Figura7_TerceiraIdadeConforme vamos envelhecendo novas atividades vão sendo adaptadas para esta etapa da vida. Apesar de algumas barreiras existentes para a utilização de dispositivos e interfaces atuais, atualmente temos muitos recursos de acessibilidade voltados para a terceira idade. Também existem vários programas de treinamento e terapia ocupacional que incluem o uso de computadores.

Além disso, incluir a perspectiva de pessoas com idade avançada em aplicativos e sistemas pode trazer benefícios que possivelmente não seriam obtidos quando se tem uma equipe de desenvolvimento com idade média muito diferente dos seus usuários.

Entretanto, o uso de programação na terceira idade ainda engatinha (eu sei, piada ruim…). Procurando por referências encontrei alguns vídeos motivadores de projetos que se concentram mais no uso de aplicativos gerais do que na programação em si. Este é um primeiro passo significativo, mas gostaria de ver outras iniciativas voltadas para o aprendizado de programação para pessoas da terceira idade.

https://www.youtube.com/watch?v=bA_w9Zb3ZI8

https://www.youtube.com/watch?v=KE5yduWfPUM



Gatos, cachorros e afins

Figura8_GatProgrmador

Para finalizar destaco alguns contextos um tanto quando estranhos quando falamos sobre programação. Que tal a história do mendigo que não tinha onde morar e aprendeu a programar? Exemplos como esse mostram que a vontade de aprender supera muitas dificuldades.

Também há espaço para abordagens bem humoradas quando se fala em programação como o tutorial que ensina a programar em Javascript para gatos. Parece que ainda não criaram algo semelhante para cachorros, mas pelos menos eles podem ser divertir assistindo TV.

Publicado em Programação, Uncategorized | Com a tag , , , , , , , | Deixar um comentário

DatabaseCast 46: Log de banco de dados

VitrineDatabaseCast46Neste episódio do DatabaseCast Mauro Pichiliani (@pichiliani) e Wagner Crivelini (@wcrivelini) armazenam instruções no log com os convidados Ricardo Rezende (@ricarezende) e Fabiano Amorim (@mcflyamorim).

Neste episódio você vai saber o que é e como trabalhar com o log do bancos de dados, porque alguns DBAs são como mosquitos, quais são as opções para ler dados de logs, e o que são instruções SQL da ostentação e da maldade.

Não deixe de nos incentivar digitando o seu comentário no final deste artigo, mandando um e-mail para  databasecast@gmail.com, seguindo o nosso twitter @databasecast, vendo informações de bastidores e as músicas do programa no nosso Tumblr e curtindo a nossa página no Facebook.

Clique aqui para obter o endereço do feed RSS e assinar o DatabaseCast

Veja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio46

Veja na tag cloud abaixo a contagem das palavras mais usadas nos emails, comentários e tweets do episódio anterior:

TagCloud_ep45

CAMISETAS E PRODUTOS DO DATABASECAST:

Camisa Data baseCast Sonho Fractal

Camiseta DatabaseCast Fluxo Matrix

Você pode comprar a camiseta com estampa fractal Fluxo Matrix e Sonho Fractal diretamente neste link.

Livro Conversando sobre Banco de dados do Mauro Pichiliani (Impresso e PDF, EPUB e MOBI)

Curso online básico de MySQL

Curso introdutório de lógica de programação

Links do episódio:

 




Publicado em DatabaseCast | Com a tag , , , , , , , , | Deixar um comentário

15 fatos sobre programação que você provavelmente não sabia

0_Capa

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 post 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, independente 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 estudos 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 nestes resultados que escolhi os fatos a serem citados neste post junto com as devidas referências. A propósito, 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 neste contexto, vou apresentar 15 fatos importantes e que, infelizmente, são pouco conhecidos por quem programa. Mas antes faço um aviso: estes 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 são estas informações.

1) Programadores demoram para pedir ajuda quando tem problemas

1_PedirAjuda

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. Este formato leva os aprendizes a tentar muito nos exercícios e, muitas vezes, resolver tudo sozinhos sem pedir ajuda.

Esta atitude não é ruim e é até recomendada, porém é preciso saber até que ponto deve-se deixar de tentar e pedir alguma forma de ajuda.

Referência: Andrew Begel e Beth Simon. Novice software developers, all over again.  ICER ’08 Proceedings of the 4thinternational Workshop on Computing Education Research, 2008.

2) Programadores possuem uma tendência a reportar de forma incompleta seus problemas

2_Erro

Este fato é relacionado com pesquisas da área da psicologia. Os resultados indicam que quando uma pessoa tem algum problema ela não comunica todas as informações completas sobre os problemas, especialmente quando ela é o responsável de forma direta ou indireta.

Este 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 da habilidade e proficiência por quem está ouvindo o relato. Esta situação é muito mais comum quando se trata de um erro básico de principiante.

Referência: Shrauger, J.S. and T.M. Osberg. The Relative Accuracy of Self-Predictions and Judgments by Others in Psychological Assessment. Psychological Bulletin, 1981. 90(2): p. 322-351.

3) Programadores procuram outras formas de ajuda antes de falar com colegas de trabalho

3_StatckOverflow2O fato da 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 e outros floresceram explorando este tipo de comportamento através da agregação da ajuda com diversos aspectos de comunidades para desenvolvedores.

Referência: LaToza, T.D., Venolia, G., and Deline. R. Maintaining Mental Models: A Study of Developer Work Habits. in Proc. ICSE. 2006: IEEE.

4) O progresso na programação pode ser classificado em quatro fases

4_Progresso4
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, também é 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 ao ponto de atrasar alguma entrega. Uma classificação interessante identificou (de forma automática) quatro possíveis estados de progresso:

a)    Programação complexa
b)    Fazendo progresso
c)    Progresso lento
d)    Emperrado (stuck)

Referência: Jason Carter,  Prasun Dewan. Design, Implementation, and Evaluation of an Approach for Determining When Programmers are Having Difficulty. ACM Group 2010.

5) Programadores encontram barreiras superáveis e insuperáveis

5_BArreira2 Este fato pode parecer óbvio, mas ele é muito importante de ser detectado, uma vez que uma barreira de programação pode levar a sérios problemas de prazo, moral da equipe e confiança.

Uma das principais dificuldades de se detectar barreiras e classifica-las está no fato que esta 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 este tipo de barreira na programação,

Referência: Andrew J. Ko et al. Six Learning Barriers in End-User Programming Systems. 2004 IEEE Symposium on Visual Languages – Human Centric Computing.

6) São 6 os tipos de barreiras relacionadas à programação

6_Barreira

Além da classificação de barreiras de programação em 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:

a) Design: “Eu não sei o que o computador deve fazer”.
b) Seleção: “Eu sei o que fazer, mas não sei o que usar”.
c) Coordenação: “Sei o que usar, mas não sei como combinar o que preciso”.
d) Uso: “Eu sei o que usar, mas não sei como usar”.
e) Compreensão: “Pensei que sabia usar X, mas ele não faz o que eu esperava”.
f) Informação: “Compreendo o que aconteceu, mas não consigo checar”.

Referência: Andrew J. Ko et al. Six Learning Barriers in End-User Programming Systems. 2004 IEEE Symposium on Visual Languages – Human Centric Computing.

7)  Programadores passam aproximadamente 30% do tempo navegando no código fonte
7_Navegando

Quem programa sabe que a maior parte do tempo é gasta dentro de uma ferramenta de edição de código fonte. Contudo, como o tempo é divido entre as tarefas de edição do texto representado pelo código fonte ainda não está claro do ponto de vista científico.

De acordo com um estudo muito importante, descobriu-se que aproximadamente 30% do tempo de trabalho de um programador não é gasto editando o texto (incluindo, alterando o excluindo), mas sim navegando entre diversos arquivos com códigos fontes. Esta 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.

Referência: Andrew J. Ko et al. An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks. Journal IEEE Transactions on Software Engineering archive Volume 32 Issue 12, December 2006 pp. 971-987.

8) Produtividade de programadores remotos é menor que a produtividade de programadores locais

8_FastEsta afirmação sobre produtividade é polêmica, especialmente quando 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 desta maneira se analisarmos os outros fatos desta lista como, por exemplo, 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 desta pesquisa, pois pedir aquela dica no encontro durante uma pausa para o café é muito importante de acordo com que foi apurado.

Referência: Herbsleb, J.D., et al. Distance, dependencies, and delay in a global collaboration. In: Proceedings of the 2000 ACM Computer-Supported Cooperative Work conference.

9) A maioria dos programadores é masculina, branca e jovem
9_computer-programmer

Esta afirmação sobre a diversidade de programadores não veio exatamente de uma pesquisa acadêmica, mais sim de Adda Birnir que é a fundadora do site de recrutamento e seleção Skillcrush. Esta declaração foi apresentada no vídeo “Is CODE the most important language in the world?”.

Atualmente é muito comum destacar minorias na programação, espacialmente a baixa quantidade de mulheres. Contudo, como certos dados mostram este não é o único perfil que 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

10_compile-time-error2

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 do 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 acontece em diferentes contextos.

TempoMedioResolverProblemasTabela 6.2. Erros mais frequentes (Java) e tempo médio de execução

TabelaErrosDeExecucaoTabela 6.12. Frequência de erros de execução em Java (runtime)

TabelaErrosCompilacao Tabela D.1 Principais erros de compilação (Java) e tempo médio para resolvê-los

Referência: Thompson, Suzanne Marie. An exploratory Study of Novice Programming Experiences and Erros. Tese de mestrado defendida em 2004 na inversidade de Victoria, Canadá.

11) A manutenção de software consome mais de 50% do esforço

11_legacy-code

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 manutenção.

No estudo que citou este 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 uma olhada nesta referência antes de tomar aquela decisão sobre começar a desenvolver a solução do zero ou trabalhar com uma base de código existente.

Referência: Kemerer C.F. and Slaughter S. An Empirical Approach to Studying Software Evolution, IEEE Transactions on Software Engineering, 25(4), pp. 493-509, 1999.

12) A manutenção de software consome entre 40 e 90% dos custos

12_Sem título

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 através de tarefas de manutenção pode chegar a custar até 90% de todos os custos do projeto.

Estas estatísticas são bem genéricas e foram obtidas em um contexto muito particular das 487 organizações estudadas nesta pesquisa, sem contar que a data do estudo é de 1980. Certamente existem diversos fatores a serem considerados, mas ao menos existe um ponto de partida para analisar cursos e discutir sobre este aspecto quando se fala de manutenção de software.

Referência: Lientz, B.; Swanson, E.B. Software maintenance management: a study of the maintenance of computer application software in 487 data processing organizations. Addison Wesley, 1980.

13) O trabalho de manutenção de software é dividido em 4 tarefas básicas

13_Sem título

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:

a)    Melhoria: envolvem mudanças de funcionalidades
b)    Adaptativa: são mudanças no ambiente para adaptação a requisitos
c)    Corretiva: atividades para a correção de erros
d)    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.

Referências: Lientz, B.; Swanson, E.B. Software maintenance management: a study of the maintenance of computer application software in 487 data processing organisations. Addison Wesley, 1980.

Lientz, B.; Swanson, E.B.; Tompkins, G.E. Characteristics of applications software maintenance, Communications of the ACM, Vol. 21, pp.466-471, 1978.

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
14_059.TRONSS.32_905

Este fato é um clássico da área e motivou a evolução dos processos tradicionais 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.

Referências: Barry W. Boehm: Software Process Management: Lessons Learned from History. ICSE 1987: 296-298.

15) Revisão de código pelos pares consegue descobrir até 60% dos defeitos

15_PairProgramming

A revisão de código feita por outas 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.

Este 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.

Referência: Barry W. Boehm: Improving Software Productivity. IEEE Computer 20(9): 43-57, 1987.



Publicado em Programação | 15 comentários

DatabaseCast 45: Raspagem de dados

VitrineDatabaseCast45

Olá, pessoal! Neste episódio do DatabaseCast Mauro Pichiliani (@pichiliani) e Wagner Crivelini (@wcrivelini) raspam dados com o convidado João Batista Oliveira Neto (@netojoaobatista).

Neste episódio você vai saber o que é open data, descobrir como participar de um hackaton, se decepcionar com seu scanner, passar uma madrugada a base de café e energético, extrair dados de páginas HTML, Flash, PDF, vídeos e áudio e soltar um grito esquisito de satisfação quando conseguir obter os dados.

Não deixe de nos incentivar digitando o seu comentário no final deste artigo, mandando um e-mail para  databasecast@gmail.com, seguindo o nosso twitter @databasecast, vendo informações de bastidores e as músicas do programa no nosso Tumblr e curtindo a nossa página no Facebook.

Clique aqui para obter o endereço do feed RSS e assinar o DatabaseCast

Veja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio45

Veja na tag cloud abaixo a contagem das palavras mais usadas nos emails, comentários e tweets do episódio anterior:

TagCloud_ep44

CAMISETAS E PRODUTOS DO DATABASECAST:

Camisa Data baseCast Sonho Fractal

 

Camiseta DatabaseCast Fluxo Matrix

Você pode comprar a camiseta com estampa fractal Fluxo Matrix e Sonho Fractal diretamente neste link.

Livro Conversando sobre Banco de dados do Mauro Pichiliani (Impresso e PDF, EPUB e MOBI)

Curso online básico de MySQL

Curso introdutório de lógica de programação

Links do episódio:




Publicado em DatabaseCast, Podcast | Com a tag , , , , , , , , | Deixar um comentário

Fazendo arte com SQL

Figura1_SQLArtA linguagem SQL surgiu para facilitar a manipulação de dados e implementar as principais operações da álgebra relacional. Neste post vou comentar algo inusitado que dá para fazer ela: a criação de arte.

Com o passar do tempo várias novas funcionalidades, extensões e modificações foram adicionadas à linguagem SQL que atualmente vai muito além do SELECT, INSERT, UPDATE e DELETE. Uma das mais interessantes foi a possibilidade de realizar desenhos a partir de primitivas gráficas como pontos, retas, círculos e outros.

Estas primitivas gráficas foram criadas para que a SQL possa ser utilizadas em conjunto com soluções de geoprocessamento que manipulam mapas, coordenadas, locais e outros elementos. A integração se dá de várias formas, mas algumas pessoas utilizaram os recursos e as primitivas gráficas para começar a fazer desenhos.

Figura2_SQLArt
A ideia é simples: ao invés de uma instrução SELECT retornar linhas e colunas e vai retornar um desenho. Geralmente há uma parte ou aba da ferramenta de consultas que permite visualizar este tipo de retorno de dados. O resultado final fica muito parecido com a ASCII Art.

Figura3_SQLArt

Os SGGBD mais utilizados para este tipo de desenho são o SQL Server e o PostgreSQL com a extensão PostGIS. Muita gente pode torcer o nariz e dizer que é pura perda de tempo, mas acho bacana explorar este tipo uso, especialmente pelo fato que muitos DBA e desenvolvedores estão acostumados apenas a ver resultados no formato relacional (linhas e colunas). Veja abaixo mais alguns exemplos de SQL Art.

Figura4_SQLArt Figura5_SQLArt Figura6_SQLArt
Para mais informações sobre como criar seus próprios desenhos com SQL recomendo uma visita aos links abaixo:

http://www.purplefrogsystems.com/blog/2011/05/sql-server-art-using-spatial-data/
http://sqlfromhell.wordpress.com/category/spatial-data/
http://alastaira.wordpress.com/2012/03/06/drawing-fractals-with-sql-server-spatial/



Publicado em Programação, SQL | Com a tag , , , , , , | Deixar um comentário

Vícios e manias de quem aprende a programar sozinho

Fonte: http://matus76.deviantart.com/art/Self-Taught-411149744 - Matias Sierra

Fonte: http://matus76.deviantart.com/art/Self-Taught-411149744 – Matías Sierra

Atualmente é muito comum encontrar desenvolvedores, programadores e demais profissionais que aprenderam a programar sozinhos. Neste post vou comentar um pouco sobre os tipos de vícios e manias que acabo vendo em profissionais com este perfil.

Para começar gostaria de destacar que fiz questão de não utilizar a palavra autodidata. O motivo é que este termo certamente não tem mais a mesma conotação e peso que que tinha há algum tempo atrás. Isso se deve à necessidade de sempre aprender coisas novas da área e à grande quantidade e facilidade de acesso às informações disponível na internet, especialmente para desenvolvedores. Sendo assim, não acredito que utilizar o termo autodidata contribui para expressar o tipo de pessoa que possui os comportamentos que vou descrever aqui. Afinal de contas, somos todos autodidatas em algum nível e isso não torna necessariamente alguém melhor ou pior que outra pessoa.

Outro aspecto importe de citar antes de descrever os vícios e manias é que tenho noção do fato que nem todo mundo que aprendeu a programar sozinho pode ter os vícios e manias que citei aqui. Sim, eu sei que muita gente passa longe das atitudes descritas, mas infelizmente durante a minha experiência profissional tenho visto muitos perfis comprovando que, de fato, o aprendizado individual acaba fortalecendo vícios nada adequados para o ambiente de trabalho profissional com programação.

Dificuldade no trabalho com uma equipe
Figura2_NoTeamWork

Quem aprende a programar sozinho e por conta está acostumado a passar horas e horas isolado ou com pouca interação com outras pessoas. Enquanto este isolamento auxilia na concentração e esforço mental, ele possui um efeito colateral: a falta de entrosamento e a pouca aptidão para se trabalhar em equipe. Esta dificuldade envolve muitos pontos, mas vou me concentrar em apenas três: dificuldade de comunicação, desprezo por opiniões divergentes e atritos no relacionamento com superiores.

A comunicação é um das habilidades (soft skills) extremamente importantes quando se trabalha com programação em uma equipe. É preciso saber avisar o que foi feito, pedir opiniões, comunicar problemas, descrever cenários, solicitar tarefas, negociar prazo e mais uma série de outras atividades que não podem ser feitas sem boas habilidades comunicativas. Contudo, as pessoas que aprendem a programar desenvolvem um vício que chamo de economia verbal, pois na mente destas pessoas quanto menos palavras forem ditas melhor. É complicado conversar com um profissional com este vício em uma reunião, por exemplo, pois ele está tão aplicado em seu pensamento que praticamente despreza e dá o mínimo de atenção à comunicação.

Muitos programadores que conheci possuíam uma resistência e desprezo admirável a sugestões, opiniões ou comentários relacionados aos códigos que eles escreveram, especialmente quando se cita alguma falha, problema ou possível melhoria. Estas atitudes mostram que o há um forte senso de propriedade (algo como “o código é meu e eu sei o que faço!”) e falta de traquejo social para aceitar que nem sempre suas “crias” são as mais bonitas ou funcionam da melhor maneira possível. A provável razão deste comportamento é que quando a programação é realizada por uma pessoa que aprendeu sozinha ela não recebeu críticas, aconselhamento, opiniões, revisão e outros inputs durante seu aprendizado. Esta falta de um par extra de olhos acaba levando o programador a adotar atitudes defensivas e às vezes até agressivas quando ele se depara com o que outras pessoas acham do seu código.

O aprendizado individual acaba reduzindo a noção de que durante o trabalho provavelmente teremos algum tipo de hierarquia onde um ou mais pessoas vão assumir papéis de liderança. Quando se aprende sozinho o aprendiz é o seu próprio chefe e a cobrança é dele para ele mesmo. Contudo, no mundo real as coisas são um pouco diferentes, pois superiores (gerentes de projeto, supervisores, coordenadores e outros) possuem formas diferentes de pedir tarefas, cobrar resultados, trocar prioridades e gerenciar pessoas. Este conflito acaba levando a situações onde há algum nível de insubordinação que pode levar a ações punitivas. Na melhor das hipóteses o aprendiz reconhece que ele deve ficar quieto, ouvir e obedecer. Na pior das hipóteses pessoas abandonam equipes e juram que nunca mais vão trabalhar sob a supervisão de outros profissionais.

Falta de padronização na codificação

Figura3_CameCase
Quem aprende a programar sozinho presta pouca ou nenhuma atenção a detalhes como, por exemplo, a padronização dos nomes de elementos do programa. Se por um lado esta tarefa requer mais esforço e consome um pouco mais de tempo na codificação, por outro lado ela facilita muito a manutenção do código.

Apesar de muitos materiais didáticos, cursos, vídeos e outros recursos de ensino de programação recomendarem o uso de padrões de codificação ainda é muito comum encontrar profissionais que ou fogem destas praticas ou as implementam de forma parcial. Este tipo de comportamento acontece com todo mundo durante a carreira, mas tenho visto uma tendência muito forte ao desrespeito aos padrões de codificação para nomes de variáveis, classes, métodos, funções, procedures, interfaces e outros elementos de programação em profissionais que aprenderam a programar sozinhos.

Em alguns momentos a coisa ficou tão comum que já tive a impressão que estava perante uma epidemia de nomes ruins utilizados em variáveis, métodos, funções e procedures.  A vacina? Revisão de código e regras que forçam certos padrões ao ponto do código fonte não ser utilizado por ter uma qualidade abaixo do mínimo aceitável para que outra pessoa trabalhe com ele no futuro. Mesma se esta pessoa for o autor original deste código e que o programa esteja atendendo os requisitos funcionais.

Falta de conhecimento de ferramentas do mercado
Figura4_FaltaConhecimento

Quem está aprendendo a programar geralmente escolhe alguma linguagem, ambiente, plataforma ou tecnologia para “pegar o jeito da coisa”. Agir desta maneira é OK, mas é preciso lembrar que uma coisa é como você está aprendendo e outra é como o mercado e as empresas usam esta tecnologia.

Por exemplo: durante o aprendizado básico de criação de CRUDs raramente são citados aspectos de controle de transação para situações onde há a possibilidade de operações conflitantes. Já na realidade é relativamente comum encontrar problemas clássicos como deadlocks, phanton records e outros que vêm de reboque quando um sistema começa a ter muitos usuários e alguma atitude para atender a escalabilidade já foi tomada.

Outro exemplo clássico é a falta de conhecimento e uso de sistemas de controle de versão. Afinal de contas, quem aprendeu sozinho não se depara com a necessidade de compartilhar seu código com outras pessoas. Esta falta de conhecimento e uso de ferramentas de controle de versão (GitHub, CVS, Mercurial, Team Foundation e outras) é tão notória quanto o desconhecimento de ferramentas de automação de build como o ANT, Maven e Gradle. Devido à necessidade de uso destas ferramentas nas empresas é praticamente obrigatório um treinamento de novos colaboradores nestas tecnologias, o que acaba consumindo tempo e recursos valiosos que poderiam ser empregados em outras tarefas mais nobres, digamos assim.

Por fim, a prática de revisão de código (code review) soa como algo alienígena para quem estuda sozinho, afinal de contas por que eu pediria para alguém revisar o meu código enquanto estou aprendendo? Bem, sem entrar mais detalhes basta dizer que sessões de revisão de código não mais podem ser consideradas um luxo uma vez que seus benefícios já foram largamente comprovados em diversos estudos e situações reais.

Não investir na documentação
Figura5_FaltaDocumentacao

A documentação de código pode assumir vários formatos e, independente de como ela exista, é muito importante investir na sua criação. Esta documentação não é útil apenas para ajudar a esclarecer aspectos técnicos, mas também para organizar e gerenciar o trabalho de todos os profissionais envolvidos em um projeto de software seja no presente ou no futuro.

Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item obrigatório em qualquer projeto, servindo a vários propósitos. Contudo, por questões culturais e outros motivos tradicionalmente o brasileiro não é conhecido pelas suas habilidades de organização e documentação.

Novamente, uma forma de traçar a origem deste sério problema é analisar quem aprende sozinho. Neste cenário a tarefa de investir na criação de documentação recebe prioridade, pois o pensamento é que quem criou o código sempre vai se lembrar dele no futuro.  Já escrevi um pouco sobre isso com foco no DBA, mas acredito que as lições e tipos de artefatos apresentados naquela ocasião ainda são válidos e podem ajudar quem dá pouca ou nenhuma atenção à documentação.

Foco na implementação e não no design
Figura6_FocoImplementacao

Durante o período de aprendizado é comum gastar mais tempo tentando resolver os problemas do que analisando suas características. Isso já foi destacado no post que escrevi aqui no blog onde discuti e apresentei recomendação sobre como focar no problema ao invés da solução.

Quando me deparo com pessoas que aprenderam a programar sozinhas na maioria das vezes fica claro o padrão de comportamento representado pela dificuldade de analisar, conceber e pensar no design da solução e como este design deve ser separado da implementação do código. A avidez por sair codificando e utilizando os recursos de produtividade das plataformas de desenvolvimento mostra que o design e arquitetura acabam ficando de lado perante aspectos de implementação.

Tal atitude também fortalece e favorece o trabalho customizado no sentido que a cada novo problema a maneira de resolvê-lo vai ser diferente da anterior. Este modo de trabalho ad hoc pode ser bom para cenários altamente voláteis e com requisitos imprevisíveis (algo raro) que tornam a previsão da próxima necessidade impossível de ser conhecida. Não obstante, geralmente o trabalho no dia a dia requer um nível alto de sistematização das atividades onde processos e práticas comuns são largamente empregadas sem muito desvio.

Este tipo de trabalho sistematizado, previsível e altamente compartimentalizado é visto com bons olhos na programação profissional, pois ele permite que sejam feitas previsões e que metas sejam completadas com sucesso dentro do prazo. O que quero dizer aqui é que o vício do modo cowboy de programação (também chamado de heroico) é muito comum em cenários onde o programador tem a convicção de resolver tudo sozinho e que sem sua “mágica” nada vai funcionar corretamente. Contudo, agir desta maneira pode acabar sendo contraproducente quando é preciso encarar a programação de modo profissional.

Muita duplicação de código e pouca reusabilidade
Figura7_CopyPaste

Quando analiso código de outras pessoas fico atento a um dos principais indícios que me permite identificar se estou lidando com alguém que aprendeu sozinho: o abuso dos recursos de copiar e colar representado pela alta taxa de duplicação de código e quase nenhuma usabilidade.

Os recursos de copiar e colar estão entre os principais truques que aumentam a produtividade de quem programa. E pela facilidade destas operações é quase uma consequência observar que tanta gente acaba duplicando de forma inadequada o código ao invés de utilizar técnicas adequadas de reusabilidade.

O abuso das técnicas de copiar e colar e códigos fontes é tão disseminado que uma vez conversando com um colega ele sugeriu uma atitude radical: a criação de um “polícia do copy & paste”. Esta polícia seria responsável por detectar, julgar, sentenciar, punir e criar novas leis para erradicar e obliterar o uso bizarro de copiar e colar em código fonte. Acho que não preciso dizer que este meu colega era responsável por dar manutenção em código fonte legado e não conhecia ou não praticava algumas das técnicas descritas para manipular código legado descritas em outro artigo meu.

Aqui vale a pena investir em design patters, refatoração, componentização, uso de frameworks e o tão negligenciado olhar focado no design através da boa modelagem de classes, relacionamentos, interfaces e outros elementos.

Para fechar este post gostaria de terminar com um tom otimista: todas as pessoas que trabalham com programação possuem um ou outro hábito, vício ou mania ruim que pode ser melhorado. Isso faz parte do jogo. Mas acredito que nunca é tarde para para tentar reduzir o impacto que este hábito ruim pode trazer na vida profissional de um desenvolvedor.



Publicado em Programação | Com a tag , , , , , , , , , | 12 comentários

DatabaseCast 44: ORM

VitrineDatabaseCast44Neste episódio do DatabaseCast, o podcast brasileiro sobre banco de dados, Mauro Pichiliani e Wagner Crivelini mapeiam objetos e bancos de dados com a convidada Priscila Sato.

Neste episódio você vai compreender o que é e para que serve um ORM, onde esta tecnologia pode ajudar e atrapalhar, porque DBAs não gostam de abandonar o SQL, discutir sobre código gerado pelo ORM x código gerado por uma pessoa e tentar não perder a paciência com atitudes conservadores e ranzinzas.

Lançamento: Livro “Conversando sobre Banco de Dados” do Mauro Pichiliani nos formatos EPUB e MOBI

CAPA_AMAZON

Camisetas do DatabaseCast

Camiseta DatabaseCast Fluxo Matrix Camisa Data baseCast Sonho Fractal

Você pode comprar a camiseta com estampa fractal Fluxo Matrix  e Sonho Fractal  diretamente neste link.

Resultado da promoção: Ouça neste episódio o resultado da promoção que valia uma camiseta Fluxo Matriz ou Sonho Fractal do DatabaseCast.

Não deixe de nos incentivar digitando o seu comentário no final deste artigo, mandando e-mail para  databasecast@gmail.com, seguindo o nosso twitter @databasecast, vendo informações de bastidores e as músicas do programa no nosso Tumblr e curtindo a nossa página no Facebook.

Clique aqui para obter o endereço do feed RSS e assinar o DatabaseCast

Veja no gráfico abaixo a duração e os tempos aproximados de início e fim de cada bloco:

GraficoTamanhoDatabaseCastEpisodio44

Veja na tag cloud abaixo a contagem das palavras mais usadas nos emails, comentários e tweets do episódio anterior:

TagCloud_ep43Links do episódio:



Publicado em DatabaseCast, Podcast | Com a tag , , , , , | 1 comentário

Como se destacar na programação?

CapaPostA cada final de semestre milhares de recém-formados são despejados no mercado de trabalho quando os cursos de suas faculdades e universidades são finalizados. Isso quer dizer que a concorrência para uma vaga na área de programação ou banco de dados é grande e, mesmo assim, ainda há um enorme déficit de profissionais destas áreas.

Com base neste contexto resolvi escrever este post com algumas recomendações de como se destacar da maioria dos profissionais que terminam seus estudos e estão caminhando para o mercado de trabalho. Enquanto estas dicas não necessariamente vão acender a luz verde em um processo de contratação, elas têm o potencial de ao menos fazer com que a pessoa que olha o currículo note algo diferente que se destaca dos demais candidatos.

Faça mais do que o mínimo e do que a média

Quando estamos aprendendo uma tecnologia dentro de uma sala de aula geralmente vamos ver apenas o básico que ela proporciona devido a vários fatores como limitação de recursos, falta de tempo ou mesmo dificuldade de aplicação imediata. Isso contribui para que muitos aprendizes adquiram o péssimo hábito de fazer apenas o básico ou mesmo ficar na média dos demais.

Alguém que deseja de destacar na área técnica precisa primeiro identificar o que é o mínimo e o esforço médio que a maioria das pessoas fazem. Uma vez que isso esteja claro é preciso ter muita motivação, força de vontade e trabalho duro para se destacar e fazer muito acima do que a média das pessoas fazem.

O professor mandou ler os capítulos 1 e 2 do livro para a próxima aula? Leia o 1, 2,3 e o 4.

No trabalho em grupo você deve escolher um banco de dados e montar o modelo de dados de um sistema OLTP? Faça este modelo em diferentes bancos de dados e apresente também como ele poderia ser criado para um sistema OLAP.

Se o exercício pedir para criar um diagrama de classes com, no mínimo 5 entidades, aproveite a oportunidade e faça um diagrama com 10 classes.

Aprendeu um novo algoritmo clássico de ordenação? Implemente-o nas linguagens clássicas (Java, C#, C/C++) e também crie uma implementação em linguagens que pouca gente conhece como F#, Go, LUA ou outras.

Nas reuniões de grupo sempre chegue mais cedo e aproveite para revisar o que vai ser discutido. Se marcaram às 08:00, segue às 07:30 e deixe bem claro para todos que você leva muito à sério este tipo de atividade.

Todos os membros da equipe estão confidentes que o plano vai funcionar logo de cara? Tenha um plano B e C pronto para ser implementado mesmo que ninguém saiba disso.

Mostre iniciativa

Iniciativa

Em muitas situações a pessoa que mostra uma iniciativa acaba sendo recompensada, seja de uma forma ou de outra. Quem está começando na área e é convidado a participar de projetos sempre deve mostrar a iniciativa para resolver problemas, otimizar soluções, reduzir custos, tornar algo mais fácil, acelerar processamento e realizar outras atividades que vão além do que é comandado por quem está à frente do projeto.

Já escrevi sobre isso antes, mas repito aqui: entrar em uma reunião mudo e sair calado é uma receita certa para que o profissional não seja notado. A propósito, sempre procure evitar participar de um projeto, reunião ou encontro de mãos vazias, ou seja, traga sempre alguma ideia, novidade, recurso ou algo que posso ser discutido.

Mesmo que as pessoas não apreciem isto ou que esta iniciativa logo seja descartada a atitude de trazer algo que contribua não vai passar em branco e manda uma mensagem clara para todos os envolvidos: você gastou um tempo se preparando e não apareceu de mãos abanando para o encontro.

Invista na sua carreira

InvistaCarreira

As carreiras que envolvem programação e banco de dados estão em constante atualização, pois sempre há uma nova versão de software, modelo de desenvolvimento, patch, service pack, anúncio sobre o rumo da empresa ou outro tipo de notícia relevante para os profissionais da área.

Quando o profissional está saindo da faculdade e quer entrar no mercado de trabalho sinaliza que ele ainda tem muito que aprender e que não vai parar de investir na sua carreira ele está sendo maduro e demonstrando que entende como a área funciona. Indicar que há interesse em algum curso, workshop, treinamento, livro ou outro tipo de forma de atualização é um ponto positivo que pode fazer a diferença em uma entrevista de emprego.

Atualmente é muito mais fácil encontrar pessoas que descrevem seus sonhos de consumo como itens materiais (novo carro, apartamento, celular, etc) ou em experiências (viagens, shows, cruzeiros) do que pessoas que investem em oportunidades para aprimoramento pessoal como cursos, intercâmbios e bolsas de estudo. Não há nada de errado em ter sonhos de consumo comuns, mas quando a pessoa passa mais tempo almejando conquistar algo que não têm relação direta com a carreira isso deixa claro qual é o tipo de perfil que ela representa.

Bata metas e quebre recordes

MonstersUniversity

Muitas oportunidades na área de desenvolvimento surgem para aquelas pessoas que acabaram se destacando em outras áreas e mostrando que são competentes. O caso clássico envolve os profissionais que trabalham com suporte, telemarketing e infra que foram muito competentes ao ponto de receberem convites para as áreas que realmente lhe interessam.

Quando se está começando no mercado de trabalho é comum passar por situações, ambientes, áreas e até problemas que as pessoas com mais senioridade não passariam. Apesar desta situação ser um pouco desmotivante, é preciso lembrar que tal cenário pode ser apenas um passo para alcançar algo melhor no futuro.

Independente da área ou contexto na qual o profissional começa, ele deve se lembrar de que sempre é possível se destacar alcançando (e ultrapassando) as metas e batendo os recordes existentes. Isso me lembra uma das cenas finais do filme Universidade Monstros. Sem conter muitos spoilers, em um determinado momento do filme os personagens não conseguem atingir o objetivo da maneira que eles planejaram inicialmente. Mas isso não fica assim, pois eles começam por baixo galgando diversos postos até finalmente chegarem na área que eles queriam. E como eles fazem isso? Simplesmente trabalhando duro, se dedicando e batendo metas e recordes em cada uma das áreas que eles foram colocados mesmo quando o que eles têm que fazer é muito distante do objetivo final deles.

Não tenha medo de arriscar

Risco

Profissionais iniciantes (e até alguns experimentes) muitas vezes apresentam certo receio e medo de se arriscar para modificar e realizar tarefas que ninguém que fazer como, por exemplo, a manutenção de código fonte legado. Este comportamento é justificado pela complexidade, precariedade ou falta de motivação de se trabalhar com uma base de código antiga, possivelmente ultrapassada e que tenha características que não atraem quem está envolvido na programação.

Um exemplo são sistemas antigos que ninguém mais altera com medo de fazer parar de funcionar. Na mente dos profissionais ser alocado para realizar manutenção nestes sistemas é encarado com uma armadilha, pois se por algum motivo o profissional manipular o código e o sistema parar de funcionar isso certamente será motivo para algum tipo de punição. Por outro lado, esta situação é uma excelente oportunidade para que o profissional se destaque.

A solução na maioria dos casos é confiar que este sistema jurássico funciona e cercar ele de serviços que podem ser testados. E quando a empresa não acredita em testes e considerar que a linha que acaba de ser escrita já está legada? Esta afirmação não é sempre verdade, pois caso seja um sistema pequeno onde é a alteração é fácil (um CRUD simples, por exemplo), talvez os testes não sejam tão importantes.

Se por um lado receber a tarefa de trabalhar com este tipo de sistema jurássico e que ninguém mais quer manipular gera medo e receito, por outro lado esta tarefa pode ser uma ótima oportunidade para que o profissional realize um excelente trabalho e se destaque na carreira perante outros que não quiseram fazer tal trabalho. Certamente o profissional que conseguir enxergar uma oportunidade neste tipo de situação vai conseguir se aprimorar tecnicamente e também demonstrar para seus superiores que ele não tem receio de encarar situações que, além de lhe forçarem sair de sua zona de conforto, são tecnicamente desafiadoras.

Tomar a atitude de assumir a responsabilidade pela manutenção de um sistema legado que não atrai programadores requer muita coragem e tempo de treinamento para realizar alterações, mesmo que sejam superficiais. Em compensação, o profissional pode sair valorizado, tecnicamente mais experiente e também melhorar sua autoestima e se destacar dos demais.

Mostre que você consegue se virar bem nas adversidades tendo imaginação e soluções criativas

Criatividade2

A criatividade é uma das habilidades geralmente ssociada ao pessoal de design, marketing, comunicação ou área de produção. Contudo, ela é uma habilidade extremamente importante por quem trabalha na área de desenvolvimento e que envolve programação e banco de dados.

Muitas vezes o famoso “pulo do gato” ou “truque” tem pouco a ver com inspiração ou com aquele momento eureca que somente gênios são capazes de produzir. Isso quer dizer que para se destacar sendo criativo existem várias atitudes e comportamentos ao longo da carreira que não podem ser resumidas ao simples fato de acordar do meio da noite e ter uma ideia genial. Criatividade e imaginação também devem ser cultivadas através de vários estímulos e referências e o profissional que dominar como exercitar seus pensamentos para agir de forma criativa certamente estará a um passo à frente dos demais.

Participe de concursos e competições

Hackathon

Atualmente a área de programação possui diversas atividades que ajudam muito um profissional a ter um item que se destaca no seu currículo. Estou falando sobre concursos, competições, hackathons e outros eventos que de alguma forma ou de outra premiam os seus melhores colocados.

Tais eventos geralmente são presenciais e podem despertar o interesse de um entrevistador. Participar deste tipo de evento mostra que o profissional está interessado em resolver problemas e quer testar suas habilidades de forma competitiva. Estas qualidades são algo que podem tornam o profissional muito atrativo para empresas, pois mostra que ele está fazendo algo em seu tempo livre além do que a maioria faz.

Faça o seu networking em eventos

O estereótipo do profissional que trabalha com desenvolvimento muitas vezes é retratado como aquela pessoa antissocial, que não se comunica, trabalha melhor sozinho e não se preocupa com nada que está além da linha de código. Este rótulo já deixou de ser verdade há muito tempo e, inclusive, atualmente ele não tem mais a conotação de profissionalismo necessário para o mercado de trabalho.

Isso quer dizer que quem deseja se destacar e prosperar na área precisa ir a eventos, conversar com pessoas, anotar contatos, mostrar interesse pelo que o outros fazem, fechar parcerias, montar projetos em conjunto com outras pessoas e, o mais importante, ser visto.

Uma ótima oportunidade para estas realizar ações é participar de conferência técnicas e não técnicas (voltadas para CEO) da área de forma ativa, ou seja, conversando com a maior quantidade de pessoas possíveis e aumentando a rede de contatos (o famoso networking). Certamente tal participação reflete na carreira do profissional e é uma excelente oportunidade para colocar em prática as habilidades de marketing pessoal que fazem com que as pessoas saibam quem é quem, que está aonde e quem é capaz do quê.

Esteja engajado em algum projeto pessoal ou colaborativo

Collaborate

Independentemente da escolha que o profissional estudou saber trabalhar com desenvolvimento requer algum grau de experiência, tanto na parte teórica quanto prática. E é aí que está o problema: a falta da parte prática, pois a teoria é relativamente fácil de ser obtida através de estudo, cursos, faculdade etc.

Mas como conseguir experiência com desenvolvimento e se destacar se todas as entrevistas de emprego pedem essa tal experiência? Uma ótima forma de se ganhar experiência em programação, e por tabela com banco de dados, é a participação de projetos de software livre. Sim, esses projetos são abertos à comunidade e sempre estão precisando de colaboradores.

Muitos projetos de software livre precisam de colaboradores de todos os níveis, desde aquele programador avançado até quem está começando a aprender a utilizar o computador. O importante é compreender o espírito de colaboração e saber contribuir para o projeto com algo relevante. Com certeza quem coloca no seu currículo que participa ativamente em um projeto de código livre mostra um diferencial na hora da contratação, assim como quem tem certificação também se diferencia. Porém colaborar para um projeto de software livre, independentemente do nível do projeto ou do tipo de colaboração, mostra que o profissional sabe trabalhar em grupo, é proativo e está em sintonia com a comunidade.

É claro que existem diversas formas de contribuir para um projeto de código livre. O primeiro passo é conhecer o projeto, como funciona e qual é a sua finalidade. Em seguida, é preciso entrar em contato com os membros que participam do projeto, geralmente através da lista de discussão de e-mail, fórum, comunidades em redes sociais e até pelo Twitter. Este é um ponto chave: apresentar aos membros do projeto quem você é, como você quer contribuir, como está engajado.

A contribuição em si pode variar. Não sabe programar? Tudo bem, você pode montar uma documentação, ajudar na tradução ou mesmo sugerir melhorias ou reportar bugs. Normalmente o começo é assim, devagar. Porém, com o tempo, é possível assumir mais responsabilidades, desde que você entenda a visão dos membros mantenedores do projeto e se adapte à forma de trabalho deles. Novamente, o importante aqui é ter vontade de contribuir para ganhar experiência. Divergências sempre vão surgir, mas, pelo menos a princípio, é importante deixar claro até que ponto você pode contribuir no projeto e como você pretende realizar essa contribuição.




Publicado em Programação | Com a tag , , , , , , , , , | 4 comentários

Meu livro na Amazon

CAPA_AMAZONDepois de algum tempo vendendo meu livro no formato impresso e PDF pelo Clube de Autores resolvi atender alguns pedidos e publicá-lo no formato EPUB e MOBI através do serviço de auto publicação da Amazon.

Estes dois formatos digitais são mais adequados para e-book readers, como o Kindle, e tablets. A propósito, quem tem algum dispositivo iOS ou Android pode baixar gratuitamente o applicativo do Kindle (aqui na Google Play e aqui na Apple Store) para conseguir ler o livro.

O conteúdo é o mesmo entre as versões PDF, MOBI e EPUB, a não ser pela diagramação e a capa. Outra diferença é que preço da Amazon é um pouco abaixo do preço do Clube de Autores devido à aspectos relacionados à cotação do dólar. Contudo, este valor varia muito, principalmente devido às promoções que acontecem em ambos os sites.

Novamente, agradeço ao meu colega Wagner Crivelini por escrever o prefácio e sempre me incentivar nessa área.




Publicado em Livro | Com a tag , , , , , , , , , , , | 1 comentário

Aggregation fail

PostAggregationFailCapaVitrine

Recentemente ouvi este termo – aggregation fail – e fiquei pensando um pouco sobre ele. Quando trabalhamos com tecnologias para BI, especialmente OLAP, é comum agregarmos dados para realizar análises. Geralmente esta agregação é feita pela média de valores ou pelo soma total, mas vou me concentrar apenas nos casos que utilizam a média.

Quando utilizamos o valor médio para uma análise precisamos levar em consideração que, dependendo da quantidade de dados, é possível ter sérios problemas de interpretações nas análises. A propósito, a primeira vez que ouvi o termo aggregation fail foi no vídeo abaixo que detalha o projeto selficitie, cujo objetivo é analisar detalhes sobre o fenômeno de fotos tipo selfie.

Voltando a falar sobre a média, quando analisamos apenas o valor desta métrica podemos ter problemas em compreender efetivamente como os dados são distribuídos e chegar a conclusões incorretas. A figura abaixo ilustra um pouco desta situação onde podemos nos dar mal se considerarmos apenas a média.

FiguraBuraco

Infelizmente muitas pessoas, e em especial jornalistas que gostam de generalizar e criar títulos chamativos para notícias, não conseguem compreender as implicações de analisar apenas a média. E quem conhece um pouco mais sobre estatística sabe como é importante apresentar a média acompanhada de outros valores como o valor mediano e o desvio padrão. Estatisticamente falando, podemos utilizar também a moda para comparar melhor o comportamento dos dados.

FiguraMediaMedianaModa

Do ponto de vista de visualização de informações e algoritmos, precisamos sempre considerar vários aspectos quando trabalhamos com grandes quantidades de dados. Pensar somente na média é contraproducente, mas pode ser um bom começo para análises mais profundas.

Não há muito um caminho certo ou errado a seguir aqui, mas sou a favor e acredito que a combinação de estatísticas, agregações, mineração de dados e ferramentas que permitem manipular os dados podem ser mais úteis para a descoberta de padrões e valores muito fora do comum e anormais do que a análise de dados agregados pela média. Por exemplo: a figura abaixo mostra o rosto médio de mulheres de acordo com diversos países. Esta visualização é interessante, mas há muito mais por trás disso do que a imagem mostra, especialmente em casos onde há populações com pouca miscigenação e com características faciais marcantes mantidas a gerações.

average-facePor isso sempre que me deparo com uma análise de dados ou ferramenta de BI fico a procura de como os dados podem ser mostrados além da média ou outra forma de agregação. Este ponto é algo que agrega valor ao produto e permite análises mais detalhadas do que simplesmente enquadrar valores em grupos ou estereótipos de acordo com valores médios.




Publicado em Programação, Uncategorized | Com a tag , , , , , , | Deixar um comentário