SitePoint PHPWriting PHP Git Hooks with Static Review (31.8.2015, 16:00 UTC)

If you’ve been using Git for more than a short length of time, you’ll hopefully have heard of Git hooks. If not, Git hooks, as Andrew Udvare introduced here on SitePoint back in August of last year, are scripts which run, based on certain events in the Git lifecycle, both on the client and on the server.

Hook illustration

There are hooks for pre- and post-commit, pre- and post-update, pre-push, pre-rebase, and so on. The sample hooks are written in Bash, one of the Linux shell languages. But they can be written in almost any language you’re comfortable or proficient with.

As Tim Boronczyk pointed out in September 2013, there are a wide range of meaningful purposes which hooks can be put to. These include linting, spell-checking commit messages, checking patches against accepted coding standards, running composer, and so on.

Now, PHP’s a great language, don’t get me wrong, but it’s not necessarily the best language for shell scripting. Admittedly, it’s gotten a lot better than it once was. But compared to languages such as Bash, Python, and Ruby, it hasn’t been quite as suitable for creating Git hooks; that is, until now.

Thanks to Static Review, by Samuel Parkinson, you can now write Git hooks with native PHP, optionally building on the existing core classes. In today’s post, I’m going to give you a tour of what’s on offer, finishing up by writing a custom class to check for any lingering calls to var_dump().

Installing the Library

Like most, if not all modern PHP libraries and packages, StaticReview is installable via Composer. To install it in your project, run composer require sjparkinson/static-review in the root of your project. With that, let’s get going.

Continue reading %Writing PHP Git Hooks with Static Review%

Link
Stefan KoopmanschapWeCamp Day 5 (31.8.2015, 14:45 UTC)

I still owe you one day, so here it is. This blogpost came a bit late because as day 5 ended we still needed to get the island back into its regular state, get speakers back to the airport etc. Enough excuses… here’s day 5.

The last day of WeCamp 2015 was an exciting day. After 4 days of preparations and hard work, this was the day that Team Enygma would present Project Cypher. A project that we had kept an utter secret aside from the name.

During the morning, I had another round of individual conversations with my team members to see how their short-term goals were working out. It was very good to see that all team members had either reached their goals or at least were very close to reaching their goals. Some also had a clearer view of what to do with their long-term goals thanks to the experience of WeCamp. One person had not actually reached his goal, but instead had gotten something completely different and unexpected out of WeCamp which he still counted as a win.

The preparations for the presentation of the product went well, although it was finished slightly too late (lunch had already started). Still, good enough.

Then it was time for the project presentations. Team Enygma was presenting as the last team, so we could see the other teams present their stuff first. It was awesome to see what people had come up with: Being able to use a Slack Bot to control an Arduino, community-minded projects for new speakers to get feedback on their project, even a daemon that you can use to play battleships. So very cool. The presentations also gave us an overview of what people had learned. An amazing amount of things were learned, that is clear.

And then… Project Cypher was presented. The idea behind the project was to be able to keep track of information about people you know. In the original project pitch by team member Remco it would be like a CRM for Friends (FRM?). The problem (and I can so relate to this problem): Forgetting about specific things (Where do I know this person from? What do they like? When is their birthday). As we worked on the project, we came to the conclusion that this was also the ultimate tool for stalkers, but it could also very easily be applied by the police for keeping track of criminals. So it was creepy, or not. Team member Paul (who wanted to learn to be a public speaker) killed it in the presentation, sharing what we had learned and also doing an awesome demo of our system in action: Everyone that was at WeCamp was in our database, nicely tagged and easily searchable. You might be able to imagine the feeling of pride I had when I saw all this. 4 people who had never before met had created this project in just 5 days, and learned so much in the process.

After that, it was time for the closing notes and saying goodbye to everyone. The crew and coaches stayed behind to have a final dinner together and chat for a bit more, processing everything that had happened along the way. Such a fantastic week. Thanks everyone who was there.

Link
PHP ClassesCalculating Periodical Events in PHP Part 1: The Problem Challenges (31.8.2015, 03:05 UTC)
By Dan Thanh
Sometimes it is necessary to calculate the days of periodical events, like for instance sweepstakes, contests, regular publications, etc..

In general, it is an easy problem to solve. However when the events span multiple days and must not occur in holidays, the problem becomes less trival to solve.

Read this article to learn how you can use the PHP Sweepstakes class to compute the days of regular event taking in account these nuances that may complicate the calculations.
Link
Stefan KoopmanschapWeCamp Day 4 (29.8.2015, 08:10 UTC)

In terms of working, day 4 was actually only half a day. But since the last day of WeCamp would also just be half a day, some work had to be done. The team focussed on finishing their MVP and ended up actually finishing this as well! A great accomplishment for a team that, 4 days ago, did not know eachother at all.

After lunch the Pragmatist Survival Game was scheduled. We were randomly assigned team mates (get out of that little comfort zone you built during this week!) and went on to do four different games. The games were: A balance game to get team members over the water (preferably without falling in), trying to get as many floating items out of the water, making a fire and lighting gun powder with it and sword fighting. It was awesome to see everyone get into their pirate role so well, including the secret assignment each team got, which was to make a song or poem about Mikke One-Eye. For me personally it was fun to speak to and work with some people from outside of my team as well. And I succeeded pretty good in the whole “being a pirate” by stealing the tally stick of another team, thereby robbing them of the points they earned. Unfortunately our plan to add those points to our own points was stopped by the pirate leaders denying to add it to our points. Still, we earned a third place, which I think is pretty good, out of 8 teams.

Then it was time for the Enrise BBQ (which I was told by Eli should actually not be called a BBQ, but rather a grill-out). This was a perfect way to end the day with all attendees, plus some extra guests: Rick and Stefan from Enrise, Merel and a friend (Merel is the awesome graphical artist who did our coach avatars) and my wife and kids. The night ended in the big tipi around a campfire. I hear some people didn’t go to bed until 5AM. Not surprisingly, this morning the stand-up had some people missing in action.

Today is the last day of WeCamp. It means polishing up the projects, preparing the presentation and delivering the presentation. For me it also means sitting down with my team members to evaluate their personal goals for WeCamp. It’s going to be an interesting day.

Link
Nomad PHPWhat to Learn First In PHP (28.8.2015, 16:12 UTC)
Speaker: Tessa Mero @TessaMero Are you interested in learning how to use PHP? In this presentation, you will gain the tools necessary to get started with programming. PHP is one of the easier programming languages to learn and I will show you all the basics you need to know to start writing code. I will …
Link
SitePoint PHPLogging with Monolog: From Devtools to Slack (28.8.2015, 16:00 UTC)

Logging is an important part of the app development/maintenance cycle. It’s not just about the data you log, but also about how you do it. In this article, we are going to explore the Monolog package and see how it can help us take advantage of our logs.

Installation

Monolog is available on Packagist, which means that you can install it via Composer.

composer require 'monolog/monolog:1.13.*'

However, there is a great chance that you’re using a framework for your app. Monolog provides a list of integrations for most popular frameworks. I’m using Silex for this demo, but I won’t be using the provided integration to show how you can configure Monolog for any of your apps.

The Logger

When you create a new logger, you should give it a channel name. This is how you distinguish your list of loggers. I will bind my logger to the app container.

// app/bootstrap/container.php

$logger = new \Monolog\Logger('general');
$app->container->logger = $logger;

Because Monolog is PSR-3, you can be sure that you are adhering to the PHP-FIG standards. This will allow you to switch to any other implementation if you don’t feel comfortable with Monolog (I don’t see any reason why you wouldn’t). You can now start logging using one of the following methods, depending on your log level. (log, debug, info, warning, error, critical, alert, emergency).

Continue reading %Logging with Monolog: From Devtools to Slack%

Link
Thijs FerynCall varnishstat remotely using Go (28.8.2015, 13:08 UTC)
Varnish is one of my favorite pieces of technology. It’s a reverse caching proxy that makes slow websites go fast. It
Link
Stefan KoopmanschapWeCamp Day 3 (28.8.2015, 08:30 UTC)

Day 3 brought change. As I mentioned yesterday some of the personal goals that were set during the individual conversations with my team members affected the work we were doing. This meant, for instance, that Jasper took a more leading role within the team, and Kanban was being implemented for a better view on our progress.

There was also some discussion on functionality and focus, as the team members were realizing they were affected by scope creep. So the minimal requirements were defined more strictly and for all the “fluff” extra post-its were added to the Kanban board. The board now also had a split: The top of the board contained all the features that were really needed, and the bottom contained the nice-to-haves. There was even a small corner of the board dedicated to “super-bling”.

The team became more and more of an actual team, with lots of discussions and a lot of pairing and helping eachother. This was great to actually watch and see it happen.

The goal that was set in the morning was to finish the minimum viable product, and the team worked really hard to reach this goal, working until very late in the night. When I left the team at about 11PM they were still at it, and from what I hear they worked until after midnight even. The goal wasn’t fully reached, but we’re close.

Today will be an interesting day, because the MVP needs to be finished, but there’s also the Pragmatist Survival Game and the Enrise BBQ. I’m very much looking forward to seeing what will happen today, and I’ll share with you tomorrow.

Link
SitePoint PHPVoice controlled PHP apps with API.ai (27.8.2015, 16:00 UTC)

In this tutorial we’ll be looking into Api.ai, an API that lets us build apps which understand natural language, much like Siri. It can accept either text or speech as input, which it then parses and returns a JSON string that can be interpreted by the code that we write.

All the files we’ll use in this tutorial are available in this Github repository.

Microphone in front of blurred audience

Concepts

Before we move on to the practical part, it’s important that we first understand the following concepts:

  • agents - agents are applications. We create an agent as a means of grouping individual entities and intents.

  • entities - entities are custom concepts that we want to incorporate into our application. They provide a way of giving meaning to a specific concept by means of adding examples. A sample entity would be ‘currency’. We define it by adding synonyms such as ‘USD’, ‘US Dollar’, or just ‘Dollars’. Each synonym is then assigned to a reference value that can be used in the code. It’s just a list of words which can be used to refer to that concept. Api.ai already provides some basic entities such as @sys.number, which is an entity referring to any number, and @sys.email which is an entity referring to any email address. We can use the built-in entities by specifying @sys as the prefix.

  • intents - intents allow us to define which actions the program will execute depending on what a user says. A sample intent would be ‘convert currency’. We then list out all the possible phrases or sentences the user would say if they want to convert currency. For example, a user could say ‘how much is @sys.number:number @currency:fromCurrency in @currency:toCurrency?’. In this example, we’ve used 2 entities: @sys.number and @currency. Using the colon after the entity allows us to define an alias for that entity. This alias can then be used in our code to get the value of the entity. We need to give the same entity a different alias so that we could treat them separately in our code. In order for humans to understand the above intent, all we have to do is substitute the entities with actual values. So a user might say ‘How much is 900 US Dollars in Japanese Yen?’ and Api.ai would just map ‘900’ as the value for @sys.number, ‘US Dollar’ for the fromCurrency @currency and ‘Japanese Yen’ for the toCurrency @currency.

  • contexts - contexts represent the current context of a user expression. For example, a user might say ‘How much is 55 US Dollars in Japanese Yen?’ and then follow with ‘what about in Philippine Peso?’. Api.ai, in this case, uses what was previously spoken by the user, ‘How much is 55 US Dollars,’ as the context for the second expression.

  • aliases - aliases provide a way of referring to a specific entity in your code, as we saw earlier in the explanation for the intents.

  • domains - domains are pre-defined knowledge packages. We can think of them as a collection of built-in entities and intents in Api.ai. In other words, they are tricks that Api.ai can perform with little to no setup or coding required. For example, a user can say, ‘Find videos of Pikachu on YouTube.’ and Api.ai would already know how to parse that and returns ‘Pikachu’ as the search term and ‘Youtube’ as the service. From there, we can just use the data returned to navigate to Youtube and search for ‘Pikachu’. In JavaScript, it’s only a matter of setting the location.href to point to Youtube’s search results page:

    window.location.href = "https://www.youtube.com/results?search_query=pikachu";
    

Continue reading %Voice controlled PHP apps with API.ai%

Link
Stefan KoopmanschapWeCamp Day 2 (27.8.2015, 08:00 UTC)

Yesterday was day 2 of WeCamp and it was an interesting day. While gathering requirements in day 1 we created two spikes, topics to research to find out if we could actually do what we assumed we could. So in the morning, two people started on the research, while two other team members started on setting up the vagrant box and the Laravel project (we decided to go with Laravel for our project on day 1).

The first bit of research was quickly finished with a successful result, however the second one caused some problems: It turned out we could not do what we had assumed we could do. This meant we had to go back to the drawing board for at least part of the application we’re building.

After a very constructive and successful session we decided that our change in scope wasn’t all that big. We could still build our main scenario in a slightly different way. So we decided on a new list of tasks to focus on and started building those. At the start I noticed that my team members were all working very much as isolated units, but as the day progressed a lot of interaction started happening between team members. This was a nice development.

Another thing I focussed on as a coach was to set personal goals with each team members. So during the afternoon, I had private conversations with each team member to determine what goals they wanted to set. We talked about work, life and ambition and set one or two long-term goals (for “life after WeCamp”) and one short-term goal (“what do I want to have learned/done during WeCamp?”). Some of the short-term goals immediately had an effect on the work we were doing in the team, so we made some changes to the team dynamic to give the people with those goals the opportunity to reach those goals.

We wrapped up the day in a really positive vibe with some excellent progress on our project and went to dinner. After dinner it was time for the Persgroep Gamenight. I pretty much lost track of my team members at that point, each went to play their own choice of games. In my case, this was: Dixit, Exploding Kittens, Masquerade and more Dixit. Being the responsible adults we are here at WeCamp (grin) we turned off the light at 1:30 and went to bed.

As I’m writing this, day 3 has started and the team is already working on the project again. I’ll try to summarize today in another blogpost tomorrow morning.

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