Vacation

Yesterday and today are spent getting ready for my Grand Canyon trip. I'll be gone until August 2nd. See you then.

Members

The signup and login functionality are both complete and I am turning my attention to members. Creating, reading, updating, and deleting. I'm very excited about some graphic desing ideas I have for the app. I'll need to hire a designer to create the art but I have a good idea of how I want it to look. Sort of grungy. It should be fun to use.

Slideshare

I am currently evaluating Slideshare for use on my website. It allows you to sync audio with PowerPoint presentations and share them online. This might be a great way to demonstrat the features of my software.

Sustainable Competitive Advantage

Customers tell me that they love the simplicity and ease of use of my desktop product. That is definitely my competitive advantage. My number one goal for the web app is to maintain that at the expense of everything else. I'm taking the 37signals approach to simplicity.

I won't have a lot of time to work on the app in the next three weeks. I'm leaving on a trip to the Grand Canyon this Saturday, and much of this week will be spent preparing for that. I also want to get things finalized for the school store next fall and at least have some idea of how to start curriculum planning, which I'll do in August.

I'm also going to take a day this week to just do nothing except read a good book, becuase I haven't really had a down day on my summer vacation yet. Not that I'm complaining; I like being busy!

Update For Thursday

All of my tests for New Account Signup passed. I'm now enhancing the feature for members with multiple accounts. After biking this morning, I spent some time at the garden and then ran some errands in town. It's 2:00 now so I'll have a few hours to work on the program this afternoon.

First Feature Complete: New Account Signup

I'm done coding my first feature, New Account Signup. This one was a bit tricky because it involved validating three models, saving to three database tables, and redirecting to a page before completing the operation. I think most features will be a lot easier to code than this one was.

My task for tomorrow is to write a ton of test cases to exercise the moderately convoluted logic. Then it's on to creating members.

I spent a good part of yesterday and today in St. Cloud. Tomorrow I'll be at school half of the day working on the store and then going to the college to get my badge. I'm leaving for the air show on Friday; this will be a short week indeed. Next week I'll be getting ready for my two week trip to the Grand Canyon. Then it will be August and time to start planning and updating curriculum.

I'm Inserting Stuff!

I'm making a lot of progress on my first feature, Sign Up For New Account. The system is creating a new organization, group, and member. The database inserts with parameterized queries are working wonderfully! PDO is a very nice tool to work with; I'm glad I chose it over mysqli, and I'm glad I'm not using a third party abstraction layer.

This will probably the last I work on the system until Monday.

One reason for blogging to so I don't come to September and say, "what the heck did I do all summer?" So before I forget, here is also some of the fun things I've been doing besides working on my new program:

St. Cloud airshow
Duluth airshow
Camping in Duluth
Kayaking on the Brule River
Brainer for the Fourth of July
Tubing on the Apple River
AP Computer Science Training
Saw Cats! At the Orpheum
Saw a community theater production of Oliver!
Biking nearly every day
Picnic in St. Cloud

So it's been a good summer so far, the second half should be just as fun.

Data Access Success

After three days of research and experimentation, I have a solid, working data access layer. I'm using PDO, as it's basically considered a standard now, wrapped in a singleton class. Now I can finally get on with the programming!

The first feature I'll implement is one of the most complicated: new account signup. I have to create a new organization, group, and user, relating them all together, in one step. I have to conduce a number of complex validation steps before doing so. Setting up a new account might not sound like a terribly complicated task, but it is, trust me :)

Singleton mysqli Class

Since mysqli is fully object oriented, the most obvious approach to using it is to create a singleton:

Class Db extends mysqli { }

Write a public static getInstance method to return an instance of Db so you get access to all of mysqli's properties and methods while ensuring that mysqli is instantiated only once throughout your application. Sounds straightforward enough.

I was half successful with this approach. I had a line of code like this in the parent class for all of my models:

Public $db = new Db::getInstance();

Then, to call any of mysqli's methods or properties, I would use code like this within my child model classes:

$this->db-> query();

This is where it gets really strange. This technique worked great when calling mysqli's static methods and properties, but would not work at all when calling methods and properties that required an instance of mysqli. For example, calling:

$this->db->affected_rows() gives the following error:

Call to a member function affected_rows() on a non-object

Query is a static method, while affected_rows is an instance method (I tried calling several other static and instance methods; the results were consistent: static methods worked, instance methods didn't). Why would static methods work but not instance methods? In my singleton class, I am returning an instance of mysql, so all of the instance methods should work.

Is this me being boneheaded, or is it a bug in PHP? Viewing the bug tracking system, I noticed that there were some problems when a class extended built-in classes such as mysqli, but those issues have been resolved.

After spending almost two full days working on database implementation, I'm almost ready to go the easy way out and use a global variable to store the mysqli object. The normal concern about unintentionally changing the value of the global variable is totally manageable if I maintain discipline in my code. The one drawback of this approach is that I'll be using a DB connection even when I don't need to. With a singleton, I was using a DB connection only when a model was instantiated, which does not happen on every request.

Other frameworks I've used, including CakePHP, CodeIgniter, and Kohana, always connect to the database for every request, and I don't think the performance hit from this will be significant, especially if I use persistent connections. Also, the vast majority of requests will require a database connection; only a few will not. So global variable it is.

Data Access Options

There are several options I have for interacting with MySQL. I could use PHP's native msql_ functions, its new mysqli_ functions, PHP Data Objects (PDO), or a third party ActiveReocrds or ORM library. After implementing flash session variables, email validation, and a new skin, much of yesterday was spent researching these options. I'm leaning toward the mysqli_ functions, but I haven't decided yet.

Persistent database connections are only useful when PHP is installed as an Apache module. When installed as a CGI instead, the PHP process is killed when the script is done executing, killing all DB connections along with it. My shared hosting provider runs PHP as CGI by default, although the option to run as an Apache module is provided. The Apache module option has some security drawbacks on shared hosts, because other users on the system can access my scripts and files if they're not tied down securely.

I think I'll be OK with the default setup of my shared hosting platform for now. When I outgrow that, I'll move to a (virtual or real) private server. I'll run PHP as an Apache module then because I'll be the only user on the machine, making the security questions moot.

Have We Been Here Before?

I got a lot of good things done on the first day back from my vacation. I got sessions working with HTTP only session cookies and shared memory as the storage engine. I'm checking every request for a consistent user agent; I'm checking requests for protected resources for an authenticated and active session; and I'm checking updating requests for a POST command and matching CSRF token. I also have the validation working on my Users model and just need to pass that data on to the view. The code structure that I'm using in my models, views, and controllers is very similar to what it was when I was using pre-made frameworks. I have to say that using my own homemade framework is much better in many ways. I also got some cool jQuery effects going on my signup form. Tomorrow, I'll continue working on the validation, hopefully making my first database inserts with parameterized queries, and trying to put a different skin on my app – I already have one designed, and my framework was built to make the task of switching skins easy.

Goals For Today

The MVC portion of my framework is nearly complete. The only trouble I ran into was getting views within views. I decided to take the same approach that Wordpress does - making the header and footer separate files, including them on every request, and then sandwiching the main content file in between.

I thought I was sure how I wanted the UI to look. In the past two years or so, I've prototypes about six different possible layouts. I thought I settled on one, but when I looked back at my previous attempts, one of them looks more appealing. It will be quite easy for me to skin the application. I think I'll do that and defer the decision as to which layout to use. I would like some other people's opinions on the matter as well.

So for today, I want to get the skinning system working and then it's off to the races coding up the first feature.

The Framework To End All Frameworks

With the specs, prototypes, and DB schema complete, I started work on the framework for my app yesterday, which will provide features like: clean URLs, routing, MVC architecture, Data sanitization, authentication, CSRF protection, and form validation.

Why roll my own? I've used three CMS systems (Wordpress, Joomla, and Drupal) and three frameworks (CakePHP, CodeIgniter, and Kohana). All of them force me to do things in funky and hacky ways. All of them are too big and slow - they load up so many dependencies, slowing down the system, and I don't use 90% of the features. The features that would be useful to me, such as access control lists, are implemented in a way that would not be useful to me, so I've ended up rewriting those systems anyway. After getting experience with these systems, I have some great ideas for what an idea framework for me should be like.

It should be lightweight and do only what I need it to do. I don't plan on using ActiveRecords or ORM because my SQL queries will be too complex for that. I plan on building only what I need as I go. In other words, it WON'T be the "framework to end all frameworks", it will be the "framework I need for my particular app".

I do plan on open sourcing the framework, code named Tabby, in case it might be useful to others. But really it's designed with my own needs in mind first.