Genericamente pretende-se conceptualizar os fundamentos jurídicos e aplicá-los sempre que possível ao dominio da informática.
Para tal é necessário interiorizar certas noções como copyright (protecção contra cópias) e direitos de autor (protecção do autor).
O copyright tem origem nos país anglosaxónicos e resume-se à common law, os direitos de autor resumem-se aos restantes países através da civil law.
Ao longo da história sempre existiram leis, e a lei dos direitos de autor tem um perido centenário duante o qual foi sofrendo
evoluções e propgredindo de forma aproteger o autor da obra, lhe era apenas atribuido o direito de imprimir a obra sem mais nenhuma contarpartida.Por iniciativa de um advogado pioneiro (Louís d’Héricourt ) , os autores passaram a ter direitos sobre as suas obras e a
poder lucrar com elas.A garantia de protecção desses direitos foi dada pela convenção de Berna em 1791.Actualmente em Portugal existem entidades que se dedicam a perservação destes direitos.(Autoridade da Concorrençia e Assoft entre outras)As leis sob produtos vendidos em todo o mundo vigoram noutros paises devido à existência de tratados internacionais de forma
a proteger os produtos das empresas radicadas noutro país (ex. Microsoft).A nocção de patente é importante pois as invovações com
aplicabilidade industrial.A patente de software é reconhecida em poucos países (E.U.A e Japão) .De forma a proteger o utilizador e produtores de
sotware a Justiça procura acompanhara inovação e responder juridicamente a todos os aspectos emergentes, embora a informática ande sempre um passo à frente.Existem contudo uma série de artigos especializados que protegem os cidadão para os delitos mais comuns na área da
informática (sabotagem,falsidade ...), cujas multas podem levar desde o simples arresto de bens à prisão de acordo com a gravidade do delito (exemplo de alguns hackers já
condenados).
Outro aspecto prende-se aos processos de protecção jurídica dos programas de computador.
Todo o software produzido de forma colectiva é propriedade da empresa, no caso de ser feito por encomenda pertence ao destinatário (salvo especificações em contrário).
Os programas que caem em dominio público, não voltam à condição de protegidos.É necessário ter em conta que na compra de um programa original, poder-se-á instalar em apenas dois computadores(windows) e 1 computador para outros programas, e fazer-se apenas uma cópia para backup(segurança).A propriedade duma aplicação é assegurada pelo registo da mesma, sendo que uma aplicação pode sugerir interesse a alguém que a registe e então deixa de ser do criador original - salvo garantias e provas irrefutáveis de que é mesmo sua.A ASSOFT (ASSOFT - Associação Portuguesa de Software), é o alto representante na defesa e zelo pelos criadores de sofware e luta contra a pirataria em Portugal.Comporta essencialmente dois serviços para acreditação de software - o registo e o depósito.O registo de software aplica-se aos programas de computador que, estão ainda em fase de elaboração.O depósito de software destina-se aos programas de computador cuja elaboração está finalizada e que se encontram prontos para comercialização.
quarta-feira, 28 de março de 2007
SQLITE - BASE DE DADOS EM FORMA DE LIVRARIA
Quando apereceu o SQLite poucos acreditavam que essa tecnologia, mas surpreendentemente , ela rápidamente se integrou juntamente com as outras linguagens de programação existentes. No PHP4 era necessário configurar o php.ini para trabalhar com a livria mas o PHP5 traz tudo pronto a funcionar.
Esta base dados é uma base de dados relacional a nível de arquitectura , sendo que todos os processos necessários ao seu funcionamento (tabelas, informação , indices...) ,estão contidos em apenas um unico ficheiro contido e manipulado directamente no sistema, ou seja , é um sistema embebido, cujo motor SQL não necessita de alguma configuração.
O SQLite é uma pequena livraria escrita em C escrita por Richard Hipp, e a padronização de acesso e mainupulação de dados é o SQL.
A ideia que se matinha de que uma base de dados é uma aplicação do tipo cliente-servidor, cujo protocolo de comunicação TCP-IP atrás de uma porta qualquer, foi posta de lado por esta nova tecnologia que funciona como um ficheiro (na verdade é-o) , no qual toda a informação relativa a uma determinada funcionalidade ou objectivo está contido sob a forma de base de dados.
Algumas propriedades do SQLite são no mínimo interessantes:
O prestigio reconhecido a esta tecnologia atinguí o apogeu quando o seu criador Richard Hipp, foi reconhecido com o prémio atribuido pela Google e pela colossal editora O´REILLY com o prémio "Open Source Award Winner" em 2005.
Este feito foi o projectar para que muitos utilizadores passasem a pelo menos testar e verifcar as funcionalidades que a tecnologia proporcionava, e o certo é que muitos passaram a utilizá-la com frequência, não só devido à facilidade de gestão mas à sua rápidez e portabilidade.
Com o surgimento do PHP- GTK (a livraria que permite criar aplicações gráficas), o SQLite, teve junto dos programadores PHP o merecido reconhecimento e passou a ser utilizado em massa.
Eu pessoalmente uso esta tecnologia nas minhas aplicações escritas em PHP-GTK, e uso uma classe genérica que desenvolvi para acessar manipular e consultar dados usando SQLite.
Todo o código está disponível na minha página pessoal na secção de downloads.
Esta base dados é uma base de dados relacional a nível de arquitectura , sendo que todos os processos necessários ao seu funcionamento (tabelas, informação , indices...) ,estão contidos em apenas um unico ficheiro contido e manipulado directamente no sistema, ou seja , é um sistema embebido, cujo motor SQL não necessita de alguma configuração.
O SQLite é uma pequena livraria escrita em C escrita por Richard Hipp, e a padronização de acesso e mainupulação de dados é o SQL.
A ideia que se matinha de que uma base de dados é uma aplicação do tipo cliente-servidor, cujo protocolo de comunicação TCP-IP atrás de uma porta qualquer, foi posta de lado por esta nova tecnologia que funciona como um ficheiro (na verdade é-o) , no qual toda a informação relativa a uma determinada funcionalidade ou objectivo está contido sob a forma de base de dados.
Algumas propriedades do SQLite são no mínimo interessantes:
- Transacções atómicas, consistentes, isoladas, e duráveis (ACID) mesmo até quando o sistemas falha devido a quebra de energia.
- Nenhuma configuração - não necessita instalação ou pianel de controlo
- Implementa a maioria das normas padrão SQL92.
- Uma base d eaddos completa é armazenada num simples ficheiro
- As base de dados podem ser partilhadas ente máquinas com diferente ordem de bits
- Suporta base d edados acima dos 2 tebibytes (241 bytes) em tamanho
- Strings e BLOBs acima dos 2 gibibytes (231 bytes) em tamanho
- Arquitectura base necessária bastante reduzida 400Kib
- Mais rápido face aos sistemas de base dados cliente/servidor na maioria das operações
- API de fácil uso
- Implementações TCL incluídas As implementações para as várias linguagens estão disponiveis de forma separada.
- Código bem comentado e testado com cobertura d etestes superior a 95%
- Sem dependências
- Código fonte de dominio público. Pode usá-lo para o que quiser.
O prestigio reconhecido a esta tecnologia atinguí o apogeu quando o seu criador Richard Hipp, foi reconhecido com o prémio atribuido pela Google e pela colossal editora O´REILLY com o prémio "Open Source Award Winner" em 2005.
Este feito foi o projectar para que muitos utilizadores passasem a pelo menos testar e verifcar as funcionalidades que a tecnologia proporcionava, e o certo é que muitos passaram a utilizá-la com frequência, não só devido à facilidade de gestão mas à sua rápidez e portabilidade.
Com o surgimento do PHP- GTK (a livraria que permite criar aplicações gráficas), o SQLite, teve junto dos programadores PHP o merecido reconhecimento e passou a ser utilizado em massa.
Eu pessoalmente uso esta tecnologia nas minhas aplicações escritas em PHP-GTK, e uso uma classe genérica que desenvolvi para acessar manipular e consultar dados usando SQLite.
Todo o código está disponível na minha página pessoal na secção de downloads.
segunda-feira, 26 de março de 2007
PHP6 - O PRINCIPIO DA MUDANÇA
Um problema chamado mudança
O problema é simples de entender , mas a solução pode vir a dar dor de cabeça a muitos programadores ou freelancers em PHP.
Imaginem que possuem trabalhos realizados em PHP , cujos conteúdos estão publicados na web e que muitos dos clientes para que realizaram os trabalhos dependem deles para o seu modelo de negócio.
Agora imaginem que alguém responsável pelo "core" de desenvolvimento PHP, se lembrava de reestructurar a linguagem e muitas das funções e funcionalidades existentes até aquí deixam de estar acessíveis, tornando muitas aplicações e web sites totalmente obsoletos .
Parece brincadeira , mas não é ! Segundo consta, as pelas últimas noticias emanadas pela comunidade de desenvolvimento da linguagem, a nova versão PHP6 terá este enorme problema. A garantia de isso iria acontecer foi publicamente confirmada por Derick Rethans , um dos obreiros actuais da linguagem.
O problema apenas se verificará quando os responsáveis pelos manutenção dos sites online actualizarem os servidores para a nova versão PHP6.
Geralmente as empresas responsáveis pelo alojamento ou manutenções do site tinham a preocupação de manter as versões anteriores a correr de forma a manterem no activo antigas aplicações.
Com esta alteração de fundo muitas das aplicações simplesmente deixaram de funcionar; e apesar da versão 6 do PHP não ter sido lançada, o resultado da imcompatibilidade começou a ser notado, e foi tornado publico pelo equipa de desenvolvimento da versão PHP6.
Mas o que poderão fazer os criadores, empresas e freelancers para ultrapassar esta questão ?
Em primeiro lugar será necessário rever o tipo de contracto que tem com os seus clientes, mas será sempre melhor ter em conta que essa manutenção terá de ser gratuíta, pois ela não é imposta pelo cliente mas por uma exigênçia da tecnologia.
Outro ponto fulcral, abona o facto de que o cliente pagou por um serviço que na maioria dos contratos é vitalicio (salvo raras excepções), daí que esse produto, seja ele um site ou não no mínimo terá que possuir as funcionalidades que continha até a aqui.
O PHP6 permitir-lho-á, mas a aplicação necessitará de ser reprogramada de forma a substituir as "depracted functions" pelas novas funções e novas funcionalidades.
O problema resume-se fundamentalmente ao afacto de que a nova versão PHP6 será incompativel com as versões anteriores PHP4 e 5.
Mas o que será necessário alterar para que tudo o que funcionava até aquí continue a funcionar ?
Para melhor entender a solução é necessário estudar e perceber aquilo que irá ser alterado.
A noticia já havia sido antecipada no encontro realizado em Paris em Novembro de 2005 (dias 11 e 12), mas por inércia ou qualquer outro factor somente agora se está a dar a devida importância ao assunto. Mesmo na altura se dava conta que as alterações mencionadas seriam feitas de forma progressiva. Mas com o decorrer do tempo e à medida que essas alterações vão sendo implementadas, as questões e dúvidas vêm à tona e deixa muitos atónitos , nao percebendo bem aquilo que se está a passar. O certo é que esssas alterações de fundo ao "core" da linguagem vão mesmo ser implementadas.
Vou em seguida falar de forma o mais suscinta possível acerca das tão faladas mudanças e da forma como afectam os códigos escritos em PHP.
O Unicode é visto como uma nova funcionalidade, mas todas as restantes alterações não irão funcionar quando utilizadas em códigos a correr em versões anteriores, gerando erros na execução , impedindo que os serviços funcionem.
Fica assim possível escrever classes com acentuação. Este é uma exemplo, mas existe milhares de aplicações onde isto é mais vantajoso.
Existem no entanto uma série de alterações que estão a deixar os programadores de cabelos em pé.
O site ofical do PHP deixa transparecer algumas das alterações já a decorrer.
As register_globals eram frequentemente usadas para o tratamento de formulários.
Em versões do PHP anteriores a 4.2.0, a diretiva register_globals tinha como valor padrão estar activada, o que, por questões de segurança, não acontece nas versões actuais.
Contudo por desconhecimento ou por descuido, esta constitui uma falha grave na segurança aos servidores que interpretam código PHP.
Actualmente os programadores experientes tem formas alteranativas de implementar esta funcionalidade mas, para quem a use ainda ou em aplicações a correr sob PHP6 deixará de estar assecível.
Esta é uma alteração já esperada há muito tempo, uma vez que nem sequer é uma forma segura de programar e a maioria dos programadores nem sequer usa esta funcionalidade (?).
Segudo foi tornado público, os programadores terão a possibilidade de ligar e desligar funcionalidades, sem intervenção do administrador do servidor.
Esta medida não é concerteza coerente, pois não estou a ver um administrador de serviços web, que não quer que utilizemos as contas de email ou de FTP , tenha um canal aberto que contaria as restrições impostas ... (?) , no mínimo estranha e discutivel esta medida.
Aquí esta uma medida que no mínimo provoca a discordia. Com esta medida todos os scritpts, mais antigos serão obsoletos,uma vez que deixarão de funcionar, ou impondo obrigatóriamente a que o código seja reescrito ou actualizado.
Isto implica perca de tempo, pelo que em aplicações de pequeno porte o melhor será reescrever a aplicação na totalidade.
Em aplicações consideráveis ficará ao critério de cada um.
.... este artigo está incompleto
volte em breve
O problema é simples de entender , mas a solução pode vir a dar dor de cabeça a muitos programadores ou freelancers em PHP.
Imaginem que possuem trabalhos realizados em PHP , cujos conteúdos estão publicados na web e que muitos dos clientes para que realizaram os trabalhos dependem deles para o seu modelo de negócio.
Agora imaginem que alguém responsável pelo "core" de desenvolvimento PHP, se lembrava de reestructurar a linguagem e muitas das funções e funcionalidades existentes até aquí deixam de estar acessíveis, tornando muitas aplicações e web sites totalmente obsoletos .
Parece brincadeira , mas não é ! Segundo consta, as pelas últimas noticias emanadas pela comunidade de desenvolvimento da linguagem, a nova versão PHP6 terá este enorme problema. A garantia de isso iria acontecer foi publicamente confirmada por Derick Rethans , um dos obreiros actuais da linguagem.
O problema apenas se verificará quando os responsáveis pelos manutenção dos sites online actualizarem os servidores para a nova versão PHP6.
Geralmente as empresas responsáveis pelo alojamento ou manutenções do site tinham a preocupação de manter as versões anteriores a correr de forma a manterem no activo antigas aplicações.
Com esta alteração de fundo muitas das aplicações simplesmente deixaram de funcionar; e apesar da versão 6 do PHP não ter sido lançada, o resultado da imcompatibilidade começou a ser notado, e foi tornado publico pelo equipa de desenvolvimento da versão PHP6.
Mas o que poderão fazer os criadores, empresas e freelancers para ultrapassar esta questão ?
Em primeiro lugar será necessário rever o tipo de contracto que tem com os seus clientes, mas será sempre melhor ter em conta que essa manutenção terá de ser gratuíta, pois ela não é imposta pelo cliente mas por uma exigênçia da tecnologia.
Outro ponto fulcral, abona o facto de que o cliente pagou por um serviço que na maioria dos contratos é vitalicio (salvo raras excepções), daí que esse produto, seja ele um site ou não no mínimo terá que possuir as funcionalidades que continha até a aqui.
O PHP6 permitir-lho-á, mas a aplicação necessitará de ser reprogramada de forma a substituir as "depracted functions" pelas novas funções e novas funcionalidades.
O problema resume-se fundamentalmente ao afacto de que a nova versão PHP6 será incompativel com as versões anteriores PHP4 e 5.
Mas o que será necessário alterar para que tudo o que funcionava até aquí continue a funcionar ?
Para melhor entender a solução é necessário estudar e perceber aquilo que irá ser alterado.
A noticia já havia sido antecipada no encontro realizado em Paris em Novembro de 2005 (dias 11 e 12), mas por inércia ou qualquer outro factor somente agora se está a dar a devida importância ao assunto. Mesmo na altura se dava conta que as alterações mencionadas seriam feitas de forma progressiva. Mas com o decorrer do tempo e à medida que essas alterações vão sendo implementadas, as questões e dúvidas vêm à tona e deixa muitos atónitos , nao percebendo bem aquilo que se está a passar. O certo é que esssas alterações de fundo ao "core" da linguagem vão mesmo ser implementadas.
Vou em seguida falar de forma o mais suscinta possível acerca das tão faladas mudanças e da forma como afectam os códigos escritos em PHP.
Mudanças fundamentais
UNICODE
O unicode não é uma mudança mas sim uma novidade no PHP, já na versão 6.
O Unicode associa um número a cada caracter independentemente do programa ou da plataforma ou da língua.
Desta forma as aplicações ganham uma maior flexibilidade e fiabiliadade.
Ofereçer a padronização Unicode permite às empresas (essencialmete no ramo dos servidores), reduzir custos, uma vez que o conjunto de caracteres legacy são desnecessários.
Além disse este recurso torna a linguagem mais poderosa, pois a a fusão com outros padrões permite tirar maior partido da linguagem; e por exemplo o XML tem a necessidade de codificação Unicode.
O Unicode é visto como uma nova funcionalidade, mas todas as restantes alterações não irão funcionar quando utilizadas em códigos a correr em versões anteriores, gerando erros na execução , impedindo que os serviços funcionem.
Fica assim possível escrever classes com acentuação. Este é uma exemplo, mas existe milhares de aplicações onde isto é mais vantajoso.
Alterações de fundo
Existem no entanto uma série de alterações que estão a deixar os programadores de cabelos em pé.
O site ofical do PHP deixa transparecer algumas das alterações já a decorrer.
Remoção completa das "register_globals"
As register_globals eram frequentemente usadas para o tratamento de formulários.
Em versões do PHP anteriores a 4.2.0, a diretiva register_globals tinha como valor padrão estar activada, o que, por questões de segurança, não acontece nas versões actuais.
Contudo por desconhecimento ou por descuido, esta constitui uma falha grave na segurança aos servidores que interpretam código PHP.
Actualmente os programadores experientes tem formas alteranativas de implementar esta funcionalidade mas, para quem a use ainda ou em aplicações a correr sob PHP6 deixará de estar assecível.
Remoção " magic_quotes_* "
Esta é uma alteração já esperada há muito tempo, uma vez que nem sequer é uma forma segura de programar e a maioria dos programadores nem sequer usa esta funcionalidade (?).
Aceder às funcionalidades activas e desactivas no Painel de control
Segudo foi tornado público, os programadores terão a possibilidade de ligar e desligar funcionalidades, sem intervenção do administrador do servidor.
Esta medida não é concerteza coerente, pois não estou a ver um administrador de serviços web, que não quer que utilizemos as contas de email ou de FTP , tenha um canal aberto que contaria as restrições impostas ... (?) , no mínimo estranha e discutivel esta medida.
Remover tudo aquilo considerado desactualizado até as versões 3 e 4
Aquí esta uma medida que no mínimo provoca a discordia. Com esta medida todos os scritpts, mais antigos serão obsoletos,uma vez que deixarão de funcionar, ou impondo obrigatóriamente a que o código seja reescrito ou actualizado.
Isto implica perca de tempo, pelo que em aplicações de pequeno porte o melhor será reescrever a aplicação na totalidade.
Em aplicações consideráveis ficará ao critério de cada um.
.... este artigo está incompleto
volte em breve
Subscrever:
Mensagens (Atom)