DEV Community: Elanor

Onboarding New Developers (a series) - The First Week

Elanor — Sat, 04 Sep 2021 02:56:34 +0000

In this series, I'm going over how I onboarded a new hire into my development team. I wasn't given a lot of predefined onboarding resources, so I had to develop a plan of my own. If you missed the intro, make sure to read it to have a better understanding of what information I used to make my onboarding plan.

Read the Introductory Post Here

The First Week

The First Week with your new developer will depend heavily on your goals for the employee within your team, and your organization’s onboarding process. For instance, a previous company I worked for spent the first entire week as a cohort of new hires learning about the company’s history and the industry as a whole. Very little time was actually spent with the employee’s actual team during the first week.

If this is the case for your organization, consider “The First Week” to be the first week that the employee can spend with you on a dedicated basis. For my employee’s first week I wanted them to have the resources they needed to be successful, and if they didn’t have those resources yet, to ensure that all requests were in process so that we had a timeline when they could be fully up to speed.

I set up a schedule for the first week with bullet points to get the new hire up to speed with their team members, our normal meeting schedule, and the company culture, as well as the tools we use. There was zero expectation that any meaningful work would be done during their first week.
Though it was broken up into different days, the bullet points on each day were not an end-all-be-all set in stone schedule. They could complete tasks on different days as it suited them. My goal was that most of the tasks be completed before the end of the week.

This schedule included reading materials from our intranet, employee handbook, as well as documentation on the various systems and frameworks that our team uses on a daily basis. Much of this documentation already existed in-house in our Confluence site. If your company doesn’t have resources like these, you may have to come up with some basics and bullet points on your own.

Here is an example:

Monday
- Meet with Manager
- New Hire Intro with HR
- Get your computer set up the way you like
- Make sure you have all the software you need
Tuesday
- Read our Team Member Guide (with a link to this resource)
- Read through New Hire Documentation (our HR department has an entire section of our Intranet dedicated to New Hires)
- Read the Slack Guide
- Read the Zoom Guide (Add any tools or software your team uses to make sure the new employee has plenty of time to get up to speed)
Wednesday
- Mid week check-in with Manager
- Get familiar with framework that we use (Link to the documentation of the framework or software that your team develops on a regular basis. For example, Laravel, Nuxt, etc)
- Learn about Jira and Confluence (if your company has documentation or other ticket tracking tools, list those in the first week schedule and make sure to answer any questions about their use as early as you can!)
Thursday
- Learn about our company culture (have the new hire talk to other employees, meet all the team members and other people at all levels of the company if possible)
- Schedule a meeting with a team member and get to know them (preferably someone outside our team)
- Get familiar with our Development Process (this included a link to our “Developer Manifesto”)
Friday
- Order any office supplies you need to make your home office productive!

First week overall goal

The new hire has the tools and resources to get some actual work done next week. They’ve met their teammates, they have the software they need to get started, and their access to systems and code they will need has been set up. They should already have (or be in the process of receiving) equipment and licenses necessary to be a productive member of the team, starting on Monday.

So What's Next?

Your employee should be on good footing to do some actual work next week. Start them off at their comfort level (and that of your team's) with paired programming or a small individual ticket.

It's important not to micromanage them. No one enjoys micromanagement. Allow them the freedom to figure out how they fit within your team, but give them the tools and structure to succeed.

The next post in this series will go over the 30-day plan, and how to keep your employee engaged and active as they get used to working with you and your company!

Onboarding New Developers (a series)

Elanor — Thu, 26 Aug 2021 21:05:50 +0000

Congratulations! You’ve hired a new employee! But what now? Maybe your company has a regimented onboarding process for new employees already. Maybe it doesn’t. Either way, introducing and integrating them into your team will be a unique, but important process.

I recently hired and needed to onboard a new developer and, as a new manager myself, did not have a lot of resources to start with. The last thing I wanted was my new employee to arrive and feel overwhelmed or lost during their first few days and weeks. Getting your new employee familiar with procedures, software, and the way your team works at a comfortable pace will go a long way to make them a productive member of the team!

As I was researching this question: “How do you onboard a new developer?” I came across a lot of different approaches. I took many of the recommendations and combined them with my own desires, if I were that new employee. I was constantly asking myself, “How would I want to be introduced and welcomed to a team?” As you are reading these ideas, make sure that you’re thinking about how you can personalize this process; each team and each employee will be different.

Let’s get started!

What are your goals for your new hire?

The entire onboarding process depends on your goal for the employee as a member of your team. This should also be informed by their role within the team. If they are a junior member, you wouldn’t expect them to be a subject-matter expert or leading project initiatives at the end of their first 90 days. If they’re being hired into a more senior position, however, you should expect them to be comfortable with small leadership tasks at the end of your onboarding process.

Before you can begin onboarding, or even developing an onboarding plan, you need to consider why this person was hired in the first place. How can they become a contributing member of your team? What tools will they need to be successful? And how can you help?

What resources are already available to you?

Don’t reinvent the wheel if you don’t have to. Make sure to fully utilize any resources that your company provides to new hires and gather links to these items in a central location so they are easy for your new hire to access.
Our company has a well-defined goal setting process which it uses to evaluate employee performance at the end of each calendar year. Each employee’s annual goals are linked with our company’s Core Values, so many of the goals of onboarding the new employee were linked with these core values as well.

Existing Onboarding Process

More than likely, your company has some sort of dedicated on-boarding process. In the case of my company, the new employee is shipped equipment, granted access to systems and servers, and has accounts created in various benefits and HR management systems. However, there was no concrete onboarding process for our development team. (That’s one of the reasons I’m writing this article; to help managers like you figure out what you might need to be successful!)

Intranet

Your company most likely has some sort of repository of internal documents, such as benefits information, employee handbooks, etc. Wherever this may be located, make sure you go over it with your employee so they understand how to access these documents and what is included. Your HR department may go over this, but it can’t hurt to reiterate the importance of reviewing all the important “corporate” stuff.

Code Documentation (internal & external)

Hopefully your team maintains some code documentation so that the new employee does not have to rely on face-to-face conversations with other employees. If they do, make sure that your employee has time to read through all of this information and is shown how to access it.
If you don’t have this kind of documentation for your systems and software, you will most likely need to schedule time to walk them through the basics of how the systems operate. This might involve scheduling time with other team members who know more about specific components and can perform adequate walkthroughs.

Even with technical documentation in writing, ask your new employee how they learn best. It’s possible that they will learn more effectively with a walkthrough than by reading documentation.

Team Experts and Mentorship

The most important part of onboarding is integrating the new employee into your team! And a great way to get them integrated is to have your team experts on different parts of your systems mentor the new employee as they are working through tasks that deal with those parts. If you do not have “team experts” or have a few people who may fit the bill, try to identify at least one person who knows the most about a specific facet of your system or software. Have a diverse set of work ready for your new employee to work through, and as they get to each new area, they can pair up with the team expert to learn from their expertise.

Setting up 1:1s with your new employee

This is actually one of the first steps to a successful onboarding process, in my opinion. You, as the manager, need to be available to your new hire to answer questions and guide them along the process as they get used to the way your team and your company do things. One of the very first tasks you should do when your employee gets access to their calendar is to set up regular meetings with them on an ongoing basis.

Initially, the 1:1s need to be much more frequent then your normal meeting cadence with your existing team members. For instance, I meet with my team members on a bi-weekly basis. With my new hire, I met with them weekly for the first month and then checked in to see how they felt about moving to the bi-weekly schedule at that point. I was also available for ad-hoc meetings, calls, and slack chats whenever I could be, since I fully expected them to have lots of questions in the first weeks they were with us.

If you, as the manager, don’t have that kind of availability, try to have a senior member of your team act as a mentor and onboarding guide. (Even if you do have wide availability, having a team mentor is still a good idea). It’s crucial that your new hire isn’t left waiting with questions while they are getting acclimated; they might forget what they wanted to ask and miss out on critical details or make a silly mistake that will take more time to fix down the road. Better that they can address their problems and questions immediately then having to wait.

Next Steps

The next step is to take all of this information that you have gathered and make a plan of action for your employees first days and weeks. You don't want your new employee to be overwhelmed with tasks, but you also don't want them sitting at their desk twiddling their thumbs.

In the next few posts in this series, I will go over a 7-day, 30-day, and 90-day plan to get your employee integrated into your team and become a productive developer at your company!

Starting up a new Statamic site with Lando, Part 1

Elanor — Fri, 05 Mar 2021 04:54:34 +0000

Photo by Michael Dziedzic on Unsplash

Why Stamatic?

I have been meaning to rework my website for several years, but other projects have always gotten in the way. I was waffling between a Laravel custom site, Wordpress, flat file sites, others.. you get the idea. That was also not helping with the spinning of wheels and getting nowhere.

When Laravel News announced that they had updated their site to using Statamic 3, I looked into the platform in more depth. (They also have a really cool write-up from the team that helped migrate them from Wordpress to Statamic here)

Please come along on the ride with me as I try to boot this thing up and rebuild my website with Stamatic.

Lando

Another tool I had recently learned about is Lando, which is a very simple Docker-based site configuration tool that makes spinning up new web development projects super easy. Docker makes everything easier to develop and release since it is all self contained, and Lando takes a lot of the initial overhead of Docker container setup out of the equation. It even handles the creation and management of HTTPS certs, so you can develop securely on your localhost right out of the box. I highly urge you to check it out.

Getting Started

Install Lando

Step 1 is to install Lando which varies depending on your operating system. On Linux, you can follow their simple four step process which includes installing Docker Community Edition. The Windows installer includes Docker Desktop, as well.

After you have installed, verify your installation by attempting to use the lando version command -- which should print out the current version installed.

Create your Lando + Statamic Project

The beauty of Docker (and Lando) is that you don't have to have any of your dependencies installed on your local machine, you can use the containers to do everything for you. Lando makes this super simple. Without composer installed locally, we can install the Statamic installer and start up a new application folder with a few commands.

$ mkdir my-cool-project
$ cd my-cool-project
$ lando init \
> --source cwd \
> --recipe lamp \
> --webroot public \
> --name my-statamic-site

It will create the .lando.yml file for you:

name: my-statamic-site
recipe: lamp
config:
  webroot: public

Lando comes with several recipes out of the box, and LAMP, LEMP, or even the Laravel recipe will work (if you install Statamic's Laravel package). For this tutorial, I chose the LAMP stack.

Configure Services (Optional)

I did not configure much at this point, but before building your images and containers, now is a great time to check out the Lando documentation to see the additional services and configuration you can add to your project. Statamic doesn't require anything beyond the LAMP recipe's defaults.
Each recipe has it's own available options, so make sure to read through the available configuration for the one you choose.

Install Statamic

From the base Lando configuration, we can use the composer image to install Statamic (from your newly created project directory):

$ lando ssh -c "composer global require statamic/cli && statamic new placeholder"

NOTE I was unable to figure out how to install statamic into the current directory, so we're installing it into placeholder and then we'll move everything up to our root directory afterwards.

After it's installed everything, move the project files up a directory (frustrating, but if you actually do want to keep this directory, you can just use that instead of the placeholder name -- just make sure to update your webroot in the .lando.yml above):

$ cd placeholder
$ mv * .* ..
$ cd ..
$ rm -rf placeholder

Booting it up for first run!

You now have Lando configured, which will take care of your technology stack, and you have installed Statamic which is the software we will be using to build the site!

Let's turn it on! From our working directory, type the following command:

$ lando start

This will build all the Docker containers and images and get everything up and running. At the end, Lando will provide URLs where you can access your new shiny website!

   ___                      __        __        __     __        ______
  / _ )___  ___  __ _  ___ / /  ___ _/ /_____ _/ /__ _/ /_____ _/ / / /
 / _  / _ \/ _ \/  ' \(_-</ _ \/ _ `/  '_/ _ `/ / _ `/  '_/ _ `/_/_/_/ 
/____/\___/\___/_/_/_/___/_//_/\_,_/_/\_\\_,_/_/\_,_/_/\_\\_,_(_|_|_)  


Your app has started up correctly.
Here are some vitals:

 NAME                  statamic                             
 LOCATION              /home/<your_user>/workspace/statamic      
 SERVICES              appserver, database 
 APPSERVER_NGINX URLS  https://localhost:49155              
                       http://localhost:49156               
                       http://statamic.lndo.site/           
                       https://statamic.lndo.site/

Now your new site is up and running with only a few commands!

Create your admin user

The final step is to make your super user and get started on the control panel. Make sure you choose yes when asked if you want your user to be a super user!

$ lando php please make:user

Email:
 > youremail@yourdomain.com

 Name []:
 > John Smith

 Password (Your input will be hidden):
 > 

 Super user (yes/no) [no]:
 > y

User created successfully.

Wrap Up

In this post, I went over how to install Lando to get a really quick LAMP or LEMP stack up and running and also installed Statamic! As I work more on building my new website, I will update with Part 2 -- which will include basic content creation and a little bit of tinkering with the layout and theme.

Testing DataTables JSON response in Laravel without using Dusk

Elanor — Mon, 18 May 2020 19:48:28 +0000

Recently, I needed to quickly test Datatables-as-a-service implementation but I didn't want to use Laravel Dusk for just one test. An easy workaround is to check that the JSON response contains the data that you're looking for. But because this is encoded I ran into a caveat with the random test data.

For example, I was filtering the datatable so that administrator users can see all the entries, but normal users can only see their own entries. We expect the JSON response to only have the data related to the specific user viewing the results.

Test That Users Can Only See Their Entries

public function testUserCanOnlySeeTheirEntries() {
    $user = factory('App\User')->create();
    // Create one that belongs to me
    $user_entry = factory('App\Entry')->create(['user_id' => $user->id]);
    // Create one that is random
    $other = factory('App\Entry')->create();

    $this->actingAs($user)
       ->getJson(route('entries.index'), ['HTTP_X-Requested-With' => 'XMLHttpRequest'])
       // See the users' results as expected
       ->assertJsonFragment(['end' => $user_entry->end->format('m/d/Y h:i A')])
       ->assertSeeText($user->name)
      // Don't see results that do not belong to me
       ->assertJsonMissing(['end' => $other->end->format('m/d/Y h:i A')])
       ->assertDontSeeText($other->user->name);
    }

This test worked great, until it didn't. If Faker happened to generate a user's name with special characters, like Ellie O'Neil the test would fail due to encoding. Ellie O'Neil could not be found in string: Ellie O'Neil

Technically the application was working fine -- since this data will be passed to the browser for display it doesn't matter if it's encoded or not. But we want our CI pipelines to succeed no matter what the randomly generated data might be.

Quick fix for this is to use htmlspecialchars to encode the search string so that it will match the JSON results no matter what.

// Change
->assertSeeText($user->name)
// to
->assertSeeText(htmlspecialchars($user->name, ENT_QUOTES))

Make sure to use the ENT_QUOTES flag so that apostraphes are encoded as well as everything else.

PHPStorm + Xdebug + Alpine on Docker

Elanor — Wed, 08 Apr 2020 16:50:46 +0000

First, I wanted to thank @aschmelyun for his very informative series on Docker + Laravel for development. If you haven't checked out his posts on this topic, you absolutely should!

You can also check out his git repository for this development strategy.

I've customized and integrated this method into my repos for local development and it's made starting up new projects a breeze.

BUT, I recently worked through getting PHPStorm and Xdebug working with this docker setup, and it was a bit tricky. Here's what I did to make it work:

Add Xdebug to the Webserver `Dockerfile`

Since this image is using alpine, it's a little different than a lot of the approaches you might find if you just google "Install Xdebug PHP." At the end of your app Dockerfile you need to manually install xdebug using pecl, so add this command at the bottom.



RUN apk add --no-cache $PHPIZE_DEPS \
    && pecl install xdebug-2.7.0 \
    && docker-php-ext-enable xdebug

This will download and enable xdebug (change the version to the one you want to use as needed, ensuring that it's compatible with the version of PHP you're using in your dockerfile).

Modify the nginx config to expose the ports

In your docker-compose.yml modify the nginx section to include the port for xdebug:



webserver:
    image: nginx:stable-alpine
    container_name: ${APP_NAME}-webserver
    ports:
      - "80:80"
      # Add the port for Xdebug here
      - "9001:9001"
    volumes:
      - ./:/var/www/html
      # Path to custom nginx config (yours may be different)
      - ./docker-nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app
      - db
    networks:
      - laravel

Add xdebug configuration to PHP's configuration

You'll also need to create a new .ini file to include the xdebug configuration in your PHP config.

Create a new .ini file in your project folder, wherever you want to put it. I called mine docker-xdebug.ini and placed it in the root of my project. If you wanted to organize it into a different folder to keep things organized, you're welcome to do so. Just make sure to define the path correctly when you modify your docker-compose.yml in the following steps:



# File: docker-xdebug.ini
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_autostart=1
;xdebug.remote_handler=dbgp
#To activate XDEBUG remote host must be your local IP address.
#This is not Docker machine ip address, but the ones running Phpstorm
xdebug.remote_host=host.docker.internal
xdebug.remote_port=9001

On Windows host.docker.internal will automatically resolve to your local IP address. You might need a different workaround on Linux or Mac. You can read more about this from Jetbrains.

Now, make sure to include the new .ini file in your PHP configuration in the docker-compose.yml



app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: ${APP_NAME}-app
    restart: unless-stopped
    tty: true
    ports:
      - "9000:9000"
    volumes:
      - ./:/var/www/html
      # Xdebug Config for PHPStorm, check your local path to make sure it exists
      - ./docker-xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
    networks:
      - laravel

Setting up PHPStorm

At this point you should be able to boot your images using the command line docker-compose command or using PHP storm to build a run configuration. You can follow along with the Jetbrains blog post.

Make sure to modify your Xdebug listening port to 9001 in your Preferences: CTRL+ALT+S Languages & Frameworks | PHP | Debug:

In the settings you can also check "Break at first line in PHP scripts" for now just to make sure your connection is working.

Debugging!

If you have your application files available, you can now set a breakpoint in your code and visit http://localhost to trigger the "break on first line of PHP" degug breakpoint. Otherwise, you can create a simple HelloWorld.php file in your public directory and PHPStorm should pick up the breakpoint and display the debugging information in your IDE window.

Make sure you enable listening in PHPStorm to start the debugger:



<?php

echo "Hello World!";

Hopefully, this helps someone else get PHPStorm + Docker working together!

Bitbucket Pipelines + Laravel + PHPUnit

Elanor — Thu, 27 Feb 2020 21:01:55 +0000

I recently decided to enable pipelines in a relatively simple repository to see if I could automate my PHPUnit tests. There's lots of other articles online about getting this to work for laravel, but my application had a few unique requirements beyond the standard Laravel packages:

LDAP for authentication with Active Directory
GD Image manipulation library for use with intervention\image
I wanted to use SQLite in-memory database for my tests
I did not want to commit a "pipeline" environment file, instead using the phpunit.xml file included with Laravel

Setting up Bitbucket Pipelines

The first step is enabling pipelines for your repository. Bitbucket cloud comes with 50 minutes per month for free, so almost everyone can utilize this service without having to pay for an account.

Within your repo, you need to click on "Settings" then scroll down to Pipelines -> Settings

You'll be greeted with a slider to enable pipelines for your repository.

Choosing a Base Image

Once you've done that, you will need to create a bitbucket-pipelines.yml file. Bitbucket helpfully provides a default PHP configuration, but we need to modify it to work for us. Bitbucket uses Docker to load pre-configured images and you can customize them using this file. Dockerhub is a great repository to find the perfect base image for your pipeline!

Bitbucket will automatically handle downloading your repo and linking it into the Docker image, but you will need to include any additional requirements for your specific project. Many tutorials suggest starting with a PHP base image. This is a great starting point and allows you to customize all your requirements from the bottom up.

For example, you could choose to start with one of the official php Docker images, in my case I wanted at least PHP 7.2.



# Start your bitbucket-pipelines.yml file with your base image
image: php:7.2-fpm

The major downside to this approach, is that you have to install and enable all your dependencies from scratch. This also means your pipeline will take longer to complete each time it runs. For the free bitbucket plan, this means you'd be using up more of your free minutes! For my use case, I wanted to pre-load as many dependencies if possible, so finding a Laravel-specific base image was imperative.

After reading several tutorials, I stumbled across this git-lab specific tutorial for Laravel by Loris Leiva, which included their customized laravel Docker image. This whittled down the additional packages that I would need to install to just a few, rather than all the Laravel-specific dependencies.

Writing the `bitbucket-pipelines.yml` file

Loris's image is based on alpine linux, so we can easily install the few dependencies needed for our specific Laravel app within the bitbucket-pipelines.yml file as follows:



# Load the Laravel image for PHP 7.2
image: lorisleiva/laravel-docker:7.2

pipelines:
  default:
    - step:
        # Name your step, in my case I'm running tests
        name: Test

        # Cache composer dependencies to speed building between runs
        caches:
          - composer

        # This is the heavy lifting portion where we install our dependencies
        script:
          # I need to install sqlite for in-memory testing, ldap, and libpng for gd compatability
          - apk --no-cache add php7-ldap php7-sqlite3 sqlite sqlite-dev
              libpng libpng-dev libldap openldap-dev

          # Enable the PHP extensions for the previously installed dependencies
          - docker-php-ext-install ldap pdo pdo_sqlite gd

          # Install composer dependencies
          - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts

          # Run our tests!
          - phpunit --coverage-text --colors=never --verbose

If there's a dependency for Alpine linux you need, and you're not sure how to find it, the Alpine Linux packages reference is a great way to find what you need! Of course, don't be surprised if you have to update your build file a few times to figure out everything exactly.

Viewing your results

Once you have committed your bitbucket-pipelines.yml file, you can view the results of your builds by clicking on Pipelines in the sidebar of the Bitbucket repo interface.

If you click on one of the success or failed lines, you can deep dive into the console to figure out what went wrong.

In my case, I had to add libldap to the apk add command for the php extension to be enabled successfully.