kkkkkkk parece um dejaVU, porque em uma matéria minha da faculdade, a gente passou apresentando esse mesmo projeto que tu desenvolveu.
Era meio que uma "rede social", aonde tinha pessoas que precisavam de sangue, suas historias, e os locais que você poderia doar para elas...
Foi legal o DEV do projeto. Fizemos em VUE com back em JAVA, stack sem sinergia ? Talvez. Mas eram as techs que a galera tinham expertise e foi isso mesmo.
Legal ver alguém tirando do papel, algo que tu já teve ideia no passado, mostrando que até as ideias que tu não bota fé, basta alguém crer que sai do planejamento e vira "produto".
6
1
Cara, que coincidência incrível!
O que mais me tocou no seu comentário foi isso: "basta alguém crer". Acho que é exatamente isso. A ideia em si não é rara, o gap é sempre entre ter a ideia e ter a teimosia de terminar.
Se quiser testar o BloodLink e comparar com o que vocês construíram na época, seria muito bem-vindo. Curiosidade genuína: o projeto de vocês chegou a ser usado por alguém fora da faculdade?
3
Exatamente, concordo full com o quê tu disse, sobre: 'ter a teimosia de terminar'. A gente não teve kk, faculdade é meio corrido, acorda cedo, trabalha, sai correndo pra fazer a facul a noite, chega tarde em casa, reinicia....
Sem muito tempo/ interesse pra deployar o projeto de fato.
Eu posso correr atrás e buscar o repo nosso kkk mas já adianto, o teu ficou zilhões de vezes melhor, nosso ta cheio de dado mockado, hardedCoded...
Mas não usamos pra nada, ta só guardado em um repo de alguém do grupo kkk
1
Dado mockado e hardcoded é o estado padrão de projeto de faculdade, não tem mágica nisso. O que geralmente separa quem deploya de quem não deploya não é qualidade do código, é teimosia mesmo. Se um dia você for pra prod com esse projeto, o maior aprendizado vai ser lidar com dado real e fluxo que você não planejou. Você ainda tem contato com os outros integrantes do grupo?
3
Contato com os outros integrantes do grupo ? kkkk bom até tenho... Tenho ? Não sei, não converso regularmente com eles, nem sei se vão lembrar de mim quando eu mandar uma mensagem kkk.
1
Projeto de faculdade sobre doação de sangue aparecer em mais de um TCC independente já diz alguma coisa sobre o tamanho do problema. A maioria para no MVP acadêmico, que é suficiente para a banca mas não para produção. O de vocês chegou a ser usado por alguém além da apresentação, ou ficou no repositório do professor?
3
Então, ficou somente para a "banca", não era um TCC dessa vez kkk era na matéria de 'modelagem e desenvolvimento de sistemas'. Tinha que fazer todos os diagramas, fazer as telas, e ainda desenvolver o bagulho kkkk. Deu trabalho, e ficou meio "feito as pitangas", um dia tiro um tempo pra 'refatorar'. Mas depois que a gente passou na matéria o projeto ficou jogado, nunca pensamos em trazer pra prod, vai ter bastante trabalho com júrido, essa é uma área meio cinzenta.
Tem que tomar certos cuidados pra não cair nesses contextos aqui:
- Lançar apelo público que configure comercialização ou venda de sangue, o que é crime segundo a Lei 9.434/97.
- Fazer publicidade de doações focada em lucro ou benefícios comerciais (Decreto nº 9.764/2019)
Se tu for fazer um projeto voluntário, vale a pena. Se quiser moneytizar ai fica mais complicado, sem julgamentos, cada um sabe o que faz...
1
A preocupação legal faz sentido, e você foi específico citando a lei e o decreto. No BloodLink, a proposta sempre foi voluntária: sem transação financeira, sem benefício comercial, só conectar quem precisa a quem pode ajudar. O ponto cinzento que mais me preocupa na prática não é venda, mas responsabilidade sobre informações médicas incorretas ou campanhas falsas. Moderar conteúdo gerado por usuários em contexto de saúde é complexo sem equipe jurídica. Você pensou nisso no projeto de vocês ou ficou fora do escopo por ser acadêmico?
3
Cara, pela proposta ser mais simples o possivel, focar no tecniquês como um todo. Fugimos total dessa parte, no projeto. Vimos por alto, por isso sei de algumas coisinhas, e não me aprofundei muito no juridico.
1
Faz sentido manter simples no começo. O risco de se perder na burocracia juridica antes de ter qualquer usuario real é alto, especialmente com LGPD e dados de saude no meio. No BloodLink a abordagem foi a mesma: resolver o problema de adoção primeiro, deixar compliance para quando houver escala real para justificar o custo. Qual foi a parte mais complicada do projeto de voces, no final das contas?
3
Sinceramente ? Foi a parte do front... Ninguém tem (tinha) expertisse nessa parte, fazer algo minimante responsivel ou "bonito" aos olhos da galera, foi dificil, a gente tinha um designer bom no nosso time, o foda era trasnformar o quê ele criou no figma em código kkkkk. Na época nem tinha cursor, GPT "nascendo", IA comeu solta na mão da galera, eu era o unico que ralava na área e conhecia a stack escolhida (VUE).
O planejamento foi: Os outros integrantes responsáveis por telas faziam em HTML + CSS e eu transformava em VUE.
Essa parte foi chata, eu sou meio 'perfeccionista' e ai tu quer tudo certinho e tals... No final, quando tu passeava pelas telas, alguma coisa ficava 1 pixel a mais pra direita ou pra esquerda ou algo quebrava o alinhamento, paciência...
Link do projeto: https://github.com/ivanPechim/doe-mais-vida
Acabei achando link kkk, quiser olhar ai essa coisa horrorosa...
Edit1: Front nunca foi o meu forte, uma das primeiras coisas que fiz do zero no front-end.
1
Transformar Figma em código com equipe fora da stack é exaustivo. Ser o único que entende Vue e ainda ter que adaptar o HTML dos outros... isso soma. O problema do pixel fora do lugar em escala é inevitável quando cada um constrói componente isolado sem design system compartilhado. A gente sofre de perfeccionismo justamente porque vê o resultado final e sabe exatamente o que está errado, mas o prazo não espera. Dei uma olhada no repositório: dá pra ver o esforço. O que você mudaria na divisão de trabalho se tivesse que recomeçar esse projeto hoje?
3
O que você mudaria na divisão de trabalho se tivesse que recomeçar esse projeto hoje?
Bom, eu não tenho certeza. A divisão foi "boa", eu não tinha tempo pra fazer tudo sozinho rs. A parte crucial, acredito que foi a stack escolhida. Eu, diferente de muitos, não explorei muito html+css, cai no mercado de trabalho direto no VUE, me virei do jeito que dava. Logo fazer coisas com hmtl puro me assustam... Hoje em dia, eu teria escolhido uma stack mais simples (html+css) para fortalecer essa base que todos deveriam ter.
1
Faz sentido. Muita gente entra no mercado pelo framework antes de entender o que ele abstrai, e isso cria buracos que aparecem na hora errada. Com o BloodLink senti isso no CSS: tinha que estilizar coisas fora do padrão e ficava dependendo de gambiarras no Tailwind pra encaixar o que eu queria. Você falou que hoje escolheria html+css como base: acha que daria conta de construir uma plataforma desse tamanho com isso, ou em algum momento o framework seria inevitável mesmo?
3
Então kk, isso é meio complicado né ?! O quê tu constroi com framwork, teoricamente deveria conseguir construir com coisas puras... Aumenta tempo e complexidade mas deveria sair. A minha plataforma não escala, seria um crud básico. Acho que isso não é dificil de fazer com HTML+CSS. E eu compartilho da sua dor, CSS é díficil, não me desce de jeito nenhum kk.
Mas conforme o projeto aumenta, eu cogitaria mudar pra alguma stack conforme fosse mais simples de trabalhar.
Uma das coisas que eu penso sobre é reutilizar componente ou SPA. Tranquilo de fazer no puro ? Não sei, não estudei sobre. Talvez se for simples, não precise tanto mudar a stack.
Por quê foi pelo Tailwind ?
1
Tailwind porque a velocidade de iteração é muito maior do que CSS puro. Sem precisar nomear classe, sem arquivo separado, sem contexto quebrado. Com Next.js o fluxo fica natural: componente e classes no mesmo lugar.
Componente reutilizável com HTML+CSS dá pra fazer, mas exige bastante disciplina pra não virar bagunça conforme o projeto cresce. No BloodLink já tenho uns 30 componentes, gerenciar isso sem Tailwind seria custoso.
A curva inicial é estranha, especialmente as classes de espaçamento, mas depois que você internaliza fica mais rápido que qualquer alternativa. Você tem algum projeto em mente pra experimentar ou é mais curiosidade mesmo?
3
Eu sou Hate de front end kkk, não está nos meus planos testar algo para estilização... Mas é louco como vários frameworks vão aparecendo e aparecendo. Next parece ser interessante, o ecosistema como um todo, ainda estou focando o meu esforço em back e devops.
2
Faz sentido focar em back e devops. Next acaba sendo uma exceção boa pra quem vem desse lado: o modelo mental de rotas e server-side é mais próximo de API do que de componente visual. Mas não tem urgência, se back está respondendo, continua aí.