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

SitePoint PHP Blog:
API Client TDD with Mocked Responses
February 19, 2015 @ 12:57:51

The SitePoint PHP blog has posted the third part of their series guiding you through the creation of your first PHP package with a look at mocking API responses in unit tests created via the TDD (test-driven development) process.

In parts one and two, we built some very basic functionality and used TDD with PHPUnit to make sure our classes are well tested. We also learned how to test an abstract class in order to make sure its concrete methods worked. Now, let's continue building our library.

He starts with a bit of catching up to ensure everyone is on the same page in the development process. From there he starts in on the mocking of the API, preventing the need for the (slow) external requests. He shows some updates that are needed to the main DiffBot class, the factories/entities for making objects for requests and examples of putting these to use in a few tests. Finally he shows the creation of the mocks themselves and the result from a sample test.

0 comments voice your opinion now!
mock response tutorial unittest testdrivendevelopment api client

Link: http://www.sitepoint.com/api-client-tdd-mocked-responses/

Matthew Weier O'Phinney:
PSR-7 By Example
January 29, 2015 @ 09:13:20

As a part of his involvement in the PHP-FIG standards group, Matthew Weier O'Phinney has been contributing to the PSR-7 proposal. This proposal defines a standardized structure for HTTP message handling. In his latest post he gets into a bit more detail on what this means for the PHP developer and how it might be implemented.

PSR-7 is shaping up nicely. I pushed some updates earlier this week, and we tagged 0.6.0 of the http-message package last week for implementors and potential users to start coding against. I'm still hearing some grumbles both of "simplify!" and "not far enough!" so I'm writing this posts to demonstrate usage of the currently published interfaces, and to illustrate both the ease of use and the completeness and robustness they offer.

He starts with a base definition of what the proposal, well, proposes around HTTP messaging, both the incoming and outgoing. He describes the basic structure of an HTTP message and what each part represents. He talks about message headers, bodies and how the current library could return that content. He then looks at requests vs responses, server-side requests and some various uses cases and more practical examples:

  • HTTP Clients
  • Middleware
  • Frameworks

With the PSR-7 standard in place, all of these different tools could have interchangeable interfaces for HTTP request/responses, easily swappable with any other implementation.

0 comments voice your opinion now!
psr7 http message request response summary tool framework middleware client

Link: https://mwop.net/blog/2015-01-26-psr-7-by-example.html

Anthony Ferrara:
A Point On MVC And Architecture
December 02, 2014 @ 12:10:24

Anthony Ferrara has posted another in his series looking at MVC as a design pattern and as an idea for building web applications. In this latest post he goes on to make a point about MVC, how it relates to architecture and CRUD.

Last week I post a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I'm still working on it. It's a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

He responds to the comment (essentially that CRUD is a solved problem) and where the need for customizations is needed. He suggests what the real problem is, though: the three classes of developers - CMS users, custom developers and users of both.

0 comments voice your opinion now!
mvc architecture opinion problem crud comment response

Link: http://blog.ircmaxell.com/2014/12/a-point-on-mvc-and-architecture.html

Phil Sturgeon:
Is PSR-0 Shortsighted, or are you?
April 17, 2013 @ 09:14:42

In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.
0 comments voice your opinion now!
psr0 autoload opinion response phpfig composer

Link: http://philsturgeon.co.uk/blog/2013/04/is-psr0-shortsighted-or-are-you

NetTuts.com:
HTTP The Protocol Every Web Developer Must Know - Part 1
April 09, 2013 @ 10:56:28

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

0 comments voice your opinion now!
http protocol series basics headers statuscode verb request response

Link: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/

Hari KT:
Aura.Http Request and Response
February 18, 2013 @ 11:49:58

On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

0 comments voice your opinion now!
aura project framework http request response tutorial


Lorna Mitchell:
How NOT to Design Your API
January 10, 2013 @ 10:46:04

Recently Lorna Mitchell asked the wide world of Twitter about some of their recommendations of things not to do when creating an API. In this new post to her site, she gathers together those responses including comments about documentation, consistency and response codes.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

  • Response codes not matching the content (ex. 200 on an error)
  • NullPointerExceptions
  • Different endpoints for single vs collections
  • Order-sensitive XML in requests
  • Poor error handling
  • Bad documentation
  • Incorrect content type handling
So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.
0 comments voice your opinion now!
api design response code error handling documentation opinion twitter


Phil Sturgeon:
Arguing on the Internet
December 28, 2012 @ 10:51:39

In his latest post Phil Sturgeon shares some thoughts in response to this article from Shawn McCool about the "death of CodeIgniter", citing a few specific points.

I have referenced Shawn McCool's blog a few times, "Why CodeIgniter is Dead" and people are wondering why I argued so hard against it back in May but then gave CodeIgniter such a hard time in my last article. For the record I'm not team CodeIgniter or team Laravel, I'm a PHP user who has some opinions, and some of those opinions change over time - which is fair enough.

He goes through several of Shawn's points including:

  • Comments about best practices in CI (or lack of)
  • Modularity/design pattern use
  • The implementation of modules/sparks
  • The community contributions to the Reactor project
  • Dropping PHP4 support

Phil also notes that, just because something isn't making significant progress, it doesn't mean it's dead in the water:

Dead insinuates being closed right down. Repo removed, or just nothing is ever tagged again. Where CodeIgniter sits is closer to Smarty. Smarty is still active and has it's last stable release 2 months ago. It just hasn't changed much in years and probably never will.
0 comments voice your opinion now!
codeigniter opinion project response framework


Paul Jones:
A Response To "On php-fig and Shared Interfaces"
December 24, 2012 @ 12:54:57

Paul Jones has written up a response to Matthew Weier O'Phinney's recent post on shared interfaces and the PHP-FIG. In it he talks about the PHP-FIG group itself and specific references back to the original post.

He mentions the ideas of "new thinking" and the limitations that standardized interfaces might try to impose on an application:

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land. Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

Matthew Weier O'Phinney responded with some of his own comments and correcting some of the misinterpretation of his original comments.

0 comments voice your opinion now!
phpfig shared interface response comment


DevShed Forums:
PHP is a fractal of bad design? Hardly.
August 29, 2012 @ 09:41:55

A while back there was an article that put a negative spin on PHP ("PHP: a fractal of bad design") and there was a huge community response to it with over 1400 comments on the post itself. Over on the DevShed forums, there's a lengthy new post that goes back over that article, piece by piece, and evaluates everything that was said.

As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

He goes back through each of the sections - Stance, Arguments, Philosophy, etc - and includes quotes from the articles and his own impressions/thoughts about them. There's a section covering some of the individual complaints that were mentioned and things like PHP's OOP model and security.

0 comments voice your opinion now!
opinion forum response article bad design



Community Events

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


unittest version laravel podcast symfony framework threedevsandamaybe library series interview introduction language api opinion release security voicesoftheelephpant extension community laravel5

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