Category Archives: self-improvement

Convert docs with OS X terminal

I’m teaching a workshop on Japanese text mining this week and am getting all kinds of interesting practical questions that I don’t know the answer to. Today, I was asked if it’s possible to batch convert .docx files to .txt in Windows.

I don’t know Windows, but I do know Mac OS, so I discovered that one can use textutil in the terminal to do this. Just run this line to convert .docx -> .txt:

textutil -convert txt /path/to/DOCX/files/*.docx

You can convert to a bunch of different formats, including txt, html, rtf, rtfd, doc, docx, wordml, odt, or webarchive. It puts the files in the same directory as the source files. That’s it: enjoy!

* Note: This worked fine with UTF-8 files using Japanese, so I assume it just works with UTF-8 in general. YMMV.

Writing Process: NaNoWriMo and Me

I’ve been meaning to write about my writing process for quite a while now and am surprised, looking back through my blog archives, that I have not yet addressed it.

This post could alternately be titled “How NaNoWriMo Enabled Me to Write My Dissertation in Three and a Half Months” or “The Importance of NaNoWriMo for Academic Writing.” Or just “Do NaNoWriMo at Least Once, People.”

NaNoWriMo stands for “National Novel Writing Month” and has been going since the turn of the twenty-first century. I’ve done it myself since 2002, most years. No, I don’t have a published novel, and in fact I only finished two of them in that time. (And the first one didn’t even “win” — the only criterion for winning is having a file containing 50,000 words — because it came in about 40,000 words when it was done. Oh well. My best and first finished work, so I’m cool with it. In fact, I’m still working on revising that work and trying to cut a version of it into a 10,000-word short story.) But man, what I got out of it.

NaNoWriMo taught me how to write. I don’t mean how to write well, or grammar or mechanics or plot or anything like that. It taught me how to put words on the page. And, after all, that is the first step to writing something. You have to just start making words. Continue reading Writing Process: NaNoWriMo and Me

research diary go

binding

Lately, I feel like I’m stuck in short-term thinking. While I hear “be in the moment” is a good thing, I’m overly in the moment. I’m having a hard time thinking long-term and planning out projects, let alone sticking to any kind of plan. Not that I have one.

A review of my dissertation recently went online, and of course some reactions to my sharing that were “what have you published in journals?” and “are you turning it into a book?” I graduated three years ago, and the dissertation was finished six months prior to that and handed in. This summer, I’ll be looking at four years of being “done” without much to show for the intervening time.

Of course, it’s hard to show something when you have a full-time job that doesn’t include research as a professional component. But if I want to do it for myself — and I do — that means that I need to come up with a non-job way to motivate myself and stay on track.

That brings me to the title of this post. My mother recently had a “meeting with herself” at the end of the work week to check in on what she meant to do and what actually happened. It sounds remarkably productive to me as a way to keep yourself 1) kind of on track, and 2) in touch with your own habits and aspirations. It’s easy to lose touch with those things in the weekly grind.

I decided I will have a weekend meeting with myself every week, and as a part of that, write a narrative of what I did. I’ll write it before I review my list of aspirations for the previous week and then when I compare, not necessarily beat myself up over “not meeting goals” but rather use it as an opportunity to refine my aspirations based on how I actually work (or don’t). As a part of that — to hold myself accountable and also to start a dialogue with others — I’ll be writing a cleaned-up version of that research diary once a week here. Don’t expect detailed notes, but do expect a diary of my process and the kinds of activities I engage in when doing research and writing.

I hope this can be helpful to a beginning researcher and spark some conversation with more experienced ones. While this is a personal journey of a sort, it is public, and I welcome your comments.

academic death squad

Are you interested in joining a supportive academic community online? A place to share ideas, brainstorming, motivation and inspiration, and if you’re comfortable, your drafts and freewriting and blogging for critique? If so, Academic Death Squad may be for you.

This is a Google group that I believe can be accessed publicly (although I’ve had some issues with signing up with non-Gmail addresses) although you appear to have to be logged in to Google to view the group’s page. Just put in a request to join and I’ll approve you. Or, if that doesn’t work, email me at mdesjardin (at) gmail.com.

Link: [Academic Death Squad]

I’m trying to get as many disciplines and geographic/chronological areas involved as possible, so all are welcome. And I especially would love to have diversity in careers, mixing in tenure-track faculty, adjuncts, grad students, staff broadly interpreted, librarians, museum curators, and independent scholars – and any other career path you can think of. Many of us not in grad student or faculty land have very little institutional support for academic research, so let’s support each other virtually.

In fact, one member has already posted a publication-ready article draft for last-minute comments, so we even have a little activity already!

Best regards and best wishes for this group. Please email me or comment on this post if you have questions, concerns, or suggestions.

よろしくお願いいたします!

*footnote: The name came originally based on a group I ran called “Creative Death Squad” but the real origin is an amazing t-shirt I used to own in Pittsburgh that read “412 Vegan Death Squad” and had a picture of a skull with a carrot driven through it. I hope the name connotates badass-ness, serious commitment to our research, and some casual levity. Take it as you will.

don’t learn to code

There is a lot of speculating going on, on the Internet, at conferences, everywhere, about the ways in which we might want to integrate IT skills – for lack of a better word – with humanities education. Undergrads, graduate students, faculty. They all need some marketable tech skills at the basis of their education in order to participate in the intellectual world and economy of the 21st century.

I hear a lot, “learn to code.” In fact, my alma mater has a required first-semester course for all information science students, from information retrieval specialists to preservationists, to do just that, in Python. Others recommend Ruby. They rightly stay away from the language of my own training, C++, or god forbid, Java. Coding seems to mean scripting, which is fine with me for the purposes of humanities education. We’re not raising software engineers here. We tend to hire those separately.*

I recently read a blog post that advocated for students to “learn a programming language” as part of a language requirement for an English major. (Sorry, the link has been buried in more recent tweets by now.) You’d think I would be all about this. I’m constantly urging that humanities majors acquire enough tech skills to at least know what others are talking about when they might collaborate with them on projects in the future. It also allows one to experiment without the need for hiring a programmer at the outset of a project.

But how much experimentation does it actually allow? What can you actually get done? My contention is: not very much.

If you’re an English major who’s taken CS101 and “learned a programming language,” you have much less knowledge than you think you do. This may sound harsh, but it’s not until the second-semester, first-year CS courses that you even get into data structures and algorithms, the building blocks of programming. Even at that point, you’re just barely starting to get an idea of what you’re doing. There’s a lot more to programming than learning syntax.

In fact, I’d say that learning syntax is not the point. The point is to learn a new way of thinking, the way(s) of thinking that are required for creating programs that do something interesting and productive, that solve real problems. “Learning a programming language,” unless done very well (for example in a book like SICP), is not going to teach you this.

I may sound disdainful or bitter here, but I feel this must be said. It’s frankly insulting as someone who has gone through a CS curriculum to hear “learn a programming language” as if that’s going to allow one to “program” or “code.” Coding isn’t syntax, and it’s not learning how to print to the screen. Those are your tools, but not everything. You need theory and design, the big ideas and patterns that allow you to do real problem-solving, and you’re not going to get that from a one-semester Python course.

I don’t think there’s no point to trying to learn a programming language if you don’t currently know how to program. But I wish the strategies generally being recommended were more holistic. Learning a programming language is a waste of time if you don’t have concepts that you can use it to express.

 

* I’m cursed by an interdisciplinary education, in a way. I have a CS degree but no industry experience. I program both for fun and for work, and I know a range of languages. I’m qualified in that way for many DH programming jobs, but they all require several years of experience that I passed up while busy writing a Japanese literature dissertation. I’ve got a bit too much humanities for some DH jobs, and too little (specifically teaching experience) for others.

programming practice problems

One of the hardest things for me about learning a new programming language is not getting an understanding of the syntax or overarching concepts (like object-oriented programming or recursion), but rather a lack of opportunity for practice. It’s one thing to read a few books about Python, and quite another to look at others’ nontrivial code, or write nontrivial code yourself.

However, I’m often at a loss for ideas when I try to come up with programming projects for myself. Call me uninspired, but I just don’t have many needs for writing programs in my daily life, especially complex ones. And I don’t have any big creative ideas, either. I don’t even have uncreative ideas. So what to do?

It turns out there are a few good resources online for practice programming problems. They’re language-agnostic, presenting a problem and asking you for its solution. Unfortunately, there are only a few resources for this, but I thought I’d share the ones I found.

The first is the Association for Computing Machinery’s International Collegiate Programming Contest. This provides the contest problems from 1974 to the present! Talk about a treasure trove of programming challenges.

Second, UVa Online Judge. This site contains hundreds of programming problems, some simple and some complex. They have volume upon volume of problem sets. You could spend the rest of your life doing the problems on this site.

Does anyone have additional resources to add?

I’m done!

As of today, I’m officially done with all requirements for my PhD. So I don’t have a conferred degree yet, but I think I can finally order people to call me “Doctor Molly” now.

Woohoo!

Keep an eye out for a PDF copy of my dissertation, which will be posted on this site relatively soon – sooner than the copy in U of M’s institutional repository, which won’t be released until December. So if you’ve got some time on your hands and would like to read 259 pages on the history of the book, please stay tuned.

what books to read and how to read

I came across a book a while ago from 1912 entitled What Books to Read and How to Read when searching around in the university library basement. (Incidentally, this is where all of my wonderful finds come from – including the ones that make up the basis of my research!) It’s such a fascinating and still-relevant book that I’d like to introduce it here. (Full citation: David Pryde, LL.D. What Books to Read and How to Read: Being Suggestions for Those Who Would Seek the Broad Highways of Literature. New York and London: Funk and Wagnalls Company, 1912.)

The book starts off with the anxiety that is surely familiar to us: there is too much information out there, and it’s growing exponentially. It’s overwhelming. The number of books being printed is too much for any one human to deal with and the problem is only getting worse. What to do in the face of this?

Well, this book has an answer. First, how to read books. You don’t want to become a “dungeon of learning,” someone who reads a wide variety but can’t apply any of it to real life. Instead of just ingesting, investigate first. The advice reads like a library seminar on reliable sources and searching for research leads. Learn something about the author first. Read the preface carefully. Take a comprehensive survey of the table of contents – “if the preface is the appetizer, the table of contents is the bill of fare.”

Give your whole attention to whatever you read. “A book is a representation of the best workings of the author’s soul. In order to understand it, we must shut out our own circumstances, cast off our personal identity, and lose ourselves in the writer before us. We must follow him closely through all his lines of thought, understand clearly all his ideas, and enter into all his feelings. Anything less than this is not worthy of the name of reading.”

Be sure to note the most valuable passages as you read. Write out in your own language a summary of the facts you have noted.

Most important? Apply the results of your reading to your every-day duties.

This guide is a paean to close reading and taking books to heart. It’s a guide to knuckling down and processing information in a useful way, rather than simply succumbing to the overwhelming amount of books out there. It’s reading for use, not reading for reading’s sake.

The second half of the book involves a full bibliography of books you should read, and annotations of them. It’s a catalog of useful knowledge that everyone ought to be familiar with.

There is much to be said for going outside a set canon and reading widely, and for not relying on authoritative sources to tell you what to read. But I can’t help but wish there were an updated version of this book – and perhaps the “how to read” does not really need to be updated. Actually, the bibliography probably doesn’t need to be either. But it could be adapted and expanded to meet the specific contents of our information overload now. In any case, I found it remarkable that 100 years ago this year, someone was writing in a very 21st-century way about just the same problems that we wrestle with now, and over which many anxious words have been spilled.

Information. It’s always a problem. The question is what you’ll do about it. Say what you will about the contents of any particular bibliography, but the advice of Mr. Pryde is timeless.

thinking in functional programming

My internship this summer gives me the opportunity to get acquainted with and even use some XSLT – misleadingly the “stylesheets” of XML.

XSLT has been hard to wrap my head around, not least because “stylesheets” and “used to format XML” make me think of CSS, not – well, functional programming. It’s been a good many years since I got to play around in Lisp, let alone make something with it, and this has brought me back to those two great semesters of AI electives that introduced me to this way of thinking. It took a few weeks to get into it, but once I “got” how Lisp worked at a more intuitive level, I remember my impression: I am thinking in a different way. It wasn’t just about programming, it was about problem solving, and about a way of looking at the world.

Diving into a functional programming language again has got me thinking about that experience. Learning how XSLT works has of course made me remember a time when Lisp made sense, because XSLT is functional programming. If I had been introduced to it in that way at the outset, it would have clicked much sooner. Now it makes me yearn a little for the time when I didn’t just know that I was working in a different way, but when that way came to make sense and I was able to start going somewhere with it.

But when I learned Lisp in the context of an AI (artificial intelligence) class, I didn’t learn it as “functional programming” then either. I wasn’t introduced to it in the context of lambda calculus, which I came to find much later – last semester – in a natural language processing course. I knew it was different, but I didn’t know how on a bigger picture level.

Now that I have that bigger picture, I am appreciating this way of thinking more and more.

Why is functional programming “hard”? Why is it something that I had to get used to for a time before it clicked? I have an answer this time – because I have been doing imperative programming for so long, because that’s how I was introduced to programming (I didn’t attend MIT after all), and because that has become the natural and intuitive way for me to solve a problem. But imperative programming isn’t a more natural way of thinking about things. It’s a different way. Obviously, these two ways of approaching problems have different applications, but the elegant and concise ways of approaching problems that functional programming offers are perhaps even more appealing to me now.

Because I am not an expert, I write this not to make a profound statement about how to approach problem solving, but to share a great article about where functional programming came from, why it’s so appealing, and the things it makes possible. I give you,

“Functional Programming For the Rest of Us.”

Take the 10 minutes to read this and enjoy!