I've had this blog for more than 12 years.
In 2008, When I was starting this blog, Wordpress was the most popular open source blogging platform.
As time went by, many security flaws were discovered.
The plugins, the main driver for extending the platform and one of the main reasons why the platform was so popular, had many architectural concerns raised.
Today, after all this years, and with all this security and design consideration, Wordpress ended up being, well... probably the most popular PHP platform on the web, with all the legacy code still working with the new versions and many of the plugins from 2008 still going strong.
As time went by and I was writing less and less, it became obvious that I was spending more time keeping Wordpress up to date than actually using it to write.
So today I finally decided to move to Hugo.
Hugo is a static site generator, built in Golang. Everything is static when building with Hugo and, even more curious, there is no database, there are only config and Markdown files. So the end result for me is a lot less work on updating the platform.
With the new platform, a new theme also comes along, which brings the blog to a more modern look and with the very important feature of night mode!
Jekyll is the most popular platform for static site generator, but it is built with Ruby and I like Hugo better because the templates are generated from Go Template files. It is a matter of taste more than anything else.
And with this update, please enjoy my now static blog!
Something interesting happened to me recently: my access to a repository that required authentication was no longer valid. The problem in my case was a failure of the repository, but it could have just as easily been that I’ve lost my credentials or some other similar cause. My access was due to be restored soon. As we all know, soon in IT it can be anything from minutes to the end of life as we know it, and I needed to make a deployment before then.
And another thing, my local install was working.
For a while I wondered why my local was working, but, if you read the title, you already know why, my local cache was still valid.
I searched for a while for a way to get my local packages to the remove that was making the build, and there are ways, but I don’t want to waste days on an issue that may fix itself before I figure it out anyway.
The solution is very simple:
- make a copy of your local cache, if you are using linux it should be in “~/.composer”;
- put the copy on the server of your interest in a preferred location (let’s say /tmp/composer_cache);
- export the COMPOSER_CACHE_DIR variable (“export COMPOSER_CACHE_DIR=/tmp/composer_cache”);
- run composer as usual.
That’s it, you are now using your local cache on a remote server. It’s not the most elegant solution out there, but a quick and dirty hack that gets the job done easily.
Oct 13, 2019
Buy a Xiaomi Air Conditioning Companion without first researching how well it is supported by Home Assistant.
Realize that the Chinese power socket for 16A is different from the 10A one.
Realize that nobody is selling a 16A socket adapter for a 10A China power outlet in Romania.
Order a 16A power socket from China.
Wait 2 months for both the socket and the device to arrive from China.
Realize that there is no adapter for the wall outlet from China also.
Find the only seller that will sell a modular outlet that matches outlet box, probably by mistake
Wait for them to tell you that it will be delivered in a month
If it did not arrive yet, wait for a socket module to be delivered
Install the wall module and power socket
Connect the Xiaomi Air Conditioning Companion and AC for the first time
Realize that the Xiaomi Mi Home App has been updated in the meantime and there is no working tutorial on how to get the password for Home Assistant.
Figure out (after many tries) how to get the gateway password.
Add it to Home Assistant and realize that the gateway is not well supported and that the only things you can do from Home Assistant are sound the alarm and change its volume.
Find the xiaomi_airconditioningcompanion module and realize that you didn’t need the gateway password in the first place.
Downgrade the Xiaomi Mi Home App to get the token as specified in the instructions: https://www.home-assistant.io/integrations/vacuum.xiaomi_miio#retrieving-the-access-token
Realize that you don’t have the right version of Hass.io to use the module.
Move to Hassbian from Hass.io
Finally, install the extension and setup the module.
Now the only thing that remains is to enjoy the comfort of controlling your air conditioning from a few feet away, without ever using the remote!
Nov 29, 2018
Please note that this solution is tailored specifically for my needs and, while your needs may vary, don’t worry, everything is on GitHub, so feel free to take what you need.
I would like to add that this is not a “you’ve been using Docker with Magento2 wrong, this is how it’s done” kind of blog, I just want to share what I’m using and how. It may not be the best fit for you, but maybe you will find something useful.
For almost 2 years I’ve been using Magento2 in Docker containers. I’ve been doing that before, but I must admit that it was because I had to, not because I’ve seen the light, I mean advantages.
As you may know Magento2 is not exactly a small and light app, it’s quite heavy on the resources, especially during development.
Compared to a VM, with Docker you get:
- Speed: I think the speed is one of the biggest advantages, you can stop and start containers very fast, only the first build will take time, after that it will be very fast;
- Light on resources: Compared to a VM, the container does not need to include the entire operating system, so it will not take a lot of space on disk and will not use a lot of processing power, because it’s not an entire OS doing… well… OS stuff, it’s just a server most of the time.
What you don’t get:
- Learning curve: if you don’t know Docker and Docker Compose, it will be less intuitive at first;
- First setup: harder to setup at first, if you have been using a VM for a long time, you will feel that you are going against the tide, but I assure you, in the long term it will be a lot simpler this way.
Taking the above into consideration, I would like to say that when I’ve started with this setup I was using Linux with 8G of RAM. One of my colleagues even wished me good luck on installing Magento2 on a ultraportable 8Gb RAM system. He wasn’t even sarcastic, more like pitying me for my bad workstation selection.
One of the requirements was that I needed some isolation and configuration between projects, I couldn’t just install a server and be done with it.
Previously I’ve been using Vagrant and VirtualBox, a great fit, very easy to use (most of the time). However, for Magento2 I’ve realised that it was heavy enough on its own, it was making me run out of resources fast.
Also, I wanted it to be easy to use, I don’t like to have to remember and type out a 3 word command, I just want to press some tabs and get it over with.
There were some specific requirements:
- nginx config – should work out of the box, Magento configuration isn’t very small, I wanted to make use of it with ease;
- SSL – the domain has to also work with HTTPS, mostly because some APIs require it, the certificates don’t need to be valid;
- bash – the Magento command should work as the system user, not as root (as containers usually do). This is required, because I don’t want the files generated by Magento to be generated as root (and therefore only removable with root rights);
- xdebug – must work out of the box and be easily integrated with an IDE.
The implementation and usage
Magento2 offered a Docker container to work with. I will not say anything about it, since it wasn’t at all something I needed.
My main source of inspiration was: https://github.com/markoshust/docker-magento. The project changed a lot since I’ve started, so I definitely think you should check it out.
The starter point is: https://github.com/claudiu-persoiu/magento2-docker-compose
The relevant files are:
- magento2 – it should contain a folder html with the project
- dkc_short – it can reside anywhere, but it should be added to the files ~/.bash_profile or ~/.bashrc, this file contains shortcuts, it’s not necessary, but I like it because it make my life easier;
- docker-compose.yml – it contains all the mappings and relevant containers.
NOTE: I think I should point out that the commands on the PHP container run in two ways, as the system user or as root. This is a limitation of the Linux implementation, please make a note of it, as I will refer to it later.
What you should do when starting a new project with an existing Magento2 repository:
1$ git clone https://github.com/claudiu-persoiu/magento2-docker-compose.git project_name 2$ cd project_name 3$ git clone your_own_magento2_repository magento2/html 4
Step 2 (optional):
Copy the shortcuts to your bash console:
1$ cp dkc_short ~/ 2$ echo ~/dkc_short >> ~/.bash_profile 3$ source ~/.bash_profile 4
NOTE: If you don’t have the file ~/.bash_profile on your computer, just use ~/.bashrc
Start the setup:
1$ dkc-up -d 2
It will take a bit of time the first time, but it will be a lot faster next time you run it.
Run composer install:
1$ dkc-php-run composer install 2
That’s about it.
What is this dkc stuff?
Well, I like to use tabs when running a command, so I added some aliases that allow me to run a Magento command without typing everything, I just type dkc[tab]p[tab]-[tab] and the command. I just love bash autocomplete.
The command list is very simple:
- dkc-up -d – start the containers in the background
- dkc-down – stop all containers
- dkc-mag [command] – run a Magento2 command
- dkc-clean – clear the cache
- dkc-php-run – run a bash command inside the php container, like composer in the previous example. NOTE: This command is running as the system user, not as root.
- dkc-exec phpfpm [command] – this is same as above, but running as root. You should almost always use the command above.
- dkc-exec [container] [command] – this command needs a bit more explanation:
- container can be:
- app – for Nginx server,
- phpfrm – for php container,
- db – for database,
- cache or fpc – for cache containers;
- container can be:
- the command can be anything that applies to that container, like “bash” or “bash composer”, etc.
I know the commands seem like “one more thing to learn”, but most of the time you will only use the first 4 commands.
How does the magic work?
Well, to see what the above commands translate to, just check the “dkc_short” file.
There are only 2 other interesting repositories:
- https://github.com/claudiu-persoiu/magento2-docker-php – that contains phpfpm,
- https://github.com/claudiu-persoiu/magento2-docker-nginx – that contain the nginx server.
The repositories are pretty small and not very hard to understand.
If you need to modify anything, just feel free to fork the repositories.
That’s about all you need to know about it, I’ve been using this setup for almost 2 years.
For me, it’s working as a charm and I was able to use Magento2 on ultraportable laptop with 8Gb RAM without any issues.
The (happy) end!
Don’t be fooled, this post is about programming, system architecture but mostly about using a heating system.
If you don’t know how can you talk about programming without programming you should check out the “The Passionate Programmer” book by Chad Fowler, a great read. The Jazz stories from this book inspired me to write this blog.
The story begins with a new apartment in an old building. Or at least it’s new to me.
The building has its own heating system, very old and extremely inefficient. After a long consideration I’ve decided that it was time to install my own heating system and disconnect from the main building one.
So far, nothing interesting, there are many people that do this, partly because of the added comfort and partly to optimize expenses.
With this being said, I had a project and needed a developer. Or in other words, I had a heating system to build and I was in need of somebody to do it.
I’ve asked around for that “good” developer.
Like in anything else, there are a lot of people that come up with bad solutions. There are devs that make great offers but are unable to finish the project, or they write very bad code that is not scalable and even worst, unmaintainable.
Since what I know about heating systems can be covered by anyone with the patience to google the subject for a couple of hours or so, I wanted somebody I could trust, so I was looking for the passionate kind of developer!
I had a couple of recommendations. The first one told me that he had to put all the pipes close to the ceiling. After convincing him that I don’t want my house to look like a factory full of pipes he said that he will definitely need to replace one of the radiators (at least) because he could not fit a pipe behind it. I could fit my palm behind that radiator, with this in mind I knew I wanted somebody that could fit a pipe behind my radiator.
It was clear that he wasn’t a good developer. A good developer must work with the requirements, the very least a project should be able to respect most of the client requirements, if it doesn’t, there can be several explanations: he can’t because he doesn’t know how or he doesn’t want because he knows it’s hard and doesn’t want to go that extra mile. In some cases that’s not a tragedy, maybe it will be cheaper and faster, and in his case it was. Unfortunately for him, I aimed for quality.
Then there was the passionate developer. He never mentioned anything about not being able to do something, it was always a cost and maybe a consequence. The deal with better developers is that they are more expensive and everything about them is expensive, they will want better servers for hosting, better tools and sometimes more time for things like testing and maintenance. In other words, sometimes the cost is bigger not just then, but also in the log run. A quality project takes time and money.
This is my resulting project:
If you never seen an apartment heating system before you should know that except for the pipes, nothing else is actually required.
It’s all just passion!
For instance: the pump on the lower right, it’s there just to force the water to move faster in the system. Think of it as Redis, it will have a good effect on your system but most systems will happily work without it. Of course, at some point there may be maintenance for that pump and can even result in issues, like this Magento 2 issue: https://github.com/magento/magento2/issues/10002. Every system has its own cost.
The expansion tank in the lower left was unnecessary (in the sense that the system already has one built-in), but it’s not a bad idea to have an extra. Think of it as that extra storage space, ram or CPU that you don’t actually use. Your server should never go above certain server loads, that’s the expansion tank you should take into consideration.
The water intake filter is like your firewall, you need it, it’s your protection, maybe most of the time will be useless but when there will be issues, then you will be glad you have it, because he will have filtered them out.
The good thing with passionate developers is that other developers understand and appreciate their work. That is very important, no matter the industry of the “developer”.
The only one that had anything to comment on the system was the ISCIR certified technician that initialized the heating system (ISCIR in Romania is a special authorization needed for this exact thing). You can tell that he wasn’t passionate, he just wanted to say something bad about it because he wanted to make a good impression on me.
Unfortunately for him, he made some very stupid comments and then he made me a maintenance offer. This guy was the consultant, he didn’t do the project and he doesn’t want to work on it but he definitely wants to make some money on it without actually doing anything.
I guess the conclusion is that no matter the developer, the quality and passion transcends the industry.