Claiming that sounds pretty snobbish right? I realise that this might come off as something out of a trashy magazine, but I genuinely believe this. So let me tell you what this is about;

So let's start with the vital question; why are admin panels a thing? Well, most products have them so non-technical people can quickly add data in the database and/or easily run tasks — the things developers would typically use console commands for.

These panels are often an afterthought, as a customer won't able to access these. Being an afterthought, this often results in the worst UX possible, enormous navigation trees, and a lack of decent CSS (I've even seen products with admin panels that have no CSS at all.)

Well, to me it's a bit strange. You build an entire portal to your database, the most vital part of your product, that is often used by non-technical people and put close to no thought into it?

Even if only people use it that is fully aware of the data model and structure of your application, this still sounds extremely risky. I would even argue that if your admin panel doesn't support validation on your input, you would be better off with just half a day of SQL training for the people that would use the panel (with protective rules on the accounts). That way, you have a security vector less and don't have to maintain the panel at all.

But it goes further than that. There is this movement in developer land that talks about DX. DX is developer experience and revolves around creating an environment that a developer likes to work in. I'm not talking about ping-pong tables or free sodas. I'm talking about the nitty-gritty itself. Working with a nice API or changing the font of your code editor (IBM Plex Mono <3).

If your entire day is based around working with a webpage, with scarcely any CSS, and upon submitting your form, you see a 500 Error because you made a small typo: that's pretty frustrating. Even if you only have to do a small change every x days, it's still not going to be pleasant.

There is also the point of the broken windows theory. I've written an article about this in the past, but I quickly want to touch upon it here as well. Once you create a part of your application that you don't care about, that's when the entire application starts to slip. These small blemishes never seem to be contained to their "admin panel sandbox."

Things Laravel Made Me Believe - Jeffrey Way - Laracon EU 2015

There is this excellent talk from Jeffrey Way that talks about this concept more deeply. (Now whatever you think about Jeffrey, Laravel or even PHP. I do believe that all of these transients beyond that)

Wasn't your previous post about the ROI of code? 

Yes. In that post, I talked about: time to market, ROI of clean code and how you, as a startup, have to do things quick and dirty to get the ball rolling. Your first instinct might be to see this as a total contradiction to that (so was mine, that's why I wrote this part).

But there are some differences here. When I talk about a quick and dirty hack to meet a deadline, I don't talk about laziness. This point is crucial to me. If you can't figure out how to do something "cleanly" and resort to writing it in the ugly way to reach the deadline, those things are excusable. If you make a form in an admin panel and can't be bothered to add validation to that form, that is laziness. The laziness can poison your database with corrupt data and could have been avoided by putting in 5 minutes of work.

What is the least amount of effort I can do? 

Just use something off the shelf. Open source or not doesn't matter. If you have to validate a credit card number, and your framework doesn't have a built-in validation for that, your first reaction is probably checking Github. So why not for admin panels? They mostly already come with a theme, so you don't have to bother with that. Validation often comes out of the box and as a bonus: it probably also has a ton of extra feature that you might not have thought about. I'm thinking about graphs and user management.

I assume your application already has a way to display tables and forms (or it's going to have it at one point) if that's the case, then you have all the tools already available to display and handle data. Now apply the same care you put into the client-facing part to the admin part.

Regarding the navigation; you can apply the same domain borders to the navigation. Takes a bit more thought, but it's also not going to make you embarrassed at the next standup.

I understand that all of this doesn't sound very critical to the operations of your product. But I do believe that this is all about mindset. A mindset that directly relates to the rest of the application. So next time you have to add a small form to a neglected admin panel, please take the extra 5 minutes and add at least form validation, or maybe even a lick of CSS.

One of the first things I do when I join a new project is checking out the admin panel, that's even before I see a single line of code. Why? It tells us so much about the company and the mindset of the project.

What your admin panel tells us about your company

So everyone is talking about this hip “new” kid on the block for PHP: Generics. The RFC is on the table and a lot of people are getting all excited about it, but you don’t fully see the excitement? Let’s explore what it’s all about!

Generics is not something new. Statically typed languages like Java and C# have had them for ages. There are even some dynamically typed languages like Dart that implement them in their core. And even languages that don’t support Generics for example Javascript can still support them with a 3rd party implementation, in the case of Javascript, this would be Typescript.

The basic idea is that you can reuse a class that is statically typed with different type parameters. OK, I understand that this might sound very confusing. So let's check out an example:

genericsPhpBefore.php

Yes I know, I’m explaining OO stuff with a car class. I know it’s super cliche, and I’m normally not a fan of getters, but just roll with it.

As you can see, we are creating a Car object with 2 parameters. The wheels and the engine. Now, this is all fine and dandy, but what do $wheels and $engine parameters represent? In this case, it’s the number of wheels and what engine it sports one would assume, as we send an integer and a string along.

But $car = new Car(‘pirelli’, true); would be just as valid.

This is of course one of the typical things of a dynamically typed language. But if we want to add some more uniformity in our class we could, thanks to PHP 7 and types:

genericsPHP7Before.php

Now it’s impossible to create an invalid object thanks to the strict types. OK cool, let’s make everything strictly typed then!

But what if we want to create an object that’s both statically and dynamically typed? This sounds absurd but let me give you a use case. You want an object that accepts a parameter on creation but it needs to always return that same type of parameter on its return.

So for example when I do $myCar = new Car('honda'); and later $myCar->getEngine(); I want to be sure that what I get back from getEngine is the same type as what I’ve put into the constructor (in this case a string).

Well… the thing is… at the time of writing, generics don’t yet exist in PHP yet. I know… what a tease. But luckily for us there is an RFC! So people are still loudly arguing whether or not they want to include generics into PHP and how it should look. But let us take a look at what the current proposed way of doing it is.

The use case described above could look like this:

genericsPHPAfter.php

As you can see, we now have brackets! So first up is this:

Here we say, we are going to create a new Car, with 2 parameters; an integer and a string. You could according to the currently proposed RFC just send:

but I like the explicit version better for explanation sake. Next up is:

This tells the class about what variable types it supports. And then we can use these virtual types just like normal types in the class. So in this case the WheelType will be an integer and the EngineType a string.

That’s a use case that will never happen! 

It is indeed a niche use case, but as PHP grows towards a hybrid of a dynamically typed and strictly typed language it does make sense to include some more features of strictly typed languages. While true, you will not use this every day, there is no harm in having it in the language. It would however be handy for people that write logging or collection packages. Take this piece of code for example:

GenericsPHPAfterEdge.php

You can now reuse this collection for whatever you want, but you will always be sure getValues() will return a collection of items that have the same type.

Even more fun is that you can instantiate a Collection like this: $collection = new Collection<Runnable >(); where Runnable is an interface. This way you could have, for example, a collection that you are sure of only has items with values objects in them that conform to the interface. For example:

GenericsPHPExample.php

The <T is Runnable> in this context would stand for: "you can enter whatever type you want here, but it has to adhere to the Runnable interface."

So what’s next? As I said before, the proposal is currently in draft. Once the proposal is finished it will go into a voting round and if there is a consensus about implementing it, it will be added, otherwise it’s back to the drawing board for Generics in PHP.

p.s. you can follow along with how the RFC is going here

What the hell are generics and would I want them in php?

Frederick Vanbrabant's

delirious rantings

What your admin panel tells us about your company

What the hell are generics and would I want them in php?