Blog
Why unit tests are cool
Posted on 10/03/09 10:52:08. 0 comments.
Open source and govermental funding
Posted on 04/12/09 21:49:09. 0 comments.
I've been recently thinking should Midgard project after it's transformation to a fundation apply for some govermental (TEKES) funding or something else from EU level.
Currently Midgard is developed with normal work (testing and stomping mines) or with my spare time (weekend hacking sessions) from my part. But in the big picture lot's of developement is funded by companies that are really and only using Midgard for their living.
R&D costs are considerable and I think that there should be some funding programs that coming Midgard Foundation can apply financing from. Commercial products do it shouldn't we also?
List of projects funded by tekes (in finnish)
New year comes with big changes
Posted on 02/07/09 20:37:56. 0 comments.
It has been a while since my last post. Mainly because great stress at school and my personal life. It has also been very interesting beginning of a new year. I bought my very own apartment and the company that I'm partner in bought majority of another company. That means that lots of new technology knowledge must be absorbed as quickly as possible.
Good thing is that it broadens up a perspective about how to make different kind of web services for consumers. That knowledge comes through all layers from the very top to the very bottom of the code itself. I've encountered some innovative solutions as well as the problems that will be encountered when the amount of data and traffic goes to another level.
Year 2009 means lots for the midgard itself. New Vinland (Midgard 2.0) will be released. The possibility to use Midgard as content repository of your application has became a reality. It's quite easy to do midgard + python + guid application that you can replicate to net. Also new codebase gives possibility to make enhancements to Midgard Core itself to make it very versatile tool for developers. But most importantly, new Core gives possibility to rethink some design rationales behind all. As far as I know when data storage grows and it's usage intensifies rules change at the very level of data storage and abstraction. How Midgard scales to this? By the developer meeting at Linkköping I'll try to find out.
Many aspects of testing
Posted on 12/21/08 21:39:35. 0 comments.
Christmas is almost here but there's still yet another exam ahead. This time it's about testing and quality assurance of software. The fact is that it can be done with quite workfull way. For example we had a exercise where we had to test a java program with black box methodology. When doing it properly it takes quite an effort.
But now when the sanity points and mental energy is almost gone after several exams there must be something wrong when reading dry text and I start laughing when stumbled following: "Soap-opera testing"
Luckily christmas vacation is only two days away.
Caching thoughts
Posted on 11/22/08 13:09:13. 0 comments.
I've previously written something about caching and it complexity. A short while ago I've heard from Bergie about interesting facts about memcache and also been bitten by it first hand.
It seems that with bigger sites with current MidCOM caching philosophy and level of atomicity are getting more heavier than just serving pages without any cache. It seems that if Memcached is heavily punished and if there's lots of keys in it it start so slow down and also reliability goes down. Basically it means that you don't always get data from cache or be able to store it in there resulting some database punishment and you can imagine what happens next.
This comes again to MidCOM 3 and the way caching should be handled there. I've taken a close look about how Zend Framework does it. They are useing tags as possible cache identifiers. Basically MidCOM's cache works quite same way but in fact every cache entry get's autotagged by lots of guids. So that is basically the problem.
One possible solution that I've pondered would be to give developer some additional tools to control caching in controllers. There could be some hint's for cache's level like if it's same for all users or per user basis. This helps caching to be done more intelligent way
But in addition to this there should be a concept for cache invalidation logic. In some cases you need more atomicity than others and the problem was with too big guid indexes. What if developer has in addition to tagging possibility to attach some callbacks to tags. Basically it means that you have possibility to call cache invalidation per tag but then those callbacks could do some logic whether or not tag entry really needs to be invalidated.
That would enable us to diminish the size of guid cache, put some intelligent invalidation where needed. Bit heavier process it is but if it's lighter than getting data and rendering it, then it's worth to explore.
