O que faremos quando o filipe terminar o video-maker about video-maker HOT 40 OPEN

Sensacional! Apesar de que não estou interagindo nas issues, estou lendo todas e está fascinante a energia que todo mundo está colocando nos PRs, principalmente quando abre já falando que sabe que não vai ser feito o merge, mas só para deixar sua ideia/participação.

Gravei um vídeo ontem e estou na correria de edição e depois desse vou tentar acelerar ou ao menos compactar os vídeos para conseguir chegar no fim da POC o mais rápido possível 👍

Uma das coisas que eu miraria para o futuro do projeto é desacoplar o backend totalmente para que possamos criar um front (seja web, app, ou o que seja) para a pessoa conseguir montar um pipeline de robôs, e a issue #73 já é um ótimo começo. Hoje o que temos é apenas um pipeline fixado por um script.

Nesse pipeline customizado a pessoa pode escolher quais robôs ela quer adicionar no meio da produção e por consequência vai gerar um output diferente.

Se a gente conseguir isolar cada responsabilidade muito bem isolada, com uma interface padronizada, dá pra construir muita coisa em paralelo e ir longe com esse projeto.

Parabéns ao envolvimento de todo mundo :)

from video-maker.

Novidade, barra de progresso para promises.

from video-maker.

Ótima discussão turma e exato, esse repositório aqui vai ter uma semântica mais voltada para mostrar na prática o que é uma POC e feita de uma forma que fique melhor de explicar dentro dos vídeos.

Mas só depois com o envolvimento de vocês que eu percebi o quão grandioso as coisas poderiam ficar... eu tomei um susto na verdade, preciso ser sincero kkkkk 😍

@leodutra Sobre fatiar o projeto/robôs em vários repos, o cuidado que eu tomaria é procurar entender se isto é um sinal de complexidade causado por não sabermos exatamente como manejar o projeto. Qual o tradeoff envolvido nesta separação? Temos com clareza o ganho, que é o isolamento do código e forçar interfaces melhores... mas o que perdemos? Bato muito nesta tecla principalmente quando vejo empresas com projetos grandes como Google e Facebook adotando a estratégia do monorepo.

Talvez de início, para dar o primeiro passo no MVP, o que eu faria é uma estrutura em que voltasse com a idéia de uma pasta inteira por robô e dentro dela o robô pode ser implementado em qualquer linguagem e pudesse ser servido pelo https://zeit.co/now por exemplo.

E ai fazendo o próprio advogado do diabo com a própria idéia, isso também é um tradeoff, em que o ganho é convergir todo mundo a um mesmo local (e isso ajuda no envolvimento das pessoas, percepção de atividade no projeto, na geração de idéias e facilita movimentações estruturais) mas a perda é na gestão do que pode se tornar um grande repositório (muitas issues, muitos PRs com conflito dado a evolução do projeto).

Independente disso, eu criaria/manteria a idéia org com certeza absoluta e matou a pau em reservar o nome 👍 mesmo que só tenha um repositório de início caso a idéia do monorepo seja válida... porque esse projeto pode ser tão grandioso, nós podemos envolver tanta gente legal, que não vai caber mais dentro do meu namespace. A gente mantém esse aqui como referência educacional (com a combinação dos vídeos) e principalmente mostrar como o envolvimento da comunidade open source do Brasil foi poderosa e criou ao final algo muito melhor e maior.

from video-maker.

Pessoal, tudo bem?

Eu vou dar um gás na gravação dos vídeos (mas enfileirar a edição), pois assim eu consigo chegar no final do código mais rápido para liberar vocês a tocarem o projeto como for melhor.

O tradeoff disso é que, os vídeos no canal e o que está no repositório vão ficar dessincronizados, pois o código no repositório vai estar na frente dos vídeos (que vão continuar sendo editados/publicados semanalmente). Mas acho que vale a pena, principalmente quando eu chegar na Live de conclusão, vocês já poderem também apresentar algo legal sobre a continuação do projeto 👍

Fechado?

from video-maker.

Pessoal, criei a org video-maker para segurar o nome.
Uma sugestão é criarmos repos diferentes para transformadores ou conectores do video-maker
a fim de permitir sempre extensibilidade sem deixar o flow principal grande e confuso.

É claro que isso seria um progresso continuado após o Filipe finalizar as publicações sobre.

Assim poderiamos ter na org:
video-maker
video-maker-watson-nlu
video-maker-watson-image-recognition
video-maker-google-trends
video-maker-adove-premiere
video-maker-linux-renderer
...

O video-maker ficaria sendo um orquestrador de chamadas aos módulos e da renderização.

Se houver concordância, podemos usar a org.
Passarei o owner ao @filipedeschamps.

Por enquanto, comecei ontem a fazer merge dos PRs e refatorar o código para comportar o máximo de melhoria antes de quebrar os módulos.

Continuarei o processo hoje.
O código está no meu fork, nesta branch: https://github.com/leodutra/video-maker/tree/core-improvements

Abraço e bom trabalho à todos. Se tudo der certo, seremos os top 50 do YouTube, Facebook, Vimeo e WhatsApp. 🤣

from video-maker.

@leodutra caraca que sensacional!! 👏 👏 👏

from video-maker.

Uma dica e sugestão. As vezes é simples de fazer uma parada. Então façam. Coloquem como issue ou ideias. O Filipe nao vai ficar dando aval disso ou daquilo. É importante tomar iniciativa. Já valida a ideia. Testa. Tem aceitacao ou nao... etc. Entao mandem os pulls.. abram as issues por ai vai.. organizamos isso..

Faça o fork crie uma branch. Sincronize com esse repo master como fazer isso? . Vamos acertando essa dinamica de trabalho :)

Exato. O filipe já deu aval de fazermos o que quiser nos nossos repos, sem mexer no dele. Bora fazer

Só acho importante @leodutra termos os robos com acesso via API REST, assim o cliente que a consome pode ser ser qualquer um, angular, vue, react, electron, android, ionic, nativescript e/ou outros. Neste ponto você concorda, certo?

from video-maker.

Eu estou fazendo o projeto e aprendendo bastante com ele. Sempre tive o interesse de aprender Javascript e o @filipedeschamps me incentivo bastante com o conteúdo e didática.

Eu pensei em quando terminar o projeto implementar um novo robô que realizasse um tweet toda vez que publicar um vídeo novo como uma forma de divulgar o vídeo.

from video-maker.

Uma coisa que estou tentando mudar, mas talvez volte atrás, é a estrutura de content.
O fato de todas as funções mudarem o content é side-effect e ele leva a problemas arquiteturais, ne principalmente manutenção, pois requer que todo o fluxo seja consciente do state.

É algo que pode não ser sentido porque o sistema ainda é pequeno e uma só pessoa teve consciência do flow completo do state. Mas isso pode e vai mudar.

Separei as APIs em uma pasta apis e estou mantendo as funções o mais puras possível.
Assim, apenas o workflow principal será realmente consciente do state e pode utilizar qualquer outra das partes como units totalmente individuais.

Este é um projeto com grande chance de ser ajudado por um Rx.js, para criar workflows que lembra muito a estrutura de thenables que o Filipe e vocês gostam, mas com alguns poderes maiores em paralelismo e reatividade... mas isso é enhancement do enhancement. Apenas uma ideia.

from video-maker.

Muito bom @leodutra ! A ideia é que cada peça (robo) do video-maker seja totalmente stateless, pura, sem side effect. Chegaremos lá!

Também penso que cada funcionalidade seja uma API em express ou restify, e não um fluxo contínuo do console. Assim, tendo uma API, podemos criar clients em react/angular/vue para consumir os robozinhos

Vamos conversando mais sobre isso, OK?

Exatamente. Esta ferramenta tem muito potencial para ser utilizada como um FFmpeg... headless.

Por enquanto estou apenas fazendo o merge dos PRs do pessoal. A maioria das coisas que temos virou apenas funcões na pasta apis. Estou juntando mais e mais apis e mantendo opções... como Google Trends por RSS/API, Wikipedia com e sem uso do Algorithmia, etc.

Continuo removendo todos os side-effetcs possíveis para deixar o flow principal livre para fazer a ordem ou usar cada função como quiser.

Não fiz merge de Babel pois acho desnecessário. Não incluí nem underscore ou lodash para continuarmos usado apenas o ES*. Linting e Jest foram mergeados.

Estou deixando os robots para resolver por último, por enquanto apenas tenho organizado código e fixado erros.

Estou no modo Goku da dopamina, então estou aproveitando para jogar o projeto ainda mais para a frente e atrair mais mãos.

from video-maker.

Fazer o trampo a gente faz. Organiza, arruma nego, sei la. Faz uma lista de task, nego puxa, resolve, faz pull. Nao tem mta treta.. Sou do time q vamos fazer, vamos pra cima, se tiver problema gente resolve.. a ideia o projeto seja colaborativo. MAior problema das empresas hj eh arrumar gente.

Esse projeto hj
173 watches
842 stars
172 forks

porra.. nego pra caralho pra ajudar.. pensar mais no colaborativo.. mais no desenvolver.. ajudar.. resolver..

quem chegar e nao tiver no rip.. alguem ajuda.. eu ajudo.. sei la.. tamo ai na atividade :)

from video-maker.

@leodutra acho super massa sua ideia, quero vê-la o no seu repo rsrs

Tomara que apareça mais pessoas, implementado em python, em go, rust... Seria lindo de se ver

from video-maker.

No open source isso funciona para organizar um backlog, mas a execução é FIFO.
Tem gente que chega, gente que esfria, ...

from video-maker.

Ótima discussão turma e exato, esse repositório aqui vai ter uma semântica mais voltada para mostrar na prática o que é uma POC e feita de uma forma que fique melhor de explicar dentro dos vídeos.

Mas só depois com o envolvimento de vocês que eu percebi o quão grandioso as coisas poderiam ficar... eu tomei um susto na verdade, preciso ser sincero kkkkk

@leodutra Sobre fatiar o projeto/robôs em vários repos, o cuidado que eu tomaria é procurar entender se isto é um sinal de complexidade causado por não sabermos exatamente como manejar o projeto. Qual o tradeoff envolvido nesta separação? Temos com clareza o ganho, que é o isolamento do código e forçar interfaces melhores... mas o que perdemos? Bato muito nesta tecla principalmente quando vejo empresas com projetos grandes como Google e Facebook adotando a estratégia do monorepo.

Talvez de início, para dar o primeiro passo no MVP, o que eu faria é uma estrutura em que voltasse com a idéia de uma pasta inteira por robô e dentro dela o robô pode ser implementado em qualquer linguagem e pudesse ser servido pelo https://zeit.co/now por exemplo.

E ai fazendo o próprio advogado do diabo com a própria idéia, isso também é um tradeoff, em que o ganho é convergir todo mundo a um mesmo local (e isso ajuda no envolvimento das pessoas, percepção de atividade no projeto, na geração de idéias e facilita movimentações estruturais) mas a perda é na gestão do que pode se tornar um grande repositório (muitas issues, muitos PRs com conflito dado a evolução do projeto).

Independente disso, eu criaria/manteria a idéia org com certeza absoluta e matou a pau em reservar o nome mesmo que só tenha um repositório de início caso a idéia do monorepo seja válida... porque esse projeto pode ser tão grandioso, nós podemos envolver tanta gente legal, que não vai caber mais dentro do meu namespace. A gente mantém esse aqui como referência educacional (com a combinação dos vídeos) e principalmente mostrar como o envolvimento da comunidade open source do Brasil foi poderosa e criou ao final algo muito melhor e maior.

Então, deixa eu tentar passar a visão que estou tendo.
Como estou separando os conectores, scrappers e transversores de dados em uma pasta de APIs - totalmente burra quanto ao que os robots fazem, mas ainda voltadas para o uso dentro dos robots - vamos acabar com arquivos como "watson.js", "google-trends.js" e outros. Estes seriam os módulos que futuramente eu separaria na org.

Assim teríamos:

video-maker
video-maker-google-trends
video-maker-youtube
video-maker-watson
video-maker-algorithmia

Por dois motivos: gestão de versão melhor, usando NPM. Digamos que eu tenha um video-maker customizado e a API do Google Trends mudou. Fazemos a manutenção apenas naquele módulo e qualquer um pode decidir usar a versão A ou B como melhor lhe suprir.

Isso também traz uma grandiosidade com o poder da comunidade. Qualquer um passa a poder criar uma nova API e esta não vai tornar o projeto principal mais convoluto.

O segundo ponto são os robots. Podemos criar robots sem side-effects e utilizá-los em um video-maker customizavel, onde cada robot e api pode ser acoplado com alguma convenção... como uso de JSON descriptor e pequenos lambdas entre um robot e outro para atribuir variaveis e outras transformações. Mas ainda não achei uma solução prática para criação deste workflow por quem não saiba programar...

Mas o que eu quero com isso? Um tipo de:

• pego um robot de trends
• um robot de conteudo da NASA
• um robot de Vimeo
• faço um workflow que adiciona anotações de uma API do Evernote
• done

ou

• pego um robot de Twitter
• outro de tradução para russo
• robot de publicacao russo
• done

É claro, como eu havia dito antes, com a separação modular isso é um futuro bem bem futuro possível; como outros que poderemos vislumbrar;

Mas separando API, de robot de e minimizando side-effects - ou seja, fazendo com que cada robot tenha um input e output totalmente ignorante sobre outros robots ou mesmo o content... permitimos que tudo seja colado ou separado conforme as exigências de uma produção.

O Video-Maker, na sua melhor forma futura, seria um motor de workflow de robots e API customizável... onde toda a comunidade gira em torno de criar módulos. Arrastando caixinha tipo Unreal Engine... ou apenas tendo um código limitado mas modular e preparado para crescer.

De qualquer maneira, damos mais poder à pipeline de script, pois seus componentes apenas realizam algo e sem se preocupar com o contexto (content) e criamos um tipo de IFTTT com vários inputs, transversers e outputs.

from video-maker.

Merge das últimas mudanças do Filipe feitas no fork onde estou reunindo melhorias
leodutra@a183d65

from video-maker.

Estou reinstalando o Windows para testar os merges de After Effects.
Em algum momento seria bom usar o Kdenlive ou o Blender para renderizar no Linux / cross-platform.

Tive uma ideia legal para a customização de workflows:
https://developers.google.com/blockly/

Lembrei que já vi isso em 2 joguinhos de robôs. Com isso, a edição fica visual e baixa muito a dificuldade para criar um workflow custimizado usando possíveis futuros módulos da org.

E @filipedeschamps , obrigado pela citação no vídeo das APIs do Google Cloud 😄

from video-maker.

Me amarraria em tocar algo com FFmpeg. Mas o grande pulo do gato é o importante sistema de templating visual.

Em uma busca rápida encontrei algum material de Blender e FFmpeg, mas nada muito direto a scripting de animações e exemplos práticos para um início ágil.

O Blender possui alguns marketplaces, oficiais e de terceiros, de template e pode ser uma melhor opção, se viável, por ter toda uma interface mais amigável e que agradaria mais a verdadeiros criadores de conteúdo - FFmpeg puro é pedrada.

O que achei, de Kdenlive, era meio "anêmico" então nem dei relevância.

Video - Automating Motion Graphics with Blender

Article - Automating Motion Graphics with Blender

Blender scripting API

FFmpeg Video Slideshow Scripts

SO - Creating video containing animated text using FFMPEG alone

NPM - fluent-ffmpeg

from video-maker.

Muito bom @leodutra ! A ideia é que cada peça (robo) do video-maker seja totalmente stateless, pura, sem side effect. Chegaremos lá!

Também penso que cada funcionalidade seja uma API em express ou restify, e não um fluxo contínuo do console. Assim, tendo uma API, podemos criar clients em react/angular/vue para consumir os robozinhos

Vamos conversando mais sobre isso, OK?

from video-maker.

Cara, ta lindo seu repo. Vou forkar ele pra te ajudar.

O que vc acha de mudar o nome do diretorio "apis" para "robots".

Eu vou forcar seu projeto, criar o server.js, e criar o diretorio apis, que conterá as apis de acesso que irão consumir os robots. Entendeu? Se o código em "robots" for puro, baseado em programação funcional, poderemos usá-lo tanto para o console quanto para apis (e no futuro para funções lambdas)

Eu já to criando aqui meu video-maker-vue que vai consumir essa porra toda KKKKK desculpem o palavrão KKKK

from video-maker.

Ali tem que ser apis mesmo... são apenas funções de fetch e particulares de cada serviço (Wikipedia, Trends, etc).

A ideia é criar os robots consumindo as APIs mas eles só vão conter o workflow particular, sem side-effect.

Assim, qualquer mudança de API fica modularizada e o Robot sofre pouca ou nenhuma alteração.

from video-maker.

@filipedeschamps acho legal cara as sugestões. Algo importante é separar simples assim

• oq vai evoluir a ideia?
• oq vai melhorar a ideia?

Acho o primeiro mais interessante pois eh o caminho de um servico, produto, mvp. Dentro d um escopo pequeno (melhorias e evolucoes continuas pra algo usavel). Isso ja comeca criar varias fronts. Tipo uma galera desenvolvendo servicos (apis), uma galera corrigindo erros, uma galera num app/website. Acho q da pra organizar e paralelizar.

Entendo sua proposta q eh do caralho :) e o mais legal eh tds tramprarem como um time. Um fazendo isso. Outro fazendo aquilo. Esse aqui fazendo sei la oq. E eh uma vivencia de projeto do caralho. Que poucos tem. Mta gente vai botar isso no cv. Expertise pra td lado :)

Qndo a ideia é boa mano. Nao tem jeito. Ninguem mandou inventar algo dahora. Agora segura rsrsrs

from video-maker.

Uma dica e sugestão. As vezes é simples de fazer uma parada. Então façam. Coloquem como issue ou ideias. O Filipe nao vai ficar dando aval disso ou daquilo. É importante tomar iniciativa. Já valida a ideia. Testa. Tem aceitacao ou nao... etc. Entao mandem os pulls.. abram as issues por ai vai.. organizamos isso..

Faça o fork crie uma branch. Sincronize com esse repo master como fazer isso? . Vamos acertando essa dinamica de trabalho :)

from video-maker.

Ali tem que ser apis mesmo... são apenas funções de fetch e particulares de cada serviço (Wikipedia, Trends, etc).

A ideia é criar os robots consumindo as APIs mas eles só vão conter o workflow particular, sem side-effect.

Assim, qualquer mudança de API fica modularizada e o Robot sofre pouca ou nenhuma alteração.

Beleza !!

from video-maker.

Entendo o resumo dessa thread :)

Projeto original
Td isso soh vai rolar depois do Filipe fechar o escopo inicial dele. Olha a cobrança kkk

MVP
Fechar o mvp. Vai ajudar no norte dos próximos passos e esforço. O q o mvp faz? é um app? é um site?

API / Serviços

• Vi uma sugestão de criar um serviço pra cada robo, isso msm? Dessa forma não parece q será consumido por um mvp.
• Expor um ou dois endpoints pro mvp é um bom começo.

Repositórios

• repo dos bots (filipe). Bots ficando complexos podem ser quebrados em mais repos
• outro repo api (servicos) / se nao for monorepo
• outro repo (web)
• outro repo (app)
• por ai vai

@filipedeschamps

Talvez de início, para dar o primeiro passo no MVP, o que eu faria é uma estrutura em que voltasse com a idéia de uma pasta inteira por robô e dentro dela o robô pode ser implementado em qualquer linguagem e pudesse ser servido pelo https://zeit.co/now por exemplo.

Deploy do projeto como ele estah hj? Mudaria alguma coisa na estrutura?

from video-maker.

O legal é que teria todo tipo de louco, usando módulos de input, output e transformação de dados em qualquer tipo de projeto... mais força para a comunidade.

Mas sempre com foco em uso no video-maker e seguindo a convenção.

from video-maker.

Isso também facilita para alguém que queira usar uma API X ou um robot Y. Ele pode acessar aquele repo e ver as issues e evoluções apenas daquela faceta do workflow.

from video-maker.

A verdade é... como o Maker tem varias fontes e possivelmente várias saídas... ele na verdade é um intermediário.

Temos que deixar ele tunado para intermediar e apenas encaixar os pipes que vamos usar.

from video-maker.

Sugestão de diretrizes:

• projetos devem estar sob a org video-maker sempre que forem suportados oficialmente pela org;
• projetos sob a org video-maker devem sempre ser prefixados com video-maker-;
• projetos devem conter uma pasta apis e uma robots;
• projetos devem conter README ou wiki de como utilizar API ou robot, sempre atualizada;
• projetos devem sempre conter suas issues no repositorio do projeto;
• projetos devem sempre estar no mesmo VCS e hub do projeto principal;
• projetos JS devem preferir uso de eslinting AirBnB;
• projetos devem todos seguir a licença MIT;
• projetos devem sempre usar sistema de releases e npm publish para release de versão, mantendo tags e releases anteriores;
• projetos devem sempre manter um CHANGELOG, por mais simples possível... ou minimamente um histórico de commits com mensagens e descrições explicativas.

from video-maker.

Pessoalmente, não recomendo mais Babel ou TS... o primeiro porque API do V8 está bem avançada e o segundo porque a comunidade maior é de JS (e para usar types, eu usaria Java ou Go).

Mas essa é minha humilde opinião.

Aqui tem o suporte de ES do Node.
http://node.green

from video-maker.

Deixar a ideia anotada aqui: No readme do projeto inserir informações de outros repos do video-maker em outras linguagens, como o python !

from video-maker.

@leodutra Como está o seu repo lá? No final teremos uma forma de acessar os robôs via API HTTP? vamos conversar mais sobre esse projeto, to querendo montar um cliente em vuejs que o consome. E colocar tudo num servidor cloud ☁️ 🚀 ☁️

from video-maker.

@leodutra @danielschmitz @filipedeschamps acho q essa a ideia. Já comentei aki e vejo duas formas de expor. Uma expor o robo com o resultado do search tipo google e outro endpoint com o conteudo ja gerado. Outra expor robo em modulos. A primeira solucao vejo mais interessante..

from video-maker.

@danielschmitz eu criaria um projeto para o REST separado.
A razão é que desenvolver os módulos é sempre muito mais flexível do que o REST (módulos podem ser usados no CLI, dentro de outros programas ou REST, ou com Protobuff, ... mil formas).

O REST seria muito mais uma interface da futura API de orchestrador, do Video Maker, do que uma interface direta para cada módulo.

O que mais importa por agora, como eu disse, é remover os side-effects, separar cada API e robot em seu projeto e depois fazer do Video Maker um workflow engine voltado para usar os módulos.

Assim, o REST entraria como interface alternativa ao CLI e não causaria atrito nas outras possibilidades.

from video-maker.

Uma outra questão muito importante é: o workflow vai ter sempre que indicar a versão do módulo que usa.

Se o Google Trends, por exempĺo, evoluir 4 versões, fica bem complicado de gerenciar 4 APIs REST em detrimento de apenas ter uma versão diferente no NPM.

Também, é muito mais fácil fazer um require() e debugar do que ter que criar um agente conector para um REST. Fora a latência de rede, que mesmo mínima, não se compara à performance dos módulos acessados diretamente.

Então, não vejo motivação arquitetural forte para criação de REST entre cada API/ robot/ layer.

from video-maker.

O repo está esperando principalmente a última parte.
Estou finalizando mais um batch de PRs e o número de side-effects está muito muito menor.

https://github.com/leodutra/video-maker/tree/core-improvements

from video-maker.

e se os push fossem feitos somente no dia que fosse soltar o video, assim manteria o sincronismo 🤓

from video-maker.

Estou reinstalando o Windows para testar os merges de After Effects.
Em algum momento seria bom usar o Kdenlive ou o Blender para renderizar no Linux / cross-platform.

Tive uma ideia legal para a customização de workflows:
https://developers.google.com/blockly/

Lembrei que já vi isso em 2 joguinhos de robôs. Com isso, a edição fica visual e baixa muito a dificuldade para criar um workflow custimizado usando possíveis futuros módulos da org.

E @filipedeschamps , obrigado pela citação no vídeo das APIs do Google Cloud smile

cara isso seria bem legal utilizar tecnologia open source pq usar o after efects ja seria bem dispendioso pra galera eu tava ate pensando em fazer em fmmpeg pra isso

from video-maker.

Merge dos principais PRs no fork onde estou reunindo melhorias.

#2 - User input
#6 - usa o google trends para exibir uma lista de palavras para o searchterm
#7 - Sugestão de filmes a partir do IMDB
#10 - Adiciona linter e exemplo unittest
#12 - Correção da licensa descrita no package.json
#13 - Gerar executável
#19 - feat: start text robot
#21 - Adicionando busca automática de termos no Google Trends e generalizando a função de user input
#24 - Adding visual recognition of an image
#25 - Troca o readline-sync por prompts
#34 - Adicionando Robo da Wikipedia
#38 - Refatoração: remover redundância de condicional
#49 - Possibilidade de incluir texto manualmente.
#51 - Choose language
#55 - feat: add Watson natural language understanting service
#56 - Removendo API do algoritmia e adicionando títulos relacionados ao searchTerm
#61 - Reject Watson analyze error
#63 - feat: add Trends Geo select option
#66 - Feat: Add Languages and option to use Api Algorithmia or Api Wikipedia
#72 - feat: add input robot and state robot
#76 - Simplificações de código e paralelização de fetchs de keywords do Watson.
#78 - Ajuste de performance na recuperação das keywords
#82 - feat: add google images search
#100 - feat: add youtube robot
#116 - feat: black list of images

- API do algoritmia se tornou uma opção
- Escolha linguagem é aplicada aos trends e à obtenção de texto da Wikipedia pela API HTTP

O status atual da branch ainda é WIP, pendente testes e correções menores com After Effects.

from video-maker.

@danielschmitz @leodutra @danielschmitz Senhores, e demais comunidade, o que acham de substituirmos o Google Search por algo mais Open, como o ContextualWeb? seria uma ideia?

from video-maker.

Galera, apesar de já ter uns meses essas discussões e tal, sou um dos alcançados por esse projeto espetacular do @filipedeschamps e tenho aprendido bastante. Eu formei em SI, mas fiquei bem sem norte e isso me trouxe uma nova visão para saber o quanto posso ainda ganhar o mercado, fazendo portfólio.

Gostaria bastante de ajudar em alguma coisa, mesmo não tendo a experiência de vocês, com certeza vou continuar aprendendo e me recolocando no mercado! Abraço a todos, vcs são demais!

from video-maker.