Ingvord

version: '2'
services:
  tango-db:
    image: tangocs/mysql:9.2.2
    ports:
     - "9999:3306"
    environment:
     - MYSQL_ROOT_PASSWORD=root
  tango-cs:
    image: tangocs/tango-cs:9

Ingvord

@GET
@Path("/{name}")
public void get(@Context TangoProxy proxy,
                @Suspended final AsyncResponse response) {

    //this is required because parameter proxy is actually a wrapper around ThreadLocal contextualData.get
    final TangoProxy finalTangoProxy = ResteasyProviderFactory.getContextData(TangoProxy.class);
        
    CompletableFuture.runAsync(() -> {
        try {

Ingvord

Keep It Simple

One common goal of the Keep It Simple principle is to reduce the number of lines of code dedicated to a task. Fewer lines of code mean fewer latent faults.

Memory Corruption

You should not assume that data storage is always correct. There are many potential errors, from stray writes to bad memory chips to transient errors like alpha particles. Information retrieved from memory should be checked before it

Ingvord

Here I want to share I few ideas on designing an API. This is especially important if you are developing a core library, which will be used by a number of developers whom you might not even know.

API must be self explaining

Kind of obvious point, but hard to achieve actually. The key thing here is to change a hat (switch your context so that to put yourself in a position of API user).

The best is to illustrate it by discussing an anti-example (do not do this at home!):

interface Device {

Ingvord

Layered architecture

2. Protocol layer:

interface TangoProtocol {
  TangoProtocolVersion getVersion();
  TangoResponse ping(TangoRequest) throws IOException, TangoProtocolException;

Ingvord

In this gist I want to highlight two points:

• Never modify generated code
• Never put generated code into repository

I am talking about JTango, namely its IDL module (link). JTango is a Java implementation of TANGO Controls - a widely used SCADA framework.

But this gist is not specificlay about JTango itself. It is about the fact that JTango uses CORBA stubs generated from IDL i.e. it uses generated code.

For historical reason (long before I came to the project) these stubs were generated once in a while and stored in the repository. At some point we decided to migrate to maven. As maven has plugins for everything why not to generate these stubs each time we build the project. Apart from the fact that it simply feels right, we benefit from IDL compiler and CORBA implementation consitency:

Ingvord

//Client side attribute comes from user call e.g.
//consumer.subscribe_event(proxy, "Double_scalar", TangoConst.CHANGE_EVENT, new CallBack(){
//here attribute == "Double_scalar"

//line number #266
//attribute is not changed here. Should be lowerCase?
callback_key += "/" + attribute + ".idl" + device.get_idl_version() + "_" + event_name;

//...

Ingvord

JTango is Java implementation of Tango-Controls. Tango-Controls is a SCADA framework widely used at large research facilities across Europe. As it was developed by enthusiast with scientific background rather than software developers it is usually the case to see a code like this:

  public String[] getPollStatus(final String deviceName) throws DevFailed {
      xlogger.entry();
      final String fullDeviceName = TangoUtil.getfullNameForDevice(deviceName);
      final List<String> pollStatus = new ArrayList<String>();
      boolean deviceFound = true;
      for (final DeviceClassBuilder deviceClass : classList) {
          int nbDevices = 0;