How Do You Manage Your Blocks?

[Anders Schneiderman]

Up till now, when I've had time to experiment with d3 I've done it by putting chunks of my work in a GH repo. This is how I'm used to working, and it was particularly useful when helping some folks at work dip their toes in the d3 water, because they could download a whole bunch of simple d3 scripts and fiddle with them during and after our play sessions (see http://datachefs.github.io/a-taste-of-d3/).

Now that I have a clue about what I'm doing, I'd like to switch to using blocks. So:

1) For those of you who do your d3 work on your box, how do you organize the gists so you know what they are? For ex, if you fork a gist, you end up with a folder name like 471c2bde0bd7182758d7463573e6c725. If you have a bunch of them, how do you tell which is which? If you use the fabulous bl.ock builder it's not an issue, but unfortunately I have to use voice recognition, which doesn't play nicely with it (I use Artom instead). What do folks who don't use bl.ock builder do?

2) If you teach a class/workshop, how do you manage the code you expect students to work with? Do you just use a repo? Do you also create a copy of each example as a gist block? For example, I noticed that Peter Cook's terrific d3 in Depth uses blocks to store its examples. Peter, if you end up teaching off the book, how will you manage the code you expect your students to work with?

I'm no d3 expert and don't plan to teach formal classes in it -- mostly I'm just teaching/mentoring at the nonprofit where I work, to help a few of the folks in our Shiny Object Task Force start experimenting with d3 -- so it isn't critical I figure this out, but I'd rather start with good habits than have to redo it all later.

Any recommendations/thoughts/insights would be greatly appreciated.

Thanks!
Anders Schneiderman

[Ian Johnson]

On Fri, Nov 25, 2016 at 12:20 PM, Anders Schneiderman <aschne...@gmail.com> wrote:

Up till now, when I've had time to experiment with d3 I've done it by putting chunks of my work in a GH repo. This is how I'm used to working, and it was particularly useful when helping some folks at work dip their toes in the d3 water, because they could download a whole bunch of simple d3 scripts and fiddle with them during and after our play sessions (see http://datachefs.github.io/a-taste-of-d3/).

Now that I have a clue about what I'm doing, I'd like to switch to using blocks. So:

1) For those of you who do your d3 work on your box, how do you organize the gists so you know what they are? For ex, if you fork a gist, you end up with a folder name like 471c2bde0bd7182758d7463573e6c725. If you have a bunch of them, how do you tell which is which? If you use the fabulous bl.ock builder it's not an issue, but unfortunately I have to use voice recognition, which doesn't play nicely with it (I use Artom instead). What do folks who don't use bl.ock builder do?

Once you have your gists cloned you can rename the directories to human-readable names and the mini git repos inside will still function properly. You can download all of your gists at once with this handy script:

http://bl.ocks.org/mbostock/3883098

I'm super curious about coding with voice recognition and making blockbuilder more accessible in this regard. Would you like to have a conversation offline about that?

 

2) If you teach a class/workshop, how do you manage the code you expect students to work with? Do you just use a repo? Do you also create a copy of each example as a gist block? For example, I noticed that Peter Cook's terrific d3 in Depth uses blocks to store its examples. Peter, if you end up teaching off the book, how will you manage the code you expect your students to work with?

Elijah Meeks also has all of his d3.js in action examples in blocks. I've taught a workshop where I made blocks for examples and then organized them as github issues: https://github.com/enjalot/wwsd/issues

this allowed me to share starting points as well as goals (completed code) in a well ordered fashion.

 

I'm no d3 expert and don't plan to teach formal classes in it -- mostly I'm just teaching/mentoring at the nonprofit where I work, to help a few of the folks in our Shiny Object Task Force start experimenting with d3 -- so it isn't critical I figure this out, but I'd rather start with good habits than have to redo it all later.

Any recommendations/thoughts/insights would be greatly appreciated.

I'd love to add more categorization and management features to blockbuilder, I just haven't had much time to develop new features. There is plenty of value to be created by adding them though as I know for a fact you are not the only one running into these issues.

 

Thanks!
Anders Schneiderman

--
You received this message because you are subscribed to the Google Groups "d3-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ian Johnson - 周彦

http://enjalot.github.io/

[Anders Schneiderman]

Thanks, Ian!  that's very helpful.  

I'm super curious about coding with voice recognition and making blockbuilder more accessible in this regard. Would you like to have a conversation offline about that?

That would be great.  This next week is pretty jammed, but I'll round back with you after that.

Thanks,

Anders

[Anders Schneiderman]

And thank you so much for having created blockbuilder!  It's a really nice piece of work.

Anders

[Peter Cook]

Hi Anders,

Good question. In the past I've just organised code samples using directories and distributed a zip of the files.

Now that the D3 in Depth examples are in bl.ocks, I'd either:

- get students to work in jsbin (there's a link for each example in the book) or

- I'd write a script to copy each example to a separate repo which students would then clone. This would allow them to work in their usual editor.

Not sure if that helps...

All the best,

Peter

[Anders Schneiderman]

Interesting!  Thanks for the ideas, Peter.

Anders