Userscripts.org Blog

Progress

Sun, 25 May 2008 07:00:35 -0000

Implemented several requests and am planning several other features/fixes thanks to your input.

I think the new feedback tab has worked out pretty good. I dislike that it requires a new user account with uservoice (the service that I'm using), but it was much quicker than implementing the service myself, allowing me to focus on fixing the site.

So far the fixed list includes:

unmonitoring of topics in the forum works
don't allow flash embeds in comments/forums
show the time a userscript was uploaded as well as the last update time
fixed logged exceptions rails plugin so admins can see when issues occur
comments are editable
users can delete their own comments
comment creation/editing uses forum bottom box style
a link to add a comment at the top of the userscript's comment list
updated links to beast (forum software) and famfamfam (icons)
remove users who haven't verified their email (unactivated) after 3 days
expose comment feed on userscripts page
expose feeds of updates to your favorite scripts and comments on all your scripts (see /users/me after you login)

I plan to keep fixing things as fast as possible, so keep telling me what needs fixed.

Feedback Redux

Mon, 12 May 2008 06:34:37 -0000

The site has been stable for a while, now lets start improving it.

Hi guys. My name is Jesse, and I apologize. I haven't been as responsive as I should with dealing with issues on the site. To that end I've integrated a service called uservoice that will help me build what you say is missing from userscripts.org!

Our feedback page at uservoice allows you to add issues and vote on which are the most important.

Hotlinking of Unlisted Scripts Disabled

Sun, 27 Jan 2008 13:10:34 -0000

Disabling hotlinking for unlisted scripts means they cannot be used in bookmarklets.

Scripts that are marked as unlisted are no longer hotlinkable.

To install them you MUST visit the script's userscipts.org page, where a unique link to the script is generated for each visitor. If you try to get the source of an unlisted script using a URL like http://userscripts.org/scripts/source/20989.user.js, you are given a 403 Forbidden page.

I've also posted a page about unlisted scripts. As we move forward this page will be updated (as will other pages about userscripts.org as we allow other users to edit them.)

Britt has implemented a badwords filter that will automatically unlist scripts that contain certain words (orkut or scrap for example). It will be activated Sunday. If you have a valid script that is unlisted due to the filter, contact us and we will relist it. This is an interim solution until we have the karma system in place.

UPDATE

The "dirty word" filter is in place. and it has been a day without having to review scrap all scripts! Instead I'm dealing with lots of emails from those users and having to explain disabling hotlinking doesn't break a Greasemonkey script - it breaks using it as a bookmarklet. So you script still works...

Script Reviews

Wed, 23 Jan 2008 10:52:33 -0000

The last straw happened this evening. Reviews are coming this weekend! Help plan them here.

The basics: unreviewed scripts CAN be installed by logged in users only... On the rails side I'll catch the request and send a 403 FORBIDDEN if the user isn't logged in.

Why? Because people are uploading scripts *cough* scrap all *cough* whose only purpose on the site appears to be a hosting service for them. They then use the userscripts as a component of a bookmarklet.

So - what does this mean?

Every script needs reviewed before it is public. If you are logged in you can see/install everything...

So, why has it taken this long? Well, the question I have is: Who determines if a script is acceptable? I neither can nor want to review hundreds of scripts a week. Obviously when a script is updated the changes will need to be accepted before they are public.

Are the reviewers a selection of a bunch of trustworthy users?

Do we make it so anyone can, but certain users have more weight (eg, the more karma you have the more your vote counts)? And add a delay between upload and acceptance if only "weak" users have rated it... giving time (a day?) for other users to see it and vote to reject?

UPDATE

I wrote this in utter frustration. After you comments and emails we implemented hiding of scripts with "dirty words" - see Hotlinking of Unlisted Scripts.

Communities Idea

Sat, 29 Dec 2007 04:09:22 -0000

Communities are what happens when tags grow up ;) Here is the current idea and some questions.

First, the "news" section of the site is now the "userscripts blog", and technorati is making me register it as a blog by doing this: Technorati Profile.

Ok, now that is out of the way, lets talk about Communities, with a capital C.

First, what do we hope to accomplish with communities?

I think the site is divided into two groups, developers and users. Right now there are ways to comment on individual scripts, and to have discussions in a global forum. This micro and macro discussions miss the sweet spot, which I think is discussions between users and authors of scripts in a general area.

I hope to add areas where communities can talk about how they are using scripts, ideas for scripts, and also developers talking shop about developing script.

To that end, a community is centered around a tag. This means the community might be about a specific site (twitter, gmail, facebook, ...), or around a general area (video, ads, books), or even a group of people who decide to use the same tag.

When viewing a tag page, logged in users will be able to click "create a community around this" which will allow them to fill in a description about the community. The community is then created, with two forums (users and developers), scripts list, and membership list. Anyone can join the group (all groups are going to be public at first, if we need to create private groups we can cross that bridge when we get there), and anyone can add their scripts to the group by tagging it with the communities' tag (all scripts tagged with the communities tag in the script list)

The description will be a wiki, where members can edit it (with history being maintained).

The major open questions to be determined before it is released that I have are:

1) how does a community add scripts that others wrote, since only the authors can currently tag scripts?

2) how does a community rank scripts? (so they can highlight the useful ones)

3) this is related to #2, but how can a community remove scripts they don't want that are tagged with their name?

I want to build these so the community members are in control, as the last thing I want is to moderate and judge hundreds of communities!

What questions / ideas do you have?

Vague Scripts

Tue, 25 Dec 2007 02:10:51 -0000

I've added the required code to the database, search engine, and user interface to support hiding of scripts, 1632 scripts so far. Also, you can flag a script as vague...

The 1632 scripts were mostly scrap all scripts. I've not gotten them all, but a good start.

Instead of deleting the scripts, since their are people using them (ugh), I've added a unlisted flag (like flickr's "NSIPA" - not shown in public areas), which removes the scripts from browsing, search, and other public areas. If you go to the script by url, or by visiting the owner's page and then view a list of their scripts, it will still be there.

I've also added an option to flag a script as vague. If the summary, description or title aren't useful to understand what the script is, then flagging it as vague will put it in a list for admins to determine if the script should be unlisted.

Features such as searching including unlisted scripts, and only showing unlisted scripts is still to come, but I wanted to make the site semi-useful again.

As always, ideas for how to make the site better are welcome :)

"Scrap All" Defense Plan

Sun, 23 Dec 2007 07:00:55 -0000

Now that the site has been upgraded to the current version of rails, I can move forward with making it so the "Scrap all" plague doesn't kill the site. This involves: 1) adding non-public flags to scripts so they don't get shown in public areas 2) adding a "group/community" feature

The Scrap All "attack" is relentless; the result being a denial of service attack against the regular users of userscripts.

I see 2 issues:

1) Making it so new/unwanted scripts don't flood the common area

The front page, and browsing of scripts has always sucked, but when you get a flood of unwanted scripts, the design flaws cause hte site to be non-functional. People have always uploaded personal/testing scripts, causing frustration, but the velocity at which scrap all keeps coming has pushed it over the top and requires a new design.

One part of my proposed solution would be the ability to mark scripts as "non-public." Those scripts would not be shown in: script search, the home page, browsing through the scripts page, or browsing by tags. They would still be visible at their url, and linked from the authors page. (and there will be the ability to choose "show all" which will include non-public scripts as well)

Phase 1 of this part of the solution would be taking flagged scripts and then admins using their judgement on if they should be hidden (eg, we don't want to hide a good script just because a single user voted to hide it). The purpose will be to hide all the scrap all, and other test scripts.

Phase 2 will be voting by the community. So when a script is down voted enough it will disappear from the public. I'm not sure the exact mechanics/rules of this yet. Discussion is welcome!

2) Making it easier to find scripts you want.

Even if we fix the problem of unwanted scripts appearing on the homepage, the site still is not very navigable.

To fix this I think creating "groups/communities", where scripts and discussions about the scripts can occur. These communities might be around a site (flickr, gmail, google, twitter, livejournal, orkut, ...), or they might be around a topic (better search, libraries, books, pictures).

Scripts can be added by members of the group. The group can choose what scripts they want, and what ones are hidden.

Discussion boards for both users, as well as about script development for the site.

Please discuss if you have opinions/ideas on how improving the experience!

Flagging spam / bad scripts

Wed, 28 Nov 2007 07:37:52 -0000

Userscripts.org has long needed a way to mark content (scripts/comments/...) as spam/malware/... Today the feature has been deployed!

The final push to deploy the Flag this as spam/malware is done.

It isn't perfect, not everything can be flagged yet (forum discussion for improvements).

Currently you can flag a script or comment as spam or malware.

Superior Searching

Sat, 20 Oct 2007 07:46:13 -0000

Searching for userscripts used to be slow and only search the descriptions. Now searching uses SOLR and searches names, summary, descriptions and source.

Searching on this site always sucked, for you and me... Every day I get a report of the the performance of the site (rails performance analyzer). I always see:

Slowest Request Times:
	ScriptsController#search took 69.622s
	ScriptsController#search took 64.092s
	ScriptsController#search took 55.131s
	ScriptsController#search took 49.324s
	ScriptsController#search took 48.399s
	ScriptsController#search took 47.859s
	ScriptsController#search took 45.436s
	ScriptsController#search took 44.657s
	ScriptsController#search took 43.686s
	ScriptsController#search took 42.745s

70 seconds for a search!!! That is bad for everyone - who wants to wait for over a minute for results, and I have to make it scale. Luckily the average search time is less than a second (here are the stats for the last day):

                                         	Count	Avg	Std Dev	Min	Max
ScriptsController#search:                   	12366	0.728	2.256	0.128	69.622

I had been hoping Henrik would have time to add acts_as_solr to the site since he is doing lots of cool stuff with it on other rails projects, but alas, he is busy. So I rolled up my sleeves, and released solr based search.

The search order is currently only ranked on the prevalence of the search in the document (ignoring number of favoritings, installs, comments, ...) but it is a start. Once this is stabilized adding better sorting shouldn't be too hard.

Now if only the front page didn't suck so bad... ;)

Happy Mongrels

Fri, 19 Oct 2007 01:41:04 -0000

Scaling userscripts.org has been a fun journey. Thanks to monit, it has become a much easier journey.

You may notice on the 16th, memory usage decreased dramatically. Userscripts.org had a problem, the code that generates those nice colorized views of the scripts leaks memory. Massive amounts of memory. I'm not sure if it is the fault of coderay, hpricot, something I'm doing or ... but trying to colorize 20KB userscripts makes mongrels (application servers for rails) grow by hundreds of megabytes.

For a long time I would log in periodically and restart everything so that the mongrels didn't grow to consume more memory than we have. I messed up a few times in the last couple months and the server would start swapping and the site go down.

Not any more. Thanks to monit, I've got some simple rules that will keep the dogs at bay.

I have 10 rules like this in my /etc/monit/monitrc:

check process uso_mongrel_4000 with pidfile /home/deploy/app/shared/log/mongrel.4000.pid
   group uso_mongrel
   start program = "/usr/bin/mongrel_rails cluster::start -C /home/deploy/app/current/config/mongrel_cluster.yml --clean --only 4000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /home/deploy/app/current/config/mongrel_cluster.yml --only 4000"
   if failed port 4000 protocol http
     with timeout 10 seconds
     for 2 cycles
     then restart
   if totalmem > 100 Mb then restart
   if cpu is greater than 60% for 2 cycles then alert
   if cpu > 80% for 3 cycles then restart
   if loadavg(5min) greater than 10 for 8 cycles then restart
   if 3 restarts within 5 cycles then timeout

The result is that every few hours, someone renders a page that causes mongrels to leak massive amounts of memory, but monit restarts them within a minute. Right now we are running 10 mongrels, so even if one is down, site performance isn't effected.

Deploying a new copy of the code is still easy:

Check new code to my local git repository
Push my changes to my git server
cap deploy

To keep capistrano and monit from fighting I needed to switch from palmtree using mongrel_cluster to restart to using monit. I updated my deploy.rb file removing palmtree and adding:

set :monit_group, 'uso_mongrels'

namespace :deploy do
  desc "Restart the Mongrel processes on the app server by calling restart_mongrel_cluster."
  task :restart, :roles => :app do
    sudo "/usr/sbin/monit restart all -g #{monit_group}"
  end
end

Now those are some happy dogs!

Server Upgrades

Tue, 03 Jul 2007 01:29:14 -0000

There have been a few hiccups in the last week userscripts.org as it has been moved to a new server, new http server, feeds have been deployed and a power outage.

There's been a lot of activity on userscripts.org lately (a lot of it behind the scenes).

New Server: Userscripts.org is hosted at serverbeach. The recent changes (new parsing and code highlighting specifically) substantially increased memory usage. Unfortunately the only choice was to upgrade to a new server (since the ram wasn't available for our current server). So, we are now on a faster box, with 3GB ram.

New HTTP Server: We've been using lighttpd for a while now. It has done a good job, but not perfect. The rules for being a reverse proxy, checking filesystem based cache, and serving static content were getting convoluted. Luckily Nginx (pronounced engine-x) is a great replacement.

Feeds: Fixing the above issues meant we could start rolling out features that might have caused scalability issues. There are 2 feeds per user (comments on scripts you've written and updates to your favorite scripts), and 1 feed per script (comments), which means we went from having a handful of feeds to tens of thousands of them.

Power Outage: There was a power outage sometime last night. :(