AFTER ENTER - Episode 2 - Pressing!Created on 20151120
The story so far:
Hi again. Last time we spoke about what happens before a search engine like Google has to accomplish before doing a search through billions of documents that make the Internet. Today we are starting our journey by doing a real search.
Our particular search will be the age old question that every child asks and every adult is ashamed to not know the answer:
Why is the sky blue?
How many ways can you think of doing that search? If you are on a phone or have a smartwatch you can say “OK Google, (hear a small bleep) why is the sky blue?”. Or you can tap on your home screen box and type with the keyboard that appears on the screen. If you are at home and have a laptop on your… well, lap… you could type on your keyboard.
So which one was it for you? This interaction is called interfacing. The word interface is used frequently and interchangeably but basically it means what are the ways to communicate from one thing to another. If you used your laptop keyboard, that was an interface. Inter meaning between and face - ummm … face? On the other hand the keyboard interfaced with the computer via some internal cables, the laptop interfaces with the internet via WiFi, cable or mobile network and so on.
Okay so you typed it and pressed enter or said it and are now waiting. Well you don't wait for too long because the response comes almost instantly. But the story is incredible! Listen…
Let's assume you pressed enter and we slow down time a LOT. So much that a blink of an eye will take the next 10 episodes. That's long…
All right, here we go!
Let’s look around, what is happening. A keyboard consists of electrical switches in a similar way a lamp switch is made.
Now, see that switch. The two cables have electrons which stay relatively static. (Well, that's a lie, they move all the time buzzing randomly like flies.) Why do they buzz randomly? They are excited but they don't feel strongly to move one way or another. There is no direction in their life. It's like when you are in a big pool and you have more than enough energy to enjoy swimming but with no particular direction. Where is that energy coming from? The loud Big bang. Now, concentrate!
Once we press the button, closing the switch the electrons start feeling a force. It's like a wind starts blowing in one direction and they slowly obey. They still are kind of randomly moving, but randomly with direction.
While our finger is still on the keyboard, the electrons start flowing in one direction. Where is that force actually coming from? Your finger? Not exactly. When you turn on your lamp, your finger just opens the gates for power to go. Now how does your computer know that?
Well, your keyboard is actually not just these two wires connecting the enter. There are many more connecting each key. But if there was one cable connecting each key, that will be a lot of cables! Your keyboard will be big and bulky.
No, let's not do that. Let's organize the cables in a matrix. Now in this case a matrix is a fancy way to say that cables form grids on two layers. If you have an old keyboard connected to a desktop computer, I would disassemble it and see what's inside. It's pretty cool! You’ll see two thin plastic sheets with some very thin paths made of some metal separated by a third layer with holes… it's like a sandwich with emmental cheese, mmm..
So when you press the button you connect the two pieces of bread of this sandwich through the cheese which lets these electrons flow.
Now the keyboard has small computer itself called a controller. What it does is checks every thousandth of a second or so which two metal pieces of the two grids made contact if any. If any of them did, the controller records that in a memory of its own called the endpoint.
And then it waits. Remember, we slowed down time a lot. The controller checks every thousandth of a second just to be sure but there is no typewriter in the world that is that fast.
Turns out the the fastest of the fastest types about 200 words per minute which is about 1000 characters per minute equating to merely 15 keystrokes per second. I said merely because from our standpoint that's eternity. In real time, that's pretty impressive!
This is of course in the case of a real, solid keyboard. What if it was one on your smartphone?
Well, it’s pretty similar, just your finger acts as a connector between the two components. Don’t worry, these electrons are actually pretty tiny and won’t hurt you.
Anyway, the information about the press got to the keyboard controller. And the keyboard controller waits. For what? Remember we slowed down time. The keyboard controller queries for keypresses thousands of times per second but the computer queries the keyboard much less often. There are two ways computer stuff communicate - they either push or they pull. Let’s say our keyboard controller waits for a pull from the computer. If it was more pushy type, it would flush down what it gathered down the line for the computer to collect and not wait at all.
Why the two ways?. Well, the brain of any computer, called the Central Processing Unit or CPU is a very important and busy boss. It allows you to listen to music while you type, move your mouse, browse the Internet and many other tasks.
Now she can either order that some of her workers go and fetch things in which case the workers go, pull and then queue or if the keyboard pushes a message, the keyboard worker queues. This queue exists so that you can do many things seemingly at the same time. What actually happens is that the boss reads messages really quickly and passes messages around the workers.
It depends on many factors whether the communication will be push or pull. Some interfaces like USB wait for pull from the computer, other push. In the end, the messages always end up in the queue for the boss.
All right. So a worker goes to the keyboard controller endpoint and asks: “Do you have anything new for me?” to which the keyboard controller answers: “Yes, indeed I do. Here is what I gathered in the last 10ms” and passes the code for Enter.
This is very cute and all but it’s not really what happens. See, there are no small humans inside your machine. There are just wires and electrons. What I just pictured above is a model of how it works because you, reader, are probably a human and humans speak abstractions. The real language that the keyboard controller communicates with the computer speak is not really English. It’s called binary.
Binary is the language that comprises of two letters - 0 and 1. Zero means no (or very weak) signal, one means (stronger) signal. The controller actually sends these signals in a specific variation in order to encode the message that the key was pressed down the wire to the cable connecting via the computer interface.
You press a button on a physical or virtual keyboard which is the interface to your machine. A physical keyboard has a matrix or a grid of electrical conductors separated by a layer of electrical insulator like a sandwich with emmental cheese. By pressing the button you let some small amount of electrons move around. The keyboard controller reads the matrix about a thousand times a second to check for changes, saving the change in a memory location called the endpoint. Now it can either push this data down the cable to the computer or wait to be pulled. Computers communicate in a language called binary which uses only zeros and ones as letters.
So far we know what has to happen before a search occurs and what happens when you press a button of a keyboard. The information about your query has just started - 10 milliseconds into the trip only your keyboard knows that you have asked something. The journey continues next time as we follow the information flowing into your computer and what happens there.
Summary entry IICreated on 20140327
If the first semester was balanced and happy with occasional hiccups, the second semester was quite a different story. Courses like Operating Systems, Network Systems and Databases were much more demanding both in theoretical knowledge and assignments. I enjoyed them and now I can say I get these areas much deeper thanks to both the material in the lectures and the assignments which also helped me solidify my knowledge in C. It was interesting (from an academic practice point) to build a web server, chat program and disk driver even though not many of us will have to do this in the future. However, it definitely made me get a better understanding of some of the inner processes. On the other hand, optimising database queries can actually be applied to the real world and I am happy we did that.
In addition to that, the team project had reached a phase beyond just mocks and requirements capture and implementation work needed to be done.
Another semester long project was the Distributed Information Management assignment which required building a website from scratch using Django web development framework. This was not interesting or valuable for me as I already knew how to do all of that and therefore tried to encourage the other people from my team to spend a bit more time on it and I would help filling in whatever parts were unclear. In the end, we had a working application but it was a result of mainly my work and one of the team members didn’t participate at all whatsoever.
Contribution and Achievements
On the PSD front, unfortunately, I can’t say what stayed in my head except constant frustration with the setting up of frameworks. As I said several times in this blog, a framework cannot be taught in a week. Getting the “taste” of it clearly didn’t work for me as I couldn’t see the practical application. If PSD was the only subject that I had to concentrate on, surely, I would be able to practice AspectJ, JBehave, Jenkins, OSGi, Apache Felix, Ant and Ivy. However, next to the other subjects, I had maximum of one day in the week to actually try to do that. It didn’t work.
The assignments (bi-weekly sprints) were implemented with the limited understanding that we got from the frameworks. As it was mentioned the more important part had to be team work. So I decided that I shouldn’t concentrate that much on the technicalities but try to separate the workload between the people. And here we get to the second part of this summary.
I suppose I had constant negative criticism of the PSD course, which I hope is obvious in my previous posts, student-staff meeting (in which I tried to summarize the general feeling, not only mine, but the whole class) and in the feedback for the third year. Basically it boils down to 1) Too many frameworks 2) Artificial assignments and 3) Too much assuming that everyone will work for a company, rather than venturing something of our own. Even with all these complaints, that would be mostly irrelevant had the teams been better balanced.
If I could genuinely separate the workload of the course to the other team members in roughly equal parts, the assignments would be much more doable and enjoyable. However what I noticed not only in my team, but in many others is the fact that one or two of the people were doing the majority of the work with the other two doing nothing to very little amount of work. My working hypothesis is that the pseudo-random algorithm of separating people in teams was “two with above average marks + two with below average marks” in order to equalize it. Let’s assume that this was indeed the case.
What this easily leads to is demoralizing the people with lower grades (as they quickly can see that they can’t keep up) while at the same time annoying the people with the higher grades and effectively making them do all the work. This leads to a positive feedback loop in which the described effects are amplified during the year. Additionally people with the higher grades have (usually) always been above the average and thus want to have the good grades at the end of this year as well. Same for the people with the lower grades - they are used to not showing the maximum and thus don’t care about it so much.
Of course the deltas are supposed to solve the problem with the grades. However this doesn’t help much with the total less acquisition of knowledge and practice in the average case as the feeling of doing all the work feels unfair through the year.
If this way of combining people in the team is in fact true, then this needs to be rethought for next years. I would vote for stricter exams at the end of 2nd year and combining people based on roughly equal ability rather than trying to compensate for the slow learners. Slow learners will always be that way, smart learners can’t teach them what they couldn’t acquire in 20 years of their lives!
Lastly, I would like to seriously criticize the argument that “This is how teams work in the real world”. First, people who don’t do work will be fired. I have seen and heard about people who have done absolutely 0 work (no group meetings participations, 0 lines of code for any of the team projects, constant deferring and not taking responsibility for work etc.). These people would be fired in the “real world”. Second, in many tech companies you can get some choice of the people in the team (this is not 1980s!) and if something doesn’t work, there are mechanisms to raise this issue. In the University, there is no such mechanism.
The things that I actually found useful in this second part of the course is the components idea and continuous integration idea. The components does provide a good separation if implemented correctly and people can (in theory) work on different parts of the system and then combine it to result in a big, cohesive system. The continuous integration is another thing that I enjoyed - fully automate everything. One of the teammates actually is part-time working and helped me understand and showed me some useful tricks. Unfortunately I didn’t have time to practice these correctly, but rather hack working solutions for the assignments.
Lastly, talking about hacking, I also got to know that nothing of this matters as long as you can talk convincingly and give your ideas to the right people. This can win you a £20,000 hackathon while doing all the other things wrong. It's a great story and if you would like to read more about it, I would recommend reading my real blog.
And finally, out of all models that we learnt this year, I found this one the most useful:
Week XXCreated on 20140327
As I said in the previous week post, OCL is great. Here is how I imagine my first meeting in a bank (that I will definately go to work for):
Did you know that the site http://omg.org is actually relevant to the topic? I mean, OMG... Is Object Management Group! OMG! So these guys are doing a good job creating formal language for development. Here is what I definately read:
Actually for a whole week now, when I message my buddies, I do it like this:
context Message: inv type=Individual let message="Hello John" pre: open(facebook) post: press(Enter)
See, I am into it! Discussing, linking, appraising and critisising. I love my blog!!!
Week 90nCreated on 20140311
Formal Methods in Software Engineering. From what I got from the lecture, this is a mathematical way to describe requirements and the process of developing software.
Here are some links that completely taught me about formal methods:
Of course, that's next to the brilliant lecture slides and note materials. [TODO: Pile of bricks]
This can be useful in safety critical systems and security systems. We were introduced to the idea of the Object Constraint Language. I was left with the impression that the proves can be so hard and tricky, generated from a computer, that it's hard to understand it as a human. However software tools are really not mature enough to work with. Therefore it's a good idea, but without much practical applications.
Other good ideas without much practical applications:
Did we pass the phase where we were learning useless stuff for some practical application (like learning how to be semi-interested in a manager meeting) and went into the learning useless stuff for no practical reason?
How I would do things differently is spend some energy into teaching us how to become our own bosses. The idea goes like this: if banks (for example) wants us to know these stuff but everyone is complaining, then get rid of the banks and you'll get rid of complaining students. Just saying.
Week Adult (in most European countries)Created on 20140304
We did state machine diagrams in year 2, computer systems course. We dealt with finite state machines and explored their properties in semester 1 in Algorithmics 3. (Personal background experience noted) But until now, we had no idea how do draw state machine diagrams.
So now we know! Here are some links to support my thesis:
The second part of the lecture - Threads! We did that too in Advanced programming 3, semester 1. With the second assessed excersise being on Java threads. And refreshed it in Networking Systems, semester 2. And the assessed excercise in NS was with C Threads. And the OS assessed excersise requires knowledge of C Threads (with tutorial refreshing the concepts).
But I think it's the first time that we see a UML state diagram.
Here are some links to support what I am saying:
I know the repetition is the mother of learning but I would argue with that. If I repeat a 1000 times the expression "Hello world" to a dog, it will not be able to learn it how to do it himself, although it would react somehow the next time I mention it. The doing of the assessed excersices help in the different courses but introducing us to threads once we have done it for a year... Maybe as well, who am I to judje?
How would I do things differently? Spend some time making the courses more coherent. (A constructive suggestion.)
Appraisal: I liked that the lecture was moved to 10 o'clock. I am surprised how suddenly the room was made available for us one hour later on Monday. Many questions will remain unanswered though: who was occupuing the room at that time all year? What happened to them? Is the University haunted by aliens?