Diego Pacheco Tech blog

Remote work was kind of the default for me. I'm a Gypsy, always traveling, 6 months home in Brazil, 6 months in Europe / USA. Doing that for +10 years makes me feel remote native :-). Even in Brazil, I travel a lot to Santa Catarina and S ao Paulo states. I go to standard office 1-2 times per week maximum. So remote was a default for me a long time. Now we are facing dangerous and different times because of the COVID-19 .  So remote becomes the default for everybody. Remote work has several advantages like You dont loose commute time, I used to lose 2h per day in a traffic jam. Also, you can have your meals with your family and you can work with much more comfort and focus. IMHO I always worked much more from HOME rather in the office for basic 3 reasons. First of all, I felt much more obligated to produce more results since I was working from home. Second I have much fewer interruptions in HOME than in a formal office. Unfortunately, there are tons of people who do not know h...

Github is the best platform for remote work nowadays. I'm not saying that because my company( ilegra ) is a Github partner but because I deeply believe that. I always liked Github, in fact, way before my company become a partner. Anyone can use Github anyway, however just dropping code in Github won't do the trick, there are patterns and practices you can follow to the best out of Github. PR's(Pull Requests) can be great or can be a nightmare depending on how you do. I use Github since 2009(Yes, +10 years), today I want to share the trick and patterns I use working with Github with my teams in remote projects. There is no right or wrong, this is what works for me, I'm not saying this is the only way, but here we go on what I'm doing so far. This is not the first post I do about Code Reviews, this is more towards remote work but you won't check these posts out: 1. Lessons Learned and Experiences doing Code Review. 2. Business Review: The Gateway to Automati...

Is quite common you need debug JBoss remotely, basically you may have an Linux server running it for Development or QA environment. In order to be able to debug JBoss in your machine you just need change one configuration file. Open the file $JBOSS_HOME \bin\run.conf in your favorite text editor an serach for this lines: # Sample JPDA settings for remote socket debugging # JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n" You new uncoment the last line, like the following sample: # Sample JPDA settings for remote socket debugging<br>JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"<br> The parameter address is the port that JBoss will be listing to remote debug. Now you can open eclipse an run and remote debug like the following sample: 1. Create a new Remote Java Application Debug configuration. 2. Select your project, remember that must be an EAR or WAR(You can use jar...

Em sintese depende do cenário. Considerando as possíveis formas de remoting do Spring: RMI Http Invoker Hessian Burlap Jax RPC JMS EJB RMI: Acredito que todos conhecem essa abordagem. É na verdade semelhante ao RPC só que para objetos, vocês podem achar mais informações aqui . A Desvantagem é ter que disponibilizar uma porta na maquina. Http Invoker : Estratégia especial de remoting que faz comunicação via protocolo http via serialização. A vantagem é por que trafegamos por um protocolo caracter que já está disponível para nos, leia-se já é utilizado por uma aplicação web. Hessian : É um protocolo leve baseado em http binário, que é provido através do Caucho. Você pode encontrar mais informações sobre esse protocolo para Web Service binário aqui . A Vantagem é que é bem leve. Burlap : É uma solução baseada em XML como alternativa do Hessian, também desenvolvido pelo Caucho's. É muito utilizado em comunicações com dispositivos moveis, como o telefone celular, já que alem de simp...