Monday, October 13, 2008
ITM 353 Slides
I gave a talk to the ITM 353 class on Oct 10th, You can go to http://docs.google.com/Presentation?id=dccvgnrf_41c4gk6dk4 to view the slides and download them.
Thursday, August 14, 2008
Data Issues: Crosslisted courses
We're actually dealing with this one right now. There's a meeting scheduled on Monday for it. The problem is the difficulty of identifying crosslisted courses and then knowing which department is the primary sponsor of the crosslisted course.
A crosslisted course is a single class that students can register for using two different CRNs (Course Reference Numbers). For example, Asian Studies 608 and Political Science 645C are the same class, with the same teacher, hours, etc. Two students registering one under AS and the other under PS will find themselves in the same class.
The problem we are encountering for eCAFE is that there doesn't seem to be a way to distinctly identify a crosslist course. There is a field in the database named crosslist_group which gives a two character code. This code consists of either two letters or a letter and a number. The code is used to group sections together as either crosslisted or concurrent (another story). We were initially told that two letters meant that a course was crosslisted and a character-letter code meant it was concurrent. This turned out not to be true. Apparently other campuses use a different convention, and to top it off, the outreach college at UHM has their own convention as well.
So we asked if there was another method of getting this data, and were told that there was. We were given access to an internal-use table that contained the information we needed. However, when I went to look at it, there was no information for the semester that starts in a few weeks. Upon further inquiry, it turns out that table isn't filled with the current semester's data until a month into the semester. Far too late for our needs. Blocked again.
Let's hope the meeting on Monday provides some illumination to the problem.
A crosslisted course is a single class that students can register for using two different CRNs (Course Reference Numbers). For example, Asian Studies 608 and Political Science 645C are the same class, with the same teacher, hours, etc. Two students registering one under AS and the other under PS will find themselves in the same class.
The problem we are encountering for eCAFE is that there doesn't seem to be a way to distinctly identify a crosslist course. There is a field in the database named crosslist_group which gives a two character code. This code consists of either two letters or a letter and a number. The code is used to group sections together as either crosslisted or concurrent (another story). We were initially told that two letters meant that a course was crosslisted and a character-letter code meant it was concurrent. This turned out not to be true. Apparently other campuses use a different convention, and to top it off, the outreach college at UHM has their own convention as well.
So we asked if there was another method of getting this data, and were told that there was. We were given access to an internal-use table that contained the information we needed. However, when I went to look at it, there was no information for the semester that starts in a few weeks. Upon further inquiry, it turns out that table isn't filled with the current semester's data until a month into the semester. Far too late for our needs. Blocked again.
Let's hope the meeting on Monday provides some illumination to the problem.
Data Issues: changing ids
After discussing my woes about ODS (where our class/student/instructor data comes from), a developer pointed out I should be noting all this stuff down. It's a good reference for explaining why our project took some of the turns that it did, and it may save another developer some headaches. So, here's the first of these.
When we first started designing eCAFE, we were told that the person_uid and id_number fields were the primary values used to identify a person in the database. I don't recall if someone told us this explicitly, or we just assumed it, but it was our belief that the numbers were unchanging. This turned out not to be the case.
While either number was fairly constant, during our updates each semester, we would inevitably find a few that changed. Since we built our tables using person_uid as the foreign key that all other tables referenced, this caused big problems. I finally had to write a script to do the following:
1.) Remove the unique index from the person table on the id_number field.
2.) Add a new record with the new person_uid (with same id_number, hence #1).
3.) Go to all dependent tables and change the person_uid to the new value.
4.) Remove the original record in the person table.
5.) Restore the unique index.
What a pain. In the redesigned eCAFE we autogenerate a unique key for each person and use that as the FK in the dependent tables. Now we can change the person_uid field with a simple update statement.
When we first started designing eCAFE, we were told that the person_uid and id_number fields were the primary values used to identify a person in the database. I don't recall if someone told us this explicitly, or we just assumed it, but it was our belief that the numbers were unchanging. This turned out not to be the case.
While either number was fairly constant, during our updates each semester, we would inevitably find a few that changed. Since we built our tables using person_uid as the foreign key that all other tables referenced, this caused big problems. I finally had to write a script to do the following:
1.) Remove the unique index from the person table on the id_number field.
2.) Add a new record with the new person_uid (with same id_number, hence #1).
3.) Go to all dependent tables and change the person_uid to the new value.
4.) Remove the original record in the person table.
5.) Restore the unique index.
What a pain. In the redesigned eCAFE we autogenerate a unique key for each person and use that as the FK in the dependent tables. Now we can change the person_uid field with a simple update statement.
Wednesday, July 30, 2008
MySQL Notes
I just posted on one of my project_specific blogs about some of the issues we've encountered trying to move data from an Oracle db to MySQL.
I was banging my head against a wall trying to figure out why this:
create table ecafetest.temp_stats (
statistic_id int not null
, survey_id int
, section_id int
, org_id int
, question_id int
, answer_id int
, answer_order_num int
, response_id int
, srs_id int
, urs_id int
, cnt int not null default '0'
, FOREIGN KEY (statistic_id) REFERENCES statistic(id) ON DELETE CASCADE
, FOREIGN KEY (survey_id) REFERENCES survey(id) ON DELETE CASCADE
, FOREIGN KEY (section_id) REFERENCES section(id) ON DELETE CASCADE
, FOREIGN KEY (org_id) REFERENCES org(id) ON DELETE CASCADE
, FOREIGN KEY (question_id) REFERENCES question(id) ON DELETE CASCADE
, FOREIGN KEY (answer_id) REFERENCES answer(id) ON DELETE CASCADE
, FOREIGN KEY (response_id) REFERENCES response(id) ON DELETE CASCADE
, FOREIGN KEY (srs_id) REFERENCES section_response_set(id) ON DELETE CASCADE
, FOREIGN KEY (urs_id) REFERENCES user_response_set(id) ON DELETE CASCADE
, primary key(statistic_id, question_id, answer_id, response_id)
) Engine=InnoDB;
Was generating a table where question_id, answer_id, and response_id were declared "not null" and my insert was failing because response_id was null. Imagine how silly I felt when I finally noticed the primary key. MySQL doesn't allow null values in a primary key, although they are allowed in all other indexes. So, while I may not have written "response_id int not null," through the primary key I had in effect done so.
I was dealing with this at the end of yesterday, and wasn't making any progress on it. I finally went home, and within a minute of looking at it this morning, saw my problem. It's amazing how often walking away from a problem brings you the solution.
I was banging my head against a wall trying to figure out why this:
create table ecafetest.temp_stats (
statistic_id int not null
, survey_id int
, section_id int
, org_id int
, question_id int
, answer_id int
, answer_order_num int
, response_id int
, srs_id int
, urs_id int
, cnt int not null default '0'
, FOREIGN KEY (statistic_id) REFERENCES statistic(id) ON DELETE CASCADE
, FOREIGN KEY (survey_id) REFERENCES survey(id) ON DELETE CASCADE
, FOREIGN KEY (section_id) REFERENCES section(id) ON DELETE CASCADE
, FOREIGN KEY (org_id) REFERENCES org(id) ON DELETE CASCADE
, FOREIGN KEY (question_id) REFERENCES question(id) ON DELETE CASCADE
, FOREIGN KEY (answer_id) REFERENCES answer(id) ON DELETE CASCADE
, FOREIGN KEY (response_id) REFERENCES response(id) ON DELETE CASCADE
, FOREIGN KEY (srs_id) REFERENCES section_response_set(id) ON DELETE CASCADE
, FOREIGN KEY (urs_id) REFERENCES user_response_set(id) ON DELETE CASCADE
, primary key(statistic_id, question_id, answer_id, response_id)
) Engine=InnoDB;
Was generating a table where question_id, answer_id, and response_id were declared "not null" and my insert was failing because response_id was null. Imagine how silly I felt when I finally noticed the primary key. MySQL doesn't allow null values in a primary key, although they are allowed in all other indexes. So, while I may not have written "response_id int not null," through the primary key I had in effect done so.
I was dealing with this at the end of yesterday, and wasn't making any progress on it. I finally went home, and within a minute of looking at it this morning, saw my problem. It's amazing how often walking away from a problem brings you the solution.
Thursday, March 27, 2008
User Centered Design
I went to a seminar today titled "Conducting User-Centered Design Tests in 5 Minutes or Less." The speaker was Matthew Winkel, Communications Officer for Web and New Media at The College of New Jersey. The presentation took about 75 minutes, including questions.
The gist was that most people don't have a big budget for design testing, or alot of time. To top it off, most users have an attention span that tops out at 15 minutes. This led to the idea of quick and dirty user design tests, which I summarize below. The first three can be accomplished with a print out of your interface and a pencil or highlighter, the last two are a little more involved.
The short version of the different types of tests:
1.) Label test: Hand out a printed screen shot and have the user circle or highlight the labels they find confusing. This shows which labels aren't adequately descriptive or are ambiguous.
2.) Visual Affordance Tests: On a printed screen shot, have the users highlight which areas of the page are selectable. This helps you pinpoint which parts the site the users don't realize are clickable, and which parts fool the user into thinking they are.
3.) Brand Tests: Hand the user a sheet of paper that has a list of attributes (ex: trustworthy, cluttered, simple, contrived, etc), and have them circle the ones they think applies to your site. Of course, this test only works with people who have actually seen/used the site. You could also provide a printed screenshot if your site lends itself to that.
4.) Single Question Web Poll: A popup dialog that asks a single question. Figure out what one thing you most want to know. Given it's only one question, it's more likely people will respond than if there were more.
5.) One or Two Task Tests: Have user sit down and assign them a single task (or two, max). Record what they say/do. Users are more likely to participate if they know it will only take 5 minutes or so.
What to ask about? Identify your key task or most desired task. Look at the search logs to see what people are most interested in. Look at Google Analytics (or other tracker/logger) to see what questions people navigate to in the FAQ. That tells you what parts of your site are the most confusing.
How to find people for tests? Approach people in common areas, get student help to recruit their friends and friends of friends. Do not use same students repeatedly.
The gist was that most people don't have a big budget for design testing, or alot of time. To top it off, most users have an attention span that tops out at 15 minutes. This led to the idea of quick and dirty user design tests, which I summarize below. The first three can be accomplished with a print out of your interface and a pencil or highlighter, the last two are a little more involved.
The short version of the different types of tests:
1.) Label test: Hand out a printed screen shot and have the user circle or highlight the labels they find confusing. This shows which labels aren't adequately descriptive or are ambiguous.
2.) Visual Affordance Tests: On a printed screen shot, have the users highlight which areas of the page are selectable. This helps you pinpoint which parts the site the users don't realize are clickable, and which parts fool the user into thinking they are.
3.) Brand Tests: Hand the user a sheet of paper that has a list of attributes (ex: trustworthy, cluttered, simple, contrived, etc), and have them circle the ones they think applies to your site. Of course, this test only works with people who have actually seen/used the site. You could also provide a printed screenshot if your site lends itself to that.
4.) Single Question Web Poll: A popup dialog that asks a single question. Figure out what one thing you most want to know. Given it's only one question, it's more likely people will respond than if there were more.
5.) One or Two Task Tests: Have user sit down and assign them a single task (or two, max). Record what they say/do. Users are more likely to participate if they know it will only take 5 minutes or so.
What to ask about? Identify your key task or most desired task. Look at the search logs to see what people are most interested in. Look at Google Analytics (or other tracker/logger) to see what questions people navigate to in the FAQ. That tells you what parts of your site are the most confusing.
How to find people for tests? Approach people in common areas, get student help to recruit their friends and friends of friends. Do not use same students repeatedly.
Thursday, March 20, 2008
Status Report: 3/17-3/20
What I said/did:
- Assess and start training the new guy
<snip>
- Meet w/ ASUH representative to get student-oriented feedback.
Had the meeting and wrote it up on the blog: http://uhmis-ecafe.blogspot.com/2008/03/asuh.html.
The short version is that they pretty much approved the system, liked what they saw, and are very happy we talked to them. They also said that it appeared that privacy concerns were addressed and they had no issues there. We spent the majority of the meeting talking about possible methods of increasing response rates.
- Implementing staff features.
Writing code? What's that?
- Reading: MySQL and ?
The ? turned out to be Ruby. My eyes are tired. Florescent lights suck. Let's declare the Manoa Starbucks a "Remote Office," they have windows.
In other news:
- I mentioned how there needs to be a small barrier for requesting features. I'm trying out this. We'll see how it goes.
- The BSAR specs were posted to the blog and I sent an email to D on Wednesday.
- Some advisory board members were saying that they like the blog, but want notification of when posts are made. So, I started a Google Group which users can join and opt for email notification. When a post is made, the blog automatically sends notice to the group, the notice is then disseminated by email to all members of the group.
Next week:
- Reading (will it EVER end?)
- Working on eCAFE Staff features
- Going to that "User Centered Design Tests" lecture
- Looking into how we can "hide" grades when students don't do their surveys.
- Assess and start training the new guy
<snip>
- Meet w/ ASUH representative to get student-oriented feedback.
Had the meeting and wrote it up on the blog: http://uhmis-ecafe.blogspot.com/2008/03/asuh.html.
The short version is that they pretty much approved the system, liked what they saw, and are very happy we talked to them. They also said that it appeared that privacy concerns were addressed and they had no issues there. We spent the majority of the meeting talking about possible methods of increasing response rates.
- Implementing staff features.
Writing code? What's that?
- Reading: MySQL and ?
The ? turned out to be Ruby. My eyes are tired. Florescent lights suck. Let's declare the Manoa Starbucks a "Remote Office," they have windows.
In other news:
- I mentioned how there needs to be a small barrier for requesting features. I'm trying out this. We'll see how it goes.
- The BSAR specs were posted to the blog and I sent an email to D on Wednesday.
- Some advisory board members were saying that they like the blog, but want notification of when posts are made. So, I started a Google Group which users can join and opt for email notification. When a post is made, the blog automatically sends notice to the group, the notice is then disseminated by email to all members of the group.
Next week:
- Reading (will it EVER end?)
- Working on eCAFE Staff features
- Going to that "User Centered Design Tests" lecture
- Looking into how we can "hide" grades when students don't do their surveys.
Friday, March 14, 2008
Status Report: 3/10-3/14
What I said/did:
- Factor D's most recent comments into the BSAR specs.
Done. I'll be posting it to the site and asking for his review on Monday.
- Implementing staff features.
Didn't really do much here. Ended up doing some edits to the database layout and looking into how/if I can accommodate a feature request. In contemplating how the feature would work, I generated a number of questions I needed them to answer. When I forwarded the questions, the request got dropped.
At one of the sessions I went to at the conference, there was a discussion on users asking for features and how it quickly bloats software. The determination was that users should have to go over some sort of hurdle when making a feature request. If it's too easy, then they'll toss up any old idea, even if hardly anyone would use it. This was proven true in the above example, and now I'm debating how to incorporate a small "barrier" for future feature requests to make sure it's something that people have really thought about and need, rather than just a whim.
- Reading up on MySQL and maybe some other technologies for BSAR.
I'm working my way through some of the MySQL books. Will be ongoing for a while.
Next week:
- Assess and start training the new guy
- Meet w/ ASUH representative to get student-oriented feedback.
- Implementing staff features.
- Reading: MySQL and ?
While I wrote the above as a guide, it's going to be pretty fluid depending on what happens with new guy. I'll be playing things by ear next week.
- Factor D's most recent comments into the BSAR specs.
Done. I'll be posting it to the site and asking for his review on Monday.
- Implementing staff features.
Didn't really do much here. Ended up doing some edits to the database layout and looking into how/if I can accommodate a feature request. In contemplating how the feature would work, I generated a number of questions I needed them to answer. When I forwarded the questions, the request got dropped.
At one of the sessions I went to at the conference, there was a discussion on users asking for features and how it quickly bloats software. The determination was that users should have to go over some sort of hurdle when making a feature request. If it's too easy, then they'll toss up any old idea, even if hardly anyone would use it. This was proven true in the above example, and now I'm debating how to incorporate a small "barrier" for future feature requests to make sure it's something that people have really thought about and need, rather than just a whim.
- Reading up on MySQL and maybe some other technologies for BSAR.
I'm working my way through some of the MySQL books. Will be ongoing for a while.
Next week:
- Assess and start training the new guy
- Meet w/ ASUH representative to get student-oriented feedback.
- Implementing staff features.
- Reading: MySQL and ?
While I wrote the above as a guide, it's going to be pretty fluid depending on what happens with new guy. I'll be playing things by ear next week.
Friday, March 7, 2008
Status Report: 3/3-3/7
What I said/did:
- Open the original eCAFE up to instructors.
Done. Been answering the inevitable questions that result from it. On a side note, S and I agreed on an arrangement for answering emails. We'll alternate weeks for now, adjusting/pitching-in as needed. We had a few missteps where we both answered the same email, hence the need for the arrangement. I just wanted to let you know this since you are on the mailing list now and might think that she was shirking the job. This was my week, next week it's all her.
- Factor D's most recent comments into the BSAR specs.
Didn't happen. Pushing this to next week.
- Rework the specs to account for the Women's Studies changes (once approved).
Done and posted to the blog.
- Work on implementing the staff features (this will be a repeating item on my list for the next month or so).
Ongoing.
In other news: I did the summary of other schools' experiences with going to an online evaluation system, and posted it to the blog. I haven't yet heard back any feedback on it, or on any of the ideas that came out of it.
I've also been trying to re-work part of the database that just seems... well, messy. It works, but I'm sure there's a better way to arrange things so it's more intuitive, yet I've been unable to see another way to do it. These few tables are a hold out from the last version and I think I'm so used to seeing them, that my brain won't drop them for another way.
Next week:
- Factor D's most recent comments into the BSAR specs.
- Implementing staff features.
- Reading up on MySQL and maybe some other technologies for BSAR.
- Open the original eCAFE up to instructors.
Done. Been answering the inevitable questions that result from it. On a side note, S and I agreed on an arrangement for answering emails. We'll alternate weeks for now, adjusting/pitching-in as needed. We had a few missteps where we both answered the same email, hence the need for the arrangement. I just wanted to let you know this since you are on the mailing list now and might think that she was shirking the job. This was my week, next week it's all her.
- Factor D's most recent comments into the BSAR specs.
Didn't happen. Pushing this to next week.
- Rework the specs to account for the Women's Studies changes (once approved).
Done and posted to the blog.
- Work on implementing the staff features (this will be a repeating item on my list for the next month or so).
Ongoing.
In other news: I did the summary of other schools' experiences with going to an online evaluation system, and posted it to the blog. I haven't yet heard back any feedback on it, or on any of the ideas that came out of it.
I've also been trying to re-work part of the database that just seems... well, messy. It works, but I'm sure there's a better way to arrange things so it's more intuitive, yet I've been unable to see another way to do it. These few tables are a hold out from the last version and I think I'm so used to seeing them, that my brain won't drop them for another way.
Next week:
- Factor D's most recent comments into the BSAR specs.
- Implementing staff features.
- Reading up on MySQL and maybe some other technologies for BSAR.
Status Report: 2/25-2/29
What I said/did:
> - Hook up the new eCAFE to MySQL and start adding parts back in (copy
> code from the old eCAFE and edit it for the new schema).
Done. I have the stripped-down eCAFE working off my local MySQL server, and I've started adding basic functionality back in and editing it all for the new schema.
> - Once I have the changes to the schema finished, I'll add more tables in
> the MySQL database as necessary.
Made many changes, posted the new schema to the blog along with a listing of what changed between each revision and why. I'm creating tables in the db as they become necessary for implementing code/functionality.
> - Try to get some meetings with users.
I had a meeting with the chair of the Women's Studies department today (finally), and it was a very productive conversation. We came around to a different way of handling some things. I'm working on a post and an email to send to all interested parties to put the changes out there and get feedback. Assuming the changes are ok with everyone, then I'll do the necessary revisions to the schema.
Next week:
- Open the original eCAFE up to instructors.
- Factor Darrell's most recent comments into the BSAR specs.
- Rework the specs to account for the Women's Studies changes (once approved).
- Work on implementing the staff features (this will be a repeating item on my list for the next month or so).
> - Hook up the new eCAFE to MySQL and start adding parts back in (copy
> code from the old eCAFE and edit it for the new schema).
Done. I have the stripped-down eCAFE working off my local MySQL server, and I've started adding basic functionality back in and editing it all for the new schema.
> - Once I have the changes to the schema finished, I'll add more tables in
> the MySQL database as necessary.
Made many changes, posted the new schema to the blog along with a listing of what changed between each revision and why. I'm creating tables in the db as they become necessary for implementing code/functionality.
> - Try to get some meetings with users.
I had a meeting with the chair of the Women's Studies department today (finally), and it was a very productive conversation. We came around to a different way of handling some things. I'm working on a post and an email to send to all interested parties to put the changes out there and get feedback. Assuming the changes are ok with everyone, then I'll do the necessary revisions to the schema.
Next week:
- Open the original eCAFE up to instructors.
- Factor Darrell's most recent comments into the BSAR specs.
- Rework the specs to account for the Women's Studies changes (once approved).
- Work on implementing the staff features (this will be a repeating item on my list for the next month or so).
Monday, February 25, 2008
Status report 2/4-2/22
The last few weeks were in upheaval from the mainland trip and getting
sick, so the last weekly status report I filed was on 2/1.
What I said/did:
> - Setting up a meeting w/ the official advisory board.
Had the meeting. Got approval on the specs so we can move forward with
development. There are a few issues still outstanding, but we have time
before those need to be resolved, and people are assigned to get them
resolved.
> - Setting up interviews w/ various people who do things "differently."
No one wants to talk. It seems that everyone wants to
complain, but when I try to set up meetings, they're busy. At
least some actually read the doc and provided feedback. I haven't
given up on meetings, or at least phone conversations, yet.
> - Working on db schema (where I plan to spend the majority of my time)
Some changes came out of the meeting which still need to be incorporated.
I plan on finishing this today.
> - HCC stuff.
Never touched it.
In other news:
I made a stripped down version of eCAFE which logs in all the different
user types and takes them to the appropriate page. It doesn't do anything
else. This is necessary due to the huge changes going on in the database
schema. We had to strip all but the most basic of code out so we can run
the system on the new schema. This new eCAFE is checked in as a
completely separate new project.
I spent some time looking into possible methods of transferring data from
ods to eCAFE, I know this is tasked to someone else, but since it's going
to affect S and I in a big way, I think I should at least have a
passing familiarity with the options.
Spending time working on my MySQL knowledge. Apparently, I've forgotten a
lot. No worries, it's coming back.
Next week:
- Hook up the new eCAFE to MySQL and start adding parts back in (copy
code from the old eCAFE and edit it for the new schema).
- Once I have the changes to the schema finished, I'll add more tables in
the MySQL database as necessary.
- Try to get some meetings with users.
sick, so the last weekly status report I filed was on 2/1.
What I said/did:
> - Setting up a meeting w/ the official advisory board.
Had the meeting. Got approval on the specs so we can move forward with
development. There are a few issues still outstanding, but we have time
before those need to be resolved, and people are assigned to get them
resolved.
> - Setting up interviews w/ various people who do things "differently."
complain, but when I try to set up meetings, they're busy. At
least some actually read the doc and provided feedback. I haven't
given up on meetings, or at least phone conversations, yet.
> - Working on db schema (where I plan to spend the majority of my time)
Some changes came out of the meeting which still need to be incorporated.
I plan on finishing this today.
> - HCC stuff.
Never touched it.
In other news:
I made a stripped down version of eCAFE which logs in all the different
user types and takes them to the appropriate page. It doesn't do anything
else. This is necessary due to the huge changes going on in the database
schema. We had to strip all but the most basic of code out so we can run
the system on the new schema. This new eCAFE is checked in as a
completely separate new project.
I spent some time looking into possible methods of transferring data from
ods to eCAFE, I know this is tasked to someone else, but since it's going
to affect S and I in a big way, I think I should at least have a
passing familiarity with the options.
Spending time working on my MySQL knowledge. Apparently, I've forgotten a
lot. No worries, it's coming back.
Next week:
- Hook up the new eCAFE to MySQL and start adding parts back in (copy
code from the old eCAFE and edit it for the new schema).
- Once I have the changes to the schema finished, I'll add more tables in
the MySQL database as necessary.
- Try to get some meetings with users.
Friday, January 25, 2008
Status Report 1/24-1/28
What I said/did:
- Release to staff users. Set up HCC campus-wide.
- Volunteering at TIP conference for most of the week, and there's a holiday on Monday, so I'll work in eCAFE/BSAR specs as I can, but I'm not expecting much.
I did send out the notice to the staff users. HCC needs a bit more work as I'm trying something new with setting them up which needs more testing but hopefully will save me effort later in the semester.
I'm still holding on the BSAR specs as I've only gotten three responses so far, and not all of my questions have been addressed. Darrel sent an email to all probable users yesterday, asking them to provide feedback. I'll give that a week and then put out a final plea if I don't get much back.
The eCAFE specs are coming along nicely.
Had a meeting with Hae regarding eCAFE. She's going to talk to some faculty organization about a plan we discussed regarding who gets to see results. She opines that any faculty who is mandatory likely has to share their results, so we could allow the dept to see those without having the instructor send it. She'll be looking into it, meanwhile, I'll write it into the specs and see if instructors flip about it or what.
We also discussed the advisory board. She told me about hers, and I told her about mine. We've agreed that I'll publish the new specs to the blog, gather feedback from both boards, and then we'll set up a meeting with her official board to discuss and make any needed decisions.
Next week:
- Finish eCAFE specs rewrite and post to blog
- Test new HCC setup
- Work on setting up the schema in eCAFE MySQL db.
- Release to staff users. Set up HCC campus-wide.
- Volunteering at TIP conference for most of the week, and there's a holiday on Monday, so I'll work in eCAFE/BSAR specs as I can, but I'm not expecting much.
I did send out the notice to the staff users. HCC needs a bit more work as I'm trying something new with setting them up which needs more testing but hopefully will save me effort later in the semester.
I'm still holding on the BSAR specs as I've only gotten three responses so far, and not all of my questions have been addressed. Darrel sent an email to all probable users yesterday, asking them to provide feedback. I'll give that a week and then put out a final plea if I don't get much back.
The eCAFE specs are coming along nicely.
Had a meeting with Hae regarding eCAFE. She's going to talk to some faculty organization about a plan we discussed regarding who gets to see results. She opines that any faculty who is mandatory likely has to share their results, so we could allow the dept to see those without having the instructor send it. She'll be looking into it, meanwhile, I'll write it into the specs and see if instructors flip about it or what.
We also discussed the advisory board. She told me about hers, and I told her about mine. We've agreed that I'll publish the new specs to the blog, gather feedback from both boards, and then we'll set up a meeting with her official board to discuss and make any needed decisions.
Next week:
- Finish eCAFE specs rewrite and post to blog
- Test new HCC setup
- Work on setting up the schema in eCAFE MySQL db.
Thursday, January 24, 2008
Session: CERN
David Foster of CERN
A Brief Tour of Grid Computing for the LHC.
Particle Accelerator
1/8th of the tunnel was already the largest superconductor ever.
1.9 Kelvin
15 PetaBytes of new data each year (that's what's stored, but it produces a PB/second)
Tier 1: (CERN) data acquisition, initial processing, and distribution
Tier 2: (Distributed World-wide) data heavy analysis. Managed mass storage.
Tier 3: Simulation and End-user analysis - batch and interactive
Any Tier 2 may access data at any Tier 1.
Middleware: Security, data management, job management, information system
EGI: European Grid Initiative. www.eu-egi.org
The accelerator is constructed, but still needs to be proved. Two sections have been cooled, with the remaining six to go. CERN is the largest consumer of liquid hydrogen in Europe. Each magnet is 10 meters in length and weighs 30 tons, they expand/contract so the connections are tricky. After multiple cooling/warming cycles, the fingers connecting the magnets got bent, causing a multi-year delay. The plan is to cool it once and leave it cold.
The target to open is this year. April 6th is the last day for the public to go to the tunnel because after that it will be radioactive. There's a press event later in the year (September?). The reality is they will be delighted if it ever works.
Cost so far: 10-15 billion Euro.
Can run about 100 days a year, the rest of the time it's in maintenance. Have robots to go into the radioactive tunnels and do work. Although the radiation dissipates to a point where people can go in on occasion.
The energy in the bean is equivalent to 100kg of TNT. And since it's in a very small space, it can drill a hole through anything imaginable. So the energy of the beam needs to be distributed over the target.
600 million proton collisions per second.
100 meters underground.
We had time at the end, so a discussion regarding the beginnings of the Internet was sparked. The funny part? It was originally for academic and research, if you put anything commercial on there, "You were shot."
A Brief Tour of Grid Computing for the LHC.
Particle Accelerator
1/8th of the tunnel was already the largest superconductor ever.
1.9 Kelvin
15 PetaBytes of new data each year (that's what's stored, but it produces a PB/second)
Tier 1: (CERN) data acquisition, initial processing, and distribution
Tier 2: (Distributed World-wide) data heavy analysis. Managed mass storage.
Tier 3: Simulation and End-user analysis - batch and interactive
Any Tier 2 may access data at any Tier 1.
Middleware: Security, data management, job management, information system
EGI: European Grid Initiative. www.eu-egi.org
The accelerator is constructed, but still needs to be proved. Two sections have been cooled, with the remaining six to go. CERN is the largest consumer of liquid hydrogen in Europe. Each magnet is 10 meters in length and weighs 30 tons, they expand/contract so the connections are tricky. After multiple cooling/warming cycles, the fingers connecting the magnets got bent, causing a multi-year delay. The plan is to cool it once and leave it cold.
The target to open is this year. April 6th is the last day for the public to go to the tunnel because after that it will be radioactive. There's a press event later in the year (September?). The reality is they will be delighted if it ever works.
Cost so far: 10-15 billion Euro.
Can run about 100 days a year, the rest of the time it's in maintenance. Have robots to go into the radioactive tunnels and do work. Although the radiation dissipates to a point where people can go in on occasion.
The energy in the bean is equivalent to 100kg of TNT. And since it's in a very small space, it can drill a hole through anything imaginable. So the energy of the beam needs to be distributed over the target.
600 million proton collisions per second.
100 meters underground.
We had time at the end, so a discussion regarding the beginnings of the Internet was sparked. The funny part? It was originally for academic and research, if you put anything commercial on there, "You were shot."
Session: NorStore
NorStore - A National Distributed Storage Infrastructure for Research & Education
By Jan Meijer
Norway is a mountainous country, rocks. Hard to dig to lay cable. 4 High Performance Computing Locations.
Why? separate long term storage from HPC. Can lose information when changing computers. Need a strategy, policy, and practice regarding the creation, management, and long term storage of data.
Trends: Size of data has increased to terabyte scale. IT tools evolve rapidly and the flexibility in using these tools put the very data they create and transform at risk. Survival of digital scientific information depends on a hierarchy of constantly shifting technologies.
Reasons to keep data:
- retention of unique observational information which is impossible to recreate
- retention of expensively generated data which is cheaper to mainteain than to recreate.
- reuse data for new or future research purpose
- validate and account for publicly funded research
- for compliance with legal requirements
- for educational and teacher purposes.
Objective: establish and maintain a broad and sustainable infrastructure for the curation, archiving,... [?]
Goals:
-operate storage resources and peripheral equipment
-provide support to researchers needing storage capacity, digital repositories, and curation services.
-promote a set of standard services and establish best practices and polices that aim to improve the reuse and reusability of scientific data
-provide easy, secure, and transparent access to distributes storages resources, provide access to larger aggregate storage.
Non-technical issues: security, confidentiality and continued privacy, ownership, assured provenance, authenticity and integrity. How to guarantee the quality of the primary data and associated metadata? One solution to some of this is to only handle data that has open-access, so ownership, etc goes away.
Initial consortium: Universities in Bergen, Trondheim (NTNU), Oslo, Tromso, UNINETT (NREN), UNINETT Sigma
2007: initial specs, choice of technologies, levels of curation, roadmap for 2008, and accumulation of experience
2008: investment in hardware for initial infrastructure.
Initially two locations with 600TB each.
http://www.norstore.no
http://www.terena.org/activities/storage
By Jan Meijer
Norway is a mountainous country, rocks. Hard to dig to lay cable. 4 High Performance Computing Locations.
Why? separate long term storage from HPC. Can lose information when changing computers. Need a strategy, policy, and practice regarding the creation, management, and long term storage of data.
Trends: Size of data has increased to terabyte scale. IT tools evolve rapidly and the flexibility in using these tools put the very data they create and transform at risk. Survival of digital scientific information depends on a hierarchy of constantly shifting technologies.
Reasons to keep data:
- retention of unique observational information which is impossible to recreate
- retention of expensively generated data which is cheaper to mainteain than to recreate.
- reuse data for new or future research purpose
- validate and account for publicly funded research
- for compliance with legal requirements
- for educational and teacher purposes.
Objective: establish and maintain a broad and sustainable infrastructure for the curation, archiving,... [?]
Goals:
-operate storage resources and peripheral equipment
-provide support to researchers needing storage capacity, digital repositories, and curation services.
-promote a set of standard services and establish best practices and polices that aim to improve the reuse and reusability of scientific data
-provide easy, secure, and transparent access to distributes storages resources, provide access to larger aggregate storage.
Non-technical issues: security, confidentiality and continued privacy, ownership, assured provenance, authenticity and integrity. How to guarantee the quality of the primary data and associated metadata? One solution to some of this is to only handle data that has open-access, so ownership, etc goes away.
Initial consortium: Universities in Bergen, Trondheim (NTNU), Oslo, Tromso, UNINETT (NREN), UNINETT Sigma
2007: initial specs, choice of technologies, levels of curation, roadmap for 2008, and accumulation of experience
2008: investment in hardware for initial infrastructure.
Initially two locations with 600TB each.
http://www.norstore.no
http://www.terena.org/activities/storage
TIP Conference
I spent most of yesterday monitoring sessions at the Techs In Paradise Conference here at the UH Manoa Campus. Thus far, I'm afraid I haven't gotten much out of it. Still, for those who are wondering what a monitor does, it's pretty basic. I'm stationed in a room, provisioned with a radio. Any issues that crop up, I either deal with it, or call in someone who can. This can run the gamut from misbehaving electronics, noisy people in the halls, or random speaker requests. Also, given this is Hawaii, I'm also responsible for presenting the speakers with a lei.
Some lessons learned. 1.) Bring food. 2.) Bring a book or laptop or anything to work on during downtime. There's a lot of downtime. 3.) Keeping a memory stick with you isn't a bad idea should a computer malfunction, then you can transfer their presentation to another machine. 4.) Bring business cards, people expect it.
Observations:
There are an insane number of tiny little computers around here.
Business cards in Asian cultures are a very formal affair. They are presented with two hands and a bow, and received in the same way, accompanied by an inspection of the card. A far cry from the standard American action of immediately shoving it in a pocket.
Some lessons learned. 1.) Bring food. 2.) Bring a book or laptop or anything to work on during downtime. There's a lot of downtime. 3.) Keeping a memory stick with you isn't a bad idea should a computer malfunction, then you can transfer their presentation to another machine. 4.) Bring business cards, people expect it.
Observations:
There are an insane number of tiny little computers around here.
Business cards in Asian cultures are a very formal affair. They are presented with two hands and a bow, and received in the same way, accompanied by an inspection of the card. A far cry from the standard American action of immediately shoving it in a pocket.
Status report 1/14-1/18
What I said/did:
>
> - Monday is likely going to be all BSAR stuff. Tweaking the presentation,
> cleaning up some recent changes I made to the specs, and incorporating
> feedback from the meeting.
The meeting went as expected, I learned that while I had a good starting
point, there are quite a few changes that need to made. I've re-written
the specs since then and posted a list of questions on the blog. I'll
give a few days for answers, incorporate those, and send out the new
version of the specs for more comments.
> - There's a meeting Swee set up with the ODS people to discuss a specific
> issue we've been having. It's on Tuesday at 2pm if you care to join us.
Went well. Hashed out issues regarding dirty data and functional/organizational concerns.
> - The rest of the week is going to be spent wrestling with Photoshop (a
> new toy for me) and redoing the eCAFE specs with the goal of getting the
> first version out to current board members at the end of the week.
When I wrote this, I had forgotten that the next usage period for staff
starts this coming week. My time has been spent making sure accounts are
ready to go and other last minute setup stuff. This would be easier if
people were better about returning their phone calls.
I did do some work on the eCAFE specs, but there's a ways to go.
> - The caveat to the previous item is that Swee leaves on Thursday, so
> Thursday/Friday may be taken up with unknowns depending on where she is
> with the database stuff.
She did a good job. BTW, in talking to the people that used eCAFE last
semester, everyone has good things to say about Swee. The general
consensus is that she was very prompt in answering emails, conscientious
about her work, and in general left a positive impression. Thought I
would pass that on.
Next week:
- Release to staff users. Set up HCC campus-wide.
- Volunteering at TIP conference for most of the week, and there's a holiday on Monday, so I'll work in eCAFE/BSAR specs as I can, but I'm not expecting much.
>
> - Monday is likely going to be all BSAR stuff. Tweaking the presentation,
> cleaning up some recent changes I made to the specs, and incorporating
> feedback from the meeting.
The meeting went as expected, I learned that while I had a good starting
point, there are quite a few changes that need to made. I've re-written
the specs since then and posted a list of questions on the blog. I'll
give a few days for answers, incorporate those, and send out the new
version of the specs for more comments.
> - There's a meeting Swee set up with the ODS people to discuss a specific
> issue we've been having. It's on Tuesday at 2pm if you care to join us.
Went well. Hashed out issues regarding dirty data and functional/organizational concerns.
> - The rest of the week is going to be spent wrestling with Photoshop (a
> new toy for me) and redoing the eCAFE specs with the goal of getting the
> first version out to current board members at the end of the week.
When I wrote this, I had forgotten that the next usage period for staff
starts this coming week. My time has been spent making sure accounts are
ready to go and other last minute setup stuff. This would be easier if
people were better about returning their phone calls.
I did do some work on the eCAFE specs, but there's a ways to go.
> - The caveat to the previous item is that Swee leaves on Thursday, so
> Thursday/Friday may be taken up with unknowns depending on where she is
> with the database stuff.
She did a good job. BTW, in talking to the people that used eCAFE last
semester, everyone has good things to say about Swee. The general
consensus is that she was very prompt in answering emails, conscientious
about her work, and in general left a positive impression. Thought I
would pass that on.
Next week:
- Release to staff users. Set up HCC campus-wide.
- Volunteering at TIP conference for most of the week, and there's a holiday on Monday, so I'll work in eCAFE/BSAR specs as I can, but I'm not expecting much.
Friday, January 11, 2008
This week/Next week Status report
This week:
What I said I'd do vs. what I did:
> - The BSAR project documentation and db outline seems to be done for now.
> Next up is another meeting with Darrel followed by doing a presentation
> for the other BSAR people. There's no meeting scheduled yet, but
> hopefully I can get one in next week.
The presentation is this Monday at 2. Slides are done, but I imagine I'll
spend some time tweaking them before the actual meeting.
> - Rewriting the eCAFE specs as a starting point for the advisory board.
This turned out to be bigger than I thought. All my old "screenshots"
need to be redone, along with the site flow diagrams. Between that and
re-thinking how all the pieces fit together, this will be my big job for
next week.
- More reading.
Slow progress. I feel a little scattered right now between the usability
stuff and the MySQL stuff. Guess I need to set a priority.
Next week:
- Polish up the BSAR presentation, and incorporate feedback from the meeting.
- Clean up some recent changes I made to the specs
- There's a meeting on Tuesday @ 2pm with the ODS people to discuss a specific
issue we've been having.
- Rewrite the eCAFE specs with the goal of getting the first version out to current board members at the end of the week.
- The caveat to the previous item is that co-worker leaves on Thursday, so Thursday/Friday may be taken up with unknowns depending on where she is with the database updates.
What I said I'd do vs. what I did:
> - The BSAR project documentation and db outline seems to be done for now.
> Next up is another meeting with Darrel followed by doing a presentation
> for the other BSAR people. There's no meeting scheduled yet, but
> hopefully I can get one in next week.
The presentation is this Monday at 2. Slides are done, but I imagine I'll
spend some time tweaking them before the actual meeting.
> - Rewriting the eCAFE specs as a starting point for the advisory board.
This turned out to be bigger than I thought. All my old "screenshots"
need to be redone, along with the site flow diagrams. Between that and
re-thinking how all the pieces fit together, this will be my big job for
next week.
- More reading.
Slow progress. I feel a little scattered right now between the usability
stuff and the MySQL stuff. Guess I need to set a priority.
Next week:
- Polish up the BSAR presentation, and incorporate feedback from the meeting.
- Clean up some recent changes I made to the specs
- There's a meeting on Tuesday @ 2pm with the ODS people to discuss a specific
issue we've been having.
- Rewrite the eCAFE specs with the goal of getting the first version out to current board members at the end of the week.
- The caveat to the previous item is that co-worker leaves on Thursday, so Thursday/Friday may be taken up with unknowns depending on where she is with the database updates.
Thursday, January 10, 2008
Tasks for week of Jan 7-11
Granted the week is almost over, but here's my plan for the rest of today and tomorrow.
- Practice the BSAR presentation, post the slides to the blog, and send the slides to remote team members.
- Working on rewriting the eCAFE specs.
Nevermind re: RememberTheMilk
It has already crashed my browser too many times. I quit. I'll just post my weekly status reports and ToDo lists here. Don't know how that's going to work, but time will tell.
HighEdWebDev '07
A few months ago, I went to the HighEdWebDev conference in Rochester, NY. The following is a document I sent out of ideas derived from the conference that I thought I could apply to myself or that may be useful for our development group in general.
HighEdWebDev Conference, 2007: Rochester, NY
This is just a rough fleshing out of various ideas that came up during the conference. I don’t know how much of this is feasible, but I thought I’d put it out there. I did this in some order of relevance, so the ideas get more far out there as you go on.
Testing
- Set up a testing rivalry. We could either do this between developers in our group, or this may be a means to work on the relationship between us and Michael Hodges group. The idea would be to pass off systems to each other for testing. The goal would be for the testers to find as many non-trivial issues as possible with there being an award for the group with the lowest defect rate. The metrics on this would need to be worked on since a large project will inevitably have more defects than a small one, so maybe defects as a measure of lines of code?
- Hire a tester. Maybe some students or a contract worker that we bring in at the test phase of major projects. The idea is that the ideal testing situation is to bring in someone with no ties to the project, someone where their sole goal is to find errors, without the thought that they have to fix it. Developers hate searching for bugs because we have to fix it, a tester has no such conflict. On a related note, it would be great if the tester also has a usability background.
- Get the ICS department involved. At the least, I can pitch the idea to professors about giving a class day to evaluate our interfaces. Or we could make a contest where students who break the system get a prize. Maybe we could arrange a work/study?
- If we don’t already have one, it would be good to have a “best practices” document for testing. It would cover all the standards (test all value limits, put in wrong data types, etc) as well as things that we may not immediately think of such as disability testing, or getting the site to work on mobile devices. We could include a checklist that people have to go through and sign off on at the end to make sure they really think about the items.
- Have some machines that are set up for disabled users, or get the most popular adaptive tools to run on our own machines. Right now, I have no idea if eCAFE will work for automated reading software, or any of the other tools that people with disabilities use. It would be great to have an old machine somewhere that’s set up with the different adaptive tools so we can make sure it works. At a minimum, perhaps we could buy a few adaptive tool licenses to set up accounts on our own machines. BTW, some schools have a disability office, do we? If so, maybe we can talk to them about it.
Emergency Communications
I know this really isn’t our group, but the V.Tech people gave a talk, and it seemed a pity to just ignore it. Also, there are other things we can do in addition to the text message broadcast that’s being worked on right now.
- Have a backup page with minimal content and no graphics ready to go, along with the means to redirect users to that page. When the event happened, their usage went from 15GB/day to approaching 400GB a day (193,000 hits to 2,300,000, a 1087% increase). He emphasized that you need to have backup server capacity along with the “lite” page that load fast. There also needs to be a crisis plan, as in who handles what. The plan should have a strict layout of responsibilities so people know who to go to for what. The web content guy kept hearing rumors and items presented to him as “facts,” but he knew he could only post information that came from one specific person who’s job was to verify the information. This helped eliminate bad information from getting on the site.
- Create a means to add a banner to all UH pages for the display of emergency notices. Perhaps create a widget that’s embedded in the UH banner and will show a notice if posted? Or just one that people can add to their pages that will automate the task. Consider what happens when email isn’t available, this would be a good way to let everyone know what’s going on.
- Have people voluntarily register their IM addresses and set up a system to send them a message if they’re on.
- Set up a blog of sorts that contains all important messages. The blog could have an RSS feed that people can subscribe to.
- Create a Facebook widget: I need to look into this, but some schools were talking about using Facebook to get the word out since many of their students had accounts there. My understanding is that Facebook allows people to create widgets/applications that users can download onto their pages. Given this, we could create a widget that posts UH related notices, and/or events that students can add to their personal page. I hear Facebook is offering money to developers for useful widgets, maybe we could get a piece of that.
- Facebook flyers. Facebook has a program where you can buy “flyers” that get displayed to specific users. It’s $5 for 2,500 page views. In an emergency, we could pay Facebook to post flyers to all users with UH listed as their school. We can specify if we want the flyers to be shown to graduate students, undergrads, or even alumni. We can also specify the time period during which the flyers are displayed. On a related note, this could act as advertising, like when eCAFE goes into wide release.
Tools:
- Write or buy a generalized tool for automating build/release processes. Something that does the build, sends the war to the destination, shows a “down right now” page, etc. It’d be a bonus if we could include a widget in our sites that show a countdown to downtime.
- Write or buy a tool to automate getting our Oracle tables and dumping them into another Oracle db, a local MySql database, or even just files. It would be great for making our own in-house backups for when we’re about to make a bunch of changes and want to be able to compare the differences afterwards. I don’t know if it’s possible, but a program that automates copying data from one db to another would be great, as it would save us from having to bug Jason a few times each semester.
- Use a spider program that crawls our pages looking for broken links. I don’t know if the main site uses this, but I doubt it given the dead links I’ve seen.
- Get a few of the most common mobile devices, along with a checklist for developing for such devices. The idea here is that many students are using cell phones, pdas, iphones, etc. We could have more access to the students, and perhaps more responsiveness from them if we made sure our sites worked on those devices. Like the “best practices for testing” idea, we could have one for this as well, and have a few in-house items to test on.
Blogs
My initial thought on this was that it probably wouldn’t be too useful to us, but upon further reflection, there are a number of possibilities for it.
- Project specific blogs. This would be a place where we keep users up to date on the progress of a project. The deeper I get into users and eCAFE, the more I learn it’s ALL about communication. To have a place where people can go to get the status of a project may be useful. The blog, if started at the beginning of a project, could act as a history of the project. If you let potential users (like teachers we have a relationship with) know about it, they could see how plans are shaping up and provide their input before we head into development. As the project matures, it could talk about why certain decisions were made, successes, failures, and lessons learned. The advantage to this is it would personalize a project, giving users the realization that there are real people working on it, and that their input does affect what happens rather than thinking of it as a black hole. It could also offer a place for user input (that everyone can see = accountability) as well as list future features. It also provides a built-in means for searching a project for something, as well as keeping everything in a cronological order so there’s no question as to what the most up-to-date documentation is.
- Have developers set up “Professional Blogs.” We could all list our skills, current projects, etc. This would help new hires know who to go to for help with specific things. The blogs could also be places where we share technical book reviews, a listing of what books are in our offices, ideas (like this conference write up). It could also be used for promotions if someone takes it in that direction, sort of like an extensive C.V.
- If we did either of the above blogs, we could set up an RSS feed them all to a site where we talk about what’s going on in MIS.
Podcasts and iTunesU:
With the exception of the first idea, these likely have little relevance to our group, but I thought they were fascinating. You can throw these out if Lassner is ever looking for new things to do (assuming you like them of course), as I don’t think we’re doing any of this right now.
- Get video recording software that records actions on a screen. We can use this to record typical actions that a user would want to do in one of our systems and post them as demos of individual tasks. So the next time an instructor emails me about “How do I…” I can point them to the video to see exactly how it’s done.
- While podcasts in a University context are usually associated with lectures, it doesn’t have to be. It can include visiting lecturers, special presentations, open houses, student projects, student interviews, student “storycore” (ala NPR), walking tours of campus, professors introducing their own research or research groups, or even our own “brown bags” topics for those who couldn’t go, etc. These can be used as a recruiting tool to help students get a sense for what happens outside of class, or just to keep people informed of what’s going on. Some campuses have started using it as an extension of their campus newspaper, so they have roving reporters that record on the spot interviews about whatever the topic of the hour is. As a bonus, the content can be leveraged onto the main page via RSS feeds.
- Bonus content or audio review. Some campuses reported that their instructors were reluctant to record their full lectures since they feared students wouldn’t come to class. One campus’ solution to this was to have professors record “learning objects.” These could be short snippets that review a particularly difficult concept, or just an audio recording that students could listen to while reviewing their notes from class. The students would still have to come to class, but they could get a refresher from the audio. Some professors also offered “bonus content” where they covered related ideas for those who are interested, or offer extra credit. The audio-only approach also works for foreign language courses, as faculty to include pronounciation cues.
- Professors could offer a “course preview” via podcast. They would record their first day of class so students could get a feel for what to expect and help them decide which class/professor they wanted to register for.
From the “Far-out” files:
- Get someone certified in Usability. Since hiring someone with this seems unlikely, we could train someone. There’s a 10 day certification course offered by Usability International. I think having a usability expert in house would be second only to getting a testing team (well, and a designer, once we lose Sandra), but it seems easier to obtain. There are probably other programs to accomplish the same thing.
Believe it or not, that’s the greatly condensed version.
Remember The Milk
In an attempt to get a handle on my todo lists and their progress, I'm trying a new site, it's called rememberthemilk.com. While other people rave about it, I'm not impressed yet. It randomly crashes my browser. Still, the publish feature is pretty cool, so I'm going to play with it a bit. My new ToDo list is at: http://www.rememberthemilk.com/home/jgeis/2370009/
Introduction
I originally envisioned this blog as being a feed of all my project specific blogs along with any non-project specific stuff. Since I've yet to figure out how to get one blog to automatically feed into another, it's going to be just the more general stuff. Ideas on improving my efficiency, task lists, links to the project-specific sites, etc.
Subscribe to:
Posts (Atom)