Criei uma proposta de layout para o TabNews, envolvendo outras telas e interações conforme verifiquei que o pessoal foi comentando e dando sugestões na outra issue #6 pelo @luantoningalvan.

Segue os links para a projeção e para a prototipação no figma. Mals as inconsistências, sou um desenvolvedor que tenta criar boas interfaces 😆.

Projeção
https://www.figma.com/file/aSjqvEUZYSQwYFIQ0KO4Fp/TabNews?node-id=43%3A673

Prototipação
https://www.figma.com/proto/aSjqvEUZYSQwYFIQ0KO4Fp/TabNews?node-id=43%3A673&scaling=min-zoom&page-id=0%3A1&hide-ui=1

Proposta

• Layout pensado no conteúdo
• Todo o site acessível pelo teclado
• Tabcoins e pontos de experiência disponível na barra superior
• Link para o projeto no Github
• Central de notificações
• Tags em posts
• Acionar Text to Speech em cada post como sugerido pelo @daniloster
• Pesquisar por tags como sugerido pelo @LuanEdCosta.
• Pesquisar por voz
• Menu do usuário no avatar como sugerido pelo @filipedeschamps.
• Accent color configurável dentro do menu do usuário, como sugerido pelo @brunofamiliar e pelo @filipedeschamps
• Adição de espaço de ads para custear o projeto (mais sobre na seção abaixo)
• Adição de um "footer" sobre a criação do projeto
• Post completo abrindo diretamente na página principal como um overlay
• Sistema de votação dos comentários como o Stack Overflow ou Disqus
• Link para reportar a postagem caso for identificado uma fake news ou postagens desrespeitosa

Anúncios

Coloquei um espaço de anuncio reservado para custear o projeto, tipo custo com os servidores, como o @filipedeschamps comentou em algum dos vídeos do membro. Coloquei o Carbon como exemplo devido ser um ótimo sistema de ads para projetos de tecnologia. A ideia não seria abrir espaços comprados nem nada disso. O Carbon, por exemplo, seria o único sistema de ads externo apenas para custear o projeto.

Imagens

Home

Post

Olá, pessoal! Queria utilizar o espaço aqui para as ideias a respeito do perfil do usuário.

O usuário em si, deveria ter um perfil único por cadastro como no Instagram ou Twitter, ou deveria expandir para a possibilidade de ter suas páginas como no Facebook, LinkedIn ou até mesmo como o próprio GitHub aqui com suas páginas de organizações/empresas.

Caso, tenhamos as pages, acredito que elas deveriam ter algumas funcionalidades específicas. E as TabCoins das suas páginas seriam independentes dos usuários ou o engajamento da página influenciaria nos TabCoins do usuário? (imagino que não deveria influenciar, haja visto que uma página pudesse ter apenas um administrador temporário).

Ou será que essa ideia de page poderia ser negativa para a proposta do TabNews que é focar no valor das publicações e talvez não necessariamente nas marcas por trás delas?

E o que mais é relevante levantarmos aqui?

Descrição

Como desenvolvedor e leitor do site, eu gostaria de saber que temos uma ou mais pessoas responsáveis pelo assunto acessibilidade para nos ajudarem a manter o site o mais acessível possível em suas implementações, seja nos educando no assunto, ou até apontando falhas de acessibilidade no que já foi implementado ou que está em revisão.

Motivo

O @CarlosZiegler trouxe na issue #43 muitas informações importantes e eu fico feliz que isso tenha sido levantado já agora no início, pois isso dá a chance do assunto entrar no DNA do projeto.

Esquecemos de colocar o favicon, acreditam ser muito importante?

Ola Pessoal, trazendo uma outra proposta aqui. Vejo que o @filipedeschamps tem sempre o objetivo de trazer todo seu conteudo de forma a deixar isso acessivel para todos os niveis de programadores/ apaixonados por TI. E acho que quando estamos implementando um projeto como esse, o ideal seria se atentar na implementacao de acessibilidade digital, para ajudar na inclusao de todos.

O que é a acessibilidade web?
A Acessibilidade web envolve uma série de recursos que possibilitam a navegação, a compreensão e a interação de todas as pessoa na internet, independentemente de suas dificuldades ou limitações.
Isso significa que sites, ferramentas e tecnologias são projetados, desenvolvidos e codificados adequadamente para que pessoas com deficiências permanentes ou com incapacidades momentâneas possam usá-los. Dessa forma as pessoas, independentemente de suas limitações, podem perceber, entender, navegar, interagir e contribuir para o ambiente em que aquela página ou programa é disponibilizado na web.

Publico Alvo
Pessoas cegas
Usuários cegos utilizam sites por meio de um leitor de tela, que é navegado exclusivamente pelo teclado. Para fazer esse teste, considere navegar em seu site com a tecla TAB. Verifique se você consegue chegar em todos os inputs e botões possíveis, realizar ações com eles de forma sequencial.

Pessoas com baixa visão ou daltônicas
Usuários com daltonismo ou baixa visão utilizam funções de alto contraste ou adaptações de cores para imagens e textos. Sua página possui alguma destas opções?

Pessoas surdas ou com audição comprometida
Pessoas surdas fazem uso do transcritor de texto em língua de sinais integrado ao site e também, de descrições em vídeos. Seu site possui alguma opção de tradução livre em língua de sinais?

Dislexia e outras deficiências intelectuais
Esse grupo de pessoas possui dificuldade em interagir com elementos da tela muito pequenos ou de acesso complexo, como menus em navbars ou botões mal posicionados.

Web Content Accessibility Guidelines (WCAG)

• Navegação limpa
• Ordem de tabulação
• Marcos e mapas do site
• Estrutura do HTML
• Títulos expressivos
• Cabeçalhos bem inseridos e definidos
• Listas de conteúdo
• Texto
• Contraste
• Cor
• Imagens descritivas

Referencia: https://dev.to/aryclenio/um-guia-pratico-da-acessibilidade-web-parte-1-meu-site-e-acessivel-39do

Pessoal, o último PR #49 adicionou uma feature sensacional de passar o mouse em cima e o avatar dar zoom, mas cada imagem que vem do Github pode vir com um tamanho diferente e algumas situações fica estranho.

Link com o bug: https://www.tabnews.com.br/pocs/construction-02

Alguém tem alguma sugestão de como consertar? Como foçar a imagem ocupar o espaço inteiro, sem crop 👍

Gostaria de usar essa issue para propor a discussão acerca da página "Em construção"

Eu tive uma ideia interessante.
Uma ilustração Parallax com pessoas trabalhando (desenhos) e na cara de cada pessoa ficaria o avatar de quem participa. Ao passar o mouse pelo avatar pausa a animação e aparece o nome com o link do github.

Isso ficaria ocupando 1/3 da tela na parte de baixo e o restante acima um texto com os dizeres "Em construção" e algum subtítulo

Exemplo de um site usando um fundo que eu imagino:
https://www.drugtreatment.com/

Estive lendo o diário e as discussões do projeto e, pelo menos até onde pude acompanhar, acho que ainda não foi discutido alguns pontos que, pelo menos eu, acho relevante quando se trata de consumir conteúdos na internet.

O primeiro problema: informação sem data pode confundir as pessoas.

Imagine o seguinte cenário: você lê a notícia de que um bug crítico foi encontrado no Windows. Você não sabia disso. Só que essa notícia já tem alguns meses e o bug já foi corrigido. Isso pode te causar uma sensação de urgência desnecessária. Sendo assim, eu gostaria de levantar algumas questões.

Eu vi que nos layouts testados existe o tempo em que aquela notícia foi postada. Mas não informa de quando é aquela notícia.

• Se uma pessoa, por engano, postar uma notícia antiga, como ela (a notícia) será tratada?
• Ficará esperando que alguém note que ela é antiga e avisará ao autor?
• O procedimento padrão será apagar a notícia ou deixar que ela vá perdendo relevância na medida que recebe poucos ou nenhum tabcoins?

Segundo problema: as fakenews.

• O que acontece se uma notícia se mostrar falsa?
• Só o autor poderá apagar a publicação ou existirá alguma tipo de moderação?
• A notícia receberá alguma tag de "fakenews" como o Facebook anda fazendo?

Isso me leva também a pensar na fonte da notícia. Uma notícia pode ter mais de uma fonte. Às vezes uma fonte possui mais informações do que a outra. E às vezes as fontes são até conflitantes.

• Existirá alguma forma de agrupar as mesmas notícias de fontes diferentes como acontece no Google Notícias?
• Existirá algum rank de fontes confiáveis?

Resolvi levantar essas questões porque esse é o tipo de coisa que me preocupa bastante quando estou consumindo informação na internet. E para que o TabNews se torne um veículo importante na comunidade de TI acho importante que o conteúdo dele seja extremamente confiável ou que pelo menos ele mostre que tem o compromisso de oferecer conteúdo relevante e confiável ao ter ferramentas que evitem os problemas que apontei.

E para ficar claro, não estou esperando que as pessoas postem conteúdos duvidosos por má intenção. Estou considerando o engano mesmo. Acho que todos nós, alguma vez na vida, postou nas redes sociais algum conteúdo desatualizado ou que era fakenews. A gente se engana. É normal.

Sim, eu sei que esta um pouco cedo para pensarmos na implementação. Mas nada impede a gente de debater como o sistema será.

Pensando aqui eu cheguei a um sistema que julgo legal. O meu foco foi:

• Deixar o mais simples possível. Se você não conseguir explicar para seu pet não vale.
• Resolve o problema de como as TabCoins são geradas.
• Incentiva a interação ao mesmo tempo que impede o flood

Lembrando que o importante é seu funcionamento. Por isso coloquei as variáveis em colchetes. Sintam-se livres para ler com os números que julgarem mais justos.

TabCoins (TC) é TabCoin Bonus (TCB)

A TabCoin será usada para sinalizar valor. Quando você "curte" uma notícia ou comentário, você estará sinalizando para a comunidade que esse conteúdo tem valor.

TabCoins:

• Cada "curtida" gastará [1] TC (ou TCB, se tiver), e adicionará [1] TC ao saldo de que gerou o conteúdo.

• Sem TC você não poderá curtir

TabCoins Bonus:

• A cada [30 min] você ganhará [1] TCB.

• O máximo de TCB acumuladas serão [3] e seu saldo aparecerá junto do saldo de TC.
  Ex.: Total de TabCoins: 357+3

• Ao curtir algum conteúdo, as TCB serão usadas antes das TC. Com isso incentiva quem é "pão duro" a sinalizar valor enquanto impede quem quiser flodar curtidas, já que após as TCB, você gastará suas TC para curtir.

• Ao ser usada, a TCB passa para o gerador de conteúdo como uma TC "comum".

• Daqui que vem todas as TC do sistema.

Gostei desse sistema pois o montante de TabCoins no sistema cresce conforme a comunidade cresce. Então se alguém tiver muito a mais que a média você sabe que essa pessoa acrescentou MUUUUITO valor a comunidade.

Pronto. O que acharam? Eu sei que tem falhas, mas como estou encantado não consigo ver. Então podem ir! Vai! Quebrem meu encanto! 🤣

Descrição

Como responsável pelo SRE do site, eu gostaria de ter disponível um endpoint /status que ao ser feito um GET retorna a saúde do sistema e dos serviços dependentes, em formato JSON.

Execução

Eu tentei procurar se existe algum padrão de retorno em APIs REST, e não encontrei nada, meio que cada um implementa da forma que quiser. O que achei de padrão foram endpoints para gerenciar a saúde e readiness num contexto Kubernetes, mas daí meio que acaba tendo uma função que vai mais pro lado de gerenciar o cluster (e também pra mensurar a saúde). Talvez o que seria mais interessante é pesquisar se existe padrões no contexto de microsserviços, procurei aqui e não achei muita coisa.

De qualquer forma, o que sugiro é implementarmos o endpoint /api/v1/status (ou /health confira ali em baixo) e o retorno pode depender de como o serviço de monitoria que utilizarmos funciona (se ele vai conseguir interpretar um JSON).

Por exemplo podemos retornar 200 OK se tudo estiver saudável e 503 Service Unavailable se algum serviço não estiver saudável, como por exemplo o banco de dados que é a única dependência atual do site.

{
    "updated_at": "2021-08-13T18:36:35.138Z",
    "dependencies": {
        "database": {
            "status": "healthy",        // "healthy", "degraded", "unhealthy"
            "opened_connections": 30
        }
    }
}

Ou até podemos retornar 200 mesmo com uma dependência não saudável, dado que o endpoint fez com sucesso o que deveria fazer. E deixa o 5xx se der algum problema inesperado na consulta. O que acham? Novamente, vai depender de como as ferramentas de monitoria conseguem interpretar o cabeçalho ou objeto retornado.

Status ou Health?

Me pergunto isso, porque seria interessante mais para frente ter um endpoint que retorna as estatísticas do site, por exemplo, quantidade de cadastros, views, etc... me preocupo do nome desse endpoint ser muito parecido com "status"). Então por isso penso que talvez o nome do endpoint que retorna a saúde dos sistemas deva ser /health. Por outro lado, é comum se usar a nomenclatura "status page" para procurar a página de status de um serviço. Inclusive o subdomínio de muitos serviços é status.dominio.com.

Alguém tem alguma opinião?

Serviços de monitoria

Esbarrei faz pouco tempo atrás com esse https://updown.io/ e achei bem barato.

Alguém tem sugestões sobre que tipo de serviço usar para monitoramento?

Dependência

Existe a issue #96 que poderia ser executada antes, mas essa aqui pode ser executada em paralelo sem problemas, porque a única coisa que daria conflito seria no package.json.

Agora o que realmente tem de dependência é o PR #98 do @brunofamiliar , nada muito grave, pois só vai alterar a interface do módulo do banco de factory para singleton.

Sem muito mistério, basicamente redirecionar o DNS para Vercel, adicionar o domínio tabnews.com.br lá e fazer uma nova publicação. Inclusive, já vou apontar o DNS para ele já estar propagado.

Pessoal, sei que ainda é cedo para pensar em algo do tipo, mas desde que o Filipe divulgou o projeto eu não paro de pensar nessa ideia. Já viram um site chamado Dailly Dev? Ele basicamente agrega notícias de diversas fontes e disponibiliza de uma forma acessível cada vez que o usuário abre uma nova aba no navegador; isso na minha opinião é fantástico! Que tal nós trabalhar numa ideia semelhante a essa? 😄

Descrição

Como leitor do repositório, eu gostaria de poder ter um índice com cada entrada do diário de desenvolvimento, e que ao clicar num item desse índice me levasse para o conteúdo completo sobre o que aconteceu naquele dia, ao invés de ter todas as entradas expostas no README principal.

Motivo

O README está ficando extremamente grande e pesado, e vai ficar cada vez mais.

Execução

Isto já está sendo executado por @geovani-brito no PR #89

Descrição

Como leitor do repositório, eu gostaria de ver no início do README os passos necessários para rodar o projeto na minha máquina local, e também como commitar minhas contribuições, e isso inclui:

1. Como rodar em modo de desenvolvimento, incluindo como configurar o docker-compose nos sistemas operacionais (ou apenas apontando para outros tutoriais).
2. Como rodar os testes com npm test
3. Como dar watch nos testes com npm run test:watch
4. Como rodar as Actions usando o act
5. Qual padrão de commits usamos (e para ajudar, indicar o script npm run commit)

Motivo

Mostrar como é realmente simples rodar o projeto em ambiente local e como consequência aumentar as contribuições.

Dependências

Primeiro fazer o merge do PR #89 que está refatorando o diário.

Descrição

Eu como usuário avançado do site, através de uma API eu gostaria de poder usar os dados de acesso do meu usuário (username/email e password) para me autenticar no sistema, criar uma sessão ativa e a resposta desta requisição marcar nos cookies o token da sessão.

Execução

A execução não deve fugir muito de:

• Rotas
• Controllers
• Model
• Migration / Tabela no Banco
• Testes

Sugiro seguirmos o modelo clássico de autenticação com cookies, e de início armazenar as sessões no Postgres (o que não é recomendado, mas como discutimos em live, vamos testar o limite antes de adicionar um outro serviço como Redis).

Sugiro não usarmos JWT

Eu sugiro não utilizarmos JWT, pois vejo que um dos principais motivos de se usar essa tecnologia é ter um sistema de autenticação sem a necessidade de uma máquina de estado (um backend que de forma persistente guarda as sessões), porque isso de fato tem várias vantagens, principalmente na escalabilidade (por não ter o gargalo da persistência que é difícil de escalar horizontalmente).

E também como iremos depender bastante de autorização, iremos precisar colocar isso no token que vai para o client, e eu não fico confortável com o client poder decidir isso no payload, mesmo que para ter qualquer efeito ele precise quebrar a assinatura (o que hoje é algo ainda impraticável caso seja usado uma chave forte, mas procure por brute forcing jwt token).

Outro ponto que vejo um pouco de confusão ao usar essa tecnologia é na hora de precisar invalidar/banir manualmente algum token em específico, que sem a máquina de estado fica impraticável, e com isso as pessoas começam a usar máquina de estado junto com JWT. Acho isso muito estranho, pois você está usando uma tecnologia projetada para não ter estado no backend (e assim conseguir facilidade de implementação e escalabilidade) e no final adiciona estado. É confuso, pois na minha visão fica muito mais limpo você decidir ou ir para o modelo full JWT sem estado, ou full tradicional com estado e cookies... ou eu to enganado?

Por favor, qualquer discussão nesse ponto é super bem vinda, principalmente pelo fato de nunca ter implementado autenticação JWT, apenas estudei a respeito e fiquei muito frustrado com esses pontos.

Dependência

• #105

Turma, durante essa semana a nossa conta gratuita na Vercel estourou um dos limites e eu precisei fazer o upgrade para a conta Pro. Inicialmente pensei que isso não teria nenhum impacto (ainda mais por estar numa conta paga agora), mas eu estava enganado. Como estou pagando por 1 assento apenas, todos os Preview Deployments vindos de outras contas irão dar problema.

Solução

Não sei e estou pensando aqui como resolver isso. Por exemplo, se o PR for aprovado, eu fazer o merge contra uma branch de release candidate, pois daí vai ser criado o Preview com o meu assento. É um saco e perde a dinâmica de todo mundo conseguir rapidamente gerar URLs de Preview.

Bom, se alguém tiver alguma sugestão sobre como não perder essa dinâmica seria show 👍

Descrição

Como desenvolvedor do sistema, eu gostaria que o meu editor de código carregasse automaticamente as regras de code style sobre o Prettier, vindo do arquivo de configuração .prettierrc.

Motivo

Pelo que foi informado na última Live e que faz total sentido, sem esse arquivo os editores não possuem nenhuma pista que deveriam respeitar esse padrão de formatação.

Mais detalhes

As regras usadas hoje são as padrões do Prettier, então eu não sei exatamente o que colocar dentro desse arquivo.

Depois da bagunça causada pelo Github Copilot, vamos entender se estamos com a licença certa. Eu sempre assumo a licença MIT, e nem sei mais porque. O intuito dessa issue não é necessariamente sair da MIT, mas de entender os motivos caso continuarmos com ela e também quais alternativas temos e porque.

Framework de teste no Next.js: ?
Postgres rodando local: um docker-compose é bem simples e resolve
CI: Github actions é muito bom, é facil instanciar um DB postgres para os testes

Descrição

Como desenvolvedor do site (ou usuário avançado), através de um endpoint na API eu gostaria de poder criar, ler, atualizar ou deletar usuários, sem inicialmente precisar de autorização, autenticação e nem confirmação por email.

Execução

Sugiro começarmos da forma mais simples possível, que é fazer todos o CRUD do usuário e isso envolve:

• Rotas
• Controllers
• Model
• Migration / Tabela no Banco
• Testes (incluindo uma nova função no orquestrador para deixar o banco num estado zerado, mas com as migrations rodadas)

E o objeto sugiro que seja o mais simples possível, sem especularmos campos, só o necessário para o que está dentro dessa Milestone, que acredito ser:

• id
• username (único dado público)
• password
• email

[edit]

• features / credentials (algo relacionado às habilidades dele no site)
• status
• created_at
• updated_at

Se não for isso, me avisem 👍

Dependência

Seria bom ter resolvido essas três issues:

• #92
• #96
• #97

Próximo passo

Depois iremos engatar isso no sistema de autenticação e autorização para, por exemplo, somente o próprio usuário poder ler ou alterar seus dados, ou algum outro usuário admin que tenha a permissão para fazer isso.

Descrição

Eu como desenvolvedor do sistema, gostaria de poder ter um sistema de autorização que controlasse o acesso aos recursos. O sistema não deveria ser Role-based Access Control (RBAC) e sim ser Resource-based Access Control. Então ao invés de um usuário ter o papel (role) de admin ou moderator que agrega uma variedade de permissões, no caso de controle de acesso por recurso o usuário possui um controle muito mais refinado, por exemplo, qualquer usuário pode receber a permissão para rodar as migrations, ou deletar posts, fazer upload de imagens, criar anúncios ou o que seja de funcionalidade no sistema.

Execução

A evolução de um usuário dentro do TabNews (no quesito de o que ele pode fazer) vai se basear muito em dois pilares: Ações e Recursos. Inicialmente um usuário vai poder apenas criar comentários, por exemplo. Depois de um tempo, ele vai poder criar notícias na home, e depois criar comentários usando formatação em markdown, depois enviar imagens... ou o que seja. Tudo isso é uma combinação de ação contra um recurso. Você pode ler mais sobre isso nesse artigo: The New RBAC: Resource-Based Access Control. Tem um outro tipo de método que é Attribute Based Access Control (ABAC), que parece ser bem standard, assim como o RBAC, mas traz uma granularidade ainda maior, só que eu acho desnecessário para o nosso contexto. De qualquer forma, como sempre, tudo está aberto a discussão 🤝

Sobre a implementação de fato, não vou me prolongar aqui porque só vou conseguir visualizar algo concreto implementando, mas a primeira direção que vou tomar para testar deve ir nessa linha:

// só um rabisco de uma rota da API

import routes from "next-connect";
import authentication from "models/authentication.js";
import authorization from "models/authorization.js";

export default routes()
  .use(authentication())
  .use((req, res) => {
    const user = req.user;
    const resource = req.query.resource;
    const action = req.method;

    if (!authorization.can(user, action, resource) {
      throw new Error('Acesso negado');
    }
  })

Esse rascunho ta bem bagunçado, middleware dentro de models, o nome das coisas de forma estranha, mas independente disso, como falei preciso por a mão no código para visualizar melhor as moving parts envolvidas 👍

No mais, alterações em:

• Model de Autorização
• Modificar Controllers que precisam de autorização
• Modificar User para ter um array de permissões
• Testes

Dependência

• #106

Olá a todos.

Pensando em um crescimento mais saudável do projeto, mas sem trazer complicações e Overengineering, pensei em trazer um modelo de arquitetura para o frontend do projeto.

Indo direto ao ponto, esse é o modelo:

src
├── components   # Componentes globais de uso geral do projeto.
├── layout       # Wrappers padrões para componentes ou páginas.
├── hooks        # Hooks globais de uso geral do projeto.
├── contexts     # Contexts para gerenciamento de estado global do projeto.
├── modules      # Módulos. Um para cada página, com a lógica de negócio.
│      └──   example-module
│              ├──  index.js/ts  # Ponto de partida desse módulo. Esse arquivo será importado na página pertinente.
│              ├──  hooks        # Hooks globais de uso exclusivo desse módulo.
│              ├──  components   # Componentes de uso exclusivo desse módulo.
│              ├──  service      # Funções e lógicas de utilização geral e genérica de uso exclusivo desse módulo.
│              └──  utils        # Componentes de uso exclusivo desse módulo.
├── pages        # Cada página associada com uma rota e um módulo. 
├── services     # Lógica de comunicação com o backend.
├── shared       # Tudo que for compartilhável entre módulos. Sendo configuração de temas, etc.
└── utils        # Funções e lógicas de utilização geral e genérica.

Essa estrutura interna aos Módulos é opcional e pode ser criada mediante necessidade, precisando inicialmente só do index.js/ts

Caso queiram agregar em algo, criticar ou propor melhorias, por favor coloquem aqui nessa Issue. Sei que queremos manter KISS, mas acredito que isso não seja distante do simples e intuitivo, mas agregue muito a longo prazo na manutenibilidade do projeto.

Um forte abraço pessoal.

Oi pessoal,
Como ainda não vi sugestão desta parte na milestone da fundação, vim compartilhar oq tenho utilizado, se alguem tiver algo diferente, mais interessante, ou talvez algo mais padronizado para projetos Next.js. Fica a vontade para compartilhar.

Independente do linter (apesar de usar o eslint), o que tem ajudado muito, muito mesmo é utilizar o https://prettier.io e um arquivo de configuração com o "padrão", tambem utilizo um plugin do VSCODE que ao salvar os arquivos, tudo é formatado para o padrão, desta forma, meu lint acaba nunca falhando...

Segue o padrão que tenho utilizado nos projetos Javascripts:

# .prettierrc.js

module.exports = {
  semi: false,              // Não precisa de ; no final das linhas
  singleQuote: true,
  tabWidth: 2,
  useTabs: false,          // não usa tabs no lugar de espaço
  trailingComma: 'es5',    // https://prettier.io/docs/en/options.html#trailing-commas
  arrowParens: 'always',   // mantem o () nas arrow functions
}

Resumo:

• o eslint ou qualquer outro no package.json, dai no CI tem a validação automática para ver se tudo está no formato corretamente anes do deploy. Pega erro de sintaxe tambem
• um arquivo .rc para deixar explícito qual o padrão de formatação, assim as pessoas tambem ficam livres para utilizar outros plugins/formatadores
• um plugin (no editor) para ajudar no trabalho de formatação/verificação ao mesmo tempo que estamos codando.

Abraço

Pessoal,

Geralmente precisamos compartilhar segredos entre a gente, onde podemos armazená-los para compartilhar?

Por exemplo, no script do ansible que adicionei para instalar o postgres (issue #61 ), tem o arquivo devops/ansible/group_vars/development.yml que tem a pwd do banco de dados.
Mas este arquivo está criptografado usando o ansible-vault.

para voces saberem o user/pwd do banco, precisa usar o ansible-vault decrypt e passar a chave que usei para encriptar, como passo esta chave para voces?

Descrição

Como mantenedor da infraestrutura de testes, eu gostaria de tirar do package.json scripts que não agregam em nada, como o test:ci e repassar o comando do jest de dentro desse script diretamente para a Action/Workflow tests.yml.

Motivo

Me parece uma abstração completamente desnecessária ter um comando que é usado exclusivamente pela Action, que no final das contas roda apenas jest --runInBand. Sugiro economizar essa linha dentro do package.json e não ter que fazer a pessoa que está lendo a Action ter que voltar para o package.json para entender o que o comando faz.

Criando essa issue para colocar dentro da Milestone 0 e começar o trabalho de fazer merge ou fechar os PRs de POCs, incluindo mover tudo para dentro de uma pasta poc.

Descrição

Como desenvolvedor do sistema, eu gostaria de importar o módulo do banco de dados e usá-lo diretamente, sem precisar rodar a Factory que cria e me devolve uma instância do banco.

Então ao invés de:

import databaseFactory from "infra/database.js";
const database = databaseFactory();
await database.query("SELECT...");

Ser assim:

import database from "infra/database.js";
await database.query("SELECT...");

Motivo

Uma das estratégias mais básicas quando se lida com banco de dados é a utilização de um Pool que vai gerenciar as conexões ao banco, e isso inclui abrir novas conexões, reutilizá-las quando necessário, ou fechar quando ficaram paradas por muito tempo.

A versão atual da codebase já está utilizando o Pool fornecido pelo módulo pg, porém pelo fato de estar dentro de uma Factory acaba perdendo o sentido, porque toda vez que é criada uma instância, é criado consigo um novo Pool... e idealmente você deveria ter apenas um único Pool para todo o backend. Infelizmente esse é um cenário impossível para nós, porque atualmente estamos rodando em um ambiente serverless na Vercel, então isso vai agravar o problema de consumo de conexões ao banco porque as Serverless Functions são stateless, o que nos vai levar para o futuro já previsto de usar o PgBouncer.

De qualquer forma, sugiro usar o Pool do jeito que ele é feito para ser usado, [edit] até porque eu acho que apesar da função ser stateless, eles reutilizam o contexto que está fora do handler. Talvez o @paulogdm possa confirmar isso.

Alternativas

Todo módulo num ambiente Node é um Singleton por natureza, e é apenas executado uma única vez independente de quantas vezes for importado, então uma das estratégias poderia ser mover a inicialização do Pool para fora da Factory, mas daí na minha visão fica confuso, pois quando uso uma Factory quero ter a garantia que recebo como retorno uma instância sem reúso de estado. Então sugiro assumirmos que o módulo database é um Singleton de fato, pois estrategicamente queremos reaproveitar o Pool do jeito que foi arquitetado para ser usado, independente de qual servidor está hospedando nosso sistema.

Sei que não é algo que será definido agora no inicio do projeto, mas já gostaria de abrir o assunto para começar a lapidar a lógica e ferramentas que vamos utilizar.

Estou estudando algumas grandes sacadas do Google, e a principal alavanca para o sucesso dos anúncios foi a exibição personalizada por "categoria" das buscas efetuadas.

Acredito que podemos seguir a mesma lógica para o Revenue Share, Se o usuário clicar em uma noticia sobre Bitcoin, dar prioridade para exibição de "Anúncios" sobre o assunto: cursos, vídeos. Desta forma teremos mais sucesso em visitas para os "parceiros".

Sugestão de como fazer:
01 - Criar palavras-chaves quando um usuário criar um Revenue Share, com um certo limite parecido com o Youtube.
02 - Procurar as palavras dentro das noticias e apresentar os Revenue com similaridade sobre assunto.

Bom dia, pessoal.

Como na Milestone 1 tem como uma das metas a padronização de commits, venho propor algumas regras que uso para contribuir em projetos com outros programadores. Costumo colocar essa regras no arquivo CONTRIBUTING.md.

Caso seja interessante, podemos ver uma adaptação desse arquivo, ou a criação de um novo que seja mais coerente com a política do projeto.

Conectado com a issue #83 (porque se a gente resolve essa, a outra ta garantida), eu tentei conectar a nossa aplicação no ambiente de Preview da Vercel e deu problema, isso após configurar as variáveis de ambiente.

Olha o erro que está acontecendo:

error: no pg_hba.conf entry for host "3.238.132.189", user "doadmin", database "defaultdb", SSL off
    at Parser.parseErrorMessage (/var/task/node_modules/pg-protocol/dist/parser.js:287:98)
    at Parser.handlePacket (/var/task/node_modules/pg-protocol/dist/parser.js:126:29)
    at Parser.parse (/var/task/node_modules/pg-protocol/dist/parser.js:39:38)
    at Socket.<anonymous> (/var/task/node_modules/pg-protocol/dist/index.js:11:42)
    at Socket.emit (events.js:375:28)
    at addChunk (internal/streams/readable.js:290:12)
    at readableAddChunk (internal/streams/readable.js:265:9)
    at Socket.Readable.push (internal/streams/readable.js:204:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:188:23) {
  length: 155,
  severity: 'FATAL',
  code: '28000',
  detail: undefined,
  hint: undefined,
  position: undefined,
  internalPosition: undefined,
  internalQuery: undefined,
  where: undefined,
  schema: undefined,
  table: undefined,
  column: undefined,
  dataType: undefined,
  constraint: undefined,
  file: 'auth.c',
  line: '496',
  routine: 'ClientAuthentication'
}

Por se tratar de um teste rápido, eu estou usando o banco e usuário padrão que a DigitalOcean retornou. Eu vi que se trata de SSL e pesquisei aqui e só fiquei ainda mais confuso, mas um detalhe importante, na URL de conexão do banco, tem isso no final:

...ondigitalocean.com:xxx/defaultdb?sslmode=require

sslmode=require então talvez o banco local funcione, pois está sem SSL, e em produção ele continua tentando conectar sem SSL e dá problema?

Alguém já passou por isso?

Cara! Acabei consumir tudo que vocês postaram nas issues e no repo como um todo. Vocês são sensacionais!

Vou tentar contribuir um pouquinho: talvez seja maluquice, mas a gente não consegue reter tanto os usuários da newsletter quanto os do site não? Eu enxergo 2 tipos de usuários: "usuários que consomem" e "usuários que consomem e contribuem"

Não sei o quanto eficiente seria, mas acredito que conseguimos criar um único site que atenda ambos.

1. Eu imagino o layout default o mais limpo possível, pois a maior parte dos usuários querem apenas entrar e consumir assim como fazem no email, e para estes, não faz sentido outras features.
2. E em algum lugar no site poderia ter um botão de show/hide para os usuários que querem uma experiência "mais completa" e "tudo bem" ter um passo a mais para acessar esses recursos já que seriam usuários que já estão dispostos a interagir e contribuir para o site.

Rabisquei no figma o que eu imagino. Não se prendam nos detalhes mas sim na ideia como um todo: https://www.figma.com/file/rovD0eecxO0264VseLCcMZ/Untitled?node-id=1%3A2

Coloquei essa ideia aqui, pois faz parte da estrutura do projeto e não apenas uma feature.

Originally posted by @danwhat in #1 (comment)

Origem da necessidade

Nós produzimos uma newsletter diária que tem o objetivo principal de economizar o tempo do leitor ao sintetizar em um único parágrafo uma notícia (o que internamente apelidamos de "sushi de notícia" porque é uma "unidade de comida para o cérebro", pequena e que tem início, meio e fim) e por isso que a chamada principal é "Notícias de Tecnologia para quem não tem tempo de ler notícias".

Isto dá muito trabalho, principalmente para o @GustavoDeschamps (Guga, meu irmão), ainda mais considerado o filtro que usamos para selecionar as milhares de notícias que são geradas no mundo todos os dias. E apesar de que este modelo está funcionando muito bem, ainda temos dificuldades na entrega do material por email.

Nós adoramos o formato do email, porque você fica com uma "cópia pessoal" do que foi enviado, mas ao mesmo tempo ficamos extremamente frustrados quando algum provedor de email arbitrariamente escolhe não entregar este material para uma pessoa que passou por um double opt-in (se inscreveu e confirmou a inscrição).

Dado a isso, surgiu a idéia de publicar esse material (e vários outros que não entram no filtro da newsletter) em um site chamado TabNews.

Origem do nome

Quem deu a idéia do nome foi o @GustavoDeschamps porque a usabilidade que gostaríamos no site é o usuário deixar ele aberto numa Aba (Tab) e automaticamente as Notícias (News) vão entrando, por isso do nome TabNews.

Mas a origem da necessidade é fraca

Claro que é importante endereçar o problema de entregabilidade dos emails, e o que eu vou falar agora parece besta, mas tem um ponto importante: isso é um problema apenas para quem tem esse problema. O que eu quero dizer é que um site não deveria existir para resolver apenas isso... principalmente se considerarmos que Site e Email vão ser dois públicos diferentes e um Site não vai resolver o problema de quem quer receber as informações por Email. Então fica a pergunta:

Por quê esse site existe?

Qual o real objetivo dele? Uma das coisas que o @GustavoDeschamps especulou é que, diferente da Newsletter onde ela contém a síntese de notícias para quem não tem tempo de ler notícias, o TabNews poderia ser justamente o contrário, notícias para quem tem tempo e quer se aprofundar nos assuntos, propor discussões e fazer novas perguntas a respeito.

Mas as pessoas querem isso? Quem quer isso? Vai ter uma grande desproporção entre quem vai produzir essas novas informações e quem vai consumir. Como ser recompensador para os dois lados? Por exemplo, no lado de quem produz ter a possibilidade de um revenue share? No lado de quem consome conseguir destacar as melhores informações.

E se for isso, como podemos sintetizar tudo o que eu escrevi nessa issue até agora em uma única frase, assim como fizemos na chamada principal da Newsletter? Na Newsletter se alguém me perguntar o que ela é, fica fácil, é economizar o tempo do leitor... e o site?

Fala turma, como estão todos?

Caso você esteja dando watch no projeto, percebeu que as issues para a Milestone 2 estão sendo criadas com bem mais carinho, depois da sugestão do @huogerac, ao ponto de ser possível já implementar algumas até ao final, como já está sendo feito inclusive.

E fazer as issues dessa forma está sendo muito melhor, tanto porque dá para pensar de uma forma mais profunda no que deve ser feito, quanto possibilita qualquer pessoa conseguir contribuir dado que as explicações estão mais detalhadas... mas como a natureza não deixa nada de graça, dá muito mais trabalho. Eu pensei que conseguiria terminar tudo até ontem, mas foi impossível dado a dinâmica aqui de casa e talvez não consiga terminar hoje também.

Em paralelo, a OpenAI lançou o Codex e eu realmente gostaria de fazer um vídeo sobre isso porque eu fiquei maravilhado, a parte de ir descrevendo um jogo e ele ir sendo feito pelo computador é um sonho meu de infância e eu gostaria muito de cobrir isso no canal e me botei o desafio de conseguir fazer esse vídeo até segunda (inclusive, eu quero conversar sexta-feira no vídeo dos Membros sobre a dinâmica entre o Canal e TabNews).

Então o que eu proponho aqui é:

Como já temos várias issues bem formatadas para execução direta ou para discussão, a ideia é empurrar a abertura da Milestone alguns dias pra frente para eu conseguir produzir esse vídeo.

Se vocês toparem, eu ficaria muito feliz e em seguida eu volto a criar o restante das issues continuando com o mesmo carinho dessas primeiras issues 😍

Elaborei uma proposta para design e junto com ela diversas funções interessantes

Link da proposta: https://www.figma.com/file/YbgVm2pLpCxhb5XcFIM7hI/TabNews

Existem comentários no arquivo, porém não tenho ciência que será possível o público ver, então farei os mesmos aqui

Propostas

• Home com as publicações em destaque. Usuário experiêntes podem adicionar imagens.
• Card de notícia possuirão uma borda lateral indicando o quão em destaque está o assunto sendo uma variação de um tom de cor
• Anúncios terão design padronizado para fácil criação
• Será possível criar uma playlist para um player que faz text to speech
• Ao logar usuário poderá conferir uma barra lateral com suas moedas e atividades que geram pontuação

Oi, galerinha... Por meio da issue é que eu pensei em como expor isso diretamente para os envolvidos de forma fechada. Porém no futuro acho possível estarmos falando seriamente até em incluir um sistema de colecionáveis no próprio TabNews, não necessariamente de compras e vendas, mas talvez colecionáveis de conquistas...

Queria mostrar o NFT que criei do Dia 0 do TabNews.

Disponível no marketplace JGN da rede Binance Smart Chain: https://jgnnft.com/assets/0x3E31F70912c00AEa971A8b2045bd568D738C31Dc/2764?owner=0x55aca363fafd420e7630c55685d949d1bc45c0d2

É um gif animado com nossas carinhas maravilhosas em hover rapidamente.

Fiz mais para na posterioridade lembrarmos que esse dia foi "registrado em pedra", ou melhor, em blockchain, e NUNCA será deletado, do que propriamente achar que as pessoas deveriam comprar. Simbolicamente foram geradas 262 cópias e foi aplicado o preço de 0.00262 BNB, que na cotação de hoje está em torno de $0.84 USD.

CALMA. Não sou o chatão que tá tentando vender coisas para a comunidade não, relaxem... Não estou esperando que comprem, minha satisfação está no REGISTRO e a maior satisfação ainda será o dia que o TabNews possa ser uma grande referência em notícias tecnológicas e olharmos para trás e ver que em sua construção ele já teve sua presença marcada de alguma forma em blockchain. Afinal, a tecnologia está no nosso DNA (ainda bem que não é uma comunidade de profissionais da saúde e não vão me corrigir nisso).

Para quem não sabe ainda do que se trata NFT's, são colecionáveis registrados em blockchain e o intuito é certificar a originalidade de um arquivo digital e torná-lo limitado. Como todo inicio de algum recurso tecnológico, a ideia parece bastante abstrata para muita gente ainda, com o hype do momento a tendência é que apareçam muita coisa inútil (um gif de uma homepage talvez fosse um exemplo?) no processo. Porém, eu vejo MUITA utilidade para isso no futuro, no pós-hype, até que o dia que será essencial em alguns cenários específicos.

No caso do marketplace da JGN é necessário ter uma carteira digital da Metamask, ou da BinanceChain ou da WalletConnect para transacionar.

Eu achei massa fazer isso.

Acabei ficando sem tempo para documentar o problema que tive no Ubuntu na live TabNews: Milestone 1 (ENCERRAMENTO)

Apenas para manter o histórico de lições aprendidas, vou deixar essa Issues já como finalizada.

Ao iniciar o comando npm run dev era apresentado o seguinte erro:

[email protected] services:up
docker-compose -f infra/docker-compose.development.yml up -d
ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running?

Achei a resposta para o problema neste link:

https://docs.docker.com/engine/install/linux-postinstall/

Executando os itens 1,2,3,4.

Ola pessoal, primeiro me desculpe a falta de acentos (teclado alemao).

Sempre comentei que esse conteudo e muito rico e precisa ser disseminado para mais pessoas e claro mais linguagens (ingles, alemao, japones ... ). Alem de mais pessoas beneficiadas com essa leitura, tambem teriamos a oportunidade de trabalhar com essa feature que com toda certeza vai nos fazer crescer profissionalmente.

Internacionalização

Por que Internacionalização e Localização importam?
Se você trabalha desenvolvendo um produto voltado ao mercado nacional, já deve estar habituado ou habituada a escrever todas as strings em Português, pelo menos aquelas vistas pelos usuários. O que aconteceria se o seu cliente quisesse expandir o mercado e passar a vender o produto em outro país? O quão trabalhoso seria fazer com que uma pessoa mexicana, por exemplo, utilizasse sua aplicação de forma correta e com uma boa experiência de usuário?

Localização vs Internacionalização
Localização (l10n1) é o processo de adaptar uma aplicação, produto ou até mesmo um documento para ser mais agradável para clientes de países e culturas diferentes.

Por outro lado, internacionalização (i18n) é o processo de tornar a localização do produto possível. Implementar o software para que este possa saber quando e como mostrar conteúdos diferentes dependendo da localidade da pessoa usuária.

Como a documentação do Django resume perfeitamente: localização é feita por pessoas tradutoras, enquanto internacionalização é feita por pessoas desenvolvedoras2.

Contudo, essa definição resumida de internacionalização e localização pode dar a impressão errada de que se trata apenas de uma tradução de idiomas. Na verdade, esse processo envolve várias outras adaptações necessárias para fazer com que pessoas de diferentes culturas se sintam mais confortáveis usando o produto, como por exemplo:

• Formatação de datas e moedas
• Conversão de câmbio
• Conversão de unidade de medidas
• Caracteres especiais e texto bidirecional (ver exemplo abaixo)
• Fuso horário e feriados

Ressources

• https://nextjs.org/docs/advanced-features/i18n-routing
• https://labcodes.com.br/blog/pt-br/development/por-que-internacionalizacao-e-localizacao-importam/

Após definida a ideia de como será a página de "Em Construção", essa issue é responsável por definir como será programada essa ideia.

Para não perdermos controle sobre a quantidade de issue aberta, proponho que já logo no início dessa Milestone a gente faça um fechamento da maioria das issues que ficaram stale. Isso não significa que o assunto foi encerrado, e muito menos que não pode ser repescado (inclusive, o que é importante geralmente é repescado naturalmente). Mas é muito de fazermos a manutenção do repositório aqui no Github, tanto quanto fazemos em código. Eu vejo que nem todas as issues valem a pena fechar, mas algumas valem 👍

Por gentileza alguém pode me auxiliar neste erro?

Config do meu note:
docker-compose version 1.29.2, build 5becea4c
Docker version 20.10.7, build f0df350
Windows 10 Home Single Language
Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz 2.11 GHz
RAM 8,00 GB (utilizável: 7,72 GB)
Sistema operacional de 64 bits, processador baseado em x64

Estou adicionando mais essa issue, pois é ela que deveremos fechar na live da próxima sexta-feira dia 30/07 🎉🎉🎉 😍

Descrição

Como desenvolvedor do sistema ou consumidor da API, eu gostaria de contar com um padrão de erros, tanto na implementação de erros customizados, quanto no retorno da API.

Motivo

Consultas com sucesso vão acabar não tendo um padrão no seu retorno, pois hora um endpoint pode retornar um objeto, hora pode retornar uma lista, mas retornos com erro podem ter um padrão. Isso é extremamente importante, pois o "caminho feliz" de uma aplicação é geralmente muito discutido, mas o "caminho infeliz" pode fugir do nosso controle e um padrão no objeto de retorno pode ajudar muito a mostrar esse erro de uma forma legal numa interface com o usuário, ou programaticamente quando consultado por um outro programa.

Execução

Tem uma talk que fiz no Pagar.me Talks sobre como fazer erros customizados e de uma forma padronizada, não sei se esse assunto evoluiu ao ponto de mudar alguma coisa, é preciso avaliar.

De qualquer forma, segue aqui uma sugestão da estrutura do objeto de retorno (e sempre super aberto a discussão):

{
    "message": "Mensagem curta sobre o erro.",
    "action": "Uma sugestão, para quem recebeu esse erro, do que fazer para consertar ele.",
    "type": "tipo_do_erro_para_ser_consultado_de_forma_programatica",
    "traceid": "2525ef6e-fa2e-11eb-9a03-0242ac130003",
    "errors": [{
      "field": "username",
      "message": "O nome de usuário deve ser preenchido."
    }, {
      "field": "password",
      "message": "A senha deve ser preenchida."
    }]
}

Dependência

Seria interessante primeiro executar a issue #96 e padronizar os controllers.

O Filipe falou, no último vídeo, que o diário estava ficando gigante e que era preciso pensar melhor como trabalhar essa ideia de documentar a evolução do projeto. E de fato já tá ficando difícil rolar a página ou procurar alguma coisa lá. E cada nova entrada tem um texto cada vez mais longo, o que já era esperado pois a complexidade do projeto continua aumentando.

Por isso quero fazer uma sugestão ao @filipedeschamps.

1. Colocar o diário na pasta init com um arquivo para cada dia registrado (em uma pasta própria, claro).
2. Colocar no README.md apenas um índice com os dias e os títulos, linkando para o arquivo correspondente. Por exemplo:

Diário

Antes de 17/10/20 - Um grande problema
17/10/20 - Registro do domínio
25/12/20 - Criação do repositório

3. Ao fim de cada arquivo, colocar um link para o próximo dia registrado assim que ele for redigido. Dessa maneira, pra quem estiver lendo na sequência, evita ter que ficar voltando ao índice.

O que acham? Tem algum problema de praticidade ou técnico que eu não tenha notado?

Como vai funcionar o trabalho feito aqui?

• Vai existir um Kanban (podendo usar até o próprio Projects desse repo) com backlog e andamento das tarefas com um gitflow (e se for esse o caso, seria baseado em features ou CI)?
• Ou será totalmente descentralizado a ponto em que todas as novas funcionalidades virão através de pull requests vindo de forks?

Pessoa, com o intuito de conquistar mais notabilidade, tenho como proposta a criação de um gerador para RSS.
Pode parecer um pouco defasado esta tecnologia, mas existem sites e apps que tem uma notável contribuição para que esta tecnologia continue funcionando. Como o Feddly, Inoreader., e por ai vai.
Com os seus feedbacks, eu posso vir com uma proposta através de um pull request.
#KISS

Objetivo dessa Inssue é unificar todos detalhes básicos evitando o esquecimento futuro. Ficará dentro do label (repescar):

1. Adicionar um favicon ao projeto.
2. Customizar as páginas de erro (404, 405, etc..).

Descrição

Como desenvolvedor do sistema, gostaria de encontrar um padrão nos controllers da API.

Motivo

O módulo next-connect parece estar se tornando quase que um padrão para quem desenvolve uma aplicação mais elaborada com Next.js. Fora que ele é extremamente similar com a forma Express de se declarar rotas/controllers.

Com ele poderemos de forma mais organizada usar middlewares de autenticação, autorização e tratamento de erros de forma centralizada.

Olá pessoal,

Acredito que a fundação deste tema está dividido em 3 partes:

• Conexão com o banco de dados
• Migrações para criar/alterar as tabelas de forma programática
• Consulta ao banco (que pode ou não utilizar um ORM)

Me parece que no Next.js tem o https://www.prisma.io/ e https://github.com/typeorm/typeorm.
Aparentemente resolvem os 3 pontos acima. Talvez uma desvantagens é ter que instalar typescript (já que o projeto inicialmente não vai usá-lo)

Uma alternativa que acredito interessante e não sei se no NodeJS/Javascript tem, é algo que já utilizei no Python, algo nesta linha aqui: https://nackjicholson.github.io/aiosql/

É bem minimalista, ou seja, temos que resolver a conexão e migrations com outras bibliotecas,
mas é muito mais simples, não tem um ORM (e definições de Models)

Obs: ORM é bem legal, tem diversas vantagens, mas a maior desvantagem pode ser que quando voce precisa fazer uma consulta um pouquinho mais complicada, coisa q no SQL puro é bem simples e direto, no ORM pode ser dificil

Tem isto em varias linguagens, onde temos o SQL puro, mas ainda separado e com uma abstração bem pequena

## No código:
queries.get_all_greetings(conn)

## Na camada do banco:
-- name: get_all_greetings
-- Get all the greetings in the database
select greeting_id, greeting from greetings;

Bom, o que voces já trabalharam para resolver isto no nodejs/next.js?

Abraço

Vendo o layout não localizei a opção para compartilhar nas Rede Social (sugestão: linkedin, twitter, facebook), podendo incluir também a opção de salvar para ler depois.

Pessoal, fiz um rascunho das Milestones (Marcos Históricos) do TabNews para cadastrar aqui no Github e começar a organizar as issues. Com isso vamos ter uma noção de progresso do projeto e nada disso está escrito em pedra, inclusive preciso de muita ajuda, pois faz tempo que não organizo um projeto dessa natureza. E com certeza quanto mais avançarmos nas tarefas, mais são reveladas e mais precisão vamos tendo ao longo do caminho.

Mas por enquanto, o jeito que organizei foi MPVs funcionais, onde de pouco em pouco vamos comemorando as conquistas e chegando nas features extras e algumas delas não precisam ser executadas nessa ordem que eu coloquei (principalmente as que estão na Milestone 6, podem ser antecipadas sem problemas 👍 )

Milestone 0: Em construção

• Merge ou Close dos PRs sobre POCs ainda em aberto
• Home clássica "em construção" com foto de todo mundo que quiser aparecer nesse momento histórico do projeto 😍
• Colocar em produção no domínio tabnews.com.br

Milestone 1: Fundação

• Manutenção das issues (quais fechar?)
• Tipo da Licença
• Falar sobre Arquitetura e definir padrão de pastas
• Definir padrão de commits/linter
• Definir padrão de code style/linter/code formatter
• Conexão com banco de dados
• Migration
• Rodar testes local e CI

Milestone 2: Auth e Usuários

• Separar entradas do Diário em arquivos isolados
• Atualizar README com instruções sobre como instalar, rodar ou testar o projeto (incluindo usando act)
• Avaliar transformar o Database em um Singleton para reutilização do Pool
• Criar um .prettierrc
• Remover do package.json o "test:ci" e mover para Action
• Definir quem será o "Guia de Acessibilidade"
• Padrão nos controllers usando next-connect
• Padrão de retorno das APIs (Dados e Erros)
• Sistema de Autenticação
• Sistema de Autorização (ACL)
• CRUD de Usuários

Milestone 3: Notícias e Comentários

• CRUD de Notícias
• Lógica de ordenação das Notícias V1: pela mais recente (e mais nada)
• CRUD de Comentários e sub-comentários
• Página de Status mostrando todos os números do projeto

Milestone 4: TabCoins

• Sistema de TabCoins
• Sistema de Auditoria
• Lógica de ordenação das Notícias V2: (TabCoins - Tempo de Publicação)

Milestone 5: XP (ou outro modelo)

• Sistema de XP

Milestone 6: Revenue Share

• Sistema de Revenue Share

Milestone 7: Recursos Cereja do Bolo

• @pscruzzz - DarkMode
• @SysDaemon - RSS
• @rodrigoKulb - Botão de compartilhar notícia em redes sociais
• @brunofamiliar - Extensão para Navegador (já fez PR)
• @luantoningalvan - text-to-speech
• @LuanEdCosta - Integração com Unsplash
• @lucasbaccan - PWA
• Atualizações em tempo-real

Considerações

• Tudo pode mudar (e vai mudar 😂 )
• Itens podem ser antecipados, por exemplo os que estão na Milestone 6