News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Julien Pauli:
Zoom on PHP objects and classes
March 26, 2015 @ 12:50:49

Julien Pauli has a recent post to his site that "zooms in" on objects and classes with a look behind the scenes at how they're handled in the PHP source (at the C level) with plenty of code examples and explanations as to how they work.

Everybody uses objects nowadays. Something that was not that easy to bet on when PHP5 got released 10 years ago (2005). I still remember this day, I wasn't involved in internals code yet, so I didn't know much things about how all this big machine could work. But I had to note at this time, when using this new release of the language, that jumps had been made compared to old PHP4. The major point advanced for PHP5 adoption was : "it has a new very powerful object model". That wasn't lies. [...] Here, I will show you as usual how all this stuff works internally. The goal is always the same : you understand and master what happens in the low level, to make a better usage of the language everyday.

The article does a great (if lengthy) job of covering everything that happens with PHP's objects and class system, including stats about memory consumption. He includes both the PHP code and the C code to illustrate what's happening with classes, interfaces, traits and object methods/attributes (including object references). He also talks about what "$this" is and how class destructors are handled.

0 comments voice your opinion now!
object class behindthescenes detail c code memory usage

Link: http://jpauli.github.io/2015/03/24/zoom-on-php-objects.html

Piotr Pasich:
Ant, composer and code quality tools
March 18, 2015 @ 11:33:47

In his latest post Piotr Pasich shares some handy tips (and tools) to help you use Composer to do some of the common tasks you might use Ant or Phing for.

I decided to start with something uncomplicated - a simple solution that could help me solve a prosaic, but annoying issue. For instance, XML format. No, I won't fight with it. I see it as great and practical, however mostly I don't need so sophisticated code to cover my needs - the yaml usually fits the purpose. [...] Yet, do I really need this flexibility [of XML configuration] when I use vagrant or docker to maintain the same environment as on the production? For 90% of PHP projects probably I won't use all of the features of the virtualization tools. I only want to install necessary libraries, check the code quality before committing or introduce fixtures. Most of those points are easily feasible in composer.

He then shows how to execute these checks through the functionality included with Composer to run custom scripts. His example measures the quality of the code based on the results first from a single run of the PHP Mess Detector (phpmd) command. He then extends this with the open source contribution he mentions earlier with his CodeQualityThreshold library allowing not only for more checks (phpmd, phpcs, phpcpd, etc) but also allows you to configure the thresholds for each class if desired. He includes an example of it in action and screenshots of the results.

0 comments voice your opinion now!
ant composer code quality phpmd commandline library codequalitythreshold threshold

Link: http://piotrpasich.com/ant-composer-and-code-quality-tools/

Derick Rethans:
Code Coverage Finding Paths
January 07, 2015 @ 09:33:13

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.

0 comments voice your opinion now!
code coverage phpunit xdebug report paths vld lines

Link: http://derickrethans.nl/path-branch-coverage.html

Stefan Koopmanschap:
UWYC Use What You Can
January 05, 2015 @ 10:15:21

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).

0 comments voice your opinion now!
opinion code resuse diy usewhatyoucan

Link: http://leftontheweb.com/blog/2015/01/02/use-what-you-can/

SitePoint PHP Blog:
Visualize Your Code's Quality with PhpMetrics
December 26, 2014 @ 12:48:31

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.

0 comments voice your opinion now!
code quality metrics phpmetrics visualize tutorial

Link: http://www.sitepoint.com/visualize-codes-quality-phpmetrics/

Eric Wastl:
Your Job Is Not to Write Code
December 04, 2014 @ 09:05:04

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.
0 comments voice your opinion now!
software engineer write code opinion correction medium

Link: http://hexatlas.com/entries/5

Jani Hartikainen:
How to make your code self-documenting?
December 02, 2014 @ 09:35:21

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.

0 comments voice your opinion now!
selfdocumenting code examples naming separation extract group

Link: http://codeutopia.net/blog/2014/12/01/how-to-make-your-code-self-documenting/

Dejan Angelov:
Experimental upgrading to Laravel 5 How I did it
November 24, 2014 @ 12:57:18

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.

0 comments voice your opinion now!
upgrade laravel5 framework change configuration code fix

Link: http://angelovdejan.me/2014/11/22/experimental-upgrading-to-laravel-5-how-i-did-it.html

NetTuts.com:
Refactoring Legacy Code - Part 11 The End?
October 27, 2014 @ 13:36:14

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).

0 comments voice your opinion now!
refactor legacy code part11 series end correctly answered

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-11-the-end--cms-22476

SitePoint Web Blog:
How to be a Good Developer
October 13, 2014 @ 11:54:17

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.

0 comments voice your opinion now!
good developer opinion professional code focus communication

Link: http://www.sitepoint.com/good-developer/


Community Events

Don't see your event here?
Let us know!


library version laravel php7 interview opinion podcast video release language introduction laravel5 unittest security community series voicesoftheelephpant framework example api

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework