O Visual Studio 2010 tem diversos recursos que estão muito bem escondidos nos seus vários menus e telas de configuração, mas são acessíveis por teclas de atalho. Isso é vantajoso em diversas situações pois pode agilizar a utilização desses recursos mas também pode se tornar uma irritação ou mesmo um problema se você por acaso acionar uma dessas teclas de atalho por acidente e não souber como voltar atrás. Foi o que aconteceu com um colega no trabalho recentemente.

Por acidente esse colega acionou uma tecla de atalho do Visual Studio 2010 que ativa a exibição de caracteres ocultos (white space). Em outras palavras, o Visual studio passou a exibir todos os espaços e marcação de final de arquivo na tela. O resultado foi algo semelhante ? imagem abaixo:

Não parece ser algo muito irritante neste exemplo pois há pouco código, mas em arquivos com centenas de linhas de código e em arquivo com html esse modo de visualização é bastante irritante e chega a atrapalhar a produtividade pois polue visualmente a tela. Esse colega passou quase 2 meses trabalhando com essa configuração pois não conseguia encontrar um meio de desfazer e voltar ao modo normal de visualização. Ele chegou inclusive a reinstalar o Visual Studio mas não adiantou pois o instalador não removeu as configurações problematicas.

Hoje eu dei uma pesquisada um pouco mais a fundo e acabei encontrando a solução. A opção do menu para essa configuração se encontra em Edit > Advanced > View White Space e pode ser acionada pela tecla de atalho Ctrl+E, S (que foi o que aconteceu com meu colega).

2012 será mais um ano de ascensão dos dispositivos mobile em todo o mundo. Mesmo que aqui no Brasil tudo seja mais lento, com preços mais altos, estamos seguindo em frente. Já temos frameworks javascript adaptados ? s telinhas, como o Sencha, ? e o jQueryMobile, além do Flex Mobile, claro. Outras tecnologias estão crescendo a cada dia, e a quantidade de informação que é “jogada” para nós programadores aumenta em um ritmo alucinante. Seguindo esta tendência, estamos também nos adaptando, e para que tudo fique bem claro ao leitor, decidi comentar as principais mudanças do site neste post.

Neste novo ano estaremos adotando algumas mudanças que visam melhorar a qualidade de nossas obras. As principais mudanças que estão por vir são:

1)? Fim do suporte por email: Nestes quatro anos de suporte por email, pude observar diversos prós e contras, e sempre tentei agradar a “gregos e troianos”. Nunca fiz nenhuma distinção de quem comprou ou quem não comprou meus livros, sempre respondendo as dúvidas em menos de 48 horas. Todo esse tempo foi um aprendizado enorme, e agora tenho a necessidade de “lapidar” este processo de suporte. Observei que muito das dúvidas dos leitores eram repetidas e que sempre respondia ? s mesmas questões. Observei também que, ? s vezes, dava prioridade a alguém que não tinha comprado um livro, e deixava “na fila” uma outra pessoa que tinha dúvidas relativas aos livros. Também cheguei ao ponto de responder 10, 15 e-mails por dia, tornando uma tarefa bastante trabalhosa. Neste contexto, estarei “movendo” o suporte para um fórum especial, aberto a qualquer pessoa e destinado a sanar dúvidas dos livros. Falarei mais deste fórum em um outro post, mas deixo claro que, para quem é leitor, terá como sempre o suporte 100% garantido.

2)? eBOOKs serão predominantes: Todo o processo de criação/distribuição de um ebook é perfeito aos olhos do autor se não fosse a pirataria. Realmente encontrar meus livros que consumiram várias horas de preparo e trabalho nos torrents por aí não é uma sensação boa. Mas eu quero acreditar que isso é possível! Eu quero acreditar que o brasileiro é gente honesta, que deseja pagar por um conteúdo útil sem ser “assaltado”. Por isso, em 2012, eu vou priorizar o desenvolvimento de eBooks, cobrando um preço justo, e com a meta de criar muito mais ebooks do que já foi criado atualmente.

3)? Flex não será prioridade: Nestes últimos quatro anos tenho me dedicado muito ao Flex. Fui o primeiro a escrever um livro sobre Adobe Flex no Brasil e desde então foram quase 10 livros abordando o tema. Sei que está chegando o momento em que eu terei que “dissipar” o meu conhecimento para outras áreas, pois o tema Flex já está bastante difundido, felizmente hoje em dia existe bastante conteúdo dedicado a cultura Flex e só não aprende quem não quer. Veja que, para quem escreve livros, as tecnologias saturam, mas não morrem. Este é o caso do Flex, o conteúdo está saturado, eu não tenho muito mais a escrever, por isso o foco será distribuído para outras áreas. O livro “Adobe Air em Ação” será o último livro a ser escrito para a tecnologia Flex, e não haverá mais edições previstas. O suporte continuará normalmente para quem comprou qualquer livro sobre Flex.

4)? Mobile será prioridade: Daremos certa prioridade ao desenvolvimento mobile, e dependendo de novas tecnologias que deverão surgir, estaremos pesquisando e publicando material sobre elas. Isso significa que determinados livros poderão conter menos páginas, por exemplo, 100, mas que expliquem um conceito ou tecnologia emergente.

5)? Tendências serão prioridade:? A rapidez com que uma tecnologia emerge abre uma lacuna de desinformação para nós tupiniquins. E a? idéia? é preencher esta lacuna com um livro. Por exemplo, ainda não temos um livro sobre SENSHA, muito menos EXTJS. Um livro sobre HTML 5, custa nada mais, nada menos que 73 reais. Nem temos um livro sobre a linguagem SCALA ou sobre DJANGO. Enfim, existe muito assunto para se escrever.

6)? Site flex.etc.br deixa de conter informações sobre os livros:? Todas as informações estarão no site danielschmitz.com.br. O blog flex continua, mas aos poucos deixará de ser atualizado.

Resumindo:

- Vamos publicar ebooks com qualidade e a preços atraentes, sobre diversos temas. Contamos com a aprovação de vocês, enviando críticas e sugestões, .

- Haverá um fórum dedicado ao suporte dos livros.

- Estaremos em breve publicando quais serão os primeiros eBooks a serem lançados e contamos com a sua opinião. Mande ideias !

Twitter!

Uma das vantagens de utilizar a arquitetura do Spring para implementar projetos Web, é fazer uso do Sprin-WEB-MVC. Quem já usou sabe que isso é uma vantagem a se considerar quando for feita a escolha das tecnologias e frameworks que serão utilizados no projeto.
Spring WEB-MVC é uma abstração poderosa para a camada de apresentação, tornando muito flexível o uso de diferentes tipos de tecnologias no frnt-end da aplicação.
Veremos uma dessas abstrações que ajudam a modularizar e simplificar nosso trabalho do lado do servidor: Views.

Conceito de Views

Toda requisição que segue para o WEB-MVC passa pelo DispatcherServlet do spring. A partir daí, o container se responsabiliza por delegar a chamada para o controller correto, baseando-se nas configurações de sua aplicação.
Depois que a chamada é tratada pelo controller, o spring manda a resposta correspondente atrelada a uma View. Uma View é um descritor da forma com que os dados vão ser apresentados na interface, podendo ser JSP, JSF, JSon, XML, etc., ou até mesmo uma forma de encapsular os dados específica da sua aplicação.
O poder das Views está justamente no fato de ser apenas uma descrição de como os dados serão apresentados, portanto desconecta-se completamente da aplicação, e pode ser aproveitada em outras ocasiões por outros sistemas.
Uma View no Spring nada mais é do que uma interface Java que descreve o tipo do conteúdo, e é responsável por renderizar a requisição:

Todo o código e JavaDoc está no projeto do Spring.

JSon e XML

Vamos criar um exemplo de controller com duas views diferentes: JSon e XML. JSon e Xml são os formatos mais comuns na Web, por isso vamos ver uma das maneiras de devolvê-las em nossos contrllers.
Não vou entrar no detalhe de como configurar os controllers da sua aplicação para funcionar com o Spring-WEB-MVC, pois não é o intuito deste post, e existe bastante documentação disponível na internet sobre o assunto.


A maneira que escolhi para o exemplo, foi deixar a resposta padrão da servlet como XML, e criar uma alternativa de view em JSon. Você pode configurar como quiser a ordem e o padrão de view da sua aplicação, essa escolha serve apenas para ilustar como lidar com os dois casos.
Comece criando alguma classe de domínio para servir de resposta do nosso controller:

Agora vamos criar um Controller para devolver nosso objeto de domínio:

Agora temos uma servlet que responderá por “//exemplo/xml” devolvendo a instância de exemplo que acabamos de criar no método.
Vamos configurar agora nosso ‘empacotador’ de XML para torná-lo formato padrão da aplicação. No arquivo de beans do Spring crie os seguintes beans:

O que fizemos foi criar um “marshaller” de XML que usa o XStream para converter ‘de’ e ‘para’ XML. Também mapeamos nossa classe de domínio para o alias “exemplo”. Feito isso basta criar um bean que representa os conversores de mensagens do Spring, nesse caso ‘messageConverters’, e associar o conversor de XML nele.
Pronto! Agora que temos as configurações necessárias para criar XML, e anotamos nosso método do controller com ‘@ResponseBody’, o padrão do Spring será devolver o XML que representa a entidade de domínio criada:

Para criar a view de JSon agora, vamos fazer de maneira diferente. Comece criando um bean em seu arquivo do Spring que representa a View de JSon:

Note que precisamos da dependência do ‘Jackson’ no classpath do nosso projeto, que está disponível no site do projeto ou até mesmo no repositório do maven.
Agora em nosso controler, vamos adicionar a dependência da view que acabamos de criar, e adicionar o método que tratará a requisição em JSon:

Repare que não precisamos da anotação ‘@ResponseBody’, e que ao invés de devolver um ‘Exemplo’ estamos devolvendo o ModelAndView do SpringWEBMVC.
Para que a resposta chegue no formato correto, basta mandar a view de JSon que criamos junto com o ModelAndView, e o objeto de domínio. Dessa forma temos a resposta que esperamos:

Conclusão

Para a moda REST que está tomando força nos últimos tempos, as múltiplas views do Spring é uma ótima ferramenta para fazer parte dessa onda, e ainda prover diferentes maneiras de seu servidor se comunicar com diversos tipos de dispositivos e aplicações clientes, sem comprometer código com regras de negócio.

Espero ter sido útil, e qualquer dúvida, crítica ou comentário são sempre bem vindos.

Por @Gust4v0_H4xx0r

Twitter!

Introdução

Um desafio de todo desenvolvedor html é manter o seu site compatível com todos os browsers ( em especial o Internet Explorer ), devido as limitações e detalhes na implementação de cada um, isso é um fato inegável, e qualquer um que ja tentou um dia desenvolver alguma coisa em html sabe disso.

Em projetos pequenos podemos tomar conta disso sem a necessidade de nenhuma ferramenta extra, entretanto com o? crescimento? do projeto? a tendência ? é que estes trechos de códigos para manter a compatibilidade fiquem tão grande quanto o código do próprio site em si, tornando difícil de manter e etc.

jQuery

Nesta hora é importante conhecer as ferramentas que existem para ajudar o desenvolvimento, e utiliza-las de maneira correta. Uma ferramenta importante no desenvolvimento html é o jQuery.

Para quem não sabe o que é, o jQuery é uma biblioteca javascript que facilita a manipulação do DOM ( Document Object Model ) html, ou seja, facilita a manipulação da sua página html.

Para entender melhor do que este post se trata é necessário ter um conhecimento básico da biblioteca jQuery

Hooks

Muitos dos métodos get e set do jQuery podem ser extendidos para casos especiais, estas extensões são conhecidas como hooks. O namespace $.cssHooks permite extender o método .css(), permitindo criar novas propriedades de CSS.

Os hooks podem ser utilizados como uma solução elegante para a compatibilidade de CSS em diferentes browsers, por exemplo, a propriedade text-shadow do CSS3 não é suportada pelo Internet Explorer, portanto o código abaixo não funcionará no IE:

Este código aplica um glow verde em todos os elementos H3 do documento HTML, porém não funciona no IE.

CSS Hooks

Mas nós podemos criar uma nova propriedade css, e internamente tratar o caso do IE. Vamos chamar a nova propriedade de glowColor:

Este código cria uma propriedade dentro do namespace .cssHooks chamada glowColor, esta propriedade possui uma função set específica para o caso do IE e outra para o caso dos outros browsers. A lógica deste código é basicamente, verificar se possui suporte ao textShadow, caso sim,? define? uma função set que altera o atributo elem.style.textShadow com a cor do parâmetro, caso não, define uma função que altera a propriedade elem.style.filter com um filtro especifico utilizando a cor do? parâmetro.

Agora podemos aplicar o efeito através do código

Conclusão

O lado bom de criar um cssHook no jQuery para o problema de descrito é que o código que trata a compatibilidade fica oculto do desenvolvedor, ele não precisa se? preocupar? com isso, o foco é no código que? constrói? a pagina unicamente. Esta? estratégia pode ser aplicada para outros diversos efeitos e manipulações, criar uma serie de hooks para tratar este tipo de coisa e etc. O lado ruim no meu ponto de vista é que estamos criando propriedades novas, que são desconhecidas pelos outros desenvolvedores e etc, portanto um novo desenvolvedor iria demorar para aprender todas customizações e suas funções, uma dica é tentar manter os nomes semelhantes ao padrão.

Por @thiagoofelix

Referências

• Learning jQuery, Third Edition
• jQuery API

Twitter!

JodaTime

Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.

Lembrando do Calendar

Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.


Problema: não funciona.


Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:

Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.

DateTime

O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:

Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.

JodaTime e Hibernate

Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:

Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:

Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.


Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho .

Por @Gust4v0_H4xx0r

Olá pessoal, venho através desse post fazer um convite ? todos vocês.

Recentemente nós aqui do maranhão fundamos um adobe user group o BumbAUG (Bumba meu boi + AUG) e gostaríamos de lhe convidar a fazer parte desse grupo.

Inicialmente nós iremos tratar principalmente o desenvolvimento de aplicações mobile sejam utilizando o flex, PhoneGap ou mesmo nativamente. Poderemos também fazer algo de introdução ao Flex Framework, mas isso é projeto futuro.

Apesar de ainda estar engatinhando nós do BumbAUG realizamos no dia 18/11 o Flash Mobile Day Edição São Luís, onde tivemos palestras das mais diversas áreas.

Acessem o grupo, participem, deixem suas idéias e contribuição. Como eu já falei é um GRUPO de estudos, então se você tiver um tema para palestrar, sinta-se ? vontade. O espaço é seu.

O Rafael Laranjeiras já marcou 2 palestras muito interessantes e em breve eu irei divulgar os temas para vocês.

Acessem: http://bumbaug.groups.adobe.com e vamos levar o desenvolvimento de aplicações ? um novo patamar.

Twitter!

Como todos devem ter percebido, nos últimos meses o CSS3 e o HTML5 tem ganho um grande destaque no desenvolvimento web. Grandes empresas como o Google, Microsoft, Adobe e Apple estão apoiando fortemente o desenvolvimento web utilizando WebStandards. Caso você já conheça algo sobre CSS, provavelmente deve saber como é complicado a organização desses documentos em um projeto de médio ou grande porte. Dado esses problemas conhecidos, foram surgindo os chamados pré-processadores de CSS, que viabilizam a criação de documentos de estilo, adicionando novas funcionalidades.

Hoje vamos conhecer o LESS, The Dynamic Stylesheet Language. O objetivo dessa biblioteca em javascript é prover uma série de funcionalidades para as, usualmente criadas a mão, folhas de estilos. Recursos tais como, variáveis, mixins (Multiple Inheritance, Traits), mixins parametrizáveis, funções, namespaces, importação, etc. Vamos aprender como utilizar os principais recursos dessa biblioteca em um projeto e como aproveitar o melhor dessa biblioteca para organizar corretamente nossas folhas de estilo.

Variables

As variáveis ajudam-nos a definir valores que podem ser utilizados em diversas regras do nosso CSS. Elas possuem escopo assim como em uma linguagem de programação orientada a objetos, trocando em miúdos:

O que é interessante no uso de variáveis é a reutilização e organização. Imagine uma design guideline onde existem RGBs específicos a serem seguidos, essas cores poderiam ser definidas em um documento chamado color_variables.less e adicionados ao nosso arquivo principal utilizando a clausula @import.

@Import – Importando outros arquivos

Quando um arquivo LESS é importado, todas as suas variáveis e mixins são adicionados ao arquivo principal. Os escopos serão mantidos e a extensão .less é opcional.

@import “lib.less”
@import “lib”

É possível utilizar pastas nas clausulas de @import:

@import “where/is/my/stylesheet.less”
@import “where/is/my/stylesheet”

Mixins

No LESS, mixis são como uma espécie de classe CSS que pode ser reutilizada em diversas outras regras. Quando utilizadas, todas as propriedades definidas no mixin são adicionadas a regra onde a mesma foi adicionada, caso um mixin mude, todas as regras que o referenciam serão também modificadas.

Imagine o conceito de mixin como classes CSS orientadas a objeto, o que é interessante do mixin é que temos aqui algo como uma herança múltipla, caso uma mesma instrução seja declarada em mixins diferentes, e esses mixins adicionados a uma regra, o mixin declarado por último terá vantagem na construção final do CSS da regra onde foi adicionado.

Quando modificarmos o mixin .bordered, todos os elementos que o estão utilizando serão modificados. Reutilização!
Vamos para um exemplo mais usável para exemplificar como é um mixin parametrizável.

É importante destacar que um mixin pode conter diversos parâmetros. Isso pode ser feito da seguinte forma:

Nested Rules

Com o LESS você pode criar suas regras de CSS utilizando uma espécie de hierarquia. Vamos ver como isso funciona na prática.

Com o LESS, o mesmo CSS acima poderia ser escrito da seguinte forma:

Depois de processado, o CSS será exatamente igual. Você não precisa utilizar esse esquema de hierarquia caso não queira, é importante lembrar que o LESS é apenas uma extensão do CSS, se for de desejo do desenvolvedor, podemos escrever um código LESS sem usar nenhum recurso especial, como se fosse um CSS tradicional.

Operations

Com o LESS o seu CSS sabe fazer contas. Qualquer número, cor ou variável pode ser utilizada em uma operação aritmética.
Ele sabe identificar quando estamos utilizando uma cor ou um número, por exemplo:

Assim como no javascript, é possível também utilizar parênteses nas suas operações:

Color Functions

Na minha opinião um dos recursos mais úteis durante o desenvolvimento de uma aplicação. Podemos efetuar operações em cima de RGBs, por exemplo, imagine que o layout do seu website foi criado baseado-se em apenas uma cor, utilizando diversos tons dessa cor. Com o LESS é possível utilizar métodos pré-definidos como lighten, saturate, darken, fadein, fadeout e spin. Esses métodos retornam sempre um RGB que pode ser utilizado em seu LESS. Vejamos alguns exemplos:

É possível também extrair informações de uma determinada cor para ser utilizada em outra.
Isso é feito a partir dos métodos hue, saturation e lightness.

Namespaces

Em dado momento necessitamos organizar uma série de mixins e variáveis. Para isto podemos utilizar um conceito presente no LESS chamado Namespaces. Assim como em linguagens de programação orientadas a objetos, que possuem o conceito de pacotes, os namespaces fornecem encapsulação para nossas folhas de estilo. Isso pode ser implementado facilmente utilizando a mesma notação de ID do CSS tradicional. Vejamos.

Verifique que acima, criamos um mixin chamado button dentro do namespace bundle. Para o utilizarmos devemos fazer da seguinte forma:

Uma utilização muito comum dos namespaces é na criação de pequenas bibliotecas de utilidades. Imagine que sua empresa pode possuir uma série de arquivos LESS, e em um determinado projeto você necessita de acesso a esses mixins, variáveis, etc. Organizar seus documentos com namespaces fácilita a visualização e localização de uma determinada instrução no seu documento LESS, como por exemplo, um mixin customizado que pode ser facilmente encontrado a partir da sua indicação de namespace.

Conclusão

Como podemos ver, o LESS facilita uma série de tarefas que são praticamente impossíveis de serem efetuadas pelo CSS tradicional.
Aconselho a todos que tenham interesse em se aprofundar mais na biblioteca a conhecer o website (http://lesscss.org/). Lá você poderá encontrar a documentação com maior riqueza de informações também poderá ver alguns exemplos de código que não foram abordados nesse post.

Qualquer dúvida, sinta-se a vontade e envie-nos um comentário!
Abraço!

Twitter!

Como todos já devem saber, o Canvas é um elemento muito poderoso do HTML5, com ele podemos desenvolver diversos tipos de componentes e aplicações. Tenho certeza que ainda não descobri 5% de seu potencial, ainda mais que meu estudo hoje está limitado a javascript/html puro, sem a introdução de frameworks auxiliares.

Para o exemplo abaixo, utilizei como base um outro exemplo que encontrei na internet, pois ele tinha as funções de desenho das linhas dos gráficos. Com ele em mãos resolvi desenvolver algo mais próximo do que fazemos em dashboards no Flex, como um range de datas para filtro no gráfico, e não é que ficou legal?

Your browser does not support iframes.

Como todos já devem saber, o Canvas é um elemento muito poderoso do HTML5, com ele podemos desenvolver diversos tipos de componentes e aplicações. Tenho certeza que ainda não descobri 5% de seu potencial, ainda mais que meu estudo hoje está limitado a javascript/html puro, sem a introdução de frameworks auxiliares. Para o exemplo abaixo,…

Twitter!

Antes de mais nada, meu enorme agradecimento a diretoria da DClick, Rafael Martinelli, Rogério Martinelli, e Eduardo Melendez, os quais estavam comigo nesse evento da MAX de 2011.

Como alguns aqui já sabem, fui para a MAX porque ganhei a primeira Season do Agon, nossa rede social interna na DClick.

E claro, estou aqui para trazer as minhas primeiras impressões sobre o evento.
Começo dizendo que de infraestrutura não deixa nada a desejar, é um evento de grande porte, muito bacana, e com uma produção de dar inveja. A abertura do evento possui toda a pirotecnia possível, mas vamos deixar essa parte de lado (que você pode conferir facilmente no youtube) para comentar sobre o conteúdo do evento, que é o mais importante.

Sempre reforço que Design é uma matéria que pertence a UX, e não o inverso, tal como outras demais matérias fazem parte do resultado final que é a Experiência do Usuário, e reforçando o que Rafael Martinelli comentou no seu post, a tecnologia é o meio, e ? no Design não é diferente… ? você pode desenvolver uma User Interface com qualquer ferramenta, e para qualquer estrutura, ou seja, qualquer linguagem, Flex, HMTL5, Android, iOS, etc etc… e claro, a ferramenta gráfica mais poderosa do mercado continua sendo o imbatível Photoshop, na minha humilde opinião… Eu sinceramente estava bastante curioso para ver o que a MAX iria trazer nesse sentido, na área de Interfaces, portanto me escrevi nas diversas Sessions de Photoshop, também na de ROX (Return of Experience, ROI pensando no Usuário) e claro, em uma palestra de Flash Catalyst….

Vou começar falando minha impressão sobre as palestras sobre Photoshop, o que vi foi que não se falou muito, ou quase nada de User Interface, e sim foi mostrado técnicas para fotógrafos e outros designers que visam o tratamento de imagem, ou ainda, a produção de imagens detalhadas com 3D e outros efeitos. Confesso que como AppDesigner que sou, me senti meio orfão, mas não é de se admirar, não há profissionais muito empenhados nesse segmento, nem mesmo lá fora, certamente a Adobe fez uma pesquisa do que seria mais atrativo aos participantes da MAX, e acertou em cheio nas palestras voltadas a tratamento de imagens, pois acaba agradando a todos, mesmo AppDesigners como eu se interessam também pelo assunto, pois também utilizamos tais recursos.

Sobre UI não vi nada de novo, nada que eu já não conheça, mas sobre tratamento de imagens, não exatamente no Photoshop, mas por exemplo no Camera Raw e Adobe Bridge, vi recursos que podem ajudar-nos no dia a dia a sermos mais produtivos, sim, muito mais produtivos.. ? e vou abordar as técnicas que vi em posts futuros. Resta dizer ainda, meio que reforçando os comentários do Rafael, que me surpreendi um tempo e vi um pouco de descaso ao Flash, ao Flex nem se fala, praticamente só ouvi falar do mesmo na Session de Catalyst, mas sobre o Flash, depois seu logo apareceu estampado no telão da general session… ? mas o foco era outro, percebi o que não é novidade para ninguém o quanto a plataforma está voltada para games. E claro, o quanto os games estão voltados para o social.

Mas se teve algo que foi comentado em grande escala em todos os eventos, quer seja a general session ou os eventos segmentados, foi sem dúvida o tão badalado nome do momento: HTML5. Acho que você tanto quanto eu sabe as implicações dessa tecnologia, do que ela depende, etc… mas não cabe aqui discutir isso, e sim que o mercado está aceitando o nome, como uma grife, como algo que as pessoas querem estampar. Eu me lembro do termo Web2.0, baladíssimo, as pessoas citam os termos mas não sabem do que se trata realmente.

Agora chega de blá blá blá e vamos a um resumo da situação.

Photoshop:

A MAX trouxe profissionais que falaram de muitas novidades, não dentro do software, mas extensões, aquele tipo de ferramenta que te ajuda no dia a dia. Se teve algo de novo para mim no Photoshop foi sobre uma palestra de compactação de arquivo JPG, confesso que ouvi coisas que me surpreenderam, e é de uma utilidade absurda. Futuro Post

UX:

Nada de novo, mas o óbvio, que avaliar as possibilidades do estudo centrado no usuário pode trazer um retorno muito maior ao investimento feito nos projetos. Não é novo, mas a maioria das empresas não aplica essa estratégia… ? UX também é um termo que está já meio que saturado, todo mundo fala, ninguém sabe o que é, mas é bonito de se citar… ? Não é bem assim que deveria ser, mas ao que parece, a Adobe também está fazendo o seu papel em educar os seus profissionais e evangelistas sobre esse termo, o que é, e o quanto é importante nos projetos. Logo, foi positivo ver esse posicionamento da empresa sobre o assunto. ROX, Futuro post

Design:

A MAX não é o que podemos dizer de um evento propriamente voltado a esse segmento, para isso existe um evento só sobre Photoshop, onde além de se tratar do software em si, se fala sobre os diversos aspectos do Design. Mas resta dizer que estava impecável o tratamento e cuidado com a matéria, quer seja nos games que vi, aplicações, ou citações nas palestras.

Novidade:

A Adobe trouxe alguns tipos de apps para mobile (Tablet mesmo), que pasmem (até parece.. rs) são para Androids primeiramente, e em breve vão sair para iOS.
Você pode encontrá-las aqui: http://www.adobe.com/products/touchapps.html

Aos poucos estarei trazendo as novidades referente aos temas que abordei em posts ou screencasts. Acompanhem o Blog!!!