Posts de October, 2008

[Emerson Macedo] Quem ama bloqueia

Monday, October 27th, 2008

Quem não se lembra do comercial da Oi sobre bloqueio de celulares que fez bastante barulho?

O bloqueio as vezes faz parte da vida do Desenvolvedor de Software. Em muitas empresas que trabalhei, tive que conviver com alguns. Foram eles:

  • Bloqueio da Internet (Parece mentira, mas trabalhei num lugar onde somente algumas equipes tinham acesso a internet)
  • Bloqueio de Instant Message
  • Bloqueio de email (Não dava pra acessar o Gmail)
  • Bloqueio do Internet Banking
  • Bloqueio de alguns sites (Eu não conseguia acessar alguns blogs importantes)
  • Bloqueio do Telefone (Não dava nem pra ligar pra casa e em algumas empresas nem telefone na mesa tinha)
  • Bloqueio da estação de trabalho (Como que um desenvolvedor que não pode instalar nada no seu computador consegue trabalhar?)
  • Bloqueio da Impressora (Tinha senha especial pra imprimir)

Depois de sofrer bastante com esses bloqueios eu me interessei em saber o motivo que leva muitas empresas a trabalhar dessa forma. Apesar do argumento deles ser furado, vou listar o que eu ouvi de diversas pessoas:

  • Perda de produtividade (segundo eles, as pessoas perdem muito tempo com coisas inúteis na internet e telefone)
  • Falta de foco dos funcionários (Pessoas se desconcentravam facilmente com o IM e outros)
  • Desperdício de recursos da empresa. (Gente imprimindo e usando o telefone demasiadamente)

Depois disso, passei a observar o comportamento das pessoas pra ver como cada um se resolvia com essa série de bloqueios. Eis o que percebi:

  • A ausência da Internet gerava falta de produtividade, pois os desenvolvedores não conseguiam pesquisar algumas coisas, não tinham forum de discussão e não se mantinham atualizados lendo alguns blogs de tecnologia
  • A ausência do Instant Message impedia que um desenvolvedor pedisse ajuda a algum colega que já tenha trabalhado com ele para solucionar um determinado problema.
  • A falta do email fazia com que houvessem notebooks com internet móvel espalhados pela empresa para que o pessoal conseguisse ler seus emails.
  • A impossibilidade de instalação de softwares na máquina do desenvolvedor fazia com que o mesmo perdesse mais tempo que o necessário para resolver determinados problemas.
  • Muitos criaram seu prórpio jeito de burlar isso tudo (Proxys anônimos, senha de admin das máquinas escondido, mais tempo de almoço pra telefonar e imprimir em lan-houses)

E o pior: Essas empresas PERDERAM ÓTIMOS PROFISSIONAIS.

Atualmente eu trabalho numa empresa onde não tem dessas coisas. Aqui nossa internet é totalmente liberada, podemos usar o telefone sem problemas, enviar email a vontade, pagar nossas contas e até mesmo usar o Instant Message (MSN, Yahoo, ICQ, Gtalk), que é considerado por muitos um absurdo.

A conclusão que eu cheguei foi que não importa o que a empresa faça, se o desenvolvedor não quiser trabalhar, ele vai dar um jeito de faze-lo, mesmo que seja burlando as coisas ou simplesmente levando um livrinho e passando o dia lendo na sua mesa.

O que a sua empresa precisa é contratar profissionais de verdade e não pessoas que simplesmente querem um emprego, pois quem quer realmente trabalhar, usa esses recursos a favor da empresa e não contra.

Para aumentar a produtividade e diminuir os custos, recomendo ainda introduzir alguma filosofia de trabalho ágil na sua empresa.

Quem ama não bloqueia !!!

[Danilo Bardusco] Falando em Agile 2008

Saturday, October 25th, 2008

Nos dias 23 e 24 de Outubro aconteceu em São Paulo o evento Falando em Agile.

O evento reuniu grandes nomes do movimento ágil no Brasil para discutir estudos de caso, patterns de adoção das práticas ágeis, presente e futuro do desenvolvimento ágil. Entre os palestrantes estavam: Phillip Calçado, Antonio Carlos Silveira, Guilherme Chapiewski, Danilo Sato, David Anderson e muitos outros.

A pedido de algumas pessoas que viram minha ultima apresentação em Recife sobre a adoção de Scrum na Globo.com, eu repeti a dose, atualizando todos sobre como estamos evoluindo, quais os desafios que estamos enfrentando e quais são os planos para o futuro.

Os slides atualizados estão no slideshare:

ATUALIZADO:
o pessoal da Caelum publicou hoje(04/12/08) o vídeo a palestra:

Como sempre, pra quem assistiu a apresentação o feedback é muito bem vindo, fiquem a vontade para deixar seus comentários.

Reblog this post [with Zemanta]

[Tiago Peczenyj] Fear, uncertainty and doubt

Friday, October 24th, 2008
Fear, uncertainty and doubt (ou simplesmente FUD) não é algo novo. Volta e meia alguma instituição ou candidato a utiliza de forma a enfraquecer o(s) seu(s) adversário(s), geralmente os projetos open-source são vitimas frequentes.

Hoje, no Rio de Janeiro haverá o ultimo debate entre os candidatos a prefeito. Não sou de usar blog técnico como meio de propaganda politica porém não posso ficar de braços cruzados enquanto um candidato utiliza FUD, Boatos e Mentiras. Aqui e aqui vemos alguns exemplos extremamente baixos, que qualquer pessoa com um minimo de instrução deveria perceber. Até quando isso será permitido? E o TRE? E os panfletos apócrifos apreendidos?

Felizmente o outro candidato, cujo partido possui uma cor verde interessante, não responde na mesma moeda pois seria facil usar coisas desse tipo, mas que não acrescentam nada.

Realmente a melhor forma de se proteger do FUD é informando a população, cobrando das autoridades cabíveis e destacando o quão antiético é esse tipo de abordagem. Felizmente cada cidade tem o prefeito que merece.

Comments

ju-ju
Tá na hora de atualizar, né? :)
Tiago Albineli Motta
Muito bom!
Dia 26, vou votar 43!

[Emerson Macedo] O Ventilador e o Pirulito

Thursday, October 23rd, 2008

Faz alguns meses que os gujeiros Rodrigo Yoshima e Carlos Villela blogaram sobre o uso errado da tecnologia numa fábrica de pastas de dentes. Para resolver o problema de caixas vazias que passavam desapercebidas numa linha de produção, a empresa comprou uma ultra-mega-power solução que ainda acabou atrapalhando os trabalhadores da fábrica. Mas os próprios trabalhadores se encarregaram de comprar um ventiladorzinho de 20 dólares e dispensar o mega equipamento.

Quem é Brasileiro e principalmente presenciou as corridas de nossos grandes pilotos de Fórmula 1, provavelmente ainda acompanha a categoria, mesmo que exporadicamente. Eu, criado em uma família muito ligada a esportes, com forte inclinação para F1(por que será que meu nome é Emerson? Alguém consegue advinhar? rs), continuo acompanhando os campeonatos, na esperança de que um brasileiro novamente seja campeão mundial.

Pirulito F1

Eis que no primeiro GP noturno da história da F1 a Ferrari atrapalhou Felipe Massa durante o seu pit-stop com um equipamento ultra moderno que foi desenvolvido para substituir o tradicional pirulito, durante os pit-stops. Esse pirulito foi utilizado por mais de 20 anos e que sempre se mostrou adequado. O novo equipamento fica posicionado em uma altura acima da cabeça do piloto, o que dificulta a visualização em caso de uma nova instrução para parar. O piloto brasileiro perdeu uns 30 segundos pois a mangueira de combustível rompeu-se e sua corrida foi comprometida, inclusive comprometendo a possibilidade de conquiista do campeonato. No pit-stop seguinte, na mesma corrida, a Ferrari voltou a usar o pirulito e no GP seguinte, aposentou de vez a sua engenhoca.

Uma das filosofias que mais gosto para Desenvolvimento de Software nos tempos atuais é KISS. Eu até hoje não sei o motivo de querermos fazer as coisas de forma complicada ao invés de simplificar (eu mesmo já errei muito nisso). Note que simples não significa sem qualidade, mas fazer o suficiente que possa atender a necessidade. As metodologias ágeis da moda como SCRUM / XP falam muito sobre isso. A prática de TDD também tem esse foco, quando prega que devemos fazer o código mais simples possível que atenda a necessidade em questão. E não poderia me esquecer do tão importante princípio de Baby Steps, utilizado em tudo isso que mencionei anteriormente.

Eu sinceramente acho que esse problema é inerente do ser humano e nós é que devemos nos doutrinar pra não cair nessa besteira.

[Guilherme Cirne] Falando em Agile 2008

Wednesday, October 22nd, 2008

Nesta quinta e sexta-feira (23 e 24/10/2008) estarei em SP para o Falando em Agile, um grande evento sobre métodos ágeis. Organizado pela Caelum, contará com palestras de Guilherme Chapiewski, Phillip Calçado, Antônio Carlos Silveira e Danilo Bardusco, entre outros.

Certamente promete!

[Rafael Silva Pereira] Stream Multiplexing for FME Failover in Flash Media Server

Thursday, October 16th, 2008

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

[Rafael Silva Pereira] Stream Multiplexing for FME Failover in Flash Media Server

Thursday, October 16th, 2008

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

[Tiago Motta] Imagem de fundo no captcha gerado pelo simple_captcha

Thursday, October 9th, 2008

O simple_captcha, plugin de geração de captcha para rails, não possui opção para colocar um imagem de fundo na imagem gerada. Mas fazer isso não é nenhum bicho de sete cabeças, basta alterar algumas partes chaves do plugin utilizando um pouco de rmagick. Vou mostrar aqui mais ou menos como fiz isso em um recente projeto.

No arquivo simple_captcha_image.rb basta alterar o método generate_simple_captcha_image para que na criação da imagem seja colocado o fundo desejado. Veja o exemplo de código abaixo:

def generate_simple_captcha_image(options={})  #:nodoc

  fundo = Magick::Image.read(url_da_imagem_de_fundo).first  preenchimento = Magick::TextureFill.new(fundo)

  @image = Magick::Image.new(197, 45, preenchimento) do     self.format = 'JPG'  end

  # ...

Repare que existe ali uma chamada ao método url_da_imagem_de_fundo que no caso é um método que pega o path de uma imagem aleatória. Dessa forma o captcha poderá ter vários fundos diferentes. Veja um exemplo de como pode ser a implementação desse método:

  def url_da_imagem_de_fundo    "#{RAILS_ROOT}/vendor/plugins/simple_captcha/assets/imgs/picture_" + (rand(9)+1).to_s + ".jpg"  end

Foi preciso também comentar a chamada ao método que aplica estilo e distorção à imagem, mas não sei bem se isso é necessário. Como fiz isso, precisei alterar o método append_simple_captcha_code que escreve o texto na imagem, de forma a utilizar diversos tamanhos, posições e fontes diferentes.

[Tiago Motta] Validação no lado cliente com form_remote_tag

Wednesday, October 8th, 2008

Para fazer validações de formulário no lado cliente basta informar ao método form_tag ou ao form_for, utilizando o parâmetro :onsubmit, o código javascript que se deseja executar para validá-lo. Veja no exemplo:

  <% form_tag "/entrar", :onsubmit => 'return valida(this)' do %>      <h1>ok</h1>  <% end %>

Contudo para a tag form_remote_tag e form_remote_for não há a possibilidade de utilizar o parâmetro :onsubmit. Isso porque o formulário gerado pelo rails já possui a ação onsubmit definida com o código que fará o acesso remoto. Para colocar então sua validação antes deste código deve-se usar o parâmetro :before como é mostrado no exemplo:

  <% form_remote_tag :url => "/entrar",         :update => 'meu_div',         :before => 'if( !valida(this) ) return false' do %>      <h1>ok</h1>  <% end %>

Repare que é importante que haja o “return false” no caso de não ter sido validado, caso contrário ele executará o restante do código colocado pelo rails no onsubmit.

[Tiago Motta] Impedindo redeclaração de objetos javascript

Thursday, October 2nd, 2008

Ao importar duas vezes um mesmo arquivo .js em uma página, as funções, protótipos e objetos são redeclarados. Se for necessário que um determinado objeto mantenha seu estado durante as iterações assíncronas dessa página, perde-se este estado na segunta importação do arquivo .js.

Veja por exemplo o objeto abaixo, que nada mais é que um repositório de outros objetos. Tá ta ta, não é um exemplo que tenha tanta utilidade, mas vá lá, é só pra explicar o mecanismo.

var Repositorio = {    sequencia:0,    lista:[],    registrar:function(obj) {        var id = ++this.sequencia;        this.lista[ id ] = obj;        return id;    },       recuperar:function(id) {        return this.lista[ id ];    }}

Agora estando esse código num arquivo por exemplo repositorio.js teríamos o problema relatado com o código a seguir:

<script src="repositorio.js"></script><script>    Repositorio.registrar( new Object() );    Repositorio.registrar( new Object() );</script><script src="repositorio.js"></script><script>    alert( Repositorio.recuperar( 1 ) );</script>

Para impedir essa redeclaração do objeto, e os possíveis erros que ela pode causar, basta tentar utilizá-lo dentro de um bloco try e fazer sua declaração dentro do bloco catch. Ou seja, ele só será declarado caso haja um erro na tentativa de usá-lo. Veja:

try{ Repositorio.existo(); }catch(e) {    Repositorio = {        sequencia:0,        lista:[],        existo:function(){},        registrar:function(obj) {            var id = ++this.sequencia;            this.lista[ id ] = obj;            return id;        },           recuperar:function(id) {            return this.lista[ id ];        }    }}

Mas aí você poderia me dizer: Pô pra que tudo isso, basta não importar duas vezes o javascript. Acontece que se você está criando uma biblioteca para ser distribuída para diversos sites e blogs, você não deve subestimar a “criatividade” dos utilizadores dela. Então, o melhor é se precaver.