{
"url": "http://www.unmung.com/feed?feed=http%3A%2F%2Finessential.com%2Fxml%2Frss.xml",
"children": [
{
"updated": "2018-03-14T19:09:31",
"name": "The Omni Show #10: Dave Lonning, Documentation Wrangler",
"url": "http://inessential.com/2018/03/14/the_omni_show_10_dave_lonning_documen",
"summary": "\n\nIn this episode we talk with Dave Lonning, who writes documentation for Omni apps. Dave\u2019s a long-time fan of role-playing games \u2014\u00a0running them and creating them \u2014 and he lived for years in Japan before making his way to Omni.\nAmong Dave\u2019s hobbies is painting miniatures:\n\nDave, it should be noted, is a cat person \u2014 but, importantly, he\u2019s learned to love the Omni dogs. They\u2019re good dogs, Dove.\n",
"content": "\n\n\nIn this episode we talk with Dave Lonning, who writes documentation for Omni apps. Dave\u2019s a long-time fan of role-playing games \u2014\u00a0running them and creating them \u2014 and he lived for years in Japan before making his way to Omni.\nAmong Dave\u2019s hobbies is painting miniatures:\n\nDave, it should be noted, is a cat person \u2014 but, importantly, he\u2019s learned to love the Omni dogs. They\u2019re good dogs, Dove.\n\n",
"type": "entry"
},
{
"updated": "2018-03-10T00:50:30",
"name": "Marketing Human",
"url": "http://inessential.com/2018/03/09/marketing_human",
"summary": "\nI\u2019ve got some career-change news that might sound weird at first but that I promise will make sense in a minute: I\u2019m quite happily still at Omni, but I\u2019m switching from engineering over to marketing.\nI am the new Marketing Human, a new member of the Design department.\nIf you think of me as an engineer, you\u2019re not wrong \u2014 but the secret, hidden in plain sight, is that throughout my career I\u2019ve done a whole bunch of design and things that could be called marketing.\nBlogging could be called marketing, after all, and today I wrote my first post for the Omni blog.\n(For whatever freakish reason, writing has never been a chore to me \u2014 I love it. Sometimes I think I only make apps just to have something to write about.)\nBut the new job isn\u2019t just blogging \u2014 I\u2019m also doing a podcast. I\u2019ll help figure out the marketing points behind the release of OmniFocus 3. I\u2019ll write some ads. I\u2019ll create new websites. I don\u2019t even know what all the different things are yet.\nI\u2019ll also help with defining future versions of our apps, which is super-exciting for me. This keeps me close to the process of app-making \u2014 at a different level, sure, but at a place where I\u2019m quite happy, since I\u2019ve done this kind of work with Frontier, NetNewsWire, MarsEdit, Glassboard, Vesper, and now with Evergreen and back to Frontier.\nIn other words, I\u2019m using the skills I\u2019ve learned as an indie and sort-of-indie over decades \u2014 just not the skills I write about here that often.\nMake sense? Cool. :)\n* * *\nFor now, until OmniFocus 3 ships, I\u2019m splitting my time: doing this and continuing to work directly on the Mac app. After that I\u2019ll be a full-time Marketing Human.\nIf you want to get in touch with me, you can email me at marketing at The Omni Group\u2019s domain name.\n* * *\nOne interesting part of this \u2014\u00a0at least for me \u2014\u00a0is that, for the first time in decades, I\u2019ll be back to writing code purely for fun. I\u2019ll continue to work on Evergreen and other apps on nights and weekends, for sure. And I\u2019ll keep writing about code on this blog.\nBut engineering will just be my hobby. I love that.\n",
"content": "\n\nI\u2019ve got some career-change news that might sound weird at first but that I promise will make sense in a minute: I\u2019m quite happily still at Omni, but I\u2019m switching from engineering over to marketing.\nI am the new Marketing Human, a new member of the Design department.\nIf you think of me as an engineer, you\u2019re not wrong \u2014 but the secret, hidden in plain sight, is that throughout my career I\u2019ve done a whole bunch of design and things that could be called marketing.\nBlogging could be called marketing, after all, and today I wrote my first post for the Omni blog.\n(For whatever freakish reason, writing has never been a chore to me \u2014 I love it. Sometimes I think I only make apps just to have something to write about.)\nBut the new job isn\u2019t just blogging \u2014 I\u2019m also doing a podcast. I\u2019ll help figure out the marketing points behind the release of OmniFocus 3. I\u2019ll write some ads. I\u2019ll create new websites. I don\u2019t even know what all the different things are yet.\nI\u2019ll also help with defining future versions of our apps, which is super-exciting for me. This keeps me close to the process of app-making \u2014 at a different level, sure, but at a place where I\u2019m quite happy, since I\u2019ve done this kind of work with Frontier, NetNewsWire, MarsEdit, Glassboard, Vesper, and now with Evergreen and back to Frontier.\nIn other words, I\u2019m using the skills I\u2019ve learned as an indie and sort-of-indie over decades \u2014 just not the skills I write about here that often.\nMake sense? Cool. :)\n* * *\nFor now, until OmniFocus 3 ships, I\u2019m splitting my time: doing this and continuing to work directly on the Mac app. After that I\u2019ll be a full-time Marketing Human.\nIf you want to get in touch with me, you can email me at marketing at The Omni Group\u2019s domain name.\n* * *\nOne interesting part of this \u2014\u00a0at least for me \u2014\u00a0is that, for the first time in decades, I\u2019ll be back to writing code purely for fun. I\u2019ll continue to work on Evergreen and other apps on nights and weekends, for sure. And I\u2019ll keep writing about code on this blog.\nBut engineering will just be my hobby. I love that.\n\n",
"type": "entry"
},
{
"updated": "2018-03-03T06:06:25",
"name": "Greenwood: Unfinished Microblogging System",
"url": "http://inessential.com/2018/03/02/greenwood_unfinished_microblogging_syst",
"summary": "\nA year ago I was working on a microblogging system and wrote a bunch of it,\u00a0but I didn\u2019t actually finish it.\nWhen I realized it\u2019s not what I actually want, I shelved it.\nBut interest in microblogging has grown since then \u2014 thanks to Micro.blog \u2014\u00a0and so I posted my code on GitHub just in case somebody else wants to fork it and do something with it.\nThe app is called Greenwood. Partly because I like the freshness it evokes \u2014\u00a0it\u2019s a great name for a fresh, simple start \u2014\u00a0and partly because Greenwood is the neighborhood next to mine (I\u2019m in Ballard), and I\u2019ve been giving things Pacific Northwest names lately.\n* * *\nBlog posts are stored as separate files on disk. There\u2019s a place for attributes at the top of each file, and then the rest is Markdown.\nIt\u2019s written in Ruby; it\u2019s a Sinatra app. It\u2019s fast. I tested it using eight years of inessential.com\u2019s files.\nMy plan was to put it in front of a caching Nginx server, so it would essentially run as fast as a statically-rendered site.\nThere\u2019s surprisingly not much code. And, well, that\u2019s because it\u2019s unfinished.\nAnd \u2014\u00a0as it says at the top of the README in the repo \u2014\u00a0DO NOT DEPLOY THIS APP AS-IS. IT IS NOT SECURE.\n",
"content": "\n\nA year ago I was working on a microblogging system and wrote a bunch of it,\u00a0but I didn\u2019t actually finish it.\nWhen I realized it\u2019s not what I actually want, I shelved it.\nBut interest in microblogging has grown since then \u2014 thanks to Micro.blog \u2014\u00a0and so I posted my code on GitHub just in case somebody else wants to fork it and do something with it.\nThe app is called Greenwood. Partly because I like the freshness it evokes \u2014\u00a0it\u2019s a great name for a fresh, simple start \u2014\u00a0and partly because Greenwood is the neighborhood next to mine (I\u2019m in Ballard), and I\u2019ve been giving things Pacific Northwest names lately.\n* * *\nBlog posts are stored as separate files on disk. There\u2019s a place for attributes at the top of each file, and then the rest is Markdown.\nIt\u2019s written in Ruby; it\u2019s a Sinatra app. It\u2019s fast. I tested it using eight years of inessential.com\u2019s files.\nMy plan was to put it in front of a caching Nginx server, so it would essentially run as fast as a statically-rendered site.\nThere\u2019s surprisingly not much code. And, well, that\u2019s because it\u2019s unfinished.\nAnd \u2014\u00a0as it says at the top of the README in the repo \u2014\u00a0DO NOT DEPLOY THIS APP AS-IS. IT IS NOT SECURE.\n\n",
"type": "entry"
},
{
"updated": "2018-03-02T22:33:37",
"name": "Script Debugger 7",
"url": "http://inessential.com/2018/03/02/script_debugger_7",
"summary": "\nScript Debugger has long been the secret weapon of people who write AppleScript scripts \u2014\u00a0and now it\u2019s at version 7. Better than ever!\nPlus really cool new icons!\nEvergreen is AppleScript-able. So are Omni\u2019s Mac apps. So is Acorn. And MarsEdit. And so many others.\n(Bonus tip: FastScripts is a great utility for running AppleScript scripts. I use it all day every day.)\n",
"content": "\n\nScript Debugger has long been the secret weapon of people who write AppleScript scripts \u2014\u00a0and now it\u2019s at version 7. Better than ever!\nPlus really cool new icons!\nEvergreen is AppleScript-able. So are Omni\u2019s Mac apps. So is Acorn. And MarsEdit. And so many others.\n(Bonus tip: FastScripts is a great utility for running AppleScript scripts. I use it all day every day.)\n\n",
"type": "entry"
},
{
"updated": "2018-02-28T19:51:33",
"name": "The Omni Show #9: Ainsley Bourque Olson, OmniPlan PM",
"url": "http://inessential.com/2018/02/28/the_omni_show_9_ainsley_bourque_olson_",
"summary": "\n\nThe latest episode of The Omni Show features Ainsley Bourque Olson \u2014 who\u2019s the product manager for OmniPlan,\u00a0a project management app. It\u2019s almost meta!\nShe\u2019s also a knitter \u2014 we have a pretty strong group of knitters here \u2014\u00a0and a cat person.\nMe too. In fact, I\u2019m going to go find a place in the sun to curl up. :)\n",
"content": "\n\n\nThe latest episode of The Omni Show features Ainsley Bourque Olson \u2014 who\u2019s the product manager for OmniPlan,\u00a0a project management app. It\u2019s almost meta!\nShe\u2019s also a knitter \u2014 we have a pretty strong group of knitters here \u2014\u00a0and a cat person.\nMe too. In fact, I\u2019m going to go find a place in the sun to curl up. :)\n\n",
"type": "entry"
},
{
"updated": "2018-02-15T00:14:29",
"name": "OmniOutliner 3 for iOS",
"url": "http://inessential.com/2018/02/14/omnioutliner_3_for_ios",
"summary": "\nI\u2019d done almost no iOS work since system 7 came out \u2014\u00a0but, once we were finished with OmniOutliner 5 for Mac (a release I\u2019m super-proud of), it was time to go work on OmniOutliner 3 for iOS, and so they pulled me back in. :)\nI was just one person on a much bigger team, of course. I helped indent some things and helped with filters. But there\u2019s a whole bunch more besides \u2014\u00a0it\u2019s a big release.\nAnd it\u2019s the first OmniOutliner for iOS release with a lower-cost Essentials version ($9.99). And it\u2019s a free trial.\nAnd I\u2019m super-proud of this release, too.\nRead all about it on The Omni Blog: OmniOutliner 3 for iOS is here! Get your free trial from the App Store.\n",
"content": "\n\nI\u2019d done almost no iOS work since system 7 came out \u2014\u00a0but, once we were finished with OmniOutliner 5 for Mac (a release I\u2019m super-proud of), it was time to go work on OmniOutliner 3 for iOS, and so they pulled me back in. :)\nI was just one person on a much bigger team, of course. I helped indent some things and helped with filters. But there\u2019s a whole bunch more besides \u2014\u00a0it\u2019s a big release.\nAnd it\u2019s the first OmniOutliner for iOS release with a lower-cost Essentials version ($9.99). And it\u2019s a free trial.\nAnd I\u2019m super-proud of this release, too.\nRead all about it on The Omni Blog: OmniOutliner 3 for iOS is here! Get your free trial from the App Store.\n\n",
"type": "entry"
},
{
"updated": "2018-02-14T20:22:22",
"name": "The Omni Show #8: Orion, Bug Hunter",
"url": "http://inessential.com/2018/02/14/the_omni_show_8_orion_bug_hunter",
"summary": "\n\nIn the latest episode of The Omni Show I talk to Orion Protonentis, recovering actor and stage fighter, friend of Shakespeare, and Software Test Pilot.\nThe Scottish Play is mentioned, but only as \u201cthe Scottish play.\u201d So we\u2019re all good there \u2014 if you\u2019re in a theater right now you can safely listen to this.\n",
"content": "\n\n\nIn the latest episode of The Omni Show I talk to Orion Protonentis, recovering actor and stage fighter, friend of Shakespeare, and Software Test Pilot.\nThe Scottish Play is mentioned, but only as \u201cthe Scottish play.\u201d So we\u2019re all good there \u2014 if you\u2019re in a theater right now you can safely listen to this.\n\n",
"type": "entry"
},
{
"updated": "2018-02-07T05:49:09",
"name": "Brenty\u2019s First Pod",
"url": "http://inessential.com/2018/02/06/brentys_first_pod",
"summary": "\nRSParser is now a CocoaPod! It\u2019s my first.\nI\u2019m super-proud of myself for taking this the last few tiny steps of the way there \u2014 Silver Fox did all the rest of the much-appreciated work.\nThis means that if you\u2019re a CocoaPods user, you can now go forth and parse feeds.\nStill to do: support Carthage and Swift Package Manager. And, after this repo, there are at least a half-dozen more to do.\nBut that\u2019s okay \u2014\u00a0doing open source is what I signed up for, and learning and using the infrastructure is part of the gig.\nPS I really like what happens in the Terminal when you successfully publish a pod. Here\u2019s a screenshot.\n",
"content": "\n\nRSParser is now a CocoaPod! It\u2019s my first.\nI\u2019m super-proud of myself for taking this the last few tiny steps of the way there \u2014 Silver Fox did all the rest of the much-appreciated work.\nThis means that if you\u2019re a CocoaPods user, you can now go forth and parse feeds.\nStill to do: support Carthage and Swift Package Manager. And, after this repo, there are at least a half-dozen more to do.\nBut that\u2019s okay \u2014\u00a0doing open source is what I signed up for, and learning and using the infrastructure is part of the gig.\nPS I really like what happens in the Terminal when you successfully publish a pod. Here\u2019s a screenshot.\n\n",
"type": "entry"
},
{
"updated": "2018-02-06T21:08:21",
"name": "On Missing the Point",
"url": "http://inessential.com/2018/02/06/on_missing_the_point",
"summary": "\n(Disclaimer: before I get started, I should take extra care to note that I don\u2019t speak for Omni. This is my personal blog, with my personal opinions.)\nEvery time I make some criticism of the App Store \u2014 that, for instance, the 30% cut for Apple is too high, or that free trials would be a good thing \u2014 some number of people respond that Apple is a business and they\u2019re allowed to do what they\u2019re doing.\nThey may also remind me that this is capitalism, and that I can vote with my feet \u2014 that is, go create an Android app (or whatever) where the cost is presumably lower.\nAnd they remind me that I should work with the world as it is, rather than the world as I want it to be.\nThey\u2019re not wrong. Of course Apple is a business and is within their rights to charge whatever they want to charge, and developers could go do something else. And when making business decisions we have to look at facts and best extrapolations, not wishes and ponies.\nBut that misses the point entirely.\n* * *\nThe point is that we are allowed \u2014\u00a0even in a capitalist system! \u2014 to criticize and to ask for changes. You can ask your spouse to put away the dishes more often; you can ask your kids to do their homework before dinner; you can ask the government for universal health care or corporate tax cuts; and you can ask Apple to lower the App Store cut.\nImagine if Starbucks charged $20 for a latte. You might complain about it and ask them to lower the price. Even if there\u2019s another coffee shop nearby with much less expensive lattes, you still might.\nYes! Even in a capitalist system you can do this! It\u2019s totally a-okay! Even if they\u2019re within their rights (they are) to charge that much. Even if they are a business!\nThere\u2019s no sacred verse that says businesses acting lawfully can\u2019t be criticized. Nothing says we can\u2019t advocate for change. In fact, I\u2019d say that that\u2019s part of capitalism, too.\n* * *\nSo I got into a lengthy Twitter argument about Apple\u2019s 30% App Store cut.\nMy thinking is that a lower cut provides more incentive for developers to invest in high-quality, long-lived apps \u2014\u00a0and that that\u2019s good for the platform and good for users, and good for Apple, and so everybody wins.\nIt\u2019s at least worth trying (this being capitalism, there are no guarantees of success) \u2014\u00a0and, since Apple is the wealthiest company in the history of companies, they could afford to try this.\nIf I\u2019m right, then everybody wins: Apple, users, and developers. And if I\u2019m wrong, Apple is not in any financial jeopardy.\n* * *\nI don\u2019t think I\u2019m misunderstanding or breaking the rules of capitalism by saying this. Nor am I telling developers to base their business decisions on fantasies.\nBut somebody will tell me that I am.\n",
"content": "\n\n(Disclaimer: before I get started, I should take extra care to note that I don\u2019t speak for Omni. This is my personal blog, with my personal opinions.)\nEvery time I make some criticism of the App Store \u2014 that, for instance, the 30% cut for Apple is too high, or that free trials would be a good thing \u2014 some number of people respond that Apple is a business and they\u2019re allowed to do what they\u2019re doing.\nThey may also remind me that this is capitalism, and that I can vote with my feet \u2014 that is, go create an Android app (or whatever) where the cost is presumably lower.\nAnd they remind me that I should work with the world as it is, rather than the world as I want it to be.\nThey\u2019re not wrong. Of course Apple is a business and is within their rights to charge whatever they want to charge, and developers could go do something else. And when making business decisions we have to look at facts and best extrapolations, not wishes and ponies.\nBut that misses the point entirely.\n* * *\nThe point is that we are allowed \u2014\u00a0even in a capitalist system! \u2014 to criticize and to ask for changes. You can ask your spouse to put away the dishes more often; you can ask your kids to do their homework before dinner; you can ask the government for universal health care or corporate tax cuts; and you can ask Apple to lower the App Store cut.\nImagine if Starbucks charged $20 for a latte. You might complain about it and ask them to lower the price. Even if there\u2019s another coffee shop nearby with much less expensive lattes, you still might.\nYes! Even in a capitalist system you can do this! It\u2019s totally a-okay! Even if they\u2019re within their rights (they are) to charge that much. Even if they are a business!\nThere\u2019s no sacred verse that says businesses acting lawfully can\u2019t be criticized. Nothing says we can\u2019t advocate for change. In fact, I\u2019d say that that\u2019s part of capitalism, too.\n* * *\nSo I got into a lengthy Twitter argument about Apple\u2019s 30% App Store cut.\nMy thinking is that a lower cut provides more incentive for developers to invest in high-quality, long-lived apps \u2014\u00a0and that that\u2019s good for the platform and good for users, and good for Apple, and so everybody wins.\nIt\u2019s at least worth trying (this being capitalism, there are no guarantees of success) \u2014\u00a0and, since Apple is the wealthiest company in the history of companies, they could afford to try this.\nIf I\u2019m right, then everybody wins: Apple, users, and developers. And if I\u2019m wrong, Apple is not in any financial jeopardy.\n* * *\nI don\u2019t think I\u2019m misunderstanding or breaking the rules of capitalism by saying this. Nor am I telling developers to base their business decisions on fantasies.\nBut somebody will tell me that I am.\n\n",
"type": "entry"
},
{
"updated": "2018-02-01T21:01:38",
"name": "Why Micro.blog is Not Another App.net",
"url": "http://inessential.com/2018/02/01/why_micro_blog_is_not_another_app_net",
"summary": "\nWe could be excused for thinking that Micro.blog is like App.net \u2014\u00a0a Twitter alternative greeted with enthusiasm but that eventually closed.\nIt\u2019s not the same thing, though, and I\u2019ll explain why.\nMicro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that the web itself is the great social network.\nThat\u2019s the important part: even if Micro.blog doesn\u2019t last (though I believe it will), the idea \u2014 that the web itself is where we are and where we talk to each other \u2014 will continue.\nAnd: Micro.blog could be just one of thousands of similar services. And those services would all work together, because they\u2019re made of web-stuff.\nThe Dream of 1999\nPick your year. I like 2003, since that was when I released NetNewsWire 1.0, an early Mac RSS reader. You might prefer 2000 (nice round number) or 2005 (things were a bit more advanced).\nBut if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years \u2014\u00a0but then a few tragedies happened: Google Reader came out, and then, almost worse, it went away. Worse still was the rise of Twitter and Facebook, when we decided it would be okay to give up ownership and let just a couple companies own our communication.\nEven if those companies had the public interest in mind \u2014 and they most definitely do not \u2014 they hold far too much power over something too fundamental to give up: our own human voices.\nTwitter and Facebook are convenient, sure, but so are fossil fuels, and the cost was similarly unknown for a long time. But now we have some idea just how bad these things are for the world.\nMicro.blog rewinds us to 2005 (or pick your year) \u2014\u00a0but, also, it has learned the lesson that people really like a timeline of short posts. People like being able to write and reply easily to other people. Good to know!\nBlogs\nWhen you post to Micro.blog, you\u2019re posting to an actual blog with an RSS feed and everything. The blog might be hosted by Micro.blog, or it might be some other blog somewhere else. (Could be a WordPress blog, for instance.)\nYour posts are just a normal, everyday part of the open web. At this writing, mine appear on micro.inessential.com \u2014 but it\u2019s on my to-do list to have those appear on my main blog (this blog) instead. (Probably won\u2019t happen until after I ship the app I\u2019m currently working on.)\nAnd this is how it used to be, and how it never should have stopped being: my blog is me on the web. I own my blog: I own me.\nAnd so everyone who follows me on Micro.blog sees my blog posts, and I see theirs. Simple.\nAnd anyone who wants to could just read my blog in an RSS reader instead. All good, all open.\nReplies\nReplies are a little trickier. (Micro.blog is not a finished thing \u2014 the-web-as-social-network is not a finished thing, and, we hope, never will be. That\u2019s totally fine.)\nReplies don\u2019t appear on your blog (though this could become an option, I suppose) \u2014 but they are sent as a WebMention when possible, which means even replies are part of the open web. You can read more about replies and @-mentions on the help site.\nI expect this area to get more work in the future, especially as it\u2019s part of the key to making Micro.blog part of the great social network but not the great social network (the web itself).\nThe app in your pocket\nIf you\u2019re running the Micro.blog app on your iPhone or Mac, it really does look like a slimmed-down Twitter. This is by design. But don\u2019t let that deceive you.\nIf the web is a river, Micro.blog is water, where Twitter and Facebook are dams.\nWhat about my Uncle Joe?\nYou might think this is too difficult for normal people, that it\u2019s all too nerdy, and that it won\u2019t make headway against Twitter, so who cares.\nMy reply: it\u2019s okay if this is a work in progress and isn\u2019t ready for everybody yet. It\u2019s okay if it takes time. We don\u2019t know how it will all work in the end.\nWe\u2019re discovering the future as we build it.\n",
"content": "\n\nWe could be excused for thinking that Micro.blog is like App.net \u2014\u00a0a Twitter alternative greeted with enthusiasm but that eventually closed.\nIt\u2019s not the same thing, though, and I\u2019ll explain why.\nMicro.blog is not an alternative silo: instead, it\u2019s what you build when you believe that the web itself is the great social network.\nThat\u2019s the important part: even if Micro.blog doesn\u2019t last (though I believe it will), the idea \u2014 that the web itself is where we are and where we talk to each other \u2014 will continue.\nAnd: Micro.blog could be just one of thousands of similar services. And those services would all work together, because they\u2019re made of web-stuff.\nThe Dream of 1999\nPick your year. I like 2003, since that was when I released NetNewsWire 1.0, an early Mac RSS reader. You might prefer 2000 (nice round number) or 2005 (things were a bit more advanced).\nBut if you think of the years 1995-2005, you remember when the web was our social network: blogs, comments on blogs, feed readers, and services such as Flickr, Technorati, and BlogBridge to glue things together. Those were great years \u2014\u00a0but then a few tragedies happened: Google Reader came out, and then, almost worse, it went away. Worse still was the rise of Twitter and Facebook, when we decided it would be okay to give up ownership and let just a couple companies own our communication.\nEven if those companies had the public interest in mind \u2014 and they most definitely do not \u2014 they hold far too much power over something too fundamental to give up: our own human voices.\nTwitter and Facebook are convenient, sure, but so are fossil fuels, and the cost was similarly unknown for a long time. But now we have some idea just how bad these things are for the world.\nMicro.blog rewinds us to 2005 (or pick your year) \u2014\u00a0but, also, it has learned the lesson that people really like a timeline of short posts. People like being able to write and reply easily to other people. Good to know!\nBlogs\nWhen you post to Micro.blog, you\u2019re posting to an actual blog with an RSS feed and everything. The blog might be hosted by Micro.blog, or it might be some other blog somewhere else. (Could be a WordPress blog, for instance.)\nYour posts are just a normal, everyday part of the open web. At this writing, mine appear on micro.inessential.com \u2014 but it\u2019s on my to-do list to have those appear on my main blog (this blog) instead. (Probably won\u2019t happen until after I ship the app I\u2019m currently working on.)\nAnd this is how it used to be, and how it never should have stopped being: my blog is me on the web. I own my blog: I own me.\nAnd so everyone who follows me on Micro.blog sees my blog posts, and I see theirs. Simple.\nAnd anyone who wants to could just read my blog in an RSS reader instead. All good, all open.\nReplies\nReplies are a little trickier. (Micro.blog is not a finished thing \u2014 the-web-as-social-network is not a finished thing, and, we hope, never will be. That\u2019s totally fine.)\nReplies don\u2019t appear on your blog (though this could become an option, I suppose) \u2014 but they are sent as a WebMention when possible, which means even replies are part of the open web. You can read more about replies and @-mentions on the help site.\nI expect this area to get more work in the future, especially as it\u2019s part of the key to making Micro.blog part of the great social network but not the great social network (the web itself).\nThe app in your pocket\nIf you\u2019re running the Micro.blog app on your iPhone or Mac, it really does look like a slimmed-down Twitter. This is by design. But don\u2019t let that deceive you.\nIf the web is a river, Micro.blog is water, where Twitter and Facebook are dams.\nWhat about my Uncle Joe?\nYou might think this is too difficult for normal people, that it\u2019s all too nerdy, and that it won\u2019t make headway against Twitter, so who cares.\nMy reply: it\u2019s okay if this is a work in progress and isn\u2019t ready for everybody yet. It\u2019s okay if it takes time. We don\u2019t know how it will all work in the end.\nWe\u2019re discovering the future as we build it.\n\n",
"type": "entry"
},
{
"updated": "2018-01-31T18:49:12",
"name": "The Omni Show #7: Ken Case Talks About the 2018 Roadmap",
"url": "http://inessential.com/2018/01/31/the_omni_show_7_ken_case_talks_about_t",
"summary": "\nCheck out episode #7 (I wish we had called it 007) where Ken Case talks about all the good stuff coming up in 2018.\nThere will be new releases of OmniOutliner, OmniPlan, and OmniGraffle \u2014 plus a whole bunch of great stuff for OmniFocus 3.0 for Mac and iOS,\u00a0including tags, JavaScript scripting, and OmniFocus for the web.\nYou can subscribe to the podcast or just listen to this episode \u2014 there\u2019s a player on the page. Or you can read the transcript.\n* * *\nI\u2019ve been wondering if other companies in our world are doing similar podcasts.\nThere is the Supertop Podcast from our friends who make Castro. And there are much larger companies (such as Microsoft) who create videos and podcasts.\nIt may be that Omni\u2019s size is somewhat unique in the Mac and iOS world: it\u2019s big enough that we won\u2019t run out of people to interview and topics to talk about, which could be tricky for a 5- or 10-person company. And it\u2019s small enough to still be intimate \u2014\u00a0my goal is to eventually interview every single person who works here. (Though, of course, people can decline: it\u2019s not required!)\nAnyway: there was a time before companies had blogs, and now they have blogs. I wonder if more and more companies will find value in having a podcast too.\n(And a Slack group. And a Micro.blog account.)\n",
"content": "\n\nCheck out episode #7 (I wish we had called it 007) where Ken Case talks about all the good stuff coming up in 2018.\nThere will be new releases of OmniOutliner, OmniPlan, and OmniGraffle \u2014 plus a whole bunch of great stuff for OmniFocus 3.0 for Mac and iOS,\u00a0including tags, JavaScript scripting, and OmniFocus for the web.\nYou can subscribe to the podcast or just listen to this episode \u2014 there\u2019s a player on the page. Or you can read the transcript.\n* * *\nI\u2019ve been wondering if other companies in our world are doing similar podcasts.\nThere is the Supertop Podcast from our friends who make Castro. And there are much larger companies (such as Microsoft) who create videos and podcasts.\nIt may be that Omni\u2019s size is somewhat unique in the Mac and iOS world: it\u2019s big enough that we won\u2019t run out of people to interview and topics to talk about, which could be tricky for a 5- or 10-person company. And it\u2019s small enough to still be intimate \u2014\u00a0my goal is to eventually interview every single person who works here. (Though, of course, people can decline: it\u2019s not required!)\nAnyway: there was a time before companies had blogs, and now they have blogs. I wonder if more and more companies will find value in having a podcast too.\n(And a Slack group. And a Micro.blog account.)\n\n",
"type": "entry"
},
{
"updated": "2018-01-25T21:21:54",
"name": "Evergreen Diary #9: On IndieWeb",
"url": "http://inessential.com/2018/01/25/evergreen_diary_9_on_indieweb",
"summary": "\nWhen IndieWeb started, some years back, the first thing I noticed was that they appeared to be against the idea of feeds \u2014 or, at least, what they called side feeds: RSS and similar.\nTheir idea was that the data a reader might collect should be encoded in the page itself, using microformats. The argument (I think; I hope I\u2019m not misrepresenting anyone) was that microformats are simpler than mantaining a separate file.\nI don\u2019t know which thought occurred to me first:\nI took it personally, since I\u2019d spent much of my career working with feeds, and I took this as a suggestion that my career was all wrong and they wouldn\u2019t be interested in someone like me, someone who would be an ally in their committment to the open web.\nI objected on practical grounds, too. Feeds have been and remain tremendously successful \u2014 see podcasting, for one thing \u2014\u00a0and the way forward is to build on that success. And, while I understand the elegance of microformats, side feeds have critical advantages that microformat-feeds don\u2019t.\nSo I decided to ignore IndieWeb.\nHere\u2019s the thing, though: that was me being a total jerk.\n(I\u2019m telling you about this so you can learn from my mistake.)\nFast-forward\nIn the last couple years I\u2019ve been chatting with Manton Reece, Micro.blog creator, a bit \u2014 and Manton agrees with me about feeds.\nBut Manton also works with IndieWeb, and has mentioned any number of good ideas they have that I should look into.\nIt took me a while, but I realized that I was acting like a Clinton or Sanders supporter still arguing with the other side about the 2016 primaries \u2014 after losing the general election to a monster, after the point where those small differences matter at all.\nAnd then I started to get excited about IndieWeb. I may have a difference of opinion when it comes to feeds, but who the hell cares when there\u2019s so much good stuff to do? (They\u2019re not holding my opinion against me; why should I hold theirs against them?)\nAnd so I decided to support the h-feed format in Evergreen (hopefully in 1.0). That\u2019s just for starters: I also decided to look into everything else and see what makes sense to support.\nMy default position now is: if a format or API or syncing service makes sense for a feed reader, then I\u2019ll (at least try to) support it.\n",
"content": "\n\nWhen IndieWeb started, some years back, the first thing I noticed was that they appeared to be against the idea of feeds \u2014 or, at least, what they called side feeds: RSS and similar.\nTheir idea was that the data a reader might collect should be encoded in the page itself, using microformats. The argument (I think; I hope I\u2019m not misrepresenting anyone) was that microformats are simpler than mantaining a separate file.\nI don\u2019t know which thought occurred to me first:\nI took it personally, since I\u2019d spent much of my career working with feeds, and I took this as a suggestion that my career was all wrong and they wouldn\u2019t be interested in someone like me, someone who would be an ally in their committment to the open web.\nI objected on practical grounds, too. Feeds have been and remain tremendously successful \u2014 see podcasting, for one thing \u2014\u00a0and the way forward is to build on that success. And, while I understand the elegance of microformats, side feeds have critical advantages that microformat-feeds don\u2019t.\nSo I decided to ignore IndieWeb.\nHere\u2019s the thing, though: that was me being a total jerk.\n(I\u2019m telling you about this so you can learn from my mistake.)\nFast-forward\nIn the last couple years I\u2019ve been chatting with Manton Reece, Micro.blog creator, a bit \u2014 and Manton agrees with me about feeds.\nBut Manton also works with IndieWeb, and has mentioned any number of good ideas they have that I should look into.\nIt took me a while, but I realized that I was acting like a Clinton or Sanders supporter still arguing with the other side about the 2016 primaries \u2014 after losing the general election to a monster, after the point where those small differences matter at all.\nAnd then I started to get excited about IndieWeb. I may have a difference of opinion when it comes to feeds, but who the hell cares when there\u2019s so much good stuff to do? (They\u2019re not holding my opinion against me; why should I hold theirs against them?)\nAnd so I decided to support the h-feed format in Evergreen (hopefully in 1.0). That\u2019s just for starters: I also decided to look into everything else and see what makes sense to support.\nMy default position now is: if a format or API or syncing service makes sense for a feed reader, then I\u2019ll (at least try to) support it.\n\n",
"type": "entry"
},
{
"updated": "2018-01-24T21:20:45",
"name": "Evergreen Diary #8: Coding Guidelines",
"url": "http://inessential.com/2018/01/24/evergreen_diary_8_coding_guidelines",
"summary": "\nI published the first draft of Evergreen\u2019s Coding Guidelines yesterday.\nI posted this because I\u2019d like to have people help me with the app \u2014 but I\u2019m not ready yet. Or, rather, a few people who I know are starting to help, and I want to keep it small for now since I\u2019ve never done this before.\nIf you\u2019re interested in helping, I hope you\u2019ll forgive me as I take it slow and learn how to manage an open source app with many contributors.\n* * *\nThis isn\u2019t the only app I want to do: there are several others. Ideally I\u2019ll get to the point where I\u2019m managing several open source apps \u2014 assuming people are interested in helping, which is a big assumption \u2014 and it\u2019s all going great. But it will take time to get there.\n(All my ideas are Mac and iOS apps that have something to do with the open web. I\u2019ve always been happiest when working at that intersection.)\nAnyway\u2026 it seemed like a good idea to write up coding guidelines early, so I did.\nPS When I was faced with that blank document window, I started by typing the words \u201cNo subclasses,\u201d because sheesh I really, really hate subclasses. The rest tumbled out.\n",
"content": "\n\nI published the first draft of Evergreen\u2019s Coding Guidelines yesterday.\nI posted this because I\u2019d like to have people help me with the app \u2014 but I\u2019m not ready yet. Or, rather, a few people who I know are starting to help, and I want to keep it small for now since I\u2019ve never done this before.\nIf you\u2019re interested in helping, I hope you\u2019ll forgive me as I take it slow and learn how to manage an open source app with many contributors.\n* * *\nThis isn\u2019t the only app I want to do: there are several others. Ideally I\u2019ll get to the point where I\u2019m managing several open source apps \u2014 assuming people are interested in helping, which is a big assumption \u2014 and it\u2019s all going great. But it will take time to get there.\n(All my ideas are Mac and iOS apps that have something to do with the open web. I\u2019ve always been happiest when working at that intersection.)\nAnyway\u2026 it seemed like a good idea to write up coding guidelines early, so I did.\nPS When I was faced with that blank document window, I started by typing the words \u201cNo subclasses,\u201d because sheesh I really, really hate subclasses. The rest tumbled out.\n\n",
"type": "entry"
},
{
"updated": "2018-01-19T21:29:16",
"name": "Evergreen Diary #7: Syncing and Immediate and Deferrable Actions",
"url": "http://inessential.com/2018/01/19/evergreen_diary_7_syncing_and_immediat",
"summary": "\nThere are, as I mentioned previously, two types of syncable actions: immediate and deferrable.\nAn immediate action is something like adding a feed: it requires that the server is reachable right now, so that the feed actually gets added.\nA deferrable action is something like marking articles as read. The sooner the server knows, the better, sure \u2014\u00a0but it can wait if necessary. It can even wait for weeks or months.\nI\u2019ve decided to make it simple and categorize these actions like this: any structural action that affects the list of feeds and folders (or tags) is an immediate action, while any action that affects the status (read, starred) of articles is deferrable.\nOr, in UI terms: if it\u2019s something you do in the sidebar, it\u2019s immediate; it it\u2019s something you do in the timeline, it\u2019s deferrable.\nMost importantly: you can read articles while you\u2019re offline.\nDiscarded alternate approach\nYou could argue that all actions should be deferrable. For instance, Evergreen could remember that you want to add a given feed, and add that add-feed action to the sync queue and wait for the server to become reachable again.\nBut doing so would add more chance for conflicts. Consider the case where the add-feed action got queued (on your day Mac) and then just sat there. Then, on your night Mac, you add the feed and it succeeds \u2014\u00a0then you decide you don\u2019t like it after all, then delete it.\nThe next day, back on your day Mac, the add-feed call finally goes through, and then you have to delete it again. (And then you report an Evergreen syncing bug.)\nThere are other issues as well: do you add the feed locally? And read it? No, because this gets ambiguous quickly, as Evergreen\u2019s article IDs won\u2019t match the article IDs the server has assigned. Evergreen might not even have found the same feed URL the server found (in the case where you just gave it a website URL).\nSo we\u2019ll stick with these two categories, immediate and deferrable.\nTo refine the definitions: a deferrable action is one where the state change can be reflected locally without risking serious conflicts or ambiguity.\nImmediate actions\nThese will result in an immediate API call, and the result will be reflected in the UI. This is straightforward.\nDeferrable actions\nThese actions will be stored in a database.\nThe simplest way to do this is probably a set of tables: articlesToMarkRead, articlesToMarkUnread, articlesToStar, articlesToUnstar. Each table would have one single column: articleID.\nThis layout is probably the most efficient way to add/delete articles.\nThis is not actually an ordered queue, but I think that\u2019s okay. Most of the time all four tables will be empty.\nWhen articles are marked read (for instance), then those articles will be added to articlesToMarkRead and deleted from articlesToMarkUnread. The system will then know that it has pending status changes to the send to the server.\nThen, periodically, the app will attempt to contact the server. Most of the time this should happen within a minute or so.\nPart of the idea is using this system to coalesce calls: the app shouldn\u2019t call the server every time you select an article (which marks it read). Better to update the database and call the server very-soon-ish, but not necessarily this exact second, to allow for multiple articles to queue up.\nThe downside to this particular layout, which may make me change it, is that supporting additional status types means adding more tables. But the alternative is to add more columns to a single table, which is better but not necessarily that much better.\nAnother downside is that there\u2019s no automatic guarantee that an article ID won\u2019t exist in, say, both articlesToMarkRead and articlesToMarkUnread at the same time. But the answer here is simple, careful coding: a single bottleneck function that never adds to one without deleting from the other.\n",
"content": "\n\nThere are, as I mentioned previously, two types of syncable actions: immediate and deferrable.\nAn immediate action is something like adding a feed: it requires that the server is reachable right now, so that the feed actually gets added.\nA deferrable action is something like marking articles as read. The sooner the server knows, the better, sure \u2014\u00a0but it can wait if necessary. It can even wait for weeks or months.\nI\u2019ve decided to make it simple and categorize these actions like this: any structural action that affects the list of feeds and folders (or tags) is an immediate action, while any action that affects the status (read, starred) of articles is deferrable.\nOr, in UI terms: if it\u2019s something you do in the sidebar, it\u2019s immediate; it it\u2019s something you do in the timeline, it\u2019s deferrable.\nMost importantly: you can read articles while you\u2019re offline.\nDiscarded alternate approach\nYou could argue that all actions should be deferrable. For instance, Evergreen could remember that you want to add a given feed, and add that add-feed action to the sync queue and wait for the server to become reachable again.\nBut doing so would add more chance for conflicts. Consider the case where the add-feed action got queued (on your day Mac) and then just sat there. Then, on your night Mac, you add the feed and it succeeds \u2014\u00a0then you decide you don\u2019t like it after all, then delete it.\nThe next day, back on your day Mac, the add-feed call finally goes through, and then you have to delete it again. (And then you report an Evergreen syncing bug.)\nThere are other issues as well: do you add the feed locally? And read it? No, because this gets ambiguous quickly, as Evergreen\u2019s article IDs won\u2019t match the article IDs the server has assigned. Evergreen might not even have found the same feed URL the server found (in the case where you just gave it a website URL).\nSo we\u2019ll stick with these two categories, immediate and deferrable.\nTo refine the definitions: a deferrable action is one where the state change can be reflected locally without risking serious conflicts or ambiguity.\nImmediate actions\nThese will result in an immediate API call, and the result will be reflected in the UI. This is straightforward.\nDeferrable actions\nThese actions will be stored in a database.\nThe simplest way to do this is probably a set of tables: articlesToMarkRead, articlesToMarkUnread, articlesToStar, articlesToUnstar. Each table would have one single column: articleID.\nThis layout is probably the most efficient way to add/delete articles.\nThis is not actually an ordered queue, but I think that\u2019s okay. Most of the time all four tables will be empty.\nWhen articles are marked read (for instance), then those articles will be added to articlesToMarkRead and deleted from articlesToMarkUnread. The system will then know that it has pending status changes to the send to the server.\nThen, periodically, the app will attempt to contact the server. Most of the time this should happen within a minute or so.\nPart of the idea is using this system to coalesce calls: the app shouldn\u2019t call the server every time you select an article (which marks it read). Better to update the database and call the server very-soon-ish, but not necessarily this exact second, to allow for multiple articles to queue up.\nThe downside to this particular layout, which may make me change it, is that supporting additional status types means adding more tables. But the alternative is to add more columns to a single table, which is better but not necessarily that much better.\nAnother downside is that there\u2019s no automatic guarantee that an article ID won\u2019t exist in, say, both articlesToMarkRead and articlesToMarkUnread at the same time. But the answer here is simple, careful coding: a single bottleneck function that never adds to one without deleting from the other.\n\n",
"type": "entry"
},
{
"updated": "2018-01-18T05:02:45",
"name": "Evergreen Diary #6: Proposed Sync Design",
"url": "http://inessential.com/2018/01/17/evergreen_diary_6_proposed_sync_design",
"summary": "\nMost of the time, a user will do a thing \u2014\u00a0mark some articles as read, for instance \u2014\u00a0and then Evergreen will tell the server (Feedbin, Feedly, etc.) right away. That\u2019s good and easy.\nThe hard part is this: what happens when the server is not reachable for some reason?\nContinuing the example: Evergreen could, in the case of the unreachable server, refuse to mark those articles as read.\nIt could insist that syncing works only when the server is reachable \u2014\u00a0which is not that weird, especially given that it can\u2019t pull new data from the server unless it\u2019s reachable.\nBut it\u2019s weird enough. Consider that selecting an article marks it as read. This policy would make it impossible to even just read what you\u2019ve already downloaded.\nOffline Syncing\nIt\u2019s clear that syncing requires some sort of offline ability.\nRather than set a policy for each possible user action (marking articles read, deleting a feed, etc.), I want to set a single policy and single structure for handling these actions.\n(Note: there will be some things that do actually require a reachable server: downloading new articles and adding a feed come to mind. This design refers to actions where it would be okay to defer notifying the server.)\nProposed Policy\nWhen the user performs a syncable and deferrable action, that action and the relevant parameters will be remembered.\nEvergreen will attempt to notify the server periodically. Once it succeeds, it will forget that action and its parameters.\n(Update 18 Jan: 2018: the original version of this design had a time limit, which has been removed. The concern was that this offline queue would grow unbounded \u2014 but it can\u2019t, since if you can\u2019t reach the server you can\u2019t download new articles, which means the queue is limited to your current local data set.)\nProposed Implementation\nWhen the user performs a deferrable action, the app tries immediately to notify the server.\nIf this first attempt fails, then the action is recorded in a SQLite database with a timestamp and with the parameters it needs to be able to make that call again later. Those parameters will be minimal \u2014 article IDs instead of entire Article objects, for instance.\nThe app will periodically attempt to empty this database: starting with the oldest action, it will notify the server of each. On success, a given action is removed from the database.\nUndo\nEvergreen supports undo as much as possible. For instance, if you mark a number of articles as read, you can undo it.\nIn this case, Evergreen will notify the server of the mark-read action, and then, upon undo, notify the server of a mark-unread action, thereby undoing the effect of the first action.\nIn the case where the mark-read action is in the offline action queue, that will be found and deleted, and there will be no queued action to reverse the effect.\nNon-Deferrable Actions\nActions that require an immediate response from a reachable server include actions such as adding a feed. In the case where a user attempts one of these and the server can\u2019t be reached, an error sheet will explain the problem. Such actions will not be queued.\nThere will not, however, be an error sheet for performing a refresh when the server is unreachable. Instead, in that case, a warning icon is placed next to it in the sidebar, a la Mail and similar apps. Clicking the icon will attempt a connection to the server, and an error sheet explaining the problem will appear if the server still can\u2019t be reached.\nOther Notes\nEvergreen works like Mail and similar apps in that it has a set of accounts for services such as Feedbin, Feedly, and others, along with an On My Mac account that is not synced.\nEach account has its own section in the main window\u2019s source list; each account has its own set of folders and feeds.\nAccounts will be added to Evergreen in Preferences, in an Accounts pane.\nThe policies of these accounts will be respected. For example, if the On My Mac account automatically marks articles as read after n days, it\u2019s possible that some service does this after some other number of days, or never does that at all, and Evergreen won\u2019t override those policies for that service.\nAnother example: the On My Mac account doesn\u2019t support folders-within-folders \u2014 but if a feed service does support that, then the app will support it too, for that service.\n(Current plan: Evergreen 1.0 will ship with Feedbin support, and Evergreen 2.0 will add support for more services.)\nLet me know if any of the above sounds weird or if I missed anything. (There is contact info at the bottom of Evergreen\u2019s main page.)\n",
"content": "\n\nMost of the time, a user will do a thing \u2014\u00a0mark some articles as read, for instance \u2014\u00a0and then Evergreen will tell the server (Feedbin, Feedly, etc.) right away. That\u2019s good and easy.\nThe hard part is this: what happens when the server is not reachable for some reason?\nContinuing the example: Evergreen could, in the case of the unreachable server, refuse to mark those articles as read.\nIt could insist that syncing works only when the server is reachable \u2014\u00a0which is not that weird, especially given that it can\u2019t pull new data from the server unless it\u2019s reachable.\nBut it\u2019s weird enough. Consider that selecting an article marks it as read. This policy would make it impossible to even just read what you\u2019ve already downloaded.\nOffline Syncing\nIt\u2019s clear that syncing requires some sort of offline ability.\nRather than set a policy for each possible user action (marking articles read, deleting a feed, etc.), I want to set a single policy and single structure for handling these actions.\n(Note: there will be some things that do actually require a reachable server: downloading new articles and adding a feed come to mind. This design refers to actions where it would be okay to defer notifying the server.)\nProposed Policy\nWhen the user performs a syncable and deferrable action, that action and the relevant parameters will be remembered.\nEvergreen will attempt to notify the server periodically. Once it succeeds, it will forget that action and its parameters.\n(Update 18 Jan: 2018: the original version of this design had a time limit, which has been removed. The concern was that this offline queue would grow unbounded \u2014 but it can\u2019t, since if you can\u2019t reach the server you can\u2019t download new articles, which means the queue is limited to your current local data set.)\nProposed Implementation\nWhen the user performs a deferrable action, the app tries immediately to notify the server.\nIf this first attempt fails, then the action is recorded in a SQLite database with a timestamp and with the parameters it needs to be able to make that call again later. Those parameters will be minimal \u2014 article IDs instead of entire Article objects, for instance.\nThe app will periodically attempt to empty this database: starting with the oldest action, it will notify the server of each. On success, a given action is removed from the database.\nUndo\nEvergreen supports undo as much as possible. For instance, if you mark a number of articles as read, you can undo it.\nIn this case, Evergreen will notify the server of the mark-read action, and then, upon undo, notify the server of a mark-unread action, thereby undoing the effect of the first action.\nIn the case where the mark-read action is in the offline action queue, that will be found and deleted, and there will be no queued action to reverse the effect.\nNon-Deferrable Actions\nActions that require an immediate response from a reachable server include actions such as adding a feed. In the case where a user attempts one of these and the server can\u2019t be reached, an error sheet will explain the problem. Such actions will not be queued.\nThere will not, however, be an error sheet for performing a refresh when the server is unreachable. Instead, in that case, a warning icon is placed next to it in the sidebar, a la Mail and similar apps. Clicking the icon will attempt a connection to the server, and an error sheet explaining the problem will appear if the server still can\u2019t be reached.\nOther Notes\nEvergreen works like Mail and similar apps in that it has a set of accounts for services such as Feedbin, Feedly, and others, along with an On My Mac account that is not synced.\nEach account has its own section in the main window\u2019s source list; each account has its own set of folders and feeds.\nAccounts will be added to Evergreen in Preferences, in an Accounts pane.\nThe policies of these accounts will be respected. For example, if the On My Mac account automatically marks articles as read after n days, it\u2019s possible that some service does this after some other number of days, or never does that at all, and Evergreen won\u2019t override those policies for that service.\nAnother example: the On My Mac account doesn\u2019t support folders-within-folders \u2014 but if a feed service does support that, then the app will support it too, for that service.\n(Current plan: Evergreen 1.0 will ship with Feedbin support, and Evergreen 2.0 will add support for more services.)\nLet me know if any of the above sounds weird or if I missed anything. (There is contact info at the bottom of Evergreen\u2019s main page.)\n\n",
"type": "entry"
},
{
"updated": "2018-01-17T17:05:58",
"name": "The Omni Show #6 with Liz Marley",
"url": "http://inessential.com/2018/01/17/the_omni_show_6_with_liz_marley",
"summary": "\nThis episode features Liz Marley, OmniGraffle engineer, formerly a tester and PM.\nShe talks about switching from testing to writing code \u2014 and about how she came to do technical talks using Swift playgrounds. Playgrounds with ducks, that is, because every good playground has ducks.\n",
"content": "\n\nThis episode features Liz Marley, OmniGraffle engineer, formerly a tester and PM.\nShe talks about switching from testing to writing code \u2014 and about how she came to do technical talks using Swift playgrounds. Playgrounds with ducks, that is, because every good playground has ducks.\n\n",
"type": "entry"
},
{
"updated": "2018-01-15T22:26:26",
"name": "Evergreen Diary #5: Send to MarsEdit",
"url": "http://inessential.com/2018/01/15/evergreen_diary_5_send_to_marsedit",
"summary": "\nThe latest build of Evergreen, fresh from the lab, now adds MarsEdit to the sharing menu in the toolbar.\nWhen you choose the command, it sends the current article to MarsEdit \u2014\u00a0which opens it in a new window, and then you can edit and add your own commentary before posting to your blog.\n* * *\nSee SendToBlogEditorApp.m for the code that packages up the article and sends an Apple event.\nThe code is not MarsEdit-specific \u2014\u00a0other apps in the past have supported this same Apple event, though I don\u2019t know if any other current apps do. If I find some, I\u2019ll add them to the sharing menu alongside MarsEdit.\n* * *\nThe Apple event code is written in Objective-C, even though I almost always write new code in Swift. But, with Apple events code, Objective-C is easier.\nIt\u2019s easy to call from Swift: see SendToMarsEditCommand.swift.\n(Reminder: this is all MIT-licensed. You can use this code.)\n",
"content": "\n\nThe latest build of Evergreen, fresh from the lab, now adds MarsEdit to the sharing menu in the toolbar.\nWhen you choose the command, it sends the current article to MarsEdit \u2014\u00a0which opens it in a new window, and then you can edit and add your own commentary before posting to your blog.\n* * *\nSee SendToBlogEditorApp.m for the code that packages up the article and sends an Apple event.\nThe code is not MarsEdit-specific \u2014\u00a0other apps in the past have supported this same Apple event, though I don\u2019t know if any other current apps do. If I find some, I\u2019ll add them to the sharing menu alongside MarsEdit.\n* * *\nThe Apple event code is written in Objective-C, even though I almost always write new code in Swift. But, with Apple events code, Objective-C is easier.\nIt\u2019s easy to call from Swift: see SendToMarsEditCommand.swift.\n(Reminder: this is all MIT-licensed. You can use this code.)\n\n",
"type": "entry"
},
{
"updated": "2018-01-15T17:35:13",
"name": "Evergreen Diary #4: Send to Micro.blog",
"url": "http://inessential.com/2018/01/15/evergreen_diary_4_send_to_micro_blog",
"summary": "\nThe latest build of Evergreen adds Micro.blog to the Share menu in the toolbar, if you have the Micro.blog Mac app.\nIt sends the title and link of whatever you\u2019re reading over to the Micro.blog Mac app, and you can edit it before actually posting.\nThis is hugely important. RSS readers exist not to just make reading easy but to make the web a conversation.\nThe next release will (probably) include MarsEdit, for the exact same reason. If you have ideas for other apps to include, let me know (see the bottom of the Evergreen site for contact info).\nIdeally, every app like Micro.blog and MarsEdit would have a sharing extension \u2014 but, where they don\u2019t, I can add them as long as they support some kind of way to do so.\nTechnical Details\nMicro.blog supports a URL scheme for sending it a post: see See SendToMicroBlogCommand.\u200bsendObject for the implementation in Evergreen. (And of course feel free to use any Evergreen code in your app.)\nHistory\nIt\u2019s not that we realized just today that posting from an RSS reader is important. Since posting was always an absolute requirement, way back in 2003 I released NetNewsWire 1.0 with an integrated blog editor.\nI got that idea from Radio UserLand, which was an RSS reader and blog editor by the company where I worked before I wrote NetNewsWire. It\u2019s Dave\u2019s idea, not mine.\nBy the time I was working on NetNewsWire 2.0, it became apparent that smooshing a blog editor into a reader app meant that the blog editor suffers. The blog editor in NetNewsWire 1.x was pretty darn bad. So I had the idea of splitting out the blog editor to a separate app \u2014\u00a0inducing mitosis \u2014\u00a0which you can read about in my MarsEdit report of late 2004.\nMitosis was a success.\nOne of the keys of that success was that the API for contacting MarsEdit had to be open, and NetNewsWire had to support any blog editor, or any other app, that supported that API \u2014\u00a0because otherwise I would have been unfairly leveraging success with NetNewsWire on behalf of my new blog editor, and that would have been wrong.\nMarsEdit still supports that interface, and my next step is to write the client side in Evergreen, so it can send to MarsEdit and any other app that supports that interface.\nI am, by the way, delighted to be writing code for a 14-year-old API that still works.\n",
"content": "\n\nThe latest build of Evergreen adds Micro.blog to the Share menu in the toolbar, if you have the Micro.blog Mac app.\nIt sends the title and link of whatever you\u2019re reading over to the Micro.blog Mac app, and you can edit it before actually posting.\nThis is hugely important. RSS readers exist not to just make reading easy but to make the web a conversation.\nThe next release will (probably) include MarsEdit, for the exact same reason. If you have ideas for other apps to include, let me know (see the bottom of the Evergreen site for contact info).\nIdeally, every app like Micro.blog and MarsEdit would have a sharing extension \u2014 but, where they don\u2019t, I can add them as long as they support some kind of way to do so.\nTechnical Details\nMicro.blog supports a URL scheme for sending it a post: see See SendToMicroBlogCommand.\u200bsendObject for the implementation in Evergreen. (And of course feel free to use any Evergreen code in your app.)\nHistory\nIt\u2019s not that we realized just today that posting from an RSS reader is important. Since posting was always an absolute requirement, way back in 2003 I released NetNewsWire 1.0 with an integrated blog editor.\nI got that idea from Radio UserLand, which was an RSS reader and blog editor by the company where I worked before I wrote NetNewsWire. It\u2019s Dave\u2019s idea, not mine.\nBy the time I was working on NetNewsWire 2.0, it became apparent that smooshing a blog editor into a reader app meant that the blog editor suffers. The blog editor in NetNewsWire 1.x was pretty darn bad. So I had the idea of splitting out the blog editor to a separate app \u2014\u00a0inducing mitosis \u2014\u00a0which you can read about in my MarsEdit report of late 2004.\nMitosis was a success.\nOne of the keys of that success was that the API for contacting MarsEdit had to be open, and NetNewsWire had to support any blog editor, or any other app, that supported that API \u2014\u00a0because otherwise I would have been unfairly leveraging success with NetNewsWire on behalf of my new blog editor, and that would have been wrong.\nMarsEdit still supports that interface, and my next step is to write the client side in Evergreen, so it can send to MarsEdit and any other app that supports that interface.\nI am, by the way, delighted to be writing code for a 14-year-old API that still works.\n\n",
"type": "entry"
},
{
"updated": "2018-01-11T21:13:41",
"name": "Mentions: Proof-of-Concept",
"url": "http://inessential.com/2018/01/11/mentions_proof-of-concept",
"summary": "\nBen Curtis posted feed_searcher to GitHub \u2014\u00a0it creates custom search feeds, and even has a handy Deploy to Heroku button. Cool.\n(This is in reference to App Idea: Mentions).\n",
"content": "\n\nBen Curtis posted feed_searcher to GitHub \u2014\u00a0it creates custom search feeds, and even has a handy Deploy to Heroku button. Cool.\n(This is in reference to App Idea: Mentions).\n\n",
"type": "entry"
},
{
"updated": "2018-01-11T21:09:35",
"name": "App Idea: Inside Story",
"url": "http://inessential.com/2018/01/11/app_idea_inside_story",
"summary": "\nI had this idea around the time Apple came out with Bonjour (n\u00e9e Rendezvous), and all these years later I realize I\u2019m never going to get around to it.\nHere\u2019s the scoop:\nThe idea is microblog posts (tweet-like) but that live inside a specific network only.\nYou run a Mac app that:\n\nLets you post short messages.\nShows short messages from people inside your network.\n\nThe app runs a small webserver that\u2019s discoverable via Bonjour, that has a specific service name. That webserver publishes a feed of your posts.\nThe app also downloads a feed from every other app it finds (and caches those feeds, for when other apps are offline).\nIn other words, it\u2019s instant office microblogging with no centralized server. Completely peer-to-peer.\nThe design is what you expect \u2014\u00a0a reverse-chronological list of posts with usernames and avatars. You can reply, mention people, mute people, etc. (I think you\u2019d follow everybody on the network automatically \u2014 so muting becomes the thing, not following.)\n* * *\nImportant thing: your posts are network-specific. So if you go to a coffee shop or the airport with your Mac, you won\u2019t be publishing your at-the-office posts.\n* * *\nI haven\u2019t done research into whether this is do-able on iOS. Is it possible to run a little webserver, in a backgrounded app, that other people on the local network could connect to? Seems unlikely \u2014\u00a0but I don\u2019t know. Cool if you could.\n* * *\nI have no idea how you\u2019d make money with this one. If you charge for it, not enough people would use it to make it worthwhile. (The standard dilemma of social networking apps.)\nMaybe, though, you could add some IAP features? One might be to let people add RSS feeds, so it could also function as a lightweight RSS reader. A person might want posts from Daring Fireball and wherever else added to their timeline.\nOr just add that feature anyway, and do the whole thing for fun.\nPS \u201cInside Story\u201d is a long name. Should be one word. Scoops? Bulletins? Officecast? Gossip? (\u201cGossip\u201d was, if memory serves, the name of an app Chuck Shotton was working on a long time ago. Probably reusable at this point.)\n(I mean, c\u2019mon, office Gossip. It\u2019s so perfect.)\n",
"content": "\n\nI had this idea around the time Apple came out with Bonjour (n\u00e9e Rendezvous), and all these years later I realize I\u2019m never going to get around to it.\nHere\u2019s the scoop:\nThe idea is microblog posts (tweet-like) but that live inside a specific network only.\nYou run a Mac app that:\n\nLets you post short messages.\nShows short messages from people inside your network.\n\nThe app runs a small webserver that\u2019s discoverable via Bonjour, that has a specific service name. That webserver publishes a feed of your posts.\nThe app also downloads a feed from every other app it finds (and caches those feeds, for when other apps are offline).\nIn other words, it\u2019s instant office microblogging with no centralized server. Completely peer-to-peer.\nThe design is what you expect \u2014\u00a0a reverse-chronological list of posts with usernames and avatars. You can reply, mention people, mute people, etc. (I think you\u2019d follow everybody on the network automatically \u2014 so muting becomes the thing, not following.)\n* * *\nImportant thing: your posts are network-specific. So if you go to a coffee shop or the airport with your Mac, you won\u2019t be publishing your at-the-office posts.\n* * *\nI haven\u2019t done research into whether this is do-able on iOS. Is it possible to run a little webserver, in a backgrounded app, that other people on the local network could connect to? Seems unlikely \u2014\u00a0but I don\u2019t know. Cool if you could.\n* * *\nI have no idea how you\u2019d make money with this one. If you charge for it, not enough people would use it to make it worthwhile. (The standard dilemma of social networking apps.)\nMaybe, though, you could add some IAP features? One might be to let people add RSS feeds, so it could also function as a lightweight RSS reader. A person might want posts from Daring Fireball and wherever else added to their timeline.\nOr just add that feature anyway, and do the whole thing for fun.\nPS \u201cInside Story\u201d is a long name. Should be one word. Scoops? Bulletins? Officecast? Gossip? (\u201cGossip\u201d was, if memory serves, the name of an app Chuck Shotton was working on a long time ago. Probably reusable at this point.)\n(I mean, c\u2019mon, office Gossip. It\u2019s so perfect.)\n\n",
"type": "entry"
},
{
"updated": "2018-01-09T21:33:23",
"name": "App Idea: Mentions",
"url": "http://inessential.com/2018/01/09/app_idea_mentions",
"summary": "\n\u201cHold on \u2014 I need to check my Mentions.\u201d\nTen years ago or more we had several blog-specific search engines and services: Technorati, BlogBridge, and others.\nOne of the great things about these services was not just being able to search for something but being able to set up persistent searches: that is, you\u2019d get a search as an RSS feed, and in your feed reader you\u2019d get results from all over the place on the thing you\u2019re searching for.\nIn the obvious and common cases, you\u2019d set up searches for people linking to your blog, writing about the apps you work on, mentioning the place where you work, and mentioning you.\nI\u2019d like to see something like this for today, but where the scope is just the Apple/Mac/iOS community. It would crawl the obvious sites (such as Daring Fireball and Loop Insight) and it would crawl the many blogs and microblogs that make up the community.\nI think this is best as a web service, though it could have Mac and/or iOS client apps. It needs to provide feeds for people using feed readers.\n* * *\nWith that reduced scope, and with the better tools and cheaper cloud computing these days, I don\u2019t think it would be terribly expensive. Not like it was 15 years ago.\nYou might want to make money with this, though, and there are a few ways to do it: charge extra for things like notifications and email alerts. Charge money for client apps. Make the first three search feeds free, and charge money for a ten-pack of searches. Etc.\n* * *\nAn alternate version of this idea isn\u2019t a web service \u2014 it\u2019s a Mac and/or iOS app that does the crawling. A kind of specialized Mac/iOS feed reader.\nThe list of feeds-to-crawl would probably just be an OPML file on the web, and the app would periodically grab that list.\n(If you did this, you could use RSParser as starter code, since it parses OPML, RSS, Atom, JSON Feed, and RSS-in-JSON.)\nThis would make a great open source project, but it could just as well be free or for-pay.\n* * *\nOne challenge is handling spam and abusive or hateful content. You\u2019d most likely want to have a suggest-a-site form, so you don\u2019t have to go out and find every single site there is.\nBut you have to be able to say no, and you have to be able to update the list of sites-to-crawl quickly if a site turns bad or inappropriate somehow.\nYou\u2019d also need a way for users to report an issue.\n(Again, the reduced scope \u2014\u00a0Apple-related blogs \u2014\u00a0makes this somewhat easier than if you tried to do the entire blogosphere.)\n* * *\nI want this! I\u2019d use it every day. I know other people who would too.\nBut I\u2019ve got enough on my plate that there\u2019s no way I can do it myself \u2014\u00a0though I\u2019d be happy to answer questions and provide feedback to anyone who does want to do it.\n",
"content": "\n\n\u201cHold on \u2014 I need to check my Mentions.\u201d\nTen years ago or more we had several blog-specific search engines and services: Technorati, BlogBridge, and others.\nOne of the great things about these services was not just being able to search for something but being able to set up persistent searches: that is, you\u2019d get a search as an RSS feed, and in your feed reader you\u2019d get results from all over the place on the thing you\u2019re searching for.\nIn the obvious and common cases, you\u2019d set up searches for people linking to your blog, writing about the apps you work on, mentioning the place where you work, and mentioning you.\nI\u2019d like to see something like this for today, but where the scope is just the Apple/Mac/iOS community. It would crawl the obvious sites (such as Daring Fireball and Loop Insight) and it would crawl the many blogs and microblogs that make up the community.\nI think this is best as a web service, though it could have Mac and/or iOS client apps. It needs to provide feeds for people using feed readers.\n* * *\nWith that reduced scope, and with the better tools and cheaper cloud computing these days, I don\u2019t think it would be terribly expensive. Not like it was 15 years ago.\nYou might want to make money with this, though, and there are a few ways to do it: charge extra for things like notifications and email alerts. Charge money for client apps. Make the first three search feeds free, and charge money for a ten-pack of searches. Etc.\n* * *\nAn alternate version of this idea isn\u2019t a web service \u2014 it\u2019s a Mac and/or iOS app that does the crawling. A kind of specialized Mac/iOS feed reader.\nThe list of feeds-to-crawl would probably just be an OPML file on the web, and the app would periodically grab that list.\n(If you did this, you could use RSParser as starter code, since it parses OPML, RSS, Atom, JSON Feed, and RSS-in-JSON.)\nThis would make a great open source project, but it could just as well be free or for-pay.\n* * *\nOne challenge is handling spam and abusive or hateful content. You\u2019d most likely want to have a suggest-a-site form, so you don\u2019t have to go out and find every single site there is.\nBut you have to be able to say no, and you have to be able to update the list of sites-to-crawl quickly if a site turns bad or inappropriate somehow.\nYou\u2019d also need a way for users to report an issue.\n(Again, the reduced scope \u2014\u00a0Apple-related blogs \u2014\u00a0makes this somewhat easier than if you tried to do the entire blogosphere.)\n* * *\nI want this! I\u2019d use it every day. I know other people who would too.\nBut I\u2019ve got enough on my plate that there\u2019s no way I can do it myself \u2014\u00a0though I\u2019d be happy to answer questions and provide feedback to anyone who does want to do it.\n\n",
"type": "entry"
},
{
"updated": "2018-01-06T21:10:23",
"name": "Evergreen Diary #3: On Punting",
"url": "http://inessential.com/2018/01/06/evergreen_diary_3_on_punting",
"summary": "\nI have a vision for 1.0, and then, as time goes on, I have to cut it back beyond where it hurts. I have to keep punting. I hate this part of shipping software.\nBut I also love it because it reminds me that I have the stomach for it. Shipping software is an emotional skill.\nAfter shipping \u2014\u00a0no matter what \u2014 there will be people who absolutely cannot believe that feature X wasn\u2019t included. In fact, it\u2019s the one thing they totally need.\nAnd they\u2019re right. Not wrong. And I would have loved to have included feature X, loved I not quality (the app maker\u2019s honor) more.\n* * *\nI wondered if Evergreen as open source instead of as a for-pay app would affect what and how much I punt. I hope the answer is: not at all; the decisions would have been the same.\nI think that\u2019s right because I\u2019m trying to make as good an app as I can, which would be true regardless.\nBut it is nice not to have to consider money as I make decisions. I do think about how I want it to have as many users as possible, and I want people to love the app. And I have to think about the economy of my time. But I don\u2019t have to consider money.\nAnother difference between open source and commercial is that I can be utterly transparent about what\u2019s been punted. Check out Evergreen\u2019s 2.0 milestone. It will keep growing. Every single one of those things was originally supposed to go in 1.0.\n* * *\nSome things I keep reminding myself as I make progress toward 1.0\u2026\nThis isn\u2019t the last release, it\u2019s the first. There will be many more. (I hope to work on this app for 20 years. It\u2019s been only three years so far.)\nAny feature I ship, I probably have to support forever. So it\u2019s wise to be cautious.\nQuality \u2014\u00a0design, stability, performance, lack of bugs \u2014 is way more important than any collection of features.\nAnd, perhaps most importantly: shipping 1.0 means learning about your users, how they use your app, and what they need \u2014\u00a0and those lessons will change future plans, as they should. It\u2019s best to learn those lessons early, before doing too much.\n",
"content": "\n\nI have a vision for 1.0, and then, as time goes on, I have to cut it back beyond where it hurts. I have to keep punting. I hate this part of shipping software.\nBut I also love it because it reminds me that I have the stomach for it. Shipping software is an emotional skill.\nAfter shipping \u2014\u00a0no matter what \u2014 there will be people who absolutely cannot believe that feature X wasn\u2019t included. In fact, it\u2019s the one thing they totally need.\nAnd they\u2019re right. Not wrong. And I would have loved to have included feature X, loved I not quality (the app maker\u2019s honor) more.\n* * *\nI wondered if Evergreen as open source instead of as a for-pay app would affect what and how much I punt. I hope the answer is: not at all; the decisions would have been the same.\nI think that\u2019s right because I\u2019m trying to make as good an app as I can, which would be true regardless.\nBut it is nice not to have to consider money as I make decisions. I do think about how I want it to have as many users as possible, and I want people to love the app. And I have to think about the economy of my time. But I don\u2019t have to consider money.\nAnother difference between open source and commercial is that I can be utterly transparent about what\u2019s been punted. Check out Evergreen\u2019s 2.0 milestone. It will keep growing. Every single one of those things was originally supposed to go in 1.0.\n* * *\nSome things I keep reminding myself as I make progress toward 1.0\u2026\nThis isn\u2019t the last release, it\u2019s the first. There will be many more. (I hope to work on this app for 20 years. It\u2019s been only three years so far.)\nAny feature I ship, I probably have to support forever. So it\u2019s wise to be cautious.\nQuality \u2014\u00a0design, stability, performance, lack of bugs \u2014 is way more important than any collection of features.\nAnd, perhaps most importantly: shipping 1.0 means learning about your users, how they use your app, and what they need \u2014\u00a0and those lessons will change future plans, as they should. It\u2019s best to learn those lessons early, before doing too much.\n\n",
"type": "entry"
},
{
"updated": "2018-01-03T16:40:02",
"name": "The Omni Show #5 with Mark Boszko",
"url": "http://inessential.com/2018/01/03/the_omni_show_5_with_mark_boszko",
"summary": "\nIn this episode I finally get around to talking to Mark Boszko, the show\u2019s intrepid producer and The Omni Group\u2019s Video Producer.\nI\u2019ve known Mark for more than ten years \u2014 we met at a SXSW conference many years ago, long before either of us came to Omni. Mark didn\u2019t even live in Seattle in those days. Now he does, and now we have the pleasure of working together on a podcast.\nPS If you like movies, definitely check out the podcast Mark hosts: The Optical.\n",
"content": "\n\nIn this episode I finally get around to talking to Mark Boszko, the show\u2019s intrepid producer and The Omni Group\u2019s Video Producer.\nI\u2019ve known Mark for more than ten years \u2014 we met at a SXSW conference many years ago, long before either of us came to Omni. Mark didn\u2019t even live in Seattle in those days. Now he does, and now we have the pleasure of working together on a podcast.\nPS If you like movies, definitely check out the podcast Mark hosts: The Optical.\n\n",
"type": "entry"
},
{
"updated": "2018-01-03T14:29:03",
"name": "2018: Some Hope",
"url": "http://inessential.com/2018/01/03/2018_some_hope",
"summary": "\nMike Monteiro writes of Twitter CEO Jack Dorsey:\nJack let it happen. He watched as a once-entertaining, once-illuminating, once-vital network to global communication became a garbage fire of hate. He did nothing to stop it. Or curb it. He didn\u2019t see a problem.\nOur current crises of democracy and good faith did not just blow in with the wind and transform the air without our knowledge or consent.\nThese crises were made by people, and we knew what they were doing, and we agreed to this.\nJack Dorsey is one of those many people. Just one. But one with a kind of power that nobody in the world should have: the power to directly control a vast amount of the world\u2019s communication.\nIt\u2019s not that Dorsey failed to consider the good of the world. Or, really, it\u2019s not just that. It\u2019s that this kind of power should not exist at all.\nBut we agreed to it. We\u2019re still agreeing to it.\nTwitter \u2014\u00a0and Facebook, and the power of tech companies\u00a0\u2014\u00a0is not our only problem.\nBut I have no doubt that had Twitter not become a loving home for hate, Trump would not be President now. In that universe we\u2019d still have big problems, yes, but not like this.\nHow we can stop agreeing to this\nThe great social network is, or ought to be, the web itself.\nThe unruly web \u2014\u00a0unregulated and uncontrolled \u2014 is, perhaps paradoxically, the easiest place to limit hate. Not because we can stop people from publishing, but because we don\u2019t have to live by Dorsey\u2019s and Zuckerberg\u2019s rules and designs.\nI don\u2019t know all the details of how we get there, or what it will be like once we do. That\u2019s fine: that\u2019s part of what makes the journey fun.\nSoftware\nConsider a few apps.\nOvercast and Castro and others help ensure that podcasting is not just a vital and exciting medium of independent publishing but is also open and built on standards. Anybody can write any kind of podcasting software they want to \u2014\u00a0but nobody can control podcasting.\nAnd nobody can force you to listen to hate. You pick the shows you want to hear.\nMarsEdit lets you write whatever you want to write and publish it on the web. You\u2019re limited only by the law and whatever terms of service your hosting provider may have.\nAll the words you read in MarsEdit are your own. And nobody can make you read what other MarsEdit users write.\nEvergreen (which I\u2019m working on), NetNewsWire, Reeder, Unread and other RSS readers work like Overcast and Castro but for written words. You choose what to read, and if a blogger you like suddenly turns hateful, you hit the Delete key.\nThen there\u2019s Manton\u2019s new service, which needs its own section\u2026\nMicro.blog\nIt\u2019s a publishing platform and a social network, based on standards.\nYou don\u2019t even have to use Manton\u2019s Mac or iOS apps: you can write posts in MarsEdit or other blog editor, or read your timeline using an RSS reader.\nPeople could, though, sign up for it and flood your mentions with hate. In theory. So I asked Manton about that, and he wrote:\nMicro.blog is similar to MarsEdit in a way in that it can be used to write hateful posts, etc. What we have to do as a social network is limit the damage. So, by default, if someone writes something terrible\u2026 No one sees it. It doesn\u2019t automatically show up in trends (because we don\u2019t have them, for this reason) and it doesn\u2019t show up in Discover (because that\u2019s curated by a human). Replies are where it\u2019s an issue, and that\u2019s where good tools and automatic flagging and reporting are needed.\nIn other words: the rules are different, and the easy exploits on Twitter are not so easy on Micro.blog. And there\u2019s an actual committment to fighting this.\nManton also writes on his blog:\nImagine instead a service based on blogs, where the internal posts on the platform were the same format as the external posts. The curators of the platform would have more freedom to block harassing posts and ban nazis because those problematic users could always retreat to their own web site and leave everyone else in the community alone.\nThat\u2019s how the web is supposed to work. It\u2019s a core principle of Micro.blog.\n(I\u2019m @brentsimmons on Micro.blog, by the way. Here\u2019s my microblog. I plan to post there more often than on Twitter in 2018.)\nI should also mention\u2026\nSlack\nI\u2019m not sure where to put Slack in all this \u2014\u00a0except to say that admins control who\u2019s in their groups, and I\u2019ve never seen hate and harrassment there. I run a few groups, and I would have zero tolerance for this, and so would everybody I know who runs groups.\nWell. One more thing about Slack: it meets some of the needs that Twitter used to meet. The talking-with-friends-and-family needs are very well covered there.\nAnd the more we find ways outside of Twitter and Facebook to meet those needs, the less we\u2019ll use Twitter and Facebook.\nMaybe, back in 2012, Twitter did five important things for you that only Twitter did. I bet, in 2018, that that\u2019s down to one or two.\nFun\nThe period from 1995-2008 (roughly speaking) was fun. It seemed like everybody was coming up with new things, and people were experimenting, and we were finding new joys in new connections, both human and technological.\nThen, as Facebook and Twitter (and Google Reader; can\u2019t forget that thing) grew, it\u2019s as if we froze.\nAnd those things were fun for a while, but they\u2019re not now, and it\u2019s obvious we made a mistake in allowing that much power to concentrate.\nIt\u2019s time for the thaw: it\u2019s time to get back to having fun. You\u2019re free to make whatever you want.\nWhat I\u2019m Not Saying\nRebuilding the social open web is not the one cure that we need for all our ills. I\u2019m fully skeptical of technological solutions to problems of culture and politics.\nBut it is an important thing we can and should do.\nMy small hope for 2018 is the knowledge that I\u2019m not the only person thinking that way.\nRelated Reading\nMe in 2011: What we talk about when we talk about RSS\nMe in 2013: Why I love RSS and You Do Too\nAnil Dash in 2012: The Web We Lost and Rebuilding the Web We Lost\nIndieWeb is\u00a0a thing I need to learn more about.\nTantek \u00c7elik (video) - The once and future IndieWeb\n",
"content": "\n\nMike Monteiro writes of Twitter CEO Jack Dorsey:\nJack let it happen. He watched as a once-entertaining, once-illuminating, once-vital network to global communication became a garbage fire of hate. He did nothing to stop it. Or curb it. He didn\u2019t see a problem.\nOur current crises of democracy and good faith did not just blow in with the wind and transform the air without our knowledge or consent.\nThese crises were made by people, and we knew what they were doing, and we agreed to this.\nJack Dorsey is one of those many people. Just one. But one with a kind of power that nobody in the world should have: the power to directly control a vast amount of the world\u2019s communication.\nIt\u2019s not that Dorsey failed to consider the good of the world. Or, really, it\u2019s not just that. It\u2019s that this kind of power should not exist at all.\nBut we agreed to it. We\u2019re still agreeing to it.\nTwitter \u2014\u00a0and Facebook, and the power of tech companies\u00a0\u2014\u00a0is not our only problem.\nBut I have no doubt that had Twitter not become a loving home for hate, Trump would not be President now. In that universe we\u2019d still have big problems, yes, but not like this.\nHow we can stop agreeing to this\nThe great social network is, or ought to be, the web itself.\nThe unruly web \u2014\u00a0unregulated and uncontrolled \u2014 is, perhaps paradoxically, the easiest place to limit hate. Not because we can stop people from publishing, but because we don\u2019t have to live by Dorsey\u2019s and Zuckerberg\u2019s rules and designs.\nI don\u2019t know all the details of how we get there, or what it will be like once we do. That\u2019s fine: that\u2019s part of what makes the journey fun.\nSoftware\nConsider a few apps.\nOvercast and Castro and others help ensure that podcasting is not just a vital and exciting medium of independent publishing but is also open and built on standards. Anybody can write any kind of podcasting software they want to \u2014\u00a0but nobody can control podcasting.\nAnd nobody can force you to listen to hate. You pick the shows you want to hear.\nMarsEdit lets you write whatever you want to write and publish it on the web. You\u2019re limited only by the law and whatever terms of service your hosting provider may have.\nAll the words you read in MarsEdit are your own. And nobody can make you read what other MarsEdit users write.\nEvergreen (which I\u2019m working on), NetNewsWire, Reeder, Unread and other RSS readers work like Overcast and Castro but for written words. You choose what to read, and if a blogger you like suddenly turns hateful, you hit the Delete key.\nThen there\u2019s Manton\u2019s new service, which needs its own section\u2026\nMicro.blog\nIt\u2019s a publishing platform and a social network, based on standards.\nYou don\u2019t even have to use Manton\u2019s Mac or iOS apps: you can write posts in MarsEdit or other blog editor, or read your timeline using an RSS reader.\nPeople could, though, sign up for it and flood your mentions with hate. In theory. So I asked Manton about that, and he wrote:\nMicro.blog is similar to MarsEdit in a way in that it can be used to write hateful posts, etc. What we have to do as a social network is limit the damage. So, by default, if someone writes something terrible\u2026 No one sees it. It doesn\u2019t automatically show up in trends (because we don\u2019t have them, for this reason) and it doesn\u2019t show up in Discover (because that\u2019s curated by a human). Replies are where it\u2019s an issue, and that\u2019s where good tools and automatic flagging and reporting are needed.\nIn other words: the rules are different, and the easy exploits on Twitter are not so easy on Micro.blog. And there\u2019s an actual committment to fighting this.\nManton also writes on his blog:\nImagine instead a service based on blogs, where the internal posts on the platform were the same format as the external posts. The curators of the platform would have more freedom to block harassing posts and ban nazis because those problematic users could always retreat to their own web site and leave everyone else in the community alone.\nThat\u2019s how the web is supposed to work. It\u2019s a core principle of Micro.blog.\n(I\u2019m @brentsimmons on Micro.blog, by the way. Here\u2019s my microblog. I plan to post there more often than on Twitter in 2018.)\nI should also mention\u2026\nSlack\nI\u2019m not sure where to put Slack in all this \u2014\u00a0except to say that admins control who\u2019s in their groups, and I\u2019ve never seen hate and harrassment there. I run a few groups, and I would have zero tolerance for this, and so would everybody I know who runs groups.\nWell. One more thing about Slack: it meets some of the needs that Twitter used to meet. The talking-with-friends-and-family needs are very well covered there.\nAnd the more we find ways outside of Twitter and Facebook to meet those needs, the less we\u2019ll use Twitter and Facebook.\nMaybe, back in 2012, Twitter did five important things for you that only Twitter did. I bet, in 2018, that that\u2019s down to one or two.\nFun\nThe period from 1995-2008 (roughly speaking) was fun. It seemed like everybody was coming up with new things, and people were experimenting, and we were finding new joys in new connections, both human and technological.\nThen, as Facebook and Twitter (and Google Reader; can\u2019t forget that thing) grew, it\u2019s as if we froze.\nAnd those things were fun for a while, but they\u2019re not now, and it\u2019s obvious we made a mistake in allowing that much power to concentrate.\nIt\u2019s time for the thaw: it\u2019s time to get back to having fun. You\u2019re free to make whatever you want.\nWhat I\u2019m Not Saying\nRebuilding the social open web is not the one cure that we need for all our ills. I\u2019m fully skeptical of technological solutions to problems of culture and politics.\nBut it is an important thing we can and should do.\nMy small hope for 2018 is the knowledge that I\u2019m not the only person thinking that way.\nRelated Reading\nMe in 2011: What we talk about when we talk about RSS\nMe in 2013: Why I love RSS and You Do Too\nAnil Dash in 2012: The Web We Lost and Rebuilding the Web We Lost\nIndieWeb is\u00a0a thing I need to learn more about.\nTantek \u00c7elik (video) - The once and future IndieWeb\n\n",
"type": "entry"
},
{
"updated": "2017-12-27T02:10:09",
"name": "Evergreen\u2019s Parser as Separate Open Source Framework",
"url": "http://inessential.com/2017/12/26/evergreens_parser_as_separate_open_sour",
"summary": "\nI copied Evergreen\u2019s parsing framework, RSParser, to a separate repository on GitHub.\nIt has no dependencies other than system-supplied libraries. It\u2019s offered via the MIT License.\nIt builds a Mac framework only at the moment, but adding an iOS target should be easy. It\u2019s the one issue in the bug tracker (at least so far).\nOtherwise it\u2019s fast and stable and does the jobs it\u2019s designed to do.\nThings it parses\n\nRSS\nAtom\nJSON Feed\nRSS-in-JSON\nOPML\nInternet dates\nHTML metadata\nHTML links\n\nIn addition, you can build your own XML or HTML parser by creating an RSSAXParserDelegate or RSSAXHTMLParserDelegate.\nIt\u2019s a mix of Objective-C and Swift. More recent code is in Swift.\nParsing a feed that\u2019s RSS, Atom, JSON Feed, or RSS-in-JSON is a matter of calling FeedParser.parse and getting back a ParsedFeed object. Pretty simple.\n",
"content": "\n\nI copied Evergreen\u2019s parsing framework, RSParser, to a separate repository on GitHub.\nIt has no dependencies other than system-supplied libraries. It\u2019s offered via the MIT License.\nIt builds a Mac framework only at the moment, but adding an iOS target should be easy. It\u2019s the one issue in the bug tracker (at least so far).\nOtherwise it\u2019s fast and stable and does the jobs it\u2019s designed to do.\nThings it parses\n\nRSS\nAtom\nJSON Feed\nRSS-in-JSON\nOPML\nInternet dates\nHTML metadata\nHTML links\n\nIn addition, you can build your own XML or HTML parser by creating an RSSAXParserDelegate or RSSAXHTMLParserDelegate.\nIt\u2019s a mix of Objective-C and Swift. More recent code is in Swift.\nParsing a feed that\u2019s RSS, Atom, JSON Feed, or RSS-in-JSON is a matter of calling FeedParser.parse and getting back a ParsedFeed object. Pretty simple.\n\n",
"type": "entry"
},
{
"updated": "2017-12-20T23:23:35",
"name": "WKWebView Workarounds",
"url": "http://inessential.com/2017/12/20/wkwebview_workarounds",
"summary": "\nIn Evergreen I\u2019m using WKWebView instead of WebView, because it\u2019s the new and improved WebKit view. NSHipster writes:\nBoasting responsive 60fps scrolling, built-in gestures, streamlined communication between app and webpage, and the same JavaScript engine as Safari, WKWebView is one of the most significant announcements to come out of WWDC 2014.\nSounds great! I\u2019m on board.\nOne of the best parts about it \u2014\u00a0easily enough to sell me \u2014\u00a0is that a crash in WKWebView won\u2019t crash my app.\n(Back when I was doing NetNewsWire, crashes in the old WebView \u2014\u00a0the predecessor to WKWebView \u2014 were the most common crash. But, to be fair, many if not most of those were actually Flash crashes.)\nI\u2019ve also heard, though I\u2019m not sure how to verify, that WKWebView is better for accessibility, too. So it\u2019s a win all around.\nBut it\u2019s not a win all around\nWebView \u2014 good \u2019ol trusty friend \u2014 has a bunch of things that WKWebView is missing.\nThe new web view has no built-in support for finding text, for instance. I\u2019m not sure what I\u2019m going to do about this, since the ability to hit cmd-F and look for some text is a pretty fundamental thing, and I can\u2019t skip it.\nIt also has no delegate method for when you mouse over a link. Seems like another fundamental thing, right? Any browser offers you a status bar or some way to see the URL of the link your mouse is over.\nWhat I ended up doing there: my article renderer adds some JavaScript that adds event listeners. (See ArticleRenderer in the renderedHTML() method.) Then I added handlers in DetailViewController: see viewDidLoad and the WKScriptMessageHandler extension.\nThis worked fine: now my status bar shows the URL of the link your mouse is over. Cool.\nThen the issue of scrolling came up\nEvergreen\u2019s design includes a key feature: you can go through all of your news just by hitting the space bar repeatedly.\nIf there\u2019s more to scroll in the web view (the article), it scrolls. If not, then it goes to the next unread article.\nThis is a coffee-in-hand feature, which is critical for a news reader.\nBut WKWebView provides no access to its scroll view. (It does on iOS, yes, but not on Macs.)\nThe logic goes like this:\nif canScrollDown()\n scrollDown()\nelse\n goToNextUnread()\n\nThere are two parts to this, and both (I thought) required access to the scroll view.\ncanScrollDown()\nWell\u2026 JavaScript comes to the rescue again, just as with the mouseover-link handling. I can run a script in the app and get the results \u2014\u00a0and JavaScript can tell me the content height and the current amount of scrolling. (I already know the frame size, but I could have gotten that via JavaScript also.)\nI did this an DetailViewController, in the fetchScrollInfo method.\n(Unfortunately, this is asynchronous. I expect it to be super-fast, but I won\u2019t know if this is a problem without a bunch of testing. Let\u2019s set that issue aside.)\nThe fetchScrollInfo method creates a ScrollInfo struct (at the bottom of DetailViewController) that has canScrollDown and canScrollUp properties.\nSo that\u2019s how I know if the web view can scroll. Part one of two solved.\nscrollDown()\nI tried making it scroll via JavaScript. It\u2019s super-easy. But it\u2019s not animated, and it needs to be. (In Safari, with a scrollable page, hit the space bar \u2014\u00a0notice how it animates.)\nSo I did some research and found some JavaScript utilities, some needing JQuery, for animated scrolling.\nBut do I really want to add that much JavaScript on every single article load? No way. And will their animation match the animation users expect? I strongly suspect it would be noticeably different.\n(I write Mac apps. \u201cNoticeably different\u201d is the kiss of death.)\nSo I did some nerd-sniping, on Twitter and Slack, to see if anybody had a suggestion that would work.\nPeople had ideas. Nothing worked.\nTwist ending\nSo I\u2019m frustrated, and I\u2019m just about to switch back to my old friendly friend WebView, because I know it will do what I want.\nThe voice of another old friend \u2014 the guy who mentored me in my early days as a programmer \u2014 came into my head, as it often does in these situations.\n\u201cWhat is the real problem you\u2019re trying to solve?\u201d asks Dave Winer, in my head.\nThe real problem is not arbitrary animated scrolling. The real problem is that I want to do a page-down exactly the same way it would work if the WKWebView had focus and you hit the space bar. Exactly the same animation and scroll distance.\nBut not arbitrary scrolling: just a page-down.\nSo I think maybe I can spy on the event stream; maybe I can figure it out by seeing what happens when I click in the web view and hit the space bar. Maybe I can post an event that will do the job.\nTo do so I make an NSApplication subclass, which I do (in Swift, of course), and break on sendEvent.\nBut of course this doesn\u2019t work. The app crashes immediately saying it can\u2019t find the EvergreenApplication class. (Which is right there! Dude!)\nWhatever.\nOkay, maybe it\u2019s back to WebView after all. Forget WKWebView.\nThen I do a search in Xcode on pagedown, just out of a last gasp of trying \u2014 and, forgotten long ago by me, but look: there is a scrollPageDown method in NSResponder \u2014\u00a0and WKWebView is an NSView subclass which is an NSResponder subclass \u2014 so, could it be? maybe? it might work?\nI tried it: sure enough! It works! With animation and everything. It\u2019s perfect.\n* * *\nSo, in the end, the action method is in MainWindowController \u2014 see scrollOrGoToNextUnread.\n(It\u2019s a little weird due to the async thing I mentioned earlier. But it does the job.)\nAnd now \u2014\u00a0after three years of working on this app \u2014\u00a0I was finally able to go through all my news just by hitting the space bar. Big day for me.\n",
"content": "\n\nIn Evergreen I\u2019m using WKWebView instead of WebView, because it\u2019s the new and improved WebKit view. NSHipster writes:\nBoasting responsive 60fps scrolling, built-in gestures, streamlined communication between app and webpage, and the same JavaScript engine as Safari, WKWebView is one of the most significant announcements to come out of WWDC 2014.\nSounds great! I\u2019m on board.\nOne of the best parts about it \u2014\u00a0easily enough to sell me \u2014\u00a0is that a crash in WKWebView won\u2019t crash my app.\n(Back when I was doing NetNewsWire, crashes in the old WebView \u2014\u00a0the predecessor to WKWebView \u2014 were the most common crash. But, to be fair, many if not most of those were actually Flash crashes.)\nI\u2019ve also heard, though I\u2019m not sure how to verify, that WKWebView is better for accessibility, too. So it\u2019s a win all around.\nBut it\u2019s not a win all around\nWebView \u2014 good \u2019ol trusty friend \u2014 has a bunch of things that WKWebView is missing.\nThe new web view has no built-in support for finding text, for instance. I\u2019m not sure what I\u2019m going to do about this, since the ability to hit cmd-F and look for some text is a pretty fundamental thing, and I can\u2019t skip it.\nIt also has no delegate method for when you mouse over a link. Seems like another fundamental thing, right? Any browser offers you a status bar or some way to see the URL of the link your mouse is over.\nWhat I ended up doing there: my article renderer adds some JavaScript that adds event listeners. (See ArticleRenderer in the renderedHTML() method.) Then I added handlers in DetailViewController: see viewDidLoad and the WKScriptMessageHandler extension.\nThis worked fine: now my status bar shows the URL of the link your mouse is over. Cool.\nThen the issue of scrolling came up\nEvergreen\u2019s design includes a key feature: you can go through all of your news just by hitting the space bar repeatedly.\nIf there\u2019s more to scroll in the web view (the article), it scrolls. If not, then it goes to the next unread article.\nThis is a coffee-in-hand feature, which is critical for a news reader.\nBut WKWebView provides no access to its scroll view. (It does on iOS, yes, but not on Macs.)\nThe logic goes like this:\nif canScrollDown()\n scrollDown()\nelse\n goToNextUnread()\n\nThere are two parts to this, and both (I thought) required access to the scroll view.\ncanScrollDown()\nWell\u2026 JavaScript comes to the rescue again, just as with the mouseover-link handling. I can run a script in the app and get the results \u2014\u00a0and JavaScript can tell me the content height and the current amount of scrolling. (I already know the frame size, but I could have gotten that via JavaScript also.)\nI did this an DetailViewController, in the fetchScrollInfo method.\n(Unfortunately, this is asynchronous. I expect it to be super-fast, but I won\u2019t know if this is a problem without a bunch of testing. Let\u2019s set that issue aside.)\nThe fetchScrollInfo method creates a ScrollInfo struct (at the bottom of DetailViewController) that has canScrollDown and canScrollUp properties.\nSo that\u2019s how I know if the web view can scroll. Part one of two solved.\nscrollDown()\nI tried making it scroll via JavaScript. It\u2019s super-easy. But it\u2019s not animated, and it needs to be. (In Safari, with a scrollable page, hit the space bar \u2014\u00a0notice how it animates.)\nSo I did some research and found some JavaScript utilities, some needing JQuery, for animated scrolling.\nBut do I really want to add that much JavaScript on every single article load? No way. And will their animation match the animation users expect? I strongly suspect it would be noticeably different.\n(I write Mac apps. \u201cNoticeably different\u201d is the kiss of death.)\nSo I did some nerd-sniping, on Twitter and Slack, to see if anybody had a suggestion that would work.\nPeople had ideas. Nothing worked.\nTwist ending\nSo I\u2019m frustrated, and I\u2019m just about to switch back to my old friendly friend WebView, because I know it will do what I want.\nThe voice of another old friend \u2014 the guy who mentored me in my early days as a programmer \u2014 came into my head, as it often does in these situations.\n\u201cWhat is the real problem you\u2019re trying to solve?\u201d asks Dave Winer, in my head.\nThe real problem is not arbitrary animated scrolling. The real problem is that I want to do a page-down exactly the same way it would work if the WKWebView had focus and you hit the space bar. Exactly the same animation and scroll distance.\nBut not arbitrary scrolling: just a page-down.\nSo I think maybe I can spy on the event stream; maybe I can figure it out by seeing what happens when I click in the web view and hit the space bar. Maybe I can post an event that will do the job.\nTo do so I make an NSApplication subclass, which I do (in Swift, of course), and break on sendEvent.\nBut of course this doesn\u2019t work. The app crashes immediately saying it can\u2019t find the EvergreenApplication class. (Which is right there! Dude!)\nWhatever.\nOkay, maybe it\u2019s back to WebView after all. Forget WKWebView.\nThen I do a search in Xcode on pagedown, just out of a last gasp of trying \u2014 and, forgotten long ago by me, but look: there is a scrollPageDown method in NSResponder \u2014\u00a0and WKWebView is an NSView subclass which is an NSResponder subclass \u2014 so, could it be? maybe? it might work?\nI tried it: sure enough! It works! With animation and everything. It\u2019s perfect.\n* * *\nSo, in the end, the action method is in MainWindowController \u2014 see scrollOrGoToNextUnread.\n(It\u2019s a little weird due to the async thing I mentioned earlier. But it does the job.)\nAnd now \u2014\u00a0after three years of working on this app \u2014\u00a0I was finally able to go through all my news just by hitting the space bar. Big day for me.\n\n",
"type": "entry"
},
{
"updated": "2017-12-09T20:57:58",
"name": "Evergreen Diary #2: Random Notes",
"url": "http://inessential.com/2017/12/09/evergreen_diary_2_random_notes",
"summary": "\nI\u2019ve been working on Evergreen for about three years, and so I considered writing about playing such a long game \u2014 but then Daniel released MarsEdit 4.0 after seven years.\nI tip my fedora to the master.\n* * *\nBut there is at least one difference: it\u2019s taking so many years just to get to one-point-oh. I\u2019ve never been on any kind of project that took so long just to get to the initial release.\nThe app\u2019s been built from the bottom up. Since I knew in advance what I needed, I could write code that wouldn\u2019t get actually used for years.\nHere\u2019s a small example, written almost two years ago:\u00a0RSHTMLMetadata.h.\nThe scoop: it always bugged me that in NetNewsWire, when it was mine, the favicon downloading system never checked the metadata in a feed\u2019s home page to find the favicon.\nIt always just appended /favicon.ico \u2014 which wasn\u2019t always correct. So it would get the wrong one or just not find it.\n(Note: it\u2019s entirely likely that the current version of NetNewsWire has fixed this bug.)\nSo, a year-and-a-half ago, I wrote code in RSHTMLMetadata that pulls the favicon URL from web page data.\nAnd then, just last month, when I finally got around to writing the favicon downloading system, it took very little code to actually pull the favicon URL from a web page (in FaviconURLFinder.swift):\nlet htmlMetadata = RSHTMLMetadataParser.\u200bhtmlMetadata\u200b(with: parserData)\nreturn htmlMetadata.\u200bfaviconLink\nThis pattern \u2014 ground-up development, where you know what you need in advance \u2014 isn\u2019t really different from apps developed much more quickly.\nThe difference is the amount of satisfaction I feel when I finally connect old and new pieces. It feels great.\nAnd that\u2019s the position I\u2019m in now, now that I\u2019m at the top layer: code that I wrote a long time ago is finally getting used. The puzzle is coming together.\n* * *\nOf course, I didn\u2019t, and couldn\u2019t, know everything in advance. I didn\u2019t know I\u2019d want Open Graph and Twitter images from web page data \u2014 but I was glad when I found that the code I\u2019d already written was easy to extend.\n* * *\nSince I have no commercial interest in Evergreen \u2014\u00a0since it\u2019s free and open source \u2014 I can take all the time I need. One of the many advantages of this is spending more time writing unit tests than I used to.\nThere aren\u2019t enough, yet \u2014\u00a0not even close; and there never are enough \u2014 but they do exist. Here, for example, are the tests for HTML metadata parsing.\nAnd when I find a bug I add a new test: for example, the feed type detector was not detecting Natasha the Robot\u2019s feed as RSS. So I fixed the bug and added a test.\n* * *\nFrom the now-it-can-be-told department\u2026 a couple years ago, in November 2015, I collected a list of blogs written by women that would be \u201cof interest to Mac/iOS developers, designers, and power users.\u201d\nThis was for Evergreen. When I was working on NetNewsWire, the default feeds were all, or almost all, written by men. For Evergreen I wanted to fix that, and I also wanted to create a larger feed directory that was inclusive. (Here\u2019s the plist for the directory. It still needs a bunch of work.)\nIf you have feeds to suggest, please do a pull request. Or send me a note on Twitter via @evergreen_mac.\n* * *\nI just started working on syncing via Feedbin. It\u2019s what I use, and syncing is necessary. It\u2019s likely that 1.0 will ship with just Feedbin syncing, though, and I\u2019ll add other systems in follow-up releases.\nAlso: I just got a new iPad Mini which travels to and from work with me. I didn\u2019t expect to love this device so much! So now I\u2019m thinking of doing Evergreen for iOS after all. (Also open source, as part of the same project.)\n* * *\nIt gratifies me to see my friends working on open web stuff. Dave Winer, of course, is always on the ball. Daniel just released MarsEdit; Manton is working on Micro.blog.\nThis is a political act, and, I think, fundamentally conservative: it wants to preserve what\u2019s great about the web, and it recognizes that concentrations of power are bad things.\nPower should be distributed to the individuals, not hoarded by large companies and governments that have their own interests in mind, which match ours purely by coincidence from time to time.\nNext year may be a horrible year for a whole bunch of reasons, but it may also be a year where the open web fights back. Evergreen wants to help.\n",
"content": "\n\nI\u2019ve been working on Evergreen for about three years, and so I considered writing about playing such a long game \u2014 but then Daniel released MarsEdit 4.0 after seven years.\nI tip my fedora to the master.\n* * *\nBut there is at least one difference: it\u2019s taking so many years just to get to one-point-oh. I\u2019ve never been on any kind of project that took so long just to get to the initial release.\nThe app\u2019s been built from the bottom up. Since I knew in advance what I needed, I could write code that wouldn\u2019t get actually used for years.\nHere\u2019s a small example, written almost two years ago:\u00a0RSHTMLMetadata.h.\nThe scoop: it always bugged me that in NetNewsWire, when it was mine, the favicon downloading system never checked the metadata in a feed\u2019s home page to find the favicon.\nIt always just appended /favicon.ico \u2014 which wasn\u2019t always correct. So it would get the wrong one or just not find it.\n(Note: it\u2019s entirely likely that the current version of NetNewsWire has fixed this bug.)\nSo, a year-and-a-half ago, I wrote code in RSHTMLMetadata that pulls the favicon URL from web page data.\nAnd then, just last month, when I finally got around to writing the favicon downloading system, it took very little code to actually pull the favicon URL from a web page (in FaviconURLFinder.swift):\nlet htmlMetadata = RSHTMLMetadataParser.\u200bhtmlMetadata\u200b(with: parserData)\nreturn htmlMetadata.\u200bfaviconLink\nThis pattern \u2014 ground-up development, where you know what you need in advance \u2014 isn\u2019t really different from apps developed much more quickly.\nThe difference is the amount of satisfaction I feel when I finally connect old and new pieces. It feels great.\nAnd that\u2019s the position I\u2019m in now, now that I\u2019m at the top layer: code that I wrote a long time ago is finally getting used. The puzzle is coming together.\n* * *\nOf course, I didn\u2019t, and couldn\u2019t, know everything in advance. I didn\u2019t know I\u2019d want Open Graph and Twitter images from web page data \u2014 but I was glad when I found that the code I\u2019d already written was easy to extend.\n* * *\nSince I have no commercial interest in Evergreen \u2014\u00a0since it\u2019s free and open source \u2014 I can take all the time I need. One of the many advantages of this is spending more time writing unit tests than I used to.\nThere aren\u2019t enough, yet \u2014\u00a0not even close; and there never are enough \u2014 but they do exist. Here, for example, are the tests for HTML metadata parsing.\nAnd when I find a bug I add a new test: for example, the feed type detector was not detecting Natasha the Robot\u2019s feed as RSS. So I fixed the bug and added a test.\n* * *\nFrom the now-it-can-be-told department\u2026 a couple years ago, in November 2015, I collected a list of blogs written by women that would be \u201cof interest to Mac/iOS developers, designers, and power users.\u201d\nThis was for Evergreen. When I was working on NetNewsWire, the default feeds were all, or almost all, written by men. For Evergreen I wanted to fix that, and I also wanted to create a larger feed directory that was inclusive. (Here\u2019s the plist for the directory. It still needs a bunch of work.)\nIf you have feeds to suggest, please do a pull request. Or send me a note on Twitter via @evergreen_mac.\n* * *\nI just started working on syncing via Feedbin. It\u2019s what I use, and syncing is necessary. It\u2019s likely that 1.0 will ship with just Feedbin syncing, though, and I\u2019ll add other systems in follow-up releases.\nAlso: I just got a new iPad Mini which travels to and from work with me. I didn\u2019t expect to love this device so much! So now I\u2019m thinking of doing Evergreen for iOS after all. (Also open source, as part of the same project.)\n* * *\nIt gratifies me to see my friends working on open web stuff. Dave Winer, of course, is always on the ball. Daniel just released MarsEdit; Manton is working on Micro.blog.\nThis is a political act, and, I think, fundamentally conservative: it wants to preserve what\u2019s great about the web, and it recognizes that concentrations of power are bad things.\nPower should be distributed to the individuals, not hoarded by large companies and governments that have their own interests in mind, which match ours purely by coincidence from time to time.\nNext year may be a horrible year for a whole bunch of reasons, but it may also be a year where the open web fights back. Evergreen wants to help.\n\n",
"type": "entry"
},
{
"updated": "2017-12-07T21:21:20",
"name": "The Omni Show episode #4 with Andrea McVittie, Omni Slack Group",
"url": "http://inessential.com/2017/12/07/the_omni_show_episode_4_with_andrea_mcv",
"summary": "\nYesterday we published an episode with Andrea McVittie, User Experience Designer at The Omni Group.\nAndrea will brook nae interference with the puppies. Be nice!\nShe also talks a bit about how design works at Omni and about design and ethics. After we posted the episode, she followed up with a tweet where she codifies her ethical guidelines.\n* * *\nRecently Omni created a Slack group \u2014\u00a0you can join up.\nIt\u2019s not intended as a replacement for support. But you can talk with Omni people and with other people who use Omni apps. It\u2019s not super-busy; it\u2019s, well, nice. I like having the people who use the things we work on so nearby.\n",
"content": "\n\nYesterday we published an episode with Andrea McVittie, User Experience Designer at The Omni Group.\nAndrea will brook nae interference with the puppies. Be nice!\nShe also talks a bit about how design works at Omni and about design and ethics. After we posted the episode, she followed up with a tweet where she codifies her ethical guidelines.\n* * *\nRecently Omni created a Slack group \u2014\u00a0you can join up.\nIt\u2019s not intended as a replacement for support. But you can talk with Omni people and with other people who use Omni apps. It\u2019s not super-busy; it\u2019s, well, nice. I like having the people who use the things we work on so nearby.\n\n",
"type": "entry"
},
{
"updated": "2017-11-22T21:01:09",
"name": "The Omni Show Episode #3 with Brian Covey, Support Manager",
"url": "http://inessential.com/2017/11/22/the_omni_show_episode_3_with_brian_cove",
"summary": "\nNew episode is up!\nBrian is the Support Manager at The Omni Group, and he has a bunch to say about how support \u2014\u00a0and the Support Humans \u2014 work at Omni, including how they\u2019re involved with product decisions, and how we came to offer phone support.\nDVD extras content: a video from 2006 of Brian doing the worm. Unmissable.\n",
"content": "\n\nNew episode is up!\nBrian is the Support Manager at The Omni Group, and he has a bunch to say about how support \u2014\u00a0and the Support Humans \u2014 work at Omni, including how they\u2019re involved with product decisions, and how we came to offer phone support.\nDVD extras content: a video from 2006 of Brian doing the worm. Unmissable.\n\n",
"type": "entry"
},
{
"updated": "2017-11-08T21:15:56",
"name": "The Omni Show",
"url": "http://inessential.com/2017/11/08/the_omni_show",
"summary": "\nI\u2019m the host of a new podcast: The Omni Show. Here\u2019s the announcement on the Omni blog with all the details. There\u2019s a Twitter account, @theomnishow, you can follow.\nI\u2019m super-excited to be doing this, partly because my co-workers at Omni are interesting, and partly because some of it may actually be useful \u2014 that is, learning how we think about UX, testing, engineering, support, and so on might be helpful for other people. That\u2019s my hope.\nOur first episode is with Kristina Sontag, Software Test Manager, and the second episode is with Curt Clifton, OmniFocus engineer. The next two episodes will feature support and UX. We\u2019re covering all the bases. :)\nI\u2019ve done podcasts before (see Identical Cousins and The Record), so I\u2019m not completely new to this. It\u2019s produced by Mark Boszko, also a podcast veteran, who does The Optical, which is a must-listen for everybody who likes movies. The music is by Aaron Cherof, composer extraordinaire, and the look of the site is by Kaitlin Reiss. My favorite touch is the big \u201cTHE OMNI SHOW\u201d title at the top \u2014\u00a0watch it as the gradient slowly changes. It\u2019s mesmerizing.\nAnd, of course, there are more people working on the show. Like everything else, it\u2019s a team effort, but it goes to the theme of the show (\u201cThe Omni Show is people!\u201d) to mention some specific individuals \u2014 and to thank them. Thank you to everyone who works on The Omni Show.\n",
"content": "\n\nI\u2019m the host of a new podcast: The Omni Show. Here\u2019s the announcement on the Omni blog with all the details. There\u2019s a Twitter account, @theomnishow, you can follow.\nI\u2019m super-excited to be doing this, partly because my co-workers at Omni are interesting, and partly because some of it may actually be useful \u2014 that is, learning how we think about UX, testing, engineering, support, and so on might be helpful for other people. That\u2019s my hope.\nOur first episode is with Kristina Sontag, Software Test Manager, and the second episode is with Curt Clifton, OmniFocus engineer. The next two episodes will feature support and UX. We\u2019re covering all the bases. :)\nI\u2019ve done podcasts before (see Identical Cousins and The Record), so I\u2019m not completely new to this. It\u2019s produced by Mark Boszko, also a podcast veteran, who does The Optical, which is a must-listen for everybody who likes movies. The music is by Aaron Cherof, composer extraordinaire, and the look of the site is by Kaitlin Reiss. My favorite touch is the big \u201cTHE OMNI SHOW\u201d title at the top \u2014\u00a0watch it as the gradient slowly changes. It\u2019s mesmerizing.\nAnd, of course, there are more people working on the show. Like everything else, it\u2019s a team effort, but it goes to the theme of the show (\u201cThe Omni Show is people!\u201d) to mention some specific individuals \u2014 and to thank them. Thank you to everyone who works on The Omni Show.\n\n",
"type": "entry"
},
{
"updated": "2017-10-10T23:08:04",
"name": "On Fixing that NSNull Crasher in Overcast",
"url": "http://inessential.com/2017/10/10/on_fixing_that_nsnull_crasher_in_overcas",
"summary": "\nI don\u2019t normally head home after lunch, but today I was on the bus going back to Ballard, about to open iBooks on my phone and get back to reading The Caledonian Gambit (which I\u2019m thoroughly enjoying), when I decided to check Twitter first \u2014\u00a0and saw Marco\u2019s tweet about Overcast\u2019s oldest crash.\nI\u2019ve written before about how I love fixing crashing bugs. Partly because I\u2019m adamant that an app should, at a minimum, keep running \u2014\u00a0and also because it\u2019s fun detective work. (I\u2019ve even written a series of blog posts on how not to crash in the first place.)\nSo I took this one as a challenge. Here\u2019s how I figured it out:\n\nThe exception reported [NSNull doubleValue]: unrecognized selector. Now, NSNull is a stand-alone code smell: there\u2019s hardly ever a time where it should be used. Well, there was that one weird thing with the kerning a long time ago, but that\u2019s about it. This crash is probably not that.\nThen I looked at the backtrace and saw -[NSRTFWriter writeKern], and then I looked a little further and saw that an NSAttributedString was being exported to RTF, and, furthermore, writeKern probably is writing out the kerning attribute, which was set to NSNull. writeKern was expecting an NSNumber. So that was it.\n\nI replied:\nThe kerning attribute is NSNull. That used to be the way to specify use font-specified kerning.\nAnd then Marco found the bug and fixed it.\n* * *\nThis is a story about experience and luck, not brains. It\u2019s just that I\u2019ve been working with these APIs for a long time.\nHere\u2019s the story behind setting NSKernAttributeName to NSNull. Back in the iOS 6 days, when John and Dave and I were working on Vesper \u2014 which used a custom font, Ideal Sans \u2014\u00a0we noticed that the kerning was fucking awful. We obviously couldn\u2019t ship it like that. We had to either figure out how to fix the kerning or switch to the system font \u2014 which would have been heart-breaking, since Ideal Sans was so perfect for this app.\nSo I searched around until I found that there was a little bit of magic: in our NSAttributedStrings, we needed to set NSKernAttributeName to NSNull to get the font-specified kerning. I tried it \u2014 and it worked! We were able to ship with Ideal Sans.\n(Here\u2019s a search in Vesper\u2019s code base for that attribute.)\nI don\u2019t know if this bit of magic is still needed these days. Hopefully not \u2014\u00a0because 1) it\u2019s weird to have NSNull have a meaning like this, and 2) NSRTFWriter doesn\u2019t know to expect an NSNull instead of an NSNumber (this should get filed as a Radar).\nI no longer remember exactly where I ran across that bit of magic. Memory tells me what it was a slide from a James Dempsey talk somewhere, though I can\u2019t seem to find it right now.\nAnyway. This bug was fixed because years ago I was working with type nerds (and I am one myself), and because of James.\nFixing crashing bugs takes a village.\n",
"content": "\n\nI don\u2019t normally head home after lunch, but today I was on the bus going back to Ballard, about to open iBooks on my phone and get back to reading The Caledonian Gambit (which I\u2019m thoroughly enjoying), when I decided to check Twitter first \u2014\u00a0and saw Marco\u2019s tweet about Overcast\u2019s oldest crash.\nI\u2019ve written before about how I love fixing crashing bugs. Partly because I\u2019m adamant that an app should, at a minimum, keep running \u2014\u00a0and also because it\u2019s fun detective work. (I\u2019ve even written a series of blog posts on how not to crash in the first place.)\nSo I took this one as a challenge. Here\u2019s how I figured it out:\n\nThe exception reported [NSNull doubleValue]: unrecognized selector. Now, NSNull is a stand-alone code smell: there\u2019s hardly ever a time where it should be used. Well, there was that one weird thing with the kerning a long time ago, but that\u2019s about it. This crash is probably not that.\nThen I looked at the backtrace and saw -[NSRTFWriter writeKern], and then I looked a little further and saw that an NSAttributedString was being exported to RTF, and, furthermore, writeKern probably is writing out the kerning attribute, which was set to NSNull. writeKern was expecting an NSNumber. So that was it.\n\nI replied:\nThe kerning attribute is NSNull. That used to be the way to specify use font-specified kerning.\nAnd then Marco found the bug and fixed it.\n* * *\nThis is a story about experience and luck, not brains. It\u2019s just that I\u2019ve been working with these APIs for a long time.\nHere\u2019s the story behind setting NSKernAttributeName to NSNull. Back in the iOS 6 days, when John and Dave and I were working on Vesper \u2014 which used a custom font, Ideal Sans \u2014\u00a0we noticed that the kerning was fucking awful. We obviously couldn\u2019t ship it like that. We had to either figure out how to fix the kerning or switch to the system font \u2014 which would have been heart-breaking, since Ideal Sans was so perfect for this app.\nSo I searched around until I found that there was a little bit of magic: in our NSAttributedStrings, we needed to set NSKernAttributeName to NSNull to get the font-specified kerning. I tried it \u2014 and it worked! We were able to ship with Ideal Sans.\n(Here\u2019s a search in Vesper\u2019s code base for that attribute.)\nI don\u2019t know if this bit of magic is still needed these days. Hopefully not \u2014\u00a0because 1) it\u2019s weird to have NSNull have a meaning like this, and 2) NSRTFWriter doesn\u2019t know to expect an NSNull instead of an NSNumber (this should get filed as a Radar).\nI no longer remember exactly where I ran across that bit of magic. Memory tells me what it was a slide from a James Dempsey talk somewhere, though I can\u2019t seem to find it right now.\nAnyway. This bug was fixed because years ago I was working with type nerds (and I am one myself), and because of James.\nFixing crashing bugs takes a village.\n\n",
"type": "entry"
},
{
"updated": "2017-10-03T20:18:16",
"name": "Accessibility",
"url": "http://inessential.com/2017/10/03/accessibility",
"summary": "\nAs a young developer I didn\u2019t pay that much attention to accessibility. I figured that most people didn\u2019t need those features, and it was something I could get to later. Plus: adding those features wasn\u2019t easy back in those days.\nThings have changed.\nFor one thing, supporting accessibility features \u2014\u00a0at least on Macs and iOS \u2014\u00a0has gotten much easier. It\u2019s almost delightful with how much you get for free and how easy it is to add what\u2019s missing. Apple deserves a huge amount of credit for this.\nBut there are two bigger things I keep thinking of.\nFirst thing: I want to say that access to computing and communications power is a human right. It\u2019s not, not really \u2014 but it would be wrong to deny someone access when, with a little extra work, you could make it work for them.\n(Would you be lost without your iPhone? I would be.)\nSecond thing: accessibility is not just for some small number of people with one specific issue. It\u2019s a diverse set of features and solutions. And everybody \u2014 even the youngest and healthiest of us \u2014 will eventually rely on some accessibility features if they live long enough.\nYou may not need it now, in other words, but you will, if you\u2019re lucky. And future-you will be proud of past-you if you cared about it before it was personal.\nIt\u2019s personal to me now, by the way, at age 49: I use the Dynamic Type feature on my iOS devices to bump up the font size. Though I run into layout bugs from time to time (reported: rdar://34791630), I\u2019m still utterly grateful that the feature exists and that so many developers have adopted it (or done the equivalent in their apps).\nWithout that feature I\u2019d be an iOS programmer who has a hard time actually using an iPhone. Which would be dumb.\n",
"content": "\n\nAs a young developer I didn\u2019t pay that much attention to accessibility. I figured that most people didn\u2019t need those features, and it was something I could get to later. Plus: adding those features wasn\u2019t easy back in those days.\nThings have changed.\nFor one thing, supporting accessibility features \u2014\u00a0at least on Macs and iOS \u2014\u00a0has gotten much easier. It\u2019s almost delightful with how much you get for free and how easy it is to add what\u2019s missing. Apple deserves a huge amount of credit for this.\nBut there are two bigger things I keep thinking of.\nFirst thing: I want to say that access to computing and communications power is a human right. It\u2019s not, not really \u2014 but it would be wrong to deny someone access when, with a little extra work, you could make it work for them.\n(Would you be lost without your iPhone? I would be.)\nSecond thing: accessibility is not just for some small number of people with one specific issue. It\u2019s a diverse set of features and solutions. And everybody \u2014 even the youngest and healthiest of us \u2014 will eventually rely on some accessibility features if they live long enough.\nYou may not need it now, in other words, but you will, if you\u2019re lucky. And future-you will be proud of past-you if you cared about it before it was personal.\nIt\u2019s personal to me now, by the way, at age 49: I use the Dynamic Type feature on my iOS devices to bump up the font size. Though I run into layout bugs from time to time (reported: rdar://34791630), I\u2019m still utterly grateful that the feature exists and that so many developers have adopted it (or done the equivalent in their apps).\nWithout that feature I\u2019d be an iOS programmer who has a hard time actually using an iPhone. Which would be dumb.\n\n",
"type": "entry"
}
],
"type": "feed",
"name": "inessential",
"summary": "Brent Simmons\u2019s weblog."
}