So I had a bunch of small but really cool updates which I planned to have a post for each and everyone one of them.
yeah…. well, that’s not gonna happen. It’s not that fact that I’m lazy (I am, but it’s not) – rather then the fact I prefer to add a new feature instead of writing about the ones I already have. The ideal should be 10-20% of the development time for documentation. That’s all nice on paper. In reality, I really wanted those features released. So let’s talk about what I just added:
1. README documentation
so the first item is that I started logging my progress into the README file, so you can see a short title of the main issue in each commit I’m doing. I’m not sure if the best approach but for now it’s working well for me. Whenever I have a new feature to release, I branch out in github, naming it with the feature name; I pull to my laptop, do my magic and eventually push it back; back in github I merge it to the master branch and (maybe I shouldn’t do that?) close down the branch, per github advice. Wait! I’m not done: I have an automatic script that now pull the master branch from my openshift server and then merge it with the latest master from github into a new folder on my laptop and eventually push it back to the openshift server. This script should run automatically, except from the part where I need to comment the commit. There aren’t suppose to be any merge problem as I don’t make other changes in the openshift but sometime the jenkins’ build doesn’t work properly so I need to run it manually from the openshift server. Jenkin is ahem….”Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute with Oracle“, according to wikipedia. it basically means that the server still provides service, even when the node.js server is restarting, which is cool. anyway, now each commit has a release note in the REAME file.
I hope everyone what do tags means, yes? Tags are short expressions (usually a word or two) to describe something (a topic) for easier referencing. Suppose you’re interested in Environment, it’ll be easy for you to filter all the related topics by selecting the environment tag. But who decides which tag suits the topic? that’s a terrific question, as I pondered about this quite sometime because of my policy that “Authorship isn’t ownership“. so it came down to this: anyone can add tags for a topic he wishes to promote. Read an interesting topic and you think it’s related to environment? tag it! (I should probably give you points for doing that in the future). You might be wrong or lying but I’m hoping that with enough participants, all the false tags will eventually fade out. You can always update the tags you’ve added, and you can filter topics by clicking on the tags cloud on the right sidebar, which currently shows the top-ten popular tags. Maybe it should show more or at least have a “more” button. I’ll get back to that as soon as those tags gains more popularity…
4. Fixed bug of profile-images folder deleted whenever a new version is released
When releasing the tag feature I realised, to my horror, that the profile-image folder, that was part of the www folder is being obliterated, as Jenkins simply replaces the entire project folder. doh! the solution was easy – I move the folder outside of the project folder so Jenkins can no longer touch it. Ha!
5. A basic version of responsive css layout
Following some feedbacks I got from people trying to use the service from their tablet, I prepared a basic responsive version. it doesn’t look much – but at least you can work with it. Responsive, in case you don’t know, means the css styling adjusts itself based on the screen-width so it’ll be readable on any device. There are pretty simple CSS rules that can do that but it requires a bit of a hassle as you need to check something like 8 different layouts.
6 .Escaping all input to safe-tify input, fixed bug in responsive layout, added warning for DB integrity errors
Another feedback I received was that I don’t check for code-injection. Shame on me. Really. So I fixed that. Quite easy, honestly, as I have a single function called useInput which takes whatever data the user sent me , safe-tify it, and puts it in session.input. I also checked that the uploaded profile images are actually images and not wooden horses (you never know). Other than that, I had some left-over from previous commit and since I temper with my local mysql database manually, I need to add some integrity error-check. I should really add something to email me for any error occurring on the production server. Yup, that’s important stuff
7. Coloured tags, much faster page loading and rendering
8. Fixed bug in sign-in, added email capabilities, added email confirmation
9. Use of localStorage to boost XSLT and single-image to improve performance
10. Added “forgot password” + change password features
Lastly, as I already have the email capabilities, adding the “forgot password” and “change password” were really a no-brainer.
Again, an template-based email is sent with a link that opens the “change password” page, with the hash instead of the “old password”. I got to work a bit with messages, which is cool: load the JSON of the next page, add the message to it and forward it to be rendered. that’s an awesome concept. This way I can tell after sending the “forgot password” mail, I simply return to the sign-in page (because this is where you came from, right?) with the pop-up message “email sent successfully.
OK. This was a long post. It took me about two hours to write. If I could only bring myself to write this short passage as a separate post after each commit, that would be great. until next time, cheers