afts Componente Acbrba - Balança AFTS

[Paulo Henrique de Castro]

Bom dia,

Adaptei comunicação com a balança rodoviária da AFTS .

Se for de interesse da comunidade, gostaria de contribuir com este fonte,

este foi desenvolvido com base na balança Digitron, fiz alteração retirando a divisão para colocar decimais e  invertendo o peso.

exemplo:

peso lido é de "000100" peso é "1.000"

peso lido é de "010100" peso é "1.010"

peso lido é de "009100" peso é "1.900" 

Segue em anexo a unit ACBrBALAFTS.pas e a alteração na ACBrBAL.pas.

Se houver a necessidade de alguma modificação fiquem a vontade para me passar ou realizá-las.

O manual com o protocolo se encontra

Atenciosamente.

ACBrBALAFTS.pas

ACBrBAL.pas

Manual AFTS.pdf

[Paulo Henrique de Castro]

Me perdoe acabei criando dois POST iguais minha maquina estava travada acabei clicando novamente e salvando um outro post.

[Daniel Simoes]

Obrigado pela contribuição... Já está no SVN, com pequenos ajustes...

[Dipold]

Eu já havia escrito código para essa balança há 1 ano atrás (embora meu código estava considerando apenas a parte inteira da leitura, sem decimais), juntamente com a balança rodoviária Toledo...

Infelizmente minhas contribuições ficaram no esquecimento... Sistema de Controle de Versão por Fórum não tem como funcionar direito...

[Juliomar Marchetti]

12 minutos atrás, Dipold disse:

Eu já havia escrito código para essa balança há 1 ano atrás (embora meu código estava considerando apenas a parte inteira da leitura, sem decimais), juntamente com a balança rodoviária Toledo...

Infelizmente minhas contribuições ficaram no esquecimento... Sistema de Controle de Versão por Fórum não tem como funcionar direito...

Desculpe mas não dá pra fazer o que tu quer ali e nem cogitamos a ideia de Git! porque senão viraria um pan demonio!

fora que sendo o svn ainda simples o pessoal se perde!

além de termos que filtrar códigos que não servem e nem podem ser aproveitados!

[Waldir Paim]

@Juliomar Marchetti

Não quero criar polemicas nem sou contra ou a favor.

 

Citar

Desculpe mas não dá pra fazer o que tu quer ali e nem cogitamos a ideia de Git! porque senão viraria um pan demonio!

fora que sendo o svn ainda simples o pessoal se perde

Um passo para a evolução já foi dado pelo próprio projeto quando definiu que não daria suporte oficial para compiladores que não sejam Unicode a partir de Agosto desse ano.

Mas sei também da postura de não adotar o GIT, até já questionei sobre isso em outro post.

Mas não podemos nivelar os usuários por baixo e dizer que não muda de versionador por dificuldades de alguns usuários pois se fosse assim ainda teria que manter suporte a IDEs antigas, alguns reclamaram mas a grande maioria gostou desse decisão e estão evoluindo juntos.

GIT na minha opinião é quase uma unanimidade para a maioria dos projetos e mais cedo ou mais tarde o SVN perde força se já não perdeu.

O pascal evoluiu muito nesses últimos anos até para não perder todo seu espaço para outras linguagens, que por outro lado evoluem diuturnamente.

Uma sugestão sobre o versionador seria abrir uma pesquisa ou enquete e pedir a opinião de outros usuários, com isso a gente conseguiria ver o que a maioria acha disso.

 

Citar

além de termos que filtrar códigos que não servem e nem podem ser aproveitados!

Nesse caso a atribuição de dos membros com poder de commit e não podemos te ajudar nesse ponto.

Não leve como uma critica por favor, quero apenas demostrar que as coisas evoluem e nunca podemos dizer nunca para algo tão volátil como tendencias. 

[Daniel Simoes]

Tive uma breve experiencia com o GIT no Fortes Report... Minha conclusão foi "ódio a primeira vista"... GIT é complicado, burocrático, e caótico...  

Não vejo como fazer "Push Request" de maneira simples nos fontes do ACBr... todas as contribuições que recebemos exigem MUITA analise e correções... antes de subirmos para o SVN..

No que depender de mim... continuamos com SVN por um bom tempo...

[Dipold]

17 horas atrás, Juliomar Marchetti disse:

Desculpe mas não dá pra fazer o que tu quer ali e nem cogitamos a ideia de Git! porque senão viraria um pan demonio!

fora que sendo o svn ainda simples o pessoal se perde!

além de termos que filtrar códigos que não servem e nem podem ser aproveitados!

Como assim, "não dá pra fazer o que tu quer ali"? O que havia de errado na minha contribuição?

Com relação à crítica ao GIT, e de tudo que andei lendo nesse fórum à respeito, é visível que os que criticam desconhecem profundamente como o GIT funcionaria e quão mais simples e poderoso seria que o SVN + fórum atual. Eu trabalhei anos com VCS e SVN e grande sacada do GIT não é o GIT em si, mas o GITHUB.COM.

Para efeitos didáticos, vou relacionar aqui como "seria" o ACBr no github.com:

• Todo repositório ficaria em um branch chamado master, e apenas Daniel Simões poderia alterá-lo e, opcionalmente, dar o mesmo poder à outros;
• Nenhuma alteração, nem mesmo Daniel Simões, seria feita diretamente no master, ela é sempre feita em forma de Pull Requests (PR), que é um pacote de alterações com um ou mais commit´s, que é publicado para ser discutido e, quando aprovado pelos interessados, faz-se o mergeamento dele no master;
• Tudo que cito aqui, fazer PR, Fork, Branch, Commit, etc, são só botões que o usuário clica na interface do github.com ou usando um programa auxiliar como o GitHub For Desktop, não há nada de complicado. A burocracia pode ser resumida em um arquivo "Como Contribuir" em apenas alguns passos:
  • Fazer um fork do projeto ACBr na sua conta do github (que é tipo uma cópia local);
  • Programa as contribuições em um novo branch nessa cópia, dividindo as alterações em pequenos commits;
  • Sobe essas alterações para seu fork, a opção para fazer um Pull Request (PR) irá surgir automaticamente;
  • Faz o PR para o ACBr explicando sua contribuição em um texto. Isso cria um novo branch no repositório original e só o que foi alterado fica visível;
  • Daniel Simões, moderadores e interessados acessam o PR e fazem sugestões de adequação/melhorias, comentando diretamente nas linhas do código, ou solicitando adequação de arquivos relacionados como documentação, exemplos, testes unitários, etc.;
  • O usuário faz novos commits adequando o código às solicitações. Repete-se o ciclo até a contribuição ficar perfeita e irretocável;
  • O PR agora é um pacote de alterações, e está pronto para ser mergeado, pois todos os membros participantes aprovaram as alterações;
  • O Daniel Simões aprova o PR, apenas clicando no botão Aplicar PR, que mergeia o código no master e apaga o branch criado;
• Para relatar uma dúvida, um bug, uma sugestão:
  • Abre-se uma Issue no projeto, que é tipo um tópico em um fórum;
  • Qualquer um pode respondê-la/comentá-la;
  • Um moderador classifica/etiqueta a Issue como: bug/regressão/dúvida/sugestão/etc. e pode fechá-la ou mantê-la aberta;
  • Caso seja um bug ou sugestão, mantem-se aberta. Qualquer usuário pode então criar um código para atender essa Issue, e ao fazer o PR, ele linka com a Issue relatada;
  • Qualquer um que queria contribuir pode olhar na lista de Issues abertas e contribuir, seja respondendo uma dúvida, ou fazendo um PR com alterações no código. O objetivo da comunidade é ir fechando todas Issues abertas;

As vantagens são claras:

• Não há mais necessidade de manter um fórum, e até mesmo a página pois o GitHub fornecesse tudo isso de graça. Pode-se trabalhar com releases periódicos, e que ficam hospedados nele, sem qualquer ônus; 
• Os moderadores apenas "moderam e supervisionam". Não há mais necessidade deles ficar baixando código dos anexos dos tópicos, olhando, tentando compilá-los, corrigindo e adequando-os manualmente e então subindo para o SVN, pois todo esse trabalho é transferido para os próprios usuários que estão contribuindo;
• Há sim uma certa "burocracia", mas ela não é à toa, é uma burocracia que trás enormes vantagens à qualidade das contribuições, e pode ser facilmente ensinada em um pequeno tutorial de 15-20 linhas;
• Cada contribuição fica em evidência na lista de PR´s, não tem como cair no esquecimento. Não depende mais do fator: "moderador ter tempo";
• O usuário comum que quer testar aquele PR antes dele entrar no master, pode fazer um fork dele e pronto. Já sai testando. Hoje o usuário tem q baixar as units do anexo do fórum, copiar para as pastas corretas, modificar os dpr´s, tentar compilar, etc, etc. etc.;
• O código só entra no master quando a comunidade o aprova, o que gera menor possibilidade de bugs;
• Tudo fica devidamente documentado, pois tem acesso a toda discussão que determinada linha de código passou antes de entrar no repositório, pois um PR pode ser linkado com outros PR e Issues de forma que vc tem todo histórico de vida de cada alteração;
• Quem contribui, mesmo que não seja moderador, terá seu nome na lista de commit´s. Ser reconhecido cria um incentivo maior para contribuir;
• O GitHub dá muito mais visibilidade ao projeto, pois é a maior comunidade mundial de desenvolvedores;
• Vejam como a Caelum, referência na área, lida com seus projetos open-sources como VRaptor por exemplo. Clique nas abas Pull Request e Issues para ver como as contribuições ao projeto ocorrem. Inclusive tem algumas minhas lá. Vejam também quanta contribuição tem nesse projeto e 95% são brasileiros. Porque tratar os programadores Delphi como incapazes de aprender a fazer contribuição no GitHub.com, com relação a programadores de outras linguagens? 
• O GitHub não é apenas um sistema de controle de versão do GIT, ele é uma rede social de desenvolvedores!

Enfim, poderia escrever muito mais à respeito, e de forma mais técnica se preciso, mas vou deixar aqui esse resumo como uma crítica construtiva ao projeto.

 

 

 

[Juliomar Marchetti]

Fechando o tópico pelo visto se deixar vai longe

E o Daniel como nós também já tem a decisão está e ficará em SVN !

[Daniel Simoes]

TLDR