Dreamwidth Development Training

On reusing/tweaking code in a language you don't know

Thu, 20 Sep 2012 03:51:47 GMT

Posted by: aedifica

Hi all! This isn't directly about Dreamwidth development, but I was encouraged to post it here because it's an example of how one might approach a problem in a strange language.

( Long post got loooong )

TL;DR: If you know a very little bit about programming languages, you know English, and you have Google (or your search engine of choice), you may be able to tweak some existing code to do what you want. Hooray! Also, COMMENT YOUR CODE! The life you save may be your own! And so forth. :-D

comments

Test Plan Walkthrough: Bug 2154

Sun, 25 Mar 2012 13:02:24 GMT

Posted by: purplecat

As well as uploading a patch file for bug 2154, I uploaded the notes I had made for the test plan for the patch in case they were of use in the review process. denise asked if I could write a post explaining how I came up with the tests for this comm, since it was something people often asked about.

( Generating Tests for Bug 2154 )

comments

Walkthrough for bug #2159 (part 1)

Sun, 11 Sep 2011 02:05:15 GMT

Posted by: kareila

http://bugs.dwscoalition.org/show_bug.cgi?id=2159

First problem: how to generate the image.

No idea. How do comment counts do it?

To answer that question, I will load the dw-free change history into
my text editor to find the relevant code. A changelog search might also
work for this.

(All commands assume execution at the top level of dw-free.)

hg log -v -r 1: | bbedit

Looks like the relevant file is htdocs/tools/commentcount.bml, according
to the original bugfix from Allen. But that file isn't there! Searching
further, it becomes apparent that Dre moved this to a controller in the
course of her crusade to slay BML.

bbedit cgi-bin/DW/Controller/CommentCount.pm

Not much code! Most of it is using Image::Magick methods. The only
non-obvious parameter is the size of the image - how big should it be
for our text? We will have to use trial and error.

What should our arguments be? Comment count uses user and ditemid, the
necessary information to figure out which entry is referenced. For our
image, we should only need the text of the invite code itself.

Hmm. Since we only have two states to communicate, used and available,
maybe instead of using dynamic text like comment count does, we should
use icons - perhaps a green check mark for available, a red stop sign
for used. This has the advantage of not requiring the viewer to
understand English.

open htdocs/img/silk/site/tick.png
open htdocs/img/silk/comments/delete.png

Those are pretty close! Let's see if we can figure out how to return
those images as responses, instead of using Image::Magick. I think the
best way to do this is to redirect the request to the URL of the image,
and use HTTP headers to tell the browser how long to cache it.

Once an invite code is used, it will never revert to being unused. We may
be able to reduce the computation needed for this feature by extending the
cache period once the code activation is detected. On second thought, though,
this may not be true for promo codes, and our tool will work for those too.

Time to decide on the name of our controller and the site URL that will be
used to point to the dynamic image. Once we make those decisions, the new
controller can be written and tested independent of any other work that needs
to be done for this bug. We'll also need to consult DW::InviteCodes for the
function that tells us whether a code has already been used or not.

The actual code as described above doesn't take long to write. Unfortunately,
the name of the source image is advertised to the end user because we used
a redirect. But since the images are intended to be embedded in a page,
the redirection shouldn't be obvious in normal use conditions.

You can read through the resulting patch here:
http://bugs.dwscoalition.org/attachment.cgi?id=5472

Let me know if anything I wrote needs further explanation. :)

comments

Getting started with the DW codebase.

Tue, 05 Oct 2010 08:02:32 GMT

Posted by: tyggerdev

"Hudson: Is this gonna be a standup fight, sir, or another bughunt?
Gorman: All we know is that there's still no contact with the colony, and that a xenomorph may be involved.
Frost: Excuse me sir, a-a what?
Gorman: A xenomorph.
Hicks: It's a bughunt. "

One of the eternal problems faced by large open source projects is keeping new developers. People show up with the best of intentions, but unless they have experience in the specific problem domain, language, and even the toolset of the project already, the barrier to entry just in finding the right file to edit can be overwhelming. Let alone suddenly having to learn ssh, cvs and the command line. I have written up my recent experiences with dw - I only got here last week, so I'm still very much at the "where do I even *find* that?" stage, but I have a little experience with this sort of thing, so hopefully this will be helpful.

http://tyggerdev.dreamwidth.org/470.html

Enjoy. And remember, the more feedback you add here or over there, the less work new developers have to do later :)

comments

Review 101

Mon, 24 Aug 2009 17:50:53 GMT

Posted by: yvi

Hello and welcome to today's feature on dw_dev_training. I'll be your host today and we will be discussing:

Review 101
Or: How to get that queue a tiny bit smaller

[Note: There is also a Wiki page on code reviewing http://wiki.dwscoalition.org/notes/Code_Review ,which you might want to read. I will likely expand that page soon]

( Read more... )

Sorry if this was short in places or unclear, I wrote this down rather quickly and my fingers are starting to hurt. Comments welcomed, as I would love to post a finished up version of this on the Wiki.

And I hope this helps someone :) Reviewing is nice, needed and not that difficult!

And nobody will kill you if you do something wrong. Really! For any questions, the Dreamwidth channels #dw and #dw_kindergarten are also welcoming of questions regarding reviewing.

comments

Walkthrough for Bug 1518

Sun, 02 Aug 2009 05:14:43 GMT

Posted by: denise

This is a walkthrough for how I patched Bug 1518, "Option to get notified by email when you send a message". I wrote up this walkthrough because it's a good example (IMO) of how a developer makes design choices when taking a top-level bug description and sitting down to implement it -- both architectural/code design and user interface design.

( and away we go )

comments

Bug Walkthrough: Bug 1512

Thu, 30 Jul 2009 03:02:37 GMT

Posted by: denise

I decided to take on Bug 1512 as a quick hit, and thought I'd do a walkthrough so people could see my process!

(I like having walkthroughs. I think we should do them more often!)

( My process )

comments

Tracking the original source of an edit

Mon, 13 Jul 2009 15:29:04 GMT

Posted by: sophie

Sometimes, it's useful to be able to track how a change made its way into the codebase to start with, for tracking why something is a certain way when it seems totally nonsensical or non-obvious.

Fortunately, it's easy to do so with the versioning systems that Dreamwidth and LiveJournal use, which track every single change made to the source code. (It's quite literally possible to specify any arbitrary date and pull a complete copy of the source code as it was on that date.) In this post, I'm going to use this feature to track down the original source of the FIXME that foxfirefey mentioned in her wonderful bug walkthrough, to try to see if it's possible to find out what it's for.

( Walking down Memory Lane... )

comments

Bug 1362 fix walkthrough: If journal title == user name, name doesn't display on profile.

Tue, 30 Jun 2009 03:00:30 GMT

Posted by: kareila

Here's my take on a simple bug I patched in five minutes. Most of the bugs I investigate are not this quick, but I wanted to use a simple example to encourage people to get their feet wet. Many of the bugs that get filed are actually not very complex, especially if they have the "effort-minor" keyword.

The bug in question here is bug 1362, "If journal title == user name, name doesn't display on profile." So we have to look at the code that generates the profile page. As a longtime LJ user, I happen to know that the canonical reference to the profile code is in /userinfo.bml, and the /profile and /info links on the user pages redirect to that. But if you didn't know that, you could either spend some time in the code looking around until you found it, or ask a developer to give you the starting point. In my personal experience, I asked for starting points for the first two or three bugs I did, and after that started looking around more on my own to get a feel for where important things tended to live.

The next thing for a new developer to realize is that because user-visible strings are supposed to be translatable for different languages, they are not (read: not supposed to be) stored in the code file itself, but in a companion file with the suffix .text. This is well documented in the section of the DW wiki that talks about English-stripping. In this case, if I look in htdocs/userinfo.bml.text, I find that "Name:" has the translation label of .label.name. We need to find out where this is being printed.

Somewhat confusingly, I don't find any references to .label.name in userinfo.bml itself, which means it's being called in another part of the code. So on the command line, I use grep -r to find all references to .label.name. The grep command is a developer's best friend, and the main reason to have a checked out copy of the code as opposed to browsing the repository through the web interface. One of my favorite techniques (not needed for this bug) is to grep 'sub function_name' to find the definition of a function, ignoring all the places the function is merely called, which you would see if you just grepped 'function_name'. Anyway, this command shows me that .label.name is called from cgi-bin/DW/Logic/ProfilePage.pm, line 357: grep -r \.label\.name .

The reported problem is that the name doesn't print if the name equals the journal title. We can see the code is doing exactly that:


unless ( $name eq $u->prop( 'journaltitle' ) ) {
    $ret->[0] = LJ::Lang::ml( '.label.name' );
    $ret->[1] = $name;
}

So all we have to do is remove the conditional surrounding the statements, and it will always print the name. Problem solved! I'm not going to spend time here talking about how to generate a patch and test a fix, because that's covered elsewhere.

My point is that the main work here was just finding the code to fix. The actual change was pretty trivial. I'd go so far as to suggest that beginning developers look at many different types of bugs to figure out what parts of the code are involved. Even if you can't figure out what changes need to be made to fix the bug, you'll still learn a lot in the process.

Anyway, that's a bugfix from my perspective. If you think I was too vague anywhere and you want more details, just ask!

comments

Bug 1123 fix walkthrough: Post image link broken on update page

Mon, 22 Jun 2009 15:49:13 GMT

Posted by: afuna

Walkthrough for Bug 1123 - Post image link broken on update page

Table of contents

Picking a bug / preparation / background
(Interlude) Applying changes
HTML editor
RTE
- Finding stuff
Patch evaluation, clean up, submission
Getting reviewed, resubmitting
- Form
- Function

( walkthrough, etc )

That got long! *laughs* Next time, I'll try to look for something shorter, and maybe also more technical.

comments

Bug 858 fix walkthrough: Private messages strip (rather than escape) HTML

Mon, 25 May 2009 06:59:07 GMT

Posted by: foxfirefey

This is a walkthrough for how I tackled Bug 858 - Private messages strip (rather than escape) HTML. I'm not a very experienced DW developer, so you're going to see me do a lot of bumbling around as I try to figure things out. But, I'm going to document all of my wrong turns and head scratchings in the hopes that seeing the whole process laid out from start to finish might help people who aren't sure how to go about things. I will note ahead of time that some of the issues I run into won't happen to people on Dreamhacks--they're due to my setup not being completely right.

To be honest, this walkthrough is a bit advanced and best suited for people already comfortable with the command line and coding. I'm going to do another one soon and hope that it doesn't go as awkwardly as this one did.

Table of contents:

( The Walkthrough )

I hope this has been a useful walkthrough of the process of bug fixing and banging your head against things until they work. If anybody has questions about the contents here, or suggestions about things I should have done differently, feel free to comment!

comments