I'm in the process of moving all contents to http://sites.psu.edu/edued/ . All new contents will only be found there.
I'm presenting the contents in LDSC 12 poster session. 11:50 a.m.-12:30 p.m.: "Gallery opening" in Zoller Gallery in the Visual Arts Building.
Attending Open Source Bridge 2012 (OSB) was an experience beyond my original expectation. Besides learning about new technologies and the trend in the field, I am very impressed by how the conference is organized, whom I met in the conference, the insights of various technologies I learned from the conference, and the spirit which drives all these.
Organization
Normally a technology conference is organized by either a cooperation or an institute, but OSB is totally organized by volunteers, most of whom are open source software developers themselves. Now here is something very special about open source developers. These are the people who have donated their time and intelligence to collaborate with others on a projects that benefit others. I think this conference itself is just another project of these open source veterans.
Talking to some of the organizers, I learned quite a few tips about their workflow, team organization, and project management techniques. Motivating volunteers by creating values for everyone is indeed an art that is worth learning.
Come to think of it, our symposiums and summer camps also call for volunteers and the main organizers have always open channels for ideas. I feel that we share some open source spirit here in ETS.
The last day of the event is the unconference day. The agenda is to be decided on the beginning of the day by the participants together. I think it's a great in two ways: 1. it involves the participants to determine what they want collectively; 2. it gives everyone an opportunity to discuss their ideas with all the great minds already being there. Many sessions are raw ideas waiting for participants to add ingredients to cook.
Insight behind technologies
This conference gathered open source developers, project managers, and enthusiasts, as well as some famous developers in high profile open source projects such as Wikimedia, Firefox, Drupal, etc. and companies such as Mozilla, Wikipedia, Google, Twitter, etc. This makes it a great opportunity to learn about the latest development of various projects, the challenges they are facing in managing their projects, and the solutions they come up with.
The problems sometimes are purely technical so they have to resort to latest technology or new creative ways of using existing technologies (which is a familiar practice in our blog team here).
However, a lot of problems are not technical. They often need to come up with a way to lead the volunteers to reach to a consensus so such large number of developers can continue working in the same direction.
I also see how small projects can potentially turn into a game changers in such conferences. People openly share their ideas and a bunch of coders would sit together impromptu to hack away a problem.
Participants
Besides the "professional" characteristics mentioned above, this conference, held by this particular group of people, surprised me in a few ways.
I had never experienced any conference that is totally vegetarian. All food is clearly labeled whether it contains gluten or soy. Finally there is a conference where I could have enough good, healthy, and tasty food. (I am a vegetarian.)
There are all sorts of developers I saw here: those who don't wear shoes (in life), those who bike and walk instead of drive, those who bring their own mug, those who walk around to invite shy fellows into a conversations, those who always think about how to help newbies, etc. There is a common theme: these people believe that the future is in the hands of people who practice what they believe, and that by collaboration, we can really make a difference.
A few of them had donated their time to Code for America, and I've met some who is doing a healthcare version of it.
These are not only dreamers, but doers.
Open Source Spirit
This ted talk expressed the spirit of open source very nicely.
Lately I've experienced several online and traditional classes, as a supporting staff, a student, and an observer. I have some thoughts about what were done right and what could be improved, but I found myself lack of a systematic way and the proper vocabulary to offer my feedback. This got me interested in what instructional designers really do. I realized that my superficial understanding of them does not go beyond the job titles. Brad and I had a discussion and at one point he pointed out that we simply needed to include real instructional designers into our discussion.
Besides what courses they took in school, what roles they played when they were in the business world, and what they do currently, I learned what equipped them to approach an instructional design problem. The understanding of how people learn, and how different people learn differently, enabled them to ask them the right questions and suggest appropriate solutions.
Some professors in my grad school made comments about the unnecessity of instructional experts, specifically referring to education programs for higher eds. They understood the need for expertise in early childhood, but expected the mature learners to be able to learn from content experts, no matter how the materials are taught.
I understand where they came from, and I have my thoughts on their perspectives, too.
First, they were frustrated by the under-prepared students from high school, or even college. While the education system is responsible for the low standards, they see that individuals stopped taking ownership of the learning result. When passing tests become the only goal, students lose the essential curiosity of knowledge as well as the ability to learn materials outside of the requirement.
However, I think this is precisely the time to become part of the solution. If students don't have what they need, then in addition to pointing out the problems that made them so, we can still make their time with us meaningful.
Second, the awkward position of an education program sits between the academia and practicality, making it doubtable by traditional academic researchers.
However, so was the discipline of engineering, and even medicine. Today, the function of a graduate program needs to serve the modern world's demand. Expecting everyone to be able to dive through the raw materials and figure out things on their own may let the very few genius emerge, but is that a good use of the public resource? Is it good that a system is designed in a way that we simply rely on the percentage of genius who can be autodidactic anyway?
Both points above help me look at the slogan "Meet them where they are" with a positive attitude. While some may think that this is a compromise of the standard, I see this not only as a meaningful act of problem solving, but also as an opportunity of discovering a whole new world of learning model which may bring out new potentials we did not know.
Just as Angie and Kate did not expect me to know much about their field and were still able to enlighten me with stimulating questions that I was able to grasp.
Through ETS faculty fellow projects, Dr. Clements in Music Education met Dr. Guertin in Geology and started their collaboration. One interesting results from that collaboration is how Google Earth can be useful for unexpected purposes. Dr. Clements, in her course about Teacher's Identity, invited Dr. Guertin to come in and showed students the power of Google Earth, and the students are given the final assignment: present the journey of the formation of your teacher's identity, with Google Earth.
I provided technical support in Dr. Guertin's presentation and students' final presentation, and have learned a few things in the process.
1. Teaching a complex tool like Google Earth requires some careful pedagogical thinking.
Dr. Guertin prepared a handout with all the technical details, including some screenshots, menus, procedures, the markup codes, and caveats. This frees the students from having to memorize all those details while trying to get a good high-level understanding. Students later told me that handout became crucial later on when they actually started working in Google Earth on their own.
To make this learning proces even better, I think we can clearly structure the training session into two parts: in the first part, ask the students to concentrate on the projected screen, and in the second part, have the students practicing on their own computers. It was a big challenge for some students to follow the complex steps on the projected screen, while trying to find those complex menus on their own computers. For those who don't touch type, their eyes needed to move between the projected screen, their own computers, and the keyboards. Having the "lecture" and the "lab" parts in a session makes sense here, in my humble opinion.
2. Given resources, students can be pushed to learn own their own.
I was amazed by the features used by students in their presentation. The skill to use markup languages is definitely atypical among students in Music Education, but the students were able to style their presentation as well as embed pictures, audio, and videos. Perhaps being resourceful is just part of being a future teacher, but I really think we can aim high when it comes to what students can do on their own.
3. This is about digital literacy, not about one single tool.
Google Earth, typically, is most suitable for presenting location-based information. However, many students use it to present their education and musical experiences in terms of chronology, and locations just happen to be part of it. In such cases, Google Earth does not really add anything to the contents. The 3D manipulation of the earth/map/buildings adds some eye candies just like the flying-in text effect in PowerPoint, which we rarely see today as most people have realized its distracting effect. In this specific topic (Teacher's Identity), perhaps structuring the information around location may provide some insights of why specific regions emphasize certain musical/teaching styles because of local policy, funding situation, or social classes.
However, in my opinion, while this tool may not be the ideal vehicle for their specific information delivery, I think students should at least learn the following things:
a. The evaluation of a tool, how to choose the best tool for one's purpose, and how to make a tool work effectively in a presentation.b. The concept of the markup language, and the experience of thinking in terms of contents and forms.c. How to learn something new from reading technical documents.
4. Google Earth specifics:
a. When preparing a presentation, knowing the resolution of the projector is important. Students prepared their presentation on their laptop with full resolution, but the projector in the classroom could not display the pictures in its entirety.b. Google Earth heavily relies on the internet to load its map data, so it is crucial to have a stable and fast internet in the room. Reserving a computer lab may be a better in this case.c. Google Earth's tour mode is still buggy. Any file operations performed while the tour mode panel is opened will crash Google Earth. Let's hope Google fixes that one some time soon.
In all, I appreciate that Dr. Clements and Dr. Guertin are challenging these future teachers to acquire new skills, who, I hope, will also do the same for the new generations.
Jane McGonigal's talk in TLT Symposium (actually, also her TED talk I watched the night before the symposium) has flipped a switch in me. I started to notice a lot of potentials in various environment that we don't normally associate with gaming. It'll probably take me a while before I can capture what's really going on in my mind and what may come out of it later, but here are a few changes I notice:
1. Games don't have to be "competitive"
This is a big one for me. The common conception is if there are winners, there are losers. Jane said she makes a point not to have players compete against whoever is in the same space or the same time, so players are either playing against somebody (or themselves) in the past or somewhere far away.
I appreciate this notion a lot because I believe one's good emotion doesn't have to build upon other people's negative emotion.
However, to design games like this really takes a lot of creativity and thoughts, since we are so used to gain the satisfaction from feeling that I am (or "We Are") better than others.
2. Some activities don't look like games but they are.
This one is even bigger.
Allen pointed out the game Zombies, Run! to me. It's a great game against Zombie (also imaginary enemies) to emerse the runners into an engaging real-time story. However, what's even bigger than itself was the inspiration I got from the force behind it: Kickstarter.com. It never occurred to me that Kickstarter is a kind of social game.
People evaluate an opportunity and come together to nurture a potential epic win. I believe most of the emotions behind those projects are not materialistic. People love to see others succeed, and people love to be part of it.
If you win, I win. What a positive cycle!
Kudos to the TLT Symposium committee for such a great invite. The impact is big and deep.
In the past two weeks I have been 'frantically merging two bases of code'. However, the widely used method of automatic merge turned out to be a dangerous practice. I'm writing this post to illustrate some of the problems (of either totally trusting the automatic merge, or a combination of our specific code modding practice combined with automatic merging).
Say we have a code version 1 that looks like this:
VERSION MT1
sub func
{
statement1;
statement2;
statement3;
statement4;
}
And let's say we want to make a change to the function so the system will call our version instead.
VERSION PSU1
sub _func
{
statement1;
statement2;
statement3;
}
sub func
{
statement4;
}
Namely, we only want statement 4 to be executed but we'd like to keep statement 1-3 around for future reference.
And now the upstream base of the original code has an update:
VERSION MT2
sub func
{
statement1;
statement1.5;
statement2;
statement3;
statement4;
statement5;
}
Namely, they added statement1.5 and statement 5.
Supposedly, we should get a conflict since the semantics of the code has changed; however, since git deals with only chunks of diffs, and the determination of conflict has to happen onto the same chunk of code, i.e. consecutive lines, git will not see this as conflict waiting to be resolved. It gives us the wrong merge result (suppose we don't want statement 5 in our environment):
VERSION PSU2
sub _func
{
statement1;
statement1.5;
statement2;
statement3;
}
sub func
{
statement4;
statement5;
}
Let's look closely at what happened here. First, in MT2, there are two sections that got changed from VERSION MT1, i.e. the addition of statement1.5, and the addition of statement5 are simply two additions. In PSU1, we changed the function name from func to _func, and then inserted brackets and another function name between statement 3 and 4. So from git's point of view, the first chunk of diff is the change of function name (from func to _func. It's independent and will pass the automatic conflict resolution. The second chunk of diff is the insertion of statement 1.5. Same, it's independent and will pass automatic merge. The 3rd chunk is insertion of two brackets and a function name -- independent and will pass check. The 4th chunk is insertion of statement 5 -- independent and will pass check.
There is no way that git will know that we only want statement 4 to be execute and statement 5 is irrelevant to us.
There are two potential solutions:
The first solution is the common standard. Don't do any trick like changing the function name; instead, just delete the original code and write out our target:
VERSION PSU1 SOLUTION1
sub func
{
statement4;
}
git will not resolve the conflict but at least it'll tell us that it can't so we can do it manually. The principle here is: when we have a mod that changes program logic like this, we want to make sure that our mod will create conflict.
The second solution is also about creating intentional conflict. We can comment out the original code and add our mod after that, so it looks like we both added and deleted something and will require manual intervention.
VERSION PSU1 SOLUTION2
#sub func
#{
# statement1;
# statement2;
# statement3;
# statement4;
#}
sub func
{
statement4;
}
The manual merge will still be a lot of work, but at least git won't create hidden problems that lead to infinite debugging time.
I needed a break in a long code merging session, so I improved the Penn State's Amazing Race by separating its code and data, so faculty can now easily change the question set for their specific use. I also fixed a few things so now it can run on any local machines (note that Google Earth still requires internet access to read its earth data).
What I did was extract the section of the hard-coded questions, replace that with a synchronous Ajax call to read in a JSON data set, so now all the questions are laid out in a separate text file, with JSON format. JSON is a simple and clean format for both users and coders.
I learned a few things that are not apparent in any documents I found:
1. JSON does not support comments, so the compromise is to use a variable called "_comment". I use an array to include multi-line comments.
2. JSON does not support raw TAB in its data, i.e. within the quotation marks, there should not be any TABs. I replaced them with spelled out spaces.
Here's the downloadable version.
My day started from a sign of global warming:
Global warming
-> warm day in February, while I was frantically merging two sets of distinct code for Blogs@PSU
-> hibernated animals woke up, while I was frantically merging two sets of distinct code for Blogs@PSU
-> they felt hungry, while I was frantically merging two sets of distinct code for Blogs@PSU
-> they chewed my internet cable line, while I was frantically merging two sets of distinct code for Blogs@PSU
-> Comcast came to fix it, while I was frantically merging two sets of distinct code for Blogs@PSU
-> I was frantically merging two sets of distinct code for Blogs@PSU
-> ate lunch, while frantically merging two sets of distinct code for Blogs@PSU
-> supported Dr. Laura Guertin and Dr. Ann Clements' Google Earth presentation
-> learned about teaching users both tools and the applications of the tools
-> showed Knowledge Commons and OneButtonStudio to Dr. Guertin
-> witnessed Cole and Scott teaching Disruptive Technology in a special room in Knowledge Commons
-> thought about the shift of the paradigm: now it's more of the instructors' responsibility to engage students and capture their attention and concentration
-> wrote this post, feeling absurd of the mixture of various experiences today
Lately I've encountered a few impressive showcases of the new browser technology:
David Stong has been using quite some of the new CSS functions. We plan to look into what the new CSS has to offer, by learning from this impressive lightbox with CSS.
Due to much faster compiling technology available nowadays, games are now possible in the browser (with javascript). I read about Cut the Rope, and Brad pointed out Angry Birds has come to Chrome for a while.
Beside the faster performance of the new technology, what's important for me is the ease of development of more complex application with tools available. Google Web Toolkit is one of such tools. Google's Closure Library is another. These tools allow the developers to focus on the logic, rather than lower-level technical details such as cross-browser compatibility, server availability, data exchange, etc.
Recent Comments