CS Senior Seminar Blog @xyp940910-blog - Tumblr Blog

Importance of open source experience

This week’s seminar we discussed the success of FOSS projects including Red Hat and LinkedIn. We also touched on how open source experience is important to us as students, and how it can help us during job hunting.

As more and more people start learning and working on computer science, this field has become much more competitive. As a result, during job hunting, big companies would definitely prefer hiring people who have an outstanding experience. This requires students to have completed some research, projects or internships. However, because of the trend of open source projects, contributing to OSS community becomes a valuable experience for us. Since we were only focusing on coding, learning basic syntax, algorithms and have few opportunities to work on a real project, OSS provides us a good opportunity of getting involved in a team and work with experts, teammates, and professionals which would help us have a sense of working with others. Also, it improves our coding skills if you contribute to the code.

Although OSS experience is beneficial for students, it does not guarantee you a job opportunity because it really depends on individual efforts. If you only put limited time into the project and do not contribute or only edit some typos, basic documentations, you will not gain much through that. Instead, if you are willing to dig into the project, get involved in the community, try to fix some bugs, and try to look into its source code, this kind of activities are beneficial and will help you gain a lot of knowledge about the project and improve yourself overall as a programmer/engineer.

#FOSS #open source projects #job #experience #success #Senior Seminar

Business in FOSS Project

This week we had an interesting discussion on what motivates business to run, support or participate in FOSS projects. There are many advantages of getting involved in FOSS projects. For large companies such as Apple, Google, and Facebook, they can attract many engineers who can contribute to the projects with no costs and fasten the development of it. It also helps the company to gain useful feedback from users which will result in a better product. Branding is another benefit that business can get out of opening source because more users and more contributors can build a reputation. Also, in engineers perspective, participating in a FOSS project would help you gain coding/programming experience in real projects and improve your skills which can be beneficial in job hunting. On the other hand, companies can gain lots of talents and potential employees.

React Native is the FOSS project I am working on this semester. It is a framework for building native apps using React, which is released by Facebook and it becomes one of the favorite mobile app development frameworks today. So why would Facebook make it open-source? First of all, in my opinion, Facebook does not expect React Native to be a “profitable” project in terms of money income. However, it helps the company in many other ways. For example, when you create a framework, it makes lots of tasks easier and you can develop faster, but it also creates bugs, which need to be tested and fixed before you can use in more and more projects with wider user cases. Testing the framework on wide sets of use-case is not easy and certainly is very expensive. Hence, open sourcing the framework suddenly provided a larger group of testers who are going to use the framework and give feedbacks. Having more talents work on coming up with the ideas could make the development faster and more usable. Moreover, a free project does not mean that Facebook would not gain any money. Since React Native is very widely used, they can advertise other companies who are using this framework and any other products from Facebook.

So open source projects can be really beneficial in many ways but it does not mean that every project should be open-source. Companies should be careful in other factors including security, maintainability, and licenses.

#FOSS #business motivation #Senior Seminar

Software Process

The past week we have discussed several Software Processes such as Agile, EP(Extreme Programming), Scrum, and TDD (Test-Driven Development). All we talked was somewhat related to Agile and we did not touch on the traditional process called Waterfall. So in this post, I would like to share my understanding of Waterfall process and the comparison between Waterfall and Agile.

Waterfall was first proposed In 1970 by Winston W. Royce in his paper, Managing the Development of Large Software Projects. Although he never used the term in his paper, the incremental methodology later became known as Waterfall and became one of the most widely used software development model in history. Waterfall is a linear process in which development of software is depicted as cascading through the following four SDP phases sequentially: requirements analysis, design, implementation, and testing/validation.

According to the book, Project Management for the IBM Unified Process, the basic tenants of the waterfall method are (Gibbs, 2006):

One cannot build anything before knowing its requirements.

Rework should be minimized by not beginning development until all the requirements and specifications are agreed upon.

One may not begin work on a subsequent phase until all the work of the current phase is complete.

This rigid structure makes it conducive to establishing schedules, efficiently allocate resources, and is overall is a simpler process to understand and manage. However, because its rigid structure requires all of the requirements to be collected before any design or is performed, it can serves to minimize the amount of time the project sponsors are engaged in the process of developing the product and also discourages the use of iterative feedback sometimes required by the sponsors to completely understand their specifications.

Agile, on the other hand, due to its approach of aggregating product over numerous short iterations, it is very flexible in responding to changing specifications and thrives when user involvement is at its maximum. However, because its structure is so fluid and seemingly open-ended, it can be a difficult one to manage and anticipate. Additionally, because Agile is so dependent on user involvement, in circumstances where sponsors’ time is limited or otherwise cannot fully commit to becoming a part of the process, the process itself may fail.

#waterfall model #agile development #software process

Software Testing

Unfortunately, I did not attend our discussion on software testing this week because of sickness. I would like to share my experience on software testing which I learned when I was in Australia last semester.

The class I have been taking is called Human-interface Design. The major goal of this course is to introducing students what is the interface design and what makes the design good or bad. We are lucky to make our own project as a group and one of the most important processes of our project is to do user testings. First of all, we designed paper-prototype for our project first. Although this prototype is well developed and does not look exactly like the interface will be used for the application, it still contains certain features, images, icons etc. that allow us to do some basic user tests. I remember when we were doing the test, we have to first prepare our test plans. Test plans should include the goals of the test, what feature should be tested, what are the rationales of the test, how would you evaluate it, and steps to finish the test. The following shows an example of our test plan.

After testings, we would collect the data and analyze it and modify our prototype based on the result. Then, we improved our paper-prototype into an electronical prototype which looks similar to the actual interface. And we did user tests again. Differing from the previous tests, this time, we need to test on many more users in order to have a better feedback from them. For our project, we only did two cycles of test to help us gain some hands-on experience, I believe for a large design, more tests are needed. Combining this experience and what we learned so far in senior seminar, I now have a better understanding how much efforts are required for designing a successful software. It’s not only about programming, software architecture, patterns, and testings etc. are all closely related.

#software testing #user testing #senior seminar

Software Patterns

This week’s seminar we discussed software patterns. Before we do the readings, we did not realize what is software patterns and how they are so closely related to our programming practice. From the first intro class till now, we have used many of the patterns already such as Iterator, Observer, and Strategy patterns. What interested me the most is the question that whether software patterns should be taught more in our school?

Personally, I think software patterns should be learned by practicing. There are tons of books and texts explaining the differences among those patterns. However, it is impossible for us to understand the concept by just reading. The learning process requires a lot of coding exercises. So prerequisite knowledge is necessary before touching on those concepts. Professor Braught hit a good point that software patterns sometimes restrict programmers’ creativity, especially for students who are learning how to code. Patterns provide people templates for better code design. If they are widely taught in intro classes, students will most likely rely on these templates when doing coding exercises. This would be a wrong way of starting programming.

Also, software patterns do exist independently, it includes many other notions. For example, software architecture, as mentioned in my previous blog post, is strongly connected to this knowledge. In order to let students have a better understanding of these concepts, software architecture and software patterns should be taught in the same course.

However, the topics about software patterns are wide-ranging, it is impossible to teach all of them in one single course. So I think for undergraduate students, this course should be more of an introduction to the field. Since the knowledge is so important for our future careers, knowing the software architecture and patterns are beneficial for students and help them more prepared for job interviews. If interested, advanced courses would be taught in some graduate school. When is the appropriate time of that class? I prefer taking this class in my junior or senior year. Specifically, in Dickinson, I think this course should be a 300-level course and it would be appropriate for students to take when they start job hunting or prepare for graduate school.

Wondering if our department is going to open this course, and how the course is instructed? I would definitely suggest students take this course.

Code Comments

As I remembered, when we first learned how to code, we are taught to write a simple description for each function. At that time, we had no idea about what are good or bad comments and why we are writing these. As we get familiar with programming and code designs, we noticed that comments are very important. However, comments are not something you should rely on in your programs. It’s always helpful to make your codes as simple as possible to understand. And it’s important to keep the audience in mind when you are writing codes. Knuth suggested an interesting idea in his essay “Literate Programming”:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

We are writing human-readable comments for people to let them understand what the “big picture” of the program is. However, more comments do not mean more readable code. You may not wanna write excessive comments for each line of code because that will make codes even messy. Overall, both codes and comments are important and interdependent of each other, we should always try to make them work together and produce a clean and functional program.

Software Architecture

At this week’s Senior Seminar, we discussed software architecture. Two of the principles of building an architecture attracted my attention.

The first one is the idea of “Build to change instead of building to last.” My understanding of this concept is that since the world is changing so fast, especially anything related to technology, there is no beneficial to build an architecture as one final product. Not only technologies could change, customers desire and business requirement can change as well. As an architect, you have to build the architecture based on a solid foundation including potential scenarios and challenges that you may comeover in the future. Otherwise, it will make the application difficult and less flexible to deploy or maintain.

Another principle is what’s called “The least knowledge principle.”, which is explained in the reading as any component or object should not have the knowledge about internal details of other components. This approach is also called “Law of Demeter (LoD).” This approach avoids interdependency and helps maintainability. The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents). One example could be: inventory.SalesInfo.Items.Count = 2500; VS

SalesInfo si = inventory.SalesInfo; int salesItemsCount = si.GetSalesItemsCount();

As we can see, we would rather build separate objects with non-overlapping methods than accessing information by listing of dots. The advantage of this principle is that it can make the project easier to maintain because objects are less dependent on other objects.

Discussion on FOSS Licensing

You need good coding skill to create a good software but the success of a FOSS project also depends on your choice of license. That's because the license under which you make your code available has a real impact on what you can do with your code, who will contribute to it, and ultimately whether it gets widely used or ignored.

However, there have been lots of issues related to licenses since the idea of licensing came up. Based on the discussion we had on this week’s seminar, I have the following concerns about licensing: First, we know that a project can have more than one license and often times that causes some trouble for its users. For example, a person will believe he download one open source project under one open source license, but in reality, there are probably multiple open source projects and licenses nested in the source code they downloaded. This can become an issue when you are trying to avoid certain licenses and those licenses are nested in the project with little to no reference to them. Another similar issue I found out is that what if a project will have a base license tied to it but have option parts that can be used under other licenses. For instance, if a project is under license of LGPL 2.1 or later but it also includes other parts that are covered by GPL 2.0. Nested licenses such as these can really create license confusion and compliance failure, especially if somebody downloads this project from another origin that isn’t the project website. A difficult situation like this can cause fewer developers to contribute the product and hurt the project in the long run. Also, we discussed “cheating” or “stealing” in terms or copying the source code from a project and release it after modifying only a little. We are not sure about how original developers determine if their codes got stolen and if there are any methods of punishing those stealers.

It seems that licensing is a double-edged sword. New developers like us should always keep that in mind and ask professionals for advice when we are dealing with a complicated situation.

Centralized vs. Distributed Version Control System

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. I remembered when we were taking COMP131, we were using SVN which is a commonly used centralized version control system. However, at that time, I didn’t understand how exactly SVN is working. I thought it’s just a distributed system. Professors can upload their source code to a server and then students who have access to the server can download codes and then working on it.

And this week we got to know about the Distributed Version Control System. DVCS does not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

DVCS has some main advantages compared to centralized. Everyone has a full copy of the project repository on their own machines. Because of that, programmers can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone. You can make changes to codes offline unless you need to share changes. Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access your local drive, not a remote server. And most importantly, branching and merging is much easier with DVCS.

However, there are also concerns about DVCS. If the project has really huge source files, downloading the entire repository can take a impractical amount of time and disk space. In addition, a file can be locked when making a check-out, are usually not possible because of concurrency that may happen between repositories in DVCS. The reason file locking exists in version control is because developers want to avoid merge conflicts. However, locking has the disadvantage of slowing development down as two developers can't work on same piece of code simultaneously as with a long transaction model and it isn't full proof warranty against merge conflicts. Source leakage could also be a problem. In proprietary projects, it would be disastrous if the whole repository becomes publicly available. Even more so if a disgruntled or malicious programmer gets hold of a cloned repository. Source code leakage is a severe pain for proprietary businesses. DVCS's makes this plain simple as you only need to clone the repository.

Overall, both systems have their own advantages and it is eventually an organizational decision choosing between centralized and DVCS.

Discussion on H/FOSS Project Structures and Bug Tracker

In today’s seminar, we discussed the structure of FOSS Project first. In order to build up a successful project, we need to know what factors are critical for a project and what a well organized and maintained project should be like. Several key factors we pointed out include documentation, communication, bug tracker, and management.

A good documentation gives both developers and users a clear idea of what the project is about, how the project works and every detail they need to know before they decide to use it or contribute to it. In addition, efficient communication tools such as live chat and forum are important for the success of a project. Also, a well-built bug tracker can indicate how well do developers deal with bugs because this ability tells if they can upgrade and maintain the project. Lastly, good management plays an important role as well. Good relationship and connections between leader and members can improve work efficiency.

Then, we had a good discussion on bug trackers. Some questions we discussed include what kind of issue should be reported as a bug, how to determine priority. The most interesting part of this discussion is who should open those tickets. We know for a huge size project, there could be hundreds or thousands of bugs appearing every day. What is a good way of assigning those tickets? We discussed that the developer/leader who has more knowledge on codes and solving the bug should be the person who opens the ticket. However, that will put more work on this person. Is this really an efficient way of dealing with this situation? Probably more discussions are needed.

Discussion on H/FOSS History & Philosophy

Before doing the readings and discussion in class, I barely know about FOSS project. But after learning its history and philosophy, I gained a bit of knowledge about FOSS. What impressed me a lot are the fact that FOSS project has about 95% failure rate and the discussion on what does it really mean by “free”.

When I saw “Free open source” for the first time, the idea of zero-cost came through my mind. However, free does not only mean free of charge but also contains a sense of freedom, that is the freedom to share and modify for any purpose.

We also discussed that many factors could lead to a failed project such as too much competition, poor collaborative work, poor documentation, lack of capital and technical support and no market for the product. All of these factors seem to have nothing related to the programme or code itself. However, the truth is that for huge size projects, writing executable and efficient programme is much harder and requires lots of efforts. This is definitely a challenge for all the developers because such amount of work can easily get them bored and make them lose their interests of keep developing the project. Thus for us students, we have to understand what situation will be in the future and get ready for this one-year project.

xyp940910-blog

Comp491

This blog is created for Senior Seminar in Dickinson College. It is used to reflect writings on reading and discussion topics related to free and open source software (FOSS) and software engineering.

xyp940910-blog

This blog is created for Senior Seminar in Dickinson College. It is used to reflect writings on reading and discussion topics related to free and open source software (FOSS) and software engineering.

My plan after college: I will try to get a job and if I don’t I will go for graduate school.

Comp491

This blog is created for Senior Seminar in Dickinson College. It is used to reflect writings on reading and discussion topics related to free and open source software (FOSS) and software engineering.

Trending Blogs

Recently Viewed Blogs

CS Senior Seminar Blog