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.
Friday, March 7, 2008
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.
Subscribe to:
Posts (Atom)