Archive for the ‘Using Amethyst’ Category

Amethyst’s Fate

Wednesday, June 20th, 2012

As mentioned in Beauty, a previous post, I’m shutting down Amethyst on the Internet. I’m my only current customer and it’s taking time and money to keep it running that can be better spent elsewhere. It may not be a viable commercial product, but it continues to be very useful to me. It is the major way I read news. If I can’t drop an RSS feed for some news/information source into Amethyst, I’m much less likely to read it regularly.

Development will be ongoing.  With just one user profile, direction is clearer and fewer tradeoffs need be juggled.  Rails 3 has outgrown my needs but Rails 2 is not getting any updates, bug fixes, or security fixes.  The first two I can deal with myself, but generally not the last.  On the Internet, that’s a problem.  On my own laptop, it’s a problem I can live with.

Padrino is a lighter weight Web framework built on top of Sinatra.  It’s somewhere around the functionality of Rails 1 when I started.  And I know Web frameworks better now so I can fill in most of the holes.  Some of the speed annoyances of Rails 2 are gone on Padrino.  Or at least on the partial conversion to Padrino already done.

I’ve considered open sourcing Amethyst, however as noted in Beauty, much of the code is not something I’m proud of.  Unless there is a request, I won’t publish it.  I am working on making the Padrino port code I can be proud of and am willing to show in public.  Currently it is running in split mode, the backend that reads the subscribed RSS feeds is the old Rails 2 code.  The front end is partially ported to Padrino.  I’ll push it to GitHub when a minimal front end and complete backend are working in Padrino.

I’ll continue blogging here about the Padrino port.

Annoyances

Wednesday, June 13th, 2012

Amethyst’s major and truthfully only user (me) values speed.  (See Single Focus for additional design consequences of that value).  One of the annoyances is how long it can take to open up a feed with a lot of posts.  Currently they are cached so the second time it is a lot faster.  But that first time remains annoying.

Amethyst is over six years old, so Moore’s Law has noticeably helped, but my demands (i.e. number of feeds) and expectations have grown faster.

There are several possible ways to speed it up.  The Erubis rendering engine is faster than the original ERB rendering engine.  The improvement is incremental, something you need a stopwatch to see.  Switching is not a lot of work, but is not enough speedup.

Profiling did show that the Rails 2 url_for() method was using much of the render time.  It ties into the routing and is wonderously flexible.  The URL structure doesn’t need to have any resemblance to code structure.  I’d rather have the speed and live with a hard to change URL structure.  I’ve replaced most calls to url_for() by interpolated Ruby strings.

Another approach is to assume the user’s computer is faster and shared by fewer users than the server.  This is probably a good bet in general.  This takes more programmer work, is harder to test, and is more likely to bump up against browser incompatibilities.  I’ve done some research but not any coding yet.

The last possibility I’ve considered is pre-rendering, doing the HTML rendering ahead of time and storing the result in cache (i.e., in memory) or on disk.  Rails is not set up to make this easy, but it is doable.  With pre-rendering to cache/memory, the first time opening a large feed is as fast as the current design’s second time.  But it doesn’t scale well – keeping tens of thousands of posts in memory gets expensive fast.  Economical only for personal use or well-paying clients.  Pre-rendering to disk is feasible.  I may try that when I get more fed up with the slow speed than anything else on the implementation backlog.

Amethyst Server Shut Down

Wednesday, June 13th, 2012

No one but me has used the Amethyst server on the cloud for months so I pulled the plug.  It was costly me time and money that is better spent elsewhere.  I continue to use it personally for the bulk of my news reading.

I have plans to clean it up, update the Web framework it used (Rails 2 to Padrino), make both the UI and the code beautiful, and open source it.

Single Focus

Wednesday, June 6th, 2012

Amethyst supports one pane, two pane, and three pane views.  (A pane is a section of the page that moves and updates independently of the other parts.)  Casual users have expressed a preference for the three pane view.  (The two pane view came later and the users mentioned were already set in their preferences by then.)  Most e-mail and RSS readers use two or three panes, so they have the advantage of familiarity (i.e., no learning curve).

The two and three pane views require shifting focus.  Click on a feed in the left pane, shift focus to the (top) right pane to see its contents.  Click on a post title and shift focus to the bottom right pane to see its contents (three pane only).

In the one pane view, new content revealed by clicking on a feed or article title appears right below the click.  No focus shift needed.

The way the one pane view works, content is always surrounded by its context (article and feed lines), though scrolling may be required to reveal it.

Another common way to handle one pane is to fill the pane with the current focus and show surrounding context in a fixed top or bottom line.

I find I strongly prefer one pane, I want to see as much of the current focus as will fit.  Amethyst’s one pane view was designed with this principle/preference in mind.

It seems unlikely that any user will routinely switch between one, two, or three pane views.  The main page can be simplified by moving the choice to the settings page.  However, how to let new users know that the choice exists is a To Be Solved problem.  RTFM isn’t a very good answer.

Beauty

Tuesday, June 5th, 2012

Amethyst is not beautiful.  The user facing Website is not beautiful, it’s functional.  The programmer facing code is not beautiful, it’s functional.  In places, it’s ugly.  Error handling code is almost always ugly.  Dealing with when things don’t go well is usually ugly.  Think divorces.  Ugly divorce or ugly bankruptcy is almost redundant.

Amethyst is functional.  That’s not suprising, I’m an engineer and functional and reliable are the top priorities for things engineers build.  There are beautiful bridges, think the Golden Gate.  But getting safely across, consistently, is a must have for a bridge.  Beauty cannot make up for a lack of functionality or reliability.  They are required to be in the running.

I am an information junkie.  I want to read it all, know it all.  If I let it, my mind will suck all the facts, trivia, data in sight and want more.  Mostly it sucks up dirt and dust.  The occasional diamond ring is enough to keep the habit going.

Amethyst is an info-junkie’s enabler and an info-warrior’s weapon of choice.  I can spend my days reading blog posts and news of trivia and stuff of only academic interest.  Amethyst is more than adequate for this task.

According to my wife, also an intellectual, but not a know-it-all in recovery, Amethyst is too complicated to use without classes.  To me there is so much more I could add to make it even more useful.

I’m afraid in trying to appeal to both of us, Amethyst has fallen into the Mediocre Middle, neither easy to use for the casual user, nor powerful and full featured enough for the professional.  The limited development effort is spread too thin and too much effort spent trying to appeal to two irreconcilable user profiles.

No one besides myself has used Amethyst on the cloud in over two months.  Monitoring it and investigating discrepancies from expected behavior is taking time that could be better spent.  So I will be taking it down soon.  Real soon.

Google Reader

Thursday, November 3rd, 2011

Google Reader is Amethyst’s most visible competition.  A new release has been rolled out recently that is getting a lot of mostly negative notice.  Chris Wetherell was the original developer of Google Reader.  He has posted some of his thoughts about the direction Google Reader is going on Google Plus here.

I think his statement, “Reader is (was?) for information junkies; not just tech nerds. This market totally exists and is weirdly under-served (and is possibly affluent).”, is correct, but I haven’t found how to reach those people.  In fact, I am seriously considering shutting down Amethyst on the cloud and keeping it as my secret weapon.  There are still some things for me to learn running in the cloud, so for the moment it is going to stay up.

Your Own “River of News”

Wednesday, October 19th, 2011

Dave Winer, one of the originators of RSS, blogged about reaching River2 1.0, his “River of News” aggregator. What is it good for? I’ll let him explain:

Who would find this interesting: news organizations and journalism schools. Operating a river is a way to automate news gathering in your sphere of interest, your community. And for J-schools, it’s a way to give your students a head start on the news system of the future, which will surely operate in this fashion. Imho of course.

I certainly agree a “River of News” on topics of your choice is a valuable resource. Not quite sure why it is restricted to news organizations and journalism schools. I expect installation takes some technical skill (pre-built packages are available for Windows and MacOS), but it isn’t rocket science or brain surgery.

“River of News” is just one of the ways of viewing your feeds in Amethyst (the others are feed, rather than post oriented, also valuable).

Steve Jobs Wannabee or Steve Jobs Disciple/Student?

Thursday, October 6th, 2011

My Twitter and RSS feed readers are full of eulogies for Steve Jobs.  As I mentioned in my previous post,
El Camino Real – The Royal Road of the Personal Computer Era, we both started our computer careers in the Silicon Valley, so there were various crossing of paths. Being cheap and not a follower of fashion, I’ve never actually owned an Apple product. With both the current and the previous laptops, the pro version of the Apple laptops have been in the running. As someone said, Web developers create Web apps on Macs that run on Linux. My work is more about running Web apps, so I run Linux. Like Matz, the creator of Ruby, I prefer Thinkpads. And I write technical articles as well as code. The consensus on the Computer Book Publishers e-mail list I was on, is the IBM Thinkpads have the best keyboards in a laptop. Lenovo Thinkpads are not quite as high quality, but still one of the best.

I have noticed lately that too much of my time is going into being informed about too many things.  And so there isn’t much time left to actually move Amethyst forward.  I need to focus.  Which means ignoring the siren call of the many posts, including the obits, eulogies, remembrances, etc. on Steve Jobs.  I can read everything about Steve, sitting at his feed, or I can focus on my life.
Universe Dented, Grass Underfoot points out rightly, that focusing on what matters is the best way to honor Steve Jobs.

Disappearing Checked Off Items

Tuesday, May 31st, 2011

My workload is largely task driven (as opposed to appointment driven like a family doctor).  So I use a number of TODO lists – on my smartphone and on my computer.  One thing that bugs me is tasks that disappear when checked off.  Poof, all my work disappears and is unacknowledged.  Bad for us workaholics trying to stay in recovery.  And given the vagueness of gestures on touchscreen devices, not nice.  Several times I have had to go digging through the completed items to uncheck a wrong selection.

One of the weaknesses of Amethyst’s UI is short titled articles may lead to errors on clicking the correct delete box.  So now delete boxes on articles don’t immediately banish the article. It will be lined out.  Clicking the box again will undelete it.

And I’m working on a better solution to matching up short titles with their delete box besides alternating color bars.

Facebook Backtracks on RSS Feeds

Sunday, May 22nd, 2011

The (admittedly quiet) uproar about Twitter and Facebook moving away from supporting RSS feeds (e.g,
Twitter and Facebook Both Quietly Kill RSS, Completely) has had an effect. Facebook has put back links to the RSS feeds for public pages, see Facebook Listens. RSS Added Back to Pages. Will Twitter be next?. Thank you Facebook.

In comments to the earlier post, a Facebook engineer noted that developers prefer the JSON APIs.  True, and non-developers and non-Facebook specific apps are shut out by a proprietary API.  Both Facebook and Twitter are big enough that they might think that of course everyone will support their API.

Amethyst may support the Twitter API in the future, but we can support Twitter’s RSS feeds immediately.  RSS’s expected 1 hour refresh is not the best match for Twitter’s near real-time nature, but it is an easy first step.  I think of a ladder with doable distances between rungs and an easy first step.  Too many people think when they add another rung (“raising the bar”) they have to cut off the bottom rungs to do it.  Supporting RSS feeds is not terribly resource intensive.  I see little to gain by dropping legacy support and something to lose by excluding potential clients.

With RSS feeds, Amethyst can support Twitter immediately.  And we have a lot of work invested in reliable RSS in the face of timeout, redirections, not quite standard RSS/XML, etc.  Doing the same for just one non-RSS source is not inviting without some proven interest. The next rung is relatively easy, formatting the Twitter RSS feeds more like the typical Twitter client (i.e. no redundant title and description).  Straightforward, though not as easy as it looks; the changes reach half way through the Rails stack,from HTML templates almost all the way down to the database.  Moving to support of Twitter’s real-time nature and the Twitter native API requires changes all the way up and down the Rails stack.  It is made more inviting because several envisioned changes require the same deep changes.

Amethyst is over 5 years old.  Many reasonable current uses just didn’t exist back then, e.g. supporting smart phones and other mobile devices.