On the Laravel News site there's a new post covering a new feature in Marcel Pociot's "Building a Chatbot" series (that makes use of the Botman package). This latest addition, a playground for testing and debugging bots allows you to get up and running without having to set up a complete environment.

Marcel Pociot recently launched a course called “Build A Chatbot,” a step-by-step video course on developing, extending, and testing Chatbots and Voicebots. Marcel is the author of Botman, a PHP chatbot framework for building chatbots.

Along with his Build a Chatbot course, Marcel launched Botman Playground, which provides a quick way to get started building and debugging chatbots without setting up a local development environment.

The playground allows you to set up a new bot, add commands and test the result with an included widget, all in-browser. The playground also allows you to set up connections to external services like Facebook, Telegram and Cisco Spark. The only catch is that you must be signed up for Marcel's Build a Chatbot course to gain access.

Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

On SitePoint's PHP blog Taylor Ren has posted the second part of his series looking at integrating Polymer/Dart and the Symfony framework to make a simple browser-based widget. The first part of the series can be found here.

If the server (and thus the configuration, the programming) is managed by ourselves, the process to get data from a RESTful API from that same server will be simple. We can enable CORS in the returned response header. Done! But if the remote server's RESTful API does not set that header, we will face a CORS error when we try to invoke that API call from within the Dart app.

He offers one solution - JSONP - but dismisses it because of its "hacky nature". Instead he opts to use the PHP (Symfony) side to grab the data from the remote feeds and pull it into the local domain for the widget to fetch. Code for both the client side and server side functionality are included as well as the HTML markup to create the page for the widget.

Jan Bodnar has pointed out a great PHP-GTK tutorial on ZetaCode.com that walks you through some of the major points of this graphical frontend for PHP:

This tutorial will teach you the basics of GUI programming with the PHP GTK. The tutorial has 8 chapters which cover the first steps with the library, menus, toolbars, dialogs and various widgets. It has some examples for drawing with Cairo library. The final chapter presents a small computer game; The Nibbles.

Each of the topics has sample code and screenshots of the resulting output for each. Also included is information on layouts and "painting" with Cairo - drawing shapes, rectangles, text, etc.

The SitePoint PHP blog has part three of their "create your own Twitter widget" series posted today. This is the last post of the series and involves a little cleanup on the data pulled from the Twitter API.

In part 1 of this series, we examined the Twitter API, created a PHP TwitterStatus class, and imported the latest tweets in JSON format. In Part 2, we parsed the Twitter data, replaced links, and generated the complete HTML for our widget. In this last post, we’ll cache our widget and translate tweet dates into a friendlier format - download the full source code here.

They talk about caching the data pulled back from the API (making it faster and less resource-intensive) and how to parse the dates that you get back from the request using the DateTime functionality included with PHP.

On the SitePoint PHP blog today Craig Buckler is back with the second part of their series on creating a Twitter widget for your site. You can find more about the first part of the series here.

In Part 1 of this series, we examined the Twitter API, creating a PHP TwitterStatus class, and imported the latest tweets in JSON format. Today, we’ll populate the data into HTML templates - download the full source code here.

The templates are strings of HTML with tags for where the content belongs - in this case things like "{TWEETS}" and "{profile_image_url}". Regular expressions are used to parse the templates and a str_replace used to make the substitution. The final product is included showing a few example tweets with some parsed links inside each.

From the SitePoint PHP blog today there's a new tutorial from Craig Buckler (part one of a series) on how to create your own Twitter widget you can drop in anywhere on your site (main content or sidebar). It uses cURL to make the requests to the Twitter servers, so you'll need that installed on your PHP instance.

Because you can! Your own widget will always be more customizable than any off-the-shelf solution, and you’ll be the envy of your peers. We’ve also been asked by several readers for articles about the topic, and it’s a great introduction to PHP, REST APIs, JSON, regular expressions and Object Orientated Programming.

In this first part of the series, he helps you set up the class to connect to the Twitter services and fetch the latest statuses for the SitePoint account (obviously, you can substitute yours in its place) and some of the basics like templating and caching. The script uses the REST API since it only needs to fetch, so there's no messing around with the OpenID authentication the Twitter API now requires. You can also download the source for the code that'll be generated during the series.

Matthew Weier O'Phinney has a new post to his blog today showing you how to use action helpers to make widgets that you can reuse all over your Zend Framework application. His method doesn't use the "action()" helper, either.

The situation all started when Andries tweeted asking about what he considered some mis-behavior on the part of the action() view helper -- a situation that turned out not to be an issue, per se, but more a case of bad architecture within Zend Framework. [...] The helper was done this way because Zend Framework does not render views a single time -- it instead renders after each action, and accumulates views to render in the layout.

Instead, he offers action helpers as a solution. He gives an example of a user module that has views, helpers and forms but no controllers, including a Bootstrap file. This bootstrap defines the helpers, configuration file and adds the helpers into the process flow of the application. Once things are all set up and the action helper is created, adding the module to a page is as easy as calling "createProfileWidget()" into a partial view.

On NETTUTS.com a tutorial has been posted recently showing you how to build a widget for Buzz, the Google's service similar to Twitter. If you've ever worked with the Twitter timeline concept, using Buzz will feel very familiar. Unfortunately, for the moment at least, it's a read-only kind of thing.

At the moment, there’s no API to work with the Buzz service; Google is expected to provide one within the next several months, however, for now, the public updates are available as Atom feeds.

They grab these Atom feeds via a proxy PHP script (can't cross-domain with Ajax, after all) and then some Ajax to real the latest from this proxy. The results are displayed in a (very familiar looking) timeline with the help of the included HTML and CSS/images. The last part of the process is to push it into a jQuery plugin for easier use down the line. You can get the source download here and check out a demo online.

On PHPBuilder.com today there's a new tutorial walking you through the creation of a simple WordPress plugin that shows the latest YouTube video from your blog's channel.

Think of plugins as components where you put your functionality and widgets as components of your user interface. Building your own WordPress plugins and widgets will make your blog truly original, and all you need is basic PHP and HTML knowledge - and your imagination.

They help you get started with defining a few constants, registering the actions with WordPress, building the widget (with complete cut-and-paste-able code) and including it in your WordPress blog. You can download the complete source if you want to get started quickly.