“The best code only comes from a good design” — Gabriel Gonzalez ’s Weblog
Through this past year I haven’t post anything on this blog, why? I have been working hard in a really innovative and cool tool with a friend and finally we are about to release a beta the February 12th.
This application belongs, as one can think, to the security world and I hope it will make the life of a bunch easier. I am not gonna reveal anything till the release date so keep tunned!
Not enough time to keep this blog up to dates with articles and stuff. But soon I will be presenting a really nice and innovative tool which is gonna make our life better. See you soon
When building distributed application sometimes you need to use some kind of protocol to allow your parts to communicate each other. In the simple example I have been using for a while where you have an embedded client asking to a centralized server for new firmware updates, you have to establish a way to log into the server and ask for the next available version you can upgrade.
Along with the Class and sequence diagrams you have to use the State Machine diagrams or Protocol State Machine diagrams. The main difference is in the second one you do not need to specify embedded states.
I will write a longer post with some diagrams and nifty stuff 
I wish all the anonymous and known readers of this blog the best for the 2007 and following years. I hope through this year we can keep improving the world contributing to keep the information free as it should be.
All the best!
When building an infrastructure which require some kind of controlled extensibility one of the most common approaches is to consider a plug-in system. But how should it be considered in the requirements and design?
The best approach seems to be specify and close the interface with the plug-in subsystem in the main system and afterwards develop each new subsystem independently.
The bad point of this procedure is that it can lead of loads of documentation since you need requirements and design documentation for each new plug-in.
The good point is that the system is completely isolated by analysis, and obviously design, of each subsystem which increase cohesion and encapsulation, decrease coupling and produce a cleaner product.
When designing a new application you usually have in mind a big picture of the future application and maybe you know a given system should be decomposed as the client / server models dictates.
But when in the analysis this factor comes important? In which part of the document should you split the server and client functionalities?
I am not really sure what would be the best approach to solve this problem, for sure it depends on what the client wants you to design but what if other client is not that sure?
For the first kind of client I came across with a simple solution, just include the client/server model as a design constraint and go on with the analysis.
If instead of the client it’s you who finds out that the client/server model is the best one which fits the system architecture I think you shouldn’t consider the client/server model till the design stage.
I have just published a new paper under the “Good Coding Practices” section, which I think can be useful for someone else.
In this article I classify the bugs depending where in the life cycle of development they can be produced. This would be helpful to reduce the bugs which can be produced in the softwae development and will help if any bug appears since we know, just with its behaviour, where in the life cycle was produce. Therefore we will be able to react sooner and fix it in less time.
This is the base of comming papers about building secure software systems from a software engineering point of view.
Besied the PDF and HTML versions I always provide this time I have the Google version as well.
This is quick review of the article written by Martin Fowler about Continuous Integration, which basically explains that you should use a control version system and commit and build every day.
I only find, the advice regarding the periodicity of the commits and builds, not right at all since I think it would much better building a few times a day rather than a build per commit.
So I propose a fixed building times spread over the working hours which, as I explain in the paper, leads to an improvement of the productivity while keeps the developers happy, which I think is a must for all the project managers.
You can find the article in the Good Coding Practices section or get the pdf just here.
UPDATE: HTML version available!
Hi there, here is my very first Audio Show called “NITS” (Nothing Interesting To Say). Apologizes for my very bad speaking English but I haven’t been able to improve it as much as the written one.
The goal of this show is chat with someone about the computer related stuff I am working on, maybe I haven’t done my best this first time but I will keep on improving so stay tuned for the second show!
This I have talked:
- Aspect Oriented Programming
- Generative Programming
- Bluetooth Projects
PS: I think I haven’t spoken very much about technical stuff just a few general ideas really so I will focus on it a little more 
After a while publishing nothing I have come with this “wee” post just to complain about my holidays! I came to Spain willing to have a nice rest, enjoying the sun shineing and stuff BUT I am stuck at my parent´s business!!
It is not bad at all since I chat with quite a few ppl and I enjoy that and I help my parents as well but I need to sleep 12h in a row and spend the rest of the day with my computer!
Well maybe be in a couple of weeks