NetNewsWire/Frameworks/RSParser/RSParserTests/Resources/inessential.json

157 lines
58 KiB
JSON
Raw Normal View History

{
"version": "https://jsonfeed.org/version/1",
"title": "inessential.com",
"description": "Brent Simmonss weblog.",
"home_page_url": "http://inessential.com/",
"feed_url": "http://inessential.com/feed.json",
"user_comment": "This feed allows you to read the posts from this site in any feed reader that supports the JSON Feed format. To add this feed to your reader, copy the following URL — http://inessential.com/feed.json — and add it your reader.",
"favicon": "http://inessential.com/favicon.ico",
"author": {
"name": "Brent Simmons",
"url": "http://inessential.com/",
"avatar": "http://ranchero.com/downloads/brent_avatar.png"
},
"items": [
{
"id": "http://inessential.com/2017/06/02/james_dempsey_and_the_breakpoints_benefi",
"url": "http://inessential.com/2017/06/02/james_dempsey_and_the_breakpoints_benefi",
"title": "James Dempsey and the Breakpoints Benefit App Camp for Girls",
"content_html": "<p>On Wednesday night I know where Ill be — playing keyboard for a few songs at the James Dempsey and the Breakpoints concert benefitting App Camp for Girls.</p>\n\n<p><a href=\"https://www.classy.org/events/-/e126329\">You should get tickets</a>. Its a fun time for a great cause.</p>\n\n<p>Bonus: James writes about how <a href=\"http://jamesdempsey.net/2017/06/02/wwdc-in-san-jose-full-circle/\">this concert is full circle for him</a>. Its a special night.</p>",
"date_published": "2017-06-02T22:05:47-07:00"
},
{
"id": "http://inessential.com/2017/06/01/evergreen_diary_1_open_source",
"url": "http://inessential.com/2017/06/01/evergreen_diary_1_open_source",
"title": "Evergreen Diary #1: Open Source",
"content_html": "<p><a href=\"https://ranchero.com/evergreen/\">Evergreen</a> is a new feed reader for Macs. Its not actually <em>done</em> yet — in fact, its not even alpha yet, much less beta. Its still in the painful-to-use stage, for sure.</p>\n\n<p>Ive been working on it (<a href=\"http://inessential.com/frontierdiary\">among other things</a>) on nights and weekends for a couple years. For much of the time I planned to make it a for-pay app — the plan was a free Lite version and a for-pay version.</p>\n\n<p>But as time went on I was less and less motivated to make a for-pay app. Doing all that stuff — dealing with licenses, money, a store, support, and everything else that goes along with a commercial app — just didnt sound like any fun, and it would have taken time away from actually working on the app, which is all I really want to do. I just dont have time to spare.</p>\n\n<p>So I decided to make it free and open source. (The <a href=\"https://github.com/brentsimmons/Evergreen\">code is up on GitHub</a>.) This fits with my goals:</p>\n\n<ul>\n<li>Promoting feed-reading as part of promoting the open web.</li>\n<li>Publishing a bunch of feed-reading code and an example Mac app that other developers can use.</li>\n<li>Giving me something to write about on this blog.</li>\n</ul>\n\n\n<p>I like developing in public. Publishing the code makes it feel like a performance, a kind of <a href=\"https://www.youtube.com/watch?v=d2Z9qN8R9Bg\">tightwire act</a>. Which suits me.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>The one thing that almost held me back from making it open source was the effect on other developers. There are for-pay Mac feed readers, after all, and I dont want to take anything away from them.</p>\n\n<p>And I dont want to send the message that software ought to cost nothing.</p>\n\n<p>I think that making it open source makes it an obvious special case. There is at least <a href=\"https://github.com/ViennaRSS/vienna-rss\">one other open source Mac feed reader</a>, and there are other open source Mac apps, and I dont think that these projects are fueling the race to the bottom with app pricing.</p>\n\n<p>I went over and over this decision for months. It wasnt easy! But in the end I decided its a good thing, and there are always good reasons not to do a good thing.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>The app doesnt have any icons yet. <a href=\"https://twitter.com/BradEllis\">Brad Ellis</a>, who Ive worked with before on some versions of my previous feed reader, and who is my favorite designer, is working on icons.</p>\n\n<p>Brad is not only my favorite designer, hes the favorite designer of people who thought they might be my favorite designer. :)</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>At some point it will sync with some existing systems (such as <a href=\"https://feedly.com/\">Feedly</a>, <a href=\"https://feedbin.com/\">FeedBin</a>, and similar) — but probably not till after 1.0, though as top priority.</p>\n\n<p>I have no plans to make an iOS version (though anything could happen). The plan is to make it a great Mac app. Period. But if it syncs with Feedly and so on, then you could use some other reader on iOS and it would sync with Evergreen.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>There is a road not taken here thats worth exploring, though probably not by me (for reasons of time).</p>\n\n<p>I would love to see a casual feed reader (as opposed to productivity-style) that just provides a timeline, with new stuff at the top. The idea is to make something like a Twitter client but for feeds. Youd get a list of articles, and when you want to read something youd click (or whatever) to open the article in your browser.</p>\n\n<p>Such an app wouldnt have per-article read/unread status  instead it would maintain a high-water mark, the date of the newest item youve seen in the timeline.</p>\n\n<p>For a little while I was planning to do <em>both</em> styles of reader,
"date_published": "2017-06-01T17:27:32-07:00"
},
{
"id": "http://inessential.com/2017/05/26/app_the_human_story_screening_in_san_",
"url": "http://inessential.com/2017/05/26/app_the_human_story_screening_in_san_",
"title": "“App: The Human Story” Screening in San Jose",
"content_html": "<p>Heres the <a href=\"https://medium.com/altconf/altconf-layers-present-app-the-human-story-3c2b3cb8fc4c\">scoop</a>. Its Sunday, June 4 at 5 pm. Theres a panel afterward with a bunch of people from the movie (including me).</p>\n\n<p><a href=\"https://www.classy.org/san-jose/events/app-human-story-documentary-screening-presented-by-altconf-layers/e128096\">You can get tickets</a>. You <em>should</em> get tickets — the event benefits <a href=\"http://appcamp4girls.com/\">App Camp for Girls</a>.</p>\n\n<p>Plus I think youll enjoy it. :)</p>",
"date_published": "2017-05-26T12:57:19-07:00"
},
{
"id": "http://inessential.com/2017/05/17/json_feed",
"url": "http://inessential.com/2017/05/17/json_feed",
"title": "JSON Feed",
"content_html": "<p>I was hesitant, even up to this morning, to publish the <a href=\"https://jsonfeed.org/version/1\">JSON Feed spec</a>.</p>\n\n<p>If you read Dave Winers <a href=\"http://scripting.com/2017/05/09/rulesForStandardsmakers.html\">Rules for standards-makers</a>, youll see that we did a decent job with some of the rules — the spec is written in plain English, for example — but a strict application of the rules would have meant not publishing at all, since “Fewer formats is better.”</p>\n\n<p>I agree completely — but I also believe that developers (particularly Mac and iOS developers, the group I know best) are so loath to work with XML that they wont even consider building software that needs an XML parser. Which says to me that JSON Feed is needed for the survival of syndication.</p>\n\n<p>I could be wrong, of course. I admit.</p>\n\n<h4>Feed Reader Starter Kit</h4>\n\n<p>See my <a href=\"https://github.com/brentsimmons/RSXML\">RSXML repository</a> for Objective-C code that reads RSS, Atom, and OPML. Ive done the work for you of supporting those formats. Go write a feed reader! Seriously. Do it.</p>\n\n<p>I planned to have a JSON Feed parser for Swift done for today, but other things got in the way. Its coming soon. But you probably dont actually need any sample code, since JSON is so easy to handle.</p>\n\n<h4>Feedback so far</h4>\n\n<p>Feedback has been interesting so far. Some <a href=\"https://github.com/brentsimmons/JSONFeed\">questions</a> on the GitHub repo need answering.</p>\n\n<p>Some people have said this should have happened ten years ago, and other people have said that they hate how developers jump on the latest fad (JSON).</p>\n\n<p>And some people really like the icon:</p>\n\n<p><img src=\"http://jsonfeed.org/graphics/icon.png\" height=70 width=70 /></p>\n\n<h4>Microformats</h4>\n\n<p>One of the more serious criticisms was this: why not just support the <a href=\"http://microformats.org/wiki/hatom\">hAtom microformat</a> instead? Why do another side-file?</p>\n\n<p>My thinking:</p>\n\n<p>My experience as a feed reader author tells me that people screw up XML, badly, all the time — and they do even less well with HTML. So embedding info in HTML is just plain too difficult. In practice it would be even buggier than XML-based feeds.</p>\n\n<p>And there are other advantages to decoupling: a side-file can have 100 entries where there are only 10 on an HTML page, for instance. A side-file can have extra information that you wouldnt put on an HTML page. And yet, despite the extra information, a side-file can be much smaller than an HTML page, and it can often be easier to cache (since its not different based on a logged-in user, for instance).</p>\n\n<p>Microformats sounds elegant, but I dont prize elegance as much as I value things that work well.</p>",
"date_published": "2017-05-17T13:22:14-07:00"
},
{
"id": "http://inessential.com/2017/05/01/frontier_diary_8_when_worlds_collide",
"url": "http://inessential.com/2017/05/01/frontier_diary_8_when_worlds_collide",
"title": "Frontier Diary #8: When Worlds Collide",
"content_html": "<p>I spent the weekend making a bunch of progress on the compiler. It has two pieces: a <a href=\"https://github.com/brentsimmons/Frontier/blob/master/UserTalk/UserTalk/Compiler/Tokenizer.swift\">tokenizer</a>, which I created by rewriting the original C code (<a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierOrigFork/Common/source/langscan.c\">langscan.c</a>) in Swift, and a parser.</p>\n\n<p>The parser in OrigFrontier was generated by MacYacc, which is similar to Yacc, which is similar to <a href=\"https://www.gnu.org/software/bison/\">Bison</a>, which is on my Mac. The thing about the parser is that its C code, and the rest of the app is Swift.</p>\n\n<p>How do you bridge the two worlds? Easy answer: with Objective-C, which is a superset of C and which plays nicely (enough) with Swift.</p>\n\n<p>So I renamed langparser.y — the rules file that the parser generator uses — to <a href=\"https://github.com/brentsimmons/Frontier/blob/master/UserTalk/UserTalk/Compiler/langparser.ym\">langparser.ym</a> so that Xcode would know to treat the generated parser source as Objective-C. I edited it slightly, not to change the grammar rules but to change how nodes are created (as return values rather than via inout).</p>\n\n<p>I also made my <a href=\"https://github.com/brentsimmons/Frontier/blob/master/UserTalk/UserTalk/CodeTreeNode.swift\">CodeTreeNode</a> class, written in Swift, an Objective-C class so that it would be visible to my Objective-C code.</p>\n\n<p>And then, finally, I started a build…</p>\n\n<p>…and then it stopped with an error because the parser places my <code>CodeTreeNode</code> in a C union, which isnt allowed in ARC.</p>\n\n<p>Crushed.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>I think I have three options:</p>\n\n<ol>\n<li>Go down the rabbit hole of figuring out how to get the parser to work with ARC.</li>\n<li>Go with the flow: have the parser generate nodes that are, as in OrigFrontier, C structs. The last compilation step would be Objective-C code that translates that tree of C structs into a tree of <code>CodeTreeNode</code> objects, and then disposes the C-struct-node-tree.</li>\n<li>Write the parser by hand, in Swift.</li>\n</ol>\n\n\n<p>My thinking:</p>\n\n<p>I could waste a ton of time on #1, and bending tools in that way can be pretty frustrating work when they refuse to bend.</p>\n\n<p>With #2 Id feel a bit weird about the redundancy: building a tree and then building a copy of that tree with a different type of object.</p>\n\n<p>My heart tells me #3 is the answer. After all, Ive already done the tokenizer. How hard would it be to parse those tokens into a code tree? I could skip C and Objective-C altogether and stay in Swift. And it would be <em>so fun</em>. (Because thats precisely the style of weirdo I am.)</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>But the real answer is #2. Writing a parser by hand would take way longer than I think. Given enough tests, it shouldnt be a huge source of bugs, but still.</p>\n\n<p>The thing about #2 is that yes, its redundant, its doing more work than it needs to, ideally — but my bet is that it would still be so fast that you wouldnt be able to tell the difference. Computers are so good at this kind of thing. Its not like reading files or networking; its just in-memory traversal and creating/releasing things.</p>\n\n<p>You remember in Indiana Jones that guy with the twirling swords, and Indy gives that look and then just shoots him? The second option is the Indiana Jones solution.</p>\n\n<p><i>Update 2:05 pm</i>: Two people have already written me to recommend <a href=\"http://www.antlr.org\">ANTLR</a>. So I will definitely give that a look. It might be exactly what I need.</p>",
"date_published": "2017-05-01T13:34:23-07:00"
},
{
"id": "http://inessential.com/2017/04/27/frontier_diary_7_pretty_much_everythin",
"url": "http://inessential.com/2017/04/27/frontier_diary_7_pretty_much_everythin",
"title": "Frontier Diary #7: Pretty Much Everything Throws",
"content_html": "<p>A script can throw an error, either intentionally (via the <code>scriptError</code> verb) or by doing something, such as referencing an undefined object, that generates an error.</p>\n\n<p>OrigFrontier was written in C, which has no error-throwing mechanism, and so it worked like this: most runtime functions returned a boolean (for success or failure), and the return value was passed in by reference. If there was an error, the function would set a global error variable and return false. The caller would then have to check that global to see if there was an error, and then do the right thing.</p>\n\n<p>This was not unreasonable, given the language and the times (early 90s) and also given the need to be very careful about unwinding memory allocations.</p>\n\n<p>But, these days, it seems to me that Swifts error system is the way to go. Theres just one downside to that, and its that I have to do that do/try/catch dance all over the place, since pretty much any runtime function can throw an error.</p>\n\n<p>Even the coercions can throw, so last night I changed the <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierData/FrontierData/Value/ValueProtocol.swift\">Value</a> protocol so that <code>asInt</code> and so on are now functions, since properties cant throw (at least not yet).</p>\n\n<p>The extra housekeeping — the do/try/catch stuff — kind of bugs me, but its honest. I considered making script errors just another type of Value — but that meant that all those callers have to check the returned Value to see if its an error, and then do the right thing. Better to just use Swifts error system, because it makes for more consistent code, and it makes sure Im catching errors in every case.</p>\n\n<p>It also means Im not multiplying entities. A Swift error is a script error, and vice versa.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>Working on this code is like applying the last 25 years of programming history all at once.</p>\n\n<p>A completely different type of error is a <em>bug</em>, and Im certain to write a bunch of them, because thats how programming goes.</p>\n\n<p>Thats where unit tests come in. Frontier has long had a stress-test suite of scripts — youd launch the app, run that suite, wait a while, and see if there are any errors. This was critically helpful.</p>\n\n<p>But OrigFontier didnt have unit tests at the C code level. The new version does. (Well, <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierVerbs/FrontierVerbsTests/Math.swift\">Ive started them anyway</a>.) This means I can more easily follow <a href=\"http://scripting.com/2002/09/29.html#rule1\">Rule 1</a> — the no-breakage rule — and can also more easily follow Rule 1b — the dont-break-Dave rule.</p>\n\n<p>PS Ive added a <a href=\"http://inessential.com/frontierdiary\">collection page for the Frontier Diary</a>, as I did with earlier diaries. Theres a link to it in the footer of every page on the blog.</p>",
"date_published": "2017-04-27T13:30:42-07:00"
},
{
"id": "http://inessential.com/2017/04/26/frontier_diary_6_ballard_from_the_par",
"url": "http://inessential.com/2017/04/26/frontier_diary_6_ballard_from_the_par",
"title": "Frontier Diary #6: Ballard, from the Parallel Universe",
"content_html": "<p>In another universe I didnt decide to port Frontier — instead, I started over from scratch on an app <em>inspired</em> by Frontier.</p>\n\n<p>In that universe, the new scripting language, descended from UserTalk, is called Ballard. <a href=\"http://inessential.com/ballard_lang\">And its documented</a>.</p>",
"date_published": "2017-04-26T13:04:04-07:00"
},
{
"id": "http://inessential.com/2017/04/25/my_microblog",
"url": "http://inessential.com/2017/04/25/my_microblog",
"title": "My Microblog",
"content_html": "<p>Im on Mantons cool new microblogs system. Heres where you can follow me, once youre on the system: <a href=\"http://micro.blog/brentsimmons\">http://micro.blog/brentsimmons</a>.</p>\n\n<p>And heres my microblog: <a href=\"http://brent.micro.blog/\">http://brent.micro.blog/</a>. (Which you can read using RSS, whether youre on the system or not.)</p>\n\n<p>I wrote about three-quarters of my own single-user microblog system — and then stopped because I didnt feel like running a server and because Mantons service is so good.</p>",
"date_published": "2017-04-25T14:27:28-07:00"
},
{
"id": "http://inessential.com/2017/04/25/frontier_diary_5_values_and_progress_o",
"url": "http://inessential.com/2017/04/25/frontier_diary_5_values_and_progress_o",
"title": "Frontier Diary #5: Values and Progress on the Language",
"content_html": "<p>I put the <a href=\"https://github.com/brentsimmons/Frontier\">Frontier repository</a> up on GitHub.</p>\n\n<p>(The build is currently broken. This is bad discipline, but since its still just me, I forgive myself. Sometimes I run out of time and I just commit what I have.)</p>\n\n<p>The repo has my new code and it also contains <a href=\"https://github.com/brentsimmons/Frontier/tree/master/FrontierOrigFork\">FrontierOrigFork</a>, which is the original Frontier source with a bunch of deletions and some changes. The point is to give me 1) code to read and 2) a project that builds and runs on <a href=\"http://inessential.com/2017/04/03/frontier_diary_1_vm_life\">my 10.6.8 virtual machine</a>.</p>\n\n<p>The original code is in C, and the port is, at least so far, all in Swift. In the end it should be <em>almost</em> all in Swift, but I anticipate a couple places where I may need to use Objective-C.</p>\n\n<p>Heres one of the Swift wins:</p>\n\n<h4>Values</h4>\n\n<p>Since Frontier contains a database and scripting language, theres a need for some kind of value object that could be a boolean, integer, string, date, and so on.</p>\n\n<p>Original Frontier used a <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierOrigFork/Common/headers/lang.h\">tyvaluedata</a> union, with fields for the various types of values.</p>\n\n<p>This is a perfectly reasonably approach in C. Its great because you can pass the same type of value object everywhere.</p>\n\n<p>Were I writing this in Objective-C, however, Id create a <code>Value</code> protocol, and then create new value objects for some types and also extend existing objects (<code>NSNumber</code>, <code>NSString</code>, etc.) to conform to the <code>Value</code> protocol. This would still give me the upside — passing a <code>Value</code> type everywhere — while reducing the amount of boxing.</p>\n\n<p>But: this still means I have an <code>NSNumber</code> when I really want a BOOL. Luckily, in Swift I can go one better: I can extend types such as <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierData/FrontierData/Value/ValueBool.swift\">Bool</a> and <code>Int</code> to conform to a <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierData/FrontierData/Value/ValueProtocol.swift\">Value</a> protocol.</p>\n\n<p>This means passing around an <em>actual</em> <code>Bool</code> rather than a boxed boolean. I like this a ton. It feels totally right.</p>\n\n<p>Other topic:</p>\n\n<h4>Language Progress</h4>\n\n<p>Im still in architectural mode, where Im writing just enough code to validate and refine my decisions. A couple days ago I started on the <a href=\"https://github.com/brentsimmons/Frontier/blob/master/UserTalk/UserTalk/LangEvaluator.swift\">language evaluator</a> — the thing that actually runs scripts.</p>\n\n<p>It works as you expect: it takes a compiled code tree and recursively evaluates it. Its not difficult — its just that its going to end up being a fair amount of code.</p>\n\n<p>Ive done just enough to know that Im on the right path. (The Swift code looks a lot like the C code in OrigFrontiers <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierOrigFork/Common/source/langevaluate.c\">langevaluate.c</a>. See <code>evaluateList</code>, for instance.)</p>\n\n<p>The next step is for me to build the parser. I thought about writing a parser by hand, because it sounds like fun, and it would give me some extra control — but, really, it would slow me way down, so forget it.</p>\n\n<p>OrigFrontier generated its parser by passing a grammar file — <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierOrigFork/Common/source/langparser.y\">langparser.y</a> — to MacYacc (there was such a thing!), which generated <a href=\"https://github.com/brentsimmons/Frontier/blob/master/FrontierOrigFork/Common/source/langparser.c\">langparser.c</a>.</p>\n\n<p>Ill do a similar thing, except using <a href=\"https://www.gnu.org/software/b
"date_published": "2017-04-25T13:26:33-07:00"
},
{
"id": "http://inessential.com/2017/04/14/save_300_on_coccoaconf_next_door",
"url": "http://inessential.com/2017/04/14/save_300_on_coccoaconf_next_door",
"title": "Save $300 on CocoaConf Next Door",
"content_html": "<p>My pals at CocoaConf asked me to remind you that the <a href=\"https://twitter.com/cocoaconf/status/852898192035282944\">Early Bird sale ends in two weeks</a> for CocoaConf Next Door — the one taking place in San Jose during WWDC.</p>\n\n<p>Ill be there. At least in the afternoons.</p>\n\n<p>Check out the <a href=\"http://cocoaconf.com/nextdoor/speakers\">speakers list</a>. Yummy, chewy, nutty speakers list.</p>",
"date_published": "2017-04-14T13:53:02-07:00"
},
{
"id": "http://inessential.com/2017/04/14/frontier_diary_4_the_quickdraw_problem",
"url": "http://inessential.com/2017/04/14/frontier_diary_4_the_quickdraw_problem",
"title": "Frontier Diary #4: The QuickDraw Problem and Where It Led Me",
"content_html": "<p>In my fork of Frontier there are still over 600 deprecation warnings. A whole bunch of these are due to <a href=\"https://en.wikipedia.org/wiki/QuickDraw\">QuickDraw</a> calls.</p>\n\n<p>For those who dont know: QuickDraw was how, in the old days, you drew things to the Macs screen. It was amazing for its time and pretty easy to work with. Functions included things like <code>MoveTo</code>, <code>LineTo</code>, <code>DrawLine</code>, <code>FrameOval</code>, and so on. All pretty straightforward.</p>\n\n<p>These days we have Core Graphics instead, and we have higher-level things like <code>NSBezierPath</code>. QuickDraw was simpler — though yes, sure, that was partly because it did less.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>I was looking at all these deprecation warnings for QuickDraw functions and wondering how Im ever going to get through them.</p>\n\n<p>I could, after all, convert all or most of them to the equivalent Core Graphics thing. But sheesh, what a bunch of work.</p>\n\n<p>And, in the end, it would still be a Carbon app, but with modern drawing.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>So I thought about it from another angle. The goal is to get to the point where its a 64-bit Cocoa app. All these QuickDraw calls are in the service of UI — so why not just start over with a Cocoa UI?</p>\n\n<p>The app has some outlines (database browser, script editor, etc.), a basic text editor, and a handful of small dialogs. <em>And all of that is super-easy in Cocoa.</em></p>\n\n<p>Use an <code>NSOutlineView</code>, <code>NSTextView</code>, and some xibs for the dialogs, and were done. (Well, after <em>some</em> work, but not nearly the same amount of work as actually writing an outliner from scratch.)</p>\n\n<p>In other words, instead of going from the bottom up — porting the existing source code — I decided to start from the top down.</p>\n\n<p>I started a new workspace and started a new Frontier project: a Cocoa app with Swift as the default language.</p>\n\n<p>Then I looked at the existing source and thought about how to organize things. I came up with this:</p>\n\n<ul>\n<li>Frontier — App UI</li>\n<li>UserTalk.framework — the language</li>\n<li>FrontierVerbs.framework - the standard library</li>\n<li>FrontierDB.framework — the object database</li>\n<li>FrontierCore.framework — common utility functions and extensions</li>\n</ul>\n\n\n<p>I like using frameworks, because it helps enforce separation, and it helps in doing unit testing. And frameworks are so easy with Swift these days.</p>\n\n<p>Hardly any of this is filled-in yet. Ive got the barest start on FrontierVerbs. <a href=\"https://twitter.com/tedchoward\">Ted Howard</a>, my partner in all this, is taking UserTalk.framework and FrontierDB.framework.</p>\n\n<p>In the end, its possible that no code from the original code base survives. Which is totally fine. But it also means that this is no quick project.</p>\n\n<p>At this point I should probably put it up on GitHub, since its easier to write about it if I can link to the code. Ill do that soon, possibly on the weekend.</p>",
"date_published": "2017-04-14T13:14:20-07:00"
},
{
"id": "http://inessential.com/2017/04/13/frontier_diary_3_built-in_verbs_config",
"url": "http://inessential.com/2017/04/13/frontier_diary_3_built-in_verbs_config",
"title": "Frontier Diary #3: Built-in Verbs Configuration",
"content_html": "<p>Frontiers standard library is known as its built-in verbs. There are a number of different tables: <code>file</code>, <code>clock</code>, <code>xml</code>, and so on. Each contains a number of verbs: <code>file.readWholeFile</code>, <code>clock.now</code>, and so on.</p>\n\n<p>Most of these verbs are implemented in C, in the kernel, rather than as scripts. At the moment, to add one of these kernel verbs, you have to jump through a few hoops: edit a resource, add an integer ID, add to a switch statement, etc. Its a pain and is error-prone.</p>\n\n<p>So I want to re-do this in Swift, because Im all about Swift. And I want adding verbs to be fool-proof: I dont want to remember how to configure this every single time I add a verb. Adding a verb needs to be <em>easy</em>.</p>\n\n<p>My thinking:</p>\n\n<ul>\n<li>Give each table its own class: ClockVerbs, FileVerbs, etc.</li>\n<li>Have each class report the names of the verbs it supports. These need to be strings, because we get a string at runtime.</li>\n<li>Run a verb simply by looking up the selector, performing it, and returning the result.</li>\n</ul>\n\n\n<p>To make things easy and obvious, I think it should work like this: the selector for a given verb is its name plus a parameter. Then theres not even a lookup step.</p>\n\n<p>Each verb will take a VerbParameters object and return a VerbResult object.</p>\n\n<pre><code>dynamic func readWholeFile(_ params: VerbParameters) -&gt; VerbResult\n</code></pre>\n\n<p>The flow goes like this:</p>\n\n<ol>\n<li>We have the string <code>file.readWholeFile</code>.</li>\n<li>We see the <code>file</code> suffix and so we know we need a <code>FileVerbs</code> object.</li>\n<li>We check <code>fileVerbs.supportedVerbs</code> (an array) to see if <code>readWholeFile</code> is in the list. It is.</li>\n<li>We construct a selector using the <code>readWholeFile</code> part of the string and we add a <code>:</code> character: <code>NSSelectorFromString(verbName + \":\")</code></li>\n</ol>\n\n\n<p>This is great! Were almost home free. Then we run the verb:</p>\n\n<pre><code>if let result = perform(selector, with: params) as? VerbResult {\n return result\n}\n</code></pre>\n\n<p>That doesnt work. We get:</p>\n\n<pre><code>Cast from 'Unmanaged&lt;AnyObject&gt;! to unrelated type 'VerbResult' always fails\n</code></pre>\n\n<p>Nuts.</p>\n\n<p style=\"text-align:center\">* * *</p>\n\n\n<p>It was <em>so</em> close.</p>\n\n<p>In Objective-C this would have worked. And obviously, apparently, I still think in Objective-C.</p>\n\n<p>I investigated some other options. At one point enums were abused, because theres <em>always</em>, in Swift, an enum-abuse step. But everything I tried was more code and was more error-prone, and my goal here is to improve the situation.</p>\n\n<p>I think, in the end, Im going to do something that looks kind of ugly: a switch statement where the cases are string literals.</p>\n\n<pre><code>switch(verbName) {\ncase \"readWholeFile\":\n return readWholeFile(params)\n\n}\n</code></pre>\n\n<p>Nooooo! you cry. I hear ya.</p>\n\n<p>My experience as an object-oriented programmer tells me this: if I write a <code>switch</code> statement, I blew it.</p>\n\n<p>And my experience as a programmer tells me that string literals are a bad idea.</p>\n\n<p>But the above may actually be the easiest to configure and maintain. Each string literal appears only in that one switch statement and nowhere else in the code. And the mapping between a verb name and its function couldnt be more clear  its right there.</p>\n\n<p>(Yes, instead of using a string literal, I could create a String enum and switch on that. But thats actually more code and more room for error. Im going to have to type those string literals <em>somewhere</em>, so why not right where theyre used?)</p>\n\n<p>It does mean that <code>readWholeFile</code> appears three times in the code (the string literal, the call, and the function itself), and in an Objective-C version it would appear only twice (in
"date_published": "2017-04-13T22:25:41-07:00"
},
{
"id": "http://inessential.com/2017/04/11/frontier_diary_2_two_good_ideas_that_a",
"url": "http://inessential.com/2017/04/11/frontier_diary_2_two_good_ideas_that_a",
"title": "Frontier Diary #2: Two Good Ideas that Arent Good Anymore",
"content_html": "<p>Strings in <a href=\"http://inessential.com/2017/04/03/frontier_diary_1_vm_life\">Frontier</a> are usually either Pascal strings or Handles.</p>\n\n<p>You probably dont know what Im talking about. Ill explain.</p>\n\n<h4>Pascal Strings</h4>\n\n<p>Frontier is a Mac Toolbox app thats been Carbonized just enough to run on OS X. You may recall that the Mac Toolbox was written so long ago that the <a href=\"https://developer.apple.com/legacy/library/documentation/mac/pdf/MacintoshToolboxEssentials.pdf\">original API</a> was in Pascal. That Pascal heritage lived on in many ways, even after everyone switched to C — and one of those ways was Pascal strings.</p>\n\n<p>A Pascal string is n bytes long, and the first byte specifies the length of the string, which leaves the rest of the bytes for the actual string. <code>Str255</code> was probably most common, and certainly is most common in Frontier, but there are also smaller sizes: <code>Str63</code> and <code>Str31</code>, for instance.</p>\n\n<p>Unlike C strings, theyre not zero-terminated, since theres no need to calculate the length: you always know it from that first byte.</p>\n\n<p>You create a literal Pascal string like this…</p>\n\n<pre><code>Str255 s = \"\\pThis is a string\";\n</code></pre>\n\n<p>…and the compiler turns the <code>\\p</code> into the correct length (16 in this case).</p>\n\n<p>Now, I bet youre saying to yourself, “Self, those Pascal strings are too small to be useful.”</p>\n\n<p>But consider this: every menu item name can fit into a Pascal string. You can fit a window title or a file name into a Pascal string (in fact, memory suggests that file names were even shorter, were <code>Str31</code> Pascal strings). Any label or message on any bit of UI is probably short enough to fit into a Pascal string. (Especially if you assume English.)</p>\n\n<p>So for GUI apps these were terrifically useful, and the 255-byte limit was no problem. (You can fit a tweet in a Pascal string, after all, with a bunch of room left over. [Well, depending on the size of the characters.])</p>\n\n<p>Frontier still uses them internally a ton. (For some reason, in the Frontier code, <code>Str255</code> strings are called <code>bigstring</code>, which sounds ironic, since theyre so small, but I think it was to differentiate them from even smaller Pascal strings such as <code>Str31</code>.)</p>\n\n<p>You might ask what the text encoding was for these strings.</p>\n\n<p>“Text whatzit?” Id reply. “Oh, I see. Just regular.” (<a href=\"https://en.wikipedia.org/wiki/Mac_OS_Roman\">MacRoman</a>.)</p>\n\n<p>It was a good idea, but its time has come and gone. We have better strings these days.</p>\n\n<h4>Handles</h4>\n\n<p>Frontier includes a scripting language and a database, which means it certainly has a need for strings much larger than 255 bytes.</p>\n\n<p>It also needs heap storage for other things binary data, structs, etc. that could be much larger than 255 bytes.</p>\n\n<p>Enter the Handle. A Handle points to a pointer <em>that might move</em>: the memory you access via a Handle is <em>relocatable</em>.</p>\n\n<p>Which sounds awful, I know, but it was a smart optimization in the days when your Macs memory would be a single-digit number of megabytes, or even less than that.</p>\n\n<p>Heres the problem: your applications heap space can become fragmented. It could have a whole bunch of gaps in it after a while. So, to regain that memory, the system could compact the heap  it would remove those gaps, which means relocating the memory pointed to via a Handle.</p>\n\n<p>This is better than running out of memory, obviously. But it means that you have to be careful when dereferencing a Handle: you have to actually lock it first <code>HLock(h)</code> so that it cant be moved while youre using it. (And then you unlock it <code>HUnlock(h)</code> when finished.)</p>\n\n<p>Handles are also resizable <code>SetHandleSize(h, size)</code> and resizing a Handle can result in it need
"date_published": "2017-04-11T13:01:55-07:00"
},
{
"id": "http://inessential.com/2017/04/05/two_little-known_and_completely_unrelate",
"url": "http://inessential.com/2017/04/05/two_little-known_and_completely_unrelate",
"title": "Two Little-Known and Completely Unrelated Facts",
"content_html": "<p>One. <a href=\"https://www.omnigroup.com/omnioutliner\">OmniOutliner</a>s outline view is implemented as CALayers rather than as a view with subviews. (I dont think Im giving away a trade secret here.)</p>\n\n<p>Two. If you eat fenugreek, your <a href=\"https://www.theatlantic.com/health/archive/2010/06/the-mystery-of-the-maple-syrup-smell/57980/\">armpits will smell like maple syrup</a>.</p>",
"date_published": "2017-04-05T16:57:59-07:00"
},
{
"id": "http://inessential.com/2017/04/05/ios_javascript_and_object_hierarchies",
"url": "http://inessential.com/2017/04/05/ios_javascript_and_object_hierarchies",
"title": "iOS, JavaScript, and Object Hierarchies",
"content_html": "<p><a href=\"http://iam.fahrni.me/2017/03/25/scripting-ios/\">Rob Fahrni</a>:</p>\n\n<blockquote><p>Given x-callback-url and App URL schemes in general it would be extremely cool to use those to create object hierarchies using JavaScript. Why JavaScript? Well, its native to iOS and applications can use the runtime.</p></blockquote>",
"date_published": "2017-04-05T14:53:01-07:00"
},
{
"id": "http://inessential.com/2017/04/05/cocoaconf_near_wwdc",
"url": "http://inessential.com/2017/04/05/cocoaconf_near_wwdc",
"title": "CocoaConf Near WWDC",
"content_html": "<p>There are a bunch of things happening near WWDC this year. Me, Ill be at <a href=\"http://cocoaconf.com/blog/nextdoor\">CocoaConf Next Door</a>. Im not preparing a talk, but Ill probably be on a panel. And hanging out.</p>\n\n<p>Check out the <a href=\"http://cocoaconf.com/nextdoor/speakers\">speakers list</a>, which includes Omnis own <a href=\"http://cocoaconf.com/nextdoor/speakers/162\">Liz Marley</a>. And a bunch of other people you totally want to see — Manton Reece, Jean MacDonald, Laura Savino, and plenty more.</p>\n\n<p>Also… <a href=\"http://altconf.com/\">AltConf</a> and <a href=\"https://layers.is/\">Layers</a> will be near WWDC. If you could be in three places at once, you would. Well, four, including WWDC itself, I suppose. :)</p>",
"date_published": "2017-04-05T14:35:05-07:00"
},
{
"id": "http://inessential.com/2017/04/05/omnioutliner_5_0_for_mac",
"url": "http://inessential.com/2017/04/05/omnioutliner_5_0_for_mac",
"title": "OmniOutliner 5.0 for Mac",
"content_html": "<p>Ive been on the OmniOutliner team for over a year now. Though we dont have positions like junior and senior developer, I enjoy calling myself the junior developer on the Outliner team, since Im newest.</p>\n\n<p>I may be a new developer, but Im not a new user — Ive been using the app since the days when OmniOutliner 3 came installed on every Mac.</p>\n\n<p>Every time I start a talk, I outline it first. I organize the work I need to do in my side-project apps in OmniOutliner. And — dont tell the OmniFocus guys, who are literally right here — sometimes I even use it for to-do management in general. Id be lost without a great outliner.</p>\n\n<p>Anyway… <a href=\"https://www.omnigroup.com/blog/omnioutliner-5-is-now-available\">theres a new version: OmniOutliner 5.0</a>. Its my first dot-oh release at Omni, and Im proud of it and proud of the team.</p>\n\n<p>As is common with our apps, we have two levels: a regular level and a Pro level. The regular level is called “Essentials” and is just $9.99. Theres a demo so you can try it out first.</p>\n\n<p>It syncs with iOS and with other Macs, by the way. Sync is free. And of course it comes with extensive documentation, and Omnis awesome support humans are standing by.</p>\n\n<p><a href=\"https://www.omnigroup.com/omnioutliner/\">Get it while its hot</a>!</p>",
"date_published": "2017-04-05T10:44:45-07:00"
},
{
"id": "http://inessential.com/2017/04/03/frontier_diary_1_vm_life",
"url": "http://inessential.com/2017/04/03/frontier_diary_1_vm_life",
"title": "Frontier Diary #1: VM Life",
"content_html": "<p>Its been years since I could build the <a href=\"http://frontierkernel.org\">Frontier kernel</a> — but I finally got it building.</p>\n\n<p>Its really a 90s Mac app thats been Carbonized just enough to run on MacOS, but its by no means modern: it uses QuickDraw and early Carbon APIs. Its written entirely in C.</p>\n\n<p>I got it building by installing MacOS 10.6.8 Server in VMWare. Installed Xcode 3.2.6. And now, finally, I can build and run it.</p>\n\n<h4>What is Frontier?</h4>\n\n<p>Frontier — as some of you know — was a UserLand Software product in the 90s and 2000s. I worked there for about six years.</p>\n\n<p>The app is a development environment and runtime: a persistent, hierarchical database with a scripting language and a GUI for browsing and editing the database and for writing, debugging, and running scripts.</p>\n\n<p>The <a href=\"http://scripting.com/frontier/snippets/nerdsguide.html\">Nerds Guide to Frontier</a> gives some idea of what its like, though it was written before many of the later advances.</p>\n\n<p>Maybe youve never heard of it. But heres the thing: it was in Frontier that the following were either invented or popularized and fleshed-out: scripted and templated websites, weblogs, hosted weblogs, web services over http, RSS, RSS readers, and OPML. (And things Im forgetting.)</p>\n\n<p>Those innovations were due to the person — <a href=\"http://scripting.com/\">Dave Winer</a> — and to the times, the relatively early web days. But they were also in part due to the tool: Frontier was a fantastic tool for implementing and iterating quickly.</p>\n\n<h4>The Goal</h4>\n\n<p>The high-level goal is to make that tool available again, because I think we need it.</p>\n\n<p>The plan is to turn it into a modern Mac app, a 64-bit Cocoa app, and then add new features that make sense these days. (There are so many!) But that first step is a big one.</p>\n\n<p>The first part of the first step is simple, and its where I am now: mass deletions of code. Every reference to THINK_C and MPWC has to go. All references to the 68K and PPC versions must go. There was a Windows port, and all that code is getting tossed. And then Ill see the scale of what needs to be done.</p>\n\n<p>(Note: my repo is a fork, and its not even on the web yet. The code Im deleting is never really gone.)</p>\n\n<p>Im doing a blog diary on it because it helps keep me focused. Otherwise Im jumping around on my side projects. But if I have to write about it, then Ill stay on target.</p>",
"date_published": "2017-04-03T13:44:34-07:00"
},
{
"id": "http://inessential.com/2017/03/31/the_goal",
"url": "http://inessential.com/2017/03/31/the_goal",
"title": "The Goal",
"content_html": "<p>The goal isnt specifically impeachment and conviction. Its for Trump to leave office.</p>\n\n<p>The stretch goal is that he dies broke and in prison.</p>\n\n<p>But we could settle for him going down in history as our worst President, as the worst person ever to become President, with the name Trump held in less esteem than that of Benedict Arnold, with Trumpism — that pseudo-populist white nationalism for the benefit of the super-rich — thoroughly loathed and seen for the brutish scam that it is.</p>\n\n<p>I think there comes a point before an actual trial in the Senate where Republican leaders — in Congress, in the Cabinet, wherever — realize that Trump can no longer govern, and they tell him so and urge him to resign.</p>\n\n<p>And I think he actually does resign at that point. Hes been through bankruptcy, and hes shown that when theres no path to winning, hell take the easiest route out of the situation, the route that leaves him the most status. He doesnt have the stick-to-it-iveness to go to trial in the Senate: hed quit.</p>\n\n<p>I dont know what it will take to bring Republican leaders to this point. Their ongoing cowardice is the real scandal — when faced with a threat to our democracy, they play along because theyre hoping for some goodies.</p>\n\n<p>I dont think they get to this point unless the public gets to this point, and so I look to the approval polls. If it gets below 30%, its probably there because of further revelations in the Russia affair, and its probably at the point where even cowards feel safe in doing the right thing — even if only to save their own necks, which will need saving.</p>\n\n<p>But right now Speaker Ryan wont even replace Devin Nunes as chair of the house intelligence committee. So theres still a long way to go.</p>",
"date_published": "2017-03-31T13:47:44-07:00"
},
{
"id": "http://inessential.com/2017/03/25/my_cocoaconf_yosemite_2017_talk",
"url": "http://inessential.com/2017/03/25/my_cocoaconf_yosemite_2017_talk",
"title": "My CocoaConf Yosemite 2017 Talk",
"content_html": "<p><a href=\"http://cocoaconf.com/yosemite\">Yosemite 2017</a> was so great. It always is.</p>\n\n<p>Below is the rough draft of my first-night talk. A few notes…</p>\n\n<p>The actual spoken version is probably not even close to the text, which was written before any rehearsal, and of course its never my intent to memorize it exactly.</p>\n\n<p>The bit with Laura Savino was a quick three-chord rock medley. We both played acoustic guitar and sang. It went like this:</p>\n\n<p>B: Louie Louie, oh baby, we gotta go<br />\nL: Yeah yeah yeah yeah yeah<br />\nB: Louie Louie, oh baby, we gotta go<br />\nL: Yeah yeah yeah yeah yeah<br />\nB: I live on an apartment on the 99th floor of my block<br />\nL: Hang on Sloopy, Sloopy hang on<br />\nB: I look out my window imagining the world has stopped</br />\nL: Hang on Sloopy, Sloopy hang on<br />\n[Slight change of chords]<br />\nB &amp; L: Teenage wasteland, oh yeah, only teenage wasteland [repeated]</p>\n\n<p>Heres my <a href=\"https://www.youtube.com/watch?v=RzBz7p0A3-Y\">favorite video for Brimful of Asha</a>.</p>\n\n<p>During the Squirrel Picture interlude (slide #3) I told the <a href=\"http://inessential.com/2001/06/07/2001_06_07\">Squirrel Story</a>, which wasnt planned or recently rehearsed, but Ive told it often enough that it didnt really need rehearsal.</p>\n\n<p>I dedicated the performance of Hallelujah to <a href=\"https://twitter.com/dori\">Dori Smith</a>.</p>\n\n<p>The talk was meant to be about 20 minutes long. Afterward I went around the room with a microphone and each person introduced themselves. (The talks job is to be a first-night ice-breaker talk.)</p>\n\n<p>I spent about 10 hours on rehearsal for those 20 minutes.</p>\n\n<p>Heres the talk:</p>\n\n<h4>Slide #1: Three Chord Rock</h4>\n\n<p>Hi. Im Brent.</p>\n\n<p>Before I get started seeing my friend Brad Ellis reminded me of the most rock-n-roll moment of my life. Wheres Brad? Hi Brad. Anyway I was at a party at my friend Chriss house, and he let me borrow his guitar and do a sing-along. I think we did White Rabbit and Me and Bobby McGee and Hotel California.</p>\n\n<p>Well, heres the problem I have a hard time hanging on to a guitar pick. Especially after a few beers. So at one point the pick goes flying, and Im strumming with my fingers.</p>\n\n<p>But I had a hangnail, and it got a bit aggravated as I was strumming. At the end I noticed that there was my actual blood on the guitar. I felt bad about it, but Chris was gracious, of course, and I thought that right then: thats rock and roll.</p>\n\n<p>You can use this as metaphor. Bleeding? Keep right on playing. Maybe you wont even notice that youre bleeding, at least not until you stop.</p>\n\n<p>Chris told me later that the guitar cleaned up fine, so all was well.</p>\n\n<p>Okay. On to the actual talk</p>\n\n<p>I bet most of you have heard the phrase three chord rock n roll. Or have heard that rock is so great because you only need three chords.</p>\n\n<p>What you may not realize is that its even easier than that: its three specific chords. Always the same three chords.</p>\n\n<p>They might be in any key but theyre the first, fourth, and fifth. In the key of C, the first is C, the fourth is F, and the fifth is G. In the key of A its A, D, and E.</p>\n\n<p>And when a song <em>does</em> have more than those three chords, it has at least those three chords. Theyre the foundation for almost all pop and rock.</p>\n\n<p>One part of music is building tension and then resolving it. Ill demonstrate on guitar.</p>\n\n<p>[On guitar] Play the first .... and youre fine. Youre home. Play the fourth .... and theres a little tension. Not a ton, but some. But you want to go back to the first, to home.</p>\n\n<p>Then play the fifth ... and you have maximum tension. You definitely want to go back home to the first.</p>\n\n<p>So with those three chords you have everything you need to write a thousand songs.</p>\n\n<p>Now for a little demo, Id like to in
"date_published": "2017-03-25T11:55:21-07:00"
}
]
}