Remember Digger, that MS-DOS game?
There is even a new version for PS3 (Digger HD):
The theme music of old Digger is "Popcorn", for which there is GREAT remix, too.
Wish I had a car full of subwoofers to play this :)
2010/08/07
A novela do N85 chega ao fim; trocando Claro pela Oi
Depois de tantos meses que fiz aquele post sobre problemas no N85, deixando o celular encostado por conta disso, e inclusive tendo cancelado um excelente serviço de negociação em Bolsa via celular da Ágora porque ele não roda no N900, acabei descobrindo que o problema era da... Claro!
Embora a assistência Nokia seja proibida de comunicar-se diretamente com o cliente, da última vez que o N85 foi para lá veio um bilhetinho "contrabandeado" embaixo da bateria: verificar com a operador se ao celular não está na "lista negra". É a última coisa que você pensa quando compra um aparelho com nota fiscal e tudo mais, mas vai saber, né? Apesar disso, a Claro disse à época que não havia nada errado com o IMEI do celular, tanto no atendimento via Internet como na loja. O celular continuava o suspeito #1, e nessas alturas do campeonato eu já estava "amando" o N900, não voltaria para o N85 nem que o folheassem a ouro.
Nas últimas semanas, ficou quase impossível usar Claro aqui em casa, talvez por estarem construindo outra casa quase ao lado, no caminho da antena. O sinal sempre foi um pouco fraco (a casa é construída com alvenaria estrutural, o que também diminui o alcance do WiFi), mas ficou impossível de usar. Mesmo no segundo andar ficava horas a fio fora do ar, o que sugeria algum problema do lado da Claro (a tal casa em construção é apenas térrea). Nunca recebi um retorno pelas reclamações que fiz a respeito.
Como o celular é meu plano B de acesso à Internet, tinha de tentar outra operadora, ou cancelar a assinatura (e adotar como "plano B" encostar o automóvel numa das WiFi abertas que tenho detectado aqui perto :) Comprei chips pré-pagos da Tim e Oi, e o da Oi apresentou boa recepção. Funcionava mesmo nos conhecidos "pontos cegos" da casa, não ficava fora do ar quando chovia.
Decidi usar a tal portabilidade para o número com conta que tinha da Claro, e surpreendentemente o processo funciona, e sem sair de casa. Liguei para a Oi, comuniquei os dados, disse que plano queria. Três dias depois veio um chip Oi pelo SEDEX, e eles ligam quando o Correio confirma a entrega (não adianta ligar antes, liguei 10 minutos depois que chegou e fui informado que eles esperam pela confirmação de entrega).
O acesso à Internet da Oi também mostrou-se melhor que o da Claro -- que era excelente em 2007 mais foi decaindo, ficando quase impossível de usar mesmo antes dos supracitados problemas de sinal. Além disso, o chip da Oi é 3G para as áreas com cobertura 3G, coisa que eu não tinha solicitado por esquecimento. O desempenho da Internet via 3G também pareceu ser interessante, talvez indistinguível de um hotspot WiFi público.
O único problema da Oi, sobre o que outros me alertaram quando eu mencionava a intenção de migrar: o atendimento. Os atendentes em si são muito simpáticos mas o sistema dá uns glitches, do tipo cair ligação, demorar para a URA começar a falar etc.
Bem, voltando ao N85. Agora que eu tinha chips de outras operadoras, resolvi tirar aquela velha dúvida de uma vez por todas. Arrumei um daqueles códigos "mágicos" para desbloquear o N85 (que era restrito à Claro), e meti nele o chip da Oi. E funcionou de primeira!
Fiquei de consciência pesada por ter apedrejado a Nokia, afinal a rigor o problema não era dela. Por outro lado, não custava o técnico ter inserido um chip qualquer da Claro e exercitado o problema, e mesmo contactado a operadora para determinar a causa exata do bloqueio (que não é na lista negra de IMEIs porque se fosse o N85 não funcionaria tampouco com a Oi).
Embora a assistência Nokia seja proibida de comunicar-se diretamente com o cliente, da última vez que o N85 foi para lá veio um bilhetinho "contrabandeado" embaixo da bateria: verificar com a operador se ao celular não está na "lista negra". É a última coisa que você pensa quando compra um aparelho com nota fiscal e tudo mais, mas vai saber, né? Apesar disso, a Claro disse à época que não havia nada errado com o IMEI do celular, tanto no atendimento via Internet como na loja. O celular continuava o suspeito #1, e nessas alturas do campeonato eu já estava "amando" o N900, não voltaria para o N85 nem que o folheassem a ouro.
Nas últimas semanas, ficou quase impossível usar Claro aqui em casa, talvez por estarem construindo outra casa quase ao lado, no caminho da antena. O sinal sempre foi um pouco fraco (a casa é construída com alvenaria estrutural, o que também diminui o alcance do WiFi), mas ficou impossível de usar. Mesmo no segundo andar ficava horas a fio fora do ar, o que sugeria algum problema do lado da Claro (a tal casa em construção é apenas térrea). Nunca recebi um retorno pelas reclamações que fiz a respeito.
Como o celular é meu plano B de acesso à Internet, tinha de tentar outra operadora, ou cancelar a assinatura (e adotar como "plano B" encostar o automóvel numa das WiFi abertas que tenho detectado aqui perto :) Comprei chips pré-pagos da Tim e Oi, e o da Oi apresentou boa recepção. Funcionava mesmo nos conhecidos "pontos cegos" da casa, não ficava fora do ar quando chovia.
Decidi usar a tal portabilidade para o número com conta que tinha da Claro, e surpreendentemente o processo funciona, e sem sair de casa. Liguei para a Oi, comuniquei os dados, disse que plano queria. Três dias depois veio um chip Oi pelo SEDEX, e eles ligam quando o Correio confirma a entrega (não adianta ligar antes, liguei 10 minutos depois que chegou e fui informado que eles esperam pela confirmação de entrega).
O acesso à Internet da Oi também mostrou-se melhor que o da Claro -- que era excelente em 2007 mais foi decaindo, ficando quase impossível de usar mesmo antes dos supracitados problemas de sinal. Além disso, o chip da Oi é 3G para as áreas com cobertura 3G, coisa que eu não tinha solicitado por esquecimento. O desempenho da Internet via 3G também pareceu ser interessante, talvez indistinguível de um hotspot WiFi público.
O único problema da Oi, sobre o que outros me alertaram quando eu mencionava a intenção de migrar: o atendimento. Os atendentes em si são muito simpáticos mas o sistema dá uns glitches, do tipo cair ligação, demorar para a URA começar a falar etc.
Bem, voltando ao N85. Agora que eu tinha chips de outras operadoras, resolvi tirar aquela velha dúvida de uma vez por todas. Arrumei um daqueles códigos "mágicos" para desbloquear o N85 (que era restrito à Claro), e meti nele o chip da Oi. E funcionou de primeira!
Fiquei de consciência pesada por ter apedrejado a Nokia, afinal a rigor o problema não era dela. Por outro lado, não custava o técnico ter inserido um chip qualquer da Claro e exercitado o problema, e mesmo contactado a operadora para determinar a causa exata do bloqueio (que não é na lista negra de IMEIs porque se fosse o N85 não funcionaria tampouco com a Oi).
2010/07/26
Resultado da gincana-relâmpago
O nome deste blog, "Senzala Digital", é uma referência jocosa à extinta ONG de software livre "Quilombo Digital".Considero que o @caio1982 foi o que chegou mais perto da resposta, de modo que ele é o ganhador do livro. Peço a ele que me passe seu endereço para a remessa.
2010/07/19
Gincana-relâmpago
Como alguns já sabem, lancei mais um livro sobre opções, pela editora Novatec.O tempo anda curto e ainda não escrevi "aquele" post detalhado sobre o novo livro. Mas, enquanto isso, vamos nos divertir um pouco! Ganha um livro (autografado, ull!) o primeiro que responder corretamente à seguinte pergunta: Por que este blog chama-se "Senzala Digital"?
Ah, os #d00dzers não podem participar do concurso :) Primeiro porque sabem perfeitamente a resposta, segundo porque já têm sua cota de livros de brinde. Sejam bons esportistas e deixem o povo tentar a sorte, ok?
2010/07/03
Git-merge: a legitimate use and a goof
In spite of general allergy that Git users have against merge, there are perfectly legitimate uses for it. I currently work in a project where merging is routinely used.
The following cases are real-world. the specific details of my work are not relevant for this post, but if someone is curious, the
sources are public; they can be found here, and they are based on this other project.
The story is: my work is based on someone else's project, let's call it project Foo. I keep a branch called "fixes", which is based on Foo main line of development, plus some bugfixing commits that have not been integrated into Foo itself yet.
Since Foo is in active development, I need to rebase "fixes" often, so the patches will apply cleanly when Foo maintainers take a look on them. Some fixes are independently made by Foo, so my patches conflict and sometimes become obsolete, and they can simply skipped.
Then I have the "new_feature" branch, that is an implementation if a new feature (d0h). I need to base new_feature on "fixes" branch, so when I rebase fixes, in turn I rebase new_feature again, too.
I have a third branch, called "testing", which adds some code to fixes branch that will probably never make it into the main project, but it is useful for testing. It is based on fixes branch too, so it is rebased often as well.
Then, the problem: I need to test my new feature. It is not possible to rebase on both "new_feature" and "testing".
But, since they touch completely different sections of code, merging becomes trivial. So I created the "new_feature_testing" branch, which is based on "testing", but with "new_feature" merged into it.
It is a legitimate use of git-merge (or sounds legitimate to me) because a) it expresses exactly what I want to do: merge two diverging development lines; b) it does not affect the history of original branches; c) it is a "final" branch, something that will not see further developments based on it; any bugfix or new functionality goes either to "plugin" or to "new_feature".
When either "plugin" or "new_feature" changes, because of my development or because they had to be rebased against Foo, in general I try to update "new_feature_testing" using rebase and merge again. It works in 3 out of 4 times. But sometimes it fails, so I simply rebuild it from scratch, as if I did the first time.
Now, the goof :)
I develop this thing in 3 computers and need to push/pull commits often. Generally I take care to avoid merges in history, so all push/pulls are fast-forwarded. But I let one merge slip into the history. I thought it could not do much harm, because, after all, it was merging two almost identical branches.
Bad mistake, because I have to rebase "plugin" often on "fixes", as I said. Git got completely lost in the next rebase because of this merge. Could Git be more "intelligent"? Perhaps, but the fact was that rebase was full of conflicts and this "plugin" branch have commits that I can't lose.
Well, time to resort to the "stupid" technique again: dump the patches and apply manually. I did a format-patch -n HEAD~15, and about 100 patches were dumped out, because of the merge. Then the cause of problems was immediately obvious: the "same" patches were dumped twice, one from each merged branch, and of course that failed in rebase because it was trying to apply the same sequence twice.
Since I had the patches "saved" now, I resorted to recreate the "plugin" branch from "fixes" and apply the additional patches using git-am. Once the duplicates were eliminated, a git am 00* without -3 worked perfectly.
The following cases are real-world. the specific details of my work are not relevant for this post, but if someone is curious, the
sources are public; they can be found here, and they are based on this other project.
The story is: my work is based on someone else's project, let's call it project Foo. I keep a branch called "fixes", which is based on Foo main line of development, plus some bugfixing commits that have not been integrated into Foo itself yet.
Since Foo is in active development, I need to rebase "fixes" often, so the patches will apply cleanly when Foo maintainers take a look on them. Some fixes are independently made by Foo, so my patches conflict and sometimes become obsolete, and they can simply skipped.
Then I have the "new_feature" branch, that is an implementation if a new feature (d0h). I need to base new_feature on "fixes" branch, so when I rebase fixes, in turn I rebase new_feature again, too.
I have a third branch, called "testing", which adds some code to fixes branch that will probably never make it into the main project, but it is useful for testing. It is based on fixes branch too, so it is rebased often as well.
Then, the problem: I need to test my new feature. It is not possible to rebase on both "new_feature" and "testing".
But, since they touch completely different sections of code, merging becomes trivial. So I created the "new_feature_testing" branch, which is based on "testing", but with "new_feature" merged into it.
It is a legitimate use of git-merge (or sounds legitimate to me) because a) it expresses exactly what I want to do: merge two diverging development lines; b) it does not affect the history of original branches; c) it is a "final" branch, something that will not see further developments based on it; any bugfix or new functionality goes either to "plugin" or to "new_feature".
When either "plugin" or "new_feature" changes, because of my development or because they had to be rebased against Foo, in general I try to update "new_feature_testing" using rebase and merge again. It works in 3 out of 4 times. But sometimes it fails, so I simply rebuild it from scratch, as if I did the first time.
Now, the goof :)
I develop this thing in 3 computers and need to push/pull commits often. Generally I take care to avoid merges in history, so all push/pulls are fast-forwarded. But I let one merge slip into the history. I thought it could not do much harm, because, after all, it was merging two almost identical branches.
Bad mistake, because I have to rebase "plugin" often on "fixes", as I said. Git got completely lost in the next rebase because of this merge. Could Git be more "intelligent"? Perhaps, but the fact was that rebase was full of conflicts and this "plugin" branch have commits that I can't lose.
Well, time to resort to the "stupid" technique again: dump the patches and apply manually. I did a format-patch -n HEAD~15, and about 100 patches were dumped out, because of the merge. Then the cause of problems was immediately obvious: the "same" patches were dumped twice, one from each merged branch, and of course that failed in rebase because it was trying to apply the same sequence twice.
Since I had the patches "saved" now, I resorted to recreate the "plugin" branch from "fixes" and apply the additional patches using git-am. Once the duplicates were eliminated, a git am 00* without -3 worked perfectly.
Assinar:
Postagens (Atom)
