Feeds Para Programadores

Mais uma dica de meu amigo +Charles Rockenbach   que fezum gif dessa minha excepcional jogada que merecidamente deveria ser exibida no Fantástico! Fora isso a ferramente que ele usou para criá-lo  que é o objeto desse post http://gifyoutube.com/ cria gifs a partir de vídeos hospedados no Youtube! Demais!

1 Message 2 _id : integer # 3 key_remote_jid : text #Identificador da conversa (-1 se de nenhuma) 4 key_from_me : integer #1 para mensagens minhas, 0 para mensagens de terceiros 5 key_id : text # identificador 6 status : integer #[0,4,5,6,8,10] 7 #0,10 Não enviado por mim 8 #4,5,6,8 Enviado por mim 9 #4 enviado para grupos conseituais(nem sempre reais) 10 #5 para PVT 11 #6 Criação de grupos, adições de usuários 12 #8 Envio áudio 13 #10 envio de áudio 14 needs_push : integer # 15 data : text #Texto se foi uma conversa 16 timestamp : integer #data de criação (unix) 17 media_url : text #URL para download externo da mídia 18 media_mime_type : text #tipo da mídia 19 media_wa_type : text #[1,2,3,4,5]: 0 - Texto ou evento do WA,1- imagem, 2-audío, 3 - Vídeo, 4-Contato, 5-Localização 20 media_size : integer #tamanho da mídia (se áudio ou vídeo) 21 media_name : text #nome da mídia se existir 22 media_hash : text

É importante respeitar os diferentes critérios SEO para melhorar a visibilidade do seu aplicativo móvel Android na Google Play. Quais são os mais importantes? Que ações realizar para proporcionar maior visibilidade à sua aplicação e aumentar o número de downloads? Critérios de SEO relativos à descrição da aplicação Nome do aplicativo Descrição da descrição Logo da aplicação Captura de tela de aplicação Categoria Critérios de SEO exterior à aplicação Classificação geral Opiniões Total de downloads do aplicativo Links retorno Ferramentas Mais informações Critérios de SEO relativos à descrição da aplicação Estes critérios de SEO são próprios aos elementos de descrição de uma aplicação Android em vista de sua aplicação na Google Play. Nome do aplicativo O nome do aplicativo corresponde à baliza "title", e como para o SEO natural de uma página web, é crucial para SEO otimizar sua aplicação móvel para Android no Google Pla

Escrever testes unitários é uma parte importante do ciclo de desenvolvimento de um app Android, já que isso encoraja uma abordagem de desenvolvimento incremental, e permite que o código seja facilmente refatorado para uma melhoria continua. Os testes unitários tem muita relação com dependências ou sobre substituir dependências por testes dublês(test doubles)[0]. Isso permite que você rode seus testes o mais isolados possível. Mas isso levanta a questão de como você pode criar de maneira eficaz, testes dublês no seus testes unitários. Uma maneira de se criar testes dublês no Android é usando o Mockito [1]. Mockito é um framework open source que oferece uma API fluente e legível, que permite tanto testes baseado em estado (state-based-testing, stubbing) assim como testes de comportamento (behavioral-testing, verifications) [2]. Para começar com o Mockito no seus testes unitários, você precisa incluir a seguinte dependência no seu arquivo build.gradle [3]: dependencies {     andro

A emergencia é um dos princípios fundamentais da agilidade, e é a coisa mais próxima da magia pura. Propriedades emergenciais não são projetadas ou vêm prontas, elas simplesmente acontecem como um resultado dinâmico do resto do sistema. “Emergencia” vem do Latim da metade do século 17, que significa “ocorrência não prevista”. Você não pode planejá-la ou agendá-la, mas pode cultivar um ambiente em que a deixe ocorrer, se beneficiando dela. Um exemplo clássico de emergência está no comportamento dos bandos de pássaros. Uma simulação de computador pode usar apenas três regras simples (parecidas com “não colida-se com outros”) e de repente você tem comportamento complexo quando o bando vai batendo as asas graciosamente pelos céus, se remodelando em torno de obstáculos e assim por diante. Nenhum desses comportamentos avançados (como se remodelar na mesma forma ao redor de obstáculos) é especificado pelas regras; eles emergem da dinâmica do sistema. Regras simples, como na simul

Um dos tópicos mais polêmicos do livro Getting Real é o “Comece com Não”. Certa vez eu fiz alguns comentários sobre este ponto e ficou claro que algumas pessoas simplesmente não concordam com ele. Acredito que o grande vilão neste caso são as consultorias e empresas de software que desde que sejam pagos aceitam criar qualquer tipo de funcionalidade solicitada pelo cliente, mesmo as mais ridículas delas. E isto de forma indireta acaba nos influenciando, mesmo quando estamos construindo nossa própria empresa. Não me entendam mal, consultorias foram criadas exatamente para isso e este é o negócio delas. Quando uma empresa contrata uma consultoria para desenvolver seu software, normalmente é isso o que ela espera, gerar uma lista de demandas e ser atendida. (Hoje podemos encontrar algumas consultorias com filosofias um pouco diferentes, mas estou falando da maioria) O que não podemos esquecer, entretanto, é que o livro Getting Real não trata desde ramos especifico de

Este texto é uma tradução do artigo escrito por Chris Wanstrath, onde ele explica os benefícios de aplicar os princípios do Getting Real na construção do GitHub . Você pode encontar a versão original (em inglês) aqui . Decidi traduzir este artigo, porque considero o GitHub como um caso de sucesso e a forma como ele foi desenvolvido é inspiradora para todos aqueles que desejam “cair na real”. Bom proveito! Getting Real desde o primeiro dia Temos empregado o Getting Real (com grande sucesso) no GitHub desde o primeiro dia. Não porque quisemos, ou porque pensávamos que seria o única coisa certa a fazer. Fizemos isso porque não tivemos escolha. Tom Preston-Werner e eu estávamos trabalhando em tempo integral em outras startups quando começamos o GitHub. Este era apenas um trabalho secundário. Compartilhar repositórios em Git era muito difícil. Os sites existentes exigiam que se configurasse tudo na mão, o que era uma dor de cabeça. Sem perceber, passamos a adotar o Get

Caindo na Real Bem vindos à primeira das traduções mundiais completa do livro 'Getting Real'. Totalmente em Português. capítulo 1 Introdução capítulo 2 A Linha de Largada capítulo 3 Permaneça Enxuto capítulo 4 Prioridades capítulo 5 Seleção de Funcionalidades capítulo 6 Processo capítulo 7 A Organização capítulo 8 Contratando capítulo 9 Design de Interface capítulo 10 Código capítulo 11 Palavras capítulo 12 Precificação e Assinatura capítulo 13 Promoção capítulo 14 Suporte capítulo 15 Pós-Lançamento capítulo 16 Conclusão Introdução capítulo 1 O que é Caindo na Real? Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software. Caindo na Real é sobre pular todas as coisas que representam a realidade (cartas, gráficos, caixas, setas, esquemas, wireframes, etc.) e realmente construir a coisa real. Caindo na Real é menos. Menos massa, menos software, menos funcionalidades, menos papéis, me