Uphook update #5
void main()
{
Yesterday I created the encoded strings for the database so all it has to do is transfer an obscure string for queries. The decoding will likely be part of the php (as opposed to JavaScript). This is simply to avoid storing a large amount of actual data in the database.
I also created the tables for both users and their respective hook data. I left several open fields in case in need to expand at a later time. But for now, I'm keeping everything quite simple. The first release will be a Beta, and upgrading can always come later if the site is getting positive feedback.
Yesterday, I also explored the possibilities of including a captcha for the user input to deter automatic scripts and mass spammers from posting crap on Uphook.
Today, I modified an open source captcha library and integrated it with my temporary user input script. But I ran into a possible problem:
A unique specification of my site is that there won’t be any registering-- so I decided to use the captcha on the homepage. That way anyone who wants to sign up wont have to navigate away from the homepage to verify that they aren’t spammers. I also programmed my scripts to delete the captcha images and keys from the server after each successful or failed access.
What this means is that the only way captcha images can accumulate on the server is if someone visits the site and does NOT attempt to post their data. Unfortunately, I anticipate that the vast majority of visitors will NOT be posting. In sites like this there are always more spectators than participants. In fact, that’s what I was counting on. Also, the aspect of transferring an image from the server to the client for each page view doesnt really appeal to me. So I have 2 choices:
1- Forget about the space and transfer problem. My captcha images run about 1.5 kb a piece (little jpegs). Maximum anticipated 5000 users a day. Times 30 days equals over 200 megabytes transferred per month for the captchas. My monthly payload size restriction is a total of 5 gigabytes. It won’t kill me to transfer an image per page view. As for space, I can modify my scripts to delete all images that have been on the server for more than 10 minutes (or 30).
or
2- Ajax the images such that only users who are filling out the form are presented with the captcha verification routine-- all done without actively reloading the page. This would save a couple of megabytes of bandwidth. Plus Ajax seems kinda neat to work with. But doing this would take more time (since I'd have to learn how to use it properly).
I believe the first choice is the best. There is a definite time/effort vs. gain/efficiency relationship that points heavily toward ignoring space and bandwidth for such a small image.
The next step is the preliminary interface design. After which, I will integrate and complete the post functionality. Next will be the search functionality complete with database integration (MySQL Server)
We're making progress!
}
{
Yesterday I created the encoded strings for the database so all it has to do is transfer an obscure string for queries. The decoding will likely be part of the php (as opposed to JavaScript). This is simply to avoid storing a large amount of actual data in the database.
I also created the tables for both users and their respective hook data. I left several open fields in case in need to expand at a later time. But for now, I'm keeping everything quite simple. The first release will be a Beta, and upgrading can always come later if the site is getting positive feedback.
Yesterday, I also explored the possibilities of including a captcha for the user input to deter automatic scripts and mass spammers from posting crap on Uphook.
Today, I modified an open source captcha library and integrated it with my temporary user input script. But I ran into a possible problem:
A unique specification of my site is that there won’t be any registering-- so I decided to use the captcha on the homepage. That way anyone who wants to sign up wont have to navigate away from the homepage to verify that they aren’t spammers. I also programmed my scripts to delete the captcha images and keys from the server after each successful or failed access.
What this means is that the only way captcha images can accumulate on the server is if someone visits the site and does NOT attempt to post their data. Unfortunately, I anticipate that the vast majority of visitors will NOT be posting. In sites like this there are always more spectators than participants. In fact, that’s what I was counting on. Also, the aspect of transferring an image from the server to the client for each page view doesnt really appeal to me. So I have 2 choices:
1- Forget about the space and transfer problem. My captcha images run about 1.5 kb a piece (little jpegs). Maximum anticipated 5000 users a day. Times 30 days equals over 200 megabytes transferred per month for the captchas. My monthly payload size restriction is a total of 5 gigabytes. It won’t kill me to transfer an image per page view. As for space, I can modify my scripts to delete all images that have been on the server for more than 10 minutes (or 30).
or
2- Ajax the images such that only users who are filling out the form are presented with the captcha verification routine-- all done without actively reloading the page. This would save a couple of megabytes of bandwidth. Plus Ajax seems kinda neat to work with. But doing this would take more time (since I'd have to learn how to use it properly).
I believe the first choice is the best. There is a definite time/effort vs. gain/efficiency relationship that points heavily toward ignoring space and bandwidth for such a small image.
The next step is the preliminary interface design. After which, I will integrate and complete the post functionality. Next will be the search functionality complete with database integration (MySQL Server)
We're making progress!
}
| Permalink | 