Efetividade.net sorteia produtos da Papelaria Cícero
Há um tempo atrás interessei-me pelos produtos da Papelaria Cícero, especificamente, pela Agenda Semanal 9×13 da Linha Couro. Cheguei, inclusive, a solicitar imagens internas das agendas. Os produtos pareceram-me bem acabados, mas não comprei a agemda porque já estava em agosto e deixei para o próximo ano.
Internas das agendas
Augusto, do Efetividade.net, recebeu amostras grátis dos produtos da papelaria e comentou sobre a boa qualidade dos produtos. O artigo veio em boa hora porque estava em dúvida se deveria comprar ou não uma caderneta também. Como os produtos foram muito bem avaliados, sanei minha dúvida: na minha próxima compra no Submarino, comprarei a agenda mais uma caderneta sem pauta.
Como vieram muitos produtos, ele resolveu sortear, entre os leitores do Efetividade.net, várias cadernetas de tamanhos diversos com e sem pauta. Para participar da promoção, veja as regras no site.
Descolagem #3
Luli Radfahrer http://videolog.uol.com.br/video.php?id=389425
computador nao eh ferramenta, eh linguagem.
tecnologia nao eh solucao nem eh o problema. nao eh deus nem o demonio. nao idolatrar nem rejeitar.
armadilhas do absoluto.
escola nao é centro de treinamento. a escola nao foi feita para proporcionar respostas. isso é a coisa mais dificil que tem pra neguinho aprender. ninguem vai pra escola para aprender. voce vai pra escola pra aprender a perguntar. o fim da escola é o comeco do dialogo. a hora que voce termina a escola é a hora que voce comeca a pensar. a universidade é um lugar que voce passa quatro anos aprendendo a fazer uma pergunta, que é a pergunta que voce vai fazer pro resto da sua vida. (…) a escola serve para inspirar voce. (…) o professor é só o seu guia.
professor é o cara que propõe a pergunta.
não é o avaliador, carrasco, pronto pra cortar a cabeça
do moleque se ele fizer besteira.
avaliação é parte do processo.
avaliação não é a função.
a escola de hemisfério norte tinha acesso à informação antes.
eu não preciso ter toda informação em mim (…) ela está acessível em algum lugar.
Patrícia Konder http://videolog.uol.com.br/video.php?id=391906
a forma de pensar do homem se modifica com esses diferentes suportes [de relacionamento com o mundo].
Kart em João Pessoa
Speed Kart Indoor
Onde
- Rua da república, ao lado cemitério, no galpão da antiga Matarazzo
Quanto
- 15 minutos: R$ 25,00
- 20 minutos: R$ 30,00
- 30 minutos: R$ 45,00
Horários
- Segunda a Sexta: 18:00-22:30h
- Sábado, Domingo e feriados: 15:00-22:30h
Reservas
- Mônica nos telefones 8816-4940 e 3224-1464
Observações
- Mínimo 5 karts, máximo 8. se levar turma com menos de 8 karts e houver gente esperando, entra na bateria;
- 2 karts reservas;
- Informações válidas em 19 de Agosto de 2009
Web 2.0 e RSS
Quem passou os últimos anos em Marte e não tem a mínima noção do que são as palavras Web 2.0 e RSS, leia:
Não espere que a informação, toda e qualquer, inclusive a irrelevante, venha até você através do e-mail. Selecione suas fontes e busque o que realmente lhe interessa. Este é o princípio do RSS.
Sites para aprender inglês
- As Palavras Mais Comuns da Língua Inglesa, por Rubens Q. Almeida (2001)
- English Experts
- Inglês na Ponta da Língua
- Inglês On-line
- Tecla SAP
- BBC Learning English
- About.com ESL
- Ingles Pra Que? – Dicas de Inglês
Podcasts
- English as a Second Language Podcast
- The Word Nerds
- This American Life
- EnglishLingQ
- BBC Grammar Challenge
- BBC How to…
- BBC Talk About English
- EnglishPod
- Business English Pod
- Listen to English – learn English!
Conversação com nativos
Dicionários com pronúncia de palavras de forma sintética:
Pronúncia de palavras por nativos:
Download dos feeds em formato OPML. Caso não saiba o que é OPML Web 2.0 e RSS.
Novas linguagens de programação e software legado
Fabio Cevasco lista possíveis 10 linguagens de programação que poderiam ser aprendidas no ano de 2009. Há quem discorde da prática de aprender uma nova linguagem de programação a cada ano.
Enquanto ainda há gente rodando software em Cobol de 20 anos ou programas escritos em assembly – porque não havia outra linguagem disponível na época – há quem rode “the best and the brightest situational-Web 2.0-agile-social-networking-enabledsemantically-dense-cloud-basedsystems-of-systems-script-based software” (Booch) e, em poucas semanas, considere-o velho porque surgiu a novíssima e a melhor tecnologia dos últimos tempos da última semana (propaganda clichê).
Independentemente do mérito de aprender ou não uma nova linguagem de programação, seja por experimentação ou por demandas e necessidades mais sofisticadas, por exemplo, concorrência, faz-se necessário entender que sistemas escritos em novas linguagens possuem quase nenhuma representatividade no mercado de trabalho. Possivelmente serão Java, 14 anos de estrada, que segundo os apocalípticos já está tornando-se o novo COBOL, C, com quase 40 anos continua sendo importante no cenário na indústria, e C++, 30 anos em 2009, que pagarão suas contas. Estas são, respectivamente, as três primeiras colocadas no índice TIOBE e em muitos outros rankings. O ranking de Janeiro de 2009 esta abaixo:
TIOBE Programming Community Index for January 2009
Muitos novos profissionais frustram-se ao depararem-se com a realidade de dar manutenção em sistemas antigos, com linguagens de programação “defasadas”. Sommerville estima que cerca de 80% do tempo de vida do software seja dedicado à manutenção e evolução. Por isto que linguagens de programação “ultrapassadas” como Visual Basic, Delphi e Perl ainda configuram na lista entre as 10 linguagens mais populares em janeiro de 2009, logo abaixo, entre as top 20, aparecem ABAP e COBOL. Não é nenhuma surpresa elas dividem espaço com linguagens mais novas.
TIOBE Long term trends
O certo é que software legado é realidade nas empresas, encará-lo é questão de tempo. Ele existe porque tem valor para seus usuários e, principalmente, porque não é trivial substituí-lo. Cedo ou tarde as empresas deparam-se com a pergunta: o que fazer com meu software legado? Para Booch, além da natural manutenção, há outros possíveis fins para software legado:
- Abandoná-lo, jogar na lata do lixo;
- Abrir o código fonte para a comunidade;
- Ignorá-lo, isto é, apenas deixá-lo rodando como está hoje, por exemplo, como os bancos fazem há décadas com muitos de seus sistemas;
- Mantê-lo rodando em sua plataforma original, pois software legado não é multi-plataforma, tentando assim encontrar e comprar o hardware antigo onde ele roda quando a disponibilidade da plataforma é o maior desafio;
- Reescrevê-lo em novo ambiente, plataforma e linguagem;
- Inspirar-se e criar novo software baseado no conhecimento embutido no código;
- Encapsulá-lo em serviços, SOA, para ser usado como componentes de um novo software;
- Mantê-lo e evoluí-lo no seu ambiente atual;
- Preservá-lo, doando-o a um museu.
Importante frisar: a linguagem é apenas uma pequena parte do ecossistema técnico do desenvolvimento de um software. O melhor mesmo é aprender a programar em vários paradigmas e, de preferência, em qualquer linguagem para encarar o duro mercado de trabalho.
Referências:
- Booch, G. 2008. Nine Things You Can Do with Old Software. IEEE Software September/October 2008.
- Sommerville, I. 2004 Software Engineering (7th Edition). Pearson Addison Wesley.
Mais blogs no Planeta DI/UFPB.
Encontrei mais alguns blogs de pessoas ligadas ao DI/UFPB.
- Intercambistas: Michael van der Linden em Bremen, Alemanha, e Rebeca Dantas em Lyon, França;
- Erisvaldo Junior, aluno de graduação;
- Herbet Ferreira, ex-aluno de graduação, em Recife.
Endereço do feed: http://feeds.feedburner.com/planetadiufpb
Atualização em 30/03/2009
- Raphael Marques, mestrando – http://raphaelmarques.wordpress.com/
- Igor Cavalcanti, DBA no SERPRO: http://igorcavalcanti.wordpress.com/
Dicas sobre Padrões de Projetos
Dúvida de um aluno:
- Prof. Kelon, gostaria que você pudesse nos sugerir o uso de alguns padrões para utilizarmos no nosso mini-projeto. Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.
A minha resposta segue logo abaixo.
Três coisas:
- Para poder recomendar algo, preciso conhecer melhor como você está projetando seu software e para qual ambiente;
- Padrões de Projeto (PP) são usados por necessidade e não ‘usar por usar’. É a mesma coisa de você querer encaixar Herança onde não existe só para depois dizer que usou polimorfismo. Sei que não é estritamente seu caso, pois entendo o que você está pedindo, porém é salutar ressaltar;
- Padrões de Projeto não são solução para software mal projetado. Novamente, não estou sugerindo que este seja seu caso, mas talvez seja o caso de alertá-los para ‘Buzzword bingo‘ (vídeo de comercial IBM).
Retomando o que falei no início, elaborarei um pouco mais o item (3). Volto a falar, mais uma vez, que balas de prata não existem e possivelmente nunca existirão
O mais próximo que temos da famigerada bala de prata são bons projetistas (arquitetos) de software (de arquiteturas), pois eles buscam direta e primariamente minimizar os problemas essenciais de software, principalmente complexidade e conformidade (com o ambiente onde é implantado). Por isto que ratifiquei o link compartilhado e enviei outro sobre o mesmo assunto: Projeto de Software Orientado a Objetos.
De nada vale usar os 23 padrões de projeto clássicos se você força uma hierarquia de classes apenas para usar determinado padrão, isto é, você adapta seu projeto para acomodar um padrão. O que deveria ocorrer é muito diferente: o projeto de sua aplicação, naturalmente, sugerirá os padrões a serem aplicados.
Por exemplo, considere o caso de um objeto exigir mudanças em outros quando ele próprio é alterado, mas você não sabe quantos outros objetos necessitam ser modificados, como em um software de segurança residencial que dispara sinal de alerta para os vários alarmes no momento que a residência é invadida. Este problema é recorrente em várias outras situações e é resolvido com o padrão Observer. A depender de como sua solução foi projetada, o padrão Observer será a solução óbvia. Claro que ter conhecimento sobre PP auxilia a pensar e projetar as soluções, porém sozinhos não resolvem problema algum. O problema de projeto de software é mais embaixo, este é o ponto.
Para aprender a projetar software OO, recomendo Larman, C. 2004 Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR. Livro que vai do básico ao avançado em se tratando de análise e projeto orientados a objetos.
Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.
Você já usa vários padrões sem saber (pena o link não exibir alguns dos códigos).Mas, continuando a explicação anterior, padrões de projetos são usados quando se identifica uma oportunidade para tal, isto é, quando percebe-se que determinado problema é recorrente e já tem solução disponível. Quando isto ocorre, você consulta catálogos de padrões, verifica se há um padrão que resolve o problema e lê como ele deve ser solucionado. Para isto, sugiro ler Comentários finais sobre Design Patterns, que aponta para Sinopse dos Design Patterns da “Gang of Four”, pois é um resumo bem elaborado dos padrões clássicos de GoF.A [finada?] Argo Navis tem dois ótimos cursos no tema, com material disponível para download: J930: GoF Design Patterns em Java e J931: J2EE Design Patterns. A Argo Navis ainda disponibiliza um mini-curso sobre o tema. Veja o que há nos pré-requisitos do segundo curso: “[...] É fortemente recomendado que o aluno tenha conhecimentos de Design Patterns clássicos (GoF) – pelo menos os mais importantes (Observer, Composite, Strategy, Command, Factory Method, Abstract Factory, Iterator, Proxy, Adapter, Façade, Singleton, Decorator) pois eles não serão revisados e são aplicados em vários padrões J2EE. [...]” (Grifo meu). Sendo assim, a dica é ler os dois primeiros capítulos do livro Design Patterns: Elements of Reusable Object-Oriented Software, de Gamma e demais, e depois ler esses padrões citados. O primeiro capítulo do livro explica o que são padrões de projeto, enquanto que o segundo exemplifica seu uso no projeto de um editor de textos complexo.O livro da GoF é leitura obrigatória para qualquer engenheiro de software comprometido com sua carreira. Subindo um pouco o nível de abstração, seguem Pattern-Oriented Software Architecture: a System of Patterns, de Buschmann e colegas, e Patterns of Enterprise Application Architecture, de Fowler. No nível mais abstrato, Software Architecture in Practice, 2nd edition, de Bass, Clements e Kazman. Catálogos de PP online:
- Gamma et al, Clássicos – Não substitui a leitura do livro;
- Fowler, Patterns of Enterprise Application Architecture;
- Booch (um dos líderes da UML e RUP, por sinal), Handbook of Software Architecture (precisa de registro);
- Java BluePrints Patterns Catalog;
- Alur, Crupi e Malks, Core J2EE Patterns;
- Veja padrões de projeto na prática no software Java Pet Store 2.0 Reference Application.
