Last month I had the joy of attaining my first year as a professional web developer in a Finnish firm centered around online payments.
My background involves a couple of years as a technical support desk worker in a huge ISP, university research centered around digital game layout, and a few pop-culture criticism to sites and hobbyist papers.
I’m 30 years old and currently composing a Master’s thesis concerning playtesting. Let this be my introductory article for the dev.to community and my own retrospective on three important things I’ve learned this season.
Number1 PHP Is Back With a Bang
Or depending upon your point of view, still excellent. That’s an response too. I used to create some simple dynamic websites and personalize WordPress blogs with PHP 5 and quickly noticed myself becoming tired of it. Languages like Python and Ruby only felt a lot more sensible and fun to design websites with than old dog PHP. Luckily, that isn’t true anymore.
In the university information system class my applications technology instructor — that happens to also be a professor — known to PHP as a toy speech that nobody must utilize. I’m sure many of you have read one of these notorious blog posts warning about PHP being poor in everything but in 2017++ that’s actually very far from the truth.
PHP of now comes with strict typing, great community development support together with Vagrant and Docker, smarter syntax (never kind variety() again), and a ton of handy frameworks. Talking of frameworks, utilize them. Seriously. Not only can frameworks like Laravel and Lumen improve your program safety, but they also give you with a enormous selection of helpers from database abstractions, authentication patterns and to — one of my favorites — templating engines. You’ll still get funny comparisons such as:
Echo 123 == '123lol' ? 'True' : 'False'; # Outputs Authentic
But this will only teach you to compare forms aside from values. Switch == to === over and watch what happens.
All of the goodness of all frameworks also concerns CMS platforms such as WordPress too. As an example, Sage 9 is a impending major update to this popular WordPress starter theme that permits you to compose your theme together with Webpack, Blade templates and Bootstrap 4.
A thing of past are the times you had to edit your PHP files locally, then firing up an FTP client such as FileZilla or WinSCP for transferring your code to a distant server, and finally hope that whatever works. My private PHP workflow is composed of installing PHP locally via Homebrew package supervisor, setting up nginx, MariaDB, Redis, and other dependencies in their own Docker containers that I’ve connected together with Docker Compose. I could too put in each of these in a digital Vagrant box such as Homestead or even Scotch or simply let them live happily in macOS atmosphere. However, this really is the strategy I’m most comfortable with and it provides enough freedom when going between notebooks.
Simply speaking, PHP gives you liberty whilst not sacrificing current best practices. It’s fine to not like it, but only if you’ve understood the truth and not jumped onto some random hater bandwagon.
#2 Don’t Be a Fool, Configure Your Tools
This can be very an important issue which often gets overlooked. Setting up your environment is and ought to be more than simply downloading a simple text editor such as Sublime Text and enabling syntax highlighting. If you are a Vim user you understand editor setup like no one else can.
I’m in a fortunate place where my supervisor really allows and recommends us to educate ourselves and research superior workflows when there are no critical issues waiting on board. To this end, I’ve been swallowing Laracasts movies concerning tooling which I recommend to everybody.
Thus, select your weapon of choice, research its characteristics and limitations so long as it requires. Then place it up along with your favorite UI scheme and install the required plugins. Do this before beginning to compose the first line of code to this groundbreaking new app you are working on.
I, not unlike many others, have switched from alternating between Vim and Atom to Visual Studio Code which provides me integrated terminal, debugging, unit test taker, plus some smart static analysis and code refactoring tools via extensions. For a few of the more complex jobs, I utilize IntelliJ IDEA which currently has better PHP integration however I intend to begin using VS Code as my only editor when possible.
Despite Linus Torvalds badmouthing the use of debuggers I strongly suggest using one — XDebug is great for PHP. Without a debugger, you are going to place an additional cognitive load on your brain while trying to keep the stream of system on your mind. It’s then very likely you just get tired and begin ditching the shit out of each factor in scope to your files before you discover the poor sucker process returning 127 instead of fictitious. Having a debugger, you find the whole state of the program as it is till the breakpoint, and you may evaluate expressions inside that state. Not only does this save time but blocks naturally fatigue too.
As a final but not least important bit of advice; if a person enjoys Emacs don’t try to convert them to utilize Vim or vice versa. You simply look as if you left your brain in the past century. The culture about creation tools is enormously wealthy and everybody has space for selecting their very best equipment. Or would you start contending with Gimli to change his ax to get a bow right ahead of a horde of Uruk-hai is preparing for assault? I don’t believe you would.
#3 Continuous Integration Guarantees Sweet Dreams
If you don’t know what constant integration (CI) means it’s been explained in detail in this article.
We, like every good software firm, do code reviews as part of our growth procedure. Without a stable CI, we would be drowning in regression bugs and might need to bug our coworkers should they’ve tested this or that and with what coverage.
In my principal project we’ve put the CI to run code linting using PHP Code Sniffer and PHP Mess Detector (that can be wonderful tools when configured correctly), run unit tests with coverage, and finally check whether the coverage is 100 %. Any preceding assess returning non-zero leave code will neglect the alert and run the developer through a notification. Lower than complete coverage will also neglect the run. If some of those checks have failed we don’t approve the code review. At times it’s a tricky way but it ensures the technical debt stays relatively brief, code quality stays on acceptable rates, and new features won’t break present ones.
CI is also rather simple to set up in Travis and in Gitlab using a couple of YAML blocks. If you operate on a project with more than a handful of programmers utilizing CI is well worth it if not compulsory.
Conclusion
2018 can see me creating these skills even further while adopting some fresh ones. Now I’m interested in hearing exactly what were your particular lessons from your first year?
If you liked what you read, follow me and onto Twitter.
Cover picture by DigitalOcean licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
source http://www.pendragoninteractive.com/three-lessons-ive-learned-as-a-professional-web-developer/
No comments:
Post a Comment