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.
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.
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.
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:
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.
Finally 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.
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.