December 2013

I need to be able to override the automatically generated feed URL, so that people can confidently subscribe to the feed for the blog. The goal is to get the docs to settle down, so we can get into some kind of a routine.

So the URL for the feed is going to be this: http://fargo.io/blog/rss.xml

With the #opmlFeed directive I can tell the CMS to use this URL instead of the one it generates pointing into my dropbox folder.

12/29/13; 20:28PM

Choose the Settings command in the System menu at the right end of the menu bar. Click on the CMS tab. There's a new checkbox that allows you to enable the "watched" folder.

Screen shot.

In a few seconds a new folder is automatically created in your Small Picture folder called watched.

Copy an image into the folder. Wait a few seconds (as many as 11 or 12).

A dialog should appear with the URL of the image.

You can use it anywhere you would use the URL of an image. It doesn't even have to be in Fargo.

People who use the OPML Editor for content management will recognize the feature.

They don't have to be images. They could be MP3s, PDFs, whatever.

A picture of a slice of cheese cake.

12/29/13; 18:34PM
  1. Carefully follow the instructions on this page.

  2. When you set up the folder for your repo, make it a direct sub-folder of the Fargo app folder in Dropbox. This is important. It must have the same name as your repo.

  3. There's a new directive, #siteFolder, that allows you to tell Fargo where to store your files. This is how I set it up for the Kim Parker site: #siteFolder "scripting.github.io/kimParker/"

  4. When you're ready to try it out with Fargo content, render the whole site with the Render All Pages command in the File menu.

  5. Verify that the pages were rendered into the sub-folder of your github folder.

  6. In the GitHub client, click on Commit & Sync button. Screen shot.

  7. View the updates on your website.

12/27/13; 13:22PM

There are two new settings in Fargo, the default file name and file suffix.

They are initially index.html and .html, but the server system you use may require you to use different values. However for most applications you can leave them as-is.

You can access the settings dialog from the System menu in the right edge of the menu bar in Fargo.

12/16/13; 07:33AM

As part of the slow software movement, I'm taking my time with a new template I call medium because it is inspired by the template used on medium.com. There's a big picture at the top of the page, a title and a sub-head, followed by the body of the post.

The idea is that it's supposed to look good no matter what picture you put up there. And the bigger the better. And it should look good on a mobile device. And all the parameters come from the attribute hierarchy, so you can have global defaults, and override them on specific pages.

Anyway, enough hype, here's the beef...

Pointers
  • The template is in this outline.

  • This is the outline for my test site.

  • Here's an example page about Dick Van Dyke in Mary Poppins.

  • And another example -- about Bargniani, a player on the Knicks.

  • I was having so much fun I did another story about Clara Peller, the Where's The Beef lady.

  • Then Adam posted a picture on Twitter, I thought it would make an interesting page.

The text on the pages of course is purely silly. It's the container that's interesting.

12/15/13; 09:04AM

I recognized the pattern, there was spaghetti starting to envelop the CMS code.

This happens when you add special cases by adding boolean parameters to routines.

That happens because when you wrote the high level code you didn't fully understand the problem. This al ways happens. The question is did you leave yourself the room in the schedule and with regard to potential breakage to actually rebuild the code so it correctly achieves its purpose? Too often you can't go back and re-engineer it, and you live with the bad construction. Then the code is fragile its whole life, so you don't build new layers on top of it, or if you do they're either inefficient or missing obviously valuable features.

I decided to rebuild this time. The problem was confusion over how and when index files would be built. And how to link to them in the Next/Prev links.

What I realized was the code was optimized for minimizing the amount of stack building. When I got to that point in the rebuild, I added a cache, so the upper level code could be totally simple and natural. It worked!

Now the question is can I use the software for its intended purpose? I was able to do that before. Can I still do that?

12/03/13; 11:43AM

Last built: Mon, Jan 6, 2014 at 12:39 PM

By Dave Winer, Tuesday, December 3, 2013 at 11:43 AM.