O investimento no mercado imobiliário é um jeito fantástico para gerar um fluxo de renda passiva e expandir seu patrimônio. Inúmeros estudos apontam que o investimento em imóveis criou mais milionários durante a história do que qualquer outro tipo de investimento (como este estudo e este). Então, por que não há mais pessoas fazendo isso?
Eu me perguntei exatamente isso há alguns após conversar com um grupo de amigos sobre o sucesso que tive com o mercado imobiliário e após escutar o porquê eles achavam que isso não era para eles.
A maioria deles achava que era algo muito difícil de aprender e dominar. Havia etapas demais, a curva de aprendizado era muito íngreme e havia muita possibilidade de cometer erros para alguém que estava apenas começando, especialmente ao analisar o desempenho financeiro de possíveis propriedades para investimento.
Tradicionalmente, a maioria dos investidores usava planilhas para fazer os cálculos, que só funcionava se você soubesse o que iria calcular e a forma como faria isso. Mas, se você não sabe essas informações, é muito fácil cometer erros e deixar alguns detalhes passarem batidos. Ninguém quer cometer erros matemáticos antes de uma grande compra, como uma propriedade para investimento.
Por onde começo?
Foi aí que tive a ideia de criar o DealCheck: uma ferramenta de análise de propriedade fácil de usar e baseada na nuvem para agentes e investidores imobiliários. Meu objetivo era criar uma plataforma que ajudasse novos investidores a aprender os macetes e evitar erros onerosos, mas, ao mesmo tempo, fornecer a flexibilidade para realizar análises mais avançadas com o clique de um botão.
Tornando o investimento imobiliário mais fácil e acessível.
Eu trabalhava como engenheiro de front-end na época, então já sabia que podia desenvolver a IU por conta própria, mas e o back-end, o armazenamento de dados, a autenticação e várias outras coisas necessárias para um aplicativo na nuvem completamente funcional?
Não conhecia ninguém que eu poderia incluir como cofundador, então comecei a pesquisar quais tecnologias e plataformas eu poderia aproveitar para me ajudar com a infraestrutura de back-end e do servidor.
O Firebase aparecia constantemente e comecei a procurar mais detalhes sobre ele. Na época, ele havia acabado de ser adquirido pelo Google e sua coleção de módulos BaaS (back-end-como-serviço) parecia oferecer a solução exata que eu precisava para criar o DealCheck.
Fiquei impressionado principalmente com a documentação de cada recurso e a maneira como todas as tecnologias diferentes podiam ser reunidas para criar uma plataforma unificada.
Logo abri uma conta e comecei a criar o primeiro MVP do app.
Como o único desenvolvedor no projeto, eu tinha pouco tempo e recursos para gastar desenvolvendo o back-end. Assim, decidi usar cada recurso do Firebase que estava disponível na época.
Meu objetivo, na realidade, era escrever o mínimo possível de código do lado do servidor e, em vez disso, me concentrar em aproveitar os diferentes módulos do Firebase para resolver três desafios específicos:
O primeiro desafio era a autenticação e o gerenciamento de usuários. Os usuários do DealCheck precisavam criar contas para que pudessem visualizar e analisar as propriedades em qualquer dispositivo (falarei mais sobre isso depois). Eu queria poder fazer login com e-mail, Facebook ou uma conta do Google.
O Firebase Authentication foi desenvolvido especialmente para esse propósito, e usei o recurso para gerenciar grande parte do processo do fluxo de gerenciamento. Como ele vem pronto, tem compatibilidade com a maioria das redes sociais, vinculação de credenciais em redes cruzadas e operações básicas de gerenciamento de conta, como alterações de e-mail, redefinições de senha e exclusões de conta.
Não precisava de qualquer código no lado de servidor. Eu só precisava criar uma IU no front-end.
Login com e-mail, Facebook e Google oferecido pelo Firebase.
Outro benefício do Firebase é que o Firebase Authentication se vincula diretamente ao produto Realtime Database para criar permissões declarativas e estrutura de controle de acesso que seja fácil de implementar e manter. Isso me ajudou a garantir que os dados do usuário fossem protegidos contra acesso não autorizado e facilitassem o compartilhamento de informações entre usuários.
O armazenamento de dados era o próximo item na lista. Eu queria que os usuários do DealCheck pudessem usar o app e analisar as propriedades on-line, no iOS e no Android. Por isso, eu precisava de uma solução de banco de dados baseada na nuvem e em tempo real que pudesse sincronizar dados entre dispositivos.
Sincronizar dados na Web e em dispositivos móveis não é fácil!
O Firebase Realtime Database é uma solução de banco de dados NoSQL baseada em JSON, que foi projetada exatamente para essa finalidade. Eu fiquei surpreso com o bom funcionamento dela. Usei as vinculações oficiais do AngularJS do Firebase no front-end para ler e gravar diretamente a partir do cliente.
Precisei trabalhar um pouco mais na parte móvel para implementar um modo off-line com sincronização após reconexões, mas, no geral, o código necessário para fazer tudo funcionar foi mínimo.
Como mencionei, o Firebase Authentication vinculou diretamente ao banco de dados para facilitar o controle de acesso. Assim, meu trabalho aqui havia terminado. Pude configurar backups diários de todos os dados automaticamente com apenas o clique de um botão.
Até agora, eu não havia escrito sequer uma linha de código no lado do servidor, e tudo estava sendo gerenciado diretamente pelo cliente. No entanto, à medida que o desenvolvimento do DealCheck avançou, eu sabia que precisaria de um servidor para gerenciar algumas operações que não poderiam ser feitas no cliente.
Eu não tinha muita experiência com manutenção de servidor e DevOps, mas felizmente, o produto Firebase Cloud Functions conseguiu atender a todas as minhas necessidades. As Cloud Functions são basicamente funções de objetivo único, que podem ser acionadas (ou executadas) com base em uma solicitação HTTP ou eventos específicos oriundos do Authentication, do Realtime Database ou de outros produtos do Firebase.
Cada função pode ser executada uma vez com base em um evento específico que acionará a execução da tarefa descrita. Você não precisa se preocupar com provisionar uma instância de servidor ou gerenciar uma carga. Tudo é feito automaticamente pelo Firebase.
Sabe o que é ainda mais legal? As Cloud Functions podem acessar os intervalos do Realtime Database e Cloud Storage do mesmo projeto, realizando operações neles no lado do servidor, quando necessário.
É assim que o DealCheck processa pagamentos de assinatura pelo Stripe, valida recibos de assinatura móvel pelo Apple e Google Play, se integra a APIs de terceiros e atualiza o registro de bancos de dados sem interação de usuários.
Incluindo dados de vendas comparáveis de fornecedores terceirizados para o DealCheck.
As Cloud Functions são como “cola” que unem toda a infraestrutura de back-end.
A primeira versão do app do DealCheck foi desenvolvida e lançada em menos de 5 meses, e eu estava sozinho na equipe de desenvolvimento. Eu realmente não achava que seria possível sem o Firebase oferecendo a infraestrutura de back-end. Talvez o projeto nem fosse lançado.
Embora o Firebase seja incrível para o desenvolvimento rápido de MVP, ele certamente foi projetado para também alimentar aplicativos de produção. À medida que o DealCheck cresceu de um pequeno projeto secundário para um dos apps imobiliários mais populares com mais de 100 mil usuários, todos os produtos do Firebase que usamos se dimensionaram para oferecer suporte para o aumento de carga.
Além disso, a interoperabilidade fantástica de todos os módulos do Firebase nos permite desenvolver e lançar novos recursos muito mais rapidamente porque precisa de menos código e possui fácil configuração.
Então, na próxima vez que você estiver pensando em desenvolver um projeto ambicioso com uma equipe pequena, confira como o Firebase pode ajudar você a reduzir o tempo de desenvolvimento e fornecer um pacote de ferramentas eficazes que crescem junto com sua empresa.
Foi exatamente assim como o DealCheck cresceu de uma ideia simples para tornar a análise de propriedades mais rápida e fácil para um app que ajuda dezenas de milhares de pessoas a aumentar seu patrimônio e renda passiva com verdadeiro investimento imobiliário. É uma experiência realmente incrível e gratificante ver seu trabalho afetar positivamente tantas pessoas, e isso não seria possível sem o Firebase.
O programa Recompensas de segurança do Android (ASR, na sigla em inglês) foi criado em 2015 para recompensar os pesquisadores que encontram e relatam problemas de segurança, ajudando a manter o ecossistema do Android protegido. Nos últimos quatro anos, premiamos mais de 1.800 relatórios e pagamos mais de US$ 4 milhões.
Hoje estamos expandindo o programa e aumentando os valores das recompensas. Anunciamos um prêmio máximo de US$ 1 milhão por uma exploração de execução remota de código em cadeia completa com persistência que comprometa o elemento de segurança Titan M em dispositivos Pixel. Além disso, lançaremos um programa específico que oferece um bônus de 50% para explorações encontradas em versões de visualização específicas para desenvolvedores do Android, o que significa que nosso maior prêmio agora é de US$ 1,5 milhão.
Como mencionado em uma postagem anterior do blog, em 2019, a Gartner avaliou o Pixel 3 com Titan M com as classificações mais “fortes” na seção de segurança integrada em todos os dispositivos verificados. Por isso, criamos um prêmio dedicado a recompensar os pesquisadores por explorações encontradas que contornem as proteções dos elementos de segurança.
Além das explorações que envolvem o Pixel Titan M, adicionamos outras categorias ao programa de recompensas, como as relacionadas a exfiltração de dados e desvio do bloqueio de tela. Essas recompensas chegam a US$ 500 mil, dependendo da categoria de exploração. Para ver todos os detalhes, consulte a página das regras do programa Recompensas de segurança do Android.
Agora que falamos sobre as novidades, recapitularemos fatos marcantes deste ano. Veja alguns destaques de 2019:
A maior recompensa paga a um membro da comunidade de pesquisa foi por um relatório de Guang Gong (@oldfresher), da Alpha Lab, Qihoo 360 Technology Co. Ltd. Esse relatório detalhou a primeira cadeia de exploração de execução remota de código com um clique no dispositivo Pixel 3. Guang Gong recebeu US$ 161.337 do Programa de recompensas de segurança do Android e US$ 40 mil do Programa de recompensas do Chrome, totalizando US$ 201.337. A recompensa combinada de US$ 201.337 também é o maior valor pago por uma única cadeia de exploração em todos os programas de recompensa de vulnerabilidade do Google (VRP, na sigla em inglês). As vulnerabilidades do Chrome apresentadas no relatório foram corrigidas no Chrome 77.0.3865.75 e lançadas em setembro, protegendo os usuários dessa cadeia de exploração.
Queremos agradecer a todos os nossos pesquisadores por contribuírem com a segurança do ecossistema do Android. Se você tiver interesse em se tornar um pesquisador, confira nossa Bughunter University para ter informações sobre como começar.
A partir de hoje, 21 de novembro de 2019, as novas recompensas entram em vigor. Todos os relatórios enviados antes de 21 de novembro de 2019 serão recompensados com base na tabela de recompensas anterior.
A temporada de caça aos bugs está aberta!
Quando se trata de serviços gerenciados do Kubernetes, o Google Kubernetes Engine (GKE) é uma ótima escolha se você procura por uma plataforma de orquestração de contêineres que ofereça escalonabilidade avançada e flexibilidade de configuração. O GKE oferece controle completo sobre todos os aspectos da orquestração de contêineres, desde rede e armazenamento até a forma como a capacidade de observação é configurada. Além disso, ele é compatível em casos de uso de aplicativos com estado. No entanto, caso seu aplicativo não precise desse nível de configuração e monitoramento de cluster, o Cloud Run totalmente gerenciado pode ser a solução certa para você.
O Cloud Run totalmente gerenciado é uma plataforma sem servidor ideal para microsserviços em contêiner sem estado, que não exigem recursos do Kubernetes como namespaces, localização conjunta de contêineres nos pods (arquivos secundários) ou alocação e gerenciamento de nós.
O Cloud Run, uma plataforma gerenciada de computação sem servidor, oferece diversos recursos e benefícios:
Implantação fácil de microsserviços. É possível implantar um microsserviço em contêiner com um único comando, sem a necessidade de outra configuração específica do serviço.
Experiência do desenvolvedor simples e unificada. Cada microsserviço é implementado como uma imagem do Docker, a unidade de implantação do Cloud Run.
Execução sem servidor escalonável. O escalonamento de um microsserviço implantado no Cloud Run gerenciado é feito automaticamente com base na quantidade de solicitações recebidas. Não é necessário configurar nem gerenciar um cluster do Kubernetes completo. Se não houver solicitações, o Cloud Run gerenciado escalonará para zero. Ou seja, nenhum recurso será usado.
Compatibilidade com códigos escritos em qualquer linguagem. O Cloud Run usa contêineres como base. Assim, é possível escrever códigos em qualquer linguagem, usando qualquer binário e biblioteca.
O Cloud Run está disponível em duas configurações: como um serviço totalmente gerenciado do Google Cloud e como o Cloud Run para Anthos (essa opção implanta o Cloud Run no cluster do Anthos GKE). Se você já usa o Anthos, o Cloud Run para Anthos pode implantar contêineres no seu cluster. Assim, é possível acessar tipos de máquinas personalizados, suporte de rede adicional e GPUs para melhorar os serviços do Cloud Run. Os serviços gerenciados do Cloud Run e os clusters do GKE podem ser criados e administrados completamente do console e da linha de comando.
O melhor disso é que é possível mudar sua escolha, alternando do Cloud Run gerenciado ao Cloud Run para Anthos ou vice-versa, sem precisar implementar o serviço novamente.
Para ilustrar esses pontos, vejamos um exemplo de caso de uso: um serviço que adiciona, atualiza, exclui e lista endereços.
É possível implementar esse serviço de gerenciamento de endereços por meio da criação de um microsserviço em contêiner para cada operação. Após as imagens terem sido criadas e registradas em um registro de contêiner, você pode implantá-las no Cloud Run gerenciado com apenas um comando. Quando os quatro comandos forem executados (uma implantação para cada microsserviço), o serviço estará ativo e operará em uma plataforma completamente sem servidor. A imagem a seguir mostra a implantação usando o Cloud Spanner como o banco de dados subjacente.
Para casos de uso como esse, o Cloud Run gerenciado é uma ótima escolha porque o serviço de gerenciamento de endereços não exige configurações complexas, de acordo com o que é compatível com o Kubernetes. Além disso, esse serviço não precisa de gerenciamento de cluster 24 horas por dia nem supervisão operacional. A execução desse serviço de gerenciamento de endereços como contêineres no Cloud Run é a melhor estratégia para a carga de trabalho de produção.
Por ser uma plataforma de computação gerenciada, o Cloud Run gerenciado é compatível com configurações essenciais: é possível definir as solicitações simultâneas máximas que um único contêiner recebe, o tamanho da memória de alocação para o contêiner e o tempo limite da solicitação. Não são necessárias configurações nem operações de gerenciamento adicionais.
O Cloud Run gerenciado e o GKE são ofertas poderosas para diferentes casos de uso. Antes de escolher, verifique se entendeu os requisitos de serviço funcionais e não funcionais, como a capacidade de escalonar para zero ou de controlar a configuração detalhada.
Pode ser que você queira usar as duas opções ao mesmo tempo. Uma empresa pode ter aplicativos complexos com base em microsserviços que exijam os recursos avançados de configuração do GKE e outros que, mesmo sem essa necessidade, queiram aproveitar a facilidade de uso e a escalonabilidade do Cloud Run.
Para saber mais sobre o Cloud Run, acesse nosso site e siga o guia rápido.
As primeiras impressões são muito importantes no local de trabalho. Muitas vezes, elas ocorrem por meio de documentos ou apresentações que compartilhamos com outras pessoas. Erros ortográficos ou gramaticais podem causar distrações e fazer com que uma proposta pareça não profissional, algo que todos nós queremos evitar. Estamos focados em oferecer recursos de escrita mais úteis no G Suite para auxiliar você a fazer seu melhor trabalho. Por isso, no começo do ano, apresentamos as novas ferramentas de correção gramatical no Documentos Google para ajudar as pessoas a escrever de forma mais rápida e precisa. Com a ajuda do aprendizado de máquina, já são mais de 100 milhões de sugestões de gramática sinalizadas a cada semana.
Avanço das sugestões de gramática com a tradução automática neuralAtualmente, o sistema de correção gramatical do Google usa a tecnologia de tradução automática. Cada sugestão é tratada como uma tarefa de tradução. Nesse caso, o conteúdo é traduzido do idioma da “gramática incorreta” para o idioma da “gramática correta”. Em um nível básico, a tradução automática substitui e reorganiza as palavras de um idioma de origem para um idioma de destino. Por exemplo, a substituição de uma palavra originária do inglês (“hello”) para uma palavra em espanhol (“hola”).
Com os avanços mais recentes da nossa equipe de pesquisa na área de processamento de linguagens, possibilitados pela tradução automática neural, estamos melhorando significativamente a maneira como corrigimos erros linguísticos por meio da correção de gramática neural no Documentos Google.
Como funcionaComo a Correção de erros gramaticais (GEC, na sigla em inglês) pode ser vista como uma “tradução” de sentenças gramaticalmente erradas para frases corretas, é possível aplicar modelos sequenciais desenvolvidos para tradução automática neural a essa tarefa. Para treinar modelos de qualidade, geralmente precisamos de milhões ou bilhões de exemplos de dados paralelos em que cada amostra de treinamento consista em uma sentença no idioma de origem pareada com a tradução no idioma de destino. Ao contrário de outras tarefas de tradução automática (como traduzir do inglês para o francês), há pouquíssimos dados paralelos para GEC. Com o objetivo de superar esse desafio, desenvolvemos dois métodos contrastantes para gerar grandes quantidades de dados paralelos para GEC.
O primeiro método traduz sentenças corretas para algum outro idioma e, em seguida, passa novamente para inglês, causando perda de qualidade.
O segundo método extrai pares origem/destino dos históricos de edição da Wikipédia com uma quantidade mínima de filtros.
Você pode ler mais sobre GEC e algumas das nossas abordagens neste artigo.
Para garantir que seria viável implantar os modelos no Documentos Google sem usar uma quantidade absurda de recursos de computação, usamos Unidades de Processamento de Tensor (TPUs, na sigla em inglês). As TPUs forneceram aumentos substanciais no desempenho de muitos outros produtos do Google, inclusive a Escrita inteligente no Gmail. Além disso, usamos a biblioteca do TensorFlow de código aberto do Google, Lingvo. Com ela, foi possível testar facilmente alterações de modelagem e otimizar de forma cuidadosa como as sugestões seriam geradas pelos núcleos de TPU.
O que isso significa para os redatoresQual o significado disso para você? Ao aplicar modelos de tradução automática neural à correção gramatical, conseguimos corrigir muitos outros erros gramaticais que você pode cometer enquanto escreve. Para lançar essas melhorias, fizemos muitos testes com o objetivo de garantir que as mudanças sejam mais úteis. Veja alguns exemplos do nosso processo de avaliação que demonstram os recursos da correção de gramática neural:
Qual o tempo verbal mesmo?
O correto é “steak” ou “stake”?
A mudança para o método de tradução automática neural apresenta um aumento notável no resultado de sugestões de correção gramatical no Documentos Google. Esperamos que essa atualização possa continuar facilitando sua escrita.
use_preemptible_nodepool()
copydata
train
train(2)
"invisible"
"activatable"
autofocus
font-optical-sizing
list-style-type
disc
decimal
::before
list-style-position
Worklet.addModule()
AbortError
SyntaxError
self.serviceWorker
self.serviceWorker.state
error
load
<script>
