Estive pensando em estudar Flash ultimamente, para incrementar o meu potencial para web e para atender algumas necessidades também, já que eu fiquei encarregado de fazer o site da minha banda... Nas minhas pesquisas por tutoriais eu acabei me deparando com um artigo que me deixou bem intrigado:
10 motivos pra não usar introduções em sites
Cara, esse artigo caiu matando com Flash, não que o Flash seja uma tecnologia ruim, se fosse ruim simplesmente não seria tão popular como é hoje em dia, mas a falta de sensatez no uso do Flash é algo que é cada vez mais lastimável. Para os fãs de Flash, um bom puxão de orelha como esse artigo é essencial. Resolvi não transcrever esse artigo para o meu blog só por preguiça mesmo, cliquem no link e divirtam-se :D
Quinta-feira, 20 de Novembro de 2008
Terça-feira, 18 de Novembro de 2008
API do Windows em .NET
Faz tempo que eu não posto aqui, hein? Só pra constatar, eu estou vivo e muito bem por sinal :D
Recentemente andei passeando pelo Google atrás de umas dicas sobre API do Windows e olha só o que eu achei:
http://www.codegod.de/WebAppCodeGod/Win32APIViewer.aspx
Um guia de referência para API do Windows em .NET, traduz chamadas da API para C# e VB.NET, é super prático e sem complicações, através de código não-gerenciado (unmanaged - lembre-se de declarar o namespace System.Runtime.InteropServices). Você pode implementar essas chamadas externas em qualquer classe sua, desde que você sempre declare as funções como estáticas (testei aqui com o compilador gmcs do Mono, não dá pra implementar essas chamadas como instância). A parte boa é que roda perfeito no Mono e que você tem inúmeras opções para lidar com esse tipo de API, a parte ruim é que é uma API só pra Windows, e nem via Wine ele rodaria no Linux (a menos que você rodasse o Mono dentro do Wine, mas isso é uma tarefa totalmente sem noção, ninguém rodaria o Mono via Wine sabendo que ele roda nativo no Linux). Vamos torcer para que haja alguma luz no fim do túnel para o projeto do gluecode que ligue o Mono ao Wine, aí quem sabe essas APIs rodem no Linux também.
E para matar mais um pouco a curiosidade sobre APIs do Windows, achei mais 2 links interessantes:
http://mwinapi.sourceforge.net - Managed Windows API. Um projeto que sugere o uso de APIs do Windows por funções gerenciadas (managed).
http://www.c-sharpcorner.com/UploadFile/shrijeetnair/win32api12062005005528AM/win32api.aspx - Um artigo super interessante para complementar o uso de APIs do Windows, você pode usar o primeiro link como referência para diversas APIs e entender mais sobre o funcionamento delas com esse artigo. Recomendo :)
Recentemente andei passeando pelo Google atrás de umas dicas sobre API do Windows e olha só o que eu achei:
http://www.codegod.de/WebAppCodeGod/Win32APIViewer.aspx
Um guia de referência para API do Windows em .NET, traduz chamadas da API para C# e VB.NET, é super prático e sem complicações, através de código não-gerenciado (unmanaged - lembre-se de declarar o namespace System.Runtime.InteropServices). Você pode implementar essas chamadas externas em qualquer classe sua, desde que você sempre declare as funções como estáticas (testei aqui com o compilador gmcs do Mono, não dá pra implementar essas chamadas como instância). A parte boa é que roda perfeito no Mono e que você tem inúmeras opções para lidar com esse tipo de API, a parte ruim é que é uma API só pra Windows, e nem via Wine ele rodaria no Linux (a menos que você rodasse o Mono dentro do Wine, mas isso é uma tarefa totalmente sem noção, ninguém rodaria o Mono via Wine sabendo que ele roda nativo no Linux). Vamos torcer para que haja alguma luz no fim do túnel para o projeto do gluecode que ligue o Mono ao Wine, aí quem sabe essas APIs rodem no Linux também.
E para matar mais um pouco a curiosidade sobre APIs do Windows, achei mais 2 links interessantes:
http://mwinapi.sourceforge.net - Managed Windows API. Um projeto que sugere o uso de APIs do Windows por funções gerenciadas (managed).
http://www.c-sharpcorner.com/UploadFile/shrijeetnair/win32api12062005005528AM/win32api.aspx - Um artigo super interessante para complementar o uso de APIs do Windows, você pode usar o primeiro link como referência para diversas APIs e entender mais sobre o funcionamento delas com esse artigo. Recomendo :)
Segunda-feira, 29 de Setembro de 2008
Slackware 12.1 + Gnome Slacky: Adeus Thunar, agora é NAUTILUS!
Desde ontem estive numa empreitada de fazer um upgrade básico no meu Linux e desde muito tempo estava decidido a deixar meu Linux o mais bem configurado possível. Há um tempo atrás estive usando Gnome SlackBuild (http://gnomeslackbuild.org), até que eu gostei, já vem muita coisa configurada, mas de certa forma eu acabei enjoando dele, algumas dependências do Gnome como o Mono não vem 100% (tive que encontrar o mod_mono na raça por exemplo), fora que é chato ter que baixar os pacotes toda vez que quiser instalar o Gnome no Slackware. Daí acabei descobrindo o site http://www.slacky.eu, um site italiano dedicado a pacotes de Slackware. Eles tiveram a brilhante idéia de fornecer o Gnome numa ISO à parte, assim eu posso gravar um CD com tudo que o Gnome tem direito e instalar sempre que possível, junto com o Slackware 12.1, que já oficializou o slapt-get (http://software.jaos.org) para atualizar pacotes necessários.
Pois bem, instalei o Slackware 12.1 (parabéns para o novo splash screen do LILO, tava na hora do Slackware ter uma abertura mais bonitinha mesmo rsrs) com apenas 2 dos 3 CDs, já que eu não estou afim de usar KDE, rodei o CD do Gnome Slacky perfeitamente e o Gnome ficou ótimo. Só veio uma coisa que me incomodou (já incomodava no GSB também): Por que o Nautilus não abre no menu Locais? Ao invés dele vem o Thunar, navegador de arquivos mais econômico, rápido, mas com poucos recursos. Fui pesquisar no Google e acabei descobrindo uma solução:
1- Abra um terminal como root (ou simplesmente abra um terminal, digite "su" e em seguida a senha de root), e certifique-se de saber lidar com algum editor de texto console (eu tenho preferência por mcedit, do mc... mas tem gente que prefere nano ou vi).
2- Abra o arquivo /usr/share/mime/packages/freedesktop.org.xml e procure a seguinte linha:
Altere para a seguinte forma:
Assim desabilitando o Thunar de vez, ou também assim:
Para colocar o Thunar em segundo plano (caso haja algum problema com o Nautilus).
4- Ainda como root, digite update-mime-database /usr/share/mime para recarregar o MIME e setar o Nautilus como navegador padrão de arquivos.
Essa dica me ajudou bastante, e espero que ajude muito mais gente por ai :D
Fonte: http://www.htmlstaff.org/ver.php?id=21737
Fotos:
Navegando na internet com Firefox e dando uma atualização de rotina com Gslapt
Nautilus funcionando perfeitamente. E para os otakus curiosos, eu tenho One Piece completo :P
Pois bem, instalei o Slackware 12.1 (parabéns para o novo splash screen do LILO, tava na hora do Slackware ter uma abertura mais bonitinha mesmo rsrs) com apenas 2 dos 3 CDs, já que eu não estou afim de usar KDE, rodei o CD do Gnome Slacky perfeitamente e o Gnome ficou ótimo. Só veio uma coisa que me incomodou (já incomodava no GSB também): Por que o Nautilus não abre no menu Locais? Ao invés dele vem o Thunar, navegador de arquivos mais econômico, rápido, mas com poucos recursos. Fui pesquisar no Google e acabei descobrindo uma solução:
1- Abra um terminal como root (ou simplesmente abra um terminal, digite "su" e em seguida a senha de root), e certifique-se de saber lidar com algum editor de texto console (eu tenho preferência por mcedit, do mc... mas tem gente que prefere nano ou vi).
2- Abra o arquivo /usr/share/mime/packages/freedesktop.org.xml e procure a seguinte linha:
<alias type="x-directory/normal">Comente-a no formato XML, deixando-a assim:
<!--<alias type="x-directory/normal">-->3- Após salvar a alteração, vamos ao arquivo /usr/share/applications/mimeinfo.cache para alterá-lo também. Procure a seguinte linha:
x-directory/gnome-default-handler=Thunar-folder-handler.desktop;nautilus-folder-handler.desktop;
Altere para a seguinte forma:
x-directory/gnome-default-handler=nautilus-folder-handler.desktop;
Assim desabilitando o Thunar de vez, ou também assim:
x-directory/gnome-default-handler=nautilus-folder-handler.desktop;Thunar-folder-handler.desktop;
Para colocar o Thunar em segundo plano (caso haja algum problema com o Nautilus).
4- Ainda como root, digite update-mime-database /usr/share/mime para recarregar o MIME e setar o Nautilus como navegador padrão de arquivos.
Essa dica me ajudou bastante, e espero que ajude muito mais gente por ai :D
Fonte: http://www.htmlstaff.org/ver.php?id=21737
Fotos:
Navegando na internet com Firefox e dando uma atualização de rotina com Gslapt
Nautilus funcionando perfeitamente. E para os otakus curiosos, eu tenho One Piece completo :P
Domingo, 28 de Setembro de 2008
Processadores 64 bits: a evolução
Faz tempo que eu não posto aqui, hein? rsrs
Antes de mais nada, estive num árduo trabalho de desenvolver um front-end em Mono para servidores Linux, já me disseram que esse tipo de coisa existe, mas como eu gosto de fazer coisas inusitadas, a oportunidade foi perfeita. Em breve estarei abrindo uma página no GoogleCode para disponibilizar o código-fonte. Aos leitores do blog, desculpem a falta de conteúdo nesse mês.
Mas enfim, voltando ao assunto do dia, andei pesquisando sobre processadores 64 bits, andei pensando na possibilidade de pegar um Windows XP 64 para aplicar em uns clientes (eles tem processador 64 bits mas usam Windows XP convencional, perder desempenho com PCs de última geração me incomoda um pouco), também pesquisei acerca do Windows Vista e a única coisa que disseram foi "use o Vista 64, é recomendado", nada de novidade... Linux então nem se fala, 64 bits já é caso resolvido há muito tempo em praticamente todas as distros, mas como o Linux ainda não é tão popular entre meus clientes, vou ter que aceitar o fato de que Windows dá mais lucro no momento, mas sempre digo que 64 bits é tendencia nova que eles não estão aproveitando. A novidade mesmo foi um trabalho de um cara que eu achei num fórum, que merece aplausos pela informação bem coletada e bem trabalhada. Confiram o texto abaixo, e logo em seguida a referência do link original:
Escrito por: =[ Golden® Fire© ]=
Data: 01/08/2006 Tecnicamente um processador de 64bit garante maior poder de processamento, pois pode manipular o dobro de bits que um processador de 32bit pode manipular ao mesmo tempo. Alem disso, processadores de 64bit podem endereçar muito mais do que os 4Gb de memória que os processadores de 32bit endereçam. O problema é que para fazer uso dos 32bit adicionais, o software deve ser escrito para isso e, atualmente, sistemas operacionais e programas domésticos de 64bit ainda não são uma realidade.
Segundo os especialistas, sistemas operacionais, jogos e programas de 64bit só começarão realmente a inundar o mercado a partir de 2008.
Até lá, quem fez a opção de adquirir esta nova tecnologia, terá de se contentar em ficar com o sistema subutilizado, assim como ocorreu com os antigos usuários do Intel 386 na década de 80.
Vamos as cálculos e aprenderemos a diferença física dos processadores 32 bit para os processadores 64 bit. Quando temos processadores de32 bits ou 64 bits estamos falando dos bits internos que o processador possui, ou seja, representa a quantidade de instruções e dados que o processador consegue trabalhar simultaneamente. O processador de 32 bit pode manipular números de valor até 4.294.967.296 em uma única operação.
Se este o valor do número for superior ao mostrado acima, o processador terá de executar 2 operações, ou seja, mais tempo gasto. E os processadores de 64bit ? Qual o número que ele poderá calcular em apenas 1 operação ?
Para calcular esse limite, basta fazer 2 elevado à quantidade de bits internos do processador. 2^64 = 18.446.744.073.709.551.616 Somente isto!
As nomenclaturas
Como são 2 os fabricantes de processador lideres de mercados, vamos as nomenclaturas que cada uma utiliza:
AMD64: originalmente chamado de x86-64, AMD64 (ou AMD64 ISA - Instruction Set Architecture) é o nome da tecnologia de 64 bits desenvolvida pela AMD. Um de seus destaques é o suporte às instruções de 32 bits (Legacy Mode);
EM64T: sigla para Extended Memory 64-bit Technology, o EM64T é tido como a interpretação do AMD64 feita pela Intel. Devido a isso, recebeu de alguns a denominação iADMD64 (o "i" faz referência à primeira letra do nome da Intel).
Incompatibilidade entre Hardware e Drivers
Devido as diferenças de Hardware, o IA64 e o x64 necessitam de versões binárias diferentes do sistema operacional. Drivers compilados para x64 são compatíveis com implementações AMD64 e Intel EM64T.
Trabalhando com aplicações 32-bits no Windows 64-bits
Como sabemos a maioria das aplicações foram compiladas para as plataformas de 32-bits (processadores e sistemas operacionais). Para permitir uma transição suave de 32 bit para o 64 bit, Microsoft, AMD e Intel desenvolveram produtos que trabalham com as 2 arquiteturas ao mesmo tempo, com desempenho igual ou superior aos sistemas executados sem emulação e total confiabilidade.
Para possibilitar o uso de aplicações 32-bits no Windows 64-bits é necessário o uso de uma camada de emulação x86, conhecida como WOW64 (Windows-On-Windows64). O sistema isola por completo as aplicações 32 bits e 64 bits, para que não ocorram conflitos entre arquivos ou no registro do Windows.
Modos de operação
Os processadores AMD64 e IA64T possuem 3 modos de operação diferentes
Modo 32 bits: Ambos processadores AMD64 e EM64T atuarão exatamente como outros processadores compatíveis com IA-32 (32 bit) . É possível instalar um sistema operacional de 32 bits nestes sistemas e rodar programas 32 bits, entretanto, eles não serão capazes de fazer uso das novas funcionalidades exclusivas de 64 bits como endereçamento real de memória acima de 4GB ou dos registradores GPRs. Programas 32 bits irão rodar com a mesma velocidade que rodariam A maioria dos programas para IA-32 poderão rodar até mesmo mais rápidos que nas próprias plataformas aproveitando outras características implementadas na plataforma x64 que aumentam o desempenho.
Modo de compatibilidade: É um modo intermediário do modo completo (full). Para rodar no modo de compatibilidade, é necessário instalar um sistema operacional de 64 bits com drivers de 64 bits. O modo de compatibilidade com um sistema operacional de 64 bits possibilita rodar programas de 32 bits sem modificações. Cada programa 32 bits deve estar limitado à no máximo 4 GB de memória física. Porém, este limite de 4 GB é imposto em um nível de pré-processo e não em um nível de sistema. Isso significa que cada processo de 32 bits neste sistema pode ter seu próprio bloco de memória de 4 GB de espaço de memória física (supondo que se tenha bastante memória física instalada). Isso é uma enorme vantagem comparada ao sistema IA-32, onde o kernel do sistema operacional e o programa têm que compartilhar os 4 GB de memória física. Este modo não suporta o antigo modo virtual 8086, apenas os programas que utilizam o modo-real e os de modo protegido de 16 bits podem rodar.
Modo completo (full) de 64 bits: O último modo é o modo completo para 64 bits. A AMD se refere a este modo como "long mode” e a Intel trata como modo -32e. Este modo é ativado quando são executados programas de 64 bits em sistemas operacionais de 64 bits. Neste modo, um programa pode ter um espaço de endereçamento virtual de até 40 bits (cerca de 1 TB de memória endereçável). A quantidade de memória física será limitada pela quantidade de slots físicos de memórias DIMM. Programas que rodam no modo completo terão acesso à toda memória física instalada e às GPRs expandidas do sistema. Mas é importante entender que este modo de operação só estará ativo em um sistema operacional de 64 bits com drivers de 64 bits rodando programas de 64 bits.
Na arquitetura de 64 bit as versões Windows de 64 bit endereçam a memória RAM de maneira diferente. O sistema operacional é executado em endereços de memória acima de 32 bit (havendo memória RAM suficiente), permitindo que grandes blocos de memória RAM sejam disponibilizados para as aplicações sem a necessidade de compartilhamento do uso de memória.
Com esta arquitetura as aplicações podem receber blocos de 4GB de memória para endereçamento direto, reduzindo a paginação e permitindo que o desempenho das aplicações de 32 bit seja até superior nos sistemas x64 com Windows 64-bit, uma vez que além do melhor uso da memória RAM, o núcleo dos processadores x64 também executam instruções x86 diretamente.
Antes de mais nada, estive num árduo trabalho de desenvolver um front-end em Mono para servidores Linux, já me disseram que esse tipo de coisa existe, mas como eu gosto de fazer coisas inusitadas, a oportunidade foi perfeita. Em breve estarei abrindo uma página no GoogleCode para disponibilizar o código-fonte. Aos leitores do blog, desculpem a falta de conteúdo nesse mês.
Mas enfim, voltando ao assunto do dia, andei pesquisando sobre processadores 64 bits, andei pensando na possibilidade de pegar um Windows XP 64 para aplicar em uns clientes (eles tem processador 64 bits mas usam Windows XP convencional, perder desempenho com PCs de última geração me incomoda um pouco), também pesquisei acerca do Windows Vista e a única coisa que disseram foi "use o Vista 64, é recomendado", nada de novidade... Linux então nem se fala, 64 bits já é caso resolvido há muito tempo em praticamente todas as distros, mas como o Linux ainda não é tão popular entre meus clientes, vou ter que aceitar o fato de que Windows dá mais lucro no momento, mas sempre digo que 64 bits é tendencia nova que eles não estão aproveitando. A novidade mesmo foi um trabalho de um cara que eu achei num fórum, que merece aplausos pela informação bem coletada e bem trabalhada. Confiram o texto abaixo, e logo em seguida a referência do link original:
Escrito por: =[ Golden® Fire© ]=
Data: 01/08/2006 Tecnicamente um processador de 64bit garante maior poder de processamento, pois pode manipular o dobro de bits que um processador de 32bit pode manipular ao mesmo tempo. Alem disso, processadores de 64bit podem endereçar muito mais do que os 4Gb de memória que os processadores de 32bit endereçam. O problema é que para fazer uso dos 32bit adicionais, o software deve ser escrito para isso e, atualmente, sistemas operacionais e programas domésticos de 64bit ainda não são uma realidade.
Segundo os especialistas, sistemas operacionais, jogos e programas de 64bit só começarão realmente a inundar o mercado a partir de 2008.
Até lá, quem fez a opção de adquirir esta nova tecnologia, terá de se contentar em ficar com o sistema subutilizado, assim como ocorreu com os antigos usuários do Intel 386 na década de 80.
Vamos as cálculos e aprenderemos a diferença física dos processadores 32 bit para os processadores 64 bit. Quando temos processadores de32 bits ou 64 bits estamos falando dos bits internos que o processador possui, ou seja, representa a quantidade de instruções e dados que o processador consegue trabalhar simultaneamente. O processador de 32 bit pode manipular números de valor até 4.294.967.296 em uma única operação.
Se este o valor do número for superior ao mostrado acima, o processador terá de executar 2 operações, ou seja, mais tempo gasto. E os processadores de 64bit ? Qual o número que ele poderá calcular em apenas 1 operação ?
Para calcular esse limite, basta fazer 2 elevado à quantidade de bits internos do processador. 2^64 = 18.446.744.073.709.551.616 Somente isto!
As nomenclaturas
Como são 2 os fabricantes de processador lideres de mercados, vamos as nomenclaturas que cada uma utiliza:
AMD64: originalmente chamado de x86-64, AMD64 (ou AMD64 ISA - Instruction Set Architecture) é o nome da tecnologia de 64 bits desenvolvida pela AMD. Um de seus destaques é o suporte às instruções de 32 bits (Legacy Mode);
EM64T: sigla para Extended Memory 64-bit Technology, o EM64T é tido como a interpretação do AMD64 feita pela Intel. Devido a isso, recebeu de alguns a denominação iADMD64 (o "i" faz referência à primeira letra do nome da Intel).
Incompatibilidade entre Hardware e Drivers
Devido as diferenças de Hardware, o IA64 e o x64 necessitam de versões binárias diferentes do sistema operacional. Drivers compilados para x64 são compatíveis com implementações AMD64 e Intel EM64T.
Trabalhando com aplicações 32-bits no Windows 64-bits
Como sabemos a maioria das aplicações foram compiladas para as plataformas de 32-bits (processadores e sistemas operacionais). Para permitir uma transição suave de 32 bit para o 64 bit, Microsoft, AMD e Intel desenvolveram produtos que trabalham com as 2 arquiteturas ao mesmo tempo, com desempenho igual ou superior aos sistemas executados sem emulação e total confiabilidade.
Para possibilitar o uso de aplicações 32-bits no Windows 64-bits é necessário o uso de uma camada de emulação x86, conhecida como WOW64 (Windows-On-Windows64). O sistema isola por completo as aplicações 32 bits e 64 bits, para que não ocorram conflitos entre arquivos ou no registro do Windows.
Modos de operação
Os processadores AMD64 e IA64T possuem 3 modos de operação diferentes
Modo 32 bits: Ambos processadores AMD64 e EM64T atuarão exatamente como outros processadores compatíveis com IA-32 (32 bit) . É possível instalar um sistema operacional de 32 bits nestes sistemas e rodar programas 32 bits, entretanto, eles não serão capazes de fazer uso das novas funcionalidades exclusivas de 64 bits como endereçamento real de memória acima de 4GB ou dos registradores GPRs. Programas 32 bits irão rodar com a mesma velocidade que rodariam A maioria dos programas para IA-32 poderão rodar até mesmo mais rápidos que nas próprias plataformas aproveitando outras características implementadas na plataforma x64 que aumentam o desempenho.
Modo de compatibilidade: É um modo intermediário do modo completo (full). Para rodar no modo de compatibilidade, é necessário instalar um sistema operacional de 64 bits com drivers de 64 bits. O modo de compatibilidade com um sistema operacional de 64 bits possibilita rodar programas de 32 bits sem modificações. Cada programa 32 bits deve estar limitado à no máximo 4 GB de memória física. Porém, este limite de 4 GB é imposto em um nível de pré-processo e não em um nível de sistema. Isso significa que cada processo de 32 bits neste sistema pode ter seu próprio bloco de memória de 4 GB de espaço de memória física (supondo que se tenha bastante memória física instalada). Isso é uma enorme vantagem comparada ao sistema IA-32, onde o kernel do sistema operacional e o programa têm que compartilhar os 4 GB de memória física. Este modo não suporta o antigo modo virtual 8086, apenas os programas que utilizam o modo-real e os de modo protegido de 16 bits podem rodar.
Modo completo (full) de 64 bits: O último modo é o modo completo para 64 bits. A AMD se refere a este modo como "long mode” e a Intel trata como modo -32e. Este modo é ativado quando são executados programas de 64 bits em sistemas operacionais de 64 bits. Neste modo, um programa pode ter um espaço de endereçamento virtual de até 40 bits (cerca de 1 TB de memória endereçável). A quantidade de memória física será limitada pela quantidade de slots físicos de memórias DIMM. Programas que rodam no modo completo terão acesso à toda memória física instalada e às GPRs expandidas do sistema. Mas é importante entender que este modo de operação só estará ativo em um sistema operacional de 64 bits com drivers de 64 bits rodando programas de 64 bits.
Na arquitetura de 64 bit as versões Windows de 64 bit endereçam a memória RAM de maneira diferente. O sistema operacional é executado em endereços de memória acima de 32 bit (havendo memória RAM suficiente), permitindo que grandes blocos de memória RAM sejam disponibilizados para as aplicações sem a necessidade de compartilhamento do uso de memória.
Com esta arquitetura as aplicações podem receber blocos de 4GB de memória para endereçamento direto, reduzindo a paginação e permitindo que o desempenho das aplicações de 32 bit seja até superior nos sistemas x64 com Windows 64-bit, uma vez que além do melhor uso da memória RAM, o núcleo dos processadores x64 também executam instruções x86 diretamente.
Quarta-feira, 3 de Setembro de 2008
Aprenda a "flashear" a sua BIOS em poucos minutos
Na Internet eu já vi tosqueiras, porcarias, sátiras, sacanagens... Mas no sério, esse cara superou qualquer técnico de hardware que eu já vi antes:
Vejam com seus próprios olhos e aprendam com o "mestre" :D
E a propósito, esse cara é um ignorante sem caráter, ele tem uma série de vídeos xingando o Linux e dizendo que o Windows Vista e o Opensolaris são os melhores SOs que existem, sendo que o Opensolaris usa um kernel inspirado em Unix e de certa forma se assemelha bastante com o Linux... Se ignorância matasse...
E eu não falo isso porque sou fã de Linux... Eu digo isso porque eu sou democrático, e apesar de gostar mais do Linux, não xingaria o Windows num escalão tão baixo. Pelo contrário, tenho que concordar que se o Windows é tão usado no mundo, é porque ele tem alguma coisa pra oferecer, mesmo que eu não goste, tem a torcida do Flamengo que gosta... Linux é do mesmo jeito, ele não seria o que é se não fosse tão usado e tão querido pelos internautas.
Enfim... Guerrinhas à parte, espero que gostem do vídeo :D
Vejam com seus próprios olhos e aprendam com o "mestre" :D
E a propósito, esse cara é um ignorante sem caráter, ele tem uma série de vídeos xingando o Linux e dizendo que o Windows Vista e o Opensolaris são os melhores SOs que existem, sendo que o Opensolaris usa um kernel inspirado em Unix e de certa forma se assemelha bastante com o Linux... Se ignorância matasse...
E eu não falo isso porque sou fã de Linux... Eu digo isso porque eu sou democrático, e apesar de gostar mais do Linux, não xingaria o Windows num escalão tão baixo. Pelo contrário, tenho que concordar que se o Windows é tão usado no mundo, é porque ele tem alguma coisa pra oferecer, mesmo que eu não goste, tem a torcida do Flamengo que gosta... Linux é do mesmo jeito, ele não seria o que é se não fosse tão usado e tão querido pelos internautas.
Enfim... Guerrinhas à parte, espero que gostem do vídeo :D
Quarta-feira, 20 de Agosto de 2008
Mini-jogo em Delphi 7
Ano passado, quando eu ainda desenvolvia coisas legais em Delphi, eu comecei um esboço de jogo escrito com um componente aprimorado do famoso DelphiX. Trata-se de um RPG 2D retangular (não apliquei isometria por falta de recursos gráficos... sou péssimo em design e arte em geral :D), com controle de câmera (sem restrições, você pode "sumir" com o mapa do jogo se quiser :D), movimentações orientadas a mouse (como os famosos Tibia e Ragnarök)... Dirirtam-se com o código, pra quem tiver curiosidade em desenvolver jogos com Delphi, lembrando que o DelphiX/unDelphiX é uma binding de DirectX pra Delphi, isso representa dependência total de Windows (no Linux só pega via Wine... quem roda jogos via Wine no Linux sabe como é chato).
Segue aqui o exemplo que eu criei em Delphi 7 (código-fonte + executável): http://www.4shared.com/file/36842351/7492600/delphix_map.html?dirPwdVerified=d96b15a8
E aqui, o componente necessário para usá-lo: http://www.micrel.cz/Dx (baixe o componente unDelphiX).
Só pra constatar, é um joguinho demonstrando como se faz um jogo em Delphi com DirectX... E sim, o personagem é uma pyong =P
Controles:
Setas direcionais - controlam a câmera
ESC - sai do jogo
clique do mouse - move a pyong
Dentre algumas poucas limitações desse código, a maior de todas é a falta de um sistema de waypoints. No registro de cada bloco do mapa existe uma variável booleana representando se o bloco é bloqueado ou não, minha intenção é fazer o personagem desviar de tais blocos (podem ser paredes, escadarias ou obstáculos em geral), mas a variável está lá apenas para ser aproveitada no futuro, quem sabe alguém se encoraje em continuar tal código.
E para os fãs de .NET, futuramente eu estarei escrevendo uma versão similar em SDL.NET, uma versão nativa do SDL original, roda tanto em .NET Framework quanto em Mono. Como eu não estou tendo tempo nem de postar aqui direito, eu não sei quando irei começar, mas a pretenção é quebrar algumas limitações desse código em Delphi, inclusive a dos waypoints.
Segue aqui o exemplo que eu criei em Delphi 7 (código-fonte + executável): http://www.4shared.com/file/36842351/7492600/delphix_map.html?dirPwdVerified=d96b15a8
E aqui, o componente necessário para usá-lo: http://www.micrel.cz/Dx (baixe o componente unDelphiX).
Só pra constatar, é um joguinho demonstrando como se faz um jogo em Delphi com DirectX... E sim, o personagem é uma pyong =P
Controles:
Setas direcionais - controlam a câmera
ESC - sai do jogo
clique do mouse - move a pyong
Dentre algumas poucas limitações desse código, a maior de todas é a falta de um sistema de waypoints. No registro de cada bloco do mapa existe uma variável booleana representando se o bloco é bloqueado ou não, minha intenção é fazer o personagem desviar de tais blocos (podem ser paredes, escadarias ou obstáculos em geral), mas a variável está lá apenas para ser aproveitada no futuro, quem sabe alguém se encoraje em continuar tal código.
E para os fãs de .NET, futuramente eu estarei escrevendo uma versão similar em SDL.NET, uma versão nativa do SDL original, roda tanto em .NET Framework quanto em Mono. Como eu não estou tendo tempo nem de postar aqui direito, eu não sei quando irei começar, mas a pretenção é quebrar algumas limitações desse código em Delphi, inclusive a dos waypoints.
Segunda-feira, 18 de Agosto de 2008
User Controls em ASP.NET
Anteriormente abordado no meu blog, eu citei sobre Master Pages, uma facilidade e tanto para aquelas velhas brigas entre programadores e designers, que ficam naquela onda de injetar código no meio do HTML, depois trocar o código de lugar só por causa de uma alteração nova no layout (alguns programadores PHP conhecem bem acerca do assunto hehehe). Os Master Pages já são uma ajuda e tanto, mas eles se referem apenas ao layout global em si... O ASP.NET tem inúmeras facilidades, e uma delas também diz respeito a controles, os User Controls. User Controls são nada mais do que um tipo de componente útil para definir trechos pequenos de código, onde você pode reaproveitá-lo em várias partes do site.
Imagine uma situação onde você precise criar uma caixa de bate papo (conhecida em fórums como "Shoutbox"), e essa mesma caixa será usada em 4 lugares diferentes... Alguns diriam que o ideal seria criar 4 funções, uma pra cada caixa... Chato, né? Imagine você fazer a alteração em uma das caixas, ai lá vai você dar um velho CTRL+ C / CTRL + V pra resolver o problema... A programação orientada a objetos trouxe facilidades do tipo reciclar códigos, e a partir desse conceito surgiu os User Controls. Você cria um User Control com toda a tecnologia da sua shoutbox, e apenas declara o seu controle nas 4 páginas... Tudo que você alterar nesse User Control vai surtir efeito nas 4 páginas de uma vez! Uau, isso é fantastico! Para bons programadores esse tipo de coisa já é costume, mas com um pouco de versatilidade e padronização oferecida pelo ASP.NET, o rendimento no trabalho de programação fica ainda mais proveitoso.
Chega de conversa e vamos à prática. A sintaxe básica do User Control é descrita da seguinte forma:
Dentro da tag <%@Control %> podemos especificar alguns parâmetros (também comuns às Pages e às Master Pages):
Language: define qual linguagem será usada como base para o seu controle (padrão: C#)
Inherits: define a classe pela qual o controle receberá herança, qualquer controle que herde ou seja parcial à System.Web.UI.UserControl (padrão: System.Web.UI.UserControl - significa dizer que ele vai receber um User Control padrão e oco, sem nada a acrescentar)
Para receber o User Control dentro de uma página ASP.NET, temos 2 formas: a forma interna, onde você declara o User Control dentro da página, e a forma externa, que você declara no arquivo web.config. Usando o web.config, você pode usar seu User Control em todas as páginas do projeto.
Metodo 1 - Tag @Register
Lembrando que os User Controls são salvos em arquivos de extensão .ascx. Veja que eu registrei manualmente o prefixo da tag (meuprefixo) e o nome da mesma (MeuControl), demonstrando que eu posso dar o nome que quiser para a tag. Note que no segundo exemplo eu usei a diretiva Assembly, que nada mais é do que puxar uma classe derivada de System.Web.UI.UserControl e transformá-la num User Control aplicável no ASP.NET. Ou seja, é possível criar um User Control 100% via código, sem depender do arquivo .ascx (padrão dos User Controls).
Método 2 - web.config
O uso dos User Controls é exatamente igual, o que muda é apenas a declaração dele. Caso queira usar o User Control apenas em uma página, pode-se usar o primeiro método. Caso o User Control seja útil em vários lugares, o segundo método é mais indicado.
Caso queiram entender mais sobre User Controls, deixarei uma série de links abaixo:
http://weblogs.asp.net/scottgu/archive/2006/11/26/tip-trick-how-to-register-user-controls-and-custom-controls-in-web-config.aspx
Imagine uma situação onde você precise criar uma caixa de bate papo (conhecida em fórums como "Shoutbox"), e essa mesma caixa será usada em 4 lugares diferentes... Alguns diriam que o ideal seria criar 4 funções, uma pra cada caixa... Chato, né? Imagine você fazer a alteração em uma das caixas, ai lá vai você dar um velho CTRL+ C / CTRL + V pra resolver o problema... A programação orientada a objetos trouxe facilidades do tipo reciclar códigos, e a partir desse conceito surgiu os User Controls. Você cria um User Control com toda a tecnologia da sua shoutbox, e apenas declara o seu controle nas 4 páginas... Tudo que você alterar nesse User Control vai surtir efeito nas 4 páginas de uma vez! Uau, isso é fantastico! Para bons programadores esse tipo de coisa já é costume, mas com um pouco de versatilidade e padronização oferecida pelo ASP.NET, o rendimento no trabalho de programação fica ainda mais proveitoso.
Chega de conversa e vamos à prática. A sintaxe básica do User Control é descrita da seguinte forma:
<%@Control Language="C#" %>
<!-- aqui fica o conteúdo do User Control,
insira aqui o que der na telha :D -->
Dentro da tag <%@Control %> podemos especificar alguns parâmetros (também comuns às Pages e às Master Pages):
Language: define qual linguagem será usada como base para o seu controle (padrão: C#)
Inherits: define a classe pela qual o controle receberá herança, qualquer controle que herde ou seja parcial à System.Web.UI.UserControl (padrão: System.Web.UI.UserControl - significa dizer que ele vai receber um User Control padrão e oco, sem nada a acrescentar)
Para receber o User Control dentro de uma página ASP.NET, temos 2 formas: a forma interna, onde você declara o User Control dentro da página, e a forma externa, que você declara no arquivo web.config. Usando o web.config, você pode usar seu User Control em todas as páginas do projeto.
Metodo 1 - Tag @Register
<%@Page Language="C#" %>
<%@Register TagPrefix="meuprefixo" TagName="MeuControl"
src="meucontrol.ascx" %><%@Register TagPrefix="meuprefixo" Assembly="AssemblyControl" %>
<meuprefixo:MeuControl />
<meuprefixo:AssemblyControl />
Lembrando que os User Controls são salvos em arquivos de extensão .ascx. Veja que eu registrei manualmente o prefixo da tag (meuprefixo) e o nome da mesma (MeuControl), demonstrando que eu posso dar o nome que quiser para a tag. Note que no segundo exemplo eu usei a diretiva Assembly, que nada mais é do que puxar uma classe derivada de System.Web.UI.UserControl e transformá-la num User Control aplicável no ASP.NET. Ou seja, é possível criar um User Control 100% via código, sem depender do arquivo .ascx (padrão dos User Controls).
Método 2 - web.config
<?xml version="1.0"?>
<configuration>
...
<system.web>
...
<pages>
<controls>
<add tagPrefix="minhatag" tagName="MeuControl"
src="meucontrol.ascx" />
<add tagPrefix="minhatag" assembly="AssemblyControl"/>
</controls>
</pages>
...
</system.web>
...
</configuration>
O uso dos User Controls é exatamente igual, o que muda é apenas a declaração dele. Caso queira usar o User Control apenas em uma página, pode-se usar o primeiro método. Caso o User Control seja útil em vários lugares, o segundo método é mais indicado.
Caso queiram entender mais sobre User Controls, deixarei uma série de links abaixo:
http://weblogs.asp.net/scottgu/archive/2006/11/26/tip-trick-how-to-register-user-controls-and-custom-controls-in-web-config.aspx
Assinar:
Postagens (Atom)
