Journal 1: What's your itch, with respect to technology? What kinds of problems are you interested in solving? The area of technology that I am most interested in is security. This includes, but not limited to information technology security. When I say not limited to, for example if I open a company that does black box penetration tests for its clients, this might include anything from firewalls to mushroom locks, every type of security, where to place the security guards or whether sonar or infra-red alarm system to place. When we use the term security, this includes everything from software to hardware, telephones to education of employees against social engineering. I am interested in solving problems related to security systems and in finding ways to harden them against possible attacks. Journal 2: a) What is your favorite programming language, and why? I like C++ and this has many acceptable reasons. First of all, I have had a year-long education on this language and it feels pretty much easier than any other language as I am so much used to it. Another reason is, I have also had an education of Visual Basic, however, although Visual Basic makes using some built-in functions, standard applications and user interfaces much easier to create, it limits the programmer dramatically at times. For example, it might be much easier to create a three-way handshake and connection (all you do is winsock.connect()), on the other hand it is much harder to send one tcp syn packet with a specific characteristic. Similarly, it is much easier to create a database application based on Microsoft Access or Microsoft SQL, but it is much harder to write an efficient database application of your own. C++ is not excessively hard to use like assembler is, and still gives the programmer enough feeling of freedom. Moreover, if we want, it also allows us to throw a few commands of assembler, which practically leaves no limit. b) When and how has coding style most benefited (or hurt) your software engineering experiences? Until I was in high school, whenever I wrote programs I would not really use any comments. The problem was, if I stopped writing a program and did not write for a few weeks, it was generally forcing me to rewrite it. My high school computer science teacher, Mr. Marcos Texiera taught me how to write comments. This certainly helped. In CS128 and CS256 from Mr. James Rogers I learnt how to do more extensive commenting, such as variants, preconditions and postconditions, which made it even better. Now in software engineering class, we will hopefully be improving it to an even better point. c) How do you interpret clarity, simplicity, generality, and automation? With basic language, we can say that if I read it and I understand what it is doing, it is clear. If I read it and I understand how it is doing, it is simple. If I try to run it on some different system or if I try to place it into another piece of code and it works fine, it is general. If I do not need to give the same input ever again or as few times as possible, it is well-automated. Journal 3: A question about open source software. Does open source software provide enough security? As far as it seems, although open source software has more people working on it (from all the places in the world), there is the problem that also malicious people also have access to the code. One thing that is explained in many different texts about hacking is that black-box analysis is much harder than white-box analysis, and one of the first things to do when hacking a system is to find a copy of the same program and/or its source code. When the cracker does not have the source code, the attacks tend to be much noisier, as it depends on trial and mistake type of approach. When the cracker has a copy of the same program, s/he can just do the same blackbox testing and eventually find a bug in the program. When s/he has the source code, life becomes even easier. It is possible to run automatic tools that check for buffer-overflows, format string vulnerabilities, it is possible to test the functions individually, especially for input validation errors and it takes a much shorter time to find how big the buffers are and which libraries are used (as sometimes the library might have a bug, for example a randomizer might not be really very random). On the other hand, getting a copy of the commercial software, especially expensive software that include well-known operating systems such as Windows 2000 Server Family and many security tools, such as Checkpoint, becomes a problem for the cracker. Of course, it is impossible to say that it stops the cracker. There are many shareware versions and pirate versions of these systems around. However, making the cracker's task just a little bit harder is one more step towards security. It should be remembered that perfect security is not feasible and it is all about making the attacker's job a bit and some more harder. Journal 4: Bug Fix Secure rm is a removal utility that removes and overwrites a file in a loop, causing it to become certainly unretrievable. This is used against the scavangering attacks crackers are likely to use once they get access onto a system. The problem with this little command-line utility was that it was not closing a file that it was opening. The solution I have posted as a comment you can find by following this link: https://sourceforge.net/tracker/index.php?func=detail&aid=1001600&group_id=3297&atid=103297 Journal 5: TPOP chapter 4: The 3 most important principles in interfaces First of all, I think hiding information details is one of the most important principles. If the implementation details are not hidden from the rest of the program and the rest of the program skips the interface while using the program, first of all it might become nearly impossible to change some lower level implementation details without hurting the rest of the program. Secondly, the number of mistakes occurring from changing one value but not the other values depending on it might increase (under normal circumstances, the interface would change the value and the other dependant values automatically). Lastly, it might become nearly impossible to track the invariants. A program that seems to be doing something and is doing something else is a Trojan Horse! It is a very bad idea to "reach behind the user's back" and do not tell them what is really going on. The user should not be expecting something and facing something else. This could disturb the users badly and they might start to think that everything can be expected from your program. Not the best possible reputation for sure. When a person is learning a foreign language or chemistry, the exceptions to the rules are among the things that the students tend to complain about the most. Learning a rule happens once, but people have to learn once more and once more for the exceptions. This is easy neither for the programmer or the user. That's why we should do the same thing the same way everywhere. This way we can decrease the possibility of making mistakes because of exceptions. Journal 6: Test cases and revelant issues How many test cases are enough question depends on how dependable we want that application to be. We have to assess the risks thoroughly. For example, if I am using an old version of Linux at home and it has some bug that allows denial of service on my computer, this would hardly bother me. First of all, the possibility of someone actually trying to find and attack me is low, and even if someone randomly attacking everywhere attacks me, what is the worst thing that can happen? My computer will be rebooted, and as I do not really have much of an important information that I work on using my home computer, I might lose some basic information like the last e-mail I was writing. Hardly a problem. Moreover, I am on a dial-up connection, if the same guy wants to DoS me once more, it will be hard to find me again, as my IP address is dynamic and changing every time I connect. In the worst case that he does a number of searches and DoSses me every time I connect, then I might bother to download the patch for it. And I will not really bother to patch any more DoS bug, unless somebody else comes up with something similar. On the other hand, for a bank or military based organization, it is hard to say the same thing. Imagine what would happen if somebody kept DoSsing again and again the bank's computer. It would soon start to come close to going bankrupt and lose most of its reputation. It is even worse when we start to talk about the bank's whole system getting compromised. This may very easily end the bank up in a lot of trouble. For example somebody can download some huge sum of money into his account. Alternatively, in a hospital, imagine what can happen if the computer starts to have some strange problems in the middle of a heart operation, or what if someone gets too much radiation because of a bug. Certainly, how much debugging is enough depends on the scenario. However, as there is no such thing as total security, we have to talk about some probabilities at this point. In the beginning, when code is written, there might be lots of bugs. For example, a bug might be found every 2 hours by 5 programmers. However, as time passes debugging, it will soon start to get harder. For example 30% of the bugs might be found in the first week, 20% in the next week, and this number keeps decreasing. Eventually, it will come to a point that it will take 100 programmers a week to find the next bug. One example to this is the hacker challanges. If a machine is taking thousands of hackers for two weeks to get compromised, then we can say that it will probably take much more for one or a group of hackers to get into the system, as more eyes staring at the code means higher chances of finding the bug. So, if it will take probably about 6 months for this one hacker to possibly compromise the system, then we have to ask the questions, "how important is the data we have on our system? What can be the biggest loss?" Moreover, we also have to say, "how much this six months be affected with how much resources?" For example, because so much debugging is already done on the code, working 100 programmers on the code for a week more might be increasing that time for one hacker to find the next bug just a little more. Do we want to keep wasting money? Also how many people are there, that are willing to invest this much time to break into our system? For example, if it is my personal computer, I doubt if anybody would even give a day for it. On the other hand, on places like banks, there might be thousands of crackers trying to get into the system and they might continue to do that forever. This means that debugging also needs to continue forever. That is why, banks and military has a special group of personel such as security administrators and white-hat hackers that try to keep hardening the system by thousands of test cases every single day. How many of these people will be recruited depends on the budget. Journal 7: Portable programming I do not have any programming experience related to tool portability, however I will talk about some other experience. One thing today about the martial arts issue is that people are becoming more and more aware of the fact that most martial arts do not work in most real-life situations. This is not because they do not train hard, nor their technique do not work. This is due to the fact that the techniques are designed to work in some specific scenarios and in real-life that specific situation do not always occur. These techniques, especially the ones for using on the ring, assume that you are allowed to hit only specific places on the body, which give you points. These are generally the body, the head (with kick only in some arts) and depending on the art, sometimes legs. Moreover, there is all the protection you need on most competitions. Even more than that, you do not get into the competition when you are feeling the worst and your rival is at his best. Generally speaking, people choose not to enter the competition when they feel physically or emotionally bad. The techniques are designed to work in a situation where you can hit specific parts, you can be hit on specific parts, you will be mostly protected against injuries, there is no way for your rival to take out a knife in the middle of the competition, you are of similar weight, you feel at your best, etc. On the other hand, mostly we are attacked when we are feeling at our worst and unaware of the upcoming danger. After a long and tiring day at work, going back home, shaking from cold, all you think about is a warm cup of tea, and you will maybe just look at the television for half an hour, and sleep on the couch, but hey, they are coming. Five people around you, one pushes you, before you even start thinking about your perfect roundhouse kick that you used in the dojo, the guy responds with a kick between your legs and one of them hits you on the head with some spiked club, world goes black... What happened? Your technique was made to be used in some specific situation. This was essentially a portability problem, and this little bug caused some big crush on your system. If your technique was designed to be more portable, you would more likely to survive the scenario. Now realizing this, many martial art systems try to create the techniques that work at all costs. For example, some arts try to create techniques that will work against any techniques the opponent uses at that time. Some arts have a different set of techniques for some of the main emotions that the martial artist can be in at the time of the fight (confidence, fear, ambiguity, anger, etc). Some other arts try to come with a whatever works approach where they try to develop the artists' ability to think clearly under stress. This is what will happen with programming. Soon, we will be heading towards systems that work under most situations and can work with most other systems. Standardization is the most important issue here. Although standardization cannot be effective after some point (it may not be effective for a client machine to run the same system with the Earth Simulator), it may be effective if same clients created for similar needs to have same standards. This is what happened with networking protocols. TCP/IP, Appletalk, IPX/SPX, NetBIOS, and many others. At last, TCP/IP has won, and all the internet today is standardized. Unless you are using one of the other protocols for some specific reason in a specific area (like talking to your old Win3.11 server on your network to run your very old accounting program to see what happened 10 years ago or something like that), they basically are not used. Similarly, some standards will decrease to a minimum and most systems will be able to run most programs. Journal 8: Data set Towards the end of the Ottoman Empire, Enver Pasha decided to send an army over Russia to fight. Over the map he did his calculation; it was only 13km (less than 10 miles) of strong cold on the mountain, and then the passage was clear. He also estimated that the army had enough cold gear to pass through. Sad but true, on this 13 little kilometers, according to various sources, 50 to 90 thousand soldiers died freezing. Out of the few thousand who were actually able to pass to the other side, most of them died afterward of illness. As a result, war was lost before it ever began. The few hundred survivors hardly came back to Ottoman Empire and soon Russia would reply. If he interpreted this data differently or had another different data set, he could estimate how the results would be. For example, the passage on the mountain was extremely narrow. According to his passage, it was just a passage, and he also interpreted it that way. According to him, they would not freeze, but extreme cold of maybe -30s, -40s or even colder, without much winter gear (according to his data set more people had winter gear), there is no way of passing. Journal 9: Apple Human Interface Design The main aim of software is speed up and automatize tasks. For example, if we are going to do calculations with astronomical numbers, we would solve the problem much faster using software. On the other hand, if the computer usage is even slower than not using it at all (imagine the first computers) it might not really give us an advantage. What we understand from here is that the faster and higher performance is the better. Secondly, if the result we get is not reliable, then the value of the result falls dramatically, as we want the correct answer and only the correct answer. If at the end we end up with an unreliable answer and need to check it by hand or by some other sources, it might not really help much. Actually, these reliability and high performance issues are all all about costs. Reliability generally can be defined as time too (re-checking time and time lost in a case of failure). Moreover, at different times, value of one second is different For example, if I am at home playing video games, the value of one second for me is generally very low. We can understand how much one second of mine costs at that minute by a basic question. With the minimum of how much money you would be willing to give me one second of your time? Of course, at different times the value of money can be different too. For example, you could get my second at that time probably for a penny or two, while with Bill Gates, for whom the value of one dollar is much lower, it might take a bit more to get a second. That is why, the conversion should be done with the time and money value at a specific second. Similarly, all the other characteristics, such as interoperability and the rest, can be defined in time, and thus, money values. For example, interoperability allows me to create a cluster, which will earn me even more time. If it is not interoperable, I might need to solve the whole problem on one computer, which would be a loss of time with our current technology. Out of these variables, only attractive appereance seems to be seperate from all the others, but it is just a fake apperance, as it can also be converted to time and money. For example, why some people do not like GUIs is the answer to this. For those people generally the time earned is so much higher in value that giving computer resources to GUI, resulting in slower process and loss of time is not acceptable. As a result, these people use the system with less attractive appering command line instead of GUI. It is similar with the ease of use issue, where generally ease of use comes with a loss of flexibility, which at some point comes back as a time loss value. In conclusion, all these values can be converted to time and money. Going back to class, I want to talk about the computer "religion" issue. For example, some person might claim that FreeBSD is better than Linux. This is generally due to the fact that a slight difference in the combination of the variables above might make a big difference for a person. For instance, for this person, an increase in dependability might be much more important than ease of use and attractive apperance. It might also be just the reverse. Moreover, which operating system is more dependable et cetera are sometimes totally based on religion too. Maybe most of the times it depends on who is the administrator. Moreover, religion issue can be converted to time and money too. For example, if the same program is running much faster in Linux than FreeBSD, this person who is a strong follower of FreeBSD religion might suddenly convert. Similarly, if a Linux administrator is offered a much higher salary in a FreeBSD environment, that might end up with that person changing religion too. Moreover, this person might not accept to change environment for a slight increase in salary but a bigger one. How much salary change is going to make this administrator change religion equals directly to money value of that religion at that specified time (for example, if that person has just finished working on developing Linux for a year and is returning from a seminar where s/he was the speaker and talked about how better Linux is than FreeBSD in that seminar, the value of money that will make that speaker convert religion might increase dramatically). Journal 10: Group reflections Together with my group, we decided for me to be the librarian of the group. Moreover, just like everybody else, I also am a developer. In http://wiki/index.php/SE2006:group_bar:roles page you can find a list of my person specific roles and just below that under the title "developer (all of us)" you can find my general roles in this group. Basically, what I have been doing so far includes helping out with wiki, writing meeting minutes, finding data sources, writing code (contributed pretty much to two of the scrAPI code blocks), writing documentation for my code and sometimes others' code, watching people write code (XP style over-the-shoulder watch) and trying to give ideas while they write, work with others in accomplishing similar tasks explained above. I believe that most of the time I did a pretty well job. Although my skillset was a little limited at times (which has been improving), with the help of my group members, I was able to get through most of the problems I have faced. I came to all of the group meetings and have been devoting an incredible amount of time for this class. Every meeting of ours takes an average of 4 to 5 hours, generally from 8pm to 12am or even later, three times a week, and together with the journals and labs, I have been ending up more than 15, sometimes around 18 hours for this class every week outside of class times. Being a three credit class, normally it is supposed to require around 9 hours of classwork outside of class. Giving 1.5 to 2 times of the required-by-standards time to this class, and sometimes more time than all my other classes combined, I know that I have certainly been doing very well. Moreover, the results of my work also seems to be promising. Although I had nearly no idea on how to write regular expressions by the end of last month, I started to write pretty complicated enough regular expressions, moreover, in the last two months, my Perl and Java skills have been dramatically augmented. The group is going pretty well. We have been developing the product and it seems that we will be able to in time. I believe that the group can do better if we concentrate more on deadlines than adding this and that feature. I believe reaching the deadline without any cut-offs from the main requirements should be our main goal. Cool features et cetera can be added after the main requirements are completed.