Hello! Thanks for coming by, but there's nothing new here to see. I blog at Scribbling.net now.
Just uploaded an extensive update to Todo.txt for Android to the Google Play Store! Todo.txt for Android now archives completed tasks, supports swipe-to-complete, has smarter Dropbox sync, and looks great on the Nexus 7.
Now that the app can archive tasks to done.txt, it's officially feature-complete, version 1.0. You can use it completely independent of the command line interface or any other desktop app or text editor.
Get it in the Google Play Store now:
Here's what's new and different in this version. Todo.txt for Android now:
- Archives to done.txt: When you mark tasks on your todo.txt as complete, the app can automatically or manually archive them to a separate done.txt file. In settings, either tap "Archive Now" to do it manually (this is my favorite method, because seeing crossed-off items in my todo list for a little while makes me feel accomplished), or check off "Archive automatically" to make the app clear away tasks as soon as you mark them complete.
- Supports swipe to complete: To quickly mark a task complete on your list, swipe your finger from left to right across it. To undo tasks that have already been completed, swipe across them from right to left.
- Reduces file conflicts: The app now references Dropbox file revision tags and does more frequent background syncs to reduce file conflicts and avoid overwriting changes on Dropbox or on your device.
- Automatically gets back online when your device does: We've completely rejiggered the app's off-then-back online behavior so it never gets stuck in offline mode again. When your device goes offline, Todo.txt for Android keeps working offline, and when you come back online, it automatically syncs your work back to Dropbox, no need to manually turn Work Offline off. For users who want to preserve bandwidth, there is a "Manual Sync" checkbox in Settings you can toggle on and off at will.
- Looks great on the Nexus 7: The app now includes an extra high density icon for high-res devices like the Nexus 7 and Galaxy Nexus.
- Fixes project parser bug: Fixes bug where words with + in them (like URLs) used to get parsed as projects.
- Gets French translation: A new French translation is now available, as well as fixes to the existing German translation.
- Has fewer settings: By combining and reducing settings, the app now has 3 fewer checkboxes for users to fiddle with, and all the more reason to just get back to work.
I'm deeply grateful to the tireless contributors who make Todo.txt go, especially the people who created this release: Chuck and Florian for adding smarter syncing and done.txt support, John for creating higher density artwork, Alex for the French translation, and to all the typo-fixers and question-askers and release candidate-testers.
The NY Times' Tim Kreider's defense of idleness:
Idleness is not just a vacation, an indulgence or a vice; it is as indispensable to the brain as vitamin D is to the body, and deprived of it we suffer a mental affliction as disfiguring as rickets. The space and quiet that idleness provides is a necessary condition for standing back from life and seeing it whole, for making unexpected connections and waiting for the wild summer lightning strikes of inspiration — it is, paradoxically, necessary to getting any work done.
Reminded me of my all-time favorite essay on idleness, Quitting the Paint Factory.
At ThinkUp, we've produced a lot of developer documentation on how to write great PHP code, the kind of code that's worthy of acceptance into the project. But if I were to suggest a general list of PHP best practices, I could not have done a better job than Josh Lockhart's PHP (The Right Way). It's a strong collection of generic guidelines and resources, and I'm pleased to see that it describes a lot of what we do at ThinkUp.
PHP is deeply flawed, but it remains the leading "gateway" language for new web developers. Coding Horror's Jeff Atwood wants this to change. He argues that veteran developers should start actively working to end the PHP singularity. The first step, he says, is to stop using it in new projects—something even seasoned developers like Marco Arment have difficulty doing.
I applaud Atwood for kicking off an ambitious cultural shift in the web development world. Good programmers should use great tools, ideally, from the beginning. But, this is a battle I didn't choose to fight quite this way.
PHP is not the best tool to use, but I chose it for ThinkUp for two reasons. First, when you're building a webapp that users run on their servers, PHP is the only reasonable choice, because LAMP is the most widely available web server stack out there. Second, one of ThinkUp's community goals is to bring new coders into open source. PHP is the language of new web developers, so using it in ThinkUp attracts that talent pool.
Staunch anti-PHPers could say that's just perpetuating the problem of encouraging new programmers to start with bad tools. I see it as an evolutionary, rather than revolutionary, approach. Even in PHP, it is possible to teach new coders best practices like object-oriented programming, test-driven development, design patterns, documentation-driven development, and the importance of consistent code style. If amateur web developers want to level up to pro, a good place to start is in a language they already know.
Cross-posted to the ThinkUp blog.
On our third episode of In Beta, Kevin and I discussed webapps that require you to enter your username and password to accounts that can move your money around or purchase items—namely, Mint.com and App Annie. My concern, with App Annie in particular, was that while the app promises to only use your account to read app sales data, in theory it could use your username and password to go on a shopping spree in the iTunes and/or Play Store.
Listener Steve wrote in to suggest creating secondary developer accounts to use with App Annie that don't have purchasing power. Duh! If you log into iTunes Connect, click on "Manage Users" to invite a new user and grant it access to your app's financial information. Similarly, in the Play Store Developer Console, you can also invite a read-financial-data-only account for use with App Annie. These accounts cannot purchase anything, they can only see the financial reports for your apps. Thanks to Steve for pointing this out. I hope that App Annie makes this suggestion more blatantly in its interface to assuage developer fears about sharing sensitive account credentials going forward.
It bugs me when technologists automatically blame subpar creative work on "design by committee." Individuals can make mediocre stuff just as easily as groups can make mediocre stuff. The effectiveness of a group doing creative work depends on whether or not there's a clear vision and strong leadership. Just because it's a group doesn't mean it's more likely to fail.
Of course, the word "committee" in "design by committee" implies that there is not a clear vision and strong leadership. When you have a group of people with those things, it's not a committee, it's a team.
Still, you rarely hear about great design by team. The myth of the lone genius, the brilliant solo auteur, persists. Lone geniuses do exist, but they're very, very rare. Even Steve Jobs had Woz and Ive.
I don't work well in groups. I work pretty well solo. I'm at my absolute best in a pair. When facing down a difficult problem, I'm likely to be my most open-minded, persistent, and creative riffing and building and even competing with the right person. In a strong pair—preferably a planner/explorer or mentor/mentee matchup—magic can happen.
I'm tired of hearing about lone geniuses and design by committee. Let's recognize more brilliant collaborations.
Brett Slatkin on Owning Your Content · In this video interview, Brett Slatkin, Googler and co-creator of PubSubHubbub, talks briefly about his vision of decentralized sharing, where users publish on their own web site and push that content to each other without relying solely on a service like Twitter or Facebook. Looks like he's walking the talk, too. Slatkin appears to publish everything to his own site and re-post it out on social networks (here's his Twitter, Tumblr, and Google+). I'd love to know what his publishing process looks like. The key to popularizing this practice is dead-simple user experience. ∞ June 24th, 2012
Early Facebook employee, Katherine Losse:
More interesting than the fact that the photo was taken and posted on Facebook is that it didn't occur to anyone in the office that there was anything wrong with it, or that it revealed something unattractive about the culture of Facebook. As Mark wrote on his business card with boyish hubris, "I'm CEO, bitch." The image of me in the bearskin was saying that power wasn't something to be questioned; it was something to collect and brandish.
I don't presume my work is important, but it is important to me. There is so much latent value in our own personal databases of words, links, ideas, emails, likes, photos, IMs, tweets, posts, titles, subtitles—so many connections to be made and so much data to be explored; How many companies have been talking in rapturous tones about their analytics upside, the fact that they can make those connections and resell them? That would work at the micro-level too, for individuals. But it's incredibly difficult to explore my historical self using the disaggregated services out there today. The web in 2012 is still more like Jenga than LEGOs.
In a post entitled Please Don't Learn How to Code, software developer Jeff Atwood argues that the "everyone should learn programming" meme has gotten out of control, and that most people don't need to learn how to code.
I mostly disagree with Atwood's premise and land on Benjamin Stein's side of the argument. Coding teaches you analytical thinking skills, logic workflows, and debugging like no other activity can, and you can apply those skills to lots of situations beyond actually building production apps.
But Atwood hit one nail right on the head that I can't stress enough to people who want to make digital tools:
[Coding] puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
Originally published on CNN.com.
Startups are fighting a war for talent in Silicon Valley, and the companies that actively welcome men and women are going to win it. Smart companies don't recruit "brogrammers."
The term "brogrammer" is a joke, of course. Male software engineers don't actually pop their collars, wear sunglasses and lift weights while writing code, and share hot tubs with bikini-clad women. But the joke is funny (to some people) because it reflects a certain truth about a community that excludes great talent in favor of frat house fun.
Most people have no idea what the market rate or prevailing wage is for their profession and career level, much less where they fall on the pay scale.I’m tired of fluffy unvetted career advice, so I’ve sourced and linked to ten ways you can determine what other people with your job are paid.
"Want to bro down and crush code?" No.
The Shit Girls Say meme blew up because all of us vaguely recognize the college-age woman who says those things. The meme is also highly annoying because it implies "girls" are airheads.
I prefer a more constructive commentary on female speaking habits, which is why I loved a recent podcast interview with Tara Mohr, a women's leadership expert. Mohr describes little ways in which women unconsciously discount or minimize what they have to say, by overusing words like "just" and "actually," making declarative statements sound like questions, and by talking too quickly to avoid interruption.