Tag Archives: Building

[ad_1] TL;DR: I’m tired of writing code without consistent standards (I often work on code that changes between WordPress or PSR2) so this is how I installed PHP Coding Standards via Composer and a few extra extensions for the project. This also details how to automatically format the code on save. Adding PHP Coding Standards I’ve talked about this in previous posts (or maybe several previous posts) but for the purposes of this project, I’m going to be using a certain extension within Visual Studio Code. Add PHPCS via Composer (and Running PHPCBF) First, I’m going to install it at the global level – or verify it’s installed at the global level and document it here for those who are following this series. To install it with Composer (and here’s how to install Composer), you can issue this command in the terminal (you can choose a different version but, at least a the time of this writing, this is what I’m using): $ composer global require “squizlabs/php_codesniffer=^3.5” Then, in the composer.json file located at the system level (if you’re on macOS, this will be something like /Users/your-user-name/.composer/composer.json, make sure it contains something like this: { “require”: { /* … */ “squizlabs/php_codesniffer”: “^3.5” }, “require-dev”: { /* … */ } } Then run: $ composer install And this will install PHPCS and PHPCBF which is the utility that will help format the code for any problems. Ultimately, I’m looking to make sure my output looks something like this. You can verify this works by entering the following command in your terminal: $ which phpcs And this should return: /Users/your-user-name/.composer/vendor/bin/phpcs You can also get information about the installed rules by running: $ phpcs -i And this will return something like this: The installed coding standards are PEAR, Zend, PSR2, MySource, Squiz, PSR1, PSR12 If you’ve gotten this far, then you’re ready to go with make sure Visual Studio Code has what it needs to use PHPCS. Add Support to Visual Studio Code First, I use the phpcs extension by Ioannis Kappas. This is where you can find it in the Marketplace. From the project page: This linter plugin for Visual Studio Code provides an interface to phpcs. It will be used with files that have the “PHP” language mode. phpcs Remember that it’s important to make sure this is installed Composer and you know how to access that path because the extension expects the binary to be available in the system. I keep it installed at the system level because I use it in some form across all of my projects. Next, Update the settings.json file for your project so that it contains the following two lines: “phpcs.executablePath”: “/Users/tommcfarlin/.composer/vendor/bin/phpcs”, “phpcs.standard”: “PSR2”, After doing this, then you should see errors show up in your code or you shouldn’t see anything different. If you’re writing PSR2-based code, you’re good to go; otherwise, you can easily fix it by using another extension. (Yes, you can use the terminal but automation can be a major time-saver here). Automatically Running PHPCBF Rather than writing a terminal command to do this, I recommend another Code extension called phpcbf. From the project page: This extension provides the PHP Code Beautifier and Fixer (phpcbf) command for Visual Studio Code. phpcbf is the lesser known sibling of phpcs (PHP_CodeSniffer). phpcbf will try to fix and beautify your code according to a coding standard. phpcbf Once you install it, you should be able to configure it very easily, again, in settings.json by doing the following: “phpcbf.executablePath”: “/Users/tommcfarlin/.composer/vendor/bin/phpcbf”, “phpcbf.enable”: true, “phpcbf.onsave”: true, “phpcbf.standard”: “PSR2”, This tells Code that where phpcbf is, to enable it, which standard to use, and to perform formatting whenever you save the file. You can also manually do it (as shown here). Until Part 6 With all of this in place, it’s now possible to make sure the code that’s being written is up to a consistent standard and to have the IDE actually take care of it for you automatically. Scattered Thoughts I’m thinking that some of the content in each of these posts would work well as stand-alone posts for things that others may be looking for (maybe some of the stuff here, maybe some of the stuff in other posts). I’m going to consider breaking some content out into separate posts. There’s no particular reason that I chose PSR2 over any of the other standards. I work with the rest enough and this is the one I chose just to keep on the up and up with said standard. (I’m not religious but what standards I use so long as I use an actual standard.) It’s been a little while since I’ve blogged about the work I’ve done on this project so the tone of this post is different than what I’ve done in previous posts. I know that. I ought to clean it up, but I probably won’t 🙂. I’m more concerned with information than the tone of the posts write now. [ad_2] Source link

[ad_1] TL;DR: The private podcast account is set up but not yet recorded; I’m looking to do that sooner rather than later. I’m looking to possibly abandon exclusive Overcast support which I’ll briefly talk about. This article walks through the process of defining the conditions for unit testing and how I’ve decided to go about writing the first set of unit tests. Building Backcast, Unit Testing Where Do I Go From Here? Originally, this post was going to be a combination of setting up PHPUnit and getting up and running with writing unit tests but, if you’ve been reading along, then you saw how well that went over. Honestly, I’m glad I encountered that early on in the process as it shows the random rabbit holes any of us end up in whenever we’re writing code. Secondly, after running into a hurdle with authentication with Overcast and deciding to just go with a manual export of podcast feeds, I started looking at a couple of different podcast applications to see how they exported their feeds. Ultimately, I was looking for a set of standards (which would include common attributes) that I could use to evaluate the validity of a file and to update the backup with only new information. (Of course, the first import is always going to be the largest.) I asked myself the following questions: Do I look for a file with a specific name? Do I verify the content of the file? Do I accept any XML file? Do I need to verify the size or date of the file? Some of these questions, like many, lead me into thinking about other things, too, but in trying to make as much progress as possible with as little friction as necessary, I decided to do the following: Verify the type of file (that is, an opml file), Verify that it’s well-formed or, rather, valid XML, Verify four attributes of the XML file that appear to be common across podcast exports. (I’m going to test for the opml tag, the rss value for the type attribute, the outline tag, and the xmlUrl key.) If any of these fail, then I’ll assume that I have an incorrect export. That seems to be a reasonable balance for now. And now that I have PHPUnit set up and running correctly, I can start writing unit tests. Test Data Before writing the tests, I want to make sure I have a couple of export files that I can test against. This, I hope, will verify the validity of the tests. I’m creating an exports directory in the tests directory and dropping in an export from Overcast and from Pocketcasts. And now that I’ve that done, I’ve merged the current feature branch into the develop branch. A Note About My GitHub Workflow In case I’ve not described this before, my workflow for this project includes creating a develop branch off of main and then a corresponding feature branch off of develop so that I can work on a single branch. As it stands, I’m trying to keep each branch with a specific post. I’ve not really shared them yet because it’s a private repository but once I have enough functioning code to throw out into the public, I’ll open the repository. Maybe by the end of this post, even. Writing Tests Before writing tests, I need to do the following: set up a core class in the src directory, set up the autoload functionality in the composer.json configuration file, and verify that PHPUnit can access my class Once that’s done, I can actually get into writing tests. But I need to get this scaffolding done first. Set Up a Core Class That’s in a Namespace Initially, I’d started out with a constant defined in the main file, but I’m going to move away from that. The fastest way for me to get from nothing-to-something is to set up a single class, for now, that will encapsulate the functionality I’m trying to test. This is the part where I rationalize not doing BDUF. Big Design Up Front (BDUF) is a software development approach in which the program’s design is to be completed and perfected before that program’s implementation is started. It is often associated with the waterfall model of software development. Wikipedia I share a little bit more in my Scattered Thoughts in the section at the end of this post. Refactoring the Bootstrap First, I’m creating a new branch (aptly called feature/add-validation-tests since that’s what I’ll be doing in this post) and I’m going to clean out the code in the core backcast.php file, or the bootstrap file, so that I can use it to instantiate an object from the class I’m going to be writing. This means the bootstrap file will look like this: #!/usr/local/bin/php <?php namespace Backcast; require ‘vendor/autoload.php’; new Backcast(); Note here, though, that I’m including the autoload.php file generated by Composer. Define Autoload Functionality Before going any further, let me share what the composer.json file looks like: { “name”: “tommcfarlin/backcast”, “description”: “An application used to backup podcast subscriptions via podcast XML exports.”, “require-dev”: { “phpunit/phpunit”: “^8” }, “autoload”: { “psr-4”: { “Backcast\”: “src” } }, “autoload-dev”: { “psr-4”: { “Backcast\Tests\”: “tests” } } } The two things I want to call out are the autoload and the autoload-dev areas. The first section tells composer where to locate files for the autoloader which is ideally used in production environments. The second section tells Composer that only the files in this area are intended for non-production environments. This means when you run composer dump-autoload –no-dev on the command-line, nothing will be generated for the tests directories. With that said, let’s set up the core class. The Initial Backcast Class First, I’m going to add a Backcast.php file to the src directory. I want to easily verify it’s been instantiated so to make this easy, it looks like this: <?php namespace Backcast; class Backcast { public function __construct() { echo ‘This class