Será feita uma paletra on-line para o lançamento do RAD Studio XE, com as novas versões do C++ Builder XE, Delphi XE, Delphi Prism XE e RAD PHP XE, gratuito a todos os cadastrados na comunidade CodeGear. Cadastro que é gratuito também, claro.
O evento será dia 15/09 (quarta-feita) das 14 às 16 horas, onde serão demonstradas por funcionário brasileiro da CodeGear, as novas ferramentas para controle de versões com SubVersion, computação multi-camadas, "cloud-computing" (nuvens), programação web com RAD PHP, criação de aplicativos desktop, .Net, iPhone, e vários outros recursos da nova IDE.
Link do prospecto, onde tem um link para inscrição:
http://forms.embarcadero.com/forms/AMBR ... ebinar9-15
Link para a página do novo RAD Studio XE:
http://www.embarcadero.com/br/products/rad-studio
Link para um vídeo com uma pequena demonstração (pode ser baixado, mas são uns 90MB):
http://www.embarcadero.com/ch-e-video.p ... 8507b0ce51
Editado: corrigido o horário.
Lançamento: RAD Studio XE
Moderador: Moderadores
Lançamento: RAD Studio XE
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
Cara...
Essas ferramentas novas são tão robustas e com tantos recursos que dá até medo de começar a usar. Você pensa, nunca dominarei isso... Mas sei lá, talvez eu seja antiquado mas não sou fã deste tipo de ferramenta. Ainda prefiro usar os recursos nativos de cada compilador, seja pela suas IDEs ou na mão mesmo como no caso do bom xHarbour.
Com um ambiente deste, trabalhando em equipe a produtividade vai a mil, né? E documentação, modelagem etc e tal fazem muita diferença em sistemas realmente complexos. Sem contar a portabilidade!
E dizem lá que 3 milhões de profissionais já usam.
Abraços!
Essas ferramentas novas são tão robustas e com tantos recursos que dá até medo de começar a usar. Você pensa, nunca dominarei isso... Mas sei lá, talvez eu seja antiquado mas não sou fã deste tipo de ferramenta. Ainda prefiro usar os recursos nativos de cada compilador, seja pela suas IDEs ou na mão mesmo como no caso do bom xHarbour.
Com um ambiente deste, trabalhando em equipe a produtividade vai a mil, né? E documentação, modelagem etc e tal fazem muita diferença em sistemas realmente complexos. Sem contar a portabilidade!
E dizem lá que 3 milhões de profissionais já usam.
Abraços!
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Começar a usar é um tanto quanto estranho, eu diria. No começo você se sente um completo novato. Lembro de quando comecei a usar o C++ Builder. Além da troca da linguagem, tive que me acostumar com a IDE e procurar entender o framework VCL. A IDE é até simples. É fácil se acostumar com ela. Mas ela só dá recursos para acabar com a perda de tempo com coisinhas bobas, como configuração dos controles (não)visuais. O código que faz as tarefas é no braço mesmo. Aí (também) entra a compreensão do framework. Pode-se ficar no básico, claro, mas conhecer a VCL é primordial para melhor aproveitar os recursos do sistema e assim, obter uma qualidade muito maior.
O help não tem o que falar. Só o diretório help, criado na instalação do C++ Builder, tem uns 250MB. É uma documentação excelente. Não tem nada resumido. É uma documentação completa mesmo. Sem falar dos helps dos componentes. Alguns ficam à parte. Mas a maioria é integrado ao help principal. Basta pressionar F1 com o caret sobre uma palavra e o help busca a informação automaticamente. Mas tem também o code completion, os hints, etc.
Claro que devido à popularidade da ferramenta (VCL é sempre VCL, não importando se é Delphi ou C++), acrescentam-se a isso as toneladas de helps, discussões e cases encontrados pelo Google. E os fóruns da própria empresa; eu mesmo tenho colecionadas umas 30.000 mensagens dos newsgroups da antiga Borland e da nova CodeGear. Difícil não matar uma dúvida apenas com pesquisa.
Sempre achei o fim da picada a escassez de documentação do [x]Harbour. Algum tempo atrás (espero que tenha mudado), havia uma documentação (bem fraquinha) em PDF até era cobrada. É o cúmulo. Help para programador é como sapato para mulher: tem que ter de monte, mesmo que nem use.
E tem a compilação. Vemos de vez em quando alguém se matando para compilar uma coisa boba no [x]Harbour. Eu não preciso configurar quase nada no Builder. Se quiser ficar apenas no básico, basta informar uma vez só alguns paths, gravados no arquivo do projeto e compilar. Tenho debugging integrado, breakpoint visual, watching list, etc. Some-se a isso as ferramentas de engenharia. Não posso falar muito disso, pois a versão que uso (ano: 2006) não tem muito a oferecer. Mas hoje já existem diversos recursos nesse sentido.
Somam-se também as inúmeras ofertas de componentes. É componente pra tudo que se possa imaginar.
É realmente muito mais produtivo. Quem quer trabalhar menos com coisas bobas e (teoricamente) desnecessárias para focar seus esforços apenas na codificação importante, uma ferramenta dessas é o melhor caminho. Aliás, uma coisa que sempre achei muito legal: o fonte sempre fica limpo, pois toda a configuração de formulários e controles residem em arquivo à parte. No fonte só fica o código que eu escrevo.
Em suma: como tudo na vida, há um custo. Mas acho que o custo de uma migração dessas sempre compensa para aqueles que se dispõem a encarar um mundo diferente. E que podem migrar, claro. Alguns precisam atender certas necessidades com o código XBase legado, o que torna essa mudança impossível. Mas não conheço quem tenha migrado e se arrependido. O ganho é muito grande. Se há alguém nessa situação, acredito que seja por que não soube aproveitar o potencial da ferramenta ou, talvez, por que não conseguiu simpatizar com a linguagem Delphi ou C++. Há quem simplesmente adore XBase. Simpatia também impõe um custo.
)))
O help não tem o que falar. Só o diretório help, criado na instalação do C++ Builder, tem uns 250MB. É uma documentação excelente. Não tem nada resumido. É uma documentação completa mesmo. Sem falar dos helps dos componentes. Alguns ficam à parte. Mas a maioria é integrado ao help principal. Basta pressionar F1 com o caret sobre uma palavra e o help busca a informação automaticamente. Mas tem também o code completion, os hints, etc.
Claro que devido à popularidade da ferramenta (VCL é sempre VCL, não importando se é Delphi ou C++), acrescentam-se a isso as toneladas de helps, discussões e cases encontrados pelo Google. E os fóruns da própria empresa; eu mesmo tenho colecionadas umas 30.000 mensagens dos newsgroups da antiga Borland e da nova CodeGear. Difícil não matar uma dúvida apenas com pesquisa.
Sempre achei o fim da picada a escassez de documentação do [x]Harbour. Algum tempo atrás (espero que tenha mudado), havia uma documentação (bem fraquinha) em PDF até era cobrada. É o cúmulo. Help para programador é como sapato para mulher: tem que ter de monte, mesmo que nem use.
E tem a compilação. Vemos de vez em quando alguém se matando para compilar uma coisa boba no [x]Harbour. Eu não preciso configurar quase nada no Builder. Se quiser ficar apenas no básico, basta informar uma vez só alguns paths, gravados no arquivo do projeto e compilar. Tenho debugging integrado, breakpoint visual, watching list, etc. Some-se a isso as ferramentas de engenharia. Não posso falar muito disso, pois a versão que uso (ano: 2006) não tem muito a oferecer. Mas hoje já existem diversos recursos nesse sentido.
Somam-se também as inúmeras ofertas de componentes. É componente pra tudo que se possa imaginar.
É realmente muito mais produtivo. Quem quer trabalhar menos com coisas bobas e (teoricamente) desnecessárias para focar seus esforços apenas na codificação importante, uma ferramenta dessas é o melhor caminho. Aliás, uma coisa que sempre achei muito legal: o fonte sempre fica limpo, pois toda a configuração de formulários e controles residem em arquivo à parte. No fonte só fica o código que eu escrevo.
Em suma: como tudo na vida, há um custo. Mas acho que o custo de uma migração dessas sempre compensa para aqueles que se dispõem a encarar um mundo diferente. E que podem migrar, claro. Alguns precisam atender certas necessidades com o código XBase legado, o que torna essa mudança impossível. Mas não conheço quem tenha migrado e se arrependido. O ganho é muito grande. Se há alguém nessa situação, acredito que seja por que não soube aproveitar o potencial da ferramenta ou, talvez, por que não conseguiu simpatizar com a linguagem Delphi ou C++. Há quem simplesmente adore XBase. Simpatia também impõe um custo.
Provavelmente uma contagem oficial, das cópias vendidas e registradas. Tem o resto.E dizem lá que 3 milhões de profissionais já usam.
)))[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
É verdade Maligno,
Eu diri que uma boa documentação é meio caminho andado para o sucesso de uma ferramenta. Existem programas por aí prometendo fazer o impoossível mas simplesmente não dizem como, ou seja você precisa quebrar a cabeça e pesquisar muito pra descobrir. Às vezes até são excelentes ferramentas, mas a falta de documentação não nos permite explorar os recursos.
No caso específico do Harbour, eu não vejo isso como um problema tão grande assim, pois creio que ele nasceu da necessidade de se recompilar sistemas feitos em Clipper para plataforma 32 bits, assumindo que o programador já possuia conhecimento em CLipper. e não tinha inicialmente a intençao de trazer novos usuários. Acontece que vieram depois as "extensões", como libs gráficas, RDDs etc, e estes sim devereim cumprir melhor este papel de documentação. Mas este é um problema geral do opensource. Aliás, por recomendação do pessoal aqui do fórum eu fui dar uma olhada em como integrar o ambiente de desenvolvimento da QT com o Harbour e fiquei surpreendido. Finalmente sinto que o Harbour atingiu a maioridade. Não posr sí só, mas pelo simples fato de permitir tal integração. E a documentação da QT é excelente, você clica num componente e a ajuda é contextual.
Quanto a RAD, eu de fato nunca usei, mas já deu umas olhadas em frameworks parecidos, alguns com mais outros com menos recursos, e de fato é impressionante a questão dos componentes, que na verdade são o que expandem as ferramentas cada vez mais.
Vou até te fazer a sugestão de testar o Qt-Creator, que é uma IDE bastante completa para C++, com boa parte dos recursos que você citou, como color encoding, debugger, etc, e de quebra roda nativamente em qualquer SO, utilizando o padrão de forms UI, que é um XML que quase todas as linguagens já oferecem suporte. Isso é interessante porque diferentes programas podem exibir e acessar a mesma tela. É um conceito que nasceu no Linux, mas que tende a ser usado no Windows, em substituição a algumas telas da API, ou mesmo outras que não existem. Por exemplo um diálogo de "abrir arquivo", todos os programas usam o mesmo né? No Windows sempre foi fácil chamar isso, mas no Linux não tinha padrão, você precisava desenhar seu diálogo. Hoje existem centenas de forms UI, provavelmente bem mais do que tarefas prontas da API do Windows. E como eu disse podem ser usados no Windows por diversas aplicações ao mesmo tempo, e até serem alterados.
Enfim, acho que o futuro é por aí, centralizar libs e recursos para que muitos programas acessem nativamente, algo como o a pasta "arquivos de programas\arquivos comuns" do Windows, mas ela com 1 ou 2gb de libs... rs. Emgora este sempre tenha sido um conceito no Linux, em termos de recursos gráficos, faltava algo como a QT, pois a GTK nunca deu conta. Claro que o WIndows sozinho não poderia dar conta também, afinal ele é o SO, e não um provedor de bibliotecas.
No mais, vale a pena sempre estar atento a todo tipo de novidade na área, e são muitas. A gente fala, torce e tal, mas é sempre difícil destacar uma tendência. Eu mesmo após dois ou três anos volto ao forum, e me dão o xHarbour quase como morto... rs
Abraços!
Eu diri que uma boa documentação é meio caminho andado para o sucesso de uma ferramenta. Existem programas por aí prometendo fazer o impoossível mas simplesmente não dizem como, ou seja você precisa quebrar a cabeça e pesquisar muito pra descobrir. Às vezes até são excelentes ferramentas, mas a falta de documentação não nos permite explorar os recursos.
No caso específico do Harbour, eu não vejo isso como um problema tão grande assim, pois creio que ele nasceu da necessidade de se recompilar sistemas feitos em Clipper para plataforma 32 bits, assumindo que o programador já possuia conhecimento em CLipper. e não tinha inicialmente a intençao de trazer novos usuários. Acontece que vieram depois as "extensões", como libs gráficas, RDDs etc, e estes sim devereim cumprir melhor este papel de documentação. Mas este é um problema geral do opensource. Aliás, por recomendação do pessoal aqui do fórum eu fui dar uma olhada em como integrar o ambiente de desenvolvimento da QT com o Harbour e fiquei surpreendido. Finalmente sinto que o Harbour atingiu a maioridade. Não posr sí só, mas pelo simples fato de permitir tal integração. E a documentação da QT é excelente, você clica num componente e a ajuda é contextual.
Quanto a RAD, eu de fato nunca usei, mas já deu umas olhadas em frameworks parecidos, alguns com mais outros com menos recursos, e de fato é impressionante a questão dos componentes, que na verdade são o que expandem as ferramentas cada vez mais.
Vou até te fazer a sugestão de testar o Qt-Creator, que é uma IDE bastante completa para C++, com boa parte dos recursos que você citou, como color encoding, debugger, etc, e de quebra roda nativamente em qualquer SO, utilizando o padrão de forms UI, que é um XML que quase todas as linguagens já oferecem suporte. Isso é interessante porque diferentes programas podem exibir e acessar a mesma tela. É um conceito que nasceu no Linux, mas que tende a ser usado no Windows, em substituição a algumas telas da API, ou mesmo outras que não existem. Por exemplo um diálogo de "abrir arquivo", todos os programas usam o mesmo né? No Windows sempre foi fácil chamar isso, mas no Linux não tinha padrão, você precisava desenhar seu diálogo. Hoje existem centenas de forms UI, provavelmente bem mais do que tarefas prontas da API do Windows. E como eu disse podem ser usados no Windows por diversas aplicações ao mesmo tempo, e até serem alterados.
Enfim, acho que o futuro é por aí, centralizar libs e recursos para que muitos programas acessem nativamente, algo como o a pasta "arquivos de programas\arquivos comuns" do Windows, mas ela com 1 ou 2gb de libs... rs. Emgora este sempre tenha sido um conceito no Linux, em termos de recursos gráficos, faltava algo como a QT, pois a GTK nunca deu conta. Claro que o WIndows sozinho não poderia dar conta também, afinal ele é o SO, e não um provedor de bibliotecas.
No mais, vale a pena sempre estar atento a todo tipo de novidade na área, e são muitas. A gente fala, torce e tal, mas é sempre difícil destacar uma tendência. Eu mesmo após dois ou três anos volto ao forum, e me dão o xHarbour quase como morto... rs
Abraços!
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Olá
Eu considro o fato de podermos usar a documentação da Qt um dos pontos fortes da HBQt.
O Harbour tem bastante documentação dos recursos novos, só não é completo e nem está com uma organização muito boa. Algumas poucas coisas podem ser vistas na documentação do xHarbour. Curiosamente um produto pago não tem uma documentação muito melhor.
Qualquer um com conhecimento de inglês pode colaborar para melhorar a documentação oficial do Harbour e a HBIde tem até um recursos para facilitar a escrita de novos documentos no padrão próprio.
Essa estória de centralizar todas DLLs ou SOs que seja num único lugar passou ser uma coisa questionável. Hoje, não temos mais tantas restrições de memória e disco, fora que o grosso do consumo de memória desses componentes são ocupados pelo heap individual de cada processo utilizando-o e não pelo código em si. Faz tempo que prefiro manter minhas DLLs/SOs só para minha aplicação, o custo adicional de se fazer isso é negligível e resolve o problema do DLL Hell tão comum quando se centraliza tudo.
T+
Eu considro o fato de podermos usar a documentação da Qt um dos pontos fortes da HBQt.
O Harbour tem bastante documentação dos recursos novos, só não é completo e nem está com uma organização muito boa. Algumas poucas coisas podem ser vistas na documentação do xHarbour. Curiosamente um produto pago não tem uma documentação muito melhor.
Qualquer um com conhecimento de inglês pode colaborar para melhorar a documentação oficial do Harbour e a HBIde tem até um recursos para facilitar a escrita de novos documentos no padrão próprio.
Essa estória de centralizar todas DLLs ou SOs que seja num único lugar passou ser uma coisa questionável. Hoje, não temos mais tantas restrições de memória e disco, fora que o grosso do consumo de memória desses componentes são ocupados pelo heap individual de cada processo utilizando-o e não pelo código em si. Faz tempo que prefiro manter minhas DLLs/SOs só para minha aplicação, o custo adicional de se fazer isso é negligível e resolve o problema do DLL Hell tão comum quando se centraliza tudo.
T+
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
Mas eu não entrei na questão do funcionamento da alocação de memória e tampouco do espaço em disco, o que até poderia ser considerado.clrod escreveu:Essa estória de centralizar todas DLLs ou SOs que seja num único lugar passou ser uma coisa questionável. Hoje, não temos mais tantas restrições de memória e disco, fora que o grosso do consumo de memória desses componentes são ocupados pelo heap individual de cada processo utilizando-o e não pelo código em si. Faz tempo que prefiro manter minhas DLLs/SOs só para minha aplicação, o custo adicional de se fazer isso é negligível e resolve o problema do DLL Hell tão comum quando se centraliza tudo.
Você pode pereferir manter seus recursos só para você, o que é o pensamento dominante na plataforma Windows. Mas muito provavellmente, no Windows você também não consegue dar um include no começo do seu programa, linkar uma lib compartilahada, e gravar um CD, gerar um ISO, alterar a resolução de uma imagem ou enviar um email sem escrever uma linha de código a mais.
É aí que reside o poder dos recursos compartilhados.
Abraços.
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Olá
Aí vem alguém troca o componente por uma ver~soa diferente incompatível e sua aplicação não funciona mais
T+
Aí vem alguém troca o componente por uma ver~soa diferente incompatível e sua aplicação não funciona mais
T+
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
Isso porque estou sonhando alto demais ao imaginar isso na plataforma Windows, o que exigiria um "instalar e remover programas" aprimorado para gerenciar dependencias, porque no Linux você cria seu pacotezinho seja RPM, DEB ou o que for e ele avalias a dependências, e o controle é tal que ao alterar o componente "pai" um aviso é dado sobre quais os programas dependentes dele e que eles podem parar de funcinoar. Além do que muitos trabalham com links simbólicos, e as libs normalmente são instaladas com o nome da versão acoplados ao nome tipo minhalib.1.50.so, e então um link simbólico minhalib.so, aponta para esta. basta remover este link e manter as duas versões.clrod escreveu:Aí vem alguém troca o componente por uma ver~soa diferente incompatível e sua aplicação não funciona mais
Mas mesmo com as opções acima se o cara trocar mesmo assim, o problema é dele. No mais, é parte do trabalho do desenvolvedor manter seu aplicativo atualizado de acordo com a evolução das ferramentas envolvidas no projeto.
O que não daria certo é o você usar uma lib de terceiros que manipula imagens, e outro programa também usar, e depois mais um, e cada um ter essa lib na sua pasta. É um tanto quanto incoerente, para não dizer ineficiente, do ponto de vista global do SO. Já imaginou se você pudesse acessar pelo seu programa todos os recursos das DLLs do Photoshop? No linux você pode acessar do Gimp, que embora não seja muito legal de usar para desenhar, tem quase que todas as funções do photoshop, e você pode acessar via código também. No Windows você também pode acessar as LIBs do Gimp, mas tem que copiar pra pastinha do seu programa.
Cabendo lembrar que a estrutura de pastas desta forma fica mais simples, embora não pareça, afinal toda a pasta de binários está no path do sistema, então de qualquer ponto você pode chamar o executável de um programa. Já no Windows por exemplo, você precisa ficar setando o path para inúmeras pastas de programas, por exemplo, BCC, Harbour, MiniGui, TASM, MySQL etc.. Você não pode abrir o executar e digitar "firefox www.pctoledo.com", muito embora uma mágica permita que você o faça com o "iexplore.exe" rsrs. (Mas isso é uma mudança muito mais profunda, e não é o que eu estava falando, não tenho intenção de comparar a estrutura dois SOs, mas apenas esta questão das libs compartilhadsas, que poderia ser implementada no Windows semn grandes mudanças estruturais, como por exemplo na pastinha que eu citei acima).
Abraços.
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Olá
Bom, 95% do mercado é Windows.
No Windows também avisa que vai sobrepor e todo mundo sobrepôe do mesmo jeito. E tecnologias como Mono/.Net resolveram de vez esse tipo de problema, mas não dá para resolver o legado.
Evitar que o cara tenha problema porque o problema dele acaba sendo o meu é justamente o que eu evito.
Não vejo nenhuma ineficiência em usar componentes locais.
A grande vantagem do Linux nestes casos é que leigo não põe a mão e não faz nada que possa criar grandes problemas para o técnico, mas nem vou entrar nessa discussão porque isso vira jihad.
T+
Bom, 95% do mercado é Windows.
No Windows também avisa que vai sobrepor e todo mundo sobrepôe do mesmo jeito. E tecnologias como Mono/.Net resolveram de vez esse tipo de problema, mas não dá para resolver o legado.
Evitar que o cara tenha problema porque o problema dele acaba sendo o meu é justamente o que eu evito.
Não vejo nenhuma ineficiência em usar componentes locais.
A grande vantagem do Linux nestes casos é que leigo não põe a mão e não faz nada que possa criar grandes problemas para o técnico, mas nem vou entrar nessa discussão porque isso vira jihad.
T+
Re: Lançamento: RAD Studio XE
Posso falar apenas do C++ Builder, que tem sim uma documentação muito melhor do que qualquer opensource que já vi, incluindo o [x]Harbour. É até raro encontrar componente VCL com documentação fraca.Curiosamente um produto pago não tem uma documentação muito melhor.
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
Opa,
Que o mercado é dominado pelo Windows é indiscutível, mas nada impede que em busca de melhorar seu sistema, a MS adote padrões de compartilhamento como este. Veja que o MS Ofiice cria um apasta de recursos compartilhados, assim como os programas da Borland, Adobe etc também criam, e muitos outros já adotam este conceito, mas como são programas proprietários, ainda criam somente para seus próprios aplicativos.
Eu sinceramente acredito sim que isso venha a ser implementado mais cedo ou mais tarde no Windows. Há muitos anos eu ouço esta história dio Windows ser muito mais usado e tal, e claro que é verdade, mas em busca de manter-se como um SO de qualidade, muitos recursos tiveram que ser implementados ou aprimorados, até mesmo para ficar igual ou compatível com os já antes existentes no Linux, no Mac ou outros SOs.
A onda de softwares opensources é crescente e irreversível. Hoje apesar do Windows ter aí seus mais de 90% de mercado, ao anailisar o que roda sobre o Windowsr, chegamos até mais de 50% de software opensource ou freeware, como firefox, picasa, entre muitos outros que já são os mais usados em suas categorias.
Ou seja, por trás disso existe toda uma comunidade de desenvolvedores, que embora não atinja o usuário final, a Microsoft haverá de dar um respaldo quanto a estas questões deste tipo, como o de compartilhamento, caso queira manter-se no topo do mercado, afinal o usuário não liga tanto assim pro SO, e sim pros programas que existem disponíveis para este SO, e é interesse da MS que qualquer bom programa possa rodar no Windows.
Abraços.
Que o mercado é dominado pelo Windows é indiscutível, mas nada impede que em busca de melhorar seu sistema, a MS adote padrões de compartilhamento como este. Veja que o MS Ofiice cria um apasta de recursos compartilhados, assim como os programas da Borland, Adobe etc também criam, e muitos outros já adotam este conceito, mas como são programas proprietários, ainda criam somente para seus próprios aplicativos.
Eu sinceramente acredito sim que isso venha a ser implementado mais cedo ou mais tarde no Windows. Há muitos anos eu ouço esta história dio Windows ser muito mais usado e tal, e claro que é verdade, mas em busca de manter-se como um SO de qualidade, muitos recursos tiveram que ser implementados ou aprimorados, até mesmo para ficar igual ou compatível com os já antes existentes no Linux, no Mac ou outros SOs.
A onda de softwares opensources é crescente e irreversível. Hoje apesar do Windows ter aí seus mais de 90% de mercado, ao anailisar o que roda sobre o Windowsr, chegamos até mais de 50% de software opensource ou freeware, como firefox, picasa, entre muitos outros que já são os mais usados em suas categorias.
Ou seja, por trás disso existe toda uma comunidade de desenvolvedores, que embora não atinja o usuário final, a Microsoft haverá de dar um respaldo quanto a estas questões deste tipo, como o de compartilhamento, caso queira manter-se no topo do mercado, afinal o usuário não liga tanto assim pro SO, e sim pros programas que existem disponíveis para este SO, e é interesse da MS que qualquer bom programa possa rodar no Windows.
Abraços.
Editado pela última vez por Stanis Luksys em 06 Set 2010 14:43, em um total de 1 vez.
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Acho que esse negócio de ser ou não compatilhado é o que menos importa. Um SO se mantém pelos seus usuários, que não são em sua maioria programadores. O leigo não está nem aí se fica mais fácil ou difícil com recursos compartilhados ou não.
Aliás, só pra constar: prefiro não usar nada compartilhado. Minha instalação é sempre monolítica. Se quiser, é só copiar o diretório pra outra máquina e tudo funcionará perfeitamente. Aliás, se o que ouvi for verdade, no Mac (nunca usei) é assim mesmo; cada instalação é um diretório e só. Nada fica compartilhado e muito menos espalhado pelos diretórios do SO.
Aliás, só pra constar: prefiro não usar nada compartilhado. Minha instalação é sempre monolítica. Se quiser, é só copiar o diretório pra outra máquina e tudo funcionará perfeitamente. Aliás, se o que ouvi for verdade, no Mac (nunca usei) é assim mesmo; cada instalação é um diretório e só. Nada fica compartilhado e muito menos espalhado pelos diretórios do SO.
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Re: Lançamento: RAD Studio XE
Olá
Compatilhar recursos com seus próprios softwares é fácil, difícil é compartilhar com terceiros.
A grande vantagem do Windows é também seu carrasco: o sucesso. A imensa maioria dos programadores para Windows usam a tática do "tá funcionando então tá certo" enquanto que no Linux isso é muito raro, as pessoas sabem o que estão fazendo e não aparecem, ainda, tantos aventureiros que não seguem os padrões. O Windows tá cheio de padrões que se fossem seguidos não teríamos metade dos problemos que temos, mas os programadores ignoram a existência desses padrões. Nunca foi culpa do Windows uma aplicação parar de funcionar porque ela fez coisas que não eram documentadas, mas todo mundo joga a culpa no Windows.
Open source é uma coisa excelente, só não faça escolhas me baseando só nisso.
Já usava Unix/Xenix/Minix (que foi meus primeiros passos com essa família) desde 89 e o Linux desde 95 ou 96 se me recordo bem, mas o grosso do que faço ainda é sobre o Windows.
Concordo com o Maligno. Eu só faço toda minha instalação centralizada ao contrário de compartilhar parte dela com outros, porque é mais prático para mim e evita alguns problemas sem trazer nenhuma desvantagem real prática.
T+
Compatilhar recursos com seus próprios softwares é fácil, difícil é compartilhar com terceiros.
A grande vantagem do Windows é também seu carrasco: o sucesso. A imensa maioria dos programadores para Windows usam a tática do "tá funcionando então tá certo" enquanto que no Linux isso é muito raro, as pessoas sabem o que estão fazendo e não aparecem, ainda, tantos aventureiros que não seguem os padrões. O Windows tá cheio de padrões que se fossem seguidos não teríamos metade dos problemos que temos, mas os programadores ignoram a existência desses padrões. Nunca foi culpa do Windows uma aplicação parar de funcionar porque ela fez coisas que não eram documentadas, mas todo mundo joga a culpa no Windows.
Open source é uma coisa excelente, só não faça escolhas me baseando só nisso.
Já usava Unix/Xenix/Minix (que foi meus primeiros passos com essa família) desde 89 e o Linux desde 95 ou 96 se me recordo bem, mas o grosso do que faço ainda é sobre o Windows.
Concordo com o Maligno. Eu só faço toda minha instalação centralizada ao contrário de compartilhar parte dela com outros, porque é mais prático para mim e evita alguns problemas sem trazer nenhuma desvantagem real prática.
T+
-
Stanis Luksys
- Colaborador
- Mensagens: 1329
- Registrado em: 18 Jun 2005 03:04
- Localização: São Paulo
- Contato:
Re: Lançamento: RAD Studio XE
Sim Maligno,
Eu entendo perfeitamente isso, e nem estou dizendo que deve-se fazer diferente. Se você criou um programa para Windows, ele deve, até mesmo por força conceitual, ser assim.
O que estou dizendo é que isso deve vir a ser implementado no Windows, pois hoje roda-se muitos programas opensource no Windows, e eventualmente, outros programas, sejam opesource ou não, podem se beneficiar dos recursos já disponíveis.
Quando eu faço um programa eu também coloco tudo numa pasta, mas se eu criasse um programa que poderia servir de base para muitos outros, como uma lib dinâmica em C por exemplo, não teria porque imaginar que cada programa dependente disso a colocasse no seu próprio diretório. Seria muito mais simples compartilhar.
Veja, o que estou dizendo é o seguinte. A pasta Windows fica no path do sistema é a central de recursos do Windows e de quem quiser usar os seus recursos. Acredito que futuramente haverá uma pasta com esta mesma função, mas com DLLs que foram criadas por terceiros para serem acessadas por muitos programas. Hoje muitos programas ao sereim instalados pedem pra vc copiar a DLL tal para a pasta Windows, porque sabem que outros programas usarão esta lib depois. Mas infelizmente se você desisntalar este programa e todos os seus dependentes, a DLL fica.
É só isso, não estou dizendo que no Windows qualquer programinha deva ser compartilhado ou espalhado pelo SO, mas apenas que aqueles que foram feitos para o propósito de servir base para muitos outros, possam usar o recurso de compartilhamento, assim como acontece com as DLLs do Windows.
O que proponho é só um controle maior ao invés de ficar colocando cada vez mais coisas no PATH ou então ficar copiando tudo para a pasta Windows, porque com o crescente uso de programas opensources em qualquer sistema operacinal, vai acontecer de as dependências existirem, e no caso do Windows, não há ainda controle sobre isso. Enfim, pode demorar versões, mas tenho certeza que isso será aprimorado no Windows.
No mais, os recursos criados por você e que ninguem mais vai usar nunca, fica na sua pastinha mesmo. Quem haveria de querer usar?
** editando
Me lembrei até um caso real que exemplifica isso. Outro dia formatei o PC da minha irmã e depois de tudo certinho instalei o Avast Antivirus. Notei que ele baixa o Framework C++ numseioque. Algumas semanas depois fui na casa dela e o antivirus tinha parado de funcionar, tava tudo no vermelho. Fui verificar e adivinha só? Ela entrou no painel de controle, vui aquele tal framnwork que ela nunca tinha baixado e nem tava no meu iniciar, e desinstalou.
O Sistema Operacional por sua vez não tinha controle sobre suas dependências e não avisou nada, de forma que o Antivirus parou de funcionar, e muitos outros programas também poderiam ter parado. É o típico caso onde os recursos poderiam estar compartilhados, e ser feito um gerenciamento de dependências.
Ou para prevenir, o Avast poderia ter copiado todas as benditas DLLs na sua propria pastinha, o que seria irracional (talvez até ilegal).
Eu entendo perfeitamente isso, e nem estou dizendo que deve-se fazer diferente. Se você criou um programa para Windows, ele deve, até mesmo por força conceitual, ser assim.
O que estou dizendo é que isso deve vir a ser implementado no Windows, pois hoje roda-se muitos programas opensource no Windows, e eventualmente, outros programas, sejam opesource ou não, podem se beneficiar dos recursos já disponíveis.
Quando eu faço um programa eu também coloco tudo numa pasta, mas se eu criasse um programa que poderia servir de base para muitos outros, como uma lib dinâmica em C por exemplo, não teria porque imaginar que cada programa dependente disso a colocasse no seu próprio diretório. Seria muito mais simples compartilhar.
Veja, o que estou dizendo é o seguinte. A pasta Windows fica no path do sistema é a central de recursos do Windows e de quem quiser usar os seus recursos. Acredito que futuramente haverá uma pasta com esta mesma função, mas com DLLs que foram criadas por terceiros para serem acessadas por muitos programas. Hoje muitos programas ao sereim instalados pedem pra vc copiar a DLL tal para a pasta Windows, porque sabem que outros programas usarão esta lib depois. Mas infelizmente se você desisntalar este programa e todos os seus dependentes, a DLL fica.
É só isso, não estou dizendo que no Windows qualquer programinha deva ser compartilhado ou espalhado pelo SO, mas apenas que aqueles que foram feitos para o propósito de servir base para muitos outros, possam usar o recurso de compartilhamento, assim como acontece com as DLLs do Windows.
O que proponho é só um controle maior ao invés de ficar colocando cada vez mais coisas no PATH ou então ficar copiando tudo para a pasta Windows, porque com o crescente uso de programas opensources em qualquer sistema operacinal, vai acontecer de as dependências existirem, e no caso do Windows, não há ainda controle sobre isso. Enfim, pode demorar versões, mas tenho certeza que isso será aprimorado no Windows.
No mais, os recursos criados por você e que ninguem mais vai usar nunca, fica na sua pastinha mesmo. Quem haveria de querer usar?
** editando
Me lembrei até um caso real que exemplifica isso. Outro dia formatei o PC da minha irmã e depois de tudo certinho instalei o Avast Antivirus. Notei que ele baixa o Framework C++ numseioque. Algumas semanas depois fui na casa dela e o antivirus tinha parado de funcionar, tava tudo no vermelho. Fui verificar e adivinha só? Ela entrou no painel de controle, vui aquele tal framnwork que ela nunca tinha baixado e nem tava no meu iniciar, e desinstalou.
O Sistema Operacional por sua vez não tinha controle sobre suas dependências e não avisou nada, de forma que o Antivirus parou de funcionar, e muitos outros programas também poderiam ter parado. É o típico caso onde os recursos poderiam estar compartilhados, e ser feito um gerenciamento de dependências.
Ou para prevenir, o Avast poderia ter copiado todas as benditas DLLs na sua propria pastinha, o que seria irracional (talvez até ilegal).
Editado pela última vez por Stanis Luksys em 06 Set 2010 15:23, em um total de 1 vez.
Stanis Luksys
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
sites.google.com/hblibs
Apoiar e se utilizar de projetos opensource não é uma questão de boicote, mas sim de liberdade.
Utilize, aprimore e distribua.
Re: Lançamento: RAD Studio XE
Olá
O Windows controla dependências sim, só que quase ninguém sabe disso porque desconhecem os padrões do Windows e reinventam a roda, começando pelos desenvolvedores de instaladores. O problema não é do Windows, é dos programadores porcos que não sabem ou não querem usar os recursos do SO adequadamente. E maioria dessas aplicações open preferem fugir dos padrões porque eles não querem ficar criando uma maneira diferente de fazer a mesma coisa em plataformas diferentes.
Eu gostaria de ver o Linux crescer primeiro porque é mais a minha cara e segundo para desmistificar muita coisa sobre o Linux, principalmente que o Linux tem as melhores soluções. Linux tem os melhores usuários, só isso. O sucesso do Linux faria aparecer todos os seus defeitos e ele tem muitos, assim como Windows tem uma pancada. Escolher entre Windows e Linux e escolher quais problemas se quer ter.
Na verdade eu gostaria de ver o FreeBSD crescer que é melhor tecnicamente e tem uma licença melhor também, mas não fico falando muito isso porque só faria o que a comunidade Linux é especialista em fazer, afastar cada vez mais o leigo do Linux. Papo de geek não apetece o leigo. Quando não tem geek influenciando os usuários usam muito o Linux e assemelhados, preciso dizer onde? Os geeks até se esquecem que os leigos usam muito SOs open. Eu sou geek como muitos aqui mas não nado contra a maré.
T+
O Windows controla dependências sim, só que quase ninguém sabe disso porque desconhecem os padrões do Windows e reinventam a roda, começando pelos desenvolvedores de instaladores. O problema não é do Windows, é dos programadores porcos que não sabem ou não querem usar os recursos do SO adequadamente. E maioria dessas aplicações open preferem fugir dos padrões porque eles não querem ficar criando uma maneira diferente de fazer a mesma coisa em plataformas diferentes.
Eu gostaria de ver o Linux crescer primeiro porque é mais a minha cara e segundo para desmistificar muita coisa sobre o Linux, principalmente que o Linux tem as melhores soluções. Linux tem os melhores usuários, só isso. O sucesso do Linux faria aparecer todos os seus defeitos e ele tem muitos, assim como Windows tem uma pancada. Escolher entre Windows e Linux e escolher quais problemas se quer ter.
Na verdade eu gostaria de ver o FreeBSD crescer que é melhor tecnicamente e tem uma licença melhor também, mas não fico falando muito isso porque só faria o que a comunidade Linux é especialista em fazer, afastar cada vez mais o leigo do Linux. Papo de geek não apetece o leigo. Quando não tem geek influenciando os usuários usam muito o Linux e assemelhados, preciso dizer onde? Os geeks até se esquecem que os leigos usam muito SOs open. Eu sou geek como muitos aqui mas não nado contra a maré.
T+