Meu antigo controle andava meio abandonado. Primeiro pelo tamanho. É bem grande e desengonçado para se carregar por aí. E segundo, eu mesmo não estava jogando muita coisa que necessitasse dele – Left4Dead, por exemplo.
Mais em Controle Arcade. Round 2!
Meu antigo controle andava meio abandonado. Primeiro pelo tamanho. É bem grande e desengonçado para se carregar por aí. E segundo, eu mesmo não estava jogando muita coisa que necessitasse dele – Left4Dead, por exemplo.
Isso até lançarem o Street Fighter 4 para PC.
O jogo é sensacional. Tem uma ótima jogabilidade, combos fáceis, combos difíceis, e os personagens são quase equilibrados entre si. Mas o principal atrativo é a possibilidade de se jogar online! Quando entrei no jogo para terminar no modo Arcade, e vi surgir um “Here comes a new challenger!”, me senti dentro uma casa de fliperama.
Isto me motivou a terminar meu projeto: o de um controle arcade individual. Há tempos eu havia planejado sua construção, mas a única coisa que eu tinha eram os botões, o controle e só.
Já era hora de voltar ao projeto. Primeiro criei um modelo no excelente Google Sketchup. Foi bem divertido criar o modelo. Ele se encontra logo abaixo, disponível para download.
Depois entreguei o projeto para meu amigo Batata, que, com suas ferramentas mágicas, tranformou placas MDF na caixa do controle. Um trabalho fantástico, praticamente profissional. Valeu Batata!
Instalei os botões e o joystick. Depois peguei a minha placa I-PAC e o instalei no interior da caixa, após ligar todos os cabos com suas respectivas microchaves com conectores F.
E, depois de pronto, Round 1! Fight!
Ando investigando a API Javascript ArcGIS. Esta API é escrita em cima do framework Dojo, que provê um monte de funções úteis, além de um biblioteca bacana de widgets.
Tentando criar um código JS mais organizado, encontrei o método dojo.require, que, em conjunto dos métodos dojo.declare e dojo.provide, devolvem um pouco de sanidade ao programandor. Ele funciona da seguinte maneira. Você inventa um namespace/pacote, e depois associa um caminho à ele:
dojo.registerModulePath( "pacote", "http://localhost/scripts/")
E depois pode incluir ou importar pacotes assim:
dojo.require("pacote.MinhaClasse");
A mágica é que o arquivo http://localhost/scripts/MinhaClasse.js é carregado automaticamente. Legal! Parecido com Java, C# e um monte de outras linguagens. Agora vou criar arquivos correspondentes às classes que criarei, e organizar a macarronada Javascript.
Mas não. A API Javascript ArcGIS, por alguma razão, procura pelo arquivo http://localhost/scripts/MinhaClasse.xd.js !!! De onde saiu este xd? E mesmo criando o arquivo que ele espera, seu conteúdo não é processado da forma correta.
Elaborando alguns testes eu susbtitui a referência:
<script type=”text/javascript” src=”http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.4″></script>
pela:
<script type=”text/javascript” src=”http://dojotoolkit.org/sites/all/modules/dojo/dtk_build/dojo/dojo.js”></script>
E funcionou ok. Parece que a versão do dojo entregue pela ESRI no ArcGIS não permite o uso do dojo.require. Para que isto seja possível, é necessário compilar o dojo de forma a permiti-lo carregar arquivos de domínios distintos, ou cross domain. Mas na API da ESRI não dá. Pena.
Encontrei como resolver o problema:
djConfig = {
parseOnLoad: true,
baseUrl: "./scripts",
modulePaths: {
"minhasClasses": "./minhasClasses",
"meusDijits": "./BLA"
},
isDebug: true
}
Isto me ensina a aprender direito antes de escrever! =)
As analogias servem para se apresentar, de maneira fácil, uma idéia complexa. No entanto, ela é mais utilizada para apresentar, de maneira distorcida, uma idéia a qual quero garantir apoio (ou repúdio).
Um exemplo é o texto “A delinqüência no mundo virtual“, de Vittorio Medioli, sobre a Lei Azeredo (que encontrei pela web, lendo sobre a PLS 607/2007):
É norteada por um intuito preventivo, como seria a construção de uma passarela antes de acontecerem dezenas de atropelamentos no mesmo local. Sabe-se que aí as vítimas aumentarão em breve, e agir com rapidez permitirá economizar transtornos e lágrimas.
Creio que uma analogia melhor seja:
É norteada por um intuito monitorativo, como seria a construção de um posto de checagem, onde se anotaria o horário, o nome, a origem e destino de qualquer pessoa que porventura passe pelo local. Assim, em caso de necessidade, pode-se consultar esta base de dados.
Creio que assim fica mais claro o que a lei implica, ao invés do objetivo, correto ou não, que se quer passar adiante. Quem responde pelo uso destas informações? Elas servem apenas para identificar culpados de “atropelamento”? Surgem questões de deixar qualquer paranóico de cabelos em pé…
Ando efetuando uns testes com o Postgresql e o Virtual Box, ambos excelentes sistemas. No Virtual Box eu criei uma máquina virtual, nele instalando um Ubuntu Server 64 bits com o Postgresql – e configurando o postgresql.conf e pg_hba.conf como sempre.
A partir de outra máquina virtual, rodando o Ubuntu Jaunty Desktop, consigo normalmente acessar o banco de dados no Ubuntu Server, então tudo ok. Ou quase tudo ok.
Para acessar o banco de dados postgresql a partir de meu sistema hospedeiro – ou seria anfitirião? estalajadeiro?, rodando o indefectível ( até o momento) Windows 7 tive de instalar os controladores ODBC (disponíves no ftp do Postgresql) .
Depois de instalar, navego até o Painel de Controle, depois para Fontes de dados Odbc e, CADÊ? Sumiu, ninguém viu. Só aparecem listados os controladores das fontes de dados do SQL Server. Muito estranho.
Mas eu já havia feito isto. Uma busca em minha memória e me lembrei que era um problema de versão do sistema. O controlador, ou driver , que instalei é de 32 bits. O sistema é de 64 bits. E o Windows não gosta de misturar alhos com bugalhos.
Para acessar finalmente o gerenciador de fontes de dados ODBC 32 bits é necessário executar este safado:
C:\Windows\SysWOW64\odbcad32.exe
Agora sim!
Algumas vezes é necessário um upgrade no banco de dados. E chegou a vez do PostgreSQL, para ir da versão 8.2 para a 8.3. Aproveitando, fiz um upgrade do PostGIS 1.1.6 para a versão 1.4. Surpreendentemente não ocorreram grandes problemas. Quer dizer, não até eu migrar os dados.
O próprio PostGIS possui um script para migração de dados. Se trata de um script Perl que recebe um dump do PostgreSQL e mais alguns outros parâmetros, trata-os gerando um novo dump e depois finalmente faz o restore do dump no banco de dados.
Parecia tudo ok, até eu tentar fazer um backup do novo banco:
ERROR: geometry contains non closed rings
Será que os dados se corromperam durante a migração?
O PostGIS 1.4 é um pouco mais restritivo quanto aos dados que armazena. Um multipolygon ou polygon, por exemplo, só podem ser inseridos no sistema se estiverem bem formados, o que significa que devem ser polígonos fechados (hmm, e existe “polígono aberto”?).
O problema é que a versão 1.1.6 é mais, digamos, liberal. Você consegue gravar “polígonos abertos”, consegue fazer SELECTs e backups em cima deles. Apenas operações que envolvam as formas geométricas podem dar problema.
E o processo de migração de dados não realiza nenhuma verificação de validade destas entidades.
Assim, os dados migrados para a nova versão continua com “polígonos abertos”, impossibilitando, na versão 1.4, até mesmo um simples select sobre os dados da tabela.
A solução foi encontrar os registros com este problema e removê-los da tabela através da seguinte consulta SQL:
DELETE FROM <nome_da_tabela> WHERE isvalid(coords) != 't'
E se você possui muitas tabelas com o problema, boa sorte!
Importei um projeto para trabalhar em meu Visual Studio 2008. Ao tentar rodar os testes, que utilizam o framework MbUnit, fui contemplado com a seguinte mensagem:
No tests were run because no tests are loaded or the selected tests are disabled
O problema é que o projeto de testes é tratado como uma simples biblioteca de classes, embora seus métodos sejam decorados com atributos [Test] e similares.
E como fazer o VS2008 entender que o projeto em questão é de testes? É necessário abrir o arquivo .csproj correspondente ao projeto e incluir o seguinte:
<ProjectTypeGuids>
{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
</ProjectTypeGuids>
Logo antes do primeiro </PropertyGroup> do arquivo. O VS2008 verifica o tipo do projeto em questão através destes identificadores. E como encontrei estes números? Criei um projeto de testes MSTest pelo VS2008 e abri o .csproj.
E encontrei o significado destes guids:
Há alguns dias recebi por email um link apontando para um projeto de lei (PLS - PROJETO DE LEI DO SENADO, Nº 607 de 2007)tramitando em nosso senado. O texto inicial é de autoria do senador Expedito Júnior, com relatórios subseqüentes por Eduardo Azeredo e Marconi Perillo.
Meu ponto de vista, compartilhada por muitos, é de que é uma lei desnecessária. Inútil.
Imagino que o objetivo do projeto de lei, ao regulamentar a área, seja de atribuir responsabilidades à alguns tipos de pessoas. Para isso precisamos:
Estas responsabilidades, ao menos até o último texto, são descritas como:
É privativa de Analista de Sistemas a responsabilidade técnica por projetos e sistemas para processamento de dados, informática e automação, assim como a emissão de laudos, relatórios ou pareceres técnicos.
E as pessoas descritas como (grifo meu):
Art. 1º É livre, em todo o território nacional, o exercício das
atividades de análise de sistemas e demais atividades relacionadas com a Informática, observadas as disposições desta Lei.
O grande problema é de tentar atribuir uma ampla gama de responsabilidades a um espectro imenso de profissionais. Contornando este último problema define-se Analista de Sistemas, profisisonal apto a exercer análise de sistemas e demais atividades relacionadas com a Informática, como a pessoa formada nos cursos superiores de Análise de Sistemas, Ciência da Computação ou Processamento de Dados.
Isto não leva em conta muitas questões, levantadas por pessoas mais aptas que nossos representantes no legislativo: a ACM, a IEEE e a SBC, como cita Phillip Calçado. O resultado a que chegaram:
ACM e IEEE:
“ACM is opposed to the licensing of software engineers at this time because ACM believes it is premature and would not be effective at addressing the problems of software quality and reliability.
SBC:
1. Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal.
2. Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima.
3. A área deve ser Auto-Regulada.
Sabemos que na prática esta lei não mudará nada, a não ser a necessidade de, em orgãos públicos ou que prestam serviços ao governo, existir algum Analista de Sistemas para assinar e se responsabilizar por um sistema de informação.
Muita gente clama pela lei e espera que ela seja selada, registrada, carimbada, avaliada, rotulada, aprovada. Acreditam que uma lei diferenciaria os profissionais entre competentes e não-competentes. Acreditam que é necessária uma lei para distinguir entre competentes e não-competentes. Acreditam que este é um bom modo de justificar o tempo e dinheiro gasto para se formarem. Acreditam que empresas que não sabem contratar, vão passar a saber depois da lei. Acreditam que seus salários vão subir. Acreditam que a profissão está banalizada, e este é um passo para torná-la séria.
É muita coisa para se acreditar. Sinto muito, mas não acredito em nenhuma delas. Acredito que produzir melhor e com mais eficiência seja mais importante. Uma graduação não te garante isto. Uma boa graduação ajuda. Bastante. Ou inteligência, habilidade e perseverança. Deixe o mercado separar o joio do trigo. Ele tem mais prática e competência neste jogo.
Enquanto nossos políticos se preocupam em regulamentar uma profissão, há quem diga que ela está morta. O controle é ilusão, ao menos nos projetos que importam:
Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We’ve been rather successful at transformation, often while operating outside our control envelope. Software development is and always will be somewhat experimental.
Regulamentar, controlar, guiar. Parece não ser o caminho para obtermos melhores resultados.
Eu havia comprado um roteador da 3Com, modelo 3CRWER101U, faz um pouco mais de um mês quando decidi comprar um outro. O anterior foi para deixar na casa da minha namorada, servindo a 3 PCs, 2 por cabos e um por rede sem fio. Tudo funcionando.
Feliz com o alcance e maior quantidade de opções (embora o firewall não funcionasse), resolvi comprar um para meu uso. Decepção! O motivo para isto é a instabilidade em alguns tipos de conexão. Utilizo meu micro para trabalhar, e volta e meia necessito acesso remoto à alguns servidores Linux por meio de um terminal e conexão ssh. E o maldito roteador 3Com derruba a conexão, invariavelmente, sem motivo aparente.
E não é só a conexão ssh. Meu amigo, que compartilha da mesma rede, notou que o MSN também cai, sempre que ele recebe uma mensagem. Não investiguei a fundo o motivo para este comportamento. Até testei configurar de modos diferentes o aparelho. Mas parece que não estou só.
O jeito foi retornar para o DLink velho de guerra, que embora cambaleante e necessitar de reboot a cada dois ou três dias, permanece totalmente funcional no meio tempo.
Moral: se não estiver totalmente quebrado, não conserte!
Falando sério, vou agora pensar na troca por um Linksys.
Na Parte I vimos como emitir um boleto para impressão. O que falta é populá-lo com dados que façam sentido. Vamos então populá-lo com dados relevantes.
Em primeiro lugar é necessário que você tenha os dados armazenados em algum lugar, um banco de dados talvez. Mas vou presumir que seu código já trate dos dados e me ater à construção de duas partes fundamentais do boleto: a linha digitável e o código de barras.
Note que, embora alguns dígitos da linha digitável sigam um padrão, cada banco pode possuir regras próprias para gerá-la. Entre em contato com seu banco para ter essas informações.