Posted in tips

How to do repetitive tasks in vi?

A general technique that we know is pressing the dot key. But it quickly becomes inapplicable, if one wants to apply a set of tasks repeatedly.

For that, we have the recording feature. When we want to record, press q followed by any symbol in the alphabet or a digit. All the actions will be recorded in a buffer which can be referred to by this symbol. Once the tasks are done, press q again to stop recording. Now we are ready for replaying the tasks. To replay the task, place the cursor at the corresponding position (this can also be recorded and can save you time and energy). Press @<symbol> to replay that set of tasks. If we have to choose one among a set of tasks to do in the current situation, then give the appropriate symbol (of course, you must have recorded that set of tasks with that symbol as its reference). In this way, you can do a set of tasks very easily. Pressing @@ would repeat the last task.

Posted in musings

The Ferrari show.

No, it is not the show on the roads. Its the show in the factory. Today I accidentally tuned to the NatGeo channel and saw the making of Ferrari. What an awesome piece of documentary was that!! I was simply amazed at the quality assurance of the folks there. The way they test the things, the way they work with passion, the way they build things, the way their work environment was organized, every minute thing was a treat to the eyes and the brain.

They have got a mini race course track to test the Ferrari!! But that is only the first phase of testing. The next phase is on the real roads. The entire fitting of the engine is done manually. The whole body of the car is checked for its perfect aerodynamic design very carefully. The aesthetic section carefully stitches all the leather work. One guy points minute discrepencies in the painting of a car and sends it back to the painting department. The robotic arms were designed to operate with precision…the list goes on. It is the place. The quality place. I am simply awestruck by the environment there.

There also is software. I wonder who builds such mission critical software. Definitely not these business software folks (that includes me 🙂 ). Such mission critical software is also built in cathedrals. There must be some solid engineering processes in place to build and certify such software. Sometimes, there wont be any existing models to build, so it is a new one in its own kind. They are software engineers. And mind you, such software is never outsourced. It is all done by the folks there.

Posted in problem solving

Incrementally reading log files..

The problem is this: You have a set of log files. You will have to scan the log files periodically and retrieve only new messages. You are allowed to put  a marker in it. The log files switch frequently. Here is what is can be done:

  1. Sort the files according to the modification time.
  2. While there are more files, do:
    1. Put a marker in the syslog file.
    2. Scan for the number of markers.
    3. If the number of markers scanned is zero and the number of markers found so far is also zero, read all the messages in the file.
    4. If the number of markers scanned is 1 and the number of markers scanned so far is zero, it means that this is the first marker being encountered, so read all the messages from the marker to the beginning of the file.
    5. If the number of markers is scanned is 1 and the number of markers scanned so far is also 1, it means that we are actually reading the messages from a log file which has already been read to some extent. Read the messages from the end of the file to the marker and return. No need to scan the files further.
    6. If the number of markers scanned is greater than or equal to 2, then read the messages between the last two markers and return.
    7. If the number of markers scanned so far is greater than or equal to 2, then return, no need to search further.

If we cannot put a marker in the file, then we can do the following:

  1. Have a config file where there are sets of key=value pairs. The key is the file identification (say its inode number or a checksum of the file name) and the value is the number of lines read so far from the file.
  2. When incrementally scanning the files, read the config files and load the key=value pairs in a hash.
  3. For each file:
    1. If the filename’s checksum is found in the hash, get the count of lines read, read the remaining lines and update the count of lines read.
    2. If the filename’s checksum is not found in the has, read all the lines and add an entry in the hash accordingly.
    3. Save the config file back to the disk.
  4. Return.
Posted in git, software

Linus on Git

There are somethings that Linus talks about in his Git talk to Google, that caught my attention:

  •  Performance is NOT secondary. It affects the way you work, it affects the quality of the work.
  • Its not the file that matters, its the content that matters – that is what git is centralized around (yet distributed)
  • SVN was trying to solve the wrong problem (dealing with branches and not merges which was the problem)
  • With Git, Linus gets the job done by other folks as much as possible with its distributed nature. 🙂