Checking the user agent on incoming requests to prevent session hijacking is sort of like putting scotch tape on your door to keep intruders out of your house.
But, it is one little extra barrier that an attacker will have to bypass, so I put it in my code. Then I was playing around on my site in IE8 one day, and just for fun I hit the Compatibility View button. And it broke everything.
Clicking this button toggles the user agent between IE7 and IE8 and thus breaks the whole thing. To make sure the site still works, I've taken the user agent checking completely out of the application.
This still won't allow anyone to hijack a session, because all traffic, including cookies, is sent only over SSL. There are a number of other security features built in, so the scotch tape can come off.
Nov 9, 2010
Nov 1, 2010
Beta Is Imminent
I have enough features coded to start beta testing. The software is still not complete; there are a few holes in the functionality, and there are a few known bugs, but I’d like to get a system up and running on the live web server at Dreamhost so I can iron out any deployment issues far in advance of the launch date.
Here are a few particular things I’ll be watching for:
Problems with SSL. I’m currently hosting jQuery and jQueryUI on Google, and those requests are non-encrypted, so I’m curious to see if that will work, or if I’d be better hosting jQuery locally.
PHP Configurations. I’m setting PHP configurations directly in my scripts; I’ll look into the possibility of installing PHP from binaries and configuring those settings directly in php.ini.
Performance. There are three concerns here. First, the wire transfer speed (what a technical term). I know that there are more HTTP requests on my pages than there needs to be. Combining CSS and JS, as well as using image sprites, will reduce the number of concurrent requests, but I haven’t done these things yet. Some pages are very JavaScript intensive and I’m interested in the client performance on older machines. Lastly, I have some rather complex SQL queries, and I’d like to see how the database performs when n gets big.
Usability. How easily will people be able to figure out how to use the software to perform specific tasks?
Unknown Bugs. I’m mainly looking for logic errors here. For example, today I just discovered that members cannot change their own passwords because they don’t have setSecurityRole permission.
File permissions. I want to make sure that users only have access to the files they need access to. On my development machine, all folders are writable, but that won’t be the case in production.
I just set up the SSL certificate on my server today. I anticipate launching beta by Wednesday!
I'd like to introduce my brother, the eminent psychologist, Niles Crane.
Frasier was eminent when my eminence was merely imminent.
Here are a few particular things I’ll be watching for:
Problems with SSL. I’m currently hosting jQuery and jQueryUI on Google, and those requests are non-encrypted, so I’m curious to see if that will work, or if I’d be better hosting jQuery locally.
PHP Configurations. I’m setting PHP configurations directly in my scripts; I’ll look into the possibility of installing PHP from binaries and configuring those settings directly in php.ini.
Performance. There are three concerns here. First, the wire transfer speed (what a technical term). I know that there are more HTTP requests on my pages than there needs to be. Combining CSS and JS, as well as using image sprites, will reduce the number of concurrent requests, but I haven’t done these things yet. Some pages are very JavaScript intensive and I’m interested in the client performance on older machines. Lastly, I have some rather complex SQL queries, and I’d like to see how the database performs when n gets big.
Usability. How easily will people be able to figure out how to use the software to perform specific tasks?
Unknown Bugs. I’m mainly looking for logic errors here. For example, today I just discovered that members cannot change their own passwords because they don’t have setSecurityRole permission.
File permissions. I want to make sure that users only have access to the files they need access to. On my development machine, all folders are writable, but that won’t be the case in production.
I just set up the SSL certificate on my server today. I anticipate launching beta by Wednesday!
I'd like to introduce my brother, the eminent psychologist, Niles Crane.
Frasier was eminent when my eminence was merely imminent.
FogBugz World Tour
Last Thursday, I had a chance to see Joel Spolsky at his Minneapolis stop on the FogBugz World Tour. I’ve been following Joel’s blog and businesses for the last ten years, and it was cool to see him speak in person. He was in town to pitch the latest version of his FogBugz and Kiln software.
I’ve been using FogBugz as a bug tracking and project management tool for the last six months, and I really like it. Luckily, I can get a free license as a one-person startup. Past that, it gets quite expensive. That shouldn’t be a problem, however, as I don’t ever anticipate adding employees.
I’ve been considering using distributed version control for a while. For development teams, there are no questions about its superiority to traditional version control systems. But I haven’t found a real need for any type of VCS yet. I keep daily backups of all of my projects, so I can go back in history to whenever I want.
The one thing that does get a bit more complicated is when I’ll have different versions of the codebase – one for dev and one for production. The branching capabilities of Mercurial would definitely help me out there, but I’m not sure it’s worth the half day investment it would take to configure and learn it. I’m pretty focused on my ship date at the moment, and this is one of those things that I feel can wait.
I’ve been using FogBugz as a bug tracking and project management tool for the last six months, and I really like it. Luckily, I can get a free license as a one-person startup. Past that, it gets quite expensive. That shouldn’t be a problem, however, as I don’t ever anticipate adding employees.
I’ve been considering using distributed version control for a while. For development teams, there are no questions about its superiority to traditional version control systems. But I haven’t found a real need for any type of VCS yet. I keep daily backups of all of my projects, so I can go back in history to whenever I want.
The one thing that does get a bit more complicated is when I’ll have different versions of the codebase – one for dev and one for production. The branching capabilities of Mercurial would definitely help me out there, but I’m not sure it’s worth the half day investment it would take to configure and learn it. I’m pretty focused on my ship date at the moment, and this is one of those things that I feel can wait.
Oct 18, 2010
Six To Eight Weeks
I'm slowly but surely making my way toward beta testing. I have all of the core functionality for events done, and now I'm adding the polish. I'm taking the mantra, "do one thing extremely well," to heart. Attendance is the only thing the software does, so it needs to be an extremely polished experience all around.
I've added some really neat AJAX effects, so the past week has been spent learning AJAX and JSON, hitting some roadblocks, and finally getting the thing looking pretty polished.
I just need to add two quick validation rules to members and eventtypes to prevent XSS. All data is htmlspecialchars cleaned before it is printed to the view, but JSON data must be htmlspecialchars_decode'd, which means that I need to make sure the data itself is clean. Member names and event type names are sent in the clear as JSON objects, which is why the extra validation is needed.
There is one more thing I could do to improve performance. I'm currently loading JSON objects to populate the event calendar one month at a time. When the user navigates to a new month, it's a new AJAX call. But it would greatly improve performance if I loaded several months at once. That fix should not be too difficult, and it's definitely on my list. More polish.
It's all this polish that takes so much time, but is definitely worth it. The best part of my software is its simplicity and ease of use. This I can not compromise on.
The other thing that was on my mind today was that the signup form does not look incredibly enticing. I'm going to start looking at signup forms for other webapps to get inspiration on how I'd like to design mine.
I have decided that my marketing website does not need to look like the app itself. Most webapps have a completely distinct marketing site. I might even be able to keep my current template for my marketing page, and link people over to the signup page on my app when they click the signup button.
I've added some really neat AJAX effects, so the past week has been spent learning AJAX and JSON, hitting some roadblocks, and finally getting the thing looking pretty polished.
I just need to add two quick validation rules to members and eventtypes to prevent XSS. All data is htmlspecialchars cleaned before it is printed to the view, but JSON data must be htmlspecialchars_decode'd, which means that I need to make sure the data itself is clean. Member names and event type names are sent in the clear as JSON objects, which is why the extra validation is needed.
There is one more thing I could do to improve performance. I'm currently loading JSON objects to populate the event calendar one month at a time. When the user navigates to a new month, it's a new AJAX call. But it would greatly improve performance if I loaded several months at once. That fix should not be too difficult, and it's definitely on my list. More polish.
It's all this polish that takes so much time, but is definitely worth it. The best part of my software is its simplicity and ease of use. This I can not compromise on.
The other thing that was on my mind today was that the signup form does not look incredibly enticing. I'm going to start looking at signup forms for other webapps to get inspiration on how I'd like to design mine.
I have decided that my marketing website does not need to look like the app itself. Most webapps have a completely distinct marketing site. I might even be able to keep my current template for my marketing page, and link people over to the signup page on my app when they click the signup button.
Oct 7, 2010
Tea, earl grey, hot.
The end is in sight on my web-based attendance software! I'm on track to start beta testing in December. I'm been blogging less in order to spend more time on development. I feel like I'm on the home stretch.
Sep 30, 2010
I Love This Pricing Page
http://chargify.com/pricing-and-signup/
I spent about an hour last night doing some good QA on the system and found about five bugs. I wish I had more time for QA! Today I spent about 2 hours at the library fixing the bugs. I also looked into recurring payment processing systems, and chargify looks like the one I'll go with.
Oh yeah, I want my pricing page to look just like this!
I spent about an hour last night doing some good QA on the system and found about five bugs. I wish I had more time for QA! Today I spent about 2 hours at the library fixing the bugs. I also looked into recurring payment processing systems, and chargify looks like the one I'll go with.
Oh yeah, I want my pricing page to look just like this!
Sep 29, 2010
Countdown To Launch
I knocked out about ten FogBugz items tonight. Some of these were things that I fixed and forgot to close, some I decided not to fix because I'm going a different direction with the app than I originally planned, and some were simple fixes to the code.
I'm finding that I'm overestimating the time required for most of my FogBugz issues by a factor of two. FogBugz says there are 238 remaining hours in my project; I think the actual completion time will be much less.
On the Events Index page, I need to make the search filter, which will be a bit more complicated than it was for the Members Index page. After that, I need to work on Event Types (creating, reading, updating, and deleting).
I'm very happy with the new visual design I've been working on. It's mostly all done, including the icons and buttons, but I'm sure I'll be making a few tweaks to it along the way.
So I realistically think that I can finish Events and Event Types by the end of next week.
Then, it's on to designing the calendar and main attendance screen. I'm blocking off the entire month of October for that.
November is reserved for creating the actual attendance reports.
Then I'm done! The first two weeks of December will be spent on deployment, and then beta testing can begin.
Since this is a web app, I don't need to have every last feature coded by launch day. For example, Consolidate Event Types was a rather fringe feature that was VERY useful to people who needed it, but not many did. Things like this I can leave out at first and code them later.
I'm happy to say that security has been a very big part of what I've been doing all along - the system seems rather unhackable to me - but I'd love some quality QA to prove me wrong (or better yet, prove me correct).
Beta in December!
I'm finding that I'm overestimating the time required for most of my FogBugz issues by a factor of two. FogBugz says there are 238 remaining hours in my project; I think the actual completion time will be much less.
On the Events Index page, I need to make the search filter, which will be a bit more complicated than it was for the Members Index page. After that, I need to work on Event Types (creating, reading, updating, and deleting).
I'm very happy with the new visual design I've been working on. It's mostly all done, including the icons and buttons, but I'm sure I'll be making a few tweaks to it along the way.
So I realistically think that I can finish Events and Event Types by the end of next week.
Then, it's on to designing the calendar and main attendance screen. I'm blocking off the entire month of October for that.
November is reserved for creating the actual attendance reports.
Then I'm done! The first two weeks of December will be spent on deployment, and then beta testing can begin.
Since this is a web app, I don't need to have every last feature coded by launch day. For example, Consolidate Event Types was a rather fringe feature that was VERY useful to people who needed it, but not many did. Things like this I can leave out at first and code them later.
I'm happy to say that security has been a very big part of what I've been doing all along - the system seems rather unhackable to me - but I'd love some quality QA to prove me wrong (or better yet, prove me correct).
Beta in December!
Sep 25, 2010
Sep 22, 2010
Redirect Thingy Working!
After 2 1/2 days of work, the redirect thingy is working!!!
There is an array in the abstract controller class with an array called $redirectPageIds. This is an index of pages to which POST requests should be redirected. See either members->profile or events->profile (along with the views) and groups->update for example implementations.
There is an array in the abstract controller class with an array called $redirectPageIds. This is an index of pages to which POST requests should be redirected. See either members->profile or events->profile (along with the views) and groups->update for example implementations.
Sep 20, 2010
FogBugz # 59
Check out the following places that I screwed up in the code:
Tabby::getRedirect
Tabby::setRedirect
Controller->__construct
members->profile
groups->update
Trying to get the redirect thingy to work. Foolish to think I could do it in an hour at the end of the day. Two hours in the morning on a fresh brain should kill the bug.
I want to implement this before I get too far because a lot of other features will depend upon it.
I also came up with a good UI idea for filtering and reporting similar to what FogBugz has. See the file I made called filters_reports.txt in the documentation folder.
Tabby::getRedirect
Tabby::setRedirect
Controller->__construct
members->profile
groups->update
Trying to get the redirect thingy to work. Foolish to think I could do it in an hour at the end of the day. Two hours in the morning on a fresh brain should kill the bug.
I want to implement this before I get too far because a lot of other features will depend upon it.
I also came up with a good UI idea for filtering and reporting similar to what FogBugz has. See the file I made called filters_reports.txt in the documentation folder.
Next Step
The next step is to create the Events index page. The calendar should go on here so we should figure out how we want the calendar to act as well. Perhaps now would be a good time to mock up the main screen and the attendance report screen so we can give the whole app a consistent look and feel.
Deleting Groups
Deleting Groups is a bit tricky.
Currently, if a group contains members, I don't allow the user to delete it. In the future, I'll provide a nice GUI for users to either reassign or delete members who belong to a group they want to delete. All members must belong to at least one group.
If there are events tied to a group, this gets trickier. Suppose the user wants to delete a group. The system searches for all events assigned to that group. If the event is tied to other groups as well, the system unassigns the event from the group to be deleted, but keeps it assigned to the other groups. The system also keeps all attendance marks associated with that event.
If the event is not assigned to any other groups, the system will delete the event, along with all attendance marks assigned to it. This seems to be working correctly but it could probably use a few quality hours of QA testing.
Currently, if a group contains members, I don't allow the user to delete it. In the future, I'll provide a nice GUI for users to either reassign or delete members who belong to a group they want to delete. All members must belong to at least one group.
If there are events tied to a group, this gets trickier. Suppose the user wants to delete a group. The system searches for all events assigned to that group. If the event is tied to other groups as well, the system unassigns the event from the group to be deleted, but keeps it assigned to the other groups. The system also keeps all attendance marks associated with that event.
If the event is not assigned to any other groups, the system will delete the event, along with all attendance marks assigned to it. This seems to be working correctly but it could probably use a few quality hours of QA testing.
Sep 17, 2010
My Brain Hurts
OK, I'm viewing and editing events, and I'm finally assigning and unassigning them from groups too!
I have to go revisit the Delete Group functionality now. When a user deletes a group, I now have to make sure that any event assigned to that group is unassigned. Also, I must ensure that if an event was assigned ONLY to the group being deleted, that event gets deleted as well.
When attendance marks enter the picture, I'll need to make sure that attendance marks tied to events being deleted for any reason are deleted as well.
I added a bunch of other stuff into FogBugz and my use cases that are much too technical and detail-y to write here, but needless to say, my brain hurts!!
I estimate this bit of stuff to take between half a day and a full day to code and test.
I have to go revisit the Delete Group functionality now. When a user deletes a group, I now have to make sure that any event assigned to that group is unassigned. Also, I must ensure that if an event was assigned ONLY to the group being deleted, that event gets deleted as well.
When attendance marks enter the picture, I'll need to make sure that attendance marks tied to events being deleted for any reason are deleted as well.
I added a bunch of other stuff into FogBugz and my use cases that are much too technical and detail-y to write here, but needless to say, my brain hurts!!
I estimate this bit of stuff to take between half a day and a full day to code and test.
Sep 16, 2010
Traffic!
Doubling my advertising budget has greatly increased the traffic to my bestattendance.com website. The conversion rate on my pay-per-click ads is about 10%, which I think is quite good. There will be about a month of lag time before these downloads convert to sales.
After the website redeign, I've increased my position on Google search results. I was already quite high in Bing and Yahoo. Organic traffic has therefore increased as well.
The next obvious step is to expand my site by adding more resources to it. Either articles, attendance forms, slideshows, or other resources will help with SEO and even further grow organic traffic. I've set a goal to produce two new resources for the site each month.
Traffic to highschoolwebdesign.com has increased greatly as well. I get over 5,000 unique visitors a month to that site, and traffic levels are still growing. I haven't done anything to monetize the site yet - it is just a free resource for teachers now, although I might implement some monetization plans soon. Everything is ready, I just basically have to pull the trigger.
I'm still struggling with what the purpose of that site is. Is it to provide a service to teachers or is it to make money? The two are not mutually exclusive, of course, but I feel a definite lack of a clear vision for that enterprise.
I've recently decided that mini-sites will be a big part of my marketing strategy moving forward. My attendance software is used in many niches. Rather than consolidating all of the marketing messages into one site, I'm going to try separating them out and let each niche compete on its own.
After the website redeign, I've increased my position on Google search results. I was already quite high in Bing and Yahoo. Organic traffic has therefore increased as well.
The next obvious step is to expand my site by adding more resources to it. Either articles, attendance forms, slideshows, or other resources will help with SEO and even further grow organic traffic. I've set a goal to produce two new resources for the site each month.
Traffic to highschoolwebdesign.com has increased greatly as well. I get over 5,000 unique visitors a month to that site, and traffic levels are still growing. I haven't done anything to monetize the site yet - it is just a free resource for teachers now, although I might implement some monetization plans soon. Everything is ready, I just basically have to pull the trigger.
I'm still struggling with what the purpose of that site is. Is it to provide a service to teachers or is it to make money? The two are not mutually exclusive, of course, but I feel a definite lack of a clear vision for that enterprise.
I've recently decided that mini-sites will be a big part of my marketing strategy moving forward. My attendance software is used in many niches. Rather than consolidating all of the marketing messages into one site, I'm going to try separating them out and let each niche compete on its own.
Sep 15, 2010
What A Great Deal!
One of the podcasts I listen to is Startups for the Rest of Us. On this week's show, they mentioned a service called AppSumo, which aggregates deals to web-based software and services.
One of the deals this week was to get $100 of Grasshopper services for only $15. This means that my first six months are free, and I only pay $9.95 per month after that. I really could not pass that up.
So now I have a sales phone number on my website! It's currently configured to go straight to voicemail, but perhaps I'll actually start taking calls. I'll just have to feel it out as I go.
Another thing they mentioned is that marketing is not a TASK TO BE COMPLETED, but a CONTINUAL PROCESSES. I totally agree with them. Even though I'd love to have my head in code all day, I just can't push off marketing until the end. It has to happen continually.
In the past two months, I've made some quite simple marginal improvements that have increased my traffic by a factor of at least two, increased by the CTR on my ads by a factor of two, and increased my download rate by about another factor of two. In theory, I should see sales go up by a factor of 8 in the coming months from these changes.
One thing that has NOT changed is my downloads:sales ratio. This is being addressed by creating a web app instead of a desktop app. Changes in pricing will further increase revenue. But really, the point is that all of these changes were small and incremental. It is only over time of continuous improvement that it affects the bottom line.
One of the deals this week was to get $100 of Grasshopper services for only $15. This means that my first six months are free, and I only pay $9.95 per month after that. I really could not pass that up.
So now I have a sales phone number on my website! It's currently configured to go straight to voicemail, but perhaps I'll actually start taking calls. I'll just have to feel it out as I go.
Another thing they mentioned is that marketing is not a TASK TO BE COMPLETED, but a CONTINUAL PROCESSES. I totally agree with them. Even though I'd love to have my head in code all day, I just can't push off marketing until the end. It has to happen continually.
In the past two months, I've made some quite simple marginal improvements that have increased my traffic by a factor of at least two, increased by the CTR on my ads by a factor of two, and increased my download rate by about another factor of two. In theory, I should see sales go up by a factor of 8 in the coming months from these changes.
One thing that has NOT changed is my downloads:sales ratio. This is being addressed by creating a web app instead of a desktop app. Changes in pricing will further increase revenue. But really, the point is that all of these changes were small and incremental. It is only over time of continuous improvement that it affects the bottom line.
Subscribe to:
Posts (Atom)