Summary
Our dev retreat the week before last was, as always, time well spent. Our discussions resulted in greater clarity, organization, and structure in our work across all dev teams. Yes, we know, we say this sort of thing after every retreat, but that’s because nothing beats face-to-face time for rapid coherence forming.
Highlights
- How to Run a Distributed Organization
- Code Quality: Exploring Testing Methodologies
- Housekeeping: Getting to Pull Release Zero
- Deprecation Warning: New hc-web-client Available
- Core hApps: Making Scenario API DPKI-Aware
Details
1. How to Run a Distributed Organization
Building a globally distributed team is a double-edged sword. You can assemble the best talent, allow everyone to create their own work/life harmony, and keep your operating overhead low. Plus, many of our dev team members are naturally introverted, so it’s nice to find our ‘sweet spot’ without the bustle and noise of an open floor plan office.
There’s something special, however, about the energy we generate when we get together — late-night brainstorming sessions, exploring problem spaces, spirited and candid discussions of solutions — all of which become more productive when we’re in the same room. We’ve found that the regular rhythm of coming together and dispersing helps to maintain cohesion for both our conceptual understanding of the project and our teams themselves.
We’ve also discovered that these retreats can be quite intense, so we’re learning to take time out individually to recharge. This is a large part of our organization’s commitment to a healthy, balanced working environment.
Because this retreat involved all dev teams — from Holochain Core to hApps to Holo Host — one key item was team restructuring.
We gained clarity on team responsibilities, how to effectively sync our teams, and tuned our task priorities. As the project progresses, and our teams will grow, and roles will expand, contract, and shift; therefore, we need to be open to regular improvements.
2. Code Quality: Exploring Testing Methodologies
A big focus of the retreat was testing — how to ensure everything is well crafted and operating properly — from the micro-level (individual functions) to the macro-level (users’ real needs are being met). We mapped out the many different types of testing methodologies, identified the purposes of each, and came to a good understanding of which projects need which kinds of testing and in what measure. We now have a shared language to talk about testing.
An important outcome of our dev team restructuring is that testing and integration are now at the heart of our development process across the entire organization.
Our long-term goal is to automate things to the extent that hApp developers can actually hook their own apps up to our testing infrastructure. There are two reasons for this goal — one, devs would get immediate notice of core changes that break their apps, and two, we’d get the feedback to see how our changes affect real apps in the wild.
3. Housekeeping: Getting to Pull Release Zero
Some people talk about reaching ‘inbox zero’ — a fabled state of flow where your email inbox takes up almost none of your mental space so you can get on with your real work. Pull requests can also take up mental space and create a drag on your project’s velocity. During the retreat we took a hard look at our pull request processing flow, identifying reasons PRs might languish in ‘open’ state. We arrived at a clear set of standards that you might also find useful:
- Tag pull requests as WIP or RFC if they’re not yet ready for review and merging.
- Choose the number of required reviewers based on needs:
0 for hotfixes, typos, or merges from master back to develop
1 for documentation or trivial changes that simply need an extra pair of eyes
2 for most changes
Everybody for WIPs, RFCs, or contentious topics- During review, make a change yourself rather than commenting.
- Minimize the scope of your PR to make reviews easier.
- Watch out for ‘bad apples,’ or code that contaminates future code — stick to good practices.
- Write unit tests for your changes; they expose bad apples before they fall into the barrel.
- Regularly review the list above and refine best practices.
4. Deprecation Warning: New hc-web-client Available
As mentioned in Dev Pulse 25, we’ve changed the format of JSON-RPC calls to zome functions. That means that, if you’re using hc-web-client in your GUI to talk to a DNA instance, you’ll want to update it. The deprecated format hasn’t been removed yet, but will be soon. Don’t forget that you can get hc-web-client from NPM!
5. Core hApps: Making Scenario API DPKI-Aware
We recently allowed the scenario testing API to specify a DPKI config. What does that mean and why should you care? Well, it doesn’t have a huge impact on your work — unless you’re planning to build a DPKI implementation — but it does help the DeepKey developers test their work.
As you may recall, DPKI is our solution for managing your keys across multiple devices and apps without the centralizing influence of a certifying authority.
It’s meant to make public-key-based authentication as easy to use as, and more secure than, centralized password login. As such, we consider it a ‘core app,’ — so much so that Holochain itself expects it to be installed.
That doesn’t mean that the Holochain Core is tightly coupled to a particular hApp. DeepKey is simply our reference implementation of DPKI, our picture of how it should work. If you write your own implementation, all you need to do is make sure it conforms to a DPKI ‘trait.’ A trait is like an interface, protocol, or contract in object-oriented programming terms. You’d then tell the Conductor to use your own implementation in place of DeepKey.
Development Status:
- 0.0.16-alpha1 Released
- Next: 0.0.17-alpha1
