
Já não me lembro de quantos artigos li a respeito deste tópico de hoje, que trata da Falha na Comunicação entre pessoas dentro de uma organização ou empresa, mas com certeza são muitas dezenas. E não há o que discutir: Falha na Comunicação pode trazer grandes conseqüências, tais quais o aborrecimento, a perda de tempo, de dinheiro e de credibilidade.
Falha de comunicação = Desperdício de Dinheiro
Singularidade: Ficção? Não, Realidade!

Talvez ao terminar de ler este post você possa pensar que tudo não passa de uma tremenda balela, ficção ou algo sem nenhum sentido. Respeito a opinião e as limitações de compreensão de cada pessoa, assim como respeito o pensamento criativo de muitas outras, porém o que expresso neste texto a seguir, reproduz tacitamente aquilo em que acredito e confio que acontecerá, ou melhor, que já está acontecendo!
Trata-se da Singularidade Tecnológica, o que para muitos não passa de um conceito ou teoria, mas que para mim é PURA REALIDADE.
Vernor Steffen Vinge, um cientista da computação, ex-professor de matemática da Universidade Estadual de San Diego, autor de vários livros premiados sobre ficção científica refere-se a Singularidade Tecnológica da seguinte maneira:
"Com o avanço da tecnologia, em um futuro próximo, criaremos - ou nos tornaremos - criaturas que ultrapassem os seres humanos nas dimensões intelectual e criativa. Eventos que vão além disso, são tão inimagináveis para nós quanto uma ópera é para um verme."
Vamos a algumas poucas considerações iniciais para então, no decorrer do texto, entendermos essa tal Singularidade:
- Só depois de 1.943 anos da era crsitã (DC) é que o primeiro computador, chamado de ENIAC, começou a ser projetado na Universidade da Pensilvânia. Era composto por 18.000 válvulas, 15.000 relês e emitia o equivalente a 200 quilowats de calor;
- No início dos anos 60 nascia um projeto militar americano chamado ARPANET que mais tarde evoluiu e se tornou a Internet que conhecemos atualmente;
- 28 anos depois do ENIAC, nascia o primeiro micro-chip, criado pela Intel, o Intel4004, no ano de 1971;
- Muito mesmo antes da década de 70 terminar ou a de 80 iniciar, nasciam os primeiros computadores pessoais, período este que foram criados o Apple II, o TRS 80 da Tandy ou ainda o Zx 80 da Sinclair;
- A partir de 1.985 a Internet começou a tomar impulso e começou a sua jornada para se tornar a grande rede que conhecemos hoje;
"A humanidade está prestes a testemunhar uma das maiores transformações históricas que irá transceder o modo como vivemos, pensamos e conhecemos a vida".

Os aparelhos que conhecemos hoje não serão nem de perto parecidos com o que usaremos no futuro, pois a Nanotecnologia permitirá que os aparelhos tomem formas diversas, mudem de cor instantâneamente e se pareçam como quisermos, a exemplo disto, nos dias de hoje há experimentos com aparelhos de celular que usam a Nanotecnologia, que mudam de forma e cor de acordo com uma bolsa de uma mulher. Veja um vídeo conceito sobre o aparelho aqui.
Ficção ou Realidade?
Minha narrativa acima quanto ao que penso sobre o futuro da tecnologia em nossas vidas até parece um roteiro desses filmes, ai pergunto: Haveria alguma razão para muito do que vimos nesses filmes não se tornar realidade? Para mim, razão nenhuma. Se analisarmos o que já vimos em filmes como na série 007 com James Bond, usando toda uma coleção de aparatos tecnológicos que se transformaram em realidade, podemos pensar que alguns desses filmes são apenas a ilustração daquilo que está por vir.

Os jovens de nossa geração, que se tornarão os cientistas e pesquisadores de amanhã, tem nas mãos a oportunidade de participar e fazer parte das transformações da nova era tecnológica e poderão entrar para a história.
As transformações pelo qual passaremos então, também abrirá portas para novas oportunidades e negócios no mundo todo, gerando bilhares e bilhares de dólares, euros ou seja lá a moeda que for, em lucros para as corporações que se anteverem e enxergarem tais oportunidades. Não posso deixar de citar também que muitos aproveitarão das oportunidades e possibilidades e irão buscar o poder, a possibilidade de ser superior a outras pessoas, de tirar proveito da fraqueza dos menos capacitados na época, prática comum do ser-humano.

Tanta evolução, tanta novidade e tantas mudanças não trarão apenas grandes benefícios, mas também grandes problemas a serem enfrentados, e isso já está sendo previsto.
Recentemente soube que a Google e a Nasa já estão tomando providências antecipadamente para promover uma Universidade que visará a formação de pessoas que estudarão os problemas causados pelo avanço tecnológico, evitando assim, por exemplo, que computadores com capacidade intelectual dezenas de vezes mais potente que a dos seres-humanos, possam nos dominar e passar a ter o controle, assim como na série de filmes Terminator, onde uma rede neural formada por computadores super-inteligentes chamada Skynet toma o controle do mundo e se torna superior a raça-humana.
A universidade já tem nome, e se chamará Universidade da Singularidade e será coordenada pelo então famoso Ray Kurzweil, um grande inventor e futurista americano, visionário e defensor da singularidade tecnológica, do qual sou fã de suas idéias e invenções. Kurzweil escreveu um livro em 2005 intitulado "A Singularidade está próxima", onde o escritor prevê que os computadores serão mais inteligentes que o ser-humano até a metade desse século.
Há uma palestra de Kurzweil no TED falando sobre a universidade da singularidade, que vale muito a pena ser assistida. Também há outras matérias sobre Kurzweil no Youtube falando sobre singularidade (aqui, aqui e aqui).
Em se falando de problemas, na minha opinião o maior de todos será o social, pois, a evolução não chegará a todos os seres-humanos nem a todo o mundo. Muitas pessoas não terão acesso a tecnologias, as transformações, as possibilidades do futuro. Serão como uma casta não evoluída, ficando a mercê de uma casta tecnológicamente evoluída e "superior". Haverá muito sofrimento e dor!
Espero que a Universidade da Singularidade preveja isso, para tentar amenizar os seus efeitos.
Compartilho da opinião de muitos visionários que acreditam na velocidade das transformações, que estamos vivendo o momento do início da virada tecnológica, que se dará a partir do hoje.
Parece insanidade tentar imaginar o que será de nós seres-humanos no futuro, num futuro não tão longe quanto alguns possam imaginar, mas particularmente espero estar vivo para presenciar parte disso tudo.
Uma coisa é certa, não se levará outros 1.943 anos para acontecer, será muito muito antes que isso.
PS: A maioria dos links que usei estão direcionando para artigos em Inglês pela qualidade e riqueza de informações que não encontrei em artigos em português.
[Delphi Series] Como saber o Serial Number de um HD via Delphi?

Recentemente procurando um trecho de código em Delphi para uma implementação em um dos poucos programas que ainda sou responsável, encontrei um código que escrevi há algum tempo atrás que me foi muito útil em uma ocasião onde precisava validar a instalação da aplicação mediante uma licença vinculada ao número de série do HD do PC instalado.
Além desta função, ainda encontrei outras tantas procedures e functions que escrevi e mantenho ainda em meus arquivos de código e pretendo disponibilizar esses códigos numa série específica de códigos em Pascal, para os que ainda desenvolvem em Delphi e passam talvez pela mesma necessidade que eu já passei algum dia.
Sei que talvez hoje poucas pessoas ainda estejam programando aplicativos para Desktop, Win32. Também acredito que o número de desenvolvedores que usam Delphi ainda, é bem menor que alguns anos atrás, mas também acredito que alguém ainda algum dia possa precisar, então ai vai o primeiro código, a que se refere à identificar o número de série de um HD.
Testei o código na versão 7 do Delphi em um PC com Windows XP SP3 e funcionou corretamente, ok?
function GetSerialNumberFromHD(const SourceDrive: String): String;Para testar é simples:
var SerialNumber, DirLenght, Marks: DWord;
DriveLabel: Array[0..11] of Char;
stringDrive: String;
charDrive: Char;
begin
Result := 'Error';
if (length(SourceDrive) = 0) then Exit;
stringDrive := SourceDrive[1]; charDrive := stringDrive[1];
if (charDrive in ['A'..'Z','a'..'z'] = false) then Exit;
try
GetVolumeInformation(PChar(charDrive+':\'), DriveLabel, 12, @SerialNumber, DirLenght, Marks, nil, 0);
Result := IntToHex(SerialNumber,8);
except
Result := 'Error';
end;
end;
Comece uma nova aplicação, acrescente um componente Button ao seu Form, e coloque o seguinte código no evento OnClick:
procedure TForm1.Button1Click(Sender: TObject);Espero ter ajudado! :)
begin
showmessage(GetSerialNumberFromHD('c:'));
end;
Vendendo "Seu Peixe" - parte #3 - É mensal? Não quero!

Em todos os anos em que tenho atuado como comercial de uma empresa de software, oferecendo sistemas, soluções e serviços, colecionei um número de resistências consideráveis por parte das diretorias e coordenadorias das empresas, principalmente quando encerrava a fase de apresentação e demonstração do produto e o assunto passava a ser a política comercial, a precificação.
Dentre as resistências que encontro, destaco uma em especial, talvez a maior de todas elas: a cobrança por um valor mensal, seja ela pela manutenção e suporte técnico de um sistema, seja por uma locação mensal do software. Enfim, quando se trata de uma política comercial que envolve uma taxa mensal por qualquer que seja a razão, há uma certa repulsa por parte dos dirigentes da empresa e em muitas situações inicia-se uma cansativa negociação e um interminável questionamento para que se justifique as reais razões pela tal cobrança.
Fazendo um parênteses aqui, não poderia deixar de citar um artigo postado pelo Carlos Brando no seu blog Nome do Jogo recentemente, onde ele relaciona as formas mais conhecidas de se cobrar por softwares e tem tudo a ver com este post. Se você ainda não leu, vale a pena, vá conferir!
Acontece que, na minha opinião, quando se trabalha com desenvolvimento de softwares e sistemas especializados/específicos, voltados à empresas de médio e grande porte, uma empresa de desenvolvimento nesse segmento não pode e nem deve se aventurar em depender apenas das vendas de licenças de uso, ignorando a cobrança de uma mensalidade por suporte e manutenção do sistema ora desenvolvido. Como se poderia manter uma equipe de suporte técnico especilizada, uma boa equipe de desenvolvedores preparados, atualização de equipamentos como servidores e estações de trabalho, link de Internet, atualização de ferramentas de desenvolvimento e principalmente, como se poderia manter a evolução do sistema ou software no cliente, sem uma boa e saudável receita recorrente?
Trato aqui como receita recorrente, não só as provenientes da venda de licença de uso, mas sim também, e principalmente, as originadas das mensalidades pagas pelos clientes.
Alguns poderiam me responder que isso é possível somente com a venda de licenças de uso, claro, concordo, quando se está falando de softwares que são vendidos em grandes quantidades de licenças de uso e que demandam pouco suporte técnico (pelo menos o suporte técnico que envolve interação humana).
Já passei por uma experiência em uma empresa que, equivocadamente, para fazer frente ao seu principal concorrente, usava o argumento de que não existia a necessidade de cobrança por uma taxa mensal de suporte ou manutenção do software. Em alguns anos conseguiu um número considerável de clientes, até mesmo conseguiu fazer com que clientes do concorrente trocassem de fornecedor, porém a empresa em que trabalhava na época se esqueceu de pensar em alguns detalhes:
- O mercado que atuava era muitíssimo restrito, praticamente algumas centenas no Brasil todo;
- O software era muito específico e muito peculiar;
- O software em algum momento precisaria evoluir, ter uma nova versão mais atualizada e que acompanhasse as necessidades de cada cliente;
- Haveria a necessidade de prestar suporte técnico à esses clientes, e obviamente, quanto mais clientes, mais pessoas seriam necessárias contratar para o departamento de suporte técnico;
- O espaço físico para suportar o número de pessoas contratadas teria que ser maior, ocasionando em investimentos na ampliação do espaço, fosse ele construindo ou locando tal espaço;
Hoje, quando sou sabatinado pelos diretores e coordenadores das empresas que estou prospectando sobre o motivo da cobrança de uma mensalidade para o que chamamos de manutenção e suporte técnico, faço uso de meu principal e mais forte argumento perguntando-lhes se preferem um contrato de parceria com uma empresa que possa perpetuar sua permanência no mercado evoluindo tecnologicamente, mantendo em seu quadro de profissionais pessoas qualificadas e preparadas ou um contrato de parceria com uma empresa que corre o risco de ser extinta por não possuir recursos suficientes para se manter no mercado ou para manter os melhores profissionais em seu quadro.
Até agora tenho obtido êxito com minha argumentação, pois a grande maioria das empresas sérias, buscam uma parceria duradoura e de qualidade com as empresas de software, visto a grande dependência por sistemas de informação que realmente funcionem com qualidade e precisão.
Portanto, caso você tenha passado pela mesma experiência de ser sabatinado e questionado quando se apresenta uma política comercial que envolva a cobrança de mensalidades, tente tal argumentação, mas seja enfático, seja convincente o suficiente para que o seu prospect confie plenamente no que você argumenta. E o mais importante disso tudo: Mantenha sua palavra! Se o seu argumento o convercer que os valores percebidos mensalmente irão possibilitar um bom produto combinado com um excelente atendimento, cumpra-o, pois caso contrário, também estará fadado ao descrédito e ao insucesso.
Caso tenha algo a complementar no post, comente, deixe sua experiência, compartilhe suas idéias. Valew :)
Vendendo "Seu Peixe" - parte #2

Alguns meses atrás escrevi meu primeiro post sobre vendas, focando principalmente o trabalho de vendas e comercial na área de desenvolvimento de softwares. Meus planos eram de escrever pelo menos 1 artigo relacionado com o assunto por mês, porém acabei deixando que outros compromissos me impedissem de dar continuidade e a partir de hoje farei o possível para postar com mais periodicidade, nem que sejam posts mais curtos.
Como já havia postado, vender software ou oferecer um serviço de consultoria no mercado, realmente não é uma das tarefas mais fáceis de se fazer. Convencer um cliente do valor que se tem o produto ou serviço oferecido, muitas das vezes se torna um processo longo e até mesmo cansativo, mas como digo às vezes: "se fosse muito fácil, não teria graça nenhuma." ;)
Em primeiro lugar, assim como qualquer bem ou serviço que se queira vender, é preciso conhecer em detalhes aquilo que está sendo oferecido para o cliente, é preciso conhecer cada função, cada tarefa, cada recurso que o software oferece, como se comporta, saber exatamente os detalhes da interface, a navegabilidade entre os formulários ou páginas do sistema, como extrair rapidamente uma informação importante, conhecer profundamente as integrações entre os módulos, enfim, o vendedor, ou melhor ainda, o Engenheiro de Vendas, como é chamado o profissional de vendas de software no livro da Aisa Pereira, deve conhecer minuciosamente o software ou o sistema a ser oferecido.
Mas não basta apenas conhecer todos os detalhes do software oferecido, deve-se também saber dos detalhes técnicos, muitas das vezes fatores de decisão na contratação pelo cliente:
- A linguagem ou plataforma utilizada no desenovlvimento;
- O banco de dados utilizado;
- A plataforma do sistema operacional requerido;
- As configurações de hardware necessárias (servidor e estações);
- A estrutura de rede;
- A economia financeira que pode ser alcançada (Na minha opinião, o principal argumento que o cliente quer ouvir);
- A agilidade de processos operacionais;
- Redução de tempo em tarefas antes manuais;
- O melhor aproveitamento dos profissionais da empresa;
- Maior controle do fluxo e centralização de informações;
- Velocidade na tomada de decisões;
- Segurança e sigilo dos dados;
- Suporte ao crescimento da empresa como um todo;
- Entre outros;
Enfim, considero o conhecimento detalhado do produto, bem como seus aspectos técnicos e detalhes da implantação, de suma importância para o início de uma boa negociação e fundamentais para a conclusão de um bom negócio.
[Delphi Series] Fazendo Uploads de Arquivos via HTTP usando Delphi

Há alguns anos escrevi uma aplicação em Delphi que faz parte de um pacote de solução oferecida pela nossa empresa, a Plano Bê. Trata-se de um programa, chamado de Quick Index, usado para auxiliar na tarefa de indexação de documentos digitalizados pelos escaners de nossos clientes e na integração com nosso Sistema GED WEB.
O QI, como carinhosamente é chamado pelos usuários desta aplicação, acessa as informações no banco de dados do sistema WEB, através de requisições HTTP a uma página ASPX de nosso sistema GED WEB desenvolvido em VB.NET, para evitar a necessidade de instalação do client do banco de dados, configurar ODBC ou BDE, etc.
Acontece que, até então, a transferência dos arquivos digitalizados era meio que, como poderia chamar, meio rudimentar na minha opinião, pois usava um compartilhamento de pastas no servidor de GED e isso sempre trazia um problema ou outro quando o profissional de TI do cliente instalava o QI numa nova máquina com escaner, e não configurava corretamente as permissões de acesso, usuários, entre outras coisas.
Eu já não estava muito contente com esse tipo de funcionamento e já estava pensando em resolver de um modo diferente, quando fui procurado por um cliente que teria uma nova necessidade. Ele precisaria então digitalizar documentos remotamente, ou seja, em estações de trabalho fora de sua rede local, porém conectadas a Internet, detalhe: poderia ser até de outra cidade.
Foi o suficiente para pensar que está seria a chance de estudar uma mudança na maneira de subir estes arquivos para o servidor de GED. Pensei então em estudar uma forma de fazer um Upload destes arquivos para o servidor de GED usando HTTP mesmo, de forma que o QI pudesse estar em qualquer lugar, seja na rede local do cliente ou em uma estação externa conectada a Internet.
Cheguei pela manhã e comecei a estudar um componente que já usava no QI para acessar os dados do Sistema GED WEB, o idHTTP que fica localizado na paleta de componentes chamada Indy Clients.
Depois de encontrar algumas dicas em sites gringos, fiz um pequeno sample para testar o funcionamento do componente usando também um objeto da classe TIdMultiPartFormDataStream que funciona como um repositório onde coloco quais arquivos quero fazer o dito Upload usando o método POST do componente idHTTP.
Depois de pronto meu sample, pedi ajuda ao Jean, nosso analista WEB e perito em VB.NET, para que fizesse uma página ASPX que recebesse meus arquivos enviados pelo sample. Alguns minutos depois e voilá, estava funcionando nossos testes (claro depois de alguns pequenos enroscos).
Terminado meus testes, antes de partir para a execução da "cirurgia" no neu fonte do QI, resolvi que poderia contribuir também com a galera que desenvolve em Delphi e que assim como eu, também poderiam precisar de algo parecido. Criei logo um repositório no GitHub e subi meu sample pra lá, portanto, se você se interessar pelo sample, e precisar de algo parecido ou for apenas um curioso que gostaria de conhecer o código, clique ai no link e fique à vontade em implementar, modificar, sugerir e até mesmo criticar, ok?
Rapidamente, vou postar aqui um resumo dos códigos usados para o tal Upload, acompanhe ai e veja como é simples (Claro, o sample é mais completo):
formData := TIdMultiPartFormDataStream.Create;
formData.AddFile('Identificação do Arquivo', 'Nome do Arquivo para Upload', 'plain/text');
IdHTTP1.Request.Referer := 'URL da página ASPX que recebe o arquivo';
idHTTP1.Post('URL da página ASPX que recebe o arquivo', formData);
Obrigado pela leitura e fique à vontade em comentar o post e ajudar meu BLOG a ser mais útil.
Fazendo a diferença
Como tenho relatado neste Blog, não sou muito antigo no mundo Rails não, aliás, posso me considerar um iniciante embrionário no mundo Rails, mas desde que comecei a conhecer e me aprofundar um pouco mais nesse universo, tenho conhecido pessoas realmente que fazem a diferença na comunidade.
Minha introdução oficial com Ruby e Rails foi em Outubro passado quando participamos, eu e o @luisbebop, do Rails Summit LA em Outubro de 2008, veja mais em RailsSummit #1, RailsSummit #2, RailsSummit #3 e RailsSummit Final.
Desde então, conheci pessoas e profissionais que fazem realmente a diferença, que se doam, que investem seu tempo e que de alguma forma amam o que fazem, e muitas das vezes sem ganhar 1 centavo com seus trabalhos e dedicação à comunidade. Pessoas como o Carlos Brando do Blog Nome do Jogo (@carlosbrando) que dedica boa parte do seu tempo escrevendo artigos em seu blog sobre Ruby e Rails, que trabalha horas afinco escrevendo livros sobre o tema, e centenas de outras horas traduzindo outros materiais como o recente livro do Why, e há também o Rails Podcast Brasil, gravado com o Brando e o Fábio Akita (@akitaonrails).
Recentemente o Carlos Brando liberou mais um livro de sua autoria, o "Ruby on Rails 2.2 - O que há de Novo?", que inicialmente estava sendo oferecido à 9 dólares para custeio de seu investimento inicial e que agora pode ser baixado gratuitamente.
O primeiro livro escrito pelo Brando também pode ser baixado em formato PDF, por este link.
Encontrei essa forma de reconhecer e divulgar o seu trabalho, que tem contribuído tanto com a comunidade Rails no Brasil.
Parabéns Carlos!




