The Hello World Collection

A listagem é muit boa e inclui APIs para serviços como digg, last.fm e amazon.

Uma mão na roda para o pessoal que está desenvolvendo em Flex, AIR e Flash.

Vale a visita: List of 22 ActionScript 3.0 API’s

Ontem atualizei sem querer para o firmware 1.1.4 e acabei com um telefone que só faz chamada de emergência. Após muito sufoco, descobri como voltar para o 1.1.3.

Passos:

1 - Efetue um restore no iTunes para o 1.1.3 (Vai dar erro, sem problemas)
2 - Utilizando o ZiPhone, efetue o JailBreak e a ativação
3 - Via SSH suba esse arquivo(descompactado) para um diretório qualquer do iPhone e de as permissoes 755 para o bbupdater e ieraser
3 - Efetue unload no commcenter (ulctl)
4 - No terminal do iPhone execute:

./ieraser
./bbupdater -f ICE04.03.13_G.fls -e ICE04.03.13_G.eep

5 - Efetue load no commcenter denovo e reinicie seu iphone
6 - Pelo ZiPhone, efetue o unlock no SIM-Card

Bom pessoal é isso, o ideal é esperarem sair o Jailbreak e a ativação oficial para o 1.1.4, mas para quem atualizou essa dica pode ajudar.
Lembrando que o meu iPhone é o 1.0.0 OTB

Update 28/02/2008: O ZiPhone já está fazendo o downgrade automaticamente. Recomendo utilizar o ZiPhone para realizar o downgrade.

andei um bom tempo sumido daqui, pois não estava sobrando tempo para blogar !!!

Tenho me dedicado ao estudo de algoritmos genéticos e inteligência artificial.
Estou desenvolvendo um framework de desenvolvimento com suporte a GA e AI.

Como novidade, abandonei o domínio antigo (luizantonio.com) e adotei um novo: luizpicanco.com

Confira no google maps (Item 43):
Belo Horizonte - Miami - Como Chegar

Segue abaixo a solução para o problema:
1 - Você vai precisar dos seguintes arquivos (Download aqui):

2 - Com o iBrickr, crie um diretório para guardar esses arquivos (Ex.: restore) e copie os 3 arquivos para lá
3 - Pelo iBrickr, instale a aplicação MobileTerminal
4 - No iPhone, execute o MobileTerminal
5 - Digite os seguintes comandos:

cd /restore

launchctl load /System/Library/LaunchDaemons/com.apple.CommCenter.plist

Se você receber uma mensagem do launchtcl dizendo “no process”, ignore-a.
6 - Execute o AnySim
7 - Enjoy!

Nos últimos anos tem se observado uma crescente movimentação no mercado em torno do modelo de desenvolvimento denominado Fábrica de Software. Esse modelo tem uma grande característica que é o uso de técnicas utilizadas na engenharia industrial de produção em série, para a criação de um ambiente produtivo de desenvolvimento de software com qualidade e baixo custo.
Esse modelo de desenvolvimento não é novo, surgiu na década de 60, mas só agora começa a ser intensivamente utilizado pelas empresas de desenvolvimento de software.
Os avanços da engenharia de software nos últimos anos e as mudanças ocorridas nos processos de desenvolvimento de sistemas, como o software livre e o surgimento de padrões abertos para desenvolvimento corporativo, fizeram surgir um novo modelo de fábrica de software no mercado. As novas facilidades tornaram possíveis que empresas de médio e até de pequeno porte, pudessem montar suas fábricas de software para prestar serviços de desenvolvimento de sistemas à crescente terceirização do mercado, resultando numa proliferação deste novo modelo de fábrica pelo mundo.

Evolução

Empresas em todo mundo estão percebendo que o desenvolvimento de software é uma atividade bastante especializada para ser absorvida e custeada internamente. Desta forma é crescente o número de terceirização na área de informática, especialmente na área de desenvolvimento de software.
Juntamente com esta crescente demanda por terceirização, cresce também o nível de exigência do mercado em termos de qualidade e custo do software. Como resultado, empresas estão investindo em ferramentas de automação, enquanto trabalhos de pesquisas em novos paradigmas de implementação, como orientação a aspectos, estão obtendo resultados significativos.
Algumas destas pesquisas já possuem resultados práticos, como o AspectJ, uma extensão da linguagem Java para o paradigma orientado a aspectos desenvolvida pelos Institutos de Pesquisa da Xerox. Com a evolução e amadurecimento da orientação a aspectos, será possível desenvolver software de forma mais consistente, abordando de uma única vez importantes aspectos não-funcionais do sistema, que poderão ser reutilizados em várias demandas da fábrica, eliminando desta forma o retrabalho e a replicação de código.
Segundo Jack Greenfield, importante arquiteto de software da Microsoft, “os métodos e práticas de desenvolvimento de software terão que mudar radicalmente… A solução deve envolver a modificação dos nossos métodos e práticas. Devemos encontrar formas de tornar os desenvolvedores muito mais produtivos”.
A Microsoft está desenvolvendo uma nova arquitetura de desenvolvimento de sistemas denominada “Software Facotories” (Fábricas de Software).
Segunda a própria Microsoft será uma arquitetura revolucionária, que elevará bastante os níveis de reutilização de software, através de conceitos como o de linhas de produção de software, onde componentes poderão ser montados, configurados e empacotados, resultando num produto final completo. O desenvolvedor se preocupará apenas em customizar os aspectos altamente especializados e específicos do projeto.
Um outro tópico que será um diferencial no futuro são os significativos avanços das ferramentas case nos últimos anos, que permitirá a visualização e controle de todas as fases de desenvolvimento do sistema em uma única ferramenta. Atualmente o nível de integração entre todos os artefatos das várias fases do projeto é alto, mas não permite uma automação e rastreabilidade de todos os pontos do sistema. Porém num futuro próximo, com a evolução dos processos de software e das tecnologias de construção de ferramentas case, se espera abranger todo o sistema, desde a geração do código à partir dos artefatos de análise e projeto até a automação na realização dos testes.
Com a constante evolução da engenharia de software e das tecnologias envolvidas no desenvolvimento de sistemas, as fábricas de software poderão vir a ser uma realidade cada vez mais presente no mercado e se tornando cada vez mais efetivas dentro de seu objetivo de produzir software de qualidade em pouco tempo e com baixo custo. Como resultado, espera-se em todo mercado mundial um crescimento ainda maior na adoção do modelo de fábricas de software para o desenvolvimento de sistemas.

Conclusão

Como pode-se observar a engenharia de software está sempre evoluindo. Novos paradigmas, linguagens, ambientes surgem a cada dia, buscando aumentar a produtividade e qualidade no desenvolvimento de software. Sistemas que levavam dois anos para serem codificados hoje em dia podem ser feitos em meses.
O profissional ligado a área de desenvolvimento de software deve ficar atento a esses novos paradigmas, pois se não o fizer, correrá o risco de tornar-se obsoleto.

Hoje está completando um ano que comecei o blog Programando na Madrugada.

Espero ter mais tempo para me dedicar ao blog.

• The Liar
  • Todos os metodos de um teste unitário estão passando perfeitamente, aparentando serem validos, entretanto sob uma inspeção mais próxima é descoberto que o teste unitário não testa o real intuíto para que foi criado.

• Excessive Setup
  • Um teste que necessita muito trabalho para ser configurado antes mesmo de ser executado. Algumas vezes centenas de linhas de código tornam-se necessárias para adaptar o ambiente a um único método de testes, com dezenas de objetos envolvidos. Aqui a maior dificuldade é compreender “o quê” realmente está sendo testado dentro de toda a “sujeira” que um setup pode causar. (tradutor: Lembrem-se sempre do princípio KISS)

• The Giant
  • Um teste unitário que, mesmo sendo verdadeiro na intenção de validar um objeto, pode possuir centenas de linhas contendo inúmeros casos de teste (inúmeros mesmos). Esta pode ser uma indicação do que chamamos de God Object, objeto que possui responsabilidades demais dentro do sistema. Indício claro de alto acoplamento em seu sistema.

• The Mockery
  • Muitas vezes um mock pode ser útil e bastante indicado. Mas desenvolvedores podem perder tempo desnecessariamente esforçando-se em mockear o que não está sendo testado. Percebe-se neste caso que a classe possuí tantos mocks, stubs ou fakes que no final das coisas o sistema não está sendo testado, mas o que é retornado da interação entre os mocks. (tradudor: use apenas o que for estritamente necessário!)

• The Inspector
  • Um teste unitáro que viola o encapsulamente em um esforço de atingir 100% de cobertura de testes, mas está situação nem sempre é favoravél, pois qualquer tentativa de refactor pode quebrar testes desnecessariamente, necessitanto adequações nas classes de teste unitário.
• Generous Leftovers
  • Uma instância de um teste unitário cria um dado que é persistido em algum lugar, e outro teste utiliza tal dado para seus próprios asserts. Caso algo saia errado, o teste que utiliza o dado cadastrado também falhará. (tradutor: Testes devem ser independentes! )

• The local Hero
  • Um teste que é dependente de algo específico do ambiente de desenvolvimento em que ele foi escrito. O resultado: o teste passa perfeitamente na células de desenvolvimento, mas falha quando alguém tenta executá-lo fora desse ambiente.

• The Nitpicker
  • Um teste unitáro que compara toda a saída quando o que lhe deveria interessar é uma pequena parte apenas, assim o teste deve se manter sempre alinhado com detalhes que o teste não deveria tratar. Esta situação é endemica em testes de aplicações web.

• The Dodger
  • Um teste unitário que possui muitos testes para efeitos pequenos (e presumidamente simples de testar), mas nunca testando o comportamente real desejado. Encontrado em testes relacionados para testes de banco de dados, onde um método é chamado, e então o teste seleciona itens do banco e procede asserts contra os resultados.

• The Loudmout
  • Um teste unitário (ou suite de testes) que enxe o console com mensagens de diagnóstico, logs e qualquer outro tipo de saídas, mesmo quando os testes estão passando. Algumas vezes durante a criação dos testes existe o desejo de manualmente ver a saída dos metodos, mas mesmo eles deixando de serem necessários, são deixados para trás.

• The Greedy Catcher
  • Um teste unitário que trata exceções e sobrepões pilhas de execução (stack trace) algumas vezes com mensagens menos informativas, mas algumas vezes ainda apenas logando (Loudmouth) e deixando o teste passar.

• The Sequencer
  • Um teste unitário dependente de uma lista que sempre é retornada em forma desordenada.

• Hidden Dependecy
  • Primo de primeiro grau do “The Local Hero”, um teste unitário dependente de um dado que deve ser populado em algum lugar par ao teste rodar. Se o dado não estive presente, o teste falhará deixando pouca informação para o desenvolvedor o que é necessário, ou porque o teste falhou… forçando-o a buscar através de uma floresta de código para descobrir de onde vem o dado que o teste deveria utilizar.

• The Enumerator
  • Um teste unitário em que os nomes de métodos são apenas uma enumeração: teste1, teste2, teste3. Como resultado, a intenção dos testes torna-se pouco clara, e a única maneira de ter certeza é ler o código fonte e rezar para que esteja bem escrito.

• The Stranger
  • Um método de teste que nem ao menos pertence ao Teste Unitário que ele está inserido. O método está realmente testando um objeto separado e independente, normalmente um objeto utilizado pelo objeto que sofre o teste.

• The Operating System Evangelist
  • Um teste unitário que está ajustado apenas para um determinado sistema operacional para que possa funcionar. Um bom exemplo seria um caso de teste que utilize o separador de linhas do Windows para um assert, que falha apenas rodando em Linux.

• Success Against All Odds
  • Um teste escrito para passar antes mesmo de falhar. Como um infeliz efeito colateral, o caso de teste acaba sempre passando mesmo que tenha sido feito para falhar.

• The Free Ride
  • Ao invés de escrever um novo teste para uma nova funcionalidade ou característica, apenas um novo assert é criado ao final de um teste já existente.

• The One
  • Uma combinação de alguns outros padrões, particularmente o TheFreeRide e TheGiant. Um teste unitário que contém apenas um único metodo que teste todo tipo de funcionalidade que um objeto pode conter. Um indicador comum é que o teste possui o mesmo nome da classe, e ainda com múltiplas linhas, setups e asserts

• The Peeping Tom
  • Um teste que, compartilhando recursos, pode ver o resultado de outro test, e pode falhar mesmo que o sistema testado esteja em perfeito funcionamento. Verificado na ferramenta Fitnesse, onde a utilização de variáveis estáticas para abrigar coleções não eram corretamente limpas após a execução do teste, podendo surgir erros durante a execução de qualquer teste. Também conhecido com TheUninvitedGuests.

• The Slow Poke
  • Um teste unitário que é incrivelmente lento para ser executado. Quando o teste é iniciado, os programadores podem ir ao banheiro, fumar um cigarro ou pior ainda, inicar o teste no final do dia e ir para casa, esperando que o resultado saia no dia seguinte.