Anna FilinaConference travel expenses (19.5.2015, 21:58 UTC)

Some conferences cover expenses of their speakers, other conferences don’t. Travel and accommodation can be extremely expensive and some speakers wonder why a conference would choose to put that burden on the speakers.

There are many ways to run a conference. I believe that all conference models are valid.

Ticket price

The price of a ticket directly affects what portion of the expenses organizers can afford to cover. Of course, organizing a conference can be very expensive, so even a high ticket price does not mean that there’s a big travel budget. These things can be very expensive. Coffee alone can cost in the five figures depending on the venue.

The higher the quality of the event, the higher the expenses. Where organizers choose to spend their money is entirely up to them. There is room for $5 conferences in universities that make you buy your own meal like there is room for $1000 conferences in 5-star hotels that serve warm lunch at your table. Every experience is unique and defines the event.

For-profit conferences would obviously like to make some money from it and there’s nothing immoral about this model. Some speakers may disagree and are welcome to leave their spot for those who are okay with that idea. I personally speak at such events now and then because I get tangible business opportunities from them.

Community

Different communities have different values. I wanted to invite a speaker once that asked $20,000 + business class flight for a keynote. That’s common practice in his industry and I respect that, although I can’t afford it.

Some communities strongly believe in the fact that everyone has to give back, which is why their speakers even pay their own conference ticket to come speak. As long as there will be speakers who would be okay with that, they will submit to these events and we can’t really judge them for that. If one day too many speakers decide that this model no longer suits them, they will submit elsewhere and the community will have to adapt.

Opportunities

Some event organizers spend a lot of money to create a strong brand and attract a valuable audience. They believe that to speak for them is rewarding enough. I can respect that too. Speaking at events with a high reputation can be good for one’s career. Some people are advanced enough in their careers that they no longer care for visibility. Remember: each event is organized differently and for a different purpose. It’s up to the speaker to decide whether they want to be a part of it.

What can speakers do?

If you’re a speaker and cannot afford to pay your own travel, I suggest that you inquire about speaker packages upfront. How much is the conference covering? Are there any prerequisites for that, such as giving multiple talks? Is the hotel also included? How many nights?

Some events will cover a percentage of the flight. Some events will propose financial aid for travel only if you ask. Some events will cover more expenses in exchange for more talks. Watch out: more than two talks can be a huge burden for the inexperienced. It is possible for events to get cancelled, so watch out for refund policies if you’re buying your own plane ticket.

What can organizers do?

Be clear about the rules. Don’t wait for people to ask for financial aid and just make clear rules that apply to everyone. I’d rather see everyone get a little less than a few people get everything. Asking for favours varies by culture and you may penalizing some people that way.

Sponsors can go a long way towards increasing your travel budget. It’s easier to find a single sponsor than finding multiple international speakers who are willing to pay their own flight.

Evangelists often have a travel budget with their company so ask them if their company can cover the expenses. A few companies who would say yes may enable you to bring more international speakers to your event.

If you can only afford to partially cover expenses, that works too. Many speakers are okay with splitting the costs, because they might want to take a vacation right after that. You can also ask them to give more talks. Three talks can be okay for experienced speakers but don’t push it. You don’t want to fill your conference with talks by exhausted people.

That’s it for today. Add more ideas in the comments below.

Link
Brandon SavageTake the summer session of The Object-Oriented PHP Masterclass (19.5.2015, 21:22 UTC)

A large number of people told me that they couldn’t make the February class of The Object-Oriented PHP Masterclass, and that they hoped I’d teach it again soon. Well, if you’re one of those people, I have great news for you: the Object Oriented PHP Masterclass is back, and registration is open! This class is […]

The post Take the summer session of The Object-Oriented PHP Masterclass appeared first on BrandonSavage.net.

Link
Paul M. JonesRadar: A PSR-7 Action-Domain-Responder Framework (19.5.2015, 15:00 UTC)

Radar is a PSR-7 compliant Action-Domain-Responder (ADR) system. While it may look like a micro-framework, it is more like a wrapper around the real core of your application domain. Its architecture makes it an excellent complement to Domain Driven Design.


Radar is superficially similar to a micro-framework. It has a routing system to point URLs to actions, a filter-style middleware system to modify the incoming HTTP request and outgoing HTTP response, and a dependency injection container and configuration system to wire everything together.

However, with Radar, you don’t specify “controllers” or “closures” for your routes. Instead, you specify up to three callables per route, all of which are optional:

  1. A Domain callable to be invoked with the user input. (If you don’t specify a Domain callable, the Responder will be invoked directly; this is unusual but sometimes convenient.)

  2. An Input callable to extract user input from the incoming HTTP ServerRequest. The default Radar Input callable will naively merge the route path attributes (path-info parameters), the query parameters ($_GET), the parsed body parameters ($_POST), and the uploaded files array ($_FILES) into a single associative array of user input.

  3. A Responder callable to convert the Domain output to an HTTP response. The default Radar Responder expects a Payload object from the Domain; it delivers JSON output and sets proper HTTP status codes for a wide range of scenarios.

These three callables are invoked within a standardized ActionHandler. As a result, the Action logic in Radar is always the same for every route. The only variations are in how input is collected, how output is presented, and of course in how your core application domain operates.

So, don’t think of Radar as a micro-framework. Think of it more like a wrapper around the core of your real application domain. Its only purpose is to guide input from the user into the domain, and to present output from the domain back to the user.

You can read the documentation for it here.

Link
Lorna MitchellPHP7: Easiest Upgrade Yet (19.5.2015, 09:22 UTC)

With PHP7 looking increasingly stable (relatively speaking, it's still pre-alpha so it's VERY early days and anything could happen!), and work going well on the GoPHP7-ext project to get extensions converted, I have been thinking about the migration guides we'll need to help people upgrade their existing applications. To this end, I took the simplest project I currently have (http://api.joind.in) and gave it a whirl on PHP7, using Rasmus' PHP7 dev box. The result:

<script async src="//platform.twitter.com/widgets.js" charset="utf-8">

All in all, it wasn't a great study of what kinds of things can go wrong when upgrading projects, because as far as I can tell with the test coverage that we have, it Just Works (TM).

I think the main reason for this success is that this project doesn't use many (any?) dependent libraries. Those libraries are catching up fast to PHP7 but you will probably need to update to the newest versions of everything prior to doing a PHP5 to PHP7 platform upgrade. If your project uses libraries that aren't already working on PHP7, check if they already have a branch for updates and use that in your testing (see also: Use a GitHub Branch as a Composer Dependency). If you can still break it, we love you!! Please immediately file a bug with a replication case and keep trying to break it if/when fixes are supplied. NB: this is open source, you may well need to fix things yourself.

So what kind of project will "Just Work" on PHP7?

  • Smaller codebases are more likely to upgrade without issues, they are also much easier to debug!
  • Older codebases are also likely to be fine! We're removing the PHP4 style constructor but the majority of those simple PHP4-style MVC applications will probably run fine on PHP7. It's the PHP 5.3 generation with lots of automagical things and huge full stack frameworks that will be a problem.
  • Code created with modern component frameworks and running on PHP 5.5 or PHP 5.6 will probably upgrade without much fuss
  • Projects with test coverage (unit tests, integration tests, all kinds of tests) will fare best, because it's much more likely that any issues will be found before it's a live environment problem.

After this failed experiment of what to look out for when upgrading a codebase, I'll be following up with my findings on other upgrades and sharing what to look out for. If you're starting to test how your code runs on PHP7, then I'd be interested to hear how you get on - please leave me a comment.

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

Link
PHP ClassesReview: PhoneGap 3.x Mobile Application Development Hotshot (19.5.2015, 09:05 UTC)
PhoneGap 3.x Mobile Application Development Hotshot
Title
Reviewer
Manuel Lemos
Category
Books about development tools
Publisher
Packt
Author
Kerri Shotts
Summary
If you are getting started with developing native mobile applications, PhoneGap (or Apache Cordova) is probably one of the most viable solutions to move on as quick as possible and release your application without great efforts to adapt it to each kind of device.

You will reuse your current knowledge of HTML, CSS, and JavaScript and the available frameworks that you already use for regular Web development.

So, unless you need very deep integration with the underlying mobile device platform, PhoneGap is one way to go.

The greatest thing about this book is that it teaches you how to solve each of the main types of mobile application problems that you will face in easy to understand manner.

Instead of teaching you about PhoneGap APIs directly, it shows how to solve common problems using real applications that you can try immediately and see it in action.

This is a very fortunate approach because most of us tend to learn better using real world examples that we can try in practice and tweak to see how you can adapt it to your needs.

Therefore this book is well recommended to all those that to not want to invest too much time and money learning how to develop native applications for Android or iOS using Java or Objective-C, when using the common Web technologies that you already know will do for your application needs.
Link
Evert PotPSR-7 released today (19.5.2015, 06:52 UTC)

Today PSR-7 got the 'accepted' state after quite a long journey. This is the result of the hard work of many people, but in particular Matthew Weier O'Phinney who did an amazing job herding cats with class.

Despite my concerns and my lone vote against the proposal, I'm excited to see this become the standard. It's long overdue and it's time for PHP to move on from its clumsy superglobals. I'm also very interested to see if my concerns around the immutability aspect of the objects turned out to be unfounded.

Further reading:

Link
Cal EvansInterview with Gary Hockin (19.5.2015, 05:00 UTC) Link
Matthew Weier O'PhinneyPSR-7 By Example (19.5.2015, 03:00 UTC)

PSR-7 is now accepted!!!

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.

First, though I want to clarify what PSR-7 is attempting.

HTTP Messages

HTTP messages are relatively simple, which is why the protocol has succeeded over the years. All messages have the following structure:


<message line>
Header: value
Another-Header: value

Message body

Headers are key/value pairs. The keys are case insensitive. Values are strings. The same header type may be emitted multiple times, in which case (typically) the values are considered as a list; in most cases, these can also be expressed by concatenating the values with comma delimiters.

The message body is a string, but typically handled by servers and clients as a stream in order to conserve memory and processing overhead. This is incredibly important when you transmit large data sets, and particularly when transmitting files. As an example, PHP natively represents the incoming request body as the stream php://input, and uses output buffers — a form of stream — to return a response.

The message line is what differentiates a request from a response.

The message line of a request is called the request line, and has the following format:


METHOD request-target HTTP/VERSION

METHOD indicates the operation requested: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD, etc. The VERSION is typically 1.0 or 1.1 (usually 1.1 in modern web clients). The request-target is where things get complex.

A request target can be one of four different forms:

  • origin-form, which is the path and query string (if present) of the URI.
  • absolute-form, which is an absolute URI.
  • authority-form, which is the authority portion of the uri (user-info, if present; host; and port, if non-standard).
  • asterisk-form, which is the string *.

Typically, an HTTP client will use the scheme and authority from a URI to make the connection to the HTTP server, and then pass an origin-form target in the transmitted HTTP request message. However, it's perfectly valid to send the absolute URI as well. authority-form is typically only used with CONNECT requests, which are usually performed when working with a proxy server. asterisk-form is used with OPTIONS requests to get general capabilities of a web server.

In short, there's a lot of moving parts in the request-target.

Now, to make things more complicated, when we look at URIs, we have the following:


<scheme>://<authority>[/<path>][?<query string>]

The scheme, when doing HTTP requests, will be one of http or https. The path is a well-known format as well. But what about authority?

[user-info@]host[:port]

The authority always contains the host, which can be a domain name or an IP address. The port is optional, and only needs to be included if it's non-standard for the current scheme (or if the scheme is unknown). user-info is of the form:

user[:pass]

where password is optional. In fact, in current specifications, the recommendation is to never include the password in a URI, to force prompting for the value by the client.

The query string is a set of key-value pairs delimited by ampersands:

?foo=bar&baz&quz=1

Depending on the language implementation, it can also model lists and hashes:

?sort[]=ASC&sort[]=date&filter[product]=name

PHP will parse the above to:


[
    'sort' => [
        'ASC',
        'date'
    ],
    'filter' => [
        'product' => 'name'
    ],
]

So, as if the request-target was not complex enough, URIs also present a fair amount of moving parts!

Fortunately, responses are simpler. The response line looks like this:

HTTP/VERSION <status>[ <reason>]

Truncated by Planet PHP, read more at the original (another 28981 bytes)

Link
Matthew Weier O'PhinneyPSR-7 Accepted! (19.5.2015, 03:00 UTC)

I'm pleased to announce that as of 22:00 CDT on 18 May 2015, http://www.php-fig.org/psr/psr-7 PSR-7 (HTTP Message Interfaces) has been accepted!

The road to PSR-7

The road to PSR-7 was a long and winding one. It started in summer of 2012 as a draft proposal on HTTP clients by Benjamin Eberlei, during which others proposed that perhaps a smaller standard on the HTTP message interfaces themselves — which would also allow targeting server-side applications, as those rely on the messages.

At that point, Chris Wilkinson picked up the ball and created the formal draft that became PSR-7. In it, he developed the original HTTP message interfaces. During his tenure as editor, he also started drafting a related proposal on URIs, but this was never picked up as a PSR. PSR-7 was polished significantly during his tenure, particularly in the aspect of keeping headers as part of the message, and having a MessageInterface describing the commonalities between the two message types, with differentiators being in the request and response descriptions.

At a certain point (I'm not sure when, as I've still not found any formal announcement in the group archives), the baton was handed over to Michael Dowling. His big addition to the proposal was modeling the message body as a stream. This has been fairly controversial from its introduction, and prompted a lengthy blogpost in summer 2014 detailing the why. I feel this was a stellar decision. Every language I've surveyed that has first-class HTTP abstractions has modeled the message bodies as streams: doing so allows for async operations in many languages (though not natively in PHP for a bit longer, alas), but also ensures that large messages do not eat your available memory. PHP itself models message bodies as streams (php://input and the output buffer are examples), so modeling them this way is a natural fit.

Shortly after that blog post was written, I was playing heavily with node.js, and was immediately struck by how uniform various modules were in terms of handling HTTP. This was in large part due to Node having a built-in, well designed (mostly!) HTTP abstraction. The other part was a side effect of that: middleware essentially arises naturally in the language due to that abstraction, meaning that middleware is abundant and works pretty much anywhere you're writing web-facing applications.

I decided to port Connect, the middleware library that gave rise to Express, the arguably dominant node web framework, to PHP. In doing so, I had one huge hurdle to jump immediately: HTTP abstraction.

Sure, every framework has an HTTP abstraction. I even contribute to one in Zend Framework. But my thought process was: I want to expose as many PHP developers to these concepts as possible, but my choice of HTTP abstraction might end up raising tribal flags. And then I remembered seeing Michael's post on PSR-7 streams and thought, "maybe I should target PSR-7!"

The problem was there was no implementation yet.

So, I put together an implementation over a weekend, and went to the list with it. About two days after Michael posted saying he was going to abandon PSR-7 due to time constraints.

After a few weeks of discussion and heavy thinking, I decided to pick it up and try to move it forward. Phil Sturgeon and Beau Simensen agreed to continue as sponsor and coordinator, respectively, and so my tenure as editor began.

This has been an interesting journey for me. When I started, there were still debates about using streams; I had to quickly ramp up on the spec and Michael's arguments, and see if I agreed with them (I did), and, better, if I could defend them (I could).

I discovered there was another aspect I felt needed to be addressed though: the messages worked great for client-side aspects, but fell short for server-side: users were left to parse the URI for query string arguments, and to parse the body manually, and headers for cookies, and... well, this is where the "mostly" came in with Node: you end up having to do a lot of stuff yourself, or rely on a microframework for that stuff. I felt we could do better. Thus, the ServerRequestInterface was born, providing access to the data we take for granted in PHP's superglobals, but also providing some necessary abstraction f

Truncated by Planet PHP, read more at the original (another 3312 bytes)

Link
SitePoint PHPYouTube Videos in PHP: Categories, Search and Suggestions (18.5.2015, 16:00 UTC)

This entry is part 2 of 2 in the series How to Build a YouTube API App with LaravelIn the first part, we introduced the YouTube API and built a small demo to list the most popular videos on YouTube. In this part, we will extend our application to have search functionality, and we’ll also […]

Continue reading %YouTube Videos in PHP: Categories, Search and Suggestions%

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP