Bits and pieces
Jul. 22nd, 2008 09:05 amSunday, after getting home from the writers retreat, I failed at napping, and then went over to Darkside's, where I had trouble not falling asleep. I came home early, and found that Grandma had died. I spent the rest of the day very quietly. Today, after waking up, I started in on laundry once the power rates went down.
I have been attempting to tag somewhat more recent bits of my journal. This leads to retagging old bits, and merging older duplicate tags (by hand, ew, but at least I don't destroy Canada), and encountering some pretty entertaining stuff.
http://blamebrampton.livejournal.com/34875.html -- Punctuation Pixies!
http://amaliedageek.livejournal.com/279788.html -- did I link this before? This is the ending to Dr. Horrible that is not a tragedy. I think Joss writes fine tragedies, myself, but he also writes hilarious comedy. This can be somewhat problematic when the two get combined, for an audience who isn't ready for the juxtaposition.
http://atalantapendrag.livejournal.com/561439.html -- What might be crackfic is starting in the comments.
http://www.theregister.co.uk/2008/07/22/tesco_condom_cockup/ -- ways not to market.
I have been attempting to tag somewhat more recent bits of my journal. This leads to retagging old bits, and merging older duplicate tags (by hand, ew, but at least I don't destroy Canada), and encountering some pretty entertaining stuff.
http://blamebrampton.livejournal.com/34875.html -- Punctuation Pixies!
http://amaliedageek.livejournal.com/279788.html -- did I link this before? This is the ending to Dr. Horrible that is not a tragedy. I think Joss writes fine tragedies, myself, but he also writes hilarious comedy. This can be somewhat problematic when the two get combined, for an audience who isn't ready for the juxtaposition.
http://atalantapendrag.livejournal.com/561439.html -- What might be crackfic is starting in the comments.
http://www.theregister.co.uk/2008/07/22/tesco_condom_cockup/ -- ways not to market.
As you may have noticed, LiveJournal's limit on the number of entries that can be displayed in the /tag/foo view is now 1,000. It was 100 for a long time, and prior to that, it was something that now seems very extremely limited. Most people don't have to worry about having hit previous tag limits, because they don't post as insanely often as I do, so this whole post is going to be irrelevant to a lot of my readers.
When this change was announced in
lj_releases, the number one question I saw about this was: "So, I've got about 300 entries tagged 'bar', but I can't see them in /tag/bar; I can only see 100 -- what's wrong?" One of the things that was stressed in the
lj_releases post was the concept from this point on, which was what a lot of people with this question weren't picking up on, or weren't fully understanding.
If you haven't figured out how LJ's tag system works, this is completely confusing. The entries in the tag view are not searched out each and every time someone wants to look at a tag. They're modified if and only if someone saves a change to a tag. (
afuna demonstrated to me that merely opening an entry in tag edit mode and saving no-changes, or saving a change to a different tag on the same entry did not actually create a change in back entries of the specified tag that had fallen off the end of the tag-view, and now that I've thought about it for a while, I see why.)
The tag view acts like it's the result of a list of entries possessing that specified tag. It displays sorted in chronological order by the displayed date on the entry (something that was posted in 2002 and wasbackdated dated out of order to 1995 is going to display with the rest of the 1995 entries). ( Analogy. )
But wait! you say. It says that I have exactly 365 entries tagged with this tag. How can it keep an exact count of the number of entries I have tagged with this tag if it doesn't know exactly where all of them are? It counts them as they come in and go out. ( Explanation and analogies. )
Each tag is counted separately, and each tag counter and each tag view operates independently of each other. This can be annoying if you want changing one tag to re-tag the whole entry, but I could see how someone who has come to expect the current behavior could come to depend on it (say, editing a post that has fallen off the end of the apple tag view to add an orange tag, but without re-adding the post to the apple tag view at the expense of knocking a more recently tagged apple tag post off of the view).
What I would really like would be a re-tagging tool. It would be useful for anyone who has discovered that their entries have been tagged out of order, so that you have big chunks missing out of the middle of the tag view because the ones that should have been in the middle were tagged first and have fallen off first, or just people who have a lot of posts with a lot of tags and want to make sure that all of their entries were tagged and tagged in order. It wouldn't tag your entries for you; you'd have to do that, but once you had tagged them, it would go and tidy up their order, or make sure that your journal was taking full advantage of the new tagging limits.
The tool would go in from the chronological beginning of the journal and re-save all the tags on all the entries in chronological order. It would go in to edit the tags on that entry, cut the tags off from that entry, save the entry with no tags, paste the tags back on that entry, and save the entry once again fully tagged. It would have to be a polite bot, or I could see it being banned fast. It sounds like the sort of thing that LJ should offer as a paid service, so LJ can control the speed and make sure it isn't eating up resources. Like the entry security changer, it might only do a chunk at a time, and then e-mail the user when the whole process has been completed. It also sounds like it could be a risky thing; someone could lose all their tags if things weren't done right.
* I spent a fun and productive night experimenting with the exact practical limits of the tagging system at some point when the limit was 100. I was in IRC with the usual suspects, someone was curious, someone was bored, and I was the one who had over 100 entries in one tag. I wound up playing with my tags a lot that night. 100 entries was the smallest top-limit that we encountered when doing that, and it would occasionally show up to 120-ish entries, then reset back down to 100 entries, unless I was testing it wrong. Thus the tiny-binder-with-pages analogy, rather than a-clear-tube-full-of-marbles analogy.
When this change was announced in
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
If you haven't figured out how LJ's tag system works, this is completely confusing. The entries in the tag view are not searched out each and every time someone wants to look at a tag. They're modified if and only if someone saves a change to a tag. (
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
The tag view acts like it's the result of a list of entries possessing that specified tag. It displays sorted in chronological order by the displayed date on the entry (something that was posted in 2002 and was
But wait! you say. It says that I have exactly 365 entries tagged with this tag. How can it keep an exact count of the number of entries I have tagged with this tag if it doesn't know exactly where all of them are? It counts them as they come in and go out. ( Explanation and analogies. )
Each tag is counted separately, and each tag counter and each tag view operates independently of each other. This can be annoying if you want changing one tag to re-tag the whole entry, but I could see how someone who has come to expect the current behavior could come to depend on it (say, editing a post that has fallen off the end of the apple tag view to add an orange tag, but without re-adding the post to the apple tag view at the expense of knocking a more recently tagged apple tag post off of the view).
What I would really like would be a re-tagging tool. It would be useful for anyone who has discovered that their entries have been tagged out of order, so that you have big chunks missing out of the middle of the tag view because the ones that should have been in the middle were tagged first and have fallen off first, or just people who have a lot of posts with a lot of tags and want to make sure that all of their entries were tagged and tagged in order. It wouldn't tag your entries for you; you'd have to do that, but once you had tagged them, it would go and tidy up their order, or make sure that your journal was taking full advantage of the new tagging limits.
The tool would go in from the chronological beginning of the journal and re-save all the tags on all the entries in chronological order. It would go in to edit the tags on that entry, cut the tags off from that entry, save the entry with no tags, paste the tags back on that entry, and save the entry once again fully tagged. It would have to be a polite bot, or I could see it being banned fast. It sounds like the sort of thing that LJ should offer as a paid service, so LJ can control the speed and make sure it isn't eating up resources. Like the entry security changer, it might only do a chunk at a time, and then e-mail the user when the whole process has been completed. It also sounds like it could be a risky thing; someone could lose all their tags if things weren't done right.
* I spent a fun and productive night experimenting with the exact practical limits of the tagging system at some point when the limit was 100. I was in IRC with the usual suspects, someone was curious, someone was bored, and I was the one who had over 100 entries in one tag. I wound up playing with my tags a lot that night. 100 entries was the smallest top-limit that we encountered when doing that, and it would occasionally show up to 120-ish entries, then reset back down to 100 entries, unless I was testing it wrong. Thus the tiny-binder-with-pages analogy, rather than a-clear-tube-full-of-marbles analogy.
Second time is not the charm.
Apr. 17th, 2006 05:25 amhttp://www.livejournal.com/support/faqbrowse.bml?faqid=226&view=full -- tags.
What this FAQ does not cover is what the hell happens when you delete the tags. Depending on stuffs, there are like two options for user expectations for what happens when yous deletes tags.
Option 1, the user-friendly option, says that the 100 tags is a server-strain limiting option, so's the trained monkeys don't get tired or anything, and it's a floating limit; when you delete the tag from entry 1, entry 2 moves up, and so on down the line, and entry 100 becomes entry 99, and entry 101 that was not previously viewable becomes entry 100 and therefore viewable. This depends on the tag system depending either heavily on search, or mostly on indexing but using search when there are any changes made.
Option 2, the user-unfriendly option, says that the 100 tags is a list-limiting option, so's you don't have to have a st00pid hyuuuuge index for tags, and only list the 100 most recently added/edited tags. When a tagged entry is deleted/edited to remove the tag, the entry disappears from the index, but is not replaced. The index will begin collecting up to 100 of the recently added or edited posts with this tag ... when they're added or edited.
I've had to answer at least two Support requests about this undocumented "feature" of the tags system. I think it's bloody well time for me to document it, but I think that'll wait until I'm awake.
Note that I think that we would not be getting requests about "But it says I have XXX of $TAG but I was editing those tags because I have a st00pid hyuuuuge number of them and I can only see 100 of them and OMFG I RAN OUT OF TAGS but the masterlist of ALL TAGS says I've got XXX of them and yet WHERE ARE THEY ON MY BLOODY LIST plzkthx?" if it were Option 1. It's Option 2, folks. Option 2.
What this FAQ does not cover is what the hell happens when you delete the tags. Depending on stuffs, there are like two options for user expectations for what happens when yous deletes tags.
Option 1, the user-friendly option, says that the 100 tags is a server-strain limiting option, so's the trained monkeys don't get tired or anything, and it's a floating limit; when you delete the tag from entry 1, entry 2 moves up, and so on down the line, and entry 100 becomes entry 99, and entry 101 that was not previously viewable becomes entry 100 and therefore viewable. This depends on the tag system depending either heavily on search, or mostly on indexing but using search when there are any changes made.
Option 2, the user-unfriendly option, says that the 100 tags is a list-limiting option, so's you don't have to have a st00pid hyuuuuge index for tags, and only list the 100 most recently added/edited tags. When a tagged entry is deleted/edited to remove the tag, the entry disappears from the index, but is not replaced. The index will begin collecting up to 100 of the recently added or edited posts with this tag ... when they're added or edited.
I've had to answer at least two Support requests about this undocumented "feature" of the tags system. I think it's bloody well time for me to document it, but I think that'll wait until I'm awake.
Note that I think that we would not be getting requests about "But it says I have XXX of $TAG but I was editing those tags because I have a st00pid hyuuuuge number of them and I can only see 100 of them and OMFG I RAN OUT OF TAGS but the masterlist of ALL TAGS says I've got XXX of them and yet WHERE ARE THEY ON MY BLOODY LIST plzkthx?" if it were Option 1. It's Option 2, folks. Option 2.
Administrative: Tags
Jun. 17th, 2005 02:35 amThis journal now supports tags. Tags FAQs I have set tag permissions to a newly-created "taggers" security group to create and set tags. The "taggers" group contains pretty much every human I have listed as a friend who I have very much of a personal relationship with. Use this power wisely (read: relevantly) and with great abandon.