Since I forgot to post on the class last week (or more like, too caught up in work), will do one post on both weeks at the same time.
----
Week 9 was on security. Security as a form of protection for users' data that has been entrusted to you (as simple as a password).
The ultimate test of the lecture contents is what you remember after 1 week. The 2nd half on how IBM is structured to produce security products, I didn't really pay attention. But the first half was rather interesting, especially when a typical loophole after another were revealed in class. I particularly remember the part on SQL and code injection, because that was one of the earliest security lessons on a web service I had. And maybe about password hashing for storage. And this.
I remember the first time I encountered PHP programming was in Year 1, in RH computer club. We were supposed to pick up PHP and MySQL to write a "Supper Ordering System". Of course novice projects weren't implemented, but in the implementation, one of the seniors taught me the concept of MD5 hashing. I was hooked on this simple way of protecting users' passwords, yet not being computationally complex (I still don't understand SSL, encryption keys).
Under some circumstances that are now fuzzy memories, I managed to talk to one senior on database statements. And so he taught me the need to protect against SQL injection, by escaping every string that was provided by the user — possibly using a custom layer to protect every SQL query that goes to the server.
One thing that I always believe when developing apps is that we have to have security in mind right from the start. From the storage layer, user data especially private information should be somehow protected. The best place this can be done is probably at the database interface layer.
I don't know much about securing the communication between the user and the server, but another thing is to protect your data from being tampered without the right credentials, and to prevent leaks of the same data. So the usual implementation I'd come up with is: if you have the correct credentials to access the data, I'll let you push or pull the data. And guess where this goes — database layer.
Of course, authentication and stuff is another tricky issue that needs rather in depth testing to make sure no information can be leaked. I don't know much about this, so let's leave this to the experts to say so?
----
Week 10 was on scalability. Nice, big word. And coming with it are a whole bunch of related terms like, elastic provisioning, high availability, load balancing, duplication, redundancy.
I always had an interest in scalability - of storage. In the past, when I was running a computer with a small hard disk, the numerous external hard disks that came in 40 or 80 GB, ended up being consumed very quickly. That'll probably make any person who backups regularly think "where am I going to put my next backup? a new hard disk? or do I delete some old ones to make space for the newer backups?" And the headache gets bigger when you deal with backups and shared storage across a network that you maintain alone.
Then came along NASes. And WHS (Windows Home Server - I'm a supporter of this OS). After one year of evaluating the costs-benefits of each variant (linux boxes vs headless WHS), I caved in and got a DLink DNS323. What it seemed to tell me is that the storage in this box is going to be scalable. Put in one disk, you get a 500GB NAS. Put in 2 disks, you get redundancy (duplication RAID-1) or speed (RAID-0 or JBOD). Replace disks, you can seamlessly upgrade to larger disks under RAID-1, and to your clients, it's all transparent.
WHS was even better. After WHSv1 got terminated by MS, I got a friend to buy back WHSv1 from the US, and installed it on an older desktop. The best part of WHS over linux NASes like my DNS323 was that my storage was expandable, scalable — across ANY bus type — to create a disk pool. And I didn't have to worry about storage being a limitation anymore as long as I have enough ports (money is still, data must still live in hard disks). When capacity is reached, just get a new disk, and the software automatically balances storage and duplication across the disks using certain heuristics (like associated files are kept on one disk to prevent spin-up & down across many disks or something like that). And still, to the clients, it's all transparent. (Plus I get proper windows server support for shared printers!)
But. The awesome Drive Extender software layer had been terminated as of WHS2011, but its spirit lives on, reinvented in Windows 8 Storage Spaces.
(The joys of a digital hoarder.)
As can be seen, scalability of a home NAS / server has many parallels to a web service that is accessed by many clients. In a storage environment, the resources that are needed are the physical disks, while in a web service, the resources are the app logic and database etc.
But the same concepts apply. Addition of low cost layers to the resource acquisition process: duplication of essential services (redudancy), load balancing & proper routing to the desired resource. All while being transparent to the client (same IP, same HTTP requests).
In any case, it was interesting learning about the scalability issues from a more fundamental software, hardware and efficiency point of view (like swap, RDS i.e. slow clients, and the expensiveness of threads on linux - never knew that!)
----
Noticed I like to relate what I've learnt to past experiences. Interesting.
Tuesday, 23 October 2012
Sunday, 21 October 2012
Panic state
Having real serious time management problems now.
Competing objectives of FYP, 3216, core module projects. Each with different time costs and benefits. Sounds like an optimization problem, but with unknown weights.
FYP is really stuck. The model isn't working beyond 1 cell, so optimization of fuel cell stack is not really possible in the current state. The updated scripts that I got run really slow, and the API is really complex, so I don't know where I should continue.
CS3216, just doing database for now. Although it sounds and looks very similar to VB6, VC# and .Net in general, I'm going to leave the real coding to yj and yl, since they're experienced and I think they don't want me to mess up anything, or slow anything down. Which is real likely. I don't know if it's me or what, but I just feel like I'm not doing enough for this group.
Have too much on my hands already. Feel very lost and tired.
Competing objectives of FYP, 3216, core module projects. Each with different time costs and benefits. Sounds like an optimization problem, but with unknown weights.
FYP is really stuck. The model isn't working beyond 1 cell, so optimization of fuel cell stack is not really possible in the current state. The updated scripts that I got run really slow, and the API is really complex, so I don't know where I should continue.
CS3216, just doing database for now. Although it sounds and looks very similar to VB6, VC# and .Net in general, I'm going to leave the real coding to yj and yl, since they're experienced and I think they don't want me to mess up anything, or slow anything down. Which is real likely. I don't know if it's me or what, but I just feel like I'm not doing enough for this group.
Have too much on my hands already. Feel very lost and tired.
Thursday, 4 October 2012
Peer review
So I missed the deadline for peer review... Must have been blind to not see the time but the date only... Opened IVLE at 9:02 when it closed at 9am. ARGH.
Can I do anything for it now? ><
Can I do anything for it now? ><
Tuesday, 2 October 2012
For the record
Somehow I think my response to the Case Study 2 might be a bit too hard-handed for most people. These kind of decisions are easy to make, yet hard to make.
If you know the people yourself and you've worked with them long enough, it's probably like 割肉. Slicing off a part of yourself. Yet in the overall big picture, one has to put aside this to be effective, and to follow what's left of the original idea.
The guest speaker Vincent (I think) talked about MBTI. I've actually read a lot about it for the past 7-8 years, and I fully know my tendency - INFJ. And yes I'm making drastic evil decisions even though I'm supposed to be Feeling "type".
You see, this is one of the main reasons why you don't pigeonhole people into 16 boxes. People express a tendency to express different types (or functions) at different times, but the type that people test for is the one they feel most natural with. And circumstances can get someone to behave differently. In the real world, when organizations are concerned with bottom-lines, there's not much room for people to express certain tendencies.
For example, who really cares that introverts will die if asked to do a presentation? This world is driven with an expectation that introverts need to adapt for an extraverted world.
One has to balance their tendencies and reality to survive. And reality being reality, always wins. (Of course). So what you can do, is either be in denial, or work within the constraints of reality while subtly pushing for acceptance of your own personality, a bit at a time.
Reference for anyone interested:
http://www.infj.com/INFJ_CodeCracking.htm (I love this website)
http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
If you know the people yourself and you've worked with them long enough, it's probably like 割肉. Slicing off a part of yourself. Yet in the overall big picture, one has to put aside this to be effective, and to follow what's left of the original idea.
The guest speaker Vincent (I think) talked about MBTI. I've actually read a lot about it for the past 7-8 years, and I fully know my tendency - INFJ. And yes I'm making drastic evil decisions even though I'm supposed to be Feeling "type".
You see, this is one of the main reasons why you don't pigeonhole people into 16 boxes. People express a tendency to express different types (or functions) at different times, but the type that people test for is the one they feel most natural with. And circumstances can get someone to behave differently. In the real world, when organizations are concerned with bottom-lines, there's not much room for people to express certain tendencies.
For example, who really cares that introverts will die if asked to do a presentation? This world is driven with an expectation that introverts need to adapt for an extraverted world.
One has to balance their tendencies and reality to survive. And reality being reality, always wins. (Of course). So what you can do, is either be in denial, or work within the constraints of reality while subtly pushing for acceptance of your own personality, a bit at a time.
Reference for anyone interested:
http://www.infj.com/INFJ_CodeCracking.htm (I love this website)
http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
Case Study 2: Team Dynamics
Fell asleep writing Case Study 1, so Case Study 2 has been delayed. Instead of open ended discussion, I think this time round I'll just stick to some of the points listed. (this stifles though ><)
And maybe I'd just link back to the stuff I said yesterday. That sometimes sadly people have to leave a project if their motivations aren't in alignment. Cruel fact of life for organizations that are product-focused, and not people-focused. But, how many people-focused organizations can really cater to the needs of every single member and still ship great things? As you grow, bureaucracy sets in, and the explicit list of what you can and cannot do just grows.
Why do I feel so sensitive about this? Learnt this from my HR class (engin core mod). In this age, the workforce is very mobile. They can seek employment from anywhere. We assume that the team that the company has is already a good fit, chosen by means of alignment of vision and purpose. Now as time progresses, as the company grows, we want to retain these people, but how do we do this? Companies therefore need strong retention policies, and career development programs. Note the use of "career". "Career" implies the need for the person to grow and develop lifelong skills and interests together with the company, and not just skills like MS word, presentation skills. Investment both ways must occur - to make the fit both ways even better. This is what I call a people-focused organization.
But I digress. Back to small project groups or startups (they're about the same environment, just that startups have one more motivation - to make money and build their bottom line).
One thing that we've seen so far is that execution matters in bringing an idea to life. If the idea is good, but implementation is wrong, the idea's going to be something worthless as a product. But if the idea isn't well thought-out in the first place, what good execution can we really talk about?
If they had scaled down early enough, it might not be that drastic to require a change in idea.
If it happens again, my expectation would be to attempt the work anyway, or at least inform the rest in reasonable time that he's unable to complete the work. Should follow up on a promise unless there's something really bad that happened. If I see that he has tried his best, I'll take over the work gladly if I have spare energy and time.
Understand and understanding. At all stages of the project, everyone should understand their motivation for the project. If the expectation diverges, it's important to realign everyone again to get everyone on the same track again.
At times, people do get caught up in issues, and sometimes they can't deliver what they had promised. Who knows, the next person might be me? So don't blame, but take on the work if you can. Forgive and forget. If no one can do the task, it's probably time to see if it's really that important. Or re-evaluate the priority of all the tasks to find out what's really essential.
----
Back to FYP.
And maybe I'd just link back to the stuff I said yesterday. That sometimes sadly people have to leave a project if their motivations aren't in alignment. Cruel fact of life for organizations that are product-focused, and not people-focused. But, how many people-focused organizations can really cater to the needs of every single member and still ship great things? As you grow, bureaucracy sets in, and the explicit list of what you can and cannot do just grows.
Why do I feel so sensitive about this? Learnt this from my HR class (engin core mod). In this age, the workforce is very mobile. They can seek employment from anywhere. We assume that the team that the company has is already a good fit, chosen by means of alignment of vision and purpose. Now as time progresses, as the company grows, we want to retain these people, but how do we do this? Companies therefore need strong retention policies, and career development programs. Note the use of "career". "Career" implies the need for the person to grow and develop lifelong skills and interests together with the company, and not just skills like MS word, presentation skills. Investment both ways must occur - to make the fit both ways even better. This is what I call a people-focused organization.
But I digress. Back to small project groups or startups (they're about the same environment, just that startups have one more motivation - to make money and build their bottom line).
1. Lanh said, “It would be really bad if we have a great idea but are unable to execute it successfully”.
What are your views? Which is more important - the idea or the execution? Why?
One thing that we've seen so far is that execution matters in bringing an idea to life. If the idea is good, but implementation is wrong, the idea's going to be something worthless as a product. But if the idea isn't well thought-out in the first place, what good execution can we really talk about?
2. What have you learnt about Facebook so far?Crazily hard to build for, especially if you're using it as an IFrame app. No proper ways to control what you can do. Communication between the platform and developers is often just one way, (maybe with the exception of major players like, eg Zynga?)
3. Comment on the ideas for Another Life and Fan Gang.Another Life just seemed too difficult. Fan Gang was something that seemed more managable.
4. Should the team have changed their idea for the Final Project mid-way or stuck to their original idea? Why, or why not?Of course, one of the main problems was the scope. It seemed that Another Life had too many things that we required to be done, with huge time commitment. Maybe, they could have decided on a much smaller feature set and progressively build up from there, instead of a one-shot-do-everything. Of course there are milestones that they have to meet, like basic user interactivity, and essential stuff. Key is not being too ambitious I guess.
If they had scaled down early enough, it might not be that drastic to require a change in idea.
5. List the major problems (obvious and non-obvious ones) in faced by the team? How could they have done differently and better?Could not gauge the amount of effort that they needed. Lack of time management (related to the first point). Synchronization of work (waiting on each other), eg for poster presentation, and even the framework used.
6. What did the team do right/well?Sought advice constantly. Decisive about changing to another project (so it seems).
7. What would you do if you were Jeremy on the evening of 24th April (and the deadline for the final project submission was the next day)?I would have sought eg a 1 hour discussion session earlier in the week, and understand from the rest of the group where the work remained to be done. And over the progress of that week, grasp some skills somewhere to make the app work, one feature at a time. If it's the night before, it's a bit too late I guess...
8. How would you handle a situation where one of your team members is unable to deliver on the work he/she promised because of personal problems?I have actually had this situation before, where one of the groupmates did not show up for the task and the report. To our indignation, the coordinator asked us to include his name on the report. This was such an unpleasant experience since the guy didn't contact the rest of the group regarding his absence or provide a proper explanation. Just disappeared poof.
If it happens again, my expectation would be to attempt the work anyway, or at least inform the rest in reasonable time that he's unable to complete the work. Should follow up on a promise unless there's something really bad that happened. If I see that he has tried his best, I'll take over the work gladly if I have spare energy and time.
9. What, in your opinion, are the key learning points from this case study?Might not be solely from the case study, but in general.
Understand and understanding. At all stages of the project, everyone should understand their motivation for the project. If the expectation diverges, it's important to realign everyone again to get everyone on the same track again.
At times, people do get caught up in issues, and sometimes they can't deliver what they had promised. Who knows, the next person might be me? So don't blame, but take on the work if you can. Forgive and forget. If no one can do the task, it's probably time to see if it's really that important. Or re-evaluate the priority of all the tasks to find out what's really essential.
----
Back to FYP.
Case Study 1: Get Help
Actually, this app sounded so much like an idea that I came up with for assignment 1 too. Just that it wasn't developed or even brainstormed upon as much as Let's Goal which we eventually settled upon...
So having had the answers posted on IVLE, I think most of the lessons talked about were really quite right. Sometimes developers want a feature to stand out (we have a way to store this statistic! let's have a page for it!), want to experiment with something (hey twitter bootstrap tab pills look good. how do I use it?) or sometimes it's about totally not understanding the interaction between the user and the app (oh so users actually really use it like this?)
Those stuff in brackets up in the previous paragraph, I've done it all. Pills? Let's Goal main page nav buttons. Statistic? Let's Goal ranking page (heck, even my own app requirements up there). But it's not like I've learnt from it, just that I become more aware of it, and consciously avoid it if I remember.
Anyway, the focus of this post is on the Get Help mobile app... back to topic.
----
In such a mobile app, we have certain assumptions about the user and device:
- Screen size limited (the screen's not as luxurious as iPad, that can probably use the non-mobile optimized app since graphics and stuff are barely minimal)
- Network IO limited (restrain use of hosted graphics and resources, try to be app-embedded if critical)
- Users are probably going to encounter the app via the FB app, so we assume they know "how it works"
Since this is a FB social app, we definitely need a login screen - a "Connect to Facebook" button. This is essential since the hosted data - the requests, friends - all comes from Facebook. If the user isn't a user yet, a sequence to connect to Facebook should be necessary.
The page after login/registration should lead the user to the equivalent of the website main page - where you get to enter a new request (Figure 5 in the Background document):
Small number of push requests can be used to create user engagement, eg to alert them that someone has received help. Or someone has indicated help for their help requests.
This seems like a basic featureset for a mobile app, allowing you to provide a consistent functionality for the mobile app (post requests to friends, and view friends' requests).
----
It is really weird and surprising to see some idea you had, actually being realized 5 years ago and not knowing of it...
Help app (by JG) - HOLD (or unless someone else wants to develop this with me)But it's really interesting to see that the same idea had actually been done many years back! Really super surprised...
- Allow people to post requests for help - public or only to friends
- Earn points by helping others
- Or earn points by helping ppl to help others (by forwarding requests)
- “Helped” person gets to award points to the people who helped him/her
- Points can be used as broadcast (xxx helped someone today)
- “Classifieds” allow people with more points to have their requests higher up on the global list.
So having had the answers posted on IVLE, I think most of the lessons talked about were really quite right. Sometimes developers want a feature to stand out (we have a way to store this statistic! let's have a page for it!), want to experiment with something (hey twitter bootstrap tab pills look good. how do I use it?) or sometimes it's about totally not understanding the interaction between the user and the app (oh so users actually really use it like this?)
Those stuff in brackets up in the previous paragraph, I've done it all. Pills? Let's Goal main page nav buttons. Statistic? Let's Goal ranking page (heck, even my own app requirements up there). But it's not like I've learnt from it, just that I become more aware of it, and consciously avoid it if I remember.
Anyway, the focus of this post is on the Get Help mobile app... back to topic.
----
In such a mobile app, we have certain assumptions about the user and device:
- Screen size limited (the screen's not as luxurious as iPad, that can probably use the non-mobile optimized app since graphics and stuff are barely minimal)
- Network IO limited (restrain use of hosted graphics and resources, try to be app-embedded if critical)
- Users are probably going to encounter the app via the FB app, so we assume they know "how it works"
Since this is a FB social app, we definitely need a login screen - a "Connect to Facebook" button. This is essential since the hosted data - the requests, friends - all comes from Facebook. If the user isn't a user yet, a sequence to connect to Facebook should be necessary.
The page after login/registration should lead the user to the equivalent of the website main page - where you get to enter a new request (Figure 5 in the Background document):
- "I need" box for new posts (phrasing should be consistent)
- Leads to a page to complete the new post:
- Trim the "I feel" and "Rewards" sections
- Another section for friend's requests.
- Large tappable region (of course)
- Goes into a new page with full-page details of the request.
- Needs/Rewards (as a tab/page)
Small number of push requests can be used to create user engagement, eg to alert them that someone has received help. Or someone has indicated help for their help requests.
This seems like a basic featureset for a mobile app, allowing you to provide a consistent functionality for the mobile app (post requests to friends, and view friends' requests).
----
It is really weird and surprising to see some idea you had, actually being realized 5 years ago and not knowing of it...
Subscribe to:
Posts (Atom)