gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
EvaristoCFG Aplicativo para o Evaristo
Contribuído por scorpio em 04-06-06 21:41
do departamento software:pt_PT
Linux mrmax escreve "Eu resolvi desenvolver o EvaristoCFG porque o Evaristo não permite anular facturas, para adicionar a taxa de IVA dos Açores temos que fazer 3 passos sendo um deles ter que editar um ficheiro para validar a taxa, para Adicionar o nome da Empresa nas facturas e por o logotipo da mesma temos que editar 3 ficheiros, o que não é nada agradavel ter que repetir 3 vezes os mesmos passos. Então porque não ter uma aplicação que faz isso tudo com apenas alguns cliques? "
" O que o EvaristoCFG faz é o seguinte:
  • Permite anular Factura
  • Facilidade em editar os dados da Empresa
  • Adicionar taxas de IVA de uma forma facil

Mais informações visite: EvaristoCFG "

Listas de colocação dos professores - Apenas em IE | infra-estruturas para o mundial 2006  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • EvaristoCFG
  • mrmax
  • Mais acerca Linux
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Muito fixe (Pontos:1)
    por lusotech em 05-06-06 17:53 GMT (#1)
    (Utilizador Info) http://www.lottoassistant.eu
    Vou experimentar...
    EvaristoCFG Aplicativo para o Evaristo (Pontos:1)
    por tuxado em 05-06-06 19:44 GMT (#2)
    (Utilizador Info) http://www.linuxoeste.org
    Olá, Em primeiro lugar tenho q dar os parabens pela iniciativa, acho q faz parte da filosofia do software livre melhorar as aplicações e partilhar com os outros essas mesmas melhorias. Não posso no entanto deixar de fazer alguns comentários construtivos: 1º depois de ler o código, vejo q a abordagem é um pouco destrutiva, se já tivermos algumas configurações ou mesmo se for acrescentada uma tag ao "company-data" o evaristocfg simplesmente apaga tudo o q lá esteja. A meu ver seria melhor usar o dom e trabalhar directo nas tags em vez de simlpesmente escrever o ficheiro do zero. 2º Quanto á tão falada questão de apagar facturas, tanto quanto sei, a lei portuguesa não o permite, este assunto tem gerado grandes polémicas porque software a,b e c deixam e o evaristo não, pois bem a meu ver o evaristo está certo mas não posso deixar de dizer q a mim também me dá jeito ;-). Pelo q vi, para anular um documento não basta apagar as linhas na tabela como o evaristocfg está a fazer, pois dessa forma lá se vão os dados financeiros e os stocks "á viola", se reparares existem triggers na bd, algo dificeis de inverter. Por ultimo, quanto ao iva tudo bem, se bem q a unica coisa necessária quando se introduz uma nova taxa é alterar a sua designação num ficheiro. Com isto espero estar a contribuir com ideias, já agora era bom incluires a alteração da string de ligação á bd nos relatórios, essa sim dá algum trabalho para quem é um pouco novato em unix. Disponibilizo-me desde já a ajudar no que fôr preciso, especialmente pq é Python ;-). Bem haja a todos!!!
    Because life should mean something!!!
    E esta, hein? (Pontos:1)
    por m16e em 05-06-06 20:07 GMT (#3)
    (Utilizador Info) http://www.m16e.com

    São as maravilhas do software livre :-D

    Antes de mais, parabéns pela iniciativa. Pena é não nos teres contactado primeiro ;-)

    Presumo que tenhas começado o teu trabalho com base em versões anteriores à 2.3, dado que a partir desta já existe um configurador da aplicação (install.sh).

    Quanto à história de remover documentos (facturas, etc) e não falando dos constragimentos legais que são, em última análise, da responsabilidade de quem produz o documento (isto é, quem está a emitir a factira): pensaste no que poderia acontecer apagando um documento anterior ao último produzido? Como é que o "buraco" seria preenchido?

    Hint: a maneira correcta de apagar documentos passaria por criar um conjunto de triggers que actualizem as tabelas da aplicação (dados financeiros e stocks) -- procurar na base de dados pelos triggers de inserção de documentos e criar novos para a sua remoção -- é (quase) só trocar o sinal ;-)

    Carlos Correia


    Re:E esta, hein? (Pontos:2)
    por gass em 05-06-06 22:39 GMT (#4)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    Normalmente para estas coisas utilizam-se notas de devolução e coisa e tal, ou notas de credito (ou debito).

    A anulação de facturas é um caso especial, sem o ser.

    Claro que é facil apagar a factura, mas depois, tens uma incorrecção legal, falta a factura nº tal. Logo, tens um crime de colarinho branco.

    Talvez seja melhor criar um trigger, como o carlos diz, que inverta a factura, isto é, reduza os respectivos valores no stock, podendo ainda ser adicionado, talvez, um campo a informar que a factura foi anulada.

    Ao mesmo tempo ficas com a factura disponivel, mas não valida. Pegas em todas as cópias, escreves um ANULADO em todas elas, agrafas e guardas. Este é o metodo mais correcto, ficas com a prova documental de que a factura está anulada.

    Não sei realmente se és obrigado a guardar cópia da factura (penso que sim), pelo que, em vez da cópia, ficas com todas as cópias e original, mas inválida.
    Cumps-
    Gass
    Re:E esta, hein? (Pontos:1)
    por humaneasy em 05-06-06 22:49 GMT (#5)
    (Utilizador Info) http://www.care3g.org
    Este é o método mais legal e que não dá chatices. Se emitiste uma factura é melhor teres o original a dizer anulado ou no caso de ter mesmo seguido para um cliente que depois não paga então tens de emitir uma nota de crédito em nome do mesmo.
    Re:E esta, hein? (Pontos:1)
    por m16e em 05-06-06 23:02 GMT (#7)
    (Utilizador Info) http://www.m16e.com

    Tanto quanto eu sei, legalmente, só se pode "anular" uma factura (notem as aspas), com uma Nota de Crédito.

    É claro que há uma série de situações em que é aconselhável alterar a factura (engano do utilizador e o original ainda não foi enviado para o cliente, por exemplo). Sendo a responsabilidade última de quem emite a factura, não parece haver impedimentos legais a que um sistema de gestão as possa alterar depois de emitidas, desde que se trate de uma correção de um engano, por exemplo.

    Nessa perspectiva, está no topo da nossa TODO list implementar essa funcionalidade. à custa de triggers, de algumas validações na interface sobre quem tem permissões de o fazer e de um registo das alterações efectuadas -- keep in touch :-)

    Anular Facturas (Pontos:1)
    por mrmax em 06-06-06 9:58 GMT (#11)
    (Utilizador Info)
    Quanto a parte de anular facturas, quem já experimentou o EvaristoCFG ou quem viu o codigo, pode ver que o EvaristoCFG não remove a factura da base de dados, o que ele faz é guarda o nome do cliente, põe a factura a 0¤ e nas observações "Documento Anulado". Assim ficam sempre com as facturas todas. De qualquer forma obrigado pelas criticas pois só assim é que podemos evoluir :)
    Re:Anular Facturas (Pontos:2)
    por gass em 06-06-06 17:13 GMT (#12)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    humm ... assim é outra opção, desde que n haja movimento de stock.
    Cumps-
    Gass
    Re:E esta, hein? (Pontos:1)
    por humaneasy em 05-06-06 22:52 GMT (#6)
    (Utilizador Info) http://www.care3g.org
    Podias um dia destes pensar em usar o Tango, não podias? :)

    Um abraço.
    Re:E esta, hein? (Pontos:1)
    por m16e em 05-06-06 23:09 GMT (#8)
    (Utilizador Info) http://www.m16e.com

    Prefiro samba... ou Jazz ;-)

    A sério: é fácil fazer um novo conjunto de ícones (basta dar uma olhada no directório './img/') e todas as propostas são bem-vindas! De preferência em formato SVG. Podes começar ;-)


    Re:E esta, hein? (Pontos:2)
    por tuxe em 05-06-06 23:17 GMT (#9)
    (Utilizador Info) http://luisnyheter.blogspot.com/
    Em 1o lugar, parabens pelo Evaristo! :D

    No entanto os icones são realmente maus... :(
    Que tal um textinho por baixo?

    Keep up the good work!
    É só mesmo... (Pontos:1)
    por humaneasy em 07-06-06 1:42 GMT (#15)
    (Utilizador Info) http://www.care3g.org
    ... porque a malta do Tango tem gente de muitas origens técnicas -- no que se incluem marmelos da Usabilidade -- e como aparenta caminhar (devagarinho) para um interface/icon comum usável no KDE e GNOME, entre outros, seria talvez uma boa ideia pensares nisso.

    Vê se puderes o Generic Icon Theme Guidelines que não deixa de ser interessante como inspiração.

    Não vi ainda como calculas qual o naming convention que estás a usar mas se usares algo mais Standard facilitas o trabalhinho dos designers eventualmente interessados.

    Ah! Os icones do Tango são em SVG e RGBA PNG, topas ;)

    Deixo-te alguns bonecos iniciais do Tango.

    Ouvi dizer que o pessoal que anda pela lista deles costuma ser interessado e prestável. Pede ajuda que até pode ser que tenhas sorte. Quem sabe?

    Lopo
    Re:É só mesmo... (Pontos:1)
    por m16e em 07-06-06 13:26 GMT (#19)
    (Utilizador Info) http://www.m16e.com
    Eu estava a sugerir que fosses tu a fazer esse trabalho, eu até gosto destes ícones e demoraram um dia inteiro a fazer ;-)

    Quanto aos nomes dos ícones, a Icon Naming Specification não cobre o software de gestão. Se reparares, uma boa parte, se não a maioria, dos ícones são específicos da aplicação... de qualquer modo, estou aberto a sugestões, podes enviá-las para aqui ;-) Carlos

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 06-06-06 17:16 GMT (#13)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    isso é compilado com java livre também? É que estou para testar novamente o programa (testei e n gostei de aquilo ser um programa de popups, n sei se está igual ou não).

    Existem muitos downloads para windows? Não se poderia ter uma versão exclusiva de linux, em que aproveitasse, por exemplo, as ferramentas de integração com gnome.

    não quero nenhuma flame, apenas quero uma opinião.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2, Informativo)
    por m16e em 07-06-06 1:02 GMT (#14)
    (Utilizador Info) http://www.m16e.com

    Toma lá a opinião (e um pouco de fogo para animar):

    1. Java livre: das máquinas virtuais Java (livres) que conheço, não há nenhuma que implemente completamente a parte da interface com o utilizador (swing), o que faria com que se perdesse a portabilidade ("compile once")...
    BTW: se a JVM não implementa a API a 100%, como é que se resolve o problema da parte que fica por implementar? em C? notNet? GTK?
    BTW2: provavelmente até ao fim do ano o Java será publicado sob uma licença "decente", sendo um dos objectivos declarados da Sun que venha a fazer parte do repositório main da Debian... eu sei, ainda hão-de correr muitos bytes nas mailing-lists, but, eventually?

    2. Popups: realmente foi uma opção de gosto -- atrai-me a liberdade proporcionada por um sistema MDI em contraponto com o SDI (várias janelas por aplicação versus uma única janela), e tem a vantagem de facilitar um desenvolvimento modelar e verdadeira independência em relação à interface)
    Nota: a pedido de várias famílias, essa opção foi adicionada à wish-list ;-)

    3. Downloads: de há um mês e pouco para cá, ou seja, desde que foi publicada a versão 2.3 (e como podes verificar aqui ) foram feitos (no momento em que escrevo estas linhas) 933 downloads da versão Windows e 435 da versão genérica (que serve qualquer sistema operativo).

    4. Integração com Gnome (tragam a gasolina, por favor): então, e o KDE? XFCE? Blackbox, etc, etc? -- aqui estás com azar... partilho da opinião do Linus sobre o Gnome... e onde é que encaixava o "compile once"? Pior:embirro mesmo com o Gnome (agora, que até há 3 anos atrás era o gestor de janelas que usava... KDE not free, etc e tal)

    5. Um pouco de história: quando o projecto nasceu (em 2001) usava tanto Windows como Linux ou Unix (SCO) e o grande problema que se colocava então era desenvolver uma aplicação que que não tivesse de ser expressamente compilada em cada um dos sistemas alvo e mantivesse o mesmo comportamento independentemente da combinação plataforma/sistema em que estivesse a correr. Nessa altura, a resposta era só uma: Java. Hoje, ainda é (e por favor, não me fales em interfaces web, que, mesmo depois de terem "inventado" o AJAX e a Web 2.0, ainda têm um longo caminho a percorrer até atingirem as funcionalidades e a verstibilidade do Java).
    Digamos que fiquei traumatizado após alguns anos a desenvolver sistemas de gestão em C tendo como alvo Windows e Unix ;-)

    Só para terminar (só mais um pouco de gasolina): não, não gosto da licença do Java, preferia que fosse GPL ou semelhante, mas sempre a considerei suficientemente aceitável, sobretudo tendo em consideração o historial da Sun em relação à activação daquelas cláusulas de digestão mais complicada: só as accionou uma vez e o alvo é agora conhecido como "notNet", "Java--" ou "Mono"... talvez por oposição a "Stereo" ;-)

    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 07-06-06 6:18 GMT (#16)
    (Utilizador Info)

    O Kaffe utiliza, Classpath, que tem mais de 98% da implementação de Java 1.4.. Precisas de mais?

    Gnome não é um gestor de janelas. Tem um gestor de janelas oficial, chamado Metacity. Mas é muito mais que isso, e o KDE também. A integração com o window manager é pouco relevante, mas a integração com o ambiente de desktop permite, poupar tempo no desenvolvimento e aumentar a quantidade de features que não fazem parte do core da aplicação, mas que são uteis ao utilizador, de forma mais rápida.

    As interfaces web, até são uma possibilidade, não vejo porque não. Mas para além disso podes simplesmente usar webservices com SOAP (tendo em conta que até tens a interface em XML), ou então utilizares CORBA, dependendo do que fosse realmente melhor para o caso do Evaristo.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 07-06-06 13:16 GMT (#18)
    (Utilizador Info) http://www.m16e.com
    Estive a ver o estado actual do Kaffe (a última vez tinha sido há uns 6 ou 7 meses e ainda faltava completarem o suporte a impressão e localização), e fiquei impressionado. Teoricamente, o Evaristo já deverá funcionar com o Kaffe! Alguém já o testou?

    Quanto às interfaces web, são uma possibilidade, mas ainda não vi nada que me enchesse as medidas ;-)

    SOAP, talvez, agora CORBA? Não a esta escala, não é necessário, atrasa o desenvolvimento e é demasiado pesado, só mesmo se for absolutamente necessário para interagir com outra aplicação.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 07-06-06 19:53 GMT (#22)
    (Utilizador Info)

    Tenho estado a usar SOAP, WSDL e Python num projecto. Constato que o desenvolvimento para além de extremamente rápido é também muito fácil.

    Se tivesse acesso a documentação melhor e ao código fonte de algumas das aplicações que estou a integrar com as que estou a desenvolver, mas que para além de proprietárias, estão sob a alçada de outra empresa, a coisa ainda avançaria mais depressa, mas o que vale é que o WSDL e as API de Python facilitam muito.

    Devias considerar a hipotese de utilizar estas tecnologias (pelo menos de forma complementar), pois permitem uma integração e adaptação a novas necessidades sem dores. São fáceis de aprender, são muito fáceis de usar e permitem facilmente aumentar a produtividade.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Cyclops em 07-06-06 9:15 GMT (#17)
    (Utilizador Info)
    1. Java livre: das máquinas virtuais Java (livres) que conheço, não há nenhuma que implemente completamente a parte da interface com o utilizador (swing), o que faria com que se perdesse a portabilidade ("compile once")... BTW: se a JVM não implementa a API a 100%, como é que se resolve o problema da parte que fica por implementar? em C? notNet? GTK? BTW2: provavelmente até ao fim do ano o Java será publicado sob uma licença "decente", sendo um dos objectivos declarados da Sun que venha a fazer parte do repositório main da Debian... eu sei, ainda hão-de correr muitos bytes nas mailing-lists, but, eventually?
    Atenção que o Init j+a está desactualizado, a classpath implementa 99.17% da API 1.4

    O caso da SWING é onde há mais quebras que contribuem para não term os 100%, mas quando falamos de 99.17% da API implementada, a probabilidade é já não afectar o Evaristo!
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 07-06-06 13:31 GMT (#20)
    (Utilizador Info) http://www.m16e.com
    (...) mas quando falamos de 99.17% da API implementada, a probabilidade é já não afectar o Evaristo!

    Disseste bem, não afectar... Aqui há uns meses atrás não era assim, e muito menos há 5 anos, quando nasceu o projecto. Pelo que estive a ver, agora não deve haver problemas.

    BTW: já testaste com o Kaffe?


    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 07-06-06 18:13 GMT (#21)
    (Utilizador Info) http://www.m16e.com
    Acabei de testar com o Kaffe e não foi animador... estampou-se logo no início, tanto com o Evaristo como com o Gaudí :-(

    Se alguém o conseguir, por favor, avisem.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por [Cliff] em 07-06-06 20:40 GMT (#23)
    (Utilizador Info) http://www.yimports.com/~cpinto
    Tens de ter uma coisa em mente, é que lá por a API estar implementada a XX.XXX% não quer dizer:

    1) que não tem bugs
    2) que vais obter os mesmos resultados



    ---
    Este espaço pode ser seu...
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 08-06-06 6:07 GMT (#25)
    (Utilizador Info)

    Podes dizer o mesmo em relação às próprias JVM da Sun. Também têm alguns bugs, e não obtens sempre os mesmos resultados entre JVMs para diferentes sistemas operativos e arquitecturas.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 08-06-06 8:38 GMT (#27)
    (Utilizador Info) http://www.m16e.com
    1º: todo o software tem bugs
    2º: uns tem mais bugs que outros

    Num caso, a aplicação funciona sem problemas tanto em Linux como em Windows, no outro, nem sequer arranca.

    :-(

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 07-06-06 21:00 GMT (#24)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    Já vi que isto foi tudo para o calsspath versus sun SDK , well ... forget it. Eu perguntei porque gostaria de re-testar essa aplicação e de a propor para inclusão em distribuições (é fazivel), mas tem o impedimento jdk, por agora.

    1 - concordo. o java sun vai ter uma licença melhor, é uma questão de tempo. True.

    2 - Quanto a sistema MDI vs SDI, é muito confuso os popups (atenção, ainda n testei a ultima versão, portanto posso cometer gralhas). A versão de várias janelas pode provocar demasiada "baralhação" ao utilizador, que foi a minha percepção enquanto nesse papel. Algo do genero unica janela, com popups internos (dentro da main window) e um fundo base imutavel, isto é, sempre com um fundo que n sejam icones ou outras aplicações, que levam o utilizador à confusão. Ficam os argmentos.

    3 - era para ver se se podia ir para linux only :P

    4 - a integração com o gnome é para dar ao utilizador uma noção mais integrada do ambiente, sendo que gnome ao que parece já tem bidings ou classes para java para praticamente todo o seu API. Sou utilizador de gnome e prefiro-o aos restantes. Não vou apontar vantagens nem desvantagens, pois n quero iniciar uma flame, porque nem vale a pena. Ah ... a minha é maior que a tua.

    5 - a minha pergunta de gnome vinha neste sentido, se era de valorizar a portabilidade, ou se linux era mesmo o alvo do evaristo.

    Quanto a linguagens, penso que java é a linguagem de alto nivel a seguir, visto que é a unica que será free (as in speech) a curto/medio prazo. Penso que o mono, embora seja de louvar porque facilita a portabilidade da plantaforma .Net para linux tanto das aplicações como dos programadores, não terá grande futro, até porque as suas aplicações têm muitas tendências suicidas em termos de uso de recursos.

    abraço, e um resto de boa sorte para o projecto. Prometo re-testar o evaristo e contribuir com algo mais contrutivo.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 08-06-06 6:19 GMT (#26)
    (Utilizador Info)

    1 - concordo. o java sun vai ter uma licença melhor, é uma questão de tempo. True.

    A Sun anda a prometer libertar o Java à anos. Na verdade pouco se viu sobre isso. Não vejo que essa opinião seja algo mais que fé, pois baseada no cumprimento de promessas não deve ser, visto terem cumprido tão poucas...

    Algo do genero unica janela, com popups internos (dentro da main window) e um fundo base imutavel, isto é, sempre com um fundo que n sejam icones ou outras aplicações, que levam o utilizador à confusão. Ficam os argmentos.

    Deixo aqui o alerta que nesses casos passas a ter um outro problema para gerir que é o tamanho dos widgets no ecrã do utilizador. Já vi aplicações que em ecrãs de formatos e tamanhos diferentes deixam widgets inacessiveis.

    Quanto a linguagens, penso que java é a linguagem de alto nivel a seguir, visto que é a unica que será free (as in speech) a curto/medio prazo.

    Não acredito que a Sun liberte o Java, muito menos a curto prazo.

    Não sei se caracterizaria o Java como sendo de alto nível.

    Então e o Perl, Python, Ruby, e outras linguagens de propósito geral que são mesmo de alto nível?? Não te estarás a esquecer delas?

    Penso que o mono, embora seja de louvar porque facilita a portabilidade da plantaforma .Net

    Tenho dúvidas sérias sobre até que ponto o Mono .Net consegue isso de uma forma relevante, para valer a pena não utilizar outras tecnologias para atingir essa tal portabilidade.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 08-06-06 17:19 GMT (#31)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    "Deixo aqui o alerta que nesses casos passas a ter um outro problema para gerir que é o tamanho dos widgets no ecrã do utilizador. Já vi aplicações que em ecrãs de formatos e tamanhos diferentes deixam widgets inacessiveis."

    Epah ... conheço um programa de contabilidade feito em Visual Fox Pro, que é uma porcaria em termos tecnicos, mas em termos de usabilidade considero-o muito bom, chama-se Query Pro. Eu ponho aqui uns shots um dia destes.

    Aquilo raramente sobre põe janelas (widgets) e utiliza apenas 1 funcionalidade de cada vez, isto é, se estás a emitir uma factura, não vais ver um extracto mensal (isto é um exemplo para o evaristo).

    "Tenho dúvidas sérias sobre até que ponto o Mono .Net consegue isso de uma forma relevante, para valer a pena não utilizar outras tecnologias para atingir essa tal portabilidade."

    Se visses o que eu vi nestes ultimos meses de pessoal viciado em .Net, não dizias isso. Se não for o mono, quando um dia essas pessoas se virem confrontadas com uma possivel mudança, elas só a farão se tiverem algo similar a .Net em linux, porque SÓ sabem criar aplicações nessa plantaforma.

    "Então e o Perl, Python, Ruby, e outras linguagens de propósito geral que são mesmo de alto nível?? Não te estarás a esquecer delas?"

    Não. Essas linguagens pecam por não serem compilaveis.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 08-06-06 20:08 GMT (#32)
    (Utilizador Info)

    Tendo em conta que boa parte das espcificações de .Net são proprietárias, fechadas, e que a equipa do Mono vai andar sempre PELO MENOS um passo atrás. O Mono dificilmente permitirá verdadeira portabilidade de aplicações com alguma complexidade.

    Não ser compiláveis não é um pecado, é uma caracteristica. Caracteristica essa que as torna mais indicadas para uma série de situações.
    É possível compilar essas linguagens embora seja pouco usual fazer tal coisa. Por exemplo para Python tens o compilador Psyco, que é semelhante a um compilador JIT (JIT é a solução usada normalmente em Java), também podes compilar Python para Java Bitecode e ainda podes graças ao Iron Python (implementação de Python para .net) compilar para a plataforma .Net.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 08-06-06 20:27 GMT (#33)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    "Tendo em conta que boa parte das espcificações de .Net são proprietárias, fechadas, e que a equipa do Mono vai andar sempre PELO MENOS um passo atrás. O Mono dificilmente permitirá verdadeira portabilidade de aplicações com alguma complexidade."

    A minha ideia é do mono como sendo uma forma de transição. Não interessa andar um passo atrás. Desde que implemente a maioria de funcionalidades.

    Pelo blog do Icaza (que leio por ter um agregador de blogs via debian) vês que até conseguem portar quase directamente coisas feitas em .Net para windows, para mono e linux.

    "Não ser compiláveis não é um pecado, é uma caracteristica. Caracteristica essa que as torna mais indicadas para uma série de situações."

    Poes trabalhar em sitios onde podes ter codigo "scriptado", mas em muitos sitios ter o codigo assim é oferecer à pirataria e cópia facilitada.

    Python pode ser sem duvida uma hipotese, até bem boa.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 09-06-06 6:15 GMT (#36)
    (Utilizador Info)

    Sem dúvida que eles devem conseguir portar programas de .Net para Mono, não ponho isso em causa. A questão é que eles suportam apenas um pequeno subset das tecnologias do .Net. Tal como acontece com o WINE, tenho sérias dúvidas se alguma vez conseguiram implementar a maior parte. Mas não seria nada mau que conseguissem.

    Pirataria tem a ver com atacar barcos e aviões.

    Se não existisse cópia ilegal massiva de programas compilados até poderias ter realmente um ponto aí. Não me consigo lembrar de um único caso em que tenha acontecido isso, por isso deve ser um risco assim tão grande. As linguagens de scripting são normalmente utilizadas como linguagens de integração, ou seja, utilizadas para programas à medida que frequentemente não tem utilidade nenhuma para outra entidade. Para além disso, podes sempre compilar esse código, como eu disse no post anterior.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 09-06-06 8:18 GMT (#37)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    "Se não existisse cópia ilegal massiva de programas compilados até poderias ter realmente um ponto aí. Não me consigo lembrar de um único caso em que tenha acontecido isso, por isso deve ser um risco assim tão grande. As linguagens de scripting são normalmente utilizadas como linguagens de integração, ou seja, utilizadas para programas à medida que frequentemente não tem utilidade nenhuma para outra entidade. Para além disso, podes sempre compilar esse código, como eu disse no post anterior."

    É assim:

    Num projecto proposto (que acabou por não se ralizar) tive um sério problema.

    O proposto era um programa que fizesse uma série de configurações automaticas e também permitisse a sua gestão via web.

    fizemos alguns filtros em perl para as configurações e trabalhámos no interface web, em php.

    Como era para sistemas debian, fizemos um pacote de instalação que utilizava o script .postinst para efectuar muita configuração.

    Estes sistemas eram para ser revendidos, o que, se algum carola se lembrasse, bastava copiar as coisas certas dos sitios certos e sem grande trabalho, conseguiria reunir o pacote original.

    Mais que isso, devido a ser tudo scripts, e mesmo que colocássemos algum mecanismo de verificação, ele poderia ser anulado com pequenas alterações directamente no codigo scriptado.

    Mexer em algumas configurações não requeria arte nem engenho. Qualquer script em qualquer linguagem faria o serviço, no entanto era esse pequeno script em que nos iriamos apoiar e era extremamente facil a sua cópia ilegal (ok ... pirataria ... bem...) .

    Além disso tinhamos o frontend web, em php, que já existia 80%. Embora exista um compilador de php, ele não é 100% seguro neste aspecto.

    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2)
    por Init em 15-06-06 20:38 GMT (#48)
    (Utilizador Info)

    Em primeiro lugar se usava o script de pós instalação, então tinham um trabalho derivado desse script, o que me faz imediatamente duvidar da legalidade de vender de forma proprietária esse vosso trabalho.

    Mesmo não sendo scripts poderia ser copiado e usado pelos outros, como acontece com quase todo software proprietário relevante.

    Para além disso como já disse poderias compilar esses scripts.


    «They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790)
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 08-06-06 20:40 GMT (#34)
    (Utilizador Info) http://www.m16e.com
    Aquilo raramente sobre põe janelas (widgets) e utiliza apenas 1 funcionalidade de cada vez, isto é, se estás a emitir uma factura, não vais ver um extracto mensal (isto é um exemplo para o evaristo).

    E por que é que o utilizador não há de poder consultar um extracto (ou oura coisa qualquer) enquanto está a fazer uma factura? É essa noção de "usabilidade" (mas que raio de palavra) que faz muita gente afastar-se do Gnome: "tens de fazer isto desta maneira porque é a melhor maneira de o fazer"...

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 08-06-06 23:17 GMT (#35)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    preciso de chamar-t a atenção de que n falei de gnome, nem queria entrar em flames ... bem ... eu gosto de gnome por muita coisa, uma delas é a "objectividade" de utilização. Atenção, que concordo que existem exageros, como por exemplo as respotas ao linus, cuja feature em questão eu abomino e é alteravel, facilmente.

    Mas pronto, a minha continua a ser maior que a tua.

    Aquilo que referi é uma aplicação de contabilidade em visual fox pro.

    O que aconteceria com os utilizadores "normais" que conheço (normal = n percebem nada de pc, nem windows e caso aconteça algo que n esperam bloqueiam ou fazem asneira) é que as tantas em vez de clickar sei lá onde, clickam nos executaveis do ambiente de trabalho, executam mil e uma coisas, quando, afinal, queriam imprimir uma factura e acabam por reiniciar o pc por aquilo ter corrido mal e levam meia hora para imprimir uma factura porque se enganaram.

    Aqui o que se coloca é que a panoplia de possibilidades não é compativel com facilidade de utilização por pessoas que não dominam os aspectos que os programadores dominam.

    Vou tentar dar-t um exemplo, que foi a primeira aplicação que utilizei deste genero: o gimp.

    Aquilo é muito bom teres n janelas, no fundo, cada janela tem lá todas as opções e tal. Mas depois de abrires 6 ou 10 imagens e mais umas 2 aplicações, a tua barra de tarefas fica um enorme caos, além de que, andas a clickar à parva a ver onde anda quela imagem que queres.

    Por outro lado tens o inkscape, que mantem o formato original que permite um melhor controlo disso.

    Claro que o gimp dá uma maior mobilidade, sim, sobretudo em ecrãs enormes, porém, temos que ver que para utilizadores menos astutos o modelo do inskape é capaz de ser mais rentavel.

    epah ... anda por aqui um carola da usabilidade (tipo ... daqueles gajos que n fazem nada e só opinam coisas que a gente até sabe) ... ó carola, aprochega-t à discussão.

    Era bom mesmo debater o tema, pois existe sempre as 2 opções e gostaria mesmo de saber qual a melhor para que situações. A minha abordagem já a referi, gostaria de saber dos especialistas.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:2)
    por fhc em 09-06-06 14:22 GMT (#38)
    (Utilizador Info)

    Linguagens Compiláveis: O problema é que um sistema de informação de gestão não é em tempo real. Logo, python cai que nem uma luva. É mais fácil de manter que Java.

    O nosso (Stella Polaris) sistema de informação (Mercator) é escrito em Python e pygtk, com reportlab para fazer e imprimir documentos. Estou a pensar em abri-lo para que todos contribuam e este melhore.

    Não vi o Evaristo, e muito menos analisei o código. Não acredito que o Evaristo seja de modo algum mau: tem cinco anos em cima de pessoas notoriamente competentes. Se é escrito em Java ou em C ou em Python ou em Visual basic, isso é irrelevante. Um romance esloveno pode ser tão bom quanto um romance francês ou português.

    Francisco Colaço


    Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 09-06-06 14:57 GMT (#39)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    Achei um defeito no evaristo que ... deve ser um defeito de java ... é lento .
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 09-06-06 15:51 GMT (#40)
    (Utilizador Info) http://www.m16e.com
    Não é só do Java. O interpretador de layouts actual é mais pesado do que o necessário. O próximo (ainda em desenvolvimento, deverá estar concluído no final do verão) será bastante mais rápido.

    Uma dica: se tens qualquer coisa inferior a um Pentium III a 1 GHz não uses o Java 1.5. A versão 1.4 tem melhor performance nas máquinas de menores recursos.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 09-06-06 17:29 GMT (#41)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    nop ... tenho um amd64 3000 ... é naquela isto levar tanto tempo a arrancar.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 09-06-06 22:18 GMT (#42)
    (Utilizador Info) http://www.m16e.com
    Se é só a arrancar, é do Java (sobretudo quando invocado com a opção '-server') e é normal. Não te esqueças que, primeiro, tem de carregar uma Máquina Virtual ;-)

    Mas depois, passa-lhe.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por fhc em 10-06-06 19:43 GMT (#43)
    (Utilizador Info)

    TÊm separado o modelo da interface? Isto estou a perguntar porque sei de experiência que SWT é muito mais rápido e fluido que o SWING. Por outro lado, CURSES poderia ser uma excelente interface.

    Francisco Colaço


    Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia.

    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 11-06-06 1:16 GMT (#44)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    Já pensei em fazer uma aplicação de facturação e gestão de stocks (aqui à uns tempos atrás) e estava a apontar para algo que corresse em consola e/ou janela gtk com consola embutida.

    A facilidade de utilização de apenas teclado é muito maior que a utilização de rato/teclado. A aplicação seria similar à utilizada na radio popular, em consola, e uma aplicação manhosa da cabovisão, em janela com consola.

    No entanto, a versão de POS teria sempre que ser totalmente gráfica.

    Penso que um ponto fundamental destas aplicações é a rapidez e estabilidade. Criar uma venda a dinheiro ou factura em segundos e com facilidade é realmente um bom objectivo.

    Penso eu de que.
    Cumps-
    Gass
    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 12-06-06 20:51 GMT (#46)
    (Utilizador Info) http://www.m16e.com
    O SWT tem um modelo de tratamento de eventos que é completamente diferente do Swing... a escolha foi feita muito antes de ter surgido o SWT, mesmo agora, e apesar dos relatos que apontam para um ganho de desempenho considerável, tenho muitas dúvidas que seja a opção acertada. No mínimo teria de adicionar mais umas classes à CLASSPATH... duvido que "o crime compense" ;-)

    Quanto ao curses, sim, sobretudo se aparecer uma cadeia de hipermercados a querer implementar esta solução. Fora isso (necessidade absoluta de um excelente desempenho), não vejo outras razões para o utilizar, a não ser, talvez, reaproveitamento dos "velhinhos" terminais VTxxx, mas teriam de ser muitos para valer a pena ;-)

    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 12-06-06 21:12 GMT (#47)
    (Utilizador Info) http://www.m16e.com
    python cai que nem uma luva. É mais fácil de manter que Java.
    Depende da escala do projecto e, no caso do Evaristo, são já mais de 100.000 linhas de código. À partida, o Java apresenta uma grande vantagem: ser uma linguagem fortemente tipada, o que torna muito difícil as ocorrências de erros derivados da conversão de tipos, dado ter de ser feita explicitamente.

    Ajuda, também, ter 2 (duas!) das IDEs mais sofisticadas e desenvolvidas do momento (Eclipse e Netbeans).

    Resumindo: se fosse arrancar agora com o projecto, a dúvida seria mais entre o EE (Enterprise Editon) e o SE (Standard Edition), e não entre Java e Python ou (blasfémia!) notNet...

    O Python (quero dizer, o Jython, devido à integração fácil com o Java) é uma hipótese que anda a ser estudada já há algum tempo para "colar" os vários módulos da aplicação. Um dia, havemos de testá-la a sério e daremos conta dos resultados ;-)

    Re:E esta, hein? Outra questão. (Pontos:1)
    por m16e em 08-06-06 8:50 GMT (#28)
    (Utilizador Info) http://www.m16e.com
    1. Esperemos que seja mais cedo que mais tarde ;-)

    2. Admito que, para utilizadores descuidados (a maioria) possa criar confusão, mas a experiência diz-me, que após um período de adaptação, não querem outra coisa.

    3. No way! Considero que a independência em relação ao Sistema Operativo é um requisito básico de qualquer aplicação empresarial.

    4. Quanto a uma melhor integração com o Gnome (de que género?), why not?.
    Não. A minha é maior que a tua ;-)

    5. Vê o ponto 3.

    Todas as contribuições são bem-vindas,

    Um abraço para ti também,

    Carlos


    Re:E esta, hein? Outra questão. (Pontos:2)
    por gass em 08-06-06 17:14 GMT (#30)
    (Utilizador Info) http://www.otiliamatos.ath.cx/~gass
    2 - acredito em utilizadores normalmente habituados a mexer em computadores, não acredito nisso para utilizadores pouco experiênciados, tipo o mecânico lá na esquina que só mexe no pc para tirar a factura.

    4 - integração de funcionalidades, por exemplo, envio de emails, acesso ao filesystem (utilizando o gnomeVFS), icones, apresentação de janela, etc. Dava um look de melhor integração e essa integração facilita a mobilidade do utilizador pelas aplicações. Exemplo: faz um open file a uma pen montada em /media, no firefox e um atach no thunderbird, um com integração, outra sem.

    Para os utilizadores, por exemplo, não é transparente o ir ao /media/nome_da_pen , mas devido à organização do gnomevfs, é. eu mais logo faço uns shots e mostro.

    ah ... meu amigo ... não ... a minha é de certeza maior.


    Cumps-
    Gass
    Ó Evaristo... (Pontos:2, Engraçado)
    por Specimen em 05-06-06 23:47 GMT (#10)
    (Utilizador Info)

    ... tens cá disto?


    'In the future, the oppression will come in increasingly subtle forms'.

    Re:Ó Evaristo... (Pontos:1)
    por DOOM em 08-06-06 12:16 GMT (#29)
    (Utilizador Info)
    E é disto que o Gildot é feito ultimamente. É preciso começar a divulgar este espaço como o melhor local na web para comediantes. "Quer rir? Quer ver como as pessoas se insultam? Visite o Gildot......fim de semana sempre a rir!:) É triste.........
    Se não sabes COMO funciona não tentes perceber PORQUE NÂO funciona!!!! HackingBill is sooo Cooool:)))
    Re:Ó Evaristo... (Pontos:2)
    por Specimen em 12-06-06 0:10 GMT (#45)
    (Utilizador Info)

    Não gosta, não come.


    'In the future, the oppression will come in increasingly subtle forms'.

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]