jeorane Blog

Procurando um lugar espetacular para passar a sua lua-de-mel?
Que tal uma noite numa suíte embaixo da água?
Tem champanhe, café da manhã e a companhia de muitos peixes.

Clique nas fotos abaixo para ver em alta resolução (a imagem é enorme , é melhor clicar com o botão direito e salvá-la em seu computador, ou abrir em outra guia ou aba).

Dia

Noite

O hotel é esse aqui. Fica na República das Maldivas

Fonte: The Brides Guide

Jeorane

A idéia principal de "A Origem":
Se você executar uma VM dentro de uma VM dentro de uma VM dentro de uma VM, tudo vai ficar muito devagar.

Jeorane

A calça do modelo abaixo tem bolsos pra iPhone e iPad, é só um protótipo.

Eles tem outros modelos mais interessantes Aqui.

Jeorane

Está precisando de ideias para a sua nova cozinha?

Visite esse site: http://www.houzz.com/photos/kitchen - Lá tem mais de 6500 fotos, e esse número está aumentando.

Eu sei que muitos usuários desse site vão torcer o nariz para esse artigo, mas a cozinha é tão ou mais importante que a sala de jogos, por exemplo.

Jeorane

As ideias expressas nesse vídeo são muito interessantes. É notável que quase nenhuma dessas ideias tenha se concretizado até hoje, 50 anos depois.

Ao assistir esse vídeo tenha em mente que:

• Esse filme foi feito em 1958
• Não existia computação gráfica
• Então ele foi feito à mão!

Jeorane

O filme "A Origem" merece ser assistido duas vezes ou mais, eu o definiria como sendo o filme "Matrix" ao quadrado ou ao cubo.
Alguém percebeu um detalhe sobre a música do filme e postou no vídeo abaixo: na verdade essas 2 músicas do filme são a mesma, só que em velocidades diferentes. Quem assistiu ao filme vai entender a razão, e vai achar genial.

Fonte: Boing Boing

Jeorane

Look at this block of text until you become bored with it. When you become bored with it, instead of instinctively redirecting attention to something more stimulating, notice the slight agitation that has come and try to resist it. This is not to make you tolerable of things that are mundane, but to help build back your attention span that the internet has taken away from you.

Fonte: David Horvitz

O princípio da liberdade é a consciência de que você não é "o pensador". No momento em que começar a observar o pensador, um alto nível de consciência torna-se ativado. Você, então, começa a perceber que existe uma vasta área de inteligência além do pensamento, que o pensamento é apenas um pequeno aspecto dessa inteligência. Perceberá também que todas as coisas que realmente importam - beleza, amor, criatividade, alegria, paz interior - surgem além da mente.

"Esteja onde você estiver. Olhe em volta. Apenas olhe, não interprete. Veja a luz, formas, cores, texturas. Esteja consciente da presença silenciosa de cada coisa. Esteja consciente do espaço que permite tudo ser. "

O texto abaixo é do Giovanni Bassi. Achei muito interessante e por isso resolvi reproduzi-lo aqui.

Mitos sobre Stored Procedures

Com razoável frequência alguém levanta a ideia de usar stored procedures (procs, para abreviar) porque melhora segurança e performance.

Como eu sei que isso não é verdade, e o assunto é levantado sempre, vou escrever esse post, depois é só linkar.

Geralmente as consultas via procs são comparadas com queries feitas com texto SQL, que vou chamar de ad-hoc. Esse tipo de consulta é aquela onde você escreve “SELECT Id, Campo FROM Cliente WHERE Id = 1” e manda direto para o banco, e é também o usado por mapeadores objeto relacional (ORMs).

Vamos aos mitos:

1. "Stored Procedures permitem fazer cache do plano de execução, enquanto consultas ad-hoc não permitem"
   Mito. Os planos de execução são armezanados para reutilização em procs e também em consultas ad-hoc. Vejam essa afirmação do MSDN:
   “In SQL Server 2000, whenever a statement within a batch causes recompilation, the whole batch, whether submitted through a stored procedure, trigger, ad-hoc batch, or prepared statement, is recompiled. In SQL Server 2005 and later, only the statement inside the batch that causes recompilation is recompiled.” Daqui.
   Esse outro artigo entra mais a fundo. Notem que o importante é o uso de parâmetros, não só para evitar o SQL Injection, mas também para permitir o cache do plano de execução (algo que o SQL Server 2008 já tenta resolver, mesmo se você não enviar o parâmetro).
2. "Stored Procedures estimulam reusabilidade"
   Mito. Reusabilidade pode ser atingida de diversas formas. Um modelo procedural, como o da programação de um banco de dados relacional, possibilita reusabilidade dentro deste paradigma. Eu prefiro estimular reusabilidade com OO, mas isso não quer dizer que não podemos reutilizar tanto em um quanto no outro.
3. "Stored Procedures ajudam a encapsular regras de negócio"
   Mito. Eu posso encapsular, com mais produtividade na programação, em um modelo OO.
4. "Stored Procedures são mais seguras"
   Com procs você pode remover os direitos a insert, update, delete e consulta, inclusive com granularidade na coluna de uma tabela.
   Mito. Ainda que seja possível fazer isso, se em uma operação de negócio o usuário precisa atualizar um campo, ele terá que ter acesso de atualização deste campo, se não direto, indiretamente pela proc. Isso fica ainda mais irrelevante quando vemos aquelas procs de CUD, ou seja, quando o programador cria 3 procs, uma para cada operação do CUD, e simplesmente pega os parâmetros e repassa para as declarações de insert, update e delete. A proc nesse caso é um mero proxy. A outra opção é colocar a regra de negócio no banco, algo absurdo na maioria dos cenários (não vou me aprofundar no porquê, vai ficar para outro post).
5. "Stored Procedures diminuem o consumo de banda, já que a consulta que vai ao banco é somente o nome da proc e seus parâmetros"
   Meia verdade. De fato a operação que vai ao banco é menor. Mas em uma operação de consulta, o maior peso está no retorno da consulta, cheio de dados, e não na solicitação, que é um texto curto. A diferença entre a consulta com proc e sem chega a ser ridícula. E em uma operação de atualização do banco, os dados que vão subir tem que ser enviados da mesma forma, e o resto da declaração de uma operação ad-hoc é só um pouco maior se comparado com a proc. Além disso, nas redes de hoje, com servidores web ao lado de servidores de banco em rede gigabit, o gargalo não fica na rede.

Além destes mitos, o que mais me incomoda é que procs praticamente impedem o uso de ORMs. E ORMs são praticamente obrigatórios em um projeto que quer ter um mínimo de produtividade. Escrever SQL na mão hoje em dia é algo absolutamente desnecessário para 90% das aplicações, e nos 10% que sobram, só um pequeno percentual teria algum ganho sobre o uso de SQL manual sobre um ORM. Mas isso fica para outro post também.

Um caso onde vejo uso de procs como útil: ETL. Geralmente é muito difícil fazer carga de grandes massas de dados via interação com o client, seja ele .Net, Java, C++, VB6, ou o que for. O ideal é a carga acontecer no banco, e aí procs vão bem. O maior problema, derivado do ETL, é a duplicação de regras de negócio, já que uma operação de negócio que entra via carga externa estará sujeita às mesmas regras de uma entrada manual, normalmente também permitida. É algo que aumenta o custo de manutenção, mas muitas vezes não tem jeito.

É isso. Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos

Fonte: .Net Unplugged

Eu vivo em um mundo de fantasia
Então, mantenha a sua realidade longe de mim
Eu vejo o que eu quero
Eu quero o que eu vejo
E isso é tudo
Ok para mim

Itzah C. Kret

Jeorane