In the Developer Interview series, we talk to engineers who use Semaphore. We pick their brains about how they work, what wisdom they would like to pass on, and the most challenging problems they’ve faced during development.
This time around, we had the pleasure to talk to Gant Laborde, a member of the Ignite team and chief technology strategist for the San Francisco company Infinite Red.
1. First, can you tell us a little bit about yourself and how did you start working on Infinite Red’s Ignite?
In 2011 I finally discovered open source on GitHub. Before that, I had only ever built software with people I had met. Though I didn’t realize the potential, I felt drawn to it. In open source, I stood surrounded by people who didn’t carp software but encouraged it. Akin to some filtration process, I made connections worldwide with like-minded people. Two companies I interacted with would later meet in a conference in Paris to combine into one named Infinite Red. Without fear, I had left my day job to join their ranks and begin working in mobile consulting and actively maintaining their open source.
2. What was your main inspiration with the Ignite project?
What would Ruby be without Rails? Frameworks give structure and intricate knowledge across teams, especially when there’s no direction. We had written frameworks and tools like this in the past, but as we joined React Native, we knew it was too young, and we’d have to do the same once again. We set out to research and codify a standard. We still do the same to this day, as standards advance.
3. How do you handle issues and feature requests?
At first, you never know if a project will get attention at all. Most plans decay quietly. It’s this lack of confidence that causes most teams to blench when considering setting up an elaborate issue handling system. The key for us was to start small and keep complete transparency. Every idea, feature, and conversation found its way into a GitHub ticket, even if we could have spoken one on one. This was a sort of mental jumpstart for the project to scale as we created labels and assigned tasks. When each new issue arose, we would develop new guards to protect us. We added contributors guides, debugging commands (like ignite doctor which would later be the inspiration for the new Solidarity library, and git hooks. Even today, we have new advancements we are adding, like Danger JS, upstream checks, and integration verifiers.
4. What is the most interesting problem you’ve come across and how did you solve it?
Supporting diverse needs is always involved. Herbert Bayard Swope, a Pulitzer Prize winner, said it best, “I cannot give you the formula for success, but I can give you the formula for failure – which is: Try to please everybody.” We had to choose some complex points of how to support the majority of needs, but at the same time, we’re opinionated, we’re passionate, and we’re driven by our own needs. Plugins work well for Ignite; it’s there for others. As we move forward with our own “Best Practices” we don’t integrate deeply with plugins. You either do things the way we prescribe, or you get the keys and a pat on the back to build your own solution. Finding those spots is hard. I like to think we have a pretty good solution for that when we released Ignite 2.0.
5. Is your team doing TDD or BDD?
By nature, we’re more FDD (Feature Driven Development). We commonly have to perform this way with our clients who have multiple deliverables and timeline requirements. Sometimes the tests are allowed to be part of the feature, and sometimes the client comes to us with a project that’s half written, and no tests currently exist, so in that case, each test IS a feature.
Ideally, we follow Red Green Refactor TDD as much as humanly possible, but the ideal is great, and great is the enemy of the good. We have written projects end to end with fantastic test coverage, but those are often the exception and not the rule when dealing in consulting.
6. What tools and guidelines do you use to write tests?
We’re evolving with the testing frameworks. Originally, lots of unit tests in AVA, integration tests with shell scripts, and linting checks. Now we’re moving towards TypeScript, JEST, Storybook, coverage limits, snapshot testing, and Detox. JS is still advancing in testing. It’s crucial for us to improve our code spectrometer as new information comes out with each way we shine the light through the problem. Besides that, we just try to enforce that no single person merges their code (or merges after peer review).
7. How does Semaphore help you achieve your goal?
Semaphore is FAST! Also, Semaphore staff has been very personal. I’ve had questions, concerns, and needs over the project, and our communication with Semaphore has always been clear. Even when a feature I ask for isn’t existing, I get a general timeline for if and when that innovation is to be added.
8. What is the most useful Semaphore feature for your work?
Debugging via SSH helps me solve those complex “CI Only” problems that no-one was expecting. We have people developing on all kinds of machines with all sorts of permissions. Rarely do those align with the CI environment! Being able to quickly SSH into the machine and experiment in that specific environment is priceless for getting CI bugs knocked out in no time.
9. Where do you get best JS (React, Redux, Redux Saga, …) practices? Is it something you come up with internally?
We spend as much time as possible to research. All that knowledge is helpful, but there’s always a point where it’s time to cut from the knowledge and get your hands dirty. You can’t learn to ride a bike from reading a book. It’s time to get out there and apply that knowledge. Then we come back to HQ and compare scars. It’s like Machine Learning, the solution with the most success gets picked, and we all arm with that, and head back out into the field to adapt further.
10. Apart from yours, is there an open source tool or project you’re particularly excited about?
Absolutely! The list is endless. I’m pretty active with starring repos on GitHub. I have to say Reactotron is always one of my absolute favorites for my React Native work, and other than that I’m still in awe of the geniuses who maintain Ramda. Open source is my favorite place for inspiration, not just in tools, but in people.
Want to make continuous integration and delivery easy? Semaphore is free for open source and up to 100 private builds per month – set up CI for your project in a few clicks.
