To plan or not to plan

There has been a lot of posts about planning: BuildingaCity, Conformance to plan, About planning, in last few days. I feel uncomfortably not touching this topic myself.

While thinking about writing this blog, I came to the understanding, what the planning is. Planning is a process of designing a path to the final result. This path consists of tasks to be completed, resources that can be used, priorities and risks to be considered. But the most important is the understanding, that plan is not a “private static final Plan PLAN”, but rather “public Plan getPlan(Date planDate) {}” and should be used as “currentPlan = getPlan(new Date())”, if you understand what I mean :)

People want to know, what will happen next; otherwise, they get very uncomfortable and while being stressed by uncertainty, start to behave badly. Plans are used to create agreement and some certainty in the teams members, that is why it s very important to have a plan created according to our best knowledge and agreed by all team members. If plan has been created this way (we sometimes don’t have even those conditions fulfilled), why it can’t be static? Our knowledge increases constantly, thus plan, created yesterday, today does not contain our best knowledge anymore. So, plans should be changed constantly to fulfill the requirement: created according to the best knowledge. But it is not wise to change plan very frequently (every hour or day), this will lead to uncertainty. Plans should be changed regularly after some constant period, in XP those periods called Iterations, in Scrum – Sprints. Note that in XP during iteration you should follow agreed plan very strictly.

Conclusion

By making plans, human beings are trying to cooperate with uncertainty of the world. Although it is efficient to stick with the plan for some period of time, it is advisable to change plan regularly according the best knowledge, otherwise one can run against the wall if he does not look ahead and change his direction according to what he sees.

Language Oriented Programming: The Next Programming Paradigm

Our beloved Uncle Bob (Robert C. Martin), author of the book with the picture of Supernova is talking about The Next Big Thing in software development.

He hopes, that there will be no next big technological thing and he also hopes, that the major shift will be in our heads and we decide, as an industry, that we will not ship shit.

On the other side other our beloved person, Sergey Dmitriev (we love him for starting the development of Idea IntelliJ) believes, that the next big thing will be Language Oriented Programming or LOP. This term he proposes to use for the new programming paradigm which can be composed on the basis of different existing parts: intentional programming, MDA, generative programming, DSL's, etc.

The main idea of the LOP is about shortening the period of programming the designed solution by giving the programmers the language that would fit the problem domain in a most appropriate way. There are already existing DSL's for certain domains, but the main problem is, that there is no possibility to design your own language, that would fit exactly your problem domain. Sergey decided to solve this problem and currently is working on the software, that will allow to design new languages easily and according to him, not only designing possibilities matters: developers, who will use newly developed languages, will need an efficient editor for those languages, there must be also translator to some of already existing languages.

Having in mind, how appreciated Idea development environment is by Java developers community, we can hope, that Sergey will manage to give us next extraordinary thing.

Martin Fowler also believes, that it is the area to keep eye on.

Back to coding

In order to go forward, you sometimes have to look back. Now I am trying to remind myself, what was the coding about :).

I decided to implement example of very simple asynchronous messaging. My user story was: "message producer sends message to queue and message receiver gets it".

First you have to decide what implementation of JMS to use. My choice was ActiveMQ, mainly for the possibility to use it inside JVM. I just wanted to start as simple, as possible.

The first thing I understood, that I forgot how to write code. Not completely, I was pairing with our guys, but being alone in front of the code now is frightening me. Maybe I just need a teddy bear :)

Any way, I managed to create an example which uses TCP transportation. It have a BrokerAndConsumer class, which starts a BrokerContainer for queuing and then connects to this container as a MessageConsumer. MessageProducer class connects to the same container and sends a message, which is recieved by consumer class succesfully.

I also created a very simple messaging example using in-VM transportation option. Here it is:

package ee.icefire.simplemessaging; 
 
import org.codehaus.activemq.ActiveMQConnectionFactory; 
import javax.jms.*; 
import java.util.Date; 
 
public class SimpleMessage implements MessageListener { 
  public static void main(String[] args) { 
    ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("vm://localhost"); 
    try { 
      Connection connection = factory.createConnection(); 
      connection.start(); 
 
      Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 
      Destination destination = session.createQueue("BROKER.SIMPLE_QUEUE"); 
      MessageConsumer consumer = session.createConsumer(destination); 
 
      consumer.setMessageListener(new SimpleMessage()); 
 
      TextMessage message = session.createTextMessage("Message sent at " + new Date()); 
      MessageProducer producer = session.createProducer(destination); 
 
      producer.send(message); 
 
      session.close(); 
      connection.close(); 
    } 
    catch (JMSException e) { 
      e.printStackTrace(); 
    } 
  } 
 
  public void onMessage(Message message) { 
    try { 
      TextMessage textMessage = (TextMessage)message; 
      System.out.println(textMessage.getText()); 
    } 
    catch (JMSException e) { 
      e.printStackTrace(); 
    } 
  } 
}