webdev – Nigel Babu

Discourse For Websites

Over the last few weeks, I’ve been doing a bit of work with discourse. Here’s a couple of things I learned…

Over the last few weeks, I’ve been doing a bit of work with discourse. Here’s a couple of things I learned:

Discourse uses Docker pretty nicely

Installing discourse is really easy. They make it very much easy to use with the discourse_docker repository. I had discourse setup and ready to go quite quickly. And then I got stuck, for a few days.

Sometimes things are broken but fixed quickly

In the beginning, whatever I did, the static website embedding refused to work. I tried it with RSS feeds and without RSS feeds. Google searches lead me to meta.discourse.org and at that point I tried a few things which were unnecessary, which did not fix the actual problem. It turned out that at some point discourse had broken embedding. However, as soon as we figured out it was actually a discourse bug, the fix was pretty fast.

Group Discussion by CIFOR on Flickr. CC BY-NC-ND

WP-Discourse could use some love

The discourse WordPress plugin does what it promises out of the box, but it needs a bit more work. For instance, it uses the file_get_contents function to open a URL. Some hosts block that function from opening a URL. I have a pull request to fix that, hopefully, it’ll be merged soon.

I could be wrong, but I couldn’t find a way to bulk publish to discourse. For a site newly converting to discourse, the option seems to be, switch new posts new to Discourse, the rest stays on WordPress.

Showing the old comments along with the new like How To Geek needs a bit of messing around with the theme.

Documentation could be better

I found some failures that were really hard to discover. For instance, the static site embedding works only if you’ve set a username in ‘embed by username’ – No idea why that happens, but there’s no documentation I could find for it. Then there’s help text like below.

EMBEDDING ONLY: Whether to embed a RSS/ATOM feed as posts.

Perhaps something better would be

EMBEDDING ONLY: Check to disable RSS/ATOM feed as posts.

I intend to open a pull request about this one.

The API documentation really needs to be better, sadly. The WordPress implementation uses an API endpoint, which doesn’t seem to be documented. I had to figure it out from the WP-Discourse code.

Error logging needs to be better

I wish error logs gave me information when the iframe refused to load. I had to pretty much try different things to figure it out. I wish I had a checkbox that would give me better logging information. The development mode doesn’t work out of the box with the docker existing setup, so I’m stuck.

How I Got Involved With Mozilla

There have been a fair number of responses to David Boswell’s post about how he got involved with Mozilla. Most of the responses have been from fairly established contributors and contributing for a while. I thought I’d share my experience since I’ve been around for hardly 4 months now and moderately active.

My first attempt at contributing to Mozilla was a disaster. It was around January 2011 and I tried to contribute to addons.mozilla.org (AMO) before its cleaned database was publically available. It took me a while to set the whole thing up and eventually when I did have things setup, I couldn’t properly reproduce bugs since I had no data and I had trouble adding new data. Eventually, I gave up out of frustration and I had lesser time available and my interest died out. Things have definitely changed since, the database for AMO is now downloadable and I’m pretty sure my setup troubles were my lack of experience; thank you Wil Clouser for being patient with me back then.

Around June 2011, I applied to a web developer opening at Mozilla. The email which confirms my application said this, ‘If you’ve gotten this far, we’re certain you care about the future of the web. It’s easy to get involved and further that mission.’ I think this struck a note in me (whoever thought to add it, great job!). I wanted to give it another shot. This time, I just joined #webdev and asked if any projects needed help. Dave quickly responded saying that Input could use some help and I started checking out the code and setting it up. By July, I had cleaned up most of the easy bugs on Input and I continue to help fix bugs. I ended up not getting picked for the position I applied for, but I’m really glad to be contributing.

Things have changed since my attempt in January. There is now a significant interest in making virtual machine images available via either vagrant or some other means so setting up a dev environment is much easier (See posts by tofumatt, lochard, and groovecoder). This reduces the barrier of entry and frustration levels significantly. A frontend person need not be a linux sysadmin anymore to be able to fix a small CSS bug. Another good thing about this is, since everyone will be on the same environment, we’re reducing the chances of a weird environment problem.

Is the route I took still possible? I’d definitely say yes. If you know Python and Django or PHP or CSS or JavaScript, there are a bunch of webdev projects, and just asking in #webdev channel could guide you to projects that need help. It’s probably a good idea to ask during UTC–8 working hours since working hours of most of Mozilla WebDev overlap significantly around that time.

Monkeypatching Django Admin

When I started contributing to Mozilla Webdev, I started with Input.

When I started contributing to Mozilla Webdev, I started with Input. The bug that was always a mystery to me was bug 658658. The login page to Django’s admin worked in Django 1.2.3, but didn’t work with 1.3, which is what was in the input vendor. At that time, I didn’t know about monkeypatching Django well enough, or care enough to fix this. Last night, I was scrolling through bzhome (Thanks again Heather!) to find this bug again.

This is how it looks before I fixed it

After 3 hours of working with folks in #webdev, especially jsocol, peterbe), and r1cky, we finally fixed it. The problem was that the monkey patching didn’t catch one case, the login and logout views which where not in django.contrib.admin but in django.contrib.auth. Thanks to everyone’s patience (especially r1cky, since we spent about 1 hour trying various combinations of things), the bug is fixed and I now know a little more about monkeypatching.

Launchpad bug titles are everywhere!

A while back, I wrote about smart autolinkifying in bugs. Last week, at the urging of Brian Murray, I built on top of the work that I’d already done. This time, it grabs all the bug links and sends to the linkchecker and, in addition to the set of invalid bugs, it also returns a set of valid bugs with bug titles! The after effect is a ‘bug 1245’ link in the body of Launchpad like in bug tracker, merge proposals, etc, where bug 1245 is a valid bug number will have its ‘title’ attribute set to the bug title.

Valid bugs have the 'title' attribute set as bug title and it shows up as a tooltip

Embedding a terminal with byobu

The other day I blogged about how I was looking for embedded terminal in vim and found something hilarious. This post is about how I solved what I was trying to do.

Typing this blog post on the kind of setup I'm writing about

I know I can do :shell, but that’s quite not what I wanted. Here’s how I got it working the way I want with byobu:

Open a terminal and start byobu.
Type C-a S, basically, Ctrl followed by a, and then capital S.
Then, C-a :, so you can type commands to the screen.
Now you can type resize +15 to increase the size of the top split
C-a Tab, to switch to the other split
C-a c to create a new terminal there.
Use C-a Tab to switch between the splits.
???
PROFIT!

I’d love to make this into some kind of config that I can load, but I haven’t discovered that yet. If someone knows how, please do let me know in the comments!