coder . cl

Defining state machines is not so hard as it appears. Initially you can build constructs that can help on building automata processing much friendly than using plain code. Starting from the idea that you can place your state machine inside data structures allowing friendly editing without modifying the processing code. Any stateful processing can be migrated to state machines. As any automata can be represented in a state diagram and then it can be migrated to plain data structures. Even if you are using a purely functional programming language, you can place a stateful processing data structure to be processed as automata.

I was reading this blog post about productivity porn. Probably I can agree that there are many tips about how to be productive in our work, but we can use many of those tips, I think that many of those tips are good enough to make our day very productive. But memory is weak. I recognize that I cannot remember everything that I can do on a day. Mainly once you have many real work projects, side projects or personal projects. So, to make a day productive — mainly if you are a freelancer and nobody is pressuring your work and you must be responsive by your own initiative — you need some tool to track or make you remember your tasks. A calendar like GMail is useful, but as Emacs user, I prefer to use org-mode.

Graphical objects in ProView are providing two types animations and behavior attributes, where both can be highly customized. Dynamics are those animations related on how the object operates with the environment — mouse and keyboard — and the logical plant nodes. At the other side, actions are those XTT commands triggered with the user interaction. So, for example we have the Electric > ControlSwitch sub-graph, which has the action DigShift, but we can change the DigShift action to ToggleDig, allowing a digital input switching between True and False, and preserve the rotate animation which is inherited from its definition.

As you know I am working on a ProView project. It has a logical and physical distinction between plant and station nodes. Physical nodes are mainly controlled by logical nodes, including user defined applications written in C, C++ or Java. On this case we are using C and C++, C for low level ProView calls and C++ to create a nice object oriented interface. A very good approach is found on ProView General Data Handler or GDH API, where you can have access to the full node hierarchy using GDH calls. This allows managing nodes in all levels, even if you want to create new nodes in run-time. This is very nice, so I have defined a C++ class device to manage each device automatically and due to the algorithm complexity we cannot use PLC programming.

Usually you get stuck in your computer trying to solve problems. But problems are solved thinking, and getting stuck in the computer is not the optimal way to think in complex problems. In one of my recent projects I have been working on a complex state machine, which is hierarchical and deriving states to each device on the system. On a computer is hard to have an overview of the entire system, even if you have a good modelling tool. In our team we are doing some diagrams on whiteboards, taking photos from them and then we are individually thinking on wider perspectives of the problem.

ProView provides a nice interface to build custom device classes, I/O classes and graphic classes, mainly to build processing graphics. In our current project we have many device configurations which are subject of repeated configurations. To avoid repetitive work we are using classes, of all kinds. Custom process graphics as components can avoid repetitive work with equal configurations and specific processing graphics. I have made a sample HMI — Human Machine Interface — to control some devices which will be used on the real plant.

Startups as companies seems to be a common approach to create new business. There are many startups being created, with online services as their primary goal and goods. But the fact that only few companies of that kind can grow quickly — where many of their owners are expecting an exponential growing — others are failing on almost everything that they can expect, from project planning to the implementation, and many of them will not succeed. You will probably see many startup owners asking theirself «what did I missed?». I think that to succeed on a startup is to have a very clear an initial goal for the product features that it will offer. Without a clear goal — which leads to a product roadmap — they will offer something very different from the original idea. Without having a good roadmap, you will be missing resources, almost of all kinds. Is nice to have a good product, but no matter if it is fully implemented or not, the quality of that product with its released features should be good enough to support the initial investment, and probably it will make the product to grow as you are expecting.