Dojos and hack projects

[Alex Miller]

In the unsession at the conj we swapped stories of typical meeting activities at groups. It sounded like these mostly fell into one of:

- prepared talks

- project hacking in a group or dojos

- informal chatting 

I'd like to hear more specifically from those groups that do project hacking. Specifically:

- What are the mechanics - one big group, pairs, individuals?

- What kind of project - some examples I heard or have seen are:

      - katas like roman numerals

      - building a web site for the group

      - ai bot hacking

      - clojure koans

      - getting started with emacs or libs

- Do projects ever cross meetings or extend outside that context? [Most people at the unsession seemed to have the most success when the project was contained in a meeting]

 I think it would be hugely useful if there was a list of projects like this with accessory information that were recommended for user group projects. If your group does these, are they described somewhere? 

[Lee Hinman]

We have had luck at the Denver Clojure group with people suggesting
problems to work on for the next meeting at the current meeting.

For example, we had someone who works with power grid data suggest some
"big-data" crunching as a topic, then was able to pre-send out some CSVs
so people could play around with the data. The group then came together
to discuss different solutions, approaches and issues with each of the
solutions.

After this, we decided to start a Github organization[1] to hold all the
code we've been using, which could definitely be documented a bit
better.

I'd also be interested in a good place for more project ideas for a
group.

; Lee

[1]: https://github.com/den-of-clojure

[Philip Potter]

Hi Alex,

Bruce Durling has written up the structure of the London Clojure Dojo here:

http://otfrom.wordpress.com/2012/07/04/how-to-run-a-london-clojure-dojo-in-20ish-easy-steps/

I wrote up a few of the individual sessions from last year here:

http://rhebus.posterous.com/tag/dojo

The dojo has evolved through various stages to its current form. The
tl;dr of the above links:

* ideas for projects to do are suggested on the night
* we split into groups of 4 or 5
* everyone gets a turn at the keyboard
* show and tell at the end allows groups to compare their solutions
with one another

The primary goal is education rather than achievement in itself. So we
don't actually write any code that anybody goes on to keep and use for
anything; rather, people simply get into the habit of writing Clojure
code and seeing how other people write code.

Advantages of our approach:

* requires relatively little forward planning - just book a room and
order some pizza, the rest can be sorted on the night
* people generally get to work on a project that they chose or voted for
* (relatively) newbie friendly. we try quite hard to ensure that new
folks get some keyboard time, so they can come away feeling they have
written some code

Disadvantages (or non-goals):

* we mostly write throwaway code
* we rarely have projects which cross meetings (though we did once do
this with clj-processing)
* there's usually enough newbies that relatively advanced topics such
as multimethods rarely get touched on

Since Bruce is on this list too, he may have a different angle.

Phil

> --
> You received this message because you are subscribed to the Google Groups
> "clojure-power" group.
> To post to this group, send email to clojur...@googlegroups.com.
> To unsubscribe from this group, send email to
> clojure-powe...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-power?hl=en.
>
>

[Bruce Durling]

Phil and Alex,

Just a few comments inline.

On Sun, Nov 18, 2012 at 9:40 AM, Philip Potter <philip....@gmail.com> wrote:

<snip>

The primary goal is education rather than achievement in itself. So we
don't actually write any code that anybody goes on to keep and use for
anything; rather, people simply get into the habit of writing Clojure
code and seeing how other people write code.

I would actually say the primary goal is fun. The hope is that the fun keeps people coming back and that education and achievement will follow on (either inside or outside the dojo). A lot of people find the educational aspects fun though.

 

Advantages of our approach:

* requires relatively little forward planning - just book a room and
order some pizza, the rest can be sorted on the night

The pizza and drink is really nice, but not necessary. The biggest advantage of this is the small amount of planning involved. It makes it *very* easy for a busy organizer to sort out as long as you can get a venue easily. Really all you need is power, wifi and some sort of large screen/projector for the show and tell.

 

* people generally get to work on a project that they chose or voted for

Sometimes people will prepare things for the dojo. Usually these are servers that allow for team competition. Whenever someone prepares something I try really hard to make sure that we use it in the dojo. People's contribution to the group needs to be valued and acknowledged and using it is one of the best ways. Also, these competition dojos are some of the most fun we've had at a dojo.

 

* (relatively) newbie friendly. we try quite hard to ensure that new
folks get some keyboard time, so they can come away feeling they have
written some code

Newbie friendly can be tricky. Especially when we vote on things. We've had a couple of dojos where people have voted for some reasonably advanced things that move beyond clojure fundamentals into core.logic or using libraries. I've noticed this in the London Python Dojo as well, but any time the dojo moves beyond using language fundamentals without an example to start with and hack on there is a higher level of frustration and the newbies in particular feel that the whole group is a bit advanced for them. It can be tricky to balance having fun trying new things with a group that is becoming more experienced with something approachable for complete newbies.

 

Disadvantages (or non-goals):

* we mostly write throwaway code

I always consider the dojo code to be throwaway. We do other events that tend to be an entire day (like the one I'm going to in about 5 minutes) where we make more lasting contributions. We've done a fair bit of this with Incanter, ring and compojure. The dojo is all about throwing yourself into a problem fast and is the opposite of hammock driven development. 

Tom Hall @thattommyhall is actually organizing a Hammock Driven Development hack weekend in January. There has been some suggestion that it would be fun to make this a multi-location international event.

 

* we rarely have projects which cross meetings (though we did once do
this with clj-processing)

We spent about a year working on a text adventure game in both the clojure dojo and the python dojo. It was in fact the first thing we worked on in the London Clojure Dojo. There were some advantages for the people who came to each one that we actually did learn how to do things in the dojos that we applied in the next ones (get-in, update-in are examples from the text adventure). The problems were dealing with a build up of cruft in the code base (it got messy very quickly) and the learning curve for new people who came in. We also did these ones using the Randori style (2 people in front of everyone). It was an OK way of getting started, but I feel we make a lot more progress now that we have enough experienced people to be able to break up into groups.

 

* there's usually enough newbies that relatively advanced topics such
as multimethods rarely get touched on

 

If we could find something like the 4clojure problems that were simple enough and compact enough to work on in the dojo (the 4clojure problems are always excellent for the dojo, esp with the variable skill levels of the problems) then I think we could do quite a bit of exploring of multimethods, java interop, proxies/records/types/etc, core.logic. It would be great if we could create a list of problems from 4clojure that would be good for learning these kind of things.

Since Bruce is on this list too, he may have a different angle.

I think I might have written more than I intended to. I hope that brain dump was helpful.

cheers,

Bruce

[Thomas G. Kristensen]

I think a list of good dojo topics for beginners would be a great resource. We are about to have our first dojo next month in Zurich, and while I think it's easy to come up with libraries to examine, I do believe that is a bit too advanced for beginners. 4Clojure is nice, but I don't feel the tasks are well suited for collaborative work.

Do you have a list of dojo topics used in the London group?

Thomas

[Philip Potter]

On 19 November 2012 17:17, Thomas G. Kristensen

<thomas.g....@gmail.com> wrote:
> I think a list of good dojo topics for beginners would be a great resource.
> We are about to have our first dojo next month in Zurich, and while I think
> it's easy to come up with libraries to examine, I do believe that is a bit
> too advanced for beginners. 4Clojure is nice, but I don't feel the tasks are
> well suited for collaborative work.

Au contraire, I feel they are perfect for collaborative work,
particularly once you get past the elementary ones.

Here's a writeup from a dojo where we did 4clojure problems. In a
group of 4, we solved one and started another:

http://rhebus.posterous.com/london-clojure-dojo-december-2011

> Do you have a list of dojo topics used in the London group?

We haven't listed everything in one place, but here are some I can remember:

* use clj-processing to animate some circles moving around the screen
(this was before quil was big)
* overtone ( http://mytediousblog.blogspot.co.uk/2012/08/jamming-with-overtone-at-london-clojure.html
)
* 4clojure problems (multiple times, it's always a good option)
* write a chatbot based on trawling the twitter api
* see https://github.com/philandstuff/ldnclj-chatbot ; malcolm
sparks briefly described it in http://blog.malcolmsparks.com/?p=94
* write AIs to play tic-tac-toe against one another
* this involved using a game server which someone had provided for
the session
* write a program to play 20 questions and learn new
* I wrote an HTTP server for this one, I wrote up my experience
here http://rhebus.posterous.com/london-clojure-dojo-september-2011
* more 4clojure problems
* clojurescript/game of life
(https://github.com/sw1nn/ldnclj-dojo-team-5-game-of-life/blob/master/README.md
)
* rhyme generator https://gist.github.com/3507365
* rot13 cypher https://github.com/davidjameshumphreys/cypher

You can probably find a bunch of ideas by searching the london
clojurians google group for github.

Phil

> Thomas
>
>
> On Saturday, November 17, 2012 8:04:20 PM UTC+1, Alex Miller wrote:
>>
>> In the unsession at the conj we swapped stories of typical meeting
>> activities at groups. It sounded like these mostly fell into one of:
>> - prepared talks
>> - project hacking in a group or dojos
>> - informal chatting
>>
>> I'd like to hear more specifically from those groups that do project
>> hacking. Specifically:
>> - What are the mechanics - one big group, pairs, individuals?
>> - What kind of project - some examples I heard or have seen are:
>> - katas like roman numerals
>> - building a web site for the group
>> - ai bot hacking
>> - clojure koans
>> - getting started with emacs or libs
>> - Do projects ever cross meetings or extend outside that context? [Most
>> people at the unsession seemed to have the most success when the project was
>> contained in a meeting]
>>
>> I think it would be hugely useful if there was a list of projects like
>> this with accessory information that were recommended for user group
>> projects. If your group does these, are they described somewhere?
>>
>>
>>
>>

[Bruce Durling]

Tonight's topics were:

1. 4clojure problems

2. implementing lisp

3. turning code complexity into music using overtone and leipzig (beware the big downloads for overtone though)

4. porting Incanter to use jblas

We did 4 tonight as there was a pretty even split in the voting.

Usually we just start with Roman Numeral Calculator and encourage everyone to come up with a better idea and then vote on all the ideas. I generally try to encourage easier and simpler tasks for the evening as the skill levels vary, the time is short and it can be frustrating getting nowhere (we've had a few dojos that have gone that way).

cheers,

Bruce

--
@otfrom | CTO & co-founder @MastodonC | mastodonc.com

[Thomas G. Kristensen]

Great, thanks for the lists. We'll use them as inspiration.

Thomas