* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
We develop some desktop applications here at RSoftware. When we need to install or update them into some customer's network, we need to do that in each machine of the network, and these are boring and time consuming activities.
So, since the early days of December, we are testing a new way to deploy our desktop applications, using Java Web Start. During the last two weeks we've deployed two of our applications, to three customers. Everything is working fine 'till now, and we're so satisfied with the tool. To use Java Web Start it's necessary (1) to set up a HTTP Server, (2) to set up applications that will be available by the HTTP Server and (3) to install the applications into users' machines. It's not difficult to reach each one of these goals...
(1) you can use any HTTP Server, such as Apache, as a Servlet container is not required;
(2) you need to follow some steps, such as generating application's jars, signing them (and also third parties') up with a digital signature and configuring a JNLP (Java Network Launching Protocol) file that describes how your application will be available and deployed into your customers' machines;
(3) easy to do, the user just download the JNLP file and Java Web Start does the work of downloading, installing, launching and updating (when necessary) your application into his machine.
Since the applications are installed into users' machines, and we need to update them, the only thing we need to do is to update the version we keep available in the HTTP Server. Java Web Start auto updates users' versions of the installed applications the first time they are launched after the server version has been updated.
Our life has become much easier with Java Web Start. We recommend it!
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Nós desenvolvemos algumas aplicações desktop aqui na RSoftware. Quando precisamos instalá-las ou atualizá-las na rede de algum cliente, é preciso fazê-lo em cada máquina da rede, e essas são atividades são chatas e demoradas.
Assim, desde o início de dezembro, estamos testando uma nova forma de distribuir nossas aplicações desktop, utilizando Java Web Start. Nas últimas duas semanas implantamos dois de nossos sistemas, para três clientes. Tudo está funcionando bem até agora, e estamos bem satisfeitos com a ferramenta. Para utilizar o Java Web Start é necessário (1) configurar um servidor HTTP, (2) configurar as aplicações que estarão disponíveis pelo servidor HTTP e (3) instalar os aplicativos nas máquinas dos usuários. Não é difícil alcançar cada um destes objetivos ...
(1) você pode usar qualquer servidor HTTP, como o Apache, já que um Servlet container não é necessário;
(2) você precisará seguir algumas etapas, como gerar os jars do aplicativo, assiná-los (e também os de terceiros) com uma assinatura digital e configurar um arquivo JNLP (Java Network Launching Protocol) que descreve como o aplicativo estará disponível e será implantado nas máquinas de seus clientes;
(3) fácil de fazer, basta apenas o usuário baixar o arquivo JNLP, e o Java Web Start faz o trabalho de baixar, instalar, executar e atualizar (quando necessário) o aplicativo em sua máquina.
Uma vez que os aplicativos estejam instalados nas máquinas dos usuários, e seja preciso atualizá-los, a única coisa que precisamos fazer é atualizar a versão que fica disponível no servidor HTTP. O Java Web Start atualiza automaticamente os aplicativos instalados nas máquinas dos usuários na primeira vez que eles são executados após a versão servidor ser atualizada.
Nossa vida se tornou muito mais fácil com Java Web Start. Nós o recomendamos!
Tuesday, December 15, 2009
Monday, July 13, 2009
One machine, two Tomcats (Uma máquina, dois Tomcats)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Today we solved an annoying problem here at RSoftware. About two months ago we delivered a webservices based solution to one of our customers, and we needed to run two instances of Tomcat in a Windows XP machine. Our first approach was to install a Tomcat instance using the installation program and manually set up another, after unzipping it instead of installing. Both instances had the same version: 6.0.16. The first one was registered as a Windows service by the installation program, started up automatically, and run on port 80. The second one we started up using the bin\startup.bat script provided by the unzipped version of Tomcat, running on port 81. We registered a Windows task that run bin\startup.bat every time the operating system started up.
Our first feeling about that the solution was that it worked fine. But, some days later it presented a problem: if any user logged into the server and logged off some minutes later, the instance of Tomcat started by the bin\startup.bat script, simply shutted down. It was a big problem. We tried many alternatives and looked for some "light" in the internet. Today we succeeded, registering also the manually set up instance as a Windows service. The solution is very simple: when we unzip Tomcat, it comes with a bin\service.bat file. Just run the command "C:\your-Tomcat-installdir\bin\service.bat install SecondInstanceID", where you change the value of SecondInstanceID by the id, or name, desired for your instance. After running this command, the instance is registered as a Windows service and you can set up additional options using the "services.msc" application. There are options like how to startup (manual or auto), that can be so useful.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Hoje resolvemos um problema chato aqui na RSoftware. Há aproxidamante dois meses atrás entregamos uma solução baseada em webservices para um de nossos clientes, e precisávamos executar duas instâncias do Tomcat em uma máquina rodando Windows XP. Nossa primeira abordagem foi instalar uma instância Tomcat usando o programa de instalação e configurar manualmente uma outra, após descompactar o Tomcat, ao invés de instalar. Ambas instâncias tinham a mesma versão: 6.0.16. A primeira foi registrada como um serviço do Windows pelo programa de instalação, iniciada automaticamente, e rodava na porta 80. A segunda foi inicada utilizando o script bin\startup.bat fornecido pela versão descompatada do Tomcat, e rodava na porta 81. Registramos uma tarefa no Windows que roda o bin\startup.bat toda vez que o sistema operacional é iniciado.
A nossa primeira impressão sobre a solução foi a de que ela funcionou corretamente. Mas, alguns dias mais tarde, apareceu um problema: se algum usuário logasse no servidor e fizesse logoff alguns minutos mais tarde, a instância do Tomcat iniciada pelo script bin\startup.bat, simplesmente caía. Foi um grande problema. Nós tentamos muitas alternativas e procuramos alguma "luz" na internet. Hoje nós resolvemos o problema, registrando também a instância configurada manualmente como um serviço do Windows. A solução é muito simples: quando nós descompactamos o Tomcat, ele vem com um script bin\service.bat. Basta executar o comando "C:\caminho-do-seu-Tomcat\bin\service.bat instalar IDSegundaInstancia", no qual você muda o valor de IDSegundaInstancia pelo id, ou nome, desejado para sua instância. Após executar este comando, a instância é registrada como um serviço do Windows e você pode configurar opções adicionais utilizando o aplicativo "services.msc". Existem opções como o modo de inicialização (manual ou automático), que podem ser bem úteis.
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Today we solved an annoying problem here at RSoftware. About two months ago we delivered a webservices based solution to one of our customers, and we needed to run two instances of Tomcat in a Windows XP machine. Our first approach was to install a Tomcat instance using the installation program and manually set up another, after unzipping it instead of installing. Both instances had the same version: 6.0.16. The first one was registered as a Windows service by the installation program, started up automatically, and run on port 80. The second one we started up using the bin\startup.bat script provided by the unzipped version of Tomcat, running on port 81. We registered a Windows task that run bin\startup.bat every time the operating system started up.
Our first feeling about that the solution was that it worked fine. But, some days later it presented a problem: if any user logged into the server and logged off some minutes later, the instance of Tomcat started by the bin\startup.bat script, simply shutted down. It was a big problem. We tried many alternatives and looked for some "light" in the internet. Today we succeeded, registering also the manually set up instance as a Windows service. The solution is very simple: when we unzip Tomcat, it comes with a bin\service.bat file. Just run the command "C:\your-Tomcat-installdir\bin\service.bat install SecondInstanceID", where you change the value of SecondInstanceID by the id, or name, desired for your instance. After running this command, the instance is registered as a Windows service and you can set up additional options using the "services.msc" application. There are options like how to startup (manual or auto), that can be so useful.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Hoje resolvemos um problema chato aqui na RSoftware. Há aproxidamante dois meses atrás entregamos uma solução baseada em webservices para um de nossos clientes, e precisávamos executar duas instâncias do Tomcat em uma máquina rodando Windows XP. Nossa primeira abordagem foi instalar uma instância Tomcat usando o programa de instalação e configurar manualmente uma outra, após descompactar o Tomcat, ao invés de instalar. Ambas instâncias tinham a mesma versão: 6.0.16. A primeira foi registrada como um serviço do Windows pelo programa de instalação, iniciada automaticamente, e rodava na porta 80. A segunda foi inicada utilizando o script bin\startup.bat fornecido pela versão descompatada do Tomcat, e rodava na porta 81. Registramos uma tarefa no Windows que roda o bin\startup.bat toda vez que o sistema operacional é iniciado.
A nossa primeira impressão sobre a solução foi a de que ela funcionou corretamente. Mas, alguns dias mais tarde, apareceu um problema: se algum usuário logasse no servidor e fizesse logoff alguns minutos mais tarde, a instância do Tomcat iniciada pelo script bin\startup.bat, simplesmente caía. Foi um grande problema. Nós tentamos muitas alternativas e procuramos alguma "luz" na internet. Hoje nós resolvemos o problema, registrando também a instância configurada manualmente como um serviço do Windows. A solução é muito simples: quando nós descompactamos o Tomcat, ele vem com um script bin\service.bat. Basta executar o comando "C:\caminho-do-seu-Tomcat\bin\service.bat instalar IDSegundaInstancia", no qual você muda o valor de IDSegundaInstancia pelo id, ou nome, desejado para sua instância. Após executar este comando, a instância é registrada como um serviço do Windows e você pode configurar opções adicionais utilizando o aplicativo "services.msc". Existem opções como o modo de inicialização (manual ou automático), que podem ser bem úteis.
Wednesday, January 14, 2009
Testers: juniors or seniors? (Testers: juniores ou seniores?)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
I've seen in small and large IT companies the culture of hiring the youngest and cheapest techinical people to the testing teams. The reason, usually, is the same: "we need to control the costs...". Ok, I know every company needs to control its costs, but, I also believe that quality assurance should be one of main goals of any IT company. Some consequences of unexperienced people testing software are easy to list:
1. Vulnerability. How can a team assure software security if they don't know the difference between HTTP and HTTPS? How can they test some software if they don't know what SQL Injection is?
2. Poor performance. How can a team measure software response time if they don't know what a stress testing is?
3. Usability problems. How can a team assure software is good, or easy, to use, if they are not used with the surrounded technologies? Here I mean: does the developed software follow Windows, or Internet, or any other environment patterns, look and feel, like shortcuts, colors, hints, accelerators...?
Yes, it happens in many companies, and believe me, it happens even in the largest brazilian IT companies. Project managers should think about it, 'cause it's very common to pay the highest wages to senior architects, or some senior developers, but testers are in most cases, the cheapest employees. If testers aren't experienced, mature and don't have a good technology knowledge, any effort during the requirements gathering and development phases won’t result in good quality software.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Tenho visto em pequenas e grandes empresas de TI a cultura de contratar as pessoas mais jovens e baratas da área técnica para as equipes de testes. O motivo, normalmente, é o mesmo: "é preciso controlar os custos ...". Ok, eu sei que toda empresa precisa controlar seus custos, mas também acredito que a garantia de qualidade deve ser um dos principais objetivos de qualquer empresa de TI. Algumas consequências da inexepriência das pessoas que compõem as equipes de testes são fáceis de enumerar:
1. Vulnerabilidade. Como uma equipe pode garantir a segurança de um software se eles não souberem a diferença entre HTTP e HTTPS? Como eles podem testar um sistema se eles não sabem o que é SQL Injection?
2. Desempenho ruim. Como uma equipe pode medir o tempo de resposta de um software se eles não sabem o que são testes de stress?
3. Problemas de usabilidade. Como uma equipe pode garantir que o software é bom, ou fácil, para uso, se não forem acostumados com as tecnologias que o envolvem? Aqui eu quero dizer: o software desenvolvido seguiu os padrões do Windows, da Internet, ou quaisquer outros padrões de uso e aparência, como teclas de atalho, cores, dicas...?
Sim, isso acontece em muitas empresas TI, e acredite, isso acontece mesmo nas maiores empresas brasileiras desse setor. Os gerentes de projetos deveriam pensar nisso, porque é muito comum a pagar os maiores salários para arquitetos seniores, ou alguns desenvolvedores também seniores, mas os testers são, na maioria dos casos, os trabalhadores mais baratos. Se não forem profissionais experientes, maduros e não tiverem um bom conhecimento das tecnologias, qualquer esforço durante as fases de leventamento de requisitos e desenvolvimento não resultará em software de boa qualidade.
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
I've seen in small and large IT companies the culture of hiring the youngest and cheapest techinical people to the testing teams. The reason, usually, is the same: "we need to control the costs...". Ok, I know every company needs to control its costs, but, I also believe that quality assurance should be one of main goals of any IT company. Some consequences of unexperienced people testing software are easy to list:
1. Vulnerability. How can a team assure software security if they don't know the difference between HTTP and HTTPS? How can they test some software if they don't know what SQL Injection is?
2. Poor performance. How can a team measure software response time if they don't know what a stress testing is?
3. Usability problems. How can a team assure software is good, or easy, to use, if they are not used with the surrounded technologies? Here I mean: does the developed software follow Windows, or Internet, or any other environment patterns, look and feel, like shortcuts, colors, hints, accelerators...?
Yes, it happens in many companies, and believe me, it happens even in the largest brazilian IT companies. Project managers should think about it, 'cause it's very common to pay the highest wages to senior architects, or some senior developers, but testers are in most cases, the cheapest employees. If testers aren't experienced, mature and don't have a good technology knowledge, any effort during the requirements gathering and development phases won’t result in good quality software.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Tenho visto em pequenas e grandes empresas de TI a cultura de contratar as pessoas mais jovens e baratas da área técnica para as equipes de testes. O motivo, normalmente, é o mesmo: "é preciso controlar os custos ...". Ok, eu sei que toda empresa precisa controlar seus custos, mas também acredito que a garantia de qualidade deve ser um dos principais objetivos de qualquer empresa de TI. Algumas consequências da inexepriência das pessoas que compõem as equipes de testes são fáceis de enumerar:
1. Vulnerabilidade. Como uma equipe pode garantir a segurança de um software se eles não souberem a diferença entre HTTP e HTTPS? Como eles podem testar um sistema se eles não sabem o que é SQL Injection?
2. Desempenho ruim. Como uma equipe pode medir o tempo de resposta de um software se eles não sabem o que são testes de stress?
3. Problemas de usabilidade. Como uma equipe pode garantir que o software é bom, ou fácil, para uso, se não forem acostumados com as tecnologias que o envolvem? Aqui eu quero dizer: o software desenvolvido seguiu os padrões do Windows, da Internet, ou quaisquer outros padrões de uso e aparência, como teclas de atalho, cores, dicas...?
Sim, isso acontece em muitas empresas TI, e acredite, isso acontece mesmo nas maiores empresas brasileiras desse setor. Os gerentes de projetos deveriam pensar nisso, porque é muito comum a pagar os maiores salários para arquitetos seniores, ou alguns desenvolvedores também seniores, mas os testers são, na maioria dos casos, os trabalhadores mais baratos. Se não forem profissionais experientes, maduros e não tiverem um bom conhecimento das tecnologias, qualquer esforço durante as fases de leventamento de requisitos e desenvolvimento não resultará em software de boa qualidade.
Monday, January 5, 2009
JFace applications in your language (Aplicativos JFace em seu idioma)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
As an IT freelancer, I develop ERP applications to small businesses. Since 2004 I use Java to the development, and, when such applications need desktop clients, I use Eclipse's JFace library. I can use resource bundles to my applications' specific messages, menus, hints, etc. But, every time I use JFace's resources (such as a Message Dialog), messages are displayed in English, even if my customer is running its application here in Brazil. Until these days I hadn't given a special attention to this behavior... But, occasionally, I was looking for some information about Eclipse's Language Packs, and I found it's pretty easy to apply the Language Packs, even applications that use only JFace.
For example, to apply a Language Pack to a JFace Message Dialog, just download the Language Pack file (if you use Ganymede version, click here to download...), and put the org.eclipse.jface.nl_pt_BR_3.4.0.jar into your application's classpath. Run your application and call any Message Dialog to test.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Como freelancer na área de TI, desenvolvo aplicações ERP para pequenas e médias empresas. Desde 2004 eu uso Java para o desenvolvimento e, quando essas aplicações precisam de clientes desktop, uso a biblioteca JFace, do Eclipse. Posso utilizar resource bundles para as mensagens específicas de minhas aplicações, menus, dicas, etc. Mas, toda vez que utilizo os recursos do JFace (como o Message Dialog), as mensagens são exibidas em Inglês, mesmo se meu cliente está executando a aplicação aqui no Brasil. Até estes dias não tinha dado uma atenção especial para este comportamento... Mas, por acaso, eu estava procurando algumas informações sobre Language Packs para o Eclipse e percebi que é muito simples de aplicar os Language Packs, mesmo para as aplicações que usam apenas a JFace.
Por exemplo, para aplicar um Language Pack para um Mesage Dialog da JFace, basta fazer o download do arquivo correspondente ao Language Pack (se você usar a versão Ganymede, clique aqui para fazer o download...), e colocar o org.eclipse.jface.nl_pt_BR_3.4.0.jar no classpath de sua aplicação. Rode sua aplicação e chame qualquer Message Dialog para fazer um teste.
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
As an IT freelancer, I develop ERP applications to small businesses. Since 2004 I use Java to the development, and, when such applications need desktop clients, I use Eclipse's JFace library. I can use resource bundles to my applications' specific messages, menus, hints, etc. But, every time I use JFace's resources (such as a Message Dialog), messages are displayed in English, even if my customer is running its application here in Brazil. Until these days I hadn't given a special attention to this behavior... But, occasionally, I was looking for some information about Eclipse's Language Packs, and I found it's pretty easy to apply the Language Packs, even applications that use only JFace.
For example, to apply a Language Pack to a JFace Message Dialog, just download the Language Pack file (if you use Ganymede version, click here to download...), and put the org.eclipse.jface.nl_pt_BR_3.4.0.jar into your application's classpath. Run your application and call any Message Dialog to test.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Como freelancer na área de TI, desenvolvo aplicações ERP para pequenas e médias empresas. Desde 2004 eu uso Java para o desenvolvimento e, quando essas aplicações precisam de clientes desktop, uso a biblioteca JFace, do Eclipse. Posso utilizar resource bundles para as mensagens específicas de minhas aplicações, menus, dicas, etc. Mas, toda vez que utilizo os recursos do JFace (como o Message Dialog), as mensagens são exibidas em Inglês, mesmo se meu cliente está executando a aplicação aqui no Brasil. Até estes dias não tinha dado uma atenção especial para este comportamento... Mas, por acaso, eu estava procurando algumas informações sobre Language Packs para o Eclipse e percebi que é muito simples de aplicar os Language Packs, mesmo para as aplicações que usam apenas a JFace.
Por exemplo, para aplicar um Language Pack para um Mesage Dialog da JFace, basta fazer o download do arquivo correspondente ao Language Pack (se você usar a versão Ganymede, clique aqui para fazer o download...), e colocar o org.eclipse.jface.nl_pt_BR_3.4.0.jar no classpath de sua aplicação. Rode sua aplicação e chame qualquer Message Dialog para fazer um teste.
More articles on Java Magazine (Mais artigos na Java Magazine)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
From January to March of 2009 I'll publish 3 more articles on Java Magazine. They are intended to help begginers with their first "experiences" with Java.
The first article, in January (65th edition), covers the more theoretical part: layers and design patterns. I'll explain the differences about physical and logical layers, basic concepts of 3 logical layers application development (Presentation, Domain Logic and Data Access) and the following design patterns: DAO (Data Access Object), MVC (Model-View-Controller), Observer and Singleton.
The second one, in February (66th edition), covers the modeling and development of the Domain Logic and Data Access layers. I'll show a basic UML modeling of Domain Logic and the usage of DAO desing pattern, JPA and Hibernate to provide Data Access.
The third one, in March (67th edition), will bring the development of the Presentation layer, using SWT and MVC design pattern.
I would like to thank Eduardo, magazine's editor, for the new opportunity. Also, I hope the readers enjoy the subjects covered by the articles. Any comments can be post here.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
De janeiro a março de 2009 publicarei mais artigos 3 na Java Magazine. Eles têm por objetivo ajudar os novatos com suas primeiras "experiências" com Java.
O primeiro artigo, na 65a edição, em janeiro, abrange a parte mais teórica: camadas e design patterns. Vou explicar as diferenças entre as camadas física e lógica, conceitos básicos para desenvolvimento de aplicações em 3 camadas lógicas (Apresentação, Lógica de Domínio e Acesso a Dados) e os seguintes design patterns: DAO (Data Access Object), MVC (Model-View-Controller), Observer e Singleton.
O segundo, na 66a edição, em fevereiro, abrange a modelagem e desenvolvimento das camadas de Lógica de Domínio e Acesso a Dados. Vou mostrar um pouco de modelagem UML para Lógica de Domínio e a utilização do padrão DAO, JPA e Hibernate para prover Acesso a Dados.
O terceiro, na 67a edição, em março, trará o desenvolvimento da camada de Apresentação, usando SWT e o padrão MVC.
Gostaria de agradecer ao Eduardo, editor da revista, pela nova oportunidade. Além disso, espero que os leitores apreciem os assuntos tratados nos artigos. Comentários podem ser postados aqui.
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
From January to March of 2009 I'll publish 3 more articles on Java Magazine. They are intended to help begginers with their first "experiences" with Java.
The first article, in January (65th edition), covers the more theoretical part: layers and design patterns. I'll explain the differences about physical and logical layers, basic concepts of 3 logical layers application development (Presentation, Domain Logic and Data Access) and the following design patterns: DAO (Data Access Object), MVC (Model-View-Controller), Observer and Singleton.
The second one, in February (66th edition), covers the modeling and development of the Domain Logic and Data Access layers. I'll show a basic UML modeling of Domain Logic and the usage of DAO desing pattern, JPA and Hibernate to provide Data Access.
The third one, in March (67th edition), will bring the development of the Presentation layer, using SWT and MVC design pattern.
I would like to thank Eduardo, magazine's editor, for the new opportunity. Also, I hope the readers enjoy the subjects covered by the articles. Any comments can be post here.
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
De janeiro a março de 2009 publicarei mais artigos 3 na Java Magazine. Eles têm por objetivo ajudar os novatos com suas primeiras "experiências" com Java.
O primeiro artigo, na 65a edição, em janeiro, abrange a parte mais teórica: camadas e design patterns. Vou explicar as diferenças entre as camadas física e lógica, conceitos básicos para desenvolvimento de aplicações em 3 camadas lógicas (Apresentação, Lógica de Domínio e Acesso a Dados) e os seguintes design patterns: DAO (Data Access Object), MVC (Model-View-Controller), Observer e Singleton.
O segundo, na 66a edição, em fevereiro, abrange a modelagem e desenvolvimento das camadas de Lógica de Domínio e Acesso a Dados. Vou mostrar um pouco de modelagem UML para Lógica de Domínio e a utilização do padrão DAO, JPA e Hibernate para prover Acesso a Dados.
O terceiro, na 67a edição, em março, trará o desenvolvimento da camada de Apresentação, usando SWT e o padrão MVC.
Gostaria de agradecer ao Eduardo, editor da revista, pela nova oportunidade. Além disso, espero que os leitores apreciem os assuntos tratados nos artigos. Comentários podem ser postados aqui.
Tuesday, October 7, 2008
MVC in desktop... update 1 (MVC no desktop... atualização 1)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Today I updated the post about MVC in desktop development. After coding some use cases, I changed a little the architecture. Now it's simpler than the first one, and working better.
VERSÃO EM PORTUGUES (PORTUGUESE VERSION)
Atualizei hoje o post sobre MVC no desenvolvimento para desktop. Depois de desenvolver alguns casos de uso, mudei um pouco a arquitetura. Agora ela está mais simples que a anterior, e funcionando melhor.
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Today I updated the post about MVC in desktop development. After coding some use cases, I changed a little the architecture. Now it's simpler than the first one, and working better.
VERSÃO EM PORTUGUES (PORTUGUESE VERSION)
Atualizei hoje o post sobre MVC no desenvolvimento para desktop. Depois de desenvolver alguns casos de uso, mudei um pouco a arquitetura. Agora ela está mais simples que a anterior, e funcionando melhor.
Monday, September 1, 2008
Calendar (Calendário)
* This post has a version in English and then a version in Portuguese
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Monday, 09/01/2008, I go to my internet bank and... see this calendar:
Wich day of the month will be 09/13?
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Segundona, 01/09/08, eu abro o site do banco e me deparo com esse calendário:
13/09 cairá em qual dia do mês?
* Este post tem uma versão em Inglês e em seguida uma versão em Português
ENGLISH VERSION
Monday, 09/01/2008, I go to my internet bank and... see this calendar:
Wich day of the month will be 09/13?
VERSÃO EM PORTUGUÊS (PORTUGUESE VERSION)
Segundona, 01/09/08, eu abro o site do banco e me deparo com esse calendário:
13/09 cairá em qual dia do mês?
Subscribe to:
Posts (Atom)