It’s the 5th week, the last week before the middle term evaluation.
Oh… I’m exhausted, just having recorded my midterm presentations. It costed me about 1 wholed day to make the ppt, and 4 hours to record the video… Well my English is bad, so I have to retake it again and again. Even though the outcome isn’t very well, because after long time of working and speaking, I made my voice hoarse, my mind stupid…
First, another hard one, I’ve used a lot of time to fix bug of some async logic. :/
What I Have Done
Roughly finished the work of integrating the new Mongo data model with the signup module. Now you can create new account in Mongo, but you can’t log in yet…
Fixed the ID-6. Small defect about the login hint message, easy to fix, just adding a link will be fine. But I think there is still some room for improvement. Maybe when user filled out the form, they can be redirected to the original page. Or simply make it default to open a new page for that link, since there is still the verification work.
Fixed the ID-14, which is about the verification email. The old dashboard will sent the verification email, even if the account isn’t got created. This can be easily solved by using async library. Just simply using async.series() will do the trick.
Reimplemented the validation middleware for signup module. Again, by using async, the whole control flow is clearer now. I’ve spent most of my time on that, because I made some rookie mistakes on writing async code in Node.js.
Created and fixed the ID-29. This issue is about the reuse of typed values of validation form. If the user typed some wrong values, the old dashboard won’t cache them, so user have to type them again. Small bugs, but annoying.
What I Will Do
Complet the work of signup module, and march on auth(login logout) and profile module.
Continue improve the validation code.
Fix some more issues.
Test the Mongoose to see whether is possible for users to change the schema when the server is running. And whether that is a good idea… For details you can see this talk posted by Elliott.
Oh the 3rd week has ended, time for sum-up. It’s been a really really tough week :(
Those Mongoose living in MongoDB are so hard to catch!!!
Let it be terse and concise.
What I Have Done
I’d spent tons of my time messing around with MongoDB and Mongoose, to build the new data model for the Dashboard. This hard process really enhanced my understanding of Node and database stuff. This post are one of the fruits.
Found some bugs of the dashboard, see ID-24, ID-25.
Created one wiki page for the new data model design, and opened a talk topic to discuss some ideas about the new OpenMRS-ID.
Created a new-db branch for the mongodb development.
The second week has ended, another fun week, yeah!
So let me sum it up.
What I Have Done
Refactoring
Well, though in the last week I successfully rearranged the routing logic. When I tried to refactor other source files, I found it’s very hard, well almost impossible, to correctly refactor without any mistakes, when there is no tests.
And considering these files will most probably be replaced, so I decided to suspend the refactoring work. So I just simply used JsFormat, one plugin of Sublime Text, to format those files. So they are more readable now. :D
Fixing ID-12 & ID-22
OpenMRS uses a lot of team-work stuff, like Wiki and Jira. When people found some bugs or want to add some new functionalities, they can report it on Jira. And here is the categories for ID-Dashboard.
When I worked on the refactoring, Elliott asked me to create a new issue on it, so we can publicly track my work, and let people comment on that issue. And by that chance I found there are a lot of issues lying there waiting for development.
So I created my refactoring issue, ID-22 and picked up ID-12 and ID-19. Then successfully solved them.
ID-19 is just a simple typo fix, and ID-12 is about the session creating problem.
Elliott found that there are a lot extra sessions were created in database, and it blame to the global-navbar. Because the navbar was a sub module of the dashboard, and when other modules like Wiki want to use it, they could make a get request for dashbordHOST/globalnav and added it on themselves according to the response.
And then due to faultily designed of Dashboard, it will create session for all requests, whether they are needed or not. Hence, not only the /globalnav, but also some thing like /resource/* will create sessions. That’s terrible, it will add unnecessary pressure to the DB.
And so, I took a look into the sources, and found that, the real problem lies in the way of using express.session middleware. The source just directly used app.use() for it, this will make express to generate session for all routes.
After some searching, I found the best practice maybe store the session middleware first, and then use it when necessary. But later I found it will be a huge modification, ‘cause there are other middlware depends on session and they are used globally as well. So instead, I simply created a exception list for the session middleware as a temporary fix.
And in the process of solving this issue, Elliott told me that we can create a subApp for those submodules, and then let the main app use it. Like,
1 2 3 4 5 6 7
var subApp = express.createServer(); // don't call subApp.listen subApp.get('/some', function (req, res, next) { // do something }) // do something else app.use('/parentUri', subApp);
And now you can visit /parentUri/some.
That is a very good feature that could make less coupling. However, note that the subApp works like a middleware. So it will be infulenced by other middleware that the main app used.
Starting to Dig Mongoose
First, you need to configure MongoDB instance, and I did. The details are here.
What I Will Do
Continue to configure the db stuff, and make a guide for that.
Starting to design the basic data model with Mongoose.
Begin to study the unit testing, like Mocha and Jasmine.
So ended the first week of GSoC2014. It’s been exciting and funny, though there is some exam pressure on me :/
What I Have Done
Refactoring
I’ve broken the routing strategies into small pieces of files. Instead of placing all routes in app.js, now each router is placed in its own files
. E.G. get(/login) and post(/login) is placed under login.js. Above that there is an index.js requires all those files.
Besides these files were put into different modules as well, different module handle different business, and they are independent from each other. I’m trying to keep to make everything a module. Nevertheless some basic router were kept by the main project.
So now the whole are structure like these,
1 2 3 4 5 6 7 8 9 10 11
app.js # requires all modules specified in conf.js, and the router folder routes | index.js # requires router file | login.js | logout.js modules | index.js # requires lib | lib | | index.js # requires routes and controller | | routes # organized as the former one | | | ...
Setteled the disagreement on code style
We now officially adopted the Felix’s as the project’s code style standard. Due to some historical problems, there isn’t, at least for javascript, a code convention for OpenMRS. So maybe in the future, we’ll have our own formal code convention as well :D
For the sake of efficiency. I’m now using SublimeLinter to detect the potential problems and JsFormat to format my code.
However, in the process of refactoring, I had to be very very careful. Cause this project is somehow lack of unit testing. That’s to say, another to-do added on the list. Bonjour Mocha.
What I Will Do
I think I’ll stick to my old plan, thus:
Continue the refactoring work, move different views into their respective modules.
Clean-up a step further.
Learning the db stuff, starting to make some beta designs.