Center for Teaching & Learning | Baruch College

Newman Library Building, Rm 648

ed-tech

CTL Hybridization Seminar and Showcase: Our Fourth Meeting

by

The final meeting of the Spring 2018 CTL Hybridization Seminar Faculty Fellows will feature a showcase of their work. 

Want to see how other faculty have approached adapting their course to the hybrid format? Interested in applying for a future CTL Hybridization Seminar and want to see first hand what it’s like? Then please come to our last meeting of our Spring 2018 Hybrid Seminar series. We are looking forward to hearing from our faculty fellows as they present the hybrid/online course they have developed throughout the semester. The meeting is open to all Baruch faculty and staff and we encourage anyone interested in hybrid course design, new teaching strategies, and instructional technology to attend.

The CTL Hybridization Seminar is a terrific opportunity for Baruch faculty who have not yet experimented with teaching in an online/hybrid format. Seminar participants will be encouraged to think creatively about how teaching in this format can open up new pedagogical opportunities within and across disciplines. With the guidance of the CTL staff and feedback from other faculty fellows, participating faculty will develop syllabi, assignments, assessments, online learning resources, and digital spaces for their course.  Faculty Fellows will be matched with a CTL Hybridization Fellow, whose role is to support and collaborate with the Faculty Fellow throughout the semester.

The seminar is designed to offer a customized experience to meet the needs of the diversity of courses taught at Baruch and of teaching styles. This is a hands-on seminar which give faculty the opportunity and support to develop their hybrid course through a combination of seminar workshops, one-on-one consultations with the CTL staff and attendance of relevant CTL programs.

Spring OER Initiative Seminar: Workshop II

by

The topic of the second cohort meeting is “Why OER?”

In session two we will discuss the pedagogical value of using OER instead of textbooks, and also how the openness of OER creates a different relationship to education than zero cost.  Attendees will have the opportunity to learn about other faculty’s experience of the OER conversion process. We will also raise the issues of student access and usability questions when thinking about OER pedagogy. Prior to this session we encourage faculty to think about elements of their existing syllabi that could be converted to OER.

Session topics include:

  • What are textbooks for and why do we rely on them?
  • The pedagogical advantages of using OER
  • Why choose true OER over zero cost materials?
  • Mobile/Digital friendly materials vs. traditional paper-based materials

Click here to learn more about the Spring 2018 CTL OER Initiative Seminar.

Spring OER Initiative Seminar: Workshop I

by

The topic of the first cohort meeting is “What are OER?”

 

In this session we will introduce attendees to and differentiate between OER and zero cost materials. We will focus on OER specifically as an opportunity to revisit pedagogical approaches, raise student information literacy, introduce a wider variety of course materials, and embrace interdisciplinarity. Prior to this session, we encourage faculty to consider which course, or courses, they would be interested in converting to OER.

Session topics include:

  • Copyright issues and open licensing
  • Remixable content
  • Textbook networks such as OpenStax and the UMN Open Textbook Library
  • Thinking beyond just textbooks to OER as any number of different course materials

 

Click here to learn more about the Spring 2018 CTL OER Initiative Seminar.

Checking student understanding with Plickers

Filed Under: Active Learning, CTL News, ed-tech, move-green, Pedagogy, Resources by

It’s likely that most of the people reading this post have used or heard of clickers: in-class polling systems that allow instructors to gauge student knowledge, understanding, or interest in a topic.

Whether you use Poll Everywhere, Turning Point, the student-generated Cliqur system, or something else, this technology can be handy for facilitating student-centered, active peer instruction. Check out Eric Mazur’s peer instruction demo in this video link to see clickers in action.

However, one downside to using clickers is that, like with any technology, sometimes, they don’t work. Students forget to bring them to class, or they don’t have a clicker-enabled device for entering responses. Updates to software and/or limits on the number of free responses you can solicit can also impact usage possibilities.

One interesting potential solution to this problem is an app and a set of physical, laminated cards called Plickers (check out a link to the Plickers site here).

This polling technology allows a teacher to print out free cards from the Plickers website (here’s a link to the place where you can do that), or buy a durable, reusable set of laminated cards to distribute to students. The instructor also needs to download the Plickers app to a smart device. Students select the answer to the question the instructor asks by orienting their card in a particular direction, and then the instructor uses the app to “scan” the classroom. Once the cards have been scanned, the instructor can display the results of the quiz via the projector.

Check out this video demo showing how Plickers work in an elementary school math class.

CTL git workflow

Filed Under: Blogs@Baruch, Resources by

Here at the CTL, we run git as our version control system to patch and update the Blogs@Baruch code.

Currently our workflow process is fairly linear: there is an update to a plugin or theme, a new theme needs to be deployed, a patch needs to be applied. It gets added to the codebase and pushed out.

Our GitHub repository hosts multiple branches for this project, including the master branch, development branches, and production branches. The most recent production branch (which is named the date that it was finalized, ie., november-26-2014) should be exactly the same as the master branch. This is for workflow and backup purposes.

The second attempt to map our CTL git workflow
The second attempt to map our CTL git workflow

Each of our developers has their own local cloned instance of the Blogs@Baruch codebase on their computer. This is where our workflow will begin.

[Note: anything in italics below is placeholder text that needs to be replaced with the actual branch name from the git repository]

 

LOCAL SYSTEM

1. Checkout the most-recently-dated-branch from origin repository to the local system:

          git fetch origin
          git checkout –b most-recently-dated-branch origin/most-recently-dated-branch

Or, if the local files have changes that need to be overwritten by the production files:

          git fetch origin
          git reset --hard origin/most-recently-dated-branch
          git checkout –b most-recently-dated-branch origin/most-recently-dated-branch

2. Checkout a new development branch from the most-recently-dated branch on local

(naming convention is a descriptive title prepended by dev-, ie., dev-pluginupdates)

          git checkout –b dev-branch

3. Checkout a features branch from the local development branch. Each feature being added or updated should have its own branch.

(the reason for this extra step is to make future changes to our workflow more intuitive)

          git checkout –b feature-branch

4. Make changes on the local system files and test them locally (as much as is possible on a local environment)

5. Merge the features branch into the local development branch. Make sure to give a clear commit message explaining the changes.

          git add path/to/changed/file

          git commit -m "Informative message describing the changes"
          git checkout dev-branch
          git merge feature-branch

6. Push the local development branch to the origin repository

          git push origin dev-branch

*If only a minor change (like a typo), branch a local new-dated production branch from the local development branch, and push to the repository

          git checkout -b new-dated-branch 

          git push origin new-dated-branch

 

STAGING SERVER

1. Checkout the most-recently-dated branch to the staging server

          git fetch origin
          git checkout –b most-recently-dated origin/most-recently-dated


2. Merge the dev-branch into the staging server


          git merge origin/dev-branch


3. Test to make sure that nothing broke in the migration from your local system to the staging server.


4. If everything is OK, switch back to your local system and checkout a new-dated branch from the dev-branch, and push to the repository


          git checkout –b new-dated-branch


          git push origin new-dated-branch


If the test is not OK, reset the staging server to a working state, and delete the dev-branch from the staging server


          git reset --hard origin/most-recently-dated


          git checkout most-recently-dated


          git branch -d dev-branch


5. Delete the dev-branch on the repository


          git push origin --delete dev-branch


 


PRODUCTION SERVER


The master branch on the production server is live.


1.  Branch and pull the new-dated branch from the repository into master branch on the production server


          git fetch origin


          git merge origin/new-dated-branch


2. Branch a backup branch from the newly merged master branch (this branch is for quick restore purposes only and hopefully will never need to be use)


          git branch new-dated-backup


3. Push the master branch from the production server to the repository


          git push origin master


 


This workflow may seem needlessly complicated, given git’s powerful branching and merging capabilities. This is just a starting point workflow for us. Eventually, we will be able to modify this workflow to one that is focused more on specific features, where the development branches are not determined by release date, but but feature. This will allow us to have a less linear and more adaptable workflow where multiple features are simultaneously developed and released whenever they are ready.




		
		
		
		css.php