Monday, 28 July 2014

Craftsmanship

It was a busy month, all work no play... more about polishing, both code and UI, to make a better product.

1. Code Polishing

In the current Java Spring project, there are a few things worth mentioning.



1. Service layer for MVC.


My previous projects are mostly architected under MVC pattern. There is nothing wrong about that. However, when the logic gets more complexed, handling all the logic in the controller layer would not be as clean and efficient. Another layer named Service for better data access and logic control is used in the our project. http://stackoverflow.com/questions/5702391/mvcs-model-view-controller-service


The controller would not be handling too many logics, instead, it only handles routing and  parameter passing. Most logics will be handled in the service layer.


2. Exception handling vs error codes


In the beginning, I didn’t do any exception handling in the service layer, neither do I create many exception handlers in the controller layer.After reviewing my peers codes, I realize that it is more elegant to throw exception than returning error code. http://stackoverflow.com/questions/253314/exceptions-or-error-codes


In the project, we used exception handling in the service layer to return exceptions which are inherited from IOException. I found the logic clearer after shifting to the exception handling idea in my codes.


3. Bad thing about lazy fetch type

In hibernate, it specifies the lazy fetch type, which is intended to reduce database memory access for relationships such as @OneToOne, @OneToMany,  @ManyToMany ,etc.
In the following blog post, the author stated some good explanations about the difference of each fetch type. http://howtoprogramwithjava.com/hibernate-eager-vs-lazy-fetch-type/


FetchType.LAZY = Doesn’t load the relationships unless explicitly “asked for” via getter
FetchType.EAGER = Loads ALL relationships”


However, lazy can be very troublesome in some circumstances. I had a lot of null pointer exceptions when trying to get lazy type relationship entities. I've got to manually parse these relationship entities into Map before sending them to the view, which makes the code very dirty.

For instance, in the following code, I want to get all users and their associated roles. Simply get the user list array won't return the roles because of the lazy issue. But I still need to display the associated role information in the view. I've got to use the ugly way to parse the role list into strings before sending to the view. If you know any better approaches, please let me know. Thanks!
    public List<Map<String,String>> getUserList(){
        List<Map<String,String>> userList = new ArrayList<>();
        List<DashboardUser> allDashboardUsers = Lists.newArrayList(userDao.findAll());
        for (DashboardUser dashboardUser : allDashboardUsers) {
            Map<String, String> aMap = new HashMap<>();
            aMap.put("id",dashboardUser.getId().toString());
            aMap.put("email",dashboardUser.getEmail());
            aMap.put("username",dashboardUser.getUserName());
            String roles ="";
            for(Role role:dashboardUser.getRoles()){
                roles+="/"+role.getName();
            }
            aMap.put("roles",roles);
            userList.add(aMap);
        }
        return userList;
    }
2. UI polishing


Switch to angular.js.

Previously, the project is developed under jQuery. The views are not structurally organised, until it becomes quite a messy.The team decided to use angular because it’s clean and structured. After one week's polishing, the codes become much more beautiful, both in the front end and the backend.


I may write another blog about angular when the project gets more polished.

3. Project management


1. We tried to explore the scrum 
meeting(http://en.wikipedia.org/wiki/Scrum_(software_development)) inside the small team. It works quite good. The basic scrum workflow consists of sprint planning, daily scrum meeting and end review meeting.  

The daily scrum meeting is not hard to follow. We started the meeting at 9:45am for <=15 minutes everyday at the same location asking the following questions:

“1. The basic What have you done since yesterday?
2. What are you planning to do today?
3. Any impediments/stumbling blocks? “
The tasks will be noted down by the scrum master and posted on a public wall. It makes every one involved and aware of the progress.

2. Github feature branch

Previously, we develop the features under our own develop branches and make pull requests to the origin develop branch when a new feature was added. However, that’s not a good design. The new feature commits are mixed with the develop branch and you can hardly distinguish which features are added by whom in a structural manner.

Thanks Peng jun and Xu Fan for sharing this. 

http://danielkummer.github.io/git-flow-cheatsheet/

Another tip for using github is to use git stash for saving unfinished changes in the current branch before switching to another local branch.

Tuesday, 24 June 2014

Restart

It's been one month since I started working in the new company. The overall experience is very good, quite a lot to learn and practice, except that I wasn't self-motivated enough to show lots of passions.

I kept a weekly journal on Google docs to record some company-related stuffs. Some contents are operational/business related and can be sensitive to the potential competitors, thus they are saved as private journals.

Techinally, there are quite a few good gains to note down.

1.I started to use unit testing in the project development. It turns out to be a very good practice to keep the codes a good standard. 

2.One colleague and I discussed a sub part of the system and wrote the design document done before coding, which turns out to be a very cost efficient approach.

3.We used pivotal tracker to divide big projects into small parts. That is pretty useful for project management. I used trello in the past, however not as efficient for intensive collaborative working.

4. I designed and currently implmenting a sub system in a project. That's a very good way to learn things from high level architecturing to actual implementation.

It is true that people get less personal time after working. The case should be worse for startups. However, it was not that bad for my first month, mostly because the company's  major projects will start next month. Another important reason is that I wasn't assigned very heavy tasks. The mentor would love to give me some time adapting to the company's development environment. Personally, I also didn't do extra work besides the assigned tasks. Indeed, I chose to go off work on time to do have some personal stuffs.

The bad thing is that I didn't read enough tech books. Indeed, I only encountered two cases where the tech books are useful: one is to use Enum instead of static integers, another is to use Hibenate and JDA to access the data layer.

Most of the time, I feel excited reading project management related books.
For instance, this book-Remote, which is written by 37signals and translated as Rework2 in China, really excited me. It's about mobile officing. It is really happening. Indeed, I also experience the same thing working on remote projects in github over Skype.


Another book, quite an introductory book to me. I find some points here quite interesting, e.g., how to improve the working procedure to reduce bugs,  the agile mission board, etc. 




Saturday, 24 May 2014

Kilimanjaro

I decided to take some adventures before starting a new job. Around a year ago, I read a sharing from Facebook about the advantages of extreme sports. I found it quite convincing and worth a try. Last winter holiday, my friend, Qiyue,Jingping and two other girls went for sky driving and high jumping. I guess that a pretty good opportunity to start. Unfortunately, I was too busy with the ReadPeer project to go for a two weeks' trip. This summer, they are graduating and I'm changing a job, thus I decide to spend two weeks experiencing something adventurous with them. The plan is to climb the Kilimanjaro mountain. Since the safari is also nearby, we'll do that as well.
Another friend who has climbed a 4000+ camp in Nepal together with Qiyue found our plan cool, thus he also decided to join us for the Kilimanjaro trip.

Before climbing, we must have researched about the difficulty and feasibility. We knew that it is doable even for beginners like me. However, it takes courages and determinations. I'm not that confident about my physical and mentor wellness, but I strongly willing to take this opportunity as a way to train my mind, to really break my own boundary.

Thankfully, I made it even with headaches. In the first day, we climbed to the 3000m camp from the 1800m gate. It was raining heavily and we were quite troubled with the clothes. The pace is a bit too fast, but every one can catch up.The second day, we climbed up to 3900m and down to 3800m for camping. It started to rain after we climbed to 3900m in the lunch time. I felt a bit headache, thus drank a lot of water. The third day, we climbed all the way to 4600m and then down to 3900m for caming. It started to rain heavily in the afternoon and the team walked down very fast. I was a bit behind the team during the walkdown and the assistant guide accompanied me all the way according to my pace. Because of the rain, we arrived at least 1~2 hours earlier than expection each day. We four all felt a bit headache in the second day and the third day. The difference is that my teammates felt no headache after sleeping while I still felt headache after sleeping. The forth day, we climbed to the base camp at 4600m. My teammates were still quite fast but I was left behind for 30min~1h due to the mountain sickness. The original plan was to start climbing from the base camp at midnight of the forth day and  arrive at the summit during sunrise.The guide then decided that I started with the assistant guide 1 hour before the rest. I quickly had a short rest in the base camp after dinner and started climbing the last but the most difficult part of the mountain at 11pm in the midnight of the forth day. It was cold and dark, only the assistant guide and me are climbing the mountain. No one else showd up. My headache didn't get better. However, I gradually learnt how to breathe according to my own pace. In a high altitude, oxygens are rare. Normal breath cannot reach enough oxgens and I felt headache every time I breathed. Deep breath can help take more oxgens once at a time and slow down the heart beat. However, it also can slow down the pace. I've got to learn to ajust. After a few hours, teammates caught up with me. It was 1~2 hours before reaching to the rim and 2~3 hours before the summit. We then walked together. I walked between two teammates. The snow and cold wheather made the spectacles blur and frozen with ice. I can only roughly see the shoes of the teammate in front. The pace was a bit fast but I've got to catch up. The breath was also faster than my usual pace. Thankfully, I can manage the headache by letting half the brain take the oxygens. It was tiring. I also started to lose consciousness. After quite a long time, we almost arrived at the rim(known as the stella point) which is very near to the summit. The team all walked to the rim without stopping except for me who took a short break a few meters before reaching to the rim. I adjusted the breath and drank a bit more water before continuing. The headlights were shining up in the rim. They were not far, but I just felt like no energy to climb up. The assistant guide encouraged me and held my arms to walk together. People in the rim started to sing the Kilimanjaro song to encourage me as well. I felt so motivated that I climbed up with great thankfulness. The head lights were getting closer and I sang along with them"Kilimanjaro, hakuna matata". By the moment I arrived to the rim, I cannot help but hug the man who firstly greeted me with tears in my eyes(I guess that was the chief guide). That was the most touching moment in the Kilimanjaro mountain climbing experience. I also huged my teammates. Unfortunately, they were already consciousless to show happiness or tiredness. Their clothes, headlights, spectacles were all covered with a lot of ice.

Only after a short while, the chief guide asked whether we wanted to climb to the summit now or be satisfied with the rim, I said surely to climb to the top(even though I still haven't totally catch up with the breath yet). Then we started to climb. I heard it would take around 30min ~ an hour to climb to the top from the rim. That doesn't sound like a very big challenge. Unfortunately, I was behind the team only after walking for less than 10mins. I cannot remember clearly how I get to the summit. There were moments when I asked people where the summit was, when I sat down on the snow and breathed deeply, when I mistrusted the assistant guide for the direction, when there were some lights in front and the assistant guide holding my arms to move forwards, etc. It is like a miracle, but it is true that I finally arrived at the summit, 5895 meters at the Uhuru Peak of Kilimanjaro with three of my peers, the guide, assistant guide and a local porter. We quickly made some group photos just before the sunrise. Then the guide asked us to go down quickly. Along the way we walked down, I saw a beautiful glacier and it was sunrise at that moment. It is one of the most beautiful nature scenes I've ever seen. The assistant guide told me the glacier's name, but I cannot remember it clearly. Unfortunately, the camera was with the guide who walked too fast in the front. I didn't capture the scene, but I was deeply moved by its beauty, tears in my eyes. That's the second moment when I was so moved during the climbing.

The two day walking down didn't have so exciting moments. We were the first team to finish the whole trip on May 14th, 2014. There were two people finished on May 13th and one on May 12th. We are proud that we made to the peak. In the meanwhile, we learnt that team is so important to make things happen. We treasure the great experience and friendship from the professions.

Monday, 24 March 2014

Cut the Cross Down


Many things happened in the past few weeks, but I didn't record them in a consistent manner. It's like I'm carrying less burden than before, but the consequences could be pretty bad in the long run.


















Accomplishes: 

1. Finished the book "You can draw in 30 days" and managed to draw sophisticated 3D objects.
2. Finished reading the first DSLR photographing book and practised three weekends on  a second-hand Canon D7 camera. Learn everything from a scratch from Zhixing. Attended my friend, Jingping's harmonica concert.
3. Launched our Clockie app V1.0. Finished the V1.1 debugging and modification. On going for the V1.2. We consider this app to be our first experiment on how to make a real product. Besides UI and features, we are going to do some experiments on the business side as well, for instance the free-premium business model. However, since there are small issues with the current version, we still choose not to market it yet until the V1.2 comes out. 


4. Meetup with the YunReading team. Good to know that Yingbo is doing coding again on skyscanner and Aldrian is doing text mining and NLP research before going for his PHD study in the US. We are planning to open-source the YunReading project.

5. I found my new job in Visenze as a software engineer. Visenze is a tech startup specialised in image recognition. It's one of few real tech companies in SG. I was supposed to join them after my graduation. However, as Prof. Tung is so eager to make readpeer a product, I choose to finish the readpeer project first. The ReadPeer beta version is about to finish in late April including the iOS app and Android app. Though it wasn't a pleasant journey with no exposure to real clients and the business side, it is nice that the project is becoming more closed to a product. I cannot count it as an entrepreneurial experience since I've got no control over the product including the product design and decision making. A lot of useless features are included to add the complicity of the project, which is surely not my intention. I do not see myself as a lifelong software engineer, but more of a future project manager. Unfortunately, in the readpeer project, I was not given the privilege to learn new stuffs as a co-funder. I even got blamed for reading a business model book. Indeed, I lost most of my passions already when I'm more like a emotionless worker than an energetic entrepreneur that can change the world. I've got to learn more from real lean startups on how projects can be conducted, not only on the tech side, but also on the business side. I guess Visenze would be a nice place to learn when it's in a promising growing stage. For the ReadPeer project, I guess I'm already 仁至义尽. Though it might get millions of government fundings, I won't care any more. A lot of people get fundings from the government doing nothing but boasting themselves on useless projects. I'm not one of them. I'd rather do something really useful and stay passionate forever.

Losses:

I wasn't very religious in the past few weeks. Though I didn't do sinful things, I do feel myself cutting the cross down. 




Saturday, 1 March 2014

End of February

These two weeks went really quickly. All of a sudden, it is already end of the month.

There are basically two improvements worth recording.

1. In the readpeer team, we tried to do daily scrum meeting at 11am. We're clearer about the goals and we've effectively fixed miner bugs for the API as well as the App/Plugin workflow. Now, the bugs are mostly cleared and the APIs are mostly well-tested after two weeks' trials and errors. The iOS app is also progressing well, mostly because of Zijian's passion and smartness. Hopefully, we can have a demo next week for both the iOS app and the browser plugin. However, the Android app is slightly lagging. We just started integrating the APIs in the Android app. From the API design and implementation experience, I started to realize the potential security issues out there for the apps.

For Android app, it is actually pretty easy to be decompiled into codes. It's pretty dangerous to simply put the app_api_key and app_api_secret in the app without further authentication schemes. The current authentication method we use is to pass the predefined app_api_key, app_api_secret and username+password to get an unique access_token which is associated with a unique user session. Apps request for the APIs by providing the correct access_token. It seems to be useless to add on encryptions for the access_token and other keys when the app can be decompiled. Hackers can easily see the encryption methods. A more secure approach would be to add on timestamp to the access_token and cron the access_tokens in the backend every few minutes. However, that is also not good enough. What other web services, like Parse.com do is to add app identifiers,etc as additional authentication schemes. That would be nicer, however, it is also hackable especially for Android apps.  We've added SSL support for web app, however, after knowing that SSL packages also can be hacked, I realize that security can be a big issue in the long run. However, security is not the most critical thing at this moment, but the features and the UX.

We also try to create more data by ourselves on the system to make the system more appealing. That's a common trick most UGC driven companies do to make their customers more involved.

Bad thing: The network in NUS goes down very often these days, which affects our service quite a lot. Recently, the internet in the lab server is disabled by school because the owner of the subdomain gets graduated and the server cannot connect to the internet again. I've tried to persuade the prof to use DigitalOcean, however, he recently prefers to buy clustered cubietruck mini PCs partly because of the funding criteria. Honestly, that's not a wise way to go.

2. Our Pair Diary app is progressing well. I've stayed in school for quite a few times/week to work with Qiyue and Zenan. Qiyue is really really busy with lots of projects. Hope he really gets some days off to enjoy his life. Definitely, Qiyue and Zenan are very good hackers. They'll become super good in the long run. For our clockie app, Apple is reviewing it and hopefully we'll get it on app store ASAP. Can't wait any longer.

Some other stuffs worth recording: I introduced a good job to the senior designer in Beijing to come here to work. He has already passed two rounds of interviews and will fly here tomorrow to take the final interview. It's promising that he'll get the job and maybe we will work together someday to make great projects to change the world.



Wednesday, 19 February 2014

Hackathon

I attended the Facebook Hackathon last Saturday with Zenan and Qiyue. It was an awesome experience. People there are really geeky and some teams are technically very strong. Unlike other hackathons I attended which are somewhat business oriented, this hackathon consists of only developers. No business models need to get examined. I guess that's the reason why it was so geeky and fun.

The problem we want to solve is to help couples living long distances to better communicate with each other. It is painful for them to stick with each other while they cannot meet face to face very often. There are basically two needs:1. to have a unique private messaging channel where only two of them are in each other's contact. 2.to have a pair diary space that keeps track of their memorable conversations from the instant messaging channel. Zenan is really awesome in UX design and implementation. Qiyue is also very good. We managed to build the pair diary app with Pods, JSMessageViewController and Parse. Zenan finished the design and storyboard very early while Qiyue and I splited the implementation tasks into the chat+diary part and the login+pairing part. I am in charge of the chat+diary part. At the beginning, I picked a traditional tableview approach to develop the chat room which turned out to be very troublesome http://attila.tumblr.com/post/21180235691/ios-tutorial-creating-a-chat-room-using-parse-com. Later, we used JSMessageViewController which is really neat. The process itself takes too much time which slowed down our overall progress to some extent.  That's mainly due to my fault in not taking Zenan's suggestion of using JSMessageViewController earlier. Thankfully, we made the instance messaging working around the midnight and started to add on the pair diary summary feature as well as the social login and pairing feature. Around 1~2hours before the hackathon finishes, we managed to get the pair diary part working which is a big celebration.

In the end, we've made a prototype which is more or less the same as the original design by Zenan with a few unnoticeable bugs. The demo and presentation is pretty good with a lot of claps and praises. It is indeed a pretty promising prototype. We can definitely get a good prize in a normal hackathon. However, the challenge is that the other hacker teams are as awesome as us. Some are even more amazing. In the end, a team with creative UX web design standed out in the first place while two gaming teams won the second and third. In fact, I don't think the second prize team is that awesome inventing QR code for multi player access. The third prize team is the legendary NUS CS code monkeys while I guess they deserve a better rank. The team impressed me most is Xiangxin, Xiangyun,Ziwei and Eugene's kitty team though they didn't win any prize. In fact, the reason why Xiangyun attended the hackathon is to make an auto animal food monitoring machine for the lonely cat in SOC. That is so loving. One makes an auto food feeding machine with camera, wifi, infrared ray detecter simply because he finds the cat lonely and hungry asking for food around his lab. I am deeply touched.

After the hackathon, I becomes more energetic in making products. I do coding more quickly than usual. I also have a better sense of UX/UI taste learned from Zenan.

For the readpeer project, I have taken the suggestion from the Lean UX book to collect important feedbacks from reliable people every Thursday. I also redesigned the authentication method for the readpeer API while the Restful API module and OAuth2 module in Drupal rely too much on another very heavy module. In Drupal, most method in the modules are public to other modules which can take a lot of time searching for the right methods. The routing approach in Drupal also heavily relies on the hook menu settings in each module, which can also be slower than simply routing via the web server settings (Please correct me if my understandings are wrong). In terms of flexibility and reusablility, Drupal is definitely not an optimal framework. I heard something about meta programming with ruby, which sounds pretty cool. However, UX, UI, usability becomes of higher priority than the frameworks now.

For health, I haven't eaten meat for 3 weeks including the Chinese New Year. However, when the antie downstairs invited me on the Lanten Festival making meat dishes for a whole afternoon, I felt it impolite to not take a bite. However, I immediately felt like I'm gaining weight after eating the meat. Next time, I shall be more determined even facing a lot of temptations.

Keep learning and stay healthy!

Wednesday, 12 February 2014

CNY

I didn't intend to fly back home for this Chinese New Year when there are quite a lot of stuffs remaining to be done for the ReadPeer project. However, I eventually ordered the return ticket(refundable for SM2/SM3 student to fly home after graduation)in the last minute after several days' consideration.

Unfortunately, I missed the flight on Jan 29th after fixed a bug on the website. Then I changed the flight to Jan 30th and stayed in Zhixing's place for a night and fixed some more problems in the previous iOS project. Gratefully, I returned home safely in the last hour of the CNY eve.

It is quite uncomfortable to do nothing at home while I am used to work many hours a day. The first few days are more about visiting relatives and have lunch/dinner. During these days, it was more about observing. Quite a number of changes happen this year in China which affect the normal citizens.

1. Civil servants used to be one of the most desirable jobs in China. However, this year's anti-corruption activity leaded by Chairman Xi makes civil servants' life not as good. Many leaders have been dismissed and the civil servants no longer receive yearly bonus, let alone gifts. However, there are still cases where the leaders assign other people as the CEO and make money for them without affairing directly to the business. I happened to visit one brother whose boss is a village leader having a Rolls-Royce worth 10 million rmb.

2. The industry is transforming. The city I lived in is named as the China Textile City which is world's largest textile market place. Most companies are built around that industry: textile,textile machine,printing,clothing,etc. Now the traditional textile making industry is losing competitive advantages. The labor-intensive companies cannot attract cheap labors from west China to work for them when the salary is not so much higher than other cities. The printing companies even live harder because the environment agencies are taking actions to punish the pollution. However, some companies are doing pretty well by improving the quality of the product and switching to a more skill-intensive products, such as curtains. For the sales and marketing, international trading is getting more important for individual salers. However, their clients still come from normal channels such as personal connection, referencing,etc. The internet is not really helping that much, partly because the industry is still mainly maintained by the old generation whose main connection tool is cellphone. The young generation is trying more tools such as email and aliexpress. The company bosses cannot rely on manufactoring industry to make a living (indeed, most companies lose money). They transfer to real estate which might be full of bubbles.

3.WeChat is getting huge among the young generation.

4.The financial industry is changing. In some sense, China is leading the world in tranforming the financial industry. With the introduce of the innovative financial product Yu E Bao 余额宝 by Alipay, IT is again making great contributions to influence the world. Compared to 3-5% interest rate in a normal fund product, Yu E Bao has an interest rate of 6-7% which gets rid of transaction cost in banks. People now prefer to save money here instead of banks. In fact, I helped my parents save most their money into the Yu E Bao account. It is predictable that the banks will get less money to lend to the real estate investors and the banking industry can probably get healthier.

I visited my grandparents for two days where no internet is available. During those two days, I finished reading the Lean UX and wrote some lyrics. I realize that design thinking is so important. I really need to learn a lot from Lean UX teams to make productive projects. Stucking in the current team may not be a wise choice. Prof. Tung told me that the project funding is running out around end of April. I may need to find another job after finishing the mobile apps. Life is full of uncertainties. I've got to prepare for the changes.

Tuesday, 28 January 2014

Experimenting

The past week involves mostly on experimenting, somewhat similar to the experimental learning concept mentioned in the Lean Startups.

The readpeer project finally went on test by real users and we gathered feedbacks to polish the system based on real situations. Xiaoli and Prof went for meeting in Hangzhou early last week and I'm the only one who dealt with bug fixing+ web service api development+operation.

Early in the week, one senior(CTO) from Visenze(one of few real technical startups) in SG emailed me to join his company. Actually I was supposed to join his company after graduation instead of the Prof's company for a better exposure/involvement to a tech startup. However, I confirmed to Prof to make readpeer a product-standard one before moving to other projects. Now my role is almost fulfilled but I start to realize that it's not just about production design and development, but more about operation and continuous grows.  Even the functionalities and design works have fullfilled doesn't mean I'm done with the project. There are plenties of other stuffs. I told the senior that we are validating the idea and developing mobile apps right now, so I'm not ready yet but can talk to him by end of February. Kindly, he emailed me some suggestions: 1. when the product goes on public, operation(运营) becomes more crucial. 2. Do focus on one mobile platforms instead of both iOS and Android to reduce the opportunity cost. 3.when the idea doesn't work, quickly switch to other directions for validation. The suggestions are really frank.

Let me share more about the readpeer idea dispite that the Prof strongly disagree exposuring ideas to others. It was firstly about academic reading and annotation. However, we consistently seek for potential unique way out to make the system workable in real business. We started to explore the possibility of novel reading four months ago, later finding out we are not special enough to distinguish ourselves.  Then we narrowed down to script reading, which then evolve into mini movie production. The mini movie production idea can be found here: movie. readpeer.com. However, the Prof wrongly assumed that people will easily create music/posters/photo annotations out of their intrinsic motivation+some money awards. The result turned out that the cost is too high to generate such kind of highly time consuming annotations.  The first few days of market testing turned out that people are not annotating given the instructions that they have to attach originally created posters/music. In another word, this idea is Invalid. However, the Prof seems to be happy to see 10+ unique visitors coming to the site while that's certainly a bad number. Though we still haven't started really marketing the site, I started to wonder about the business model. It is impossible to make into a business if we continue believing that extending user base will be a business way out. At least, the market doesn't fit Singapore if we are targeted to people who read original created scripts and making annotations purely out of interests. I started to realize it's a business problem instead of a technical issue.

If I were only a normal employee, that would be none of my business if the business doesn't make sense. However, I guess I'm responsible enough to remind the Prof of the potential dead ends. There are possible way out like selling sub systems to enterprise customers. We will have better competitive advantages when the mobile app goes into play.

For this week's diet, I'm doing good, eating only fish vegetable and toufu, thanks to Prof.Ben's reminder. I hosted a young couch surfer yesterday and today. Unfortunately, he bought me a cup of milk tea in Chinatown last night and my stomach hurts until now...

Saturday, 18 January 2014

Polishing

I stayed in my friend Zhixing's place after polishing the last CS3217 project together with Jingping last night. We plan to publish the small app on App Store to gain some experiences as individual mobile game developers. Hopefully we'll launch a neat version for girls around the Chinese New Year.

The past week is pretty joyful, mostly on debugging and feature/UI polishing. I helped solve a crucial bug on Android TextView text selection. I also polished the website reading page JavaScripts to improve the user experience. The basic web service api also started to get developed. Last Saturday, I attended a design thinking workshop by the OrangeHive. Yangyu and I made a creative logo in the workshop and  that was an interesting experience. 

The iOS app for readpeer is getting great. Most iOS development is done by the junior, Zijian while I sometimes help solve some bugs when he encounters problems. Zijian is getting self-motivated and happy playing with iOS development. That is really great! We are expected to come up with a prototype in a month and then seek professional designers for UI polishing. It is lucky that the idea didn't die as a MVP but really going to become a product for people to use. The web client is launching next week as an experiment for market testing and bug reporting. Busy days are coming.

Another good habbit I started to form is to eat less pork and do more physical exercises every day. It is surprising to get the feedback from my peers that I looked thinner only after 1 week's time.

Too many good things happen this week and no bad news worths recording for now. Stay alert.

Wednesday, 8 January 2014

Getting Better

I started to feel more enthusiastic when the team began to have new people. We started to build Apps and I've got the chance to learn new things again!

A year 2 junior, Zijian decided to learn iOS and joined the team for internship. He is smart and quick in learning the materials. I suggested him to take CS3217 concurrently with the internship and thankfully he got the course admission. Another year 3 junior, Weiran also joined the team for internship on Android development. However, he is a bit weak in programming. Fortunately, I helped motivate him by introduce an online Android lesson on Treehouse. He now became interested in Android development. I've got some design books for him as well since he is interested in design and we've got to push him to be a tech designer. Last two weeks, I've built two simple beginner level android app running on my nexus 7. I also helped Zijian solved an important bug in his pageviewcontroller in IOS. That was a pretty good progress.

However, my real coding skills didn't really get improved in the past few months. My codes still look pretty dirty and full of bugs. Thankfully I started to learn from better programmers on maintaining high code quality. In the web project, a postdoc I worked with is an" Obsessive-compulsive disorder(OCD) patient". Well, she is not a really patient, but she is quite a perfectionist. That's actually pretty helpful for maintaining the code quality. Most of the time, my codes cannot meet her standard. Besides her, I also worked with a professional designer in Beijing and a physics PHD in Chinese Academy of Sciences who is so good in front-end programming. Their self standards are so high that I became more confident in delivering an industrial standard product.

In the web annotation project, I solved two tech problems: 1. text range selection and highlighting 2. pdf to html support. The first problem is crucial for consistent annotation data storage between different devices. That's not an easy task. I've tried a lot of ways to solve the problem. Only the current approach is considered as quite elegant. The solution relies heavily on an open-sourced javascript dom library. The second problem is also very important for academic readings. We've tried pdf.js at the beginning. However, rendering a whole document in the front end would be two expensive. Thus we changed to process the pdf doc in the backend. There was a very elegant open-sourced pdf to html project named pdf2htmlEX which will reserve every detail of the pdf document. However, it turns out to be even heavier for rendering. Thus we shifted to a lighter converter. These two major problems were solved primarily due to the help of open-sourced projects. 

Honestly, I personally don't agree with Prof.Tung in some product design ideas. I would like to eliminate unnecessary features and keep the features as less as possible, while Prof seems to overvalue the technical difficulties and would like to add too many features. I worked with the Beijing PHD on the rails version. I'm in charge of the backend and he the front end. That's a fairly good partnership. 

It was my 5th year in Singapore last December. I wrote two blogposts on Douban where no audiences read. http://www.douban.com/note/322980285/, http://www.douban.com/note/324381741/. I started to think about the past and the future. Things are quite unpredictable. It's useless to worry about future. I've got to move forward.


One problem on faith. I've always wondering about who Jesus is. In another word, "Is Jesus God?". I know from most Christians that they think Jesus is God(100% sure). And it is a fundamental basis for Christianity to recognise Jesus as the Son of God, the God and the Holy Spirit. To be a Christian/Catholics, that should not be doubtful question. There is no percentage of faith. It's either 100% or 0%. However, when I firstly read the Bible, I see Jesus as a holy man. He himself didn't explicitly claim himself as God. Words which can possibly infer his godly nature would be 1."Words become flesh".2. "I and father are one". However, these are also not strong enough to support the claim that Jesus is God. Indeed, Judaism and Islamism don't recognise Jesus as the Lord. Even some miner branches of Christianity like Jehovah's Witnesses consider Jesus's status lower than the Lord. This group of people are called Cults while their understandings are not so wrong from their own interpretation. Unfortunately, one of my friends who come from Church of Hope pitched me about his understanding. He believes that Jesus is just an instance of a so-called Son of God's class. He said his church members all believe that Jesus is not God, even not Son of God. I heard him pray in the name of the Holy Son instead of Jesus(He said Jesus is a flesh of the Holy Son, but not really God. If he is 100% God after raising from the death, his hand should not have scars). Well, I never think in his way, but I started to doubt about the credibility of the so called true believers. If they themselves cannot agree on the key beliefs, how can  they consider themselves as true Christians and others as Cults? What if they are Cults?!

Good Night!