An Emacs Hack Night

The other night at the PDX Emacs Meeting, the assembled hackers expressed an interest in getting together to actually hack on Emacs projects. While our previous ½ dozen meetings featured interesting demonstrations and workshops, I’ve always envisioned our meetup as a place to go to where we could alter our Dear Editor.

I’ve never done this sort of thing before, and am not sure how to proceed. Consider the following initial ideas as the start of a discussion where I can gather feedback, and then build some sort of play book prior to our evening’s fun.

Who should attend this hack night?

Are you new to Emacs, and would like to know more?
Do you know Emacs well, and would like to help others?
Do you use Emacs, and have an idea to would make it better?

If you can answer yes to any of those questions, then our Hack Night is for you. The following is my list of what it may take to have a successful Hack Night Project:

Ideas and Brainstorming

What if each project/goal consisted of:

Something small that could be accomplished in an hour
Could be done by 2 or 3 people
At least touches Emacs, if not written in it

If your project idea is large or complicated, carve a small piece, for we need to feel accomplished at the end of the evening.

I challenged everyone at our meetup to come up with a project, and if every other person came up with an idea, then we could pair up with someone.

Environment Setup

What shall we do to prepare for the Hack Night? Since no two people have even remotely similar Emacs setup, I would suggest using Floobits, as an easy plugin for Emacs that allows two or more people to edit the same project, but within their own Emacs environment.

Along with installing the plugin, create a Floobits account, and create a project. Seems that it works well if you have a Github account, but that is not necessary.

Are you new to Emacs? Great! Perhaps before you come, you might want prepare a bit by getting familiar with the editor. I’d suggest:

Tutorial … start Emacs, and type Control-h and then type t, or check out an online tutorial.
Emacs Lisp Introduction … in Emacs, type Control-h and then i, and move the cursor to Emacs Lisp Intro, or read it online.
Emacs Lisp Hacking Tips … this YouTube video by John Wiegley shows a bit of editing and debugging Lisp in Emacs. Lot of nifty tips.

Also, check out Sacha Chua’s Read Lisp, Tweak Emacs essays.

Project Setup

I think well defined goals would make a project easier for others to understand and help. Perhaps:

Create a Git repository
Push that repository to Github
Write a README and describe your ideas
Try to break the project into discrete tasks

Not every project would be ready for immediate coding. Perhaps your project is more an initial brainstorm. I think that would be good too, but make sure you mention that, for some people may want to jump in and start coding, while others, would prefer to help flesh our your skeletal vision.

Conduct

I suppose it goes without saying that the lowest bar for the evening will be professionalism. Our group has already established a code of conduct, and I want to make sure that everyone feels safe and welcome and is able to enjoy each others’ company.

The Soap Box

Finally, it is time to talk others into joining your project. Wouldn’t it be great if we sent our ideas to the group before the evening started, so we could just jump in with both feet… or, since we’re Emacs Hackers, all eight tentacles.

Would it be too much to ask:

Project description
Level of domain knowledge
Level of Emacs and Lisp knowledge
Expectation of participation
End goal and accomplishment

I’ll begin with a project that I’ve been stewing about for a while. The complete project would be too much for a single evening, but step one may be in order. Let me describe it, and you can tell me if it would work.

An Example

I often use Chef in my day job for deploying and configuring my applications, and often kick off a shell command to move a recipe to a Chef server using the knife command line program. I’ve often wish for some knife-related Emacs functions to stream-line my workflow, so…

Project Description

I would like to build the emacs-knife project that interfaces with the Chef web service API. I think we could use the emacs-request library.

Domain Knowledge

Understanding Chef and its API is, in a way, immaterial. We are using a web service, so understand HTTP Get and Post requests would be more important.

Lisp Knowledge

This would be written in Emacs Lisp using either the emacs-request library, or the default URL package. This shouldn’t be tricky Lisp, but knowing (or wanting to know) Lisp may be in order.

Expectation of Participants

I would like to get 2 to 4 other people sitting across from each other, connected over Floobits, and hacking on this project.

I will set up a Chef server, and will be able to connect to it through standard Curl calls before the Hack Night. I will also try to have a list of tasks, but that is more for organization, and I would like each person to follow along with the code (as that way, people less familiar with Lisp will be able to learn).

End Goal

If we could read the settings from a knife.rb configuration file, and upload a Chef cookbook, we would have ourselves the start of a great project. Other Chef commands would layer on top of the ideas in this initial knife-cookbook-upload function, and if we have time, we could discuss interfaces, e.g. Magit-style popups, etc.

Preliminary Results

I decided to try this approach on a more limited scale with a friend of mine, Ken Maupin. Before we met, I did the following:

Created a Github repository
Connected the project to my Floobits account
Invited Ken’s Floobits account to join as a writer
Wrote a few functions and used a few helpful libraries
Communicated a rough sketch of the problems to solve

We learned a wee bit.

While I felt I had communicated the goals and problems … I should have written them down.
A check list of tasks and metrics would have been ideal
Floobits is pretty good but not flawless … save and commit often.¹
Be willing to jettison initial ideas.
I got pretty excited in solving the problems at hand that I left Ken behind. Don’t do this … keep your partners in sync with you.

In summary, when planning a Hack Night / Office Hours meetup consider the following:

Initial preparation pays well … pre-experimentation lends clarity on possible paths and direction
Emphasize communal coding and relationships over code accomplishments
Set smaller attainable goals … with the night’s encouragement, the hacking will continue.

Any other suggestions and ideas?

Footnotes:

At times, we noticed file conflicts (as seen in the following screen-shot). If you see them, be careful how you react, as you could undo your partner’s changes (remember, change happens).