My PHP Development Setup
johnmackenzie.co.uk
johnmackenzie.co.uk
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
If I need to build an API, or want an app with backend/frontend separation, it is my go to.
I started the project twice in both frameworks.
And while Laravel might be the most popular one I would say you should go with Symfony 4.
Laravel just has too much magic. When your IDE doesn't know what is going on, how will you?
But whatever the choice, skip 'annotations'! It's a bad trick that will mess up your project at one point (for example if your IDE cleans up unused usages).
Framework continues to evolve, for the better of course. With the introduction of PHP 7, I believe Laravel will get rid of magic eventually. Meanwhile, we've got tools to help ourselves.
In certain use cases, it literally annihilates Golang for example and leaves node.js way, way, way behind.
Now, ignoring the numbers, there are many things you can do using PHP:
- web applications
- background services
- queue systems
Imagination is the limit (but that applies to any language these days)
There's plenty options to choose from, from web-related frameworks to community provided libraries, even the command line interface received a ton of cool libraries to play with. I can't state that you can do X in PHP but can't do the same in Y, Y being another language. However, frameworks such as Laravel make it trivial to bootstrap a project, create an API, create a nice UI using Vue (Laravel comes with excellent Vue tooling) and deploy the whole thing in a few easy steps to popular hosting providers.
Granted, it's not language specific, there was a huge community effort behind everything PHP related: from standards, to package manager, to tooling, utilities and so on so the ecosystem is quite healthy and progressing.
The nice thing about it, ultimately, is that it's really fast enough and keeps getting faster, with new (useful) language features.
If you're after a tldr version and don't care about the wall of text above:
Strenghts:
- excellent ecosystem http://www.packagist.org, http://www.getcomposer.org
- excellent *nix support, easy installation: https://launchpad.net/~ondrej/+archive/ubuntu/php
- great object oriented model that supports strong typing: http://php.net/oop
- excellent choice of web-app frameworks: https://laravel.com/, https://lumen.laravel.com/, https://symfony.com/
- big choice of extensions that expose additional functionality, such as swoole: https://www.swoole.co.uk/ or zeromq: https://github.com/mkoppanen/php-zmq
- great performance for an interpreted language
- easy scaling due to php-fpm http://php.net/manual/en/install.fpm.php (this has been available for a decade)
That makes node a lot nicer to do async.
I was recently playing with generating v4 UUIDs in Elixir, and it was fun to try writing code that was nominally faster than the most popular UUID library out there. It was also interesting to see how the code gets less maintainable, more repetitive, are harder to read when I started trying to shave nanoseconds off the average run time. It's also fun to start realizing that the program can't get much faster because your approaching the physical limits of the hardware.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But Seriously PHP has come a long way. May be there should be something that compiles to PHP? Coz Php still looks very ugly.
Many complain about PHP is from the past. Still a lot of developers just hacking around but it is not hard to find decent PHP developers anymore.
Additionally, JetBrains has good resources. The PHPStorm IDE is worth your time, as well as the blog PHP Annotated Monthly: https://blog.jetbrains.com/phpstorm/category/php-annotated-m...
phptherightway.com is by far one of the best "one stop shop" for modern php development.
PHP has its origins in scripting rather than what traditional developers might consider a "real" language but as a C# developer, I often turn to PHP for my web "sites" as it is plays much nicer with front-end frameworks and using a framework like Yii2 does most of my heavy lifting.
In Oslo, I found PHP developers hard to come by. Though, I think the situation is better in continental Europe.
I disagree. I'll argue that most of the new crop of developers are self-taught/bootcamp-trained/career-switching and they straight to the web. For RoR, Node.js, Python, Go, etc. it's not a common setup and those are the languages being learned today.
Now if we are talking about the public who has a "I remember when I started with PHP" nostalgic feeling while reading this article I might agree, but that is not "most developers" :)
There's also the niche OS called Windows that is quite popular in some circles and they don't use Makefiles either as rule.
These convenience Makefiles ultimately don't get to the root of the problem of building a dependency graph for your project, and result in much overbuilding. For example, I have a Go backend + Vue/Typescript frontend. "make all" will re-webpack the frontend when you modify the backend because make was not taught the dependency graph. It doesn't understand the dependencies between input and output because it was not told that. Telling it that involves reverse-engineering your language's internal dependency management (go already knows what it has cached, for example), so nobody does it. If you _do_ decide to rewrite your language's dependency management to make make do incremental builds correctly, you will get it wrong and then _underbuild_, which is why "just run make clean!" is such a common remark. To me, underbuilding is worse than overbuilding, but both are bad. If you can't solve that problem (by using something like Bazel), I would not bother with make. (We all dream of the days when .c became .o and your binary was just all the *.o files linked with some libraries. But that is not how newer programming languages work at all.)
For the case where the author is just using docker-compose, I would say... you have two docker-compose files, one for local development, one for production. You build your development docker-compose approximately once, have it running, and tell your web framework thingie to rebuild when the code changes (mounted in the container with a volume). Meanwhile, your CI system builds a container without any of that dynamic recompilation stuff for production. Not great, but not horrible either. You will need some glue to run your unit tests inside the container. Probably a shell script that the Windows users on your team will port to Powershell for their own use. All in all, not ideal, but not super bad either. (I personally think I will move in the direction of ksync/telepresence and minikube, so the shell scripts to do things like run the tests or wipe the database are run inside the dev container, and nobody has to pretend their local machine matters for anything but "minikube start". But it is more work than docker-compose, for sure.)
They make working in the repository as a newcomer abundantly better.
choco install makeThe real intention of a makefile is to specify dependencies, and how to (re)build targets if they are out of date compared to their dependencies. That is traditionally used to build e.g. C or C++ projects, and can indeed quickly become very cumbersome. Almost nobody writes them by hand for larger projects. These days almost everybody uses either some makefile generator or a more modern alternative to make.
Early in my re-entry to web I was using grunt to manage the build processes, but that fell away fast—
I'll either write a Makefile or a shell script to manage those builds and processes now—and I'm far more productive for it. No need for a number of plugins and yet more dependencies to manage.
Though, I have to say I've seen less and less of Grunt and Gulp (etc) in modern JavaScript (especially TypeScript)
What you mention is the main reason for that claim.
The main less I take from this is that a) it still pays to keep it simple and b) as an industry we should continue focusing on reducing maintenance costs as much as we chase after the cool new project of the week.
Also, and this is a really strong point, can manage assets super easily, React and Vue stacks are supported out of the box with laravel-mix.
And if you need something lighter (for building just an API for instance) Lumen is the light version of it.
I have a lot of experience with PHP and Python frameworks, Laravel comes as absolute top for me.
It can be frustrating. When you're on a deadline it can be unnerving and then some.
I finally got into the habit of making sure what I found was current. But that doesn't prevent so much noise in the Laraval + The Google signal.
Also the symfony documentation and particularly the source code is an excellent example of modern high quality PHP.
They make for a good read together.
I worked with PHP in '98 (ported a perl thing into this cool new web language) and then much later in 2014-2017. I found much to complain on the second time :) PHP7 is a good update, nevertheless.
A language is just as much about what features it excludes as to what it includes.
Some other deprecations: http://php.net/manual/en/migration70.incompatible.php
My impression was that PHP post-PHP 4 was basically cloning Java. On top of that, unlike Java, PHP started from the bad base provided by old PHP versions.
If your project is already in PHP or you are super proficient with PHP, ok, but otherwise I would just start directly with Java.
The popularity of Ruby/Rails and to some extent Python and node did a lot to shine a light on the productivity possibilities of embracing the dynamic/scripty side -- at its furthest edge, you can see this in how Java has changed and brought in some of the strengths from the dynamic/scripty world. But also I think it started a good part of the PHP world down the road of thinking about what the actual problems with working in PHP were and working on those.
I'm not going to enumerate PHP's strengths because I'm (a) weary of doing so and (b) have decided for the moment it's possible there's more value in keeping the various possible competitive advantages quiet. But suffice it to say that PHP has always had strengths (along with its real weaknesses) that a lot of the dev world seems astonishingly blind to, so it's a misunderstanding to think of past versions as nothing worth building on. Filing off some of the warts, adding helpful and convenient features, and bringing performance back towards first in class rather than buying into enterprise cargo culting has really given it a boost and even made it more fun.
It's definitely not the right tool for every problem/project, there are still things missing from the language that I sometimes wish I had when using it, but it's great for a certain class of web applications.
There is no such thing as "W3C School".
There is the W3C, which is a standards body that publishes various web technology specifications such as HTML, CSS, and DOM specifications.
Then there is W3 Schools, who are entirely unrelated to the W3C. They publish low quality tutorials and sell worthless certificates. They chose a name which confuses people into thinking that they are somehow "official"; this couldn't be further from the truth.
Laravel seems more popular in the US but it stills uses many Symfony components.
Laravel uses Symfony components but the APIs are a lot more fluent and more natural to use.
It allows you to have package your often used shell commands into one well known (even a 30 year manual will teach you how to read/use a makefile) file.
1. Various IDEs on my Windows machine writing PHP & HTML/CSS.
2. Saving all files over Samba to a Debian Web Server running Apache.
3. Once the code is complete and signed off, it's migrated to a production server.
4. Have a global error hook via 'set_error_handler' in each PHP file that 'echos' out the problem into the Browser. This doesn't help me with syntax errors though.
I'm fairly new to PHP development (Previously .NET dev), so I'm probably doing many things wrong here, and I'm totally open to suggestions, however I DO have to stick with Windows as my dev machine.
1. Use source control. A good idea in general.
2. Have an automated deployment system that does the "saving files over Samba" for you.
3. Use a proper logging system and access the log files to see the errors.
For 2. I don't really agree he should necessarily change that. SAMBA is nice and fast and painless. It really depends on whether that target machine will ever be used by anyone else to write code on.
2. Gitlab has solutions, Atlassian Bamboo, Buddy, FTPloy, Jenkins, etc.
3. Monolog https://github.com/Seldaek/monolog
At the job I had back then, we used to run a virtual machine on your dev computer and the ide we were using (netbeans afaik) could function properly over ftp. Since there was no real network between netbeans and the virtual machine, things were fairly fast.
These days, albeit not doing php, but python, I use a docker image with my software installed and I'm mounting a local directory (where my sources are) to the container. Needs a bit of fine tuning, but works.
#!/bin/sh
set -e
case "$1" in
up)
docker-compose up -d
;;
build)
docker-compose rm -vsf
docker-compose down -v --remove-orphans
docker-compose build
docker-compose up -d
;;
*)
echo "unknown verb: $1"
;;
esac
Even the newest PHP feels somewhat dated, Infix-Functions could reduce a lot of typing by making library and custom wrapper code – which almost always exists – resemble more.
function foo(String $s) {...}
// current function call syntax
foo('hiho');
// just syntactic sugar - below code is the same as above
function String.foo(String $s) {...}
'hiho'->foo();EDIT: I'm dumb. The syntactic sugar is just operator overloading. The better question is why would you ever give that to a PHP developer? I've been digging through some of it, and it's just annoying to untangle some of the code people write, as compared to other languages.
Right now the best is to use something like Laravel's collect, e.g. collect([1, 2, 3])->map(...). Oftentimes all you want is to add one method to an object. Right now you would have to sub-class it or write an ugly wrapper function.
Infix-Functions are one way to "extend" functionality without messing with inheritance – with other words, you can easier express what you mean with less code in an consistent way. In Android dev, Kotlin and Infix-Functions are quite popular. Too often in PHP you have to write some_function($object). The other thing is that PHP has a lot of strange function names and Infix-Functions could help to give the language designers a second chance to come up with better names, even if the Infix-Functions just call the existing code.
[1] https://atom.io
PHPStorm's XDebug integration is second to none, it has full MySQL integration, and it's autocomplete and click-through intelligence is incredibly smart.
I have tried atom, but I miss too many of PHPStorm's features. There is so much it can do, and so much intelligent functionality, but it all stays out of the way until you call upon it.
Without going into what I've tried and yadda yadda yadda, white noise, my credentials and so on - PHPStorm id the IDE. No Atom / VSCode or whatever can't compare. You get ctrl+click go to definition, you get ssh terminal, you get XDebug integration, it plays with Vue/ES6/React, you get MySQL integration, Vagrant integration, extensions to get VIM bindings and so on. Next to proper keyboard, monitor and mouse - buying PHPStorm is hands down one best money spent when it comes to what I work with every day.
I'm NOT saying "you can't get X with Y editor which is free" - sure, I believe you can, but this thing completely satisfies my every requirement and I don't have to spend time looking for integration extension or whatever. It saved me a ton of time so far, it will do so in future - I approve it, however I don't think anyone's editor "sucks and you should go with PHPStorm". Everyone should go for what they think brings them the best experience / value.
I'm not even an IDE -- I'm a strict Vim user, but when I had to work in PHP I found the experience to be very nice. Especially integrating with the debugger.
JetBrains' stuff is top notch and I will buy their IDE for any language I work in, even if I don't use it very often.
I remember that time when I couldn't get it why there isn't built-in terminal in the SublimeText and then I found windows managers like `sway` or `awesome` and I started do not care about it.
> PHPStorm's XDebug integration is second to none, it has full MySQL integration, and it's autocomplete and click-through intelligence is incredibly smart.
Support for XDebug exists in all modern editors - Atom, Sublime, NetBeans, etc. etc. If you "waste" some time on customizing your editor auto-completion feature you might will get a really decent one (in aforementioned editors).
I must say PHPStorm had a superior look-for-file (think: Ctrl+P) feature which really gets annoying in other editors if you get used to it.
About the MySQL integration: I was really positively surprised having it in the IDE but I've stopped using it as soon as my colleague told me about the HeidiSQL [0]. For person who was using SQL Management Studio at university, HeidiSQL offered the same feel - fast, lean and simple to use but also it is free and installation in Linux (wine) or macOS does not take much time. It is probably the best application written in Pascal that I know about.
It does, but PHPStorm's is particularly competent. From rewinding the stack, having an in-context command line prompt to run code in, conditional debug points, current context auto-complete for the command line, it can even read cachegrind outputs. It's the level of competence they implement in all their features that take it from a "text editor preference" to a professional level tool.
> I must say PHPStorm had a superior look-for-file (think: Ctrl+P) feature
You can also "look everywhere" which looks at literally everything from the same text-box, so if I type "show line numbers" it searches through the settings panes and finds the "show line numbers" setting, and because it's a toggle, I can just hit enter on the search result and it toggles the setting. Also class definitions (PHP, Javscript and CSS definitions) are all fuzzy searchable. "SoClNa" will find the SomeClassName definition and also the "Some/Class/Name" folder and so on.
I know I'm gushing about it but I really could talk for ages about all the little things it does.
Except PHPStorm I know many developers who got used to NetBeans IDE.
It won't make you dig around a dozen plugin to make it work in a decent way and even better than atom + plugins and what about $8/month?
What were your issues with them?
There are differences between the languages as such, e.g. PHP has traits, Python has Operator overloading, etc. From a tooling perspective I cannot tell that there is any big differences.
spl_object_hash returns a unique id, rather than a hash. So why the name? Probably because it's formatted as a masked hex value. I had already started writing code to deal with hash collisions when I found out.
The `self` and `static` keywords for accessing the current class do roughly the same thing, except `self` is static and `static` is dynamic. That's not very nice.
You can't define consts on traits. If you google it, you find a reddit thread where multiple people offer creative theories of why consts on traits would violate OOP principles, and a bug report where you find out that it's because the implementation is too naive to deal with collisions.
Sequential and associative arrays are the same data type, even though in practice you always use them either one way or the other. That interacts really badly with JSON (is an empty array supposed to become [] or {}?) and makes code harder to understand.
Anonymous functions are called closures, but they aren't closures, unless you manually declare which variables from the surrounding scope you want to access and that you want the access to be referential.
Weak typing is still around in enough places to make me paranoid. `in_array('3', ['03'])` is true (and `in_array($x, [true, false])` is true for absolutely any $x). You have to pass an extra boolean argument for strict typing, which is not nearly as easy to spot as a == operator.
Relatedly, arrays can only have string or int keys, with mandatory weak typing. A string that's sufficiently int-like is converted automatically. So this code throws a type error when it reaches 3, even though it was a string when it was entered into the array:
<?php
declare(strict_types=1);
function foo(string $s) {
}
$arr = ['x' => 1, ' ' => 2, '3' => 3];
foreach ($arr as $key => $value) {
foo($key);
}
There's a lot more like this. PHP is much better than it used to be, and it's very much possible to write good PHP programs, but I find it painful to use.
They don't prevent me from using PHP, but they make it unpleasant. A lot of mental effort that could be going into making sure my own code makes sense has to go into making sure that PHP's behavior makes sense and matches my mental model, more so than with many other languages. It increases friction.
Craft CMS is fantastic, built atop Yii 2:
For developers on Windows, I think Uniform Server[0] is really good. It's completely portable and gives the full stack as well.
My setup was so customized over years that I ended up just building simple custom stack from scratch (using Composer to manage dependencies) rather than struggle with choosing off-the-shelf replacement and tweaking it.
The command uses run though? Is that a typo? (Really eager to try this setup.)
“Modern x written in y” etcetera. To me this often is a sign to not having to read it. As if you would make or do something new in oldfashioned style without mentioning it. Eg: “what my php setup was on amiga in 1985”.
Just call it “my take on a good php setup in 2019” or something. The setup is retro in januari 2020.
Anyways, I accept the down votes.
To me this is just another setup which slapped together a bunch of fancy pancy tools. Why is docker required? I use docker a lot, but to build containers and deploy apps with it. The way it is intended to be uses. Running (python) web projects works fine without docker for development. Most team mates use macos, which is linuxy/unixy enough until you do something specific.
Make is quite an old useful tool, but certainly not modern. As are linters.
.editorconfig is a thing now.
Modern php in 2019 is php > 7.1 . Modern PHP in 2013 was 5.5
It's not specific, but it's implied you're referencing the most recent versions.
I said, “Walter! What is this? I wanted something new and innovative.”
“Oh. You want postmodern then!”
Contemporary.
I wouldn't use it for solo-development or side projects. Not worth the brain-space.
It is a huge help to get an identical environment to develop on. Especially when you have more complex apps with different services.
Until you stumble on some file permission problems if you use volumes; or some difference if the host is linux or macOS. Pure VM are the best: copy your virtual server, launch it, deploy your code. You can even have multiple containers launched inside your VM like on your production server.
Overall though, it seems me that is an indication that something is very very wrong with PHP if it's easier to just spin up containers. Docker is just the work-around that allows developers to have sane PHP environments.
In contrast with other languages like nodejs, you can almost always just use nvm to switch to the desired node version for the project, do a npm install, and it will just run. For something like that, there's a lot less need of docker for dev.
Modern is used a lot in the js world with little other meaning than that it is not "what you write is what gets sent to the browser".
Somewhere along the way, 'modern' has now come to refer to the current trends.
(SenHeng beat me to it)
Srsly?
It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file.
An anti-pattern because beginners won't understand the commands abstracted over? Come on. When I was a beginner I certainly didn't want to learn all the quirks of DOM manipulation in JavaScript, and jQuery held my attention long enough for me to build a career in this industry.
If it's your job to build a product, there's not much ROI on memorising the docker and docker-compose flags, which often don't match and are chosen quite arbitrarily.
I know what commands I intend to run when I use NixOps, but it doesn't matter. I'll still wrap them in easier-to-remember Make tasks. I'll even use tasks that just delegate to shell scripts. Here's an example from one project I'm working on:
.PHONY: deploy-prod deploy-staging cachix
build:
nix-shell -p nodePackages.npm nodejs --run "npm run build"
touch src/Settings/StaticFiles.hs
nixops modify -d moneygains services.nix aws.nix
deploy-prod: build
nixops deploy -d moneygains --include moneygains
deploy-staging: build
nixops deploy -d moneygains --include staging
cachix:
./cachix.sh
Nobody is forced to use those abstractions…
> Nobody is forced to use those abstractions…
Oh come on. You know that these scripts become canon, and anyone who deviates from them and has an error will just be told to use the build scripts. You're not forced in the same way nobody forced you to use docker, the app just won't work without it.
Good.
It's either:
- Throw all the commands into the README and force people to copy and paste
- Throw all the commands into a bash script and re-implement all the command parsing and prerequisite logic that Makefile syntax provides
- Be docker / docker-compose CLI tech support
- Write a Makefile
ahh, but you force the newbies to learn MakeFile, and that's a net win imho ;)