If you’re refactoring something – do it iteratively.
Recently I was refactoring some code, it was time to pay off some debt. We have modular monolith and it appeared that one module was clearly a part of another, they just ping-ponged themselves all the time.
I was convinced that it was trivial. Communication from and to the module is done entirely via the module’s API. So it’s enough to move all files from the obsolete module to the other one and done. Right?
Technical debt is a tool – use it, but use it wisely.
Technical debt is cool. Am I crazy? No, I think it’s a great feature (yes, feature) of agile development. Let me explain.
Technical debt is there. We can safely assume that in the very moment you finished a feature and pushed it to production – it’s debt. Best code is no code. But let’s talk about intentionally creating it.
Let’s say you like to write good, readable and tested code. You take care of DDD, use best practices, create caches when necessary. But then business has an idea for a feature, and they aren’t sure if it’s gonna work but they wants it fast. If you’d try to make this feature as you like, as your engineering soul tells you, you’d say “ok, give me a week or two”. There are disadvantages to that approach.
Test values matters.
Recently there was a bug I introduced that could be easily avoided if not poorly designed test values.
It was a pretty big refactor or core functionality. Scary, so I grabbed some people and did testing on my local environment, just to be sure everything works. I seemed so, great success!
Arrow functions are very easy and I’m just an old man.
I remember that I saw arrow functions in js for the first time. It was pretty hard to understand for me, but I didn’t do anything in js in years, so I just get used to this unknown.
But recently I’m working in a project with PHP 7.4. And guess what. Yup, arrow functions arrived in PHP in exactly this version. So I hadn’t a choice but to sit down and understand this little bastard.
Arrow functions in PHP are fairly simple, yet quite nice, and a little different than ordinary lambda functions.
Review your own code after some time, or another task.
Some time ago I had an idea. What if I could do a code review for my own code? Of course It would be nonsense to do it just after code was written. But what about day or two later?
This idea appears probably in the time, when I was the only backend developer in my team (holidays or something…). In such situation creating too much code and making too much tasks could be worse, than doing nothing. Checking this code would take all of my teammates’ time, I’ll have to make some fixes to at least some of them. And even, when the rest of team will be present, they will do CRs of my code and what could I do then? Writing more code equals more CRs. Infinite loop 😉 In such situations slack time would be better option imho.
So, I thought about some ways to be more efficient in such conditions. And self code reviews appears.
Ctrl + v and
Cmd + Shift + a shortcuts in PhpStorm. Period.
I changed my job recently, so I changed my coworkers as well. It’s always a good opportunity to learn something new. And a good excuse to write about it 😉
So I want to present to you my favorite shortcuts in PhpStorm. I’m working on a Mac so presented shortcuts are for its keyboard. And I’m using “Default” keymap.
Quick version control operations
If you’re using Git then you can use it in PhpStorm in two ways: console and in version control (VCS) menu. There are also some handy shortcuts, like
Cmd + t for
git pull or
Cmd + k for
git commit. But if you want to create a branch, or checkout to one, you go to VCS menu, find your option and click it.
Waste of time!
If you want to add a new logger to Laravel just create new service extending `Logger`, inject it via the constructor and you’re good to go!
I’m a Symfony guy, but from some time I have to use Laravel. There is the neverending war between those, but what do. It’s not that bad eventually…
Recently I was supposed to add logs to some command, for debugging purpose. Laravel has its logger as facade but I didn’t want to use this one, I just wanted to log some data to separate log file, debug the command and delete the log. And there is no way I found to create a separate log by using the `Log` facade.
As it turns out, Laravel’s log facade uses monolog, so there is a possibility to access monolog itself and create a new logger. I’ve searched the web for the best solution, some suggest creating a new facade and using it, some suggests creating logger “in place” and use it only in my command. But none of it seems right…
If you want to deploy Symfony app using Capistrano 3 to cheap OVH VPS then you’ll need to write a simple task to set proper permissions.
Edit: unfortunately, there was still a little problem with permissions and I made deployment semi-automatic.
I have a very cheap VPS in OVH, it costs only about $2 per month. It is perfect for my needs, I have my blog there, I have my friend’s blog as well. And now I want to move my wife’s portfolio from (even cheaper :P) shared hosting to this VPS.
Until now deploy to shared hosting looked like this:
- open FTP
- go to portfolio directory
- move changed files
- app/console cache:clear
Fortunately, I had access to SSH on my hosting (not popular thing) so I could try to automate this process a little bit. But because I already have VPS then the better idea was to move the portfolio there and use some tool for deployment.
The portfolio is written using Symfony 2 framework so the best idea is to use Capistrano. I had some experience with Capifony which is pretty old, unmaintained customization for Capistrano 2 (which is also quite old). I don’t want to use old stuff. So the goal is easy: deploy Symfony 2 app using Capistrano 3 to OVH, cheap VPS.
Another contribution to Symfony merged! \o/
My Pull Request has been accepted by Symfony docs guy and will be merged soon. This is a minor change, but I think it’s a good idea to improve anything we see that can be improved.
This particular change was created because I’ve seen at least 3 programmers getting parameters in service not from injection but from the container. Hope it helps them to understand how to use parameters in a good way 🙂
PR can be seen here: https://github.com/symfony/symfony-docs/pull/8399
Feels good ?
If you’re writing commands in Symfony then you probably know the ProgressBar component. It’s useful tool showing the current state of operations and, more importantly, ETA and used memory. Cool.
If you’ll go to the official ProgressBar component page then at the beginning you’ll see a very cool progress bar, with colors, icons, changing status messages, but… If you’ll look a little further you’ll see a sad, black and white progress bar, that is far from a “promise” made at the beginning 🙁
Heads up! We’ll make it like this 🙂