Week 13 Reflection

My CS3216 journey is almost reaching the end. I have so much feelings that cannot be fully expressed within a single post. Here I am going to summarise what I have learnt or experienced for each assignment.

Assignment 1 is like a warming up for this module. I had a quite enjoyable time while developing our application – Taaag. I tried a new framework and it is nice to use. It was also my first time building a single page application, thought we did not implement it in a normal way. It was a pity that we did not know how to use frontend framework at that time, so our frontend development was not that efficient. Tutors told us that our app could not solve any real life problem, which reminded me of that the original purpose of our idea is to make it easy for users to search friends with certain skills or characteristics.

Assignment 2 is very short. I remember that I only used up to one week for this assignment. However, I have learnt enough from this seminar. Firstly, the discussion made within our group has taught me how to evaluate an application in different aspects. A successful application needs to have nice UI and correct UX. We also needs to critique the app from its business value. Secondly, as a non-native English speaker, I have gained the courage for presenting in front of the class with very strict time requirement, and most of the listeners are seniors. My performance was not excellent, but I was quite satisfactory because I had made a big progress.

Assignment 3 is very challenge for me. The framework I chose is completely new to me. It was the first time that I had tried asynchronous programming. What I felt at that time is, for a simple task that I could finish within a few minutes with synchronous languages, I need to spend hours on it using asynchronous methods. I also made some stupid mistakes that pushed off the schedule of the whole group. I also gained knowledge of RESTful API, thought I am still very expert on it.

The final project made my study in the second half of this semester very fulfilling. I have learnt lots of methods of marketing a product. I also have gone through many things that I never imagined before. Honestly speaking, I am not a outgoing person and not very willing to talk to strangers. Nonetheless, in the project, I have reached a lot of students to give out our tissue papers. This was a big challenge for me, and I felt a sense of achievement for overcoming it. More importantly, we received criticisms from different people. Some are constructive criticisms, some are just brute attack. Initially I was very upset about those people. However, I have known that we must keep calm in front of these difficulties, and try our best to do better.

It is quite unbelievable that I survived CS3216, a killer module in SoC. I feel very lucky to have these teammates this semester, and I hope that we will have other chances to cooperate 🙂

Advertisements

Week 12 Reflection

The ultimate goal for CS3216 final project is to bridge to the real world and gain real users. Since our group is using existing solution, the MVP comes out in a short time. However, a big challenge is to get the first batch of users. It is extra challenging for our application, where the content is supposed to be contributed by customers. As the initial step, almost nobody knows our application. We do not have any concrete data to claim that our website is useful or trustable, either. In order to resolve this problem, our group has held many meetings about how to market our product.

Firstly, we need to make it easy for users to try out our platform. Therefore, the registration procedure must be as simply as possible. The default registration form of our website is very complex, stopping many potential users. Therefore, we used many ‘hackish’ methods to customise the form, removed some redundant fields. It is not a very good practice, but rewrite the entire form builder is very costly and meaningless. Thought simplify the registration form, we broke the barrier of using our application. However, it is still not easy to enter compared to apps with social login.

Secondly, we must make the website looks professional and reliable. Our project is dealing with money, which is so sensitive that people will not try unless we provide strong sense of safety. Besides, our application also relates to other issues like copyright, we must have reliable term of conditions to control the content and its quality. Thus, our project leader, Zheng Yuan has done lots of research on term of condition and privacy policy, and written our own terms. It is really a tedious work, and she did a good job. Besides, we also created report links under each sale item, to enable customers to report illegal stuff. These efforts are very essential in getting users trust our website.

Thirdly, we should come up with various ideas of publicity. We decided to print our login and site url on tissue paper pack, since tissue paper is what we use in daily life. We have printed many posters and pasted them around the campus (even outside campus, in NTU). I think we put the most efforts in Facebook marketing. We created a page and post valuable content regularly. We also have written some blog relevant to study and exams, to attract the attention of our target users – students. Thanks to my teammates who have paid such a huge amount of efforts on publicity.

User is one of the most essential element of a web application. I will write more reflection on marketing in the next blog.

Week 11 Reflection

I believe that my group is the only one chose PHP as our backend language. We made this decision because WordPress has some sophisticate plugins to build C2C e-commerce platforms. At the time I started learning web development, some people have told me not to use PHP since it is not progressive nowadays and is going to be replaced by more modern languages such as Python and Ruby.

I remember that only a few years ago (when CS3216 is created), PHP is such a popular language that it was recommended in the assignment descriptions, since the major content of the materials did not change over years (:p). This language could start decreasing after a few years of prosperity. It shows me that the technology is evolving very fast. People keep inventing new tools and optimising existing tools.

As I am quite new to software engineering and do not have enough prior experience of using a variety of languages, I could not get the exact reason for why somebody dislikes PHP, but I have a hypothesis from a not very technical view. The needs of users vary and grow rapidly, which requires extremely high development productivity and codebase maintainability. That’s why some people say ‘PHP beat Perl and new languages beat PHP’. Languages like Ruby and Python have neat syntax that reduce the efforts to implement a certain feature, compared to PHP. Also, in my opinion, they are more high level than PHP. I have used Ruby on Rails this summer, feeling that it is highly abstracted and somehow close to nature language (I know Rails is a framework not language, but I think Ruby itself is also very high level). The simplicity also improves the maintainability, which makes modern application prefer these languages than PHP.

Some people also argue that PHP a language with bad design, which is an area unfamiliar to me. Therefore, I read some articles online and try to digest them at least partially. It is hard to define ‘a good language’, but a language that is not intuitive to learn is hard to be considered as good. The builtin functions of PHP has many strange and unpredictable names. It is unfriendly for a newbie to memorise what E_ALL means. I agree with this point of view. When I read the code in the plugins we use, I a really unpleased time to cope with some weird function names. It is also inconsistent, like strpos and str_rot13. When I encounter a library with this kind of function names, I will feel that the developers are careless hence this package is unreliable. The fact also applies to programming languages. Developers should pay extra attention on the interface shown to user and avoid bad impression. The articles I read provides many other reasons, for example, if a variable has never been declared, it will be null when used.

However, I also saw some defenders of PHP, saying that other languages make people have invalid assumption of programming language. There is still a heat debate on ‘whether PHP is dying’, and the content in the discussion is quite subjective. My current knowledge is insufficient to draw a conclusion. Therefore, I need to study harder to explore what I am interested in and make judgement by my self.

References:
http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Week 10 Reflection

“Open source” is not a new word to me. The first time I saw this term is about 1 year ago when I did CVWO assignment. It was described as projects that expose their source code to the public and allow everyone to make contribution.

While taking CS3216, this term appeared many times, making me notice that my understanding of it is quite shallow. Therefore, I have found and read some articles online about open source project. Some of them have discussed the pros and cons for making software “open source”. Here I listed some conclusions I made based on these materials.

Pros (motivations):
1. Community maintenance. Some experienced developers point out that the efforts needed for maintain a software after delivery is more than the efforts put during the development. Additionally, many developers are not willing to maintain their softwares after delivery. Therefore, making the project open source and enable the community to help resolve issues and make improvements becomes a good choice.

2. Proof of security and reliability. In assignment 2, I wrote a reflection of Telegram. Telegram is an instant message application featured for its ‘secret chat’. In order to make this feature trustable, the organisation has opened part of its source code. The author of XcodeGhost has publish its source code to release the concern of stealing credential information of users.

3. Contribute to the community. People can make use of the fruits, from a few lines of code to the entire project. Good projects will definitely contribute to the society.

Cons (challenges):
1. Challenge of community participation. Even if the software is contributed by the community, the project owner also needs to control the contribution. In order to ensure the code quality and correctness, the code reviews must be done.

2. Usually non-profitable. Open source projects are generally considered as “giving the fruit of work hard to others for free”. Since the public can access the code, it is hard to make people pay for it. However, many companies has come up with strategies to make money with open source projects. For example, some companies make part of their products open source to attract users, to reduce the cost of marketing.

Anyway, open source is just one term among numerous adjectives describing a project. Whether the software can be well maintained depends more on the actual execution. I believe that more and more open source projects can enrich the community and benefit more people.

References:
http://www.computerworld.com/article/2986768/application-development/xcodeghost-used-unprecedented-infection-strategy-against-apple.html

http://www.infoworld.com/article/2612393/open-source-software/greed-is-good–9-open-source-secrets-to-making-money.html

Week 9 Reflection

I think I have Obsessive-Compulsive Disorder (OCD) for programming. I have difficulties falling asleep if there are some bugs to be fixed. That’s why I had a cardialgia and went to NUH this week.

Programming is extremely unpredictable. You will never know what bugs are waiting for you in the next step. For many times, I thought my work was 90% done, but in the end the remaining 10% would cost exactly the same amount of time as the previous 90% did. It is quite normal to spend a couple of hours to deal with a single, possibly ‘trivial’ bug, and then shout out ‘how stupid I was!’ or ‘this library sucks!’. I should never trust myself when thinking ‘this task seems to be easy’, since it is so easy to be killed by an easy problem.

I am complaining this because I almost died for some weird bugs in my assignment 3. For example, there was a feature that worked locally in our laptops, but broke in our production server. It is super weird because their code are the same. Since it only happened in server, I couldn’t do local debugging but had to ssh in the server to test the behavior. The server is slow and I have really no much experience with Vim. After spending a long time, I finally realized that it was a timezone issue. I never knew before that our server is in US! It is a terrible but precious experience. Although I was tortured by it, I have to admit that it is my fault for overlooking the timezone problem. Good code should work regardless the location of the server. I did learn something from it, and hopefully I can avoid the same problem the next time.

Let’s come back to the first paragraph, where I said that I couldn’t sleep until all currently existing bugs were resolved. The reason is probably that I cannot foresee the future challenges and how time-consuming they are. Even at the point that everything works well in my local server, the deployment can be annoying and troublesome. I also have a habit to do my Math or physics assignments right before the deadline, but always start my CS homework very early. If I am lucky, I might finish very quickly, but, it is also possible to be stuck and get into endless debugging. If I don’t start coding early, it’s easy to miss the deadline.

However, for me, this is a charming factor of programming. It makes me feel despairing when failing something, but feel extremely excited when passing them.

Week 8 Reflection

Since the ultimate goal of all final projects is to gain real world user, awesome user experience design has become a must. There are many principles in designing the user flow, and here I want to address a few of them which I have learnt and applied in this module. Our group is going to build a marketplace, so we must think of how to make a user feel like staying as either a seller or a buyer.

Firstly, remove the entrance barrier. Nowadays, many marketplace applications ask venders for license or account details, for secure and credible purpose. It is reasonable for those platforms to filter out those unreliable sellers, but this strategy is not applicable for our platform. The products in our marketplace are help sheet, past year paper solution and other study materials, which usually are sold in very low prices. If I want to sell my help sheet, I would prefer a platform where I can register as a vender easily. Therefore, we tried our best to simplify the registration procedure. Once signing up by filling in basic information like email and password, a user can sell their stuff directly. I hope this decision could make our platform easy to get started and therefore keep more users.

Secondly, optimising user experience in ‘most frequently used features’ should be given high priority. Especially for project with very limited time, like the final project we are working on. In our website, the most frequently used features are definitely ‘sell’ and ‘buy’. To make selling as simple as possible, we have added a big button directing to the sell page. For buyer, we put a search bar on top in order for them to filter products by universities and modules. Although we have many other functions, but we chose to polish these basic key features first.

In pre-development phase, a common tool for user experience design is user survey. User survey is a useful way to know what problem users are currently facing and what feature they are expecting. For instance, we have conducted a quick survey after the idea of ‘a platform about past year paper’. From the result, we could conclude that lacking solution for past year paper is a big problem that many students are facing currently. However, user survey does have limitations. In objection to our origin idea, Prof Ben has pointed out that ‘users do not know what they want’. It is true that people can have many misconceptions for a software before actually using it. Even when they are using this software, users have a lot of unintentional behaviours, for which they could not give specific reasons. For example, an experiment has shown that forms with placeholders can generally attract more users to fill them up, compared to forms using labels. This conclusion is unlikely to be generated from survey, because users have difficulty discovering such a behaviour by themselves. Therefore, user experience design could not only rely on asking users questions, but also look into their actual behaviours through experiments.

Week 7 Reflection

If you ask me what has changed my view on software engineer most since last summer holiday, I will say – library.

I need to do image uploading and auto-complete, and you also need this 2 features in your project. Instead of implementing both them individually, we can collaborate with each other. I do the image uploading, you do the auto-complete, then we package our work and share, everything done. I think this is somehow a ‘prototype’ of the package sharing. It largely improves the efficiency of software development by reducing the work of achieving a complex feature to simply downloading a package. For now, every time I am assigned to some tasks that I have no idea, I will google whether there are available packages first, and most of the time I could get what I want within the first three results coming out.

However, I don’t believe that it is always suitable to use library. A lot of consideration need to be taken. We have to see whether this package can be merged well into our product. It depends on the need of our product as well as the flexibility of the package. The ideal case is that we can achieve our goal by specifying some options in code, but in many situations we need to make changes to the source code of the package, all override some parts. Sometimes these changes are so tedious that cost more effort than writing functions by ourselves. It teaches me a lesson: our plugins are probably able to gain more users if it allows users to customize based on their need with sufficient and flexible options.

I did benefit a lot from using libraries, for example, the mailer plugin for Node.js I used in assignment 3. But I also have experienced how tough it is to modify a plugin from fixing the datetime picker in CVWO. Therefore, I think we need to think thoroughly when deciding whether to use certain packages, in order to prevent the risk of endless patching.