Hello my dear friends. In this article I will talk about my new little app - PgTune.

PgTune?

To optimize the settings for PostgreSQL based on maximizing performance for a given hardware configuration Gregory Smith in 2008 created a utility pgtune. The utility is easy to use and in many Linux systems can go in packages. But exists several problems about this tool:

• Not maintained (last release: October 29, 2009), what is why it have the old methods of calculation configurations for PostgreSQL
• Need to download/install it for usage

What is why I created online version of PgTune. Main benefits:

• Updated calculation for PostgreSQL config
• Don’t need to download or install anything
• Can work offline
• Can work as mobile application

And, of course, it is open source.

Offline mode

At the first loading of the page, you no longer need access to the Internet to use PgTune. It will work offline (without internet connection) by using Application Cache technology.

Mobile app

We can “install” PgTune as mobile app, because the application can operate without access to the internet.

Steps for iOS:

• Open up Safari on your iOS device
• Navigate to the PgTune page
• Tap the Share button (it’s an icon that’s a box with an arrow sticking out from it)
• Tap on Add to Home Screen
• On the next page you’ll give the shortcut a name and confirm the web address
• After that, tap on Add in the upper-right corner to add the PgTune app to your home screen

Steps for Android:

• Open the browser on your Chrome Android
• Navigate to the PgTune page
• Hit the settings button – it’s three vertical dots, locating in the top right of the screen
• Tap on “Add to Homescreen”
• On the next page you’ll give the shortcut a name
• After that, tap on Ok button to add the PgTune app to your home screen

As you can see, it is very simple to add it as mobile app.

Summary

PGTune calculate configuration for PostgreSQL based on the maximum performance for a given hardware configuration. It isn’t a “silver bullet” for the optimization settings of PostgreSQL. Many settings depend not only on the hardware configuration, but also on the size of the database, the number of clients and the complexity of queries, so that optimally configure the database can only be given all these parameters. But I hope it will help to start of tunning PostgreSQL.

That’s all folks! Thank you for reading till the end.

Em Maio a sua carteira fechou com rendimento aproximado de 1,35% (157% do CDI)

…foi o que veio no meu último relatório de investimentos consolidado. A melhor coisa desse relatório é a transparência, perceptível nos números e gráficos claros e fáceis de entender.

Na minha jornada para melhorar meus investimentos, aprendi que bancos de varejo (os que tem muitas agências), como Personnalité e Bradesco, tem uma necessidade latente que seus clientes sejam e se mantenham totalmente ignorantes financeiramente. Repare como você não entende praticamente nada do que os consultores de investimentos desses bancos falam. Isso é proposital e não pura ignorância sua. Repare como nunca comparam espontaneamente seus produtos com índices relevantes do mercado, tipo o CDI. Se você tiver saco para comparar a performance desses produtos com números e gráficos de mercado (veja abaixo um exemplo), verá que não faz o menor sentido investir ali.

Esta é a fórmula para um leigo como eu investir melhor:

1. Ter conta num banco/corretora que te dá acesso a muitos produtos de investimento baratos e de alta qualidade: LCIs, LCAs, CDBs, debêntures, centenas de fundos, Tesouro Nacional, ações etc. Recomendo a XP. O Personnalité, por exemplo, tem só uns poucos fundos dele mesmo que são caros (taxa de administração alta) e não performam muito bem.
2. Você não saberá onde investir, então precisará de um consultor de investimentos que te liga para dar status e recomendar o investimento certo para aquele período e eventuais mudanças na carteira (tipo “esse fundo ficou ruim, vamos para aquele outro”). Esse relacionamento é provido por parceiros da XP (chamados de acessores) e não pago nada a mais por isso. É imprescindível, sem ele eu não saberia onde investir corretamente.

Quando eu investia no Itaú Personnalité, eu tinha medo de ir falar com meu gerente de conta. Tinha que ser ao vivo, sempre me faziam esperar, ele/ela atendia ligações durante a reunião, eu não entendia nada do que ele falava e sempre saia com impressão de que etavam tentando me enrolar, de que havia uma agenda escondida por trás daquela conversa. Isso fazia eu achar que precisava aumentar minha cultura financeira, ler jornal, entender de índices, para eu mesmo saber onde investir. Como eu nunca tinha tempo para essa pós-graduação informal, deixava dinheiro parado e não investido por meses na minha conta. Acredito que muitas pessoas sofrem desse mal.

Como na XP meu consultor me liga proativamente a cada 15 ou 30 dias, ele me diz o que fazer. E a diferença entre os conselhos dele e do Personnalité é que ele tem um portfólio muito maior para oferecer e seu compromisso é somente comigo, não com o produto que oferece. Eu só trato de perguntar sobre a liquidez (em quanto tempo tenho o dinheiro de volta, caso precise dele), rendimento/volatilidade, solidez da instituição do investimento, alíquota de IR. E principalmente a taxa de administração. Produtos como LCI são isentos de IR e não tem taxa de administração, mas tenho certeza que nunca te ofereceram isso num banco de varejo.

Para você ter uma idéia mais visual da aberração que é investir num banco de varejo, veja esta simples comparação de 2 fundos de mesmo tipo (multimercado): o Legan Low Vol FIM e o Personnalité Multimercado Arrojado FIM:

O Personnalité MM Arrojado é muito mais caro. Mas o mais ridículo é a comparação dos gráficos desses dois fundos (extraido do ótimo ComparaçãoDeFundos.com).

Observe como o fundo Personnalité (vermelho) rende sempre menos que o CDI (um benchmark de mercado, em preto) e com altíssima volatilidade (a variação esquizofrênica da curva). E como o Legan Low Vol (azul) rende sempre mais que o CDI — o que denota melhor performance — e é muito mais constante, suave e principalmente previsível. Gráficos assim são ferramentas poderosíssimas pois em poucos segundos fica claríssimo, até para um leigo como eu, qual é o melhor investimento.

Fui vítima desse Personnalité Multimercado Arrojado por muitos anos e meu gerente de conta nunca se deu ao trabalho de me avisar que estava indo mal. Nunquinha, nem mesmo para eu me mudar para outro de seus produtos. Essa experiência me ensinou que um banco de varejo quer te manter ignorante e por isso nunca vai te mostrar um gráfico comparativo fácil de entender a situação geral como esse acima. Eles preferem mostrar tabelas com números de rendimento absoluto, nunca relativo ou comparado, que são muito mais difíceis de entender e avaliar. Isso só pode ser uma prática de falta de transparência, para manipular sua compreensão sobre o produto e sobre o mercado. Fuja disso.

Ao contrário do que se pensa, não é preciso muito dinheiro para investir com eficiência. Qualquer R$5.000,00 ou R$10.000,00 é suficiente para começar. E ao contrário do que se pensa, Itaú, Bradesco e Santander não são as únicas instituições sólidas e confiáveis do Brasil, mas as pessoas tem essa percepção (errada) porque esses bancos fazem muita publicidade e porque tem agências e caixas-eletrônicos expostos nas ruas fortalecendo a marca. A XP, por outro lado, é uma corretora que funciona como uma espécie de facilitador: eles te dão relatórios consolidados mas o investimento propriamente dito acontece diretamente em instituições solidas como BNP Paribas, J.P.Morgan, BTG Pactual e diversos outros. Se a XP falir (incrível como principiantes sempre levantam esta hipótese), seu CPF e o dinheiro que você investiu continuam intactos no JPM, BNP etc. O modelo de negócio da XP faz total sentido para quem adquriu um mínimo de educação financeira e por isso eu recomendo. Na verdade, antes de te recomendar fazer seus investimentos na XP, recomendo você abrir seus olhos para como os bancos de varejo tratam você e seu dinheiro; você não vai gostar quando entender. Por exemplo, comece tentando descobrir quanto foi o rendimento total de sua carteira, como dei o exemplo da minha na primeira frase deste artigo.

Para quem pergunta, meu acessor é o Luis Magalhães [blog dele] da Alta Vista Investimentos, empresa parceira da XP Investimentos. O Luís me foi indicado numa conversa de final de semana no clube por um amigo que conhece finanças e investimentos bem melhor do que eu.

E bons investimentos !

Também publicado no Facebook

The post Como investir seu dinheiro appeared first on Avi Alkalay.

With the release of PostgreSQL 8.4, the community gained the ability to use CTE syntax. As such, this is a fairly old feature, yet it’s still misunderstood in a lot of ways. At the same time, the query planner has been advancing incrementally since that time. Most recently, PostgreSQL has gained the ability to perform index-only scans, making it possible to fetch results straight from the index, without confirming rows with the table data.

Unfortunately, this still isn’t enough. There are still quite a few areas where the PostgreSQL query planner is extremely naive, despite the advances we’ve seen recently. For instance, PostgreSQL still can’t do a basic loose index scan natively. It has to be tricked by using CTE syntax.

To demonstrate this further, imagine this relatively common scenario: an order processing system where clients can order products. What happens when we want to find the most recent order for all current customers? Boiled down to its minimum elements, this extremely simplified table will act as our order system.

CREATE TABLE test_order
(
  client_id   INT        NOT NULL,
  order_date  TIMESTAMP  NOT NULL,
  filler      TEXT       NOT NULL
);

Now we need data to test with. We can simulate a relatively old order processing system by taking the current date and subtracting 1,000 days. We can also bootstrap with 10,000 clients, and make the assumption that newer clients will be more active. This allows us to represent clients that have left our services as time goes on. So we start with this test data:

INSERT INTO test_order
SELECT s1.id,
       (CURRENT_DATE - INTERVAL '1000 days')::DATE 
           + generate_series(1, s1.id%1000),
       repeat(' ', 20)
  FROM generate_series(1, 10000) s1 (id);

The generate_series function is very handy for building fake data. We’re still not ready to use that data, however. Since we want to find the most recent order for all customers, we need an index that will combine the client_id and order_date columns in such a way that a single lookup will provide the value we want for any particular client. This index should do nicely:

CREATE INDEX idx_test_order_client_id_order_date
    ON test_order (client_id, order_date DESC);

Finally, we analyze to make sure the PostgreSQL engine has the most recent stats for our table. Just to make everything easily repeatable, we also set the default_statistics_target to a higher value than default as well.

SET default_statistics_target TO 500;
ANALYZE test_order;

Now we’ll start with the most obvious query. Here, we just use the client_id column and look for the max order_date for each:

EXPLAIN ANALYZE
SELECT client_id, max(order_date)
  FROM test_order
 GROUP BY client_id;

The query plan is fairly straight-forward, and will probably include a sequence scan. On the virtual server we’re testing with, the total runtime for us ended up looking like this:

Total runtime: 1117.408 ms

There is some variance, but the end result is just over one second per execution. We ran this query several times to ensure it was properly cached by PostgreSQL. Why didn’t the planner use the index we created? Let’s assume the planner doesn’t know what max does, and treats it like any other function. With that in mind, we can exploit a different type of syntax that should make the index much more usable. So let’s try DISTINCT ON with an explicit ORDER clause that matches the definition of our index:

EXPLAIN ANALYZE SELECT DISTINCT ON (client_id) client_id, order_date FROM test_order ORDER BY client_id, order_date DESC;

Well, this time our test system used an index-only scan, and produced the results somewhat faster. Our new runtime looks like this:

Total runtime: 923.300 ms

That’s almost 20% faster than the sequence scan. Depending on how much bigger the table is than the index, reading the index and producing these results can vary significantly. And while the query time improved, it’s still pretty bad. For systems with tens or hundreds of millions of orders, the performance of this query will continue to degrade along with the row count. We’re also not really using the index effectively.

Reading the index from top to bottom and pulling out the desired results is faster than reading the whole table. But why should we do that? Due to the way we built this index, the root node for each client should always represent the value we’re looking for. So why doesn’t the planner simply perform a shallow index scan along the root nodes? It doesn’t matter what the reason is, because we can force it to do so. This is going to be ugly, but this query will act just as we described:

EXPLAIN ANALYZE
WITH RECURSIVE skip AS
(
  (SELECT client_id, order_date
    FROM test_order
   ORDER BY client_id, order_date DESC
   LIMIT 1)
  UNION ALL
  (SELECT (SELECT min(client_id)
             FROM test_order
            WHERE client_id > skip.client_id
          ) AS client_id,
          (SELECT max(order_date)
             FROM test_order
            WHERE client_id = (
                    SELECT min(client_id)
                      FROM test_order
                     WHERE client_id > skip.client_id
                  )
          ) AS order_date
    FROM skip
   WHERE skip.client_id IS NOT NULL)
)
SELECT *
  FROM skip;

The query plan for this is extremely convoluted, and we’re not even going to try to explain what it’s doing. But the final query execution time is hard to discount:

Total runtime: 181.501 ms

So what happened here? How can the abusive and ugly CTE above outwit the PostgreSQL query planner? We use the same principle as described in the PostgreSQL wiki for loose index scans. We start with the desired maximum order date for a single client_id, then recursively begin adding clients one by one until the index is exhausted. Due to limitations preventing us from using the recursive element in a sub-query, we have to use the SELECT clause to get the next client ID and the associated order date for that client.

This technique works universally for performing sparse index scans, and actually improves as cardinality (the number of unique values) decreases. As unlikely as that sounds, since we are only using the root nodes within the index tree, performance increases when there are less root nodes to check. This is the exact opposite to how indexes are normally used, so we can see why PostgreSQL doesn’t natively integrate this technique. Yet we would like to see it added eventually so query authors can use the first query example we wrote, instead of the excessively unintuitive version that actually produced good performance.

In any case, all PostgreSQL DBAs owe it to themselves and their clusters to learn CTEs. They provide a powerful override for the query planner, and helps solve the edge cases it doesn’t yet handle.

Postgres has a variety of datatypes, in fact quite a few more than most other databases. Most commonly applications take advantage of the standard ones – integers, text, numeric, etc. Almost every application needs these basic types, the rarer ones may be needed less frequently. And while not needed on every application when you do need them they can be an extremely handy. So without further adieu let’s look at some of these rarer but awesome types.

hstore

Yes, I’ve talked about this one before, yet still not enough people are using it. Of this list of datatypes this is one that could also have benefit for most if not all applications. Hstore is a key-value store directly within Postgres. This means you can easily add new keys and values (optionally), without haveing to run a migration to setup new columns. Further you can still get great performance by using Gin and GiST indexes with them, which automatically index all keys and values for hstore.

It’s of note that hstore is an extension and not enabled by default. If you want the ins and outs of getting hands on with it, give the article on Postgres Guide a read.

Range types

If there is ever a time where you have two columns in your database with one being a from, another being a to, you probably want to be using range types. Range types are just that a set of ranges. A super common use of them is when doing anything with calendaring. The place where they really become useful is in their ability to apply constraints on those ranges. This means you can make sure you don’t have overlapping time issues, and don’t have to rebuild heavy application logic to accomplish it.

Timestamp with Timezone

Timestamps are annoying, plain and simple. If you’ve re-invented handling different timezones within your application you’ve wasted plenty of time and likely done it wrong. If you’re using plain timestamps within your application further there’s a good chance they dont even mean what you think they mean. Timestamps with timezone or timestamptz automatically includes the timezone with the timestamp. This makes it easy to convert between timezones, know exactly what you’re dealing with, and will in short save you a ton of time. There’s seldom a case you shouldn’t be using these.

UUID

Integers are primary keys aren’t great. Sure if you’re running a small blog they work fine, but if you’re application has to scale to a large size integers can create problems. First you can run out of them, second it can make other details such as sharding a little more annoying. At the same time they are super readable. However, using the actual UUID datatype and extension to automatically generate them can be incredibly handy if you have to scale an application.

Similar to hstore, there’s an extension that makes the UUID much more useful.

Binary JSON

This isn’t available yet, but will be in Postgres 9.4. Binary JSON is of course JSON directly within your database, but also lets you add Gin indexes directly onto JSON. This means a much simpler setup in not only inserting JSON, but having fast reads. If you want to learn a bit more about this, sign up to get notified of training regarding the upcoming PostgreSQL 9.4 release.

Money

Please don’t use this… The money datatype assumes a single currency type, and generally brings with it more caveats than simply using a numeric type.

In conclusion

What’d I miss? What are you’re favorite types? Let me know @craigkerstiens, or sign-up below to updates on Postgres content and first access to training.

Segundo o desenvolvedor, o ganho de desempenho em sites WordPress é de 20%, Drupal 6.1 ganha 11,7%), e Zend Framework ganha 30,5%.

Via info.abril.com.br:

Depois de quatro meses de esforço, um desenvolvedor russo anunciou nesta segunda-feira uma grande reforma na engine do PHP. Funcionário da Zend, empresa que trabalha com aplicações baseadas na linguagem de interpretação, Dmitry Stogov revelou que obteve um ganho de 20% no desempenho do Wordpress 3.6, por exemplo, com as alterações – bem drásticas, diga-se – feitas por ele e alguns colaboradores no núcleo.

As alterações incluem, por exemplo, a presença parcial de tradução dinâmica (compilação just-in-time, ou JIT) no núcleo. De forma simplificada, só isso já aceleraria uma boa parte do processo de execução por fazer a pré-interpretação de um aplicativo.

As mudanças foram implantadas em uma versão bem prematura do PHP 5.7, e ainda se encontram em caráter inteiramente experimental, com problemas de compatibilidade e falhas gerais, como observa Solgov no comunicado. Hoje, a linguagem está na edição 5.5, com a 5.6 em fase beta.

O artigo "Funcionário da Zend anuncia versão reformulada do PHP que melhora desempenho do WordPress, Drupal e mais" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

It’s always odd to hear people say RSS is dead. The fact is, RSS is easily the most successful stealth, insurgent technology on the web. It is pervasive and is the engine for much of the Internet.

Apple uses it to syndicate computer updates. Your podcast subscriptions rely on RSS. Every Wordpress blog is RSS enabled and every major news site is broadcasting via RSS. They’re all syndicated. They all have an RSS feed. It’s the background hum of the Internet.

There are millions of feeds out there, continually connecting users to their favorite content. Just about everything online except Facebook and Twitter is available via RSS.

Even more importantly, RSS has proven to be resilient and durable regardless of what corporate interests want to do with it. Netscape invented the underlying code in the late 90’s, and then took away all documentation and support in 2001 after AOL bought them out. But even that didn’t slow the dissemination. 

And then last year, the biggest player on the Internet took its ball and went home when Google killed its Reader. Despite the fact that Google retired the most popular RSS application on the Net, it did not affect RSS in any appreciable way. All of those feeds are still available and users are still getting their content delivered exactly as they want it. What greater proof is there of the resiliency of RSS?

In fact, what might have seemed like a disaster at first is perhaps the best thing that could happen to the technology. Remember, RSS is a technology and a service; it is not a product. AOL thought they could squash this great idea, but a community of developers took the idea and ran. Then Google thought they could abandon the technology and assumed everyone would gravitate to their social networks instead.

In fact, any number of companies can go out of business, but nobody can stop anybody from publishing and reading RSS feeds. 

However, just because a technology is widely available does not guarantee success. What makes RSS truly powerful is that users still have the control. The beauty of the system is it that no one can force you to be tracked and no one can force you to watch ads. There are no security issues I am aware of and no one ever has to know what feeds you subscribe to. This may be the last area of the Internet that you can still say things like this.

Google Reader was a monopolist product built on an anti-monopolist technology. Now that they’re gone, RSS is once again anyone’s game. You’re going to see a lot more innovation and new stuff for RSS. I never know if its supposed to be a blessing or a curse to live in interesting times. But I have to believe this RSS is entering maybe the most interesting time in its long history.

O sedsed é um software que criei em 2001 (faz tempo…). É um debugger para scripts sed. Ele também alinha/formata os scripts e os converte para HTML (veja um exemplo).

Tenho bastante orgulho deste programa, pois além de ser muito útil para quem cria scripts sed mais complexos, a maneira como ele faz o debug é bem nerd: ele rescreve o script adicionando comandos sed que irão mostrar na tela o conteúdo dos registradores internos a cada passo, com o cuidado de não alterar em nada a lógica original do script. Então é chamado o próprio sed do sistema para executar este novo script, que agora mostra mensagens adicionais na tela.

Apesar de ser um de meus xodós, deixei este programa de lado durante muito tempo. A última versão lançada foi em 2004! Desde então nunca mais toquei nele.

Dez anos depois, aqui estamos em 2014 e resolvi dar uma atenção para o coitado. Minha maior surpresa foi constatar que ele continua funcionando! Uma década de negligência e lá está ele, solitário, trabalhando sem descanso, igual o Wall·E.

Pensando agora, o título deste texto não faz sentido, já que o sedsed nunca morreu.

Eu estou numa força-tarefa para migrar todos os meus códigos para o GitHub, e quando chegou a vez do sedsed acabei fazendo mais do que uma simples migração.

Não era minha intenção, mas ao testá-lo e reler seu código, acabei me apaixonando novamente pelo programa (amor antigo) e finalmente dei a atenção que ele merecia:

• Projeto migrado do Google Code (SVN) para o GitHub.
• Código modernizado para funcionar no Python 3.
• Código mais legível (PEP-8) e robusto (pylint).
• Suíte de testes completa.
• Correção de bugs apontados pelos testes.

Olhando a lista parece pouco, mas foram mais de 50 horas de trabalho para fazer tudo isso.

Essa foi minha primeira experiência de migração de código Python para funcionar na versão nova 3. Foi demorado, mas não foi complexo. Felizmente está tudo muito bem documentado pela comunidade e existe uma ferramenta chamada 2to3 que faz automaticamente alguns ajustes mais simples no código.

No fim das contas ainda consegui manter a compatibilidade com o Python 2.6 e o 2.7 também, então o mesmo código roda em todas as versões mais recentes da linguagem. Massa!

Pretendo continuar desenvolvendo o sedsed, corrigindo bugs e implementando novas funcionalidades. Se você também é programador e quer me ajudar, nos vemos lá no GitHub!

Se você usa o sed para algo mais do que um simples s/isso/aquilo/g, ou quer aprender de vez como funcionam aqueles outros comandos estranhos como N, D, h, g e x, use o sedsed. Ele vai te dar a “visão além do alcance”, mostrando o que acontece por baixo dos panos.

Basta trocar sed por sedsed -d em sua linha de comando e pronto, mágica instantânea:

$ echo foo | sed 'x; g; G; G; s/\n/:/g'
foo:foo:foo

$ echo foo | sedsed -d 'x; g; G; G; s/\n/:/g'
PATT:foo$
HOLD:$
COMM:x
PATT:$
HOLD:foo$
COMM:g
PATT:foo$
HOLD:foo$
COMM:G
PATT:foo\nfoo$
HOLD:foo$
COMM:G
PATT:foo\nfoo\nfoo$
HOLD:foo$
COMM:s/\n/:/g
PATT:foo:foo:foo$
HOLD:foo$
foo:foo:foo

Para usar o sedsed, basta baixar este arquivo Python, torná-lo executável e colocá-lo no seu PATH. Tipo assim:

$ curl -L https://raw.github.com/aureliojargas/sedsed/master/sedsed.py > ~/bin/sedsed
$ chmod +x ~/bin/sedsed

Para referência, estes foram alguns dos artigos que estudei durante o processo de atualização do código para o Python 3:

• http://python3porting.com/preparing.html
• http://python3porting.com/2to3.html
• https://docs.python.org/3/howto/pyporting.html
• https://wiki.python.org/moin/Python2orPython3
• https://docs.python.org/3/whatsnew/3.0.html
• http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Eu sou fã da linguagem SQL. Esta “coroa” já tem 40 anos, mas ainda assim a gente está sempre aprendendo coisas novas. Ou esclarecendo dúvidas antigas.

Uma questão que volta e meia perguntam é sobre performance na execução de comandos CRUD com múltiplas condições: existe diferença entre executar uma operação com múltiplas condições ou executar várias operações com uma única condição?

O bom senso sugere que qualquer operação que dependa de pesquisa deveria se beneficiar da execução de um único comando com múltiplas condições. Pensando no caso de uma operação de DELETE, por exemplo. Deve ser mais vantajoso fazer uma única varredura na tabela testando N condições do que fazer N varreduras, testando uma condição por vez. É a mesma ideia que definir uma lista de livros que se deseja antes de iniciar procura dentro de uma biblioteca.

Pena que ainda existam desenvolvedores que não se preocupam em analisar detalhes tão óbvios e acabam escrevendo códigos ruins. Mas, para os que levam estas questões a sério, como eu, mostro aqui um breve estudo para avaliar performance em alguns cenários.

Definindo cenários

Para responder a questão de performance, é preciso entender que estes números vão depender de uma série de fatores: se as condições são para um ou vários campos, se os campos são indexados ou não, qual o nível de fragmentação dos índices considerados, qual a quantidade de linhas na tabela, qual o tamanho de cada registro, qual a quantidade de registros que são afetados na declaração SQL, etc.

Se ficarmos aqui pensando em todos os fatores que influenciam esta comparação, chegaremos à conclusão que dá para fazer uma tese em mestrado sobre o tema J. Mas a ideia deste artigo é ter uma noção da resposta estudando alguns cenários bem restritos.

Sendo assim, eu resolvi adotar os seguintes critérios para fazer esta pesquisa:

• Todos os testes são feitos sobre uma tabela com layout simples, baseado na tabela Sales.SalesOrderDetails do banco de exemplo AdventureWorks2012 (SQL Server 2012). O script para criação e população desta tabela está disponível neste link;
• A tabela de teste tem tamanho médio, com pouco mais de 121 mil registros e possui apenas dois índices: um clusterizado e outro não-clusterizado;
• Todos os cenários comparam dois tipos de declarações SQL:

1. execução de 1 DELETE  com 10 condições
2. execução de 10 DELETEs com  1 condição

• O critério usado para comparação é o custo total informado no plano de execução de cada consulta;
• Os cenários de avaliação combinam dois parâmetros:

1. Número de campos usados como condição – testes com 1 ou 2 campos
2. Existência de índice no(s) campo(s) de pesquisa – testes com campos sem índice (SI), com índice clusterizado (IC) e não-clusterizado (INC).

• Quando se usa dois parâmetros simultaneamente, a declaração terá sempre o operador OR na cláusula WHERE para facilitar a lógica das declarações.

Combinando estes parâmetros, defini seis cenários de comparação que são descritos na Tabela 1.

Tabela 1: cenários pesquisados

Descrição dos cenários testados

O script com as declarações SQL de cada cenário está disponível para download aqui.

Os resultados

A seguir, apresento os resultados dos 12 testes (06 cenários com 02 declarações), mas antes é importante explicar alguns detalhes.

O custo total das declarações é facilmente identificado no plano de execução quando analisamos as declarações do tipo 2 (declaração única com múltiplos testes). Porém, quando se trata das declarações do tipo 1 (lote com várias declarações cada uma com um único teste), o plano de execução mostra separadamente o custo de cada uma das 10 declarações que compõem o lote de instruções.

Para facilitar a análise dos resultados, eu apresento na Tabela 2 custos de cada sentença, custo total do lote, o número de registros afetados e o plano de execução das declarações dos tipos 1 e 2 para cada cenário definido.

Tabela 2: resultados das declarações em cada cenário.

 Analisando os números

Eu coletei este monte de números na intenção de responder algumas perguntas. Obviamente estas “respostas” precisam ser entendidas dentro de um contexto bem limitado, dada a simplicidade dos testes que mostrei aqui.

Pergunta 1: qual é a vantagem de se executar DELETEs com base em campos indexados? Todo mundo que mexe com bancos de dados sabe que é vantagem fazer pesquisas sobre campos indexados, mas a maioria das pessoas (e eu me incluo neste grupo) não faz ideia do quanto é vantajoso usar índices.

Para simplificar a conversa, vou analisar apenas os resultados dos cenários 1, 2 e 3, que analisam apenas um único campo. Observe a Tabela 3.

Tabela 3: Desempenho conforme o tipo de índice usado

Comparitivo entre consultas conforme tipo de índice

Observe que nos testes simples (declaração tipo 1, com apenas um valor pesquisado), a consulta com índice clusterizado (IC) é significativamente mais rápida do que aquela com índice não-clusterizado (INC): custo 29% menor.

Verificando os planos de execução que nos dois casos (Tabela 2), vemos que as operações executadas são CLUSTERED INDEX DELETE (CID) no Cenário 1 e NON-CLUSTERED INDEX SEEK seguido do CID no Cenário 2. Isso acontece porque um INC é, por assim dizer, um catálogo criado sobre a tabela, enquanto que um IC é uma forma de armazenar os dados de modo que as páginas de dados, por si só, já são um catálogo. Portanto era de se esperar que houvesse esta vantagem.

Quando a análise compara os custos das declarações do tipo 2 (com 10 valores pesquisados), aí a diferença dispara: custo do IC é 89% menor do que o do INC. Esse resultado pode ter sido afetado por diversos fatores, mas neste caso especial provavelmente a diferença acontece por causa dos valores que são pesquisados.

Observe na Tabela 1 que os valores escolhidos para os três campos são sequenciais. Porém, como eu já comentei, um índice clusterizado define a forma com os dados são armazenados na página de dados. Sendo assim, os registros afetados pela consulta baseada no IC provavelmente estão todos gravados na mesma página de dados, reduzindo dramaticamente o custo da operação.

Vejamos agora as consultas com IC e SI. Aqui as diferenças de custo são estratosféricas: o custo IC É 97% menor nas consultas tipo 1, enquanto que nas consultas tipo 2 esta diferença é um pouco maior, chegando a 98%.

Olhando novamente os planos de execução, vemos que o otimizador de consultas faz um CLUSTERED INDEX SCAN seguido do CID nas consultas do Cenário 3. Ou seja, apesar das duas declarações serem executadas sobre o índice clusterizado da tabela, o fato de haver um CLUSTERED INDEX SCAN deixou estas consultas quase 100 vezes mais lentas do que as que se baseavam diretamente no IC.

Pergunta 2: é vantagem fazer uma única declaração pesquisando por vários valores? Novamente uma resposta fácil J. A Tabela 4 traz os resultados e vemos que as declarações do tipo 2 (uma declaração com N condições) têm custo menor em todos os 6 cenários pesquisados.

Tabela 4: Desempenho com base no tipo de declaração SQL

Comparativo entre consultas com vários parâmetros de pesquisa

Note que no Cenário 1 (consultas com IC) que o custo para se executar 1 consulta com 10 condições é 90% menor (ou seja, 1/10 do total) do que executar 10 consultas com 1 condição. Portanto o custo é praticamente o mesmo se a consulta tiver uma ou dez condições. Veja Tabela 2 os custos de cada declaração executada neste cenário.

Pergunta 3: é vantagem fazer uma declaração pesquisando dois campos ao mesmo tempo? Aqui a resposta é mais complicada. E em primeiro lugar, é preciso entender como combinar os cenários para comparar os resultados.

Olhando a Tabela 1, você vai notar que os cenários foram definidos de tal maneira que representassem uma composição dos cenários anteriores. Por exemplo, o Cenário 4 (testes no campos SalesOrderID e ProductID) é uma combinação dos cenários 1 e 2. Isso quer dizer que a execução das consultas do cenário 4 causa o mesmo efeito na tabela que a execução conjunta das consultas dos cenários 1 e 2.

Graças a esta estrutura dos testes, podemos comparar:

• Cenário 4 com os resultados acumulados dos cenários 1 e 2
• Cenário 5 com os resultados acumulados dos cenários 1 e 3
• Cenário 6 com os resultados acumulados dos cenários 2 e 3

Considerando esta lógica, a Tabela 5 mostra as proporções entre as combinações de cenários.

Tabela 5: comparativo do custo acumulado dos cenários equivalentes

comparativo entre consultas com 2 campos de pesquisa

Lamentavelmente a Tabela 3 não mostra resultado muito expressivos. As proporções agora são muito parecidas em 4 das 6 comparações. Aparentemente não há vantagem significativa de se juntar duas declarações pesquisando um campo para se escrever uma única declaração pesquisando dois campos ao mesmo tempo.

Aparecem diferenças importantes apenas nas declarações do tipo 2 nos cenários 5 e 6 (20% e 27%). Mas isso acontece por conta da natureza das condições destas consultas, como descrevo a seguir.

Ao combinar pesquisas em dois campos, o otimizador de consultas tomou decisões diferentes conforme a indexação dos campos escolhidos. Nas declarações do tipo 2 no cenário 4, ele usou um CLUSTERED INDEX SEEK e um NON-CLUSTERED INDEX SEEK, que são, para todos os efeitos práticos, os mesmos operadores realizados nos cenários 1 e 2 (o leitor mais observador perceberá que estou assumindo aqui que os operadores CLUSTERED INDEX DELETE e CLUSTERED INDEX SEEK pesquisam dados de modo semelhante e tem um custo de execução praticamente idênticos).

Porém a coisa muda nos cenários 5 e 6. Ao se deparar com dois campos que exigem operações distintas, o otimizador de consultas decide executar um CLUSTERED INDEX SCAN pros dois campos testados (veja isso nos planos de execução das consultas do tipo 2 nos cenários 5 e 6). Por isso a consulta combinada ficou mais lenta do que as consultas individuais.

Resumindo os resultados da pergunta 3, concluímos que não há uma vantagem significativa de se combinar numa única declaração SQL condições sobre mais de um campo. Os resultados são praticamente equivalentes quando os campos são indexados, mas a performance caiu significativamente quando um dos campos pesquisados não tiver índices.

Conclusão

Apesar de este estudo ser bem simples e sem nenhuma pretensão de dar respostas definitivas sobre o tema, eu entendo que estes números endossam algumas noções que adotamos no dia-a-dia.

Estas noções são:

1. É extremamente vantajoso executar DELETEs fazendo a pesquisa pelo índice clusterizado da tabela; se não for possível usar o índice clusterizado, é interessante indexar (INC) o campo da pesquisa;
2. É vantajoso organizar todos os valores pesquisados no mínimo de operações possível. Nos testes aqui realizados a declaração única teve desempenho melhor em todos os cenários testados;
3. Não há vantagem em se incluir na mesma declaração SQL pesquisas sobre diferentes campo. Além disso foi observada uma desvantagem clara quando um dos campos testados não é indexado. Portanto esta prática é desaconselhada.

Como eu disse anteriormente, os resultados mostrados aqui são aplicáveis apenas a cenários muito parecidos com os que foram testados aqui. Para outras situações, é recomendável que o leitor faça seus próprios testes usando o método aqui descrito (e eu recomendo fortemente que o faça J).

Até a próxima!

Noite passada sonhei que estava no Chile, na casa de um amigo. O sonho foi mais ou menos assim:

Durante o dia passeei pelas ruas e conversei com muitas pessoas.

Já de noite, na casa de meu amigo, estávamos reunidos na sala com uma galera, papeando.

Só nesse momento eu me dei conta que todo mundo estava falando em português comigo, o dia todo.

Como assim??!?

Perguntei para o chileno que estava ao meu lado e ele me disse que todos no Chile aprendiam português na escola, desde criança. Os que estavam ao redor confirmaram.

Acreditei, ué. Afinal, ali estavam eles falando comigo em português.

O sonho continuou por mais um tempo, com mais bate-papos.

Só depois que acordei e lembrei do sonho, me dei conta que meu cérebro me enganou!

Na verdade, o cérebro não conseguiu criar diálogos em espanhol no sonho (óbvio, porque não domino a língua) e improvisou com o português mesmo. Quando percebi essa falha, na maior cara de pau ele me mandou esse caô de “aprender português na escola”. E o mané aqui acreditou.

Estou indignado, não se pode confiar no próprio cérebro! :)

Ontem falamos sobre o Heartbleed, que está sendo considerada uma das piores falhas de segurança já descobertas na internet, e que circula por aí há mais de dois anos (saiba mais sobre ela aqui).

Apesar de o bug existir há um bom tempo, felizmente já foi lançada uma atualização que ajuda muitos sites a se protegerem contra a falha. Não é possível saber completamente até que pontos eles estão protegidos ou já consertaram o erro em seus servidores. No entanto, no mundo inteiro está sendo feito um trabalho de levantar quais grandes sites valeria a pena, por precaução trocar a senha, ou os que você teoricamente não precisa se preocupar. Veja quais são:

Vale mudar:

Amazon Web Services, Dropbox, Facebook, Google, GoDaddy, Instagram, Pinterest, Tumblr, Twitter, LastPass, OKCupid, SoundCloud, Wunderlist.

Não precisa mudar:

Amazon, AOL, Apple, eBay, Evernote, Hotmail/Outlook, LinkedIn, Microsoft, Netflix, PayPal, Target.

Além disso, vale mencionar a ferramenta da LastPass, uma empresa de segurança de senhas, que analisa vários sites e diz se eles estão ou não seguros. Teste aqui.

The post Quais são os sites que você precisa mudar sua senha agora? appeared first on Startupi.

No blog brasileiro para webmasters, o Google publicou um artigo que pode ser muito útil para detectar uma possível invasão em nosso site.

São conselhos para detectar ações de hackers e solucionar problemas de segurança, uma lista que qualquer webmaster pode seguir de forma simples entre suas propriedades:

- Verificar se há endereços URL suspeitos ou diretórios não reconhecidos em nosso site. Além de fazê-lo acessando via ftp podemos estabelecer um alerta em Google do tipo [site: miweb.com ( viagra | download)] recebendo, assim, um email cada vez que forem encontradas palavras chaves suspeitas (comuns nas ações de hackers) dentro de nosso site.

- Buscar por consultas artificiais nas ferramentas de Google Webmaster. Podemos verificar quais são as consultas que levam visitas ao nosso site e detectar atividade estranha na mesma, tal como mostra a imagem abaixo.

- Reenviar as notificações de Google para Webmasters a nosso email. Muitas contas de Google para webmasters não estão configuradas para que se receba um email cada vez que seja detectado um problema em algum site ali configurado. É algo simples que pode ser muito útil, já que o Google rastreia cada site em busca de problemas de segurança derivados de arquivos maliciosos. Podemos fazer isso seguindo estas instruções.

Veja também:

Google Webmasters nos avisa se foi realizada alguma ação manual de spam em nosso site

Google já permite adicionar fotos 360 graus no nosso site

Google Plus: já podemos incluir seus textos em nosso site

Dear MySQL,

Thank you for introducing me to SQL. It must have been 1998 when we first met I and fell in love with the simplicity of SQL immediately. Before that I’ve been using C structs all the time; I had to do my joins programmatically and also create and maintain my indexes manually. It was even hard to combine several search conditions via and and or. But then there was the shiny new world of SQL you were showing me…

Everything was easily. Just write a where clause, no matter how complex, you found the right rows. Joins were equally easy to write and you took all the effort to combine the data from several tables as I needed them. I also remember how easy it became to manage the schema. Instead of writing a program to copy my data from one C struct to another, I just say alter table now—in the meanwhile it even works online in many cases! I didn’t take long until I used SQL for stuff I wouldn’t have thought a database could do for me. So I was quickly embracing group by and co.

But I haven’t spent a lot of time with you lately. It’s not because I was too busy. I’m still practicing what you have shown me! And I’ve moved on. Now I’m using common table expressions to organize complex queries and I use window functions to calculate running totals or just do a ranking. I’m also using joins more efficiently because I know about hash and sort/merge joins. A while ago I was wondering why you didn’t tell me about these things. But then I realized that you don’t know them.

I know it was not always nice what I said about you recently. But now that Oracle announced your retirement to focus on Oracle NoSQL, I realized how right this comment on reddit was. Sure you are neither the most advanced nor the most widely deployed open source SQL database, but you introduced millions of people to SQL. There should be no tears when some of them move away because they want to see what’s next. Isn’t that the greatest compliment a teacher can get? You can be proud of what you have accomplished.

Thank you!

Markus Winand

April 1, 2014

ps.: Even when fooling around, I can’t resist to inform my fellow readers. Besides the claim that Oracle retires MySQL, everything is true. Initially I thought Oracle NoSQL is an Aprils fool’s joke but it isn’t.

No último final de semana, o Projeto ‘Sacando Para o Futuro’ deu início às suas atividades, que têm como objetivo a massificação da modalidade através de sua prática em escolas municipais. Como parte do programa, professores que ministrarão as aulas a cerca de 1440 alunos de dez instituições da rede de ensino do Rio de Janeiro, receberam um curso de capacitação no Madureira Esporte Clube.

Na parte da manhã, os professores tiveram aulas teóricas sobre os principais fundamentos do Tênis de mesa, como forehand, backhand, recepção, saque, posição fundamental, efeitos básicos, e outros movimentos. À tarde, tudo o que foi visto na sala de aula foi colocado em prática, fazendo com que os professores executassem os movimentos aprendidos.

O curso aconteceu no Madureira Esporte Clube, que disponibilizou alunos pertencentes ao quadro de sua escolinha para que os professores pudessem simular as aulas que vão ser dadas aos estudantes das escolas contempladas.

Para que continuem se capacitando, todos receberam uma apostila e um DVD com diversos vídeos demonstrativos.

A Confederação Brasileira de Tênis de Mesa conta com recursos da Lei Agnelo/Piva – Lei de Incentivo Fiscal e Governo Federal – Ministério do Esporte.

Ao contrário do que muitos acham, trabalho remoto (ou até um projeto freelancer) não é algo fácil. Eu sei que é o sonho de todo mundo ficar em casa, organizar o seu próprio horário para ir ao parque (cinema, praia, sítio, bar, prostíbulo etc etc etc) enquanto todo mundo se mata em um escritório.

Para ter esse privilégio, você não precisa ser só bom no que faz, você precisa ser responsável e ter disciplinas extras que vão além das suas responsabilidades técnicas.

Montar uma empresa remota – como o Tableless está se tornando – é algo realmente desafiador. Você precisa encontrar profissionais que tem um senso “social” muito apurado. Que não pensam apenas na sua tarefa, mas também na tarefa de todos os outros integrantes do projeto, inclusive, o lado do cliente, que geralmente está preocupado com o andamento do projeto.

Estas são algumas dicas básicas para você não ser um fiasco quando quiser se aventurar em trabalhar remotamente, aqui no Tableless ou em qualquer outra empresa que tenha essa possibilidade:

1. Dê status

A equipe não está o tempo todo do seu lado e é muito difícil todo mundo trabalhar no mesmo horário. Trabalhar em uma equipe remota não quer dizer que todo mundo precisa estar ali no chat o dia inteiro. Claro, é bem diferente se você trabalha em uma empresa convencional e vai fazer um dia de trabalho remoto. Nesse caso é muito aconselhável que você trabalhe no horário normal, como se você tivesse ido à empresa normalmente.

Em uma equipe não presencial, o status é o que faz as coisas não saírem dos eixos. Você precisa dar e receber o status do projeto o tempo inteiro. Seja por email, por sms, por código morse ou sinal de fumaça. Você precisa dar notícias e essas notícias precisam ser frequentes.

“Mas Diego, não basta a equipe olhar os commits e pronto?”

Não, não é só checar os commits e a listagem de issues concluídas. A equipe e a pessoa que interage e atende o cliente precisa saber de TUDO. Embora seu commit seja incrivelmente detalhado, isso não basta. Você precisa conversar com a equipe e dizer exatamente qual o status da sua parte no projeto. A lista de tarefas feitas e a lista de commits serão o apoio, mas o que vai mesmo deixá-los seguros e informados são as suas palavras.

Se você não gosta de dar satisfações, esqueça, você não serve para fazer trabalho remoto. Se você não gosta de mandar email dizendo detalhadamente em que pé está seu trabalho, desista, isso não é para você.

Geralmente o status pode ser dado 2 vezes ao dia, pela manhã e na parte da tarde. Se você fizer uma parada longa no decorrer do dia, é bom também manter a equipe informada. Mas geralmente um report no meio da manhã e outro no final da tarde é essencial para que o gerente do projeto possa informar ao cliente como tudo está andando.

2. Nunca omita informações

Se você precisa dar notícias o tempo todo, você não pode, em hipótese alguma, omitir ou esquecer informações. Quando alguém perguntar a você qual o status da tarefa, não se preocupe se ela está incompleta, diga exatamente o status atual. Não tente agradar ou dar aquela enrolada, isso não funciona.

Se falta fazer um pedaço da funcionalidade, diga. Se você se esqueceu de fazer alguma coisa, diga. Se você bebeu até cair na noite anterior e não vai conseguir trabalhar, diga. Mas nunca, de forma nenhuma, omita qualquer tipo de informação.

Digo isso porque toda a equipe e também quem está lidando direto com o cliente necessita de informações exatas. Se você simplesmente omitir informações, as decisões emergenciais, que são as decisões mais importantes, serão totalmente equivocadas.

Essas informações serão usadas também indicar um status mais adequado para o cliente. Aqui no Tableless eu sou bem sincero. Prefiro perder o cliente falando a verdade do que tentar enrolá-lo. Dá mais trabalho enrolar do que perder o projeto. Prefiro ficar são para finalizar os outros projetos que restam, do que aflito e maluco tentando inventar uma desculpa para o cliente.

Dinheiro nenhum paga uma dor de cabeça desse tipo.

3. Mantenha o repositório do projeto sempre atualizado

NUNCA, NUNCA, NUNCA saia da frente do computador sem dar um push antes. Vai pra praia curtir? Atualize seu projeto e envie seus commits para o repositório. Vai pro parque correr com seu cachorro? Atualize o repositório.

Atrasar um projeto por que você não atualizou o repositório é coisa de júnior. Ainda mais quando as suas tarefas afetam as tarefas do time.

Esse é um erro que pode causar uma dor de cabeça terrível para equipe inteira.

Só para deixar claro: não estou dizendo que você tem que subir tarefas incompletas. Você só sobe tarefas totalmente completas e revisadas para o repositório. Mesmo assim, se você estiver trabalhando em um branch separado dedicado para uma determinada tarefa, suba tudo o que puder e avise o time que determinado branch está com uma tarefa incompleta, mas sempre deixe esse branch atualizado. Alguém, eventualmente, pode continuar seu projeto de onde você parou. Se isso acontecer e você não tiver atualizado o branch, alguém vai ter problemas.

4. Uma notícia ruim é melhor do que notícia nenhuma

Ahhh, notícias ruins. Notícias ruins são normais em projetos de internet. Contudo, não ter notícia nenhuma é pior. O cliente fica desesperado, estressado e começa a duvidar da sua capacidade. Problemas acontecem. Estamos falando sobre desenvolvimento de software, ou seja, problemas invariavelmente acontecerão.

O problema é a sua posição perante este cenário. Ninguém gosta de receber notícias ruins, mas todo mundo gosta de receber notícias sobre seu projeto. É importante para que o cliente consiga programar seu cronograma. Ele pode ter engatilhado um grande lançamento, campanha de marketing, apresentação para executivos ou qualquer outra coisa importante. Quando você não dá a notícia ruim (ou qualquer outra notícia), você prejudica uma cadeia inteira de pessoas e processos.

Lembre-se que O problema não é dar a notícia ruim, o problema é não dar notícia nenhuma. Sempre dê notícias sobre o projeto para o cliente, por mais insignificante que essa notícia seja.

5. Não pegue o projeto se você acha que não vai entregá-lo

Talvez você esteja muito atarefado. Talvez você esteja de saco cheio e queira tirar férias. Talvez você queira tanto dinheiro que se envolve em muitos projetos e não entrega nenhum. Talvez você tenha problemas de saúde… Não importa o motivo, mas se você sabe que não vai conseguir entregar o projeto, seja por incompetência ou por qualquer outro motivo, não se comprometa.

É melhor perder um cliente que talvez possa te contactar novamente mais tarde, do que você se envolver, estragar o projeto do cliente e depois largá-lo com um problema gigante nas mãos.

Nesse cenário, o melhor é ser honesto. Diga que você não tem tempo porque está com muitos projetos, porque pretende viajar ou por causa de qualquer outro motivo. Nunca dispense o cliente sem uma desculpa verdadeira.

O cliente não vai ficar bravo com você. Nesse momento você não está comprometido com nada. Você pode dizer não tranquilamente nesse momento.

6. Seja responsável

Eu sinto que não deveria conversar sobre nenhum destes pontos com ninguém, pelo simples motivo de que isso é questão de ter ou não responsabilidade. Se você tiver responsabilidade e claro, comprometimento, você vai se dar bem. O problema é que muitos devs simplesmente pisam na bola e para mim isso não tem outro nome: irresponsabilidade.

Você tem um trabalho para entregar e existem pessoas que contam contigo. Você tem um cliente, que te paga para fazer um determinado projeto, ele “manda” na bagaça toda. É muita falta de responsabilidade, de educação e comprometimento você falhar ao tentar deixá-lo a par dos acontecimentos do seu próprio projeto.

Lembre-se de todas essas disciplinas e com certeza você vai se destacar da média.

O post 6 dicas para se dar bem em freelas e trabalhos remotos foi originalmente publicado em Tableless.

The PostgreSQL Global Development Group has released an update to all supported version of the database system, including versions 9.3.4, 9.2.8, 9.1.13, 9.0.17, and 8.4.21. This minor release fixes a data corruption issue with replication and crash recovery in version 9.3, as well as several other minor issues in all versions. All users of version 9.3 are urged to update their installations at the next possible downtime. Users of older versions should update at their convenience.

The data corruption issue in PostgreSQL 9.3 affects binary replication standbys, servers being recovered from point-in-time-recovery backup, and standalone servers which recover from a system crash. The bug causes unrecoverable index corruption during recovery due to incorrect replay of row locking operations. This can then cause query results to be inconsistent depending on whether or not an index is used, and eventually lead to primary key violations and similar issues. For this reason, users are encouraged to replace each of their standby databases with a new base backup after applying the update.

Other PostgreSQL 9.3-only fixes in this update include:

• Make sure that statistics files for dropped databases get deleted
• Allow materialized views to be referenced in UPDATE and DELETE queries
• Add read-only data_checksum parameter
• Prevent erroneous operator push-down in postgres_fdw

This release resolves some other issues in all versions of PostgreSQL, including:

• Fix timing consistency issue with NOTIFY
• Allow regular expression execution to be cancelled
• Improve performance of index checks for newly added rows
• Prevent premature walsender disconnection
• Prevent memory errors on newer Windows versions
• Update timezone files

Additional changes and details of some of the above issues can be found in the Release Notes. Two of the issues which affect version 9.3 have additional information on the 9.3.4 Update Wiki Page.

Users of version 8.4 should note that it will reach End-of-Life (EOL) three months from now, per our Versioning Policy. This means that this is likely to be the next-to-last update for version 8.4, and users should be planning to upgrade to a newer version of PostgreSQL.

As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Users who have skipped multiple update releases may need to perform additional post-update steps; see the Release Notes for details.

Links: * Download * Release Notes * 9.3.4 Update Wiki Page

Hoje temos o prazer em publicar mais um estudo de caso sobre a utilização da Nuvem da Amazon Web Services. Se você também quer contar sua história para nós, entre em contato conosco!

O caso é da SóNotícias, o primeiro jornal virtual do interior de Mato Grosso divulgando as principais notícias da região há 13 anos.

Jorge Maia, IT Manager do SóNotícias, nos conta abaixo um pouco mais sobre a empresa e como utilizam a nuvem da Amazon Web Services.

“O SóNotícias é o primeiro jornal do interior do Mato Grosso e está há 13 anos no mercado divulgando, em tempo real, as principais informações estaduais e publica simultaneamente os sites Social News e Agronotícias.

O nosso grande desafio era atender a toda a nossa demanda de clientes, o que não conseguíamos com o serviço de infraestrutura anterior. Este problema causava lentidão e indisponibilidade de nossos serviços gerando uma insatisfação de nossos usuários e contratantes.

Com a ajuda de um parceiro da Amazon Web Services, a Brlink( que idealizou todo o projeto de implantação, a migração do ambiente com as aplicações e o gerenciamento de nossa aplicação) no período inacreditável de 2 semanas, decidimos incorporar a AWS como o nosso principal fornecedor de infraestrutura tecnológica.

Um ponto crucial que nos levou até a AWS foi a excelente disponibilidade dos serviços da AWS. O segundo ponto foi a capacidade computacional flexível, podendo se ajustar de acordo com a necessidade de nossos portais atendendo aos picos imprevistos de usuários e o melhor, pagando somente por aquilo que usamos.

Atualmente utilizamos o Amazon Elastic Compute Cloud (Amazon EC2);  o Amazon Elastic Block Store (Amazon EBS); o Amazon Route53 como serviço de DNS para todos os domínios da empresa e o Amazon Elastic Load Balance (Amazon ELB) é encarregado da distribuição de carga de nossos sites.

Abaixo está o diagrama de nossa solução utilizando os serviços da Amazon Web Services:

Para metrificar os nossos benefícios obtidos com a Amazon Web Services, analisamos a quantidade de acessos simultâneos suportados pelos portais e o tempo de disponibilidade dos sites.

Como os portais são acessados diariamente por centenas de usuários, com a alta disponibilidade de nossa aplicação, aumentamos em 80% a satisfação de nossos clientes agregando mais valor ao nosso portal. Também houve um aumento de 150% na quantidade de usuários simultâneos acessando nossos portais e um aumento de 45% em nossa disponibilidade. Sem contar que o nosso custos com infraestrutura diminuiu drasticamente devido ao modelo on demand de pagamento da AWS.

Somente quando conhecemos melhor os recursos da AWS é que percebemos o verdadeiro valor que a empresa tem em relação aos modelos tradicionais de datacenter. A Amazon Web Services trouxe uma série de benefícios para os nossos clientes, melhorando a nossa relação, possibilitando uma melhor navegação e pagando somente por aquilo que necessitamos”.

E este foi mais um estudo de caso de uso da Nuvem da AWS!

Foi no fim de 2012 as operadoras brasileiras colocaram em prática um plano no mínimo controverso: em prol de defender o consumo de smartphones e tablets vendidos em território nacional e banir de uma só vez aparelhos xing-lings baratos que congestionam as redes, o Sistema Integrado de Gestão de Aparelhos (resumindo, SIGA) entraria em ação para num rimiro momento impedir que novos aparelhos não-homologados pela Anatel sejam ativados e num cenário posterior, celulares que já funcionam seriam até mesmo desativados.

O SIGA entrou em funcionamento nesta segunda-feira, entretanto donos de aparelhos  comprados no exterior não precisam arrancar os cabelos: nessa primeira fase a Anatel apenas catalogará quantos aparelhos piratas estão ativos, para só então decidir o que fazer.

Oficialmente a desculpa da Anatel e das operadoras é que “os aparelhos ilegais de baixa qualidade (em sua maioria chineses) poderiam em teoria representar risco à saúde dos usuários” além de causar ruídos de dados e voz na rede, mas a verdade é que o governo brasileiro quer tanto acabar com o comércio ilegal de celulares quanto evitar a evasão de divisas, no caso de usuários que trocam de smartphone todo o ano mas não o adquirem no Brasil. O projeto teve um custo de R$ 10 milhões e foi bancado pelas quatro principais operadoras do país: Vivo, Claro, TIM e Oi.

Como funciona: na primeira fase, iniciada hoje e que vai até setembro a Anatel vai apenas coletar os números IMEI de todos os dispositivos ativados e comparar ao seu banco de dados, para descobrir quantos e onde estão os aparelhos não-homologados. A Agência reforça que não coleta nenhum outro dado que não seja o número, mas mantenhamos o foco. Ela não divulga o método que utiliza para identificar os xing-lings, dizendo apenas que possui uma relação de todos os IMEIs utilizados no Brasil.

A partir de setembro aparelhos em funcionamento ainda não serão afetados, mas celulares que possuam IMEIs que não estejam na lista da Anatel não poderão ser ativados. A Fase 2, que ainda não foi confirmada e pode não vir a ocorrer (mas é bom não contar com isso) é onde as coisas complicam: aparelhos não-homologados já em funcionamento seriam desativados, não podendo mais realizar ligações e se conectar à rede de dados das operadoras. O superintendente da Anatel Roberto Pinto Martins diz que a agência “provavelmente” terá “uma campanha (para orientar usuários), mensagens com avisos” pois nas palavras dele, “ninguém vai ter o aparelho desabilitado de um dia para o outro”.

A preocupação aqui é de donos de aparelhos legítimos que não são homologados no Brasil. Toda a linha HTC mais recente por exemplo sofre disso, já que a empresa não mais possui representação no Brasil. Modelos de iPhones 5s e 5c comercializados nos Estados Unidos sofrem do mesmo problema: nossos modelos são os mesmos comercializados em países como Chile, Portugal, Reino Unido, França, Alemanha, Espanha, Itália e etc, mas os modelos norte-americanos sempre tiveram uma boa relação de custo/benefício para quem viaja muito para os States. A Anatel não confirma se essa fase será de fato posta em prática pois a tendência é como novos não poderão mais ser ativados eles sumam conforme caiam em desuso.

O mais curioso nessa situação é: como fica a situação dos turistas? A Anatel ao menos foi esperta, pondo a fase onde a aparelhos novos não serão mais reconhecidos após o fim da Copa do Mundo, mas recebemos milhões deles todos os anos. Eles serão obrigados a adquirir um celular barato só para falar no Brasil? E considerando as Olimpíadas de 2016, esse é um movimento inteligente de se fazer? Além disso a regra que permite comprar um aparelho no exterior sem ter a necessidade de declará-lo ao voltar vai pra cucuia, pois dependendo da situação ele virará um tijolo high tech tão logo adentre no Brasil.

O SindiTeleBrasil, o sindicato das operadoras de telefonia já havia declarado que o usuário deveria ser encaminhado para atendimento diferenciado da operadora em caso de ativação de um aparelho que não seja homologado no país. Entretanto a Anatel recomendou recentemente que o usuário deve primeiro checar se o aparelho é registrado no país antes de comprá-lo, o que dá a entender que as operadoras não vão aliviar para ninguém. Dura lex sed lex, simples assim.

Aqui você pode checar a lista atual de aparelhos homologados no Brasil. Portanto fica a dica: se você tem um aparelho comprado lá fora não precisa se preocupar por enquanto, mas a partir de setembro é bom abrir o olho quanto realizar suas compras de gadgets lá fora.

UPDATE: a Cristina De Luca do IDGNow! entrevistou por telefone o conselheiro da Anatel Marcelo Bechara, que esclareceu alguns pontos acerca dessa polêmica toda. Ele revelou que a resolução publicada no fim de 2013 foi interpretada de forma errônea, e na verdade o SIGA está rodando em fase de testes desde janeiro, e por enquanto nenhum dono de aparelhos não-homologados será afetado. Quando a fase de bloqueio estiver para entrar em vigor a Anatel iniciará uma campanha de conscientização, mas não entrou em detalhes até porque a agência ainda não definiu o que pode e o que não pode. Para tranquilizar a população, de acordo com o artigo 67 da Resolução 242, de 2000:

Ou seja: aparelhos comprados no exterior em países que mantenham boas relações comerciais com o Brasil e não sejam xing-lings tem tudo para continuar funcionando. O alvo da Anatel é exclusivamente os aparelhos piratas, embora até a resolução final muita água pode rolar, e particularmente não confio nada nas operadoras brasileiras. Vale a pena ler a entrevista completa.

Fonte: G1.

The post Sistema que bloqueia celulares não-homologados no Brasil já está em funcionamento [UPDATE] appeared first on Meio Bit.

Depois de criar um artigo no devmedia de como criar um slideshow do zero em Jquery sem plugins, recebi vários pedidos para fazer o mesmo com javascript, também pude notar que muitas pessoas estavam com dificuldade em colocar link nas imagens e os botões de anterior/próximo. Veremos neste artigo como criar um slideshow do zero apenas com javascript e uma dose elegante de CSS3, com controladores, legendas e links nas imagens.

Abaixo o resultado final do nosso slide:

Resultado final do nosso slide

Estrutura HTML

Nossa estrutura html é bem simples, veja na listagem 1:

Listagem 1 – Estrutura html do slideshow

<figure>
   <span class="trs next"></span>
   <span class="trs prev"></span>

   <div id="slider">
      <a href="#" class="trs"><img src="imagem1.jpg" alt="Legenda da imagem 1" /></a>
      <a href="#" class="trs"><img src="imagem2.jpg" alt="Legenda da imagem 2" /></a>
   </div>

   <figcaption></figcaption>
</figure>

Onde:

<figure></figure> –> Figura que será responsável de gerenciar todos os elementos do nosso slide

<span class=”next trs”>, <span class=”prev trs”> –> Serão os controladores do nosso slide

<div id=”slide”> –> div que abriga as imagens do nosso slide, facilitará nosso controle no javascript

<figcaption> –> Legenda do slide, será baseada pelo o atributo “alt” das imagens

Let’s go! vamos agora estilizar nosso slide.

Estilo CSS

Abaixo na listagem 2, o nosso estilo css, não explicarei a fundo nossa estilização, irei focar apenas nos principais pontos

Listagem 2 - Estilo css

<style>
* {margin: 0; padding: 0;}
body {background: #000}
a,img {border: none;}
.trs {-webkit-transition:all ease-out 0.5s;
    -moz-transition:all ease-out 0.5s;
    -o-transition:all ease-out 0.5s;
    -ms-transition:all ease-out 0.5s;
    transition:all ease-out 0.5s;}	
#slider {position: relative; z-index: 1;}
#slider a { position: absolute; top: 0; left: 0; opacity: 0;filter:alpha(opacity=0);}
.ativo {opacity: 1!important; filter:alpha(opacity=100)!important;}

/*controladores*/
span {background: #0190EE; cursor: pointer; opacity: 0;filter:alpha(opacity=0); position: absolute; bottom: 40%; width: 43px; height: 43px; z-index: 5;}
.next {right: 10px;}
.next:before,.next:after {left: 21px;}
.next:before {
    -webkit-transform: rotate(-42deg);
    top: 5px;
}
.next:after {
    -webkit-transform: rotate(-132deg);
    top: 19px;
}
.next:before,.next:after,.prev:before,.prev:after {content: "";
    height: 20px;
    background: #fff;
    width: 1px;
    position: absolute;
}
.prev {left: 10px;}
.prev:before,.prev:after {left: 18px;}
.prev:before {
    -webkit-transform: rotate(42deg);
    top: 5px;
}
.prev:after {
    -webkit-transform: rotate(132deg);
    top: 19px;
}

figure:hover span {opacity: 0.76;filter:alpha(opacity=76);}
    figure {
    max-width: 937px;
    height: 354px;
    position: relative;
    overflow: hidden;
    margin: 50px auto;
}

figcaption {padding-left: 20px;color: #fff; font-family: "Kaushan Script","Lato","arial"; font-size: 22px; background: rgba(1, 144, 238, 0.76); width: 100%; position: absolute; bottom: 0; left: 0; line-height: 55px; height: 55px; z-index: 5}
</style>

Onde:
.trs –> class que define a transição das imagens do nosso slide e dos nossos controladores
.ativo –> class que define qual imagem está ativa
figure:hover span –> faz com que mostre nossos controladores ao passar o mouse no nosso slide

Parece que tudo está indo bem, vamos começar a brincar agora com nosso slider, gogo ninja lvl2

Javascript

Veremos cada passo do código javascript bem detalhado para que não haja dúvida alguma ao termino do post.

Primeiramente vamos criar uma função setaImagem e colocar para que ela rode quando a janela (window) for carregada:

Listagem 3 – Criação da função “setaImagem”

<script type="text/javascript">
   function setaImagem(){
   }
   window.addEventListener("load",setaImagem,false);
</script>

onde:
window.addEventListener(“load”,setaImagem,false); –> faz com que a função “setaImagem” seja executada quando a janela for carregada

Agora iremos criar nossa variável “settings” que receberá alguns objetos e funções anonimas.

Listagem 4 - Criando nossa varável “settings”, já com duas funções anonimas dentro, que são “legenda” e “primeiraImg”

 var settings = {
  primeiraImg: function(){
    elemento = document.querySelector("#slider a:first-child");
    elemento.classList.add("ativo");
    this.legenda(elemento);
  },
  legenda: function(obj){
    var legenda = obj.querySelector("img").getAttribute("alt");
    document.querySelector("figcaption").innerHTML = legenda;
  }
 }

Onde:

var settings = {} –> define uma variavel “settings” que conterá as configurações do nosso slide

primeiraImg: function(){…} –> Função que seta a imagem que aparecerá inicialmente no nosso slide

elemento = document.querySelector(“#slider a:first-child”); –> captura a primeira tag “<a>” da “div#slider” e coloca numa variavel elemento.

elemento.classList.add(“ativo”); –> coloca a classe ativo na tag capturada (elemento.classList.add(“ativo”)).

this.legenda(elemento); –> chama a função anonima “legenda” e passa como parâmetro a variável elemento que acabamos de criar

legenda:function(obj){…} –> função anonima que coloca captura o atributo “alt” da tag “<img>” que tem como pai, o parâmetro determinado como “obj” e coloca como legenda do slideshow

var legenda = obj.querySelector(“img”).getAttribute(“alt”); –> captura o atributo “alt” da tag “<img>” que tem como pai, o parâmetro determinado como “obj” (que neste caso é a primeira tag “<a>”) e coloca numa variável legenda

document.querySelector(“figcaption”).innerHTML = legenda; –> coloca o html, que está dentro do atributo alt da variavel legenda, dentro da tag “<figcaption>” que neste caso é a nossa legenda do slideshow.

Até agora tudo certo, mas note que se você executar nosso documento, nada acontece, isto porque não chamamos nossa função de setar a imagem.

Listagem 5 - chamando nossa variavel settings e suas respectivas funções anonimas

//chama o slide
settings.primeiraImg();

//chama a legenda
settings.legenda(elemento);

//chama o slide à um determinado tempo
var intervalo = setInterval(settings.slide,4000);

Primeiro chamamos nossa função de setar a imagem no slideshow, depois setamos sua legenda e por fim, acionamos um temporizador que roda nosso slide a cada 4 segundos.

Vamos agora adicionar mais uma função à configuração do nosso slide, seu nome será “slide”. Esta função servirá para controlar as transições automáticas do nosso slideshow.

obs: Adicione a linha de código abaixo, dentro da variável settings

Listagem 6 - Criação da função slide

	slide: function(){
    elemento = document.querySelector(".ativo");
    if(elemento.nextElementSibling){
        elemento.nextElementSibling.classList.add("ativo");
        settings.legenda(elemento.nextElementSibling);
        elemento.classList.remove("ativo");
    }else{
        elemento.classList.remove("ativo");
        settings.primeiraImg();
    }
},

Primeiro criamos nossa função slide, dentro dela, capturamos a tag que contém a class “ativo” e colocamos numa variável “elemento”, logo em seguida fazemos uma verificação, se ouver uma tag após a tag “ativo” colocamos nesta outra tag a classe ativo, adicionamos a legenda dela no nosso slide e retiramos a classe ativo da nossa imagem que está ativa. Se não ouver nenhuma outra tag, tiramos a classe “ativo” da imagem que está ativa, e chamamos a função “primeiraImg” que servirá para setar a primeira imagem no nosso slide.

show de bola! nosso slide está rodando, mas note que nossos controladores ainda não funcionam, vamos agora fazer eles funcionarem.

Primeiro vamos criar nossa função que mostra a próxima imagem “próximo”:

Listagem 7 - Função “próximo”

	proximo: function(){
    clearInterval(intervalo);
    elemento = document.querySelector(".ativo");

    if(elemento.nextElementSibling){
        elemento.nextElementSibling.classList.add("ativo");
        settings.legenda(elemento.nextElementSibling);
        elemento.classList.remove("ativo");
    }else{
        elemento.classList.remove("ativo");
        settings.primeiraImg();
    }
    intervalo = setInterval(settings.slide,4000);
},

O processo da função anonima “proximo” é o mesmo da função slide, apenas adicionamos um clearInterval(intervalo), que irá limpar o temporizador(tempo de execução) do nosso slide, e ao final da função reiniciamos nosso temporizador.

Agora iremos criar a função para mostrar a imagem anterior

Listagem 8 - função “anterior”

anterior: function(){
	clearInterval(intervalo);
	elemento = document.querySelector(".ativo");

	if(elemento.previousElementSibling){
		elemento.previousElementSibling.classList.add("ativo");
		settings.legenda(elemento.previousElementSibling);
		elemento.classList.remove("ativo");
	}else{
		elemento.classList.remove("ativo");						
		elemento = document.querySelector("a:last-child");
		elemento.classList.add("ativo");
		this.legenda(elemento);
	}
	intervalo = setInterval(settings.slide,4000);
},

Esta função também é quase a mesma que a anterior, so mudamos onde tem “next”(próximo) e colocamos “previous”(anterior).

Ainda falta anexar o evento de click nos nossos controladores, segue abaixo

Listagem 9 – Anexando a função de clique nos controladores

	document.querySelector(".next").addEventListener("click",settings.proximo,false);
	document.querySelector(".prev").addEventListener("click",settings.anterior,false);

Obs: Coloque a função de clique nos controladores no final da função “setaImagem”

Disponibilizei nosso código no github para quem quiser contribuir ou esteja tendo algum problema no slide (clique aqui)

Bem amigos ninjas javascript’s, com isso terminamos nosso post, um forte abraço e até a próxima

Abaixo nosso código javascript completo:

<script type="text/javascript">
function setaImagem(){
    var settings = {
        primeiraImg: function(){
            elemento = document.querySelector("#slider a:first-child");
            elemento.classList.add("ativo");
            this.legenda(elemento);
        },

        slide: function(){
            elemento = document.querySelector(".ativo");

            if(elemento.nextElementSibling){
                elemento.nextElementSibling.classList.add("ativo");
                settings.legenda(elemento.nextElementSibling);
                elemento.classList.remove("ativo");
            }else{
                elemento.classList.remove("ativo");
                settings.primeiraImg();
            }

        },

        proximo: function(){
            clearInterval(intervalo);
            elemento = document.querySelector(".ativo");

            if(elemento.nextElementSibling){
                elemento.nextElementSibling.classList.add("ativo");
                settings.legenda(elemento.nextElementSibling);
                elemento.classList.remove("ativo");
            }else{
                elemento.classList.remove("ativo");
                settings.primeiraImg();
            }
            intervalo = setInterval(settings.slide,4000);
        },

        anterior: function(){
            clearInterval(intervalo);
            elemento = document.querySelector(".ativo");

            if(elemento.previousElementSibling){
                elemento.previousElementSibling.classList.add("ativo");
                settings.legenda(elemento.previousElementSibling);
                elemento.classList.remove("ativo");
            }else{
                elemento.classList.remove("ativo");						
                elemento = document.querySelector("a:last-child");
                elemento.classList.add("ativo");
                this.legenda(elemento);
            }
            intervalo = setInterval(settings.slide,4000);
        },

        legenda: function(obj){
            var legenda = obj.querySelector("img").getAttribute("alt");
            document.querySelector("figcaption").innerHTML = legenda;
        }

    }

    //chama o slide
    settings.primeiraImg();

    //chama a legenda
    settings.legenda(elemento);

    //chama o slide à um determinado tempo
    var intervalo = setInterval(settings.slide,4000);
    document.querySelector(".next").addEventListener("click",settings.proximo,false);
    document.querySelector(".prev").addEventListener("click",settings.anterior,false);
}

window.addEventListener("load",setaImagem,false);
</script>

O post Criando slideshow do zero com javascript puro foi originalmente publicado em Tableless.

Enviado por Tiago Hillebrandt (tiagohillebrandtΘubuntu·com):

O artigo "Dicas de segurança para WordPress" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Com esse vídeo eu quero te incentivar a programar.

Acesse também o Ano do Código

http://www.youtube.com/watch?v=Ypid2GYpY7U

A mais rica biblioteca, quando desorganizada, não é tão proveitosa quanto uma bastante modesta, mas bem ordenada. Da mesma maneira, uma grande quantidade de conhecimentos, quando não foi elaborada por um pensamento próprio, tem muito menos valor do que uma quantidade bem mais limitada, que, no entanto, foi devidamente assimilada. Pois é apenas por meio da combinação ampla do que se sabe, por meio da comparação de cada verdade com todas as outras, que uma pessoa se apropria do próprio saber e o domina. Só é possível pensar com profundidade sobre o que se sabe, por isso se deve aprender algo; mas também só se sabe aquilo sobre o que se pensou com profundidade.

(Schopenhauer)

Send to Kindle