|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
|
New radio2.root user-level pref -- flCanAddFeeds, if true, the user has a Feeds command in his or her menu, and the Feeds page is activated.
My linkblog, flowing to Tumblr.
Added two prefs on the Top-40 page, title and intro. You could set them previously by editing the template, but it didn't seem reasonable to force the user to reach in there to change something that almost every user would want to (eventually) change. Also we were truncating the post text at 100 chars on the Top-40 page. Must have been some early formatting thing that is no longer relevant. Disabled it. Visit the Top-40 page title, intro & template prefs page to see the result. Screen shot. More info on the support list.
I was always uneasy about what might happen if a user subscribed to a huge number of feeds, and the sysop didn't even know it was happening. I didn't think it would be a problem for a while, but then along comes an app that generates an OPML file for all the people a user follows on Twitter, and some people follow thousands of people, and all of a sudden in one hour, I've got thousands of new feeds on a server that previously was reading less than a hundred. You might wonder if the scaling profile of the server would change. Just being a little sarcastic there. This forced the issue on a Friday night when I had plans, so I just shut it down and let the problem roll around in my head a little. And I decided the Feeds command is something that, unless it's a very unusual situation with a very tight workgroup, should be something the sysop manages. He or she becomes like a DJ for the group. I don't see any other way it can work. You can still download and install River2 on your own machine. It was designed as a single-user tool. If there are problems with this approach, let's fix them. But Blork is workgroup software, and therefore requires a little leadership and management and responsibility to keep it running smoothly. If Adam wants to load up his blork with a thousand feeds, it's going to be his problem to fix. But it's kind of doubtful that most users would be sensitive enough to the issues of the server to make decisions on behalf of the group. Now, a technical note -- to change the pref, go to config.beaut.prefs.flUsersManageFeeds and set it true. But only if you've read this caveat and give it some thought.
New section in the Prefs area, Look & Feel, with a single page -- Custom CSS. You get a big text area where a huge bunch of editable CSS is placed. See the big caveat at the bottom. This is just for experimentation now. I have to do a review of the whole approach to CSS in here. So there will come a point where I will reset your CSS to conform to the changes. At that point the caveat will go away. Be forwarned. A screen shot shows what the prefs page looks like.
The Docs page gets an upgrade. Click on the Docs link in the menu at the top of the page. Instead of the instructions telling the user how to find the code to install the Bookmarklet, the code is in the page itself. Customized for the server the Docs page is running on. You also have a direct link to connecting with Twitter. There are screen shots and a Flickr page with a legend for each of the items. Now if anyone makes a serious effort to get informed upfront they can get to the core of what the product does in a few minutes. Believe it or not some people do read the docs. They tend to be the ones who use the product well. I've found that that people have a hard time catching on to the significance of the feed. So I'm calling that out a few times in a few ways.
Every time you make a change in Radio2 -- create a new post, edit an existing post, delete a post -- we set a bit in the user's table. Then, every hour we check all the users, and backup, in binary, the contents of the users table in S3 storage. Its a Frontier fttb file, whicn can be read by any version of the OPML Editor, Frontier or Radio (and then converted to whatever). It should be fairly low overhead, and should help make things safer for users. Passwords are removed before the backup. You'll see info about the backup in the Log and on the Links page. Another small change, I added an parameter at the end of the guid, so if you repost an item, it will be seen as having a different guid. I've been pushing links this way for a few days without any adverse effects reported.
There's an app that runs on all EC2-for-Poets installations that pings one of my servers once a minute. You can see a readout of the info it gathers on ec2phonehome.scripting.com. Today I added a feature that transmits info about each of the open databases. I forsee this may help in debugging problems, and noting when systems are starting to fill up, esp config.root. One of my EC2 servers has already hit the size limit (approx 2GB) on config.root. There are ways of dealing with these problems, but first we have to know they're happening. It's best to address them before the databases exceed the limit. However, in case you don't want to transmit this extra info, I added a pref that turns it off.
I have an app that maintains code listings for various parts of the OPML Editor ecosystem. This helps make searches work for our code, when I'm looking for something in the codebase, I can use Google. I'm now bringing that up to date to have listings for the new stuff. http://listings.opml.org/beaut/ http://listings.opml.org/feedhose/ http://listings.opml.org/radio2/ http://listings.opml.org/river2/ http://listings.opml.org/radioReallySimple/ Another round of performance-improving changes for River2. This time I added eTag support, so if a feed hasn't changed, and the server supports eTags (seems most of them do, based on my test) then we don't even have to download the whole feed, we just get the header. Along with a 304 return code. You can see how many 304s we're getting by watching config.river2.stats while a scan is running. I recommend watching it. I also did some testing today on number of threads, and how that effects performance. If you weren't worried about anything but the performance of your River2 scans, I'd recommend setting config.river2.prefs.maxthreads to 20. Beyond that you don't seem to get anything for adding more threads. But it is much faster with 20 than it is with 5. Also, if you're running Radio2 on your server along with River2, I wouldn't do any static building. Your machine is likely to become fairly unresponsive when it's doing that. Better to have a second machine for all the extras you want to run alongside your community, and keep your community user interface nice and zippy. Did some experiments with performance of River2 this morning, and learned a bunch. Made some changes based on what I learned. 1. New global river2 pref, the timeout for feed reading. It was defaulting to 30 seconds, I reduced it to 3 seconds. 2. Read the text of the feed before parsing it. Do a string-level compare. If no change, then we can skip all the XML parsing and looking at the items. We know in advance that we won't find any changes. If you look on your River2 log page you'll probably see a signficant performance increase in scanning. (The boost won't show up until the second scan after the update.)
A huge number of parts released for Radio2. About two weeks worth of work, getting both Radio2 and RIver2 in shape to be part of a unified interface that will be the next thing released (once everything shakes out with this release). I expect some breakage here, though I have been careful to avoid doing things that will cause breakage. Murphy's Law. It's even worse than it appears. You can always get a fresh version of radio2.root from the Tools Catalog page (off the Misc menu in the OPML Editor).
Lots of new parts released today, in two areas: 1. A new cookie-based membership system that's compatible with Radio2. 2. Performance boost for static page builds. We only build pages for users with changed feeds. There will still be problems logging onto sites remotely, the membership corner-turn isn't complete. That probably won't happen until Radio2 is fully released. But everything will be done with users in the future in River2. So if you want things to work properly, you'll need to create a user for yourself. We have an active mail list for the EC2-for-Poets project. We can help with River2 problems there. Sorry for the problems with membership, I'm going to get all this stuff sorted out asap.
For the last few days I've been working on integrating Radio2 and River2. Along the way I'm re-learning some things about River2. I want to write them down before I forget them. You guys need to know them too. 1. I've been suggesting that when you set up a River2 user, you set the urlReadingList element in the prefs table to point to the reading list and do all your work from there. This works great for fictitious users like east-village.org or wikiriver.org, but for real people, it's not the way to go. They can subscribe to a reading list just like they can subscribe to a feed, and that's the way to go. If you go the urlReadingList route, then all their subs have to go through that reading list. And their Feeds page won't work properly.
The user's password lives in members.root. Any other passwords are ignored. Eventually we will delete them so as not to confuse people. The user's blog data lives in config.radio2.users. And in the new scheme, when we access the user's Radio2 user data, we check to see if they have a table in config.river2.users, and if they don't, we create one for them. Initially, the new Radio2 user is subscribed to everyone else who uses Radio2 on this server, so it's a way to establish a workgroup around the community river on that machine. It gives you a reason to seek out interesting people to join you on your server. Further, each user has a Feeds page linked to from the menu at the top of the screen. It's River2 feeds page. They can subscribe to any feed they want to, whether or not it's on this server. Or any reading list. So you keep making new users the way we have been making them. The Howto's should continue to work. You create the new user in config.radio2, and it synchs with River2. 3. Everything is rendered through the "beautiful" template. 4. Your home page has both the River and the edit box. And each item in the River has a RT link, and it works. The bookmarklet works too.
There's now a new user command that you can enter through the web. It only works for a specially designated user. If you go to config.radio.prefs.userWhoCanCreateNewAccounts and enter your username, you will now see a New User command in the menu. The page it takes you to has a form, asking for a username and password for the new user. There is no confirmation. If you are not the special user if you try to jump to the page you get an error message.
These scripts are called at the end of the build of the feed. Each script can return a XML namespace declaration or the empty string. Two parameters are provided, the address of the user's table and the feed that's being built. If something is returned it is added to the <rss> element where namespace declarations go.
Over the weekend I worked on my rssCloud server. One little-known feature -- it produces a changes.xml of all the feeds it has been notified about. This is the format that was used by weblogs.com back in the day. Re-released code that implements the Radio2 API, which is documented with examples. It ships turned off by default. To turn it on, set config.radio2.prefs.apiEnabled to true.
The new thing in version 0.53 is the Docs command no longer points to the sad elephant. It now points to docs.
Updated the docs, made a few changes to the prefs.
Now I've got thumbs in the user interface on my machine, but I don't think everyone wants thumbs, and I think there might be other things we want to add-on in the future, so I figured out how to make this open-architecture, so I did.
It takes two parameters, both addresses. The first points to the place you will store the name of the element you want to add. The second points to the place you will store the HTML form element that you want to add to the form. Here's a screen shot of the callback I wrote that added the Thumbnail element. If you put a callback at that location that does what this does, your Radio2 installation will get a thumbnail element as well. Adam you will definitely want to do that. I've uploaded the code here. You can just download it on your server and install it. Important: the name of the HTML form element is significant. It's name must begin with extra. or it will be ignored. The second part of the name is where it will be stored in the post table. Because this element is called "thumbnail" it matches up with what buildRss is expecting for the location of a thumb, and it will generate, automatically, the MediaRSS element for a thumb. This all is very complicated, but the net-net is, if you put that script where it wants to go, it should "just work."
A bunch of changes in building RSS feeds. 1. Support for MediaRSS thumbnail elements. Works a lot like enclosures. If you look in the object database table for a post, if there's an element there named thumbnail, we generate a <media:thumbnail url="xxx" /> element, where xxx is the value of the thumbnail element. 2. If there's at least one thumbnail in a feed, we add a namespace declaration at the top of the feed, xmlns:media="http://search.yahoo.com/mrss/". 3. I ran my feed through feedvalidator.org and found a few things that needed fixing. 4. Some elements didn't have guids, because they didn't have links. So, I synthesize a guid. If this user created no more than one item in a single second, the guid is unique. These guids have isPermaLink false, because of course they are not permalinks. 5. Added microblog: prefix to sub-elements of microblog:archive. Note to Adam, you can now test for compatibility with my feed, which has a item with a media:thumbnail element.
When displaying the home page, if the title is not-empty, show the title/link/enclosure group. The user can collapse if he doesn't care. If the title is empty, don't show the title/link/enclosure group. BTW, this is how Twitter could add titles, links and enclosures without cluttering up the user interface.
I think I finally figured out how the home page should work. When you come in via bookmarklet, you see the text box, but no link box, no podcast box. You see the link though, in a new icon, next to the Submit button, which points to the place you're linking to. It's a favicon, which I really like. In a very small place, with a little color, it visually confirms where you're pointing. There's a new NEW! icon, that clears all the fields. Does the same thing as the Radio2 logo, but this is a little clearer why you'd want to do it. Okay now suppose you want to add an enclosure, link to something else, or edit the title. Click the link just below the text box on the left side, and down pops full-size edit boxes for all those things. We get to spread out because it stays hidden until you want it. Voila! If you add an enclosure, the image of an iPod is displayed. Still a little cleaning up to do, but I'm so sure this is it, I'm calling it v0.5. Fixed a bug where if you entered the "custom domain" as a domain (as most people would) the URL-shortener would fail. Now you can enter it as http://r2.ly/ or r2.ly or butt:/r2.ly It's bugs like this that inspire the disclaimer: "It's even worse than it appears." Updated the bookmarklet so it opens Radio2 in a new tab. Now when you're watching a video that you want to pass on you can keep listening while you write your tweet. To update, delete your old Radio2 bookmarklet. Go to the bookmarklet page in Radio2, re-install. Tuned up the URL-shortening section on the Prefs page so it doesn't test your credentials if you didn't change them. This was slowing down the page, and unnecessarily bothering the Adjix server and annoying Radio2 users. You can test, if you want, by: 1. Entering two passwords that don't match and hopefully seeing an error message. 2. Entering two passwords that match and are incorrect, and see if Adjix has a problem (it should). 3. Then correct the two passwords and get a green light from Adjix. 4. Then ignore the Adjix section, change something else, and have the page be faster and no spurious chat from the shortener section.
The first Radio2 callbacks. These are scripts the person running the server installs that run at pre-defined times. Sometimes what they return is ignored, other times they return values that are then used by Radio2 to modify or amend its actions. Radio2 callbacks are in config.radio2.callbacks. Each table contains any number of scripts that are run in sequence at pre-defined times. There are two new callbacks in this release, both of which add elements to RSS feeds. addToRssChannel callbacks return a string containing one or more XML elements that are added at the <channel> level of the feed that's being built. Two parameters are provided, the address of the blog and the address of the feed. addToRssItem callbacks return XML elements that are added to a RSS item. They take an additional parameter, the address of the item table. If you don't want to add anything to the feed, return the empty string. Here's a screen shot of a channel-level callback that adds a test element that's a random number between 1 and 1000.
We generate a static HTML version of every feed, as well as a static version of the Counts page. Until this release, the user had no way to change the look of these pages. Now there are two templates you can edit on the Prefs page. I've updated my public counts page with a sad elephant in the left margin. It's not necessarily great design but it proves the point that I can hack up the look of the page. A likely use of this feature is to add links to other pages on your site(s).
UI changes, designed to make it easier for a first-time user. Add a prompt to the home page -- Speak your mind... The user can change this, it's the (new) first item on the Prefs page. Also the Prefs page had errors for new users, people with one feed. Fixed. You can now set the title, description and language of your feed. The "podcast button" adds a lot of weight to the home page for the first-time user, and it's totally not obvious what it is, so I made its presence subject to a pref, default off. I will be sure to mention this in the docs, and when people ask on the mail list (or where ever) how to do podcasts with this stinkin software, you'll know to tell them to look in the Prefs page. When creating a new user from the menu command in the Tools menu, we now also publish the feeds and HTML rendering, basically everything. This way the white-on-orange XML icon and the TwitterFeed icon will show up on the home page the first time. You won't have to post something to see it. Makes screen shots for the docs make more sense. Saves having to explain something that really doesn't need to be explained.
Feed, Bucket and URLs menu items fold into Prefs. Added a link to the Docs page, a placeholder. Product name is in the title of every page Make the sign-in page elements bigger. Important: Requires updates to both radio2.root and opml.root.
This is a pretty big corner-turn, so there serious potential for breakage, so let's do this very carefully, step by step. members.root -- you should already see a file in your Window menu called members.root. This is where we're going to store membership data. When a person logs on, we'll check to see if they have an account, and if their password matches, and if so -- we return a cookie. WIth that token they can access all parts of the Radio2 site. So, our first goal is to get your Radio2 user names and password data to show up in the users table of the default group in members.root. 1. I just released to parts that should do that. 2. If you update radio2.root and wait a minute, then look in members.root, you should see something like this. Post something on the list if your members.root looks like this, or if it doesn't. Note that most of the data will remain in config.radio2.users. Only the passwords are being stored in members.root. Eventually we will delete the passwords in config.radio2.users.
Fixed a bunch of problems with URL-shortening, most notably, we now correctly interpret the top level shortener prefs. This means if, Adam or Donovan have accounts with Adjix, their users do not have to get them, unless they want to keep their data separate from Donovan's. Having this option is good -- it means no data lock-in. After updating, the thing to do is going to config.radio2.prefs.shortener and fill in the data by hand, the same data you'd fill into the form. Be sure to set enabled to true. To test it, create a new user, log on as that user (I use a different browser) and then try to post a link through the bookmarklet. If all works you should get a shortened URL. There's also a place to enter the customDomain in the URLs prefs panel. Jay, who I am getting ready for, uses jr.ly and I use r2.ly for my URLs. That's how you tell Radio2 to tell Adjix to not bother adding what it thinks the domain is to the URL. Another change, unrelated to URL-shortening is on the Counts page and all pages derived from it -- duplicate links are combined. If you linked to one thing more than once, it used to be you'd get more than one entry in the Counts page, giving a misleading impression that you were generating more traffic than you actually were. This showed up as I converted Jay's data -- he does this a lot (and he generates a lot of traffic).
I did a lot of lifting and moving this weekend, only to mostly put things back where they were. The goal is to figure out how to integrate Radio2 and River2. I have a pretty good idea of one approach that won't work at least without some fairly significant changes in River2, and I'm not working over there right now. However there is some integration in place between the two in the new release. 1. River2 is automatically subscribed to the OPML reading list for the Radio2 community. 2. There is a River2 user named radio2 who follows all the members of the community. 3. There is a River command in the Radio2 menu, but for right now it does nothing. Once filled in it will display the posts of the members of your community including your own. This river won't wait for the normal scanning to update for members of the community, there is a shortcut implemented. I tried putting the river on the home page of Radio2, but it isn't right. Radio2 is your editorial system. You need a place for that. There will be a connection between the two going the other way. You will be able to shoot a story from the river over to your edit box. The edit box might even be present at the top of the river. But I'm not ready to do that yet in a way that's fast and supportable yet. Important note: Watch for breakage here. A lot changed under the hood. Created a new AMI, ec2ForPoets4, and updated the tutorial and screen shots to reflect the change.
If you download this folder onto any Windows 2003 Server platform, running on Amazon, Rackspace, or in your living room, you will get the almost-full EC2-For-Poets experience. I don't upgrade any of the other components, so you're totally in the flow with this installed. http://static.opml.org/opmlEditor/poets/OPML.zip I produced this by: 1. Launch a new instance of EC2-For-Poets. 2. Compress the OPML program folder into OPML.zip. 3. Uploaded it to S3. 4. Tossed the instance. So it's a completely virgin folder. When the app launches it will get the latest parts. Added links to the archive for each feed to the Links page. It's still rough and needs touch-up paint, but the functionality is there. Bug fix: The HTML rendering wasn't accounting properly for items that have non-empty titles. An example of a feed with such items is my WikiLeaks feed and its HTML rendering. New "Feed" item in the menu, links to a page where you can set the title, description and language for the current feed (the one selected in the popup menu). If you only have one feed, and as a result no popup menu, you edit the settings for your only feed. Added logging code to the GetCount process, which also rebuilds the embed code JavaScript and the static top-40 list. Also logs errors.
Lots of new stuff today, all tied together by a new page, called Links. Maybe you've got a hazy picture of all the stuff we're storing in S3 on your behalf and on behalf of each user? Me too. And I was about to make it worse by storing more stuff. The new Links page shows you, in one place, where all your stuff is. Here's what you'll see on the page: 2. Links to the HTML renderings for each of your feeds. 3. A link to the static rendering of your Top-Links page. (This is new, it's a static rendering of your Counts page, but public -- you can share this with people who might be interested, like the people who follow you on a social network. Here's my Top-40 list.) 4. Embed code for your Top-Links. (This is not new, but it's the first time it's been in the user interface as a supported feature. Makes it possible to include your top links in the sidebar of your blog, or any other website, even a blog post or a comment.) 5. The community OPML reading list. (This is new, it's a list of all the feeds from all the users on your server. Plug it into an aggregator that understands reading lists, and you'll always be following every feed as they come online. River2 is of course such an aggregator.) You can get to the Links page from the menu at the top of the screen. There's one more thing I want to link into this page, but haven't done yet -- a link to a browsable version of your calendar-structured feed archive. That should go on the to-do list. Here's a screen shot of my Links page, this morning. Change on the Counts page. Instead of using date.viewDate to display the time element, just show the number of hours. Makes it easier to scan the table, which is how this page is read.
Refinements to the podcasting support added yesterday. 1. We now cache the size and type in the stats sub-table for each item, so I don't have to get them via HTTP every time the feed is rebuilt. Cut down on network traffic. 2. Released maintenence code that gets rid of empty or nil enclosure elements in post tables.
Just released an update that adds enclosure support to Radio2. There's a new element on the home page, right next to the box that shows the shortened URL. Click on the Browse button to select a file. The file is uploaded when you post the item, and linked into it, in the feed, with an enclosure element. It can then be picked up by any enclosure-aware reader, which of course includes River2. Finally, and once again -- I have a way to manage podcasts that doesn't completely suck. Unfortunately for people reading this stuff in Twitter, it doesn't at this time, have the ability to tune into podcasts. PS: Here's the archive of my feed for today with some enclosures in it.
This is where we turn a corner, and the username/passowrd system of River2 and the OPML Editor become one and the same. If you're in doubt about what your username and password are on your server, look in opmleditor.prefs.security. The username/password part of the River2 prefs page has gone away.
1. Edit your River2 prefs from the server machine. 2. Edit the OPML Editor prefs from the server machine.
Once we've verified that this works for everyone, the next step is to figure out exactly how this impacts the startup process for virgin OPML Editor users (it should either leave it unchanged or simplify it). After that, the next goal is to have Radio2 get its username and password info from the same place. The data for each user will still be stored in individual "user" tables, at least for now. But it's important to have only one password for each user on each server. Bottom-line, River2 no longer has its own password for the "main" user. Other users still use their original passwords. Radio2 is not effected at this time (that's coming up soon).
New -- when you post a new item or after editing an existing item, as we build the RSS feed, we also build an HTML archive. If your feed is located at http://yourserver.com/bull/linkblog.xml, your HTML linkblog will be at linkblog.html. The prefs are located in a new sub-table of the feed's prefs table. It's linked to from the <link> element in your RSS feed. Here's my HTML linkblog. Added <microblog:archive> at the head of the RSS feeds produced by Radio2. See my feed for an example. Screen shot.
Until now the OPML Editor borrowed its security prefs from river2.root. Not, long-term, a good approach. Now there is a security prefs page in the OPML Editor prefs system. http://127.0.0.1:5337/opmlEditor/prefs?page=1.3 It should be familiar to anyone who as set up River2 or for that matter Radio UserLand. River2, however, does not at this moment use these security settings. That's the next step. On Twitter, Les Orchard asked if there was a way to synch a folder with S3 using the OPML Editor. There is! I have it running here on my desktop. Works like a charm. (And thanks to Les for writing the first version of the S3 glue. Never could have gotten it going without his help.) I just released a new version of Prefs for the OPML Editor that allows you to turn it on and configure it from the browser. Choose Update opml.root from the File menu to get the update now. You can access the prefs page from this URL on the local machine. I'm working on a howto right now that explains what each of the fields means. If you have more than one feed you'll have a popup menu above the text box. Now, when you choose an item from the popup menu, you'll see the contents of the feed you've chosen in the history part of the home page.
Just released code that keeps a Javascript "include" file current with the top 40 links as shown on the Counts page. This makes it possible to include the links in the sidebar of your blog for example, as I do. Screen shot. The include file appears in your S3 storage, one for each user. On my server, my file lis located here. It will be in the analogous place on your server.
Obviously, you want to substitute your url in place of mine. If you're running a Scripting2 blog, you can plug the script right into the blogroll editor. Screen shot. I also made it much easier to write static files so there will presumably be more stuff like this coming soon. The relevant code, for those of you interested in the code, is in radio2suite.writeStaticFile.
Works like the Top 40 pages that Jay and I have. But built into this tool that can spread to thousands of users. More work on doing automatic cleanups. Cleanup is subject to a pref. Default on. When pipe characters show up in the title they usually separate the title in two. To the right is "overhead" and to the left is the content of the title. We remove everything to the left of the first pipe (if one is present). Add a period to the end of the title unless there is already a punctuation mark at the end (a question mark or exclamation point).
Short version: There's an update out that fixes the problem. The key was being able to reproduce the problem, which I was able to. This gave me a new confidence that I needed. As often is the case with "vexing" problems like this one, the problem is focusing your mind in a systematic way. Almost at once I realized the problem was that I wasn't doing passwords the way I usually do them using the prefs system I have, and then I remembered it was coded with the assumption that the password would be repeated in the form, and that special amazingly convoluted and arcane dance needed to take place, that of course wasn't taking place. I looked at the main prefs outline, opmleditor.data.outlines.prefs, for prior art, cribbed the code carefully as I always do with brittle stuff like this, and voila, it worked. Moral of the story: Server debugging is hard. It's even harder when you're deploying to servers you can't watch the code run in. This is a Fog Of War thing. I really made a mess of my last testbed, micro-skittles. Time to start a fresh one, so I can better test major updates like the last one I pushed through on radio2. Still learning how to develop for a community of EC2 users.
Suppose you're running an EC2 instance not just for the experience, but because you want to run a micro-blogging community. Here's a checklist of steps to take to set up your server, with links to the appropriate howtos. The goal is two-fold: 1. To help people get started. 2. Identify opportunities to simplify and connect. For example, there are too many user accounts to set up. Just one per sever would be nice. 1. Begin with the EC2 For Poets tutorial. Run through it and set up the server. 2. Set up your S3 preferences. 4. Connect with Adjix, set prefs on URLs page. 5. Do a post. Verify that the feed is correcly being built and the URLs are being shortened. If this all works, you're caught up with the people on the EC2-for-Poets mail list.
Added validation to the URLs prefs page in Radio2. It connects with Adjix and gets the counts and shortens a URL with your prefs. If both operations worked you get a green light. Began development of the titleNoise filter. When a title enters through the bookmarklet, it is run through this table. The goal is to remove the crap that sites add to the titles of their story pages on a site-by-site basis. There will eventually be a way for users to add functionality to this, but first I have to get a feel for how it works. Your menu in Radio2 should say version 0.28. Add column to the home page showing the short code for the story. Shorten URLs that are entered manually, not through the bookmarklet. Bug: In main we refer to adrdata^.prefs.shortener.enabled, but it's really adruser^.prefs.shortener.enabled that matters.
It was time to make the RSS archives actually work. If you go to the place where you store your RSS on S3, you'll see there's a calendar-structured folder hierarchy, each with a copy of your posts for the day. From now-on it will maintain that structure, automatically, as you post. I just pushed the changes for this rewrite, and set the version to 0.30. Observation: The cool thing about Radio this time around is that I don't have to run an xmlStorageSystem for everyone. These days Amazon S3 is easy enough for people to set up and run themselves. All-around things have gotten better. Plus I have FIOS at home. I'm going to be more diligent about posting change notes here.
There was a lot of confusion in my mind about what TwitterFeed was doing with the URLs as they were handing them off to Adjix. These were already-shortened but I guess TwitterFeed didn't know that. And they were pushing some awful junk on the end of the URLs and someone was getting confused for some reason. However it turns out I had a much bigger bug that explained a lot more of the confusion and once I fixed that one, things started working. So, happy ending. I hope. Anyhow, the big change is this -- there's a new command in the menu called URLs It takes you to a hopefully self-explanatory prefs page where each user must enter his or her information about Adjix, if you want us to shorten URLs. The system-wide prefs only matter as a last resort, and I'm not even sure how that would work. So please visit that page, enter your info. If necessary visit Adjix before. The big payoff of this feature are the read-counts in the history list. Nice feature to have.
This may seem really niche now, but when this stuff becomes mainstream there will be questions about it.
I say description. Because a title wouldn't be edited in a multi-line box. A title fits on one line. This is an issue when coming to my minimal blog editor from the bookmarklet. The user is looking at a story in the browser and decides to link to it from his feed. Without selecting any text, he clicks on the bookmarklet. Where should the page title go in the form? So, here's what I do when my.reallysimple.org is invoked by the bookmarklet. 1. If a description and a title are provided, no controversy, both fields in the dialog are filled with their corresponding data. This means the user selected some text in the page before clicking on the bookmarklet. 2. If there is no description, but there is a title, I swap them -- putting the title where the description is, and emptying out the title. This gives the user the most Twitter-like experience. I checked, and this is not a problem for TwitterFeed, it's just not the default. You have to set it up so that it grabs the description from the item instead of the title. It could do this a little neater, and just take the description if the title is empty. I'm going to make that suggestion. (Consider it suggested.)
Did an overhaul of listings.opml.org today. Updated RSS rootupdates code to implement a callback after each object is read. When that happens, one of my servers rebuilds the listing page for that object. Also reduced the site to just the system.verbs table and River2 and Scripting2. I'll probably add back in each of the major roots over time. I needed to simplify to make the rewrite approachable. Got rid of the index files in each directory and just use Apache to navigate the hierarchy. It works better and requires less maintenence. Improved the sitemap.xml files in each of the folders so that they actually reflect the moddates of the verbs. An example. Minor updates to rootupdates.update and a new verb, rootupdates.docallback.
|
 |
Previous / Next
