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

Benjamin Eberlei:
Traits are Static Access
April 12, 2013 @ 11:16:35

In a new post to his site Benjamin Eberlei shares an opinion about traits, noting that they're basically the same as static functionality when it comes to several things like coupling, not being testable and being a "global state" container.

I used to look forward to traits as a feature in PHP 5.4, but after discussions with Kore I came to the conclusion that traits are nothing else than static access in disguise. They actually lead to the exact same code smells. Familiar with the outcome of too much static use, we should reject traits as just another way of statically coupling your code to other classes.

He includes some code examples showing traits in use in an example controller to handle a simple redirect. He points out at least six different issues with just this simple implementation. He rewrites it as "static" code to help prove his point. He comes to the conclusion that, much like static methods, traits should be avoided and instead aggregation should be favored.

0 comments voice your opinion now!
traits static compare avoid example code

Link: http://www.whitewashing.de/2013/04/12/traits_are_static_access.html

PHPMaster.com:
Avoid the Original MySQL Extension, Part 2
February 25, 2013 @ 13:40:09

PHPMaster.com has posted the second part of their "avoid the original MySQL extension" tutorial series (part one is here). In this new part, they share more about another alternative - the PDO extension.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

0 comments voice your opinion now!
mysql extension avoid pdo tutorial abstraction


Michael Nitschinger:
A Journey on Avoiding Nulls in PHP
February 20, 2013 @ 12:17:39

Michael Nitschinger has written up a post looking at avoiding nulls in your applications in favor of a better kind of value handling - the introduction of "Optional" handling.

While every developer has kind of accepted their existence, they are suddenly there when we'd desperately need them to not show up. How often did you writeif($obj === null) in your PHP code? Can't there be a better, more elegant and fault-tolerant solution to the problem?

His solution is to create a PHP version of this "Optional" functionality (via an abstract class) that allows some evaluation of the returned value from method calls on the object. Methods like "isPresent", "getOrElse", "of" and "fromNullable" make it easier to work with null values instead of just the triple-equals checking. He includes not only the code for the classes you'll need to implement it but examples of it in use - an "Optional" abstract class and two child classes, "Present" and "Absent".

0 comments voice your opinion now!
avoid null return value optional absent present evaluation tutorial


PHPMaster.com:
Avoid the Original MySQL Extension, Part 1
February 15, 2013 @ 11:13:29

On PHPMaster.com today there's a new post, the first in a series, about avoiding the original MySQL extension in favor of what mysqli has to offer. The cover some of the basics of the extension and include code showing its use.

Experienced developers eschew the original MySQL extension because of its abandoned status in PHP. Nascent web developers, however, may be completely oblivious to its dormant past and dying future. [...] It is therefore the intention of this two-part article to raise awareness among developers who still use the MySQL extension, inform them of its problems, and to help them switch over to an alternative extension.

They start with a brief look at the "what's wrong" with the MySQL extension (including its upcoming deprecation). The article then gets into the basics of MySQLi and how to do things like make a connection and run a few queries. There's also a bit about prepared statements and the built-in ability to do "multi-queries" (complete with rollbacks).

0 comments voice your opinion now!
mysql extension avoid mysqli introduction tutorial alternative


Paul Jones' Blog:
Interview Tip Avoid Mentioning PHP Frameworks
March 20, 2012 @ 09:26:19

Paul Jones has offered a tip he thinks will help you in future interviews for a software development position - don't mention frameworks.

If the job description does not mention "Framework X," you should probably avoid answering that you use "Framework X" to solve the problem presented to you by the interviewer. If I ask you to perform a simple task, such as parsing a string in a well-known format, saying "Framework X does that for me" is likely to be seen as a negative. You should be able to do the simple things in PHP itself (e.g. parsing strings).

He points out that, as someone currently in the interview process, he is frustrated by the fact that some developers rely so heavily on the functionality that frameworks give them that they don't know how to do some of the most basic tasks outside of them.

Saying that you use a feature of "Framework X" for simple things is a negative. It sounds like you're dependent on that framework for basic tasks. That means we (the employers) will need to train you how to do it without that framework, and that's a hassle for us.
0 comments voice your opinion now!
interview tip developer framework avoid knowledge


Johannes Schluter's Blog:
Do not use PHP references
January 11, 2010 @ 10:50:22

In a new post to his blog Johannes Schluter recommends that you don't use references in your applications, mostly because of some misconceptions about how they work.

Last year I spoke at eight conferences and attended a few more multiple times at most of them I found myself in discussions about references and PHP as many users seem to have wrong understandings about them. Before going to deep into the subject let's start with a quick reminder what references are and clear some confusion about objects which are "passed by reference."

He re-introduces referenced variables and scratches the surface about the confusion they can cause, not only on the user level but also in the internals of the language, and can lead to some unexpected results. He also mentions the "always passed by reference" idea that several PHPers have about PHP5 objects and why it's not entirely correct. He finishes off the post with a look at returning referenced parameters and how it can lead to bad application design.

0 comments voice your opinion now!
references avoid misconception


Jani Hartikainen's Blog:
Common programming errors and how to avoid them
October 08, 2009 @ 14:42:01

In a new post today Jani Hartikainen has pointed out a few errors that developers commonly make when writing and debugging their code.

Back in august, I introduced the error tracking challenge. While it didn't get as much participation as I had hoped for, I did manage to collect some results. In this post, I'll go through the most common ones, and suggest some approaches to avoiding them. Suggest your own errors and tips in the comments!

He's included issues in three major categories - boolean logic errors, typos/omissions and some common debugging mistakes. Inside each are some suggestions to help them make a less frequent appearance in your code: things like splitting up conditionals for readbility/ease of maintenance and being generally more careful in your development to reduce logic and small errors that could be picked up by the simplest syntax check.

0 comments voice your opinion now!
common error avoid opinion


Brandon Savage's Blog:
Avoiding Notices When to Use isset() and empty()
September 23, 2009 @ 08:47:13

If you've ever been bothered by those pesky NOTICEs when running your code, you know that you can wrap evaluations or check things with an empty or isset call to make them go away. Brandon Savage has a new post that can help you decide which one to use when, though.

As developers, we want to develop code that never emits notices or warnings, and PHP gets a bit antsy when we develop code that utilizes uninitialized variables. Lucky for us, PHP makes it easy to test for these variables without getting these notices. [...] PHP (like most languages) evaluates a logical argument left to right. For an AND condition, both conditions have to be true; PHP stops evaluating if it finds any condition untrue.

He suggests that the case to use isset() is more when you just want to use another check in the conditional but don't want to be bothered if the variable isn't there. A call to empty(), however, also evaluates the contents of the variable if it exists. Be careful, though - empty() returns false if the value of the variable is false - so take care in your use and always test scripts with multiple values.

0 comments voice your opinion now!
avoid notice tutorial isset empty


Lorna Mitchell's Blog:
Lame Excuses for Avoiding Conferences
September 22, 2009 @ 10:11:35

If you've ever wanted to go to a technology conference (there's several PHP ones out there!) but have talked yourself away from them with excuses, you might want to check this new post from Lorna Mitchell to see if any of them match up. She dispels some of the common misconceptions about attending conferences - five, to be exact.

I can quite appreciate that different people come to conferences for different reasons, but I cannot accept that people actively avoid conferences because they think its not for them - and the reasons for this, from people who have never been to a conference, are wild and varied. Most are based on misconceptions and I'd like to take the time to examine some of these.

She looks at some of the most common:

  • I won't know anyone
  • It's too expensive
  • My employer won't pay
  • I might have to talk to people/strangers
  • I haven't been to a conference

These along with a few other recommendations can rid you of some of the worries you might have over attending and maybe give you something new to talk to your manager about when the next conference rolls around.

0 comments voice your opinion now!
excuse avoid conference wrong


ThinkPHP Blog:
Silence of the LAMPs
September 16, 2009 @ 09:13:40

In a recent post to the ThinkPHP blog Martin Brotzeller looks at a PHP operator that developers should just not use anymore - the suppression operator (@).

The silence operator exists to give programmers an easy way to suppress messages when a command might fail and the code checks for success itself (i.e. in those cases that raise errors instead of throwing exceptions).

He points out a popular use (like putting it on an fopen to prevent it from throwing an E_WARNING) but notes that this could cause trouble if the code is several layers deep and seems to fail silently. He gives en example of the Zend_Loader component of the Zend Framework and how, if the suppression operator was used, errors with an include failed without so much as a blip in the error log. While it seems handy, the suppression operator can cause more harm than good in the long run.

0 comments voice your opinion now!
suppression operator avoid



Community Events





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


release configure application interview threedevsandamaybe series laravel framework bugfix podcast developer introduction wordpress community code library language list install api

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