Importing Stripe Transactions into Xero

Posted on by
Reply

About a year ago, Paul wrote about the trials and tribulations of using PayPal. There is a lot to not like about PayPal, though most of my criticisms result from doing the bookkeeping for a company that posts a lot of PayPal transactions. Around the time he was writing, Stripe came to Canada, and we cheered (“Hurrrrah!”), because it meant we had another option. A newer option. An option whose UI might be almost navigable! Paul signed up, delighted in Stripe’s really snazzy documentation, and started writing a front end for us to send invoices that clients could pay by credit card, using Stripe.

At our accountant’s suggestion, we use Xero for our bookkeeping at WonderProxy, and, for the most part, we’re happy with it. Xero can automatically import statements from your bank accounts (including your PayPal account, which is important for us), track accounts payable and receivable, and track transfers between accounts seamlessly. Like I said, we’re mostly happy with it: it has trouble with one of our credit cards, so I have to manually import its statements, which is a bummer, but what can you do? Customer support has always been prompt and, while they’ve sometimes been unable to fix the problem, have at least explained what’s happening and suggested workarounds. It’s satisfactory… and our accountant likes them, so y’know, that seems like a good thing too.

When we started using Stripe, Paul and Will wrote their own front end to manage payments. It’s really easy to use, and has made invoicing customers a genuine pleasure, especially when I think about creating PayPal invoices. It’s another bit of functionality that we’re really happy with. At the time, we didn’t really think about how to get all the Stripe activity correctly represented in Xero. I didn’t actually bother to tackle the problem until our financial year ended and it was time to deal with taxes. Xero supports Stripe as one of its payment processors for its built-in invoicing service, but we don’t use that, and I couldn’t figure out how to make Xero automagically figure out our Stripe transactions otherwise.

Armed with the knowledge that only tracking Stripe’s transfers to our bank account was Bad Accounting, I set out to import our Stripe transactions and properly reconcile them against the transfers to our bank account. If anyone is trying to do the same in Xero, this will hopefully help.

  1. Create a new bank account for your Stripe transactions. From the Accounts tab, choose Add Bank Account. I chose the Bank Account account type. It’s probably the most accurate representation of what Stripe is, given the options.
  2. Log into Stripe, and download all your transactions as a CSV. Save them as something meaningful, like “Stripe Transactions Date-Range”
  3. Still logged into Stripe, navigate to the bank transfers, and download all the bank transfers. You’re going to match these against the statement lines in your bank account, so that everything matches up nicely. Save them as something meaningful, like “Stripe Transfers Date-Range”.
  4. If you reconciled the transfers from Stripe to your bank account (like I stupidly did), you need to un-reconcile all of them. This is a pain, but necessary. Do that now.
  5. Create CSV subfiles.First, Xero doesn’t understand Stripe’s time format. Awesome, eh? So, you need to remove the time portion of the date-time field. I did this in TextMate with a really long cursor so I could delete it all at once. You could also create another column and do some magic in Excel, selecting only the yyyy-mm-dd portion of the original column. Make sure you do this for both the transactions and the transfers.Second, Stripe’s CSV output doesn’t deal with fees and refunds in a way that Xero understands. You need to pick the columns that Xero will actually need and create new CSV files:
    • a “Payments” file that includes the ‘Created’, ‘Description’ and ‘Amount’ columns,
    • a “Refunds” file that includes ‘Created’, ‘Description’, and ‘Amount Refunded’ for any refunds, and
    • a “Fees” file that includes ‘Created’, ‘Description’, and ‘Fee’.

    For some reason, Xero likes the first column to be the date column, so putting ‘Created’ first is important.

  6. Import your appropriately-formatted CSV files into Xero. Reconcile. Rejoice!

It’s a weirdly complicated process, since Stripe’s CSV dump isn’t formatted in an immediately usable way. I’m curious about how Xero deals with Stripe transactions that result from its invoicing service. Perhaps there’s something brilliant that I’m missing. Nevertheless, I’m happy that this way, we account for the full amount our customers pay us, the fees we pay Stripe, and the amount netted, which is transferred to our bank account. I’m planning to do the Stripe import (manually) once a month, so it’s not too onerous. If I’m particularly fancy, perhaps I’ll write something to automate it for me… probably not though.

Parsing Sentences for Easy Reading

Posted on by
Reply

For the past year, I’ve had the pleasure to work on and off for a Toronto-based consultancy that focuses on accessibility. In addition to doing training, accessibilty audits, and development, they provide video captioning and description services, which is where I fit in.

Unlike those mysterious beings that close caption live television, I caption videos – generally university lectures. It’s interesting work, and was a lovely part-time job while I was finishing up my Masters. I’ve kept up with it because I enjoy it… and extra pocket money is always enjoyable. What I did not realize when I started, however, was that it would also have a lasting (positive) impact on my work as an IA/tech writer.

You know how sometimes, you’re reading, and a line break hits in the wrong spot, and it’s weird? Bad sentence parsing. I usually only notice if it’s two or three lines of text, like a PowerPoint title, or subtitles on a video. Poor sentence parsing makes it harder for readers to read smoothly: in captioning in particular, you want people to be able to read quickly and glean all the information they’re reading without becoming confused by a subject-object split. As a person whose focus is on expressing concepts clearly, this has been something of a revelation. While I’m not a designer, I necessarily do some design in my work, particularly since I’ve started freelancing. Parsing is something that I increasingly think about, and I think it’s making my visual work easier to understand.

Take, for example, the post-it note that I have had stuck to my monitor, reminding me to write this post:
Post it note reads Parsing Sentences for Easy ReadingThat’s pretty solid. I’m happy with that parsing. I might easily have written this, though:

Parsing Sentences for
Easy Reading

Hopefully you see that this is a less smooth reading experience. Let’s take another example, this time borrowed from a fantastic Girl Geeks Toronto event that I went to last night (recap post to follow). The title of the event was “Designing for Digital: Processes and Planning for Powerful Solutions.” Here are two ways we could write that on the title slide of our presentation deck:

Designing for
Digital: Processes
and Planning
for Powerful Solutions
 
Designing for Digital:
Processes and Planning
for Powerful Solutions

I think the second one is easier to parse, and easier to read. With presentation software and design software, where you create text boxes and write in them, it’s easy to rely on the automatic text wrapping. I have started to fight that urge, and to think about how best to manage my line breaks. I’m not advocating for manually line breaking everything, but for titles or short, punchy sentences, it’s something to think about. If reading it aloud sounds wonky, try moving the line break. Your readers will thank you, even if they don’t realize it.

Edited to add:

Another excellent example care of Paul, from a Zipcar ad in the New York subway:

My Grade 7 & 11 English Teacher and the Word ‘Got’

Posted on by
1

As I’ve alluded to before, my high school program was pretty sweet. Its enriched program, which I was in, was challenging and fun, and meant that we had the best teachers at the school teaching us. Many of them were older, and most have since retired to lives of contemplation, pigeon racing (seriously!), poetry, and music. The youth of today don’t know what they’re missing.

I learned a lot in high school: a strong basis in chemistry and the physical sciences, the ability to play the french horn, a remarkable willingness to dissect deceased vertebrates without wearing gloves (why didn’t they give us gloves?), a general understanding of archery, a weirdly in-depth knowledge of the history of Quebec, and the ability to throw a football, among others.

Throwing a football has come in handy (my boyfriend’s brother, who played football in college, was impressed, for instance), but the thing that comes to mind most often, particularly as I’ve started writing professionally, is a lesson I learned first in Grade 7, and then again in Grade 11, when Mister Holt was my English teacher.

Mister Holt is a fantastic teacher. I say ‘is’, because, while I understand that he has retired, the lessons he taught me have stuck. One of the core components of English at my high school was public speaking. Most teachers made their students get up in front of the class and give a speech that they’d written. There was usually a list of topics. I recall “Nature versus Nurture” being one, as well as “Mass Media”. (It was obviously the late 90s / early 00s.) Mister Holt didn’t hold with that kind of hokum for we young grade sevens: he made us learn card tricks. Card tricks, he said, gave you something to do with your hands, while also forcing you to speak, and to keep your audience’s attention. He handed out a twenty-page photocopied packet of papers that detailed a bunch of card tricks: I remember Wild Bill Hickok’s Hand and Houdini’s Double Talk Card Trick as the hardest. They both required a great deal of memorization, and the ability to engagingly tell the story that went along with the cards. I’m 90% sure I can still do Houdini’s Double Talk, but I never really got the hang of Wild bill. After two weeks of practice, we performed the card tricks one-on-one with Mister Holt. It was delightful, and a nice way to ease into the world of public speaking. Come grade eight, the concept of speaking was far less terrifying – it’s not like you had cards to screw up!

But, while that stands out, and – I think – helps to illustrate his somewhat unconventional approach to English education, card tricks are not what come to mind most days.

Mister Holt hated the word ‘got’. Got, he argued, was a lazy word. There is almost always a better word to express what you are trying to express. “I got home”, while perhaps accurate, is weaker than “I arrived home”. “I got an A” less expressive than “I earned an A”, “I’ve got the chicken pox” less evocative than “I have fallen ill with the chicken pox” or “I’m beset with the chicken pox” or “Shit, I’ve finally caught the chicken pox”.

As I recall, Mister Holt was a published writer of either short stories or poetry. I can’t find any trace of that online, so perhaps I’m mistaken, but in any case, much of our writing was of a creative nature. As such, using strong descriptive language was particularly prized. As we started writing more essays, precision of language only got became more important. I asked some friends from high school about this, and everyone who had Mister Holt as a teacher seems to have a little voice in the back of their heads preventing them from writing ‘got’ or ‘get’. My friend who just finished law school is particularly susceptible.

As a tech writer, precision of language is everything. The other day I was typing a sentence, started to write ‘got,’ and said “No!”. An moment later, I had gone in a different direction. Teachers impact our lives: Mister Holt taught me the value of choosing my words carefully (and I always have a card trick up my sleeve for parties, pun intended); Madame Azar, the majority of my French grammar; and Mister Pharès taught so much math and physics that I didn’t learn anything new until Calc 3, despite the three post-secondary math classes that preceded it.

I don’t write in French that much these days, though, and I haven’t needed to integrate in a long while… I write every day, though, and two university degrees don’t consciously impact me nearly as much as two years’ of Mister Holt’s instruction does. So, next time you go to type ‘got’, stop. Reread your sentence, and try to replace that ‘got’ with something better. Your writing will improve, and alumni of Mister Holt’s English classes won’t twitch when reading your wise words.

The Quest for the Cronut

Posted on by
Reply

I awoke this morning slightly before 5am, and I wasn’t even grumpy about it! “Really?”, you politely ask. Indeed. I awoke slightly before my alarm, bundled up, grabbed my purse, and departed on what might be my last New York adventure: The Quest for the Cronut.

For those of you who have been living under a rock, a cronut is a mysterious baked good invented by the Dominique Ansel Bakery – that is, as its name suggests, a cross between a croissant and a doughnut.

Cronuts are all the rage in New York: people line hours before the bakery’s 8am opening for a chance to buy a maximum of two cronuts (cronutae?). As a lover of a baked good, and something of a croissant aficionado, I knew it was something I had to do before I left New York. At worst, I thought, it’d be a good story. And it was with that mindset that I existed my apartment and set out.

The adventure started early: looking up the street, I noticed some small scurrying things on the sidewalk near the garbage – my first non-subway track New York rats! SUCH EXCITEMENT! I crossed the street, startling the gentleman walking along the road who I suspect was more accustomed to people crossing the street to avoid him, rather than joining him, and headed west toward Soho.

New York may be the city that never sleeps, but the Lower East Side was definitely sleeping at 5am. Mildly creeped out by the lack of humanity, I hopped a cab the rest of the way to the bakery. As I approached it, I saw a small crowd: the beginning of the line! One man had a sleeping bag (it was chilly), people had chairs, a nice guy offered to share his bench with me (which I gratefully accepted). The early liner-uppers were super friendly: people were obviously excited to sample the cronut wares, and were content to be waiting a few hours for sake of it.

A coworker who lived nearby joined me (with a couple of chairs), and we chatted the hours away as the sun rose and the line lengthened. It was really nice, and I love that they have a security guard who ensures that no one tries to butt into the line. About twenty minutes before the bakery opened, they came around with freshly-baked madeleines, and before I knew it, I was inside, ordering a cup of tea, a lovely ham and cheese croissant, and two cronuts. My coworker got two as well, and once everyone had arrived MongoDB’s docs team (the four of us who were in the office, at least) feasted.

Delicious fig mascarpone cronuts. Omnomnomnomnom.

The cronut was delicious: reminiscent of a packzi, but crispier and tastier. Would I line up for 2.5 hours for one again? Probably not – not unless a friend asked me to – but there’s something wonderful to be said for doing something ridiculous. I mean, getting up at 5am for a doughnut isn’t like going bungy jumping or something (though I like bungy jumping, so that’s not a great example), but the ritual aspects: getting up, bundling, walking or hailing a cab, chatting with your line-mates… it’s a great experience, and well worth the lost sleep.

It’s easy to say no to things: when I lived in New Zealand, I had an acquaintance who had lived there for 8 months but hadn’t done any of the touristy things “because [she] lived there, [she] wasn’t a tourist”. I lived there too, but I was going to museums and walking tours, and having awesome weekends seeing and doing. It’s easy to sleep, or hang out and work, or watch Netflix in bed when you’re in a new city. I’m glad that I’ve managed to combat the inertia, and I know that I’ve had a more exciting life than I otherwise would have. The cronut was super tasty, but the experiences are what stick with you… the experiences, and the butter…

Better Writing is One Bundle/Package/Plugin Away

Posted on by
2

Two months ago, I downloaded and installed a writing tools bundle for TextMate 2, one of my favorite text editors. “English Highlight” as it is so innocuously named, does three awesome things:

  1. It highlights weasel words (few, very, fairly, quite, etc.)
  2. It highlights passive sentences (or, should I say, passive sentences are highlighted)
  3. It highlights duplicate words (not not that you’d ever do that).

Christopher Alfeld’s “English Highlight” is an adaptation of Matt Might’s shell scripts. Matt Might is an Assistant Professor at the University of Utah. He noticed that his students tended to ‘abuse’ the passive voice, use weasel words, and repeat words, so he wrote some bash scripts to identify these and integrated them into their LaTeX build. This has spawned a variety of plugins for common text editors. I’ve complied a list of plugins at the bottom of this post.

TextMate 2 with English Highlight screenshot

Screenshot from my TextMate: purple highlighting indicates weasels, passives, or repeated words.

I am not going to lie: it was demoralizing when I first opened up a file and saw tons of purple. Apparently nine years of post-secondary education (6 of which were in the sciences) bred a deep love of the passive voice. Similarly, two years of graduate school, where the answer to every question is ‘it depends’, may have left me generous with my ‘various’, ‘numerous’, and ‘few’s. Highlighting my shortcomings in purple makes it easy for me to identify areas that need work, and to quickly make my writing stronger and clearer.

Weasel Words

The thing about weasel words is that they rarely add to a sentence: they either make your sentence vague or unnecessarily wordy, neither of which is a positive. Admittedly, sometimes you want to say that something is ‘quite’ something. That’s cool! You’re allowed! You might not realize how often you say ‘quite’ or ‘very’, though, and if it’s not helping, it’s hindering.

I went looking for a wishy-washy sentence that I’d recently wrote, but couldn’t find one: it seems my highlighter has done the trick! I’m afraid to open any of my old research papers, so I’m borrowing an example from Matt Might:

Bad: False positives were surprisingly low.
Better: To our surprise, false positives were low.
Good: To our surprise, false positives were low (3%).

I know I have a tendency to overuse ‘various’, ‘numerous’, and ‘fairly’. Highlighting those words draws my eye back to the sentence and makes me think about ways I can improve it. Often it’s as easy as deleting the word.

Passive vs. Active Voice

The passive voice thing is less straightforward than the weasel words. The passive voice has historically held a hallowed position in the sciences, where the prevailing opinion seems to be that science should mysteriously emerge completely independent of the scientists who do it. For this reason, students have to write “10mg of magnesium were massed” in their lab reports, rather than “I massed 10mg of magnesium.” This may have been a contributing factor in my changing majors from chemistry to environment, where I was occasionally allowed to write as though I existed.

During the aforementioned environment undergrad, I attended a somewhat rebellious lecture by Linda Cooper. Linda Cooper is a lecturer at McGill who studies science communication and teaches classes on science writing. She argued that using “direct, active-voiced sentences” makes sentences stronger and easier to read, and that we should all stop blathering on endlessly in the passive voice and instead, choose to use the active when appropriate. It’s easy to see that she’s right when you compare passive-voiced to active-voiced sentences:

Original: If MMS is being run with DB Profiling enabled, further permissions are required.
Revised: If MMS is running with DB Profiling enabled, the user requires additional permissions.

While both sentences point to the same concepts: that running MMS with DB profiling means you’re going to have to do something with permissions, the first sentence is far more vague. What sort of ‘further permissions’ are we talking about? Permissions for MMS? Permissions for you-the-user? Some sort of network permissions? Who knows! The second sentence get to the point: the user requires additional permissions. In either case, the next paragraphs describe what those permissions are, but the revised sentence guides the reader more quickly to the correct answer.

There’s certainly times where passive sentences are appropriate: for instance, I haven’t managed to rewrite “MongoDB is designed specifically with commodity hardware in mind…” as an active-voiced sentence, and I doubt I will. Expunging all passives from the record isn’t the goal here: the goal is to write as clearly as possible, and to be more aware the choices you make when writing.

Resources

As mentioned above, Matt Might’s scripts have been adapted for a number of text editors. I particularly like the name of the emacs / vim mode. If you’re doing any sort of writing – technical or not – I highly recommend installing one of these extensions and trying it out. It makes a huge difference.

Classification, MongoDB Operators, and Kitchen Chairs

Posted on by
Reply

ROCM: Representation, Organisation, Classification, and Meaning-Making was a required class when I did my Master of Information. At the time, I complained incessently about how useless it was, how I was never going to use any of it in real life… Well, I was wrong.

A cat laying upon a Roomba

Despite being sat upon in the kitchen, this is probably not a kitchen chair. Credit: barbostick

Yesterday morning, I spent about four hours thinking about ROCM as I reorganized MongoDB’s operators page. One of our professors had a tendency to ask “What makes a kitchen chair a kitchen chair? Is any chair in a kitchen a kitchen chair? Is anything you sit on? If you sat on your dog while he’s in the kitchen, is he a kitchen chair? If you carry a chair that’s usually in your kitchen into the living room, is it still a ‘kitchen chair’?”, etc. The “kitchen chair” metaphor became something of a meme among my cohort, one which inevitably gets brought up whenever we’re together.  The crux of the kitchen chair debate is the question of what makes stuff fit into the categories it fits into. This is really the issue that anyone involved in classification or organization has to grapple with, hopefully with the knowledge that no solution is perfect, but some are better than others.

This week, the question was “What makes these MongoDB operators fit together?”. Some groupings were obvious: the ‘Logical’ operators (‘or’, ‘and’, ‘not’, and ‘nor’) go together nicely. Same with the operators related to geospatial queries, and those specific to arrays. My problem was what’s left: the operators we’ve now classified as ‘Comparison’, ‘Element’, or ‘Evaluation’.  In a sense, the ‘Element’ category is ridiculous: by their nature, queries involve elements… for that matter, all queries involve comparison so the ‘Comparison’ category is a bit fraught as well. But what’s an IA-minded technical writer to do? Either give up and put them all in one long, awful list (which is unideal), or categorize as best you can, knowing that it won’t be perfect (also unideal). Clearly, I went with the latter.

I think the categories we settled on will be meaningful for our readers, while also being factually accurate, which is really the goal. The fact that there’s some weirdness is unfortunate, but sadly unavoidable.

The inevitable failure of classification systems is a central theme of Geoffrey Bowker and Susan Leigh Star’s Sorting Things Out: Classification and Its Consequences. Bowker and Star’s examples really highlight the power of classification: they discuss tuberculosis patients, and the ways that wishy washy diagnoses ruined peoples lives; talk about the incredibly inconsistent and damaging categorization of people under Apartheid in South Africa, and discuss nursing interventions classification and its impact on both nurses’ and patients’ lives. Sorting Things Out is one of those texts that I cited in (nearly) every paper I wrote during my MI, because it always applied. At its core, the book is about highlighting the ways that classification is – or becomes – invisible, and how people grow to accept categories as natural.  As people who care about the ways that we structure information, recognizing the theory behind classification and its implications can make us better at determining an ideal structure for our use case, and at recognizing the ways that it might fail.

Sorting Things Out is on sale at Amazon right now, for under $20. I paid about $50 when I bought my copy, so now’s a good time to bone up. It’s a great read that has instilled in me the need to regard existing classification systems with a critical eye rather than accepting them at face value, and to be far more thoughtful when creating my own.

Breaking the Silos

Posted on by
Reply

An exciting thing happened at MongoDB Inc. today. For about fifteen minutes mid-afternoon, a diverse smattering of MongoDBers converged on our cafeteria: sales people, HR, marketing, and engineers stood shoulder to shoulder, chatting and commiserating. I learned one of my coworkers used to work at an amusement park, heard some hilarious stories from the marketing department, and laughed along as we misheard an engineer talking about his DOM (document-object model).

Dippin Dots

Omnomnom. Rocky road Dippin’ Dots.

What prompted this convergence? Last week, the lovely person who sits across from me got it into her head that she wanted Dippin’ Dots, so she ordered 35 servings to be delivered (packed with dry ice) to the office. It apparently takes a week, and they arrived mid-afternoon. It seems that all it takes to bring a group of people together is the prospect of unexpected astronaut ice cream.

Companies sometimes put a great deal of effort into getting their employees to talk to each other: the all hands meeting phenomenon is probably a good example.  On a smaller scale, maybe all it takes to get more people talking to each other is a random treat in the middle of the afternoon, unexpected and unplanned. Bonus points if it’s food you’ve not eaten since you were a kid at an amusement park.

 

Learning Emacs

Posted on by
2

For the past few weeks, on top of writing delightful documentation and exploring New York, I have been executing an herculean undertaking: learning Emacs.

10gen’s lead tech writer is an avid Emacs user: he uses Emacs for his email, his chat client, and, of course, for editing the docs. We write MongoDB’s docs in Docutils, and (mostly) easy to write. It helps to have a text editor that will do reStructuredText syntax highlighting, though, and those seem to be rare. My beloved Coda 2 does not appear to do it; Sublime Text’s highlighting is inconsistent, and its tabs a pain in the ass. TextMate is great, but even it sometimes fills me with rage with auto-indent behaviours that I can’t figure out / turn off.

So my colleague suggested I try out Emacs. It was lateish on a Tuesday afternoon, and I said “why not!” and promptly downloaded the GUI version of Emacs. He kindly gave me his Emacs configuration file so that I would have all his handy reStructuredText-facilitating extensions, and gave me a quick crash course. I suspect part of his enthusiasm was the prospect of being able to use Emacs on my computer when I needed his help with something, but a good deed is a good deed regardless. After a 45-minute pep talk, I was left feeling not unlike I did when my parents bought me my first iMac back in… 1998: “this is very cool, now how the heck do I turn it off?”

Aside: for those of you who do not recall, OS 9 hid the Restart / Sleep / Shutdown menu items in the “Special” menu. The first night I had my iMac, I ended up unplugging the computer in a fit of “oh god what have I done?” and having a cry because of all the money that had been spent on a computer that I had no idea how to use. I bought David Pogue’s “iMac for Dummies,” and life improved immeasurably.

On Wednesday, I remembered that Sacha Chua was an Emacs user, and vaguely recalled her posting a Beginner’s Guide to Emacs. I printed it out, propped it up on my desk, and have been adding to it ever since. Much like the purchase of Pogue’s book, this was an excellent life choice. There are a few things that bug me about Emacs: memorizing keystrokes isn’t something that I’ve ever been very good at, and I don’t like that (given my current configuration) I can’t highlight with shift and the arrow keys. As a learning experience, though, it’s been really pleasant, especially now that I’m starting to remember how to do things (I can now consistently write files, copy & paste, and move to the beginning and ends of lines!).

It sounds goofy, but I’ve always enjoyed the idea of being a person who is good at command line-y text editors. Whenever I see someone mysteriously navigating without a keyboard, typing furiously as windows pop up and disappear, I think it’s neat. Admitting this is both amusing and embarrassing: I’m forcing myself to learn Emacs because I think it looks cool.

Despite my somewhat goofy reasoning, Emacs is kind of fun! At a minimum, it’s made me realize that the way I’ve always interacted with files is not the only way, and it has made my emacs-loving colleague’s workflow is much less mysterious to me. I also really like that I can create a buffer that will execute a command for me: I like being able to generate the html version of whatever I’m working on and being able to click on links to the file if there’s an error.

If you’re just starting out and have an intense desire to look cool learn emacs, check out Sacha’s guide. I also suggest finding someone who is patient and kind, and willing to help you learn.

Posted on by
Reply

I just started using the Freshbooks iPhone app, and I have to say, I’m really pleased! I’ve been using Freshbooks for a while now, and it’s definitely had an impact on reminding me to track my time and invoice.

So the app is easy to use, and I found it relatively easy to get a new project set up and to start tracking time. It seems to have all of the same functionality that Freshbooks’ website has: you can prepare and send invoices, create projects, track time, log expenses, etc. I doubt that I’ll use any of the functionalities beyond time tracking, though: for me, the strength of the app is that I can work wherever, and that the tracker doesn’t depend on me not quitting the browser. The timer is also kind of cool-looking, which is fune.

So, if you bill by the hour, you should absolutely check Freshbooks out… and get the app. I think it’s pretty silly that I waited this long.

NY Perl Mongers

Posted on by
Reply

It seems I haven’t blogged since moving to New York to work at 10gen, three months ago. I guess all my writing hours have been going towards writing MongoDB’s ever-improving documentation.  Now that things are quieting down a bit, and I am only semi-weekly embroiled in a well of git/docs build-enduced despair, I’m pleased to be getting back into the swing of things.

Last night, the New York Perl Mongers meetup took place in our offices. Mike Friedman, one of my coworkers who works on MongoDB’s Perl driver, among other things, spoke about the Perl API, which apparently allows you to use C to do stuff for you more quickly, and Damian Conway gave an excellent talk on giving better presentations. While Mike is lovely, I probably wouldn’t have attended just to hear his talk – I know very little about Perl and less about C – but some of my coworkers had heard Damian speak previously at OSCON and highly recommended we attend, so attend I did.  Both Mike and Damian were fantastic speakers, and I learned a lot from both… I’m not about to start writing Perl code (let alone using the Perl API), but I took some notes from both talks, and figured they might be worth sharing.

Mike Friedman: Perl API for the Mortally Terrified

“Using C gives you a better appreciation of how powerful dynamic languages are.”

I must admit that this talk went well over my head: not knowing much of anything about Perl, other than that it was another programming language in the family of Python and Ruby and such, I certainly missed some of the more nuanced points. Nevertheless, Mike listed a number of reasons why the Perl API might be something you should look into, which boiled down to:

  • you can make things faster by writing bits of your program in C
  • the Perl API lets you work with the myriad of C libraries that people have already helpfully written
  • the Perl API  lets you do fancy stuff that would be hard/impossible in Perl

He then spoke about the Perl API itself and how you work with it. I did not take notes on that, but I did draw a very confused thought bubble that said “Why are none of these function names actually meaningful?” If you’re a Perl developer and you’re interested in starting to use the Perl API, Mike suggested you check out Practical C Programming by Steve Oualline and the infamous K&R C Programming Language book… so I suggest that too.

Damian Conway: Instantly Better Presentations”

I had no idea who Damian Conway is. I googled him during the pause between Mike’s talk and his, and it seems he’s a well-known Perl developer, and an extremely well-known speaker. I cannot speak to the first thing, but I can say he is, indeed, an excellent speaker. I like to think that I give a pretty decent presentation – I was always well reviewed when presenting in school, at least – but as a person early on in my career who has (no longer) secret aspirations to speak at conferences and share my knowledges with the world, it seemed like it would behoove me hear what he had to say.

Without diminishing things, I have to say that his tips are not earth shattering. They were, however, incredibly well-packaged and well-delivered, which truly hammered home the need to focus on preparing a talk. His approach to choosing topics is incredibly practical, and he provides a strategy that a stressed, slightly panicked speaker-to-be might follow gratefully. He advocated spending 20 hours of prep time per hour of speaking time, though confessed he usually spends more like 100 hours. So that’s certainly something to think about.

According to Damian, being a good presenter boils down to 7 things:

  1. Talk about what you know and are passionate about. If you’re passionate, other people will listen, even if they don’t care about what you’re talking about
  2. Tell a story – either historical, procedural, or anecdotal. This helps to ground the talk and make sure it has good flow
  3. Don’t search for topics: select them. This was a big one for me – Damian advocates writing down everything you can think of about a topic on a piece of paper. A big ol’ brainstorm. Then when you’re ready to figure out what to talk about, you can winnow it down to the core topics
  4. Less decoration, more focus. Almost all of Damian’s slides had five or fewer words on them, in a nice large, easy-to-read font, with a plain background. No extra junk. Slides should emphasize what you’re saying, not distract your audience.

    “The use of a laser pointer will convert your primate audience to a feline audience.”

  5. Manage questions. Appear keen to take them, but make sure they happen when you want them to happen.
  6. Animate code demos. This one was pretty cool. Damian went through some elaborate Perl grammar thing and it made complete sense to me while he was explaining it. The parser tree was revealed incrementally, and then the groups in the tree moved around to map to their equivalent code blocks, and it was very cool. For normal code presentation though, simply highlighting segments as you go through is a great way to keep people from getting confused or lost in your explanation. This was the highlight for me.
  7. Harness your anxiety. I’m not a terribly nervous speaker, but I am a worrier, so this one resonated. Funnelling one’s anxiety and nervous feelings towards productive ones is, apparently, as simple as telling yourself over and over that the feeling of terror is actually a feeling of excitement. Eventually, he says, you’ll start to believe it, and your anxiety will overflow as enthusiasm and audiences will love you forever.

Damian provided the link to his talk’s handout, which you can find at damian.conway.org/IBP.pdf. I highly recommend it, and if you have the chance to see him speak, I would jump at it.