Our morning started off today with a presentation by Tracy Hilliard, who is the Director of Data Integrity for the City of Seattle's Human Services department. She talked to us about public data and what the city of Seattle is doing to provide more public data and publish it on the internet. It was interesting to hear her talk, but I felt like I didn't learn anything novel from her presentation, and while the content seemed like it would be greatly connected to what we were doing (using data about public transit versus talking about public data from the city) there wasn't much I gleaned from it that I saw as directly relevant to my work. After her presentation we took a group photo. See if you can find me! (Hint: look to the right of the red shirt.)
Before our next session, my team regrouped and talked about what we had come up with as an outline of pseudo code yesterday, and we kept going trying to fill out more of the outline, while at each step addressing any concerns that arose. The really difficult part of outlining what our algorithm is going to look like is that the pieces are all very inter-related and to work well together we all have to have a really good understanding of what each part does and how it fits into the whole.
Our team session was interrupted shortly though by the next presentation that was being put on by Google Cloud Services. This presentation also didn't seem exactly relevant to what we were doing, and I'm not sure that we'll use their services at all in what we're doing, but I liked their presentation a lot more because it was interesting for me to hear about all the services that they have to offer. I believe it is worthwhile to have these presentations just because they make you more cognizant of all the things out there that you can use and what different things you can do with them. However, they are always more memorable when you can relate them to a specific project you're already working on at the time.
Anyhow, we spent the rest of the afternoon working as a group to work out all the kinks in our plan. Written down, this makes it sound like we didn't really do that much because really how much can you possibly need to discuss a simple outline? Let me assure you though, that this is no easy feat and is critically important in moving forward with the project. As I mentioned before, the different pieces of the overall algorithm have to work seamlessly together, and therefore they must all be very well defined. Also, another big issue that we keep running across is the trade-off between greatest optimization to the system and creating something that is very computationally expensive. We have to keep in mind that this program is going to be expected to run rather quickly so that the changes it suggests to the schedule can be changed and implemented right away. In addition, we kept running across dilemmas about what the end product would really need to look like for the dispatcher, and how they would be giving us information, and how it would be reflected in the data we would be given to work with. Due to this, we kept a list of questions for Matthew going as we discussed everything, and we are hoping to have another chat with him tomorrow so he can clear up some of these details that we're still unsure about.
I think the best way to characterize today, this week, and just our project in general is to look at that moment today when Anissa, the eScience ethnographer, after having been watching us for at least an hour discuss different aspects of the outline commented, "Wow, your project really is very complicated," and when I agreed with her she went on to say that it was much more complex than it first seems when you abstract the problem and just say that we're trying to optimize routing. It's true; whenever I talk to others about our problem I feel like it sounds very simple in concept, but what they don't realize is just how limiting and complicated all the constraints we have for this particular system can be. It's as if every time you look at it and go, "OK! I understand, and I know what we have to do!" someone else interjects and says, "Right, but have you considered how x will affect y?" and you realize you forgot that small detail of x, which only comes up in the situation with y, and you're back to the drawing board again.
Our team session was interrupted shortly though by the next presentation that was being put on by Google Cloud Services. This presentation also didn't seem exactly relevant to what we were doing, and I'm not sure that we'll use their services at all in what we're doing, but I liked their presentation a lot more because it was interesting for me to hear about all the services that they have to offer. I believe it is worthwhile to have these presentations just because they make you more cognizant of all the things out there that you can use and what different things you can do with them. However, they are always more memorable when you can relate them to a specific project you're already working on at the time.
Anyhow, we spent the rest of the afternoon working as a group to work out all the kinks in our plan. Written down, this makes it sound like we didn't really do that much because really how much can you possibly need to discuss a simple outline? Let me assure you though, that this is no easy feat and is critically important in moving forward with the project. As I mentioned before, the different pieces of the overall algorithm have to work seamlessly together, and therefore they must all be very well defined. Also, another big issue that we keep running across is the trade-off between greatest optimization to the system and creating something that is very computationally expensive. We have to keep in mind that this program is going to be expected to run rather quickly so that the changes it suggests to the schedule can be changed and implemented right away. In addition, we kept running across dilemmas about what the end product would really need to look like for the dispatcher, and how they would be giving us information, and how it would be reflected in the data we would be given to work with. Due to this, we kept a list of questions for Matthew going as we discussed everything, and we are hoping to have another chat with him tomorrow so he can clear up some of these details that we're still unsure about.
I think the best way to characterize today, this week, and just our project in general is to look at that moment today when Anissa, the eScience ethnographer, after having been watching us for at least an hour discuss different aspects of the outline commented, "Wow, your project really is very complicated," and when I agreed with her she went on to say that it was much more complex than it first seems when you abstract the problem and just say that we're trying to optimize routing. It's true; whenever I talk to others about our problem I feel like it sounds very simple in concept, but what they don't realize is just how limiting and complicated all the constraints we have for this particular system can be. It's as if every time you look at it and go, "OK! I understand, and I know what we have to do!" someone else interjects and says, "Right, but have you considered how x will affect y?" and you realize you forgot that small detail of x, which only comes up in the situation with y, and you're back to the drawing board again.