For me personally, this topic has grown on me and I think it’s time to address it. For a long time I think bad architectural decisions have been made because of an unhealthy culture. I don’t consider this unhealthy culture to be an intentional one, it spawned from good intentions but along the way it backfired. I’d say mostly this is directed at the Laravel community, but it could perhaps apply to PHP in general (I honestly have no idea).
A while ago I wrote a blog post on setting up continuous integration for Laravel with Jenkins. That was for Laravel 4, and many things have happened since. In this post I widen the scope and aim for continuous integration (CI) for PHP applications in general. Applications are looking more and more similar to one another in terms of structure and tooling, which allows for a more general approach to them. Jenkins & PHP work perfectly together and Jenkins is a great tool if you want full control of your CI process since everything is open source and it has a huge and active community.
Pagination is something most web developers deal with from time and time. You can create a simple pagination in PHP in many ways. There are a few things to keep track of when creating a pagination though. Fetching and parsing data, items per page, current page, number of pages, which pages to show and so on. Using a tried and tested package instead of writing your own implementation is often the way to go. Laravel provides the great package
illuminate/pagination for pagination that you can use. This package is not depending on the framework in any way.
With the large number of frameworks that exists today, picking the right one for your next project can feel overwhelming. To make things easier for you when choosing your PHP micro framework, I want to take an in-depth at the available micro frameworks that you can build your next REST API with. I’ll try to make a fair and unbiased review of them based on their pros and cons. I’ll not be discussing on how you should build your API, I leave that to Phil Sturgeon and I can’t recommend his excellent book, Build APIs You Won’t Hate, enough.
Programming is hard work where you solve problems and try to manage complexity. Can you honestly say that you take measures for keeping your mind fresh? Keeping your body active through exercise is a great benefit for your mind, but I would like to talk about an exercise for your mind with benefits for your body also. This is of course not just for developers, but this is a blog aimed at developers. We live in a stressful world where our mind is bombarded with impressions that our mind is usually terrible at dealing with, so we need a tool to help our mind cope with this. The great part is that it will benefit your life in general and not just your work as a developer.
Yet another post on summing up the first year of working remote. But I hope it can inspire someone out there, or give someone some clue to what it’s like and where the great parts are and possible hidden pitfalls. I’m not saying it’s for everyone since I know plenty of people who like the idea of having a clear distinction between work and home. But for me it works and I probably never want to go back.
In most cases your development machine will be local only, sitting behind a NAT or a firewall. So what happens when you need to show your progress externally or on a mobile device, or when you have to test a web hook from an external provider? This is possible, and a very simple task using ngrok. It’s completely open source, created by Alan Shreve (@inconshreveable) and it’s free! Some premium features you have to pay for, but for the most part you can use it in all its glory for no expense. It describes itself as:
Once your application reaches a critical mass of users, you want to be able to deploy without any abruptions in the service. Users could be really frustrated if they work on something and suddenly when they try to save they get a message saying the service is currently unavailable and their work is nowhere to be found. It’s a horrendous user experience. Striving for your deployment to be as fast and responsive as possible just won’t cut it. We need to make them atomic.
A while back I saw the announcement of a PHP conference that would take place here in Stockholm where I live. I was very excited since it’s the only conference I’ve heard of focused only on PHP here in Sweden. Actually it’s focused on Symfony, but the components are such a major part of PHP nowadays. And then I came around thinking that perhaps I could contribute something to this conference. I had previously only given presentations at meetups and really enjoyed doing that. And since I’m writing a book on deploying PHP applications, I thought it would be great to at least try to get a talk accepted for that topic. So I submitted my talk proposal with the title “Deploying PHP applications” to Symfony November Camp, and waited.
Using Git hooks to deploy your application is simple, this is a “git push to deploy” tutorial. Of course you need to use Git as your version control system, but hopefully you are already using it. You can achieve pretty much anything with your deploys with a simple setup. If you want to deploy your application with a simple
git push to your production server and automate all the necessary steps.