Meu projeto de gerenciador de senhas: Capivara_Password! App mobile 100% em python

Então pessoas que abriram este tópico!

Agradeço pela curiosidade, eu criei ele para divulgar meu projetinho mobile para android.
Fiz ele com python 3, kivy, kivymd e SQL contundo ele usar essas linguagens através do própio python 3.

O meu projeto é um mero gerenciador de senhas, eu batizei de Capivara_Password e está em alpha e debug. Separei em três grupos de telas que são acessados pelo navegation drawer, como pode ser visto na primeira imagem.

Link para o projeto: GitHub - Saulo-Ferro-Maciel/Capivara_Password: trying to create a password manager

8 curtidas

Python e sua versatilidade! Somente um adendo, atente-se ao fato desta aplicação não está licenciada, considere adicionar uma licença ao seu projeto, para que outros tenham a liberdade de usar, e talvez contribuir. :+1:




- Se ao ler isso, e este projeto já conter uma licença, desconsidere este comentário.

7 curtidas

Vou ver, a idea é só para o curriculo, precisa de licença pra isso? Pois nunca soube que pra curriculo precisasse de licença. Mas valeu aí.

3 curtidas

TODO app deve conter licença, independentemente de sua finalidade. nunca s esqueça disso. oq é um projeto de currículo hoje, pode ser o facebook do gerenciamento de senhas amanhã. :stuck_out_tongue_winking_eye: PS: nome original.

4 curtidas

Valeu :+1:, vou vê uma ! Mas não sei se um simplório gerenciador pode ir tão longe kkkkkkkk

2 curtidas

Jamais pense dessa forma. Com a licença, você pode evitar muitos problemas futuros (cópia de código etc) como também agrega conhecimento acerca de como as licenças funcionam, por exemplo.

5 curtidas

Hummm, vou dar uma estudada pois soube que no mundo do open souce e tem várias licenças.

1 curtida

Só passando para dizer que ouvi os conselhos de vocês e coloquei licença nos meus projetos, no gerenciador coloquei o Apache2.0 por ser a do ADROID e de outros projetos para PC coloquei a do MIT.

3 curtidas

Bacana o projeto! :grin: Não sei quais são seus planos de longo prazo, mas se eu fosse você, começaria pelo menos a trocar variáveis do tipo (a, b, c, d ,e) por algo mais significativo e começaria a usar tipagem dinâmica.

Eu sei que parece bobagem agora que o projeto é pequeno, mas você vai ficar feliz de ter evitado essas coisas quando chegar em algo de 50 mil linhas.

3 curtidas

Valeu pelo conselho, esse é dos meus habito ruins. Monte de gente já disse para eu para de criar variáveis com apenas uma letra, e sobre tipagem dinâmica eu já venho dando uma olhada.

Esse é um projeto simples, não pretendo leva-lo muito adiante, pois como já falei ele é projeto para currículo - o quê pretendo dizer é que muitas pessoas vendem o python como a melhor linguagem simples e dinâmica, contudo, não usam frameworks dirigidos 100% em python e à idea era ser nativo do python para mostra que é possíveis.

2 curtidas

Se valer de algo, eu faço seleção na nossa empresa, isso é uma das coisas que, quando aparece no código, costumo perguntar na fase de entrevista, se ele acha que código com variáveis a, b, c, d seria aceito em um merge dos nossos projetos. É bom ver que você está ciente de que não é uma boa prática. De qualquer forma, muito bacana o projeto. :slight_smile:

2 curtidas

Muito obrigado, fico lisonjeado com seus comentários! Como é um projeto de currículo, eu escrevo como pensei ser mais fácil, entretanto, em projeto comercial eu tentaria não praticar esses hábitos para não prejudicar a equipe e atrasar o projeto.

2 curtidas

Apesar de ser apenas projeto para currículo, essa forma de escrever variáveis também é avaliado pelas empresas. Se você faz assim para seus projetos, o que impede de fazer igual em projetos de empresas?

“Ah, mas como é para empresas, eu não farei isso.” - Pois vai, acredite. Mesmo que seja sem querer, mas vai.

Boas práticas são bem vistas até mesmo em projetos de currículo, seja lá qual for.

Comece a evitar por agora antes que seja tarde. Permanecer na falha sabendo da sua existência, é o pior erro que pode ser cometido.

2 curtidas

Realmente, aqui na empresa acabamos dando preferência a quem apresenta código bem escrito, valorizamos especialmente:

  • Se o código resolve o problema principal de forma sólida e simples.
  • É bem escrito, compreensível mesmo sem documentação, consistente (segue um único padrão de nomenclatura, espaçamento, organização, etc).

Resolvendo bem o problema principal com um código bem escrito é o principal mas também observamos quando:

  • O projeto tem conceitos de CI/CD, testes automatizados, etc.
  • O projeto é documentado, especialmente se ha documentação externa.

Também tem questões observadas depois durante o estágio, se é aberto a mudanças, quer melhorar, etc… Essas são algumas coisas que esperamos encontrar em juniors.

2 curtidas

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.