I have a daylog and a rootlog to write, but I think that with your
permission, I'll roll them all into one.
The personal soapboxing
I really care about e2. This should be made clear. I've been on this
website for close to 8 years, on and off, but lately mostly on.
I want to talk about why I'm coding for e2. Part of it, and I hope
to keep it that way, is that it's fun. It must be fun, or I wouldn't
be be doing it. I've been devoting hours per day to e2's codebase, and
I've been trying to go home each night thinking, "these are the
problems I solved today." Fundamentally, I'm a problem-solver, whether
mathematician or coder, but happiest in the end when I can solve a
problem. Most of the smaller problems that I solve here as a coder are
intermediate steps that nobody else will recognise until the grand
goal is achieved. For me, however, even the smaller problems amount to
The big problem as I see it is that e2 has been crumbling under bit
rot. I have been coding in earnest for the past three months or so,
but I've been observing the code from a distance for many years, maybe
four. One of the biggest frustrations that I felt was the incomplete
access that mere edev membership provides, and something that I want
very much to amend. There was much code that edev could not see, and
edev also has no way to directly experiment with the code. I have
tried to fix the former by giving edev at least read access to the
running Everything Engine (ecore), which was previously disabled.
I said this was frustrating. What was frustrating was to see so many
problems with e2 (sam512's homenode has a good list of outstanding
problems, for example), but be unable to fix them, and to see
them unfixed for years. YEARS without seeing some
problems fixed that I am now discovering were not so hard to fix. Now
that I can fix them, it is difficult for me to stop.
No, really. With the blessing of the administration, I reopened e2
bugs and suggestions for e2 because I don't want anyone else to
feel that same frustration I had for years about being unable to fix
the site and see it still broken for all that time. I've been trying
to respond to issues raised by our users in a timely manner because I
care about the site, and I care about its users. I'm also very pleased
to see how other coders have also been stepping up and taking a more
active role in making e2's codebase change for the better. Thank you
Coding for e2 can be difficult and sometimes disheartening. Users
can be, perhaps unwittingly, very demanding, often because they have
no idea how easy or difficult their requests can be. If something is
very noticeably broken, whoever seems able to do something about it
gets notified immediately, and lately this is often me. I personally
get very anxious when the site isn't behaving itself, when someone's
user experience at e2 is being impeded by stupid code issues that
should never happen. It embarrasses me that my site, the site, the
precious e2 that has meant so much to me and to others, is treating
one or many of our users badly. Like a beaver anxious to build dams
when hearing running water, I am unable to be at ease until the unruly
website is nice again. The users are paramount. The users' experience
should never be bad. Their data is sacred, their comfort holy. This is
the sysadmin's creed.
The root log
Alright, let's talk about what's been going on this month codewise.
I'll summarise my work as well as all the other coders', beginning
with my own.
Getting more people involved with the code
I'm very pleased with seeing that this month I have by no means been
the dominant coder, as you can tell from a glance at patch manager.
One of my biggest goals lately has been to make it easy for more
coders to get into coding, which I did by writing a
couple of nodes. For edev's eyes, I
also opened up the Gigantic Code Lister, which provides a handy
reference to the source of the currently running ecore. This involved
getting rid of some really old unsafe practices like hardcoding
database passwords into ecore. I also put the running ecore under
source control, something that should have been done years ago. It's
impossible to reliably modify code if there is no clear breadcrumb
trail of the changes, and many of the things that we would like to
change about e2 can't be changed without changing ecore. The VCS
that I chose for e2 was Mercurial, about which I will node more in a
moment. You can see what it looks like
here, if you're so curious. I will soon
node more about Mercurial and how to use it with e2.
I think my efforts to involve more people with e2's coding have
yielded some fruit, as edev has recently seen new blood like
moosemanmooo and XWiz. Longtime noder prole has also joined us
collectively try to tear this site kicking and screaming away from
1999 web design. She's been prodding me to give her some tools to help
her work, which has resulted in me recently lifting the length
restriction in the notelet, at least for edev and
admins. As I'm writing this, I see that she's
look forward to reviewing once I'm done.
A related effort has been to clean up patch manager a little and make
our patch system a little more sane. Patches can now be filtered by
status, and I've been encouraging e2coders to use those statuses in
a meaningful way, which has already begun to happen. A few more things
have to happen before our patch system vaguely approximates the
sophistication of real source control like Mercurial, but the first
steps have been taken.
Two big user-visible changes: revoting and direct links
There were two things that were a big priority for me this month and
which I spent quite some time on. As far as I'm concerned, they're
both ready for primetime, at least codewise. The staff is still
discussing their relative merit and a few details of implementation. I
am talking about revoting and direct links.
Due to an initiative from ascorbic, I implemented direct linking,
twice, because the first one received much derision both in interface
and implementation. It required some pretty intrusive changes in
ecore, which I managed to make a little more gentle with the second
try. The basic format, as suggested by The Debutante and
[node being linked to <nodetype by noder>|pipelink text]
Of course you can omit the pipelink text as usual. The idea is that
there's now an optional tag that you can use to better describe the
link. The nodetype can be a scratchpad (abbreviated to "scratch"), a
superdoc, or a user, or a plain writeup/node, or any other kind of nodetype
(this latter general usage is usually only of interest to coders or
admins). If it's omitted, it defaults to writeups. Here "by" is a
keyword, so for example, to directly link to a really great node, you would type
[essay on silence<writeup by Lometa>|a really great
[essay on silence<node by Lometa>|a really great
[essay on silence<by Lometa>|a really great node]
all being equivalent. To directly link to a scratchpad, you can do
[coding tasks<scratch by Swap>|never ending story]
and so on. Remember that in all of these, you can still omit as usual
the pipelink text, so this last one could just be [coding
tasks<scratch by swap>], and you'll create this link: coding
tasks[scratch by swap
. To directly link to a user whose name also
happens to be a node, you can do
to produce this link: call
A special exception is for directly linking to discussion posts...
Here a number which you will now see in the title of the discussion
post you want to link is used instead. So, for example, to directly
link to a discussion post, you would do
[edev: New linking improvement<1984648>|Finally a good idea!]
Just copy-paste the direct link that you'll now see in discussion
posts. This can be useful to direct people's attention to a particular
point of a discussion.
By the way, this isn't going to be the "official" documentation for
the new direct linking methods. That will come later, in a
Virgil node somewhere. The above is just a sneak preview, if
you will. It's already all fully functioning, and while we might still
tweak it a bit, I expect that the syntax is pretty intuitive and
flexible for a all the kinds of direct links that we need, so that we
won't need to change the syntax.
I've pointed to it before, but Swap's Playground now contains what
as far as I'm concerned is a fully functional implementation of
revoting. The current implementation makes it that a revote is
completely XP and GP neutral for both parties but costs one vote for
the voter. Bringing this live will simply involve copying my code from
my playground into the general codebase, but it hasn't been done for
various reasons: there is some apprehension that being able to change
your vote without limitation will somehow be detrimental to the
database, plus a change that I think probably needs to be done in
order to maintain the significance of XP is that flipping a vote down
should cost the votee one XP, and flipping a vote up should grant one
XP to the votee. This way, a user's XP can still be directly
correlated to the number of upvotes, chings, and writeups in their
Please report errors or better, bugfixes if you know of any. I have
observed a bug where sometimes it gets stuck on "flip up" when it
should be "flip down", which mysteriously goes away when reloading the
page. Also, I haven't been able to test this on many browsers. Please
check it out again and give me some feedback on
how you would like this very requested feature to go into e2. If you
On to the rest of the root log. This month I count just slightly over
200 patches since the last root log, which doesn't necessarily mean
lots of user-visible changes, but to give you an idea, 3 months ago we
had a total of 600 patches or so in the database since the creation of
e2. Our productivity has certainly been on the rise lately. To
repeat myself, I am extremely pleased to see that there have
been so many coders contributing to our codebase. Maybe there's hope
for e2 after all. This month, we got contributions, in no particular
order, from OldMiner, call, raincomplex, DTal, BlackPawn,
moosemanmoo, mkb, DonJaime, and prole. Of course, e2coders
has also been busy, and in10se, rootbeer277, Oolong,
ascorbic, myself and even the boss got in
a patch this month. My point is, the team seems to be working really
well together. Hooray.
I'll try to detail the changes this month, except for some really
minor or hardly visible things, crediting them to the right person
when possible. They're not in chronological order, though. That kind
of detail can only be obtained from the patch manager itself.
- Chatterlight enhancements
in10se, with a little bit of help from mkb, has been working on
improving chatterlight. There's a mysteriously named My
Chatterlight node floating around, which may one day take e2 by
storm with its awesome new 21st century chatting
- Chatterbox in general
With a nudge from raincomplex, I implemented the silly "/my"
command that let's you talk about things you own in the possessive
(e.g. "/my stupidity is endless."). The /drag command has been
polished and improved, as a collaborative effort between me,
rootbeer277, and feedback on wording and functioning from
e2contact. DTal provided some cleanup for the code, and we also
have limited squawkbox to chanops and admins
- Automatic edit notification
I started working on what is now a stalled attempt to let editors
attach edit notes at the bottom of your writeups when they edit it.
The notes would be visible to the author only as a way to ease
communication between eds and the userbase in general, as a
complement to /msgs. The code is in place, but about 50% done, and
not at all functional yet. Maybe next month I can bring this live,
if the eds can all agree on how it should work.
- Not count maintenance writeups
This was an initiative from DonJaime that took me three days to
implement, plus a bugfix later on. :-( It was difficult, but the end
result is that maintenance writeups (e2 nuke request, edit these
e2 title, suggestions for e2, and so on) no longer give you XP,
nor do they count for your overall writeup count. The idea was just
a small tweak to avoid fringe cases of people who would level up
temporarily with a maintenance writeup and would later lose that
level when the maintenance in the writeup was concluded.
- Stylesheet communication
Per a suggestion from BlackPawn, I added a box for stylesheet
authors from which they can communicate to all of their users.
Sorry, sam512, you can't use it for Kernel Blue, though.
- Code cleanup
We have some really old code that was written somewhere in
2001 or 2002 and was filling up our error logs. Judge
Node[nodelet is one example. Oolong, rootbeer277, and I
went through those obsolete pieces of code and disabled them.
- Usergroup discussions
A new tweak is that it's now possible to write the first post in a
discussion before creating the discussion, so by the time that the
discussion is announced to the usergroup, the first post is already
written. Also, I fixed some outstanding issues with permissions not
working for nested usergroups (e.g. chanops is a subgroup of
- Fix a table bug in Cream of the Cool
Our new table code validation code (thanks call!) caused us
an unexpected problem where the front page could get broken if Cream
of the Cool had a table from one of our users' writeups.
rootbeer277 implemented a quick patched that, and we have some
ideas of a better way to patch all of this in general.
- Message Inbox enhancements
Based on a feature request from tentative, moosemanmoo and
I worked on improving pagination and navigation in Message Inbox.
(which as of this writing seems to not be working in Opera, ack).
The layout of Message Inbox was also CSSed, and it will probably be
soon even more CSSed.
- Create new labels for purely coding gods
Some members of the gods usergroup aren't really
"admins" in the sense of other admins, in that they don't decide on
site policy, and don't handle editorial tasks. They just have the
buttons in order to have direct access to the code. I'm one such
member, as is Dreamvirus and N-Wing, and I'm hoping to be able
to incorporate more purely coding admins into the group once the
moral fibre of the new recruits is established. To this end, I
replaced the @ symbol of the purely coding admins with a *, under a
suggestion from alex.
Oolong has been slowly working on improving our podcast
infrastructure. He's not done yet, and I'm sure we'll get an
announcement once he is. But work has been done in that direction.
- Scratch Pads
In preparation for being able to direct link to scratch pads, I made
it impossible to duplicate titles of scratch pads. When I checked,
all duplicate titles were mistakes of users reposting form data with
their browsers, so this was probably desirable anyways. Also related
to direct linking, when you use the blab box from scratch pads, the
recipient will now receive a direct link to the scratch pad in
- Magical Writeup Reparenter
This is an admin-only change, sorry, but it should be mentioned here
because over several days rootbeer277 completely rewrote from scratch
code that had been broken for years and was making it difficult for
admins to move writeups around or fix unparented writeups.
- Nodeshell highlighting
Our code did not check for nodeshells in the findings page because
we deemed that those checks were too hard on the database. However,
it is now ten years later, our computers have gotten faster, so now
we seem to be able to make those checks. rootbeer277 made it so
that Findings: now styles nodeshells differently (check with your
stylesheet author on how those things are styled, if they still look
the same to you), and there are plans if we get bold enough, to hit
the database a little harder and style more nodeshell links
- New Writeups styles voted-on writeups
Based on a request form DejaMorgana, I styled New Writeups to show
voted-on writeups differently. Again, check with your stylesheet
author if voted-on writeups still look the same to you.
- New Findings: layout
Since both TenMinJoe and Rapscallion made this request, we
changed a little the way that Findings: looks like and also the
mechanism for creating new nodes. Since it seemed too easy to create
nodeshells by accident, raincomplex made it so that instead you
could search again, and created two separate buttons for starting a
new scratchpad or nodeshell for the thing you just searched for.
Hopefully this will make it harder to create accidental nodeshells.
Whew! And that's not all! There have also been minor bugfixes and
things here and there that you probably won't notice or see. call
has also provided a patch to make our redirect mechanisms better. I am
probably overlooking some other minor things, but I think I did cover
all the important changes.
I hope our users appreciate the coding. Remember to report bugs to e2
bugs and submit your suggestions to suggestions for e2. As for the
coders, thanks for all the work and happy hacking!