TopCoder

2008-07-28T18:50:00.006-03:00

E esse???

<script>document.write("!")</script>

Para colocar um "!" em uma página web...

2008-07-28T18:48:00.000-03:00

Mais um bizarro:

Sucesso = True
if Sucesso then
...
end if

2008-07-28T18:04:00.001-03:00

Série: Comentário Exdrúxulos em códigos

'A opções escolhida foi desativar os documentos
'Aqui tenho que fazer alguns malabarismos, pois os paramentros da URL vem em minúsculo

' Tenho que consertar essa mer&*& de código

2008-05-23T16:24:00.004-03:00

Fala sério...
Imagina encontrar um codigo javascript como o abaixo, repetindo dezenas de vezes o mesmo codigo para mostrar quais os aniversariantes do dia...

');
}
</script><script language="JavaScript">

var d = new Date();
var corr_data = d.getDate();
var corr_mes = d.getMonth();
var corr_ano = d.getYear();
corr_mes=corr_mes+1
var datatotal = corr_data + "/" + corr_mes + "/" + corr_ano;

data_aniversariante = '1/4/2008';

if(datatotal == data_aniversariante){
document.write('<p><p style="MARGIN: 0px"><span ></span>

');
}
</script><script language="JavaScript">

var d = new Date();
var corr_data = d.getDate();
var corr_mes = d.getMonth();
var corr_ano = d.getYear();
corr_mes=corr_mes+1
var datatotal = corr_data + "/" + corr_mes + "/" + corr_ano;

data_aniversariante = '9/5/2008';

if(datatotal == data_aniversariante){
document.write('<p><span ></span>

');
}
</script><script language="JavaScript">

var d = new Date();
var corr_data = d.getDate();
var corr_mes = d.getMonth();
var corr_ano = d.getYear();
corr_mes=corr_mes+1
var datatotal = corr_data + "/" + corr_mes + "/" + corr_ano;

data_aniversariante = '8/5/2008';

if(datatotal == data_aniversariante){
document.write('<p><span ></span>

');
}
</script><script language="JavaScript">

var d = new Date();
var corr_data = d.getDate();
var corr_mes = d.getMonth();
var corr_ano = d.getYear();
corr_mes=corr_mes+1
var datatotal = corr_data + "/" + corr_mes + "/" + corr_ano;

data_aniversariante = '7/5/2008';

if(datatotal == data_aniversariante){
document.write('<p><span ></span>

');
}
</script>

2008-03-27T09:54:00.001-03:00

1. Aprimore suas habilidades.
Por que passar a vida desenvolvendo software se você não se preocupa em fazê-lo direito?
2. Reflita sobre o seu trabalho
Desligue o piloto automático e assuma o controle. Constantemente critique e valide seu trabalho.
3. Forneça opções. Não dê desculpas esfarrapadas
Ao invés de desculpas, forneça opções. Não diga que não pode ser feito; explique o que pode ser feito.
4. Não conviva com janelas quebradas
Corrija designes pobres, decisões erradas e código ruim quando se deparar com eles.
5. Seja um catalisador de mudanças
Você não pode forçar as pessoas a mudarem. No entanto, você pode lhes mostrar como o futuro pode ser e convencê-las a participar da sua criação.
6. Olhe o quadro geral
Não mergulhe nos detalhes para não esquecer de olhar o que está acontecendo ao seu redor.
7. Faça da qualidade um requerimento obrigatório
Envolva seus usuários para conseguir capturar os requerimentos que impõem qualidades reais para o projeto.
8. Invista regularmente no seu portfolio de conhecimentos
Torne a aprendizagem um hábito.
9. Analise de forma crítica o que você lê e ouve
Não se abale com o que dizem os vendedores, a mídia especializada ou com dogmas. Analise a informação de acordo com a sua realidade e a do seu projeto.
10. O que você diz e como você diz
Nada adianta ter grande idéias se você não consegue comunicá-las de maneira eficiente.
11. DRY – Don’t Repeat Yourself (Não se repita)
Cada pedaço do conhecimento deve ter uma representação única, sem ambigüidades e de representativa autoridade no sistema.
12. Torne fácil de reutilizar
Se for fácil de reutilizar, as pessoas reutilizarão. Crie um ambiente que favoreça a reutilização.
13. Elimine o efeito de coisas não relacionadas
Projete componentes que sejam auto-contidos, independentes e com um único propósito bem definido.
14. Não existem decisões finais
Nenhuma decisão é gravada em pedra. Pense em cada decisão como sendo gravada na areia da praia e prepare-se para as mudanças.
15. Utilize o rastro das balas para encontrar o alvo
O rastro que as balas deixam leva você para em direção ao alvo na medida em que você experimenta novas coisas e vê quão próximo conseguiu chegar do objetivo.
16. Faça protótipos para aprender
Prototipação é uma experiência de aprendizagem. O seu valor não está no código produzido, mas sim nas lições aprendidas.
17. Programe próximo do domínio do problema
Planeje e codifique utilizando o vocabulário do usuário.
18. Estime para evitar surpresas
Estime antes de começar. Você descobrirá quais são os problemas em potencial para o futuro.
19. Interaja o cronograma com o código
Use a experiência você adquire a medida que implementa para refinar suas estimativas de prazo.
20. Mantenha o conhecimento com comentários claros
Comentários claros nunca ficam obsoletos. Eles ajudam a alavancar seu trabalho e simplificam o debug e testes.
21. Use o poder da linha de comando
Use a linha de comando quando a interface gráfica não suprir suas necessidades.
22. Use um único editor. E use-o bem
O editor deve ser uma extensão da sua mão. Certifique-se de que o seu editor é configurável, extensível e adaptável as suas necessidades.
23. Sempre use controle de versão
O controle de versão é a máquina do tempo do seu trabalho – Com ele você pode sempre voltar atrás.
24. Corrija o problema, não a acusação
Não importa se o bug é uma falha de outra pessoa – ele ainda assim é um problema e portanto precisa ser consertado.
25. Não entre em pânico quando estiver debugando
Respire fundo e PENSE sobre o que pode estar causando o bug.
26. "select" não está quebrado
É raro você encontrar um bug no sistema operacional, no compilador, ou mesmo em programas e bibliotecas comerciais. Na maioria das vezes o problema está mesmo na sua aplicação.
27. Não presuma. Prove
Prove suas suposições no ambiente atual, com dados reais e para as condições de fronteira.
28. Aprenda uma linguagem de manipulação de textos
Você gasta grande parte do seu dia trabalhando com textos. Por que não deixar que o computador faça algo mais por você?
29. Escreva código que escreva código
Geradores de código aumentam sua produtividade e ajudam a evitar duplicidade.
30. Você não pode escrever um software perfeito
Software não pode ser perfeito. Mas proteja o seu código e seus usuários dos erros inevitáveis.
31. Projete para contratos (Design by Contracts)
Utilize contratos para documentar e verificar que o código não faz nem mais nem menos do que aquilo que necessita fazer.
32. Falhe cedo
Um programa morto costuma causar menos estrago do que um programa aleijado.
33. Use asserções para prevenir o impossível
Asserções validam suas suposições. Utilize-as para proteger seu código do mundo incerto.
34. Use exceções para problemas excepcionais
Exceções podem sofrer dos mesmos problemas de manutenção e legibilidade dos clássicos códigos em espaguete. Reserve as exceções para coisas realmente excepcionais.
35. Acabe o que você começou
Sempre que possível os métodos e objetos que alocam recursos devem ser responsáveis por desalocá-los.
36. Minimize o acoplamento entre módulos
Evite o acoplamento escrevendo código “tímido” e aplicando a lei de Demeter.
37. Configure ao invés de integrar
Implemente as escolhas tecnológicas de uma aplicação como opções de configuração, não como partes integradas da aplicação.
38. Coloque a abstração no código e os detalhes em metadados
Programe para o caso geral e coloque as especificidades fora da base do código compilado.
39. Analise o processo para melhorar a concorrência
Explore a concorrência dos processos dos seus usuários.
40. Projete utilizando serviços
Projete em termos de serviços independentes, com interfaces consistentes e para objetos concorrentes e bem definidos.
41. Sempre projete para concorrência
Permita a concorrência e você irá projetar interfaces limpas e com poucas suposições.
42. Separe visões de modelos
Ganhe flexibilidade a um baixo custo projetando suas aplicações em termos de modelos e visões.
43. Use quadro-negro para coordenar processos
Use quadros-negro para coordenar agentes ou fatos discrepantes enquanto mantém a isolação e independência entre os participantes.
44. Não programe por coincidência
Mantenha-se nas coisas confiáveis. Cuidado com complexidade acidental e não confunda uma feliz coincidência com uma regra geral.
45. Estime a ordem dos seus algoritmos
Faça uma estimativa do que algoritmo precisa suportar antes de escrever código.
46. Teste suas estimativas
Análises matemáticas de algoritmos não lhe dizem tudo. Tente medir o desempenho do seu código no ambiente real.
47. Refatore cedo, refatore sempre
Assim como você remove as ervas daninhas e rearranja o jardim, reescreva e reestruture o código constantemente. Corrija na raiz do problema.
48. Projete para os testes
Comece a pensar como testar antes de escrever uma linha de código.
49. Teste o seu software; ou o seu usuário testará por você
Teste arduamente. Não faça o seu usuário encontrar os erros que você deveria ter encontrado.
50. Não utilize assistentes de código que você não entenda
Assistentes podem gerar toneladas de código. Esteja certo de que você entenda tudo o que foi gerado antes de incorporá-lo ao seu projeto.
51. Não colha os requerimentos – Procure por eles profundamente
Requerimentos raramente estão na superfície. Normalmente eles estão soterrados sob várias camadas de suposições, preconceitos e politicagem.
52. Trabalhe com o usuário para pensar como o usuário
Esta é a melhor maneira conseguir inspiração sobre como o sistema será utilizado.
53. Abstrações vivem mais do que detalhes
Invista na abstração, não na implementação. Abstrações podem sobreviver às barreiras criadas pelas mudanças de implementação e pelas novas tecnologias.
54. Use um glossário de projeto
Crie e mantenha uma fonte única com todos os termos e vocabulários específicos do projeto.
55. Não pense fora caixa – Encontre a caixa
Quando confrontado com um problema impossível, identifique as verdadeiras limitações. Pergunte a você mesmo: “Isso precisa ser feito dessa maneira? Isso precisa ser feito por completo?”.
56. Comece quando você estiver pronto
Você adquire experiência durante toda a sua vida. Não deixe passar desapercebido as pequenas dúvidas.
57. Algumas coisas são melhores feitas do que descritas
Não caia na espiral da especificação – em algum momento você precisa começar a codificar.
58. Não seja um escravo dos métodos formais
Não adote uma técnica sem antes analisá-la no contexto de suas práticas de desenvolvimento e capacidade.
59. Ferramentas caras não produzem projetos melhores
Não se impressione somente pelo preço estampado na etiqueta. Julgue as ferramentas pelos seus méritos.
60. Organize o time pela funcionalidade
Não separe os designers dos programadores nem os testadores dos modeladores. Forme os times da mesma maneira que você organiza o código.
61. Não use manual de procedimentos
Um script ou arquivo de lote pode executar as mesmas instruções, na mesma ordem, o tempo todo.
62. Teste cedo. Teste sempre. Teste automaticamente
Testes que rodam a cada build são muito mais eficientes do que planos de testes empoeirados em uma prateleira.
63. O código não está terminado até todos os testes rodarem
E ponto final.
64. Use sabotadores para testar seus testes
Coloque bugs propositalmente em uma cópia separada do código para verificar se os testes irão apontá-los.
65. Teste a cobertura de estados, não a cobertura de código
Identifique e teste estados significativos do programa. Testar apenas linhas de código não é o suficiente.
66. Encontre um bug uma única vez
Quando um testador humano encontrar um bug deve ser a última vez que um humano encontre esse bug. Utilize testes automáticos para verificar esse bug a partir de então.
67. O português também é uma linguagem de programação
Escreva documentos da mesma forma que você escreve código: obedeça ao principio do DRY (não se repita), utilize metadados, MVC, geradores automáticos, etc.
68. Crie documentação durante, ao invés de tentar encaixá-la depois
Documentação criada separada do código muito mais chance de estar incorreta e desatualizada.
69. Supere um pouco as expectativas dos seus usuários
Compreenda quais são as expectativas do seu usuário e então entregue um pouquinho mais do que ele estava esperando.
70. Assine o seu trabalho
Mesmo os primeiros artesões ficavam orgulhosos de assinar seus trabalhos. Você também deveria ficar.

Estas dicas foram extraidas do livro The Pragmatic Programmer

2006-12-27T11:28:00.001-02:00

80 núcleos em um processador?!?!
http://www1.folha.uol.com.br/folha/informatica/ult124u20991.shtml

2006-12-27T11:23:00.000-02:00

YouTube, Google e outros vão matar a TV como a conhecemos?
Para que esperar o horário de um programa se podemos vê-lo na hora que quisermos?

Testando um postador automatico

2006-04-11T00:13:00.000-03:00

Será que isso funciona?

Puts... não é que funciona?

http://www.qumana.com/help.htm

Powered by Qumana

2005-06-23T17:03:00.000-03:00

EU ODEIO "SMARTNAVIGATION"

2005-06-07T11:53:00.000-03:00

"Weird" code...
Só para fazer um "DISTINCT" em um recordset

2005-06-07T11:50:00.000-03:00

Mais uma da série

Dim oFile As System.IO.File
Dim oWrite As System.IO.TextWriter

oWrite = oFile.AppendText("C:\log.txt")

oWrite.WriteLine(sSql)
oWrite.Close()

Isso em um servidor de produção só para "ver" o que tinha em uma variável

2005-06-03T17:25:00.000-03:00

Olha só que maluquice que alguém foi capaz só para colocar um CURRENT DATE ou GETDATE em um insert no banco

sdia = CStr(Day(Date))
If Len(Trim(sdia)) <>
sdia = "0" + sdia
End If

sMes = CStr(Month(Date))
If Len(Trim(sMes)) <>
sMes = "0" + sMes
End If
sAno = CStr(Year(Date))

tmpDataAtual = sAno + "-" + sMes + "-" + sdia

2004-08-20T11:12:00.000-03:00

COM+
Sinceramente a Microsoft se esforçou para fazer algo tão ruim...

2004-08-19T10:34:00.000-03:00

Sinceramente, não existe nada tão decepcionante quanto trabalhar com COM+ e .Net ao mesmo tempo...

2004-08-07T11:58:00.000-03:00

Só comentando...
A comunidade Linux (eu inclusive) que se cuide.
Lá vem chumbo grosso, de acordo com a News.com o Linux pode estar infringindo mais de 200 patentes, inclusive algumas da Micro$oft...

2004-06-16T15:14:00.000-03:00

Falando de strings
Novamente eu venho falar de strings neste blog.

No caso especifico de VB.NET normalmente nós programadores escreveriamos algo como

Dim s as String
s = "texto realmente " + _
    "muito longo " + _
    "blah " + _
    "mais alguns blahs"

para gerar uma string longa (como uma instrucao SQL por exemplo).
Simples, direto, legivel.
Mas...
O sistema de garbage collection do VB.NET tem que fazer alguns malabarismos para gerenciar isso de maneira eficiente, tendo que copiar e realocar varios objetos na memoria para fazer esta concatenacao.
Se acordo com a MSDN seria melhor fazer assim :

Dim s as new System.Text.StringBuilder
s.Append("texto realmente ")
s.Append("muito longo ")
s.Append("blah ")
s.Append("mais alguns blahs")

Mais rapido e menos memoria ocupada.

2004-05-10T18:01:00.001-03:00

Nova tentativa de fazer poesia com linguagens de programação

Module RaulSeixas

Sub Main()

Dim Nasc As DateTime = Now()
While Nasc.AddYears(10000) < Now()
End While
Print("Eu nasci a 10.000 anos atras")

End Sub

End Module

2004-04-23T13:29:00.000-03:00

Olha eu me metendo a adaptar poesia para C ...

#include <stdio.h>
int main(int argc, char** argv){

if(0) {

printf("Há sempre a pequena chance,de o impossível rolar\n");

}

2004-03-08T12:44:00.000-03:00

Sonhos de consumo :

PDA com Linux
Notebook Acer Ferrari

2004-03-08T12:32:00.000-03:00

Bodyshop em cliente para desenvolvimento Winform .NET
Ninguém merece...

2004-02-27T10:10:00.000-03:00

As melhores coisas do mundo são de graça...
No nosso mundo alguns exemplos que amo

Eclipse - "O" IDE opensourse
CVS - Controle de versões

2004-02-20T08:35:00.000-03:00

XML - Uma solução ou um pesadelo de performance?

Sei que vou ser crucificado pelos meus colegas, mas vou fazer uma reflexão quanto a linguagem XML ser usada para manipulação de grande quantidade de dados.

A linguagem XML (EXtended Markup Language) a grosso modo é um formato de arquivo texto plano que tem sido extensivamente utilizado (entre outras coisas) para tranferência e manipulação de dados.

Um exemplo:

<?xml version="1.0" encoding="utf-8"?>

<what>

Profissional de TI
Especialista em LAMP

</what>

<where>

Atualmente residindo em Uberlandia - MG

</where>

<email>cleveranjos@yahoo.com</email>

</contact>

</clever>

</xml>

Este formato de arquivo, além de facilitar em muito a leitura (sendo quase auto-explicativo, na verdade) permite uma grande flexibilidade no envio e recebimento de informações entre sistemas (homogêneos ou não)

Mas nem tudo são flores

Imagine agora um arquivo (ou um fluxo de dados) XML e que você tenha que selecionar os 10 registros apartir do 5^o. Imagine também uma sentença XSQL (linguagem SQL fictícia para um banco orientado a XML)

SELECT * FROM xml_stream LIMIT 10,5

Você é o responsável por implementar esta busca no seu banco de dados, qual algoritmo você usaria?

Na maioria das linguagens de programação existem "parsers" que fazem o trabalho sujo e você simplesmente faria :

' Exemplo em VB.NET
Private Function ReturnSlice(ByVal xml_stream As String, ByVal iFrom As Integer, ByVal iTo As Integer) As String

Dim ds As New DataSet()
Dim out As String
Dim i As Integer
ds.ReadXml(New IO.StreamReader(xml_stream)) ' Preste atenção nesta linha
For i = iFrom To iTo

out = out & ds.Tables(0).Rows(i).Item(0)

Next
Return out

End Function

Simples não? O grande problema está na linha ds.ReadXml(New IO.StreamReader(xml_stream)) . Por trás desta simples linha de código existe um "parser" que deve ler a string caracter por caracter e montar uma árvore na memória para que possa tudo ser transferido para um DataSet onde podemos ter um acesso aleatório aos dados. Agora imagine uma xml_stream de 1.000.000 de registros :-((

Então chegamos ao grande problema do XML, todas as vezes devemos ler o xml caracter a caracter e não podemos simplesmente "pular" os próximos 2Mb do arquivo, pois simplesmente não há como saber onde devemos recomeçar a ler.

Lógico que existe solução para resolver este "problema">. Uma pode ser um arquivo de índice associado que indique o começo de cada registro ou coluna (ou qualquer combinação destes), mas aí teríamos que enviar juntamente com o XML um arquivo .XMLIndex (o nome é minha invenção) que jogaria por terra qualquer ganho de possível performance ou flexibilidade.

Então, sempre que for utilizar um XML, talvez valha a pena refletir:

Qual o volume de dados que vão ser transferidos?
Quão aleatórios serão os acessos a estas informações?
O parser que vou utilizar é realmente eficiente para estes dados? Ou seria melhor eu escrever o meu próprio?

Sei que isso são conjecturas de um aficcionado por algoritmos, mas não custa lembrar que nem sempre a solução mais fácil é a melhor.

2004-02-19T14:32:00.000-03:00

Olha só o que o nosso coordenador faz conosco as vezes

2004-02-18T11:33:00.000-03:00

Uma dos melhores "gadgets" que já foram inventados...

2004-02-17T14:45:00.000-03:00

:-))))

2004-02-16T13:20:00.000-03:00

Existem alguns poetas no nosso meio:
Retirado de : Perl Poetry

#!/usr/bin/perl
# Beatles song:
submarine : yellow {

we(all,live)

}

# A small portion of: While my guitar gently weeps
# Lyrics and Music by: George Harrison (RIP)
# Adapted to Perl by: bronto
# Notes: I know, I know: s/lock/look/ :-)

while (my $guitar->weeps($gently)) {

I: { lock @you_all }
see_the_love($there,$thats) ;
sleep$ing ;
I: { lock @the_floor and i_see($it_needs,$sweeping) };

}