An Easy Executable Software Specification – A Proposal

Executable Specification 1Executable specification is a "holly graal" of modern software engineering. It's very hard to implement as it requires:

  • Formal specification of rules
  • Transformation of those rules into real-system predicates
  • Stimulating system under tests state changes in repeatable manner

FitNesse is one of such approaches that specifies function sample inputs and outputs then allow to run such test cases using special connectors and provide colour reports from test runs. It's easy to use (from specification point of view), but has the following drawbacks:

  • Software architecture must be compatible with unit testing (what is very good in general: cut unnecessary dependencies, Inverse of Control, …) – your current system might require heavy refactoring to reach such state
  • Rules are written and evaluated only during single test execution – different scenario requires another test case (no Design By Contract style continuous state validation)

Above features are present in any other unit test framework: JUnit, unittest, … All such testing changes state and checks output.

Continue reading

Posted in en | Comments Off on An Easy Executable Software Specification – A Proposal

Conflicting DHCP server locator under Linux

cable-ethernetIn order to locate conflicting DHCP server in your LAN execute the following command:

sudo dhcpdump -i eth4 | awk '/IP:/{SRC=$2 " " $3} /OP:.*BOOTPREPLY/{ print "DHCP server found:", SRC; }'

The restart your PC network (use DHCP to get new IP). If you see more than one IP address here:

DHCP server found: (0:9:6b:a3:fc:4a)
DHCP server found: (f8:d1:11:9e:1d:8b)
DHCP server found: (0:9:6b:a3:fc:4a)
DHCP server found: (f8:d1:11:9e:1d:8b)
DHCP server found: (0:9:6b:a3:fc:4a)

Then you have two, conflicting DHCP servers in your network. You can use tool to locate the device type that causes the problems.

Posted in en | Tagged , | Comments Off on Conflicting DHCP server locator under Linux

Setting up proper terminal size for serial connection to an embedded device

consoleWhen you work over serial line on an embedded device usually the terminal size it set to 80×25.

There's an easy way, however, to setup your real terminal size, just add the following line to your profile script (~/.profile):

resize > /tmp/resize
. /tmp/resize

resize command detects real terminal size and sets COLUMNS and ROWS parameters accordingly:

# resize

One just need to execute the output as sh commands (using source "." command).

Posted in en | Comments Off on Setting up proper terminal size for serial connection to an embedded device

PlantUML – draw your diagrams declaratively

One picture is worth of thousand words. So true. Even if you describe some flow with many detailed paragraphs one sequence diagram might show the idea instantly to the reader much better than all the words.

Separation of diagram drawing software (Visio, Dia, …) from your main documentation system (Google Docs, Latex, doxygen, …) is not a good idea. Having no access to source of the diagram makes modification much harder to do (when original author is not available, you have, actually, re-draw the diagram from scratch to fix some minor change).

Text-based diagrams and some form of post-processing is the answer to above problem. You embed your documentation AND the diagrams in the document and tools change those into graphics when needed. Example of such systems cooperation is doxygen and plantuml.

Let's see how easy sequence diagram could be expressed in plantuml:

MainProcess -> Library: FacadeCall()
Library -> SSO: GetToken()
Library -> Server: CallService(token)
Server -> SSO: IsTokenValid(token)

The result is rendered as diagram below:

sequenceThere are more advanced functionality there, but I hope you have already caught the idea.

Next diagram type I'd like to explore is state diagram:

Continue reading

Posted in en | Tagged | Comments Off on PlantUML – draw your diagrams declaratively

Meeting "minutes" in three simple steps

Nobody likes it. They are boring duty you ought to do after a meeting. What? "Minutes", of course.

By "minutes" I mean: a note from the meeting (or a telco) that should be sent after a call to all participants involved in order to remind what has been agreed on the meeting and what action items are specified and who is responsible for implementation.

boring-meetingIs there a way to make this very useful tool more effective? The answer is: YES!

First of all: lets enumerate expected properties of those "minutes":

  • easy to write
  • do not skip/forget anything important
  • allow to control if every action item has an assignee

Having above properties in mind I've implemented the following process using an online documents solution (Google Docs, to be specific):

  • I send proposed agenda as online document link to every participants and I allow them to extend it if needed
  • During the call I (or any participant) add action items and responsible persons to the document. Remember: concurrent editing is fun!
  • A copy the document is sent after the call in the same e-mail thread as invitation
  • And now: the previous step delivers your team "minutes"! Voila!

Everyone has R/W access to the document and this is the gag – you can delegate your job to add notes and complete document (including completeness checks) to meeting participants. They enjoy that as they're involved in the meeting flow and the output directly. Nobody is bored.

To speed things up you can add timestamp to each agenda item. Such meeting could never miss allocated time!

Implementation tracking is also easy – you can add ticket tracking ID (Jira, Redmine) to the minutes and assign appropriately.

Happy (not boring) meetings! 🙂

Posted in en | Tagged | Comments Off on Meeting "minutes" in three simple steps