TAG | criação
Realmente o lançamento do Windows 8 será um marco para a Microsoft e talvez até mesmo para a computação pessoal, pois além de alterar totalmente a semântica, funcionamento e usabilidade do Windows, implementando inclusive um novo conceito de interface, o Metro a Microsoft dará adeus até mesmo para a famosa logomarca do Windows.
Desde a versão 3.1 do Windows a sua logomarca foi remodelada, mas sempre conservou a mesma identidade, codificada em quatro cores lembrando uma bandeira tremulando, contudo a nova logomarca do Windows será plana (como todas as logomarcas atuais, ainda bem que abandonaram o 3D) e realmente irá remeter a uma janela.
Nova logomarca do Windows
De tão simples e não intrusiva a nova logomarca parece se encaixar perfeitamente para a nova linha de pensamento utilizada no desenvolvimento do Windows, que finalmente abandonou certos módulos do kernel que ainda o prendiam ao baixo desempenho por serem antigos e cheio de remendos, agora realmente será um novo Windows.
Leia mais:
O QlikView tem a capacidade de acessar uma infinidade de bases de dados, via ODBC, para realizar suas consultar ou mesmo para criar suas nuvens de dados (QVD).
Porém, por diversos motivos, as empresas encontram ao passar do tempo à necessidade de controlar algum tipo de processo empresarial a partir do Excel, moldando uma planilha eletrônica como se fosse uma “tela” do seu sistema corporativo e como passar o controle desta planilha para o QlikView?
Muito simples, o primeiro passo é colocar uma cópia desta planilha em uma pasta qualquer que o QlikView server tenha acesso.
Após este passo, é necessário ler de fato esta planilha Excel, para isso segue um breve exemplo para uma planilha com duas colunas:
LOAD @1 AS coluna1, @2 AS coluna2 FROM pasta\arquivo.xls (biff, no labels, TABLE IS Planilha1$); |
Explicando o código, é muito parecido com o acesso a dados realizado a uma tabela qualquer, na verdade você terá que declarar a planilha como uma tabela.
- As colunas: o @1 e @2 são o que me indica a coluna 1 e coluna 2 respectivamente, após isso, eu declaro um alias para as colunas, é por este alias que conseguirei acessar os dados assim como os dados resgatados de uma tabela qualquer.
- Pasta de trabalho: logo após o comando from eu irei colocar o path e nome da pasta de trabalho.
- Planilha: feito isso eu executo o comando table para definir que a planilha1 é a fonte de origem dos dados e deverá ser a nossa “tabela”.
Feito isso, poderei visualizar a planilha no Visualizar de Tabelas do QlikView como se fosse uma tabela qualquer, montando inclusive relacionamentos concluindo o MER da consulta.
Nota: erroneamente, as pessoas chamando a pasta de trabalho do Excel de planilha, na verdade a pasta de trabalho é o arquivo XLS que podem conter várias planilhas e por sua vez as planilhas são as abas.
Leia mais:
Sim, é isso mesmo que você acabou de ler no título.
O layout é 90% da informação, não só falando de sistemas de informação, mas de qualquer informação que você absorve no meio em que está.
Quem aqui nunca se rendeu a um produto com um rótulo bonitinho (mesmo que o produto não fosse tão bom), quem aqui nunca acho lindo um relatório cheio de gráficos (mesmo que outro relatório tinha informações de maior qualidade sem os gráficos).
De pouco adianta se você fornece informações de altíssima qualidade, mas sem nenhuma regra de layout, com a disposição e formatação das informações totalmente desgrenhada. Se o seu concorrente fornecer um nível menor de informações, porém com alta acuracidade visual o projeto será fechado com ele.
Quer atingir a perfeição, ou pelo menos chegar perto?
Equilíbrio.
Isso mesmo equilibre o nível de informação com a apresentação adicionando um bom impacto visual. Você será imbatível, ou só se deixará abater se usarem criptonita.
Leia mais:
Os DBA´s mais puristas irão jogar pedras e dizer que não se deve gravar campo calculado, o ideal é deixar que o software ou uma rotina interna do próprio banco de dados resgate os valores e faça o cálculo devolvendo o resultado.
Eu digo que o desenvolvedor deve decidir isso.
Por quê?
Porque nunca um software é 100% igual à outra, temos sim, regras genéricas que servem para nortear os métodos de desenvolvimento de software e para evitar que coisas bizarras ocorram, mas nunca devemos seguir cegamente, pois em casos específicos isso pode comprometer o seu software.
No caso do campo calculado digo que a grande maioria dos casos a regra da engenharia que diz que não devemos gravar em tabela campos calculados irá prevalecer e ser a melhor saída, mas casos específicos podem indicar completamente ao contrário.
Um exemplo disso é o problema de performance, imagine a sua rotina de cálculo:
- É preciso buscar os dados para o cálculo do banco de dados;
- A operação matemática é realizada;
- O resultado é devolvido.
Nas duas primeiras etapas podemos ter um gargalo, ou no acesso aos dados ou no processamento em si da operação matemática e para ajudar se a sua aplicação exigir que a rotina seja executada diversas vezes em curtos espaços de tempo, a forma tida como correta pode comprometer a performance de todo o sistema.
É por isso que sempre digo que nunca devemos ter programadores e sim desenvolvedores, pois profissionais qualificados devem saber até mesmo quando agir na exceção a regra com o intuito de obter o melhor produto possível.
Os DBA´s mais puristas irão jogar pedras e dizer que não se deve gravar campo calculado, o ideal é deixar que o software ou uma rotina interna do próprio banco de dados resgate os valores e faça o cálculo devolvendo o resultado.
Eu digo que o desenvolvedor deve decidir isso.
Por quê?
Porque nunca um software é 100% igual à outra, temos sim, regras genéricas que servem para nortear os métodos de desenvolvimento de software e para evitar que coisas bizarras ocorram, mas nunca devemos seguir cegamente, pois em casos específicos isso pode comprometer o seu software.
No caso do campo calculado digo que a grande maioria dos casos a regra da engenharia que diz que não devemos gravar em tabela campos calculados irá prevalecer e ser a melhor saída, mas casos específicos podem indicar completamente ao contrário.
Um exemplo disso é o problema de performance, imagine a sua rotina de cálculo:
·
Os DBA´s mais puristas irão jogar pedras e dizer que não se deve gravar campo calculado, o ideal é deixar que o software ou uma rotina interna do próprio banco de dados resgate os valores e faça o cálculo devolvendo o resultado.
Eu digo que o desenvolvedor deve decidir isso.
Por quê?
Porque nunca um software é 100% igual à outra, temos sim, regras genéricas que servem para nortear os métodos de desenvolvimento de software e para evitar que coisas bizarras ocorram, mas nunca devemos seguir cegamente, pois em casos específicos isso pode comprometer o seu software.
No caso do campo calculado digo que a grande maioria dos casos a regra da engenharia que diz que não devemos gravar em tabela campos calculados irá prevalecer e ser a melhor saída, mas casos específicos podem indicar completamente ao contrário.
Um exemplo disso é o problema de performance, imagine a sua rotina de cálculo:
- É preciso buscar os dados para o cálculo do banco de dados;
- A operação matemática é realizada;
- O resultado é devolvido.
Nas duas primeiras etapas podemos ter um gargalo, ou no acesso aos dados ou no processamento em si da operação matemática e para ajudar se a sua aplicação exigir que a rotina seja executada diversas vezes em curtos espaços de tempo, a forma tida como correta pode comprometer a performance de todo o sistema.
É por isso que sempre digo que nunca devemos ter programadores e sim desenvolvedores, pois profissionais qualificados devem saber até mesmo quando agir na exceção a regra com o intuito de obter o melhor produto possível.
É preciso buscar os dados para o cálculo do banco de dados;
· A operação matemática é realizada;
· O resultado é devolvido.
Nas duas primeiras etapas podemos ter um gargalo, ou no acesso aos dados ou no processamento em si da operação matemática e para ajudar se a sua aplicação exigir que a rotina seja executada diversas vezes em curtos espaços de tempo, a forma tida como correta pode comprometer a performance de todo o sistema.
É por isso que sempre digo que nunca devemos ter programadores e sim desenvolvedores, pois profissionais qualificados devem saber até mesmo quando agir na exceção a regra com o intuito de obter o melhor produto possível.
Leia mais:
Certificação é realmente necessária?
Essa é uma pergunta que praticamente todos os profissionais de TI fazem e que também assombram algumas empresas.
Realmente na hora da procura por um novo emprego, incluir em seu currículo que possui certificação é um diferencial importante para derrubar a concorrência, porém em uma situação prática (a empresa contrata o profissional e o coloca para trabalhar no dia a dia) já vi ocorrer os seguintes casos:
- Profissional certificado e que tem profundo conhecimento teórico, porém na prática não faz quase nada, ou seja, embora seja certificado e tenha embasamento teórico, por uma série de motivos não consegue colocar o conhecimento teórico na prática;
- Profissional sem certificação e que por vivência e aprendizagem prática, no dia a dia apresenta alto desempenho;
- Profissional certificado e que por vivência e aprendizagem prática tem grande capacidade e muitas vezes serve de exemplo para outros membros da equipe. Nem preciso comentar que um profissional assim pode elevar e muito o nível geral de toda a equipe e servir de fonte de motivação para os demais.
Nem preciso dizer que a certificação é apenas um fator, que não adianta ficar nesse oba-oba como costumo observar em algumas empresas, onde ao contratar alguém certificado, fazem de tudo para nivelar por baixo e rebaixar os profissionais que já fazem parte do quadro de funcionários, desmotivando e muitos vezes incitando atritos dentro da equipe. Além de que empresas assim querem contratar um profissional perfeito e pagar o valor que pagariam para um auxiliar.
Não sou contra a certificação, aliás, eu sou a favor, mas apenas ressalto que o mais importante é unir o conhecimento teórico que uma certificação trará a uma vivência prática tornando-se assim um profissional melhor de fato e não apenas um profissional que coleciona títulos, mas no fundo nem sabe fazer o básico (embora tenha conhecimento técnico para produzir um livro (teoria, lembram?)).
Leia mais:
Heterogêneo. Guarde bem esta palavra.
Mesmo com a Cloud Computing ativa e navegando a fortes ventos, é bem provável que este termo ainda atrapalhe a área de TI e desenvolvimento de software por muitos anos, afinal hoje temos uma salada de plataformas, linguagens de desenvolvimento e IDE´s que no final das contas criar compatibilidade entre todo mundo se torna uma missão impossível.
Mas no meio de toda essa bagunça algo me assustou muito, já temos que diariamente optarmos pelo caminho X ou Y em TI, seja na área de infra ou desenvolvimento de software sempre temos que escolher entre uma plataforma em detrimento da outra, vejo um desenvolvedor de software com o seguinte ambiente de desenvolvimento montado:
- Computador de desenvolvimento: um Mac;
- Linguagem escolhida: .Net;
- Plataforma de execução da aplicação final: Linux.
Vendo tudo isso, penso que só podem existir duas situações para a aberração que citei acima:
- O profissional é novato e não sabe lhufas do que está fazendo;
- Ou ele está pagando alguma promessa.
Será que ele já se deu conta do trabalho extra que terá desde a faze de desenvolvimento até a faze de homologação da solução desenvolvendo software em um ambiente tão antagônico assim?
O mundo já é heterogêneo o bastante, não precisamos complicar ainda mais a situação.
Leia mais:
Realmente temos que convir que criatividade é tudo.
Seja no mundo dos negócios, no lazer e onde mais você estiver. Se for criativo o suficiente terá destaque perante os demais.
Tanto isso é fato que um pessoal fez o vídeo de computação analógica. Ficou show.
The Art of Analog Computing from meltmedia on Vimeo.
Tem gente que vai tacar pedra e dizer que é um bando de gente desocupada, mas existe forma melhor que mostrar a capacidade, talento e criatividade de cada um?
Provavelmente terá um alcance (e consequentemente retorno) maior do que se cada um deles fosse espalhar o próprio currículo.
Fonte: Sedentário
Leia mais:
Tipografia na Web, agora existe sim
Sem comentários · Post por Petter Rafael em Imagem & Criação, Webdesign
Muitos designers, geralmente os que possuem pouca experiência, trocam blocos de texto por imagens, pelo simples fato que não podem garantir que o usuário que acessar o site terá determinado tipo de fonte utilizado.
Agora esse problema está praticamente solucionado, com suporte para o Internet Explorer versões 7, 8 e 9 com fontes EOT e Firefox, Opera, Chrome e Safari para fontes TTF e OTF agora é possível definir uma fonte remota para ser utilizada no site.
A funcionalidade @font-face do CSS é empregada para esse fim, porém em conexões lentas o designer do site se primeiro renderizado para depois a fonte ser carregada (lembre-se que a fonte agora é remota) o que pode frustar um pouco, mas também podemos contornar esse problema (e economizar banda) definindo para que primeiro a fonte seja utilizada local e somente se não existir que seja utilizada a fonte remota.
Observe o código abaixo:
@font-face { font-family: nome_familia_fonte; src: local(sua_fonte.otf), url(sua_fonte.otf); } |
Note que primeiro definimos a fonte local, para depois definirmos a fonte remota.
Veja também um exemplo de como utilizar o @font-face criado:
p { font:36px helveticaneue, Arial, Tahoma, Sans-serif; } |
Fonte: Tableless
Leia mais:
criação · design · webdesigner
O conceito de realidade aumentada não é assim algo tão novo (na verdade começou em 15.000 ac), mas nesses últimos meses tem virado hype pela Internet, e isso se deve ao fato de que algumas publicações de conteúdo adulto estão empregando a técnica de interação do usuário via webcam com vídeos de modelos.
Realidade aumentada na Internet tem se apoiado em RIA e com conexões cada vez mais rápidas é uma forma inteligente de trazer um nível maior de interação do usuário com o seu produto Web.
Agora só falta aquela história de Internet com cheiro realmente funcionar.
Leia mais:
Hoje a interação entre softwares é ampla e fácil de ser implementada, assim não é preciso reinventar a roda toda vez que surge a necessidade de desenvolver um recurso novo para o seu software, porém essa interação deve ser implementada com muito cuidado.
Pois caso seja implementada sem um devido estudo o tiro pode sair pela culatra. Quer entender melhor? Imagine a seguinte situação:
Você precisa que o seu CRUD de cadastro de clientes insira no momento do cadastro ou atualização do mesmo uma foto do seu cliente, basicamente essa foto será feita por uma webcam. Será que preciso escrever código para que a sua aplicação comunique com a webcam e obtenha a imagem? Dependendo da sua ferramenta de desenvolvimento ou de seu nível de conhecimento isso pode ser uma tarefa árdua e o pior, pode atrasar todo o projeto e deixar o cliente irritado.
A solução então é instalar o software de comunicação que vem junto com a própria webcam e fazer a sua aplicação executa-lo e depois apenas “ler” onde a imagem foi salva para que a sua aplicação enfim obtenha a foto, simples não? Em questão de poucas horas a solução já pode estar implementada e em produção.
Mas observe por outro ângulo, fazendo isso o seu software além de estar acoplado a marca (fabricante) da webcam (o seu hardware) também estará acoplado ao seu modelo e até mesmo a aplicação de comunicação (o seu software) fornecida pelo fabricante da webcam. Isso gera de imediato os seguintes modelos:
- Cada vez que o fabricante alterar o software de comunicação, você fatalmente terá que efetuar mudanças na sua aplicação;
- O cliente terá que comprar webcam iguais as que você utilizou na fase de desenvolvimento;
- Se uma webcam quebrar com o tempo de uso e o seu modelo for descontinuado, o seu software terá que lidar com N tipos de webcam diferentes e suas aplicações de comunicação o que poderá ser um grande problema em potencial.
Viram o problema que podemos ter acoplando em demasia a nossa aplicação a algum recurso, seja ele de software ou hardware? O ideal é que nossa aplicação não fosse acoplada a nada, nem mesmo a plataforma, mas isso é impossível no dia-a-dia. Qual a saída para o caso proposto?
Mesmo que pareça reinventar a roda, o ideal era que a aplicação CRUD do exemplo acima fizesse por si só a leitura da porta USB da webcam para obter diretamente a imagem, isso a princípio seria um incomodo, mas no desenrolar dos fatos é sem dúvida a melhor saida.
Pois o seu cliente estaria livre para utilizar uma série de webcam’s diferentes, pois o seu hardware segue um certo padrão, ou seja a sua aplicações estaria preparada para uma infinidade de usos e uma diversidade de ambientes de execução.
Então? A sua aplicação é ou não acoplada ao ambiente de execução?
