Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Saturday, August 9, 2014

Learning Python with the Programming Historian

For those humanists out there looking to learn Python to aid your research processes, the Programming Historian has a great set of lessons to get you started. The lessons are designed to teach you Python by doing the types of tasks historians might want to do. So instead of learning about managing an inventory of widgets (as is common in intro-to-programming books) you learn how to manage a set of historical sources.

The Programming Historian used to make it more obvious that these lessons were originally written sequentially, so that readers could build upon their skills slowly. It's not quite so obvious anymore because of the new way we've organised our table of contents. But for those of you interested in learning Python, or using it with students, I thought it would be helpful to post their original order here so that you can easily find your way through them.

Happy learning.

Your First Lesson

Introduction to Python

---

You may also like to supplement your learning with other tutorials. I found Mark Lutz, 'Learning Python' (O'Reilly) very useful. My co-editor, Fred Gibbs, is a big fan of the Code Academy. Use whatever combination works for you. Good luck.

Wednesday, April 30, 2014

How to Solve Programming Problems if you're learning Programming

Things can and will go wrong when you first start dabbling in programming. As with all new skills, you are going to get frustrated. Here are a few tips that may help you work through the frustration and solve many of your own problems.

 

Language Learning

Do not forget you are effectively learning a new language, or even languages. You will not be fluent in twenty minutes. But you can expect to start building your skills to the point where you can complete simple tasks, progressing into more difficult situations. When you are presented with new code, it's important that you take the time to really understand it. If you whip through a tutorial or cut and paste code snippets you find online, you may end up with a program that runs, but you will not understand it, nor will you be able to generalize the skills and write your own programs. Once you've got something that works, try making a backup copy and then changing things in your code one at a time. If you can predict the effect that your changes will have, you have a good understanding of what is going on. When you are surprised by the effect of a change, you have an opportunity to learn something new. When you've got something that doesn't work, make a backup copy and then try eliminating things that you don't understand. What is the simplest version that you can get to work? Once you have that version, you can try adding in new code, one thing at a time.

 

Search Engines

If you run into difficulties when writing computer code the great news is that the answer to almost any problem can be found online. Computer programmers constantly seek and give help on forums and mailing lists, and the questions and subsequent answers are readily available. This means the Internet is usually your best resource for finding help. If you run into a problem, the first thing you should do is type your problem into a search engine. More often than not someone has already asked your exact question, and other people have provided a range of answers. You might even find entire websites dedicated to solving your particular problem. When you are just starting out, it is very unlikely that you will come across a problem that no one has encountered before. Likewise, if you encounter an error message that you don't understand, cut and paste that error message into a search engine and surround it with quotation marks. Typically you will find dozens of explanations for why this error appeared and how to fix it. The more specific that you can be about your problem, the better the results you will find. Don't be discouraged if you don’t find the answer on your first search. Rephrase the search terms and try again.

 

Forums

If you’ve Googled it, Yahoo’d it, and tried various combinations of teas, coffees and energy drinks to no avail, you're going to need to ask for help. There are many Internet forums and mailing lists to which you can turn. At the time of writing, my favourite forum for general programming questions is Stack Overflow. There is also Tutor, a mailing list where people who are learning Python can ask questions, and people who are interested in teaching Python can answer them. At any given time there are swarms of friendly, knowledgeable people just waiting to answer your question. If you post your problem in a courteous manner, with a little bit of luck you will have a solution within a couple of hours. Keep in mind that it is bad form to post a question in more than one place in quick succession. It may not be the instant gratification we’ve come to expect, but don't forget, these people are volunteering to help you, and most probably if you're desperate enough to ask for help, you could use a few hours away from the keyboard anyway. Go for a walk, take a nap, or do something else to clear your mind and some new ideas will come to you.

 

Asking Good Questions

Clarity and specificity are your friends when it comes to asking for help on a forum. The FAQ page on Stack Overflow's website is great reading for anyone looking to ask a question about programming online. Even if you do not use the Stack Overflow forums, the messages here are essential. Remember, the people who read forums and offer their expertise are busy; make it easy for them by carefully thinking out your problem before you ask. Likewise, make sure you are asking a specific question to a narrowly defined problem. For example, don’t post something like: "Why won't my code work?" Instead, try: "Why am I getting a syntax error when I try to Push a value into an Object?" Always post the relevant section of your code (and only the relevant section of your code) along with your question. If possible, remove any unnecessary bits that are not immediately relevant to the question to make it easier for experts to help you solve your problem. If the answer you get does not do the trick and you are still stuck, be polite and try rephrasing the question. Remember, don’t bite the hand that feeds you; these are volunteers and they’re trying to help you!

 

 Debugging

When fixing problem code, systematically change one thing at a time and retry your program after each change. Often if you make three or four changes before retrying the program, you will solve one issue, but cause another one. This is frustrating and confusing. By changing one thing at a time and making sure it works before moving on, you will prevent a lot of confusion. It also helps to make notes of the things that you have tried, and of the solution when you find one. The more time that you spend programming and debugging, the more familiar various kinds of errors will become.

---
This post was originally published as part of the Programming Historian, and was co-authored by William J. Turkel. It has been reposted here without permission because all work on the Programming Historian is licensed under a CC-BY license. Photo credit: Peter Alfred Hess

Saturday, April 20, 2013

Is the Programming Historian 2 a MOOC?

'Evil Robot' by Jennifer Morrow (cc-by)
A few months ago I was asked if the Programming Historian 2 is a MOOC. For the uninitiated, a MOOC is a Massive OpenOnline Course. They’ve been popping up online for the past couple of years, principally at major American universities like MIT and Stanford, claiming to be able to teach thousands or even hundreds of thousands of students at the same time – for free. They’ve so far had mixed results but it seems most people in academia have an opinion on them – either, meh it’s a fad, damn we gotta get one of those at our school, or the robots have come for our jobs! Defend! Defend!

I can’t speak for the other editors of the Programming Historian 2 (PH2). But I can say: No. I don’t think the PH2 is a MOOC.  If you havn’t found us yet, the PH2 is an open access series of tutorials designed to let humanities researchers get their toes wet with computer programming. The lessons involve learning simple programming tasks that are immediately useful to ordinary working humanists. That might be automatically downloading historical recordsfrom the Internet, or analyzing a collection of sources with topic modeling. All of the lessons are online – like a MOOC – and there is no teacher in the room with you – like a MOOC.

So why no MOOC? For me, what sets a MOOC apart from a classroom-based course is a belief that the tutor-tutee relationship can be depersonalized and made redundant. MOOCs replace this relationship with a series of steps. If you learn the steps in the right order and engage actively with the material you learn what you need to know and who needs teacher?

I don’t think that’s what we’re about. Instead, some of the most exciting feedback we’ve got at the PH2 has been from academics who have used the PH2 as a teaching tool in their classroom. Either they’ve assigned lessons for their students to work through, they’ve challenged students to write lessons of their own, or they’ve used the PH2 to teach themselves a skill that they can then pass along to their students.

That’s not to say you can’t use the PH2 to teach yourself some programming if you havn’t got a teacher. It’s to say the PH2 is not the evil robot looking to take your job away. It’s the friendly robot looking to give your teaching toolkit a few more options, and maybe a new skill or two with which to impress your friends and colleagues. Not unlike a book. And Books havn’t put literature professors out of a job, but they have made English lit courses more interesting.

Wednesday, April 3, 2013

Programming Historian 2 Lessons I'd Like to See

I've been actively part of the Programming Historian 2 team for the past two years and I've been really pleased to see so many people using and learning from the site, including a number of university courses. I learned to write Python code from the original Programming Historian, and I still regularly reference skills and techniques found in the lessons in my day-to-day research.

My role as an editor of the project means I help guide lessons contributed by others through peer review and editing. I'm also always looking around the blogosphere for people working on cool new techniques or writing guides of their own that I think would be useful for practicing historians. For the most part this is a passive process. I sit, I wait, and I watch. But every once in a while I come across something I'd really like to see. So rather than wait, I thought I'd post my personal wish list of Programming Historian 2 lessons I'd like you to write for all of us.

In no particular order:

  • How do you turn a spreadsheet into a database and write custom queries? The jump from an Excel spreadsheet which you can see to a MySQL or sqlite3 database that you can't see is not an easy one. A lesson on making this leap would be well received and widely used I would imagine.
  • What the heck do you do with topic models? The entire digital humanities world seems fixated on topic models these days. Our most popular lesson by far is a tutorial on Getting Started with Topic Modeling and MALLET. But what are the cool things we can do once we HAVE generated topic models? What can we know? How do we use it responsibly? How do I interpret all these numbers and topics?
  • What can we do with our sources once they've been downloaded? I see so many people using programming to curate sources, but far fewer people asking historical questions of their sources using programming. What are some of the ways we can actually answer questions about the past with programming?
I'd be very happy to hear from anyone who'd like to take on these challenges and create a Programming Historian 2 lesson, or from anyone with an idea of their own they think others could benefit from. Check out our submission guidelines and be in touch.

Saturday, June 6, 2009

Collaboratron: an experiment in physical computing

Today is #hackday. Devon Elliott approached me about using a system called "Trackmate" to create a cool user interaction. At it's most basic level, Trackmate sends a message to your computer when an object is placed on a special platform (made out of a piece of plexiglas bought at the dollar store). We wrote a program in Processing which created a visualization that changed depending on which objects a user had put on our plexiglas platform.

In our case, we decided to use the Network in Canadian History & Environment's (NiCHE) member list as our dataset. When they signed up, each of our members were able to choose up to 45 research interest areas. The idea was that this information could be used to help people find those with like interests. Our system used a physical object to represent each of those 45 research interests. Users can put one or several of the objects on the platform and the program will create a dynamic display which will recommend potential collaborators based on the user's selections.

It's just a prototype at this point, but since today is #hackday, we thought we'd share what we've got so far. You can take a look at a video on the NiCHE website.

Sunday, March 29, 2009

How to Write a Zotero Translator

I have put together what I hope is a very comprehensive online guide detailing How to Write a Zotero Translator. This guide is the guide I wished was available for me when I was given the task of writing a Zotero translator for the site http://www.canadiana.org/. The task was part of an internship during my Masters of History at the University of Western Ontario. This internship, during the summer of 2008, was held at the Center for History and New Media — the home of Zotero. When I took on the project, I had no experience with computer programming; when I left, I had created over fifty site-specific translators.

This guide is the product of that brief, yet intensive learning experience.

The goal of this guide is to provide readers enough skills and direction to create a Zotero translator of their own (which I hope they will share). It also gives researchers, libraries, archives and databases a specific resource to make their own translators rather than rely on the overworked Zotero team.

http://niche-canada.org/zotero-guide