Month: December 2016

Posted on

Bukchon Village and my camera

​I’m thinking to change my phone, get a higher end device with better camera and eventually give up on my DSLR camera and switch to using phone camera only. It is a big decision for me because I really like to shoot photos, stay at the same spot for long time to get all settings right. And sometimes stay in front of my computer to fine tune colours and maybe combine photos to make HDR images. It is really fun, but time consuming hobby.

Pros of DSLR way:

  • Satisfaction when I finish editing and have a great looking photo in front of me.
  • Process of taking the photos is like meditation. Helping to clear my mind, not to think daily problems for a while.

Cons:

  • Takes a lot of time to take photos.
  • Camera is heavy
  • Requires additional equipment (lenses, cleaning stuff, tripod…), which is also heavy.
  • Can’t carry everything everywhere all the time.
  • Takes time to process raw images.

Mobile phone camera:

  • Point and shoot
  • High quality photos with little effort
  • With me all the time and ready to shoot immediately
  • Doesn’t need additional equipment
  • Powerful post processing with apps
  • No extra time required to process and organise photos.

Mobile camera cons:

  • Lower quality images in low light conditions and in general compared to DSLR

We visited Bukchon Village today. Took some photos to test my camera again. Before I decide to sell it or not.

 

When I copied photos to my laptop from SD card, I found that they don’t look good at all. Like none of them. I thought that there must be something about screen colour settings. Uploaded all images to Google Photos and applied auto fix to all of them one by one. Google Photos doesn’t allow batch effect processing yet. And they still far from what I expected. I was quite disappointed until I saw the photos on my phone. On the phone screen (Galaxy S5) they look much better. It must be the screen..

I am going to post some more photos to compare after I got my new phone.

Posted on

Slim Framework with Docker

Warning: This article is quite old now and some of the docker images and links might not work.

Slim Framework is a micro framework which provides minimal tools to build simple and fast APIs and websites.

We are using Slim to build many of our APIs, combined with Docker. We usually add a docker-compose file and use one of docker images we have. See previous post about building automated docker images.

First, we need composer. It is best to follow the install instructions on their website. Since it is changing from time to time. I usually move composer file into bin directory so that I can access it from anywhere.

sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

Then we can go ahead and install Slim Framework.

composer create-project slim/slim-skeleton slim-example

Now we have slim framework code installed. But we don’t want to install all PHP extensions, database, Redis, and other application requirements to our local machine. Instead, we want to share exact same development environment with other developers. For this purpose, we are using docker-compose to define our application and other linked apps and services. Our simplest docker-compose.yml looks like this:

version: '2'
services:

  slim-example:
    image: comicrelief/php7-slim:latest
    volumes:
      - ~/Examples/slim-example:/var/www/html
    ports:
      - "9001:80"
    depends_on:
      - slim-example-mysql
    environment:
      APPLICATION_ENV: local

  slim-example-mysql:
    image: mysql:5
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: mypassword
      MYSQL_DATABASE: slim-example

Then run:

docker-compose up -d

Containers are downloaded and started. Visit https://localhost:9001/ . See that default Slim example route and page is loaded.

For this example I used comicrelief/php7-slim image, which extends comicrelief/php7-base image and has some default php-extensions loaded. You can find more information about these images in their readme files and in my other post.

Time to start coding..

Posted on

Docker: Create Automated PHP Images

Docker is the buzzword for a while now. At work, we are using Docker for our website development and on continuous integration tools. It provides us an easy and fast way to get new developers local development environment up and ready.

Our team is using php7 and Slim Framework to develop PHP apps. To make the experience even better we built a docker image hierarchy which we extended from official base php7 image, and created our own “base” image.

Our docker php7 base repository has some PHP extensions, composer, some vhost files, some basic php.ini configuration, mysql extension and XDebug installed. This is pretty much the things we always need when developing any application.

image showing menu link to create automated build on docker hubFinally we set up an automated build on docker hub to have it built for us whenever we push to master branch. Here you have to authorise docker hub to access the GitHub repositories. Then pick the repository you have the Dockerfile committed. Another configuration we have here is to get another automated build triggered whenever official php image has a new release as well.  This enables us to get latest 7.0.* versions automatically upgraded in the image we are using.

image showing the config page for repository links on docker hub

For more information about docker hub automated builds, you can also check out their official documentation.

Now the fun part. The idea with this base image was, to have it ready to be extended for more specific use. For example we have php7-slim repository, which is extending base php7 image and enabling slim vhost configuration and adding slim framework requirements, and has its own automated build. Has the same link as above, but this time to php7-base image itself. Similarly, php7-drupal extends php7-base image with Drupal requirements and has its own automated build. And then another project can join and extend it once more.

The resulted docker image hierarchy is working well, and we are getting minor php upgraded to our development environment automatically, because a change in base image causes chain triggers to rebuild parent images. We can also use this to add more php extensions to all Slim Framework projects for example, or optimise composer, or update php.ini config for all docker images we use in all teams in a central location…

We are then using final images in docker-compose configuration yaml files.

Simple, and fun.