I just finished pimping my windows xp. I basically just replaced my utheme.dll file with a special patch, enabling my xp to support themes.....especially vista.........lol
So men My windows is the bomb!!!
Thursday, May 31, 2007
Monday, May 28, 2007
Progress so far
Yesterday I was able to install ruby and rails with the one click installer.
It drove me nuts a bit cus the command line window i used didnt reflect the path changes ruby had made.
I wrote my first web application......I'm a bit impressed.
The Rails framework uses the MVC architecture. It creates a view, and controller.
Pretty cool.
Only downside was when I tried to install mysql and I kept getting
error 2003, cannot connect to mysql server onlocalhost.
This is 2007, so it should be error 2007......du--h.
Oh and I think I over used the DAS-2 supercomputer on my last assignment, so my pvm code began messing up. But im finished anyways.
Gotta do the second assignment, matrix operations in HPF......in a parallel way.
Ciao all!
It drove me nuts a bit cus the command line window i used didnt reflect the path changes ruby had made.
I wrote my first web application......I'm a bit impressed.
The Rails framework uses the MVC architecture. It creates a view, and controller.
Pretty cool.
Only downside was when I tried to install mysql and I kept getting
error 2003, cannot connect to mysql server onlocalhost.
This is 2007, so it should be error 2007......du--h.
Oh and I think I over used the DAS-2 supercomputer on my last assignment, so my pvm code began messing up. But im finished anyways.
Gotta do the second assignment, matrix operations in HPF......in a parallel way.
Ciao all!
Wednesday, May 23, 2007
My dive into Ruby
Right now I am exhausted. I just got back from a meeting with my presentation partner about Mpeg-4 motion detection algorithms and their hardware architectures.
I needed something to learn that was interesting and not part of "normal " schoolwork.
Well I have been thinking of learning either perl, python , or ruby.
I have chosen the latter, so Im going to start studying it from today, and see what its got to offer.
I was just tempted by this lovely book called "the ruby way" by Hal Fulton.
I will have to sign out now............Lets see what ruby and the gym have got to offer me.
I needed something to learn that was interesting and not part of "normal " schoolwork.
Well I have been thinking of learning either perl, python , or ruby.
I have chosen the latter, so Im going to start studying it from today, and see what its got to offer.
I was just tempted by this lovely book called "the ruby way" by Hal Fulton.
I will have to sign out now............Lets see what ruby and the gym have got to offer me.
Tuesday, May 22, 2007
Assignment feedback
I just got feedback from a C++ assignment that I did, and I sorta made a foolish mistake. This was the feedback I got from the student assistant:
Bank::Bank()
{
account_list = AccountList();
// What is happening here is that first the default constructor is called, because
// no explicit call is made beforehand. Then you OVERWRITE the already created
// AccountList with a temporary new one (which happens to be idential).
}
Yeah I know.......I had another class called AccountList that initialized itself automatically when i called the Bank() constructor, simply by virtue of the fact that I had an AccountList object in my private variable section.
Now doing it the way I did would me result in creating the AccountList object twice and then rewiting the original value.....with the same results. Well, we get the same answer, but its not good to screw around creating redundant objects.
And the second student assistant, advised me to do it the way I did it, oh well, we learn everyday.
Bank::Bank()
{
account_list = AccountList();
// What is happening here is that first the default constructor is called, because
// no explicit call is made beforehand. Then you OVERWRITE the already created
// AccountList with a temporary new one (which happens to be idential).
}
Yeah I know.......I had another class called AccountList that initialized itself automatically when i called the Bank() constructor, simply by virtue of the fact that I had an AccountList object in my private variable section.
Now doing it the way I did would me result in creating the AccountList object twice and then rewiting the original value.....with the same results. Well, we get the same answer, but its not good to screw around creating redundant objects.
And the second student assistant, advised me to do it the way I did it, oh well, we learn everyday.
Architectural Mismatch
This is a paper review/reading log that I did for one of my specialization courses, SWARM(Software architecture recovery and modelling ).
The paper is about architectural erosion, and Its authored by Dave garlan,Robert Allen, and John Ockerbloom all of whom are from the Computer Science Dept of Carnegie mellon university, a school I respect.
The paper is just about how the assumptions we make about software components, affect the way they connect/fit to each other when we are trying to use them in building a large software system.
So below are the contents of my reading log, enjoy.......oh strange user.
Note: In every paper we read, we are meant to look into the feasibility of applying the technique to a "real-life" case study, in this case the migration of a monolithic blob of software for a television , to a linux platform....
Reading log for "Architectural mismatch" paper
----------------------------------------------
The authors main points:
-----------------------
The author points out that in software engineering, most people expect that in order to build a software system,
we should do so from building blocks. But the error in that is that most components are built based on assumptions about
the environement in which they will operate. These cause issues in the way the components fit together, and is known as
architectural mismatch.
The author goes on to highlight the main causes of architectural mismatch as follows:
1.Assumptions about the nature of the components
2.Assumptions about the nature of the connectors
3.Assumptions about the global architectural structure
4.Assumptions about the construction process.
The author suggests that careful consideration should go into building components that are intended to be used for
larger systems, but in my opinion, that is difficult to predict.
The author states four necessary aspects neccessary for a long-term solution
1. Make architectural assumptions explicit
2. Construct large pieces of software using orthogonal sub-components
3. Provide techniques for bridling mismatches
4. Developing sources of design guidance
Points I agree with
-------------------
1. I agree with the authors statement of causes of architectural erosion
2. I agree that ideally, when building components, they should be built with a view to being integrated
into a larger system
3 I also agree with the authors aspects for long term solutions to architectural mismatch.
Points I disagree with
----------------------
It isnt possible to predict which component would be used as a building block for a larger system.
I would imagine that building them the way the author suggests might lead to making the component very generic,
and as a result, eroding some of the functionality of the component.
Application to TV case
----------------------
Since the paper deals with systems built from components, and the tv case is simply one of migration to a new system and
doing some stripping down of the monolithic blob to the bare essentials, I have my doubts as to the
applicability of this to our case. The only thing i can think of is that maybe when we might decide to add extra functionality to the
ported system (in terms of new functional requirements), that we take the warning (about architectural erosion) into consideration.
The paper is about architectural erosion, and Its authored by Dave garlan,Robert Allen, and John Ockerbloom all of whom are from the Computer Science Dept of Carnegie mellon university, a school I respect.
The paper is just about how the assumptions we make about software components, affect the way they connect/fit to each other when we are trying to use them in building a large software system.
So below are the contents of my reading log, enjoy.......oh strange user.
Note: In every paper we read, we are meant to look into the feasibility of applying the technique to a "real-life" case study, in this case the migration of a monolithic blob of software for a television , to a linux platform....
Reading log for "Architectural mismatch" paper
----------------------------------------------
The authors main points:
-----------------------
The author points out that in software engineering, most people expect that in order to build a software system,
we should do so from building blocks. But the error in that is that most components are built based on assumptions about
the environement in which they will operate. These cause issues in the way the components fit together, and is known as
architectural mismatch.
The author goes on to highlight the main causes of architectural mismatch as follows:
1.Assumptions about the nature of the components
2.Assumptions about the nature of the connectors
3.Assumptions about the global architectural structure
4.Assumptions about the construction process.
The author suggests that careful consideration should go into building components that are intended to be used for
larger systems, but in my opinion, that is difficult to predict.
The author states four necessary aspects neccessary for a long-term solution
1. Make architectural assumptions explicit
2. Construct large pieces of software using orthogonal sub-components
3. Provide techniques for bridling mismatches
4. Developing sources of design guidance
Points I agree with
-------------------
1. I agree with the authors statement of causes of architectural erosion
2. I agree that ideally, when building components, they should be built with a view to being integrated
into a larger system
3 I also agree with the authors aspects for long term solutions to architectural mismatch.
Points I disagree with
----------------------
It isnt possible to predict which component would be used as a building block for a larger system.
I would imagine that building them the way the author suggests might lead to making the component very generic,
and as a result, eroding some of the functionality of the component.
Application to TV case
----------------------
Since the paper deals with systems built from components, and the tv case is simply one of migration to a new system and
doing some stripping down of the monolithic blob to the bare essentials, I have my doubts as to the
applicability of this to our case. The only thing i can think of is that maybe when we might decide to add extra functionality to the
ported system (in terms of new functional requirements), that we take the warning (about architectural erosion) into consideration.
Monday, May 21, 2007
Introduction
My dreams can be summarized as follows:
1. Give something back to the world of computing
2. Become awesomely stinkingly rich by doing number 1
This blog is born out of goal number 1. Here I aim to chronicle my thoughts about computing
programming and related stuff in general. I will blog about technical challenges in school, my personal opinions about new tecnology and all..........and my ideas in general.
I will also offer my own humble opinions about any IT related articles and journals I read during the week.
What do I do? Im into programming, and computing in general, both theoretical and practical.. and yeah....you guessed it, im a geek. I code in the following languages:
Java
C/C++
Assembly
pvm (Parallel programming)
and weird stuff that people dont like talking about. I'm currently pursuing my masters degree in computer engineering at the Delft University of Technology, the Netherlands.
I also muck around with linux a bit, even though when Im lazy (which is most times) I just use cygwin to carry out unix related projects.
Well enough about me, Lets get this party started.
1. Give something back to the world of computing
2. Become awesomely stinkingly rich by doing number 1
This blog is born out of goal number 1. Here I aim to chronicle my thoughts about computing
programming and related stuff in general. I will blog about technical challenges in school, my personal opinions about new tecnology and all..........and my ideas in general.
I will also offer my own humble opinions about any IT related articles and journals I read during the week.
What do I do? Im into programming, and computing in general, both theoretical and practical.. and yeah....you guessed it, im a geek. I code in the following languages:
Java
C/C++
Assembly
pvm (Parallel programming)
and weird stuff that people dont like talking about. I'm currently pursuing my masters degree in computer engineering at the Delft University of Technology, the Netherlands.
I also muck around with linux a bit, even though when Im lazy (which is most times) I just use cygwin to carry out unix related projects.
Well enough about me, Lets get this party started.
Subscribe to:
Comments (Atom)