Uphook update #3
void main()
{
So this weekend I didn’t get as much done as I wanted to. I originally intended to spend the majority of Sunday working on the UpHook project, but... I found out Prince of Persia: 2 Thrones came out. And…it was for PC. So...I had to go "get" it. I couldn’t decompress the image because the hard drive I store my..."games" on was FAT32 and a 4.5 gig file is too big to store on it. So I had to convert my fs to NTFS. Then I decided to pop in my Northwood 3.1 GHz that I had sitting in a bag in my closet (never got around to installing it) so it'd run nice and fast. And of course I played for 4-5 hours, which just wrecked my plans for working on Uphook.
But I DID come up with some ideas.
First, I will be making a word-verification scheme to prevent people from abusing the email-based messaging and posting system.
Second, I decided that storing the entire profile data in the database might not be the best idea. The reason is because I would have to make a query for a sizeable amount of data each time a person views someone’s profile data. If I store their profile data as a webpage stored on the server and index it using a unique value, my database will only have to retrieve a list of unique UIDs (and maybe a link for their picture). This isn’t meant to be a knockoff of craigslist, but I can see the similarities between how their posting system works and how I _might_ be implementing my project. However, I am certainly utilizing it differently-- queries will turn up pictures, not just text. The email verification system will be different. The data will be in a stricter format (with clearly defined fields that must be filled).
Third, there may be a way for me to enumerate all options/restrictions such that someone's "hook" is actually encoded into a bit string. I'm not sure if it would save any overhead if the database query only has to search for bit strings rather than data in multiple fields. But it might be something I want to implement. It would certainly save space. And if I support lots of users, that alone could be beneficial. The downside is that the encoding/decoding logic has to be done through code.
Either way, I'm slowly figuring out the steps I must take to get this thing launched properly. Good thing I'm an engineer.
}
{
So this weekend I didn’t get as much done as I wanted to. I originally intended to spend the majority of Sunday working on the UpHook project, but... I found out Prince of Persia: 2 Thrones came out. And…it was for PC. So...I had to go "get" it. I couldn’t decompress the image because the hard drive I store my..."games" on was FAT32 and a 4.5 gig file is too big to store on it. So I had to convert my fs to NTFS. Then I decided to pop in my Northwood 3.1 GHz that I had sitting in a bag in my closet (never got around to installing it) so it'd run nice and fast. And of course I played for 4-5 hours, which just wrecked my plans for working on Uphook.
But I DID come up with some ideas.
First, I will be making a word-verification scheme to prevent people from abusing the email-based messaging and posting system.
Second, I decided that storing the entire profile data in the database might not be the best idea. The reason is because I would have to make a query for a sizeable amount of data each time a person views someone’s profile data. If I store their profile data as a webpage stored on the server and index it using a unique value, my database will only have to retrieve a list of unique UIDs (and maybe a link for their picture). This isn’t meant to be a knockoff of craigslist, but I can see the similarities between how their posting system works and how I _might_ be implementing my project. However, I am certainly utilizing it differently-- queries will turn up pictures, not just text. The email verification system will be different. The data will be in a stricter format (with clearly defined fields that must be filled).
Third, there may be a way for me to enumerate all options/restrictions such that someone's "hook" is actually encoded into a bit string. I'm not sure if it would save any overhead if the database query only has to search for bit strings rather than data in multiple fields. But it might be something I want to implement. It would certainly save space. And if I support lots of users, that alone could be beneficial. The downside is that the encoding/decoding logic has to be done through code.
Either way, I'm slowly figuring out the steps I must take to get this thing launched properly. Good thing I'm an engineer.
}
| Permalink | 