Archive for March, 2007
Fazer acontecer
Faz tempo que estou dedicando várias horas do dia ao meu Trabalho de Conclusão de Curso. Degrau após degrau, problemas sobre problemas e aqui estou: firme e forte.
Como se torna gratificante quando você se aventura em um mundo desconhecido e vai vencendo todas as batalhas, desafios e obstáculos, um após o outro até chegar ao destino.
Muito melhor do que isso é quando você acha que tudo está perdido mas não desiste. Vai em frente. Tira código dali, adiciona aqui. Reescreve algumas rotinas. Remove algumas limitações. O resultado é mais do que o esperado.
Hoje, antes tarde do que nunca, apareceu um cubo 3D no meu emulador. 
Além de 3D ele é colorido e iluminado. Em outras palavras, matei todos os coelhos com uma paulada só, afinal o que é uma noite de sono a menos na vida do cara?
Fica aí outra imagem do que está por vir:
- A rotina que carrega o arquivo OBJ foi reescrita e agora suporta normais, texturas e vários formatos de faces (1/1/1, 1, 1//1, etc);
- Corrigido bug na rotina que carrega o arquivo MTL. Agora está carregando corretamente os valores para Ka, Kd e Ks;
- Adicionado um projeto chamado ThreeDV que nada mais é do que uma implementação usando a Gita.
É isso ae! Até +.
Tudo o que eu gostaria de fazer neste ano
Há muito tempo penso em pular de pára-quedas com uma câmera na mão para gravar todos os sons e imagens possíveis.
Também gostaria de viajar por ai a fora e conhecer toda a pobreza existente nesse mundo infeliz que nasci.
Gosto muito do pós-guerra, das ruínas, destruições e todos os malefícios que a guerra traz.
Não gosto de guerras, mas o que vem com elas reafirma minha auto-estima, afinal moro num país que, no máximo, temos uns tiros e uns corpos estendidos no chão por dia.
Formatura. Outro desejo aparentemente alcançável para este ano. Vamos lá. Ainda há chances.
Chutar o balde. Tocar o foda-se. Mandar todo mundo que me torra o saco pro inferno.
Fazer acontecer: isso já faço. Mas quero mais. Quero ver as coisas fluindo da melhor forma possível.
Trazer meus amigos para perto. Faz tempo que tenho deixado eles de lado para estudar e trabalhar. Isso não se repetirá daqui pra frente.
Chorar. Faz parte. É uma limpeza interna que resolve boa parte dos problemas. Alivia o peso nas costas.
Vender tudo o que tenho e me jogar. Pegar uma mochila, colocar nas cotas e partir rumo ao velho continente.
Conhecer gente de tudo quanto é canto do globo. Enrolar vários idiomas. Comunicar-me.
Correr pelas ruas de alguma cidade turística fazendo alguma coisa que só os brasileiros sabem fazer.
Tomar um chopp com os camaradas, amigos e demais conhecidos (já faço).
É isso!
Até +.
.NET: alternativa para o OpenFileDialog nos Smartphones
Os Smartphones não suportam a janela de pesquisa OpenFileDialog (os Pocket PC sim). Logo, nada mais natural do que arrumar uma alternativa.
O OpenNETCF é um framework open source que estende o .NET Compact Framework em diversas direções. Uma destas extensões é justamente a OpenFileDialog.
Estou utilizando ela no meu TCC e até o momento não tenho o que reclamar. A “instalação” foi muito simples e o uso mais ainda, pois segue a mesma idéia da implementação oficial.
Para ter acesso a esta funcionalidade, basta fazer o download da OpenFileDialog implementada pela OpenNETCF, executar a instalação, navegar até a pasta bin do projeto SmartphoneDialogs e usar a dll que está disponível.
Eu estou usando o Windows Mobile 6 e, consequentemente, o .NET CF 2.0. Funcionou perfeitamente. Bastou fazer a referência e usar o seguinte trecho de código:
OpenNETCF.Windows.Forms.OpenFileDialog dlg = new OpenNETCF.Windows.Forms.OpenFileDialog(); dlg.Title = "..."; dlg.Filter = "TXT Files|*.txt"; dlg.FilterIndex = 1; dlg.InitialDirectory = @"your path"; if (dlg.ShowDialog() == DialogResult.OK) { // do some stuff
A tela de pesquisa que aprece é a seguinte:
Fonte: MSDN
MD3DM e suas limitações
O Managed Direct3D Mobile, API que estou usando para desenvolver o meu Trabalho de Conclusão de Curso, possui infinitas limitações.
Somando-se estas com as dos dispositivos móveis, temos um número ainda maior que o infinito (?). Às vezes chega a torrar o saco do cara.
As últimas duas que encontrei foram estas:
- Não é possível criar um device e usar um panel no parâmetro renderWindow;
- O parâmetro renderWindow, além de não poder ser um panel, deve ser o form principal, aquele do Application.Run().
Considerando o nível de sono que estou no momento, não tive saco para pesquisar mais detalhes sobre isto. O que achei foi só um comentário no site brains-N-brawn relatando exatamente este problema.
O erro grotesco que aparece quando tento criar o device usando um panel é o 80004005.
No que isso influencia? Bom, você simplesmente não poderá colocar um menu, criar uma tela de apresentação da sua aplicação, etc. Eu, por exemplo, inicio a aplicação e para carregar algum arquivo o usuário deve utilizar a tecla número 1 para abrir uma tela de pesquisa. Ficou meio torto, mas como não é focado pros ditos “usuários finais” (leigos), quebrou o galho.
Falando em abrir uma tela para selecionar arquivos (o tal do OpenFileDialog), isto não está disponível para os Smartphones (para Pocket PC está). Amanhã escrevo um post sobre como contornar este outro problema.
É isso ae. Até +.
.NET: como acessar os arquivos em um smart device?
Complementando o post anterior, neste vou escrever sobre como acessar um arquivo (seja ele uma imagem, um txt, ou qualquer outra coisa) que está no emulador ou smart device.
Como já foi descrito, existem duas maneiras de enviar um arquivo para o dispositivo: embutido no executável (Build Action = Embedded Resource) ou literalmente copiado da máquina origem para a destino (Build Action = Content).
Para acessar arquivos enviados como Embedded Resource, o código é este:
string f = "NomeDoProjeto.NomeDoArquivo.xxx"; Stream s = Assembly.GetExecutingAssembly(). GetManifestResourceStream(f);
Veja que o nome do arquivo deve conter o nome do projeto também. Caso o arquivo esteja dentro de alguma pasta, deverá ser aparecer também. Ex: NomeDoProjeto.Imagens.Figura1.bmp.
Para acessar os arquivos enviados como Content, ou seja, copiados da origem pro destino da forma mais normal que existe, é da seguinte maneira:
string path = Path.GetDirectoryName (Assembly.GetExecutingAssembly(). GetName().CodeBase); string file = path + @"NomeDoArquivo.xxx"; StreamReader stream = new StreamReader(file);
Repare na manobra usada para pegar o diretório atual. Todo aquele estupro de legibilidade existe porque o método GetCurrentDirectory da classe Directory não funciona no .NET Compact Framework.
Também vale a pena lembrar que por default o executável e os arquivos são copiados para a pasta \Program Files\NomeDoProjeto.
É isso ae. Até +.
.NET: Propriedades dos arquivos
Provavelmente muitos desenvolvedores já clicaram com o botão direito sobre um arquivo (seja ele um .cs, .aspx, .bmp, etc) e checaram as propriedades apresentadas na janela que abriu.
Muitas delas são intuitivas, ou seja, de fácil entendimento. Porém, neste tarde tive que passar algumas horas até descobrir exatamente o funcionamento de todas elas.
Eu precisava copiar um arquivo .bmp para o emulador assim que fosse feito o deploy da aplicação. Uma maneira muito simples para ter acesso ao arquivo é usando o Build Action como Embedded Resource. Mas desta forma o executável cresce exponencialmente (aqui passou de 10k para 70k em um teste simples).
A solução mais correta, neste caso, é copiar o arquivo .bmp somente uma vez para o emulador ou dispositivo, pois ele permanecerá intacto durante toda a execução. Como fazer isso?
Antes de apresentar a minha solução, vou descrever o que cada opção significa.
- Build Action: indica o que será feito com o arquivo assim que o build do projeto for executado. Possui as seguintes opções:
- None: o arquivo não é copiado para o diretório destino do executável e também não é compilado. É usado normalmente para arquivos de documentação.
- Compile: o arquivo é compilado dentro do executável. Usado para arquivos fonte (.cs, .vb, etc).
- Content: o arquivo não é compilado mas é copiado para a mesma pasta do executável. Normalmente é usado para arquivos de imagem, .htm, etc.
- Embedded Resource: o arquivo fará parte do executável gerado. Ou seja, não será copiado para o destino, mas sim estará “embutido” no executábel (embedded).
Também é possível criar novas opções personalizadas. O blog do time de desenvolvimento do MSBuild publicou um post falando mais sobre o assunto.
- Copy to output directory: específica as condições de cópia do arquivo para o diretório destino do executável. Possui as seguintes opções:
- Do not copy: nunca copia o arquivo.
- Copy always: sempre copia.
- Copy if newer: copia o arquivo somente se for novo. Para os smart devices, as técnicas de comparação para saber se o arquivo é novo estão descritas na MSDN.
- Custom Tool e Custom Tool Namespace: define os componentes e o namespace usado para converter arquivos de um tipo para outro em tempo de design. Veja mais sobre o assunto na MSDN.
Sobre o meu problema, bastou adicionar o arquivo bmp ao projeto e definir a opção Build Action como Content e a Copy to output folder como Copy if newer. Desta forma, sempre que o arquivo bmp mudar no meu computador, será recopiado para o emulador ou dispositivo.
Claro que esta dica também é válida para projetos Windows Forms e WEB.
Fonte: MSDN - File Properties
É isso ae. Até +.
NHibernate: sugestão de arquitetura para uma aplicação CRUD
Antes de tudo, CRUD é um acrônimo para Create, Read, Update e Delete. Logo, uma aplicação CRUD nada mais é do que uma aplicação simples e que executa basicamente estas operações.
Para um projeto simples usando o NHibernate, sem uma regra de negócios muito complexa, a arquitetura abaixo serve perfeitamente:
É uma única solução com três projetos: a interface (Site), a camada de acesso a dados (DAL - Data Acess Layer) e o mapeamento objeto/relacional (DTO - Data Transfer Object, alguns chamam de VO - Value Object também). Veja abaixo uma breve descrição sobre eles.
- Site: aqui deve ficar toda a apresentação do sistema, ou seja, as páginas ASPX, o code-behind, o Web.Config, imagens, etc. A pasta App_Data não é necessária, só mantive ela pois foi criada automaticamente com o site.
- DAL: por ser a camada de acesso a dados, todos os acessos ao banco serão feitos por ela (usando o NHibernate, claro). Ao salvar uma informação, por exemplo, deverá ser usado algum método de uma classe pertencente a este projeto, e não o NHibernate diretamente ou um comando SQL (argh).
- DTO: todo o mapeamento objeto/relacional ficará dentro deste projeto. Não esqueça de definir os arquivos hbm.xml como Embedded Resource, caso contrário ficarão inacessíveis aos outros projetos. As classes, como de costume, deverão ser marcadas como Serializable.
Um breve exemplo:
Dentro do Site temos um cadastro de atividades devidamente mapeado no DTO: Atividade.hbm.xml e Atividade.cs.
No DAL deve haver uma outra classe chamada AtividadeDAL, que será responsável por inserir, buscar, atualizar e remover atividades.
Aqui vale uma observação: como os métodos CRUD do NHibernate (Save, Update, Delete e Get) recebem como parâmetro um object, recomendo a criação de uma classe BaseDAL que será herdada por todas as outras. Algo mais ou menos assim:
namespace DAL { public class BaseDAL { public static void Save(object o) { // Salva o objeto usando o NHibernate } } }
E a AtividadeDAL herda dela:
namespace DAL { public class AtividadeDAL : BaseDAL { // O método save já está disponível na BaseDAL } }
Quando o usuário clicar na opção para salvar uma atividade, o código abaixo será executado:
Atividade atividade = new Atividade(); atividade.Id = ...; atividade.Descricao = ...; AtividadeDAL.Save(atividade);
Veja que o objeto definido no DTO é carregado e é salvo pela classe DAL.
Para saber mais sobre o NHibernate, veja o artigo que escrevi sobre como criar uma aplicação Web em C# usando o NHibernate.
Hope this helps (by ScottGu).
Até +.
Quer um emprego na Microsoft? Comece por aqui.
O blog Technical Careers, mantido pelo pessoal do RH da Microsoft, já promoveu duas vezes um evento chamado Coding Exercise. É uma espécie de competição, onde cada um deve resolver um problema de computação e encaminhar a solução aos responsáveis.
Na primeira edição eu não consegui participar, pois só fiquei sabendo quando anunciaram a segunda. Foi então que resolvi ver do que se tratava.
Funciona mais ou menos assim:
- Algum funcionário da Microsoft anuncia a competição no blog;
- Os mais atentos às novidades sempre ficam sabendo e espalham para os conhecidos, afinal é uma competição bem informal, sem muitas regras e divulgação oficial;
- Quem tem interesse em participar envia um e-mail ao responsável e recebe um exercício de lógica para resolver;
- Após recebido, terá 1 hora para completar o desafio e enviar à Microsoft para ser avaliado.
Foi exatamente isto que fiz. Porém, todas as tentativas realizadas para enviar o e-mail de resposta à Microsoft foram mal sucedidas e por isso minha solução não foi avaliada.
De qualquer forma, resolvi deixar registrado aqui a existência desta competição para que você fique ligado, afinal é pelo RH que provavelmente você entrará lá. 
Na edição que participei o problema era este: procurar em uma árvore bidimensional, a partir de um nodo, o nodo pai em comum de outros dois que esteja mais próximo do primeiro. Calma. Veja os exemplos para esclarecer melhor.
Na árvore abaixo, por exemplo, se a procura pelo pai em comum for feita utilizando os nodos h e g a partir do c, deverá retornar o d. Se for feita a partir do a e utilizando os nodos g e p, deverá retornar o b. Caso for feita a partir do a e utilizando os nodos l (letra L minúscula) e c, deverá retornar uma mensagem indicando que não existe um pai em comum.
A minha solução está disponível para download aqui (feita no Visual Studio em C#).
É isso ae! Até+.
Ps: estava dando uma olhada no blog e parece que aconteceu a terceira edição do Coding Exercise. Não sei se é verdade, mas ao que tudo indica foi um brasileiro que levou o Oscar.
Plugins para inserir código fonte no Windows Live Writer
Na falta de sono não há coisa melhor a se fazer do que reavaliar algumas ferramentas do dia-a-dia. Normalmente isto leva a uma atualização ou até mesmo a troca de algumas. Pena que hoje não foi assim.
Vai e vem preciso publicar algum código fonte (C#, Delphi, SQL, etc) aqui no blog. Todos os que publiquei até hoje foram usando o plugin SyntaxColor4Writer (já falei sobre ele neste post). Porém, ele tem alguns incovenientes:
- Não quebra as linhas automaticamente para evitar a desconfiguração do layout;
- Não permite selecionar uma borda, somente a cor do background;
- Copia e cola a tabulação exatamente como está no Visual Studio, o que às vezes é um problema, pois quando preciso copiar uma parte do código que está tabulada umas três ou quatro vezes, ele copia todo aquele espaço em branco junto.
Apesar disso, é ainda o melhor plugin que encontrei. Todos os problemas acima são solucionados facilmente. No meu ponto de vista, é o melhor da categoria.
Caso interesse, abaixo fica uma lista de plugins que avaliei há algumas horas e a minha impressão sobre eles.
- Insert Formatted Clipboard: desenvolvido pelo NoahCoad (MVP), faz exatamente o que diz o nome: insere, utilizando formatação, as informações que estão no clipboard no Windows Live Writer(WLW). Suporta vários formatos, dentre eles: textos do Word, planilhas do Excel e, é claro, código fonte do Visual Studio. Não existe opção alguma de configuração. A única ação possível é copiar o conteúdo e clicar no plugin para colar no WLW.
- Paste from Visual Studio: um pouco menos inteligente que o plugin acima, este serve somente para o Visual Studio. Basta copiar o código fonte para o clipboard e clicar sobre o plugin. Também não há opção alguma de configuração.
- Code Snippet Plugin: à primeira vista é a solução para todos os problemas. Possui uma excelente janela de configuração com todas as opções necessárias (numeração de linhas, borda, cor no background, etc). Porém, na prática a coisa é diferente. Fiz alguns testes e infelizmente ele ignorou todas as definições e o que apareceu no browser foi somente o código fonte à moda antiga (em preto e branco).
Pois bem, como disse anteriormente, o negócio é continuar com o mesmo plugin. Estou usando uma versão antiga do WLW (1.0), pois há um certo tempo instalei a última e o SyntaxColor4Writer parou de funcionar. Fica aí a dica!
Só espero terminar logo esse TCC para quem sabe criar um Windows Live Writer que faz juz ao Live. Afinal, pra que serve Ajax?
Até +.
