Subscribe to RSSPolítica Comercial
Muitos desenvolvedores se mostraram descontentes com a atitude da CodeGear de descontinuar o Delphi.NET, reclamam da quantidade de produtos sem continuidade, mas esquecem que tudo isto foi feito pela Borland, e não pela Embarcadero, inclusive a decisão de mudar o foco para o Prism veio da Borland, e a Embarcadero pôde ver as vantagens e manteve a decisão.
Tudo isto faz parte da política comercial, e como eu mesmo disse em outro artigo, como desenvolvedor eu tomo decisões como esta, e no caso da CodeGear, o produto que mais causou uma explosão de sentimentos foi o Kylix, eu mesmo lamentei muito a descontinuação do produto, e não consigo ainda aceitar que foi simplesmente abandonado, mas então vamos ver este caso em específico, do ponto de vista empresarial, onde o produto teve três versões, o Kylix 3 já era um bom produto, eu usei todas as versões e até pouco tempo mantive código com o Kylix 3 usando o CrossKylix no Delphi 7. Mas mesmo após três versões e com certa maturidade, o produto ainda não dava lucro sequer pra cobrir as despesas de manutenção, três versões, no mínimo três anos, você como desenvolvedor ou empresário, manteria os investimentos neste produto?
Outro caso interessante, que podemos usar para comparação, pois vejo com freqüência usarem a Microsoft como referência, mas sequer analisam que a Microsoft faz o mesmo, hoje lendo um blog de tecnologia, vi que a Microsoft está anunciando a intenção de substituir o “LINQ to SQL” pelo “Entity Framework”, assim como já fizeram com WinForms pelo WPF, e nem vou citar outros produtos pré .NET. O que quero mostrar é que mesmo que como consumidores investimos em uma tecnologia, estamos a mercê de decisões como estas que acabam nos pegando muitas vezes de surpresa e até mesmo ferindo nosso sentimento, pois sendo usuário destas ferramentas diariamente, acabamos nos apegando e aprendendo os macetes do dia a dia.
Tecnologia é isto, é evolução, precisamos disto, precisamos nos adaptar a esta realidade. Temos de melhorar nosso trabalho, componentizar nossos projetos para aumentar a reusabilidade, ajudando a aumentar o tempo de vida comercial de nossos produtos, para que mesmo tendo uma ferramenta descontinuada, possamos ainda obter rendimentos dos produtos que criamos com elas.
Outro ponto importante é o controle de qualidade e a inovação de nossos produtos, devemos criar produtos de boa qualidade, diminuir a manutenção, para isto temos de nos aperfeiçoar diariamente, melhorar nossos processos, e por fim ter uma boa Política Comercial, estendendo o período de receitas, e aprendendo com nossos fornecedores e parceiros de negócio.
19 Comments
Os temos da MS são muito confusos, então vamos esclarecer melhor:
LINQ não tem nada a ver com Entity Framework. LINQ na verdade é apenas o recurso de executar query dentro da linguagem de forma suportada pelo compilador. LINQ não vai ser substituido por nada. Esta firme e forte.
“LINQ to SQL” é o ORM que está sendo substituido pelo Entity Framework.
Valeu Erick!
Por coincidência acabo de esbarrar no blog do PM de LINQ to SQL e Entity Framework. Ele diz que LINQ to SQL continuará sendo evoluido: http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
Bom, para que Embarcadero não faça novas “canoas furadas” como a Borland/Inprise/Borland/CodeGear fez, seria interessante:
1) Ouvir o cliente (sempre) – pesquisas de satisfação, necessidades e expectativas.
2) Implementar melhorias -> Como será o processo de adaptação/conversão e o retrabalho envolvido – É relevante para a maioria dos clientes -> Eles concordam com a maneira que será feito o processo ?
3) Vai aposentar uma tecnologia. Bom, assuma a responsabilidade e coloque uma solução viável – Não deixe o cliente empenhado/abandonado/órfão.
4) Produtos beta devem ser liberados a todos.
- Reportar bugs com identificação opcional.
- Bugs confirmados e com identificação, cita (com consentimento)o programador em uma lista de desenvolvedores na suíte (Ctrl+Alt+qualquer coisa e mostra uma lista – ovo de páscoa).
- Quem reportou bug, que foi confirmado e se identificou, oferece um desconto na aquisição do produto.
5) Aumentar o espaço entre os lançamentos de produtos, para agregar recursos matadores (fazer de cada versão uma compra imperdível), realizar bastante testes incluindo colocar o produto em linha de produção de algumas empresas parceiras pré-selecionadas.
6) Não de um presente a seus clientes e depois tome de volta – Se liberou o código, mantenha-o livre (caso do Interbase). Planejar as ações para o longo prazo e manter a constância de propósitos afirmados, transmitem segurança e credibilidade aos clientes.
7) Utilize seus próprios produtos na sua infra-estrutura. Nada de criar seus sites para comercializar seus produtos utilizando tecnologias de outros. Afinal, se nem você utiliza o produto que fabrica (preferindo o do concorrente), então nem você o suporta ou o domina.
Resumindo: Embarcadero deve explorar melhor o potencial de seus clientes e fazer o reconhecimento público daqueles envolvidos no processo – Despertar o espírito colaborativo.
Como já te disse Cesar, manter um “kylix” seria uma boa estratégia para assegurar que os desenvolvedores da plataforma Windows não migrem de delphi para outras soluções que compilem para multiplataforma.
Rodrigo, eu ainda reforçaria:
Embarcadero estaria em um sistema operacional (e quem sabe até outros no futuro) que a MS não teria interesse em portar suas ferramentas. Conforme for expandindo o movimento OpenSource, a MS vai querer tornar mais atrativa sua plataforma aos desenvolvedores e provavelmente irá distribuir de graça suas ferramentas de desenvolvimento (vide o caso dos express da vida), afinal, cobrar ou não pelas ferramentas não afetaria as principais fontes de renda dela mas em contrapartida o aumento de desenvolvedores que não ficam presos a plataforma Windows é uma ameaça – muitos hoje não migram porque aquela dita aplicação específica não roda no Linux, no BSD, no Mac, etc.
@Rodrigo, @Anderson,
Eu concordo com vocês, mas já desisti de sonhar por enquanto, prefiro no momento focar nas ferramentas que existem no momento, mas acredito que assim que a versão 64bit sair, teremos alguma evolução neste sentido, algo como o CrossKylix, pelo menos é o que tudo indica que vai existir.
Mas no caso do Linux, o que eu quero mesmo é:
- Compilador compatível com as ultimas versões do Delphi
- Servidores e Clientes TCP/IP + IPV6, no caso Indy
- DBX e os drivers pra todos os bancos
- WebService/SOAP
- DataSnap Server/Client
- Interface para Apache
Com certeza esqueci alguns itens importantes, mas isto dá a idéia que eu quero é ter o servidor de aplicações e serviços no Linux, gosto de Linux, tenho servidor e estação aqui, mas eu mesmo não quero usar no dia a dia e nem quero ter de dar suporte para desktop neste momento, acho que pra desktop Linux tem de evoluir muito.
Bom dia, Cesar – “Meu desabafo”
Eu trabalho com o DELPHI desde a versão 3.0, passei para a 5.0,para a 6.0, a 7.00 e então parei. As versões seguintes não me agradaram e achei que até então não era hora de investir em nenhuma daquelas versões.
O Delphi 2009 chegou e resolvi baixar a versão trial, para teste, resolvi que era tempo de portar o projeto “ERP” que tenho no DELPHI 7.0 e que felizmente ja está
instalado em inúmeros clientes aqui em BH. já era hora de atualizar minha ferramenta de trabalho.
Já no inicio, tive problema com o “ComboBox” todos os que eram carregados com dados dinamicamente deram erros, tive que substitui-los um por um na nova versão.
Resolvido isto, tive outro problema os “ClientDataSet” tambem criados dinamicamente,os campos Currency não apareciam de forma correta no DBGrid, e não vinha a opção
de formatação do campo com o famoso “MyClientDS.FieldByName(’CVal’).Currency:= True”;
depois de muita pesquisa, inclusive com Você, fiz uma gambiarra com o comando.:
(MyClientDS.fieldByName(’CVal’) as tCurrencyField).DisplayFormat := 0.00; para resolver
o problema.
Por fim, e o que me fez desistir da mudança, pelo menos até o momento, foi o fato de
o “assignPrn (ArqTexto)” jogar sugeira na impressora, ele simplesmente não funciona no DELPHI 2009 – façam o teste – entrei no site da GodeGear – e constatei vários posts
sobre o problema e ainda em aberto para solução.
Não vou trocar minha ferramenta de trabalho, mesmo porque foram vários anos de estudo, e trabalho, mais uma coisa é certa – estou decepcionado !!!!.
O Delphi 2009 já tem seu primeiro Update que corrige uns 50/60 bugs. Fui verificar a lista e constatei que:
- Boa parte dos erros foram referentes ao componente Ribbon
- Consertos referente a banco de dados, acho que nenhum relevante
Alguém ai trabalha com dbexpress + Devart (dbxida) + Firebird ?
Estou pensando em migrar para o Delphi 2009 e de saída já tenho 03 pendengas:
- Falta driver para firebird (o que tenho da Upscene parece não ser compatível oficialmente e o autor não se pronúnciou sobre uma nova versão). E gostaria de saber se o driver da Devart que possui suporte ao Delphi 2009 é bom (e o preço de U$ 99,95 é bastante competitivo, dá prá abraçar).
- No blog do Chau Chee Yang, tem várias dicas para ajustar os fontes em função do Unicode e ao mesmo tempo reporta um Bug que a aplicação compilada no Delphi 2009 que utiliza o dbexpress, dá erro se não achar os dbxdrivers.ini e dbxconnections.ini. No QC já havia menção disto a um bom tempo, o que leva a crer que suporte a banco de dados não é prioridade e nem faz parte dos testes (ou os testadores estão com as rotinas viciadas que não pegam estas situações).
- O Delphi 2009 esta tendo rotatividade/aceitação, não vejo relatos de migração de sistemas ? (é importante para saber quais as dificuldades encontradas e qual o caminho das pedras).
Anderson, em uma conversa informal com o Nick, ele me disse que um outro update somente para a parte de DB está sendo preparado e será disponibilizado muito em breve, foi apenas uma questão de foco para a correção dos bugs.
Inclusive este bug comentado pelo Chau Chee Yang, já faz parte deste update.
As dificuldades geralmente se encontram em blogs internacionais, e geralmente já com dicas para entender o que deve ser feito, por que o que muitas vezes ocorre, são divergências devido a mudança para Unicode, fazendo com que o comportamento de Char/PChar seja completamente diferente, e que antes muita gente usava estes tipos e string para armazenar “byte array”, quando deveria usar TBytes.
Eu converti todos meus frameworks, componentes e experts para 2009 sem problemas, não estou compilando os projetos para 2009, por uma questão de precaução, não quero correr riscos nos clientes, mas projetos pequenos sim, todos já faço com 2009.
Pela minha experiência, se você tiver os componentes que usa para 2009, migrar a aplicação é muito simples e os problemas do desabafo do Mauro, eu não tive, então sem um projeto que tenha os erros, fica difícil comentar.
Caro Cesar,
Abaixo descrevo uma unit simples que tem como objetivo listar o conteudo de um “Memo”. No Delphi 7 funciona perfeitamente, porem o mesmo código sem alterar nada, não funciona no Delphi 2009 – Quando Vc tiver um tempo – faça um teste e me diga.:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Printers;
type
TForm1 = class(TForm)
Button1: TButton;
Memo1: TMemo;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
Texto : TextFile;
I : word;
begin
try
AssignPrn(Texto);
Rewrite(Texto);
For I := 0 To Memo1.Lines.Count -1 do begin
WriteLn(Texto,Memo1.lines[I]);
end;
finally
CloseFile(Texto);
end;
end;
end.
Cesar, ótimas notícias – Agora é aguardar o update e se confirmado as correções, ir as compras (do update do Delphi e do driver da Devart).
Fico feliz que o pessoal do Delphi (Embarcadero) está botando a mão na massa, me deixando mais tranquilo em seguir apostando na solução.
O Delphi passou uma fase de tramite (se Win32 ou .NET) muito ruim, devido a filosofia adotada pela Borland “Levar ao futuro sem esquecer do passado”. A realidade agora é outra, temos
tecnologias distintas (Win32 e .NET), é muito difício para uma empresa manter essa carga. Agora que temos empresas distintas (…Embarcadero e RemObjects) tratanto cada tecnologia, fica mais claro para nós clientes e também mais viavel o investimento.
Cesar, “o em breve” do Update para banco de dados pode ser expresso em dias, semanas, meses… Tem alguma pista ou dica do Nick sobre a possível data de liberação ?
Cesar, Boa Noite, sei q/ seu tempo é escasso, porém veja se você pode me ajudar a respeito do “assignprn”, como postei acima, ele não funciona no Delphi2009 – será q/ Vc tem alguma dica para nos passar ??? – Você realizou algum teste ???. Se tiver algo a respeito por favor, manda pra gente.
Valeu.
Mauro Otoni
Mauro, eu tive um problema similar usando o ClientDataSet quando testei o Delphi 2009 em uma máquina virtual, que não aceitava passar diretamente a propriedade do componente, tenta substituir o WriteLn(Texto,Memo1.lines[I]) por:
var
st_memo:string;
.
.
st_memo:=Memo1.lines[I];
WriteLn(Texto,st_memo);
e coloca uns checks/breakpoints para ver o que esta acontecendo, pois dependendo de como esta sendo chamado o código, os erros estão sendo omitidos. Eu já tive problemas com as exceções silenciosas (agora em todo o except, coloco mensagem), onde usamos o Try .. Except e no bloco do except não colocamos nenhum aviso sobre o erro que ocorreu e ai o código simplesmente “não funciona” e “não fala nada”.
Caro Cesar, infelizmente o “assigprn” não funcionou no Delphi2009 – fiz todas as mudanças q/ Vc sugeriu, porém ele continua jogando “lixo” para a impressora. O pior é que o assunto ainda está em aberto no “QC” e sem solução. De qualquer maneira agradeço sua atenção pelo assunto. É estranho este problema não está acontecendo com outros usuarios.
Mauro, estou viajando em cliente.
Semana que vem estarei de volta, ai posso testar.
Mas com certeza tem solução, e eu desconfio que o problema é que você está enviando string para impressora, e cada caracter são 2 bytes, enquanto que o assignprn espera ansistring, por enquanto sugiro que vc crie uma variavel local como AnsiString e passe este valor para o assignprn.
Mauro, tenta trocar o comando AssignPrn(Print) por AssignFile(Print, ‘LPT1′).