What is the best way for two students to share code when working on their Create Performance Task?
Disclamer: Any code presented here is not suitable for submission to the College Board because it does not meet the Create Task rubric and will not score well.
App Lab mimics a professional development environment in so many ways, except one. Remix and version control taken together is a lot like GitHub. You can select different versions and share them via URL. That lets you work in parallel on different aspects of a program similar to a source code repository. (Assuming you name your remixes so you can tell them apart.)
What you can’t do like a professional setup is merging. App Lab doesn’t have that for good reason. It is a complex thing to do well. It is made worse by App Lab having a single source file for Javascript code. Some of you are probably thinking that isn’t true. More about that later.
Pair Programming
If students are in person they can pair program1 a project together using one or the other’s App Lab account. When finished that project can be shared and remixed by the other student so both have a copy. That works except for any databases. If they are using code.org supplied datasets they can just import those into the remix and be fine. Otherwise, they will need to export the unique database as CSV and share that file as well. This is the easiest and most unlikely scenario.
Work On Separate Projects
The hardest and most likely scenario is where students want to write code in their own bedrooms speaking to each other as little as possible. The obvious solution to this is for the students to work independently on two projects coming together when one or the other has a problem that cannot be solved. Essentially the partnership is limited to overcoming obstacles together and producing similar code that isn’t actually shared.
Work On One Project
The other solution is two or more students working separately and integrating their efforts. It can be done but it is harder and requires discipline even professional software engineers often refuse. Fortunately for students, it only needs to be one project spanning three weeks in time. Any more than that would cause a teen age head to explode.
Let’s look at two fictional yet typical teenagers who choose to work together on a single code base. They choose to work together because they are each secretly infatuated with the other but neither wants to be first to admit it. This fact will not impact how code is shared it is just typical.
With a whopping 93% chance of dating sometime in the future, Jada and Joe begin work. They must start by first dividing up the work. Choosing good perforation lines between functionality is difficult. They have decided to create an application that will show both the Fibonacci and Factorial for an input number. This has the natural dividing line of Jada working on Fibonacci while Joe works on Factorial. Not all project choices will split apart that easily.
Both Jada and Joe will go into design mode and create their best idea of what the GUI2 will look like. Joe takes a minimalist approach and produces this
Jada selects the Polar Theme and creates this pocket sized masterpiece
The would-be prom couple wisely chooses to use Jada’s version. They need to share it before they continue. Jada clicks on Share and sends the URL to Joe via text message. Joe clicks the down arrow next to screen1 and selects Import screen…
He enters the URL that Jada sent him. Then clicks Next.
He selects Jada’s screen1 and clicks Import.
Jada and Joe now have an identical screen1 to work from. Now Jada creates this code
Meanwhile, Joe has created this code
Jada likes Joe’s use of functions (among other things) and they choose joe’s code. They need to share it. This time Joe clicks Share and sends the URL to Jada via text message without realizing how important having Jada’s phone number will be later. Jada, equally unaware of the significance, opens that URL. She clicks on </> View code.3 Now she selects Joe’s code, right clicks on it, and selects Copy. Going to her own project she selects all her code, right clicks, and chooses Paste. Now they have duplicate projects again.
Jada works on showFibonacci while ignoring showFactorial. She creates this recursive beauty.
Joe continues on a more traditional path and hopes to impress Jada with this code
Both pieces work so now they need to merge. Since Jada merged last time it is only fair for Joe to merge. Jada clicks share and sends the URL to Joe. Joe opens the URL and copy and pastes Jada’s code into his project. He can now share the entire project back to Jada so they both have a completed copy. Jada and Joe both create a video and answer the written portion separately. In the end, they do go to prom together!
At this point, both Jada and Joe have identical projects. They could begin development on additional features. They can then use the same techniques to integrate a second, third, forth, etc. time.
- If you make a change to a screen or add a new screen use Import screen to merge. Avoid changing the same screen at the same time.
- If you make changes to code use copy-paste to merge. Avoid changing already merged code or your partner’s code. Adding a new function is easier to merge.
Corporations used to pay thousands of dollars to hear the following advice. I am giving it to you for free: integrate often to avoid integration hell. That is when two programmers make incompatible changes that must be debugged.
Work On a Shared GUI And 2 Libraries
Before I mentioned that there is a way to have more than one Javascript file in a project. You can do that with libraries. Let’s look at how Jada and Joe would do that. They start out the same with each creating a GUI and selecting the best one. They create an event handler for the calculate button and agree on calling two functions, one for Jada’s code and one for Joe’s code.
Then they each create a library. Jada and Joe both create a library with one function and no GUI. Joe creates an empty factorial function with a comment like this
Jada does the same with Fibonacci. They click on Share then click Show advanced options then click Share as library then click the Share as library button.
Now Joe calls his library Joe and selects his factorial function. He clicks on Publish.
Next, he clicks on Copy ID and sends the library id to Jada via text message or email.
Jada does the same but doesn’t need to send her library ID because she is going to do the integration. She goes to her GUI project and clicks the gear icon.
From the menu she selects Manage Libraries
She copies Joe’s library code into Import library from ID and clicks Add. Then she does her own
Now Jada has two new functions under the Functions tab. The original function calls have yellow triangles because Jada and Joe must specify those functions are in the Joe and Jada libraries.
So Jada adds the library names and the yellow triangles are gone.
Now Jada shares this project with Joe and he remixes it so he has his own copy. When you remix you also get the libraries as well. Now this project has 3 Javascript source files instead of one. Jada can go ahead and write her code while Joe writes his. Jada writes this in her library project.
Jada is done so she clicks on Share, Share as library, then Share as library again as before. She clicks on Select all functions and this time clicks on Update.
This updates her library. Both Jada and Joe can now go to the shared GUI project and bring in Jada’s changes.
Just click on Update. Then click Update again.
The GUI project looks just the same but Jada’s portion of the project is obviously working. You can reference GUI elements from a library and it works just fine. Next joe makes some changes and updates his library. Now Jada can bring in Joe’s changes. Jada and Joe can now test their integrated version.
Joe didn’t write unit tests and didn’t update his GUI and test it so his part doesn’t work.
At this point Jada can look at Joe’s code by going to the functions tab, hover over Joe.showFactorial(n) then click on Show code.
From here she can help Joe fix his bug.
Joe updates his library. Jada updates her GUI project and tries it again. This time of course it works and they are done with the code portion of the Create Task. If they feel more comfortable they can look at the library code via Show code then cut and paste both libraries into the GUI project. Jada is annoyed that Joe didn’t test his part of the project and goes to prom with someone else. Joe stays home and wishes he had listened when his teacher told him to test everything.
As with the single code base sharing method above, integration with libraries can be repeated over and over. As before it is better to integrate often.
- Use Import screen on the shared GUI project when new screens are created or changes are made to existing screens. Share and remix the GUI project with your partner after any GUI change is made.
- Update the libraries often. Merge those libraries into your own shared GUI project often and test your code with the most current version of your partner’s code.
1 The goal of pair programming is to produce a codebase that doesn’t belong to either programmer. The idea of a driver and a navigator was solidified by Dr. Laurie Williams’ book Pair Programming Illuminated. Boston: Addison-Wesley, 2003. I disagree with my friend’s characterization of two different roles. I find there is just one role for both programmers otherwise egos flare and work halts. This is also a big part of Collective Ownership. Leave your ego at the door.
2 Graphical User Interface. Us old timers pronounce it gee-yu-eye. Young cool programmers like Jada and Joe will pronounce it gooey.
3 App Lab code has very little to do with HTML but the HTML-ish </> is used as an icon for the code.
1 Like