I recently noted that the COPY command in Postgres doesn’t have syntax to skip columns in source data when importing it into a table. This necessitates using one or more junk columns to capture data we’ll just be throwing away. During that, I completely forgot that friendly devs had contributed alternative file handling methods as Foreign Data Wrappers. Most people think of foreign wrappers as a method for interacting with remote databases. Perusing the full list however, reveals some surprising data sources. Twitter? Hive? Video cards?!

Well, let’s take a quick look at a real case. Here’s a table we want to import data into. We can’t insert into it directly, because of that extra column. So we’ll use an intermediate table as a raw import target, then insert into the target table. Let’s use COPY as a first approximation with 500,000 rows:

CREATE UNLOGGED TABLE option_quote_raw
(
  ext_quote_id BIGINT,
  quote_date DATE NOT NULL,
  quote_time_ns BIGINT NOT NULL,
  seq_no BIGINT NOT NULL,
  sub_seq_no BIGINT NOT NULL,
  exchange_id INT NOT NULL,
  time_us BIGINT NOT NULL,
  feed_side VARCHAR NOT NULL,
  flag INT NOT NULL,
  bid NUMERIC(16, 8) NOT NULL,
  ask NUMERIC(16, 8) NOT NULL,
  bid_size INT NOT NULL,
  ask_size INT NOT NULL,
  trash TEXT
);
 
CREATE UNLOGGED TABLE option_quote
(
  ext_quote_id BIGINT,
  quote_date DATE NOT NULL,
  quote_time_ns BIGINT NOT NULL,
  seq_no BIGINT NOT NULL,
  sub_seq_no BIGINT NOT NULL,
  exchange_id INT NOT NULL,
  time_us BIGINT NOT NULL,
  feed_side VARCHAR NOT NULL,
  flag INT NOT NULL,
  bid NUMERIC(16, 8) NOT NULL,
  ask NUMERIC(16, 8) NOT NULL,
  bid_size INT NOT NULL,
  ask_size INT NOT NULL
);
 
CREATE INDEX idx_quote_id ON option_quote (ext_quote_id);
 
\timing ON
 
COPY option_quote_raw FROM '/tmp/quote_source.csv' WITH CSV;
 
TIME: 1705.967 ms
 
INSERT INTO option_quote
SELECT ext_quote_id, quote_date, quote_time_ns, seq_no,
       sub_seq_no, exchange_id, time_us, feed_side, flag,
       bid, ask, bid_size, ask_size
  FROM option_quote_raw;
 
TIME: 2062.863 ms

Just under four seconds for half a million records on a table that has a pre-existing index is pretty good. But that process is pretty convoluted. Going back to that list of foreign wrappers, there’s an included file_fdw for tying a table directly to a file. Let’s repeat the same process from above by using FDW syntax:

CREATE EXTENSION file_fdw;
CREATE SERVER file_server FOREIGN DATA WRAPPER file_fdw;
 
CREATE FOREIGN TABLE file_quote
(
  ext_quote_id BIGINT,
  quote_date DATE NOT NULL,
  quote_time_ns BIGINT NOT NULL,
  seq_no BIGINT NOT NULL,
  sub_seq_no BIGINT NOT NULL,
  exchange_id INT NOT NULL,
  time_us BIGINT NOT NULL,
  feed_side VARCHAR NOT NULL,
  flag INT NOT NULL,
  bid NUMERIC(16, 8) NOT NULL,
  ask NUMERIC(16, 8) NOT NULL,
  bid_size INT NOT NULL,
  ask_size INT NOT NULL,
  trash TEXT
)
SERVER file_server
OPTIONS (format 'csv', filename '/tmp/quote_source.csv');
 
\timing ON
 
INSERT INTO option_quote
SELECT ext_quote_id, quote_date, quote_time_ns, seq_no,
       sub_seq_no, exchange_id, time_us, feed_side, flag,
       bid, ask, bid_size, ask_size
  FROM file_quote;
 
TIME: 3867.848 ms

Looks like the overall time is roughly the same. Of course, the best use case for this approach is when using a standard file path location that doesn’t change. The contents of the “table” do not resolve until it’s used, so the filename option could represent a standard file upload location. This means the foreign file table can be repeatedly reused, while the raw import table in our first attempt needs to be truncated and refilled before the INSERT statement.

There’s also the case of archives, where CSV files are compressed for long term storage. What if we want to examine the contents of these files, or import them at a later date? Luckily, the Multicorn extension exists as a kind of generic python FDW API. Using that API, anyone can use Python to build a quick foreign data wrapper. Someone did just that and contributed an extension that can process gzip compressed files.

Let’s see how that works:

CREATE EXTENSION multicorn;
 
CREATE SERVER csvgz FOREIGN DATA WRAPPER multicorn OPTIONS (
    WRAPPER 'csvgz_fdw.CSVGZForeignDataWrapper'
);
 
CREATE FOREIGN TABLE file_quote_gz
(
  ext_quote_id BIGINT,
  quote_date DATE NOT NULL,
  quote_time_ns BIGINT NOT NULL,
  seq_no BIGINT NOT NULL,
  sub_seq_no BIGINT NOT NULL,
  exchange_id INT NOT NULL,
  time_us BIGINT NOT NULL,
  feed_side VARCHAR NOT NULL,
  flag INT NOT NULL,
  bid NUMERIC(16, 8) NOT NULL,
  ask NUMERIC(16, 8) NOT NULL,
  bid_size INT NOT NULL,
  ask_size INT NOT NULL,
  trash TEXT
)
SERVER csvgz
OPTIONS (format 'csv', file_name '/tmp/quote_source.csv.gz');
 
\timing ON
 
INSERT INTO option_quote
SELECT ext_quote_id, quote_date, quote_time_ns, seq_no,
       sub_seq_no, exchange_id, time_us, feed_side, flag,
       bid, ask, bid_size, ask_size
  FROM file_quote_gz;
 
TIME: 16563.306 ms

Though this takes just shy of 17 seconds for the same 500k records, probably because the stack includes Multicorn, which depends on Python. Despite multiple levels of redirection, at least it’s possible! There is a native C version, but the author neglected to include build instructions. It’s possible performance of this extension could be improved with better streaming, as zcat on the same file requires less than a second. It also opens up the exciting potential of another extension that has the compression engine as another option, so tables could also access bzip2, xz, or other compressed formats.

Compressed files aside, is there any way to handle wildcards? Sometimes it makes sense to process all CSV files in a single folder, for example. Well, that doesn’t exist yet, but at the rate new wrappers are appearing, it’s only a matter of time. It’s also possible there’s already one out there, but it simply isn’t on the Wiki page, or the author hasn’t formalized it for contribution yet. In fact, there are probably quite a few foreign data wrappers that share that particular attribute.

It’s great to see other import methods appearing to address deficits in COPY functionality. I’ll definitely be watching the Wiki page for more.

Photo by Tambako the Jaguar

The recent release of Postgres 9.5 has many people excited about the big new features such as UPSERT (docs) and row-level security (docs). Today I would like to celebrate three of the smaller features that I love about this release.

Before jumping into my list, I'd like to thank everyone who contributes to Postgres. I did some quick analysis and found that 85 people, from Adrien to Zeus, have helped version 9.5 of Postgres, at least according to the git logs. Of course, that number is actually higher, as it doesn't take into account people helping out on the #postgresql channel, running buildfarm animals, doing packaging work, keeping the infrastructure running, etc. Thanks to you all!

Feature: REINDEX VERBOSE

The first feature is one I've been wishing for a long time - a verbose form of the REINDEX command. Thanks to Sawada Masahiko for adding this. Similar to VACUUM, REINDEX gets kicked off and then gives no progress or information until it finishes. While VACUUM has long had the VERBOSE option to get around this, REINDEX gives you no clue to which index it was working on, or how much work each index took to rebuild. Here is a normal reindex, along with another 9.5 feature, the ability to reindex an entire schema:

greg=# reindex schema public;
## What seems like five long minutes later...
REINDEX

The new syntax uses parenthesis to support VERBOSE and any other future options. If you are familiar with EXPLAIN's newer options, you may see a similarity. More on the syntax in a bit. Here is the much improved version in action:

greg=# reindex (verbose) schema public;
INFO:  index "foobar_pkey" was reindexed
DETAIL:  CPU 11.00s/0.05u sec elapsed 19.38 sec.
INFO:  index "foobar_location" was reindexed
DETAIL:  CPU 5.21s/0.05u sec elapsed 18.27 sec.
INFO:  index "location_position" was reindexed
DETAIL:  CPU 9.10s/0.05u sec elapsed 19.70 sec.
INFO:  table "public.foobar" was reindexed
INFO:  index "foobaz_pkey" was reindexed
DETAIL:  CPU 7.04s/0.05u sec elapsed 19.61 sec.
INFO:  index "shoe_size" was reindexed
DETAIL:  CPU 12.26s/0.05u sec elapsed 19.33 sec.
INFO:  table "public.foobaz" was reindexed
REINDEX

Why not REINDEX VERBOSE TABLE foobar? Or even REINDEX TABLE foobar WITH VERBOSE? There was a good discussion of this on pgsql-hackers when this feature was being developed, but the short answer is that parenthesis are the correct way to do things moving forward. Robert Haas summed it up well:

Alas, this will probably trip a lot of people up, as REINDEX VERBOSE TABLE foobar does not work, nor does \h REINDEX in psql give the correct output as of version 9.5.0:

greg=# \h REINDEX
Command:     REINDEX
Description: rebuild indexes
Syntax:
REINDEX { INDEX | TABLE | DATABASE | SYSTEM } name [ FORCE ]

What is should output is this:

greg=# \h REINDEX
Command:     REINDEX
Description: rebuild indexes
Syntax:
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | DATABASE | SYSTEM } name [ FORCE ]

Digging in the source code for psql show that sql_help.c and sql_help.h are the files that generate this help output. I'd submit a patch, but those files are not in git, and the Makefile specifies:

sql_help.h: create_help.pl $(wildcard $(REFDOCDIR)/*.sgml)
    $(PERL) $< $(REFDOCDIR) $*

Which means that a Perl script is responsible for slurping the correct syntax in from our SGML documentation. Happily, the SGML is up to date, which you can see by visiting the offical REINDEX page (HTML). Maybe someone forgot to run create_help.pl?

Feature: pg_ctl defaults to "fast" mode

The second feature in Postgres 9.5 I am happy about is the change in niceness of pg_ctl from "smart" mode to "fast" mode. The help of pg_ctl explains the different modes fairly well:

pg_ctl is a utility to initialize, start, stop, or control a PostgreSQL server.

Usage:
  pg_ctl stop    [-W] [-t SECS] [-D DATADIR] [-s] [-m SHUTDOWN-MODE]
...
Shutdown modes are:
  smart       quit after all clients have disconnected
  fast        quit directly, with proper shutdown
  immediate   quit without complete shutdown; will lead to recovery on restart

In the past, the default was 'smart'. Which often means your friendly neighborhood DBA would type "pg_ctl restart -D data", then watch the progress dots slowly marching across the screen, until they remembered that the default mode of "smart" is kind of dumb - as long as there is one connected client, the restart will not happen. Thus, the DBA had to cancel the command, and rerun it as "pg_ctl restart -D data -m fast". Then they would vow to remember to add the -m switch in next time. And promptly forget to the next time they did a shutdown or restart. :) Now pg_ctl has a much better default. Thanks, Bruce Momjian!

Feature: new 'cluster_name' option

When you run a lot of different Postgres clusters on your server, as I tend to do, it can be hard to tell them apart as the version and port are not reported in the ps output. I sometimes have nearly a dozen different clusters running, due to testing different versions and different applications. Similar in spirit to the application_name option, the new cluster_name option solves the problem neatly by allowing a custom string to be put in to the process title. Thanks to Thomas Munro for inventing this. So instead of this:

greg      7780     1  0 Mar01 pts/0    00:00:03 /home/greg/pg/9.5/bin/postgres -D data
greg      7787  7780  0 Mar01 ?        00:00:00 postgres: logger process   
greg      7789  7780  0 Mar01 ?        00:00:00 postgres: checkpointer process   
greg      7790  7780  0 Mar01 ?        00:00:09 postgres: writer process   
greg      7791  7780  0 Mar01 ?        00:00:06 postgres: wal writer process   
greg      7792  7780  0 Mar01 ?        00:00:05 postgres: autovacuum launcher process   
greg      7793  7780  0 Mar01 ?        00:00:11 postgres: stats collector process  
greg      6773     1  0 Mar01 pts/0    00:00:02 /home/greg/pg/9.5/bin/postgres -D data2
greg      6780  6773  0 Mar01 ?        00:00:00 postgres: logger process   
greg      6782  6773  0 Mar01 ?        00:00:00 postgres: checkpointer process   
greg      6783  6773  0 Mar01 ?        00:00:04 postgres: writer process   
greg      6784  6773  0 Mar01 ?        00:00:02 postgres: wal writer process   
greg      6785  6773  0 Mar01 ?        00:00:02 postgres: autovacuum launcher process   
greg      6786  6773  0 Mar01 ?        00:00:07 postgres: stats collector process

One can adjust the cluster_name inside each postgresql.conf (for example, to 'alpha' and 'bravo'), and get this:

greg      8267     1  0 Mar01 pts/0    00:00:03 /home/greg/pg/9.5/bin/postgres -D data
greg      8274  8267  0 Mar01 ?        00:00:00 postgres: alpha: logger process   
greg      8277  8267  0 Mar01 ?        00:00:00 postgres: alpha: checkpointer process   
greg      8278  8267  0 Mar01 ?        00:00:09 postgres: alpha: writer process   
greg      8279  8267  0 Mar01 ?        00:00:06 postgres: alpha: wal writer process   
greg      8280  8267  0 Mar01 ?        00:00:05 postgres: alpha: autovacuum launcher process   
greg      8281  8267  0 Mar01 ?        00:00:11 postgres: alpha: stats collector process  
greg      8583     1  0 Mar01 pts/0    00:00:02 /home/greg/pg/9.5/bin/postgres -D data2
greg      8590  8583  0 Mar01 ?        00:00:00 postgres: bravo: logger process   
greg      8592  8583  0 Mar01 ?        00:00:00 postgres: bravo: checkpointer process   
greg      8591  8583  0 Mar01 ?        00:00:04 postgres: bravo: writer process   
greg      8593  8583  0 Mar01 ?        00:00:02 postgres: bravo: wal writer process   
greg      8594  8583  0 Mar01 ?        00:00:02 postgres: bravo: autovacuum launcher process   
greg      8595  8583  0 Mar01 ?        00:00:07 postgres: bravo: stats collector process

There are a lot of other things added in Postgres 9.5. I recommend you visit this page for a complete list, and poke around on your own. A final shout out to all the people that are continually improving the tab-completion of psql. You rock.

Se não vale a pena esperar por aquilo que você orou, então, não vale a pena pedir.

(David Wilkerson)

Certamente a essência da sabedoria está em, antes de começarmos a agir ou de tentar agradar a Deus, descobrir o que Deus tem a dizer sobre o assunto.

(Martyn Lloyd-Jones)

Duas coisas sempre vêm juntas na experiência de um crente genuíno:
uma crescente descoberta da própria vileza
e uma profunda apreciação da preciosidade de Cristo.
“Eis que sou vil” (Jó 40.4).
“Miserável homem que eu sou!” (Romanos 7.24).
“Sim, Ele é totalmente desejável” (Cântico dos cânticos 5.16).
“E assim para vós, os que credes, é preciosa [Ele, a Rocha]” (1Pedro 2.7).

(Arthur Pink)

Se a Bíblia é falsa, como alguns homens soberbos se atrevem a dizer, não há motivo para manter um dia da semana santo, não há utilidade em honrar a igreja e exercer uma profissão de fé; não somos melhores do que os animais que perecem e a melhor coisa que um homem pode fazer é comer, beber e viver como lhe agrada. Se a Bíblia só é metade verdadeira, como algumas pessoas infelizes lutam por torná-la, não há certeza sobre nossa alma eterna: todo o Cristianismo é dúvida, obscuridade e suposição, nunca poderemos conhecer o que cremos ser necessário para salvação, nunca poderemos estar certos que nos apossamos das palavras de vida eterna. Abandone sua Bíblia e você não terá uma polegada quadrada de certeza e confiança para manter-se em posição; você pode pensar, imaginar e ter opinião própria, mas você não poderá me mostrar qualquer prova ou autoridade satisfatória de que está certo; você meramente está construindo algo apoiado em seu próprio julgamento; você coloca seus olhos para fora, por assim dizer, e como alguém no escuro, não sabe para onde realmente está indo.
Mas, amado, se a Bíblia é de fato a Palavra do próprio Deus e completamente verdadeira, então pode ser comprovada por inúmeras testemunhas; se a Bíblia é de fato verdade e nosso único guia para o céu – e isso eu confio que você esteja pronto em consentir – certamente deve ser o dever de todo homem pensante e sábio colocar no coração cada doutrina contida nela, e não acrescentar nada a ela, e ser cuidadoso para não tirar nada dela.

(J. C. Ryle)

Eu não sou o que eu deveria ser. Ah, quão imperfeito e deficiente sou!
Eu não sou o que quero ser. Abomino o que é mau, e eu, no poder de Deus, dia a dia quero abrir caminho para o que é bom, a conformidade com Cristo!
Eu não sou o que eu espero ser. Logo, logo devo ser liberto de toda mortalidade, e com a mortalidade, todo pecado e imperfeição partirão.
No entanto, embora eu não seja o que eu deveria ser,
nem o que eu quero ser,
nem o que eu espero ser,
eu posso verdadeiramente dizer que eu não sou o que eu era antes;
ESCRAVO do pecado, das paixões e de Satanás;
e posso sinceramente juntar-me com o apóstolo, e reconhecer,
“Pela graça de Deus sou o que sou.”

(John Newton)

Não conheço outro prazer tão rico, tão puro, tão santificador em suas influências ou ainda tão constante em seus benefícios como aquele que resulta da verdadeira e espiritual adoração a Deus.

(Richard Watson)

É melhor ir ao céu sozinho do que ao inferno acompanhado!

(Thomas Brooks)

Precisei fazer uma prova simples para um cliente para mostrar como o parâmetro de storage FILLFACTOR afeta uma tabela e como verificar a sua eficiência. Toda vez que um UPDATE é executado no PostgreSQL, ele marca a tupla atualizada para remoção posterior e cria um novo registro. Porém, se no bloco onde o dado está gravado houver espaço sobrando, o PostgreSQL pode fazer a atualização dentro do próprio bloco, utilizando um recurso conhecido como “Heap Only Tuples”, ou HOT. Quando foi introduzido no PG 8.3, foi considerado um divisor de águas, aumentando muito a performance do banco e diminuindo o uso do Vacuum. Mas você pode dar uma ajuda para o HOT funcionar, deixando mais espaço livre para ele trabalhar em tabelas que sofrem muitas atualizações. Vejamos uma demonstração simples.

Primeiro vamos criar uma tabela nova e verificar as estatísticas e depois rodar um UPDATE:

tst=# CREATE TABLE abizi AS SELECT * FROM pg_class ;
SELECT 1009

tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi';
 n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup 
-----------+-----------+---------------+------------+------------
 1009      | 0         | 0             | 1009       | 0
(1 row)

tst=# UPDATE abizi SET relname = 'abizi';
UPDATE 1009

tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi';
 n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup 
-----------+-----------+---------------+------------+------------
 1009      | 1009      | 5             | 1009       | 1009
(1 row)

Note que após a atualização, os 1009 registros foram atualizados. Ao olhar o campo n_tup_hot_upd, ou seja número de tuplas que realizaram o HOT durante o UPDATE vemos que apenas 5 foram atualizados com o HOT.

Agora vamos criar novamente a tabela e antes de popular ela vamos ajustar o FILLFACTOR em 90:

tst=# DROP TABLE abizi;
DROP TABLE

tst=# CREATE TABLE abizi AS SELECT  * FROM pg_class WITH NO DATA;
SELECT 0
bbtmd=# ALTER TABLE abizi SET (fillfactor = 90);
ALTER TABLE

tst=# INSERT INTO abizi SELECT * FROM pg_class ;
INSERT 0 1012

tst=# UPDATE abizi SET relname = 'abizi';
UPDATE 1012

tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi';
 n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup 
-----------+-----------+---------------+------------+------------
      1012 |      1012 |           116 |       1012 |       1012

Note que agora o número de registros que usaram o HOT subiu para 116. Se fizermos a mesma coisa com um FILLFACTOR em 70:

tst=# DROP TABLE abizi;
DROP TABLE

tst=# CREATE TABLE abizi AS SELECT  * FROM pg_class WITH NO DATA;
SELECT 0

tst=# ALTER TABLE abizi SET (fillfactor = 70);
ALTER TABLE

tst=# INSERT INTO abizi SELECT * FROM pg_class ;
INSERT 0 1012

tst=# UPDATE abizi SET relname = 'abizi';
UPDATE 1012

tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi';
 n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup 
-----------+-----------+---------------+------------+------------
      1012 |      1012 |           449 |       1012 |       1012

Por fim com FILLFACTOR EM 50:

bbtmd=# DROP TABLE abizi;
DROP TABLE

tst=# CREATE TABLE abizi AS SELECT  * FROM pg_class WITH NO DATA;
SELECT 0

tst=# ALTER TABLE abizi SET (fillfactor = 50);
ALTER TABLE

tst=# INSERT INTO abizi SELECT * FROM pg_class ;
INSERT 0 1012

tst=# UPDATE abizi SET relname = 'abizi';
UPDATE 1012

tst=# SELECT n_tup_ins, n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'abizi';
 n_tup_ins | n_tup_upd | n_tup_hot_upd | n_live_tup | n_dead_tup 
-----------+-----------+---------------+------------+------------
      1012 |      1012 |          1012 |       1012 |       1012
(1 row)

Note que aumentar o valor o FILLFACTOR significa também aumentar o volume de espaço em disco utilizado. No nosso exemplo, a tabela que com 100% de FILLFACTOR (o padrão) ocupava 208KB ocupou 424KB com 50%.

O negócio é acompanhar as estatísticas da sua base e verificar onde você tem tabelas com tamanho menor e alto volume de UPDATEs. Nestas tabelas, ajustar o FILLFACTOR, AUTOVACUUM e AUTOANALYZE é vital para um bom desempenho. Tabelas pequenas às vezes passam desapercebidas pelos olhos dos DBAs, mas podem ser grande fonte de dor de cabeça se forem utilizadas com frequência e não forem ajustadas de maneira correta.

Qualquer um pode aprender teoria lendo posts de blogs, mas muitas pessoas nunca a entendem. Então para ter certeza que o(a) candidato(a) realmente entende sobre o tópico que ele(a) está falando, é uma boa ideia testar o seus conhecimentos através de exercícios. Exercícios não devem demorar muito e eles podem mostrar o nível de proficiência do candidato imediatamente.

Estes são alguns exercícios que podem ser aplicados em entrevistas.

Contexto(call, apply)

Essa é a forma que queremos usar “someFn”. O(a) candidato(a) deve implementá-la:

var result = someFun({ someProperty: 'interview' }, function() {
	console.log('This pointing to'. this);
});

console.log('Result is', result);

// Resultado esperado
This pointing to { someProperty: 'interview' }
Result is 1

Solução:

var someFn = function(obj, cb) {
	cb.call(obj);
	return 1;

Adicional

Você pode modificar a função para checar se o(a) candidato(a) sabe como usar o “apply”.

var result = someFn({ someProperty: 'interview' }, function (param1, param2) {
	console.log('This pointing to', this);
	console.log('Param 1 is', param1);
	console.log('Param 2 is', param2);
}, ['cool', 'interview']);

console.log('Result is', result);

// Resultado esperado
This pointing to { someProperty: 'interview' }
Param 1 is "cool"
Param 2 is "interview"
Result is 1

Solução:

var someFn = function (obj, cb, params) {
	cb.apply(obj, params);
	return 1;
}

Prototype e Iteração

Definir um método nativo chamado “each” para iterar em um array, com a opção de passar o contexto como segundo argumento.

var arr = [1, 2, 3];
arr.each(function (arrayItem, counter) {
	console.log('index', counter);
	console.log('item', arrayItem);

	arr[counter] = arrayItem + 1;
}, this);

Solução:

Array.prototype.each = Array.prototype.each || function (cb, context) {
    for (var i = 0; i < this.length; i++) {
        cb.call(context || this, this[i], i);
    }
};

Escopo

Definir “someFn” que irá funcionar da seguinte maneira:

var counter = someFn(1);
console.log('First call', counter(3));
console.log('Second call', counter(1));
console.log('Third call', counter(5));

// Resultado esperado
First call 4
Second call 5
Third call 10

Solução:

var someFn = function (start) {
	var private = start;

	return function (increment) {
		private += increment;

		return private;
	}
}

Traduzido de: http://goschevski.com/simple-javascript-interview-exercises/

---
Este artigo foi escrito por Wendell Adriel.

Visite o nosso site para mais posts sobre desenvolvimento web! Tableless.

The fallout from the epic hack on the Office of Personnel Management (OPM) continues. Since the congressional oversight hearings in June 2015, OPM Director Katherine Archuleta resigned; the government was hit with a number of lawsuits from “victims”; OPM hired a cybersecurity advisor, Clifton Triplett, and increased its IT “modernization” budget from $31 million to $87 million, with another $21 million scheduled for 2016; and the Obama administration announced Friday that OPM will no longer conduct background investigations. The FBI and Department of Homeland Security also released a “cyber alert” outlining a collective analysis and lessons learned from the OPM hack.

The memo was distributed only to cleared contractors by the Defense Security Service, and it includes a number of recommendations for security efforts going forward. While the memo does not name OPM specifically, according to an FCW article, the timing of its release and the recommendations included reportedly coincide with the OPM breach directly.

At the forefront is the recommendation for a segmented identity management system, which, according to the memo, could have limited the severity of the OPM breach. From the FCW article:

“When an organization’s network is not segmented from others, this could mean hundreds of sub-networks are affected versus one,” the memo states. Privileged access controls “would have helped detect the intrusion earlier and made it significantly more difficult for the actor to spread across the network.”

While the entire memo could not be located, FCW did list a number of security recommendations from it, including:

• Enabling a personal firewall at agency workstations
• Monitoring users’ online habits and blocking potentially malicious sites
• Employing encryption for data at rest and in transit
• and Investigating “outbound network traffic observed over TCP port 53 that does not conform to the DNS protocol.”

Hopefully there are more recommendations than these few in the memo. To make up for the lack of the full list, here is a list of learning lessons from current events and studies conducted over the past couple years:

• Identity management should be priority one:
  While this space with IT security has grown tremendously in the last few years, it remains a nonetheless crucial part to securing an organization. Especially if said organization outsources components of work to third-party vendors, like in the case of OPM.
  
• Keep infrastructure patched and updated:
  The Cisco Annual Security Report noted that of 115,000 devices Cisco researchers scanned, 92 percent of them were susceptible to known vulnerabilities. The FBI and DHS memo about the OPM hack names “convenience” and “accessibility” specifically as aids to the hack.
• Full disk encryption for all endpoints:
  A recent report from Sophos showed many companies are not going through the effort of encrypting company data, nearly 70 percent in some industries.

• Monitor DNS traffic and check against any and all available threat intelligence feeds:
  The same Cisco annual report mentioned earlier also found that many organizations are not monitoring DNS traffic, despite its wealth of information about user behavior and possible indicators of compromise.

• Enable and enforce strong password management:
  SplashData recently released a study that found the worst possible passwords —like ‘123456’ — are still being used regularly. Same as they were since 2011.

• Educate employees to spot phishing attempts:
  Despite its long history in the hacking toolkit, phishing continues to be an effective way to gain access to company networks. Employee training has proved effective in helping the efforts of IT and security orgs. 
• Manage third-party vendor and contractor access:
  According to congressional hearing testimony, hackers gained access to OPM networks through a third-party contractor, which is unfortunately common.

This list might be a good start, and would keep an IT organization busy for months if not years. But it’s in no way exhaustive. What would you add to OPM’s to-do list to keep it more secure?

The post FBI, DHS Share Lessons Learned from OPM Hack appeared first on OpenDNS Blog.

Postgres theory, feature discussion, and advocacy are fun. But even I’ll admit it’s nice to have some practical application every once in a while. This week, we’re going to build an actual database.

But what would be small enough for a proof of concept, yet somewhat interesting? Well, I’m a fan of Hearthstone. It’s a silly card game much like Magic: The Gathering, but has the distinct aura of “eSports!” Regardless, it’s a fun little time waster, and has a few hundred data points we can manipulate.

Annoyingly, there’s no official card list. But fans are nothing if not dedicated, and several folks maintain spreadsheets for their own purposes and often share them. This one had a pretty good breakdown and is up to date with the latest expansions, so it makes a good starting point.

The second page of this Excel workbook is a card list, which I saved as a quoted tab-delimited file. The first three lines are garbage, so away they went. The last four lines are also empty, so into the digital bucket in the sky they passed. What’s left is something that we can import into a junk table:

CREATE UNLOGGED TABLE hs_raw_import (
  junk1 VARCHAR,
  junk2 VARCHAR,
  junk3 VARCHAR,
  junk4 VARCHAR,
  expansion VARCHAR,
  card_name VARCHAR,
  character_class VARCHAR,
  rarity VARCHAR,
  category VARCHAR,
  tribe VARCHAR,
  mana_cost VARCHAR,
  attack VARCHAR,
  hitpoints VARCHAR,
  card_text VARCHAR,
  junk5 VARCHAR,
  junk6 VARCHAR,
  junk7 VARCHAR
);
 
COPY hs_raw_import FROM '/tmp/hearthstone_cards.tsv'
  WITH CSV DELIMITER E'\t' HEADER;
 
ANALYZE hs_raw_import;

All of the “junk” columns are an unfortunate reality of the current COPY command; there’s no way to ignore columns in source files. That’s OK in this case because we’re going to discard the import table when everything is done, and it’s certainly speedy. Importing all 743 rows on a test VM required less than 5ms.

Now we need to transform the data into something a bit more normalized. To do that, we need to look at the data. A technique that works really well is to examine how the data is distributed by checking the contents of the pg_stats table. Let’s look at this data:

SELECT attname, n_distinct
  FROM pg_stats
 WHERE tablename='hs_raw_import'
   AND attname NOT LIKE 'junk%';
 
     attname     | n_distinct 
-----------------+------------
 expansion       |          9
 card_name       |         -1
 hitpoints       |         12
 card_text       |   -0.89502
 character_class |         10
 rarity          |          5
 category        |          3
 tribe           |          7
 mana_cost       |         13
 attack          |         12

Looking at the statistics, any negative number means there’s a proportional relationship between the total row count and the number of distinct values. Positive numbers are absolute counts, and those are the ones we want to focus on for normalization.

After leveraging a bit of knowledge regarding the actual game mechanics, we can ignore elements that act as measurable metrics. Things like hitpoints, attack, and mana_cost may not have a lot of distinct values, but don’t have further associated information. But what about the rest? Let’s dig a little deeper:

• expansion : As with most CCGs, new cards and mechanics are added through expansions. These have their own associated attributes we might want to track independently. This one warrants a new table.
• character_class : In Hearthstone, cards are separated into nine distinct classes, with a tenth as neutral cards any class can leverage. Again, if we were writing an app, we might list several other data points about each class, so we’d want that in a separate table.
• rarity : This one is a bit tricky. There are currently only five rarity levels, each of which has an occurrence percentage when opening new card packs. Yet Blizzard is not likely to add further rarity levels. For now, let’s leave percentages as an academic exercise, and just leave rarity as a text description.
• category : Currently there are only minions, spells, and weapons. This is extremely likely to change in the future, assuming the game remains popular for several more decades, as Magic has. This one gets a new table.
• tribe : Some players consider this a subcategory. Minions can sometimes be further broken down into a taxonomy that will alter game mechanics via synergistic effects. We definitely want to track this separately.

Not listed here are attributes inherent in the card text itself. The taunt attribute for example, is a significant variable game mechanic, which we’ll want to mine from the text. Since card text is often conditional, these optional elements should also be tracked separately through an attribute table.

Given all of this, here’s an extremely simplified architecture for representing the cards themselves, with ‘etc’ representing further descriptive columns. Queries to bootstrap them from the source table are at the end:

CREATE TABLE expansion (
  expansion_id    SERIAL PRIMARY KEY,
  expansion_name  VARCHAR NOT NULL,
  release_date    DATE NULL,
  etc             VARCHAR NULL
);
 
CREATE TABLE character_class (
  class_id       SERIAL PRIMARY KEY,
  class_name     VARCHAR NOT NULL,
  hero_power     VARCHAR NULL,
  etc            VARCHAR NULL
);
 
CREATE TABLE category (
  category_id    SERIAL PRIMARY KEY,
  category_name  VARCHAR NOT NULL,
  etc            VARCHAR NULL
);
 
CREATE TABLE minion_tribe (
  tribe_id    SERIAL PRIMARY KEY,
  tribe_name  VARCHAR NOT NULL,
  etc         VARCHAR NULL
);
 
CREATE TABLE attribute (
  attribute_id  SERIAL PRIMARY KEY,
  att_name      VARCHAR NOT NULL,
  effect        TEXT NULL,
  etc           VARCHAR NULL
);
 
CREATE TABLE card (
  card_id       SERIAL PRIMARY KEY,
  expansion_id  INT NOT NULL REFERENCES expansion,
  card_name     VARCHAR NOT NULL,
  class_id      INT NOT NULL REFERENCES character_class,
  rarity        VARCHAR NOT NULL,
  category_id   INT NOT NULL REFERENCES category,
  tribe_id      INT NULL REFERENCES minion_tribe,
  mana_cost     INT NOT NULL,
  attack        INT NULL,
  hitpoints     INT NULL,
  card_text     TEXT
);
 
CREATE INDEX idx_card_expansion ON card (expansion_id);
CREATE INDEX idx_card_class ON card (class_id);
CREATE INDEX idx_card_category ON card (category_id);
CREATE INDEX idx_card_tribe ON card (tribe_id);
 
CREATE TABLE card_attribute (
  card_id       INT NOT NULL REFERENCES card,
  attribute_id  INT NOT NULL REFERENCES attribute
);
 
CREATE INDEX idx_card_attribute_attribute_id
    ON card_attribute (attribute_id);
 
INSERT INTO expansion (expansion_name)
SELECT DISTINCT expansion FROM hs_raw_import;
 
INSERT INTO character_class (class_name)
SELECT DISTINCT character_class FROM hs_raw_import;
 
INSERT INTO category (category_name)
SELECT DISTINCT category FROM hs_raw_import;
 
INSERT INTO minion_tribe (tribe_name)
SELECT DISTINCT tribe FROM hs_raw_import;
 WHERE tribe IS NOT NULL;
 
INSERT INTO attribute (att_name) VALUES ('taunt'), ('enrage');
 
INSERT INTO card (
    expansion_id, card_name, class_id, rarity, category_id,
    tribe_id, mana_cost, attack, hitpoints, card_text
)
SELECT e.expansion_id, r.card_name, cl.class_id, r.rarity,
       ca.category_id, t.tribe_id, r.mana_cost::INT,
       r.attack::INT, r.hitpoints::INT, r.card_text
  FROM hs_raw_import r
  JOIN expansion e ON (e.expansion_name = r.expansion)
  JOIN character_class cl ON (cl.class_name = r.character_class)
  JOIN category ca ON (ca.category_name = r.category)
  LEFT JOIN minion_tribe t ON (t.tribe_name = r.tribe);
 
INSERT INTO card_attribute (card_id, attribute_id)
SELECT c.card_id, a.attribute_id
  FROM card c
  JOIN attribute a ON (c.card_text ~* a.att_name);
 
ANALYZE attribute;
ANALYZE card_attribute;
ANALYZE expansion;
ANALYZE character_class;
ANALYZE category;
ANALYZE minion_tribe;
ANALYZE card;

Whew! That was a lot of work! But in the end, we have a constellation that accurately represents how cards work, with future potential of adding more mechanics without the necessity of reorganizing our architecture. There are obviously more potential attributes than taunt and enrage, but we’ll leave the data mining as an exercise for anyone interested enough to really flesh out the model.

Postgres offers us a nice way to leverage this data, too. Having to decode all of these IDs is pretty annoying, so we probably want a view. Further, cards don’t change very often, and new expansions are only released every few months. This makes them a great candidate for a materialized view. Here’s how we’d do that:

CREATE MATERIALIZED VIEW v_all_cards AS
SELECT e.expansion_name AS expansion, c.card_name,
       cl.class_name AS class, c.rarity,
       ca.category_name AS category,
       t.tribe_name AS tribe, c.mana_cost,
       c.attack, c.hitpoints, c.card_text,
       ARRAY(
         SELECT a.att_name
           FROM card_attribute tr
           JOIN attribute a USING (attribute_id)
          WHERE tr.card_id = c.card_id
       ) AS attributes
  FROM card c
  JOIN expansion e USING (expansion_id)
  JOIN character_class cl USING (class_id)
  JOIN category ca USING (category_id)
  LEFT JOIN minion_tribe t USING (tribe_id);
 
CREATE INDEX idx_all_expansion ON v_all_cards (expansion);
CREATE INDEX idx_all_class ON v_all_cards (class);
CREATE INDEX idx_all_category ON v_all_cards (category);
CREATE INDEX idx_all_tribe ON v_all_cards (tribe);
 
SELECT card_name, class, rarity
  FROM v_all_cards
 WHERE expansion = 'Classic'
   AND 'enrage' = ANY(attributes);
 
      card_name      |  class  |  rarity   
---------------------+---------+-----------
 Angry Chicken       | Neutral | Rare
 Amani Berserker     | Neutral | Common
 Raging Worgen       | Neutral | Common
 Tauren Warrior      | Neutral | Common
 Spiteful Smith      | Neutral | Common
 Grommash Hellscream | Warrior | Legendary

And of course, this particular rabbit hole can go much, much deeper. With only a few hundred rows, it may seem silly to design the database this way, but slap a front-end on this, and it’s a collection management tool that rivals the one built into the actual game client. The official client only allows players to search their collection by expansion, mana cost, and text, while our structure has far more flexibility.

This is just one example for using Postgres in an everyday scenario. There’s much more out there if you’re interested in looking. Happy hunting!

This blog post has been contributed by our NetBeans PHP user Junichi Yamamoto who is helping a lot with fixing issues in all the areas of  NetBeans PHP support. He has also contributed a few plugins, e.g. support for CakePHP framework. He would like to tell you a few words about one new PHP feature in NetBeans. Thanks a lot, Junichi!

Hi all. Today we will show you the new brace matching feature which will be available in next NetBeans version. If a caret is on a closing brace and the opening brace is hidden, not only the brace but also context information is shown as a tooltip. This feature would be useful, if an opening brace is written on the next line.

NOTE: If an opening brace is for else keyword(not elseif/else if), the last if keyword line is also shown.

That's all for today. As usually, please test it. It's available in the development version. If you find some issues or enhancements, please report them to NetBeans Bugzilla (component php, subcomponent Editor). Thanks.

O post Contar número de linhas de um arquivo de texto com PHP apareceu primeiro em PHPit - Blog de PHP do Rafa Jaques.

Contar o número de linhas existentes em um arquivo de texto pode parecer uma tarefa trivial, mas nem sempre é. Dependendo da maneira que você optar por fazer isso, pode acabar comprometendo o desempenho do servidor. Geralmente utilizamos essas técnicas para contar o número de linhas em arquivos txt, mas você pode utilizar em qualquer arquivo que contenha texto.

Técnica para contar linhas de arquivos pequenos

Se você tiver que contar o número de linhas de um arquivo pequeno, você pode utilizar uma combinação das funções file(), que carregará todo o arquivo na memória em formato de array e count(), que contará o número de índices no array (equivalente ao número de linhas).

O código fica mais ou menos assim:

$linhas = count( file( '/caminho/para/o/arquivo.txt' ) );

Importante: como o conteúdo é completamente carregado na memória, arquivos grandes irão demandar muito espaço e processamento. Não utilize essa técnica em arquivos pesados para não sobrecarregar o seu servidor.

Técnica para contagem de linhas em qualquer arquivo de texto

Você pode utilizar um ponteiro para contar o número de linhas em um arquivo de texto sem precisar carregá-lo completamente na memória. Basicamente o que você fará as seguintes etapas:

• Carregar um ponteiro de leitura na memória utilizando fopen();
• Usar fgets() para ler linha por linha, desprezando o valor da linha e ficando apenas com a contagem das mesmas;
• Aguardar feof() retornar true, indicando que a leitura chegou no final do arquivo (EOF = End Of File);
• Utilizar fclose() para encerrar o ponteiro e liberar o arquivo.

Dessa forma, separei duas abordagens, uma mais didática e outra mais concisa:

$linhas = 0; // Número inicial de linhas contadas
$arquivo = fopen('/caminho/para/o/arquivo.txt', 'r'); // Carrega o ponteiro

while ( !feof( $arq ) ) { // Enquanto não chegar ao final do arquivo...
    fgets( $arq ); // Perceba que o conteúdo não é colocado em nenhuma variável, pois não interessa à contagem
    $linhas++; // Aumenta a contagem de linhas
}

fclose( $arq ); // Encerra o ponteiro e libera o arquivo

Se quiser uma versão mais resumida, pode utilizar for:

for ($linhas = 0, $arq = fopen('/caminho/arquivo.txt', 'r'); !feof($arq); $linhas++)
    fgets( $linhas );
fclose( $fp);

Se tiver problema com as funções de arquivos, pode consultar o registro de fopen() manual do PHP para encontrar mais informações.

Não deixem de comentar na postagem se tiverem dúvidas.

Um abraço a todos e fiquem com Deus.
Rafael Jaques

O post Contar número de linhas de um arquivo de texto com PHP apareceu primeiro em PHPit - Blog de PHP do Rafa Jaques.

Passe bastante tempo meditando no que Ele fez por você e no que Ele é, como o “Primeiro entre dez mil” e o “completamente desejável.”

Desperte o fogo interior através da memória, e deixe a esperança empilhar sobre ele o combustível da promessa até que a chama volte a arder.

Cultive o hábito de conversar com Ele em voz alta em uma sala vazia ou em caminhadas a sós até que Ele esteja entrelaçado aos menores episódios da sua vida (Ct 5.10,16).

Abra seu coração para a entrada do Espírito Santo, derramando o amor de Deus no coração, e direcione os raios deste amor para formar um foco ardente em que você ame a Deus com o amor que veio do coração Dele e entrou no seu.(Rm 5.5).

E especialmente, acostume-se a fazer, por amor a Ele, muitas coisas que lhe custem sacrifício e esforço. Quando mostramos amor ao próximo, entendemos Seu amor para nós mesmos. “Todo aquele que ama é nascido de Deus e conhece a Deus. Aquele que não ama não conhece a Deus, pois Deus é amor” (I Jo 4.7,8).

A chave para o conhecimento do amor de Jesus não está no cantar hinos arrebatadores nem em buscar o despertamento de intensas emoções, mas na quietude diária da abnegação por amor a Ele.

E certamente esta é a maneira para nos semearmos como trigo no chão ao mesmo tempo que Ele mede o mínimo ato de amor, não pela magnitude do ato em si, mas pela força do amor que o inspira. É espantoso como podemos nos formar rapidamente na escola do amor quando começamos a colocar em prática tudo o que sabemos.

Fonte

A única coisa que nos consola das nossas misérias é o divertimento, e contudo é a maior das nossas misérias. Porque é isto que nos impede principalmente de pensar em nós, e que nos faz perder insensivelmente. Sem isso, estaríamos no tédio, e este tédio nos levaria a procurar um meio mais sólido de sair dele. Mas o divertimento distrai-nos e faz-nos chegar insensivelmente à morte.

(Blaise Pascal)

Digamos que você esteja indo para o escritório para ver se seu patrão está lá. Vê o carro dele no estacionamento. Pergunta à secretária se ele está e ela responde: “Sim, acabei de falar com ele.” Você vê a luz na soleira da porta dele, ouve sua voz ao telefone. Com base em todas essas evidências, você tem boas razões para concluir que seu patrão está no escritório. Mas você poderia fazer algo bem diferente. Você poderia ir até a porta, bater e encontrar seu patrão face a face. Nesse altura, as evidências do carro no estacionamento, do testemunho da secretária, da luz debaixo da porta e da voz ao telefone – tudo isso ainda seria válido, mas assumiria um papel secundário, porque agora você encontrou o patrão face a face.
Da mesma maneira, quando nos encontramos com Deus, por assim dizer, face a face, todos os argumentos e as evidências a favor de Sua existência – embora ainda válidos – assumem um papel secundário. Eles agora se tornam ratificadores do que o próprio Deus nos mostrou, de modo sobrenatural, pelo testemunho do Espírito Santo em nosso coração.

(Willian Lane Craig)

O diabo pode citar as Escrituras para seus propósitos.

(William Shakespeare)

É um homem insensato aquele que é tão ocupado que não tem tempo para considerar o estado da sua própria casa e família. Mas, não menos tolo é aquele que passa o tempo todo pensando em outras coisas e nunca no estado de sua própria alma.

(John Owen)

Os meios que Deus usa para nos libertar do pecado não é nos tornando mais e mais fortes, mas sim nos fazendo cada vez mais fracos. Esse é certamente um caminho peculiar de vitória, você diz; porém esse é o caminho divino. Deus nos liberta do domínio do pecado, não fortalecendo nosso velho homem, mas crucificando-o; não o ajudando a fazer alguma coisa, mas sim removendo-o da campo de ação.

(Watchman Nee)

Oh, que Deus faça o inferno tão real para nós que não possamos descansar, o céu tão real que guiemos os homens até lá, Cristo tão real que nossos motivação e objetivo finais sejam que o Varão de Dores venha a ser o Homem de Gozo por meio da conversão de muitos para Ele.

(Hudson Taylor)

Para o piedoso, a eternidade é um dia que não tem ocaso; para o ímpio, é uma noite que não tem amanhecer.

(Thomas Watson)

Paz!

Um novo ano é sempre um bom momento para (re)começarmos a leitura da Bíblia. Sei dos imensos desafios que a vida moderna nos impõe até mesmo sobre nossas disciplinas espirituais: comunhão com o Senhor, oração, leitura devocional e estudo das Escrituras, meditação, etc. Mas devemos insistir, pedindo a graça e o poder do Senhor. Não há outro meio de sermos cristãos maduros e bem firmados na verdade sem um contato constante, sério, profundo e intencional com o Livro Antigo.

Coletei na internet algumas sugestões de planos de leitura da Bíblia. Estão no arquivo zipado que você encontra aqui. Escolha o que for mais adequado a você e use-o com dedicação.

Planos de leitura da Bíblia

O plano cronológico apresenta leitura dos livros da Bíblia, não na ordem em que se encontram, mas pela sequência dos fatos registrados.

O calendar_mccheyne apresenta o plano de leitura idealizado por Robert McCheyne, no qual há uma leitura individual e uma leitura em família. (É o que mais indico. Há alguns anos eu desenvolvi uma Bíblia que traz essas leituras para cada dia do ano. Chama-se Bíblia Devocional Robert McCheyne. Você a encontra em boas livrarias.) E há um plano adaptado, que exclui uma das leituras.

Há um plano para ler a Bíblia toda em três meses e um para ler apenas o Novo Testamento, Salmos e Provérbios. Há planos para novos convertidos, para crianças, em que os livros são lidos de modo alternado ou misturados. Há um plano que considera os meses tendo 25 dias, para que haja tempo para meditação e para repôr alguma leitura.

Há dois planos em formato de planilha, que permitem acompanhar seu progresso (é preciso habilitar as macros).

Desejo que o Senhor abençoe você a cada dia do novo ano por meio de Sua Palavra.

Divulgue para outros irmãos.

Abraço.

O post Leitura da Bíblia em 2016! apareceu primeiro em Campos de Boaz.

Poucas influências afetam mais o coração de um homem em seu relacionamento com Deus do que a de sua esposa, para melhor ou para pior. Ela incentivará ou impedirá sua devoção espiritual ao Senhor. Ela ampliará a sua paixão por Deus ou derramará um balde de água fria sobre ela. Que tipo de mulher estimula o crescimento espiritual de seu marido? Provérbios 31:10-31 fornece um perfil da mulher que é digna da confiança do seu marido. Esta mulher é a personificação da verdadeira sabedoria que vem de Deus, fazendo com que o marido tenha total confiança nela.

“Mulher virtuosa, quem a achará? O seu valor muito excede o de finas joias” (versículo 10). Uma mulher tão boa assim é difícil de encontrar. A palavra virtuosa (hayil) significa “força, capacidade, coragem e dignidade”. Esta mulher é um exemplo de cada uma dessas qualidades, tendo grande competência, caráter nobre e um forte compromisso com Deus e sua família. Só o Senhor pode proporcionar essa mulher virtuosa: “A casa e os bens vêm como herança dos pais; mas do SENHOR, a esposa prudente”. (Provérbios 19:14). “O que acha uma esposa acha o bem e alcançou a benevolência do SENHOR” (Provérbios 18:22). Essa mulher virtuosa é um presente inestimável de Deus.

Não é de se admirar que “o coração do seu marido confie nela” (versículo 11). O marido tem fé nela, porque “ela lhe faz bem e não mal, todos os dias da sua vida” (versículo 12). Ela traz suas muitas qualidades para o casamento; cada uma adapta-se exclusivamente para complementar as fraquezas dele. Os dons dela tornam-se imediatamente os ganhos dele, e ela tem tanto a oferecer que faz com que ele confie nela.

Seu Serviço

Em primeiro lugar, essa esposa extraordinária lhe serve incansavelmente. Sem ficar sentada de braços cruzados, ela “busca lã e linho” ativamente, então estende a “mão de bom grado” (versículo 13) para costurar e fazer material. Ela é “como um navio mercante” (versículo 14), lançando-se para encontrar o melhor tecido, com o melhor preço, a fim de fazer as melhores roupas. Esta mulher altruísta “ainda noite, já se levanta” (versículo 15) para preparar comida para sua família. Uma excelente gestora, ela supervisiona “suas servas”, enquanto servem ao seu lado, no cuidado da casa.

Seu Sucesso

Em segundo lugar, esta mulher empreendedora age com bom senso em suas muitas decisões. Ela “examina uma propriedade” com astúcia, e adquire-a. Lá, ela planta uma “vinha” (versículo 16). Por sua “forte” (versículo 17) determinação, ela ganha uma renda extra para a sua família. Esses ganhos são “rentáveis” (versículo 18), fornecendo recursos adicionais para compartilhar com os outros. Ela trabalha bem até a “noite” com seu “fuso” e “roca” (versículo 19) para fazer roupas para a sua família.

Seu Sacrifício

Em terceiro lugar, esta mulher diligente dá generosamente ao “aflito” e “necessitado” (versículo 20). Quando “a neve” se aproxima, ela também provê para a sua família. Ela planejou com antecedência, fazendo vestidos de “lã escarlate” (versículo 21) para sua família. Ela não poupa nenhum esforço ou custo para prover o melhor que pode. Depois de prover para outros, essa mulher trabalhadora faz “cobertas” e roupas “para si”, com “linho fino e púrpura” (versículo 22). Sua capacidade de dar roupas caras é uma prova clara do favor de Deus sobre o seu trabalho.

Sua Inteligência

Em quarto lugar, as suas muitas virtudes realçam a posição de seu marido nos “portões” (versículo 23), onde os líderes da cidade se encontram. Com a inteligência afiada, essa esposa virtuosa “faz”, “vende” e “dá” (v. 24) seus bens. Apesar de ser muito competente, ela não compete com a liderança de seu marido, mas a fortalece por sua humilde submissão—e todos sabem disso.

Sua Força

Em quinto lugar, essa esposa preciosa olha para o futuro com “força” e “dignidade” (versículo 25). Embora preveja muitos desafios, ela “sorri” (v. 25) com confiança no cuidado providencial do Senhor. Ela tem a expectativa de que a provisão dos céus suprirá todas as necessidades de sua família. Quando as pessoas procuram o seu conselho, ela fala palavras de “sabedoria” e “bondade” (versículo 26). Apesar de ocupada fora do seu lar, ela não negligencia a “sua casa” (versículo 27).

Sua Supremacia

Em sexto lugar, ela é uma mãe tão boa que, ao observarem sua excelência, seus filhos “lhe chamam ditosa” (versículo 28). Seu marido vê o seu caráter na criação dos filhos e “a louva”. Ele se gaba de que, entre as mulheres, “[ela] a todas sobrepuja” (versículo 29). Aos seus olhos, não há nenhuma que possa, legitimamente, ser igual a ela.

Sua Espiritualidade

Em sétimo lugar, a verdadeira grandeza dessa mulher é sua devoção espiritual. Ela “teme ao Senhor” (versículo 30). “Graça” e “formosura” apenas são “enganosas” e “vãs”. O que verdadeiramente atrai o seu marido é a sua reverência a Deus. Até os líderes da cidade “a louvam” nos “portões” (versículo 31), reconhecendo a integridade em sua vida. Seu marido valoriza sua fidelidade e diligência. Ele é o mais abençoado dos homens.

É de se admirar que o marido confie nela? A realidade de Deus em sua vida faz com que ela seja merecedora de sua total confiança. Em todas as estimativas, ela é “a coroa do seu marido” (Provérbios 12:4). Somente Deus pode dar uma excelente auxiliadora como essa.

O Senhor deu-lhe essa esposa excelente? Você vê como ela é feita especificamente para você? Você reconhece como ela tem contribuído para aumentar o seu relacionamento com o Senhor? Então, dê graças a Deus por essa esposa em quem o seu coração confia.

Fonte
Em caso de dúvidas, faça contato com a Editora Fiel.

O post Seu Coração Confia Nela (Steven J. Lawson) apareceu primeiro em Campos de Boaz.

Uma reflexão sobre 2 Reis 22:1-23:3

Deus separou para si um povo, Israel, a quem se revelou e essa revelação foi registrada/escriturada, revelação essa que damos o nome de especial, pois sem ela continuaríamos perdidos tateando ao nosso redor procurando encontrá-Lo, mas perdidos e corrompidos por conta de nossos pecados. Por meio de seu servo Moisés, Deus trouxe ao povo de Israel o livro da Lei, conhecido pelos judeus como a Torá, que compõe os cinco primeiros livros da Bíblia. Lá Deus deixou mandamentos e instruções sobre como viver bem e em harmonia com a vontade de Deus, revelando o Deus Criador e Sustentador de todas as coisas, o único Deus verdadeiro.

A ordem ao povo era dedicar-se a fé monoteísta revelada no Pentateuco, amar e servir a Deus de todo coração e alma, aplicando-se por guardar todos os mandamentos da Lei (Deuteronômio capítulo 6). Basicamente, o povo tinha que escolher entre a vida ou a morte, a benção ou a maldição que estava diante deles e dependia da obediência, fruto da Aliança com Deus (Dt 28 e 30).

Davi, conhecido com o rei segundo o coração de Deus, advertiu seu filho Salomão, que para a sucessão do trono ele deveria guardar todos os preceitos e mandamento de Deus, segundo a Lei de Moisés (1 Reis 2:3).

A situação de Josias era complicada, pois aos oito anos de idade ela herdara o trono debaixo de uma catástrofe. O reino de Judá (o remanescente de Israel) havia se afastado do Senhor durante os 57 anos de infeliz liderança de seu avô (Manassés) e pai (Amom). Além de abandonar ao Senhor, a nação estava imersa na idolatria, inclusive seu avô havia sacrificado seu filho como oferta aos deuses, além de outras práticas detestáveis a Deus como consultar os mortos, feitiçaria, homicídios e promoção da injustiça, provocando assim a ira de Deus e promovendo a corrupção moral de toda uma nação.

Porém o jovem Josias distinguiu-se dos seus antepassados por fazer aquilo que eles haviam abandonado, pois aos 16 anos de idade começou a buscar Deus (2 Cr 34:3, Buscar-me-eis e me achareis quando me buscares de todo coração Jr 29:13). A devoção de Josias a Deus se convertia em ações práticas, como o abandono da idolatria, o retorno as Escrituras e a renovação da Aliança entre Israel e o Senhor.

O retorno as Escrituras foi o grande responsável pelo avivamento espiritual da nação de Israel, sobre a liderança de seu rei Josias, muito parecido com a Reforma Protestante.

A Reforma Protestante, do século dezesseis, teve início no dia 31 de outubro de 1517, quando o monge agostiniano, Martinho Lutero, fixou nas portas da igreja de Wittenberg, na Alemanha, as 95 teses contra as indulgências, rompendo assim, com os desmandos do papado e com os desvios doutrinários da igreja.

Os reformadores buscavam uma volta da Igreja aos ensinos bíblicos, ao modelo de vida da igreja primitiva, descentralizado o poder das mãos de uma liderança eclesiástica corrupta e distante dos leigos, para uma experiência de fé pessoal e comunitária acessível a todos. Porém as ideias dos reformadores não foram bem aceitas pela Igreja Romana, excomungando e condenando o ensino daqueles que protestavam.

A reforma não foi uma inovação da igreja, mas uma volta às Escrituras. Seu propósito foi fazer uma correção de rota e seguir pelas mesmas pegadas trilhadas pelos apóstolos. A reforma colocou a igreja de volta nos trilhos da Verdade.

A verdade de que a Bíblia é a nossa única regra de fé e prática e devemos rejeitar decisivamente todas as doutrinas que não estiveram amparadas pelas Escrituras.
A verdade de que a salvação é pela fé e não pelas obras. Não somos salvos pelas obras que fazemos para Deus, mas pela obra que Cristo fez por nós na cruz.
A verdade de que somos salvos pela graça de Deus e não pelos méritos humanos.
A verdade de que Jesus Cristo é o único Mediador entre Deus e os homens, o único Salvador da igreja e o único Senhor do universo.
A verdade de que a Deus pertence o poder, honra e a glória, agora e pelos séculos eternos.

Podemos fazer três aplicações simples que nos ajudarão a desenvolver na fé, de maneira segura e correta.

• Não existe vida cristã sadia sem o conhecimento das Escrituras, por isso devemos nos aplicar a leitura e estudo da mesma como uma prática devocional diária.
• Todo conhecimento sobre a fé cristã que contrariar ou ultrapassar (ir além) o ensino das Escrituras deve ser rejeitado.
• Toda resistência à obediência às Escrituras deve ser combatida com oração e submissão do ‘eu’ a Deus.

Fonte: (http://pedpau.blogspot.com.br/2013_01_01_archive.html)

O post A reforma pela Palavra de Deus apareceu primeiro em Campos de Boaz.

As palavras, caro leitor, não são como as moedas, que têm para mim o mesmo valor que têm para os outros. Eu me lembro disso cada vez que deparo com frases corriqueiras ou surradíssimos lugares-comuns empregados com um sentido completamente diferente daquele que eu jurava ser o único possível. Numa dessas manhãs, ganhei meu dia ao encontrar uma dessas surpresas na tira do Hagar, o horrível, um dos meus personagens favoritos dos quadrinhos do jornal. Como viking que é, Hagar ganha a vida sitiando castelos e enfrentando inimigos tão aguerridos como ele. Na tira em questão, o sábio Dr. Zook sentencia, solenemente: “Violência gera violência!”. Hagar pensa um pouco no que acabou de ouvir e depois, com ar satisfeito, exclama: “É justo!”. Bingo! Hagar acabava de me mostrar que a tradicional mensagem pacifista podia ter uma interpretação diametralmente oposta daquela que parecia ser a única.  

Pois nesta semana, a expressão latina que Michel Temer escreveu na carta dirigida à presidente – verba volant, scripta manent – foi medida, cheirada e explicada em praticamente todos os jornais do país. Se é relativamente fácil descobrir o seu significado − uma tradução honesta desta frase seria “A palavra falada voa, a palavra escrita permanece”, ou, como quis um autor clássico, “as falas voam, os escritos ficam” −, é importante frisar que ela pode ter duas leituras também opostas.

Eu sempre tinha lido (e empregado) essa frase como um conselho para registrar as coisas por escrito, a fim de não perdê-las em algum desvão da memória. Para mim e para milhões de outras almas deste mundo −  incluindo, certamente, Michel Temer −, essa era uma advertência contra a volatilidade da palavra falada; não me passava pela cabeça a hipótese de que outros tantos milhões vissem nela um alerta contra o uso desta técnica tão perigosamente indiscreta.

Pois se Hagar me ensinou alguma coisa, agora foi a vez de Plutarco me surpreender: ao narrar a vida de Alexandre, conta que o grande conquistador censurou Aristóteles, seu mestre e tutor, quando soube que ele tinha decidido publicar seus tratados mais importantes: “Que vantagem terei sobre o resto dos homens, se as valiosas lições que tu me deste vão ficar ao alcance de todos?”. Cáspite! Então Alexandre não se importava com a transitoriedade do que Aristóteles falava, mas sim com a permanência do que ficaria escrito! Bingo, de novo! O que eu sempre tinha considerado uma virtude da escrita era, para ele, o seu maior perigo e desvantagem!

Prisioneiro da minha própria interpretação, que parecia óbvia, nunca tinha examinado essa frase com mais atenção. Fui consultar os dicionários especializados e − para minha vergonha! − vi que para muitos o verba volant é um conselho de discrição: sejam  circunspectos nas situações em que pode ser imprudente deixar uma prova material sobre algo que foi dito; e vocês, escritores, cuidado com o que publicam, pois os livros ficarão para sempre como testemunhas do seu talento −  ou da falta dele.

[Ilustração de Edu – ZH 19/12/2015]

Este artigo é baseado na palestra “Estrutura Física e Fragmentação – Quando e Porquê Desfragmentar Tabelas e Índices”, que apresentei aos colegas DBAs da empresa RAIZEN em março deste ano.

Introdução

Quando trabalhamos com bancos de dados, é importante entendermos os conceitos lógicos (como tabelas e registros) e os conceitos físicos (como alocação de disco, buffers de memória etc) envolvidos. Porém, nem sempre temos consciência da interação que acontece entre eles. E este entendimento é essencial para garantir a boa performance de um banco de dados.

Nesta primeira parte do artigo, eu apresento alguns detalhes das estruturas física e lógica de bancos de dados do SQL Server. Na segunda parte, mostrarei como estes conceitos influenciam a fragmentação de índices, um conhecido vilão que degrada performance das consultas.

Estruturas lógicas e físicas

Quando pensamos em dados armazenados em qualquer SGDB relacional, instintivamente pensamos em registros gravados em tabelas. Porém estes são conceitos lógicos e têm pouco a ver com a forma como estes dados estão gravados fisicamente.

A partir daqui precisamos detalhar as coisas e entender a interação entre aspectos lógicos e aspectos físicos do nosso banco.

Registros são associados a tabelas e o relacionamento entre as tabelas é que define o seu modelo lógico do banco de dados. Registros, tabelas e relacionamentos são provavelmente os conceitos lógicos mais conhecidos nos SGBDs relacionais. Mas vejamos a operação física envolvida na busca de registros de uma única tabela para entendermos os demais conceitos:

Figura 1: representação de conceitos físicos e lógicos para leitura da tabela Tabela2

Filegroup

Quando lemos dados da tabela Tabela2, o SGBD precisa primeiramente identificar o filegroup a que ela está associada. Este é um conceito lógico que informa onde serão gravados os dados de uma ou mais tabelas.

O filegroup do SQL Server é o conceito mais próximo que temos da ideia de tablespace, usada em outros SGBDs (DB2, ORACLE, POSTGRES, SYBASE, etc).

A diferença principal entre tablespaces e filegroups é que este último se associa apenas a arquivos de dados (os datafiles) e não a porções de memória (os bufferpools).

Na prática, não existe restrição para a quantidade de tabelas associadas a um mesmo filegroup. Podemos associar centenas de tabelas pequenas a um único filegroup. Em contrapartida, uma tabela muito grande que seja particionada terá ao menos um filegroup associado a cada partição.

Eu costumo implementar bases de dados com, no mínimo, dois filegroups: o default, PRIMARY, reservado para tabelas e um segundo filegroup reservado para índices.

Mas é preciso cuidado, porque a associação entre a tabela e o filegroup é permanente. Se for necessário mover a tabela para outro filegroup, terá que ser criada uma nova tabela e os dados movimentados entre a tabela velha e a nova.

Datafile

É um arquivo de dados associado a um filegroup. Um datafile pode conter dados de N tabelas, desde que todas elas estejam vinculadas ao mesmo filegroup. O administrador não tem controle sobre quais datafiles serão usados para armazenar os dados de uma tabela, pois isso é administrado pelo próprio SGBD.

Novos datafiles podem ser criados em um filegroup a qualquer momento, ou seja, sempre que o espaço livre nos datafiles passe o limite de segurança adotado (geralmente entre 80% e 90% de ocupação do datafile). E este novo datafile pode ser alocado em qualquer disco do servidor.

Já vi bases com todo tipo de estratégia de gerenciamento de datafiles: as que usam um datafile por filegroup e as que usam dezenas de datafiles por filegroup. Eu entendo que os dois extremos são problemáticos, porque um número muito grande de filegroups vai ser tão difícil de gerenciar quanto um número muito grande de datafiles.

Sempre que possível, é interessante manter as quantidades de filegroups e datafiles no menor número possível. Mas aí entramos em outro problema: qual o tamanho máximo recomendável para um datafile? Esta é realmente uma questão em aberto. Eu nunca encontrei documentação oficial da Microsoft recomendando o tamanho máximo de datafile para cada versão de SQL e/ou versão do Windows. Este número pode variar segundo vários fatores, por exemplo, o tamanho dos discos usados, tipo de dispositivo de storage, versão de sistema operacional etc.

Na empresa onde trabalho nós adotamos o limite arbitrário de 32GB por datafile. Como costumamos usar discos de 200 Gb ou mais, isso nos dá uma boa versatilidade para alocação de novas bases.

Disco

Na realidade, não há nenhum vínculo formal entre o SQL Server e os discos do seu servidor. Os discos em si podem ser usados para qualquer coisa, conforme sua conveniência. A vinculação dos discos com o SQL se restringe aos datafiles.

Claro que a escolha do tipo de disco usado influencia a boa operação do banco. Discos com alta capacidade de escrita são indicados para arquivos de log ou datafiles que recebem muitas transações, já que ambos os casos têm níveis altos de inserção de dados. Discos com alta capacidade de leitura devem ser usados para discos de índices ou dados de aplicações de BI, por exemplo.

Existe uma gama enorme de opções de discos disponíveis no mercado, com preços muito diferentes. Mas o dinheiro não é tudo nesta história. É muito importante conciliar as características do disco com as características do seu servidor e também dos tipos de arquivo que usarão estes discos.

Extensão

É a menor porção de disco que pode ser reservada pelo SQL Server, com tamanho fixo de 64 Kb. Cada vez que um datafile precisa crescer, o SQL Server verifica o tamanho do parâmetro “AUTOGROWTH” (número normalmente expresso em megabytes ou em percentual do tamanho do datafile). E em seguida calcula quantas extensões de 64 Kb serão reservadas no disco.

Extensões são chamadas de uniformes ou mistas, dependendo se estão vinculadas a uma ou mais tabelas.

Página de dados

A págian de dados é uma área de 8 Kb vinculada a uma tabela específica – um conjunto de 8 páginas forma 1 extensão. A página é onde de fato se armazenam os dados.

Cada página é reservada para uma única tabela e cada registro deve ser gravado obrigatoriamente dentro da mesma página. Essa é uma característica muito importante para entender os problemas de divisão de páginas (ou “page split”) e fragmentação, que serão discutidos ao longo destes artigos.

Observação 01: No caso de registros com campos LOB (varchar(8000), varchar(max), varbinary, etc), o armazenamento é um pouco diferente, mas não tratarei desta questão aqui, já que o assunto requer um artigo específico sobre tema.

O esquema abaixo foi apresentado num artigo de Paul Randall e mostra didaticamente como a página de dados é preenchida. Ela sempre tem um cabeçalho de 96 Bytes, a área de gravação de dados e o slot array, que é uma espécie de mapa.

Na prática, a área de gravação não é homogênea como se vê neste esquema. Os espaços ocupados por cada um dos registros não são necessariamente contínuos e se misturam os espaços ocupados por registros e os espaços livres. Quem informa exatamente em que posição física do disco se encontra determinado registro é o slot array (o tal mapa que eu havia mencionado).

Memória

Evidente que memória é um componente essencial para operação do SGBD, mas o gerenciamento da memória do SQL Server não reserva porções específicas para cada filegroup.

No SQL Server, gerenciamento de memória oferece ao DBA poucas opções de configuração. Isso costuma assustar profissionais habituados com SGBDs que rodam em UNIX, pois praticamente tudo em matéria de memória é gerenciado pelo próprio SGBD.

O gerenciamento de memória do SQL Server melhorou muito nos últimos 10 ou 15 anos, mas eu tenho a sensação que a própria Microsoft incentiva a postura do “instale o máximo de memória que puder e deixe o resto pro SGBD”.

Acredito que a maior novidade ocorrida em matéria de gerenciamento seja a opção da inclusão das “extensões de buffer” do SQL Server 2014. Ela permite que DBA apresente discos SSD como parte do cache do SGBD.

Escrevendo no disco

Como se sabe, quando executamos uma operação de INSERT, os registros não são gravados em disco logo depois do “COMMIT”. A operação passa por um longo caminho pelo Log de Transações até finalmente ser gravado no banco de dados (existem artigos muito bons sobre esta questão na própria MICROSOFT TECHNET).

Quando os registros forem gravados na página de dados, eles ocuparão a área clara do diagrama acima. Se acontecer de um ou mais registros não caberem nesta página de dados, será usada uma nova página da extensão em uso. Isso é conhecido como “page split” e quando acontece, é um processo natural dentro do banco, mas obviamente ele consome mais tempo que uma operação de escrita normal. Mas a situação piora quando a 8ª página da última extensão do datafile fica lotada.

Neste caso, o datafile não tem mais nenhum espaço reservado em disco. Então, antes que possa ocorrer o page split, o SQL Server tentará executar a operação de AUTOGROWTH (caso esta opção esteja habilitada), preparando a área de disco no tamanho especificado e organizando as extensões e páginas que couberem nesta área. É lógico que este processo todo é muito lento.

Só depois de todas estas operações que os dados são gravados na página de dados, garantindo de fato a “durabilidade” da transação (o “D” da sigla “ACID”).

Cenários mais nebulosos

Não é preciso ter muita imaginação para piorar muito este cenário de page split que requer crescimento do datafile.

Considere que sua transação com um único INSERT (vamos chamá-la de T1) disparou o page split. Imagine que uma segunda transação (T2) executou várias operações até que chegou num UPDATE que envolvia um registro armazenado na página de dados que estava sofrendo a divisão.

Como esta página de dados está bloqueada (“lock”) pela transação T1, a transação T2 e todos os locks que ela gerou permanecerão na fila aguardando o COMMIT da transação T1.

Quando acontece um cenário desses, é bastante provável que os usuários comecem a reclamar de lentidão no banco de dados.

Recomendações

Para evitar estas situações, existem diversas ações preventivas, mas eu acho importante destacar três delas:

1. Sobre a configuração do banco: verifique o nível de isolamento de transações que seja mais adequado para a sua aplicação; alguns isolamentos mais restritivos causam uma infinidade de bloqueios e isso afeta terrivelmente as operações concorrentes;
2. Sobre a programação do banco: evite transações muito longas; elas podem manter objetos bloqueados por muito tempo, causando enfileiramento de transações e, consequentemente, lentidão;
3. Sobre uso dos discos: a opção AUTOGROWTH é de extrema importância e merece mais atenção dos DBAs. Não basta ativá-la; é preciso estudar qual é o tamanho de crescimento de arquivos mais adequado para seu banco de dados.

A questão do tamanho de incremento dos arquivos no AUTOGROWTH muitas vezes é desprezada pelos DBAs, como se ela não fosse importante. Errado. Ela é essencial para boa operação do banco.

Como vimos, esta operação pode causar lentidão na operação e, portanto, deve-se minimizar o número de vezes que ela acontece a cada dia. Por outro lado, o tamanho deste incremento não pode ser grande demais, porque se não, esta operação vai tomar um tempo enorme quando ela acontecer.

Portanto é bom definir um incremento compatível com o nível de crescimento diário dos seus datafiles. Hoje em dia, muita gente usa incrementos de 100 Mb para o AUTOGROWTH de datafiles.

Observação: no caso de arquivos de log, a questão é diferente, porque o log pode crescer e decrescer muito rapidamente; por isso que tantos DBAs adotam incrementos percentuais para arquivos de log (por exemplo, 10%).

Até a próxima!

Leituras sugeridas

1. How Does SQL Server Store Data? por Brent Ozar
2. Understanding Pages and Extents por MICROSOFT TECHNET
3. Data Pages & Extents por TOADWORLD
4. Maximum Capacity Specifications for SQL Server por MSDN
5. Buffer Management por MICROSOFT TECHNET
6. Inside the Storage Engine: Anatomy of a page por Paul Randall
7. SQL Server: Understanding the Data Page Structure por Nelson John.
8. Data Pages in Buffer Pool  por Pinal Dave
9. SQL Server Transaction Log Architecture and Management por MICROSOFT TECHNET
10. What Is a Page Split, What Happens, Why Does It Happen, Why worry? por Tony Rogerson

Nos estudos de redes (Ethernet, Internet etc.), Spoofing, também conhecido como Spoof, é usado para descrever uma variedade de técnicas em que o hardware e software podem ser usados para ludibriar usuários desavisados. A utilização dessa técnica também tem como estratégia imitar outras pessoas, mimetizar websites etc., tudo isso para contornar medidas de segurança.

Explicando melhor: a comunicação via rede muitas vezes se baseia nos princípios de “hosts confiáveis”. Normalmente, esses computadores enviam informações entre si sem a necessidade de verificação constante da autenticidade entre eles. O Spoofing foi o método encontrado para furar os fracos sistemas de segurança que liberam a utilização de certos serviços a um número restrito e autenticado de usuários, que estão em uma “whitelist” para ele. O propósito do Spoof é o de falsificar o remetente dos pacotes de dados que viajam na rede.

Existem vários métodos de utilização do Spoofing:

IP spoofing

Este ataque consiste em mascarar, realizar o “spoof” de pacotes IP utilizando endereços de remetentes falsificados. Alguns sistemas de segurança possuem métodos que ajudam a identificar um usuário pelo seu endereço IP ou pelo range de endereços IP. O atacante realiza o “spoof” do endereço IP para coincidir com os critérios de verificação dos softwares de segurança, conseguindo dessa maneira ultrapassar as suas barreiras. Essa técnica também é usada para enganar páginas web, realizar sondagens ou até mesmo fazer com que outros recursos na Internet pensem que o usuário é alguém autorizado.

Existem 5 maneiras para conseguir se defender deste tipo de ataque:

1. Use autenticações baseadas em troca de chaves entre as máquinas em sua rede; algo como IPsec irá reduzir significativamente o risco de Spoofing;

2. Use uma lista de controle de acesso para negar acesso de endereços IP privados em sua interface de downstream;
3. Implemente a filtragem de tráfego tanto nas portas de entrada quanto de saída;
4. Configure os seus routers e switches, se eles suportarem esse tipo de configuração, para rejeitar pacotes que sejam originados fora de sua rede local, que supostamente estão com endereçamento de sua rede interna;
5. Ative sessões de criptografia no seu roteador para que hosts confiáveis ​​que estão fora da rede possam se comunicar de forma segura com seus hosts locais.

Spoof de Websites

Este ataque utiliza o layout de um site integro para mascarar um site malicioso, tudo isso para enganar os usuários a realizarem ações dentro desse site falso. Websites com Spoof comumente imitam sites de bancos, empresas de e-commerce ou serviços oficiais do governo, muitas vezes a fim de recolher, de forma fraudulenta, informações pessoais, financeiras ou confidenciais dos usuários. Cibercriminosos podem usar métodos extremamente sofisticados para enganar os usuários finais. Métodos como “cloaking” de URL ou encaminhamento de domínio podem esconder algumas pistas para que você verifique se o site é legítimo ou não. O “cloaking” de URL é o ato de esconder o verdadeiro domain name de um site a partir do campo de URL do navegador de um usuário em favor de outro nome.

A melhor solução para evitar esse tipo de fraude, por parte do cliente, é sempre verificar se o site possui SSL/TLS em sua página Web. A indicação HTTPS é um bom demonstrativo de que seu site faz uma transação segura de informações.

Os navegadores atuais indicam que um site é protegido por SSL/TLS, por um pequeno ícone de SSL-status, que fica localizado ou na área de status na parte inferior da página ou, dependendo do caso, ao lado da URL. No entanto, essa indicação não fica muito visível para os desavisados. Usuários ingênuos e desprovidos de conhecimento podem não notar sua ausência ao acessar um website (por exemplo, se você visitar esse site rotineiramente, como no caso do seu banco). Na verdade, quase todas as falsificações na Web estão em locais sem proteção SSL/TLS, mesmo em casos em que os atacantes utilizavam “domain names” que não aparecem relacionados com quaisquer marcas comerciais conhecidas.

Ao proteger todas as suas páginas, usuários irão notar rapidamente a mensagem de aviso em seu browser; quando o usuário recebe uma versão falsificada de uma página web, eles terão a noção de que o site não é seguro para o acesso.

ARP Spoofing

ARP (tradução literal seria Protocolo de Resolução de Endereço) opera transmitindo uma mensagem brodcast por meio de uma rede para determinar o endereço MAC de um host com um endereço IP pré-definido. O anfitrião do endereço IP de destino envia um pacote de resposta contendo o seu endereço MAC. Uma vez que a operação ARP inicial está completa, o dispositivo de origem em seguida armazena a resposta ARP, que é utilizada dentro do cabeçalho da camada de enlace de pacotes que são enviados para um endereço de IP específico.

Um ataque ARP Spoofing é o envio de mensagens ARP não solicitadas. Essas mensagens ARP maliciosas contêm o endereço IP de um recurso de rede, como um gateway padrão ou um servidor DNS e substitui o endereço MAC para o recurso de rede correspondente com seu próprio endereço MAC. Os dispositivos de rede, pelo projeto, substituem qualquer informação ARP existente em conjunto com o endereço IP pela nova informação ARP maliciosa. O atacante, em seguida, assume o papel do homem no meio (man-in-the-middle), conseguindo verificar qualquer tráfego destinado para o recurso legítimo enviado por meio do sistema de ataque. Como esse ataque ocorre nos níveis inferiores do modelo OSI (camada de enlace e rede), o usuário final é alheio à ocorrência do ataque.

ARP Spoofing também é capaz de executar ataques de Denial of Service (DoS). O sistema de ataque pode simplesmente soltar os pacotes, fazendo com que os clientes tenham suas requisições de serviço negadas para o recurso de rede atacada.

A defesa contra ARP Spoofing geralmente depende de alguma forma de certificação ou verificação cruzada das respostas ARP. Respostas ARP não certificadas serão bloqueadas.

Essas técnicas podem ser integradas com o servidor de DHCP para que ambos os endereços de IP dinâmicos e estáticos estejam certificados. Essa capacidade pode ser configurada em hosts individuais ou pode ser integrada em computadores Ethernet ou outros equipamentos de rede.

E-mail Spoofing

Este tipo de ataque é o processo de falsificar um remetente de um endereço de e-mail. Essa forma de Spoofing é utilizada para enganar o destinatário do e-mail a pensar que outra pessoa lhe enviou a mensagem. Isso é comumente usado para contornar os filtros de spam ou para enganar o usuário a pensar que o e-mail é seguro, quando na realidade contém um anexo que está infectado com um vírus ou spam.

Geralmente, para um atacante realizar um e-mail Spoofing, ele precisa de:

• Um serviço funcional de SMTP (Simple Mail Transfer Protocol) para enviar e-mail;
• Um software de e-mail.

Um caso recente de e-mail Spoofing foi reportado por uma analista de segurança chamada Yan Zhu. Ela identificou um bug no aplicativo do Gmail para sistemas Android, que permite que qualquer um envie “spoofed” e-mails. Ela realizou um teste enviando um e-mail como sendo da equipe do Gmail e, uma vez recebido, o endereço de e-mail poderia enganar o receptor a acreditar que o e-mail chegou de uma legítima equipe de segurança do Gmail, o que não era o caso.

Se você quiser se proteger contra spoofed e-mails, você pode seguir algumas dicas abaixo:

• Ligue seus filtros de spam: ​​quase todos os serviços de e-mail oferecem filtros de spam e caixas de lixo que direcionam e-mails falsos para o seu lixo eletrônico.
• Aprenda a ler cabeçalhos de mensagens de e-mail e endereços IP de rastreamento: rastrear a origem do spam é uma boa prática. Quando você receber um e-mail suspeito, abra o cabeçalho, veja se o endereço IP do remetente corresponde aos de e-mails anteriores da mesma pessoa.
• Nunca clique em links suspeitos ou baixe um anexo sem saber o seu propósito: sempre preste atenção para os e-mails que você recebe e evite clicar em links de e-mail ou download de anexos. Vá para o site oficial do seu banco ou outros sites diretamente do seu navegador e acesse a sua conta para encontrar o que eles querem que você veja.

Referências:

• http://hakipedia.com/index.php/ARP_Poisoning
• http://www.htmlgoodies.com/beyond/security/article.php/3473221/Identifying-Spoofed-Websites.html
• http://www.computerworld.com/article/2546050/network-security/the-top-five-ways-to-prevent-ip-spoofing.html
• http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-4/104_ip-spoofing.html
• http://searchsecurity.techtarget.com/definition/email-spoofing
• http://thehackernews.com/2015/11/gmail-spoofing.html

***

Artigo feito junto com Marcos Ferreira.

Se você é adepto do trabalho remoto é bem provável que boa parte da sua comunicação seja feita através de e-mail. Apesar da ascensão das mídias sociais e dos aplicativos de mensagens instantâneas que decretaram de forma prematura a morte do e-mail, ele continua sendo uma das principais ferramentas de informação e interação.

O Fast Company listou nove erros comuns em e-mails que podem fazer com que o receptor simplesmente ignore a sua mensagem. Confira quais são eles e atente para os detalhes que farão com que a comunicação ocorra da melhor forma.

1. Escrever sobre algo que deve ser tratado pessoalmente

Antes de começar a escrever, pare por alguns segundos. Se o assunto é complicado ou de grande teor emocional, o e-mail provavelmente não é a melhor forma para comunicar isso. Segundo William Schwalbe – autor de Send: Why People Email So Badly and How to Do It Better – o e-mail não traduz bem o tom e a inflexão das frases e a comunicação pode falhar.

2. Não preencher o campo “assunto” ou ser vago

Não dê a chance de alguém excluir seu e-mail antes de abrir a mensagem. Use o campo “assunto” para captar a atenção e ser claro sobre o teor do e-mail, recomenda Schawlbe. Se o conteúdo das mensagens for mudando durante a troca de e-mails, atualize a linha de assunto.

3. Copiar e responder muitas pessoas

Schwalbe diz que é legal estabelecer regras básicas sobre quem deve responder as mensagens. Uma dica é verificar em qual campo você está. Se você estiver na linha “Para”, sinta-se livre para responder, se estiver na linha “CC”, sua resposta provavelmente não é necessária. Só use o “responder a todos” se realmente todos os destinatários precisam ter ciência da sua resposta, o mesmo vale na hora de escrever uma mensagem e copiar todos os colegas de trabalho.

4. Não usar saudação

Se você é do tipo que vai direto para a mensagem, sem as sutilezas de um “oi” ou “bom dia”, pode estar dando o tom errado para a mensagem, diz Natalie Canavor, autora de Business Writing for Dummies. Você pode deixar a saudação de lado após o início da troca de mensagens, mas ela é importante na primeira abordagem.

5. Não revisar ortografia e gramática

Sim, isso realmente importa. Uma pesquisa entre os leitores da HubSpot Sidekick indica que 40% consideram erros de gramática o principal fator para gerar implicância com um e-mail ou frieza na resposta. Natalie diz que erros gramaticais e de pontuação são desrespeitosos, sem falar no risco da sua mensagem virar uma piada.

6. Não ser direto e objetivo

Schawlbe recomenda que o texto tenha entre um ou dois parágrafos, e que as informações mais importantes fiquem no início. Se for preciso se estender, estruture a mensagem em tópicos para facilitar a compreensão. E se ainda assim não for possível ser conciso, talvez o e-mail não seja a melhor forma para transmitir a mensagem.

7. Não definir o que você espera

Um dos últimos itens antes de encerrar o texto deve ser o seu pedido de ação ou resposta, diz Schawlbe. Se você está atribuindo responsabilidades ou pedindo para alguém agir, seja claro. Rodeios podem tornar o seu e-mail inútil.

8. Não ter uma linha de assinatura personalizada

Natalie sugere que devemos ter quatro ou cinco assinaturas de e-mail para escolhermos qual é a melhor em cada situação. Se você está enviando uma mensagem a um amigo pessoal, pode ser mais informal. Se precisa estabelecer credibilidade com alguém, use a versão que tenha mais credenciais. Verifique se as informações de contato estão de acordo com o que o destinatário precisa receber.

9. Fazer uma troca infinita de mensagens

Uma vez que a troca de e-mails passou de três ou quatro mensagens, é provável que a conversa não chegue a lugar algum. Tendo em vista que a ideia de marcar uma reunião pode surgir lá pela sétima mensagem, o melhor que você tem a fazer é se antecipar e resolver por telefone. Basta dizer “Hey, isso está ficando complexo, vou te ligar em 10 minutos”, simplifica Schawlbe.

* Publicado originalmente em Interualla.co

O post 9 erros comuns em e-mails corporativos apareceu primeiro em Adoro Home Office.

John Wesley pregou muitas vezes sobre o uso do dinheiro. Possuindo provavelmente o maior salário já recebido na Inglaterra, ele teve oportunidades de colocar suas idéias em prática. O que ele disse a respeito do dinheiro? E o que fez com o próprio dinheiro?

John Wesley experimentou uma pobreza opressiva quando criança. Seu pai, Samuel Wesley, era pastor anglicano numa das paróquias que pagavam os menores salários do país. Ele tinha nove filhos para sustentar e raramente ficava sem dívidas. Uma vez John viu seu pai sendo levado para a prisão dos devedores. Portanto, quando seguiu seu pai no ministério, não tinha ilusão alguma acerca das recompensas financeiras.
É provável que tenha sido uma surpresa para John Wesley que, embora Deus o houvesse chamado para mesma vocação de seu pai, não o havia chamado para ser tão pobre quanto ele. Em vez de ser pastor numa paróquia, John sentiu a direção de Deus para ensinar na Universidade de Oxford. Lá, ele foi escolhido para ser membro do conselho do Lincoln College. Sua posição lhe garantia pelo menos trinta libras por ano, mais do que o suficiente para um rapaz solteiro viver. John parecia desfrutar de sua relativa prosperidade. Gastou seu dinheiro em jogos de cartas, tabaco e conhaque.
Enquanto estava em Oxford, um incidente transformou sua perspectiva acerca do dinheiro. Ele havia acabado de comprar alguns quadros para colocar em seu quarto, quando uma das camareiras chegou à sua porta. Era um dia frio de inverno, e ele notou que ela não tinha nada para se proteger, exceto uma capa de linho. Ele enfiou a mão no bolso para dar-lhe algum dinheiro para comprar um casaco, mas percebeu que havia sobrado bem pouco. Imediatamente, ficou perplexo com o pensamento de que Deus não havia se agradado pela forma como havia gasto seu dinheiro. Ele perguntou a si mesmo: O mestre me dirá “Muito bem servo bom e fiel”? Tu adornaste as paredes com o dinheiro que poderia ter protegido essa pobre criatura do frio! Ó justiça! Ó misericórdia! Esses quadros não são o sangue dessa pobre empregada?

O que Wesley fez?

Talvez, como resultado desse incidente, em 1731, Wesley começou a limitar seus gastos para que pudesse ter mais dinheiro para dar aos pobres. Ele registrou que, em determinado ano, sua renda fora de 30 libras, suas despesas, 28, assim, tivera duas libras para dar. No ano seguinte, sua renda dobrou, mas ele continuou administrando seus gastos para viver com 28, desse modo, restaram-lhe 32 libras para dar aos pobres. No terceiro ano, sua renda saltou para 90 libras. Em vez de deixar suas despesas crescerem juntamente com sua renda, ele as manteve em 28 e doou 62 libras. No quarto ano, recebeu 120 libras. Do mesmo modo que antes, suas despesas se mantiveram em 28 libras e, assim, suas doações subiram para 92.
Wesley sentia que o crente não deveria simplesmente dar o dízimo, mas dar toda sua renda excedente, uma vez que já tivesse suprido a família e os credores. Ele cria que com o crescimento da renda, o que deveria aumentar não era o padrão de vida, mas sim o padrão de doações.
Essa prática começou em Oxford e continuou por toda a sua vida. Mesmo quando sua renda ultrapassou mil libras esterlinas, ele viveu de modo simples, doando rapidamente seu dinheiro excedente. Houve um ano em que seu salário superou 1400 libras. Ele viveu com 30 e doou aproximadamente 1400. Por não ter uma família para cuidar, não precisava poupar. Ele tinha medo de acumular tesouros na terra, portanto, seu dinheiro ia para as obras de caridade assim que chegava às suas mãos. Ele registrou que nunca permaneceu com 100 libras.
Wesley limitava suas despesas, não adquirindo coisas que eram tidas como essenciais para um homem de sua posição. Em 1776, os fiscais de impostos inspecionaram suas restituições e lhe escreveram a seguinte sentença: “Não temos dúvidas de que o senhor possui algumas baixelas de prata para cada item que o senhor não declarou até agora”. Eles queriam dizer que um homem proeminente como ele, certamente possuía alguns pratos de prata em sua casa, e o acusavam de sonegação. Wesley lhes respondeu: “Tenho duas colheres de prata em Londres e duas em Bristol. Essa é toda a prata que possuo no momento e não comprarei mais prata alguma, visto que muitos ao meu redor almejam por pão”.
A outra forma pela qual Wesley limitava seus gastos era identificando-se com os pobres. Ele pregava que os crentes deveriam se considerar como membros dos pobres, a quem Deus havia dado dinheiro para ajudá-los. Portanto, ele vivia e comia com os pobres. Sob a liderança de Wesley, a igreja Metodista de Londres estabeleceu dois abrigos para viúvas na cidade. Elas eram sustentadas pelas ofertas recolhidas nos encontros e nas celebrações da Ceia do Senhor. Em 1748, nove viúvas, uma mulher cega e duas crianças viviam ali. Juntamente com elas, vivia John Wesley e outro pregador metodista que se encontrava na cidade naquela ocasião. Wesley se alegrava em comer da mesma comida que elas, à mesma mesa, antevendo o banquete celestial que todos os crentes compartilharão.
Durante quatro anos, a dieta de Wesley consistia principalmente em batatas, em partes para melhorar sua saúde, mas também para economizar dinheiro. Ele dizia: “Aquilo que eu guardo para comprar carne pode alimentar alguém que não possui comida alguma”. Em 1744, Wesley escreveu: “Quando eu morrer, se eu deixar dez libras para trás… você e toda a humanidade poderão testemunhar contra mim, dizendo que tenho vivido e morrido como um ladrão e salteador”. Quando ele morreu em 1791, o único dinheiro que estava em sua posse eram algumas moedas, encontradas em seus bolsos e em sua gaveta de roupas.
O que havia acontecido ao restante do dinheiro que ele ganhara em toda a sua vida, uma quantia estimada em trinta mil libras?[i] Ele o havia doado. Como Wesley havia dito: “Não poderei evitar deixar meus livros para trás quando Deus me chamar, porém minhas próprias mãos executarão a doação de todas as demais coisas”.

O que Wesley Pregou?

O ensino de Wesley sobre o dinheiro oferece diretrizes simples e práticas para qualquer cristão.

A primeira regra de Wesley acerca do dinheiro era “Ganhe o máximo que puder”. Apesar de seu potencial para o mau uso, o dinheiro em si é algo bom. O bem que ele pode fazer é infinito: “Nas mãos dos filhos de Deus, ele é comida para os famintos, água para os sedentos, roupas para os que estão descobertos. Ele dá ao viajante e ao estrangeiro um lugar onde pousar a cabeça. Por meio dele, podemos manter a viúva, no lugar de seu marido, e aos órfãos, no lugar de seu pai. Podemos ser uma defesa para os oprimidos, levar saúde aos doentes e alívio aos que têm dor. Ele pode ser como olhos para o cego, como pés para o coxo e como o socorro para livrar alguém dos portões da morte”!
Wesley acrescenta que ao ganhar o máximo que podem, os crentes devem ser cuidadosos para não prejudicar sua própria alma, mente e corpo ou a alma, mente e corpo de quem quer seja. Desse modo, ele proibiu o ganho de dinheiro em empresas que poluem o meio ambiente ou causam danos aos trabalhadores.

A segunda regra de Wesley para o uso correto do dinheiro era “Poupe o máximo que puder”. Ele insistiu para que seus ouvintes não gastassem dinheiro somente para satisfazer a concupiscência da carne, a concupiscência dos olhos e a soberba da vida. Ele clamava contra comidas caras, roupas luxuosas e móveis elegantes. “Cortem todas essas despesas! Desprezem as iguarias e a variedade, e estejam contentes com o que a simples natureza requer”.
Wesley tinha duas razões para dizer aos crentes para comprarem somente o necessário. Uma era óbvia: para que não desperdiçassem dinheiro. A segunda era para que seus desejos não aumentassem. O antigo pregador destacou sabiamente que, quando as pessoas gastam dinheiro em coisas que, de fato, não precisam, elas começam a desejar mais coisas das quais não precisam. Em vez de satisfazerem aos seus desejos, elas apenas os fazem aumentar: “Quem dependeria de qualquer coisa para satisfazer esses desejos, se considerasse que satisfazê-los é o mesmo que fazê-los crescer? Nada é mais verdadeiro do que isto: A experiência diária demonstra que quanto mais os satisfazemos, mais eles aumentam”.
Wesley advertiu principalmente sobre a questão de comprarmos muitas coisas para os filhos. Pessoas que raramente gastam dinheiro consigo mesmas podem ser bem mais indulgentes com seus filhos. Ao ensinar o princípio de que gratificar um desejo desnecessariamente tende a intensificá-lo, ele perguntou a esses pais bem-intencionados: “Por que você compraria para eles mais orgulho ou cobiça, mais vaidade, tolice e desejos prejudiciais? …Por que você teria um gasto extra apenas para trazer-lhes mais tentações e ciladas, e para transpassá-los com mais tristezas”.

A terceira regra de John Wesley era “Doe o máximo que puder”. A oferta de uma pessoa deve começar com o dízimo. Ele disse àqueles que não dizimavam: “Não há dúvidas de que vocês têm colocado o seu coração no seu ouro”. E advertia: “Isso ‘consumirá sua carne como o fogo’”! Entretanto, a oferta de uma pessoa não deve se limitar ao dízimo. Todo o dinheiro dos crentes pertence a Deus, não apenas a décima parte. Os crentes devem usar 100% de sua renda da forma como Deus direcionar.

E como Deus direciona os crentes a usarem sua renda? Wesley listou quatro prioridades bíblicas:

1. Providencie o que é necessário para você e sua família (1 Tm 5.8). O crente deve estar certo de que sua família possui suas necessidades e comodidades supridas, ou seja, “quantidade suficiente de uma comida modesta e saudável para comer, e roupas adequadas para vestir”. O crente também deve garantir que a família tenha o suficiente para viver caso haja imprevistos em relação ao seu ganha-pão.
2. “Tendo sustento e com que nos vestir, estejamos contentes” (1 Tm 6.8). Wesley acrescentou que a palavra traduzida para “vestir” é literalmente “cobrir”, o que inclui tanto moradia como roupas. “Conclui-se claramente que tudo o que tivermos além dessas coisas, no sentido empregado pelos apóstolos, é riqueza – tudo quanto estiver além das necessidades, ou no máximo, além das comodidades da vida. Qualquer um que tenha comida suficiente para comer, roupas para vestir, um lugar onde repousar a cabeça, e mais alguma outra coisa, é rico”.
3. Providencie o necessário para “fazer o bem perante todos os homens” (Rm 12.17) e não fique devendo nada a ninguém (Rm 13.8). Wesley disse que a reivindicação pelo dinheiro do crente que se seguia à família era a reivindicação dos credores. Ele acrescentou que aqueles que dirigiam o próprio negócio deveriam ter ferramentas adequadas, estoque ou o capital necessário para manter seu negócio.
4. “Por isso, enquanto tivermos oportunidade, façamos o bem a todos, mas principalmente aos da família da fé” (Gl 6.10). Após o crente ter provido o necessário para a família, credores e para o próprio negócio, sua próxima obrigação é utilizar todo o dinheiro que sobrou para suprir as necessidades dos outros.

Ao dar esses quatro princípios bíblicos, Wesley reconheceu que algumas situações não são assim tão claras. A forma como os crentes devem usar o dinheiro de Deus nem sempre é óbvia. Por essa razão, ele ofereceu quatro perguntas para ajudar seus ouvintes a decidirem como gastar seu dinheiro:

1. Ao gastar o dinheiro, estou agindo como se o possuísse ou como se fosse o curador de Deus?
2. O que as Escrituras exigem de mim ao gastar o dinheiro dessa maneira?
3. Posso oferecer essa compra como um sacrifício a Deus?
4. Deus me recompensará por esse gasto na ressurreição dos justos?

Finalmente, para um crente que ainda estivesse perplexo, John Wesley sugeriu a seguinte oração antes de realizar uma compra:

“Senhor, tu vês que estou para gastar esta quantia naquela comida, naquela roupa ou naquele móvel. Tu sabes que estou agindo com sinceridade nessa questão; como um mordomo de teus bens; gastando uma porção dele desta maneira, em conformidade com o desígnio que tu tens ao confiá-los a mim. Sabes que faço isso em obediência à tua Palavra, conforme tu ordenas e porque tu o ordenas. Peço-te que isso seja um sacrifício santo e aceitável a Ti, por meio de Jesus Cristo! Dá-me testemunho em mim mesmo de que, por meio desse esforço de amor, serei recompensado quando Tu recompensares a cada homem segundo as suas obras”.

Ele estava confiante que qualquer crente de consciência limpa que fizesse essa oração usaria o seu dinheiro com sabedoria.

[i] Essa quantia equivaleria a aproximadamente 30 milhões de dólares hoje.

Traduzido por: Waléria Coicev
Copyright© Charles Edward White
©Editora Fiel
Traduzido do original em inglês: What Welsley practiced and preached about Money?
O leitor tem permissão para divulgar e distribuir esse texto, desde que não altere seu formato, conteúdo e / ou tradução e que informe os créditos tanto de autoria, como de tradução e copyright. Em caso de dúvidas, faça contato com a Editora Fiel.

O post O que Wesley praticou e pregou sobre o dinheiro? (Charles Edward White) apareceu primeiro em Campos de Boaz.

Naturalmente, novas tecnologias e tendências, como redes definidas por software, Internet das Coisas e nuvem, costumam chamar bastante atenção, o que inclui a abordagem à segurança. No entanto, é importante não esquecer nunca que no centro de tudo isso ainda está a rede empresarial.

E, conforme evidenciado pela avalanche em constante expansão das violações de dados que poderiam ter sido prevenidas ou cujo impacto poderia ter sido reduzido pela aplicação de práticas básicas recomendadas para a segurança da rede, fica óbvia a necessidade de dar prioridade a tais práticas. Por isso, apresentamos a seguir uma recapitulação das regras básicas, porém essenciais, do que fazer ou não fazer para obter uma rede realmente segura.

SEMPRE: padronize sua infraestrutura de rede

Uma infraestrutura de rede não padronizada pode aumentar bastante a complexidade de seu monitoramento e gerenciamento, especialmente em relação à segurança. Normalmente, os departamentos de TI usam modelos para implantar configurações. Assim, eles costumam começar com alguma padronização, mas a entropia entra rapidamente em ação e os desvios da configuração logo dificultam o reconhecimento do modelo original. Além disso, novas iniciativas e políticas nem sempre são implantadas de forma consistente, especialmente em ambientes heterogêneos, em que os fornecedores implementam funcionalidades de maneiras diferentes. A padronização torna muito mais fácil contar com processos eficientes para atualizar a infraestrutura de maneira rápida e fácil, e garantir que todos os dispositivos estejam de acordo com a política. Isso ajuda a minimizar o risco de um ataque simples com estratégias de defesa conhecidas, que poderia ser bem-sucedido sem a capacidade de garantir uma configuração correta, devido à falta de padronização.

SEMPRE: tenha um processo claro de controle de alterações

Um processo de controle de alterações claramente definido, que inclua restrições e inspeções simples para detectar quando as alterações não seguem o processo e como reagir nesses cenários, é de suma importância. Isso ajuda os administradores a garantir que as mudanças sejam feitas sob a supervisão de uma aprovação de alterações. Também permite o rastreamento em tempo real de alterações não autorizadas. Isso é importante porque tais alterações têm um efeito na rede como um todo em termos de segurança, planejamento de capacidade, custo de previsão, avaliações do risco do negócio e muito mais.

SEMPRE: implemente a conscientização quanto à conformidade

A conformidade não se restringe aos setores de saúde e finanças. Sim, esses setores são os mais conhecidos por acatarem regulamentações de conformidade externas, mas não pense na conformidade apenas como um requisito externo. Mesmo que uma empresa opere sem regulamentações externas, ainda é recomendável desenvolver políticas internas para ajudar a esclarecer o que é importante e garantir que todas as medidas corretas sejam tomadas nesse sentido. Em outras palavras: agir de forma intencional, e não improvisada, com relação à segurança. Esse deve ser um processo contínuo e ajustado à medida que surgem novas implementações e políticas.

NUNCA: opere com a mentalidade “não mexer em time que está ganhando”

O velho ditado “em time que ganha não se mexe” nunca deve se aplicar quando se trata da segurança da rede. Operar com essa mentalidade fez com que inúmeras vulnerabilidades fossem reveladas após a violação. Em vez disso, os administradores devem fazer um inventário de sua rede com regularidade, o que revelará vulnerabilidades a tempo de serem solucionadas antes que ocorram violações. Como parte desse processo, é importante não negligenciar o inventário dos dispositivos de rede cujos prazos de fim de vida útil ou encerramento do suporte estejam vencidos ou por vencer.

NUNCA: use tecnologia ultrapassada

Isso pode parecer óbvio, mas usar tecnologias de segurança ultrapassadas, protocolos inseguros ou firmwares de dispositivos desatualizados é uma prática muito comum. Por exemplo, o Telnet ainda é usado regularmente em redes corporativas, apesar de estar bastante ultrapassado. Negligenciar a atualização de tecnologias de segurança e do firmware de dispositivos é uma maneira infalível de abrir as portas para um ataque.

NUNCA: ignore seus dispositivos pessoais

O uso de dispositivos pessoais (BYOD) não é mais considerado um privilégio – os usuários finais em praticamente todas as organizações, independentemente de porte ou setor, esperam poder conectar dispositivos pessoais às redes corporativas. Com a inclusão desses novos dispositivos que se conectam às redes, as preocupações com a segurança da rede mais do que duplicam. Para lidar com isso, os engenheiros precisam rastrear e gerenciar endereços IP, bem como monitorar os recursos acessados por tais dispositivos. Isso garantirá que os aplicativos das organizações apresentem um desempenho correto, ao mesmo tempo em que alertará quanto a anomalias potenciais que poderiam indicar uma violação de dados ou ataque.

É importante não negligenciar essas noções básicas da proteção de redes corporativas, o que torna imperativa uma revisão ocasional das regras do que fazer ou não fazer. Seguindo as regras descritas aqui, os administradores de rede podem garantir que suas redes estão protegidas.

I was idly wondering what was taking pg_dump so long and noticed that it always seemed to be pegged at 100% CPU usage on the client. That was surprising because naively one might think that the bottleneck are the server’s or the client’s disk or the network. Profiling quickly revealed that the compression library zlib was taking most of the run time on the client. And indeed, turning compression off caused pg_dump to fly without getting anywhere near 100% CPU.

When using the custom output format in pg_dump (-Fc), the output is automatically compressed, using the same default level that gzip uses. By using the option -Z, one can select a compression level between 0 (off) and 9 (highest). Although it is not documented, the default corresponds to level 6.

Some simple testing has shown that lowering the level from 6 to 1 can speed up the dump run time by a factor of 3 or more while only increasing the output size by 10%. Even the levels in between give significant speed increases with only minimal differences in output size. On the other hand, increasing the compression level to 9 only decreases the output size by about 1% while causing slow downs by a factor of 2. (In this test, level 1 was about twice as slow as no compression, but the output size was about 40% of the uncompressed size. So using at least some compression was still desirable.)

I encourage experimentation with these numbers. I might actually default my scripts to -Z1 in the future.

A lot of DBAs are quite adamant regarding ACID compliance. I count myself among them. But unlike the other parts of the acronym, there are times when data durability isn’t actually a high priority. Data staging holding areas, temporary tables that need visibility across sessions, and other transient information do not require zealous protection. As a DBA it feels weird saying it, but there’s just some data we simply don’t care about losing.

Which is why all versions of Postgres after 9.1 include the ability to create unlogged tables. Aside from not needing data durability, why even bother with such a feature? Believe it or not, enforcing durability comes with a lot of overhead. There’s a whole array of mechanisms that strive to guarantee committed transactions are permanent.

One of these, the write ahead log (WAL), is also part of the replication system. Due to their importance, WAL files are often archived as part of standard recovery procedure. That means there are potentially three redundancy levels for every table in our database! That is a vast amount of unnecessary disk writing and network activity for ultimately ephemeral data. Durability is great, except when it isn’t.

Here’s a quick demonstration at how these excess resources translate to time consumption:

\timing
 
CREATE TABLE regular_table AS
SELECT * FROM generate_series(1, 5000000);
 
TIME: 7423.529 ms
 
CREATE UNLOGGED TABLE unlogged_table AS
SELECT * FROM generate_series(1, 5000000);
 
TIME: 2843.311 ms

These timings varied somewhat, but the trend persisted through several iterations. This was on a test Postgres instance with one replica and no WAL archival. This means a production system utilizing WAL archival would potentially produce an even larger divergence. Taking the ‘D’ out of ACID has some very real performance benefits.

Of course, these advantages come with a gargantuan fire-breathing caveat. Let’s simulate a Postgres crash:

pkill -9 postmaster
pg_ctlcluster 9.4 main start

And then examine the aftermath:

SELECT COUNT(1) FROM regular_table;
 
  COUNT  
---------
 5000000
 
SELECT COUNT(1) FROM unlogged_table;
 
 COUNT 
-------
     0

Oh. Well, then. Because unlogged tables are not durable, they can’t be recovered. Following any unexpected shutdown, Postgres will truncate any unlogged tables upon the next startup. In addition, since unlogged tables are not part of the WAL system at all, they’re not streamed to any existing replicas. Replicas retain the table structure itself, but they remain entirely unusable.

This is what our clone has to say about the situation:

SELECT * FROM unlogged_table;
 
ERROR:  cannot access TEMPORARY OR unlogged relations during recovery

Given these constraints, unlogged tables are only useful on the primary server for transient data. This makes them great for use cases we mentioned earlier: data staging areas, persistent temp tables, raw COPY targets, etc. Used judiciously, they can greatly accelerate an ETL stack or multiple-step data import process.

They’re also good for application stacks that require data flushing. Certain types of queues leverage notifications or live messaging, neither of which want stale data. Some applications bootstrap one or more tables from a tertiary data source upon starting. Web apps could even store local session data in an unlogged Postgres table on each host, pending aggregation on a reporting server. There are many forms of application where phantom data is exactly what we want.

Unfortunately the psql Postgres command-line tool hasn’t gotten the postcard. None of the descriptive formats for tables reveal whether or not they’re unlogged. Neither does the pg_tables catalog view that lists all known postgres tables. It’s currently impossible to distinguish a regular table from an unlogged one without performing some forensics.

The pg_class catalog table has what we need:

SELECT relname, relpersistence
  FROM pg_class
 WHERE relname LIKE '%_table';
 
     relname      | relpersistence 
------------------+----------------
 regular_table    | p
 unlogged_table   | u

This is something of a large oversight, considering the potential impact of utilizing an unlogged table in undesirable scenarios. For now, we recommend integrating some kind of unlogged decorator into your chosen naming scheme to ensure unlogged tables are never used for anything but transient data.

In the end, the primary difference between Postgres and a strictly ACID database, is that Postgres actively facilitates circumventing unnecessary durability overhead. But it does so safely, limiting the effect to tables specifically created for that purpose. Why pay for solid reality, when all you want is smoke and mirrors?