Os quatro estágios da competência

Os quatro estágios da competência é uma teoria desenvolvida por Noel Burch em 1970 e que fala como o aprendizado acontece e evolui até uma pessoa desenvolver o conhecimento e habilidade necessários relacionado a uma determinada competência em uma determinada área.

A teoria é bem simples, determinando 4 estágios da competência:

1º estágio) Incompetência inconsciente:

A pessoa não tem a habilidade e nem sabe que ela existe, não sente necessidade ou desejo de ter a habilidade.

Também conhecido como "eu não sei que eu não sei".

Por exemplo, deve existir uma tecnologia (linguagem, framework, hardware, etc) de que nem ouvimos falar e nem sabemos que existe, logo somos inconscientemente incompetentes nesta tecnologia.

2º estágio) Incompetência consciente:

A pessoa não tem a habilidade mas sabe que tem de aprendê-la, reconhecendo a deficiência.

Também conhecido como "eu sei que eu não sei".

Por exemplo, conheço a linguagem de programação Haskell mas nunca programei nela, é algo que eu gostaria de estudar quando tiver tempo. Em outras palavras, sei que Haskell existe, que é útil, então sou consciente da minha incompetência em Haskell, pelo menos até aprendê-la.


3º estágio) Competência consciente:

A pessoa tem a habilidade necessária, realizando de imediato ou localizando recursos para realizar, sendo necessário concentrar o esforço no tarefa.

Também conhecido como "eu sei que eu sei".

É quando as tarefas são feitas sem desespero, se tem o conhecimento fundamental necessário ou sabe-se onde obtê-lo. É onde me vejo nas linguagens Ruby, Python, ActionScript, entre outros, que embora eu programe razoavelmente bem por vezes tem um recurso que não conheço e tenho que consultar a documentação. Neste instante é possível obter todas as informações necessárias através da documentação da API, tutoriais, livros, colegas de trabalho, etc.

4º estágio) Competência inconsciente:

Também conhecido como "eu não sei que eu sei".

A pessoa tem o conhecimento e habilidade necessários para desenvolver as tarefas ao ponto de não ser necessário concentração excessiva ou acesso a documentos. Acontece naturalmente, como assoviar.

Penso ser este o estágio que chamamos de "dominar", estar "calejado". Apenas problemas muito exotéricos necessitam acesso a documentação e práticas incomuns, pois a maioria dos detalhes já são conhecidos ou deduzidos daquilo que já se sabe. Dado meu contato e o estudo para certificação, penso estar neste estágio na linguagem Java.


Ainda há o Possível 5º estágio: Competência consciente de competência inconsciente:

No 4° estágio as pessoas fazem as tarefas tão naturalmente que passam a ter dificuldade de explicar para outra pessoa. Então, o 5° estágio assume que a pessoa tenha a habilidade de reconhecer sua competência inconsciente e controlá-la o suficiente para pode desenvolver essas competências em outras pessoas. Este é o estágio necessário para quem é professor, tutor ou tem algum relacionamento comunicativo, de liderança, e tem de passar habilidades a outras pessoas. Já tentaram ensinar alguém a assoviar? Eu acho muito difícil.

Em que estágio tu estás e em quais competências? Não é uma boa reflexão?


Fontes:
http://en.wikipedia.org/wiki/Four_stages_of_competence
http://en.wikipedia.org/wiki/Competence_(human_resources)

ActionScript por um programador Java: parte 2

Mais uma semana de desenvolvimento com Flex e ActionScript, mais algumas diferenças para o Java.

- Em ActionScript não é possível sobrecarregar um construtor ou um método, por exemplo, em Java posso fazer isso:

public void pagamento(Date dataPagamento, Double valor) { ... }

public void setPagamento(Double valor) { ... }

*Caso se o vencimento for omitido eu possa usar a data atual como data do pagamento.

Em ActionScript dá para fazer assim:

public function pagamento(valor:Number, data:Date=null) : void  { ... }

Nesta caso assumo a data com o valor padrão null, tornando o parâmetro opcional. Note, os parâmetros obrigatórios sempre tem que vir primeiro, como o valor. 

Agora posso chamar este método assim:  instancia.pagamento(100); ou assim: instancia.pagamento(100, new Date(2010, 1, 10));

- No ActionScript também existe algo semelhante ao varargs do Java, chamado de "rest". Posso declara o método como abaixo:

public function pagamento(valor:Number, ... outrosArgumentos) : void  { ... }

Neste caso, as reticências declaram um argumento "rest", que é um Array e pode ser iterado no corpo do método. Assim como no Java o argumento rest (varargs no Java) tem que ser o último argumento. No Java é assim:

public void pagamento(Double valor, Object ... outrosArgumentos) { ... }

ou 

public void pagamento(Double valor, Date ... datas) { ... }

Neste caso posso chamar este método definindo ou não o segundo argumento (terceiro, quarto...). Note que Java é tipado, ou seja, não há definição de tipo no Runtime como no ActionScript então ele deve fazer parte dos argumentos, diferente do AS.

- No ActionScript as funções são objetos e podem ser atribuídas a uma variável como abaixo:

var pagamento:Function = function (valor:Number) : void { ...}

Também podem ser passadas como parâmetros, como abaixo:

public function fazAlgo(metodo:Function) { ... }

Isto é especialmente útil para delegar ou fazer callbacks, caso dos retornos de chamadas no tratamento de Eventos, como abaixo:

btPagamento.addEventListener(MouseEvent.CLICK, pagamento);

Neste caso, pagamento é uma função. No C# é semelhante. Particularmente acho este método de tratamento de eventos muito melhor que no Java que usa o padrão Observer/Observable para implementar.

Bom, por enquanto é só, escrever ajuda a memorizar.

ActionScript por um programador Java

Já tive um pouco, pouco mesmo, de contato com ActionScript quando fazia testes 'domésticos' com Adobe Flex, mas nesta semana, graças a oportunidade de participar do Projeto da Vonpar, que é baseado em Back-end Java e Front-end Flex, comecei a observar as primeiras nuances, prós, contras, entre outros, claro, na minha perspectiva de desenvolvedor Java.

Todos que já leem esta lista e acompanham as minhas mensagens já devem saber que sou adepto do conceito: Não é a linguagem, mas o programador que faz um bom sistema.

ActionScript é uma linguagem orientada a objetos e como tal é muito semelhante a Java, C#, etc. Acredito que a principal barreira para um programador, como foi o meu caso que programa em linguagens procedurais, é entender OO.

Então, penso que para aprender uma nova linguagem baseada mesmo paradigma, a receita é:

1 - Prestar atenção na sintaxe:

   Várias vezes declarei um método assim:
   public void setValor(Double valor) {...}

   Quando deveria ser feito assim:

   public function setValor(valor:Number) : void 

{...}

   A diferença é auto-explicativa, apenas sintaxe e tipos.

2 -  Descobrir os recursos ausentes e usar outras estratégias (não confundir com Workarounds):

   Por exemplo, não tem Enumerado no ActionScript 3, então ...
   Usar os velhos campos estáticos constantes, como no Java 1.4  (enums vieram a partir do 5)

   Quase sempre é possível achar uma maneira elegante.

3 - Descobrir os recursos presentes na nova linguagem:

   Tchê, muito bom o recurso de declarar métodos de leitura e gravação (get e set) e ler como se fosse um atributo, basta fazer assim:

public function set valorConta(valor:Number) : void { /* lógica aqui */ }


   public function get valorConta() : Number { /* lógica aqui */ }

   Se a classe se chama Conta, eu posso acessar o valor de outra classe em uma instância da Conta assim:

   conta.valorConta    OU    conta.valorConta = 200;

   Pode parecer um atributo, mas é um get e set (acessores implícitos).

Uma dificuldade especial é trabalhar com a arquitetura assíncrona de requisição e resposta, mas para quem já uso JavaScript XML HTTP Request (Ajax no braço) é fácil se acostumar.

Estou de saída, e existem outros detalhes que deixarei para outro post.

REST Anti-Patterns

Comecei a estudar REST (REpresentational State Transfer) a algum tempo atrás, quando fazia testes com Adobe Flex usando HTTP-Service e backend Java com Servlets, solução caseira, antes de ser padronizado como uma JSR: JSR 311: JAX-RS: The Java API for RESTful Web Services (http://jcp.org/en/jsr/detail?id=311)

Com meu ingresso na Voiza e popularização do REST comecei a estudar melhor os conceitos e formas de aplicação desta estratégia, usada para desenhar e implementar aplicações com baixo acoplamento e que facilitem o intercâmbio de informações com outras aplicações.

Os protocolos utilizados, do nível mais baixo ao mais alto, não são o que definem se a aplicação é REST, mas comumente vemos a estratégia sendo implementada sobre o protocolo HTTP e, claro, sendo transportado pela pilha TCP/IP. Assim sendo, a implementação de REST sobre HTTP (HTTP RESTful) deve seguir a especificação do protocolo, usar os métodos HTTP (OPTIONS, GET, POST, DELETE, PUT, etc), mime-type adequado, cache, ser stateless, etc. Para quem no conhece o protocolo e deseja implementar alguma aplicação web-based, sugiro a leitura da RFC 2616: http://www.ietf.org/rfc/rfc2616.txt

Depois de ler a respeito, ver estratégias de implementação, testar algumas estratégias home made, ler a especificação na JSR e conversar com alguns colegas de trabalho -como o "bergamota" que usou Ruby On Rails (que é RESTful a partir da 2 versão)-, alguns pontos me deixaram com a "pulga atrás da orelha", Kent Beck diria que detectei mau cheiro (http://en.wikipedia.org/wiki/Code_smell), por que parece muito complicado implementar o REST seguindo tudo a risca.

Então comecei a procurar as boas práticas REST, como patterns, soluções de problemas conhecidos, etc, e também as más práticas, anti-patterns, estratgias de desenho e implementao a evitar, e foi assim que encontrei este excelente artigo do Stefan Tilkov, j meio antigo (2008), que fala de Anti-Patterns REST, ou seja, o que evitar, no fazer, na hora de desenhar e implementar aplicaes REST com HTTP, chamado pelo autor de RESTful HTTP.

Os 8 tópicos seguem abaixo (traduções melhores são bem-vindas):

1. Tunneling everything through GET (empacotar todas as chamadas através do método GET)
2. Tunneling everything through POST (empacotar todas as chamadas através do método POST)
3. Ignoring caching (ignorar o caching)
4. Ignoring response codes (ignorar os códigos de resposta HTTP -ver RFC-)
5. Misusing cookies (usar inadequadamente os cookies)
6. Forgetting hypermedia (esquecer a hipermídia)
7. Ignoring MIME types (ignorar os tipos MIME)
8. Breaking self-descriptiveness (quebrar a auto-descritividade)

O artigo na íntegra, com o uso correto e soluções recomendadas para cada tópico, pode ser lido aqui:
http://www.infoq.com/articles/rest-anti-patterns

Para entender melhor REST sugiro este artigo, tambm na infoQ:
http://www.infoq.com/articles/rest-introduction

Particularmente, concordo com os pontos colocados no artigo, e penso que serve de bom norteador para alguém que, como eu, é iniciante em REST.

Se interessar, aqui tem um apresentação falando sobre uma implementação real: http://www.infoq.com/presentations/REST-Financial-Service-Phillip-Ghadir onde o projeto começou com SOAP/WSDL/WS-* e mais tarde migrado para REST/APP usando o Atom Publish Protocol (APP) para expor os serviços (isto antes de inventarem o WADL anlogo ao WSDL). Foi o melhor exemplo de algo prático que encontrei.

You Can Write FORTRAN in any Language

Aproveitando o tempo ocioso na espera do build no hml, resolvi publicar um assunto guardado. Costumo ler alguns blog's, um deles o Coding Horror [http://www.codinghorror.com] de onde li um artigo que achei muito interessante. Fala de uma idéia que compartilho e os que me lêem podem formar sua opinião.

O título já diz um pouco: "Você pode escrever Fortran em qualquer linguagem" e trata de escrever bom código, e entender a cultura de cada linguagem.

Vemos programadores usando novas linguagens trazendo consigo a bagagem de experiências anteriores, e o artigo trata disso baseando-se em outro artigo, acerca de programadores que migram de VB.net para C#, e como a cultura adquirida programando em uma linguagem é levada para a outra.

Claro para entender melhor é bom ler o artigo na íntegra: http://www.codinghorror.com/blog/archives/000272.html

Como programador aspirante a desenvolvedor, sou estudante de padrões de projeto (design patterns), boas práticas OO, refatorações e por ai vai (tô quase perdendo a mulher de tanto estudar hahahaha), acabei extraindo algumas partes interessantes, pontos chave, e os traduzi, como a seguir:

"So in Visual Basic, the decision to include in the syntax and semantics the ability to assign numbers directly to strings and vice versa was a result of the designers' desire to attract a broad base of developers who would probably not understand the notions of strongly typed variables."

Vou traduzir livremente dada a minha limitação (meu ingrês é péééééésssimo amigo). Se alguém conseguir uma tradução melhor, por favor, corrija.

"Em VB, a decisão de incluir na sintaxe e semântica a possibilidade de atribuir numeros diretamente a strings e vice-e-versa foi um resultado do desejo dos projetistas para atrair uma grande base de desenvolvedores que provavelmente não entendem as noções de variáveis fortemente tipadas"

Sabe, vejo um pouco disso, na nomenclatura, tamanho dos métodos, divisão de classes, de projetos realizados em Java mas de programadores vindos do VB. Classes e métodos longos, classes de negócios, métodos estáticos, etc.
Em linguagens OO os programadores encapsulam as regras em classes e interfaces, em especial as que são mais propensas a mudar, logo "SE", se não é possível criar classes e interfaces, não se está programando OO.

Aqui fala bem:
Power Use of Value Objects in DDD
http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson

E aqui também:
Protected Variation: The Importance of Being Closed
http://im.ufba.br/pub/MATA63/Documentos/ProtectedVariation%5B1%5D.pdf

"There are characteristics of good coding that transcend all general-purpose programming languages. You can implement good design and transparent style in almost any code, if you apply yourself to it."

"Há características de boa codificação que transcendem todas linguagens de programação de propósito geral. Você pode implementar um bom design e um estilo transparente em quase qualquer código, desde que você se esmeire para isso"

Um dia, numa conversa rápida com o Rodrigo Botelho (a.k.a. Bergamota), disse o Rodrigo que estava fazendoum sistema para a faculdade em PHP.

E por que (nunca decorei a regra dos porquês) não Java?

PHP tem a fama de ser uma linguagem desorganizada e com programas espaguetes (devido a liberdade permitida), e não é. Os programadores que a usam o são (desorganizados) e "espagueteiam" o código. Existem alguns aplicativos muito melhores desenhados e implementados em PHP do que Java, por mérito do analista/arquiteto/programador/, então se o Rodrigo é um bom programador, e eu sei que ele é, está por vir um ótimo trabalho.

Ver anti-pattern "Big Ball of Mud": http://en.wikipedia.org/wiki/Big_ball_of_mud

"I cannot agree that code quality is predestined by choice of language, environment, or IDE-- it's almost entirely determined by the skill of the developer. Ergo, you can write FORTRAN in any language..."

"Eu não concordo que a qualidade do código é predestinada pela escolha da linguagem, ambiente ou IDE, ela (qualidade) é quase sempre inteiramente determinada pela habilidade do desenvolvedor.  Logo, você pode escrever FORTRAN em qualquer linguagem..."

Em outras palavras, que faz bom código tende a programar bem em qualquer linguagem - e quem faz mau código também tende a fazer em qualquer uma -;

Aqui neste blog tem uma opinião: http://www.nomedojogo.com/2009/04/16/a-melhor-linguagem-de-programacao-e-o-programador/

"Just because a programming language allows you to write bad code doesn't mean that you have to do it."

"Só por que a linguagem de programação permite que você escreva código ruim, isto não significa que você tenha que fazê-lo..."

"You can drown in a bathtub with an inch of water in it, and you can easily write a completely unreadable and unmaintainable program in a language with no gotos or line numbers, with exception handling and generic types and garbage collection."

"Você pode se afogar em uma banheira com uma polegada d'água, e você pode facilmente escrever um programa completamente ilegível e inmanutenível (nem sei se existe essa palavra, me ajudem! hahaha) em uma linguagem que não tenha GOTO's, números de linha, e que tenha manipulação de exceções e coletor de lixo."

"I agree that cultural factors are significant, however, individual developer skill is a far more accurate predictor of success than whether or not you chose the "cool" language."

"Eu concordo que os fatores culturais são significantes, contudo, habilidades individuais do desenvolvedor são indícios muito mais precisos do que escolher ou não a 'linguagem do momento'".

Muitos trechos falam por si, não deixem que ler o artigo inteiro, é muito bom.