I Hack’n Rio

Divulgando – origem: http://www.riojug.org/?p=195

O maior evento de software livre do Rio de Janeiro: I Hack’n Rio

Aproveitando toda força e união que as comunidades de Software Livre têm de promover eventos no estado do Rio, a SL-RJ (Comunidade de Software Livre do Rio de Janeiro), em conjunto com as comunidades ArduInRio, Android In Rio, DojoRio, PHP Rio, PythOnRio, Rio.pm, RioJUG, RubyOnRio e Ubuntu-RJ, vêm apresentar o I Hack’n Rio !

Apesar da palavra “hacker” atualmente estar associada a uma pessoa que explora falhas de segurança em computadores e tenta prejudicar outros, no sentido original da palavra, ela designa alguém que é profundo conhecedor de algum assunto e utiliza maneiras criativas de resolver problemas. Por isso, o Hack’n Rio não é um encontro de usuários malignos de computador, mas sim de profundos estudiosos de computação, mais especificamente software livre, e pessoas que estão buscando este conhecimento.

A idéia do I Hack’n Rio surgiu quando os entusiastas de diversas comunidades de Software Livre se encontravam nos eventos promovidos pelo nosso estado, e sempre chegavam a uma mesma conclusão: está na hora de convergir. Convergir todos os eventos específicos de cada comunidade em um só grande evento, falar e fazer sobre tudo que se vê de novidades em cada tecnologia livre adotada em nosso estado.

O grande diferencial deste evento é que ele está sendo feito por todas as comunidades. E isto quer dizer que não há a centralização de tudo numa comissão organizadora só, mas sim a distribuição da organização. Cada comunidade contribuinte terá seu espaço no evento, para utilizar do melhor jeito que a mesma souber fazer.

O nosso objetivo é realizar um evento de elevado grau técnico onde todos os participantes tenham oportunidade de aprender como as tecnologias livres funcionam a fundo e também como contribuir para sua evolução.

Por isso, planejamos a seguinte estrutura:

  • Quando? 8 e 9 de abril de 2011
  • Onde? Cidade Universitária da UFRJ, na Ilha do Fundão
  • Quantas palestras? 28
  • Quantos mini-cursos? 8
  • E o que mais? Muita mão na massa com 2 salas abertas para hackfests, como Arduino Hack Day!

Você faz parte de uma das comunidades de software livre do estado? Então você também é parte do I Hack’n Rio !

Ajude a tornar o evento um sucesso procurando por patrocinadores, buscando por conteúdo relevante e chamando pessoas que fazem as coisas acontecerem – seja construindo coisas novas, seja contribuindo com projetos já existentes.

Algumas sugestões:

  • Patrocinadores: empresas que usam software livre e querem contribuir para sua evolução; empresas prestadoras de serviço ou desenvolvedoras de softwares livres que querem encontrar talentos para contratarem (as empresas podem até mesmo fazer uma espécie de “O Aprendiz” e oferecer vagas de empregos, se desejarem) e divulgar seu nome e serviços.
  • Conteúdo: não pense só em palestras e mini-cursos, pois isso temos em qualquer evento. Pense em encontros técnicos para correções de bugs ou desenvolvimento de novas aplicações ou novas funcionalidades para aplicações já existentes.

Ubuntu May Replace GDM with LightDM

Yet another possible change in Ubuntu’s core components: they’re mulling over replacing GDM with LightDM. Why? Well: “Faster – the greeter doesn’t require an entire GNOME session to run. More flexible – multiple greeters are supported through a well defined interface. This allows Ubuntu derivatives to use the same display manager (e.g. Kubuntu, Lubuntu etc.). Simpler codebase – similar feature set in ~5000 lines of code compared to 50000 in GDM. Supports more usecases – first class support for XDMCP and multihead.”

Legi, intellexi, condemnavi.

Caberia muito bem a frase do Apóstata Juliano II, para apresentar o Ágil para os gerentes da “escola normal”. Após oito anos trabalhando no desenvolvimento de software de missão crítica e num mundo ágil, ninguém me tirava da cabeça que aquela abordagem poderia de fato ir para o mundo corporativo, área para a qual “me mudei” após o Estado iniciar o processo de sucateamento das Armas.

Pergunto-me frequentemente os tantos “li, entendi, rejeitei” que ouvi ao explicar técnicas ágeis. Veio-me à mente meu próprio passado, onde tantas vezes me fiz um Juliano, quando me apresentavam um VSAM, com suas “trees”, DBase e Clipper e seus DBFs,… rejeitava-os por achar que sistemas de tempo real não combinava com Database (storages) e comecei a ter ojeriza dos coitados, e de fato comecei a usá-los em meados de 1994. Quase dez anos trabalhando em software de controle e automação industrial (PLC, Realtime, microkernel, assembler, C) e o Ágil (XP) era um companheiro, e, acredito piamente que ele nunca me traiu.

Normalmente os testes de missão crítica (sistemas de defesa, reatores nucleares e suporte à vida) são minuciosamente programados e visando o preditivo, que seria algo como “quando acontecer”, em oposição ao “se acontecer”. Normalmente um sujeito (observe que não uso a palavra desenvolvedor) treinado em ágil vai engolir sem mastigar qualquer outra técnica, e por que? Simples, o cérebro do agilista não questiona modelos, ele simplesmente age incondicionalmente; nesse momento todo um organismo, braços, olhos, cabeça, fala, se coordena automaticamente na solução; o agilista não pensa no problema. Um bom agilista sem nenhum esforço, atinge, num momento de crise qualquer um, pois sua abordagem deixa perplexos os observadores e “chama pra dentro” os capazes, todos querem de alguma forma dar sua contribuição, todos querem dar um pouco de si, todos estariam dispostos a sacar fora um pedaço de banha (pigs?) e também a quebrar os ovos (chickens?), afinal a atmosfera é funesta, estamos em risco de vida, ou acerta ou morre… e o tempo é pouco, e as penas vão literalmente pelos ares; comprometimento implícito. Assustados? A narrativa acima aconteceu, e tantas vezes me questiono se outra abordagem não Ágil, me deixaria agora escrever esse.

Ok, esqueçamos o drama ilustrativo e diminuamos a escala de perigo e demo-nos somente os últimos quatro anos, assim a gente começa um cenário Ágil mais ameno, moderno. Continuo afirmando que existe espaço para todos e uma futura convergência é inevitável e já acontece (PMI Ágil), e isso é bom. Isso mostra que estamos sempre errados, já que buscamos sempre uma melhora nesses processos.

Agora a célebre frase seria “li, não compreendi, rejeitei” – e fico triste -, “li, compreendi, fiquei com medo”… do modismo, dessa inferência a olhos vistos?

Ao surgir uma ideia nova que simplifica e funciona, que agiliza, e principalmente porque simplifica e agiliza, encontra uma resistência compreensível, pois implica quase que afirmar a obviedade, e o óbvio é uma coisa muito, mas muito complexa de entendimento. Pior, o óbvio implica uma aceitação de uma cultura, de um novo modus operandi, e isso não é pouco. Absorver uma cultura nova implica em mudança de hábitos, aquilo que nos faz, aquilo que nos identifica, isso é o que nos indica a conformidade, uma aliança, uma aceitação. Ao aceitar, passa-se a compreensão, logo em seguida procura-se os preceitos, para em seguida iniciar o processo de incorporação puro e simples. Agora você acredita, é um converso, faz parte de sua crença, com seus acertos e erros, está “doutrinado”. Incorporado então, ele começa um processo de maturação, e logo em seguida iniciar um processo preditivo individual, ora, isso implica em busca, em pesquisa, em treinos, simulações, ele se prepara para o “quando”.

Agilidade é algo inverso a uma zona de conforto,… por que mudar? As pessoas tendem a associar agilidade com adrenalina, com correria, com sandices e outras aberrações. É o inverso, acreditem. Como dito acima, o preditivo no Ágil, aquilo que era esperado, “quando acontecer”, aconteceu, eu estava preparado, esperando, não foi uma fatalidade… já existia algo, uma carta na manga, esperando o acontecimento, estava em hot stand by, não somente em stand by. O agilista observa o ecossistema, procurando algo que “encaixe” na sua cultura e até incorpora técnicas em artes marciais (dojo, kata), o inesperado é absorvido com impacto reduzido, concentrando esforço não no ataque, mas na defesa, o mais certeiro possível, rápido e preciso.

Aprecio essa pluralidade agilista, com suas adjetividades, que esbraveja jovialidade, criatividade e vontade de mudanças, de sair da mesmice, de um sistema ou modelo completamente comprometido com formalidades. Alguns itens devem ser ajustados ou melhor compreendidos, como o foco nos desejos do cliente, em detrimento à engenharia e arquitetura de software,… estamos focando o cliente e deixando esquecido o desenvolvimento de software? Não espero isso para o Scrum, por exemplo. Acho que alguns itens de qualidade deveriam ser incorporados, como um simples 5S, visando a organização pessoal e do próprio framework ágil. Algumas boas ideias estão se mantendo, outras sendo engolidas ou enquadradas por conjunto de conhecimentos em gerenciamento de projetos (PMI), que é algo mais abrangente em gerência de projetos, enquanto que o Ágil (quase) se limita ao desenvolvimento de software, apesar de ter raízes no Lean.

As vezes penso que o mal maior do agilista é o entusiasmo pela “religião” que ele agora é um converso e, qualquer afobação gera desconfiança para seus reais resultados. Também espero que essa exposição demasiada do Scrum não o deixe tão extasiado, levando-o a sucumbir sob o peso da própria agilidade, que é afinal, seu grande mérito. Leia, compreenda, aceite-o, mas deixe alguma água no poço, mostre-o como uma alternativa.

Wooof!

Como o Java recebeu esse nome?

De: James Gosling
Data: 24 de Agosto de 2007 – 20:16:58
Para: Jonathan Schwartz
Assunto: Como o Java recebeu esse nome?
A história é a seguinte:
Nós precisávamos de um nome. Estávamos usando “oak” (que eu escolhi randomicamente), e embora o time tenha se apegado e ele, os advogados responsáveis pelo registro de marcas o descartaram. Tivemos muitos debates por email sobre nomes, mas nada era resolvido. Acabamos na estranha posição em que a única coisa que nos impedia de fazer o lançamento era o nome. Nosso líder de marketing conhecia alguém que era um “consultor de nomes” (eu não lembro o nome dele, mas ele era ótimo). Nós não podíamos pagar o preço nem tínhamos tempo para fazer um processo completo de criação de nome de produto. Ele concordou em fazer algo bem atípico, mas efetivo e rápido: ele atuou como um facilitador em uma reunião onde uma dúzia de nós nos trancamos em uma sala por uma tarde. Neste momento ele começou perguntando questões como “Como esta coisa faz vocês se sentirem?” (Animados!) “O que mais faz com que vocês se sintam assim?” (Café, Java!*). Chegamos a um quadro coberto de palavras aleatórias. Então, ele nos conduziu em um processo de ordenação onde finalizamos com um ranking de nomes. Acabamos com uma dúzia de nomes candidatos e os enviamos para os advogados: eles trabalharam na lista de cima para baixo até que chegaram a um nome que passou pela pesquisa deles. “Java” era o quarto nome na lista. O primeiro nome era “Silk”, que eu odiei, mas todos os outros gostaram. Meu favorito era “Lyric”, o terceiro na lista, mas ele não passou pelo teste dos advogados. Eu não lembro quais eram os outros candidatos.
Então, quem deu o nome Java? Uma reunião organizada pelo marketing, o consultor que a organizou, e um monte de nós gritando várias palavras aleatórias. Eu honestamente não tenho certeza absoluta de quem disse “Java” primeiro, mas acredito que tenha sido Mark Opperman.
Com certeza não foi nenhuma mente brilhante de marketing usando um processo coerente e bem pensado.
* “Java” é uma gíria norte-americana para café (NT).

Google dá resposta nerd a crítica de Steve Jobs ao Android

Uma das principais características alardeadas pelo Google para o Android é sua plataforma aberta e baseada no Linux, facilitando aos programadores a criação de aplicativos. No entanto, Steve Jobs – executivo-chefe da Apple – fez críticas à mesma em uma teleconferência realizada nesta semana.

Andy Rubin, chefe da divisão Android, inaugurou seu perfil no Twitter em 18 de outubro com uma resposta à crítica de Jobs. Sua mensagem foi enviada em forma de uma sequência de comandos que equivalem à cópia do Android para sua máquina Linux e sua compilação na sequência, deixando-o prontinho para rodar.

Para quem ficou curioso, veja a sequência citada por Rubin:

mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make