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 something.

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 to everyone.

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 again with a promise of giving us some l33t javascript stylings as we all 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 already submitted a patch with her new javascript stylings, which I 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.

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 rootbeer277 is

[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 node]

[essay on silence<node by Lometa>|a really great node]

or just

[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

[call<user>]

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.

Revoting

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 repertoire.

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 know how, also try it without javascript to make sure revoting degrades gracefully if javascript for whatever reason isn't working.

News from patch manager and Mercurial

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 21^st century chatting mechanisms!

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 only.

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 e2contact).

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. ascorbic provided some javascript for making the text box resize (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.

Podcasts

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 question.

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 differently.

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!