Crude Java and Agile thoughts
In a (m x n) matrix, m is the number of rows, n is the number of columns.
Two matrices ( a x b ) and ( c x d ) can be multiplied only if b == c.
(m x n) multiply (n x p) will result into a (m x p) matrix
Only square matrices can be inverted. Inversion is a tedious numerical procedure. Guass jordan method is a popular method to matrix inversion.
A x A(inverse) = Ainverse) x A = I ( where I is an identity matrix, it is a special case of diagonal matrix where all diagonal elements are 1 ).
If a determinant has a nonzero value, its matrix is described as regular and that if a determinant has zero value, its matrix is described as singular.
Associated with any square matrix is a single number that represents a unique function of the numbers in the matrix. this scalar function of a square matrix is called the determinant. the determinant of a matrix a is denoted by |a|.
If the determinant of the (square) matrix is exactly zero, the matrix is said to be singular and it has no inverse.
Symmetric matrix means that the matrix and its transpose are identical (i.e., a = a’).
If a matrix m is orthogonal then M x M(transpose) = M(transpose) x M = I = 1
where I is the identity matrix. but, we know that M x M(inverse) = I = 1. consequently, M(transpose) = M(inverse) ( for orthogonal matrices ). A variance-covariance matrix is used for representing a multivariate vector of p elements. the determinant of of variance-covariance matrix, is sometimes called the generalized variance.
Looks like the whole Agile world is running towards the junit coverage for quality. Does higher Junit Tests Coverage ensures better code quality? No way. The only assurance of better code quality is low complexity.
Junit Tests should be used as a tool to assist in achieving low complexity. Only high code coverage never ensures a flexible maintainable code. I have explained all this in detail in “The Myths of Junit Code Coverage“. This will help you for sure.
Nowadays Agile is almost on its peak of popularity, and Scrum is on everybody’s tongue. I see Scrum being followed almost everywhere. I even came through videos where kids were using Scrum to manage their tasks. I see small/big projects using Scrum to deliver quick and superior products. I see questions and curiosity about Scrum. There are groups where people discuss, share their Scrum pain points and other areas of improvement.
However, Distributed Scrum definitely not as easy as plain Scrum is. It involves geographical, cultural and chronological issues. It has its own set of rules. To have a successful distributed Scrum team is not at all a piece of cake. Read more of this post
Maven Lucene Plugin is an open source maven plugin for Apache Lucene developed by Xebia India IT Architects Ltd . The project is hosted on SourceForge and can be found here. It is released under GNU General Public License (GPL).
maven-lucene-plugin creates a Lucene index from a file source. The structure of the lucene index i.e. fields, analyzers, indexLocation, fileSourceLocation, store etc can be configured in a configuration file lucene.xml.
lucene.xml contains all information regarding the lucene index and the data source (from which the index is created). The Maven Lucene Plugin looks for lucene.xml file in the project root directory (adjacent to pom.xml) and creates the lucene index from the file source mentioned in lucene.xml based on the index configuration provided. Read more of this post
The first version of Maven Lucene Plugin has been released. The plugin is an open source project hosted at SourceForge. The plugin can create indexes from a file data source. The index can be configured by specifying elements in a file lucene.xml. It also provides a maven dependency maven lucene search which provides utility methods on the index created.
The plugin empowers you to use the strong capabilities of Apache Lucene with very limited or no knowledge of the technical internals of Lucene. The complete documentation about the usage of the maven lucene plugin can be found here.
The plugin is available at Central Maven Repository.
I recently did an experiment by designing using CRC cards. I did with my team and found it quiet useful and comfortable. The design outcome of this process was also the team’s design rather than one person’s design. Also, as everyone participated in the designing the design was better than a single person’s design. Please read the complete blog on my official blog site and share your thoughts.
Recently I experimented with pair programming by using two keyboards, one for driver and another for navigator. I was amazed by its out comings. It made programming fun and the code quality, design as well as the productivity increased. I have written the complete blog on my official blog site. Looking at the comments I got on that blog, I assume that people using two keyboards really like this technique. I think its high time we should change the definition of pair programming by adding a clause of using two keyboards. Referring to one of the comments I got on the blog “Pair programming was evolved much before the evolution of usb drives, so using two keyboards was not an option at that time”. Please read the complete blog and share your thoughts. Thank you.
The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:
The Blog-Health-o-Meter™ reads Wow.
You will often find people in Agile teams cribbing about the overload of meetings. Initially I also cribbed. Then, with time I became more “Agile” and then thought “communication is a key feature” of Agile. I tried to attend meetings with interest. However, I always tend to return towards cribbing about “Overload of meetings”.
So, I thought that there must be something wrong in my interest towards meetings.
The irony was, I always attended other non project meetings with great enthusiasm and participation. So, I tried to capture the impulsive moments of boredom in meetings when I my interest drifts away from the subject.
One of the major points was beginning of discussion on topics which were not planned for the meeting. So, in this scenario, you expect one thing and the result is something else. So, if you are not prepared for what is being discussed, you will feel isolated and get into your own world. Read more of this post
My tryst with TDD (Test Driven Development) started around 2 years back, when my tech lead told me to try to code this way. The first feeling was of shock. I admired my lead a lot due to his immense technical capability. So, this process centric stuff didn’t suited his style of work. Most of the time he gave us all freedom to do a job. So, he specifying a process to write code looked a bit confusing to me.
However, I tried to follow his advice (guideline ;)), at least few times, but never found anything fruitful from it. Those days I was using Agile but not Extreme Programming. So, the tryst with TDD didn’t lasted long as I was never able to utilize it judiciously. The end result of following this practice was not coming clear to me.
Later, I changed my company. The new (present) company was a veteran in Agile and Extreme Programming methodologies/practices. So, I learned to pair program. Learned to re factor. Learned to not do the complete designing at once. Learned to do upfront designing.
Here the emphasis on junit test writing was enormous . So, I sharpened my skills on junit test writing and after a while, I was able to write junit tests pretty easily.