I know that’s a mouthful of a title but it has just taken me forever to find out how to do this and hopefully this title will help some people to not run down the same rabbit holes.

By default the Symfony Serializer Component uses the built in DateTimeNormalizer. That will take a DateTime object (or anything that implements the interface, such as datetimeimmutable) and normalize it into a string. The default is given as DateTimeInterface::RFC3339 which produces output like 2005-08-15T15:52:01+00:00 for the normalized value. That is fine for most people but I needed a bit extra. Although the official RFC3339 supports milliseconds at least, in PHP it’s hidden behind the DateTimeInterface::RFC3339_EXTENDED constant, which then produces 2005-08-15T15:52:01.000+00:00 as an output. What if you want that or even go down to microseconds (6 decimals)? A lot of nothing is to be found everywhere on that topic. So I came up with my own.

Simply put, you just overwrite the default normalizers service definition with your own. This is from a Symfony 5.0.1 application and it’s in the root directory services.yaml file on the config folder. Order of loading things matters, so if it doesn’t work for you, you might need to check when it’s getting loaded.

services:
   serializer.normalizer.datetime:
       class: ‘Symfony\Component\Serializer\Normalizer\DateTimeNormalizer
       arguments
           -
               !php/const Symfony\Component\Serializer\Normalizer\DateTimeNormalizer::FORMAT_KEY: 'Y-m-d\TH:i:s.uP’
       tags:
           - { name: serializer.normalizer, priority: -910 }

And that’s it. The ‘Y-m-d\TH:i:s.uP’ part is what you need to replace with your own pattern to have what you need. This will operate on every single date time though now, so if you need a more finegrained control on a per property basis, this will probably not be for you.

If neither LUKS nor LVM says anything to you, I have no idea what you are reading this for. If they do, here is my very short way to make use of extra disk space.

Doing 4K video is space hungry. Thanks to a recent sale, I got some pretty good disks. So just adding them to the existing ones sounded like the way to go, but it took a bit trial and error to get there. I didn’t want more partitions, but extend my big data partition instead.

Always backup your data first! Don’t come crying to me if you didn’t!

Now for me, this worked like a charm and I didn’t loose any data, so it should work without data loss. But again, don’t just walk blind into this, make backups first.

To keep things straight, sde and sdf are the new physical disks, vg-01 is the volume group, lvdata is the logical volume inside vg-01 and luksdata is the name under which I’m mounting the luks container.

# Create physical volumes
pvcreate /dev/sde /dev/sdf

# Extend volume group to include new disks
vgextend vg-01 /dev/sde /dev/sdf

# Extend logical volume to get all the space
lvresize -l +100%FREE /dev/vg-01/lvdata

# Open luks container
cryptsetup luksOpen /dev/vg-01/lvdata luksdata

# Extend the luks container to use all the space available
cryptsetup resize luksdata

# Remount folder (so the system knows what file system this actually is)
mount -t xfs /dev/mapper/luksdata /mnt/data

# Grow filesystem
xfs_growfs /dev/mapper/luksdata

I’m using XFS here, but you could use other file systems. The mount command will be different of course as will the grow command. For ext based systems it’s resize2fs for example.

Now hopefully I don’t have to search all over the place again to find this in the future when I will add more space to my server.

I very much like the Sculpin project. It builds on solid components like Composer and Symfony. Thus being PHP, which is my language of choice, it makes it easy for me to configure and extend where needed. I can read up and comprehend every bit that happens inside it and that is very helpful.

Having used Sculpin now for the rokka.io website, I was eager to make it more comfortable, as in having it auto deploy. The requirements were simple. Have the code live public in Github, then auto deploy on merges to the master branch, while not needing any more tools or servers that would cost me something extra. The same requirement I have for other projects, so this will benefit those as well.

I’m deploying to an S3 bucket from which I serve the pages, but you can also do it with pretty much anything else. S3 has the advantage that it’s simple and relative cheap for small and medium static sites, often times not even cracking the free tier you get as a customer of AWS. Also zero system administration for you to do, it just runs.

Now what I’m using here is the documented features of Travis CI. It’s free and works amazingly well for this purpose.

Make a file called “.travis.yml” in the main directory. Here is mine from rokka:

language: php

php:
  - '7.0'

install:
  - composer install

script: vendor/sculpin/sculpin/bin/sculpin --env=prod generate

deploy:
  # How to deploy to S3: https://docs.travis-ci.com/user/deployment/s3/
  provider: s3
  # To store these securely, here is how to encrypt: https://docs.travis-ci.com/user/encryption-keys/
  access_key_id:
    secure: "FnJ--snip"
  secret_access_key:
    secure: "Bw4--snip"
  bucket: "rokka-io-site"
  region: "eu-central-1"
  skip_cleanup: true
  local_dir: output_prod
  on:
    branch: master

Now the first blocks tell travis to use PHP, that you want to run this under PHP 7, then run a composer install (so you have all components to build) and the script line does the actual generation of the site.

So far so good but now your files are on the VM of travis and you want them to go somewhere else. Travis CI supports already a lot of deployment ways. And if your way isn’t there, you can just supply your custom script.

The provider line tells Travis what I want to use, in this case, S3. Access key and secret are a bit weird. Why would you want yours to be public? Well turns out you can encrypt them, store them in a public file, and only Travis will be able to decrypt them again. Bucket is your S3 bucket (duh) and the region is of course the region you want to store it. Mine here is eu-central-1, you might want to choose another or just not specify it for a good default.

The next three lines are more interesting. The skip cleanup means that Travis will not try to wipe the directory clean again (and thus destroying the built site) for the deploy. The local dir is what Travis will deploy, here the built site. With the on clause you tell Travis when to do the deploy, here it says only on the master branch.

So instead of running tests, this runs the build of the site. This has the added side effect that if building the site fails, Travis will inform you and it will not overwrite your current page.

With this setup deploys are as easy as merge to master branch now. And you can spend more time working on your page and less on everything around it.

When it comes to the National Novel Writing Month, I find that I keep repeating the same things over and over, so instead of doing that and always forgetting half the things I want to say, here is a post about it. I might edit and update this along the way. Also this is not THE one and only guide, it’s what works for me very very well, and maybe it has something (or all of it) that you might find helpful.

Step 1: Start writing.
Step 2: Don’t stop.

Ok, ok, it’s a bit more than that. While I can’t tell you what to write or how exactly to write your story, I can give you some tips on the technique on how to achieve the 50′000 words for NaNoWriMo without falling into common pitfalls.

Keep reading

The symfony 2 framework has been a constant companion for a while now in my work place. I enjoy working with it. Recently a new version came out and I take these moments to look into it what changed between this and the previous one.

In 2.5, when you create the project using composer, it asks you if you want to use the 3.0 structure. I said yes and here are the major changes.

cache and logs are now in the new var folder, together with the bootstrap.php.cache file. That way your configuration just got easier. All you have to ensure is write access to the var folder, nothing else. If you intend to write files locally, the var folder also would now be your choice place to put them.

The console is now in the bin folder. This bin folder has been used by various libraries, for example phpunit if you pull it with composer. Now the console lives in there as well. No more messing up the app/con and then tab hit to be given config instead of console. If you have tools that look for it in app though, they will fail.

I like this new structure and it looks good so far. Will be interesting to see how it proves in daily use.