Friday, February 13, 2015

Book: The E-Myth Revisited

The E-Myth Revisited, Gerber, E. Michael.

It is a too verbose text for my tastes, so I will summarize it for you:

People usually start a business with a technician mindset but a successful business requires balanced entrepreneur, manager and technician roles.
  • Entrepreneur: What do people need? How much would they pay for it? How will they know about my product (marketing)? What is my future vision for the company and myself?
  • Manager: Provide structure (processes, manuals etc.) to the organization.
  • Technician: Check technical feasibility of product ideas, build products.
Each role requires the same amount of time and attention. The main reason for business failures is that their founder is not aware of this and is stuck in one (usually technician) role.

Tuesday, February 10, 2015

Notes about A*

A* (AStar) is a relatively easy to implement pathfinding algorithm. There are good resources that explain the algorithm, so I won't go into detail here:
I find the following particulary interesting:
  • Closed list does not mean pure path list. It contains the path nodes and all the nodes that were considered as path nodes some of which not being on final path.
  • Once the end node is reached, path is constructed by starting from end node and going backwards to parent nodes until start node is reached, i.e. until parent node == null.
  • If open list becomes empty (i.e. no more nodes left to consider) before end node is reached, it means there is no path from start to end.
  • Switch parent according to G cost.
  • If h is admissable (i.e. if h >= hOptimal), A* will find shortest path.

Saturday, January 31, 2015

Book: The Inner Game of Tennis

The Inner Game of Tennis by W. Timothy Gallwey argues that success can result only if you don't try too hard which sounds counter intuitive. Trying too hard means becoming emotionally attached and being judgmental. He gives practical tips on how to achieve relaxation while practicing. First and foremost, you have to be interested in what you are doing.

A very good book for anyone who wants to be a better person by using tennis (or any other practice) as a means to achieve inner peace and perfection.

Thursday, January 15, 2015

Minimal Software Design

A minimal software design effort should include the following:
  • What problem are you trying to solve? Is the problem specified clearly?
  • Comprehensibility: What will you do to help others (or yourself one year later) understand your code/design. Hint: Wiki, coding conventions, KISS.
  • Modularity/dependency: What approach will you take to make your modules independent? Hint: Encapsulation, MVC pattern.
  • Testability: How will you make sure that your implentation will be as unit testable as possible? Hint: Keep methods short. Whenever you can, make objects/methods static.
  • Error handling and logging: What error cases do you foresee and what mechanisms will you have in place to log and recover from errors? Hint: Exceptions.

Friday, November 28, 2014

Difference between a hobby project and a product

One of the most important lessons an engineer learns is that a going from a demonstration prototype (i.e. "hobby project") to a product that other non-engineer people can use requires a lot of additional work. I would say that prototype to product transition requires as much work as creating the protoype.

A product
  • is well tested and can work under a wide range of conditions (this is the main cost difference because additional testing reveals previously unknown weaknesses and will force you to make major design changes)
  • anticipates internal errors / environmental anomalies and has mechanisms in place to recover gracefully
  • anticipates user error and guides the user when he does something wrong
  • has an intuitive user interface (i.e. people don't need to ask an engineer how to operate it)
A novice thinks he almost has a product when he demonstrates basic functionality. The wise one knows that he has only covered half the distance.

Friday, November 21, 2014

Improving java.awt.Polygon contains() method

The contains() method in java.awt.Polygon, which checks if the input coordinate is inside the boundary, might not return true for all the points that you would expect. Example: xPoints = {0, 5, 10, 15, 15}, yPoints = {0, 5, 3, 10, 0}. With the standard Polygon class, contains(5,5), contains(15,10), contains(15, 0) all return false although these points are on the polygon (indicated by arrows in the figure below). If you use Matlab's inpolygon function you will get true for all of them.

The reason is related to the "insideness" definition. A point is considered to lie inside a Shape if and only if:
  • it lies completely inside the Shape boundary or
  • it lies exactly on the Shape boundary and the space immediately adjacent to the point in the increasing X direction is entirely inside the boundary
  • or it lies exactly on a horizontal boundary segment and the space immediately adjacent to the point in the increasing Y direction is inside the boundary.
I have written ImprovedPolygon whose contains() method returns true for the above cases by checking if the input coordinates lie on the edges of the polygon using the line formula y = m*x + n and limits of the line end points. Both ImprovedPolygon and its unit test class ImprovedPolygonTest can be downloaded from GitHub here.

Listening to: Take me to Church - Hozier

Monday, November 17, 2014

Java: Information hiding using interfaces

Typically, the "private" key word is used to hide any methods/attributes from other classes. However, there are cases where a class has one set of methods that is used by class A and another set of methods that are used by class B which means that all these methods have to be public. To prevent class A from accessing methods meant for class B, we can use interfaces as depicted in the following example: