Este artigo foi escrito por telles

Comparar dois produtos com longa história e com comunidades vibrantes é sempre complicado. Quando publiquei minha comparação entre Oracle e PostgreSQL em 2007, muitos comentários de pessoas que não conheciam Oracle ou PostgreSQL surgiram. Uns dizendo que o Oracle não fazia isso ou aquilo e na verdade faz e o inverso também. Por isso me dei ao trabalho de falar sobre as semelhanças primeiro.

O que eu achei interessante relendo os artigos de 2007 é que a lista de hoje deverá se renovar bastante, pois muitas coisas que eu sentia falta naquele tempo foram implementadas no PostgreSQL e outras eu não considero mais tão importantes atualmente. Então teremos uma lista bem diferente agora, vamos à ela:

• Parallel Query: O Oracle RAC é uma tecnologia que avançou muito nos últimos anos mas realmente está longe de ser uma solução definitiva para performance ou alta disponibilidade. Não garante performance quando o gargalo é I/O, que é o maior problema dos bancos de dados, particularmente escrita em I/O. Bons discos flash ajudam muito mais. Não resolvem o problema de alta disponibilidade se seus discos corromperem, um standby resolve melhor essa questão. Mas se você tem um Datawarehouse ou consultas monstruosas em tabelas gigantes, a possibilidade de quebrar uma única consulta em vários processos é uma boa. A Oracle faz isso há muito tempo e faz bem. O PostgreSQL lançou recentemente a versão 9.4 com a infraestrutura para fazer a mesma coisa. É esperado que na próxima versão essa funcionalidade esteja presente. Eu diria que em 2 anos isto deverá estar maduro no postgres.
• Multitenant Architecture: Já faz muito tempo que o PostgreSQL trabalha com várias bases sob o mesmo cluster, dividindo um catálogo global, processos, etc. Também sempre foi uma questão de segundos criar uma nova base. Mas de fato, se você tem varias bases num cluster,  migrar apenas uma base para um outro servidor é isso uma tarefa um pouco complexa. A versão 12c da Oracle tem se esforçado tornar este tipo de tarefa mais simples e tornar a convivência na nuvem mais simples.
• Exadata: Mesmo antes da Oracle comprar a Sun, já havia sido lançada a primeira versão do Exadata. O Exadata, além de ser uma forma de empacotar hardware, sistema operacional e banco de dados numa caixa preta, é possui também algumas integrações entre storage em banco de dados muito interessantes que aceleram muito algumas operações. Este nível casamento entre hardware e software provavelmente não será visto no PostgreSQL tão cedo.
• Ferramentas gráficas: O Enterprise Manager até a versão 10g era um problema. Muitas vezes o maior ofensor da base era justamente ele. Mas parece que aos poucos foram melhorando ele. Ainda acho ele bem pesado, mas é uma ferramenta que permite uma visão rápida sobre muitos aspectos do Oracle. O PostgreSQL não possui nenhuma ferramenta gráfica nativa, mas possui alguns projetos livres, notadamente o PGAdmin3 e o PGphpadmin. Assim como no caso do Oracle, algumas das melhores ferramentas são pagas.
• Assistentes de performance: Para um DBA júnior, os assistentes realmente são uma mão na roda e apontam problemas críticos sem muito esforço. Claro que existem erros e um DBA experiente deve saber quando não confiar nesse tipo de coisa, mas de fato ajuda muito numa avaliação inicial.
• Particionamento: O particionamento de tabelas continua sendo um ponto forte do Oracle. Possui inúmeras funcionalidades avançadas e é bem robusto. Já escrevi extensivamente sobre particionamento no PostgreSQL aqui. Muita coisa foi melhorando no PostgreSQL nas últimas versões, mas ainda está longe do Oracle.
• Flashback Query: Levanta a mão quem nunca quis saber o que tinha numa tabela antes de rodarem um UPDATE desastroso… Voltar a base toda para trás no tempo com um Point In Time Recovery pode não ser a melhor solução. O Flashback já me ajudou algumas vezes nesses casos, funciona bem e é bem simples de usar. Só não pode demorar demais, senão os dados somem do UNDO.
• Transações dentro de um PL: Isso é uma coisa que me chateia ainda em alguns momentos. Eu sei que pode não ser elegante dar um COMMIT ou ROLLBACK dentro de um PL. Eu sei que trabalhando bem com EXCEPTIONs muito desse problema pode ser minimizado, mas se eu quero criar um processo em lote com milhões de transações, eu quero poder dar um COMMIT de x em x registros processados e tenho que construir uma aplicação externa só para isso. Acho que isso o PostgreSQL nunca vai mexer. Só não confundam isso com a aberração do Autonomous Transaction, que é algo que a Oracle jamais deveria ter inventado.
• Recovery Manager (RMAN): Eu realmente não iria colocar este item aqui, mas sei que vai aparecer nos comentários depois, então vou me adiantar logo. O RMAN é um item obrigatório para quem usa ASM, que é uma forma de RAW Devices mais sofisticada da Oracle. Eu realmente não sou fã de forma alguma do ASM, nem do RMAN. Gosto de ver meus datafiles no sistema de arquivos e poder lidar diretamente com eles. Engana-se quem acha que com RMAN e ASM coisas ruins não vão acontecer. Vão sim e eu tenho boas histórias de terror para contar. O ganho de performance de 5% a 20% não justifica para mim perder completamente o controle da base. Claro que para quem usa RAC, o ASM se tornou praticamente obrigatório. Veja que o PostgreSQL tem uma arquitetura completamente diferente da Oracle em relação aos seus datafiles, que é muito mais simples e eficiente. Isso significa que varias limitações do Oracle em relação à sua arquitetura simplesmente não existem no PostgreSQL. Para quem bradar pela falta do backup incrementar no PostgreSQL, saiba que o clone do RMAN, o pg_rman, já existe faz tempo. Mas assim como o backup incremental, conheço poucas pessoas realmente usam o pg_rman. Mas quem faz backup utilizando o rsync no PostgreSQL sabe que a vida pode ser muito mais simples. E você pode utilizar o pg_basebackup que é bem simples e funciona de forma bem tranquila. O que não existe é uma integração nativa com ferramentas de backup em fita. Isto realmente falta. E por último, vale lembrar que quem faz backup de bases com vários terabytes sem snapshot via storage, perdeu o bonde da história.

O artigo Oracle X PostgreSQL – Parte II: Vantagens do Oracle apareceu primeiro em Savepoint.

O Git é um sistema de controle de versão. Com o Git você não perderá seu trabalho, vai poder voltar para a versões anteriores, recuperando a versão do seu código de antes de ter cometido o erro e poderá criar e trabalhar diversas versões em paralelo.

Uma ótima leitura que indico é o livro Pro Git, escrito por Scott Chacon. Ele descreve corretamente sobre o controle de versão. Olhe só:

O que é controle de versão, e por que você deve se importar?

“O controle de versão é um sistema que registra as mudanças feitas em um arquivo ou um conjunto de arquivos ao longo do tempo, de forma que você possa recuperar versões específicas.

Se quer manter todas as versões de uma imagem ou layout, usar um Sistema de Controle de Versão (Version Control System ou VCS) é uma decisão sábia. Ele permite reverter arquivos e projetos inteiros para um estado anterior, compara mudanças feitas ao decorrer do tempo, vê quem foi o último a modificar algo que pode estar causando problemas, quem introduziu um bug e quando, e muito mais. Usar um VCS normalmente significa que caso tenha estragado ou perdido algum arquivo, poderá facilmente reavê-los. Além disso, você pode controlar tudo sem maiores esforços.”

Vamos lá!

Bom, depois dessa aula com Scott Chacon, vamos ver alguns códigos!

Lembrando que todos os comandos aqui devem ser feitos pelo Terminal, Console, GitBash, entre outros e o não recomendado Prompt de Comando do Windows, incluindo entradas e saídas de pastas, tudo por comandos!

Iniciando o Git

Entre no diretório que deseja controlar a versão e inicie o Git assim:

git init

Feito isso, seus arquivos ainda não estão sendo versionados, mas eles estão esperando para serem adicionados no estágio de controle. Para fazer isso digite o comando

git add nome-do-arquivo-incluindo-extensão

Se você precisa adicionar todos os arquivos do diretório, basta digitar:

git add .

Saber o status do projeto é importante. Com o comando abaixo você consegue ver quais arquivos estão fora do controle, quais foram modificados e estão esperando por uma descrição de modificação etc:

git status

Voltando ao estágio anterior do adicionamento:

git reset HEAD nome-do-arquivo

Commit – Comitando:

git commit -m "Mensagem do commit"

Adicionando e comitando ao mesmo tempo:

git commit -a -m "Mensagem do commit"

Voltando commits a versões anteriores

Voltar um commit:

git reset HEAD~1

Voltar dois commits:

git reset HEAD~2

Voltando um commit e deixando o arquivo no estagio anterior:

git reset HEAD~1 --soft

Voltando um commit e excluindo o arquivo, deixando no estágio anterior:

git reset HEAD~1 --hard

Verificando o histórico de commits:

git log

Verificando o que foi mudado, diferença entre um arquivo e outro:

git log -p

Verificando os 2 últimos commits:

git log -p -2

Mostrando as estatísticas de todos os commits:

git log --stat

Mostrando todos os commits, cada um em uma linha:

git log --pretty=oneline

Mostrando todos os commits dos últimos 2 dias até o momento atual

git log --since=2.days

Criando um branch – uma ramificação

git checkout -b nome-do-branch

Verificando em que branch você está

git branch

Voltando para o branch master

git checkout master

Jogando o branch criado no branch master

Entre como branch master:

git merge nome-do-branch-que-foi-criado

Grudando o branch criado no branch master sem o commit

Somente localmente – localhost, entre como branch master:

git rebase nome-do-branch-que-foi-criado

Removendo um branch:

git branch -D nome-do-branch

Vendo branchs remotos:

git branch -a

Mostrando o início do hash, quem comitou, quanto tempo atrás, mensagem: descrição do commit:

git log --pretty=format: "%h - %an, %ar : %s"

Deletando arquivos:

git rm nome-do-arquivo

Deletando todos os aquivos removidos ao mesmo tempo:

git ls-files --deleted | xargs git rm

Ignorando arquivos

Existem alguns arquivos que muito provavelmente você não vai precisar versionar, como por exemplo os arquivos de cache do SASS, arquivos de configuração e etc. Nesse caso você precisa fazer com que o controle de versão ignore estes arquivos. Para tanto, crie um arquivo chamado .gitignore. Feito isso, dentro deste arquivo, digite o nome ou o endereço das pastas que você quer ignorar. Um exemplo:

# See http://help.github.com/ignore-files/ for more about ignoring files.
#
# If you find yourself ignoring temporary files generated by your text editor
# or operating system, you probably want to add a global ignore instead:
# git config --global core.excludesfile ~/.gitignore_global

# Ignore bundler config
/.bundle

# Ignore the build directory
/build

# Ignore Sass' cache
/.sass-cache

# Ignore .DS_store file
.DS_Store
.cache
.rvmrc

vendor/*

.DS_Store

# Vim
*.swp
*.swo

Gemfile.lock
.vagrant
Vagrantfile

# rbenv
.ruby-version

# Ignore deploy related files
deploy

Gemfile.lock

O arquivo .gitignore fica na raiz do projeto.

Clonando e puxando alterações de projetos

Clonando um projeto remoto:

git clone url-do-projeto

Fazendo um clone de outros branchs:

git checkout -b nome-do-branch origin/ nome-do-branch

Trazendo, puxando as alterações feitas por outros usuários:

git pull origin master

Sincronizando tudo que está no repositório remoto:

git pull

Enviando o(s) projeto(s), arquivo(s) para o repositório:

git push origin master

Enviando um branch para o repositório:

git push origin nome-do-branch

Tags

As tags servem para marcar uma etapa. Imagine que você vai lançar uma versão, que resolve uma série de problemas. Você pode marcar aquela etapa criando uma tag. Assim fica simples de fazer qualquer rollback do projeto para uma tag específica em vez de voltar para um commit. Você sabe que tudo o que foi feito até aquela tag está funcionando.

Criando tags:

git tag versão-da-tag

Listando tags:

git tag -l

Enviando a tag para o repositório

git push origin master --tags

Removendo as tags criadas localmente:

git tag -d versão-da-tag

Removendo tag no repositório remoto:

git push origin :refs/tags/versão-da-tag

Concluindo

Se você quer continuar ou iniciar seus estudos com Git, indico o link do livro citado acima, é um ótimo começo, se tiver problemas com o inglês, encontrará várias versões em português.

O Akita fez um screencast para quem está começando com Git. Vale a pena ver.

O pessoal da CodeSchool juntamente com o GitHub fizeram uma página exclusivamente para ensinar Git na prática. Visite aqui.

Há também a documentação do Git que é bastante completa.

---
Este artigo foi escrito por Candido Souza.

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

Este artigo foi escrito por telles

     X

Em 2007, escrevi 2 textos falando sobre as vantagens do Oracle sobre o PostgreSQL e vice-versa. Naquela época, minhas observações foram baseadas no Oracle 10.2 e PostgreSQL 8.2. Depois disso a Oracle lançou as versões 11.1, 11.2 e 12.1. O PostgreSQL lançou o 8.3, 8.4, 9.0, 9.1, 9.2, 9.3 e 9.4. Enfim, muita coisa mudou de lá para cá… a febre da Internet não passou e trouxe a onda no NOSQL para a mesa. Eu também mudei bastante, amadureci muitas opiniões e acho que está mais do que na hora de retomar este assunto. Outra coisa que preciso dizer para o leitor que não me conhece é que este texto não é imparcial. Sou um defensor do PostgreSQL, mas trabalho há 12 anos com Oracle também e reconheço algumas fraquezas e vantagens de um e de outro. Mas em nenhum momento aqui vou enganar o leitor me fazendo crer imparcial. Os comentários estão aí para você complementar ou corrigir qualquer informação que julgar relevante. Apenas peço o de faça de forma educada.

Para começar, devo explicar que para mim não faz muito sentido comparar o PostgreSQL com bases NOSQL ou com MySQL. São produtos com fins diferentes. Talvez comparar o PostgreSQL com o SQL Server faça mais sentido, mas o mais próximo que temos, sem dúvida é o Oracle mesmo. Vejamos aqui algumas semelhanças entre ambos que os tornam próximos:

• Origens semelhantes: No começo da década de 70 a IBM publicou os primeiros documentos que mais tarde dariam origem ao System R (que por sua vez dariam origem ao DB2) escritos pelo Sr. Edgar Frank Codd, dois grandes projetos fora da IBM se iniciaram seguindo suas publicações.
  • Em 73, na universidade de Berkeley o Sr. Michael Stonebraker junto com alguns coletas começaram a desenvolver o Ingres. O Ingres seria a base de muitos outros bancos de dados relacionais como O Sybase e o SQL Server. Em 1985, ainda em Berkeley, o sr. StoneBraker decide começar do zero uma nova versão do Ingres chamada Postgres, incluindo novos conceitos como orientação a objetos.
  • Em 77, o Sr. Larry Ellison se juntou com alguns amigos para criar o Oracle. Em 79 lançam a primeira versão do banco de dados relacional que mais tarde viria a se tornar o líder de mercado, à frente até mesmo do DB2 da IBM que cunhou o padrão SQL.
• Ambientes semelhantes:
  • Tanto o Oracle quanto o PostgreSQL praticamente nasceram em ambientes UNIX. Ambos até hoje tem como ambiente primário este ambiente até hoje: LInux e Solaris para o Oracle e Linux e FreeBSD para o PostgreSQL.
  • Ambos possuem versões para rodar em outros sistemas operacionais, inclusive o Windows. Notavelmente o PostgreSQL roda até em videogames.
  • Ambos foram escritos em sua maior parte em C.
• Ambos possuem um ótimo suporte a transações já nas primeiras versões e levam até hoje muito a sério os requisitos do ACID. Sendo assim, são bancos de dados muito confiáveis e que levam muito a sério a questão da consistência dos dados. Este não é o caso do MySQL ou do NOSQL.
• Ambos trabalham há muito tempo com o conceito de MVCC, tão caro à bases transacionais e ambientes de alta concorrência, onde o fato de você estar alterando um registro não impede que a versão não alterada do mesmo seja lida em outras sessões até que a transação atual confirme a alteração em andamento (read commited).
• Ambos são extremamente robustos e trazem há muito tempo o conceito de Point In Time Recovery. Isto permite que um backup antigo possa rolar para pontos no tempo posterior ao backup utilizando cópias dos logs de transação (conhecidos como archives) até um ponto no tempo específico. Ou seja, se você fizer seu backup corretamente, a perda de dados em caso de desastre é muito pequena.
• Ambos implementaram um rico arcabouço de funções e linguagens de programação procedural embutida no banco de dados. O Oracle criou o PL/SQL e as suas funções em C enquanto o PostgreSQL copiou esta linguagem e criou o PL/pgSQL e mais uma infinidade de outras como PL/Python, PL/PERL, C e outras mais.
• Ambos possuem ótima performance em ambiente OLTP, Data Warehouse (ou BI) e mistos. Assim conseguem um bom desempenho em variadas situações.
• Ambos tem a capacidade de trabalhar com ambientes severos, seja com bases ou objetos com grande volume de dados, grande volume de transações ou alta concorrência;
• Ambos são bastante seguros. Patches com correções de segurança são liberados com frequência e as eventuais falhas são corrigidas. Ambos se preocupam muito com a questão e tem mecanismos bem robustos para evitar ataques externos, injeção de SQL e outros perigos.

O artigo Oracle X PostgreSQL – Parte I: Semelhanças apareceu primeiro em Savepoint.

Não bastam as tempestades, nevascas e até os tubarões mordendo cabos submarinos: agora o acesso Internet das nossas casas pode sair do ar devido ao aquecimento acima da média – que, no caso de determinado provedor australiano, significa 44°C às 16h30, uma temperatura externamente que os datacenters brasileiros certamente não consideram anormal, embora eu não saiba precisar até que temperatura externa sustentada eles estão preparados para lidar.

No caso do provedor australiano iiNet, de Perth, essa temperatura é a 6ª mais alta já registrada, não era alcançada desde 1991, e sobrecarregou a capacidade de climatização, levando a desligamento por 6 horas e meia, com ativação de planos de contingência e usuários irritados – com razão, pois estamos em 2015 e prever climatização para temperaturas no limite superior da faixa história, e até um pouco acima, é o mínimo a esperar. (via tech.slashdot.org - “Extreme Heat Knocks Out Internet In Australia - Slashdot”)

O artigo "Calor extremo (44°...) faz provedor australiano desligar servidores" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Muitos vem sendo os ataques à diferentes contas, e isso desde bancos, até redes sociais, pois bem, pensando nisso, o serviço de armazenamento de arquivos na nuvem da Apple, iCloud, resolveu lançar uma ferramenta de rackeio de senhas,iDict, para, justamente, tentar ajudar quem tem dificuldade em saber se uma determinada senha é segura ou não. Pois bem, agora iDict disponibilizou uma lista com 500 senhas.

Então, se trata de uma lista com 500 senhas que devem ser evitadas por quem procura por segurança tanto em iCloud como em qualquer outro site, uma lista “das senhas que grande parte da população usa e que, cedo ou tarde, funcionarão”.

Quando ouvimos que alguém invadiu uma conta, ou que dados privados foram filtrados por “hackers”, ou que uma empresa foi invadida, geralmente imaginamos em grandes especialistas de segurança usando vários computadores em paralelo com letras verdes sobre fundo negro, porém, as vezes o problema é somente o uso de senhas comuns (não necessariamente “debeis”), e o pouco conhecimento sobre segurança de certas pessoas, que são capazes de dizer sua senha em voz alta, ou por telefone, se alguém com crachá ou se identificando como “suporte” a pede de forma educada.

Veja abaixo a lista das “500 senhas que devem ser evitadas”:

Password1
Princess1
P@ssw0rd
Passw0rd
Michael1
Blink182
!QAZ2wsx
Charlie1
Anthony1
1qaz!QAZ
Brandon1
Jordan23
1qaz@WSX
Jessica1
Jasmine1
Michelle1
Diamond1
Babygirl1
Iloveyou2
Matthew1
Rangers1
Pa55word
Iverson3
Sunshine1
Madison1
William1
Elizabeth1
Password123
Liverpool1
Cameron1
Butterfly1
Beautiful1
!QAZ1qaz
Patrick1
Welcome1
Iloveyou1
Bubbles1
Chelsea1
ZAQ!2wsx
Blessed1
Richard1
Danielle1
Raiders1
Jackson1
Jesus777
Jennifer1
Alexander1
Ronaldo7
Heather1
Dolphin1
Destiny1
Brianna1
Trustno1
1qazZAQ!
Precious1
Freedom1
Christian1
Brooklyn1
!QAZxsw2
Password2
Football1
ABCabc123
Samantha1
Charmed1
Trinity1
Chocolate1
America1
Password01
Natalie1
Superman1
Scooter1
Mustang1
Brittany1
Angel123
Jonathan1
Friends1
Courtney1
Aaliyah1
Rebecca1
Timothy1
Scotland1
Raymond1
Inuyasha1
Tiffany1
Pa55w0rd
Nicholas1
Melissa1
Isabella1
Summer07
Rainbow1
Poohbear1
Peaches1
Gabriel1
Arsenal1
Antonio1
Victoria1
Stephanie1
Dolphins1
ABC123abc
Spongebob1
Pa$$w0rd
Forever1
iydgTvmujl6f
Zachary1
Yankees1
Stephen1
Shannon1
John3:16
Gerrard8
Fuckyou2
ZAQ!1qaz
Pebbles1
Monster1
Chicken1
zaq1!QAZ
Spencer1
Savannah1
Jesusis1
Jeffrey1
Houston1
Florida1
Crystal1
Tristan1
Thunder1
Thumper1
Special1
Pr1ncess
Password12
Justice1
Cowboys1
Charles1
Blondie1
Softball1
Orlando1
Greenday1
Dominic1
!QAZzaq1
abc123ABC
Snickers1
Patches1
P@$$w0rd
Natasha1
Myspace1
Monique1
Letmein1
James123
Celtic1888
Benjamin1
Baseball1
1qazXSW@
Vanessa1
Steelers1
Slipknot1
Princess13
Princess12
Midnight1
Marines1
M1chelle
Lampard8
Jesus123
Frankie1
Elizabeth2
Douglas1
Devil666
Christina1
Bradley1
zaq1@WSX
Tigger01
Summer08
Princess21
Playboy1
October1
Katrina1
Iloveme1
Chris123
Chicago1
Charlotte1
Broncos1
BabyGirl1
Abigail1
Tinkerbell1
Rockstar1
RockYou1
Michelle2
Georgia1
Computer1
Breanna1
Babygurl1
Trinity3
Pumpkin1
Princess7
Preston1
Newyork1
Marissa1
Liberty1
Lebron23
Jamaica1
Fuckyou1
Chester1
Braxton1
August12
z,iyd86I
l6fkiy9oN
Sweetie1
November1
Love4ever
Ireland1
Iloveme2
Christine1
Buttons1
Babyboy1
Angel101
Vincent1
Spartan117
Soccer12
Princess2
Penguin1
Password5
Password3
Panthers1
Nirvana1
Nicole12
Nichole1
Molly123
Metallica1
Mercedes1
Mackenzie1
Kenneth1
Jackson5
Genesis1
Diamonds1
Buttercup1
Brandon7
Whatever1
TheSims2
Summer06
Starwars1
Spiderman1
Soccer11
Skittles1
Princess01
Phoenix1
Pass1234
Panther1
November11
Lindsey1
Katherine1
JohnCena1
January1
Gangsta1
Fuckoff1
Freddie1
Forever21
Death666
Chopper1
Arianna1
Allison1
Yankees2
TrustNo1
Tiger123
Summer05
September1
Sebastian1
Sabrina1
Princess07
Popcorn1
Pokemon1
Omarion1
Nursing1
Miranda1
Melanie1
Maxwell1
Lindsay1
Joshua01
Hollywood1
Hershey1
Hello123
Gordon24
Gateway1
Garrett1
David123
Daniela1
Butterfly7
Buddy123
Brandon2
Bethany1
Austin316
Atlanta1
Angelina1
Alexandra1
Airforce1
Winston1
Veronica1
Vanilla1
Trouble1
Summer01
Snowball1
Rockyou1
Qwerty123
Pickles1
Password11
Password1!
November15
Music123
Monkeys1
Matthew2
Marie123
Madonna1
Kristen1
Kimberly1
Justin23
Justin11
Jesus4me
Jeremiah1
Jennifer2
Jazmine1
FuckYou2
Colorado1
Christmas1
Bella123
Bailey12
August20
3edc#EDC
2wsx@WSX
12qw!@QW
#EDC4rfv
Winter06
Welcome123
Unicorn1
Tigger12
Soccer13
Senior06
Scrappy1
Scorpio1
Santana1
Rocky123
Ricardo1
Princess123
Password9
Password4
P@55w0rd
Monkey12
Michele1
Micheal1
Michael7
Michael01
Matthew3
Marshall1
Loveyou2
Lakers24
Kennedy1
Jesusis#1
Jehovah1
Isabelle1
Hawaii50
Grandma1
Godislove1
Giggles1
Friday13
Formula1
England1
Cutiepie1
Cricket1
Catherine1
Brownie1
Boricua1
Beckham7
Awesome1
Annabelle1
Anderson1
Alabama1
1941.Salembbb.41
123qweASD
abcABC123
Twilight1
Thirteen13
Taylor13
Superstar1
Summer99
Soccer14
Robert01
Prototype1
Princess5
Princess24
Pr1nc3ss
Phantom1
Patricia1
Password13
Passion1
P4ssword
Nathan06
Monkey13
Monkey01
Liverpool123
Liverp00l
Laura123
Ladybug1
Kristin1
Kendall1
Justin01
Jordan12
Jordan01
Jesus143
Jessica7
Internet1
Goddess1
Friends2
Falcons7
Derrick1
December21
Daisy123
Colombia1
Clayton1
Cheyenne1
Brittney1
Blink-182
August22
Asshole1
Ashley12
Arsenal12
Addison1
Abcd1234
@WSX2wsx
!Qaz2wsx
zaq1ZAQ!
ZAQ!xsw2
Whitney1
Welcome2
Vampire1
Valerie1
Titanic1
Tigger123
Teddybear1
Tbfkiy9oN
Sweetpea1
Start123
Soccer17
Smokey01
Shopping1
Serenity1
Senior07
Sail2Boat3
Rusty123
Russell1
Redskins1
Rebelde1
Princess4
Princess23
Princess19
Princess18
Princess15
Princess08
PoohBear1
Peanut11
Peanut01
Password7
Password21
Passw0rd1
October22
October13
November16
Montana1
Michael2
Michael07
Makayla1
Madison01
Lucky123
Longhorns1
Kathryn1
Katelyn1
Justin21
Jesus1st
January29
ILoveYou2
Hunter01
Honey123
Holiday1
Harry123
Falcons1
December1
Dan1elle
Dallas22
College1
Classof08
Chelsea123
Chargers1
Cassandra1
Carolina1
Candy123
Brayden1
Bigdaddy1
Bentley1
Batista1
Barcelona1
Australia1
Austin02
August10
August08
Arsenal123
Anthony11

Veja também:

WordPress pede a mais de 100.000 usuários que refaçam suas senhas

Confira alguns interessantes aplicativos de Controle Parental

Kindle Scout, serviço da Amazon para votar nos livros que devem ser publicados

The Interview is out now in theaters and streaming on YouTube (and elsewhere). There have now been a cross-section of experts in entertainment, celebrity lifestyle, foreign policy, and Internet security that have all weighed-in with their analysis and opinions on the how, the why and the ultimate impact of Sony’s hacking incident. If you want a decent synopsis, read this one.

Like everyone else, I followed the story as it trickled out publicly over the last several weeks. In the aftermath, George Clooney once again rose to ‘rogue hero’ status, but Sony’s leaked emails revealed that the Motion Picture Association of America has sunk to an unsurprisingly new low with it’s own new angle of attack on the Internet — and the security industry needs to be on high alert.

While we can debate the ethics of disclosing leaked emails, The Verge made the call to report on a series of messages between the MPAA and six Hollywood studios. Attempting to use the Internet’s infrastructure (and DNS in particular) and loopholes in digital law, these emails uncovered a new coordinated effort by Hollywood to brute-force its anti-piracy agenda on the technology industry and all US-based Internet users. In an article explaining its editorial decision, Emily Yoshida, The Verge entertainment editor, commented, “We decided that it was important for you to know how the MPAA plans to influence how you experience the internet, and by extension, how they intend to shape the future of the information marketplace; we could all agree that it had more impact on our world and our lives than top-secret internal intelligence that Scott Rudin is a meanie.”

Based on the leaked information, it appears that SOPA (the proposed legislation OpenDNS helped defeat) was just the beginning. For network security companies and ISPs, statements made by the MPAA’s general counsel Steven Fabrizio make it clear the fabric of the Internet is a key target in its strategy to fight copyright piracy. No longer able to bend Congress to their antiquated perspectives, they intend to bully ISPs and network vendors. In one email, Fabrizio said, “We start from the premise that site blocking is a means to an end.” Another message reads, “We have been exploring theories under the All Writs Act, which, unlike DMCA 512(j), would allow us to obtain court orders requiring site blocking without first having to sue and prove the target ISPs are liable for copyright infringement.”

While it’s incredible that a lawyer like Fabrizio would be so bold (and foolish) to use such language in discoverable emails, what he is proposing is even more incredible. A deliberate attempt to circumvent the DMCA. Ironic, right?

At a more technical level, one of the options the MPAA suggests in its quest is DNS blocking, an approach the technology industry has fought hard to show is a bad idea. In fact, back in 2012, the MPAA officially declared DNS filtering as off-the-table.

For the exact same reasons the technology industry rallied against SOPA, we cannot let the MPAA abuse DNS services as their anti-piracy hammer. DNS is a fundamental protocol of the Internet — as fundamental as the physical wiring itself. It is not in any way conducive to an environment that fosters piracy any more than oxygen is. The mere idea that DNS services induce cases of copyright infringement is a nonsensical technical argument. Fortunately, the Verge, Ars Technica and other sites and blogs sounded the warning call and several freedom of speech proponents and technology organizations have kicked off responses to the MPAA and state government officials enlisted by the association. You can bet that we will continue to drive this brain-dead idea back where it belongs… on the set of a show like The Walking Dead.

Copyright infringement is an important issue. Rather than trying to segment and cut off the Internet, the MPAA should be finding ways to reduce piracy by enabling access to content via methods that reward creators. As an industry we’ve already proven we won’t back down to threats of draconian measures. While I’d rather focus our energy and talents on delivering a safer and more secure Internet, we won’t hesitate to put that mission on hold to preserve a free and open Internet first and foremost.

The post Sony Reveals An Even Bigger Attack on the Internet…This Time, the MPAA is Behind It appeared first on OpenDNS Blog.

Desenvolvedores PHP estão progressivamente migrando para o desenvolvimento de APIs, já que há muitos desenvolvedores server-side. É uma tendência que tem ocorrido por alguns anos e chegou a um ponto em que todo mundo está escrevendo artigos que mostram como fazer uma “API incrível”. Infelizmente, a maior parte desses artigos é lamentavelmente inadequada ou promove práticas ruins.

Não vou colocar o link de nenhum exemplo ruim aqui porque isso é rude, mas há algumas regras de ouro às quais me apego ao criar uma API.

Nunca exponha resultados da base de dados diretamente

1. Se você renomear um campo, então seus usuários estarão ferrados. Converta-os com uma estrutura de array hardcoded.
2. A maior parte dos drivers de banco de dados (para PHP) exibirá números inteiros como strings numéricas e false como “0” (zero), então você vai querer converter o tipo (typecast) tanto quanto seus arrays forem utilizados para dar saída.
3. A não ser que estiver utilizando ORM com funcionalidade “escondida”, pessoas verão senhas, saltos e todo o tipo de código extravagante. Se acrescentar qualquer coisa e esquecer de colocá-la no seu array $hidden, então OPS! Declare manualmente suas saídas e NÃO use return Users::all();

Use a URI com parcimônia e corretamente

1. Use a string de query para parâmetros pais em vez de /users/id/5/active/true. Sua API não precisa ser otimizada para SEO.
2. ?format=xml é estúpido, use um cabeçalho Accept: application/xml. Eu acrescentei isso certa vez para o servidor rest do CodeIgniter para as pessoas preguiçosas, e agora acham que isso é uma coisa legal, mas não é.
3. Torne todos os seus recursos plurais. /user/X talvez faça sentido inicialmente, mas quando você tem uma palavra como “oportunidade”, as coisas se tornam estranhas mais rápido. /opportunities e /oppertunity/X causam dor.

Recursos são TUDO

1. Você está sempre ou requisitando um recurso ou múltiplos. Se for apenas um, apenas retorne os dados como um array. Se requisitou múltiplos, então retorne-os como elementos pais plurais (tal como “users”).
2. Dois recursos em locais diferentes devem parecer idênticos (seu desenvolvedor iPhone vai te amar por isso). Isso pode ser /me/friends e /users/5/friends ou dados embarcados.
3. Se quiser múltiplos recursos em uma única chamada, então entregue-os para mim. /users/X,Y,Z em um array “users” funciona bem.
4. Se requisitar múltiplos e existir algum resultado, envie-os em um array “users”.
5. Se requisitar múltiplos mas não encontrar nenhum, então um 404 faz sentido.

JSON, XML ou cale-se

1. Não fique eternamente tentando fazer o seu sistema dar saída de absolutamente tudo o que existe. É claro que você pode dar saída lolcat, mas não é necessário.
2. Diga a seus usuários para enviar um JSON ou um XML no body. Mexer com application/x-www-form-urlencoded e formatação de chave/valor apenas para conseguir dados com $_POST[‘foo’] é estranho, especialmente quando qualquer framework decente (como o Laravel 4) permitirá Input::json(‘foo’) de qualquer forma.
3. Sem parâmetros de carga. Já vi APIs aceitarem application/x-www-form-urlencoded com um parâmetro json={}. Se achar que isso é uma boa ideia, é hora de voltar ao seu treino de yoga ou algo assim, pois o estresse deve estar afetando seu julgamento.

Autenticação

1. OAuth 2 é o lance! Algumas pessoas escreveram bobagens sobre o como ele é inseguro, porque não estavam utilizando SSL. Ou porque a empresa X implementou mal o protocolo. Não implemente mal o protocolo.
2. A não ser que sua API esteja protegida da Internet por um firewall, use SSL.
3. Tenha certeza de que sua implementação do Oauth 2 é compatível com as especificações, ou você passará por maus momentos, como este.

Cache

1. Sua API precisa de uma memória menor do que saber que minha fruta favorita é melancia. Não reconheça o IP, a sessão ou o estado. Não tente adivinhar, deixe que te digam quem são através de seu token de acesso.
2. Cache deve ocorrer só em informações populares onde não há contexto de usuário e que você sabe que não haverá alteração durante esse tempo.
3. O cabeçalho Cache-Control permite que as pessoas possam (ou devam) fazer cache das coisas. Se outros desenvolvedores ignoram esses cabeçalhos, então é problema deles.

Tudo em background

1. “Quando o usuário nos envia uma imagem, redimensione-a, faça o upload para o S3, envie um e-mail e então exiba a confirmação”. Não. Deve haver pelo menos uma tarefa em background, preferencialmente 3, com uma resposta IMEDIATA. Deixe de ter apenas uma tarefa “processamento_imagem” para fazer as coisas.
2. Crie uma tarefa “email”, uma tarefa “sms” e uma tarefa “APN” por exemplo, para que você possa enviar genericamente qualquer tipo de contato a partir da sua API, suas outras tarefas etc., sem infectar sua API com todo tipo de coisa. Posso trocar do Twilio para… bem, não conheço nada melhor, mas poderia fazer isso muito facilmente ao atualizar a tarefa de envio de SMS.
3. Ponha seus “workers” em diferentes servidores. O servidor da sua API está ocupado o suficiente administrando requisições e respostas HTTP; não o faça ter que pensar em outra coisa.

Paginação

1. Faça isso. Muitas pessoas apenas despejam todos os dados do jeito “tome isso” na resposta e esquecem que ela pode ficar bem grande com o tempo.
2. Inclua um elemento “paging”, que possui uma URL “next” ou “previous” se houver mais coisas de qualquer um dos lados.
3. Não faça o cliente ter que calcular qualquer coisa.
4. ENVIE A SAÍDA COM OS TOTAIS. Estou apontando para você Facebook. Porque eu preciso requisitar “next” 20 vezes para manualmente count($response[‘data’]) para ver quantos amigos um usuário específico possui quando você obviamente já sabe a resposta? BAH!

Códigos de respostas

1. Me dê uma mensagem de erro de verdade, não apenas um código. “Ei, você, um E40255 acabou de acontecer” – Ninguém merece!
2. Use 410 em vez de 404 caso tenha sido deletado, bloqueado ou rejeitado. “Esse conteúdo foi removido” é mais útil do que “Hum, nada”.

Documentação

1. Se você tem uma documentação bem escrita, poderá dizer RTFM muitas vezes.
2. APIs versionadas são mais fáceis de manter atualizadas, porque elas não mudam (ao contrário da API do Facebook, cujos desenvolvedores podem mudá-la toda noite).
3. Use uma ferramenta. Swagger-PHP + Swagger-UI faz esse truque.

Testes

1. Escreva testes (Behat é ótimo para isso) e faça com que o Jenkins automatize-os;
2. Se os testes não forem automatizados, eles podem não existir.
3. Faça testes unitários para seus componentes, modelos e o que mais quiser.
4. Não precisa imitar a base de dados, crie um servidor de “testes” e faça ele “sofrer”, apenas imite as chamadas externas da API do FB/Twitter/etc.
5. TESTE PARA ENCONTRAR ERROS, não apenas sucesso. Tente e acione qualquer sistema de guarda.
6. Se os testes não forem automatizados, eles talvez não existam. Não, nada de copiar/colar o erro.

Versione a sua API como gente grande

1. É claro que jogar uma subpasta v1/ no seu app/controllers ou coisa do tipo parece uma forma muito esperta de fazer as coisas, mas como você vai fazer o merge dos ajustes da v1.0 na v1.1 e v2.0?
2. Se você for usar v1, então tenha certeza de que se trata de uma base de código diferente; não faça com que um app emule todas as versões porque NÃO VAI FUNCIONAR, POR QUE VOCÊ CONTINUA TENTANDO, PARE COM ISSO!
3. O Nginx vem com um módulo Map bastante útil, para mapear cabeçalhos Accept personalizados para uma variável.
4. Esses cabeçalhos podem parecer com isto: application/vnd.com.example-v1.0+json. Estranho? Quem sabe.
5. Use essa variável para mapear para um diretório diferente na configuração do seu host virtual, e cada um desses possui seu próprio branch do Git. Algo como: “set $apipath api-v$apiversion;” seguido por “root /var/www/$api_path/public;”
6. Faça o merge das mudanças nas versões posteriores, já que muitas bases de código compartilham de um histórico comum. Não tente copiar e colar as mudanças como um idiota.
7. Todas as regras nesta seção significam que 1.0 poderia ser PHP, 2.0 poderia ser Node (seu hipster!) e 3.0 poderia ser Scala (Eu nem…) e apenas as versões intermediárias precisam se preocupar em fazer o merge das mudanças nas versões posteriores.

Essa mensagem foi trazida até você com a ajuda de cerveja e algum whisky.

Faça suas APIs melhores, pois agora você não tem desculpa.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://philsturgeon.co.uk/blog/2013/07/building-a-decent-api

Nos velhos tempos, antes de a República ter derrubado o Império todos éramos Jedis. Começávamos a mexer com computadores ainda jovens padawans, com nossos TK85 e MSX ou, se você fosse azarado, com o MC1000 da CCE. Quando terminávamos nosso treinamento a última prova para nos graduarmos Cavaleiros Jedi era montar o próprio micro.

Hoje uma geração inteira não precisa mais fazer isso: o computador deixou de ser um equipamento exótico. E não há nada mais ridículo do que se orgulhar de fazer de graça o mesmo trabalho que o Ching-Chong Ding-Dong, na fábrica da Foxconn.

Por outro lado desconhecer totalmente computadores, tratando como uma caixa preta, é igualmente ruim. Minha mãe é uma completa analfabeta digital que usa computadores desde o final dos Anos 90. Ela é incapaz de entender conceitos simples, mesmo quando escritos na tela, em português. Isso a levou a passar por casos horrendos, como o TÉNICO que que desinstalou o XP original do Dell dela, e enfiou um 98 piratex, ou quando descobri que ela havia contratado uma empresa para instalar Velox, sendo que a empresa não era a TELERJ TELEMAR OI.

Isso mesmo. Há um bando de FDPs (perdoem meu francês) que faz caça predatória a leigos, de mais idade, preferencialmente retardados (minha mãe). Eles vendem facilidade para gente que acha que tudo é difícil. Como resultado ela pagou 3 boletos, num total equivalente a um salário-mínimo, para uma empresa que se limitou a pegar os dados dela, ligar para a Telemar e solicitar uma instalação do Velox.

Infelizmente não é só ela, e não é nem só no Brasil.

A internet está CHEIA daqueles banners “SEU COMPUTADOR FOI INFECTADO”, simulando interfaces do Windows 3.11, mas convenhamos o público-alvo não sabe a diferença. Depois da 18ª limpeza em avisei que se minha mãe clicasse em MAIS UM desses banners o computador dela seria atirado no oceano. Deu certo, semana passada consertei o bicho, e só tinha a ASK TOOLBAR.

Nos EUA o negócio é sofisticado, os picaretas usam catálogos de telemarketing para identificar as pessoas mais idosas, e telefonam, dizendo que são da Microsoft, do Google, e que o computador deles está com problemas. Como a TV alardeia o tempo todo hackers, Snowden, Coréia do Norte, e esse povo é 90% da audiência da Fox News, os velhinhos se apavoram e dão corda.

Os caras instruem os velhinhos a baixar malware de sites com domínios tipo windowsfullsecurityreallytrustus.com e, obviamente, todos os defeitos e perigos detectados aparecem.

Aí é pedir o cartão de crédito e “limpar” o computador, além do bolso do velhinho.

Desde maio a Microsoft recebeu mais de 65 mil reclamações, e tem que explicar que não, ela NÃO liga para os clientes. Ou melhor, liga sim, o que ela não faz é telefonar, mas se você chegou aqui já entendeu, inclusive percebeu que foi neste momento que me toquei do título click-bait descarado. Mas divago…

Nessa brincadeira é rotineiro um “serviço” de limpeza de vírus custar US$ 600,00. Uma tal de Omnitech Support chegou a cobrar US$ 859,99 para remover ameaças imaginárias do computador de incautos.

A Microsoft não gosta NADA disso, afinal de contas é o nome dela na reta. Os canalhas se identificam como a empresa. O FBI está de olho e a FTC — Federal Trade Commission também. Já foram iniciadas ações legais por parte do Governo, mas a Microsoft achou pouco, e soltou seus temíveis, sanguinários e insaciáveis advogados em cima dos canalhas, entrando com uma ação (cuidado, PDF) exigindo cabeças, mas provavelmente com empalamento antes.

Estão acusando os picaretas de estelionato, violação de copyright, competição desleal, propaganda enganosa e várias outras safadezas. É pouco. Eu ainda colocaria blasfêmia contra o Profeta e assistir a A Entrevista.

Não é a primeira vez que a Microsoft faz isso, eles vivem processando (e ganhando) spammers, mas no caso das “firmas” de suporte é mais simples, elas não se escondem tanto e o dano é facilmente demonstrado em tribunal. Agora, os advogados pegaram gosto por sangue e estão prometendo ir atrás de picaretas do mesmo nível operando no Reino Unido e na Índia.

Parabéns à Microsoft, a última coisa que precisamos é da profissionalização do “sobrinho” que conserta computador.

Fonte: MS, DT.

The post De uma vez por todas: a Microsoft NÃO liga para seus usuários. appeared first on Meio Bit.

(Operadoras reunidas conversando)
Operadora 1: Estão chegando as festas de fim de ano e as pessoas estão com mais amor no coração. Elas não estão nos odiando tanto quanto no resto do ano. Precisamos fazer algo para mudar isso…
Operadora 2: O que você sugere?
Operadora 1: Sabe aquele lance de reduzir a velocidade quando atinge um limite? As pessoas odiavam, agora já estão acostumadas… Que tal se a gente cortar a Internet de vez??
Operadora 3: Perfeito! O ódio vai voltar…
Operadora 4: Mas e a Anatel?
Operadora 1: Eu não consegui convidá-la, porque só dava fora de área, mas tenho certeza de que ela vai amar…

The post Reunião de fim de ano appeared first on Vida de Programador.

Send to Kindle

O post unhas apareceu primeiro em Pluralma.

18 DECEMBER 2014: The PostgreSQL Global Development Group announces the release of PostgreSQL 9.4, the latest version of the world's leading open source database system. This release adds many new features which enhance PostgreSQL's flexibility, scalability and performance for many different types of database users, including improvements to JSON support, replication and index performance.

Flexibility

With the new JSONB data type for PostgreSQL, users no longer have to choose between relational and non-relational data stores: they can have both at the same time. JSONB supports fast lookups and simple expression search queries using Generalized Inverted Indexes (GIN). Multiple new support functions enable users to extract and manipulate JSON data, with a performance which matches or surpasses the most popular document databases. With JSONB, table data can be easily integrated with document data for a fully integrated database environment.

"JSONB brings PostgreSQL to the JavaScript development community by allowing JSON data to be stored and queried natively. Node.js and other server-side JavaScript frameworks can benefit from the safety and robustness of PostgreSQL, while still storing data in the schema-less format that they prefer," said Matt Soldo, Product Manager, Heroku Postgres.

Scalability

In 9.4, Logical Decoding supplies a new API for reading, filtering and manipulating the PostgreSQL replication stream. This interface is the foundation for new replication tools, such as Bi-Directional Replication, which supports the creation of multi-master PostgreSQL clusters. Other improvements in the replication system, such as replication slots and time-delayed replicas, improve management and utility of replica servers.

"The main reason behind our immediate adoption of PostgreSQL 9.4 in production is the new Logical Decoding feature," said Marco Favale, Cartographic Production Manager of Navionics. "The ability to write custom and flexible output plugins will allow us to transparently collect changes on selected tables and replicate changes where we like, by removing heavier - and more complex to manage - trigger based replication solutions."

"Zalando relies on the stability and performance of hundreds of PostgreSQL database servers to continuously serve millions of customers all around Europe," said Valentine Gogichashvili, Team Lead Database Operations at Zalando Technologies. "We are excited to run time-delayed standby servers which work out of the box, and will evaluate the new bi-directional replication tools as soon as they are released."

Performance

Version 9.4 also introduces multiple performance improvements which will allow users to get even more out of each PostgreSQL server. These include:

• Improvements to GIN indexes, making them up to 50% smaller and up to 3X faster.
• Concurrently updatable Materialized Views for faster, more up-to-date reporting.
• Rapidly reload the database cache on restart using pg_prewarm.
• Faster parallel writing to the PostgreSQL transaction log.
• Support for Linux Huge Pages for servers with large memory.

"We will definitely benefit from concurrent refresh of materialised views, delayed standby servers (which will make our disaster recovery even more robust) as well as the usual performance improvements every new release carries on," added Marco Favale.

Links

• Downloads
• Press Kit
• Release Notes
• What's New in 9.4

About PostgreSQL

PostgreSQL is the leading open source database system, with a global community of thousands of users and contributors and dozens of companies and organizations. The PostgreSQL Project builds on over 25 years of engineering, starting at the University of California, Berkeley, and has an unmatched pace of development today. PostgreSQL's mature feature set not only matches top proprietary database systems, but exceeds them in advanced database features, extensibility, security and stability. Learn more about PostgreSQL and participate in our community on our web page.

Eu estava dando uma consultoria para uma empresa, enquanto estava na África do Sul, e nós fizemos um acordo. Você aciona a funcionalidade SOAP para mim e eu escrevo endpoints RESTful. Essa foi a criação da API de disparo rápido com 20 pessoas na sala.

Foi divertido, mas algumas coisas foram complicadas. As necessidades da companhia estavam longe de ser triviais, sendo uma empresa que envia milhões de e-mails e mensagens de texto por dia para pessoas com vários tipos diferentes de número de telefone, short-code ou ID do usuário. Uma ou duas vezes me vi sugerindo alguns endpoints espertos que não eram RESTful, mas toda vez que isso acontecia, eu forçava meu cérebro a trabalhar um pouco mais firme para descobrir quais combinações iriam satisfazer os deuses RESTful e, assim, evitar que despejassem sua ira sobre mim.

Estilo SOAP

Tradicionalmente APIs consistiriam em uma série de endpoints que descreveram verbos (ações):

POST /SendUserMessage HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
id=5&message=Hello!

Como você já deve ter percebido, não é assim que as coisas são feitas com REST.

Meio RESTful

Alguns desenvolvedores de API consideram a seguinte abordagem para ser mais RESTful, pois será usado um “sub-recurso”:

POST /users/5/send-message HTTP/1.1
Host: example.com
Content-Type: application/json
{ “message” : “Hello!” }

Não, porque isso ainda está usando um verbo na URL. Um verbo é uma ação – um termo que faz, e nossa API só precisa de um verbo – o método HTTP. Todos os outros verbos precisam ficar de fora da URL.

Um substantivo é um “lugar” ou uma “coisa”. Os recursos são “coisas”, e uma URL torna-se o “lugar” na Internet, onde uma “coisa” mora.

RESTful de fato

Este exemplo seria drasticamente mais RESTful:

POST /users/5/messages HTTP/1.1
Host: example.com
Content-Type: application/json
{ “message” : “Hello!” }

Perfeito! Estamos criando uma nova mensagem, que pertence a um usuário. A melhor parte de mantê-lo agradável e RESTful assim é que outras ações HTTP podem ser feitas para uma URL idêntica:

• GET /users/philsturgeon/messages
• PATCH /users/philsturgeon/messages/xdWRwerG
• DELETE /users/philsturgeon/messages/xdWRwerG

Isso tudo é muito mais fácil para se documentar e entender tanto por humanos quanto por softwares que são clientes RESTful.

Portanto, para esse cliente, eles tiveram que enviar potenciais de centenas de milhares de mensagens em uma base regular. A solução que achamos foi tornar /messages seu próprio endpoint e enviar as mensagens em lotes de algumas centenas:

POST /messages HTTP/1.1 Host: example.com Content-Type: application/json
{ [{ “user” : { “id” : 10 }, “message” : “Hello!” },
{ “user” : { “username” : “philsturgeon” }, “message” : “Hello!” }] }

Isso ficaria incrivelmente semelhante para criar os dados como para obtê-los, o que é intencional. Independentemente do verbo HTTP e da URL específica, uma pá deve sempre parecer com uma pá, e um saco de chaves de boca deve sempre parecer como um saco de chaves de boca. As coisas devem ter um padrão específico e não devem exigir suposições para descobrir como as coisas se parecem para GET ou POST … a menos que você esteja no Facebook e aí é apenas um grande gameshow sem prêmios.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em https://philsturgeon.uk/rest/2014/05/11/restful-urls-actions-need-not-apply/

The most powerful system troubleshooting tools all tend to have one trait in common: a non-negligible learning curve. As the saying goes, if you want to drive a race car, you have to learn to drive stick*. Now to be fair, we designed sysdig from the ground up to be as intuitive and straightforward to use as possible. But to get the most out of the tool, it definitely helps to have an understanding of how system level information is presented in sysdig output. In this post, I will walk through some basic operating system elements and try to explain how they are represented by sysdig, including:

• Processes and Threads
• File Descriptors
• Events, System Calls and Switches

Sysdig output basics

Running sysdig without any filters will produce output that looks like this (colors added for easier explanation, below):

1 01:40:19.601363716 1 httpd (7513) > accept

2 01:40:19.601374197 1 httpd (7513) < accept fd=14(<4t>127.0.0.1:39175->127.0.0.1:80) tuple=127.0.0.1:39175->127.0.0.1:80 queuepct=0

3 01:40:19.601506564 1 httpd (7513) > read fd=14(<4t>127.0.0.1:39175->127.0.0.1:80) size=8000

4 01:40:19.601512497 1 httpd (7513) < read res=85 data=GET /textfile.txt HTTP/1.1..User-Agent: curl/7.35.0..Host: 127.0.0.1..Accept: */

5 01:40:19.601516976 0 httpd (3750) > switch next=0 pgft_maj=0 pgft_min=522 vm_size=350196 vm_rss=9304 vm_swap=0

6 01:40:19.601661779 1 httpd (7513) > open

7 01:40:19.601668329 1 httpd (7513) < open fd=15(<f>/opt/lampp/htdocs/textfile.txt) name=/opt/lampp/htdocs/textfile.txt flags=1(O_RDONLY) mode=0

8 01:40:19.601699335 1 httpd (7513) > read fd=14(<4t>127.0.0.1:39175->127.0.0.1:80) size=8000

9 01:40:19.601701560 1 httpd (7513) < read res=-11(EAGAIN) data=

10 01:40:19.601855764 1 httpd (7513) > close fd=15(<f>/opt/lampp/htdocs/textfile.txt)

11 01:40:19.601857490 1 httpd (7513) < close res=0

The fields printed by sysdig are:

• Incremental event number
• Event timestamp – customize this with the -t command line flag (more info)
• CPU ID
• Command name
• Thread ID
• Event direction – ‘>’ means ‘enter’, while ‘<’ means ‘exit’
• Event type
• Event arguments

Now let’s dive into this output a little further and see how some fundamental operating system elements are represented here by sysdig.

Processes and Threads

Threads are the core execution unit for the operating system and, as a consequence, for sysdig as well.

The thread ID (aka TID) is the basic identifier that you want to follow when tracking execution activity in your machine. You do that by just looking at the TID number, or by filtering out the noise with a command line like this one:

> sysdig thread.tid=7513

which will preserve only the execution flow for thread 7513.

Threads live inside processes, which are identified by a process ID (or PID). Most of the processes running on an average Linux box are single threaded, and in that case thread.tid is the same as proc.pid. Filtering by proc.pid is useful to observe how different threads interact with each other inside a process.

And here’s a couple of little tricks: if you want to see only events for single threaded processes, you can use this command line:

> sysdig proc.nchilds=0

While if you want to trace a specific user session or script, you can use:

> sysdig proc.apid = X

…where X is the pid of the shell running the script

File Descriptors

You may have noticed that several of the events above have an argument called “fd”.

If a thread ID identifies a flow of execution, a file descriptor (FD) identifies an input/output flow.

In unix, a lot of stuff is abstracted as a file, including:

• files
• network connections (sockets)
• standard input, standard output, and standard error
• pipes
• timers
• signals

An FD is a numeric ID that uniquely identifies a file inside a process. This means that you can see the same FD number used more than once, but it will have to be in different processes. By following a process/FD combination, you can track specific I/O activity, and as usual you can let a filter help you:

> sysdig proc.name=httpd and fd.num=14

Sysdig is also nice enough to resolve FD numbers into human readable strings. For example, in the snippet above, notice how FD 14 is represented as <4t>127.0.0.1:39175->127.0.0.1:80, which means:

• this is an IPv4 socket (4)
• the socket L4 protocol is TCP (t)
• the connection has been established by port 39175 on 127.0.0.1
• the destination of the connection is port 80 on 127.0.0.1

All of this information can conveniently be used in filters to isolate interesting activity. For example:

> sysdig fd.type=ipv4
> sysdig fd.l4proto=tcp
> sysdig fd.sip=127.0.0.1
> sysdig fd.sport=39157

Events

Most of the events that sysdig captures and displays are system calls. The system call interface includes a number of ‘functions’ that the operating system exports to the applications running on top of it to do stuff like open files, create network connections, read and write from an FD, and so on.

Usually, you can get more information about one of the sysdig events by typing:

> man 2 <event_name>

in a terminal or in google. Be aware, however, that differently from a tool like strace, sysdig doesn’t mirror the system calls’ syntax with absolute precision.** This means that, even if the system call manual page will give you a very good indication of what the event does and what its arguments mean, there might be discrepancies between the original system call and the corresponding sysdig event. If you want to know what the arguments are for any event, type:

> sysdig -L

As you’ll see if you run this command, sysdig exports many events. However, some of them tend to be more useful for debugging or exploration. For example:

• clone() and execve() give you insight into process creation and command execution.
• open(), close(), and the FD read and write functions offer visibility on disk I/O.
• socket(), connect(), and accept() give insight into network activity.

If you are interested in what these system calls do and how to interpret them, come back to the sysdig blog tomorrow for a whole post focused on that.

In the meantime, there’s an event that I want to mention because people sometimes get confused about it: switch.

The Switch Event

Some people don’t realize that sysdig is not limited to capturing system calls. Sysdig taps into the kernel to report other types of events as well. The switch event, for example, is generated every time there is a context switch, i.e. when the process scheduler puts a thread to sleep to execute another one. Observing scheduler activity is useful for scenarios such as determining when a process/thread runs with high granularity, debugging process synchronization issues, and monitoring when a thread is migrated to a different CPU.

switch is not a system call, so you won’t find a manual page for it. It’s also one of the few sysdig events that doesn’t have an exit event, so you will only see enter as a direction. switch can also be annoying at times, because sysdig tends to print many of them even on systems with relatively low activity. Fortunately, it’s easy to filter it out if you don’t need it:

> sysdig evt.type!=switch

Conclusion

Processes, threads, file descriptors, system calls and context switches are some of the fundamental elements of the Linux operating system. Hopefully it’s more clear now how sysdig represents information about these elements, and how you can use sysdig to explore your system in some pretty powerful ways. ;) If you’d like to dive into even more information on sysdig, be sure to check out the sysdig User Guide on our wiki.

And now that you understand what all that sysdig output on your screen means, it’s time to explore which system calls to monitor and what useful information they hide. More on this in my next post tomorrow – so be sure to come back!

And remember to follow us on twitter for cool sysdig commands with the #DigoftheDay.

*This might not be a saying per se, but my friend Gerald Combs did just say it… so I guess it’s a saying now. Thanks Gerald! :)

**In case you’re wondering, the main reason for this is performance. sysdig’s primary design goal is efficiency, so you can use it in production with minimal overhead. This puts constraints on the order the arguments are returned, to minimize page fault probability. In addition, sysdig adds some useful arguments to some of the system calls. For example, memory-related events like brk or mmap return the total process memory usage, which tends to be handy when troubleshooting memory-related issues.

The post Interpreting Sysdig Output appeared first on Sysdig Cloud.

I decommissioned a fine piece of hardware today. This access point brought the first wireless connectivity to my place. It’s been in service for more than 11 years, and is still fully functional.

In the past years, the device has been running OpenWRT, which is a really nice and very powerful little Linux distribution specifically for this kind of routers. OpenWRT actually sprang from the original firmware for this device, and was extended, updated, improved and made available for a wide range of hardware. OpenWRT lately has made this piece of hardware useful, and I’m really thankful for that. It also a shows how much value releasing firmware under an Open Source license can add to a product. Aside from the long-term support effect of releasing the firmware, updated firmware would add features to the router which were otherwise only available in much more expensive hardware.

The first custom firmware I ran on this device was Sveasoft. In the long run, this ended up not being such a good option, since the company producing the software really stretched the meaning of the GPL — while you were technically allowed to share software with others, doing so would end your support contract with the company — no updates for you. LWN has a good write-up about this story.

Bitter-sweet gadget-melancholy aside, the replacement access point brings a 4 times speed increase to the wifi in my home office: less finger-twiddling, more coding. :)

Há algumas grandes e importantes conversas que acontecem na lista de discussão do PHP, na qual temos falado sobre:

• A especificação do Facebook baseada fora do PHP 5.6
• Talvez o phpng seja movido para a árvore mestre e será a base da próxima grande versão do PHP
• Como podemos melhorar o scalar type hinting

Há também uma outra conversa:

• PHP 6 ou PHP 7?

Espere … o quê?

Um pouco de história

O PHP 6 foi uma tentativa de atualizar a versão da linguagem e foi lançada em meados de 2010, mas acabou ficando presa na lama. Uma das maiores mudanças que causaram os problemas na adoção dessa versão foi o suporte para Unicode no núcleo da linguagem, então – assim como me lembro – a versão foi abandonada devido à incapacidade de utilizar o recurso de forma exatamente correta.

O resultado final foi que cada recurso utilizável previsto para o PHP 6 foi portado para a ramificação 5.x, e é por isso que nós vimos um salto tão grande nos recursos úteis disponíveis para o PHP 5.3.

O argumento atual

A pergunta “Devemos usar PHP 6 como nome para a próxima versão?” foi feita muitas vezes, mas desta vez ela está realmente decolando porque a próxima grande versão do PHP está cada vez mais perto. O prazo naturalmente é outro assunto a ser discutido também, e as apostas atualmente variam de 12 meses a 3 anos, mas ele está chegando e a versão provavelmente deverá ter um nome diferente de “PHP.número”.

Para tentar responder de uma vez por todas se o nome da versão deve ser 6 ou não, foi feita uma uma simples chamada para sugestões da comunidade, do tipo “Podemos chamá-lo de PHP 6?”, mas ela foi encerrada por não consegue fazer uma votação definitiva entre “Será PHP 6 ou PHP 7″.  Depois de algumas idas e vindas, e algumas brigas, temos uma nova votação sobre PHP 6 vS PHP 7.

Argumentos para PHP 7

Infelizmente, toda essa conversa foi baseada em torno da mentalidade de: “Se você não pode provar porque PHP 6 é melhor do que PHP 7, então devemos usar o PHP 7″.

Eu sou totalmente contra a deixar o lado que acumula o maior número de argumentos lógicos ganhar, uma vez que é muito bonito ver como uma discussão funciona. Infelizmente, o debate se parece um pouco menos como uma discussão e mais como uma estrada de ferro de argumentos irrelevantes. Um lado tem uma série de razões, o outro só tem uma: 5 + 1 = 6.

Essa é a razão mais forte. Fazer a coisa lógica não deve ser algo que precisa ser provado com 20 argumentos de 20 ângulos diferentes. Mas, qualquer que seja, vamos olhar para os argumentos positivos a favor do PHP 7 na RFC:

Em primeiro lugar, o PHP 6 já existia e era algo completamente diferente. O sistema decimal (ou mais precisamente o fornecimento infinito de números que temos) faz com que seja fácil para nós pular uma versão, com muito mais casas à esquerda para futuras versões que virão.

A ideia de o PHP 6 já existir é um pouco estranha. Eu trabalhei em todos os tipos de projetos open source, e muitas vezes um determinado código vai ser agendado para inclusão em uma determinada versão, então acaba sendo feito de forma diferente.

Fiz um ramo 3.0 antes, então decidi que não justificaria um grande lançamento neste momento.

Fiz um ramo 3.2 antes, então decidi que seria realmente necessário mudar o nome depois que mais alguns acréscimos de código entraram.

As coisas mudam.

As únicas versões que existem são aquelas que estão realmente liberadas.

Embora seja verdade que o PHP 6 nunca tenha chegado à disponibilidade geral do público, ainda era um projeto amplamente divulgado e conhecido conduzido pelo php.net, que não compartilha absolutamente nada dos recursos atuais com a versão que está em discussão agora. Qualquer pessoa que sabia da existência do PHP 6 (e são muitas pessoas) terá uma forte razão em sua mente para apoiar o conteúdo e as características dessa próxima versão nova (no essencial, quase tudo mudou sobre o Unicode).

Então, voltando ao meu ponto anterior, o “PHP 6 nunca chegou à disponibilidade geral do público”. Isso significa, principalmente, que apenas “aqueles que conhecem a linguagem” realmente têm alguma ideia do que é o PHP 6, e “aqueles que conhecem a linguagem” sabem o suficiente para ficar bem com essa mudança no sentido de dar o PHP 6 como concluído.

O PHP 6 (o PHP 6 original) foi discutido em detalhes em muitas conferências PHP. Foi ensinado aos usuários como um negócio feito, incluindo explicações detalhadas sobre características e comportamentos (e isso foi feito por desenvolvedores do php.net, e não por autores de livros).

Ah, o argumento dos autores de livros. Me mate!

Alguns autores usaram isso como arma durante um tempo, e algumas editoras os obrigaram a criar livros com o título PHP 6, porque queriam ser relevantes por um longo tempo. O argumento do livro durante anos foi o mais forte argumento “pro-PHP 7″, mas não é algo que eu acho que ainda deva ser ligeiramente válido. A maioria desses livros são de baixa qualidade, possuem muitos anos e são todos irrelevantes. Livros ruins existem agora e sempre vão existir, mas o que realmente funciona para conhecermos um livro é ler os comentários de leitores.

Um comentário dizendo “Este livro está desatualizado e não tem nada a ver com o PHP 6″ já mostra que o livro é ruim.

O argumento da conferência também não é particularmente relevante, já que “aqueles que conhecem a linguagem” a conhecem melhor.

O PHP 6 era muito conhecido não só no seio da comunidade Internals, mas em torno da comunidade PHP em geral. Foi um projeto de alto perfil que muitos – senão a maioria – dos membros da comunidade PHP conhecia.

Eu adoraria ver um estudo sobre isso. Minha experiência é que a maioria dos desenvolvedores não tem a menor ideia de que o PHP 6 foi sequer a metade de alguma coisa, mas ficam de queixo caído quando o PHP 7 é mencionado.

Há muita informação sobre o PHP 6 e sobre o PHP 6 original na web. Os livros são a menor parte do problema. Informações ultrapassadas e inúteis.

1. As pessoas sabem para onde ir para obter informação de qualidade, caso contrário, nós todos ainda estaríamos usando a função mysql_connect() em nossos arquivos de conexão.
2. Tutoriais responsáveis não são apenas escritos, possuem um pouco de errata pois sempre surgem informações novas.
3. No mundo da tecnologia, um artigo que foi publicado há alguns poucos anos dificilmente ainda será relevante.

Ao contrário da questão trivial sobre por que nós devemos pular para a versão 7, reutilizar o nome da versão versão 6 provavelmente criará uma verdadeira confusão na mente das pessoas, com ampla informação sobre duas versões completamente diferentes, com conjuntos de recursos completamente diferentes que têm o mesmo nome.

Ampla informação é uma alegação enganosa. Algumas visitas ao Google procurando por informações sobre o PHP 6 basicamente explicam o que aconteceu com a versão 6.

Assim que liberado o PHP 6, haverá um monte de pessoas escrevendo em blogs, livros e dando palestras sobre o PHP 6. Eu vou tornar minha missão pessoal dominar a homepage da linguagem, mas eu tenho certeza de que outros irão me ajudar. NetTuts, Reddit, SitePoint, YouTube e similares, todos eles terão novos conteúdos dizendo “O PHP 6 está fora! Eles tentaram um tempo atrás, mas nós temos isso agora”.

Supor que um conteúdo de quatro anos de idade nunca vai de alguma forma compensar a força de um lançamento real é um verdadeiro absurdo.

Versões de salto não são algo inédito ou incomum, seja em projetos de código aberto ou em produtos comerciais. O MariaDB saltou por todo o caminho até a versão 10.0, para evitar confusão com o MySQL. O Netscape Communicator pulou da versão 5.0 diretamente para a 6.0, e a Symantec pulou para a versão 13. Cada um deles teve diferentes razões para o salto, mas o denominador comum é que as versões de salto não são um grande negócio.

Sim e o software Salt saltou de 0.10.0 para versão 10, ou algo assim, e todos chamaram isso de marketing besteira. Pular números de versão geralmente é uma jogada burra de marketing. Isso é menos que uma jogada de marketing, o marketing de uma escolha pobre.

“Oh, o PHP foi da versão 5 para a versão 7, porque eles destruíram a versão 6 e não conseguiram arrumá-lo?”

e

“Os desenvolvedores do PHP não podem contar até 6″

Em vez de apenas:

“Uma segunda tentativa de lançar o PHP 6 está fora de questão”

A versão 6 geralmente é associada a uma falha no mundo das linguagens dinâmicas. O PHP 6 foi um fracasso; o Perl 6 foi um fracasso. Na verdade, é associada a uma falha também fora do mundo da linguagem dinâmica – o MySQL 6 também existia, mas nunca foi lançado. A percepção da versão 6 como um fracasso – não como uma superstição, mas como um fato no mundo real (similar à associação da palavra “Vista”, com falha) – vai refletir seriamente sobre essa versão do PHP.

Ninguém se importa com isso!

O caso para a versão 6 é principalmente uma refutação de alguns dos pontos acima, mas sem fornecer um argumento forte para isso no sentido de não ignorar a versão 6. Se formos mudar para o PHP 7, o pior cenário é que pulamos desnecessariamente uma versão. Nós ainda teríamos um suprimento infinito de versões principais à nossa disposição para uso futuro. Se, no entanto, nós escolhemos 6 em vez de 7 – o pior cenário é a confusão generalizada em nossa comunidade e a potencial percepção negativa sobre essa versão.

Claro, ninguém está discutindo sobre proteger o meio ambiente a partir de números inteiros perdidos, estamos apenas dizendo que o número que vem depois de 5 é o 6.

Eu realmente não me importo

Eu, como muitos espectadores conhecedores da verdade, penso que não importa o que é captado. Sou totalmente a favor de uma votação e uma série de argumentos, mas sinto que todo argumento nessa lista pró-7 é completamente inválido, e a atitude é “bem, 7 têm mais argumentos do que 6 por isso … 7!”.

Estive assistindo a este vídeo e pensando sobre o Ministério das caminhadas bobas:

Não tenho argumentos que são válidos para dizer a John ou a seus amigos para não andarem assim. Outros irão dizer que parece bobagem para todos fora do ministério, e isso simplesmente não é necessário.

Faça o que você quiser internamente, apenas não cancele a votação [novamente]. Escolha uma resposta e todos do lado perdedor terão de morder a língua, e esperamos que o lado vencedor morda também.

Alternativas

Aqui estão algumas das minhas sugestões favoritas de nomes alternativos:

Vou usar qualquer nome que for escolhido internamente, mas pelo amor de Deus, por favor, escolham algum e deixem esse voto realmente ser finalizado.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em https://philsturgeon.uk/php/2014/07/23/neverending-muppet-debate-of-php-6-v-php-7/

PostgreSQL 9.5 has added a new mode for REINDEX with this commit:

commit: fe263d115a7dd16095b8b8f1e943aff2bb4574d2
author: Simon Riggs <simon@2ndQuadrant.com>
date: Tue, 9 Dec 2014 00:28:00 +0900
REINDEX SCHEMA

Add new SCHEMA option to REINDEX and reindexdb.

Sawada Masahiko

Reviewed by Michael Paquier and Fabrízio de Royes Mello

Up to 9.4, REINDEX is able to run on different things:

• INDEX, to reindex a given index.
• TABLE, to reindex entirely a table, including its underlying toast index if there is a toast table on it.
• DATABASE, to reindex all the relations of the database user is currently connected to, including catalog tables.
• SYSTEM, to reindex all the system catalogs.

A couple of things to note though:

• Indexes reindexed are locked with a strong exclusive lock, preventing any other session to touch it.
• Parent tables are locked with a share lock
• DATABASE and SYSTEM cannot run in a transaction, and process tables one-by-one, pg_class being run first as REINDEX updates it (this last point is an implementation detail, not mentioned in the docs).

The new mode for SCHEMA mixes those things, but behaves similarly to DATABASE and SYSTEM, for a schema:

• It cannot run in a transaction.
• Each table of the schema is processed one-by-one
• pg_class is reindexed first only if pg_catalog is processed.

That's actually what you can find here, note first that pg_class is at the top of the relations indexed.

=# REINDEX SCHEMA pg_catalog;
NOTICE:  00000: table "pg_catalog.pg_class" was reindexed
LOCATION:  ReindexObject, indexcmds.c:1942
[...]
NOTICE:  00000: table "pg_catalog.pg_depend" was reindexed
LOCATION:  ReindexObject, indexcmds.c:1942
REINDEX

And that this operation is non-transactional:

=# BEGIN;
BEGIN
=# REINDEX SCHEMA pg_catalog;
ERROR:  25001: REINDEX SCHEMA cannot run inside a transaction block
LOCATION:  PreventTransactionChain, xact.c:2976

A last thing to note is that a user that has no access on a schema will logically not be able to run REINDEX on it.

=# CREATE USER foo;
CREATE ROLE
=# SET SESSION AUTHORIZATION foo;
SET
=> REINDEX SCHEMA public;
ERROR:  42501: must be owner of schema public
LOCATION:  aclcheck_error, aclchk.c:3376

This feature is particularly helpful when for example working on a server that has multiple schemas when it is wanted to reindex some multiple relations on a single schema as it makes unnecessary the step to list all the relations or to play with a custom function. It presents as well the advantage it avoids taking successive locks on all the objects when doing the work database-wide.

Este artigo foi escrito em conjunto com Raj Lahari.

Se você é um desenvolvedor que quer tornar a experiência móvel mais poderosa para os usuários finais, vale a pena conhecer a fundo a computação de 64 bits. Com ela na ponta dos dedos, os desenvolvedores de dispositivos móveis como smartphones e tablets irão se beneficiar com grandes ganhos de desempenho, memória endereçável acima de 4 GB, e melhores capacidades de segurança.

Longo caminho percorrido

Desde que surgiu no Cray-1, o supercomputador lançado em 1975, a arquitetura de computação de 64 bits tem sido considerada como um marco do poder de processamento. Ao longo das duas décadas seguintes, a tecnologia começou a encontrar seu caminho para os servidores baseados em microcomputadores e, em meados dos anos 1990, para estações de trabalho high-end.

Hoje, os processadores de 64 bits são comuns e em breve se tornarão a base para smartphones e tablets. Com a arquitetura de 64 bits, os desenvolvedores de smartphones e tablets serão beneficiados com grandes ganhos de performance, memória endereçável acima de 4 GB e maiores conjuntos de dados em memória.

Melhor para segurança

Além disso, a arquitetura de 64 bits vai proteger melhor os dados de dispositivos e redes corporativas, uma vez que afasta as ameaças à segurança. De acordo com um relatório lançado em julho de 2014 pela Nielsen, usuários de Android e iPhone com 18 anos ou mais passaram mais de 30 horas por mês utilizando aplicativos móveis em 2013, um aumento de 65% sobre os números de 2012. Os dispositivos móveis também estão permeando o local de trabalho, onde a computação complexa e a segurança são exigidas. A Symantec, em 2012, identificou mais de 200 milhões de definições de vírus, aproximadamente o mesmo número que foi identificado entre 1991 e 2011. Os smartphones e os tablets devem proteger os dados pessoais do usuário, e o hardware móvel deve proporcionar uma experiência de uso adequada.

Intel e Android

O departamento de Software e Serviços da Intel tem ajudado a melhorar o kernel Linux para habilitar a computação de 64 bits desde 2004. A Intel está envolvida em todos os programas, incluindo os navegadores de código aberto Chromium e Blink, além de contribuir para o projeto do compilador GCC, compiladores comerciais, hypervisors, drivers SLC, e “qualquer outra coisa que faça o sistema funcionar”, disse Joe Daly, diretor de engenharia do Centro de Tecnologia Open Source (OTC) dentro do departamento de Software e Serviços da Intel.

Esse grupo desenvolveu uma linha principal Android para fornecer um ponto de partida comum para que os grupos da plataforma de hardware da Intel possam lançar seus esforços de programação para acessar os recursos do processador. A linha principal também é usada como referência para outras variações do Android que requerem aplicativos Android de referência.

Grande parte dos esforços do grupo está focada no Android L e na versão de 64 bits do Android Runtime (ART). Enquanto a Intel tem trabalhado com as versões anteriores do sistema operacional em tempo de execução, a liberação da versão deste ano vai envolver a funcionalidade e o desempenho do hardware de 64 bits. Ela tira proveito de instruções prontas e da escrita de compiladores em tempo de execução que otimizam o código para hardware Intel.

Benefícios da plataforma móvel de 64 bits

Kumar Shiv, principal engenheiro e arquiteto de desempenho da Intel para as máquinas Dalvik de 32 bits e ART de 64 bits, disse que as plataformas móveis de 64 bits podem beneficiar o usuário de várias maneiras. “A plataforma de 64 bits pode, potencialmente, melhorar muitos elementos perceptíveis pelo usuário”, disse Shiv. Os exemplos mais comuns incluem os ciclos de criptografia e descriptografia de aplicativos seguros e os padrões de codificação-decodificação de reprodução de mídia. Ao fazer uma infinidade de operações lógicas em fluxos de bits de grande porte, trabalhar em plataformas de 64 bits cada vez mais é uma enorme vantagem. “Alguns algoritmos sofisticados só funcionam em sistemas de 64 bits, pois em sistemas de 32 bits seriam muito lentos. Para operações matemáticas complexas, uma plataforma de 64 bits é quase que o melhor cenário do mundo”, explicou Shiv.

Em sua pilha de referência, a Intel fornece uma implementação completa do Android, incluindo melhores práticas de segurança e privacidade. O próprio sistema operacional Linux também contém diversos recursos de segurança capazes de barrar ataques de mais baixo nível que são ativados somente em modo 64 bits. “O boot no Android é verificado, o gerenciamento de credenciais, a proteção de conteúdo, e outras coisas que acontecem no Android relacionadas ao gerenciamento de telefones e tablets Android possuem um gateway seguro para a nuvem”, disse Daly.

À medida que o mundo abraça a era Big Data, a segurança proporcionada pela computação de 64 bits será necessária para dispositivos móveis. “Do ponto de vista dos dispositivos da era da Internet das Coisas, essa é a única grande preocupação”, disse Shiv. “Esses dispositivos têm todos os nossos dados pessoais e estão todos na Internet. Precisamos torná-los o mais seguro possível”.

Além da segurança

Fotografia e gráficos com intensos efeitos digitais também serão beneficiados com plataformas de 64 bits. “Os smartphones agora são câmeras também. Edição de duas ou três fotos juntas, fazer um HDR [high dynamic range], ou extrair cenas de vídeo exigem muita memória “, disse Daly. Fotografia e edição em dispositivos móveis pode ser uma experiência melhorada com essa plataforma.

Até mesmo aplicativos de uso geral podem ganhar com plataformas de 64 bits. Com base em suas observações da migração das plataformas de 64 bits do Linux empresarial e do Windows na década de 2000, Daly disse que os aplicativos podem ver uma melhoria de cerca de 15%, à medida que ISVs mudam para plataformas de 64 bits. Desenhando uma linha média, alguns recursos vão cair para baixo dessa linha e alguns vão ultrapassá-la. Criptografia, processamento de imagem e qualquer coisa que precise de processamento irão experimentar benefícios na plataforma de 64 bits. Aplicativos que são altamente otimizados para 32 bits podem não ter nada a ganhar. “Pode haver aplicativos altamente otimizados para 32 bits que podem realmente rodar mal em plataformas de 64 bits”, disse Daly.

Alterações no código do futuro

Um ponto importante no surgimento de dispositivos de 64 bits é que os aplicativos Java puros serão executados de forma inalterada nas plataformas no tempo de execução Dalvik de 32 bits e na plataforma ART de 64 bits, independentemente se o dispositivo foi construído com ARM ou em Arquitetura Intel. Mas se o aplicativo contém código nativo ou chamadas através da Java Native Interface, ele terá de ser recompilado. Se os desenvolvedores querem tirar proveito da arquitetura de 64 bits, terão que desenvolver múltiplos binários otimizados.

Para os desenvolvedores de código nativo que planejam a transição de plataformas, o processo será diferente. “Se um desenvolvedor simplesmente quer levar seu aplicativo para o Android L, deverá recompilá-lo e testá-lo novamente. Mas se querem mudar para 64 bits, alguma portabilidade deverá ser feita, e então os desenvolvedores terão que recompilar as partes nativas do código usando o novo NDK”, disse Daly. O NDK é o Kit de Desenvolvimento Nativo do Android R10. O segundo, também disponível agora, é o SDK do Android, que oferece bibliotecas de API e ferramentas para construir, testar e depurar aplicativos Android. O SDK também está disponível juntamente com o Eclipse IDE e trabalha ao lado do pacote de ferramentas Intel® INDE (em beta). A própria Intel oferece ferramentas líderes na indústria para o desenvolvimento de aplicativos em plataformas de 64 bits, incluindo compiladores, otimizadores e um extenso Programa de Parceria de Software.

“Com grandes poderes vêm grandes responsabilidades”

Como os desenvolvedores devem se preparar para a onda de 64 bits que está chegando, uma sincronia harmoniosa deve ocorrer quando o hardware e o software estiverem equilibrados. “Esperamos que a maioria dos aplicativos funcionem bem, mas um app poderia não funcionar muito bem por causa da quantidade física de memória disponível; ou dispositivos podem demorar um pouco para ficarem atualizados até que a plataforma de 64 bits responda de acordo com sua capacidade de memória”. Os desenvolvedores podem precisar manter versões de 32 e 64 bits de seus aplicativos por um tempo para atender a todos os usuários.

O longo histórico da Intel em hardware de 64 bits, combinado com o software que habilita a otimização, cria condições favoráveis para o avanço da plataforma em tablets e smartphones. Sem as limitações de memória e velocidade, projetar software para o mundo mobile agora depende somente da imaginação dos desenvolvedores e como eles decidirão usar esse poder.

***

Artigo traduzido com a autorização do autor. O original está disponível em https://software.intel.com/en-us/blogs/2014/09/16/how-64-bit-computing-will-improve-the-mobile-experience 

We know that in order to truly enjoy your feeds, you have to be able to organize them. That’s why we’ve introduced a bunch of enhanced tools to help you create, reorder, and prioritize your feeds and folders. 

You can find these tools on the new Subscriptions management page. Click on your user name in the upper right hand corner to get there. Among all of the functions there, you can now sort feeds and folders alphabetically or however you like to read them.

We hope you enjoy the improved subscription management page features, including alphabetizing your feeds and moving feeds to a folder. Let us know what you think about them. In the meantime, we’ll continue to fine-tune your experience to make it even easier to get your fix of all your favorite feeds. 

Bitbucket helps teams build better software through collaboration. Our customers want tools they can trust and software that won’t break under stress or load. Robustness, reliability, and security are very important attributes of our software. But, like any other software, sometimes things may go wrong. Anticipating those situations and building good diagnostics and recovery features in the product is crucial.

Quality at Bitbucket

Our Bitbucket team doesn’t include an army of dedicated testers who would spend weeks before the release to find bugs. That’s inefficient and creates a sub-optimal split of responsibilities that leads to poor quality. Instead, we take a very different approach. Every developer on the team is responsible for the quality of the software. But not every developer is good at testing. That’s why we have a very small team of QA engineers whose primary goal is to enable every developer to do a better job with quality. It is usually achieved through the following tasks:

• Developer education: Help the development team learn best practices for writing high-quality code.
• Risk assessment: Think through all the possible scenarios that can cause the software to break and ensure that developers are aware of the highest-risk areas.
• Trend analysis: Analyze bugs and support requests to spot scenarios that have caused problems, and find ways to prevent similar problems in the future.
• Tool development: Provide test environments and new tools that help the development team ship high-quality software.

That’s why QA in our team stands for “quality assistance” and not “quality assurance”.

The challenges of scale

But it’s not that simple, especially if you’re building high-quality products at ever-increasing speed and scale with a small QA team. As Adrian Cockroft once said “scale breaks hardware, speed breaks software and speed at scale breaks everything!”. There are tons of problems to solve. Most importantly, there is a dire need for innovative approaches and tools.

Good engineering practices

In order to achieve our goals of building quality at scale we use some of the following tactics, which we are happy to share with the Bitbucket community:

• Branching model – Follow a branching model using git that enables the use of pull requests for code reviews. Having a second pair of eyes looking at every code change helps spread the knowledge within the team and spot potential problems early.
• Code documentation – Write code that is self-documenting and as readable as possible. This is crucial for effective collaborative work on the same codebase and helps new starters get up to speed with the code base quickly.
• Comprehensive tests – Create unit tests, system-level integration tests and performance tests to verify the functionality under load and varying environments and scenarios.
• Internal Dogfooding – Demo new features to a large audience of internal users to solicit feedback from different software teams.We sometimes use new features and components for months internally before we release them to our customers.
• Feature flags – Implement new features behind flags that allow us to roll them out slowly, starting with a small group of internal users at Atlassian, and then widening the audience to a segment of Bitbucket users.
• “Blitz” testing – Use a coordinated, short (~1-2 hour) round of exploratory testing of a new product or feature(s) by a group of people from across the company. This gives us extra confidence that we definitely handled all those different use cases.
• Right tools – Use static analysis tools to detect common coding problems. Track exceptions in real time in all of our environments and measure everything to ensure the entire system is working as expected.

This is just the tip of the iceberg. If you’re interested to learn more about how we do QA at Atlassian and if you’re in Austin, TX on 9th of December – join us for meetup and drinks. We’re also hiring, so check out this page if you’re interested.

Post written by Kostya Marchenko, QA Team Lead for Developer Tools at Atlassian

Detalhes aparentemente sem importância podem ter grandes impactos na produtividade e eficiência no trabalho. Vamos entender a importância da comunicação e aprender a valorizar um elemento fundamental na comunicação, o feedback.

A comunicação pode ser tida como a troca de entendimento entre pessoas, e informações entre máquinas. Sem ela é impossível qualquer relação interpessoal dentro ou fora do ambiente de trabalho.

Os elementos da comunicação são:

• O emissor e o receptor
• A mensagem
• O canal de propagação
• A resposta (feedback)
• O ambiente (ruído)

Todos os elementos da comunicação são igualmente importantes, mas hoje vou falar especificamente de um vilão da comunicação, a falta de feedback. Existem muitas teorias sobre este elemento.

Porém, no momento, vou me referir ao tipo mais simples de feedback. Geralmente expressado por um ok, legal, beleza, entendi, um jóia ou acenar de cabeça.

Mensagem enviada e mensagem recebida

Os e-mails tornaram-se parte integrante da comunicação no trabalho e são peça fundamental para realização de algumas tarefas, que hoje em dia, estão relacionadas à troca de informações importantes ou até indispensáveis para o funcionamento de algumas empresas.

Não é incomum assistir um funcionário cobrando determinado e-mail que deveria ter recebido e a contra-parte responder com um indignado; mas eu mandei! Tenho certeza!

Mensagem enviada não significa que foi recebida. O correto aqui seria enviar um e-mail importante solicitando a confirmação ou feedback. A comunicação entre pessoas refere-se a entendimento da mensagem e encerra-se na confirmação de recebimento, não antes.

O exemplo do e-mail serve para ressaltar uma falha de comunicação que acontece até em uma conversa, pessoalmente. A ferramenta (e-mail) neste caso foi o canal de propagação e não passa de um vetor do que acontece no face a face.

O mau hábito de supor coisas

O princípio do desentendimento está no hábito de supor coisas. Achar que o outro recebeu sua mensagem é o primeiro erro. O segundo, está no ato de quem recebe a mensagem e nunca confirma.

Algumas pessoas são assim; você diz algo, elas recebem a informação, mas não dizem nada. Como geralmente sabe-se que elas entenderam, surge o mau hábito de supor que elas sempre recebem suas mensagens.

Até o dia em que o ambiente (ruído) as impossibilite de ouvir.

Como nunca respondem, você não saberá identificar o momento em que não escutaram. Irá deduzir que entenderam sua mensagem e pronto. Traz o rolo de papel higiênico.

A comunicação em prol da produtividade

O ambiente onde a comunicação é eficiente também é produtivo. Pesquisas comprovam que 80% dos problemas nas empresas são oriundos das falhas de comunicação e muitos deles podem ser evitados apenas valorizando o feedback.

Faça seu ambiente de trabalho mais produtivo simplesmente disseminando a cultura de confirmar todas as mensagens recebidas e pedir a confirmação das que são enviadas. Basta um – Ok.

O bom hábito de confirmar todas as suas mensagens pode até servir de álibi quando esquecerem de passar aquele recado importante. Afinal, não adianta alguém falar que lhe deu determinada mensagem se você não confirmou o recebimento.

Comunicação sem confirmação é monólogo.

E aí? Recebeu minha mensagem?

The post A importância do feedback para a comunicação na empresa appeared first on DoceShop Blog.

As empresas realizam revisões periódicas de acesso a rede e aplicações, por que não revisar também o firewall? Posso afirmar, a partir da experiência do dia a dia, que as corporações podem até manter em dia seu controle interno de acesso a rede e aplicações da empresa, mas muitas vezes não fazem uma boa faxina em seus firewalls. E é aí que mora o perigo.

Parte motivada por auditorias, políticas de acesso ao ambiente interno e atenta aos acessos (de novo, quase sempre internos), a TI acaba parando na análise de contas-órfãs e do permissionamento nas aplicações de negócio, postergando a revisão dos firewalls para uma oportunidade que quase nunca chega. Por que? Se revisar credenciais em sistemas já é complexo, imagine então auditar centenas ou milhares de regras de acesso em diversos dispositivos de rede. Trata se de uma tarefa praticamente impossível de se realizar manualmente e que muitas vezes é deixada de lado pois a rede “continua funcionando” apesar de tudo.

Só que, infelizmente, isso acaba sendo porta de entrada para os indesejados ataques, roubos de informações, invasões de servidores. Empresas convivem anos com scripts espiões. Por que? Porque eles estão utilizando portas do firewall que não deveriam estar acessíveis, mas estão. Entra tecnologia, sai tecnologia, e o problema continua lá. O risco e a exposição do ambiente também continuam lá. Qual é a saída que o gestor de TI tem à sua frente, diante desse cenário tão complexo?

Começar a olhar o problema do ponto de vista estratégico – e não do ponto de vista apenas operacional. Isso significa pensar em soluções para a gestão das ameaças ao ambiente corporativo, e não apenas fazer a verificação eventual nas regras e níveis de permissionamento, ou preocupar-se somente ao acesso que determinados grupos da organização têm. É preciso alçar o olhar para um horizonte mais adiante.

Inúmeras pesquisas realizadas no país mostram que o gestor brasileiro acaba sendo reativo à segurança: só vai tomar medidas preventivas depois de sofrer um ataque. Ou seja, há uma ênfase maior na gestão de incidentes em detrimento da gestão de riscos. Na prática, o que ocorre é o aumento da exposição da organização à quebra de sigilo de informações, até a deterioração da imagem e reputação da empresa, dependendo da severidade da invasão.

Por isso, ao investir em um nova tecnologia, os gestores deveriam olhar para dentro de casa e se perguntar como melhorar a gestão do que já existe. E hoje já existem soluções para auditoria, gestão de regras e revisão de políticas de acesso em dispositivos de segurança para automatizar funções que, dependendo do tamanho do ambiente, são impossíveis de serem executadas manualmente.

Ou seja, é possível é possível fazer uma gestão integrada e automatizada das regras de acesso em seus firewalls e dispositivos de rede, sem ter que trocar todo seu equipamento, ou realizar mudanças drásticas no ambiente. O segredo é olhar para dentro de casa e sempre perguntar onde é possível melhorar com os recursos existentes. Antes, é claro, que uma invasão motive essa tarefa, transformando-a numa penosa lição.