Yep, you read it right. Miss Emma was admitted yesterday to Women & Children's hospital. She started running a 104 degree temp on Sunday morning and was real lethargic. She kept sleeping and not eating/drinking and had us worried. Late Sunday evening she started eating a little bit but never was herself. So on Monday we took her to Dr. Dudley just to have her checked out. Keep in mind she had just stared a 20 day dose of Omnicef. Well her ears/eyes/throat checked out fine but her white blood count was a little high. So we came straight to the hospital and got a chest x-ray. Luckily it was fine but her airways were a little inflamed. She has a ton of mucous in her but it seems to be getting better now. Also, she is slightly dehydrated so she is getting fluids. We still aren't sure what infection she has but they are testing her stool for a bacteria and also Rotavirus. We should hear something soon on that.
So for now we are hanging out in our little room and hope to be in a another day or two. Luckily my work is so understanding and said to take all the time I need. George worked tons of overtime last week so he can use those hours to cover his missed days this week instead of using his vacation.
Please say a prayer and send some get well wishes to Miss Emma. She is such a trooper when she is sick and has the best manners. I'm so proud of her! Hope to update soon with good news!
Tuesday, April 7, 2009
Monday, March 3, 2008
Wednesday, February 13, 2008
Valentine's Day Lightroom Preset
*EDIT* I forgot to add before and after pictures:


So this is my first attempt at an Adobe Lightroom preset, but I was playing around with some pictures and wanted to set the mood for the grand 14th of February. I have not tested this on many photos, but it seems to work well for outdoor pictures. Let me know what you think and please leave some comments if you have any suggestions.
George Titsworth's V-Day (you might need to right click and press "Save As...")
Have fun!


So this is my first attempt at an Adobe Lightroom preset, but I was playing around with some pictures and wanted to set the mood for the grand 14th of February. I have not tested this on many photos, but it seems to work well for outdoor pictures. Let me know what you think and please leave some comments if you have any suggestions.
George Titsworth's V-Day (you might need to right click and press "Save As...")
Have fun!
Saturday, August 18, 2007
Friday, July 6, 2007
Chaining SELECTs with Django and Ajax
So, I have been picked up a project at work that deals with our online task and time reporting system. Since I am in my Web-Framework kick, I have decided to use this as an opportunity to learn Django, a really nice Python Framework (The site was originally written in Python using the standard CGI package).
There is a section of the site that deals with adding a 'WorkEntry'. A WorkEntry is linked to a certain task. For example: I, George, worked 4.5 hours against Task 1: Unit Test of Function A. Task 1 is associated with a Project, Software Package A. In my job, we are working against contracts, so all work being done has to be mapped to a certain contract, or job, number that defines which bucket of money pays for the work. Also, in my company, multitasking runs rampant and each employee is juggling about 7-8 different tasks a day, which map to 3-4 different Projects, which ultimately map to 2-3 different contract numbers.
Now this flow goes both ways: There are many contract numbers, each of which has many projects, which map to many tasks.
So, what is the UI? The current site starts from the top by offering a list of Contract Numbers. When the user selects a contract number, it provides a list of Projects associated with this number. When the user selects a project, they get a list of tasks to choose from. This is accomplished by having the back-end python code spit out a large group of javascript arrays. As a user selects a contract number, these arrays are parsed and a new select box is populated with related projects. The same method is performed for tasks when selecting a certain project. This means that the entire database of contract numbers, projects, and tasks, are dumped to the site. This makes for a large chunk of data being served every time a user tries to add an individual task (a quick check shows > 4K for each request).
Since I am working on rebuilding the site using this new, fancy-schmancy web framework, why not add in some other new, fancy-schmancy technologies, such as Ajax, to make the UI more friendly while reducing the amount of total data being generated. Now that the problem and the goals is set up, let's dig in...
First we will need to set up our Form Class.
Since we are starting with the complete list of contract numbers, I decided to use the built in ModelChoiceField for contract_number and have Django build that form and load the data for me automatically (nice feature Django!). But, since the other two choices (project and task) will end up relying on what the user selects as the contract number, i do not want to pre-populate the data.
One area Django is limited in, however, is its ability to add in extra tags, such as javascript event handlers, to the auto generated forms. I am going to assume that everyone knows how to set up their view to process this form and to set up their template to display the form (if not go here), so I am going to skip strait to the part of the template that allows us to handle the user inputs and Ajax.
Once it breaks into the 'update*' functions, it does some quick error checking on the value to ensure it is none empty and then performs my Ajax functions (lines 7 and 16). For my Ajax calls, I have decided to use the Protoculous package, which combines the Prototype and Script.aculo.us packages. This provides a super easy framework for dealing with Ajax calls. I would like to give credit to the Irrational Exuberence blog for pointing me in this direction. The Ajax.Updater takes the container element that needs to be updated as the first argument, the url for the request as the second argument, and then any other arguments.
I have set up two urls in this case to handle the processing of the Ajax request in my urls.py file:
Just a heads up. I am only a couple weeks deep into Django, about a day deep in Ajax/Prorotype, about 4 years rusty on web programming, and have never written even the slightest hint of a tutorial, so if you have any helpful comments about how to make this better, please let me know by leaving a comment.
So what's next ... well, this works (and works pretty well for what I need), but is there a more efficient way to do this? Each project can have sub-projects, which can have tasks and subtasks. What is the best method for providing a slick UI when we can have these modular depth data structures. I could continue what I am doing and only provide one select box for Projects and present the user with a structure that looks like this:
There is a section of the site that deals with adding a 'WorkEntry'. A WorkEntry is linked to a certain task. For example: I, George, worked 4.5 hours against Task 1: Unit Test of Function A. Task 1 is associated with a Project, Software Package A. In my job, we are working against contracts, so all work being done has to be mapped to a certain contract, or job, number that defines which bucket of money pays for the work. Also, in my company, multitasking runs rampant and each employee is juggling about 7-8 different tasks a day, which map to 3-4 different Projects, which ultimately map to 2-3 different contract numbers.
Now this flow goes both ways: There are many contract numbers, each of which has many projects, which map to many tasks.
So, what is the UI? The current site starts from the top by offering a list of Contract Numbers. When the user selects a contract number, it provides a list of Projects associated with this number. When the user selects a project, they get a list of tasks to choose from. This is accomplished by having the back-end python code spit out a large group of javascript arrays. As a user selects a contract number, these arrays are parsed and a new select box is populated with related projects. The same method is performed for tasks when selecting a certain project. This means that the entire database of contract numbers, projects, and tasks, are dumped to the site. This makes for a large chunk of data being served every time a user tries to add an individual task (a quick check shows > 4K for each request).
Since I am working on rebuilding the site using this new, fancy-schmancy web framework, why not add in some other new, fancy-schmancy technologies, such as Ajax, to make the UI more friendly while reducing the amount of total data being generated. Now that the problem and the goals is set up, let's dig in...
First we will need to set up our Form Class.
1 class WorkEntryForm(forms.Form):
2 contract_number = forms.ModelChoiceField( \
3 queryset=ContractNumber.objects.all())
4 project = forms.ChoiceField()
5 task = forms.ChoiceField()
6 workEntryDate = forms.DateField()
7 hours_worked = forms.CharField()
8 comments = forms.CharField(widget=forms.widgets.Textarea())
Since we are starting with the complete list of contract numbers, I decided to use the built in ModelChoiceField for contract_number and have Django build that form and load the data for me automatically (nice feature Django!). But, since the other two choices (project and task) will end up relying on what the user selects as the contract number, i do not want to pre-populate the data.
One area Django is limited in, however, is its ability to add in extra tags, such as javascript event handlers, to the auto generated forms. I am going to assume that everyone knows how to set up their view to process this form and to set up their template to display the form (if not go here), so I am going to skip strait to the part of the template that allows us to handle the user inputs and Ajax.
Let's step through this. Since Django does no provide a method to add event handlers in form fields by default, all I had to do was create a Javascript function that gets run after the page loads. What this does is find the SELECT tag representing the Contract number and project choice fields. It then adds an 'onchange' event handler. So, when the user selects a certain contract number, it calls the updateProjects Function, passing in the currently selected value.1 <script type="text/javascript"
2 src="/scripts/protoculous-1.0.2-packed.js">
3 </script>
4 <script type="text/javascript">
5 function updateProjects(contractNum) {
6 if (contractNum!= '') {
7 new Ajax.Updater(
8 document.getElementById("{{ form.project.auto_id }}"),
9 '/tracker/projects_by_contract_num/' + contractNum,
10 {method:'get'});
11 }
12 }
13
14 function updateTasks(projectID) {
15 if (projectID != '') {
16 new Ajax.Updater(
17 document.getElementById("{{ form.task.auto_id }}"),
18 '/tracker/tasks_by_project_id/' + projectID,
19 {method:'get'});
20 }
21 }
22
23 function loadEventHandlers() {
24 document.getElementById("{{ form.contract_number.auto_id }}").onchange =
25 function () {
26 updateProjects(this.options[this.selectedIndex].value);
27 };
28 document.getElementById("{{ form.project.auto_id }}").onchange =
29 function () {
30 updateTasks(this.options[this.selectedIndex].value);
31 };
32 }
33 </script>
Once it breaks into the 'update*' functions, it does some quick error checking on the value to ensure it is none empty and then performs my Ajax functions (lines 7 and 16). For my Ajax calls, I have decided to use the Protoculous package, which combines the Prototype and Script.aculo.us packages. This provides a super easy framework for dealing with Ajax calls. I would like to give credit to the Irrational Exuberence blog for pointing me in this direction. The Ajax.Updater takes the container element that needs to be updated as the first argument, the url for the request as the second argument, and then any other arguments.
I have set up two urls in this case to handle the processing of the Ajax request in my urls.py file:
These requests map to two functions in my views.py file:1 (r'^projects_by_cunotract_num/(?P<contact_num>\d+)/$', \
2 'projects_by_contract_num'),
3 (r'^tasks_by_project_id/(?P<project_id>\d+)/$', \
4 'tasks_by_project_id'),
These are relatively simple calls, all they do is grab a listing of projects/tasks filtered on the currently selected contract num/project as specified by our Ajax usrl from earlier. I have created a very simple template, update_select_list.html, to spit out the OPTION tags for both projects and tasks (Projects and tasks have common attributes such as 'id' and 'title' that allows me to only use one html template to handle both classes).1 def projects_by_contract_num(request, contract_num):
2 projects = Project.objects.filter(c_num=contrcat_num)
3 return render_to_response('fastrac/update_select_list.html', \
4 {'items':projects})
5
6 def tasks_by_project_id(request, project_id):
7 tasks = Task.objects.filter(parent_project=project_id)
8 return render_to_response('fastrac/update_select_list.html', \
9 {'items':tasks})
10 )
And there you have it. That creates my chained select boxes. As a user chooses the contract number, the 'onchange' event fires, which causes an Ajax request to a function that retuns a list of tags of Projects filtered on the contract number. The same is done for tasks when a user selects a project.1 {% for item in items %}
2 <option value='{{ item.id }}'>{{ item.title }}</option>
3 {% endfor %}
Just a heads up. I am only a couple weeks deep into Django, about a day deep in Ajax/Prorotype, about 4 years rusty on web programming, and have never written even the slightest hint of a tutorial, so if you have any helpful comments about how to make this better, please let me know by leaving a comment.
So what's next ... well, this works (and works pretty well for what I need), but is there a more efficient way to do this? Each project can have sub-projects, which can have tasks and subtasks. What is the best method for providing a slick UI when we can have these modular depth data structures. I could continue what I am doing and only provide one select box for Projects and present the user with a structure that looks like this:
- Project 1
- Project 1 :: Sub Project 1
- Project 1 :: Sub Project 2
- Project 2
- ...
Tuesday, June 26, 2007
Alumni Relations Toolkit - Architecture Pt.1
The Alumni Relations Toolkit is intended to be a locally installed web application, meaning you, the user, will 'drop in' the toolkit to your web server. I fumbled with the idea of creating a website that would server multiple groups (e.g. each alumni would have to log into yourgroup.alumnirelations.com/), but I believe that would defeat the purpose of the project. The idea is to create an environment to create a community for alumni to reunite with each other and the organization. Since most organizations already have a psuedo-web presence built, it would be counterproductive to redirect them away from the where you want them to be.
Since my original project was written in PHP, and PHP is still a very popular and widely used language, I will stick with this decision. However, PHP has changed dramatically since the original release of this application. There are many new frameworks that make web programming so much easier than it used to be. They allow the developer to focus more on content and features than on the nitty-gritty details. They are also built to allow and encourage modularity and portability. This is very important when building a web app that will potentially be used on many different servers and using many different databases. Having loosely coupled modules will prevent major code changes when porting this app to a different architecture.
I have been in web framework hell for the last few days, trying to catch up on what all of the new frameworks are and what framework does what. I have been looking at the feature-set/learning-curve ratio and have narrowed it down to three frameworks that I will look deeper into :
If there is a framework that you believe is better than these three, just post a comment and I will look into it also. Once I figure out which I like the best, I will write my next post.
Since my original project was written in PHP, and PHP is still a very popular and widely used language, I will stick with this decision. However, PHP has changed dramatically since the original release of this application. There are many new frameworks that make web programming so much easier than it used to be. They allow the developer to focus more on content and features than on the nitty-gritty details. They are also built to allow and encourage modularity and portability. This is very important when building a web app that will potentially be used on many different servers and using many different databases. Having loosely coupled modules will prevent major code changes when porting this app to a different architecture.
I have been in web framework hell for the last few days, trying to catch up on what all of the new frameworks are and what framework does what. I have been looking at the feature-set/learning-curve ratio and have narrowed it down to three frameworks that I will look deeper into :
If there is a framework that you believe is better than these three, just post a comment and I will look into it also. Once I figure out which I like the best, I will write my next post.
Alumni Relations Toolkit - Database Design Pt. 1
I feel my old design needs some improvements to get it to a point where it might be useful, for example, let's look at the old 'user' type (called alumnus):
By the way, I generated this with Toad™ Data Modeler, which is a freeware database design tool.
This is a great start, but it could definitely use some more information to be useful. Some fields that might be helpful are:
I also know that the word alumnus and alumni is masculine. This is purely a nomenclature issue and most people will never notice this as a problem, but it is always good to be safe. Let's change the table name to 'Graduate' (this further excludes organizations that don't have graduates, but oh well. I can't win them all).
All this being said, let's look at how these new thoughts have changed our table:

By the way, I generated this with Toad™ Data Modeler, which is a freeware database design tool.This is a great start, but it could definitely use some more information to be useful. Some fields that might be helpful are:
- 'Username' - this would allow each graduate to configure a username to use as a login. Previously I only used the email address, but I know I hate typing in my email address on any login prompt and prefer using a simpler, and most importantly -- shorter, username.
- 'Date Registered' - This is not completely necessary, but would be useful information.
- 'Last Login' - Purely for informational purposes and potentially could be used by the group to see who the active participants are
- 'Last_Updated' - this field could also be very helpful ... If the user has not updated their information within the last year, we could send an email asking "Hey, do you need to update your info?".
- 'Is_Superuser' = This could help for administraion
I also know that the word alumnus and alumni is masculine. This is purely a nomenclature issue and most people will never notice this as a problem, but it is always good to be safe. Let's change the table name to 'Graduate' (this further excludes organizations that don't have graduates, but oh well. I can't win them all).
All this being said, let's look at how these new thoughts have changed our table:

Subscribe to:
Posts (Atom)
