As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

Para ser um Sysadmin

Posted: março 7th, 2010 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: , ,

Vendo o formspring do fike eu tentei me lembrar do que um bom sysadmin precisa. Eu e ele terminamos o papo no gtalk, e eis a lista sem uma ordem específica:

  1. Sistemas Operacionais e Organização de Computadores (não adianta tentar ser um sysadmin sem ter um amplo conhecimento de como o SO e Hardware funcionam)
  2. Rede (mesma coisa ali de cima, e aqui estamos falando daquelas chatices de TCP/IP, cabeçalhos, window size, mtu e tudo mais, não só roteamento)
  3. Programação (tem de saber algum shell script, e mais uma linguagem de verdade)
  4. Conceito das linguagens utilizadas no ambiente que vai se administrar (java, python, etc…)
  5. Banco de Dados (como eles funcionam, transações, locking, particionamento, tuning)
  6. Inglês (isso é óbvio)

Mas dai você vai dizer “porra, mas esse monte de coisa?”. Acredite, o seu ambiente vai dar merda e você pelo menos tem de ter conhecimento o bastante para apontar a falha (além de ter de resolver).

intel

1 Comment »

Programando Androids – Parte 4

Posted: maio 14th, 2009 | Author: coredump | Filed under: Programação | Tags: ,

android_t1Na parte 3 falei sobre o gerenciamento de memória. Também falei sobre o cuidado que se deve ter para manter o estado da aplicação consistente entre as várias mudanças que o Android OS executa automaticamente.

Ciclo de vida de uma aplicação no Android

Vale lembrar que uma “aplicação” no Android é na verdade uma Activity, ou um conjunto de Activities, que podem ser consideradas as “janelas” da aplicação. Cada Activity é considerada separadamente, mesmo que esteja dentro da mesma Aplicação.

O ciclo de vida de Services é bem diferente do ciclo de vida de uma Activity e não vem ao caso para este post.

A imagem abaixo (novamente cortesia do Google) demonstra o ciclo de vida básico de uma Activity.

activity_lifecycleAs ovais coloridas são os estados em que a Activity pode estar, enquanto os retângulos cinzas são os nomes de métodos de callback que serão invocadas pelo OS em cada transição. Ou seja, de quando uma Activity inicia até ela ser mostrada na tela, ela executará o código dos métodos onCreate, onStart e onResume. Os retângulos brancos com texto em itálico descrevem a ação necessária para causar os callbacks ou mudanças de estado.

Você não precisa implementar todos os callbacks, mas existem certas funcionalidades que só estão disponíveis em determinados contextos de callback e coisas que simplesmente não funcionam em alguns lugares. Por exemplo: animações, se colocadas no onResume, não iniciam. As funcionalidades para gravação de estado da aplicação são melhor aplicadas no onPause, mas este método é desenhado para ser executado rapidamente, então cuidado com o que se colocar ali.

Também é importante notar neste gráfico que sua aplicação pode ser morta caso o sistema precise de memória, e é importante dar o tratamento correto aos dados/estados que precisem ser mantidos (como em um jogo, salvar posições de objetos, valores e etc..). Outra coisa a se notar é que a Activity vai ser destruída na mudança de orientação (quando a tela roda, automaticamente ou pela abertura do teclado nos G1), e isso deve ser levado em conta (código no onCreate pode acabar sendo rodado duas vezes no caso de uma mudança de orientação).

Exemplos

Tirando o fato de que eu mal sei programar em Java, meu programa Lanterna foi um bom aprendizado sobre esses estados e o ciclo de vida da aplicação.

Por exemplo, o Lanterna requer que o telefone fique sempre ligado quando funcionando (ótima forma de se acabar com a bateria). Para isso eu precisei requerer uma parada chamada WakeLock, disponível no serviço de gerenciamento de energia (PowerManager). No onCreate eu requisito ao Android o acesso ao serviço:

/* PowerManager interface to get and release the WakeLocks later */
PowerManager pmanager = (PowerManager) getSystemService(Context.POWER_SERVICE);
this.wakelock = pmanager.newWakeLock(PowerManager.SCREEN_BRIGHT_WAKE_LOCK,
"Lanterna Lock");

A variável wakelock (ou atributo, sei lá como Java chama isso), foi criada anteriormente, só olhar o código inteiro para entender. Como isso é uma referência ao serviço e nada mais, ele ser recriado a cada vez que a Activity for ativada não faz diferença. O cuidado tem de se ter ao adquirir e liberar a WakeLock, que significa basicamente ativar ou desativar a trava que vai deixar o telefone dormir ou não. Eu faço isso no onPause e no onResume, desta forma a trava é adquirida na primeira vez que a Activity é iniciada e quando ela volta a ser a Activity mostrada na tela (o onResume é chamado nessas duas situações), e é liberada sempre que alguma outra coisa entra na frente (para evitar que o telefone nunca mais durma):

@Override
public void onResume() {
super.onResume();
...
/* Get the WakeLock */
this.wakelock.acquire();

E o código para liberar a trava:

@Override
public void onPause() {
super.onPause();
/* Releases the WakeLock */
this.wakelock.release();
}
1 Comment »

Programando Androids – Parte 3

Posted: maio 13th, 2009 | Author: coredump | Filed under: Programação | Tags: ,

android_t1

Continuando com meus posts sobre programação Android, mesmo desanimado pelo fato de não conseguir colocar minha(s) app(s) no Android Market.

Mas já que comecei, e o assunto é interessante, melhor continuar. Neste post, dando uma olhada por alto em como o Android OS é organizado e como ele gerencia a memória.

Arquitetura e Memória

O Android OS tem uma arquitetura em camadas (stacks). Os níveis mais baixos dessas camadas são por sua vez expostos para os níveis mais altos através de interfaces até a camada mais alta, onde se programa em Java.

A imagem abaixo (cortesia do google) demonstra uma visão aumentada de como estas camadas são organizadas:

Arquitetura do Android OS

Arquitetura do Android OS

Como se pode ver, o nível mais baixo do Android é o Kernel. Atualmente (versão 1.5 “cupcake”) o kernel utilizado é o Linux 2.6.27. No kernel estão também os drivers e controles básicos de hardware. A segunda camada é onde ficam as bibliotecas (libraries) e o próprio runtime do Android, incluindo aí a Dalvik Virtual Machine, encarregada de efetivamente executar o código das aplicações. A terceira camada consiste já das capacidades expostas aos desenvolvedores  para suas aplicações (gerenciador de janelas, sistema de notificação e etc). Finalmente a última camada é composta pelas aplicações propriamente ditas.

A camada de kernel é responsável também pelo controle mais fino da memória. Cada aplicação no Android roda em um processo separado, com sua própria VM, PID (número de processo) e usuário. Isso garante que caso uma aplicação dê problema, ela possa ser isolada e removida da memória sem comprometer o resto do sistema.

A Dalvik VM é a virtual machine que roda código java, mas com várias alterações para fazer isso usando menos ciclos de CPU (portanto gastando menos energia) e com otimizações de espaço/tamanho de dados. A Dalvik usa bytecode diferente da JVM tradicional e as aplicações usam um formato diferente do tradicional JAR (.jar), chamado .dex, também otimizado para menor uso de espaço.

Uma das diferenças da Dalvik é como ela mapeia a memória. Isso é feito usando um mapa memória-disco que permite que aplicações sejam rapidamente removidas da memória e depois restauradas. O G1 da T-Mobile limita cada aplicação a 16M de heap, e ainda estou tentando descobrir exatamente quanto de RAM ele tem. Algumas fontes dizem 192M, outras 64M. O fato é que a maioria das aplicações é bem menor que 16M. Quando o sistema começa a ter problemas de falta de memória o OS vai fechar aplicações que não estejam sendo exibidas, e estas aplicações podem ser retomadas depois com seus estados intactos (desde que bem programadas).

No próximo post eu vou falar um pouco sobre esses cuidados com as informações e o ciclo de vida das aplicações.

No Comments »

Lanterna: mais uma lanterna para telefones Android!

Posted: maio 8th, 2009 | Author: coredump | Filed under: Programação | Tags: , ,

English version below.

logo_lanternaComo eu disse neste post eu comecei a fazer algum progresso em programação para o sistema operacional móvel Android. Como eu precisava fazer alguma coisa para aprender/praticar, resolvi fazer uma lanterna, afinal de contas parece ser uma coisa comum para telefones fazerem o papel de iluminadores, ainda mais com seus grandes e brilhantes LCDs.

Eu me baseei em algumas aplicações já disponíveis no Android | Market, mas também em uma led flashlight da marca INOVA, a INOVA Inforce LED Military Flashlight. Por isso as diversas cores de luz e os modos strobe.

Eu não consigo colocar essa aplicação no Android | Market, por isso vou deixar ela disponível aqui e em outros sites que eu for achando (vou atualizando o post quando necessário).

Funcionalidades:

  • Modo lanterna com luzes branca, amarela, verde e vermelha.
  • Modo strobe com os padrões preto/branco, azul/vermelho (luzes de polícia), multi-cor, sinal luminoso de SOS (em morse), sinal luminoso beacon.
  • Três velocidades de strobe, se mantendo dentro da faixa recomendada pela OMS para evitar o efeito pokemon (epilepsia foto-sensível). Alguns estilos de strobe não são afetados pela configuração de velocidade.

Licença e código fonte:

Lanterna é software livre sob os termos da GPL v3. Eu aceito doações (PayPal) se você gostar o bastante do software! =)

O código fonte, projeto Eclipse e todo o resto podem ser encontrados no repositório hospedado no GitHub.

Download:

Lantena.apk

Bugs e novas idéias:

Lighthouse Bug Tracking

Lanterna, yet another flashlight for Android phones!

logo_lanternaAs I said on this post (in portuguese), I started making some progress on programming Android apps. As I needed something to learn/practice I decided to create another flashlight, after all it seems like a common app on current phones, even more with their big LCD screens.

I based my work on some flashlights already available on the Android | Market, but also on a led flashlight from the INOVA brand, the INOVA Inforce LED Military Flashlight. Thats why it got multiple colors and strobe mode.

I can’t post apps on the Android | Market, so I will make it avaiable here and in other sites (I will update this post when necessary).

Features:

  • Flashlight mode with white, yellow, green and red lights.
  • Strobe mode with the following patterns: black/white, red/blue (police lights), multi-color, SOS light signal (morse code), beacon light signal.
  • Three strobe speeds, respecting the limits suggested by the WHO to avoid the “pokemon effect” (photosensitive epilepsy). Some strobe styles are not affected by the speed settings.

License and source code:

Lanterna is free software under the terms of GPL v3. I accept donations (PayPal) if you liked the software enough!  =)

The source code, Eclipse project and all the rest can be found at the GitHub hosted repository.

Download:

Lantena.apk

Bugs and ideas:

Lighthouse Bug Tracking

1 Comment »

Programando Androids – Parte 2

Posted: maio 6th, 2009 | Author: coredump | Filed under: Programação | Tags: ,

android_t1

Ferramentas do SDK:

Uma das coisas que eu realmente gostei no SDK do Android é o fato dele ter uma integração muito boa com o Eclipse. Essa integração é tão boa que se me pedirem para criar um projeto Android na munheca é bem provável que eu ABEND e tenha de RTFM. Eu realmente gosto da praticidade de escolher “New -> Android Project” no Eclipse. Além das ferramentas para o Eclipse, existe um bom número de ferramentas para rodar e debugar aplicações, incluindo um emulador muito simpático e funcional.

Estrutura de um projeto Android:

Uma das coisas mais importantes do projeto Android é o arquivo AndroidManifest.xml, que contém a descrição e as configurações básicas da aplicação. Por exemplo, o arquivo descreve todas as Activities/Intents/etc… incluídas na aplicação, além de configurações sobre segurança e acesso a recursos.

O diretório bin/ é onde o binário da aplicação é armazenado depois de compilado, o diretório src/ contém as fontes do programa, os diretórios res/ e assets/ guardam arquivos (recursos) que sua aplicação utiliza, sendo o assets/ utilizado para arquivos estáticos e o res/ para arquivos que são alterados ou usados dinamicamente e finalmente o diretório libs/ onde são colocados qualquer JAR externo que seja utilizado pela aplicação.

O diretório res/ é bem interessante. Existe uma classe automaticamente gerada pelo build do Android que se chama R.java. Esse R.java mapeia o conteúdo do diretório res/ e seus subdiretórios para variáveis acessíveis no código java. Por exemplo, um ícone que está salvo em res/drawable/icon.png pode ser acessado por:

R.drawable.icon

O diretório res/ tem alguns subdiretórios definidos: res/drawable para imagens, res/layout para os XML definindo o layout das Activities, res/menu guardando os XML definindo os Menus, res/raw para arquivos gerais (um TXT a ser incluído, por exemplo), res/values para strings e outros valores a serem referenciados no código e res/xml para arquivos XML em geral.

Produto compilado:

O produto final da estrutura acima é um arquivo .apk, sem assinatura, que pode ser usado em telefones em modo debug e no emulador, um arquivo com seus recursos (do diretório res/) compactados e o AndroidManifest.xml ali no meio também.
Aplicativos Android tem de ser assinados digitalmente para serem distribuídos, isso é feito com o jarsigner mesmo. A versão de debug é assinada com uma chave especial de debug.

Em tempo: os posts seguem a mesma estrutura do livro “The Busy Coder’s Guide to Android Development“. Ótimo livro para iniciantes. O serviço de assinatura dele é legal, você paga 35 dólares e por um ano tem acesso aos PDF’s de todos os livros e atualizações.

No Comments »