Android: Overall and Predictions

Hello, World!

Well. its been a while I'm following what is, in my opinion, the most

interesting happening in the mobile phone arena: the previously rumored as Google Phone, and later officially named Android. The way Google entered on the mobile world was something of unexpected, and, at the same time, filled users, OEMs, carriers and, specially, developers with plenty of expectations.

Some out there might be asking themselves where I've been when Steve Jobs did his wonderful keynote announcing to every corner of the world he’s new engineering achievement: the iPhone. I would like to clarify that it is a great and innovative phone, but in my view, nothing more than that. Remember that, once, upon a time, Motorola RAZR was a great and innovative product...On the other hand, Android has something of renewing to the whole mobile industry. Its is free. It is open. It is completely customizable. And for us, developers, it builds up a entirely new paradigm for developing applications. Application developers or not, many of you might had saw the videos of the first Android SDK, which packages an emulation of what we would see later on a cell phone.

As new SDK releases follows we could preview what later became the first Android phone to hit the market. Many had noticed that the phone has exactly the same software you found on the emulator. Some might say it even looks like the emulator. What I'm trying to say is that was the system as the Open Handset Alliance has made it (Duh!). The HTC engineers had only changed hardware drivers and vuala, there it is! Other OEMs are certainly tweaking their phones so we might expect plentiful of mobile phones for all flavors and tastes to be launched this year (check what Google CEO said @ Telecoms.com).

Yes, Google has rally built something... a really powerful platform... it is even about to show up into the crescent netbook market. What!? Yes, the netbook market. Android has setup fear into dominating Windows XP. Asus, HP, Dell, Acer and recently MSI (checkout @ Engadget) had been spotted attempting to build netbooks over Android. And the latest announced OS update – version 1.5, also known as Cupcake - gives us a hint that this netbook story is becoming serous as it states to support "x86" processor architecture (used by Intel and AMD mobile processors).

Alright so we've made it through here and here it is Cupcake. Cupcake adds lot of news on the platform but if you keep in mind that Android it is being evolved into a community, many of his new features may point clues to what OEMs are planning for they forthcoming mobile devices. I could bet that one of the coming Android phones is an iPhone-like touchscreen phone without a physic QWERTY keypad, as the Cupcake supports virtual keyboard. It’s pretty acceptable that, at least another one of them is a music phone, due to the added AD2P support... (see a full list of changes @ Android.com; see how to emulate the new environment @ Nullwire.com).

The new mobile phone era brings application stores out of the carriers hood - thanks to Apple, I must agree - and just a few clicks away from our fingers, also enabled us to developing innovative applications beyond what we could even imagine. Accelerometer and GPS are now familiar and in the near future will become usual as mp3 players and cameras. Android had moved through it all and added application cooperativeness into the game. Enabled developers to replace untouchable features like phonebook, home screen or even calling applications in the way you just expect from Windows to use a music player, web browser or mailing application as default for all your requests.

Plus, I just could not believe how easy it is to deploy and test applications at Android. And debug it on device! It’s just great! Once you have installed the phone drivers, just plug the phone on the computer; go to Eclipse and press run/debug! That’s all! The application starts running on the phone in a few seconds! Marvelous! For sure, there are new times coming for the mobile devices arena.

Soft Keypad

Orientation Switching

Design Patterns: The Ultimate Reference Site

Hello, world!

As you might have noticed, is quite a while since I did my last post. This crisis times are really tough and even my "posts pruduction" had slown down. That was a joke. Good one, uh? Nevermind. Today I'm here to speak about software design patterns. In fact, I will not precisely speak on them but only point a nice site a friend of mine told me about and which I've been using as reference since then: Source Making Design Patters. This site is really amazing when it comes to this topic! There you may find rapid and straightforward answers to take down your most scareful doubts, or even learn it all to get a nice background on the subject. What the hell are you still doing here? Go for it now!

SCJP 6.0 Exam: Unmystified

Hello, world!

In December/2007, I've just started to study to take my - very late - Java Programmer certification as the version 6.0 of the exam was early released. Although I knew it wasn't the latest version of the exam (and of Java itself), I've started studying for the 5.0 exam, which, alone, has too many new things to be learned for a mobile programmer. This time, I'm going to talk about the Sun Certified Programmer for Java Platform, Standard Edition 6.0 Exam and my experience of doing the test. 

[Offtopic] As you might have noticed, I awoke with the spirit of making things different and, thus, decided to do my first English post here, at MicroKode. I'll probably keep writing my articles this way and I really hope that the few out there who read my daydreams don't bother about it. I also hope this help to transform this "few" in a "little greater few". Now, back to the topic...

As I've said, the 5.0 version of Java has a lot of new things: Generics, Boxing, Enhanced for Loop, Enums, Varargs, Static Imports and Annotations (the last is not required for the exam). So I've just forgot the existence of a newer version - the sixth - and started reading the "SCJP Sun Certified Programmer for Java 6 Study Guide" from Kate Sierra and Bert Bates. This book is just the best. Go for it! 

About one month later I finished reading it and bought the voucher. I gotta say a word on it: the Sun service here in Brazil is just a bunch of crap. They are very polite and try to attend your requests for the best, but I had to wait about 1 month and a half to get my voucher numbers. And when they finally sent it to my e-mail the expiring date was wrong. Luckily I received a new mail with the correct date, before I even notice the other was wrong.

While waiting the voucher numbers I started doing some simulated exam from the Whizlabs software and I, gotta admit, I've never passed the exam in the simulator from these guys. The difficult level they apply on their software is far more hard than the test itself. But, at the time I wasn't aware of this and decided to delay my application to a later date, that turned to be 14th this month, about one year later.

If you think I was studying all this time you are completely nut. I only did the test because my voucher was about to expire! So I stepped to the Prometric site and scheduled my test to January 14th. Note: the current day was January 8th. This day I request a friend to help me with the scheduling and he just ask me why I was applying to 5.0 exam. He argued that the differences between the two versions of the exam where very few and that it won't worth to do the "old" test anymore. I did some searching and found several articles saying the same. Look, I was about to loose 330 bucks anyway, what's the problem on adding a bit more of complexicity to the mix? I took the exam version 6.0.

The "new" Java version hasn't any bigger changes. At least none of the new exam topics were a big deal. Only one class and two new Interfaces to know about. Compared with the wave of changes from the 1.4 to the 1.5 versions, this means nothing. Here are my tips to get passed the test with no headaches:

1. Read the Kate Sierra and Bert Bates book. The reading is soft and the content is great, after finishing it you sure gonna be ready to take the test. Don't forget to make the exercises and re-read the "Two-Minute Drill" a few days before the test, so you can refresh the things in your mind and identify the parts where you have to study a little more. 
2. Buy your voucher as soon as you decide to take the test. Don't wait to finish studying to do so. If you do, you may forget all you've studded before Sun deliver your voucher number.
3. Don't even think taking the test for the 5.0 version. The differences are few to none. I got just one question about Console and none about NavigableSet and NavigableMap interfaces on my exam. Remember your voucher allows you to do any of the exams.
4. Don't even download the Whizlabs exam simulation software. Alright, that's a bit exaggerated. You can download and exercise on it, the software is really good. But keep in mind that the real exam is much easier. When I said "much", I meant MUUUUUUUCH!
5. Don't be afraid, Generics aren't a problem at the exam, but double check Collections. Much of the exam will test your knowledge on declarations, initialization and scooping, flow control and fundamentals. In fact I think about 1/4 of the exam questions just don't compile. There were also two questions about OO (coupling and cohesion), one for IO and a few for Collections and Generics.
6. On the SCJP 6.0 exam, they raised the passing score, but also the test time. And a lot! So, don't run, you got enough time. I finished the test with about one hour and half left.

Finishing the legend, I surprisingly had passed the test... and with easy. Scored 79% when the passing score was only 65%. Obviously I wish I had gone 100%, but I just don't have enough patience to study that much, and, after all, getting certified, alone, was a great deal for me.

Last, but not least, follows a list of test simulators for you to practice on before taking the real test:

Java Incsition, MasterExam, Test Killer and Whizlabs (DON'T PANIC!).

2009: Ano da Invasão Android

Hello, World!

Pois é, depois de mais um mês de pouca - na verdade nenhuma - produção, estou voltando a postar novidades por aqui. Dessa vez vamos falar do "robozinho" do Google: o Android. 

Depois de muita especulação, boatos e afins, finalmente saiu o primeiro celular portador do aclamado sistema operacional do Google... e isso não é novidade nenhuma, afinal, já faz bem mais de um mês que isso ocorreu.  O fato é que isso é apenas o começo... do post.

Nos últimos tempos li muitas matérias sobre o danado do bonequinho verde e ultimamente ele está cada vez mais presente na mídia especializada. Após o lançamento bem sucedido do G1, fruto da parceria entre a tailandesa HTC e a americana T-Mobile, nos U.S.A e, algumas semanas depois, na Europa, as principais forças do mercado de celulares estão correndo atrás de colocar um "robozinho" na rua.

Empresas como a própria HTC, Kogan, Motorola, Sony Ericsson, Kyocera, Asus, Garmin, Huawei, LG, Samsung and Toshiba já anunciaram até datas de lançamento para seus brinquedinhos (previstos, em maioria para o terceiro trimestre deste ano). A danada da latinha verde-limão está sendo cogitada até para substituir o MacOS X, no iPhone! Calma, calma! Isso é apenas um projeto de algum ciêntista/nerd maluco por enquanto. Mas a versão 2.6 do kernel Linux, usada nas entranhas do Android, já habita o gadget dos sonhos da maioria da população do mundial. Jobs que se cuide...

Bom, o que eu quero mesmo dizer com isso é que se você é um desenvolvedor, programador e peão, como eu, e também não sabe implementar um "Hello, World!" em Android, como eu, essa pode ser uma grande chance de oferecer razões concretas para seu chefe não te demitir. Aprenda a mecher nessa jossa! Vou dar uma colher de chá, pode começar vendo os videos abaixo [In English]. Eles são feitos pelos próprios membros da equipe do Android e oferecem o startup legal pra quem não sabe nem do que isso se trata. 

Introduction

Architecture Overview

Application Lifecycle

Android APIs

Building an Application Demo

Depois você pode continuar explorando essa tecnologia aqui e prepare-se! No pior dos casos você poderá participar do próximo Android Developer Challange e faturar uma grana alta, sem contar fama e prestígio. [Talvez eu esteja exagerando só um pouquinho...]

As 10 Características de um Engenheiro Brilhante

Hello World! We're back!

Após outro longo periodo de dormencia, volto à ativa por essas bandas. Estava atarantado com o trabalho e também coisas pessoais (minha filha nasce nos primeiros dias de dezembro e ainda não me mudei). Além do mais, faz um tempo que não acontece nada (ou pelo menos se conteceu passou desapercebido) interessante no mundo mobile. Nada além de resultados financeiros desanimadores para este setor que parecia inabalável. É a crise veio para todos, mas esse tópico vai ficar para um proximo post...

Vim aqui para falar de um artigo que considerei gênial. Um dia desses me fizeram a seguinte pergunta: "Como identificar um engenheiro brilhante?". Complexo. Alguém ai tem a fórmula? O fato é que comecei minhas perquisas de braços dados com o Oráculo e achei o que considerei ser a melhor resposta para a pergunta. 

O artigo com o título: Top 10 Traits of a Rockstar Software Engineer é, em minha opinião uma resposta sensata para a pergunta citada acima. O artigo apresenta uma lista de 10 características que definem um engenheiro brilhante. Seguem minhas experiências e pontos de vista sobre cada um dos aspectos citados no artigo:

1. Loves To Code

Acho que isso se aplica a qualquer coisa que uma pessoa possa fazer. Qualquer tarefa é executada melhor quando há uma pitada de paixão envolvida. Você tem que amar o que faz para poder fazer bem feito. Além do mais codificar não é uma ciência exata. Como dito no artigo: "codificar é uma arte", e toda arte precisa de um pouco de paixão para dar certo.

2. Gets Things Done

Essa é um gancho de direita no queixo desse pessoal que sai da faculdade querendo ser SQE (Software Quality Engineer): "There are plenty of technical people out there who talk about software instead writing it". Como pode uma pessoa descrever como construir software sem nunca ter construído um (projetos de faculdade definitivamente não contam). Bons engenheiros resolvem os problemas de forma simples e objetiva. Vale enfatizar: simples e objetiva. Num software em JavaME, um dos requisitos consiste em salvar as configurações do usuário (aproximadamente 5 bytes) em RMS. O que você acharia se, para esta simples tarefa, um engenheiro levasse 2 semanas e entregasse  6 classes, aplicando nelas inúmeros padrões de projetos? Particularmente achei horrível! “Keep it simple, son”. Mas não entenda esse tópico erroneamente. O processo de análise é muito importante e muitas vezes é necessário muita pesquisa e análise para achar a maneira mais simples de implementar um componente específico, mesmo que ele seja pequeno. 

3. Continuously Refactors Code

"Coding is very much like sculpting". Que mais posso dizer? Se você não sabe fazer refactoring ou se sabe e não aplica no seu dia-a-dia, a probabilidade do seu código não ser dos melhores é alta. Refactoring é uma disciplina que não pode ser ignorada. Li num livro que os projetos de software deviam ser feitos sempre duas vezes. Que apenas depois de observar os erros cometidos da primeira construção, os engenheiros estariam realmente preparados para implementar o projeto "de verdade". Refactoring tem mais ou menos esse conceito: escreva a primeira versão, observe os erros, rescreva e repita o processo até que você acredite que o código está perfeito. Certamente não estará, mas estará bom o suficiente. De quebra você ainda vai descobrir alguns errinhos que você acabou de cometer, e como está com o código fresquinho na cabeça, vai resolve-los em segundos.

4. Uses Design Patterns

"A good engineer always recognizes and leverages patterns, but is not driven by them." Conheça Design Patterns e saiba aplicá-los inteligentemente. Ao contrário do que muita gente pensa, Designs Patterns não devem ser usados em todas as classes que você criar. Apenas use onde é realmente necessário e útil. Dessa vez, ênfase no "útil". Lembra das seis classes e dezenas de padrões aplicados para conseguir salvar 5 bytes no RMS? Muito cuidado com o uso errôneo dos Patterns. Se quando aplicados corretamente soam como verdadeiras obras de arte, quando aplicados de maneira equivocada podem ser grandes vilões, afinal, quem desconfiaria de um todo poderoso Design Pattern? Eu. Na minha curta vida de desenvolvedor, não vi nenhum padrão ser tão reincidentemente mal aplicado quanto o Singleton. Banir esse Pattern  é a solução aconselhada por vários gurus, repetindo uma cruzada semelhante à travada contra o "goto" em 1900 e bolinha. A que ponto chegamos. Portanto, não acredite que padrões de projetos são a solução para tudo. Eles são apenas mais uma ferramenta à disposição e você não vai querer usar uma chave oitavada onde o mais indicado é uma tesoura.

5. Writes Tests

Você não sabe o que isso pode fazer por você e pelo seu software. No final do ano passado minha gerente me deu feedback que eu precisava melhorar minhas habilidades com testes. E ela estava certa. Meus códigos saiam do forno com dezenas de centenas de bugs. E testar é chato. Bom mesmo é escrever código. Então, por que não unir o útil ao agradável e escrever código para testar seu código? Perfeito! No inicio do ano tive de implementar um pequeno banco de dados OO e resolvi aplicar Unit Tests nele. Resultado já faz quase um ano que ele está sendo utilizado, testado e re-testado e apenas 5 manutenções corretivas foram feitas. O primeiro bug só apareceu depois de 3 meses. Nada mal, hein? Fora o benefício de estar muito mais seguro quando minha gerente me perguntou como estava o progresso do desenvolvimento do componente. Eu sabia exatamente onde estavam meus problemas e pude informar com firmeza o andamento do trabalho. Experimente uma vez, e não largue mais.

6. Leverages Existing Code

A chave nesse tópico é: "Não reinvente a roda".  Apóie-se em código que esteja pronto e que já tenha sido provado e aprovado. Procure código pronto no próprio projeto, nos projetos antigos e no google. Se já existe um componente pronto para ser usado, por que escrever um novo e ter que gastar preciosas semanas debugando e testando esse componente? Apenas tenha atenção com as licenças dos componentes que você quiser usar.

7. Focuses on Usability

Essa tarefa nem sempre é fácil. Muitas vezes quem define essas coisas não somos nós, mas sim o pessoal de Marketing e Vendas. Mas faz parte dos ossos do ofício pelo menos avisar quando algo não está lá uma Brastemp. De preferência já sugerindo uma possível alternativa. Por outro lado, se a usabilidade depender apenas de nós, pobres engenheiros, o software, quase que certamente, vai ser um fracasso nesse quesito. Tente delegar essa tarefa aos designers, mesmo que eles sejam completos excêntricos, vão produzir melhor resultado que engenheiros. Certamente o ideal é uma aliança entre os três setores.

8. Writes Maintainable Code

O código fonte tem duas funções básicas: implementar uma funcionalidade corretamente e informar claramente como essa funcionalidade está sendo implementada. Fatalmente, alguém, um dia, terá realizar manutenções nesse pedaço de código que você acabou de escrever.  E esse alguém pode ser você mesmo. Podemos escolher entre tornar isso um martírio ou apenas em mais uma tarefa a cumprir. Comente seu código, siga os padrões de nomenclatura, e nada de escrever código ofuscado. Apenas mantenha em mente que há a possibilidade de você ter de fazer manutenção no seu próprio código daqui a um ano e que, nessa ocasião, não lembrará mais do que fez. Naturalmente o código estará bem documentado e auto-explicativo.  

9. Can Code in Any Language
10. Knows Basic Computer Science

Não tenho o que acrescentar nesses últimos dois tópicos. Você não pode se apegar a uma linguagem, a ponto de não conseguir usar outra. Isso é um erro grave, acima de tudo, profissinalmente.  Tampouco pode se dar ao luxo de não conhecer algorítimos de estruturas de dados, conceitos de banco de dados e paradigmas como liguagens estruturadas ou orientadas a objetos.

Aconselho que confiram o artigo na fonte e aproveitem para lê-lo e extrair alguns pontos os quais não mencionei aqui.

Apple: Security Expert Needed

Hello World!

A Apple quer contratar um Engenheiro de Segurança para o iPhone e, dentre os requisitos para o cargo, consta: "Reverse Engeneering Expert". A empresa pretende contra-atacar os hackers com um pouco de seu próprio remédio. O posto está aberto desde setembro de 2007, mas ainda não foi preenchido.

Desde o seu lançamento o iPhone vem sendo o melhor playground para hackers do mundo. Falhas na segurança do browser Safari foram a porta de entrada que possibilitaram o destravamento da primeira versão do dispositivo, gerando uma grande dor de cabeça para a Apple e seus contratos de exclusividade.

O currículo necessário para ser admitido não é para qualquer um... mas se você conseguir realizar o feito, por favor, não esqueça do cara que lhe deu a dica! [:-P]

Fonte:
http://www.theregister.co.uk/2008/07/25/apple_iphone_hack_job_offer/
http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=12150&CurrentPage=1

PS: Elogios, críticas, sugestões e reclamações são bem vindos na sessão de Comentários abaixo.

Eclipse? Que é isso?

Hello World!

Provavelmente você deve sabe que o Eclipse é uma IDE (Integrated Development Environment) para desenvolvimento em Java, certo? Errado! O Eclipse é uma ferramenta muito mais poderosa que isso.

História
A IBM, originalmente, idealizou o que mais tarde viria a se tornar a Eclipse Platform com a intenção de resolver uma fonte de reclamações constantes por parte de seus clientes: As várias ferramentas IBM pareciam vir de companhias distintas e simplesmente não funcionavam juntas. Faltava consistência. De quebra, essa solução ainda diminuiria a replicação de código comum, coisa que é sempre bastante benéfica.

Depois de construída, a plataforma era boa o suficiente para ser difundida, então a IBM resolveu fazer uma IDE sobre essa plataforma e distribui-la gratuitamente com o intuito de divulgar a plataforma. Dessa forma a IBM mataria dois coelhos com uma única cajadada. Divulgaria a plataforma Eclipse e ainda faria frente ao VisualStudio da Microsoft.

Infelizmente os parceiros da IBM ficaram apreensivos em investir na plataforma desconhecida e isso levou a IBM a abrir o código do Eclipse em 2001. Foi fundado então o Eclipse Consortiun que ainda contava com outras oito empresas. Um fato interessante é que o domínio eclipse.org pertencia a um time de futebol feminino numa cidade chamada Illnois. Óbvio que a IBM fez uma oferta irrecusável pelo domínio...

Depois disso o Eclipse passou ser bastante conhecido, mas algo ainda afastava investidores. Parecia que a IBM estava no controle de tudo... Foi quando nasceu a Eclipse Foundation, uma empresa sem fins lucrativos e completamente desligada da IBM. Este modelo é empregado até hoje, e que vem dando muito certo por sinal.

Eclipse Foundation

O Eclipse pode ser usado como IDE Java, e essa é, certamente, sua faceta mais divulgada. Porém, também pode ser usada como IDE para várias outras linguagens como C/C++, PHP, Ruby, JavaScript e HTML. Ai você me diz: "Tá, e daí?". Daí que não acabou ainda não! Além disso a Eclipse pode ser usado pra construir qualquer outro tipo de ferramenta ou aplicativo. O Eclipse consiste de uma plataforma para construção de aplicativos em geral. Segundo a Eclipse Foundation o Eclipse é:

• IDE Framework
• Tools Framework
  
• Open Source/Community
  
• Eco-system
• Foundation

Vamos por partes...

1. IDE Framework

O Eclipse é sim uma IDE, mas também uma IDE C/C++, Ruby, etc. Na verdade é possível integrar qualquer coisa no Eclipse, até mesmo UML ou um editor de imagens avançado.

2. Tools Framework

Com plug-ins é possível transformar o Eclipse no que for preciso.
Alem disso, removendo a IDE o que sobra é um poderoso Framework para aplicações: o Eclipse RPC. E qual a vantagem? É multiplataforma, afinal o Eclipse roda em Windows, Linux e Mac; Possui integração nativa com o OS (Drag'n'Drop, OLE...); Uma larga variedade de widgets prontos.

3. Open Source/Community

Todo código do Eclipse é aberto. Há milhares de contributors, centenas de commiters, centenas de plug-ins comerciais, incontáveis blogs de entusiastas (não é meu caso... juro!) e portais, etc.
Saiba o que são contributors e commiters na próxima sessão.

4. Eco-system

Eu sempre quis saber quem faz o código do Eclipse. E a resposta é: o Ecossistema.
Calma, eu explico. O Eclipse é um projeto de código aberto, certo? Logo qualquer um pode contribuir para o projeto. Eu, você, seus amigos, meus amigos, nossas vós, etc. O que precisamos fazer é escolher uma CR no Bugzilla deles e submeter uma solução, assim nos tornamos contributors. Pronto, seu código vai direto para a Baseline do projeto, não é? Não mesmo! Ai que entram os commiters. Só eles tem acesso ao repositórios do projeto e eles tem a obrigação de revisar seu código e assegurar que ele funciona para, só então, integra-lo. Não se preocupe o crédito da resolução do problema ainda será seu. Se você for um bom contributor, pode até virar um commiter. Para isso, basta que um dos commiters indique você e que os outros aprovem sua promoção (se fosse aqui no Brasil rolariam altos nepotismos...).

Nesse momento você se pergunta: "E onde diabos entra o Ecossistema nisso?". Simples. A maioria dos desenvolvedores que trabalha nos vários projetos do Eclipse são engenheiros contratados por alguma empresa grande que está por trás do projeto, pois é de seu interesse. Interessante, hein?

Várias empresas contribuem para o Eclipse Platform, dentre elas gigantes como a Intel, Nokia, Motorola, IBM, Borland, Oracle, SyBase e Wind River.

5. Foundation

A Eclipse Foundation e uma organização sem fins lucrativos que emprega basicamente de advogados (alguém estava esperando que eu falasse desenvolvedores?). Eles ficam lá analisando a legalidade dos projetos. De acordo com a licença EPL (Eclipse Public Licence) todo código do Eclipse é livre e qualquer um pode modificá-lo contanto que submeta a sua modificação, porém se você apenas usa, digamos, o RPC para fazer sua aplicação, sem altera-lo, é possível que você adicione o RPC à seu software sem violar a licença. Essa é a grande diferença para o GPL.

A EPL também garante que o código EPL é de inteira responsabilidade da Eclipse Foundation. Isso significa que caso você venha a sofrer um processo judicial por causa do código EPL que você distribuiu com sua aplicação a Eclipse Foundation se responsabiliza completamente (apesar de soar estranho aqui, nos US e na Europa isso é normal). Entendeu por que a Eclipse Foundation tem advogados em vez de desenvolvedores?

O nome Eclipse

O nome Eclipse tem uma história interessante. E, ao contrário do que muitos pensam, não é uma afronta direta a Sun e o NetBeans, apesar de que, a Sun por muito tempo, se recusou a fazer parte do ecossistema por causa desse nome. O fato é: quem a IBM realmente queria "eclipsar" era a Microsoft que na época do lançamento do Eclipse era claramente o líder do mercado de IDEs com o VisualStudio.

Fontes:
History of Eclipse
Eclipse: Behind the Name

O Symbiam e o Smartphone

Hello World!

Depois de umas semanas se postar, aqui estou. Sabe como é, né? São João, São Pedro (no nordeste São João é feriado)... Além do mais não achei nada de interessante pra falar até a Nokia resolver comprar o Symbiam... Nada mais justo, até mesmo porque ela é a maior utilizadora do sistema - a Nokia pagou cerca de 250 milhões de dólares em licensas do Symbiam só em 2007 e comprou a empresa por 410 milhões.

Mas na verdade não foi esse o fato que realmente me chamou a atenção, e sim, uma reportagem que li sobre a história do mercado de smartphones e a relação da mesma com o Symbian , ou vice versa.

Quando citado pela promeira vez, o termo smartphone traduizia-se basicamente em acesso a internet e a emails em qualquer lugar e horário. Mas na verdade os celulares deste seguimento são primordialmente grandes, lentos, complicados e tornavam a navegação na internet realmente dolorosa.

Na reportagem o autor enumera alguns fatos interessantes: o Symbian não fez em sete anos de existencia o que o iPhone, juto com o seu OS X, fez em poucos dias (popularizar o smartphone); A interface dos celulares Nokia tem usabilidade questionável; Hoje em dia qualquer celular mid-tier roda GMail, Google e GoogleMaps sem maiores problemas.

Confira o Artigo na Integra em: Farewell then, Symbian

PS: Sempre achei que os celulares Nokia tinham uma UI muito complicada... finalmente achei alguém que concorda comigo.

Maker 2 Surpreende em Avaliação da InfoExame

Hello World!

Quem diria? A empresa baiana Softwell, desenvolvedora do Maker 2, se saiu bem melhor que a encomenda.

Na avaliação da InfoExame de Abril de 2008, o Maker 2 enfrentou concorrentes de peso como Microsoft Visual Studio 2008 e Borland Delphi for PHP e, pasmem, venceu a disputa.

Com a média de 8,4 (numa escala de 0 a 10), o software que promete ajudar a desenvolver sistemas inteiros sem que seja necessário uma linha de código sequer, derrotou as gigantes Microsoft e Borland com seus respectivos ambientes de desenvolvimento por uma diferença de um décimo.

Aparentemente a Info não levou um detalhe importante em consideração: custo/benefício. Afinal, será que um único usuário do Maker 2 (RS 13.999) é capaz de produzir mais e melhor do que seis funcionários usando o MS Visual Studio 2008 (R$ 2.299) ou ainda do que quinze usando o Delphi for PHP da Borland (R$ 897)? Só o tempo poderá responder...

Independentemente disso, este é um grande passo para a comunidade desenvolvedora de software brasileira, firmando, cada vez mais, o nome do Brasil como país de referência no desenvolvimento de tecnologia e conhecimento na área de TIC.

Fonte: http://www.softwell.com.br/PaginaAction?pagina=Noticia29

Flash Lite: 25 Milhões de Instalações

Hello World!

A Adobe que já há anos mudou a cara da internet com seu Flash, agora quer seu pedaço do bolo no mundo dos dispositivos portáteis.

Desde o seu lançamento, o Flash Lite vem crescendo significativamente. Só na europa central, a previsão é mais de 25 milhões de dispositivos possuam a versão do software instalada ao final deste ano.

A Sony Ericsson não perdeu tempo e lançou uma plataforma the promete ligar o Flash Lite ao JavaME. Segundo matéria do site Telecoms.com (é preciso se cadastrar para ver a reportagem completa), os desenvolvedores serão capazes de criar interfaces limpas com o apoio do Flash enquando desfrutam de todo o conjunto de APIs e da flexibilidade fornecida por JME.

A Adobe, que de besta não tem nada, ainda firmou um contrato com a gigante Qualcomm para que os dispositivos da mesma ganhem uma versão do mini-Flash. Dá-lhe "Fréxi"!

Confira em: Macromedia and Qualcomm Extend Flash Lite To BREW

JME DataBase

Hello world, again!

Estava pesquisando um pouco sobre o assunto e achei esse site muito interessante.

Os caras da Perst fornecem uma implementação de Banco de Dados OO para dispositivos que implementam CLDC.

Infelizmente, a licença não permite o uso comercial do software deles, mas em compensação eles publicaram um artigo muito bom falando sobre os obstáculos (e a maneira de contorná-los) encontrados por eles durante a implementação do Perst Lite, a versão mobile do Perst.

A implementação do conceito explanado pelos caras não é coisa de outro mundo não, com um pouco de paciência para entender os conceitos expostos, a implementação é tranquila.

Espero que se divirtam com a leitura! um artigo em inglês, logo, na pior das hipóteses, serve para treinar as habilidades nessa língua que vive em nosso cotidiano.

Developing an object-oriented database for J2ME-based embedded devices