Durante um bom tempo fui contra a “automatização” da computação. Achava que isso ia causar uma sucatização massiva. Achava que se o cara pudesse gerar código automaticamente, tudo ia acabar descambando pro código automático porco que não ia servir pra muita coisa. E andei até conversando com várias pessoas sobre o assunto.

E depois de conversar sobre o assunto, cheguei a conclusão de que estamos passando pela evolução que passaram os alfaiates. No princípio, tudo era feito a mão. Os alfaiates faziam as roupas, cobravam o quanto queriam por elas, pois não eram tantos os que eram mestres na profissão. E com o tempo, surgiu a indústria de roupas, o barateamento das roupas, e os alfaites, ainda existentes, caíram basicamente em desuso.

Exceto talvez pelos ternos. Já ouvi muita gente falando que terno que não é ajustado pessoalmente pra você é basicamente inútil. Não é confortável, não cai bem, etc etc.
Não uso ternos, mas já ouvi mais de uma pessoa falando isso. Fora que ternos são peças de roupas bem específicas e bem caras, também.

Por isso o paralelo, acho que com o passar do tempo a computação evoluirá para algo no molde da alfaiataria: O comum será usar fábricas de software. Software barato, rápido, que serve pro que você precisa. E só quem precisar de algo específico – só quem precisar de um terno – irá recorrer ao software feito a mão. Não completamente a mão, claro. Hoje em dia mesmo quem faz software específico não escova mais bits. O compilador ajuda muito nessas horas. Mas hoje em dia acredito que mesmo os alfaiates tem mais evolução do que tinham há anos atrás.

Eu nem sei o que a maioria das pessoas considera software específico. Eu mesmo não sei se sei. Há um tempo atrás qualquer coisa que usasse uma camada de abstração em cima do banco pra mim já começava a ficar bizarro, porque já tinha visto várias consultas desnecessariamente grandes sendo geradas pra coisas bobas. Mas hoje em dia não sei qual é o “state of the art”,  então não sei se tenho como dizer como está esse nível.

Ainda acho que automatização demais faz mal. Só gerar um UML e mandar ele gerar o software pra você não vai fazer o melhor software do mundo. Mas talvez ele esteja na medida certa pra 90%  das pessoas. E  o princípio  de pareto ainda é o mais importante. Melhor fazer 20% do esforço e resolver 80% dos problemas.

Bom, eu não sou exatamente um expert em C#, mas uso no dia-a-dia no trabalho, e ultimamente uma coisa vem me incomodando bastante na sua definição.

Primeiro, vamos deixar claro, uso .net v2.0. Ou seja, não sei se o problema foi corrigido nas versões posteriores, mas pelo que vi, não o foi.

Quando criamos um DataGrid em C#, para exibirmos dados no DataGrid precisamos especificar um DataGridTableStyle, que é o define que tipo de dado será exibido naquele DataGrid, qual será o nome de cada coluna, a ordem das colunas, etc.
Pois bem, temos então algo nesse estilo:

DataGridTableStyle estilo = new DataGridTableStyle();

estilo.MappingName = typeof(List).Name;

DataGridTextBoxColumn coluna = new DataGridTextBoxColumn();
coluna.MappingName = “Campo”;
coluna.HeaderText = “Meu Campo”;
estilo.GridColumnStyles.Add(coluna);

dataGrid1.TableStyles.Clear();
dataGrid1.TableStyles.Add(estilo);

Agora olhe bem pra esse código. Você a vê a linha que define coluna.MappingName? Pois é. Ele define uma string com o nome do campo. Sim, uma string hard-coded no seu código.
“Ah, mas qual o mal nisso?”, você pode perguntar. Como é sabido, o Visual Studio tem uma ferramenta de refactor razoavelmente eficiente. Que deixa que você modifique o nome de um campo para melhorar o seu código em poucos passos. No entanto, com o nome no campo assim numa string, isso passa a não ser mais tão útil assim, pois você tem que ir lendo todas as ocorrências da string para ver se elas são mesmas relativas ao campo que você está modificando. Se você esquecer de alguma, você terá problemas no seu programa.
Um outra caso é que em refactors algumas vezes você muda a estrutura do seu programa e aí você não pode ter certeza se o campo que você quer apagar realmente não é referenciado pois não é possível encontrá-lo sem que você busque pela string e vá vendo ponto-a-ponto.

Não é o pior problema do universo, no entanto, vai de encontro a toda facilidade de refactor estabelecida no Visual Studio.

Eu procurei e não encontrei solução para isso, e fiquei bem decepcionado. Tive que usar de truques pra encontrar essas coisas no código, como declarar uma variável temporária do mesmo tipo da Classe usada na Lista para poder usar o refactor.

Vocês conhecem uma solução melhor?

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

No primeiro post eu falei de origens, do GBA e dos primeiros flash carts, sem entrar em muitos detalhes.

No segundo post eu falei sobre a infância do homebrew no DS e o que era o DS quando eu comprei o meu.

Nesse terceiro e último post eu vou falar sobre como vejo hoje em dia o DS.

R4: Ladrão que rouba ladrão…

É fácil de ver que quando um produto faz sucesso, o que mais acontece é ele ser copiado até a exaustão (Vii, Polystation, dentre outros), e se isso acontece com produtos oficiais legalizados e tudo mais, imagina como não é com um flash cart, que está numa área muito cinza da legalidade?

Depois que o R4 ficou famoso, o que mais começou acontecer foram os inúmeros clones dele. Primeiro, clones com o mesmo nome, ou seja, R4 falsificados. Depois que isso ficou muito na cara, começaram a surgir clones com outros nomes. Até porque, e isso eu não sei dizer corretamente, o R4 tem um hardware igual ao M3, e eu não sei qual deles veio primeiro. Mas aí veio também o G6, o R4 SDHC, e tantos outros clones espalhados por aí.

Aí eu fico até com um pé atrás de recomendar algum flash cart quando alguém me pergunta. Porque como eu vou dizer qual deles é o melhor pra comprar? Se o R4 já hoje em dia tem grandes incompatibilidades, o que dizer dos clones?

E até onde os clones são compatíveis com os firmwares, originais ou não?

A boa coisa do R4 original é que ele roda, por exemplo, o YSMenu, que é o firmware do DSTT modificado para rodar no R4 (o que aumenta a compatibilidade, já que o R4 não tem mais seu kernel atualizado desde ’08).

Claro que além do R4, existem outros chips como o próprio DSTT, o CycloDS ou o Acekard, mas não tenho conhecimento de causa suficiente pra recomendar nenhum deles, e não sigo de perto os lançamentos em cada um pra saber como funcionam os lançamentos recentes neles.

Por isso, fica a conclusão, ao comprar seu Flash Cart hoje em dia, tome um cuidado extra. Pesquise bem nos fóruns antes de comprar seu DS pra não ficar arrependido depois.

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

No primeiro post eu falei de origens, do GBA e dos primeiros flash carts, sem entrar em muitos detalhes.

Nesse segundo post eu vou falar sobre a infância do homebrew no DS e o que era o DS quando eu comprei o meu.

DS: Pegando carona numa onda que já vinha

Quando o DS saiu com seus dois slots, quem já estava desenvolvendo em GBA pensou logo em usar aquela entradinha safada de GBA, chamada Slot-2, pra continuar o que já fazia usando o DS. Já que o DS roda GBA nativamente, a maioria das coisas feitas pela cena homebrew de GBA podia ser aproveitado sem problemas no DS. Óbvio que sem usar todo o seu potencial, mas ainda assim, usado.

Naquela época, o que foi feito foi usar um dispositivo semelhante ao que já era usado no GBA, porém melhorado, e para conseguir fazer ele funcionar para jogos de DS, foram usados métodos que enganavam a firmware do DS. Estão aí incluídos dispostivos como o SuperKey e o FlashMe, um firmware modificado para o DS.

Era então um pouco complicado esse início. Era necessário adquirir um cartucho para o slot-1 como o superkey, um flash cart para o slot-2 para botar os jogos, e aí sim era possível usar. Não era muito complicado, mas pra quem era leigo, a coisa começava a enrolar.

Depois de algum tempo, a encriptação do DS foi quebrada, e com isso os cartuchos para SLOT-1 puderam ser fabricados, no início, com compatibilidade pequena, mas aos poucos foi aumentando e se equiparando aos cartuchos de SLOT-2, que já estavam mais consolidados. Nessa época passa a ser possível comprar somente um cartucho, alguns com memória interna, outros aceitando cartões externos, como MicroSD.

Cartuchos de SLOT-1 tem a desvantagem de que não é possível jogar GBA diretamente deles. Para jogar jogos de GBA a partir de um cartucho de SLOT-1 é necessário outro dispositivo no SLOT-2 que sirva somente para isso. Dispositivos de SLOT-2 também tem a vantagem de aumentar a memória do DS, como é o caso do cartucho do Opera DS.

Nessa época que eu comprei meu DS. Na época, o Flash Cart mais proeminente era o R4. Claro que haviam outros, mas era o que tinha melhor custo x benefício.

O R4 tinha a vantagem de ter seu firmware colocado dentro do MicroSD, como é comum nos flash carts, e seu firmware era atualizado com frequência, para corrigir eventuais jogos novos que não funcionavam.

Mas claro que isso atraiu os olhos de outros piratas.. E é aí que entra a 3ª parte da minha história :)

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

Nesse primeiro post vamos falar de origens, vamos falar do GBA.

Nintendo GBA: Onde tudo começou

Antes do GBA, pirataria em consoles com fitas era um pouco mais complicado. Não que não existissem jogos piratas, mas você tinha que ir em algum fornecedor e comprar o jogo pirata, e só assim você ia rodar um jogo não oficial no seu portátil.

Sempre existiram cartuchos em que era possível escrever, mas em geral esses cartuchos ficavam de posse dos desenvolvedores. Existiam alguns dispositivos para fazer backups de cartuchos mas eram caros e basicamente difíceis de conseguir, ao menos no Brasil. Eram exemplos o Game Doctor SF, pra SNES. E em especial, a Bung, que fez acessórios semelhantes para Nintendo 64, Neo Geo, e GB/GBC. [1]

Embora nos EUA o Doctor V64, dispositivo de backup da Bung para N64, tenha feito sucesso, o terreno ainda não era propício, roms de N64 eram grandes pra internet na época. Era difícil armazenar um arquivo que tinha entre 4Mb e 16Mb em servidores online.

Não achei dados, mas acredito que o GBA tenha coincidido com a época do barateamento das memórias flash, como cartões de câmera, pendrives e etc. Com isso, foi muito simples fazer um cartucho nesse estilo e fazê-lo ficar barato e atrativo, com um espaço razoável. Além disso, na época, era muito fácil disponibilizar os jogos online. Fazendo assim um terreno fértil para acessórios do gênero.

Assim, ao fim da vida do GBA, era possível você comprar um dispositivo chamado Flash Cart (cartucho Flash), um exemplo era o Extreme Flash Advance, e passar seus jogos baixados da rede pra ele, e então jogar no seu GBA, sem emuladores. Assim começa o homebrew do DS.

[1] http://en.wikipedia.org/wiki/Bung_Enterprises