O que faremos quando o filipe terminar o video-maker #77
Comments
|
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 :) |
|
Pessoal, criei a org video-maker para segurar o nome. É claro que isso seria um progresso continuado após o Filipe finalizar as publicações sobre. Assim poderiamos ter na org: O video-maker ficaria sendo um orquestrador de chamadas aos módulos e da renderização. Se houver concordância, podemos usar a org. 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. Abraço e bom trabalho à todos. Se tudo der certo, seremos os top 50 do YouTube, Facebook, Vimeo e WhatsApp. 🤣 |
|
Uma coisa que estou tentando mudar, mas talvez volte atrás, é a estrutura de content. É 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 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. |
|
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 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. |
|
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 |
|
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. |
|
@filipedeschamps acho legal cara as sugestões. Algo importante é separar simples assim
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 |
|
No open source isso funciona para organizar um backlog, mas a execução é FIFO. |
|
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 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 :) |
|
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 :) |
Beleza !! |
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? |
|
Ó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. |
|
Entendo o resumo dessa thread :) Projeto original MVP API / Serviços
Repositórios
Deploy do projeto como ele estah hj? Mudaria alguma coisa na estrutura? |
Então, deixa eu tentar passar a visão que estou tendo. Assim teríamos: video-maker 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:
ou
É 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 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 ( |
|
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. |
|
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. |
|
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. |
|
Sugestão de diretrizes:
|
|
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. |
|
@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 |
|
Deixar a ideia anotada aqui: No readme do projeto inserir informações de outros repos do video-maker em outras linguagens, como o python ! |
|
@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 ☁️ 🚀 ☁️ |
|
@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.. |
|
@danielschmitz eu criaria um projeto para o REST separado. 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. |
|
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 Então, não vejo motivação arquitetural forte para criação de REST entre cada API/ robot/ layer. |
|
O repo está esperando principalmente a última parte. https://github.com/leodutra/video-maker/tree/core-improvements |
|
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? |
|
e se os push fossem feitos somente no dia que fosse soltar o video, assim manteria o sincronismo 🤓 |
|
Merge das últimas mudanças do Filipe feitas no fork onde estou reunindo melhorias |
|
Estou reinstalando o Windows para testar os merges de After Effects. Tive uma ideia legal para a customização de workflows: 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 😄 |
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 |
|
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 FFmpeg Video Slideshow Scripts SO - Creating video containing animated text using FFMPEG alone |
|
Merge dos principais PRs no fork onde estou reunindo melhorias. #2 - User input - API do algoritmia se tornou uma opção O status atual da branch ainda é WIP, pendente testes e correções menores com After Effects. |
|
Novidade, barra de progresso para promises. |
|
@leodutra caraca que sensacional!! 👏 👏 👏 |
|
@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? |
|
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! |
|
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. |
pessoALL,
já é sabido por nós que o @filipedeschamps ainda não aceitou os PRs nem as Ideias aqui nas Issues porque ele está construindo o video-maker ensinando passo a passo a arquitetura. Se ele aceitasse os PRs agora iria complicar para quem está aprendendo um monte de PR maneiro com códigos mais complexos.
Enfim, assim que o video-maker dele terminar, e ele terminar os videos, chega no ponto que poderemos criar um branch como "v2.0" ou "extended" ou "pro" ou "plus" no qual poderemos estender ao máximo a sua arquitetura.
Eu ainda vou conversar com o filipe desse branch novo, assim q ele terminar lá, e gostaria de contribuir na manutenção dele, como já fiz algumas vezes em outros projetos. Também vou dar uma atenção especial a essa ISSUE, atualizando sempre que possível.
O @faustoct já adiantou algumas coisas que pensei em #73 e #74. O @ibrunotome também em #60. E tantas outras ideias legais como #14, #25, #71, #37 e as ideias adicionais do @trenshy em #3.
Enfim, tem muita coisa pra "massa" para organizarmos. Só vamos aguardar o filipe terminar os videos e vamos prestar atenção nos videos dele para que possamos ter mais e mais ideias a medida que o video-maker evolui. Não deixe de ver os videos, e depois venham aqui criem issues com ideias e assim vamos catalogando tudo 🎉 🎉 🎉
The text was updated successfully, but these errors were encountered: