Publicada originalmente em 18/11/2010 por IDG Now!
(Melissa Riofrio)
Vazamentos de tinta têm solução. O mesmo pode ser dito de impressoras que engasgam com papel. Você sabe o que fazer quando isso acontece?
Todos os dias, diversos problemas com impressoras transformam a vida dos usuários em uma via crucis. Alguns deles são bastante comuns e relativamente fáceis de resolver. Conheça os principais:
1. Engasgar com papel
Fenômeno que ocorre quando algo interrompe o fluxo de papel em seu caminho da bandeja até a saída do documento impresso. Por vezes, a impressora entrega uma folha de papel toda amassada, outras, interrompe o processo de impressão no meio e trava à espera de alguém para socorrê-la e extirpar a página parcialmente impressa.
Siga esses passos para sofrer menos quando isso acontecer:
I. Desligue a impressora – afinal de contas não queremos faíscas, queimaduras ou curto-circuito causado por anéis e pulseiras. Impressoras laser normalmente trabalham em temperaturas elevadas; vale aguardar até que esfriem.
II. Abra todas as comportas que levam até o papel e que estejam em sua rota dentro da máquina. Se estiver em dúvida sobre onde está o problema, comece pela bandeja e vá seguindo até chegar à área em que o papel é impresso. Todas as travas devem ser liberadas nesse processo.
III. Retire cuidadosamente o papel e eventuais pedaços do interior da impressora. Se possível, puxe a(s) folha(s) no sentido que elas normalmente percorreriam a máquina; assim você evita danificar a parte mecânica da impressora. Seja minucioso e tire todas as folhas e fragmentos que podem vir a interromper o fluxo em impressões futuras. Se acontecer de danificar algum componente interno, pare o que faz e chame a assistência técnica.
IV. Feche todas as portas e travas, alimente a impressora com papel seco e ligue a máquina. O processo de impressão deverá recomeçar de onde foi interrompido. Se isso não ocorrer, repita as operações acima. Se não resolver, acione a assistência e reze para que seja um mal menor e não a substituição do cabeçote ou da rebimboca da parafuseta.
2. A interminável fila de impressão
A impressora mais moderna do mundo ainda tem uma limitação: atender apenas a uma solicitação de job por vez. Às vezes não dá conta de realizar uma impressão e, presa a esse trabalho, provoca atrasos em todas as tarefas enfileiradas. Possivelmente, um trabalho ocupou toda a memória da impressora ou um documento está configurado para ser impresso em determinado tipo de papel sem que este esteja na bandeja da máquina. Também pode ser fruto da configuração da alimentação do papel (definido para manual).
I. Se for uma impressora dedicada, conectada diretamente em seu PC, basta interferir no painel de controle (sistemas Windows) ou nos Utilitários de Impressão de máquinas munidas com SOs Apple e cancelar a ordem de impressão.
II. Impressoras de rede atendem a várias solicitações e as listam para aos usuários, esses, porém, não podem interferir em jobs que não sejam seus. Vale contatar os analistas de suporte para resolver a questão.
3. Vazamentos de tinta ou manchas de toner
Os pigmentos na tinta para impressoras e tonners são feitos para cumprir três tarefas: gravar, secar e permanecer. Mas tudo isso no papel e não no chão, nas mãos ou nas camisas brancas.
Toner
Ao derramar acidentalmente, preste atenção nos seguintes passos:
- Seque o local em que caiu;
- Não inalar o toner.
Para remover:
- Não use água fria, morna ou quente; prefira produtos de limpeza normais;
- Evite usar um aspirador de pó convencional, pois por ser um pó muito fino, pode vazar por outros cantos do aspirador. Existem aspiradores especialmente desenvolvidos para sugar toner. Eles trazem bicos que permitem alcançar cantos remotos dentro de impressoras e de mesas;
- Em casos de superfícies lisas, use toalhas de papel ou panos especiais (que atraem estaticamente o toner) e jogue em sacos de plástico bem fechados.
Tinta
Não chore a tinta derramada, remova. Eis como:
- No caso de superfícies lisas, seque a tinta com um pano ou lenço absorventes. Em seguida use um produto de limpeza para remover eventuais manchas, sempre de acordo com a superfície específica. Não espere secar.
- Caiu tinta na pele? Seque a tinta em excesso e continue lavando a pele com o sabonete de sua preferência. Não saiu? Esfrega que sai. Evite usar produtos de limpeza adicionais. Normalmente, água morna e sabonete dão conta.
- Tinta em tecidos ou no carpete. A receita chama-se água e sabão. Faça movimentos verticais, não desenhe em círculos nem de um lado para o outro. Nos dois casos você estará espalhando a tinta pelas fibras do tapete no lugar de removê-las.
- No interior da impressora. Aí complicou. É uma trabalho difícil e o resultado é incerto. Mas, se quiser experimentar, faça o seguinte:
I. Desligue a impressora se for possível. Alguns modelos somente permitem acesso à área de cartuchos quando ligadas. Se este for o caso, mantenha a máquina ligada até retirar os reservatórios de tinta. Mas vale
pensar se remover o cartucho não vai causar mais danos que se deixá-lo por hora onde está. Se optar por remover os causadores da invasão, tenha em mãos um recipiente para acomodá-los.
II. Com um pano seque o máximo de tinta que conseguir. Use tecido que não solte felpas umedecido com álcool. Cuide para não deixar nada preso no interior da impressora.
III. Faça um teste de impressão e procure por evidências de tinta por toda a folha.
4. Queda de energia elétrica durante uma impressão
Não é complicado de resolver. Pode ser encarado como um tipo de jam (papel engasgado).
I. Desligue a máquina, pois não queremos que o processo de impressão recomece enquanto você remove a folha parcialmente impressa.
II. Ligue a impressora novamente e observe se há mensagens de erro ou sons estranhos que possam indicar danos internos.
III. Impressoras laser requerem que você leia as instruções de como remover o tonner que ficou preso entre o cartucho e a cabeça de impressão. Já os modelos que operam com tinta demandam que os cartuchos sejam limpos antes de continuar o processo de print. Antes de continuar a imprimir o documento, realize um teste para verificar que está tudo bem com a máquina. Em inglês existe a sigla "RTFM"; significa algo como "prezado usuário, por favor, leia o manual".
IV. Para evitar que caso semelhante volte a acontecer, procure instalar um no-break na impressora.
5. Imprimindo do lado certo em papel fotográfico
Os intermináveis segundos que o separam de uma fotografia impressa estão para passar, quando, para o seu desespero, você se dá conta de ter colocado o caro papel fotográfico virado do lado contrário, justamente aquele que não absorve tinta.
O que fazer?
I. Se der tempo, cancele a impressão, principalmente se estiver imprimindo uma série de fotos.
II. Retire cuidadosamente as folhas de papel da impressora evitando que a tinta escorra e vá parar no chão ou nas roupas. Se quiser, pode usar um lenço para segurar as películas, uma vez que a tinta pode manchar suas mãos.
III. Jogue tudo no lixo. Sim: pode ir se despedindo do papel e da tinta caríssima. Da próxima vez, certifique-se de ter inserido o papel do lado indicado no manual da impressora.
2011/01/21
Programação: Como evitar os 12 pecados mortais mais comuns
Publicada originalmente em 10/12/2010 por IDG Now!
(Peter Wayner)
Blindar o código ou deixá-lo aberto? O que faz mais sentido, criptografia própria ou soluções prontas? Qual a decisão mais correta?
Grande parte das peculiaridades das linguagens de programação se deve ao fato de seu emprego ser propício apenas em ocasiões absolutamente singulares. O resultado disso são plataformas de programação obscuras, merecedoras de horas de estudo e de pesquisa, além de testes.
Web sites com implementações XML, por exemplo, podem não ter a instrução de avisar ao navegador que ele deve se prepara para receber dados nessa forma. Quando isso acontece, as funções não são executadas de forma propícia, até que os valores correspondentes sejam encontrados.
Desenvolvedores sofrem especialmente com programas desenvolvidos pelo que é conhecido na indústria de TI como Noob (novato, inexperiente). Estruturas antiquadas e ausência de recursos que aumentem a robustez dos códigos estão entre os principais motivos de seu descontentamento.
Mas existem outras questões, todas de cunho técnico, capazes de tirar definitivamente o sono dos desenvolvedores.
Erro de programação #1 – Um código relapso
O caminho mais rápido em direção a um programa falho consiste em relaxar na hora de desenvolver seu código. É comum isso se transformar em conseqüências desastrosas, de acordo com a aplicação, por parte de um usuário despreparado. Perguntas _ como será que uma entrada 0 é capaz de achar seu caminho até a operação de divisão? Terá o texto submetido no tamanho correto? O formato das entradas foi verificado? A identidade do usuário é verificada na base de dados? _ acabam não sendo feitas, levando a pequenos erros que podem comprometer um programa inteiro.
Para piorar ainda mais, o design avançado de linguagens de programação modernas, que deveriam corrigir esse tipo de contingência, não dá conta de cumprir seu papel. Um exemplo disso é a última versão do Java, em que foi implementada a tentativa de facilitar a checagem por "null-pointers" com base em sintaxes abreviadas para a realização dos ensaios de apontadores. Basta adicionar um ponto de interrogação a cada
invocação de método; automaticamente será incluído um teste de "null-pointers" que ajuda a subsituir uma miríade de argumentos if-then desse tipo:
Por isso:
Mesmo assim, no final das contas, esse tipo de correção de códigos apenas evita que o código trave, sem garantir que seja um código útil. Porque, em uma abordagem pragmática, percebe-se que esses recursos
não erradicam o problema principal: a proliferação de valores nulos, resultado de programação relapsa.
Erro de programação #2 – Ser refém de detalhes
Na contramão do argumento anterior, códigos ultra detalhados podem transformar uma execução breve em um processo que se arrasta parecendo não ter fim. Nada contra verificar alguns null pointers, mas existem
códigos que são um exemplo de paranóia, dada sua rotina de verificação obsessiva.
Sobrecarregar códigos com rotinas de verificação pode ser mal interpretado por determinados sites, o que ocasiona a negação de serviços na rede. Tenho vários pacotes que, de tanto verificar se existem
atualizações, rodam de maneira lenta se não estiverem sendo executados em um PC conectado à web.
O desafio nesse caso é escrever um código com camadas que chequem os dados assim que eles aparecem. Em bibliotecas que exigem a participação de vários programadores ou que sejam feitas por um programador apenas é bastante complicado manter o controle sobre as verificações de pointers.
Erro de programação #3 – Complicar funções de controle
Equivale a implorar que aconteça um desastre. "Meu maior arrependimento é ter trabalhado no desenvolvimento de um código base por três anos sem me importar em torná-lo modular. Aprendi da pior maneira quais são os resultados de não respeitar princípios de SIngle Responsibility (atribuições singulares).
Hoje, não há um código novo que eu não comece por revisar a fatoração do código original", diz Mike
Subelsky, um dos fundadores da OtherInBox.com. Como você deve desconfiar, Subelsky é um programador de Ruby on Rails, um framework que incentiva a criação de códigos simples, pois parte do
princípio de a estrutura principal do código seguir padrões usuais. No jargão de programadores da plataforma Ruby esse procedimento é chamado de convenção no lugar de configuração. O software parte do princípio de que, se o programador criar um objeto de valor "name" com dois campos, sendo estes "first" e, outro, "last", ele (o programa) deve fundar duas bases de dados com os mesmos nomes. A definição dos nomes em apenas um campo evita que surjam complicações caso alguém esqueça de manter todas as camadas em sincronia.
Erro de programação #4 – Deixar tudo na mão dos frameworks
Ao interpretar as intenções do programador, os frameworks terminam gerando mais confusão do que o esperado deles e dificultam a identificação de possíveis erros de programação. Para G. Blake Meike, profissional de programação sediado nas imediações de Seattle, o excesso de confiança em frameworks "inteligentes" é um impeditivo quando se trata de criar códigos limpos.
Para Meike, a convenção é algo que deve acontecer fora do software, ela deve ser fruto do acordo entre quem programa. "A não ser que você seja íntimo das regras adotadas pelo Ruby on Rails na hora de transformar uma URL em um método de chamadas, você jamais saberá o que acontece em resposta a uma
requisição", diz. "Se, por um lado, as regras são bastante razoáveis, elas estão longe de serem triviais. Trabalhar com Ruby requer conhecimento. À medida que o aplicativo cresce, se torna cada vez mais essencial saber detalhes dessas regras. No final das contas, de tantos detalhes triviais em sua natureza, mas
não em seu conteúdo, dominar a programação Ruby significa saber viver em um ecossistema singular".
Erro de programação #5 – Acreditar no cliente
Boa parte dos erros de programação aparecem quando o desenvolvedor parte do princípio de que o cliente sabe o que fazer. Um código, por exemplo, escrito para rodar em um browser, pode ser reescrito pelo navegador com a finalidade de executar qualquer ação arbitrária. Cabe aos desenvolvedores realizar dupla verificação dos dados retornados, pois tudo pode dar errado.
Entre os ataques mais elementares, encontra-se o fato de alguns programadores permitirem a transmissão de dados do cliente diretamente para a base de dados. Nada de errado até o cliente decidir enviar informações
no formato SQL no lugar de repostas válidas. Sites que solicitam o nome do usuário e o adicionam às requisições podem ser atacados por usuários que decidam responder informando um nome "x; DROP TABLE users;".
O que acontece é que a base de dados partirá do princípio do nome do usuário "x" e seguirá para o próximo comando, apagando a tabela contendo todos os usuários. Outras ocasiões que propiciam o abuso por parte de usuários mais experientes são as pesquisas digitais. O Buffer overrun continua sendo um dos métodos mais elementares para corromper softwares.
Para piorar, várias brechas de segurança podem surgir da união de três de quatro supostas brechas benignas. Um programador pode permitir que um cliente escreva um arquivo partindo do princípio de as permissões do diretório serem suficientes para evitar escritas em locais proibidos. Pouco depois, outro programador pode alterar as permissões temporariamente para corrigir um bug randômico. Sozinhas, essas circunstâncias não oferecem grande risco, mas uma vez combinadas, dão acesso privilegiado ao cliente.
Erro de programação #6 – Desconfiar demasiadamente do cliente
Em função de rotinas fortemente orientadas à segurança muitas vezes afastarem os usuários, alguns desenvolvedores web procuram afrouxar a segurança ao máximo. Isso facilita a interação de visitantes com os produtos além de propiciar uma defesa mínima de suas informações na hora de configurar uma conta, por exemplo.
Existe uma variedade de jeitos que permitem às bases de dados armazenar menos informação enquanto fornecem o mesmo serviço. Existem ocasiões em que a solução irá funcionar sem que guarde qualquer dado legível.
Erro de programação #7 – Confiar cegamente em caixas mágicas
Programadores são, definitivamente, profissionais de muita sorte. Afinal de contas, cientistas de computação continuam criando bibliotecas intermináveis com correções para todo e qualquer mal que assole o código. O
problema, ao mensurarmos com certa leviandade o trabalho de terceiros, é terminar criando situações de risco no código, em função da complexidade que cerca o projeto.
"Criptografia é um dos algozes dessa realidade", diz John Viega, um dos autores do "24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them" (Os 24 pecados mortais em segurança de software – como corrigir erros de programação). "A maioria dos programadores parte do princípio de que linkar dentro da biblioteca de criptografia é garantia de robustez", diz.
Erro de programação #8 – Querer reinventar a roda
"Desenvolver um método de criptografia próprio é um convite aos hackers", diz Viega. O autor sabe que até
programadores cometem erros quando tentam prevenir seus sistemas dos ataques de outros usuários ou de explorarem eventuais fraquezas em seus sistemas.
Então resta a perguntar em quem confiar. Em você ou nos outros "especialistas" em segurança? A resposta para tal pergunta se encontra na sala e na mente dos gestores de riscos. Muitas bibliotecas dispensam perfeição, o que permite que se use a primeira solução em criptografia disponível.
Erro de programação #9 – entregar o controle nas mãos dos usuários
Programadores amam incrementar seus produtos com opções de otimização e de adequação para o usuário customizar o aplicativo. O problema é que a maioria dos usuários não tem ideia de como fazê-lo. Um bom exemplo disso é o Android. A última vez que instalei um software para um smartphone com esse sistema, foram necessários cinco ou seis parâmetros de acesso aos dados. Apesar disso revelar esmero por parte da
equipe do Android em desenvolver um sistema altamente personalizado e customizável, as opções de acesso aos recursos como a câmera e o GPS podem deixar um usuário menos experiente confuso.
Quando transferem às mãos do usuário o poder de definir tais configurações também abrem as portas do sistema para, em caso de configuração imprecisa, deixar entrar pessoas mal-intencionadas no sistema.
A ironia está no fato de os usuários desejarem essas opções quando decidem por este ou aquele sistema. Quando chega a hora de configurar o ambiente, faltam as informações necessárias para realizar esses ajustes de forma adequada.
Erro de programação #10 – Simplificar demasiadamente
Para alguns desenvolvedores, a solução nos casos de múltipla escolha é deixar apenas uma opção aberta ao usuário. O Gmail é famoso por restringir as opções de uso aos desenvolvedores. Não há como criar diretórios. Por outro lado, é possível marcar cada tipo de mensagem com uma tag própria. Na perspectiva de desenvolvedores, isso pode ser ainda mais funcional que as pastas.
Pode até ser. Mas dificulta a compreensão por parte dos usuários. O resultado desse tipo de idiossincrasia é dar oportunidade à concorrência, ao passo que tentar agradar a gregos e troianos acaba custando muito caro.
Erro de programação #11 – Blindar o código
Um dos maiores desafios impostos às empresas é definir quantas informações serão partilhadas com os usuários. O co-fundador de uma das empresas pioneiras no segmento de código aberto, a Cygnus Solutions, diz que a decisão de não distribuir o código fonte junto dos produtos é uma das maneiras mais rápidas de esfriar os ânimos do público em geral.
As vantagens em abrir o código dos sistemas são variadas. É previsível que ele cresça com uma estrutura aperfeiçoada à medida que passa pelas mãos de vários colaboradores. Deixar o código fonte aberto consiste em tornar o programa mais confiável e compreensível.
Erro de programação #12 – Abrir o código a espera de perfeição
Milhões de projetos de código aberto foram iniciados, mas poucos conseguiram reunir mais de meia dúzia de entusiastas. Se, por um lado, abrir o código é um incentivo na busca por um produto melhor, é necessário prover algum tipo de recompensa para os colaboradores da plataforma. As pessoas têm outras coisas a fazer em suas vidas. O código aberto irá competir com família, amigos, bares e empregos remunerados. Vale, ainda, ressaltar que o entusiasmo dos colaboradores na busca por opções e incremento dos recursos em um sistema pode resultar em um código com várias falhas de segurança.
Muitas vezes, projetos de código aberto são disponibilizados no sourceforge.net à espera do trabalho mágico dos gnomos digitais. Essa estratégia pode condenar um sistema antes mesmo dele começar de verdade.
Abrir as informações acerca de um projeto ainda é um repelente contra investidores. A noção geral de que esses projetos são repletos de hippies e pessoas com desprezo por lucro e outras iniciativas não é um grande incentivo para quem tem poder e desejo de fazer de uma iniciativa open source algo rentável.
(Peter Wayner)
Blindar o código ou deixá-lo aberto? O que faz mais sentido, criptografia própria ou soluções prontas? Qual a decisão mais correta?
Grande parte das peculiaridades das linguagens de programação se deve ao fato de seu emprego ser propício apenas em ocasiões absolutamente singulares. O resultado disso são plataformas de programação obscuras, merecedoras de horas de estudo e de pesquisa, além de testes.
Web sites com implementações XML, por exemplo, podem não ter a instrução de avisar ao navegador que ele deve se prepara para receber dados nessa forma. Quando isso acontece, as funções não são executadas de forma propícia, até que os valores correspondentes sejam encontrados.
Desenvolvedores sofrem especialmente com programas desenvolvidos pelo que é conhecido na indústria de TI como Noob (novato, inexperiente). Estruturas antiquadas e ausência de recursos que aumentem a robustez dos códigos estão entre os principais motivos de seu descontentamento.
Mas existem outras questões, todas de cunho técnico, capazes de tirar definitivamente o sono dos desenvolvedores.
Erro de programação #1 – Um código relapso
O caminho mais rápido em direção a um programa falho consiste em relaxar na hora de desenvolver seu código. É comum isso se transformar em conseqüências desastrosas, de acordo com a aplicação, por parte de um usuário despreparado. Perguntas _ como será que uma entrada 0 é capaz de achar seu caminho até a operação de divisão? Terá o texto submetido no tamanho correto? O formato das entradas foi verificado? A identidade do usuário é verificada na base de dados? _ acabam não sendo feitas, levando a pequenos erros que podem comprometer um programa inteiro.
Para piorar ainda mais, o design avançado de linguagens de programação modernas, que deveriam corrigir esse tipo de contingência, não dá conta de cumprir seu papel. Um exemplo disso é a última versão do Java, em que foi implementada a tentativa de facilitar a checagem por "null-pointers" com base em sintaxes abreviadas para a realização dos ensaios de apontadores. Basta adicionar um ponto de interrogação a cada
invocação de método; automaticamente será incluído um teste de "null-pointers" que ajuda a subsituir uma miríade de argumentos if-then desse tipo:
[code]
public String getPostcode(Person person) {
String ans= null;
if (person != null) {
Name nm= person.getName();
if (nm!= null) {
ans= nm.getPostcode();
}
}
return ans
}
[/code]
public String getPostcode(Person person) {
String ans= null;
if (person != null) {
Name nm= person.getName();
if (nm!= null) {
ans= nm.getPostcode();
}
}
return ans
}
[/code]
Por isso:
[code]
public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}
[/code]
public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}
[/code]
Mesmo assim, no final das contas, esse tipo de correção de códigos apenas evita que o código trave, sem garantir que seja um código útil. Porque, em uma abordagem pragmática, percebe-se que esses recursos
não erradicam o problema principal: a proliferação de valores nulos, resultado de programação relapsa.
Erro de programação #2 – Ser refém de detalhes
Na contramão do argumento anterior, códigos ultra detalhados podem transformar uma execução breve em um processo que se arrasta parecendo não ter fim. Nada contra verificar alguns null pointers, mas existem
códigos que são um exemplo de paranóia, dada sua rotina de verificação obsessiva.
Sobrecarregar códigos com rotinas de verificação pode ser mal interpretado por determinados sites, o que ocasiona a negação de serviços na rede. Tenho vários pacotes que, de tanto verificar se existem
atualizações, rodam de maneira lenta se não estiverem sendo executados em um PC conectado à web.
O desafio nesse caso é escrever um código com camadas que chequem os dados assim que eles aparecem. Em bibliotecas que exigem a participação de vários programadores ou que sejam feitas por um programador apenas é bastante complicado manter o controle sobre as verificações de pointers.
Erro de programação #3 – Complicar funções de controle
Equivale a implorar que aconteça um desastre. "Meu maior arrependimento é ter trabalhado no desenvolvimento de um código base por três anos sem me importar em torná-lo modular. Aprendi da pior maneira quais são os resultados de não respeitar princípios de SIngle Responsibility (atribuições singulares).
Hoje, não há um código novo que eu não comece por revisar a fatoração do código original", diz Mike
Subelsky, um dos fundadores da OtherInBox.com. Como você deve desconfiar, Subelsky é um programador de Ruby on Rails, um framework que incentiva a criação de códigos simples, pois parte do
princípio de a estrutura principal do código seguir padrões usuais. No jargão de programadores da plataforma Ruby esse procedimento é chamado de convenção no lugar de configuração. O software parte do princípio de que, se o programador criar um objeto de valor "name" com dois campos, sendo estes "first" e, outro, "last", ele (o programa) deve fundar duas bases de dados com os mesmos nomes. A definição dos nomes em apenas um campo evita que surjam complicações caso alguém esqueça de manter todas as camadas em sincronia.
Erro de programação #4 – Deixar tudo na mão dos frameworks
Ao interpretar as intenções do programador, os frameworks terminam gerando mais confusão do que o esperado deles e dificultam a identificação de possíveis erros de programação. Para G. Blake Meike, profissional de programação sediado nas imediações de Seattle, o excesso de confiança em frameworks "inteligentes" é um impeditivo quando se trata de criar códigos limpos.
Para Meike, a convenção é algo que deve acontecer fora do software, ela deve ser fruto do acordo entre quem programa. "A não ser que você seja íntimo das regras adotadas pelo Ruby on Rails na hora de transformar uma URL em um método de chamadas, você jamais saberá o que acontece em resposta a uma
requisição", diz. "Se, por um lado, as regras são bastante razoáveis, elas estão longe de serem triviais. Trabalhar com Ruby requer conhecimento. À medida que o aplicativo cresce, se torna cada vez mais essencial saber detalhes dessas regras. No final das contas, de tantos detalhes triviais em sua natureza, mas
não em seu conteúdo, dominar a programação Ruby significa saber viver em um ecossistema singular".
Erro de programação #5 – Acreditar no cliente
Boa parte dos erros de programação aparecem quando o desenvolvedor parte do princípio de que o cliente sabe o que fazer. Um código, por exemplo, escrito para rodar em um browser, pode ser reescrito pelo navegador com a finalidade de executar qualquer ação arbitrária. Cabe aos desenvolvedores realizar dupla verificação dos dados retornados, pois tudo pode dar errado.
Entre os ataques mais elementares, encontra-se o fato de alguns programadores permitirem a transmissão de dados do cliente diretamente para a base de dados. Nada de errado até o cliente decidir enviar informações
no formato SQL no lugar de repostas válidas. Sites que solicitam o nome do usuário e o adicionam às requisições podem ser atacados por usuários que decidam responder informando um nome "x; DROP TABLE users;".
O que acontece é que a base de dados partirá do princípio do nome do usuário "x" e seguirá para o próximo comando, apagando a tabela contendo todos os usuários. Outras ocasiões que propiciam o abuso por parte de usuários mais experientes são as pesquisas digitais. O Buffer overrun continua sendo um dos métodos mais elementares para corromper softwares.
Para piorar, várias brechas de segurança podem surgir da união de três de quatro supostas brechas benignas. Um programador pode permitir que um cliente escreva um arquivo partindo do princípio de as permissões do diretório serem suficientes para evitar escritas em locais proibidos. Pouco depois, outro programador pode alterar as permissões temporariamente para corrigir um bug randômico. Sozinhas, essas circunstâncias não oferecem grande risco, mas uma vez combinadas, dão acesso privilegiado ao cliente.
Erro de programação #6 – Desconfiar demasiadamente do cliente
Em função de rotinas fortemente orientadas à segurança muitas vezes afastarem os usuários, alguns desenvolvedores web procuram afrouxar a segurança ao máximo. Isso facilita a interação de visitantes com os produtos além de propiciar uma defesa mínima de suas informações na hora de configurar uma conta, por exemplo.
Existe uma variedade de jeitos que permitem às bases de dados armazenar menos informação enquanto fornecem o mesmo serviço. Existem ocasiões em que a solução irá funcionar sem que guarde qualquer dado legível.
Erro de programação #7 – Confiar cegamente em caixas mágicas
Programadores são, definitivamente, profissionais de muita sorte. Afinal de contas, cientistas de computação continuam criando bibliotecas intermináveis com correções para todo e qualquer mal que assole o código. O
problema, ao mensurarmos com certa leviandade o trabalho de terceiros, é terminar criando situações de risco no código, em função da complexidade que cerca o projeto.
"Criptografia é um dos algozes dessa realidade", diz John Viega, um dos autores do "24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them" (Os 24 pecados mortais em segurança de software – como corrigir erros de programação). "A maioria dos programadores parte do princípio de que linkar dentro da biblioteca de criptografia é garantia de robustez", diz.
Erro de programação #8 – Querer reinventar a roda
"Desenvolver um método de criptografia próprio é um convite aos hackers", diz Viega. O autor sabe que até
programadores cometem erros quando tentam prevenir seus sistemas dos ataques de outros usuários ou de explorarem eventuais fraquezas em seus sistemas.
Então resta a perguntar em quem confiar. Em você ou nos outros "especialistas" em segurança? A resposta para tal pergunta se encontra na sala e na mente dos gestores de riscos. Muitas bibliotecas dispensam perfeição, o que permite que se use a primeira solução em criptografia disponível.
Erro de programação #9 – entregar o controle nas mãos dos usuários
Programadores amam incrementar seus produtos com opções de otimização e de adequação para o usuário customizar o aplicativo. O problema é que a maioria dos usuários não tem ideia de como fazê-lo. Um bom exemplo disso é o Android. A última vez que instalei um software para um smartphone com esse sistema, foram necessários cinco ou seis parâmetros de acesso aos dados. Apesar disso revelar esmero por parte da
equipe do Android em desenvolver um sistema altamente personalizado e customizável, as opções de acesso aos recursos como a câmera e o GPS podem deixar um usuário menos experiente confuso.
Quando transferem às mãos do usuário o poder de definir tais configurações também abrem as portas do sistema para, em caso de configuração imprecisa, deixar entrar pessoas mal-intencionadas no sistema.
A ironia está no fato de os usuários desejarem essas opções quando decidem por este ou aquele sistema. Quando chega a hora de configurar o ambiente, faltam as informações necessárias para realizar esses ajustes de forma adequada.
Erro de programação #10 – Simplificar demasiadamente
Para alguns desenvolvedores, a solução nos casos de múltipla escolha é deixar apenas uma opção aberta ao usuário. O Gmail é famoso por restringir as opções de uso aos desenvolvedores. Não há como criar diretórios. Por outro lado, é possível marcar cada tipo de mensagem com uma tag própria. Na perspectiva de desenvolvedores, isso pode ser ainda mais funcional que as pastas.
Pode até ser. Mas dificulta a compreensão por parte dos usuários. O resultado desse tipo de idiossincrasia é dar oportunidade à concorrência, ao passo que tentar agradar a gregos e troianos acaba custando muito caro.
Erro de programação #11 – Blindar o código
Um dos maiores desafios impostos às empresas é definir quantas informações serão partilhadas com os usuários. O co-fundador de uma das empresas pioneiras no segmento de código aberto, a Cygnus Solutions, diz que a decisão de não distribuir o código fonte junto dos produtos é uma das maneiras mais rápidas de esfriar os ânimos do público em geral.
As vantagens em abrir o código dos sistemas são variadas. É previsível que ele cresça com uma estrutura aperfeiçoada à medida que passa pelas mãos de vários colaboradores. Deixar o código fonte aberto consiste em tornar o programa mais confiável e compreensível.
Erro de programação #12 – Abrir o código a espera de perfeição
Milhões de projetos de código aberto foram iniciados, mas poucos conseguiram reunir mais de meia dúzia de entusiastas. Se, por um lado, abrir o código é um incentivo na busca por um produto melhor, é necessário prover algum tipo de recompensa para os colaboradores da plataforma. As pessoas têm outras coisas a fazer em suas vidas. O código aberto irá competir com família, amigos, bares e empregos remunerados. Vale, ainda, ressaltar que o entusiasmo dos colaboradores na busca por opções e incremento dos recursos em um sistema pode resultar em um código com várias falhas de segurança.
Muitas vezes, projetos de código aberto são disponibilizados no sourceforge.net à espera do trabalho mágico dos gnomos digitais. Essa estratégia pode condenar um sistema antes mesmo dele começar de verdade.
Abrir as informações acerca de um projeto ainda é um repelente contra investidores. A noção geral de que esses projetos são repletos de hippies e pessoas com desprezo por lucro e outras iniciativas não é um grande incentivo para quem tem poder e desejo de fazer de uma iniciativa open source algo rentável.
2009/08/25
Mudamos por três razões básicas
Idade: A medida que o tempo passa, que a idade avança, etapas novas vão surgindo. São mudanças naturais que a própria vida se encarrega de realizar em nós.
Necessidade: Por causas externas... Você é empurrado a mudar! Se não mudar, estará fora! Uma força externa faz com que ações venham a se realizar dentro de nós. Quase sempre não gostamos do que está acontecendo, mas somos compelidos a aderir ao movimento. Rompemos nossa homeostase a contragosto. Normalmente, esses movimentos são radicais, com um intervalo de tempo menor do que o desejado. Concluída a causa externa, tende-se a retornar para a estabilidade (e talvez morosidade).
Vontade: Por iniciativa interna... Você muda porque quer, ou deseja romper com algo! E tem impacto no cenário externo. A diferença básica entre a vontade (própria) e a necessidade, é que a necessidade, vindo de razões externas, tende a desaparecer, quando essas forças deixam de atuar. No caso da vontade, precisamos de uma força muito maior do que a anterior. Um movimento interno que nos induz a mudar. A base da vontade está intimamente ligada à motivação. A necessidade atua sobre a razão, ao passo que a vontade mexe com o coração.
Mais leituras em O tripé da mudança, por Rui Carlos Pizzato.
Necessidade: Por causas externas... Você é empurrado a mudar! Se não mudar, estará fora! Uma força externa faz com que ações venham a se realizar dentro de nós. Quase sempre não gostamos do que está acontecendo, mas somos compelidos a aderir ao movimento. Rompemos nossa homeostase a contragosto. Normalmente, esses movimentos são radicais, com um intervalo de tempo menor do que o desejado. Concluída a causa externa, tende-se a retornar para a estabilidade (e talvez morosidade).
Vontade: Por iniciativa interna... Você muda porque quer, ou deseja romper com algo! E tem impacto no cenário externo. A diferença básica entre a vontade (própria) e a necessidade, é que a necessidade, vindo de razões externas, tende a desaparecer, quando essas forças deixam de atuar. No caso da vontade, precisamos de uma força muito maior do que a anterior. Um movimento interno que nos induz a mudar. A base da vontade está intimamente ligada à motivação. A necessidade atua sobre a razão, ao passo que a vontade mexe com o coração.
Mais leituras em O tripé da mudança, por Rui Carlos Pizzato.
Geração Y
Em geral, são os nascidos a partir da década de 1970 em diante, e principalmente nos anos 1980. Desenvolveu-se numa época de grandes avanços tecnológicos e prosperidade econômica.
Conectividade: Mais plugada nas coisas – não só na tecnologia. Claro que a tecnologia é a maior manifestação, mas a questão vai além. Vê conexões em coisas do cotidiano que aparentemente não têm ligação nenhuma, que soam abstratas para outras gerações anteriores.
Individualidade: Não é no sentido do egoísmo, mas de deixar sua marca, mesmo que seja pequena. Quer participar de um projeto e deixar sua marca na experiência que está vivendo.
Faz sentido?
Ele(a) é o tio(a), embora bastante jovem - até 35 anos mais ou menos - daquele pirralho que, ao receber como resposta um "porque não" (ou "porque sim") rebate de bate-pronto: "Porque-não não é resposta!". Conclusão: está acostumado a mostrar sentido para os outros - exatamente porque ele também precisa encontrar sentido no que está fazendo ou no que lhe pedem para fazer.
Colaboração: Não no sentido de espírito coletivo, comunitário da geração anterior, mas no sentido de trabalhar em equipe, se envolver em ambientes em que possam manifestar uma parte da coisa e não o todo.
Feedback: Gosta de autonomia, mas "precisa" receber dicas de como está indo seu trabalho, sua performance - não só para corrigir alguma coisa mas, talvez, e talvez principalmente, porque ele é "movido" a elogios.
Impactos:
A geração Y é a grande força de trabalho que está chegando às empresas, é o celeiro das novas lideranças. O impacto, por enquanto, parece ser mais negativo porque a maioria das empresas ainda trabalha com estruturas e modelos voltados a gerações anteriores. Há um conflito de interesses. As redes de relacionamento, por exemplo, ainda são muito estigmatizadas, ainda são encaradas com desconfiança no mundo corporativo. Mas algumas empresas já estão tirando proveito deste cenário, criando ambientes mais flexíveis, seja no horário, no acesso aos meios de comunicação ou até no modo de se vestir. E já tem jovens que estão percebendo que as empresas mais flexíveis dão a ele um ambiente mais produtivo, aproveitando as suas características.
Liderança:
As gerações de gestores anteriores foram formadas na premissa da informação. Eu sou gestor porque sei mais que os meus subordinados. A autoridade vinha da capacidade de ter informação. Isso funcionou bem para a geração X, mas hoje a informação virou commodity, todo mundo tem acesso. Esse líder antigo tem dificuldade porque sente que perdeu poder. Já o jovem da geração Y sequer tem chance de estabelecer o poder pela posse de informação. Ele sabe que não vai ser respeitado por isso. O que funciona é a capacidade de relacionamento, a capacidade de estabelecer conexões e alianças. Ele vai estabelecer sua liderança de maneira colaborativa.
Leia mais:
Qual é a sua, geração Y?
Professor da FGV explica a geração Y
Conectividade: Mais plugada nas coisas – não só na tecnologia. Claro que a tecnologia é a maior manifestação, mas a questão vai além. Vê conexões em coisas do cotidiano que aparentemente não têm ligação nenhuma, que soam abstratas para outras gerações anteriores.
Individualidade: Não é no sentido do egoísmo, mas de deixar sua marca, mesmo que seja pequena. Quer participar de um projeto e deixar sua marca na experiência que está vivendo.
Faz sentido?
Ele(a) é o tio(a), embora bastante jovem - até 35 anos mais ou menos - daquele pirralho que, ao receber como resposta um "porque não" (ou "porque sim") rebate de bate-pronto: "Porque-não não é resposta!". Conclusão: está acostumado a mostrar sentido para os outros - exatamente porque ele também precisa encontrar sentido no que está fazendo ou no que lhe pedem para fazer.
Colaboração: Não no sentido de espírito coletivo, comunitário da geração anterior, mas no sentido de trabalhar em equipe, se envolver em ambientes em que possam manifestar uma parte da coisa e não o todo.
Feedback: Gosta de autonomia, mas "precisa" receber dicas de como está indo seu trabalho, sua performance - não só para corrigir alguma coisa mas, talvez, e talvez principalmente, porque ele é "movido" a elogios.
Impactos:
A geração Y é a grande força de trabalho que está chegando às empresas, é o celeiro das novas lideranças. O impacto, por enquanto, parece ser mais negativo porque a maioria das empresas ainda trabalha com estruturas e modelos voltados a gerações anteriores. Há um conflito de interesses. As redes de relacionamento, por exemplo, ainda são muito estigmatizadas, ainda são encaradas com desconfiança no mundo corporativo. Mas algumas empresas já estão tirando proveito deste cenário, criando ambientes mais flexíveis, seja no horário, no acesso aos meios de comunicação ou até no modo de se vestir. E já tem jovens que estão percebendo que as empresas mais flexíveis dão a ele um ambiente mais produtivo, aproveitando as suas características.
Liderança:
As gerações de gestores anteriores foram formadas na premissa da informação. Eu sou gestor porque sei mais que os meus subordinados. A autoridade vinha da capacidade de ter informação. Isso funcionou bem para a geração X, mas hoje a informação virou commodity, todo mundo tem acesso. Esse líder antigo tem dificuldade porque sente que perdeu poder. Já o jovem da geração Y sequer tem chance de estabelecer o poder pela posse de informação. Ele sabe que não vai ser respeitado por isso. O que funciona é a capacidade de relacionamento, a capacidade de estabelecer conexões e alianças. Ele vai estabelecer sua liderança de maneira colaborativa.
Leia mais:
Qual é a sua, geração Y?
Professor da FGV explica a geração Y
Faltam profissionais de TI habilitados
Apesar da crise internacional, o mercado de TI continua em evolução para suportar a remodelagem dos processos das empresas e garantir o avanço estratégico. E nesse cenário, continua aquecida a busca por profissionais que, além de qualificados tecnicamente, possuam algumas características importantes de inteligência emocional.
Para estar inserido dentro deste mercado em crescimento, é preciso mostrar mais do que a bagagem profissional e acadêmica diferenciada. O candidato ideal deve reunir competências técnicas e comportamentais para o cargo.
De acordo com um estudo realizado pelo Comitê Gestor da Internet-Brasil, 42% das 188 empresas brasileiras (da área de TI) com mais de 100 funcionários tentaram contratar especialistas em TI em 2006. Dessas, 1/3 tiveram dificuldade para achar pessoal com a qualificação necessária: 80% reclamaram da falta de qualificação, 54% reclamaram da pouca oferta de mão-de-obra e outros 54% reclamaram da falta de experiência dos profissionais.
O profissional de TI tem que estar constantemente preocupado com a sua carreira e de olho no mercado e na evolução da tecnologia, que ocorre todos os dias. O setor de TI se renova constantemente e o profissional tem que saber se reinventar completamente.
Mais referências no TI Master.
Para estar inserido dentro deste mercado em crescimento, é preciso mostrar mais do que a bagagem profissional e acadêmica diferenciada. O candidato ideal deve reunir competências técnicas e comportamentais para o cargo.
De acordo com um estudo realizado pelo Comitê Gestor da Internet-Brasil, 42% das 188 empresas brasileiras (da área de TI) com mais de 100 funcionários tentaram contratar especialistas em TI em 2006. Dessas, 1/3 tiveram dificuldade para achar pessoal com a qualificação necessária: 80% reclamaram da falta de qualificação, 54% reclamaram da pouca oferta de mão-de-obra e outros 54% reclamaram da falta de experiência dos profissionais.
O profissional de TI tem que estar constantemente preocupado com a sua carreira e de olho no mercado e na evolução da tecnologia, que ocorre todos os dias. O setor de TI se renova constantemente e o profissional tem que saber se reinventar completamente.
Mais referências no TI Master.
2009/06/02
JavaOne 2009 (II)
Abertura do JavaOne 2009, sem shows ou pirotecnia, seco e objetivo, como está no manual de contenção de custos. E com menos gente, função da crise mundial, da gripe A H1N1 e das incertezas em relação à fusão Oracle+Sun.
Jonathan Schwartz começou falando da promoção à inovação constante no desenvolvimento de novas soluções e à dimensão que Java assumiu no mundo.
Apresentou o exemplo do eBay, como aplicação de Java em escalablidade e processamento massivo.
A RIM foi chamada para demostrar o uso de Java em aplicações nos BlackBerry.
Sony Blu-ray Disc exibiu filmes e mais um editor de multimídia, que está sendo usado para produzir discos Blu-ray e trailers de filmes. O pessoal de editoração é que vai gostar, e a Adobe também vai querer fazer um igual (se pagar a patente).
Verizon Wireless informou sobre o uso de Java em suas redes móveis pelo mundo.
Intel apareceu com a iniciativa "Intel Everywhere", copiando uma ideia do Java e mostrando que tem processadores para todos os gostos e aparelhos, além de servidores, é claro.
JavaFX continua como assunto, agora mais estável. Eles ainda apresentaram um editor visual para a plataforma, do tipo WYSWYG e em tempo real, com exemplos da editoração de cenas de filmes e menus de interação.
Java FX for Digital TV também foi promovida, ao menos dentro no padrão norte-americano para TV digital.
Na sequência subiu ao palco o Dr. James Gosling, com sua camiseta sobre a Java Store, onde qualquer desenvolvedor pode ofertar sua aplicação desktop pronta, com variados preços e deploy automático para o computador do usuário.
Java Games, com o projeto Jagex e o game Rune Scape, que joga-se online e totalmente em Java. Isso é sinal de uma nova geração de games, que pode se tornar a nova alavanca para as tecnologias Java, assim como tem sido para o desenvolvimento e crescimento da capacidade de processamento das CPUs. Se os games impulsionam novas CPUs, porque não impulsionar o Java?
Um projeto premiado foi o Alice.org, ambiente de programação 3D que permite a criação de histórias animadas, jogos interativos, compartilhamento de vídeo, como forma de ensinar conceitos de computação aplicada para as crianças a partir dos seis anos de idade. Que pena que hoje só está disponível em inglês.
Na sequência subiu ao palco Scott McNealy, e desceu Jonathan Schwartz. Será que isso significa alguma coisa?
McNealy e Gosling exibiram um vídeo relacionando a vida de um garoto americano, de origem indiana, de quatorze anos de idade com a história da plataforma Java. E lembraram que Java está espalhado pelo mundo, e que esse garoto tem estudado Java.
McNealy ficou no palco e contou mais algumas coisas sobre a evolução do Java e começou a falar sobre as dúvidas que tanto o mercado quanto a comunidade tem sobre o futuro da Sun e do Java.
Para surpresa geral ele chamou ao palco Larry Ellison, que ninguém tinha visto entrar, mas que estava na plateia.
Ellison informou que Java está em todo o lugar, que a Oracle depende do Java e que vão continuar investindo em Java e na comunidade de desenvolvedores (aplausos...). Continuou falando sobre JavaFX (lógico como concorrente do SilverLight e do Flash), OpenOffice e StarOffice, e sobre vários programas que não sofrerão modificações no desenvolvimento. No final deu um adeus para todos e partiu (talvez para embarcar no helicóptero que já estava esperando em algum lugar).
Os empregados e relacionados com a Sun estão proibidos de falar qualquer coisa sobre o andamento da fusão com a Oracle, até mesmo por causa das regras do mercado norte-americano. Mas é certo que um clima de demissão paira no ar, e eu tenho sentido isso de vários lados, até em conversas informais com empregados de longa data da Sun.
Quanto à data do JavaOne 2010? Este ano a organização não antecipou nenhum planejamento. E fica a pergunta: Será que vai ter JavaOne em 2010?
Jonathan Schwartz começou falando da promoção à inovação constante no desenvolvimento de novas soluções e à dimensão que Java assumiu no mundo.
Apresentou o exemplo do eBay, como aplicação de Java em escalablidade e processamento massivo.
A RIM foi chamada para demostrar o uso de Java em aplicações nos BlackBerry.
Sony Blu-ray Disc exibiu filmes e mais um editor de multimídia, que está sendo usado para produzir discos Blu-ray e trailers de filmes. O pessoal de editoração é que vai gostar, e a Adobe também vai querer fazer um igual (se pagar a patente).
Verizon Wireless informou sobre o uso de Java em suas redes móveis pelo mundo.
Intel apareceu com a iniciativa "Intel Everywhere", copiando uma ideia do Java e mostrando que tem processadores para todos os gostos e aparelhos, além de servidores, é claro.
JavaFX continua como assunto, agora mais estável. Eles ainda apresentaram um editor visual para a plataforma, do tipo WYSWYG e em tempo real, com exemplos da editoração de cenas de filmes e menus de interação.
Java FX for Digital TV também foi promovida, ao menos dentro no padrão norte-americano para TV digital.
Na sequência subiu ao palco o Dr. James Gosling, com sua camiseta sobre a Java Store, onde qualquer desenvolvedor pode ofertar sua aplicação desktop pronta, com variados preços e deploy automático para o computador do usuário.
Java Games, com o projeto Jagex e o game Rune Scape, que joga-se online e totalmente em Java. Isso é sinal de uma nova geração de games, que pode se tornar a nova alavanca para as tecnologias Java, assim como tem sido para o desenvolvimento e crescimento da capacidade de processamento das CPUs. Se os games impulsionam novas CPUs, porque não impulsionar o Java?
Um projeto premiado foi o Alice.org, ambiente de programação 3D que permite a criação de histórias animadas, jogos interativos, compartilhamento de vídeo, como forma de ensinar conceitos de computação aplicada para as crianças a partir dos seis anos de idade. Que pena que hoje só está disponível em inglês.
Na sequência subiu ao palco Scott McNealy, e desceu Jonathan Schwartz. Será que isso significa alguma coisa?
McNealy e Gosling exibiram um vídeo relacionando a vida de um garoto americano, de origem indiana, de quatorze anos de idade com a história da plataforma Java. E lembraram que Java está espalhado pelo mundo, e que esse garoto tem estudado Java.
McNealy ficou no palco e contou mais algumas coisas sobre a evolução do Java e começou a falar sobre as dúvidas que tanto o mercado quanto a comunidade tem sobre o futuro da Sun e do Java.
Para surpresa geral ele chamou ao palco Larry Ellison, que ninguém tinha visto entrar, mas que estava na plateia.
Ellison informou que Java está em todo o lugar, que a Oracle depende do Java e que vão continuar investindo em Java e na comunidade de desenvolvedores (aplausos...). Continuou falando sobre JavaFX (lógico como concorrente do SilverLight e do Flash), OpenOffice e StarOffice, e sobre vários programas que não sofrerão modificações no desenvolvimento. No final deu um adeus para todos e partiu (talvez para embarcar no helicóptero que já estava esperando em algum lugar).
Os empregados e relacionados com a Sun estão proibidos de falar qualquer coisa sobre o andamento da fusão com a Oracle, até mesmo por causa das regras do mercado norte-americano. Mas é certo que um clima de demissão paira no ar, e eu tenho sentido isso de vários lados, até em conversas informais com empregados de longa data da Sun.
Quanto à data do JavaOne 2010? Este ano a organização não antecipou nenhum planejamento. E fica a pergunta: Será que vai ter JavaOne em 2010?
2009/06/01
Cloud e as Linguagens de Programação
Este foi o assunto de uma das palestras que me chamou a atenção no Community One West.
A pergunta na minha cabeça era: Como desenvolver para ambiente Cloud, facilmente?
A palestra foi meramente expositiva, sem demonstrações ou gráficos mais apurados. E minha pergunta não foi respondida... Mas alguns informações foram interessantes.
Asynchronous Messaging: Utilização de sistemas com alto grau de assincronia, dado que você não tem ideia sobre onde e quando os seus parceiros de processamento vão responder.
Leads to a Service Oriented System: Como quase tudo é assíncrono, arquitetura orientada a serviços parece ser parte da solução.
Quality of the Integration: O software que você disponibiliza depende da qualidade da integração entre os variados e diversos ambientes de Back-End da Cloud.
Heterogeneous: O sistema operacional e o servidor de aplicações podem ser qualquer "coisa".
Main Memory as a Database: A memória utiliza pela aplicação se mistura ao que poderia ser o próprio banco de dados. Nesse ponto é difícil definir os limites do que você pode usar, porque sua memória de processamento pode ser infinita e assíncrona, porém algumas transações ainda tem problemas para realizar "rollback".
Security: Por exemplo: Onde está a minha DMZ? Onde está meu servidor? Ondes estão meus usuários? O que proteger?
Language Models: Sandboxing VS Capabilities
Fora Java e o Google App Engine, eu nunca tinha ouvido falar em Pypy, Caja, Joe-E...
Data Center Sizes: O tamanho dos centros de processamento é um problema, em função de custo e questões ambientais. O objetivo é ter máximo performance com o menor número de servidores, e nessa entram os sistemas Multi-Core.
Parte do que temos para nos preocupar é isso aí.
A pergunta na minha cabeça era: Como desenvolver para ambiente Cloud, facilmente?
A palestra foi meramente expositiva, sem demonstrações ou gráficos mais apurados. E minha pergunta não foi respondida... Mas alguns informações foram interessantes.
Asynchronous Messaging: Utilização de sistemas com alto grau de assincronia, dado que você não tem ideia sobre onde e quando os seus parceiros de processamento vão responder.
Leads to a Service Oriented System: Como quase tudo é assíncrono, arquitetura orientada a serviços parece ser parte da solução.
Quality of the Integration: O software que você disponibiliza depende da qualidade da integração entre os variados e diversos ambientes de Back-End da Cloud.
Heterogeneous: O sistema operacional e o servidor de aplicações podem ser qualquer "coisa".
Main Memory as a Database: A memória utiliza pela aplicação se mistura ao que poderia ser o próprio banco de dados. Nesse ponto é difícil definir os limites do que você pode usar, porque sua memória de processamento pode ser infinita e assíncrona, porém algumas transações ainda tem problemas para realizar "rollback".
Security: Por exemplo: Onde está a minha DMZ? Onde está meu servidor? Ondes estão meus usuários? O que proteger?
Language Models: Sandboxing VS Capabilities
Fora Java e o Google App Engine, eu nunca tinha ouvido falar em Pypy, Caja, Joe-E...
Data Center Sizes: O tamanho dos centros de processamento é um problema, em função de custo e questões ambientais. O objetivo é ter máximo performance com o menor número de servidores, e nessa entram os sistemas Multi-Core.
Parte do que temos para nos preocupar é isso aí.
Community One West 2009
O primeiro dia de eventos em San Francisco não é no JavaOne, e sim no Community One West, que este ano irá durar três dias consecutivos.
Como é um evento gratuito, deve atrair o público que esta somente agora pensando em Java (ou quem já cansou do Java).
A direção do C1-W esta para o Cloud Computing, mas tem espaço para vários assuntos relativos aos sistemas não Java e recursos open-source.
O que ocorreu no C1-W você pode encontar no website do evento.
E, diferente dos outros anos o Pavilion abriu já na segunda-feira, durante o C1-W, com a ausência de três empresas importantes: Oracle, IBM e SAP. Porém ele está bem mais popular e com mais desenvolvedores independentes que no ano passado.
Como é um evento gratuito, deve atrair o público que esta somente agora pensando em Java (ou quem já cansou do Java).
A direção do C1-W esta para o Cloud Computing, mas tem espaço para vários assuntos relativos aos sistemas não Java e recursos open-source.
O que ocorreu no C1-W você pode encontar no website do evento.
E, diferente dos outros anos o Pavilion abriu já na segunda-feira, durante o C1-W, com a ausência de três empresas importantes: Oracle, IBM e SAP. Porém ele está bem mais popular e com mais desenvolvedores independentes que no ano passado.
JavaOne 2009 (I)
Cheguei sábado (30/Maio) à San Francisco, após uma viagem de 25 horas a partir do Rio de Janeiro. Os dois vôos em que eu estava foram dentro dos horários previstos, e sempre com avião lotado.
Este ano EU e o Clayton Chagas vamos apresentar no JavaOne 2009 a Technnical Session: Java™ in the Brazilian Digital TV: Interactivity and Digital Inclusion on TV.
No sábado já comecei a vislumbrar o impacto da crise internacional por aqui: diminuiu a quantidade de carros nas ruas e várias lojas fecharam. No entanto achei que o número de "HomeLess" no entordo da Union Square diminuiu.
No domingo (31/Maio) fomos à uma BestBuy para ver as ofertas de hardware. Poucas ofertas e muitos produtos fora do estoque na área de computadores. Em compensação, metade da loja estava dedicada aos games da Nintendo, Sony e Microsoft.
Falando em Sony, das duas lojas que ela tinha no Metreon Shopping, a de computadores já fechou, e a de games vai fechar em três meses, além de não ter nenhuma console no estoque (somente os DVDs de software/jogos).
No final da tarde do mesmo domingo, fomos ao Moscone Center para fazer o Check-In dos eventos. Como era domingo, não tinha fila, mas acho também que é porque vem pouca gente para o JavaOne este ano.
Depois do credenciamento fomos pegar os brindes... A mochila é diferente, e na minha opinião inferior à do ano passado. Uma camisa XL padrão para todo mundo, sem interessar se você tem 1,50 m ou 1,90 m de altura. E não veio nenhuma canetinha ou bloco de anotações.
Saindo do Moscone no domingo (já era umas 19:00 horas) só restava se preocupar com o Jantar, aprontar detalhes da apresentação e dormir, porque no dia seguinte começa o Community One West.
Um colega foi à GlassFish Unconference, no domingo mesmo, após termos pego os brindes, e ficou por lá. À noite ele me deu a informação de que o pessoal do GlassFish está realmente com medo de o App Server ser descontinuado, em função da fusão com a Oracle.
O blog de outro amigo, o Felipe Gaúcho, também é uma boa fonte de informações este ano, porque ele está registrado como Press e vai publicar conteúdo com frequência.
Serge Rehem, grande amigo do JavaBahia também está publicando este ano, direto de San Francisco.
E fusão da Oracle será o tema de bastidores este ano, já que os temas principais são Cloud Computing e TV Digital.
Este ano EU e o Clayton Chagas vamos apresentar no JavaOne 2009 a Technnical Session: Java™ in the Brazilian Digital TV: Interactivity and Digital Inclusion on TV.
No sábado já comecei a vislumbrar o impacto da crise internacional por aqui: diminuiu a quantidade de carros nas ruas e várias lojas fecharam. No entanto achei que o número de "HomeLess" no entordo da Union Square diminuiu.
No domingo (31/Maio) fomos à uma BestBuy para ver as ofertas de hardware. Poucas ofertas e muitos produtos fora do estoque na área de computadores. Em compensação, metade da loja estava dedicada aos games da Nintendo, Sony e Microsoft.
Falando em Sony, das duas lojas que ela tinha no Metreon Shopping, a de computadores já fechou, e a de games vai fechar em três meses, além de não ter nenhuma console no estoque (somente os DVDs de software/jogos).
No final da tarde do mesmo domingo, fomos ao Moscone Center para fazer o Check-In dos eventos. Como era domingo, não tinha fila, mas acho também que é porque vem pouca gente para o JavaOne este ano.
Depois do credenciamento fomos pegar os brindes... A mochila é diferente, e na minha opinião inferior à do ano passado. Uma camisa XL padrão para todo mundo, sem interessar se você tem 1,50 m ou 1,90 m de altura. E não veio nenhuma canetinha ou bloco de anotações.
Saindo do Moscone no domingo (já era umas 19:00 horas) só restava se preocupar com o Jantar, aprontar detalhes da apresentação e dormir, porque no dia seguinte começa o Community One West.
Um colega foi à GlassFish Unconference, no domingo mesmo, após termos pego os brindes, e ficou por lá. À noite ele me deu a informação de que o pessoal do GlassFish está realmente com medo de o App Server ser descontinuado, em função da fusão com a Oracle.
O blog de outro amigo, o Felipe Gaúcho, também é uma boa fonte de informações este ano, porque ele está registrado como Press e vai publicar conteúdo com frequência.
Serge Rehem, grande amigo do JavaBahia também está publicando este ano, direto de San Francisco.
E fusão da Oracle será o tema de bastidores este ano, já que os temas principais são Cloud Computing e TV Digital.
2009/03/08
RIA
(Rich Internet Applications)
São aplicações executadas em browsers internet, como Firefox ou Internet Explorer, no contexto de uma página XHTML e que possuem recursos audio-visuais semelhantes aos que existem em aplicações puramente desktop ou standalone.
Podem ser construídas utilizando uma ou mais das ferramentas listadas abaixo:
São aplicações executadas em browsers internet, como Firefox ou Internet Explorer, no contexto de uma página XHTML e que possuem recursos audio-visuais semelhantes aos que existem em aplicações puramente desktop ou standalone.
Podem ser construídas utilizando uma ou mais das ferramentas listadas abaixo:
- Java Applets
- JavaScript
- DHTML
- XML
- MS ActiveX Controls
- MS SilverLight
- Macromedia Flash
- Adobe Flex
- Sun JavaFX
- SAP WebDynpro
- OpenLaszlo
- AJAX
RSS
(Really Simple Syndication – 2.0)
- Arquivo XML: RSS Feed, WebFeed, Atom.
- Um dos melhores desenvolvimentos depois do CGI.
- Assinaturas de um serviço ou publicação na Web, de forma assíncrona.
- Agregadores de conteúdo dinâmico diverso.
- O publicador do conteúdo mantém o respectivo público atualizado a cada novidade.
- Permite uma combinação adequada entre conteúdo fixo e conteúdo dinâmico.
Blog
- Diário pessoal.
- Opinião individual.
- Organização cronológica.
- Palavras chaves.
- Edição em qualquer dispositivo, a qualquer hora, em qualquer lugar.
- Troca de comentários livres com os leitores e o público.
- “Nós somos a mídia!”
Assinar:
Postagens (Atom)