Division of work

[Ghost---Shadow]

If you are applying to Google Summer of Code, do not work on any issues. Read the wiki instead.

In 2016–2017 this issue tracked the list of chapters and their discussion pages. As of 2019 it is no longer being used.

Chapter	Volunteers	Discussion page
1
2		#77
3		#57
4		#58
5		#72
6		#88
7		#65
8
9
10
11
12
13
14
15		#59
16
17
18		#60
19		#68
20
21		#62
22		#103
23
24
25

[kepta]

Before that you souradeep let us please decide about the architecture, because I don't want you to be rolling back your efforts.

On Mar 20, 2016, at 2:53 PM, Souradeep Nanda notifications@github.com wrote:

To avoid wasting time, we should decide who should do what. Since @kepta and I are the only active members right now, I will pick the even chapters and @kepta can pick the odd chapters.

If more members join, we would do some kind of modulo n arithmetic and decide who should do what.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[astyanax]

Hello guys, I haven't actively participated in the discussions yet although I'm interested to work on the planning chapter (for a start).

[duaraghav8]

@kepta @Ghost---Shadow Alright let's do it this way. We all propose our structure with Point-by-Point Adv. & Disadv. Then we'll put it to a vote. Otherwise we're going to spend a lot of time discussing this.

@astyanax we're currently trying to decide upon the repo structure in order to avoid goof ups later. You too can contribute your perspective.
The goal is: for every algorithm in the book: we need to have 1 basic JS implementation (the core algorithm's code, which can be read, understood and run by any user), a script for running tests on that algorithm's implementation and an HTML document containing the visualization for that algorithm (D3 / Canvas, whichever you prefer - the user should see a visual representation that they can understand).

While talking about the structure, you need to keep the above goal in mind and also that the user of this repo must be provided with a clean interface.

[Ghost---Shadow]

I suggest that we uglify and compress all the scripts that are common to all pages (bootstrap, jQuery etc) as main.js

We will then have a folder for each chapter having code and its visualization. We may or may not uglify these scripts. Something like this. Let us keep the code and its corresponding visualization in the same js file. Some chapters like chapter 4 has 6-7 algorithms. Having one visualization js file would make it difficult to manage and debug.

The main index.html will function like a website homepage and the user can click on each chapter to see the code, visualization and a brief description to give a context.

I think Mr. @norvig will be happy with anything we unanimously decide upon.

[GiriB]

Hey guys! I was just going through the project and would like to contribute.
I agree with @Ghost---Shadow on having separate visualisation files and how he has proposed the structure to be. It would be helpful if the structure is finalised ( with few examples? @Ghost---Shadow 's implementation of Intelligent Agents is a good example ) so that people can start contributing.

I also had a doubt regarding following.

Why is there a separate Chapter5 when we a folder for this already exists ? ( Everyone should be careful while merging requests.)

@Ghost---Shadow Your index.html shows this. Take a look it why is it so.

' Part 1, Part 2 ...' is not required when you already have ' Part I , Part II ...' .

[duaraghav8]

@GiriB I wrote the minimax algorithm in JS, created the directory "Chapter 5" and made a PR following my dir. structure. At the same time, @Ghost---Shadow and 2 others were making their PRs. This resulted in a blend of GS's directory structure and mine, hence the outlier: Chapter 5/minimax.

This structure conflict is the primary reason for the existence of this thread.

[Ghost---Shadow]

I dont think folder structure matters a lot. Since the production is highly parallelizable, we can refactor easily. Also, I would like to finish Chapter 4 since it is midway done.

@GiriB I screwed up during squashing. I will fix that on Sunday,

[kaiesh]

Hi guys,

I'm keen to contribute to this too - am happy to pick up Chapter 6 to start with.

[GiriB]

I have already started with Chapter-6. @KailashVohra can start with
something else. Also I have my exams going on now, I'll start back by next
week.

I'm keen to contribute to this too - am happy to pick up Chapter 6 to
start with.

[kaiesh]

Oh right - I've already sent a pull request for 6.1.1 Map Coloring...
On 19 May 2016 11:14 p.m., "Giri Gaurav Bhatnagar" notifications@github.com
wrote:

I have already started with Chapter-6. @KailashVohra can start with
something else. Also I have my exams going on now, I'll start back by next
week.

I'm keen to contribute to this too - am happy to pick up Chapter 6 to
start with.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#27 (comment)

[kaiesh]

Ah OK, you've reassigned chapters - I had started work on Chapter 13, I'll commit the progress to the same pull request, so both can be merged.

@umgupta if you think its useful you can build from that.

@Ghost---Shadow you may consider allowing people to request for chapters to work on that interest them. Progress may move faster that way.

Cheers!

[Ghost---Shadow]

@kaiesh Requesting chapters seems a good idea. Start placing your requests.

[kaiesh]

@Ghost---Shadow I'd started on 6 and 13, so I'd be interested to continue and complete those.

[umgupta]

Hey Guys,
I read previous discussions and here are few of my suggestions :

1. Build / testing process. Why do we use jspm & gulp when there are better options (read webpack). A google search for jspm Vs webpack will give enough arguments to convince you. But main features are hot loading & single command build. I can happily port whatever is there to webpack and write a guide for structuring project using webpack. (It takes care of uglifying/minifying and splitting the code at one place)
2. What library we use for canvas/svg manipulation ? Or is it simply JS.
3. Can someone please write how to implement a module (where each file should go ideally?)

@kaiesh What should I work on finally?