Together with our clients, we want to maximise our impact on sustainable development. We distinguish between the impact on people and the environment resulting from within Liip, and from the projects that we implement. So the HOW and the WHAT. We wrote extensively about the HOW last year.

What are Sustainable Development Goals?

In 2015, the UN adopted the Sustainable Development Goals. The 17 goals set out the key areas of the social, environmental and economic sustainable development that the global community seeks to achieve. Examples include measures on climate action (13) or protecting life below water (14) and on land (15).

We opted for the internationally broadly supported SDGs,because the current proliferation of tools and labels are obstacles more than help. There is currently no single standard, as has been in place for decades for financial accounting, for example.

So that we do not lose an opportunity, we are using the SDGs to collect impact data at a very high level of granularity across all aspects of sustainability.

What exactly are we measuring?

How does the project affect the SDGs? Which SDGs more than others? And what about the company behind it: is there a clear, mandatory message regarding its impact on humans and the environment? We have assigned a percentage weighting to the individual goals. For example, topics such as species protection (14/15) or climate action (13) are weighted much more heavily for a food producer than they would be for a training company.

We then take a look at how strongly connected the project is with the company’s activities. Does the project represent the client’s main area of activity, or is it far removed from its core business? The project’s classification may be congruent with the company, may be separate, or may be a mixture of both.

For each individual aspect, we rate the contribution to a specific sustainability goal on a scale of -2 to +2. We use objective, measurable criteria wherever possible. For example, has a company made a clear and verifiable statement using recognised methods regarding if and how it expects to achieve the climate targets from the Paris Agreement?

Figure 1: Relevance and impact assessment of the individual UN goals of the client project

Of course, there are also assessments for which we lack the data basis. This is a weak point, and we will try to cross-check with recognised agencies wherever possible, especially for large-scale projects.

Figure 2: Sustainability impact of a customer product, composed of company impact (here 80%) and project impact (here 20%)

And how well are we performing?

Our first ‘inventory’ offered a fundamentally good result. Most projects are positively contributing to the SDGs, respectively do not produce any demonstrable damage. This is also thanks to the fact that we have consistently rejected critical projects ever since the company was founded – for example, any projects related to oil production or conflict materials. We are therefore beginning the measurement with a ‘beneficial’ portfolio. Due to the fact that the topic of biodiversity as a whole still receives far too little attention in the economy. This also influences our portfolio. We will pay special attention to this goal.

We now have an overall picture of our activities. This enables us to prioritise specific goals that are not doing so well more strategically.To keep it simple, we multiply the hours worked on a project by the impact on a goal. Admittedly, this is rather imprecise, but it is still meaningful for us because it gives us an indicator of what we are spending our time on in the first place.

Figure 3: Effect of hours worked for clients per SDG

Is this just greenwashing?

There are currently huge amounts of activity relating to impact measurement. And much of this is marginal. Sustainability is currently in fashion, and often things that are brown and unfair are painted green and put in a social light. Because we are aware of this, we are operating as cautiously as possible by setting broad system limits, and by drawing on a holistic metric with the SDGs. And, in the event of doubt, we make a more conservative assessment to avoid a false sense of security. As a point of principle, we obtain publicly available evidence and statements from companies wherever these are available.

What is the next step?

We plan to take this chosen approach

Truncated by Planet PHP, read more at the original (another 517 bytes)

We do constantly update and improve our image delivery and storage service rokka.io and we’d like to talk about some new feature since the last update here. You can always check the changelog for public additions or follow us on Twitter for the latest and greatest on time updates.

Option for JWT based API Tokens for authentication instead of API Keys

To access the rokka API until now, you needed the API Key which you get on sign up and of which you can create new ones in the Dashboard or via the API. This is fine for most of its use cases, like storing it somewhere on the server side. But maybe not so much when many people, you may not even know, need and have access to such a key. Be it even only with limited rights like for uploading some images or read only access. The problem with rokka’s API keys is that they are valid forever (until you revoke them) and can be used from everywhere.

We could have added time-limitable API Keys, but we chose another path: JWT tokens, which you can get via the API (and an API Key…). They do need an expiry date and can also be IP limited. You can also make them renewable or disallow that. And more limitations could be added in the future.

You most certainly don’t need such tokens, if your code runs on the server side anyway and you don’t need to give out that key to many people or store it somewhere not trustworthy.

But for browser based access to the rokka API directly, there are at least three good use cases for such tokens.

Of course you could run all your communication needed with the rokka API through your backend and wouldn’t need to give out any credentials. But either you do not even have a backend (the rokka Dashboard and the rokka Gallery are just static sites in the end) or you want to avoid unneeded latency and stressed resources on your backend and directly talk to the rokka API from the browser. For example for uploading large images and videos.

The technical details of all this are documented in the authentication chapter of the rokka documentation and our PHP library (in 1.17.0) and the JavaScript library (only in 3.7.0-rc.1 yet, stable release will follow soon) do have already support for all this. And the Dashboard and the Gallery do use these new API tokens already.

But now to three possible use cases:

1. No need to store the API key in the browser, just the limited token

This is what we do in the mentioned dashboard and gallery. People login with their organisation and an API Key, we then fetch an API Token directly from the rokka API and just store that in localStorage, but not the API Key. The token time limited to 3 days, we restrict it by IP (but do remember the last few used ones, so you don’t have to login all the time when switching IPs) and try to renew it after a day. The rokka.js library takes care of most of that, except the multiple IP limiting. The rokka.js file in the dashboard is an example of how to do all that.

Even though the end user still needs to know a valid API Key, at least we don’t store it in the browser permanently. So that if someone could steal the credentials somehow, it will only be valid for 3 days (but can be renewed within those 3 days in the above setup) and more importantly only from the IPs the user itself logged in. We add some additional layers of security this way.

2. Have more control over who has access to it

This is more or less an extension of the above. Let’s say you want to give more granular control to such a site, but not wanting to have to create an API Key for each new user (you could revoke, when the access of a user should be revoked, but that gets cumbersome). You also would lose control of what the users do with such an API Key, like reusing it somewhere else. But you maybe do have a backend already with some single sign on solution and user based access control.

In this scenario, your rokka.js based frontend would then ask your backend for an API token, log in people if they’re not already, the backend generates that token through the rokka API and the (only stored in the backend) API Key, makes it time limited for like a day and marks it as non-renewable. And even can make it IP protected, if that’s what you want.

Truncated by Planet PHP, read more at the original (another 5391 bytes)

Cal Evans hosts his friend Matthias Noback as they talk about Domain Driven Design and Matthias’ new book “Recipes for Decoupling.

@matthiasnoback

Show Notes

• Recipes for Decoupling
• Matthias Noback's blog
• Object Design Style Guide

This episode is sponsored by
RingCentral Developers

The post Interview with Matthias Noback appeared first on Voices of the ElePHPant.

Truncated by Planet PHP, read more at the original (another 21583 bytes)

TODO

• split article in GCP only and production only

• add info, that each user via IAP has sudo access by default

  • find docu reference
  • double check the tutorial where a user is used

• update php-base Dockerfile

  • fix for the git issue ==> add to the git secret tutorial

• backport the git fix to part 6 and 7

TODO globally replace all IP addresses of the VM. Canonical one is 35.192.212.130
Others: 35.239.69.58, 34.136.107.232

In the eighth part of this tutorial series on developing PHP on Docker we will manually create
a VM on GCP (Google Cloud Platform) as a “production” environment to deploy our dockerized PHP
application there and run it via docker compose as a proof of concept.

TODO: Add intro video

Add sectino on “why only a POC”

• docker compose shold not be used in production, especially true for data stores like mysql and
  redis
• permissions are far too wide
• using a Debian base image instead of a COS image

All code samples are publicly available in my
Docker PHP Tutorial repository on github.
You find the branch for this tutorial at
part-8-deploy-docker-compose-php-gcp-poc.

Published parts of the Docker PHP Tutorial

• Setting up PHP, PHP-FPM and NGINX for local development on Docker
  (2018-07-08)
• Setting up PhpStorm with Xdebug for local development on Docker
  (2018-08-06)
• Structuring the Docker setup for PHP Projects
  (2019-05-20)
• Docker from scratch for PHP 8.1 Applications in 2022
  (2022-03-21)
• PhpStorm, Docker and Xdebug 3 on PHP 8.1 in 2022
  (2022-03-22)
• Run Laravel 9 on Docker in 2022
  (2022-03-23)
• Set up PHP QA tools and control them via make
  (2022-04-25)
• Use git-secret to encrypt secrets in the repository
  (2022-04-25)
• Create a CI pipeline for dockerized PHP Apps
  (2022-04-25)
• Deploy dockerized PHP Apps on a GCP VM
  (2022-04-25)

If you want to follow along, please subscribe to the RSS feed
or via email
to get automatic notifications when the next part comes out 🙂

Table of contents

• Introduction
• GCP
  • Setup a GCP project
  • Create a service account
    • Create service account key file
    • Configure IAM permissions
  • Setup the gcloud CLI tool
  • Setup the Container Registry
    • Authenticate docker
    • Pushing images to the registry
    • Images are stored in Google Cloud Storage buckets
    • Pulling images from the registry
  • Setup the Secret Manager
    • Create a secret via the UI
    • View a secret via the UI
    • Retrieve a secret via the gcloud cli
    • Add the secret gpg key and password
  • GCP VMs: Compute Instances
    • Create a VM
      • General VM settings

Truncated by Planet PHP, read more at the original (another 162008 bytes)

Zend Server updates for IBM i are now available – and strongly recommended. In this blog, learn how to install Zend Server on IBM i to build the latest and greatest PHP stack.

I’ve been dabbling in CSS my entire career.
In the early days, it was relatively simple, as our browsers were fairly limited.
But over the years, CSS has become more and more capable, allowing styles to target only tags with specific tag attributes, only apply at specific screen sizes, and even perform complex layouts using things like flexbox and grid.
I take a bit of time every now and then to understand these things… but since I don’t use CSS a ton, it’s hard to keep up.

As such, over the past decade, I’ve tended to use CSS frameworks, and generally Bootstrap.
Every couple years, a new major version is dropped, and I have to learn new structures and components, and struggle to get things to look the way I want.
Worse, when I use these frameworks, injecting custom CSS often means understanding how the framework is already styling components so I can ensure things don’t conflict.

The last couple years, I’ve been keeping an eye on TailwindCSS.
I’ve been a bit skeptical, as its declarative, utility-first approach looks a lot like doing CSS inside your html, which, honestly, feels off.
I’ve typically subscribed to the idea of semantic html, which advocates separating style from markup.
Having styles directly that mimic CSS directives associated with every tag feels like an unholy mix, and a far cry from semantic html.

And then there’s the hype.
The original author and project lead of Tailwind is a huge hype man, and hype tends to turn me off.
That’s on me, not them, but having been in the business for over two decades, I’m finding I’m more and more likely to discount hyped products and projects, because I’ve seen them come and go so frequently; there’s often an indirect relationship between the amount of hype and the long-term viability of a project.
I’ve also often observed that hype serves as a way for users to deflect reasonable critique, and the more vehement the user base, the less interested I am in engaging with them because of this.
Clearly, YMMV, but it was definitely something keeping me from really investigating Tailwind.

However, recently, in helping out the PHP Foundation, I volunteered to setup their static website, and the team requested using TailwindCSS, so I dove in.

And I discovered… I kind of love it.

This is one of those “I’ll be googling this in the future” posts.

How it works

I won’t go into how to get started with Tailwind; their docs do a great job of doing that for you.
However, I will give a quick overview of how things work, so you can see (a) where I’m coming from, and (b) what you’ll be doing when you start with Tailwind.

The way I’ve always learned to do CSS is to first write html, and then write CSS to style that html the way you want it to appear.

<div class="box"> <h2>Title</h2> <p>Some content</p>
</div> <style>
.box { margin: 0.5rem; background-color: #333333; border: #000000 padding: 0.5rem;
} .box h2 { background-color: #dedede; padding: 0.5rem; color: #111111; font-size: 2rem; min-width: max-content;
} .box p { padding: 0.5rem; font-size: 1.2rem; min-width: max-content;
}
</style>

Tailwind instead provides a ton of “utility” classes, targetting just about every CSS directive.
You then add these html classes to elements to style them:

<div class="m-2 p-2 bg-neutral-600 border-black"> <h2 class="min-w-full p-2 bg-neutral-300 text-4xl text-neutral-800">Title</h2> <p class="min-w-full p-2 text-xl">Some content</p>
</div>

Behind the scenes, you run the Tailwind CLI tool, and it analyzes your html to generate CSS for you.
You can even have it watching for filesystem changes to files you’re interested in (templates, JS scripts, etc.), and it will regenerate the CSS automatically.

Tip 1: Layers

Out of the box, Tailwind does a CSS reset that removes all styles.
This is great, because it means that any changes you make, you can anticipate exactly what will hapen.
It’s also a pain in the ass, because everything is unstyled: your headings look just like your paragraphs, your lists look just like your paragraphs, and there’s no way to tell where one paragraph ends and another begins.

So, the first thing you’ll want to do is define your base styles.
Tailwind has a very specific suggestion for where and how to do this: in the “base” layer.

Opening your site CSS file, you’ll see these directives when you begin:

@tailwind base;
@tailwind component

Truncated by Planet PHP, read more at the original (another 14308 bytes)

In this blog, we take a look at how cloud images with ZendPHP make deployment of your PHP applications simple and consistent.