Lorna MitchellRecover Bitly Bundle Data (26.5.2015, 14:57 UTC)

For some years I've been creating a bundle of links covering articles I recommend for various topics in the Zend Certified Engineer Exam (if you can here looking for the bundle itself, it's at http://www.lornajane.net/zce-links-collection). This was done using bitly's bundles feature, which I thought was a great way to share links. In fact I had 10-15 bundles that I had created from collating all the links in a particular training course or talk, so that people didn't have to try to write down URLs as I went along. Unfortunately they sunset their bundles and then removed them completely, and I missed the announcement (it all happened quite quickly, they'd seen some abuse of the feature, it's free, all totally reasonable) BUT they also didn't respond to my support questions about how to recover the data.

It turns out, it's an undocumented feature on their API, so here is everything I know about recovering your bundle data, including the script I used to rescue my own data.

Bundle Data Via API

The endpoint you want is /v3/user/link_history and the documentation is here: http://dev.bitly.com/user_info.html#v3_user_link_history. Many MANY thanks to @jehiah for tweeting this information at me, it was a huge help! What they omitted to mention is that you'll also find a "tags" array in the values for each link as well (I assume the documentation will update really soon).

Bitly also has an API browser so you may be able to get your data out through that without needing code. I'm a programmer though so I wrote a script ...

Bitly Bundle Rescue Script

Here's my scratty script to export data. You need to do 3 things to use this:

  1. Add guzzlehttp/guzzle to your composer.json file and install it
  2. Use the instructions in the comment at the top to get your access token (or use the bitly web interface https://bitly.com/a/oauth_apps)
  3. Look around line 55 and comment/uncomment as appropriate depending on whether you want a CSV export or an HTML output
<?php

require "vendor/autoload.php";
/*
 * To request access token:
 * curl -u "username:password" -X POST "https://api-ssl.bitly.com/oauth/access_token"
 *
 * Composer: composer require "guzzlehttp/guzzle": "~5.3"
 */

$access_token = 'GenerateYourOwn';

$client = new GuzzleHttp\Client();
$offset = 0;
$limit = 100;


while(true) {
    $response = $client->get('https://api-ssl.bitly.com/v3/user/link_history',
        ["query" => [
            'access_token' => $access_token,
            'limit' => $limit,
            'offset' => $offset,
        ]]);
    if($response->getStatusCode() == 200) {
        $responseData = json_decode($response->getBody(), true);
      

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

Link
Paul M. JonesRadar: Answering Questions, and New Middleware (26.5.2015, 13:23 UTC)

Last week’s announcement of Radar, an implementation of Action-Domain-Responder using PSR-7, was a resounding success. The feedback has been mostly positive, with some confusion and misunderstanding, and with one particular question being raised more than once.

This Reddit thread is typical of the various questions and comments I’ve received so far:

[“ADR” is just] the hipster slang for ‘c’, ‘m’ and ‘v’.

In other words, “Why ADR in the first place, and not just MVC?” This is answered by the ADR white paper, and again by some commentary here. In short, ADR is a refinement of “web” MVC to more accurately describe how we actually work in a request/response environment. The renaming of the components is intended to break the association with “real” MVC. (Special thanks to “lordofworms” for his patient and civil responses to the questioner.)

Why [is the project called] “Radar”?

As noted in the Reddit thread by others, “Radar” is a sound-alike from the ADR acronym. (An early version of the ADR paper was titled Request-Action-Domain-Response, the acronym for which lends itself even more to “Radar”, and I had that in mind too.)

why use classes at all? If most of your classes contain a single __invoke method, could they not just be substituted with namespaced functions?

The questioner was answered quite thoroughly on Twitter. I will add only that there’s nothing about ADR that says you must use classes. If you can implement ADR using all functions all the time, go for it. ADR is a pattern, not an implementation; Radar is an implementation, not a pattern.

Finally, we have this very good criticism referring to the middleware implementation:

Passing arguments by reference will confuse users.

Variations on this theme came up elsewhere as well. As a result, I have re-worked the middleware implementation completely.

Previously, Radar used a “filter” style of middleware, where an iterator calls each middleware handler in turn at different points in the execution path. This is the style used by Slim 2 and Silex, and works well with globally mutable request and response objects.

However, PSR-7 requests and response are immutable. I have not previously used immutables very much, and I tried to subvert the immutability by allowing middleware to use reference parameters. The references would make the request and response objects appear globally mutable, even though the objects were in fact immutable.

The critics who noted that this was potentially confusing, as well as a subversion of the immutable intent, turned out to be worth listening to. I experimented a bit with a wrapper-style (or chain-style) of middleware, and I’m much happier with it.

In the new implementation, each middleware calls the next one in turn, instead of an external iterator looping over them. (There is a Dispatcher object that “holds” the queue of handlers, and that it what gets passed to each handler for its $next call.) I got the idea from reading MWOP’s Conduit code, although this is greatly pared down from that. You can read more about the new implementation here.

Link
Ben RamseyWebsite Redesign (26.5.2015, 13:00 UTC)

Welcome to my brand new website! I’ve worked hard to make this site, and I hope you like it.

My blog has been around since 2004. My first blog post was written about the PHP Community project. Back then, I used Movable Type as my blogging engine. WordPress was still young, having only recently been forked from b2. A few months later, I did switch to WordPress, and then many years after that, I decided to use a static site generator, so I switched to Octopress.

Why Redesign?

There were several things that prompted my desire to redesign this website:

For one, I was inspired by the branding efforts of Yitzchok Willroth, Chris Hartjes, and Chris Shiflett, and I wanted a personal web presence that would better communicate who I am and what I do.

Second, I wanted a project that would take me back to my web development roots, and I felt that developing a personal website with all the bells and whistles would do just that. Through this process, I’ve been able to learn more about HTML5 and CSS3, as well as responsive website development.

Last, I wanted to encourage and inspire others to follow suit. A decade ago, most web thought leadership conversations took place across blogs, and from blogs, leaders innovated and led the development of the Open Web. However, since the advent of closed, microblogging platforms, many (myself included) have left their blogs behind in the dust, and I feel we’ve lost some of that innovation and openness. This redesign represents the beginning of my return to the ideals of the Open Web.

/Purpose

Why do you do what you do? I am a web developer because I believe the web has the power to change the world. It is the biggest communications tool of our time, and it has the greatest power to effect change—if used appropriately. I have a passion for teaching web development because I want to encourage others to use these skills to change the world for good.

I have been inspired by my friends at Fictive Kin to create a /purpose (Slash Purpose) page, and I encourage you to think about why you do what you do and create your own /purpose page. Let it drive all that you do.

Here is my /purpose page.

IndieWeb Movement

Through Chris Shiflett, I found out about the Indie Web movement. Almost immediately, I felt a kinship with this community. I’ve already mentioned the Open Web philosophy. The Indie Web movement seems to be taking steps in this direction. I have followed their “Getting Started” guide to mark up my website with authorship information (h-card) and microformats mark-up for blog posts and articles (h-entry). This means my site content is easy to scrape, and it provides good identity information about myself that machines can read.

Chris has written a little about some of the practical applications of IndieAuth. I’m sure he’ll write more, so I encourage you to follow along.

Focus on Content

Previous versions of my website included only my blog and did not focus on my talks, articles, books, or projects. It is important to me to showcase this content, and so this new version of my site includes these and more. Just take a look under the Features navigation link up top, or follow these links:

Blog
I write about web development and related technologies in my blog. Usually, it has somethi

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

Link
PHP ClassesReview: Build APIs You Won't Hate (26.5.2015, 05:51 UTC)
Build APIs You Won't Hate
Title
Reviewer
Dave Smith
Category
Web development books
Publisher
Leanpub
Author
Phil Sturgeon
Summary
So you want to build an API, or perhaps your boss is making you since you are the IT person? If you want to build one that you, or your boss, won't hate, then this is the book for you.

Navigating the world of network services can be a daunting task for the uninitiated. This publication, Build API's You Won't Hate, gives clear and detailed instructions on how to build a REST compliant API, start to finish, and guides you through the pitfalls you should avoid. I would recommend it for any API developer at any level.

If you prefer reading it in your mother language, the good news is that at the time of this writing, the book is already translated into Portuguese, Turkish, Italian and French.
Link
Cal EvansInterview with Joe Ferguson (26.5.2015, 05:00 UTC) Link
SitePoint PHPMastering Composer – Tips and Tricks (25.5.2015, 16:00 UTC)

Composer has revolutionized package management in PHP. It upped the reusability game and helped PHP developers all over the world generate framework agnostic, fully shareable code. But few people ever go beyond the basics, so this post will cover some useful tips and tricks.

Global

Although it’s clearly defined in the documentation, Composer can (and in most cases should) be installed globally. Global installation means that instead of typing out

php composer.phar somecommand

you can just type out

composer somecommand

Continue reading %Mastering Composer – Tips and Tricks%

Link
Davey Shafik[SLIDES] Writing Faster PHP with HHVM and Hack (25.5.2015, 11:17 UTC)
Link
PHP ClassesPHP Multi-Factor Authentication for Web Development (25.5.2015, 07:35 UTC)
By Dave Smith
When we need to provide our users access only to certain information, or limit access to features for authorized users only, we need to use user authentication.

We can never be 100% certain users are who they claim to be. However we can get close using multiple authentication factors.

Read this article to learn more about multi-factor authentication and when we should use them or not.
Link
Davey Shafik[Slides] What to Expect When You’re Expecting: PHP 7 (phpDay 2015) (23.5.2015, 21:07 UTC)
Link
Ben RamseyMy Failed Attempts at Soft Skills Talks (23.5.2015, 20:30 UTC)

During the Development Hell podcast recording at php[tek] (not yet released at the time of this writing), Chris and Ed discussed soft skills talks with Yitzchok Willroth (@coderabbi). Soft skills are those skills that aren’t necessarily technical in nature—things like interpersonal communication, time management, managing teams, leadership, etc. They’re critical to our jobs, but we often see them as secondary to our technical skills. In fact, they are not soft at all—they’re rather difficult to master, which is why it’s important that we talk about them at conferences and write about them on our blogs and in our trade journals.

At the podcast, I tried to elucidate a sentiment that’s been on my mind for some time, but it came out as rambling nonsense. I’m sorry. Here’s what I was trying to get at.

I’ve been a conference speaker for many years. For a few recent years, I ramped down my speaking and took some time off from conferences to focus on my work, and as I started to ramp things back up, I tried to assess my options and how I wanted to position myself. I assumed the next step for a seasoned speaker should be to start positioning myself for keynote opportunities.

I’ve always given very technical talks, and I’ve observed that keynotes are usually non-technical and focused on ideas, concepts, and soft skills, usually filled with personal anecdotes and inspirational stories. So, I set out to craft some talks that would help take me on a new direction in my speaking career.

In 2013, I made my comeback appearance at CoderFaire Atlanta, where I was invited to give the conference keynote. This was supposed to be my shining moment as a keynote speaker to elaborate on the “Debugging Zen” article I had written for Web Advent. The keynote was entitled “Developing Intuition: How to Think Like a Software Architect.” I shifted the focus away from debugging and told my story of how I came to be a software developer and the heavy role intuition has played in my career. I think the talk resonated for about half of the audience. The other half probably thought it was a bunch of hokey gibberish.

I spoke at php[tek] a little later that year, after having taken three years off from speaking there. I gave a presentation entitled “API First.” This was another soft talk (with a little bit of technical detail thrown in), building on my experiences developing and deploying APIs. In it, I talked about how to approach your managers and company leadership to convince them of taking an API-first approach to web application development. It was well-received and I saw a lot of great feedback, but it was not easy to prepare. I gave it again at ZendCon later that year. Again, I received high marks and good feedback, but it felt lacking in a certain kind of energy and levity. After the intuition talk at CoderFaire, I realized that I’m not good at telling stories or relating anecdotes, and that was evident here, as well.

That same year, Eli asked me to put together the closing talk for php[architect]’s PHP 5.5 Web Summit. He wanted me to talk about modern PHP development, so I decided to turn it into an observation of how best practices have arisen in the community over the years. I gave the talk many times over the following year, but it always had mixed reviews. On one side were the community old-timers with whom the historical look-back resonated. On the other hand were folks newer to the community who criticized the talk as a bunch of nostalgic navel-gazing and were expecting a different kind of talk.

I made one more attempt at a soft talk. Again, I refined my “Debugging Zen” article into its own talk, discussing the role intuition plays for me in the art of debugging and how others can tap into their own intuition to be better software developers. At the Madison PHP Conference, where I first presented it, I gave it to a crowded room and received many encouraging

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

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