Author Archives:

OOP Basics

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time.
I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly.
The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declaring objects, how difficult it would be to keep track of everything and make everything work properly. 
This video was made for someone who might be interested in computers, but this is not their specialty. Although this was helpful for me in getting a better background on what OOP is, I felt it did not go far enough. I would have liked it if it went a step further and explained some of the next topics that would logically follow. The video was under fifteen minutes, and most of the videos in the channel are that length, so there wasn’t that much room to expand. 
He said that he would go over the topics like inheritance in another video, but I searched through all the videos with him, but I could not find the “OOP part two” or anything of that nature. I don’t like that the channel doesn’t cater to people with a computer science background, but on the other hand, there are some interesting looking videos that I would like to watch after this. My next step will be to learn about functional programming because I do not have any experience in that area.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Spending Testing Time Effectively

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Designing the code is more important than you thought

Personally, I always think that the design phase of a program is very important and it should be done almost immediately after I started setting up my git project. Like all other new developers, at first, when me and my cousin were working on an Android project, we thought it would be just a waste of time. Surely after a month, it started to really fall apart as we have all sort of problems like our implementations does not work well together with a lot of lengthy methods that is definitely not necessary to be that complex, and we even used some dependencies that are obsoleted just to make another piece of code compatible with the situation. We learned our lesson and from then, we developed a habit to jot down some idea and implementation to at least let each other and ourselves how we would carry out the project. I actually found this article months ago and I think it’s already pretty neat, so I decided to write my blog this week based on it.

For a start, this article is written by Marcus Biel and it mostly talks about what he called “Clean code”, which is basically the idea to have your code be precise and as close to perfect as possible, even though it is a small project. I really like the part where he says “If you have more code than you need, it shouldn’t be there. There shouldn’t be anything superfluous, and I go so far as to say that there shouldn’t even be superfluous whitespace. You want your code to be as efficient, readable, and maintainable as possible, and instead of only solving the problem.” This is probably what everyone should expect to achieve after finishing their “first draft” of the program.

Some would ask why is it so important to spend a lot of time on this phase. He gave two simple cases that are really relatable to programming. Imagine living in a house that was built without any blueprint and when it falls apart, you would not even know where to start to fix it and eventually, the roof caves in. For instance, when you have a shopping cart, of which function is to put things that you would buy into but people keep throwing trash into it until it spills out and you don’t know which one to put on the checkout counter. In these cases that he gave, it was really clear that there are no boundaries or rules to maintain your object and prevent it from long-term problems. The lazier you are at first, the more efforts you have to put in in order to have it up and running. Even if most of us are not perfectionists, this problem can’t be ignored as our projects would get more complicated the more we develop it.

Now that we know that it is critical, we can look at a few ways to accomplish clean code. The simplest thing that you have to do is to not think it as a coding project, think of it as a design and planning process. Let’s pretend that you are building a house. A strong foundation is what we really need and that can be seen from the coding aspect as file structure, classes, and methods without any bodies. When you have a solid foundation, it would cost fewer resources to maintain as it is already hard to fall apart and even if you want to expand, it is much easier to base on the old foundation, rather than having to build another one.

Not only a solid foundation that we need, but we also need the coherence, or should I say it is easy and makes sense to everyone who read it. The author of this article makes a point that we should follow the idea of “ubiquitous language”, which is to have your variable names, class names, and package names to make sense to whoever is reading your code. This design is called Domain-driven design. In addition to this, I also think that it is important to follow the naming convention, use detail unique name for variables and practice proper indentation so that myself and the one I work with can see the structure and what words mean without having to scroll up and down a lot.

Without any further reading, I think these pieces of information that I have given are quite enough to convince you to think and start to develop the habit to have a design phase before carrying out the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

A Review of Software Engineering Radio’s Conversation with eBay’s Randy Schoup (ep. 109)

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years.

To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed. It seemed that everything designed had to have a degree of compromise of what was expected of it. He referenced the “CAP Theorem,” where it seemed you cannot always have all three parts that it stood for — “Consistency,” “Availability,” and “Partition tolerance.” He also was realistic that everything can fail, especially  when the system gets as big as it gets bigger. For some reason it surprised me when someone from such a prominent company would admit this.

Something else that really surprised me what he said one of their biggest limiting factor was something I would not have expected, which was power consumption. He claimed that some companies’ database centers can use more energy than a local power station can support. This makes it much more important to design efficient database structures, especially in a company that deals with data in several petabytes.

It just boggles my mind how reliable websites like this are for millions upon millions of consumers. He said $2,000 worth of transactions were made every second, and that was over ten years ago. The site has grown since then. This gave me some great ideas to run with, as I hope to one day work for a company as esteemed as his.

Link: http://www.se-radio.net/2008/09/episode-109-ebays-architecture-principles-with-randy-shoup/

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Shailesh Rao on Quality Assurance

In this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%.

He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?”

I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software.

A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the patience to put up with a buggy app. They will move on to the next thing. It is easier than ever to launch a software project to a very wide audience, and it’s become apparent to me that it should be done right the first time around because customers don’t always give a product that flopped a second chance.

Another point brought up that will affect the way I think about testing and quality control is that you should test for all possibilities or you might not know the market you missed. People often say to themselves “it won’t happen to me,” and think their software will not be downloaded millions of times, but if they didn’t prepare for those conditions, they won’t get that chance.

The core message that was hammered home was that developers should have quality at every step. With as complicated software can be, it is extremely difficult to have it be truly bug-free, but it is possible, and we should always strive to be as close to it as we can.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Introduction

Hello everyone, I’m Khoa Nguyen and this is my blog where I would document about what I find really interesting about computer science while learning it and doing my personal projects. I’m looking forward to having a wonderful experience after writing this blog.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

The Surprisingly Complicated Problem of Programming a World Clock

In computer science, there are a lot of things we would normally take for granted, but it might not be so easy to program. Take time, for instance. If we wanted to create an app to calculate how many seconds ago a time and date was, it seems straightforward. Of course we would account things like leap days, but as I discovered, it quickly becomes a lot more complicated than that.

As Tom Scott explains in an episode of the YouTube Channel, “Computerphile,” a simple-sounding app like this can be jarringly complicated. For starters, to create this app for a worldwide audience, it seems reasonable to make it available in all time zones.

To adjust it for each time zone seems straightforward enough. All you have to do is take the Greenwich Mean Time and add or subtract hours based on the time zone that the user is in, right? Not quite.

Take daylight savings time, for instance. It varies from country to country when daylight savings starts, and then there are some states/countries that don’t go on daylight savings time. This is just the tip of the iceberg of how complicated it gets.

There are times when countries skip days when they cross the international time zone. Countries can often switch time zones several times, even within the same year. Some countries can be in the same area but in separate time zones, such  as Israelis and Pakistanis. Historically, we haven’t alway been on the same calendar. Russia only switched to the Gregorian calendar in the twentieth century, complicating matters even more. There are even more confounding historical absurdities, such as the year used to start on the 25th of March, bizarrely.

There is even a such thing as leap second, but leap seconds don’t exist in astronomical time, and the differentiation is important because of how they manufacture telescopes and such.

This video revealed just how easy it is to take a problem and not realize how much more vastly complicated it can be and to appreciate the people who came before me and worked out this absurdly complicated problem.

I found it interesting because it was a problem I never thought about before. It seems like an easy enough problem until you find out how complicated it really is. Like I say, it is easy to take something like this for granted, and this makes me appreciate how seamlessly most technology that uses programmable clocks runs. Now that I can understand how vast and complicated the problem is, I can appreciate those who came before me and did the hard work to get it right.

https://www.youtube.com/watch?v=-5wpm-gesOY

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

CS-343 First Post

Hello again! This is my first post for 343. Equally excited for this class as the other. Excelsior!

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

CS-443 First Post

Hello world! This is my first post for CS-443. I am very excited for this semester and what’s to come!

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.