Instalando CocoaPods para gerenciar dependências no desenvolvimento iOS

CocoaPods é uma forma de gerenciar dependências de bibliotecas no seu projeto de app. Quem está acostumado a usar o Java já deve ter trabalhado com Maven, quem está acostumado com Rails já deve ter utilizado o Gem. CocoaPods foi desenvolvido baseado no funcionamento e syntax do Gem. Definindo o Podfile. Abra em um editor de texto o arquivo Podfile:

Script de snapshots do xen server

O script abaixo foi desenvolvido em python para realização dos snapshots e exportação dos mesmos para arquivos nos servidores que rodam o xenserver. Tal script ainda precisa de melhorias, principalmente de performance. Espero que possam ajudar, caso interesse a vocês, fazendo um fork e alterando no github.

MySQL script de backup com python

Venho pesquisando formas eficientes de realizar backup de todas as bases de dados do meu banco MySQL. Até o momento só estou conseguindo realizar o backup full das minhas bases. E venho usado o script abaixo:

O desenvolvimento não é completamente meu. Eu busquei muita coisa na internet, mas devido ao tempo que faz, eu não consigo mais me lembrar exatamente onde.
Na proxima versão pretendo conseguir fazer o backup full apenas 1 vez na semana, e um backup diferencial 2 vezes ao dia. Até o momemnto estou pensando em usar simplesmente 2 scripts e uma configuração no cron da máquina de backup. Vamos ver como ficará.

Recuperar senha do MySQL

Você pode recuperar a sua senha do MySQL seguindo apenas 5 passos simples.

SQLite - VACUUM

O comando VACUUM recontroi a estrutura da base de dados. Há várias razões para um aplicativo pode fazer isso:

• A menos que SQLite esteja sendo executado em modo "auto_vacuum = FULL". Quando uma grande quantidade de dados é excluído da base de dados, deixa-se um grande espaço vazio, ou páginas "livres" na base de dados. Isso pode causar uma base de dados ocupando mais espaço em disco do que o estritamente necessário.
  Executando VACUUM para reconstruir a base de dados recupera-se este espaço e reduz o tamanho do ficheiro de base de dados.


• Inserções, atualizações e exclusões frequentes podem causar um arquivo de banco de dados fragmentado - onde os dados de uma única tabela ou índice estará espalhado em todo o arquivo de banco de dados.
  Execução do comando VACUUM garantimos que cada tabela e índice serão armazenados de forma contínua dentro do arquivo de banco de dados. Em alguns casos, VACUUM pode também reduzir o número de páginas parcialmente cheios no banco de dados, reduzindo o tamanho da base de dados adicionalmente.


• Normalmente, o page_sizer e o suporte(ou não) ao auto_vacuum devem ser configurados antes do arquivo de banco de dados ser criado. Entretanto, quando o modo write-ahead log não esta habilitado, as opções page_size e/ou auto_vacuum de um arquivo de banco de dados já existente podem ser modificados usando as PRAGMAS e logo em seguida o arquivo sofrerá o VACUUM. Caso a propriedade write-ahead log esta habilitada apenas a funcionalidade de auto_vacuum pode ser modificada usando o VACUUM.

O comando VACUUM pode alterar os IDs das células que não possuirem uma INTEGER PRIMARY KEY explicita.
O VACUUM falhará caso exista alguma transaction aberta, ou se houver uma ou mais instancias do SQL quando esse comando rodar.

SQLite - Configurações de PRAGMAs

Configuração de PRAGMAS do SQLite
PRAGMA cache_size
Apesar do site de referência falar dessa PRAGMA você NÃO DEVE USÁ-LA. Trata-se de uma função descontinuada pelo SQLite.

PRAGMA synchronous
O valor boleano synchronous controla se a biblioteca irá esperar ou não pela escrita no disco estará completa antes de continuar qualquer outra operação. Esta opção pode ser diferente da pragma default_synchronous lida do SQLite.
Algumas vezes o SQLite pode perder muito tempo apenas esperando o sistema de arquivos do sistema. Mudando a opção para "PRAGMA synchrounous=OFF" pode-se obter maior velocidade.
Valores possíveis:
0 - OFF: O banco rodará sem sincronização com o disco e em casa de falha do sistema tudo será perdido. Apesar da insegurança, a aplicação ficará 50 vezes ou até mais rápido que o normal.
1 - NORMAL: O SQLite ainda sincronizará, mas com menos frequencia do que no modo FULL
2 - FULL: Opção mais lenta, em compensação o SQLite manterá sempre a base sincronizada no disco e no caso de qualquer falha o risco de perda de dados é bem menor.

PRAGMA count_changes
Apesar do site de referêcia falar para usar essa PRAGMA... Você NÃO DEVE USÁ-LA. Trata-se de uma função descontinuada do SQLite.

PRAGMA temp_store
Essa opção configura onde os arquivos temporarios são salvos. Se ficam apenas residentes na memória ou são usados arquivos temporários no disco. Os valores da PRAGMAtemp_store são:
0 - Sempre usar arquivos temporários.
1 - Usar arquivos por padrão mas permite que o PRAGMA temp_store configure o uso da memória.
2 - Usar a memória como padrão mas permite que o PRAGMA temp_store configure como padrão o uso de arquivos.
3 - Sempre usar a memória.

SQLite - Truques para melhor velocidade

O SQLite pode ser muito rápido. Já ouvi alguns reclamando que ele é bem lento. Bem... Existem alguns métodos para conseguir uma melhor velocidade dele. Aparentemente a prioridade do mantenedor do projeto SQLite não é a velocidade. Mas a integridade e a verificabilidade dos mesmos.
Você, provavelmente, sabe que a parte mais lenta do SQLite, assim como muitos outros bancos de dados, é o acesso ao disco se compararmos com as leituras feitas em memória. Existem algumas coisas que podem ser feitas para melhorar esse desempenho, algumas delas bastam algumas configurações, outras precisa-se recompilar o fonte, entre elas:
(em ordem aproximada de eficiência)

• Use uma base de dados em memória


• Use BEGIN TRANSACTION e END TRANSACTION


• Use índices(index)


• Use a PRAGMA cache_size


• Use a PRAGMA synchronous=OFF


• Compacte a base de dados (VACUUM)


• Substitua a biblioteca de alocação de memória


• Use a PRAGMA count_changes=OFF

fonte: SQLite Optimization FAQ

SQLite Transaction no iOS e Android

O SQLite tem a implementação de transações. Não é tão sofisticado quanto na maioria dos bancos de dados. Por se tratar de um sgbd simples e para ser embarcado junto a aplicação mas que se você souber usar... É realmente muito bom.

Usando FMDB no iOS é simples usar o transaction, assim:


No Android as coisas ficarão assim:

Espero que isso possa ajudar um pouco quem tem sofrido com a velocidade do insert a base.

SQLite - Quando não usar?!

Certo, sabemos que o SQLite muitas coisas legais, conforme pode ser visto aqui, que é bom para isso e aquilo e que é fácil de portar e não sei o que. Mas então, quando não usá-lo?

• Altas taxas de transação - O SQLite é capaz de suportar taxas moderadas de transações, mas ele é incapaz de dar acesso simultâneo a um registro. A concorrência do SQLite depende de bloqueios de arquivos para que a base fique protegida contra perda de dados. Assim é possível permitir a leitura desta base de dados para muitos cliente, mas esta base de dados estará bloqueado para qualquer tipo de escrita. Isso acarreta na serialização das operações de escrita. O que acaba por limitar a taxa de transação global da mesma.
• Base de dados muito grandes - É possível escalar arquivos de banco de dados de 2TB no SQLite, mas há custos de memória (RAM) associados a grandes bases. Uma base de dados de 100GB exigiria a alocação 25MB de RAM antes de cada transação, isso aumentaria de forma linear conforme a base de dados cresce. Outro ponto importante de se informar é que a base de dados do SQLite é apenas um arquivo. Consequentemente esse tamanho da base de dados estará ligado ao tamanho máximo que o sistema de arquivos do sistema operacional consegue armazenar. Em um sistema FAT o máximo seria de 4GB.
• Controle de Acesso - SQLite não tem dados de autenticação e autorização. Em vez disso, SQLite depende das permissões do sistema de arquivos para controlar o acesso ao arquivo de banco de dados em bruto. Isto essencialmente limita o acesso a um dos três estados: completar acesso leitura / gravação, acesso somente leitura, ou nenhum acesso. O acesso de escrita é absoluta, e permite que tanto a modificação de dados e a capacidade para alterar a estrutura da base de dados propriamente dito. Embora a API SQLite fornece um mecanismo de autorização de base da camada de aplicação, é trivial para contornar se o usuário tem acesso direto para o arquivo de banco de dados. Em geral, isso torna SQLite inadequado para lojas de dados sensíveis que requerem por usuário controle de acesso.
• Cliente / Servidor - Como foi projetado para ser embarcado junto com a aplicação, ele não possui internamente um componente de rede. Não há suporte nativo para fornecer acesso a vários computadores através de uma rede, tornando-se uma má escolha como um sistema de banco de dados cliente/servidor.
• Replicação - Não tem suporte interno para replicação de banco de dados ou redundância. Replicação simples pode ser obtido copiando o arquivo de banco de dados, mas isso deve ser feito quando nada está a tentar modificar o banco de dados. Sistemas de replicação pode ser construído na parte superior do API banco de dados de base, mas tais sistemas tendem a ser um tanto frágeis. Em geral, se você está procurando replicação em tempo real, especialmente em uma transação segura nível-você precisa olhar para uma plataforma de RDBMS mais complexa.

Então... Recomendo que use para substituir aquela sua porcaria de rotina que salva as informações em arquivos CSV e passe a usar algo realmente funciona e que é extremamente simples.

SQLite - Caracteristicas básicas.

Quando se fala em banco de dados, ou SQL, vem logo a mente grandes SGBDs como Oracle, PostgreSQL, MySQL e SQL Server. Mas o SQLite por ser facilmente portável para qualquer plataforma(movél ou não), compacto, eficiente e confiável. Tornou-o a engine de banco mais usada no mundo.
As principais características do SQLite são:

• Serverless - Não precisa-se de um banco de dados servidor de banco de dados para se trabalhar com SQLite já que ele fica e apenas um arquivo e fica incorporado ao seu projeto.
• Zero Configuration - Nenhuma configuração ou administração é necessária.
• Cross-Platform - O SQLite foi projetado para ser facilmente portável. Podemos citar como sistemas com suporte a ele: Windows, Linux, BSD, Mac OS X, Solaris, HPUX, AIX. Plataformas embarcadas como o QNX(que será base para o novo BBOS), VXWorks, Symbian, Palm OS, Windows CE, iOS, Android, Meego, Windows Phone 7 e tantos outros...
• Self-Contained - Não há dependências externas para que se possa compilá-lo.
• Small Runtime Footprint - A implementação padrão toma menos de 1MB de código, e apenas alguns megabytes de memoria. Com alguns ajustes o tamanho da biblioteca e o uso de memoria podem ser reduzidos significativamente.
• Transactional - As transações do SQLite são ACID(atômicas, consistentes, isoladas e duráveis). Mesmo que as transações sejam interrompidas por um problema no programa, ou falha do sistema operacional ou uma falha de energia do computador.
• Full-Featured - O banco de dados suporta grande parte da query language do padrão SQL92(SQL2).

Liberar memória ram no Mac OS-X

Seu mac osx é como o meu? Vive travando por causa do gerente de memória que é uma bosta? Você não esta afim de comprar aqueles programas que prometem limpar a memória para se livrar do que está inativo nela?
Existe uma solução bastante simples que poucos usam no MaxOS-X que poucos usam. Usar o bendito do terminal. Os amigos que usam Linux estão muito mais acostumados a usá-lo que os usuários costumeiros do mac.
Bem o comando é bastante simples:

$purge

Pronto. Você acaba de fazer tudo que aqueles programas prometem fazer para você de uma forma extremamente simples só que de graça.

Instalando o MongoDB + PHP5 + Lighttpd no Debian Squeeze (6.0.5)

Se você pretende usar um banco de dados noSQL, recomendo que use o MongoDB.
Para isso recomendo que tenha um Debian operando em x64. Apesar de existir uma versão i386, o MongoDB foi projetado para funcionar e tirar total proveito da arquitetura de 64bits, além do fato de se aproveitar o mapeamento de memória ram feita por tal processador de forma nativa. Você até poderá instalá-lo no i386, mas vai dar muito problema. Então faça o certo.
A instalação é bastante simples como poderá ver nos passos abaixo

Wordpress no Debian Squeeze (6.0.5)

Mais breve do que isso para instalar o Wordpress impossível. Hehehe. Espero que seja útil para quem estiver pretendendo colocar o próprio sistema de blog ou expandir.
Recomendo que comece a configuração pelo post anterior.

Instalar MySQL + Lighttpd + PHP5 no Debian Squeeze (6.0.5)

Script para backup de DataBases SQLServer - parte 01

Um problema comum no mundo de banco de dados são os backups. Realizar diversos backups de diversas bases manualmente é tarefa de estagiário corno. As vezes as coisas podem parecer mais complicadas do que realmente são. Por isso esse tutorial mostrará como fazer o backup de suas bases de seu banco de forma simples e rápida. Usar o SQLManager e os planos de manutenção são uma boa. Mas as normalmente o bom e velho script tem um comportamento mais simples e mais fácil de se manobrar.
Como podemos gerar backups usando o T-SQL? Simples:

BACKUP DATABASE DBNAME TO DISK = "c:\backup.bak"

Esse seria o mais simples de todos, fazendo de um só banco, vc colocando o nome do seu banco. Mas e se você tiver diversos bancos e não está com a menor paciência pra escrever várias linhas iguais a essa para fazer o backup de cada banco? Ou ainda e se você possuir diversos servidores, com cada servidor com diversos bancos que precisam ter um backup e não terá tempo para escrever nome por nome de banco?
Bem, agora sim as coisas poderiam ficar complicada, mas a verdade é que essa complicação não existe. Veja:


Simples e objetivo, resolve seu problema de fazer diversos backups de uma única vez e sem ter que ficar colocando nome por nome. Esse backup é um backup full. Você pode procurar formas de fazer backups incrementais e coisas assim...

Nos próximos talvez eu me aprofunde nisso.