posted by Terrence Dorsey on Thursday, 31 October 2013 @ 02:22
Back in 2011, I pulled together a list of 10 Great Westerns that I'd recommend watching. In honor of Halloween 2013, here's a selection of "horror" films I think stand the test of time.
28 Days Later
Evil Dead 2
The Sixth Sense
Invasion of the Body Snatchers
No Country for Old Men
Special shout out for "Carrie" in recognition of Sissy Spacek's incredible performance, though I don't think the movie stands up all that well as a horror film.
Trivia: During my freshman year at UCLA, some friends and I attended what I believed to be the first public showing of an almost-complete "Evil Dead 2: Dead by Dawn" at the film school. Sam Raimi introduced the film, gave us some background about "The Evil Dead" and his efforts to remake it properly, and then... our minds were blown.
Maybe I'm remembering it wrong. There's nothing I can find on the interwebs referencing this event, so if anyone out there remembers this and can confirm, deny or clarify my memories, please get in touch.
posted by Terrence Dorsey on Friday, 18 October 2013 @ 00:09
If you're a music fan who's been looking for a low-key social experience sharing and discovering great music, I recommend checking out This Is My Jam. It takes a while to find and hook up with a circle of followers who share your taste for musical adventure. However, I've found the organic experience of letting the right influences come together quite satisfying.
Here are my recent jams. These were chosen over the course of many months — think of it as a slow-burn playlist. This list is dynamic, so check back in from time to time for new jams... or better yet, just follow me.
posted by Terrence Dorsey on Monday, 30 September 2013 @ 18:39
In my previous post, I provided some tips about how to get started writing. That's all well and good, but you would probably also appreciate some tips on what to write and how to organize your writing into something coherent and readable. Let's dig into that now.
Many of us were taught a five-paragraph mode of construction: tell us what you're going to tell us, tell us, the tell us what you told us. This is boring, repetitive and evil. Don't do it.
Instead, consider this structure for your writing:
It's similar to the old five-paragraph model — there's an introduction, a body and a conclusion — but I think this structure better directs the organization of your writing and makes for more interesting reading.
The problem statement
The problem statement is the introduction. It serves two purposes. First, it explains briefly what your article is about. Second, it's your opportunity to grab the reader's attention.
Starting with the second point, many readers think being outrageous or funny makes for a good hook. While that can work, it throws an unnecessary variable into the equation. Are you really funny? Is that enough to hook a reader? Are you sure?
Maybe it's better to just clearly state what you're writing about. Provide some context: what does it relate to (language, platform, type of development...), and why should I care (am I doing it wrong, does this make my code faster, stronger, less buggy...)? This is why I called it a "problem statement."
Readers are often more interested when you clearly define your subject within a the scope of a problem they might encounter and one or more solutions that solve the problem. One approach, of course, is to literally solve a problem, but taking a more abstract view of the problem-solution structure can help guide your writing on other topics as well.
Keep your introduction brief, but it can be several paragraphs if necessary to set up the context in sufficient detail. However, make sure at least one paragraph — preferably the first of last paragraph of your introduction — clearly states what your entire post is about. People who will share your article in social media, aggregators and newsletters will cut and paste. Make it easy for them.
View controllers are often the biggest files in iOS projects, and they often contain way more code than necessary. Almost always, view controllers are the least reusable part of the code. We will look at techniques to slim down your view controllers, make code reusable, and move code to more appropriate places.
Notice that, in three sentences, Chris explains the context (view controllers in iOS programming), the problem (they're too big and not reusable) and what he's going to explain (a solution for slimmer, more reusable view controllers).
High school geometry comes in two distinct flavors: Euclidean geometry is oriented around constructions, theorems and proofs, while analytic geometry describes geometric figures numerically using points on a coordinate system, often called the Cartesian coordinate system in honor of the pioneer of analytic geometry, René Descartes...
In the previous installment of this column... I discussed how to use the ID2D1PathGeometry to render lines in a finger-painting application that runs under Windows 8. Now I’d like to step back and explore geometries in broader detail, and in particular investigate some of the intriguing methods defined by ID2D1Geometry for manipulating geometries to make different geometries.
This is a longer introduction, and I've even left out a paragraph for clarity, but you can see that it includes the same building blocks: a context (geometry in Windows 8 programming, continuing from a previous articles), a problem (geometry is hard, you need to know how it works) and a solution (learn about ID2D1Geometry).
If you can keep your introduction — your problem statement — focused like this, it will help you keep the rest of your article focused as well.
This is the meat of your article and where you'll spend the most time writing. I won't spend too much time on this as it's really the focus of my first post on getting started writing. You just need to pick a subject and start writing.
The main portion of the article is where you can explain the problem or opportunity in more depth than a concise intro problem statement allows. Stop and provide some more context if necessary, though don't let it distract from getting to the solution. If the problem starts to become the entire article, you might want to rethink what the article is about. Maybe that's another writing project altogether, or maybe you can link to more context elsewhere.
How you write about your "solution" depends on subject and the way you want to organize your ideas. A few common patterns are:
Start from the beginning and work through to solving the problem
Pick a few key elements to explain
Top ten lists (pro tip: odd numbers work better)
Analysis of different patterns or implementation approaches
Pros and cons
There's not necessarily a right or wrong way to organize the core of your writing. Go with your gut, pick something and run with it. After you complete a draft, if the organizing theme you've selected doesn't seem to be working, don't try to force it. Rather, be open to refactoring and heading in a different direction. Reorganizing takes less effort than re-writing.
I'm of the opinion that a blog post or article does not, in fact, require a formal conclusion. If you finish your subject and want to simply stop, that's fine.
This is particularly true of very short blog posts that cover a single, very focused subject. Provide some context and a problem statement, explain yourself through your solution, and done!
If you do want to provide some closure, don't simply restate your original thesis. Instead, you can just sum up quickly: "That's a quick overview of recursive dohickies in action."
Another approach, if there are other considerations, is to qualify your solution. Although I've warned against pedantic, edge-case addicted readers, you don't need to be all-inclusive or all-encompassing in your solution. Just explain that there's more to the subject: "This solution works well for most apps, but edge cases X, Y and Z require additional hemming and hawing." Maybe that's fodder for future writing.
As implied by my heading, it's always helpful to suggest some next steps for the reader: Where to learn more or find additional examples. Other potential solutions or associated technologies. Ideas for further or more sophisticated implementations. You don't need to go on at length. A simple mention and, perhaps, a link, goes a long way.
Use links to your advantage
Links are the lifeblood of the web, and links in your article are good. They let you pull related context and information into your post without having to write it. They also let you recommend quality sources of information and code to your readers, situating your own writing within the larger web of discussion on the subject.
You can (and should) link to your own previous posts. Go back and add links in previous posts if you cover the subject again later. This is particularly important for multi-part series of articles so a reader can find the beginning of the series from any post in the series, then follow through from the end of one post to the beginning of the next. If you make it easy for readers to stay on your site, they will.
Link to other people's posts if they're relevant and helpful. People (readers and writers) appreciate that, and if they've already covered a subject, it saves you from repeating it.
Link to apps, libraries, reference material and anything else that you use or discuss in depth so readers can find and use it too. Make sure you get the name right, though, and it's a nice touch if you check occasionally that links still work.
Comments on the code examples
Code is great. You should definitely include code examples if they're relevant to in your writing. But a code example does not replace an explanation.
If you show code, you should explain the code, even if it seems obvious to you. You wrote it. Of course it's obvious. However, your reader is trying to learn. If it was obvious, they wouldn't be reading... and many of your readers are going to be far less accomplished programmers than you. Help them understand.
In fact, this is where a lot of official documentation falls down. It shows the most basic example, but never take it farther than that. Then it jumps straight to a complete sample app. There's often little explanation of how you get from A to Z.
And as we know, the API is rarely as straightforward to use as the author thinks. There are always inconsistencies and gotchas and misnamed features and things that look the same but do something completely different.
You don't need to show all of your code if it's available somewhere else. Just the important or interesting bits, and a link to peruse the rest.
If there are dependencies, make them clear.
Test your code in a fresh environment (VM maybe) to double-check that there are no unexpected dependencies. "It works on my machine... " is never a good excuse.
The specific coding style choices you make are not as important as consistency and clarity. Pick something and keep with it. It can help to use super-clear naming that you might not use in real code.
More on writing about code
This is part of a series of posts discussing the main points of my "Writing About Code" presentation at Vermont Code Camp 2013. Here are all of the posts in the series:
posted by Terrence Dorsey on Friday, 27 September 2013 @ 04:18
Writing code is job one for most software developers, but learning to write about code is almost as important. Whether you're documenting an API or showing off your own smarts, when you set out to write about what you think you know, it tests how well you really know the subject. As you write, you'll often end up deepening your understanding of how the code works and honing your skills as a developer.
In this post I'm going to provide some tips and tricks for programmers who haven't done much writing that will help you get started and find early success that fuels more writing.
This is a distillation of the first part of my "Writing About Code" presentation at Vermont Code Camp 2013. I don't believe dumping my slides on the web helps. Instead, I'm pulling the most important ideas from my presentation into a few blog posts that are easier to read, digest and use to fuel your own work.
Why write about code?
There are many reasons to write about code. Maybe you want to share your knowledge and enthusiasm for programming, to market a product or teach customers how to use it, to promote your own abilities or because it is (or should be) part your job.
But I'd like to suggest another, more valuable reason, best summed up in this ancient wisdom from Seneca the Younger: Docendo discimus ("by teaching, we learn").
Whether you write for yourself or decide to write publicly, you’ll start to explain something and, often as not, start wondering: Really? Is that all there is to it? What am I missing? How does this work? Engineers — your target audience — are always going to point out edge cases and pedantic details. Are you ready?
Go ahead and second guess your assumptions about your code, dig into the how and the why. You will most likely learn something new and improve your skill as a developer.
My code speaks for itself, right?
Unfortunately, your code does not speak effectively for itself — not for a wide audience anyway.
A code example does not replace an explanation. Sure, there are times when sharing a simple code snippet seems sufficient, but even then it's usually posted in the context of a discussion... usually via social media.
If you show code you should explain the code, even if it seems obvious to you. You wrote it, so of course it's obvious. But there are many other people — your potential readers — who are trying to learn. If the concepts you present in your code were obvious, these people wouldn't need to be reading about it.
Many of your readers are going to be far less accomplished programmers. Believe it or not, by simply taking the time to research and write a blog post, you become an expert. Help them understand.
In fact, this is where a lot of official documentation falls down. It shows the most basic example, but frequently fails to take it farther than that. Then it expects you to jump straight to a complete sample app. There's often little explanation of how you get from A to Z.
You may think it's all be written before. What do you have to contribute? We're still figuring this programming thing out. Every bit of knowledge helps move the profession forward. People are still writing about C. People are still writing about Cobol! Your unique approach to the subject may be the key that unlocks a problem for some reader.
Fear of writing... or how I learned to stop worrying and just write
The most important tip: Write something. Anything. Just get it out of your head and on the screen. Make time to write every day. 100 words or 30 minutes or whatever seems achievable on a regular schedule. As you become more comfortable, try increasing your target time or word count.
Do make it a habit, but don't make it a chore. If you get stuck, stop and come back to it later.
Use the tools and languages you use every day. Write about the thing on your mind right now. A distraction that often gets in the way of writing (and probably coding, too) is obsessing over the "best" tools. There is not best writing tool, and messing with different editors just keeps you from writing. Word is fine, but so is a basic text editor... your IDE will probably work fine if that's where you're most comfortable and productive.
Don’t underestimate the usefulness of pencil and paper.
A helpful approach for avoiding editorial paralysis is to commit yourself to at least two trips through the material. I think most people get in trouble by trying to edit while they write. The result is usually not writing. An outline or a list of the major points you want to touch on works well, but from that starting point, try to write stream-of-consciousness. Get as much down on paper as possible.
Don't fixate on the entire article. Work idea by idea, section by section. Each sentence is a building block for a paragraph, and each paragraph is a building block for your article.
Although correct technical details are important, as are correct spelling and capitalization, don't get hung up on researching each topic as you write. If there's something I'm not sure about or that needs more detail, I prefer to make a note to myself inline to go back and double-check or add more information later. Better to have the sketched out skeleton of your writing in place rather than getting side-tracked by research from writing at all.
Write a complete first draft before making any edits or revisions. That includes fretting about spelling, grammar, and so on. Once that draft is complete, then read it through, fix mistakes, add details, re-order, refine, and refactor as needed.
Focusing your big ideas into byte-sized pieces
A common problem for writers is determining the scope of what you're going to write about. If the idea is too big, you're likely to run into two problems: You either never finish (which is frustrating) or you skip over important details to finish (which leads to a poor finished product).
At least when you're starting out, focusing your writing on small, achievable goals will help you succeed more often, giving you confidence in your writing and setting up a positive feedback loop of writing, accomplishment and more writing.
It's often better to focus in on a very specific detail and write about that as clearly as possible. You have a more clear goal for the writing in front of you. You can often think around the smaller concepts more easily. Plus, there's less to write — you'll finish more quickly.
You can stitch together other small, focused bits of writing into episodic blog posts (Oren Eini does this very effectively on his blog) or into a longer article.
You’ll often find that small topics aren’t really so small when you dig into them. Think about not just how you implement a solution, but how it works... and why. What are the edge cases? What’s helpful to know? How much is boilerplate, implemented for you by the IDE or framework? Can you explain how that all works? How much is "received wisdom" about how things should be done, or code IntelliSensed in with a keystroke?
In fact, I suggest, as an exercise to practice writing about your code: take a chunk of code and explain it block by block. I bet you'll discover quite a few assumptions you've made along the way. It doesn't have to be your code. Document some random source code just for the practice.
Avoid pasting in large code blocks. It hinders the flow of reading and distracts your reader while she deciphers the entire block. Instead, break your code into digestible snippets if at all possible. Explain each bit as you go through.
At the end you can provide the entire code block for copying and pasting, or link to a file/repo.
I suggested digging into the details, but you don't always have to explain how deep the rabbit-hole goes. Most of the time, unless you're writing basic programming tutorials, you shouldn't have to explain how a for loop works, or what you're iterating or basics like that.
Instead, think about the conceptual building blocks of your idea. Break code down into snippets that let you discuss it in terms of those building blocks. For nuts and bolts coding, that may mean discussing code line by line within individual methods. Other times you might discuss the overall construction of an entire class (suitably simplified, if possible) or of classes within an application.
As an example, take a look at Chris Eidhof's Lighter View Controllers article at objc.io, which examines code organization at the class and file level. Then consider Peteris Krumins' Bash One-Liners Explained series of posts, which by definition examines one line of code at a time in great detail.
What to write about?
Still not sure where to start? Here are a few ideas:
Write about what you’re enthusiastic about
Write about what you’re curious about
Write about what you’ve done that makes you feel smart
Write about a problem you had to solve
Write about what annoys you or makes you smile
Write about what you don’t understand: you’ll learn along the way
There is a audience out there eager to learn. Start writing for them. It will do you some good, too.
People love to learn how things work... and why.
People love when someone else solves their problems.
People want to know what they need to know and where to find it. They want to know how to get started, and then they need to be handheld from the simple to the more complex.
People always appreciate clever and useful utilities and code snippets, and tips for how to use them.
Stop reading, start writing
You have some basic tools for getting started. Now put them to work and get started writing something every day. You don't have to publish it. Just keep a journal for practice... a journal of ideas, which you might return to later for material as you become more confident in your writing.
This is part of a series of posts discussing the main points of my "Writing About Code" presentation at Vermont Code Camp 2013. Here are all of the posts in the series:
posted by Terrence Dorsey on Thursday, 29 August 2013 @ 20:19
A warm cup of coffee seems a universal morning ritual. Bad coffee seems pretty universal as well. But it's not difficult to make a good cup of coffee. It just takes the right ingredients, a repeatable technique and a little trial and error.
Here are some tips for making a better cup of coffee.
Many people focus on brewing method - tools over technique - but no matter which method you have at hand, materials and preparation are most important.
To make a great cup of coffee you'll need:
Freshly roasted beans.
An adjustable burr grinder.
I can't overemphasis how important freshly roasted beans are to quality coffee. Some people say the first week or so after roasting are the best. More than a month is too old. If you buy directly from the roaster, they should be able to tell you when it was roasted. Many roast to order. If there's no roast date on the bag, assume the worst.
Grinders are available in many sizes and prices, from $50 hand grinders to giant commercial electric grinders costing hundreds of dollars. The most important feature is the ability to adjust grind in small increments. I use a Kyocera CM-45 hand grinder and a Lelit PL-53 stepless burr grinder. The Kyocera is getting hard to find, but I've heard good things about Porlex hand grinders. In electric burr grinders, the Baratza lineup has something at a variety of price points and they have a good reputation as well.
On to preparation...
I prefer espresso, but for simplicity we'll walk through brewing a simple single-serving of drip-brew coffee. This uses a "pour-over" filter holder like those made by Melitta, for example (here are some other options from Sweet Maria's), and paper filters.
First, put approximately 4 tablespoons of the beans in your grinder. The actual amount isn't as important as being consistent in how much you use. Grind the beans.
Put a filter in your filter holder and heat up the water to not-quite-boiling. Put the grounds in your filter and pour in two cups of water. Again, precision is not important, but you don't want to overfill your coffee cup and you do want to keep the beans-to-water ratio consistent from cup to cup. Let the water brew through the grounds.
Here's the important part to making a great cup: Taste the coffee. Prep it with milk and sugar if you like, but taste it.
Does it taste good? Fine, you're done. Do the same exact process next time.
Does it taste watery and thin? Tighten the grind setting on your grinder slightly to make finer grounds. Do everything else the same.
Does it taste bitter, or did the water fail to brew through the coffee after a minute or so? Loosen the grind setting slightly to make more coarse grounds. Do everything else the same.
Brew another cup. Better? You can keep making small changes to your grind settings toward a more coarse or find grind until you get a great cup.
The trick here is controlling for all but one variable: grind. If you change beans, you may have to fine-tune your grind again.
Other brewing methods offer additional variable to tweak, from Aeropress or French Press steeping time to espresso machine pressure and temperature settings. You can imagine, however, that it's easy to get out in the weeds with too many settings. No matter which method I use, I always go back to the basics: fresh beans, hot water, and adjusting the grind until the cup is tasty.
These days I get my beans from Barrington Coffee Roasters and Lucy Jo's, who sell directly at my local farmer's market. I also recommend Counter Culture Coffee who not only sell great beans, but are also leading the charge for direct, sustainable relationships with coffee growers around the world. In NYC you should give Cafe Grumpy a try. Wherever you are, find and support your local roasters.
posted by Terrence Dorsey on Wednesday, 05 June 2013 @ 03:53
Earlier today I had a brief Twitter conversation with John Resig about storing art, specifically prints. I thought I'd share a few additional thoughts that didn't quite fit into the space of 140 characters.
Disclaimer: I'm no conservation expert and my art isn't particularly valuable. If in doubt, consult a pro.
The best method, I think, is to have your prints archivally framed and hanging on the wall. You can enjoy them and they're relatively safe from damage. Unfortunately, framing is expensive and we only have so much wall space.
Although it's common practice to ship prints in tubes, you should store them flat if at all possible. It's almost always possible to flatten out a print, but in my experience the paper tends to develop a memory. The longer it's rolled, the harder it is to flatten out without developing waves or ripples.
The obvious storage solution is a flat file cabinet. They make it very easy to simply lay the prints in the cabinet and be done with it. However, flat files are big, bulky furniture. The biggest commonly available size is 36" x 48", which is a lot of real estate in your room. And remember, that's the outside dimension — the largest print you can accommodate will be more than an inch smaller.
Flat files are also fairly expensive, though careful shopping on Craigslist or the like may turn up something useful.
All that said, if you can swing a flat file, it's the way to go for safe, bulk print storage. I love mine.
Within the cabinet, some folks like to store prints in mylar sleeves. I tried this route and found the hassle and cost outweighed the utility: the sleeves don't always lie entirely flat and I couldn't stack prints without inducing some waviness in prints on lighter-weight paper.
I ended up taking the prints out of the sleeves and instead simply place prints on top of each other, alternating with sheets of acid-free blank paper.
For prints up to 24" x 36", art portfolios with slip-in sleeves work great for storage. The stiff covers provide good protection for your prints, but make it easy to page through and admire your collection. They also can slip under a bed or, if you're careful, lean against the back of a closet. Watch out for pests and spills, though.
I like the Itoya 18" x 24" Profolio and Profolio Evolution. This is a common size for gigposters, so the vast majority of my collection fits in these easily.
There are bigger portfolio cases. I have a 24" x 36" Stein deSign Picturesque Presentation Case. Pricey, and only comes with 5 sleeves, though you can expand up to 20 sleeves with "refills". On the other hand, it's a very sturdy alternative to a flat file for storing larger prints.
You may also be able to find fold-over artist portfolios in even bigger sizes. They don't typically have sleeves to help organize your prints or hold them in place, so you need to be careful about handling. Look for acid-free materials.
I have a few really long prints that don't fit in any of the commercially available, affordable solutions. So I made my own folders — basically a variation on the fold-over portfolio.
Put two boards on top of each other and tape one edge together, creating a hinge.
Carefully place the prints between the two boards. For added peace of mind, you might want to temporarily mount the prints on heavy acid-free backing paper using framer photo corners or clear mounting strips.
Hold the entire thing closed with big-ass rubber bands or similar. Handle the whole thing carefully — contents are likely to shift.
Get Your Own Art
Hand-made prints — screen prints, woodblock prints and lithographs, usually — are a great introduction to the world of art collecting. There's something everyone. I really like Andy Warhol's Cow Wallpaper, but that's not going on my wall any time soon.
Instead, I accidentally fell into the rock art gig poster scene. You can learn more about it at gigposters.com and Expresso Beans, two of the more active communities for artists and collectors.
posted by Terrence Dorsey on Saturday, 25 May 2013 @ 19:40
30 years ago today, two friends and I ditched school to see the very first screening of Return of the Jedi on its opening day on the biggest movie screen in the county. It turned out to be a significant day in ways I didn't suspect at the time.
I was a freshman in high school. My friends and I had been, of course, huge fans of the Star Wars franchise since the original movie, 7 years before. In many ways it had become the core of a SciFi and Fantasy obsession dating back even further, fueled by books, magazines like Analog, Starlog and Heavy Metal and the old movies featured by Bob Wilkins on his Saturday evening Creature Features show.
Significant anticipation had built up over the resolution of various plot lines left hanging in The Empire Strikes Back. Is Darth Vader really Luke's father? Will they rescue Han from Jabba the Hut? And who's this Boba Fett character?
We couldn't wait to find out, and dared not run the risk of someone spoiling the surprise. And besides, we were old enough now to see the movies alone. No need to wait for our parents this time.
In those days I didn't yet have that coveted driver's license, but we did have the wonderful freedom of our bikes. I frequently rode the 4 miles between home to school. So on that Wednesday afternoon 30 years ago, my friends and I ducked out at lunch, grabbed our bikes and pedaled over to the big "dome" theater in Pleasant Hill to catch the very first showing of Jedi in our town.
It seemed like such a caper at the time. I'd never really been one for breaking the rules, and recall looking over my shoulder several times, half expecting an army of Assistant Principals and Truant Officers to be chasing after us like in The Great Escape.
In reality, I don't think anyone noticed we'd gone. I certainly don't recall any disciplinary fallout from that afternoon.
We arrived at the theater and found a small group of people waiting. Not a huge crowd, but we weren't the only ones hoping for another grand installment in the story of Luke, Leia and the rebellion. We bought tickets, soda and popcorn, debated the best place to sit — we had most of the huge theater to choose from — and settled in for the coming attractions to roll.
The movie itself was great and fulfilled many of our hopes, until... the Ewoks. I remember thinking "Teddy bears? WTF?"
The rest of the movie wasn't a total disappointment. I mean, the showdown between Luke, Vader and the Emperor was pretty badass. But that's followed up by the uncomfortable makeup scene between Luke and Fat Vader, the Ewok hoedown, C3PO telling stories (badly I might add) and the bemused Jedi ghosts. (Let's not even get started on the whole Hayden Christensen thing... that was a disappointment yet to come.)
At the time I probably felt somewhat betrayed by the trite ending and the indignity of a fat bushbaby tribe saving the rebellion. But I soon came to realize something else: George Lucas wanted to keep Star Wars accessible to children. And I was growing up. In some sense I'd moved on and realized these movies weren't necessarily for me anymore. They were maybe for George Lucas or a new generation of kids or, anyway, people who were less snooty and cynical than this teen-aged cineaste was becoming.
(Ironically, I unintentionally ended up seeing The Phantom Menace on opening day 16 years later, but that's a story for another day.)
The Star Wars saga no longer holds the position in my life it once did, but it still maintains a place of respect in my pantheon of great stories. I've seen all the films so far, if only out of curiosity, and look forward to JJ Abrams' interpretation of Episode 7, lens flare and all.
I read and highly recommend Michael Heilemann'sKitbashed blog, dissecting the creative work of George Lucas and the influences remixed into the Star Wars universe. It's a very grown-up look at myth, film-making, creativity and what it means within our cultural heritage. From Kitbashed I learned of this excellent Michael Kaminski article In Tribute to Marcia Lucas from The Secret History of Star Wars, which outlines her significant contributions to George's work through Empire (and perhaps why Jedi missed the mark).
As if to underscore the fact that Star Wars remains part of my childhood, that theater where we first watched Jedi shut down in late April and was demolished two weeks ago. Like many other landmarks of my youth, it's gone forever. But I have fond memories.
posted by Terrence Dorsey on Tuesday, 12 February 2013 @ 01:48
Update 2/22: Revised to address bug fixes in TextDrop. See my notes below.
In 2011, I wrote a post about Crossplatform Note Sync with Dropbox. For the most part, the workflow and apps I wrote about still work well. However, times change I thought it would be a good idea to go back and check on some new developments, both platforms and tools, that may give you some new note-syncing options.
In a few cases, new features make this workflow even more flexible. For example, Elements now allows you to select which folder it uses for syncing files.
One new development the deserves a look is TextDrop, an online text editor for Dropbox.
TextDrop is a web app that lets you access your Dropbox folder and edit, in the browser, any text-based document there.
I learned about TextDrop from Gabe Weatherhead of Macdrifter, who's written some great introductory posts about it, most notably here and here (plus an interview with TextDrop developer Sam Nguyen that's worth a read).
There's not much to the app: one pane shows the contents of the current Dropbox folder, the other lets you view and edit the selected file. It provides minimalist text-editing features, plus MultiMarkdown preview.
There are options for enabling hard tabs, non-text file previews and full-text search. That's pretty much it.
The good news is that TextDrop works fine in some popular desktop browsers, specifically Chrome, Firefox and Safari. TextDrop also works in Mobile Safari on the iPhone and iPad, though the site is a bit too cramped for regular use on the smaller phone screen.
The not-so-good news is browser compatibility. IE 6 and 7 are not supported by design, and I couldn't get the site to load in IE 9. Google Chrome Frame might help. Windows 8 is not supported. No joy in Opera, either. The site does load on Mobile Safari, but it's marginally useful at such small screen sizes.
TextDrop is priced on a sliding scale, the actual subscription price rising a small amount with each new user. This is similar to the pricing scale used by Pinboard.in. You lock in a yearly subscription fee based on current price when you sign up.
I purchased a subscription (at around $10) because TextDrop does add some helpful flexibility to my writing work and I want to support Sam's continuing development of the app. The price recently jumped to almost $30.
Is TextDrop valuable at the current price?
If you work mostly within the toolset currently supported — namely, Chrome, Firefox and Safari — TextDrop can be quite useful. Once authorized, your documents are just a browser bookmark away, wherever you may be working.
Although TextDrop has some missing spots in its compatibility checklist, it does cover the most popular platforms. Expanding compatibility to Windows 8 and Windows Phone 8 could win TextDrop some vocal supporters. On the other hand, improving mobile compatibility and expanding the editing capabilities probably addresses the needs of a larger user base. I'll be watching with interest.
Update: It's worth noting that Sam is making regular updates to the service and making changes in response to user feedback. Not only did he fix the IE9 loading issue within a week of my pointing it out, but he also fixed a minor tab-spacing bug as well, among other things. This is the kind of service where your subscription dollars are really going to support the work of an independent developer, who in turn is working hard to address the needs of his paying customers. I like it.
posted by Terrence Dorsey on Friday, 04 January 2013 @ 02:50
Updated below on 1/3 and 1/16
Online services are going to steal all of our content and use it to enrich themselves. Or maybe they're not. It makes for great paranoid headlines whenever a popular site updates their terms of services, but what's really happening here?
IANAL and have no particular expertise in the areas of IP law, so you'd be wise to rely on your own judgement and the advice of an attorney rather than my insight. However, I think there's a lot we can learn from a close reading of actual terms of service and a little common sense.
I was inspired to write about this by a tweet from Hal Berenson, linking to a post by Bruce Schneier, suggesting that, if you "Store something in the cloud... the cloud service owns it."
Schneier mentions the recent dust-up about Instagram's terms of service, and if you've been paying attention, you also know that Twitter, Facebook and other services have faced similar controversy over their TOS language.
The general uproar is something along the lines of:
"OMG ALL YOUR CONTENT ARE BELONG TO [service du jour] AND THEY CAN DO ANYTHING THEY WANT WITH IT!"
What's this all about? Why is [service du jour] suddenly stealing everyone's photos, wry observations, presentations or whatever? And what are they going to do with all this booty?
All Rights Reserved
The problem rests in some fundamental misunderstandings about how we use copyrighted works.
When you create something — write a tweet or a blog post, take a photo, sing a song and so on — the copyright for it is granted automatically (and in most cases, to you... though there are exceptions). If someone else wants to use it, they need your permission: you can grant a license for them to use that writing or photo or song under certain conditions.
And that's exactly what's happening here. You take a photo. You have a copyright on that photo. You upload it to Instagram. For them to do anything with that photo, you need to give Instagram permission — a license — to reproduce your copyrighted content and save a copy on their server.
Say you want Instagram to let your friends see the photo. You're smart and know how computers work; think about the further consequences: Instagram has to make and distribute copies of your photo for each person who wants to see it. Maybe they distribute files around to servers for load balancing or CDN-style distribution. More copies. Hopefully they back up your data. More copies.
They need your explicit permission to copy and distribute your copyrighted work.
Of course, lawyers being lawyers, and corporations being corporations, they use very-broad-and-yet-very-specific language to cover their asses in all the ways they can possibly think of, plus a few ways both you and they haven't imagined yet.
So you end up with terms of service language that sounds like OMG ALL MY FILES BELONG TO...
Take a deep breath. Maybe it's not that bad after all.
In a previous life, part of my job involved proofreading EULA text for software installers. Yes, it was dull. But, the benefits! If you'd ever read through all of a EULA, a rental or mortgage contract or any similar legal document, you'd know that most of the language looks remarkably similar from one contract to another... it's boilerplate. Why reinvent the wheel? If it works in one situation (and holds up in court), use it again and again and....
In order to provide you with the Service, it is necessary for you to grant Prezi certain licenses to your User Content.
With respect to Public User Content, you hereby do and shall grant to Prezi (and its successors, assigns, and third party service providers) a worldwide, non-exclusive, perpetual, irrevocable, royalty-free, fully paid, sublicensable, and transferable license to use, reproduce, modify, create derivative works from, distribute, publicly display, publicly perform, and otherwise exploit the content...
(My emphasis here and throughout, by the way, unless otherwise stated.)
That sounds pretty sinister. Promising to "exploit" is rarely a great way to make friends. In addition, Prezi requires you to grant a similar license to anyone who views your public content:
When you upload User Content on or through the Service, you also hereby do and shall grant to each user of the Service with whom you share your presentation a personal non-commercial non-exclusive license to access and view your User Content.
Yikes! What are they doing with my presentation?
But hang on. Think back to what I metioned earlier. They need your explicit permission to make any copies of your content that live on their servers or move around their service, any copies displayed to other users of the service and any copies needed for features of their service they haven't implemented or even thought up yet. That is what your "worldwide, non-exclusive, perpetual, irrevocable, royalty-free, fully paid, sublicensable, and transferable license" enables Prezi to do without fear of being sued for copyright infringement.
It's a fair point to the extent that Microsoft Services Agreement section 3.1 does explicitly state "[W]e do not claim ownership of the content you provide on the services. Your content remains your content...."
I believe that to be entirely true and put in fairly straightforward terms. Further, they make the entirely valid point that other people may see, save and reproduce copies:
If you share content in public areas of the services or in shared areas available to others you’ve chosen, you agree that anyone you have shared content with may, for free, use, save, reproduce, distribute, display, and transmit that content in connection with their use of the services and other Microsoft, or its licensees’, products and services. If you don't want others to have that ability, don't use the services to share your content.
However, if we read a bit further, we'll see something a bit more like that Prezi license language start to show up:
When you upload your content to the services, you agree that it may be used, modified, adapted, saved, reproduced, distributed, and displayed to the extent necessary to protect you and to provide, protect and improve Microsoft products and services.
...you are granting Microsoft, its affiliated companies and necessary sublicensees permission to use your Submission... including, without limitation, the license rights to: copy, distribute, transmit, publicly display, publicly perform, reproduce, edit, translate and reformat your Submission... and the right to sublicense such rights to any supplier of the Services.
For better or worse, you're going to see language like this being used by pretty much any significant player in online or cloud services.
You retain your rights to any Content you submit, post or display on or through the Services. By submitting, posting or displaying Content on or through the Services, you grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to use, copy, reproduce, process, adapt, modify, publish, transmit, display and distribute such Content in any and all media or distribution methods (now known or later developed).
As the tip on the page notes, "This license is you authorizing us to make your Tweets available to the rest of the world and to let others do the same."
You own all of the content and information you post on Facebook, and you can control how it is shared through your privacy and application settings. In addition... you grant us a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook (IP License).
Some of our Services allow you to submit content. You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.
When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works...communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones.
Apple does not claim ownership of the materials and/or Content you submit or make available on the Service. However, by submitting or posting such Content on areas of the Service... you grant Apple a worldwide, royalty-free, non-exclusive license to use, distribute, reproduce, modify, adapt, publish, translate, publicly perform and publicly display such Content on the Service...
Birds do it, bees do it. Everybody on the web seems to do it. Let's do it. Let's accept that these license terms are basically industry boilerplate and move on.
Fox In The Hen House
Just to be clear, I'm not trying to belittle the comments made by Hal or Bruce... or anyone else who has concerns about this widely used, easily misunderstood — and perhaps easily abused? — licensing language.
I believe it is essentially boilerplate and meant to cover legitimate business use of our photos, videos, jokes and memories. Thus far, I can't think of any businesses that have, in fact, appropriated user content for reasons not intended by the user. And given the backlash resulting just from the suggestion that it might happen, I can't see why any sanely run business would try to do so.
But the ideas that are unacceptable today may become more acceptable tomorrow. Perhaps a future startup tries explicitly employing user content as part of its service, creating a wedge that makes the practice tempting where it was previously taboo. Of course, people tend to do stupid things, so maybe it's just a matter of time for someone to exploit this broad licensing language, consequences be damned.
In the meantime, the bold headlines seem more click-bait than Cassandra.
Update: Well, well, well... Ryan Singel points out that BuzzFeed is already raising significant investment funding on a "biz model of willful copyright infringement." Sure, they're taking liberties with photos folks have posted to other services — you haven't licensed them anything — but is this the "wedge that makes the practice tempting where it was previously taboo," or an outlaw site, doomed to failure?
My point stands, however: these terms of service aren't the problem (yet). Bad actors are.
Update 2: Today Reuters reports that News outlets improperly used photos posted to Twitter. According to the story, a reporte at Agence France-Presse took photos that photographer Daniel Morel had posted on Twitter, used them in an AFP story without permission, then passed them on to Getty Images, from whom the Washington Post procured the images.
AFP had argued that Twitter's terms of service granted it the right to use Morel's images.
The judge, though, said that while the service terms do allow the reposting and rebroadcasting of users' images in certain circumstances, such as "retweeting" them, it does not grant a license for commercial use....
Twitter was not a party in the case. "As has always been our policy, Twitter users own their photos," a Twitter spokesman said.
As before, I think this is a case of misappropriation — and a journalist at an organization of this stature should really know better.CodeProject