Going through my source files, I came across one of my old projects. A very interesting one...that I eventually somehow forgot about..till I saw it today. I had code-named the project 'Turtel'. It's undocumented in the sense that I never mentioned it in the Blog.

The project was an attempt to understand the effectiveness of different indicators and strategies if used in the stock market.

I was also exploring Design Patterns at this time. The project became multi-purposed - to improve my understanding of the patterns (I seemed to have used the Strategy Pattern and the Factory pattern in my implementation) and explore the effectiveness of investment strategies.

Here is a link to the last version (I believe) - where I left off - Project Turtel

The page above is not very interactive. But what it does is very cool (imo :)). You pass along 5 variables in the query string: fee, P, K, symbol, days, show

Fee is the transaction fee per purchase/sale
P and K are used for cross-overs I believe - values of 10 and 2 for example mean when the 10 day SMA crosses the 2 day SMA etc...
Symbol is the stock symbol - as listed in Yahoo (for example RIM would be RIM.TO)
Days indicates the number of days of data to use - a value of 100 would mean use the last 100 days of data
Show indicates whether to show the dates and quantities of transactions. A value of 1 means "yes, do show"; anything else means "no, don't"

Two strategies were implemented at the time - SMA cross-over and I think MACD cross-over. The outputs are based on these two.

Here is an example of the URL with the query string. The bolded parts are what you would change to see the output for the new values.

http://www.ai-projects.info/Turtel/sim/driver.php?P=10&K=2&days=501&show=1&symbol=RIM.TO&fee=0

May be I shall continue this project some day. But for now its probably going to stay in its suspended state. This is one of the reasons I like to look into my old stuff - I usually find something interesting :)

Labels: php, programming, project, turtel

In about 2 days :) - the first version of LocFinder is ready

I am planning on some feature additions and more sites to crawl later..currently the information contained comes from crawling only rentershotline.ca. I am thinking of having the bot crawl it every night...so the information would get updated in 24 hour periods.

The rental information is represented graphically, but if you want futher details - it links back to rentershotline.ca

Labels: bot, crawling, LocFinder, programming, project, spider, V1, Version 1, web

The busy school term is almost over. I just have 1 more exam to go..I figured I can loosen up a bit now. I have two ideas that I really want to implement in the next short little while. I'll call these projects LocFinder and LuckFinder:

• Loc Finder - We (a couple of us) are looking for rental places..there are many sites out there with a lot of information...found them kinda hard to use...I figured, I'd create a web crawler that crawls these sites and presents the information in a very friendly form.
  
  I thought this was done well by Subletr. Unfortunately...it doesn't seem to work anymore :(
  
  Well, this has given the opportunity to fill that gap. Here I go.
  
• Luck Finder - Can't explain this now...I want to implement it first :)

Hope to have this done soon! :)

Labels: crawling, LocFinder, LuckFinder, programming, project, spider, web

I wanted to try and add some php code to blogger, and when I added some php code to the template page, nothing seemed to happen....here is how you make it work:

It is actually very simple. It is a 2 step process.

Step 1: Set your blog file name in publishing option to index.php (the default is index.html). The fact that its a php file now allows you to integrate php code in the template that would be processed by the server. Here is an image of where you would do this:


Step 2: Add the php code to your template. Here is an image showing that.


The same steps will be followed for ASP pages or anyother server side scripting language - the difference being, the blog filename extension would have to correspond to the language (.asp for ASP).

The drawback is that this would only work on the index page, the rest of the pages (archives, post permanent link pages etc) are still generated as html pages.

Labels: blogger, php, programming, website

In my last post, I had complained about OOP and made some general statements, but those were probably too general to be readily usable. If OOP is not a swiss army knife and has cases where it would make sense - what are these cases?

Rephrasing this question - when to use Object Oriented Programming?

To know when to use OOP, it is important that we look at why does OOP even exist - what benefits did researchers have in mind when they came up with it.

Benefits of OOP:

• Aligns with our "model" of the world. A dog is an animal = you have a Dog class thats derived from an Animal class. Dog's do a bunch of actions like bark, eat, sleep etc... - the Dog class has bark, eat and sleep methods.
  
  What this alignment means is that the code becomes easier to read and understand. When a code is easier to read and understand, it is easier to maintain. Assuming good practices are followed, changes can be made easily and with a lower chance of breaking the app, by different people over a long time.
  
• Concepts such as inheritance reduce code duplication - thus you can make changes in less places and the change is universal, rather than you having to hunt down each instance of a code and changing it. This makes maintenance and extension of the application easier and less error-prone.
• Design patterns and Decoupling: Using OOP with design patterns you can decouple the many components in your application. When things are tightly coupled (have strong interdepency), you may not realize that one part of your app relies on another (this becomes true when the size of your app increases), and when you change one thing, a whole lot of things break elsewhere. You can use design patterns to decouple the components in your app (like the Model-View-Controller pattern)
  
  You have ready-made solutions to common problems, say you have different objects and you want one object to be automatically notified of changes in another object, you have a ready-made solution already - the observer pattern! This reduces the amount of work you have to do, and speeds up your development. See the posts on Design Patterns for more of their benefits.

OOP is not all sweet, it does have negatives that we should be aware of. Losses of OOP:

• In most cases, when you introduce OOP, you also introduce some performance drain. Objects are heavy things. They encapsulate what you want to work with and more. In procedural programming where you work directly with the data, you don't have the Object Overheads.
  
  Though, hardware is ever improving and in most cases we may not have the need to care about the performance degradation OOP results in.
• OOP results in writing a lot...sort of. OOP introduces a strong structure in the way you have to communicate, while this may be seen as a good thing, in reality it depends on what you want to do. The Coding horror blog has a good example of this: http://www.codinghorror.com/blog/archives/000617.html
  
  The OOP solutions spans 15 lines (mind you...the definition of the Object is not included in the line count), the procedural solution spans about 2-4 lines.
  
  OOP reduces the amount of code you write through reduction in code duplication. But increase the amount of fresh code you write to do things.
  

As you can see, most benefits of OOP come from its benefits in long-term maintenance and patterns for faster solutions . So, when is it best to use OOP?

The answer is when we can leverage off on these benefits and when the losses it comes up with do not significantly affect what you want to do.

Think!

• Is what you are coding something that can be extended?
• How likely is it to be extended?
  
• If I coded this in a non-OO way, will this be shorter, faster? will it result in me doing a whole bunch of copy-pastes?
• What is the scope of what I am coding...in the sense where is this going to run, who is going to use it, how many people, what is the environment? Given the scope...does it make sense for me to invest the time (and other resources?) to make this OO?

I hope this post is more definitive and helpful. Anything is useful when it is used at the right place. Sometimes, it is not easy to find the right place, but thinking about what we do, rather than just doing it would help. Same is the case with OOP.

Labels: OOP, programming

I wanted to create an address-book/contact-management type app in PHP yesterday. I started off with a Contact class (which is based off of the contact table) and typed up the private members, then wrote the get and set accessors.

Now, I had to focus on other things that make the class usable - CRUD (Creation, Read, Update and Deletion of records). I coded the constructor, which would take care of the creation; after an instance is selected, the get accessors can be used to do the reading - but a function for instance selection was needed - I coded this as getContactById where id is the unique key; I also needed functions for multi-record (subset) selection; updates would be taken care by the set Accessors; I coded a deletion function deleteById ... at this point, I got really frustrated! Thinking about it, the task I want to do is something really simple, but the amount of work/coding I was doing was disproportionately large.

I was very sure I could have coded the whole thing using procedural programming much faster. I felt very confused for an instant, this whole idea of object oriented programming did not make sense! of course, object oriented programming aligns more naturally with the way we think and all, but the amount of work was unacceptable!

Deep Breadth....Sigh....

Ok...ok...so what went wrong? and where? Doing some introspection and reading on the basics of OOP, I realized, I got carried away in my amazement of object oriented, the "clean"ness, the coolness...the ideas and concepts (like design patterns etc)...and what it made possible.

Here is what I have concluded, OOP is not a swiss army knife, its rather a complex instrument - something like a drill machine. Its powerful, it can do a lot of thing, but it is heavy and needs electricity.

Say I needed to screw one screw in, if I insisted and forced my self to use a drill machine each time, I end up doing a lot of work...when it was not necessary. I might have as well used a screw driver...and saved my energy and some power...and get the job done faster. On the other hand, if I am working on making a model of something which requires a lot of drilling, the drill machine would make more sense.

Simple, I know! But sometimes we just carried away, that we forget the simple things. We forget to think before we act, since we have trained to look at something/and act on it in a specific way.

Moral: Before attacking a problem, clear your mind, keep your mind open, think out your options and figure our what makes sense? what is the best way to do it? Do not blindly follow a general approach!

Labels: OOP, programming, thoughts