Desde o primeiro livro vendido, ainda na editora BRASPORT, em 2007, uma das minhas principais metas sempre foi o suporte. Eu sabia que este seria o diferencial que eu poderia construir para que, no futuro, pudesse vender livros por conta própria. E isso foi construído e mantido ao longo dos anos e das publicações. Felizmente consegui chegar ao nível de vender livros sem editoras, e ter a credibilidade necessária necessária para este empreendimento.

Hoje, os livros comprados na Loja Flex não possuem editoras, eu sou o “gerente” que faço praticamente tudo. Escrevo, diagramo, faço a capa, envio para a gráfica, vendo e dou suporte. Com isso consegui atingir um nível muito bom de qualidade, porque com um lucro maior os autores conseguem escrever com mais calma e geram assim uma obra com mais qualidade. Através da editora, os autores tem prazo em contrato e recebem 10% do valor do preço de capa. É isso mesmo, 10%.  Com isso livros de tecnologia passam como desinteressantes para a maioria das pessoas. Com o foco nesse mercado, eu tenho certeza que o suporte seria um dos meus diferenciais e a continuidade dele é o caminho para que eu possa vender mais. Ou seja, quando você compra um livro comigo, tem sempre que quiser o suporte através do email suporte@flex.etc.br, com os assuntos relacionados a obra. O suporte até agora só me trouxe benefício, primeiramente porque tenho a oportunidade de melhorar a obra e também conhecer um pouco mais do perfil do leitor. Baseado nisso consigo criar as futuras obras de acordo com o que os leitores querem.

Apenas para mostrar que o meu suporte realmente é levado a sério, estou publicando a seguir algumas das longas conversas que tenho com todos os meus leitores. Lembre-se, ao comprar meus livros, você também terá todo o suporte necessário, você vai aprender flex !!

Veja que todos os emails são respondidos:

A seguir alguns suportes mais complexos, mas que na maioria das vezes são resolvidos:

Bom, estes são apenas alguns exemplos, desde Novembro/2010. Se fosse colocar tudo esse post ficaria interminável . A idéia aqui aqui é mostrar que o suporte funciona, que você vai ser respondido e terá o auxílio que precisa!

Então? Quer aprender Flex? Acesse agora loja.flex.etc.br e confira nossos livros.

Neste segundo semestre do ano estamos tendo vários eventos com temas focados em Ruby ou eventos genéricos mas com espaço para a linguagem.

Apenas em Julho e Agosto tive o prazer de participar de 6 desses eventos. Uma coisa fica bastante claro, o interesse por Rails tem crescido assustadoramente.

Quando comecei a estudar a linguagem Ruby e framework Rails por volta de 2006 era comum ouvir que Ruby/Rails eram apenas modinhas e que logo isso tudo morreria.

Hoje é muito gratificante ver que esta “modinha” evoluiu para algo bem sólido no mundo todo e aqui no Brasil estamos começando a conseguir o mesmo resultado.

Isto fica bem nítido quando participamos dos eventos e vou compartilhar com vocês um pouco de como tem sido participar deles :

Mini-curso do RailsMG na UNA

Mensalmente fazemos encontros do nosso grupo, o RailsMG. Até entao nao tknhamos feito nada voltado para o publico que está interessado em começar no Ruby e no Rails.

Pensando nisso aplicamos um mini curso no meio de Julho onde eu fui o instrutor. O local para o treinamento foi cedido pela UNA e com lotação aproximada de 60 pessoas.

No esperávamos chegar perto da lotação mas o mais impressionante é que as 60 vagas foram preenchidas em menos de 5 horas.

O curso correu perfeitamente e foi bem interessante para conhecer várias pessoas de BH que tem interesse na tecnologia e mostrar um caminho por onde começar.

Os slides podem ser vistos aqui

FISL

No final de Julho, com um convite Maúricio Portal, tive o prazer de participar do FISL em Porto Alegre. Também um mini-curso mas desta vez com 6 horas (ao invés de 4 como o do RailsMG).

O curso foi quebrado em três dias com 2h por dia. No primeiro dia tivemos lotação máxima no auditório e o pessoal participou bem, com várias perguntas. O receio era que nos dias seguintes talvez o interesse diminuiria, mas isto não ocorreu e tivemos o auditório cheio nos 3 dias.

O mais interessante é que no último dia tivemos 6 horas de palestras de Ruby. Começamos com uma apresentação perfeita do Fábia Akita sobre o ecossistema Rails. Mostrando que Rails não é apenas um framework mas um plataforma sólida, focada em empreendimento e que caminha sozinha sem investimento de nenhum gigante como MS ou Oracle.

Na sequência tivemos mais uma palestra do Akita sobre boas práticas de desenvolvimento web usando a ferramentas do Ruby como exemplo. Para terminar o dia eu concluí com as duas horas restantes do mini-curso.

O resumo geral do FISL foi sensacional, vários contatos interessantes e deu para rever muita gente da comunidade Ruby e fazer aquele pós evento com direito a hora extra original com o pessoal do Rio.

Os slides do Mini-curso estão aqui.

EDTED BH

Em Julho recebi um convite da Arteccom para o EDTED de BH. O tema seria uma introdução ao Rails mas como evento coincidiu com o OxenteRails e eu já tinha confirmado com a organização do Oxente acabei não podendo comparecer ao EDTED (infelizmente).

Mas não podíamos deixar o EDTED sem uma palestra de Rails então Bruno Alves da Dito aceitou convite e a palestra parece ter sido um sucesso ( já era o esperado vindo do Bruno .

OxenteRails

Sobre o Oxente Rails, em Natal, não tenho palavras suficientes para descrever o evento.

Acabei indo de última hora e também não tinha comparecido no ano anterior então eu não sabia muito bem o que esperar.Mas o evento superou todas as expectativas possíveis. Extramente bem organizado e com palestrantes de auto nível.

O evento correu em duas trilhas paralelas e eu imaginei que não teria audiência para lotar os dois auditórios mas foi o contrário.

Foi bem legal para reencontrar a comunidade toda e conhecer pessoas como Caike da Envylabs, Geoffrey do Peepcode, Arthur Geek e várias outras pessoas que não vou me lembrar agora.

Quantos as palestras, pessoalmente gosto mais de conteúdo técnico e nesta linha as que me chamaram mais antenção (das poucas que assisti) foram as do Caike sobre refactoring e a do Geoffrey sobre sugestões de arquitetura em Rails.

Eu falei sobre Steak e você pode ver os slides neste link

Sobre o oxente eu só tenho a agradecer ao Paulo Fagiani, Annaysa e toda a equipe da Tink (Rafael, Anderson, etc). E claro não posso esquecer do Vinicius Teles por me fazer abrir o olho e enviar um tema para o evento e não deixar a oportunidade passar.

<iframe src=”http://player.vimeo.com/video/14350633?byline=0&amp;portrait=0&amp;color=b30000″ height=”304″ width=”540″></iframe>

Definitivamente o evento mais importante de Rails do Brasil (já que Rails Summit virou RubyConf .

Serpro

Duas semanas após o Oxente eu ministrei uma apresentação sobre o ecossistema Rails no Serpro MG a convite da Kátia, Alexandre e Harley (mais uma vez obrigado aos três).

Para o conteúdo eu usei boa parte da palestra que o Akita usou no FISL (com autorização dele). É um conteúdo que acho perfeito para dar uma visão geral de como caminha a comunidade em volta do Rails.

Os slides da palestra você encontra aqui

Próximos eventos

Durante este meio tempo também concluímos um treinamento da Egenial com 40 alunos e houveram vários eventos que não tive como comparecer. Destaque para o RSonRails e o encontro do pessoal do Rio.

Nos próximos meses vamos participar do seminário de “computação da UFOP” e também teremos uma palestra de Ruby na Inforuso, que está sendo organizado pelo Márcio Sete. Também não dá para esquecer do encontro de sábado agora (amanhã) do RailsMG.

Conclusão

Com todos esses eventos acontecendo e com o resultado fica bem claro que o interesse por Ruby no Brasil está começando a explodir agora.

Outra coisa que percebi é que mesmo com tantos eventos este interesse crescendo, são poucos os desenvolvedores mais experientes. Então é muito importante que os organizadores de evento tenham isso em mente.

Apesar de nós que trabalhamos como Rails a bastante tempo querermos eventos mais pesados e com conteúdo mais avançado, somos a minoria e qualquer evento no Brasil que carregue Ruby ou Rails no nome deve lembrar-se do iniciantes ao menos em algum momento na grade.

Além de introdução ao Ruby e ao Rails também é importante introdução a temas como TDD, Git, automatização de deploy e tudo mais que já é cotidiano de desenvolveres Ruby.

Nos vemos na Ruby Conf

Em duas semanas a Egenial dará inicio a um novo curso, um treinamento para empreendedores chamado de Mockup.

Você sendo proprietário do seu negócio ou mesmo trabalhando como contratado em uma empresa precisa ser um empreendedor.

Mas o ponto mais atrativo para nós desenvolvedores é que como o próprio nome diz somos profissionais com o objetivo de construir algo. No entanto muitas vezes ficamos presos em tecnologias novas e desafios técnicos que na verdade não interessam muito para o produto final.

Ter a visão de colocar as coisas em prática independente da tecnologia é muito importante tanto para um funcionário de uma empresa de software ou um fundador de uma startup aplicando uma nova idéia.

Mesmo já estando com a faca e queijo na mão e na grande maioria das vezes habituados ao desenvolvimento para clientes, criar um saas ou produto qualquer envolve muito mais coisa.

Vou citar um exemplo: a parte técnica central do Cifras foi desenvolvida em pouco mais de um mês incluindo o design. É o tempo normal para desenvolvimento de um projeto para um cliente também.

Mas o que não é perceptível a primeira vista é o que está por trás do sistema. Por exemplo existe um painel administrativo que foi sendo evoluído com base nos problemas e necessidades (ver quais usuários pararam de acessar, inadimplentes, bloquear contas, etc).

Além disso também temos todo o sistema de automatização de deploy, backups e servidor de homologação.

Também temos o site público que envolve o sistema de suporte através de FAQS criados por um CMS (cada pedido de suporte que chega mais de uma vez acaba sendo convertido em um FAQ por outro painel administrativo).

Claro ainda existem outra decisões como formas de marketing, análise de mercado, melhores formas de suporte, burocracias com formas de pagamento e etc. Além de saber filtrar sugestões alinhadas com as prioridades do produto.

Ao ter uma ideia interessante normalmente você acaba esquecendo todas estas decisões importantes e que tornam a criação de um produto um trabalho colossal.

Acredito que este curso o ajudará bastante a ter uma visão completa para criar uma solução prática e por apenas R$120,00.

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.

Não é segredo algum que eu sou fã do produtos da Apple. A grande maioria das vezes que uso algo deles a única coisa que penso é como uma empresa tão grande consegue propagar um nível de qualidade tão alto para todos os seus produtos (software e hardware) e tento aprender um pouco com isto.

Fase inicial: susto!

Porém, no lançamento do iPhone OS 4.0 (que achei fantástico) uma coisa me assustou muito. A cláusula 3.3.1 do TOS do SDK da Apple, que resumindo é: Só vamos aceitar apps em Obj-c e derivados de C++, além de apps em Javascript que usam o Webkit.

A minha primeira reação foi: “que p&@#ra é essa?” . Eles vão acabar com as plataformas PhoneGap, Rhodes, MonoTouch e outras? Não faz sentido.

Honestamente eu duvido que eles vão negar apps em Titanium e PhoneGap pois a própria cláusula defende estas tecnologias. São tecnologias que basicamente empacotam uma web app feita em HTML5+CSS3+JS no componente WebView (que utiliza o >Webkit<) de forma que possa ser compilada e vendida na App Store. Você também ganha acesso a várias api’s como GPS, câmera e etc.

As outras plataformas como o Flash CS5 com certeza estão fora e não serão mais aceitas na App Store.

Fase 2: pensamento.

Todos que acompanham o meu trabalho sabem que gosto muito dos produtos da Adobe, principalmente a plataforma Flash. Apesar de achar que ela possui diversas falhas de arquitetura (não vou detalhar isto agora) e não é de longe um produto genial como por exemplo Ruby, Smalltalk ou até Obj-c. No entanto, é fato que o Flash é muito bom para criar experiências ricas na internet.

Para web não levanto a bandeira de nada para frontend pois na minha opinião as coisas estão engatinhando. Mas para desktop a coisa é um pouco diferente.

Nos últimos 8 meses tenho dedicado boa parte do meu tempo em pesquisar plataformas para desenvolvimento desktop. Acho que testei praticamente tudo, desde Titanium e QT até Adobe AIR. E a minha opinião final é que nenhuma destas tecnologias é algo como o Rails.

Quando digo como Rails me refiro a uma plataforma onde uma equipe de 2 pessoas consiga desenvolver algo extremamente bem
feito, fácil de manter, estável, com uma experiência fantástica e em curto prazo. Todos falham em algum ponto crítico e todas
são multi-plataforma.

Fase 3: experiência de usuário e exigência.

Dependendo do grau de exigência que você tem para seus projetos, simplesmente não existe multi-plataforma. Eu poderia listar
várias coisas que não gosto em Adobe AIR ou Titanium por exemplo. Mas o mais claro é que produtos multi-plataforma para desktop destroem a experiência do usuário e entregam algo que a pessoa não espera.

Ou você acha legal uma app em Java ter a interface totalmente diferente das nativas do Mac ou do Windows? Outro exemplo é o
Kindle For Mac, sem palavras, um lixo. Ao tentar ler um livro nesta coisa a última idéia que me vem a cabeça é que eu estou
usando uma aplicação Mac. Todos os atalhos são diferentes, os ícones são diferentes, as posições das coisas são diferentes.

Eu, como usuário, não dou a mínima se é caro manter 3 versões diferentes da aplicação. Apenas espero que ela funcione como eu espero ou é melhor que ela nem exista.

Você acha que sua mãe e seu irmão querem ter que re-aprender onde ficam as coisas cada vez que abrem uma aplicação nova? Não!

E eu passei por este problema ao tentar encontrar algo para desenvolver para dispositivos móveis. Algo que fosse portável para iPhone e Android. O resultado foi que tudo que eu tentei usar criava um Frankstein e um das lados, ou seja, a app ficava com cara de iPhone e não tinha nada de Android e vice-versa.

Eu não gastaria meses em um produto onde eu não consiga entregar uma experiência excelente então a minha opção foi abandonar
o conceito multi-plataforma e focar em iPhone. Nada de Phonegap também pois você perde muito tempo tentando emular o comportamento de apps nativas e ainda fica com algo a desejar.

E quando anunciaram o Flash CS5 com suporte para apps iPhone o que logo me ocorreu (e que depois comprovei ser verdade) é que
era apenas mais uma ferramenta que vai entregar aplicações com problemas como citei acima (Frankstein’s).

Fase 4: não sei mais se a Apple está errada.

Depois de pesquisar tanto entrei de cabeça no desenvolvimento Mac em Obj-c e MacRuby. MacRuby para quem não conhece é a própria implementação da Apple da linguagem Ruby e que é totalmente compatível com Cocoa e os demais frameworks para o Mac.

A única palavra sobre os meus estudos da plataforma Mac são: um produto genial! O Interface Builder por exemplo é sem dúvida
a melhor ferramenta que conheço para criar interfaces gráficas sem gerar código bagunçado (ex.: Dreamweaver, Delphi For PHP e etc).

O XCode é bem legal e eu pessoalmente odeio IDE’s. A documentação da Apple é simplesmente excelente, com centenas de vídeos, manual bem escrito de todas as classes, forums internos, suporte e etc. E todas as ferramentas são gratuitas (já paguei pelo Mac mas o ponto aqui é outro, no Windows você pagou pelo S.O. e ainda paga pela licença da ferramenta de desenvolvimento).

Porém, mais fantástico é a linguagem e seus frameworks. O Obj-c a primeira vista assusta pois a sintaxe é bem diferente de Java, C++ ou JS (bem mais parecido com Smalltak). No Entanto logo que se acostuma percebe como é uma linguagem sólida e poderosa que bate de frente com tecnologias de alto nível como Ruby e Smalltak. Além de ser uma tecnologia que evolui a mais de 20 anos.

Ao aprender Obj-c fica óbvio o porque da qualidade do OSX. A linguagem é simplesmente fantástica, com estruturas poderosas como Key Value Coding e Metaprogramação, tudo isso sem perder performance, permitindo a criação de animações complexas com Core Animation em conjunto com ferramentas como Quartz.

E o melhor de tudo isso é que todos os recursos são condizentes. Chega a ser difícil criar uma aplicação Cocoa (framework padrão para desenvolvimento Mac e iPhone) que saia dos padrões do que estamos acostumados da experiência de usuário no Mac.

Fase 5: minha exigência começa onde termina minha preguiça.

Conversando com um amigo que defende o Flash CS5 compilar apps iPhone ele disse que tempo é dinheiro e que se já sabemos
Flash e AS3 então é bobeira ter que aprender Obj-c/Cocoa. Descordo totalmente, se algo vai ser um Frankstein e você vai ter que passar muito tempo simulando a experiência padrão em um aparelho e criando um monstro em outro então eu prefiro aprender a plataforma correta.

Se plataforma correta for sólida, fácil de manter e acessível a equipes de 3 pessoas então a minha opção como desenvolvedor e empreendedor é sem dúvida esta plataforma. E a plataforma da Apple é assim (ainda acho que falta mais foco em TDD mas isso é porque sou um cara de Ruby).

Acredito ser melhor gastar 3 ou 4 semanas de estudo intensivo para ter uma visão correta de uma plataforma nativa para criar algo realmente bom do que ser preguiçoso inicialmente e gastar meses tentando simular a experiência desejável em uma fábrica de Frankstein’s.

A única exceção ao 3.3.1

Jogos deveriam ser a única exceção. Na minha opinião a Apple deveria colocar mais um parágrafo dizendo que jogos não se aplicam ao 3.3.1.

Todos sabem a complexidade técnica para criar um jogo (eu venho da plataforma Flash antes dessas história de RIA virar moda). Até em Flash, que á pouco tempo não envolvia complexidades como 3D, é muito difícil criar uma engine de física por exemplo.

Agora imagine criar uma engine de verdade como Unreal. Imaginem o custo para isto, vai muito além da maioria dos projetos de software. Uma empresa que investe em algo assim não pode focar em apenas uma plataforma.

E para experiência do usuário eles estão mais que corretos em serem multi-plataforma. Um jogo não deve seguir nenhum padrão como um aplicação de produtividade deve. Cada interface para um game deve ser diferente, os atalhos não devem ser iguais, as janelas são diferentes e etc.

Por isso não faz nenhum sentido aplicar o 3.3.1 em jogos.

A exigência em excelência da Apple

Para quem só usa os produtos da Apple e nunca precisou estudar suas tecnologias a fundo não tem a idéia que a empresa propaga a qualidade extrema em todas ferramentas. Não é apenas criar um produto final bonitinho. Tudo é perfeito, desde a documentação ao criador de interfaces até chegar ao produto final como Mac e iPhone.

A forma como a empresa tem encarado o seu dispositivo móvel (plataforma com limitações de recursos como memória e processamento) tem sido bem interessante. Lançando todas as “features” aos poucos, enquanto a mídia e os “boateiros” bombardeiam o produto dizendo que ele falta isso e aquilo.

No entanto, quando lançam a funcionalidade que “faltava” ela vem de uma forma muito bem feia. Vejam o copiar e colar do iPhone, as pastas e o tão falado “multi-tasking”. Um sinal de preocupação em fazer tudo sempre da forma mais bem feita possível e uma preocupação muito além do que estamos acostumados.

Então, do ponto de vista da empresa, não acredito que banir os Frankstein’s seja apenas uma tentativa de criar um monopólio e vencer a concorrência no braço.

Conclusão

Não tenho certeza se o que a Apple fez é correto do ponto de vista comercial ou de marketing. Mas para o usuário como o meu pai ou minha mãe acredito que seja positivo. Eu me belisco antes de dizer isto (principalmente porque defendo tecnologias opensource como Ruby e Rail), mas também acredito ser positivo para nós como desenvolvedores de apps de produtividade, principalmente se estivermos preocupados em entregar uma experiência fantástica mas coerente.

Se existe um caminho melhor do que definir uma regra dessas eu não sei. Mas não estou nada preocupado pela Apple restringir o restante pois como pretendo desenvolver algo de qualidade para Mac/iPhone já estou focado em Obj-c/Cocoa já tem um bom tempo.

Outros posts interessantes:

• Why Apple Changed Section 3.3.1
• Steve Jobs’ response on Section 3.3.1

Conheça o Cifras, um novo produto que estamos lançando em beta público.

Com principal objetivo de simplicidade, criamos um sistema web agradável, isento dos banners, seguro, com backups diários, compromissado com sigilo e hospedado em servidores com qualidade de verdade. Este serviço é um gestor financeiro para pequenas empresas e autônomos, que da mesma forma que uma grande empresa, também dependem de saúde financeira para o sucesso.

Conheça o Cifras, um novo produto que estamos lançando, ainda em estágio beta, mas disponível publicamente.

Com principal objetivo de simplicidade, criamos um sistema web agradável, isento dos banners, seguro, com backups diários, compromissado com sigilo e hospedado em servidores com qualidade de verdade. Este serviço é um gestor financeiro para pequenas empresas e autônomos, que da mesma forma que uma grande empresa, também dependem de saúde financeira para o sucesso.

A necessidade de criar este produto surgiu em 2008, quando começamos a pesquisar formas melhores de gerir as nossas próprias finanças aqui da empresa.

Não foi difícil encontrar centenas de opções, mas depois de testar vários (mais de 50) acabamos continuando com as famosas planilhas.

Por que desenvolver um se já existem tantos?

Os sistemas não se encaixavam em nossas necessidades pelos motivos abaixo:

1º Complexidade

Não é uma hipotése aplicar algo que consome o seu tempo. Se você está gastando um dia inteiro para concluir um fechamento de mês, as coisas começam a ficar críticas, pior se a cada vez você precisa realizar um lançamento em um sistema você gasta horas.

Trabalhando em uma pequena empresa ou como freelancer, você precisa mais ainda de controle financeiro sem perder tempo. Interfaces complexas e recursos demais distraem sua atenção do foco central.

Não queremos ter que garimpar um sistema inteiro com tantas coisas, como agenda de contatos ou do índice da bolsa quando estamos apenas tentando fazer um lançamento.

2º Recursos demais

Utilizar um sistema financeiro não vai eximir a necessidade de um contador, nós sempre vamos precisar de alguém responsável por manter tudo em ordem com o governo. É impossível manter o contador totalmente atualizado com suas despesas ou projeções e com seus balanços disponíveis a todo momento.

Por isto, não precisamos de um sistema que faça cálculos complexos de juros, férias, acertos, impressões de nota fiscal ou que tenha funcionalidades demais. Só necessitamos ter acesso rápido a uma visão de como andam as coisas para poder basear as nossas decisões.

3º Banners e publicidade

A análise dos motivos do balanço atual é importante demais para ser poluída com anúncios publicitários. Várias ferramentas que testamos, principalmente as web, eram gratuitas, mas a cada momento que precisávamos olhar um relatório do mês, nossa atenção era dividida com um banner.

Prefirimos muito mais utilizar um sistema que cobra uma pequena taxa pelo serviço do que um sistema que me cobra o tempo todo através de publicidade e que ainda assim não consegue pagar uma boa estrutura para se manter com o verba levantada com estes anúncios.

4º Segurança

Computadores pessoais ou de trabalho são alvos fáceis de ataques e vírus. Por este motivo é muito mais vantajoso armazenar os dados em um aplicativo que não esteja na máquina, mas sim em um servidor que siga os padrões de segurança.

Além do servidor também não consideramos utilizar sistemas web que não utilizam uma conexão segura para no mínimo o momento do login e criação de usuários.

5º Backups

Fazemos backup das nossas máquinas constantemente, mas se por algum motivo perdermos estes dados? Um assalto acabaria com todos os nossos backups e não queremos correr o risco de perder o histórico financeiro da nossa empresa.

6º Infraestrutura e bugs

Como confiar em um sistema que ao abrir já exibe uma mensagem de erro ou que sai do ar constantemente?

Cifras, a nossa própria solução

Por estes motivos resolvemos desenvolver o nosso próprio sistema financeiro resolvendo todos os problemas acima.

Algo que qualquer pessoa aqui do escritório possa gerenciar as contas sem precisar ser um contador, ao mesmo tempo permitindo que tenhamos acesso aos relatórios, além de permitir ao contador visualizar os dados para atualizar seus registros.

Desta forma criamos um sistema web agradável, simples, isento dos banners, seguro, com backups diários, compromissado com sigilo e hospedado em um servidor com qualidade de verdade.

Estágio beta público

No primeiro semestre de 2009, jogamos fora as planilhas e desde então estamos utilizando apenas o Cifras para gestão financeira. Fazemos nossas projeções e lançamentos em segundos e emitimos relatórios de fechamento de mês ou de ano em minutos, com todos os cálculos corretos.

Em Julho começamos a receber os primeiros usuários convidados e agora em Dezembro estamos abrindo para beta público. O termo BETA significa que o sistema ainda está recebendo várias melhorias por dia, porém ele está estável. Mesmo quando ele não estiver mais em beta, por ser um sistema web, vai continuar recebendo melhorias constantemente.

Preço

Queremos manter o sistema em constante melhoria e o custo de desenvolvimento para isto é considerável. Também temos custos para manter o sistema realmente seguro com todos os certificados e uma boa infra-estrutura com servidores.

Optamos por não lançar o sistema gratuitamente e não queremos poluir o sistema com publicidade. Queremos um serviço que traga lucros para o seu negócio e que estes lucros sejam maiores que a taxa necessária para manter o sistema em plena forma.

Independente do plano que você venha a escolher, todas as contas possuem 30 dias de testes (Trial) . Temos um plano gratuito para os usuários com pouca movimentação e dois planos pagos: O plano Basic, que permite um limite maior de transações, até 3 usuários e 3 repositórios financeiros (ideal para pequenas empresas) e o plano Avanced, no qual você terá transações, usuários e repositórios financeiros ilimitados.

Beta gratuito

Já que estamos lançando o sistema agora, como uma forma de agredecimento aos nossos usuários beta, não enviaremos nenhuma cobrança até dia 31 de Janeiro.

Você não está preso

Não queremos forçar os usuários a permanecerem no serviço, por este motivo os dados são seus e você pode exportar suas categorias, transações e projeções a qualquer momento.

Cadastre-se

Se você está realmente procurando um gerenciador financeiro para o seu negócio, não perca tempo e

Conheça o PomoDo um novo aplicativo para otimizar sua produtividade utilizando os conceitos do Pomodoro Technique.

Encontrar formas de ser mais produtivo é algo que todos buscamos, e atrás desta produtividade perdida sempre andei de olho em várias técnicas que prometem tal resultado.

A última que testei e que funcionou razoavelmente bem foi o método do livro Get Things Done , mas como tenho problema para tratar com papeis acabei optando por usar o Things … tudo funcionou muito bem até eu perceber que nunca consegui aplicar a técnica direito pois exigia muita disciplina. Mas continuo usando o Things para montar minha lista de tarefas que me vêem a cabeça.

Esta falha parcial em aplicar o GTD me tornou mais cético ainda sobre estas metodologias, até que algumas semanas fui apresentado ao Pomodoro através do próprio site da ténica e resolvi testar.

A idéia do Pomodoro é bem simples e de forma bem resumida seria dividir suas tarefas em porções de 25min (que são chamadas de pomodoros) e a cada pomodoro terminado descansar 5min (na verdade 1 pomodoro são os 25min + 5min de descanso). Antes de começar seus pomodoros do dia você planeja o que deseja fazer em uma planilha e organiza as tarefas em ordem de prioridade e vai trabalhando sobre este inventário, marcando quantos pomodoros gastou, quantos interrupções teve e também gravando se por algum motivo você teve que reiniciar a tarefa.

Ao final do dia você também deve manter um registro de todas as tarefas que concluiu, assim você terá seu inventário de tarefas planejadas, um registro de tarefas concluídas e ainda vai saber com precisão quanto tempo demorou em cada uma. A técnica envolve mais coisa, explicando como proceder com tarefas não planejadas que entram no seu inventários, mas não vou entrar em muitos detalhes. A melhor parte da técnica é que você terá seus minutos de descanso sem nenhum sentimento de culpa, e ainda será muito produtivo.

Depois de testar estes conceitos na prática percebi que funcionavam muito bem, melhor do que todas as outras técnicas que eu tinha testado. Porém eu estava preso ao papel novamente e nunca lembro de manter os registros desta forma, então resolvi testar as aplicações de Pomodoro.

Testei várias para Mac e Iphone e no fim nenhuma me satisfez completamente, algumas faltavam o registro de tarefas terminadas, outras só aceitavam uma tarefa por vez na lista, outras só tinham o timer… então para não deixar a prática do Pomodoro de lado resolvi criar minha própria aplicação.

Durante o fim de semana e algumas noites da semana passada acabei criando o PomoDo que tem o objetivo de ser simples mas que tenha o inventário de tarefas, o registro de concluídas, os timers (pré-definidos para 25 e 5 minutos) e que também siga os conceitos do Pomodoro ( X = 1 Pomodoro, ’ = Interrupção, – = Pomodoro falhou ).

Como fiquei bem satisfeito com o resultado resolvi lançar publicamente esta aplicação que a batizei de PomoDo. Para fazer o download gratuito acesse pomodo.areacriacoes.com.br, a aplicação funciona tanto em Mac OS X, Linux ou Windows e foi desenvolvido utilizando Adobe Air (XHTML e jQuery).

A idéia é continuar evoluindo esta aplicação com pequenos ajustes, mas mantendo-a simples e multi-plataforma. Então se você já aplica o Pomodoro tenho certeza que o PomoDo irá ajudar, se ainda não aplica não perca tempo e procure mais sobre esta técnica que realmente funciona.

Já pensaram como seria absurdo se transportássemos para o dia-a-dia o tipo de relacionamento entre clientes que vemos com regularidade no mundo de consultoria (seja em design, desenvolvimento, etc) ?

Seria mais ou menos como o video abaixo:

 

Dica de Jamis Golick pelo Twitter