Nesta semana que passou estive na RubyConf Brasil. Um excelente evento, sinceramente eu não tenho nada a reclamar, só tenho elogios para o Fábio Akita e a Locaweb (na verdade 2 palestras me incomodaram, mas isso não tem relação com a organização).

Apesar do evento ter sido fantástico sempre existem reclamação. E este ano a reclamação ficou em dois pontos, wifi inexistente e projetores.

Reclamando do WIFI

A primeira reclamação eu acho totalmente sem sentido, já que o único motivo para eu ir aos eventos é assistir palestras e conversar com as pessoas. Internet eu tenho no escritório e para urgências o 3G do meu iPhone atende perfeitamente.

Eu não consigo prestar atenção em duas coisas e notebook/ipad durante as palestras me distrai. Por isso já nem levo notebook mais quando não vou palestrar. Então não dou a mínima para internet e sinceramente acho que os eventos já deveriam anunciar que não vai ter internet, assim ninguém reclama.

Reclamando dos Projetores

Os palestrantes reclamarem dos projetos acho que faz um pouco de sentido, mas só um pouco.

Seria muito legal a organização deixar tudo regulado mas qualquer palestrante sabe que organizar um evento é um trabalho colossal e se você quer que sua palestra corra bem não é bom depender de pontas que a organização pode ter deixado passar (isso é totalmente aceitável e esperado).

Mais uma vez: não culpe a organização pelo projetor, culpe a si mesmo. Em um evento o mais importante é ter gente na platéia (quanto mais melhor) e o projetor é uma coisa mínima. Você se propôs a palestrar, então deve ter um plano de contingência para essas situações.

Acho que nos últimos 3 anos acumulei algumas horas de palestras e também umas 300 horas de aula. O legal (ou nem tanto) é que deu tempo para muita coisa dar errado e algumas darem certo.

Meu amigo Carlos Eduardo da e-Genial sabe como a minha primeira aula de Flex em 2007 foi ridícula, um fiasco total (obrigado por não ter me demitido de imediato .

Então aprendi algumas coisas que tento seguir em meus cursos e palestras. Talvez isso possa ser útil para você também.

Palestras/Aulas Online

Uma palestra presencial é completamente diferente de uma palestra online.

Online você tem mais controle do seu ambiente e não depende de microfone e projetor. Assim você pode usar qualquer cor nos seus slides e tudo vai aparecer perfeito (isso se a ferramenta for boa como o Treinatom).

Por outro lado aprendi quem em eventos online você tem que falar bem mais e com muito menos pausa que eventos presenciais, do contrário as pessoas começam a ficar cansadas (nesse caso, é melhor você ficar cansado do que a platéia).

Não cometa erros online. Um erro online tem uma proporção muito maior e sua credibilidade vai pelo espaço muito mais rápido. Cinco minutos encontrando um bug ao vivo não parece nada, online é uma eternidade.

Palestras Presenciais em Eventos

Ao presencial as coisas são bem diferentes e como não é possível ter controle nenhum do ambiente sempre tomo alguns cuidados.

A primeira coisa é a resolução, raramente encontro projetores com resolução de 1024 ou superior, então sempre uso 800×600 nos slides.

A segunda coisa é a calibragem do monitor. Sempre que plugo meu Mac no projetor vou em System Preferences/Displays/Color escolho o sugerido pelo S.O. (as vezes ajusto manualmente o perfil também).

A terceira coisa é em relação ao contraste dos slides. Como você não tem controle da iluminação é bom criar seus slides com bastante contraste entre o conteúdo e o fundo. Não precisa tirar os efeitos e usar slide branco com texto preto, só cuidar do contraste. Sempre uso dezenas de transições, efeitos e as vezes desenho meu próprios ícones para os slides mas fico atento para que o conteúdo contraste bastante do fundo.

A quarta coisa que sempre tomo cuidado é com a centralização. Nunca espero que o projetor esteja alinhado (nunca está), então coloco tudo centralizado. Se vai ter código coloque-o em um box mais para o centro do slide. A mesma coisa para vídeos, deixe-os centralizados.

Use fontes grandes no seu código, com fundo branco e texto com muito contraste. Eu também uso o Copy as RTF no Textmate para colar código no Keynote.

Outra coisa é que não importa o que aconteça, em um evento grande eu não passo do tempo de forma alguma. Acho uma falta de respeito um palestrante atrasar o evento todo porque não preparou sua palestra direito (a final de contas foi você aceitou o convite ou enviou uma proposta).

Para evitar problemas com tempo eu sempre uso o “Presenter Display” do Keynote do Mac. Nele você vai ver o próximo slide e o tempo gasto (acho isso fundamental).

Caso você plug seu Mac e não apareça “Presenter Display” basta ir em System Preferences/Displays e “des-espelhar” os monitores. Se os monitores ficarem trocados bastar arrastar o menu para o que você deseja que seja o primário (como abaixo).

Live Coding

Live Coding é um caso a parte pois é uma fonte gigante de problemas. Parta do princípio que você vai errar tudo ao vivo, mesmo que seja o criador do Rails você vai errar uma demo com ele!

Nas aulas online eu sempre tenho um guia para seguir. Em aulas presenciais normalmente levo um papel e coloco em cima da mesa, não tem nada de errado em levar um cola. Mas não escreva uma bíblia na cola pois você se “ferrar” da mesma forma, a cola é para você saber a ordem do que fazer e não para aprender as coisas ao vivo.

Abaixo a minha cola para o curso de 6h do Fisl:

Se for uma palestra de 50 minutos então não faça live-coding, prefira um vídeo. Você não vai querer atrasar o resto da sua palestra se demorar de mais em algum ponto do código.

Para gravar os vídeos eu uso o ScreenFlow e gravo com voz. Depois removo a voz e refaço o vídeo algumas vezes, dessa forma vou saber exatamente a ordem das coisas no vídeo.

Caso você não tenha como gravar um vídeo então treine o que será mostrado várias vezes. Não tem nada mais frustrante do que cometer um erro para um auditório que não te conhece.

Palestras são diferentes de aulas e a por padrão a platéia é totalmente cética com você e com o seu tema. Você precisa ser convincente, se passar um bug e não conseguir resolver (rápido), vai pairar aquele pensamento de “hehehe, se F*eu” ou “iiih, isso não é lá grandes coisas”.

Outra coisa que é muito importante em live-coding é o tema do seu editor, como eu já disse anteriormente. Use sempre fundo branco mas caso você tenha feito um vídeo e mesmo com fundo branco e fonte grande não tiver dado certo tente inverter as cores com Ctrl+Option+Command+8.

Síndrome da Faculdade

Em computação não tem nada mais comum do que pessoas tendo se mostrar inteligentes. Ninguém vai assistir uma palestra querendo saber como você é inteligente e “bomzão”. Ninguém quer saber se você sabe 20 linguagens ou sabe “zilhões” de termos técnicos. Você não tem que se mostrar inteligente para um professor.

Não digite “zilhões” de coisas rápido de mais, não faça scroll do código para cima e para baixo, não grite ou fale correndo de mais. Se vai digitar algo ao vivo explique cada coisa que está digitando e com bastante calma, a final de contas você sabe o que está fazendo mas as pessoas não.

As pessoas assistem uma palestra para aprender algo e não estão nem aí para o que você é. Então foque em ensinar alguma coisa.

Nessa última RubyConf a palestra do Norman Clarke me deixou de queixo caído como ele conseguiu explicar um tema complexo como encoding como se fosse um “Hello World”. Parecia que ele tinha conseguido abrir a minha cabeça e colocar as palavras no local correto. Uma aula de como priorizar os ensinamentos.

Você não precisa falar dezenas de termos técnicos difíceis para ser convincente. Assuma que as pessoas sabem muito pouco do que você está falando, assim os que já sabem algo vão entender e o que não sabem também.

O que é mais agradável e convincente?

• Nosso MP3 Player vem com 2gb de RAM e sincroniza com seu computador via USB
• “O mais legal do iPod é que sua playlist inteira cabe em seu bolso.” – Steve Jobs 2001

Treine Antes

Não importa o quanto você domine o tema, pratique antes. Várias vezes, eu normalmente ensaio uma palestra de 50 min umas três vezes. Essa é a única forma de saber quanto tempo você gasta com esses slides e como pode enxugar as coisas para ajustar o tempo, caso seja necessário.

Não me venha com o papo de que treinar não dá certo para você. Se Steve Jobs treina seus Keynotes exaustivamente e Michael Jackson ensaiava suas próprias músicas centenas de vezes não caia no erro de achar que você não precisa ensaiar.

Conclusão

Meu checklist:

• Não confie no projetor
• Não confie na iluminação
• Não confie em mic’s (as vezes vai ter que ser no gogó mesmo)
• Leve sua própria garrafa d’água (as vezes não tem)
• Centralize o conteúdo dos slides
• Use conteúdo bem contrastado do fundo
• Ajuste o perfil do projetor
• Use código com fundo branco e fonte grande
• Prefira vídeos ao invés de live-coding
• Em cursos faça muito live-coding mas tenha um rascunho
• Ensaie antes várias vezes
• Use “Presenter Display” do Keynote
• Explique as coisas com calma e fale devagar se forem coisas técnicas

Eu não sou nenhum expert e nem um Steve Jobs mas essas coisas tem me ajudado a fazer minhas palestras e aulas não serem um completo fiasco. Talvez possam te ajudar.

E da próxima vez não reclame da organização, esteja preparado para tudo dar errado. Se estiver tudo perfeito então melhor ainda.

“A maré passou mas ainda há tempo para um cafezinho.”

Venha participar do primeiro Café Ágil em Belo Horizonte!

1. Programação

Cafe da manha: 8:30am – 9am
Palestra 1: 9am – 10am
Palestra 2: 10am – 11am
Palestra 3: 11am – 12pm
Coding Dojo : 12pm – 1pm

2. Palestras

Leia mais no post original aqui

A e-Genial está movimentando mais um evento on-line, será um mega evento de Ruby e desta vez eu também estou ajudando a dar uma mão na organização.

Para nós acertarmos o máximo possível e agradar o maior número de interessados precisamos da sua ajuda. Por favor respondam o rápido questionário abaixo, os resultados nos ajudaram a definir a grade, horário e etc.

http://bit.ly/eventoruby

E ajudem a divulgar para o máximo de pessoas também. Obrigado

É com enorme satisfação que informo que a RIA Labs firmou uma parceria com a E-genial para ministrar cursos online de desenvolvimento web. O primeiro fruto dessa parceria é o Curso Expresso de Flex Frameworks (http://www.egenial.com.br/swizmate), que será ministrado em dois sábados (dias 23 e 30 de Outubro de 2010). Algumas informações adicionais: Treinamento 100% [...]

Este ano, na Egenial, foram abertos vários cursos voltados ao mundo Ruby.

Um destes cursos foi Imersão Ruby on Rails. Como já trabalho em parceria com a e-Genial a mais tempo, o Carlos Eduardo (proprietário da empresa) me convidou para ser o responsável por criar este novo curso e a partir de então ficar apenas com esta nova turma.

Depois de pensar bastante, cheguei a conclusão que a melhor opção seria eu ministrar tanto o curso do básico ao avançado como o imersão. Apenas desta forma eu teria controle total de tudo que é necessário para um interessado em Rails entrar com pé direito na tecnologia e em seguida entender com precisão as internas da linguagem Ruby

Como é um curso intensivo com apenas 4 dias com 4 horas por dia (nos sábados), depois que o material estivesse pronto, eu não ficaria sobre-carregado administrando duas turmas e os iniciantes de Rails poderiam seguir a mesma linha de aprendizado deste o início, com o primeiro curso, e se aprofundarem nas internas da linguagem com este segundo. Por estes motivos, atualmente, sou instrutor do curso do Básico ao Avançado e do Imersão.

Durante a preparação da grade e do material eu tentei agrupar todos os temas que considero essenciais para um Rubista. Mas temas que não são tão triviais de se aprender.

Tentei compilar o conhecimento que não aprendemos em blogs ou palestras de 50 minutos. Assuntos como Object Model da linguagem que não vemos em muitos livros mas que são fundamentais para aplicar da forma correta metaprogramação ou para entender, de verdade, técnicas simples como “class << self”.

Outros temas importantes que tentei abordar neste novo curso são por exemplo a influência de dsls no cotidiano (e como criar dsl’s), refactoring (na prática melhorando um pequeno projeto em Ruby puro coberto com MiniTest), boas práticas de Rails como arquitetura rest para organização ao invés de criar API’s, design SOLID e criação de Gems.

Grade com detalhes

É bem provável que esta seja a última turma deste curso para 2010 então corra e faça sua matrícula. A grade do curso detalhada você pode ver abaixo (ou no próprio site do curso):

1. Ruby Object Model
   1. A verdade sobre programação orientada a objetos
   2. Os segredos para identificar o “self”
   3. Method Lookup
   4. Superclass e Metaclass
   5. Eigen Class ou Ghost Class
   6. A verdade sobre o que são classes
   7. Métodos de classe não existem
   8. A verdade sobre os módulos
   9. Usando módulos da forma correta
2. Metaprogramação
   1. Mágica é para os fracos, entenda o que é metaprogramação
   2. Importância da reflexão
   3. Compreendendo o que são e as diferenças entre blocos, proc e lambda
   4. Entendendo corretamente o escopo e como alterar o self
   5. Família “eval”
   6. Classes Abertas
   7. Criando métodos em runtime
   8. Criando classes em runtime
   9. method_missing
   10. Hooks do Ruby
   11. Exemplos reais sobre metaprogramação
3. Ruby DSL’s
   1. Entendendo o que são DSL’s
   2. DSL’s internas em Ruby
   3. Importância de DSL’s para melhor o design do software
   4. Técnicas mais comuns para criação de DSL’s
   5. Exemplos práticos de DSL’s (ex.: Whenever, rotas do Rails, delayed_job e etc)
4. Ruby best pratices
   1. Como diferenciar um bom design e de um ruim
   2. Evitando erros comuns em manutenção
   3. Aprendendo conceitos de um design S.O.L.I.D)
   4. Refactoring na prática (usando Ruby 1.9 e MiniTest)
   5. Forwardable
   6. Delegate
   7. Comparable
   8. Enumerable
   9. Parâmetros nomeados
   10. Expressões condicionais
   11. Convenções do Ruby
5. Rails Best Pratices
   1. Boas práticas em desenvolvimento Rails
   2. Como organizar sua aplicação pensando no futuro
   3. Restful como ferramenta de design e não apenas para API’s
   4. Refatorando controllers
   5. Refatorando Views
   6. Refatorando Models
6. Rails Best Pratices
   1. Controllers magros
   2. Models gordos
   3. Single Responsibility em Models
   4. Princípio do menor conhecimento
   5. R.E.S.T para arquitetura de software
   6. Rotas saudáveis
   7. DRY com metaprogramação
   8. Módulos para repetição
   9. Composição
   10. Callbacks em Observers
   11. Índices em Migrations
   12. Alimentação do banco com Seeds
   13. Sempre mantenha um rollback em Migrations
   14. Separação de lógica das views
   15. Técnicas avançadas com partials e layouts
   16. Refatorando forms com FormBuilders
7. Gems
   1. O que são realmente Gems
   2. Erros graves ao escolher uma Gem
   3. Como ler uma Gem
   4. Importância de se criar Gems
   5. Criando uma Gem na prática

Não, isso não é um anúncio da Embratel. Estou me referindo ao Curso de Mockup da e-Genial, confiram só: http://www.egenial.com.br/mockup

Todo mundo sabe que eu não tenho aptidões para design (essa arte de escolher cores, bordas, etc) não é minha praia, definitivamente. Sou um #soudev “nato” que gosta de código, mas reconheço a importância do papel de um Designer na nossa área e, também, do Arquiteto de Informação (aquele que é responsável em projetar as áreas que irão compor nossa view, além de outras coisas).

Como nem todos tem condições de dispor desses profissionais em suas equipes – ou ainda assume ‘broncas’ como freelancers  – acabam apelando para o estilo MacGyver (o faz tudo), é importantíssimo que você faça esse curso!

Esse curso não irá te ensinar a usar o Balsamiq muito menos irá te ensinar a usar o Fireworks, o que esse curso irá te auxiliar no processo de desenvolvimento de produtos desde a concepção da ideia até o lançamento.

Portanto, se você é um #soudev – ou até mesmo um empreendedor – que está cheio de  idéias legais mas não sabe como preparar o lançcamento dela na rede, aproveita esse curso e faça sua matrícula, porque vamos falar sério né?! Tá barato pra Caramba!

PS: Se vc não tem idéias legais, faça o curso também, quem sabe não aparece uma depois, heim?!?! =)

[]s

Neste segundo semestre do ano estamos tendo vários eventos com temas focados em Ruby ou eventos genéricos mas com espaço para a linguagem.

Apenas em Julho e Agosto tive o prazer de participar de 6 desses eventos. Uma coisa fica bastante claro, o interesse por Rails tem crescido assustadoramente.

Quando comecei a estudar a linguagem Ruby e framework Rails por volta de 2006 era comum ouvir que Ruby/Rails eram apenas modinhas e que logo isso tudo morreria.

Hoje é muito gratificante ver que esta “modinha” evoluiu para algo bem sólido no mundo todo e aqui no Brasil estamos começando a conseguir o mesmo resultado.

Isto fica bem nítido quando participamos dos eventos e vou compartilhar com vocês um pouco de como tem sido participar deles :

Mini-curso do RailsMG na UNA

Mensalmente fazemos encontros do nosso grupo, o RailsMG. Até entao nao tknhamos feito nada voltado para o publico que está interessado em começar no Ruby e no Rails.

Pensando nisso aplicamos um mini curso no meio de Julho onde eu fui o instrutor. O local para o treinamento foi cedido pela UNA e com lotação aproximada de 60 pessoas.

No esperávamos chegar perto da lotação mas o mais impressionante é que as 60 vagas foram preenchidas em menos de 5 horas.

O curso correu perfeitamente e foi bem interessante para conhecer várias pessoas de BH que tem interesse na tecnologia e mostrar um caminho por onde começar.

Os slides podem ser vistos aqui

FISL

No final de Julho, com um convite Maúricio Portal, tive o prazer de participar do FISL em Porto Alegre. Também um mini-curso mas desta vez com 6 horas (ao invés de 4 como o do RailsMG).

O curso foi quebrado em três dias com 2h por dia. No primeiro dia tivemos lotação máxima no auditório e o pessoal participou bem, com várias perguntas. O receio era que nos dias seguintes talvez o interesse diminuiria, mas isto não ocorreu e tivemos o auditório cheio nos 3 dias.

O mais interessante é que no último dia tivemos 6 horas de palestras de Ruby. Começamos com uma apresentação perfeita do Fábia Akita sobre o ecossistema Rails. Mostrando que Rails não é apenas um framework mas um plataforma sólida, focada em empreendimento e que caminha sozinha sem investimento de nenhum gigante como MS ou Oracle.

Na sequência tivemos mais uma palestra do Akita sobre boas práticas de desenvolvimento web usando a ferramentas do Ruby como exemplo. Para terminar o dia eu concluí com as duas horas restantes do mini-curso.

O resumo geral do FISL foi sensacional, vários contatos interessantes e deu para rever muita gente da comunidade Ruby e fazer aquele pós evento com direito a hora extra original com o pessoal do Rio.

Os slides do Mini-curso estão aqui.

EDTED BH

Em Julho recebi um convite da Arteccom para o EDTED de BH. O tema seria uma introdução ao Rails mas como evento coincidiu com o OxenteRails e eu já tinha confirmado com a organização do Oxente acabei não podendo comparecer ao EDTED (infelizmente).

Mas não podíamos deixar o EDTED sem uma palestra de Rails então Bruno Alves da Dito aceitou convite e a palestra parece ter sido um sucesso ( já era o esperado vindo do Bruno .

OxenteRails

Sobre o Oxente Rails, em Natal, não tenho palavras suficientes para descrever o evento.

Acabei indo de última hora e também não tinha comparecido no ano anterior então eu não sabia muito bem o que esperar.Mas o evento superou todas as expectativas possíveis. Extramente bem organizado e com palestrantes de auto nível.

O evento correu em duas trilhas paralelas e eu imaginei que não teria audiência para lotar os dois auditórios mas foi o contrário.

Foi bem legal para reencontrar a comunidade toda e conhecer pessoas como Caike da Envylabs, Geoffrey do Peepcode, Arthur Geek e várias outras pessoas que não vou me lembrar agora.

Quantos as palestras, pessoalmente gosto mais de conteúdo técnico e nesta linha as que me chamaram mais antenção (das poucas que assisti) foram as do Caike sobre refactoring e a do Geoffrey sobre sugestões de arquitetura em Rails.

Eu falei sobre Steak e você pode ver os slides neste link

Sobre o oxente eu só tenho a agradecer ao Paulo Fagiani, Annaysa e toda a equipe da Tink (Rafael, Anderson, etc). E claro não posso esquecer do Vinicius Teles por me fazer abrir o olho e enviar um tema para o evento e não deixar a oportunidade passar.

<iframe src=”http://player.vimeo.com/video/14350633?byline=0&amp;portrait=0&amp;color=b30000″ height=”304″ width=”540″></iframe>

Definitivamente o evento mais importante de Rails do Brasil (já que Rails Summit virou RubyConf .

Serpro

Duas semanas após o Oxente eu ministrei uma apresentação sobre o ecossistema Rails no Serpro MG a convite da Kátia, Alexandre e Harley (mais uma vez obrigado aos três).

Para o conteúdo eu usei boa parte da palestra que o Akita usou no FISL (com autorização dele). É um conteúdo que acho perfeito para dar uma visão geral de como caminha a comunidade em volta do Rails.

Os slides da palestra você encontra aqui

Próximos eventos

Durante este meio tempo também concluímos um treinamento da Egenial com 40 alunos e houveram vários eventos que não tive como comparecer. Destaque para o RSonRails e o encontro do pessoal do Rio.

Nos próximos meses vamos participar do seminário de “computação da UFOP” e também teremos uma palestra de Ruby na Inforuso, que está sendo organizado pelo Márcio Sete. Também não dá para esquecer do encontro de sábado agora (amanhã) do RailsMG.

Conclusão

Com todos esses eventos acontecendo e com o resultado fica bem claro que o interesse por Ruby no Brasil está começando a explodir agora.

Outra coisa que percebi é que mesmo com tantos eventos este interesse crescendo, são poucos os desenvolvedores mais experientes. Então é muito importante que os organizadores de evento tenham isso em mente.

Apesar de nós que trabalhamos como Rails a bastante tempo querermos eventos mais pesados e com conteúdo mais avançado, somos a minoria e qualquer evento no Brasil que carregue Ruby ou Rails no nome deve lembrar-se do iniciantes ao menos em algum momento na grade.

Além de introdução ao Ruby e ao Rails também é importante introdução a temas como TDD, Git, automatização de deploy e tudo mais que já é cotidiano de desenvolveres Ruby.

Nos vemos na Ruby Conf

Em duas semanas a Egenial dará inicio a um novo curso, um treinamento para empreendedores chamado de Mockup.

Você sendo proprietário do seu negócio ou mesmo trabalhando como contratado em uma empresa precisa ser um empreendedor.

Mas o ponto mais atrativo para nós desenvolvedores é que como o próprio nome diz somos profissionais com o objetivo de construir algo. No entanto muitas vezes ficamos presos em tecnologias novas e desafios técnicos que na verdade não interessam muito para o produto final.

Ter a visão de colocar as coisas em prática independente da tecnologia é muito importante tanto para um funcionário de uma empresa de software ou um fundador de uma startup aplicando uma nova idéia.

Mesmo já estando com a faca e queijo na mão e na grande maioria das vezes habituados ao desenvolvimento para clientes, criar um saas ou produto qualquer envolve muito mais coisa.

Vou citar um exemplo: a parte técnica central do Cifras foi desenvolvida em pouco mais de um mês incluindo o design. É o tempo normal para desenvolvimento de um projeto para um cliente também.

Mas o que não é perceptível a primeira vista é o que está por trás do sistema. Por exemplo existe um painel administrativo que foi sendo evoluído com base nos problemas e necessidades (ver quais usuários pararam de acessar, inadimplentes, bloquear contas, etc).

Além disso também temos todo o sistema de automatização de deploy, backups e servidor de homologação.

Também temos o site público que envolve o sistema de suporte através de FAQS criados por um CMS (cada pedido de suporte que chega mais de uma vez acaba sendo convertido em um FAQ por outro painel administrativo).

Claro ainda existem outra decisões como formas de marketing, análise de mercado, melhores formas de suporte, burocracias com formas de pagamento e etc. Além de saber filtrar sugestões alinhadas com as prioridades do produto.

Ao ter uma ideia interessante normalmente você acaba esquecendo todas estas decisões importantes e que tornam a criação de um produto um trabalho colossal.

Acredito que este curso o ajudará bastante a ter uma visão completa para criar uma solução prática e por apenas R$120,00.

O Flash revolucionou o distribuição de conteúdo de video na web, temos o Adobe Flash Media Server que ajudou com isso dando a possibilidade distribuir o conteúdo via stream, inclusive com a opção de usar criptografia e recursos de DRM(Digital Rights Management).

O Flash revolucionou o distribuição de conteúdo de video na web, temos o Adobe Flash Media Server que ajudou com isso dando a possibilidade distribuir o conteúdo via stream, inclusive com a opção de usar criptografia e recursos de DRM(Digital Rights Management).

O Adobe Flash Media Server 3.5 e o Flash Player 10 trouxe algumas novidades, dentre elas a possibilidade de se usar o recurso de Dynamic Streaming para distribuição de conteúdo.
Imagine o seguinte cenário, você usa uma internet 3G limitada(meu caso ), você esta feliz e serelepe vendo um vídeo e nota que do nada, o video começa a travar, sendo que você já usou toda sua banda disponivel e agora so pode usar a minima que a operadora oferece. Outro cenário é de que um mesmo vídeo pode ser visto tanto via desktop ou por algum dispositivo mobile como smartphones, que possuem pouca memória, poder de processamento e tela menor. O Flash Media Server pode dependendo das condições da rede ou recursos do cliente, trocar o conteúdo(Audio, video ou ambos)por um que melhor se adapte as condições atuais do cliente, assim garantido o QoS(Quality of Service).

O Flash Media Server pode dependendo das condições da rede ou recursos do cliente, trocar o conteúdo(Audio, video ou ambos)por um que melhor se adapte as condições atuais do cliente, assim garantido o QoS(Quality of Service).

Dynamic Streaming ajuda a garantir o QoS(Quality of Service)

A Adobe recomenda que você use dynamic streaming quando encontrar os seguintes criterios:

• Video com longa duração.
• Video com tamanho grande.
• HD video.
• Video com dimensões grandes, como um video que precise rodar em fullscreen.
• Conteúdos distribuídos para os usuários que são mais suscetíveis a problemas de largura de banda, tais como usuários domésticos, ao invés de usuários corporativos

QoS – Quality of Service – Em redes de comutação de pacotes refere-se à garantia de largura de banda ou, como em muitos casos, é utilizada informalmente para referir a probabilidade de um pacote circular entre dois pontos de rede. Fonte: Wikipedia.

Veja em detalhes o uso de dynamic streaming na documentação da Adobe.
Veja também esses dois artigos do devnet com os fontes disponiveis para download:

• Live dynamic streaming with Flash Media Server 3.5
• Dynamic streaming in Flash Media Server 3.5 – Part 1: Overview of the new capabilities

Se você esta procurando algum livro sobre Flex e Flash Media Server, recomendo Flex 3 + Flash Media Server 3.5 do meu amigo Carlos Eduardo

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.