In preparation for Laracon EU in a couple of weeks i figured I’d need to take a device along with me - paper and pen would probably have been fine but Laracon looks to be huge and i dont want to be unprepared, plus you always see rows of silver lids and glowing apple symbols in the photos from developer conferences!
I do almost all of my work on a Dell Precision 7710 which dual boots Ubuntu for development purposes and Windows for my photo editing. I also have a Surface Pro 4 which i use for note taking and photo editing on the go - I’ll be writing about how I keep all of my photos in sync in a future post!
Neither of the above are Macbooks but whilst the Dell Precision runs Ubuntu and anything else I can throw at it, it is HUGE and not ideal to take well … anywhere! So I figured I’d try and get a development environment set up on my Surface Pro 4 instead.
I’d heard of setups using Homestead / Vagrant / Virtualbox before, but since I was using Ubuntu, I’ve never had any need to explore it any further so this really is a guide for first timer noobs. The official Laravel Homestead guide appears to be geared up mostly for Mac users, Windows users will need a bit more help which is where I’m hoping this post will help.
Anyway by the end of this guide I’ll have a Surface Pro 4 running Laravel Homestead and fingers crossed you’ll have a Windows device doing the same thing too! This has been a really long introduction, lets get to it!
I once read an article on the merits of contributing to open source projects, within it i remember the author saying that the even smallest things can make all the difference. They even went on to say that their first commit was fixing a one character spelling mistake.
Open source software has provided me the tools to make my living as a software engineer over the past 9ish years, over that period I’ve always wanted to contribute back to the community to but for some reason I never actually have. Maybe I wasn’t looking in the right places, perhaps i was looking at the wrong projects when my skills weren’t where they needed who knows. I just knew that eventually I wanted to.
Earlier this week I attended my first “Big” Conference - Laracon EU 2016. I’ve been to other tech conferences before but by comparison Laracon EU was HUGE, there were 650 people in attendance in one of the most incredible venues I’ve seen. I sent pictures back to my friends and home who said that it looked like a club night more than a conference!
Where I work, we’ve been using an Ubuntu Server running gitolite to act as our “Source control server” and manage permissions and access. Its worked well, and after some initial configuration (which I recall being pretty tricky) looking after the gitolite instance has been pretty easy and could easily continue to serve our needs as a small business well.
Adding new users required you to get an ssh key from the new user, add it to an “administration repository” and then add their name to a config file within that repository. The same config file could then be used to determine which access rights they had to repositories as well as defining new repositories.
We also use a satis install to act as a private composer for our internal private packages.
One of the things gitolite doesn’t provide you with is any sort of front end at all, everything has to be done through the terminal. It also requires you to have all of the following tools separately:
Issue tracker
File browser
Activity stream
Pull request management
Which are all features that github has built in natively.
After moving our source control server from gitolite to a privately hosted gitlab instance the next thing I wanted to do was get our internal Satis server to automatically update whenever code was pushed to a repository.
Update March 2020 - I’ve given written a newer more updated version of this article, check it out over here.
Introduction
Gitlab provides some good documentation on getting build runners for your projects set up which can be found here. However I haven’t found a good article on setting up Gitlab CI for PHP applications yet.
This article is not going to discuss setting up shared runners on Gitlab since I felt the documentation provided by them in the link above was easy enough to follow, what this I am going to focus on is the .gitlab-ci.yml configuration that I’m currently using in my projects to do the following:
Run PHP CS against our code base to ensure that it conforms to PSR-2
Run PHPUnit against our code base to ensure that our unit tests pass against different versions of PHP (5.6, 7.0, 7.1)
Update March 2020 - I’ve given written a newer more updated version of this article, check it out over here.
Introduction
This article follows directly on from my previous article on adding gitlab’s CI to my PHP projects.
Once we’re happy with our code being automatically tested we might want it to be automatically deployed to a testing server / environment or maybe even production.
After moving to NYC this week, I’ve found the need to move sets of data from my local machine to a server I have back at home in the UK.
Whilst I use Resilio sync to keep things that i use regularly in sync between a number of devices this was more of a one off type deal so I decided to use the trusty command line tool rsync.
My latest projects at work have evolved from being PHP / Laravel applications with sprinklings of Vue JS on the front end to being almost entirely Vue JS components driving the frontend with Laravel backends.
Whilst laravel ships with Laravel-Mix to make webpack / asset compilation easier it doesn’t ship with anyway to lint your javascript.
Luckily adding eslint and defining rules for your .js and .vue files to follow is pretty straight forward.
