Elegância Vs Desempenho

Na maior parte das vezes fazer código elegante (que seja extensível, de fácil manutenção, etc) e com bom desempenho é a mesma coisa que por duas pessoas em extremos opostos de uma corda a puxarem para seu lado.

A minha filosofia em relação a este assunto é que os problemas de desempenho podem ser numa primeira fase postos um pouco de lado, a não ser que se saiba à partida que estamos a fazer um pedaço de software que necessita de ter um desempenho optimizado ao máximo. Geralmente os maiores problemas surgem quando o que está feito não é exactamente o pretendido pelo cliente, logo o melhor é ter um código que facilmente se modifique e se adapte a novas necessidades.

Logo a fórmula que uso será 80% para elegância e 20% para desempenho, isto traduzindo na prática é o mesmo que dizer que dou privilégio a um código de fácil extensibilidade e manutenção, mas quando vejo que isso me vai claramente custar no desempenho procuro uma solução alternativa/intermédia.

SQL - Update com IN

Há vezes que tenho o mau hábito de complicar o que é fácil e este foi um desses casos. O contexto do problema é o seguinte, tenho as tabelas Principal e Secundary que se relacionam através do campo principalId existente nas duas, e quero alterar um outro campo da tabela Secundary condicionando esse update com base na tabela Principal.

O SQL seguinte dá-me as linhas da tabela Secundary que quero afectar:

select * from Secundary as sec1
where sec1.principalId in
(select p.principalId from Principal as pr1
inner join Secundary as sec2 on sec2.principalId = pr1.principalId
where pr1.owner >= 10 and sec2.conditionId = 5)

O select interior estabelesse a relação e condiciona o resultado com base na tabela Principal (pr1.owner >= 10) e na tabela Secundary (sec2.conditionId = 5). Agora (pensava eu) basta passar o select de fora para update e tenho o resultado que quero:

update Secundary as sec1
set sec1.conditionId = 1
where sec1.principalId in
(select p.principalid from Principal as pr1
inner join Secundary as sec2 on sec2.principalId = pr1.principalId
where pr1.owner >= 10 and sec2.conditionId = 5)

Acontece um erro porque não posso usar a tabela Secundary no select, o que se formos a ver faz todo o sentido porque estaria a usar um conjunto mutável para condicionar o seu próprio update o que não faz de todo sentido. Simplificando a coisa obtive o seguinte select cujo resultado é igual ao do primeiro:

select * from Secundary as sec1
where sec1.principalId in
(select p.principalid from Principal as pr1
where pr1.owner >= 10 ) and sec1.conditionId = 5

Passar isto para um update é agora directo:

update Secundary as sec1
set sec1.conditionId = 1
where sec1.principalId in
(select p.principalid from Principal as pr1
where pr1.owner >= 10 ) and sec1.conditionId = 5

Trabalhar em casa

Há 6 meses atrás comecei a trabalhar em casa e posso dizer que até agora tem sido algo que me agrada bastante, enganem-se aquelas pessoas que dizem que se trabalha menos porque é totalmente mentira, trabalha-se mais mas também temos outras vantagens.

Existem algumas regras que cumpro religiosamente, como a hora que começo a trabalhar, nunca depois das 9h, acho que a principal caracteristica para o sucesso de trabalhos desenvolvidos em casa é mesmo a disciplina que a pessoa tem em cumprir regras que normalmente tem no local de trabalho, onde está a ser "vigiado".

Quanto a vantagens as principais são tempo e dinheiro. Dinheiro, porque não gasto combustível ou passes de transportes, apesar de ir regularmente ao escritório compro bilhetes só para essas alturas o que não é assim um grande gasto. Tempo, porque não perco diariamente 2h30m desnessárias a andar de um lado para o outro e posso aproveitar esse tempo para coisas mais produtivas ou lúdicas.

tops.zi-yu.com

O Tops é o último site criado pela equipa zi-yu. Este site é um agregador onde se podem registar outros sites fazendo assim parte de uma tabela (top). Existem diferentes categorias já disponíveis mas se for necessário criar alguma nova é só contactarem-nos.

Multidão estátua

Este foi um 'Apanhados' feito em New York está simplesmente brutal. Pelo que parece querem fazer o mesmo tipo de iniciativa aqui na nossa Lisboa.

SQL - detectar valores repetidos

Imagine-se o cenário que é a meio do desenvolvimento de uma aplicação uma coluna que não era unique ter de passar a sê-lo, mas ao mesmo tempo temos de manter os dados que já estão carregados na tabela, detectando os que estão repetidos e alterando só esses para cumprir a restrição da coluna ter valores unique.

O script seguinte é um exemplo de como podemos obter os valores repetidos:

SELECT colName, COUNT(colName) AS cnt
FROM tableName
GROUP BY colName
ORDER BY cnt desc

Stargate Atlantis

Devo dizer que eu era um grande fã do velhinho Stargate SG1, mas acho que deveria ter ficado pela 7ª season, as últimas 3 foram um desastre total uma falta de imaginação dos argumentistas para fazerem bons episódios, já para não falar do último episódio da season 10 que é o último episódio desta série...uma série destas merecia um final melhorzinho!

No que toca ao Atlantis acho que acabou por 'apanhar por tabela', já que o seu lançamento foi coincidente com a season 8 do SG1, logo o meu desinteresse aumentava e eu nunca me fidelizei muito à Atlantis. Contudo nestes últimos dias andei a 'devorar' os episódios da Atlantis e devo dizer que está a um nível tão bom como os primeiros episódios da SG1. A season 5 vai ser lançada no final de Julho ou início de Agosto, estou mesmo a esfregar as mãos já que como é habitual no Stargate o último episódio da season é um 'to be continue' para o 1º episódio da season seguinte. Só peço uma coisa, não arrastem este Stargate até à tortura como aconteceu com o SG1!

Contra a subida dos preços dos combustíveis

Quando o preço dos combustíveis fui liberalizado, muita gente pensava que a concorrência iria fazer com que os preços descessem, eu sempre pensei que o cartel se iria unir para andarem a subir constantemente os preços, infelizmente eu tinha razão.

Recebi o seguinte mail, com a proposta de uma iniciativa, à qual vou alinhar a 100%:

"1, 2 e 3 de JUNHO DIAS SEM ABASTECIMENTO NA GALP- BP- REPSOL

Eu vou alinhar...Garantidamente.

Vamos fazer a diferença!
Isto tem que começar por algum lado!
Vamos passar a palavra e não ser indiferentes, temos que fazer com que as coisas mudem!
A subida vertiginosa do preços dos combustíveis tem que parar e temos que fazer com que baixem!

Para tal vamos combinar três dias nacionais seguidos de NÃO ABASTECIMENTO NA BP, GALP, REPSOL!

Esses dias serão o 1 -2 -3 de Junho que vem!
VAMOS FAZER A DIFERENÇA!
Nesses dias abasteçam em outros postos de combustíveis tais como a Esso, Total, Continente (antigo Carrefour), Intermarché, Jumbo e Eleclerc!
Juntos teremos força para baixar os lucros destes gigantes!
Agora é só passar a palavra com urgência!
Estou farto de ser levado na hora de pagar!
CHEGA!
SEJAMOS UNIDOS PORTUGUESES E TODOS OS QUE TENTAM SOBREVIVER EM PORTUGAL!

NÃO ESQUEÇAM 1 - 2 - 3 de JUNHO que vem Não Abasteçam na BP, GALP e REPSOL!
*FORÇA PORTUGAL!*

Passem ao maior número de pessoas que conheçam."

Prós e Contras - Apito Final

Acabei de assistir a este programa que nesta emissão teve como tema o processo apito final, tendo a participação de algumas figuras de relevo no panorama desportivo nacional. Uma dúvida me assombrou depois de ver o programa - O que acabei de ver? Uma sessão de circo com um bando de palhaços, um sketch humorístico ou um dia normal na assembleia da república?

Get MasterPage

O código para obter a MasterPage de uma página é algo bastante simple, basta numa página que esteja a utilizar uma MasterPage fazer o seguinte:

SiteMaster thisMaster = this.Master as SiteMaster;

Contudo não me agrada o cast explícito que necessito fazer, pois a propriedade Master retorna um objecto do tipo System.Web.UI.MasterPage, porque será que esta propriedade por reflexividade não obtem o type da MasterPage e não retorna logo um objecto correctamente tipado? Seria muito mais útil e tornaria o código mais "limpo" e menos sujeito a erros.