On March 9th, we held our 3rd Genesis Shapers Slack meeting. As a reminder, These meetings are a great opportunity for folks to share their thoughts and ideas about Genesis. You can read the recaps of the January and February meetings.
The Genesis Shapers are a hand-selected and diverse group of people representing companies from across the community who have come together to be a representative voice in the strategic direction of Genesis in addition to the feedback we receive directly from customers, across social channels, and through Genesis WP on Slack.
Included in this group are:
Bill Erickson, Carrie Dils, Gary Jones, Greg Boser, Jennifer Bourn, Jon Brown, Jonathan Jeter, Lauren Gaige, Lee Anthony, Mike Hemberger, Robin Cornett, Sara Dunn, Sridhar Katakam, and Tonya Mork.
In the Shapers meeting earlier this month, we discussed some technical elements of Genesis, from local dev environments to regression testing to code snippets.
David Vogelpohl, the Vice President of Web Strategy at WP Engine and StudioPress brand lead, facilitated the conversation, and here was the meeting agenda:
- What local development environments do you think most Genesis developers use (if at all) and why?
- What role do you see regression testing playing in the Genesis context? What tests or testing approaches should people be using?
- Do you think learning advanced dev techniques like WP EngineÔÇÖs LocalDev & regression testing will actually help Genesis developers in ways that help them grow?
- What Genesis Code Snippet libraries are the most useful? StudioPressÔÇÖ snippets? Genesis.community snippets? Other?
- Do you think it would be valuable to let people contribute snippets to a public repo which is curated and available for all to use?
Local Development Environments
David Vogelpohl kicked off the meeting by asking the Shapers what development environments they use. Mike Hemberger jumped right in:
ÔÇ£In just this Slack group we have Valet, Valet+, Lando, Local by Flywheel, DesktopServer, MAMP, and probably more.ÔÇØ
Jon Brown echoed what Mike said, with a few additions:
ÔÇ£Local by Flywheel and Desktop Server. IÔÇÖd be willing to bet more than 95% of genesis devs use one of those two. A few percent use MAMP and the rest a various collection of things from VVV to Valet to Lando to Chasis to whatever.ÔÇØ
Personally, I use MAMP, but as Jon pointed out, I am probably in the minority. I donÔÇÖt do local development often since IÔÇÖm typically not working without WIFI connection or on sites that canÔÇÖt be live.
Representing DesktopServer was Lauren Gaige and Laragon was Robin Cornett.
Carrie Dils mentioned this, which also brought about its own thread of back and forths:
ÔÇ£IÔÇÖd suspect most are using a GUI dev environment like DesktopServer or Local.ÔÇØ
David followed up by asking:
ÔÇ£Why do you all think devs are making those choices? Anything specifically beneficial to Genesis developers as a group (e.g. Carrie’s points on GUI)?ÔÇØ
Tonya Mork explained why she uses local dev:
ÔÇ£Why? Because it lets you quickly spin up and gets out of your way. You can then focus all of your energies on developing instead of messing around with tooling.ÔÇØ
Tonya went on to say:
ÔÇ£What I prefer about Local vs. DS is I can quickly switch the environment through the GUI for each site. A couple of clicks and I can change it from PHP 5.3 to 5.6 to 7.2. That helps me to run the tests and ensure compatibility locally with different environments.ÔÇØ
Before we moved on to the next topic, John Parris from our team said:
ÔÇ£I use Local too. Quick PHP/MySQL version changes is very handy. Site cloning. Blueprints. ngrok integration. Auto-populating creds for Sequel Pro. Mailhog. Easy SSL cert trusting. It basically does everything I need in my day to day work.ÔÇØ
From the conversation we had around local development environments, itÔÇÖs clear to me that developers do in fact rely on them. Of course, like any software, a variety of sources is well represented, and more than like different folks use different tools for different reasons.
Regression Testing with Genesis
David moved us to the next topic by asking:
ÔÇ£What role do you see regression testing playing in the Genesis context? What tests or testing approaches should people be using?ÔÇØ
I stood as a bystander in this conversation because I donÔÇÖt fully understand what (and how) regression testing works, but the conversation was definitely interesting.
For those like me who needed an explanation, Carrie provided us a link. (Grins.)
Jon offered his opinion on the matter:
ÔÇ£Sounds fancy but weÔÇÖve never found automated/unit/regression testing of themes to be practical.ÔÇØ
To which Nathan Rice brought up the concept of ÔÇ£lintingÔÇØ and ÔÇ£code standardsÔÇØ:
ÔÇ£Linting … making sure that your code isn’t broken syntactically. Code standards … making sure the code adheres to the WP standards. it absolutely can. if a test that was previously passing suddenly fails, it’s (at the very least) a red flag.ÔÇØ
And I love what Bill Erickson added here:
ÔÇ£WPEngines checks when you `git push` have saved me a few times.ÔÇØ
There wasnÔÇÖt a whole lot more to the discussion around regression testing, which paved the way to the bigger topic at hand.
Genesis Code Snippet Libraries
Ok, time for the can of worms. David led this part of the meeting with this:
ÔÇ£What Genesis Code Snippet libraries are the most useful? StudioPressÔÇÖ snippets? Genesis.community snippets? Other?ÔÇØ
This was easily the bulk of our meeting, as I suspected it would be. As the provider of many Genesis Code Snippets, I was very interested to hear what the Shapers thought about the topic.
Lauren shared her process, which I think many folks in the Genesis community would concur:
ÔÇ£I generally start at SridharÔÇÖs site and if I canÔÇÖt find it there I Google.ÔÇØ
Jason Cohen, CTO of WP Engine said it best:
ÔÇ£SridharÔÇöthe new home page on the Internet.ÔÇØ
Sara Dunn quickly chimed in:
ÔÇ£I literally will not go to someoneÔÇÖs snippets and look through them to find what I want. I think many people just Google. I want tutorials, not snippets.ÔÇØ
Most of the snippets I publish for others to use are short, very basic ones. What Sara is suggesting is that contextÔÇöor specific use caseÔÇöof code snippets is far more valuable.
Jon echoed that as well:
ÔÇ£I value ÔÇÿblog posts with snippetsÔÇÖ far more than ÔÇÿsnippetÔÇÖ out of contextÔǪ that said IÔÇÖve been known to troll through BillÔÇÖs gists and find gold on occasion.ÔÇØ
I think that snippets within tutorials are more prime for a less experienced user, and normal code snippets (without context) are for someone who knows they want to do something just need to remember how to do it.
Tonya added:
ÔÇ£I tend to get a lot of people asking me how to adapt a snippet for their specific needs. One-size-fits-all snippets donÔÇÖt fit all use cases. Tutorials help when thereÔÇÖs an explanation of why it does what it does and a customization strategy.ÔÇØ
And Robin expressed:
ÔÇ£For those of us who want to know why something works, context, comments, explanations are great–but in supporting plugins, I’m finding that people don’t really want to know why, and often aren’t willing to bang on things to tweak them.ÔÇØ
David recapped this part of the discussion:
ÔÇ£So to recap these thoughts… Snippets are good, some collections better than others (@sridharkatakam is the best), and snippets are also a learning tool best paired with tutorials / documentation?ÔÇ£
I think he is spot on with his assessment, by the way.
The conversation around code snippets moved into the idea of repositoriesÔÇöwhere to host them, who should host them, and the importance of keeping them updated. The idea of a central repository is daunting for many reasons.
Mike pointed out the obvious:
ÔÇ£Managing would be crazy. 10 different versions of similar snippets, all with various coding standards/styles.ÔÇØ
And Carrie brought some valuable insight to the ramifications of a central repository:
ÔÇ£I do wonder, however, if a public repo like that would take away from the visibility of people like Sridhar who earn a living from their tutorials/snippets.ÔÇØ
I love her heart for the community, and this is something that I also think is true.
While I understand the need for sharing code snippets within the community, there are also a few things to consider. In addition to the code quality, they would have to be monitored/updated as new iterations of Genesis come out.
To which Robin dropped the mic with this:
ÔÇ£Especially if 3.0 changes all the things.ÔÇØ
Helping Genesis Developers Grow
David brought us home for the last portion of the meeting by asking this:
ÔÇ£Do you think learning advanced dev techniques like LocalDev & regression testing will actually help Genesis developers in ways that help them grow?ÔÇØ
Carried kicked off the responses:
ÔÇ£Grow? Sure. But the money in streamlining processes for more effective and efficient development, which in turn increases margin on projects. My customers donÔÇÖt care how I get it done. What matters to me is how much time it takes me to deliver. The more effective and streamlined I am, the bigger my margin.ÔÇØ
Robin chimed in:
ÔÇØI think it depends on whether youÔÇÖre talking about developers who build one off sites or who are producing something for the masses. one off, not so much, I would think–a lot of times the goal is to just ship it.ÔÇØ
Bill finished up the trifecta with:
ÔÇ£None of my clients care about my dev tools. They just want a high quality product delivered quickly and affordably.ÔÇØ
In my opinion, these responses sum up what I have experienced over the years leading StudioPress: A customer wants a beautiful website, and if they hire someone to design/develop it, they worry less about the ÔÇ£how it gets doneÔÇØ and more about ÔÇ£what it looks like and how easy it is to use.ÔÇØ
And thatÔÇÖs a great spot to end the recap of the March Genesis Shapers meeting.
As IÔÇÖve said before, itÔÇÖs an exciting time to be in the WordPress space. By focusing on the development of Genesis and suite of tools that extend it further, I feel confident that our team will be able to keep pace and continue to provide the best digital experience possible for our customers.
This blog was originally posted on Studiopress.com This post is in no way associated with Kembel.ca. For more posts by this author, please click here.
