Introducing DRY WP

Have you ever found yourself writing the same piece of code again and again when building a WordPress theme?

So did we, until we worked on making our development process as DRY as possible. Now we've got that process down to a tee, we want to share it with the world.

We are proud to introduce DRY WP, an online course that will teach you the processes that we use internally to develop WordPress themes quickly and efficiently, without compromising on code quality.

DRY WP is all about helping other agencies and developers to speed up their theme development by using a DRY (Don't Repeat Yourself) methodology. Based around template parts, which we call blocks, DRY WP will show you how we construct these to be as flexible as possible whilst saving everyone as much time as it can.

As well as templating, we'll also cover how we organise our admin fields so that we can re-use them alongside our blocks, meaning less hassle when re-arranging or updating a template on the admin side of things.

The course doesn't tell you that you need to use a certain starter theme or a new framework. Instead, we will introduce you to the methodology behind re-using template parts, how you can fit that into your current workflow and how adopting this methodology can make your life easier as a developer. 

Following this methodology will help you build themes in less time and with less effort, ultimately meaning you can make more money!

Check out DRY WP now for more information on the course and let us help you.

Daryll DoyleComment
Our Process
jefferson-santos-450403-unsplash.jpg

As demand increases on a business, there comes a time when you look at expanding and taking on more members. The problem is, especially for small 1-3 person teams, that most of the agreed best practices are in peoples heads.

How are you meant to inform a new member how the team works if it's not documented anywhere? Believe me, helping new additions adapt faster to the working habits of the company is a massive bonus and a boost in productivity.

It's safe to say that Nymble has hit this stage recently and that has created the need for us to finally write down our best practices for developers.

Over the past week, I've been sat at my desk planning and documenting all the main beliefs and ideals of Nymble's development team and what keeps our work up there with the best.

Planning the Document

Figuring out the structure and format of the document was our first task and deciding on the format was actually one of the easiest decisions. Being a forward-thinking digital company, with remote workers, it only made sense to build a wiki-style site that we could send out to everyone as they join. It also meant that current team members could refer back to it at any point.

We ended up deciding on the following structure:

About

In this section, we give some information about the document such as who it's aimed at, as well as its goal.

Tools

Here we briefly describe the tools that would be needed for new team members. We cover things such as IDEs and text editors, local environment and command line tools that will be needed to work smoothly within the Nymble team.

PHP

As our business mainly works within PHP, it's only right we lay out our PHP best practices.

This section is split into a couple of sub-sections.

Vanilla PHP

Here we discuss code style and our thoughts on controller structures when working outside of WordPress. Things such as talking about our use of the Hexagonal Rails Architecture

WordPress PHP

In this section, we inform the reader about our guidelines for WordPress development. Whilst we mostly follow the official WordPress guidelines for PHP development there are a few deviations that make debugging smoother and readability easier.

WordPress Themes

As we work a lot with WordPress themes, we thought it was best if we wrote about our basic starter theme, it's requirements and installation as well as any plugins we use on a regular basis.

We give our theme structure and what each directory should do in order for people to be able to pick up our themes with little hassle.

CSS

We have discussed our best practices when writing CSS/SCSS in this section. From our philosophy around CSS right down to our structure, naming conventions, and rules around nesting.

JS

In this section we talk about JavaScript performance, the best practices when writing JavaScript and the code style we prefer to use when writing it.

Markup

Semantic markup makes a site what it is, so this is what we wrote about in this section. Why we write markup like we do and how people should continue doing it.

Standardising this makes everyone's life easier!

Testing

Why, when and how we automate testing using Behat and PHPUnit.

Git

Our Git methodology

Writing the Sections

So now we'd planned the sections and agreed on a format for the document it was time to start actually fleshing it out. This was pretty easy as we'd already decided a lot of what needed to be said during the planning stage. It was simply a case of sitting down and getting it written.

 

In our case, Markdown seemed like the best option for writing. Not only is it easy to read and format for the author but we could use a generator like Hugo to compile it into a static website as we'd agreed, so this was the route we took.

Why Release It?

This was a simple decision for us. We'd just documented how new and current team members should work in order for us to write our best code and build the best projects we can, why wouldn't we then release that to the world?

We believe in our development processes and are confident that they work, after all, they enable us to put out the work we do. We want others to see how we work, documenting our process allows others to scrutinise them. Not only can they then look at their own internal processes and make changes if they need to, but they can also talk to us about ours.

The development ecosystem is ever-changing and we always want to be at the front of the pack. Only through collaboration can we keep learning and evolving.

Looking Forward

We now have a near complete handbook of our working practices to give to new team members in order to help bring them into the team and keep Nymble working at its ever high standard.

Feel free to go and take a look at the handbook at https://engineering.wearenymble.co.uk and let us know what you think.

Are there any changes you'd make? Have you documented your processes and if so how did you find the task?

Daryll DoyleComment
An exciting announcement!
Screen-Shot-2017-10-31-at-15.31.58-1066x709.png

We are proud to announce that our startup go-do.it has been chosen to pitch at one of Europe's biggest startup festivals!

Uprise Festival started out in Amsterdam and now resides in Dublin. Since Dublin is home to some of the most exciting early stage startups in Europe it seems like the perfect place. The two-day event has people coming from all over Europe to attend patch battles, talks and there's even some music in a tech event that's a little bit different from the norm.

With 2000 people in attendance there should be plenty of opportunities to get our message of "Doing more stuff" out to people.  We are going to have space in their startup hall and will have a couple of days pitching chatting and onboarding as many people as possible. It's going to be to be a fast-paced exciting event and we are looking forward to the opportunity!  

https://go-do.it/

https://business.go-do.it/

andy foleyComment
My WordCamp London 2018 Experience

The 15th of April, 2018. To you, this may have seemed like any other Saturday but for me it was one of the most nerve-wracking yet also one of the most exhilarating days of my life. Why? I hear you ask. I gave my first ever talk at a conference and at WordCamp London no less.

At 10:50 on that day I gave my talk "Securing SVG Uploads in WordPress" to a reasonably busy room on Track C. My talk covered a brief explanation of what SVGs are, then moved through to XML and SVG vulnerabilities, onto the sanitisation side of things and then finally how we can integrate this into WordPress.

The subject of the talk is quite a niche one, so whilst I was surprised that I got chosen to talk at all, I was just as surprised to see people filtering into the room to get listen to me with 5 minutes to go. Nevertheless 10:50 came around and it was time for me to start.

To say I wasn't nervous would be a lie, not only had I never spoken at a conference before but I also wasn't sure how the subject would go down and this specific talk was quite technical. That said, I made my start and worked my way through the slides.

The content seemed to go down well, although my delivery could have been improved upon and I finished my talk around 5 minutes earlier than I'd planned, 25 minutes into a 40 minute slot. Not to worry though, the ever helpful WordCamp MCs jumped into action and took charge of the room, facilitating a very useful Q&A session where I felt a lot more at ease.

After around 35 minutes the session was called to a close and people started to move towards their next talk, although I had some very good discussions after the Q&A had ended. That was it, I'd finished my talk and I could relax.

Looking back on it now there are a few things that I will remember for next time I give a talk:

1. You can never have enough practice beforehand
2. Don't forget to drink water (it's surprising how dry your mouth gets)
3. Slow down your talking
4. Don't worry, people are there because they want to listen to you
5. Enjoy it!

Ultimately, I really did enjoy giving this talk and will definitely be applying to talk more in the future.

I'd like to thank WordCamp London and it's organisers for giving me this opportunity, the WordCamp volunteers for being amazingly helpful and calming my nerves so much before, during and after my talk and of course the attendees for wanting to hear what I have to say.

WordCamp London was a great event and I really can't wait for the next one to come around!

N.B. The talk was filmed so I'll update this post with that as soon as it's online. In the meantime here are my slides.

 

Daryll DoyleComment
What is onshore offshoring?

Onshore offshoring. Nymble has been founded on this principle. but what does it actually mean?

In the past few years more and more companies have been offshoring projects, this normally involves sending a project to a company in India or elsewhere. This has lead to a number of difficulties. Working across different timezones can be problematic. Arranging meetings and even hitting deadlines can be difficult. Even simple things like language differences can throw up problems once a project has launched.  

At Nymble what we enjoy doing is providing technical and coding abilities to businesses. This gives you the flexibility to take on more projects or implement new internal structures without having to employ new staff.  We can take on whole projects from fully custom built projects to wordpress builds. So whatever your project think of us.