Team Heartbeat

I wonder if it shouldn't work pretty well to run a team of developers like a heartbeat network? Perhaps the 25min + break running schedule of the pomodoro technique.

It might solve the problem with being disturbed by notifications, questions, requests. Discipline might or might not be enough; and usually you want to write down your error message or problem right away; to avoid forgetting what it was, and the context.

Of course, this system could be even tighter provided all relevant tools could support it: e.g. support holding notifications and messages that arrive during the pomodoro 25min work interval without annoying the workers out of their focus. On the other hand, with such tool support, or even better, one might not need the centralized heart beat.

Or maybe just turn off Skype's sound. But wait, there are other sounds, e.g. email. So if at least the apps on my computer could be centralized into one notification inbox. Hm, what about web apps? Ah, there seems to be an experimental API for that.

> Heartbeat (computing) - Wikipedia, the free encyclopedia
> Heartbeat network - Wikipedia, the free encyclopedia
> Pomodoro Technique - Wikipedia, the free encyclopedia
> How To Use The HTML5 Notification API (Dated? Demo fails.)
> http://caniuse.com/#search=notification

Big Test Data & JUnit

A good old session of writing-to-clarify coming up.

I have a pretty difficult challenge on my hands. Well, difficult as in non-trivial, non-standard, etcetera. Which is what makes it worth writing about.

I am importing external data into a database. Most of the difficulties are beside this blog post. The subject difficulty is the testing: testing with real data. You can of course do unit tests, and I have so done, that test the details of the formats.

Now, the real data to import is big enough that you don't want to just stick it in a repo. So what can you do instead?

One thing I've done is this: download the data from the source over the internet. This takes some time the first time on a machine, but when the data is downloaded and cached as a file, it's instantly available.

Downloading is also a good test in itself, since the solution will have to automatically check for updated data now and then at a bunch of URLs.

Another thing is to try to cut the data down in size. But that is not so attractive; it's possible to make a mistake; at least in the formats that are not really simple like CSV.

So; moving ahead with the downloading solution, I need to do tests that are certainly not unit tests. JUnit is used, so it'd be nice to make them JUnit tests. This is where the 'non-standard' thing comes in. There seems to be no standard way to mark tests as manual-only in JUnit. The one way I know is to put excludes in maven's surefire. That's kind of clumsy; this should really be part of the actual source code.

So, I cooked up another solution recently, the one posted as 'Spring Plain Java Test'. But this will not be part of the JUnit tests, so as a UI for other developers it's not so good; you'd want them to be able to see these tests as ...tests. And the standard way to do that is to make them JUnit tests so they show up in their GUIs as tests. 

I have no good (practical, standard) solution to all of this.

This is related to a concept of readability, find-ability of projects that have been thinking about a lot, and written some drafts for blog posts, but they are in the cooler for now. Suffice it to say that I think it is a poor bunch of tools, practices and standards that we usually work with and within. 

Tools for the Distributed Team: ETGB Queue

Teamwork is a difficult problem to solve. And I'm not talking about conflicting personalities or whatever; just the bare practicalities of it. For instance, interrupting each other, or not. Waiting on somebody who's forgot to get back to you.

It's very much like multithreading: interrupt(ion)s and context switches often incur a non-trivial cost.

So I often end up thinking about how better adapted tools could help. Imagining tools carefully designed for cooperatively multitasking humans, or perhaps better, 'mostly cooperatively', the nodes are humans, that we're imagining kind of realistically.

And I am thinking about so-called distributed teams.

So, one problem out of many: you've send a question about work ongoing via Skype chat. No reply. You wait. Should you prod your peer again? In 15 minutes? It's hard to miss notifications in Skype, so it's probably not that the message wasn't seen. The coworker might simply be swamped in things to do.

So, that's a common scenario; now how could tools help here? And/or changed practices.

How about ACK support? "I hear you, sorry, later. "

Plus an ETA, or let's make an acronym: Estimated Time When I Can Get Back To You. ETWICGBTY. Estimated time of getting back to you. ETGB?

The awaitee end will of course often get multiple requests. That'd be a Queue; and the tool would of course update the ETGBs for everyone. Requestors should probably only be allowed one spot in the queue each. They should probably only ask for the most important or pressing thing to be done.

The poor overworked awaitee might feel stressed by seeing a row of ETGB promises, but I think that'd be at least one better than getting Skype-pinged every half hour.

Spring Plain Java Test

Invented the following as a way to run tests from main() etc without JUnit, which always annoys me with its lack of control (e.g. can't select which tests to run from multiple packages, unless you want to run all or use Suite/SuiteClasses (or, please tell me how!); can't annotate as Ignore to maven, but tell JUnit to run them manually (or tell me how!); can't run tests found with Find References, etc...or maybe one can do that, I'll have to check...), at least when I use it in Eclipse which I use. Took me a while, so I thought it might save some time for somebody, or even myself if I should find myself working in Spring again in the future.

Sorry if the formatting is whack -- I am using blogger.

package jn.spring.test.support;

import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestContextManager;

/**
 * If no better solution can be found (I've searched for a couple of hours) to
 * inhibit JUnit tests that are not good as automatic tests, this allows Spring
 * context etc to run from any Java code, e.g. main(). 

 * 

 * 
 * NOTE: maybe configure Maven Surefire excludes could be a way. 

 * 


 * 
 * @author jonasnordin4
 * 
 */
public abstract class PlainJavaSpringTestClassBase {
 
 PlainJavaSpringTestClassBase() {
 }
 
 public void _run() {
  Object tt = this;
  Class testClass = tt.getClass();
  runTestClass(testClass, this);
 }
 
 /**
  * Override to implement a test. 
  */
 public abstract void test();
 
 public static void runTestClass(Class testClass, PlainJavaSpringTestClassBase tt) {
  System.out.println("running...");
  TestContextManager tcm = new TestContextManager(testClass);
  System.out.println("tcm: " + tcm);
  try {
   System.out.println("tcm.prepareTestInstance(tt);...");
   tcm.prepareTestInstance(tt);
   System.out.println("did: tcm.prepareTestInstance(tt);");
   tt.test();
  } catch (Exception e) {
   // TODO Auto-generated catch block
   // e.printStackTrace();
   throw new RuntimeException(e);
  } finally {
     try {
       // this seems to work to clean up. E.g. Spring background threads that keep us from exiting.
       tcm.afterTestClass();
     } catch (Exception e) {

        e.printStackTrace();

     }
     
   }
   
 }
 
 /**
  * No persistence, so set-up runs quickly. 
  * 
  * @author jonasnordin4
  *
  */
 @ContextConfiguration(locations = {
   "classpath*:com/projectname/config/spring-common*.xml",
   // "classpath*:com/projectname/config/spring-cache.xml",
   // "classpath*:com/projectname/config/spring-persistence.xml",
   // "classpath*:com/projectname/config/spring-vfs.xml",
   "classpath*:com/projectname/config/spring-*-test.xml" 
   })
 public abstract static class QuickPlainJavaSpringTest extends
   PlainJavaSpringTestClassBase {
  
 }
 
 @ContextConfiguration(locations = {
   "classpath*:com/projectname/config/spring-common*.xml",
   // "classpath*:com/projectname/config/spring-cache.xml",
    "classpath*:com/projectname/config/spring-persistence.xml",
   // "classpath*:com/projectname/config/spring-vfs.xml",
   "classpath*:com/projectname/config/spring-*-test.xml" 
   })
 public abstract static class PersistencePlainJavaSpringTestClassBase extends
   PlainJavaSpringTestClassBase {
  
  
 }
 
 /**
  * See if this technique works. It seems to work well. 
  * 
  * @author jonasnordin4
  *
  */
 public static class PlainJavaMetaTest {
  
  /**
   * See if '@ContextConfiguration' is inherited (it is). 

   * 

   * 
   * @author jonasnordin4
   *
   */
  public static class TheTestClass extends QuickPlainJavaSpringTest {
   @Override
   public void test() {
    
   }
  }
  
  public void run() {
   final TheTestClass it = new TheTestClass();
   it._run();
  }
  
  public static void main(String...args) {
   new PlainJavaMetaTest().run();
   PersistencePlainJavaSpringTestClassBase p = new PersistencePlainJavaSpringTestClassBase() {
    public void test() {
     
    };
   };
   p._run();
   // System.exit(0); // needed, or some Spring thread lives on. No, see tcm.afterTestClass(); above.
  }
  
 }
}

Back To Write

Have been off the grid for four days. And I haven't worked with the computer, but rather been doing manual, rural work; working the body, resting the mind. Pretty great, I do feel rested.

And I think I now know how to write a few blog posts here: in a non-reactive, simple style. And only write with one fundamental subject in mind; until it achieves some kind of closure: motivation.

(It says something about my vocabulary that I used the words 'reactive' and 'closure', doesn't it.)