This weekend was working week, as we stayed back in school from Friday to Saturday to work. We also met up on Sunday to work on the report and the application. Unfortunately, I don't think we accomplished much. On the other hand, we managed to have a framework of how the app is going to be like, so we all have a clear idea of what to work on.
Frankly, I feel that we didn't accomplish much because we were battling with Facebook SDK. Not Facebook API, mind you. We were stupid at some points in time (e.g. forgetting to include the permissions, script to connect to the javascript SDK - Chun Teck reminded us on this), but some problems were just pure bad luck - like how school internet is slow, so we only managed to get the JS SDK to work half the time. The PHP queries also kept timing out because of this. Also, I had followed the instructions for the iframe canvas app by looking at the signed request through the POST function, but it was not viable for our canvas app. I found that it works better if we had found the signed request through the PHP SDK instead, reason being that in our app, we actually have different pages to navigate to, so the POST request will end up being lost. (Jin Guan found this bug) I think at one point in time, I was quite tempted to write a wrapper to access Facebook API.
My job in the project is to manage the database, and after writing wrappers and wrappers to query the code, I'm quite tired of it. But I'm not a HTML/CSS/JS/jQuery/AJAX expert, so I'm leaving those to the rest of my team-mates who are doing very innovative things. I'm impressed by even the smallest thing my groupmates do, like changing the colour of the input field when it is in focus. Such things really do help to improve the UI of the app. Unfortunately, due to the existence of different browsers (we have a Safari user, a Firefox user, and two Google chrome users) and the need to ensure compatibility, we sometimes face a lot of difficulties in ensuring that the same UI is shown.
Wednesday talks were interesting. I heard the first talk, or at least parts of it (the achieving potential part), during CS3217, but the delivery was different. The second talk I don't really remember much, but mainly because I've heard of Scrum before, so it wasn't as educational to me. On the other hand, I was comparing Scrum with our CS3217 working habits. The checking-with-each-other part (on what we're going to do etc.) is something that me and Yujing do a lot, and I think it's a good habit to have. Unfortunately, it might not be as easy to implement it in other groups, especially people whom I am not very close to. We'll see how the other two projects go then :)
The third talk probably interested me best, as I knew the speaker from CVWO. I concurred with a lot of his experience, probably because I have had similar experience, although I have never worked with Jon Low before. I agree that sometimes when projects don't turn out well, we might end up ignoring what the person says, but it's really important to listen just in case that person says something intelligent as well.
Saturday talks were well-done also. The presentation talk pointed out something rather obvious to us - it's the message that is more important than whatever interesting slides you have, and I think this is something most people forget. For me, the audience's understanding is very important, and I tend to panic during presentations if I see a blur face in the crowd, so subconsciously, I must admit, whether the audience understands what you are saying really matters in a presentation.
The next talk was a Photoshop talk, which was less hands-on because Su Yuen talks very fast, but I didn't have Photoshop anyway, so it was okay. She gave a lot of interesting tips on design, and a lot of her demonstrations were something that we all could do, even coders. This is actually quite useful for my team, as all four of us are coders.
During lunch, Su Yuen also sat down with us and mentioned something rather obvious to us when we mentioned that we had a group of all-coders - "If all four people are coders, you obviously don't do a game", so part of me is happy that we were subconsciously smart enough to not do a game for our first assignment.
The last talk was on Javascript, and I think even though his to-do list is small, it's actually very nicely-coded. The slide-up and slide-down transitions also make the application more dynamic-looking. Also, there are little details like changing the mouse cursor which I didn't really notice, but kudos to Angad for paying attention to all these little details. I realised that a lot of effort can go in to make even the smallest application and to be honest, I feel that I don't have what it takes to do that, mostly because I tend to think of the general design instead.
I haven't mentioned about what my group is doing, but I'm pretty sure that everyone (or at least the tutors and Colin) will know when we submit our mid-assignment submission. Something else that I can mention is the fact that instead of using Git, we are using Mercurial instead. There's not a lot of reason why we're using Mercurial, but it is pretty similar to Git, and as long as it gets the work done, no harm right? I also heard that the GUI for Mercurial is better, but when I was using Git, I didn't use the GUI version so there's no basis for comparison. Anyway, we were added to the CS3216 organisation pretty late, so we didn't know we were supposed to use Git. I think perhaps, the good part about using Git for this assignment is because the Facebook PHP SDK is in Git, so it makes it easier for you to update it (when you add it as a submodule to your Git repository).
Yeah the Facebook SDK is giving a lot of people a lot of grief. Facebook is a prime example of a major project done Agile style, and from a developer's point of view that can sometimes result in wonky behavior.. and MUCH WORSE.. API changes.
ReplyDeleteThis means that if you do a FB project you might expect stuff to break at the worst moments, and then rush to deal with it.
BTW I really liked your previous posting with the favicon generator and the MySQL Workbench. :)
Thanks Prof!
ReplyDeleteHaha, I think they changed their API from something much worse to the current one, so I guess we can't complain as much as the previous batches.
I have a bit of a complaint to make though. My team-mates don't have their iPads yet, so it's a bit hard for us to do the iPad/Facebook Seminar.
Oops! Sorry for talking too fast. Will take note for future talks I give. In future if I'm too fast, feel free to put up your hand and tell me to slow down.
ReplyDeleteThanks for feedback!