PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 13:00:29 -060030http://www.phpdeveloper.org/news/22198http://www.phpdeveloper.org/news/22198
Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

Link: http://derickrethans.nl/path-branch-coverage.html]]>Wed, 07 Jan 2015 09:33:13 -0600http://www.phpdeveloper.org/news/22184http://www.phpdeveloper.org/news/22184
In his latest post, Stefan Koopmanschap shares an interesting idea he thinks more software developers would do well to adopt - Use what you can (or "don't do it yourself).

In her book, Amanda Palmer talks about DIY, and how when you start asking for help, Do It Yourself is a strange term. Instead, she suggests UWYC, which stands for Use What You Can. I think software developers can learn a lot from this mindset. As Palmer says: "I have no interest in Doing It Myself." This is exactly how we should approach software development.

He points out that, for the most part, the tasks and needs of most software have been solved. There already exists functionality to do those things, so why would you need to create your own? By doing so, you only increase your load as a developer, shifting the hard work of maintenance and improvement into your already loaded work schedule. He does make a good suggestion for using other people's code, though: filter the solutions (according to criteria like following good practices, documentation and if it's in active development).

Link: http://leftontheweb.com/blog/2015/01/02/use-what-you-can/]]>Mon, 05 Jan 2015 10:15:21 -0600http://www.phpdeveloper.org/news/22155http://www.phpdeveloper.org/news/22155
The SitePoint PHP blog has a recent tutorial showing how to use PhpMetrics to visualize your application and the quality of its code.

We had been looking into code quality checking tools for a while here on SitePoint - most recently in a series on Jenkins, but none of those could do what a project I've only recently found out about can. PhpMetrics uses D3 and some sophisticated analysis algorithms to scan your application's code and output intricate reports about it.

He walks you through the install (via Composer) and how to clone two example projects, Laravel and Symfony, to evaluate. He includes the command line to run the evaluation and plenty of screenshots showing the results for things like:

Cyclomatic complexity

Abstractness

Maintainability

Code density

He uses the results from these two projects in his examples and, at the end of the post, summarizes and compares the results it produced.

Link: http://www.sitepoint.com/visualize-codes-quality-phpmetrics/]]>Fri, 26 Dec 2014 12:48:31 -0600http://www.phpdeveloper.org/news/22056http://www.phpdeveloper.org/news/22056
Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

Link: http://hexatlas.com/entries/5]]>Thu, 04 Dec 2014 09:05:04 -0600http://www.phpdeveloper.org/news/22042http://www.phpdeveloper.org/news/22042
In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn't it fun to find a comment in code that's completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn't need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it's less likely they'll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

Naming things

Extract functions

Introducing variables

Defining class and module interfaces

Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

Link: http://codeutopia.net/blog/2014/12/01/how-to-make-your-code-self-documenting/]]>Tue, 02 Dec 2014 09:35:21 -0600http://www.phpdeveloper.org/news/22010http://www.phpdeveloper.org/news/22010
In a recent post Dejan Angelov shares the process he went through to upgrade an application to Laravel 5, yet to be released (at least at the time of this post).

Over the past weeks, Taylor introduced many great changes and new features that we'll be able to use in the new version, firstly numbered 4.3 and later 5. According to the framework's six month release cycle, it should had hit stable late this month or in early December. Because of that, I started to play with it and to apply the changes to make my application use it.

However, a couple of days ago, Taylor wrote a blog post on the Laravel's blog saying that because of the importance of this release, the release date will be postponed to January. Considering this, everything you'll read here MUST NOT be applied to applications that are currently in production.

He starts with some of the major differences, including changes in the dependencies required and the removal of the "start.php" file for bootstrapping the application. He talks about the changes in startup and shutdown as well as autoloading. He looks at directory structure changes and the addition of a base namespace. He then gets into how to fix these issues, one at a time, including code and configuration changes that need to be made. This includes updates to the facades, changes for middleware, environment configuration, pagination and routing. There's lots of other changes happening with Laravel 5, so be sure to check out the full post if you're interested in the steps you might need to take when this latest version is released.

Link: http://angelovdejan.me/2014/11/22/experimental-upgrading-to-laravel-5-how-i-did-it.html]]>Mon, 24 Nov 2014 12:57:18 -0600http://www.phpdeveloper.org/news/21891http://www.phpdeveloper.org/news/21891
NetTuts.com has completed their series on refactoring with the posting of part eleven today: "The End?" This post finishes off a series where they've moved from the most basic level of testing out to a complex set of tests that can ensure your code's quality and functionality even after making their recommended refactoring changes.

In our previous lesson we've learned a new way to understand and make code better by extracting till we drop. While that tutorial was a good way to learn the techniques, it was hardly the ideal example to understand the benefits of it. In this lesson we will extract till we drop on all of our trivia game related code and we will analyze the final result.

They start off by "attacking the longest method" (wasCorrectlyAnswered) by starting the testing process. They make some simple checks to ensure the output is correct for various circumstances and values. With these tests in place, they safely refactor the method, splitting it up into functional pieces and completely dropping the method in favor of more targeted handling. They finish off the post with a look at some final results and comparing the refactored code with the original on things like lines of code, complexity, dependencies and structure (using this tool).

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-11-the-end--cms-22476]]>Mon, 27 Oct 2014 13:36:14 -0500http://www.phpdeveloper.org/news/21822http://www.phpdeveloper.org/news/21822
On the SitePoint Web Blog there's a recent post by George Fekete with a few suggestions about how to be a good developer, regardless of the language or technology you're using.

As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day. What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art. In this article, you'll learn about how to be a better developer by following the "etiquette" of programming and you'll learn how to use this information to perhaps teach others to better themselves.

He starts with some tips about "being professional" overall that include things like being responsible and having a strong work ethic. Then he moves into writing good code. This isn't about actual code examples, more about good practices and tools. He also shares some tips about how to keep things (and yourself) on track and tips on how to "be a master" when it comes to social interactions and the work you're doing.

Link: http://www.sitepoint.com/good-developer/]]>Mon, 13 Oct 2014 11:54:17 -0500http://www.phpdeveloper.org/news/21784http://www.phpdeveloper.org/news/21784
On the Twilio blog there's a recent post showing the construction of some fundamental parts of a MMS ticketing system using Laravel and Twilio for the messaging.

Have you ever arrived at a movie, flight or concert and realized you've forgotten your paper ticket? Imagine how much worse it would be if you showed up at Willy Wonka's front door, but forgot your golden ticket! To prevent an epic disaster such as this, we're going to build an app that delivers Willy Wonka's golden ticket directly to your phone using MMS. All the Oompa Loompas have to do is scan it. Not Willy Wonka? Don't worry, this code should be useful for any app or company that distributes tickets. Hopefully computers are more helpful with the golden ticket than last time.

The application makes use of a few libraries outside of the Laravel framework structure to handle the various functional pieces: one for creating QR codes and another for sending the messages via Twilio. They walk through some of the basic setup for the first endpoint and the "Golden Ticket Distribution" page. He then uses the Endroid QR code library to generate a code based on a string and outputting it to the user. Using a few pieces of data from the URL (in $_GET), they define the phone number to send to and the name of the user. Finally they tie it into the Twilio messaging system and send the MMS message containing the resulting QR code.

Link: https://www.twilio.com/blog/2014/09/how-to-build-an-mms-ticketing-system-using-php-laravel-and-twilio.html]]>Fri, 03 Oct 2014 12:18:54 -0500http://www.phpdeveloper.org/news/21723http://www.phpdeveloper.org/news/21723
NetTuts.com is back with the latest part of their "Refactoring Legacy Code" series for PHP. In this latest article (part 10) they work on pulling apart longer methods into smaller, more manageable chunks.

In the sixth part of our series we talked about attacking long methods by leveraging on pair programming and viewing code from different levels. We continuously zoomed in and out, and observed both small things like naming as well as form and indentation. Today, we will take another approach: We will assume we are alone, no colleague or pair to help us. We will use a technique called "Extract till you drop" that breaks code in very small pieces. We will make all the efforts we can to make these pieces as easy to understand as possible so the future us, or any other programmer will be able to easily understand them.

This "extract 'till you drop" mentality (from Robert Martin) has you look at a piece of code and find the logic and lines that can be split out and isolated without removing functionality and interaction. They include some random code from a Stack Overflow post (checking if a number is a prime) and show how to split it out, making the logic and structure less complex and more understandable. They start with a unit test to ensure the result is the same post-refactor and fixing a few bugs along the way. They split it out into two different methods and move it from a more linear approach to something recursive.