Building an application is like building a ship. At various stages, you have to wear different hats of diverse perspectives to understand what goes where next and plan accordingly. At one point, you are thinking about the engine(algorithm), and at another, you are thinking about the design. You have to consider every small detail, to keep the boat afloat amidst storms of technical crises and bugs along with taking care of the fact that every passenger is provided with their own safety kits, here pointing towards the accessibility factor.

That’s how I feel while I sail my ship of nteract-play, which I have to develop while learning the required skills. Also, we don’t talk much about how writing open-source code which is public can be intimidating for people (well, it is- at least for me!). I thank my stars for the fact that I have Safia as my mentor as she is the one getting me through this and making it easier for me to work on my project. In the first two weeks, Safia and I have taken some critical decisions about the same and they have proven to be wise, indeed. If you have not read the initial proposal, I would recommend you to give it a read in order to connect with this piece better.

Let’s look at the in-depth progress so far, shall we?

Workflow

I am working on a different repository, before moving the code to nteract-play. Now you must be wondering why, so let’s just kill the suspense already because I am working on it to eventually make it a part of nteract ecosystem. It will not only lead to individual success, instead, but it shall also influence both the projects and push forward towards success.

My initial proposal constituted of an auto-save mode to save changes when you run your notebook or the cell. However, we decided to go with just user-save mode since we don’t have enough time or bandwidth for the same; however, we always have an option of adding it later. I found this paper “Automatic Code Summarization: A Systematic Literature Review” which can be helpful to choose the right method to generate auto-commits.

Auto-Save-Mode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

st=>start: Get Github Details
user/repo/branch
e=>end: Run
e2=>end: Run

c1=>condition: Repo Exist
c2=>condition: User Logged in
c3=>condition: Wants to Save
c4=>condition: User is owner 
of repo or forked

op1=>operation: Throw Error
op2=>operation: On Cell Run
op3=>operation: Login using OAuth
op4=>operation: Fork the Repo
op5=>operation: Generate Commit message
op6=>operation: Save

io=>inputoutput: Get and Edit 
Content

st->c1
c1(no)->op1
c1(yes)->io
io->op2->c2
c2(no, below)->c3
c3(no)->e
c3(yes, right)->op3
op3(right)->c4
c2(yes)->c4
c4(no, right)->op4->op5
c4(yes)->op5->op6->e2

User-Save-Mode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

st=>start: Get Github Details
user/repo/branch
e=>end: Run
e2=>end: Run

c1=>condition: Repo Exist
c2=>condition: User Logged in
c4=>condition: User is owner 
of repo or forked

op1=>operation: Throw Error
op2=>operation: On Save
op3=>operation: Login using OAuth
op4=>operation: Fork the Repo
op5=>operation: User give
commit message
op6=>operation: Ask user:
output stripped?

io=>inputoutput: Get and Edit 
Content

st->c1
c1(no)->op1
c1(yes)->io
io->op2->c2
c2(no, below)->op3
op3(right)->c4
c2(yes)->c4
c4(no, right)->op4->op5
c4(yes)->op5->op6->e2

Github OAuth

I will be using the already created OAuth-server for nteract-play. As my initial proposal was more about the implementation, I didn’t go in detail about the security of local storage for saving the token. But, I will be taking some measures like encryption etc. to make it more secure. Using the token, we can use octacat/api to perform the following and more key tasks.

  • Check if the user is the owner of the repo. We can do this by checking the username currently logged in and the username of the repository’s owner.
  • octokit.repos.listForks: Check if the fork already exist.
  • octokit.repos.createFork: Create a fork.
  • octokit.repos.getBranch: Check if a branch exists.

Design

I used Figma for the first time to create the above prototype, and it was really helpful. If you are a non-designer (like me) and have to design something, always think about making it accessible for all. I considered it, but then Safia pointed out issues in font and colour. After reading more about it, I reconsidered it. It’s crucial-- you must think about it and improvise accordingly.

If you are not a designer or have issues with differentiating colours or are influenced by colour-blindness -- I would recommend using colour-palettes or taking help from your designer friends. You can also use plugins like A11y-Color Contrast Checker or Color-Blind. If you are using React, then skim through this page once as it might serve to be of some help to you.

I have created this new repo UI-web to start building my design components further and use them in the application.

Learning

I have learned a lot so far. I reread the React docs to brush up my skills (as I have only used it once for a small project). I learned and utilised Figma for the first time for creating that design. I had only limited experience with Storybook, but I am enjoying it so far. I am yet to learn so much more, especially all about redux next.

Conclusion

I am enthused to build my ship as I code it away and get you on board in the process. In the coming days, I will be working on building components and finally integrating Github features in the project. I hope I can complete it on time, *fingers crossed*, so by the end of phase 1 we can have a working prototype for it.

Acknowledgment