Ready to Sail Planet

March 31, 2011

Danilo Silva

Caiu na Rede

Qualquer lugar onde você esteja há uma conexão a Internet disponível. No seu bairro com certeza há uma lan house; sua casa, ou de um vizinnho, há conexão discada, ou banda larga; conexões 3g por celulares é uma realidade, mesmo instável; restaurantes, bares, cafés, hotéis, aeroportos, hospitais, tem um hotspot disponível.

Ligado, plugado, antenado, conectado, qualquer palavra usada, nos remete a necessidade de um lugar comum para a troca de informações, fazendo o mundo virtual ser mais do que uma moda.

E em tempos onde redes sociais gera movimentação de qualquer mídia, a palavra de qualquer pessoa ganhou uma força nunca antes tida. Dependendo do que se é dito em Twitter, Orkut, Facebook, MySpace, etc, essas palavras torna-se a verdade absoluta. Se não houver pesquisas e bases para localizar a fonte e os fundamentos da informação, a rede vira uma orgia de conteúdos, onde garimpar a verdade torna-se cada vez mais complicada, e até confusa.

Redes Sociais
Tivemos nos últimos tempos, um exemplo claro da força da palavra. No Twitter, a movimentação do “CALA BOCA GALVÃO” foi tão forte, que mídia impressa, televisiva, qualquer noticiário, tinha estampado o assunto, que começou como uma brincadeira e tomou proporções inimagináveis, ultrapassando a barreira do virtual.

Usar a rede com moderação é importante para o seu próprio bem. Há anos empresas monitoram perfis em redes sociais, seja ele de futuros empregados, seja dos já contratados da casa, por isso a atenção deve ser redobrada, pois sua ferramenta de entretenimento, pode ser a porta de entrada, ou saída, de sua vida profissional.

Isso não quer dizer que você deve temer, e até censurar, suas postagens ou comunidades, mas sim ficar atento a elas, tomando cuidado com suas palavras e perfis. Vale lembrar que comunidades como “Eu Odeio Meu Chefe”, “Eu Jogo CS no Trampo”, entre outras, são muito mal vistas, assim como falar mal das empresas anteriores.

Diversas empresas para entrar na onda das Redes Sociais, criaram perfis para divulgá-las e abrir um novo canal de contato com seus clientes. Assim, funcionários além de manter os próprios perfis, ainda agregam conteúdo nos perfis empresariais.

Em conversa com Marcelo Toledo (http://marcelotoledo.org), CTO da Vex, ele citou e deu sua opinião sobre algumas atitudes a serem tomadas ao manter um perfil na web:

  • Autenticidade: Não tentar imitar os outros, ser você mesmo:
"Todas as pessoas são únicas, alguma coisa de original vai sair de você, tentar imitar os outros é a pior coisa que se faz, autenticidade é a chave. Também não tenha medo de ser criticado por ser autêntico, todas as pessoas que inovam sofrem no começo."

  • Bom Senso: Tomar muito cuidado ao mexer em pontos delicados:
"Vide caso do diretor de uma empresa de tecnologia que foi demitido. Vide fotos íntimas que são publicadas em Orkuts da vida."

Ficar atento as suas atitudes é um dos primeiros passos para estar pronto para navegar.

by Dan Artimos (noreply@blogger.com) at March 31, 2011 05:22 AM

Marcelo Toledo

Startups

Inauguro hoje neste blog, uma serie de posts semanais, focada em um único assunto:

Startups

Para isso, fiz um mapa mental para entender quais são os assuntos mais importantes que circundam este mundo.

Veja o resultado:

Mapa mental dos artigos Startups

Clique para dar um zoom

São temas muito debatidos, mas como sempre foi meu objetivo neste blog, quero dar uma visão pessoal de cada um desses pontos.

Artigo por artigo, você faz um pesquisa no google e encontra uma dezena deles, mas eu quero algo diferenciado. Eu quero contar pra você o que acontece na prática, o que eu vivi e ainda vivo no meu dia-a-dia.

Funcionará assim:

Toda semana escolherei um tema, seguindo como referência o mapa mental, os comentários no blog e feedbacks. Todo post iniciará com “Startups”, assim rapidamente você saberá do que se trata. O artigo terá entre 400 e 600 palavras, equivalente a somente duas páginas de um livro, bem objetivo para não ficar chato e maçante.

Quer receber os artigos toda semana? Vá ao topo do site, na lateral direita, você tem duas opções, RSS, ou email na opção Receba por email.

Quer ajudar? Logo aqui em baixo, de um like ou retweet e avise seus amigos para que eles possam aproveitar desde o começo.

Obrigado e até semana que vem com o primeiro post da serie Startups!

by Marcelo at March 31, 2011 02:22 AM

Sergio Prado

Entrevista com Jack Ganssle

jack ganssle completo Entrevista com Jack GanssleAproveitei a vinda de Jack Ganssle ao Brasil para o II Workshop Projetando Sistemas Embarcados e fiz uma entrevista curta mas muito bem humorada. Confiram a versão original em inglês abaixo e logo em seguida a versão traduzida.

Jack, tell me a little bit about yourself. How did you end up working with embedded systems?
Well, I was always a geek, from long before anyone used that term. I was into ham radio in high school. My dad worked at a small space company as a mechanical engineer, and we kids were required to sweep up and clean the building — for free. But I was allowed to keep any parts the engineers in the lab had dropped on the floor, so built a nice collection of ICs and other parts. At 16 I got a job as an electronics technician, and while I was in college the company decided to build a product with a microprocessor. I was the only person who knew digital and programming, so was promoted to engineer. That was in 1972, working with the first 8 bit processor, the 8008. Before long we were building a lot of embedded products, and I was running the digital engineering/programming group. We worked insane hours but had a lot of fun!

Nowdays, what do you do for living?
Mostly annoy my wife! I write about this field, and do a lot of lectures about it. And I do some kinds of consulting — for instance, advise companies about their embedded challenges. I get to look at a lot of new products and talk to some really smart engineers.

What was the biggest challenge in your carreer?
Making payroll. In the 80s and 90s I started a company that provided development tools, and it was very stressful at times coming up with the cash each week to pay all of the employees. But we always did. Today I find it challenging to keep up with all of the new products and ideas that come out each day. But it’s a lot of fun to do so.

In your opinion, what is the number one source of bugs in embedded systems?
I really believe most bugs come from engineers not thinking deeply enough about their code. We shouldn’t start coding till we know exactly what we want to do, and then we should review our work very carefully before starting testing. It’s just too tempting to fire up the debugger instead of thinking deeply.

I know you love sailing! Between a big shark following your boat in the deep sea and a scary global variable in your code, which one would ou choose?
I’ll take the shark any day!

What do you have to say for the new engineers/developers that are beginning the carreer on embedded systems. Any tips or tricks?
Sure — save money every week. Bad times always come, and you want to have a financial cushion. Also, check out Mike Ficco’s book “What Every Engineer Should Know About Career Management” It’s important that we actively manage our careers. Stay involved and constantly learn new things.

What can you say about the future in embedded systems?
Embedded systems have only been around for 40 years. We can’t even dream what will come. I do expect, perhaps in my lifetime, robots that build robots. And the robots will do all of our manual labor. I wonder if money will have any value when labor is all done by the robots?

I love your books! Do you have any plan for others?
Thanks. I have a few ideas, but just don’t have the time for a book project right now.

If you would go to a desert island, which programming language, CPU architecture and operational system would you carry? :)
Hmmm. A desert island means very little power. I’d have to wire a couple of coconuts in series, so might bring a TI MSP430, which is a 16 bit machine that runs on almost no power. C, of course, and, if money were no object, a nice certified RTOS like Integrity.

Last words for our readers…
The most important thing is to have fun. You’ll spend decades doing this; there’s nothing sadder than a person who is miserable in their job.

Segue abaixo a entrevista traduzida:

Jack, fale um pouco sobre você. Como você começou a trabalhar com sistemas embarcados?
Bem, sempre fui um geek, muito antes de alguém ter usado o termo. Comecei a mexer com radioamadorismo no ensino médio. Meu pai trabalhou em uma pequena empresa aeroespacial como engenheiro mecânico, e nós crianças precisávamos varrer e limpar o prédio — de graça. Mas me deixavam pegar qualquer coisa que os engenheiros do laboratório jogavam fora, então montei uma coleção legal de circuitos integrados e outras peças. Aos 16 anos consegui um emprego como técnico eletrônico, e quando estava na faculdade a empresa decidiu montar um produto com um microprocessador. Eu era a única pessoa que sabia eletrônica digital e programação, então fui promovido a engenheiro. Isso foi em 1972, trabalhando com o primeiro processador de 8 bits, o 8008. Não muito tempo depois estávamos desenvolvendo diversos produtos embarcados, e eu era o responsável pelo grupo de engenharia e programação. Trabalhamos que nem loucos mas foi muito divertido!

E o que você faz hoje em dia?
Basicamente fico perturbando minha esposa! Eu escrevo sobre a área, e também apresento bastante palestras. Dou alguns tipos de consultoria — por exemplo, aconselho empresas sobre seus desafios na área de sistemas embarcados. Eu dou uma olhada em um monte de novos produtos e troco experiências com alguns engenheiros bem espertos.

Qual foi o maior desafio na sua carreira?
Gerenciar a folha de pagamento. Nos anos 80 e 90 eu iniciei uma empresa que fornecia ferramentas de desenvolvimento, e era muito estressante ter dinheiro toda semana para pagar os funcionários. Mas nós sempre conseguíamos. Hoje eu acho desafiador acompanhar os novos produtos e idéias que aparecem todos os dias. E é também muito divertido.

Na sua opinião, qual a causa número um de bugs em sistemas embarcados?
Eu realmente acredito que a maioria dos bugs vem do fato dos engenheiros não pensarem o suficiente sobre o código que estão desenvolvendo. Nós não devemos começar a codificar enquanto não soubermos exatamente o que queremos fazer, e então nós devemos revisar atentamente o trabalho antes de começar a testar. É muito tentador iniciar o debugger ao invés de pensar mais profundamente sobre o problema.

Eu sei que você adora navegar! Entre um grande tubarão seguindo seu barco em mar aberto e uma assustadora variável global no código, qual você escolheria?
O tubarão, sempre!

O que você tem a dizer para os engenheiros que estão iniciando a carreira em sistemas embarcados. Alguma dica?
Claro — guarde dinheiro toda semana. Tempos ruins sempre aparecem, e você quer ter uma segurança financeira. Além disso, dê uma olhada no livro de Mike Ficco 
What Every Engineer Should Know About Career Management”. É importante gerenciar ativamente sua carreira. Se envolva e aprenda coisas novas.

O que você pode dizer sobre o futuro em sistemas embarcados?
Sistemas embarcados são recentes e estão por aí em torno de 40 anos. Nem em sonhos conseguimos prever o que esta por vir. Eu espero, talvez enquanto estiver vivo, ver robôs que constroem robôs. E robôs irão fazer todo nosso trabalho manual. Será que o dinheiro terá algum valor quando todo trabalho for feito por robôs?

Eu amo seus livros! Você tem algum plano para outros?
Obrigado. Eu tenho algumas idéias, mas por enquanto não tenho tempo para um novo projeto.

Se você fosse para uma ilha deserta, que linguagem de programação, arquitetura de CPU e sistema operacional levaria? :)
Hmmm. Uma ilha deserta significa muito pouca energia. Eu precisaria ligar alguns cocos em série, e então levar o MSP430 da TI, que é uma CPU de 16 bits que roda quase que sem energia. Linguagem C, é claro, e se dinheiro não fosse problema, um bom RTOS certificado como o Integrity.

Últimas palavras para nossos leitores…
A coisa mais importante na vida é se divertir. Você irá passar décadas fazendo isso, e não existe coisa pior no mundo do que alguém infeliz no que faz.

Obrigado Jack!

Um abraço,

Sergio Prado

Posts relacionados:

  1. 2 dias de muita sabedoria embarcada com Jack Ganssle
  2. Entrevista com Colin Walls
  3. Entrevista com Gustavo Denardin


by sergioprado at March 31, 2011 01:57 AM

March 28, 2011

Sergio Prado

2 dias de muita sabedoria embarcada com Jack Ganssle

Nos últimos dias 24 e 25 de março aconteceu em São Paulo o II Workshop Projetando Sistemas Embarcados com Jack Ganssle. E foram 13 horas de muita "sabedoria embarcada Jackiniana"!

Jack é uma figura simpática, simples e que sabe passar muito bem sua experiência de mais 40 anos na área. Sua palestra abrangeu temas tão variados quanto gestão de projetos de software, melhoria de processos de desenvolvimento, uso de ferramentas, engenharia de hardware e muita, mas muita escovação de bits.

E como sua palestra fluía de um tema a outro de forma constante mas ao mesmo tempo imperceptível, ele conseguiu prender nossa atenção durante todo o seminário, e quase não vimos o tempo passar!

ONDE ESTAMOS E PARA ONDE VAMOS

Uma boa discussão sobre a evolução das CPUs deu início ao seminário, destacando a crescente capacidade de processamento e CPU's cada vez menores e mais acessíveis (hoje você consegue um ARM a "míseros" $0.65). Jack nos alertou para um dos fatores limitantes da evolução das CPU's: o consumo. A Intel esperava chegar a 20GHz em 2010, mas não conseguiu por causa deste "pequeno" problema. E o consumo é ainda mais importante em sistemas embarcados, já que alguns equipamentos precisam rodar por anos apenas com uma pequena bateria.

Um dos pontos altos da palestra foi a apresentação de um vídeo onde um repórter saiu às ruas perguntando às pessoas se elas sabiam o que eram sistemas embarcados. Este vídeo rendeu boas risadas. Quem trabalha nesta área e já não teve dificuldades em explicar para família ou amigos o que faz da vida? :)

Diversas pesquisas foram mostradas indicando um problema com a qualidade dos produtos que desenvolvemos, o que resulta numa alta taxa de bugs, seja por prazos curtos ou problemas com ferramentas de desenvolvimento ou debuggers. E depois de vários exemplos ficou a constatação de que o firmware é a coisa mais cara do universo!

GESTÃO DE PROJETOS

"Bugs são a principal causa de projetos atrasados!". Jack não cansou de dizer isso. Assim como as pessoas não casaram de dizer: "Como eu queria que meu chefe estivesse aqui!", apesar de muitos ali serem chefes. E tenho certeza que o chefe do chefe diria a mesma coisa! O problema é que só existe um chefe: o cliente!

A melhor forma de acabar com os bugs é evitá-los em primeiro lugar. Mas estamos sempre envolvidos com o dilema: "Não liberar o produto no prazo, ou liberar no prazo, mas com bugs". É como se estivéssemos "correndo atrás do próprio rabo".

Então Jack nos apresentou técnicas de gestão de projetos e o uso de ferramentas para aumentar a produtividade e a qualidade, como manter um ambiente produtivo e pessoas motivadas (regado a muitas tirinhas engraçadas de Dilbert), como estimar projetos de software e trabalhar com tradeoffs de prazo, qualidade e funcionalidade; além de apresentar modelos e práticas de desenvolvimento como o CMMI, PSP e XP.

PROJETO E ARQUITETURA

O lema aqui é "Dividir para conquistar". Devemos dividir o projeto em pequenos blocos e decidir o que terceirizar e o que desenvolver em casa, o que será resolvido com hardware e o que será desenvolvido com software.

Qual linguagem de programação usar foi outro tema interessante. A grande parte dos projetos ainda é desenvolvida em C. Mas o uso de C++ cresceu nos últimos anos, apesar de pesquisas mostrarem que poucos usam conceitos como herança ou polimorfismo. Então qual a grande vantagem? Reuso de código? Encapsulamento? Um código bem projetado em C consegue isso também. De qualquer forma, na prática, o que vemos é que as duas linguagens tem seu nicho de mercado, e que na maioria das vezes o design é mais importante que a linguagem usada.

Uma pesquisa sobre o uso de RTOS nos mostrou que muitas empresas sequer usam um sistema operacional, e que outras tantas resolvem desenvolver seu próprio SO, o que contribui para elevar a taxa de bugs, além de atrasar os projetos de software embarcado.

Jack deixou claro também a dificuldade para reusar código. Tudo deve começar com uma mudança de paradigma dos membros da equipe para incentivar o reuso e a criação de código sem dependências entre si, essenciais para termos uma base de código que possa ser reutilizável.

MALDITOS INSETOS

O fato é que passamos metade do tempo do projeto debugando o código, então foram apresentadas técnicas de debugging com BDM e JTAG.

Mas ficou claro que precisamos resolver o problema na origem, então o Jack nos apresentou a melhor ferramenta para evitar bugs: inspeção de código! Todo código desenvolvido deve ser inspecionado por outra pessoa. E concordo plenamente com esta técnica. Duas ou mais cabeças sempre pensam melhor do que uma.

Além disso, ele nos deu outras dicas para evitar bugs no código, dentre elas:

  1. Corrija o problema quando identificado, não deixe para depois!
  2. Não ignore warnings: se o compilador esta com medo, você também deveria estar!
  3. Use um padrão de codificação e/ou um padrão de software como o MISRA-C.
  4. Evite variáveis globais.
  5. Use analisadores estáticos de código como o PC-LINT ou o Splint.

ESCOVANDO BITS

Um prato cheio para os escovadores de bits: como trabalhar com interrupções e desenvolver uma rotina de tratamento de interrupção, como entender o código gerado a partir de um código em C (uma linha de código em C pode gerar 3 instruções em uma arquitetura, mas pode gerar 15 instruções em outra arquitetura!), dicas sobre matemática de ponto fixo e ponto flutuante, como usar o hardware para debugar o sistema, diversas dicas em C (ajustar tamanho estruturas em potência de 2, declarar funções pequenas inline, preferir int ao invés de short e char, etc), os cuidados ao compartilhar variáveis entre tarefas, e por aí vai.

Uma atenção especial foi dada ao uso do heap para alocação dinâmica de memória, o uso inteligente do watchdog, testes de memória e técnicas de debouncing.

LIVROS

Durante a apresentação, Jack recomendou diversos livros, dentre eles:

  1. Confessions of a Used Program Salesman - Will Tracz
  2. An Embedded Software Primer - David E. Simon
  3. High Speed Digital Design - Howard Johnson and Martin Graham
  4. Best Kept Secrets of Peer Code Review (www.smartbearsoftware.com)
  5. Test Driven Development for Embedded C - James W. Grenning
  6. Peopleware - Tom DeMarco and Timothy Lister

A PROGRAMMER'S DRINKING SONG

E para terminar, deixo aqui uma canção que expressa a infeliz realidade do desenvolvimento de projetos de software:

100 little bugs in the code,
100 bugs in the code,
 
Fix one bug, compile it again,
101 little bugs in the code.
 
101 little bugs in the code...
 
(Repeat until BUGS == 0)

Valeu Jack! Agora, que venha o ESC Brazil 2011!

 2 dias de muita sabedoria embarcada com Jack Ganssle

Sergio Prado e Jack Ganssle - 25/03/2011

Um abraço,

Sergio Prado

Posts relacionados:

  1. Entrevista com Jack Ganssle
  2. II Workshop Projetando Sistemas Embarcados
  3. Call for Papers para o ESC Brazil 2011


by sergioprado at March 28, 2011 12:31 AM