Site muito bom que contém diversos glossários, de HTML, CSS, Javascript(Jquery e compania) e muito mais!
Não deixem de ver:
Mega Collection Of Cheatsheets for Designers And Developers | SpyreStudiosMuito obrigado Wwwhatsnew pela dica!
terça-feira, 22 de junho de 2010
segunda-feira, 31 de maio de 2010
Princípio 80/20 ou Sindrome 80-20?
Um certo dia lendo um artigo sobre administração do tempo(muito interessante por sinal) vi que umas das técnicas para comprar mais tempo é aplicar o Princípio 80/20, conhecido também como Princípio de Pareto. Basicamente esse princípio consiste na idéia de que 80% dos resultados vêm de 20% dos esforços, por exemplo: ao aspirar um carpete, 80% da sujeira vem de 20% do carpete (a área mais movimentada).
Até aí beleza, mas um dia ouvi um colega meu falando do 80-20 em outro contexto na área de TI: que quando 80% do projeto está feito os outros 20% são deixados de lado (é como aquela casa que está a 10 anos ainda no emboço, ou o famoso "deixa pra depois").
Assim temos 2 tipos de "80/20", um que visa a melhor utilização do tempo e um outro que explica trabalhos inacabados! Então o que devemos fazer? Resposta: devemos aplicar o lado bom e evitar o lado ruim do 80/20. Agora vamos ver como fazer isso se tratando da área de desenvolvimento de software:
Aplicando o Princípio 80/20 (o lado bom)
Se você tiver várias tarefas, ordene-as em nível de importância e resultados e pegue primeiro as tarefas mais importantes que vão dar mais resultados (acreditem, isso não é redundante)*. Vamos imaginar o cenário em que sua equipe precise desenvolver um sistema J2EE gerenciamento de consultas médicas on-line para um grupo de hospitais (já tendo o modelo especificado e toda a infraestrutura preparada) e fazer uma apresentação dele em 2 meses e seu gerente quer uma versão rodando até a apresentação. Ao menos que os membro de sua equipe trabalhe 20 horas/dia, não vai dar tempo! Aí e que entra o tal do Princípio 80/20: já que só vai dar para fazer uma parte do trabalho, faça a que vai gerar mais resultados! Que resultados? Um sistema testado, rodando e apresentável! Neste cenário o cliente quer que o paciente entre no site, cadastre-se de acordo com o convênio, agende uma consulta, daí o médico pegue a lista de pacientes agendados para o dia de serviço e possa colocar alguma observação e dar a consulta como encerrada. Vejamos algumas dicas:
1º - Não dê idéias mirabolantes do tipo "eu posso fazer uma funcionalidade que o médico poderá colocar as imagens dos exames de terceiros apresentados na consulta dentro do sistema", faça o mais simples para o mais complexo.
2º - Evite fazer um "canivete suiço" (classes Megazord, etc,com todas as frameworks legais do mercado) para apenas "descascar laranja".
3º - Faça os CRUDs que serão realmente utilizados no momento, os CRUDS das tabelas que serão pouco utilizadas podem ficar para a 2ª fase (Ex: Cadastro de Tipo de Pagamento).
4º - Concentre-se no funcionamento da regra de negócio, neste caso é criar o processo de cadastramento, agendamento e realização da consulta, o processo deve estar bem definido e de fácil utilização, nesta fase talvez seja aceitável relatórios com fraca apresentação, porém funcionais.
5º - Não deixe para testar por último: se não quiser usar TDD ou JUnit (que são altamente recomendados), faça mesmo assim testes a cada finalização de tarefa. E depois faça um teste geral só p/ garantir.
6º - No seu planejamento, não distribua as tarefas esperando que a equipe renda sempre 100% e reserve uma porcentagem (20%, por exemplo) do tempo para imprevistos. O Scrum usa algo do tipo porcentagem de produtividade da equipe, que eu não vou abordar aqui.
7º - Aplique o mesmo princípio para cada tarefa, se dedicando ao máximo nos dias e períodos em que é mais produtivo.
Fazendo isso é provável que terminará o que precisa antes do prazo e terá tempo para implementar mais coisas e assim surpreender seu cliente e seu gerente também!
Evitando a Sindrome 80-20 (o lado ruim)
Já aconteceu com você algo do tipo de ver uma aplicação em produção, olhar para um caso de uso que você fez e daí sentir um frio na espinha pensando "Caramba! Esqueci de implementar isso aqui!"? Não é nada agradável. Isso acontece porque quando vemos que uma tarefa está quase concluídanossa preguicite aguda
nosso cérebro já conclui que já terminamos, ou que "isso pode ficar para depois". O mesmo acontece em nível sistêmico, que quando um sistema está80% quase pronto, o "resto" é deixado de lado para começar um outro sistema que já está com o prazo atrasado. Claro que sabemos que tem coisas que são realmente firulas, mas se o nosso cliente pagou E se nós nos comprometemos em fazer então devemos dar pro cliente 100% do que foi combinado e/ou pago, ao menos que isso mude mais a frente. Como podemos fazer isso:
1º - Faça sempre uma lista de sub-tarefas de cada grande tarefa e a marque como feita ou não-feita. Ex: Para o cadastro de Médico podemos ter as sub-tarefas: Criar a infraestrutura(entity, persistência, etc), Criar as regras de negócio(validações, assinaturas de métodos), Criar o controlador de ação, Criar o front-end(jsp, javascript), etc. Podendo o teste ficar como uma sub-tarefa e talvez testando cada sub-tarefa quando possível.
2º - Coloque a lista de tarefas e sub-tarefas bem acessível (de preferência ao alcance dos olhos e das mãos)
3º - Não pule para outra tarefa ao menos que tenha terminado a tarefa anterior ou que aja uma necessidade excepcional para isso (ex: seu colega faltou e terá que terminar a parte dele para fazer o deploy no final do dia)
4º - A equipe deve estar ciente do que os membros estão fazendo, isso ajuda a diminuir a competição, e cada um fica mais concentrado na sua tarefa sabendo da importancia dela para o projeto como um todo.
5º - Se não der para fazer tudo até o prazo, procure entregar o que tem se possível, marque um novo prazo para entregar o restante e esforce-se em cumprí-lo.
6º - Se "travar" peça ajuda, pesquise, e só deixe para depois se ver que poderá ser produtivo em outras tarefas. Nota: esse "depois" é no mesmo dia ou no dia seguinte! Não deixe para o acaso, senão você poderá esquecer de fazer ou fazer de qualquer jeito
7º - Não faça de "qualquer jeito" as tarefas só para cumprir com o prazo, retrabalho ou correr no final requer o dobro do esforço do que fazer certo na 1ª vez!
Enfim é isso!
Conclusão
Temos muitas distrações hoje em dia e o nosso tempo é muito corrido devido a vida dinâmica que levamos, aplicando o Princípio 80/20 e evitando a Síndrome do 80-20 conseguiremos produzir melhor e teremos menos estresse ao lidar com a difícil tarefa se tornar o mundo mais fácil para nossos usuários.
Abraços,
Rogick
-------
* Nem todos os casos dá para aplicar esse princípio,
Até aí beleza, mas um dia ouvi um colega meu falando do 80-20 em outro contexto na área de TI: que quando 80% do projeto está feito os outros 20% são deixados de lado (é como aquela casa que está a 10 anos ainda no emboço, ou o famoso "deixa pra depois").
Assim temos 2 tipos de "80/20", um que visa a melhor utilização do tempo e um outro que explica trabalhos inacabados! Então o que devemos fazer? Resposta: devemos aplicar o lado bom e evitar o lado ruim do 80/20. Agora vamos ver como fazer isso se tratando da área de desenvolvimento de software:
Aplicando o Princípio 80/20 (o lado bom)
Se você tiver várias tarefas, ordene-as em nível de importância e resultados e pegue primeiro as tarefas mais importantes que vão dar mais resultados (acreditem, isso não é redundante)*. Vamos imaginar o cenário em que sua equipe precise desenvolver um sistema J2EE gerenciamento de consultas médicas on-line para um grupo de hospitais (já tendo o modelo especificado e toda a infraestrutura preparada) e fazer uma apresentação dele em 2 meses e seu gerente quer uma versão rodando até a apresentação. Ao menos que os membro de sua equipe trabalhe 20 horas/dia, não vai dar tempo! Aí e que entra o tal do Princípio 80/20: já que só vai dar para fazer uma parte do trabalho, faça a que vai gerar mais resultados! Que resultados? Um sistema testado, rodando e apresentável! Neste cenário o cliente quer que o paciente entre no site, cadastre-se de acordo com o convênio, agende uma consulta, daí o médico pegue a lista de pacientes agendados para o dia de serviço e possa colocar alguma observação e dar a consulta como encerrada. Vejamos algumas dicas:
1º - Não dê idéias mirabolantes do tipo "eu posso fazer uma funcionalidade que o médico poderá colocar as imagens dos exames de terceiros apresentados na consulta dentro do sistema", faça o mais simples para o mais complexo.
2º - Evite fazer um "canivete suiço" (classes Megazord, etc,
3º - Faça os CRUDs que serão realmente utilizados no momento, os CRUDS das tabelas que serão pouco utilizadas podem ficar para a 2ª fase (Ex: Cadastro de Tipo de Pagamento).
4º - Concentre-se no funcionamento da regra de negócio, neste caso é criar o processo de cadastramento, agendamento e realização da consulta, o processo deve estar bem definido e de fácil utilização, nesta fase talvez seja aceitável relatórios com fraca apresentação, porém funcionais.
5º - Não deixe para testar por último: se não quiser usar TDD ou JUnit (que são altamente recomendados), faça mesmo assim testes a cada finalização de tarefa. E depois faça um teste geral só p/ garantir.
6º - No seu planejamento, não distribua as tarefas esperando que a equipe renda sempre 100% e reserve uma porcentagem (20%, por exemplo) do tempo para imprevistos. O Scrum usa algo do tipo porcentagem de produtividade da equipe, que eu não vou abordar aqui.
7º - Aplique o mesmo princípio para cada tarefa, se dedicando ao máximo nos dias e períodos em que é mais produtivo.
8º - Não teste novos métodos e frameworks nos sistemas dos clientes, principalmente numa situação dessas!
Fazendo isso é provável que terminará o que precisa antes do prazo e terá tempo para implementar mais coisas e assim surpreender seu cliente e seu gerente também!
Evitando a Sindrome 80-20 (o lado ruim)
Já aconteceu com você algo do tipo de ver uma aplicação em produção, olhar para um caso de uso que você fez e daí sentir um frio na espinha pensando "Caramba! Esqueci de implementar isso aqui!"? Não é nada agradável. Isso acontece porque quando vemos que uma tarefa está quase concluída
nosso cérebro já conclui que já terminamos, ou que "isso pode ficar para depois". O mesmo acontece em nível sistêmico, que quando um sistema está
1º - Faça sempre uma lista de sub-tarefas de cada grande tarefa e a marque como feita ou não-feita. Ex: Para o cadastro de Médico podemos ter as sub-tarefas: Criar a infraestrutura(entity, persistência, etc), Criar as regras de negócio(validações, assinaturas de métodos), Criar o controlador de ação, Criar o front-end(jsp, javascript), etc. Podendo o teste ficar como uma sub-tarefa e talvez testando cada sub-tarefa quando possível.
2º - Coloque a lista de tarefas e sub-tarefas bem acessível (de preferência ao alcance dos olhos e das mãos)
3º - Não pule para outra tarefa ao menos que tenha terminado a tarefa anterior ou que aja uma necessidade excepcional para isso (ex: seu colega faltou e terá que terminar a parte dele para fazer o deploy no final do dia)
4º - A equipe deve estar ciente do que os membros estão fazendo, isso ajuda a diminuir a competição, e cada um fica mais concentrado na sua tarefa sabendo da importancia dela para o projeto como um todo.
5º - Se não der para fazer tudo até o prazo, procure entregar o que tem se possível, marque um novo prazo para entregar o restante e esforce-se em cumprí-lo.
6º - Se "travar" peça ajuda, pesquise, e só deixe para depois se ver que poderá ser produtivo em outras tarefas. Nota: esse "depois" é no mesmo dia ou no dia seguinte! Não deixe para o acaso, senão você poderá esquecer de fazer ou fazer de qualquer jeito
7º - Não faça de "qualquer jeito" as tarefas só para cumprir com o prazo, retrabalho ou correr no final requer o dobro do esforço do que fazer certo na 1ª vez!
Enfim é isso!
Conclusão
Temos muitas distrações hoje em dia e o nosso tempo é muito corrido devido a vida dinâmica que levamos, aplicando o Princípio 80/20 e evitando a Síndrome do 80-20 conseguiremos produzir melhor e teremos menos estresse ao lidar com a difícil tarefa se tornar o mundo mais fácil para nossos usuários.
Abraços,
Rogick
-------
* Nem todos os casos dá para aplicar esse princípio,
quinta-feira, 31 de dezembro de 2009
Um pouco de etimologia
Todos deveríamos nos interessar um pouco sobre etimologia (de nossa língua pelo menos), porque daí teremos um vocabulário melhor. Mas antes disso vejam uma pequena definição de etimologia segundo a Wikipedia:
Etimologia (do grego antigo ἐτυμολογία, composto de ἔτυμον e -λογία "-logia"[1]) é a parte da gramática que trata da história ou origem das palavras e da explicação do significado de palavras através da análise dos elementos que as constituem. Por outras palavras, é o estudo da composição dos vocábulos e das regras de sua evolução histórica.
Algumas palavras derivam de outras línguas, possivelmente de uma forma modificada (as palavras-fontes são chamadas étimos). Por meio de antigos textos e comparações com outras línguas, os etimologistas tentam reconstruir a história das palavras - quando eles entram em uma língua, quais as suas fontes, e como a suas formas e significados se modificaram.
Os etimologistas também tentam reconstruir informações sobre línguas que são velhas demais para que uma informação direta (tal como a escrita) possa ser conhecida. Comparando-se palavras em línguas correlatas, pode-se aprender algo sobre suas línguas afins compartilhadas. Deste modo, foram encontrados radicais de palavras que podem ser rastreadas por todo o caminho de volta até a origem da família de línguas indo-européias.
A própria palavra etimologia vem do grego ἔτυμον (étimo, o verdadeiro significado de uma palavra, de 'étymos', verdadeiro) e λόγος (lógos, ciência, tratado).
Tá, legal, supimpa, mas por qual razão lógica, força maior da natureza, lei divina, classificação para o Mundial, alguém de TI vai estudar etimologia, já que o nosso objetivo é estragar a nossa língua misturando "portenglish", "espanhemão", etc, etc? A razão é a seguinte: para que entenda melhor o que está lendo e escrevendo!
Podemos encarar etimologia com programação: por que um administrador de rede tem que aprender técnicas de programação? Porque em algum momento ele pode se deparar com um script da vida e ele tem q pelo menos entender o que aquilo tá tentando fazer, sem precisar de um "programador intérprete" para ele.
Assim são as palavras, nós não vamos precisamos decorar o dicionário ou pesquisando na internet uma palavra pouco conhecida se nós sabermos a origem dela.
Ex: alguém aí sabe o que é isonomia? Antes de se sentir tentado a pegar um dicionário analise a estrutura dela: ela é composta de 2 radicais gregos iso(isos) + nomia(nomos), onde isos em grego significa 'igualdade' e nomos significa 'lei'. Então isonomia (isos + nomos) significa 'igualdade perante a lei'. Daí todas as palavras que vermos começando com iso já vamos saber que significa alguma coisa sobre igualdade e terminando com nomia ou nomio significa alguma coisa sobre lei. Daí não precisaremos usar todo o nosso poder mental e nerdice para conseguir entender o que realmente estamos lendo ou ouvindo! Legal né?
Ser quiser saber mais visite o blog:
Em breve estarei finalmente postando minhas aventuras com TI.
Abraços.
quarta-feira, 10 de junho de 2009
Teoria do infinito
AVISO: Isso é uma teoria do meu irmão!
Tah bom que não muda nada, continua como eu disse, " A matemática eh ilógica" (ateh agora , eh claro)
Antes de podermos dizer qual é o resultado de uma operação, há que nos perguntarmos o que significa exactamente. O que significa subtrair dois infinitos? Para tentarmos fazer uma ideia, vamos a aproximar-nos da questão a partir de dois pontos de vista diferentes: um analítico e outro de conjuntos.
Aproximação analítica
Infinito pode ser o resultado de uma passagem ao limite. Podemos ver o que se passa quando subtraímos duas sucessões de limite infinito.
Sejam as sucessões seguintes:
- an = n;
- bn = n2;
- cn = n + k, onde k é um número real qualquer.
- lim an = lim bn = lim cn = +∞
Agora, se subtrairmos as sucessões e tomarmos limites, temos: - lim (bn - an) = lim (n2 - n) =+ ∞
- lim (cn - an) = lim (n + k - n) = lim k = k
Conclusão provisória: ao subtrairmos duas sucessões de limite infinito, a sucessão resultante pode ter por limite qualquer coisa.
Aproximação conjuntista
O Infinito também pode ser o cardinal de um conjunto, ou seja, o número de elementos que esse conjunto tem. A ideia agora é tomarmos um conjunto de cardinal infinito, subtrair-lhe subconjuntos de cardinal também infinito, e ver qual é o cardinal do conjunto resultante. Não é muito diferente do que fazemos quando para explicar a uma criança quanto é três menos dois lhe dizemos: “se tenho três maçãs e como uma, com quantas maçãs fico?”.
Sejam os conjuntos seguintes:
IN = {1, 2, 3, 4 ...}, ou seja, o conjunto dos números naturais .
P = {2, 4, 6, 8 ...}, ou seja, o conjunto dos números pares.
I = {1, 3, 5, 7 ...}, ou seja, o conjunto dos números ímpares.
A1 = IN - {1}, ou seja, o conjunto dos naturais excepto 1.
A2 = IN - {1,2}, ou seja, o conjunto dos naturais excepto 1 e 2.
An = IN - {1, 2,..., n}, ou seja, o conjunto dos naturais excepto 1, 2, 3, ... ,n
Entenderemos por A - B o conjunto resultante de tirar ao conjunto A os elementos do conjunto B. Vejamos alguns casos:
1. IN - IN = Ø
Se ao conjunto dos números naturais lhe tirarmos todos os números naturais, o que nos sobra? Nada, claro. Ao conjunto que não tem elementos em matemática chamamos conjunto vazio.
Portanto, ∞ - ∞ = 0.
2. IN - P = I
Está claro - se aos números naturais lhe tirarmos os pares ficam os ímpares.
Então: ∞ - ∞ = ∞.
3. IN - A1 = {1}
Ao conjunto dos números naturais tiramos-lhe todos os naturais excepto 1.
Então: ∞ - ∞ = 1.
4. IN-An = {1, 2, ..., n}
Ao conjunto dos números naturais tiramos-lhe todos os naturais excepto 1, 2, 3, ... n.
Então: ∞ - ∞ = n.
Conclusão: se a um conjunto com uma quantidade infinita de elementos lhe tirarmos una quantidade infinita de elementos, o conjunto resultante pode ter... qualquer quantidade de elementos, inclusive nenhum.
Conclusão provisória:
Nenhuma das duas aproximações nos dá uma ideia de como podemos definir a diferença de infinitos para que tenha sentido. Eu não conheço nenhuma, mas isso não quer dizer nada, claro.
Infinido = nada
AVISO: Isso é uma teoria do meu irmão!
Não, não tenho certeza se tah certo, tô mandando esse e-mail pq tô revoltado de tanto estudar, mas é uma boa perda de tempo
note
0,999... = x
(0,999...).10 = x .10
(9,999... ) -x = 10x - x (lembrando que x = 0,999...)
9 = 9x
x = 9/9 = 1 (tah, isso a matemática explica, tudo bem, mas eu, em minhas pertubações mentais pensei)
imagine um número infinito que vou representar por '§' (a representação real é outra, mas não tem no teclado)
então
x . 10 = §.10
10x = § (já que o infinito vezes qualquer número real é infinito)
10x - x = § - x
9x = 0 (infinito - infinito = 0)
x = 0/9 = 0 logo infinito é igual a nadaaaaaaaaaaaa!!!!!!!!!!!!!!!!!!!!!!!
Começando do início
Ao contrário da famosa saga Star Wars, decidi começar realmente do início. irei postar aqui as minhas descobertas e consecuções em Java, Web e metodologias ágeis, coisas que ainda estou "engatinhando" porém evoluindo. Além de outras nerdices da vida em geral de áreas de "ciências exatas".
Aguardem em breve mais postagens, sua visita diária é muito importante para nós....
Assinar:
Postagens (Atom)