Our final assignment for Introduction to Computer Science was to study the documentation of the VECAP project and give an advice to one of the parties involved based on our findings. In this project, three companies, namely The Dinkelland Research Institute for Rehabilitation, Virtual-Fit and ExercITe, work together to produce home training equipment that can send and receive information over the internet. Additionally, an online community aspect is added to keep the users motivated to do their exercises. Soon it became clear that communication between the parties is very bad, and because of this deadlines are missed and the project doesn't evolve as planned.
While this assignment isn't related with Computer Science at first glance, there are some lessons to be learned from it that also apply to Computer Science. Firstly, the principle of a "black box" is also seen in this project. For instance, one party has a trainer with a connection to the internet, and the other parties don't have to know how this works internally, they are only interested in what the input is (a user who trains, resulting in training data) and what the output is (training data via the internet). How this training data is acquired, for example, is not relevant to the other parties. Because of this, the party that manufactures the training equipment has to make sure the input and output are clearly defined for the other parties, since they won't know what is going on internally.
Secondly, it is extremely important to have proper communication between the parties involved in a project. If this is neglected, components are build that aren't compatible with each other. Not only internal communication is important, communication to the press and unions that represent the users is also essential. If you don't report anything about the progress of your project to the press they will come up with their own stories that often don't depict your product the way you want, and if you don't communicate with unions they will feel left out and as a result approach your product with care.
Thirdly, in Computer Science it is important to be able to grasp what exactly a company wants. Often specifications for products will not be complete, simply because certain requirements are deemed too obvious to mention or are forgotten. Building a product to these incomplete specifications will result in a product that seems fine to the creator but isn't acceptable to the company who requested it.
Showing posts with label Introduction to Computer Science. Show all posts
Showing posts with label Introduction to Computer Science. Show all posts
Tuesday, October 12, 2010
Sunday, September 19, 2010
The Little Man's Computer
On Thursday we learned about computers on the lowest (machine) level with Introduction to Computer Science. The lesson started with the assignment to name devices that are computers, and of course they are all around us. It turns out that 90% of all processors that are manufactured today end up in so call embedded devices, from washing machines to cars.
After this introduction we were told how programming code is handled by computers. There are three terms that are important to this process: Compilation, Interpretation and Emulation. With Compilation, so called higher level code (programming code that is easy to understand for humans) is first translated into machine code or low level code. When an application is executed, the machine instantly gets this low level code to work with. With Interpretation, on the other hand, applications are saved in high level code, and when they are executed, the high level code is translated to low level code on-the-fly. The advantage of using this method is that you don't have to compile the high level code for every different architecture you want to use it on, but you can just use one piece of high level code on all architectures, since it will be translated on the moment of execution, specifically for the architecture you use it on. When however Interpretation can not be used, for example, when the high level code is not available to you, you can use Emulation. An emulator translates from machine code suited to one (processor) architecture to machine code suited to a different architecture.
At the end of the lesson we got to try our hands at low level programming ourselves. Using the Little Man's Computer we had to program a couple of simple applications such as adding two numbers. For the last assignment we had to program an application that could divide one number by another number, and the result had to be split into two parts: the "whole" part and the fraction part. While this may sound easy enough, it proved to be quite difficult, because we could only add and subtract, and couldn't multiply or divide. By doing this assignment it became clear to us that using low level code is overly complex, and it is far more convenient to use a high level programming language.
After this introduction we were told how programming code is handled by computers. There are three terms that are important to this process: Compilation, Interpretation and Emulation. With Compilation, so called higher level code (programming code that is easy to understand for humans) is first translated into machine code or low level code. When an application is executed, the machine instantly gets this low level code to work with. With Interpretation, on the other hand, applications are saved in high level code, and when they are executed, the high level code is translated to low level code on-the-fly. The advantage of using this method is that you don't have to compile the high level code for every different architecture you want to use it on, but you can just use one piece of high level code on all architectures, since it will be translated on the moment of execution, specifically for the architecture you use it on. When however Interpretation can not be used, for example, when the high level code is not available to you, you can use Emulation. An emulator translates from machine code suited to one (processor) architecture to machine code suited to a different architecture.
At the end of the lesson we got to try our hands at low level programming ourselves. Using the Little Man's Computer we had to program a couple of simple applications such as adding two numbers. For the last assignment we had to program an application that could divide one number by another number, and the result had to be split into two parts: the "whole" part and the fraction part. While this may sound easy enough, it proved to be quite difficult, because we could only add and subtract, and couldn't multiply or divide. By doing this assignment it became clear to us that using low level code is overly complex, and it is far more convenient to use a high level programming language.
Wednesday, September 15, 2010
Move the cursor to the right...
I don't feel like explaining yet another Technodrama today, so I'm going to keep this post short.
Today we took our first look at Operating Systems with Introduction to Computer Science. We did this by acting out two Technodrama's.
In the first Technodrama, the actors were asked to move the cursor across the screen by moving the mouse. In the first take of the Technodrama we had a user, the cursor display and the mouse, but in the end we had established that the mouse needs a mouse driver to translate its movement into relative coordinates, which the cursor display can than use to position the cursor.
In the second Technodrama, the actors were asked to click the icon that had been selected in the first Technodrama. This assignment proved to be pretty difficult, as we couldn't agree on how this should happen. We ended up with a cursor display, a window manager, and the actual application that will launch when the icon has been clicked.
At the end of the lesson we had to break down both these Technodrama's in steps, telling which instrument performs what action in each process. You can see my version here.
Today we took our first look at Operating Systems with Introduction to Computer Science. We did this by acting out two Technodrama's.
In the first Technodrama, the actors were asked to move the cursor across the screen by moving the mouse. In the first take of the Technodrama we had a user, the cursor display and the mouse, but in the end we had established that the mouse needs a mouse driver to translate its movement into relative coordinates, which the cursor display can than use to position the cursor.
In the second Technodrama, the actors were asked to click the icon that had been selected in the first Technodrama. This assignment proved to be pretty difficult, as we couldn't agree on how this should happen. We ended up with a cursor display, a window manager, and the actual application that will launch when the icon has been clicked.
At the end of the lesson we had to break down both these Technodrama's in steps, telling which instrument performs what action in each process. You can see my version here.
Tuesday, September 14, 2010
Languages & Representations
On Friday (10-09-2010) we finished the subject "Languages" by learning about different web development languages. The most basic way of creating a webpage is by coding in HTML. When you want to have a more advanced layout, CSS can be used, a language specifically suited to webpage layout.
The problem with only coding in HTML or HTML+CSS is that the content on the page is the same for every user. When you want to display a different page for each user, you have to use PHP (or a similar language like ASP) to display content based on user input. A common use of PHP is a login system. The user has to provide his or her credentials, and somewhere in the PHP code a database server will be asked to look for a record with the matching user name and password. When this record exists, the user will be directed to a personal page, and when this record doesn't exist, the user will be asked to log in in again.
Web developers nowadays want more than just a static page though. To be able to update the page without refreshing, Javascript can be used. Due to the increased need for user provided content since Web 2.0, an extension had to be build on top of Javascript, which makes it possible to put data in a database or read data from a database without refreshing the page.
After "Languages" we discussed "Representations". Representations are a very important subject in Computer Science, because it affects file size, ease of use and accuracy. The examples that were provided for representations were JPG and GIF. Both are image formats, but they have a very different way of keeping file size reasonable. JPG uses macro blocks at the smallest level. In these blocks, the pixels only differ in brightness, and not in colour, which results in smaller files, because it isn't necessary to storage brightness and colour for each individual pixel. GIF does store brightness and colour for every pixel, but uses another trick to keep filesizes down: the palette of colours is limited to 256 colours. Although this results in small files, it also limits the file format in its use. A photo, for example, can't be properly displayed in the GIF format. When you only want to show a drawing with a limited amount of colours, however, GIF is a viable option.
We ended the lesson by looking at the representation of numbers, which is often binary in the digital domain.
The problem with only coding in HTML or HTML+CSS is that the content on the page is the same for every user. When you want to display a different page for each user, you have to use PHP (or a similar language like ASP) to display content based on user input. A common use of PHP is a login system. The user has to provide his or her credentials, and somewhere in the PHP code a database server will be asked to look for a record with the matching user name and password. When this record exists, the user will be directed to a personal page, and when this record doesn't exist, the user will be asked to log in in again.
Web developers nowadays want more than just a static page though. To be able to update the page without refreshing, Javascript can be used. Due to the increased need for user provided content since Web 2.0, an extension had to be build on top of Javascript, which makes it possible to put data in a database or read data from a database without refreshing the page.
After "Languages" we discussed "Representations". Representations are a very important subject in Computer Science, because it affects file size, ease of use and accuracy. The examples that were provided for representations were JPG and GIF. Both are image formats, but they have a very different way of keeping file size reasonable. JPG uses macro blocks at the smallest level. In these blocks, the pixels only differ in brightness, and not in colour, which results in smaller files, because it isn't necessary to storage brightness and colour for each individual pixel. GIF does store brightness and colour for every pixel, but uses another trick to keep filesizes down: the palette of colours is limited to 256 colours. Although this results in small files, it also limits the file format in its use. A photo, for example, can't be properly displayed in the GIF format. When you only want to show a drawing with a limited amount of colours, however, GIF is a viable option.
We ended the lesson by looking at the representation of numbers, which is often binary in the digital domain.
On sending "beer" and receiving "ber"
Let me preface this post by apologising for the fact that I haven't posted for quite some time. Let me try to make it up by posting four articles at once ;)
On Thursday (09-09-2010) we learned about the AB protocol. We did this by acting out a Technodrama again. Two people participated in the Technodrama: one of them was the sender, and the other one acted as the receiver. The sender had to send a message to the receiver, and this could only be done one letter at a time. The problem was that the medium they use to pass their messages is unreliable. This means that once in a while a message doesn't reach its destination. The only guarantee they had was that when you send an infinite number of messages, not all of them will be destroyed.
At the first attempt, the sender would just send all the letters to the receiver. Unfortunately, the unreliable medium made sure that a lot of messages didn't end up at the receiver, but were destroyed instead. To circumvent this problem, the sender just kept on sending the destroyed letters. In real network communication though, it is impossible to see which messages are lost on the way to the receiver, so the result of just sending all the letters to the receiver would be that the receiver might have some letters of the word, all of them, or end up with no letters at all.
At the second attempt, the sender put a number next to each letter she sent out. In this way the receiver would know that either she got all the letters that were send to her or that she missed some letters. When using this method there are two problems: first of all, you can't do something with the information that the receiver has not got all the letters. Moreover, the receiver has no way of telling that the word has ended. In other words, there is no way to tell the communication has ended.
Both these problems were solved in the final attempt. This time the sender would send a letter with a number, then wait for confirmation from the receiver for a certain time, and when this time has ended without confirmation, the sender would send the message again. At the end of the word the sender would send an “end mark”, signifying that the communication has ended.
In the second part of the lesson we discussed languages, mainly the difference between natural languages and formal languages. The most important difference between them is that in a natural language the meaning of the words are not strictly defined (one word can have multiple meanings), while in a formal language a word can have only one meaning. Another significant difference is that a natural language evolves because the community “owns” its definition, while the definition of a formal language is “owned” by one company, and as a result has little to no change in definition (of course new words can be added to formal languages, but the meaning of existing words are seldom changed).
At the end of the lesson we had to design a formal language, in groups of 4 or 5, with the purpose of describing how to draw buildings. All the groups that presented their ideas ended up with a system based on lines, their length and their direction. Our group ended up with a system of shapes, drawn in a size relative to the other shapes.
After four groups had presented their ideas, our teachers made clear that we could have designed a language that doesn't describe how to draw lines, or even shapes, but perhaps common elements in buildings (windows, roofs, doors) or maybe even complete buildings, which makes the language specifically suited to the task it must perform. This made clear to me that we hadn't paid attention to the sheet about designing a “proper” formal language, which contains the following points:
On Thursday (09-09-2010) we learned about the AB protocol. We did this by acting out a Technodrama again. Two people participated in the Technodrama: one of them was the sender, and the other one acted as the receiver. The sender had to send a message to the receiver, and this could only be done one letter at a time. The problem was that the medium they use to pass their messages is unreliable. This means that once in a while a message doesn't reach its destination. The only guarantee they had was that when you send an infinite number of messages, not all of them will be destroyed.
At the first attempt, the sender would just send all the letters to the receiver. Unfortunately, the unreliable medium made sure that a lot of messages didn't end up at the receiver, but were destroyed instead. To circumvent this problem, the sender just kept on sending the destroyed letters. In real network communication though, it is impossible to see which messages are lost on the way to the receiver, so the result of just sending all the letters to the receiver would be that the receiver might have some letters of the word, all of them, or end up with no letters at all.
At the second attempt, the sender put a number next to each letter she sent out. In this way the receiver would know that either she got all the letters that were send to her or that she missed some letters. When using this method there are two problems: first of all, you can't do something with the information that the receiver has not got all the letters. Moreover, the receiver has no way of telling that the word has ended. In other words, there is no way to tell the communication has ended.
Both these problems were solved in the final attempt. This time the sender would send a letter with a number, then wait for confirmation from the receiver for a certain time, and when this time has ended without confirmation, the sender would send the message again. At the end of the word the sender would send an “end mark”, signifying that the communication has ended.
In the second part of the lesson we discussed languages, mainly the difference between natural languages and formal languages. The most important difference between them is that in a natural language the meaning of the words are not strictly defined (one word can have multiple meanings), while in a formal language a word can have only one meaning. Another significant difference is that a natural language evolves because the community “owns” its definition, while the definition of a formal language is “owned” by one company, and as a result has little to no change in definition (of course new words can be added to formal languages, but the meaning of existing words are seldom changed).
At the end of the lesson we had to design a formal language, in groups of 4 or 5, with the purpose of describing how to draw buildings. All the groups that presented their ideas ended up with a system based on lines, their length and their direction. Our group ended up with a system of shapes, drawn in a size relative to the other shapes.
After four groups had presented their ideas, our teachers made clear that we could have designed a language that doesn't describe how to draw lines, or even shapes, but perhaps common elements in buildings (windows, roofs, doors) or maybe even complete buildings, which makes the language specifically suited to the task it must perform. This made clear to me that we hadn't paid attention to the sheet about designing a “proper” formal language, which contains the following points:
- understand the purpose
- understand the domain
- capture the essential concept
- identify the basic "compositional mechanisms"
- understand the users
Wednesday, September 8, 2010
Do you have some money for me?
Today we had Introduction to Computer Science. The subject for this lesson was Protocols. The lesson started with some examples of protocols, to make us understand what a protocol is and what its use is. This was demonstrated by an anecdote about the French Court, and by a scene from the "Family Guy".
After we had some idea of what a protocol is, some volunteers had to act in a Technodrama, with which we had to find out the protocol for withdrawing money. A Technodrama is a kind of mini-play in which technology that employs a protocol has a significant role. We start off with a protocol that left a lot to be desired, but by continuously interrupting the play, and offering suggestions for improvement, it became more and more refined. We ended up with a protocol that is more or less "the real thing". After this piece of interactive entertainment, we had to make a timeline on which we had to put every step in the protocol. The final assignment was to create a workflow taxonomy for cash withdrawal, using your timeline as a guidance. You can see my version on my wikipage.
The usage of a Technodrama to understand the protocol of cash withdrawal has really shown to me than if you want to understand how a certain protocol works, it is often more useful to act out the protocol, instead of writing it down on paper, as you will become aware of its problems much more quickly. It was also interesting to see that, with a little help, we were able to construct this protocol without actually knowing what problems can arise when withdrawing cash.
After we had some idea of what a protocol is, some volunteers had to act in a Technodrama, with which we had to find out the protocol for withdrawing money. A Technodrama is a kind of mini-play in which technology that employs a protocol has a significant role. We start off with a protocol that left a lot to be desired, but by continuously interrupting the play, and offering suggestions for improvement, it became more and more refined. We ended up with a protocol that is more or less "the real thing". After this piece of interactive entertainment, we had to make a timeline on which we had to put every step in the protocol. The final assignment was to create a workflow taxonomy for cash withdrawal, using your timeline as a guidance. You can see my version on my wikipage.
The usage of a Technodrama to understand the protocol of cash withdrawal has really shown to me than if you want to understand how a certain protocol works, it is often more useful to act out the protocol, instead of writing it down on paper, as you will become aware of its problems much more quickly. It was also interesting to see that, with a little help, we were able to construct this protocol without actually knowing what problems can arise when withdrawing cash.
Monday, September 6, 2010
Workflow Taxonomy
Due to a weekend that was packed with events I was not able to update my blog until today, so my apologies for that. Let me start with what we did this Friday for Introduction to Computer Science: we learned about "workflow taxonomy".
In a workflow taxonomy you break down a certain workflow in the following categories: order, recipe, recipe step, process, processing step, object, instrument and service (See the create wiki). You can use this to carefully study complex workflows.
First, we went trough the example step by step, so that we got a good grasp of what exactly a workflow taxonomy is. Secondly, we were asked to create our own workflow taxonomy for a different workflow, and we had to put those examples on the wiki afterwards. I made a workflow taxonomy for a cleaning company, as you can see here.
After a few of us had presented their own taxonomy workflow, we had to construct the workflow taxonomy for fetching a webpage with the whole class. I experienced that, while I have quite a good grasp of how this works, it is difficult to break the process down step by step for a workflow taxonomy, because you have to know the process inside-out and you also have to be aware of what the role of each component in the workflow is. Luckily, most of us participated enthusiastically, so we finished the taxonomy in no time, after which it was time for our weekend break!
In a workflow taxonomy you break down a certain workflow in the following categories: order, recipe, recipe step, process, processing step, object, instrument and service (See the create wiki). You can use this to carefully study complex workflows.
First, we went trough the example step by step, so that we got a good grasp of what exactly a workflow taxonomy is. Secondly, we were asked to create our own workflow taxonomy for a different workflow, and we had to put those examples on the wiki afterwards. I made a workflow taxonomy for a cleaning company, as you can see here.
After a few of us had presented their own taxonomy workflow, we had to construct the workflow taxonomy for fetching a webpage with the whole class. I experienced that, while I have quite a good grasp of how this works, it is difficult to break the process down step by step for a workflow taxonomy, because you have to know the process inside-out and you also have to be aware of what the role of each component in the workflow is. Luckily, most of us participated enthusiastically, so we finished the taxonomy in no time, after which it was time for our weekend break!
Thursday, September 2, 2010
The start to Introduction to Computer Science
Today we had 4 hours of Introduction to Computer Science. The lecture consisted of 3 parts: a part about networks, a part about in which ways the internet can be used and a part about the basics of the internet.
In the first part we have learned that networks, however different they may be from each other, always consist out of 2 things: nodes, which receive the product that is sent over the network, and the thing that is sent over the network. The nodes might be machines, companies or people, and the thing that is sent over the network might be information, goods or money.
In the second part it became apparent that the internet can be used in various ways, but most applications require a model with a server/database and a viewer. Web 2.0 added user interaction to this model, so the user is not only a passive viewer but actively contributes to the website he or she is viewing. Furthermore, we have seen more intuitive / more creative uses of the internet, such as the Internet Furby, a Furby doll which can be controlled via the internet.
Lastly we got a basic explanation about how the internet actually works. This was later demonstrated by a video from a German TV programme.
I found it intriguing and exciting to see how the internet can be used in a more user-centric and intuitive way and think we are now only scratching the surface of how internet can be used in a way that really feels natural.
In the first part we have learned that networks, however different they may be from each other, always consist out of 2 things: nodes, which receive the product that is sent over the network, and the thing that is sent over the network. The nodes might be machines, companies or people, and the thing that is sent over the network might be information, goods or money.
In the second part it became apparent that the internet can be used in various ways, but most applications require a model with a server/database and a viewer. Web 2.0 added user interaction to this model, so the user is not only a passive viewer but actively contributes to the website he or she is viewing. Furthermore, we have seen more intuitive / more creative uses of the internet, such as the Internet Furby, a Furby doll which can be controlled via the internet.
Lastly we got a basic explanation about how the internet actually works. This was later demonstrated by a video from a German TV programme.
I found it intriguing and exciting to see how the internet can be used in a more user-centric and intuitive way and think we are now only scratching the surface of how internet can be used in a way that really feels natural.
Wednesday, September 1, 2010
You can all go after you have created your wiki page...
Today the only course was Introduction to Computer Science. The lesson was more of an introduction to the course than the start of the actual course itself, though. We were first told what to expect of the course. The course aims to get students familiar with how a computer works. It starts at computer networks and goes gradually to gate level. This overview of computers is provided to give us a framework for when we start programming later on this year.
Our assignment for today was to create a wikipage with some information about yourself. Since this isn't a very hard task, I expected to get some more information about the course or the first lesson of the course after we had finished the assignment. Instead, the teacher told us that when you had finished your wikipage, you could leave. Some students weren't all that happy that they had come to the university just to create a wikipage, because some students haven't found a room yet and have to travel quite a while to get to the university.
Tomorrow we have 4 hours of Introduction to Computer Science, so I expect the actual course to start then.
Our assignment for today was to create a wikipage with some information about yourself. Since this isn't a very hard task, I expected to get some more information about the course or the first lesson of the course after we had finished the assignment. Instead, the teacher told us that when you had finished your wikipage, you could leave. Some students weren't all that happy that they had come to the university just to create a wikipage, because some students haven't found a room yet and have to travel quite a while to get to the university.
Tomorrow we have 4 hours of Introduction to Computer Science, so I expect the actual course to start then.
Subscribe to:
Posts (Atom)