@seun

I have just committed some changes. Please check and let me know what happens.

techytom:
Thanks, I'll check that now

@seun, I've fixed that

jacob05:
You are a genius Man!!! Stepping out to learn more from you man! Thumbs Up Man .. Waiting for the final and fixed version. Peace

@jacob05

Even though I might feel a little (ok drop the "a little" elated at the fact that a co-contestant step out for me, I CANNOT advise you enough to stay in this challenge. You've come this far, too far to step down for anybody and @seun has probably said it politely enough.

Like I had earlier mentioned, I am open to questions, discussions and even collaborations. So @jacob05 please push that commit now.

@Seun
You can check out my solution now. I am still cleaning stuff up. but it works.

@kadeerna,
If I read the rules well, you were meant to develop your solution with cherrypy, but from what I see from your code, you used bottle? How is that against the rules? I like your solution, its very technical, but you didnt stick to the rules if I must say

kadeerna: Repo is at http://code.google.com/p/kadeer-jambpy/

This is my stab at an implementation of a relatively scalable implementation of a read heavy app which is the case of JAMB's examination results checking website. Even though I don't support the idea of limiting the dozens of applicable tools to the problem, I have come out on the other side with 1 more language under my belt, Python.

Before the replies begin to refer to this one, I want you to understand that this implementation / solution refers to the JAMB's candidate accessible database for the SOLE purpose of checking their results. That means JAMB can have multiple versions of their databases. A few used internally, but most importantly 1 candidates check their results against.

I was prompted to enter this challenge mainly by the many arguments I have seen on the thread with majority examining the problem of JAMB's catastrophic failure in 2012 to provide read access to results for ~ 1.5million between day 0 and 2 of releasing results, as an issue simply requiring MORE servers or hosting in the cloud. Yes that could help, yes that helps, but still a far off shot from all the hundred or thousands of other things architects & designers should work on before going for that "all reliable" solution of throwing more hardware at the problem. A few examples of such an optimization are the selection of proper database table field types, use of indexes on the tables, normalization OR denormalizaion, sharding and partitioning, caching and others I will talk about in detail given time. Just a bit about proper field type now.

Using chars in place of varchars in my implementation, varchar(50) and char(50) can hold up to 50 charachters of text, but the difference is that char only uses as much space as there are characters for on a row-by-row basis. Variable row sizing might sound good at first - after all, why leave unused space to waste? The problem lies in the fact that, becasue varchars can vary in size, mysql need to calculate the length of each varchar field in a row so it knows how far to jump to get the next record. Compare that to using char as the data type, where mysql can just add 50 (in my above example) to get to the end of one field and start of another.

Another optimization is the collation type and character set used for fields. The JAMB examination result checking website is a Nigerian+English only database. Probably to vague to comprende but my point is the database stores records and charachters comprising of english alphabet letters [A-Za-z] and numbers [0-9] a few other characters [.=]. If the designer of the database knows this, why use UTF, LATIN or other convoluted character set when ASCII can do the job. Comparing an ASCII record ex "left" = "right" will be faster than comparing Unicode or some other ISO encoded string of the same u"left" == u"right". Storing ASCII "left" COULD also save more space than storing u"left".

Normalization of such a READ heavy database like JAMB's results database I feel is simple illogical and unnecessary. Why even try to do a join? Just because I can do one is not necessarily the right approach to designing large apps. As much as possible, JOINS should be eliminated because they are evil (thinking Illuminati?). Better denormalize and partition or shard against a unique consistent field key. With normalization, single tables, single databases, single instances will grow large. Many rows in tables, logs, connection and threads to manage in the case of instances are there to manage. I will try to expand on this point and few others in a subsequent reply (if need be).

The source code is also dotted with suggestions and ideas as to how the a few things will change in a real implementation.

So, this is a result of 3 days of learning and coding Python. Depends on Bottles 0.11.dev, CherryPy 3.2.2., python3_memcached-1.44-py3.2, MySQLDb, Jinja2. CherryPy might need to be patched with the latest changes to the wsgiserver3.py source. The latest changes are can be applied by pasting wsgiserver3.py in the root of the repo in the "cherrypy/wsgiserver" folder in the "site-packages".

Begin by
- Running "Create DBs" under the "db-Ops" menu on the home page,
- Generating say any number of results and cards in using the "Number of results to generate" & "Number of cards to generate" forms at the top of the home page
- Running the "Load MySQL Memory Results DB" & "Load Memcache Results cache" to load the results data into MySQL memory tables and memcache cache.

Every time you restart you mysql server, make sure to run "Load MySQL Memory Results DB".

Oh, and last word. "OFF COURSE IT'S NOT COMPLETE"

Update:
Almost forgot, uncomment 1 of lines 51, 52, or 53 of result_controller.py to select a data store repo strategy. MySQL Shards, MySQL Memory or Memcache. Need I say restart the server.

Update
Crap, had pushed the wrong db setup script. Fixed now.

dem say build website. Not novel

dirtymoney:
dem say build website. Not novel

Was that sarcasm? If it was skip this comment.

If not, I don't engage in pesky arguments.

WoW, Less Than 10mins to go,
I've updated my code with better error managagement and caching...
I also think it'd be nice to understand the theory behind my website

Orchard (My Fav fighter Killer Instinct) is a jamb result checking website that tries to speed up data access by:

1. Providing caching for subject combinations. I mean query individual values in the subjects table when you can just read it from the cache. A Combination is values a set of 4 subjects [English Language, Mathematics, Biology, chemistry]
2. Providing 1-1 relationship between candidates and scores, hence reduce latency when querying results.

I tried to keep a denial of service attack off by
1. Turning Locking browser sessions while a request is being made. This blocks requests from being made bya particular browser while another request is being processed

I tried to protect the website from xss by using jinja2. Jinja2 autoescapes html unless that feature is disabled

I also tried to control access to html verbs(GET, POST, PUT etc)

So How does it work??

Open the Config.py file, change the database
Run test.py to generate and populate database components

I'm always open to suggestions, contributions, you can fork my repo http://code.google.com/p/emergency-jamb-result-checker at any time

done my last commit before the deadline. what can I say

Its 11:00PM and I'm hungry.

Yeah comments to follow like "this no be Twitter". I know.

The deadline has been extended to 11:59pm today. Good luck!

Anybody wey win dat money no forget me oh..... One luv naija, lol!!! We dey wait for winner

Winner, am waiting 4 u

Announce the winner pls and let's pop champaigne.

CURTAIN CALL*********THE END*******************

Thanks, y'all, for participating.

Whoever wins this should not forget to come pay his/her tithe in my church.

ifyalways: Whoever wins this should not forget to come pay his/her tithe in my church.

Are you the pastress?

Past 12

nice job for making it available to those that want to learn something from it.

ifyalways: Whoever wins this should not forget to come pay his/her tithe in my church.

LOL!

We are still waiting for the winner.

And so, ladies and gentlemen, the winner is...

Where this boy called SEUN! Abeg come announce winner naw...

Even if I dont win, I am really greatful for the experience. Thanks @Seun.

It's not like I know a single thing about programming, but going by previous posts and the content of his website, I strongly believe techytom to be the winner of the contest. He seems to be a stickler for details and the most knowledgeable.

That's if techytom is a he.

@Tinyemeka: Good point. Definitely,techytom was the contestant who followed the rules of the contest most closely. He indicated interest early, updated his repo regularly, responded to feedback gracefully, and his final submission was much better for it. pystar also indicated his interest early but failed to update his repo until second-to-last day of the contest, and as a result, he discovered a bug in the final moments of the contest. kadeerna submitted his entry very late and because of this, despite his impressive intent, I'm yet to be able to run his code (he didn't have enough time to fix the issues that came up, because he submitted so late)

So the prize goes to @Techytom!!!. cool, you deserve it bro. @Seun, at least I get an honourable mention or presidential handshake abi?

pystar: So the prize goes to @Techytom!!!. cool, you deserve it bro. @Seun, at least I get an honourable mention or presidential handshake abi?

hmmm... @seun has not said so, but believe me @pystar, u really did great. I'd still luv to code wif u even if u do not win this...

pystar: So the prize goes to @Techytom!!!. cool, you deserve it bro. @Seun, at least I get an honourable mention or presidential handshake abi?

The winner has not been selected yet. I'm going to be commenting on the pros and cons of each entry for a while.

@seun, who are your panel of judges?? Or is it just you?