Double-slit Experiment: Are we Living in a Simulation?

If you’re curious about our reality but not familiar with the Double-slit experiment, I think you should take the time learn about it.  It was a favorite of Richard Feynman, a personal hero of mine.

So what about this experiment made me think about the “Are we living in a simulation?” question that has been discussed by folks of late?  It’s where it intersects with the Copenhagen Interpretation, which posits that it’s best to stick to the math and think in terms of probability waves rather than discrete measurables.

So you have this experiment that shows that an electron acts like a probability wave, until you actually observe it, and then it’s a particle.  Observe it, it’s a particle. Don’t observe it, it’s a wave.

To the software engineer in me that sounds rather like some sort of optimization. Have the simulation, where it isn’t being observed just operate in fuzzy probabilities. When a part of the system is being observed, resolve the probabilities into discrete particles. Maybe Quantum Physics is where we’ve started detecting the mechanics of the simulation.

Advertisements

@TimedMethod Aspect Implementation

You want to do some very limited metrics gathering in Java, breaking out a profiler seems like overkill, so how can you approach this?  It’s not a new story, and the code below isn’t ground breaking, a search of the net will get you several similar articles with similar solutions.  I just wrote this up because AOP tools can be a bit finicky, and so I had to dust off my old solution, to get it working again and thought I’d share the update.

The Tried And True Answer

Profiling tools in the Java ecosystem work and are very usable, but they are often involved to set up and get working, and their power can be overwhelming.  If you just want to get a few simple data points like how long a specific method taking to execute, then AOP shines for this.  The advice you want to add it just the timing collection and logging. The join point you want is simply some specified methods.  Using AspectJ and a Java annotation you can do both of these with a very small amount of code.

So first lets create an annotation that we can tag any method with to make indicating the join points trivial.

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface TimedMethod {
}

Now lets use AspectJ to write the advice.

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

import java.util.logging.Logger;

@Aspect
public class MethodTiming {
    private static final Logger LOGGER
            = Logger.getLogger(MethodTiming.class.getName());

    @Around("execution(@TimedMethod * *(..))")
    public Object timed(ProceedingJoinPoint pjp) throws Throwable {
        final long startTimeMillis = System.currentTimeMillis();
        try {
            return pjp.proceed();
        } finally {
            final long endTimeMillis = System.currentTimeMillis();
            LOGGER.info(" " + (endTimeMillis - startTimeMillis) + " ms " +
                    " spent in [" + Thread.currentThread().getName() + "] " +
                    pjp.getTarget().getClass().getName() + "." +
                    pjp.getSignature().getName() + "()"
            );
        }
    }
}

The code is done.  You now need to get AspectJ set up and then you just mark any method you want timed with the @TimedMethod annotation and the timings for every invocation of the method will spew out in your logs.

Jun 17, 2016 7:42:34 PM com.github.nwillc.timeraspect.examples.Pauser pause_aroundBody1$advice
INFO: > 2000 ms spent in [Test worker] com.github.nwillc.timeraspect.examples.Pauser.pause()

Testing Your Tests: Mutation Testing

If you’re into testing you should read the post Mutation Testing. I’m a advocate of testing in general and TDD in specific.   I’ve done mutation testing manually, breaking code to make sure my tests caught the break, but finding a tool to do it automatically seemed like a win.

What does mutation testing buy you? It makes sure your tests cover semantic changes that they might have missed.  Does your fluid API always return the target object?  Do you handle null arguments as expected?  Are all the sad paths really covered?

Having read the above I immediately tried applying the tools to one of my more stable frameworks – almost-functional.  I found that pitest had a gradle plugin and put it in place.  It was really easy to hook up, took all of maybe thirty minutes, and immediately yielded results!  I was happy to see that my coverage percentage was in line with my overall coverage (90% +) but caught some things well worth adding to improve the stability of my API.

So, yeah, if you’re a Java dev and want your tests done right, I’d advise you read the above and try it on your project.  I’ve even been chatting with folks at sites like codecov to see what it would take for them to support pitest.