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
SitePoint PHP7 Mobile UX Mistakes You’re Probably Making Right Now (25.5.2015, 15:00 UTC)

Making changes on mobile UX can be a tricky process, especially if you come from a web background. In mobile, developers have more constraints, including screen real estate, attention times, and UI control limitations. Improving the mobile experience is always a learning process full of trial and error, so this list will get you on the right track by helping you steer clear of common pitfalls.

Mistake #1. Assuming your users need to sign in

Everyone knows there are a ton of benefits to having users sign in, yet it's also a significant pain point for your users. Who doesn't get impatient having to type in the same personal data hundreds and hundreds of time for each app or service?

Most apps' solutions are to allow users to temporarily skip registration so that they can try out the app and get a sense of value.

While this method works well enough for Apple to adopt it into their User Experience Guidelines, cutting the funnel even further can have huge benefits. If registration is a pain point, why not see what happens when you remove that pain entirely?

HotelTonight, a hotel booking app, used A/B testing to create a variant where users could complete the transaction without having to create a dedicated account. Previously all users had to sign in before completing a booking.

They tracked the bounce rate, as well as completed transactions, and found that discovered that making sign-ins optional actually increased bookings by 15%.

To encourage users to sign up still, they're given the option to sign up in order to save their data to make future bookings even more painless and quick.

HotelTonight significantly decreased friction by removing a common pain point needed to generate value, then incentivized users to address those same pain points by giving them additional incentive to do so. Removing sign ins turned out to be a great decision for the app, as they were able to improve their bottom line.

Mistake #2. Assuming you need to bombard users with "value"

Two of the most common recommendations for app optimization are to include onboarding tutorials, and allow users to skip registration. Each of these is supposed to give users a great sense of value for an app, making sure they know all they can do with your app, and what they'll get out of it.

Even though these techniques can typically increase sign ins and engagements, Vevo wanted to see if removing them could possibly increase their KPIs. They hypothesized that removing tutorials would increase the amount of users that logged in and signed up.

After testing two variants: one with and one without, the results were clear. Without tutorials, 10% more users logged in, and 6% more signed up.

Vevo believed that the tutorial was unnecessary because they have enough of a brand that most users who download the app are familiar with the core value proposition of the app. They didn't need convincing.

Instead, users simply wanted to get started watching music videos as soon as possible, and the tutorial only proved to be a hinderance. Their new flow gives 2 sets of simple instructions, and off you go.

Trying to convince users of possible value through a tutorial can impede them from getting to the actual value in an app. Be sure that your app isn't doing the same.

Mistake #3. Copying other app experiences

The above two blunders come from implementing generally accepted good practices without questioning if they could be improved. While online advice is generally a good starting point, each app and product is unique in their goals, audience, value, functionality, etc. What works for someone else doesn't mean it will automatically have the same effects for you.

Instead of implementing example tests found online, draw your ideas from customer feedback. Create surveys, read reviews, and gather as much qualitative data as you can as to what users would like to see changed. Using that data, create new test ideas specific to your app, then use A/B testing to determine their effects on your audience.

Instead of just following in other's footsteps, teams should strive to use A/B testing as a powerful tool to gain quantitative data about whether a change improves your KPIs or decreases them.

Mistake #4. Underestimating how long it can take to update a mobile app

It's easy to forget how much longer any change on mobile takes when compared to web. On the web, information is stored on company controlled servers so making changes is a breeze. If a mistake is pushed in

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

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
SitePoint PHPCRUD (Create Read Update Delete) in a Laravel App (22.5.2015, 16:00 UTC)

In the previous part, we’ve bootstrapped our Laravel CRUD application by creating the database, some controllers, basic routes and simple views. In this part, we’ll wrap things up and implement proper CRUD.

Laravel Logo

If you’d like to follow along through this interactive walk through Laravel’s docs, please catch up by reading the first part now.

Creating A Record

Continuing right where we left off, let’s create the page where we’ll actually perform this action. In our TasksController, let’s return a view like this:

public function create()
{
    return view('tasks.create');
}

And now, in our views directory, let’s create tasks/create.blade.php, and enter some starter content:

@extends('layouts.master')

@section('content')


Add a New Task</</span>h1><</span>p class="lead">Add to your task list below.</</span>p>


Continue reading %CRUD (Create Read Update Delete) in a Laravel App%

@stop

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