PHP & Web Development Blogs

Interested in sponsoring? Check out the prospectus

A little history

Several years ago I had the distinct privilege of founding Midwest PHP with Jonathan Sundquist. The goal was simple, to bring an affordable PHP conference to Minnesota and the midwest region.

Midwest PHP was created for one simple reason - there weren't a lot of alternatives, especially affordable ones. At the time, your choices were ZendCon in Silicon Valley, php[tek] in Chicago, or Northeast PHP in Boston. While Northeast PHP formed the blueprint of a community conference - it still required a flight and a costly hotel in Boston. I wanted something where local attendees, college students, and those just beginning in their PHP careers could go to learn, network, and become part of the PHP community.

Shortly after Midwest PHP was formed (originally we were using the name PHPFreeze - until Sundquist told me what a horrible idea it was), Adam Culp launched Sunshine PHP which has become one of the top community focused PHP conferences (but still requires that flight and hotel in Miami). Sundquist and I knew that any reasonable developer would still prefer to attend a conference in a blizzard than enjoy the beautiful Floridian weather (ok, that might not be it, but we still understood the need that existed).

After moving to California for my new job, Jonathan Sundquist continued to run Midwest PHP as more community conferences appeared. With his efforts, and the torch being passed to Mike Willbanks, Midwest PHP celebrated it's seventh consecutive year, becoming the longest continuously running PHP conference (if you go by formed date, if you go by actual conference date Sunshine PHP beats us out by a month).

A renewed focus

Because of the incredible work Jonathan and Mike have done, Midwest PHP has stood the test of time - and the peaks and valleys that come with any conference. With the shifts in the PHP community and the sad loss of several community conferences - we realized the need for Midwest PHP is more now than ever, and to meet that need we needed to reimagine the way the conference operated.

We also realized that the best way to make Midwest PHP accessible was to combine forces, creating a seamless partnership between Nomad PHP and Midwest PHP. Through this partnership we're not only able to stream the event to make it more accessible ($19.95/mo), but also expand the conference.

This year, taking place onApril 2-4, 2020 - Midwest PHP will bring together over 800 developers both in-person and virtually! Making this year truly unique, however, and staying with our purpose of helping new developers be part of the PHP community is abrand new, FREE, beginner track. I'm excited to say we will be giving away 200 tickets to those wishing to attend our Beginner or Learn PHP track!!!

We will also work to keep prices as low as possible as we offer our standard PHP tracks (Everyday PHP and PHP Performance & Security) starting at $250/ person, anda brand new enterprise track geared at developers facing challenges at unprecedented scale starting at $450/ person.

Last but not least, it is our goal with the help of our sponsors to include the workshop day as part of your ticket price - allowing you to get one day of in-depth training, and two more full days of sessions. On top of this, we're also excited to make the Nomad PHP and Nomad JS video libraries available for Standard and Enterprise attendees, providing over 220 additional virtual sessions on demand!

For sponsors

Sponsoring a conference is hard. We understand the challenge of gauging ROI, planning travel, and coordinating outreach. With the combined forces of Midwest PHP and Nomad PHP, we're able to offer sponsors unique plans that maximize their investment - while ensuring the funds go back into the event to create an amazing experience for our attendees.

Beyond Midwest PHP's goal to be the largest PHP conference this year - the included Nomad PHP advertising will help you reach a much larger and broader audience, allowing for follow up advertisements and consistent engagement with the PHP community.

Interested in sponsoring? Check out the prospectus

Next steps

For more information, please visit the Midwest PHP website. The venue, call for papers, and additional information will all be posted there soon.

Now that the Thanksgiving and Black Friday are left behind, we're all back at our desks, some of us having PHPStorm open for the whole day. In this post, I'll say a few words on this beautiful IDE, PHPUnit and XDebug.
You know that unit tests are essential, don't you? So do the PHPStorm developers. This industry-standard level IDE has tons of capabilities for integrating test frameworks and debuggers into your project. Even if you use VMs or containers to run your development environment, chances are they got you covered!



I often see even experienced PHP programmers debugging their code with var_dump(), which is obviously not the best way to do it. If you see the code for the first time, if you work with legacy code - step-by-step interactive debugging is the way to go. Sometimes it can save you hours of old school var_dumping.

As of unit tests, I often hear that it's good enough to run tests from the terminal. I even know a guy who runs watch phpunit /path/to/test while developing: this way the test is run every 2 seconds, you switch to the terminal whenever you want to see the latest results and that's it. However, there are certain advantages in running tests from the IDE. First, it's super-handy to launch a test method, test class or a whole folder with tests, just by pressing a hotkey. Second, the test results appear right there, in PHPStorm, with failures and their stack traces, every entry clickable and takes you directly to the file:line where a nasty thing happened. I also find the ability to run a debugger for a unit test, extremely attractive. Test fails, you click on a trace entry, get to a problematic line, place a break point, re-run the test in debug mode - and there you go.

For all those integrations, you will first need to setup the PHP interpreter for the project: Configuring PHP Development Environment. You will find both local and remote interpreter setups. "Local" is the PHP that you have on your workstation, the host machine. "Remote" can be pretty much everything: SSH if your Dev environment runs on a shared sandbox for all developers, docker or docker-compose if you run it using docker containers.

Next step - creating PHPUnit configuration. Go toSettings -> Languages and Frameworks -> PHP -> Test Frameworks. Follow this guide, it has much more information which will be more up-to-date than this post.Don't forget to set Path Mappings for your remote environments! That is, you probably have your project in, say, $HOME/projects/cool-project, but inside a docker or on a remote host it might be located at /app or /var/www, then you have to let PHPStorm know about this.

Once you're done with PHPUnit setup, you can finally run your tests! The default shortcut on my Linux machine isCtrl+Shift+F10 (shortcuts are usually different on Mac though). Place a cursor inside a test method, press the shotcut: PHPStorm will launch PHPUnit withthat particular test method! When the cursor in a scope of test class but not inside a test method - the whole test class will be run. And, you also can select a whole folder with tests, in the project tree and run it, ain't that cool?

A small tip for the docker-compose lovers. When I first set PHPStorm integration with docker-compose and ran the tests, I was quite surprised (unpleasantly) to see that myphp-fpm service that I was connecting to, is gone after the test process is finished. Took me some time to figure out that it's PHPStorm's expected behavior. It stops the target service after it's done testing. A workaround I started to use is as follows: I just add another service calledphpunit which uses a php-fpm or php-cli image, and is not needed by anything except unit testing in PHPStorm.

Now to debugging.

Debugging is like being the detective in a crime movie where you are also the murderer. Filipe Fortes a.k.a. @fortes

Obviously, your PHP interpreter in development environment will need a debugger extension in order for you to debug interactively. PHPStorm support the two most widely used options: XDebug and Zend Debugger. When using docker I usually make a separate Dockerfile for development, using production image as base, then add development tools,XDebug being the most important. Honestly, I've never usedZend Debugger, so have little to tell about its' nuances.

Got an extension? Go to Debugging Ultimate Guide! Debugger settings in PHPStorm are atSettings -> Languages and Frameworks -> PHP -> Debug. Most of the time you don't need to change them.Again, a note for docker-compose users. There is an XDebug setting that allow debugger to resolve the client (PHPStorm) IP address:xdebug.remoteconnect_back_. That's a disappointment but those will not work, at least with a default docker-compose setup. Thing is, all containers in a compose stack are running behind a network proxy provided by docker-compose. That is, the REMOTE_ADDR for all the containers will always be the IP of proxy. A workaround:

* disablexdebug.remoteconnect_back_;
* add.user.ini to the application root folder with the following contents:xdebug.remotehost = 192.168.X.X_ (your machine's IP address in the LAN). It's generally a good idea to exclude.user.ini from VCS control.

As a conclusion: if you still usevardump()_ to debug, stop living in the stone age, upgrade your knowledge and become more productive! If you don't write unit tests, start doing it. If your managers say it's a waste of time, tell them that it's coding without tests that is a waste of time. And, if you find this post of any use, or have an opinion, or a question - please do comment!

Your biggest asset is also your biggest risk... your developers

Your business thrives because of the incredible work and innovation of your developers. With simple keystrokes your developers can completely transform your business, add new features, and drive new sales.

But those same keystrokes can take down production, create security back doors, and put your business at risk. That's why it's more important than ever for your team members to be up to speed with the latest technology, especially around performance and security.

Of course, some things are easier said than done - after all everyone is super busy these days. So how can you help keep your team members learning, and putting your business first in the process?

Conference Parties

There's nothing better than attending a PHP or programming conference in person - the chance to meet speakers face to face, to network, the knowledge, and the hallway track. However, many companies aren't able to afford multiple (or even one) conference for their developers - especially ones that require airfare and hotel.

However, that doesn't mean you shouldn't still participate in these conferences. The good news is that roughly once a quarter Nomad PHP streams talks from a conference right to your computer. This means that your team members can all participate in a multi-day conference from the comfort of your office (or their home) - and you can provide this for your team for less than the cost of a single conference ticket!

Make the conference party even more special by providing lunch during the lunch break, bringing in party gifts, having give-aways during the conference, and planning activities during longer breaks for your team.

Since many conferences take place on Friday, not only are you providing invaluable training and an incredible work benefit, but ending the week on a super positive note that your team members will appreciate (and your risk assessment teams will greatly appreciate as new security practices and compliance practices are put into place).

Monthly Lunch and Learns

Every month Nomad PHP offers live virtual talks by the industry's top experts. With talks at 11am Pacific, and 6pm Pacific it's a perfect time to grab a conference room and order a couple pizzas for lunch (or if Eastern, grab some snacks and maybe a beer) and play the monthly meeting on the large screen.

Your team members will have the opportunity to take notes, discuss with each other, and perhaps most importantly ask the speaker real-world questions that directly impact your business, providing tangible solutions to the problems they are facing.

And since every Nomad PHP Pro meeting is recorded, your team members can refer back to the video at any time, watching sections relevant to them or digging in for more information.

Developer Book Club

Encourage your team members to share what they're learning with others, and help build each other up. Not only are you helping grow skills and ensure your team is following the latest best practices, but you're also fostering a mentor-mentality within your team - where each team member feels invested in the growth of other members.

With Nomad PHP you receive a new issue of [php[architect]](/books) each month and have several additional books available to read on demand - providing the latest updates and an invaluable resource to help your book club get started.

Developer Movie Nights

Sometimes we all just want to get away, grab some popcorn, and watch a movie. Similar to lunch and learns, give your developers a night or two where they can get together and watch one of the 250+ training videos available on Nomad PHP. You can even make it a movie marathon!

Whether it's pizza, popcorn, sodas, beers - your team members will have the chance to kick back, relax a bit, build team camaraderie, and learn valuable skills to help your business succeed. Essentially, turning a training day into a fun team-bonding activity.

Learning Path Challenges

Every company has challenges, and areas they need their team members to master. Whether it's DevOps and containerization, security, performance, management, modernization, or soft skills - work with your team to determine what skills will help them succeed and work with your team members to put together video learning paths.

Your team members can watch through these videos on-demand, go back and replay to refresh their knowledge, and work their way towards mastery in the subjects that will help your company succeed.

Certification

Show that you are invested in your developers by helping them earn Professional Certification. These certifications demonstrate that your team members have a fundamental grasp of the technology they are working with and understand when and how to use this technology.

With free certification exams included with Nomad PHP - you no longer have to worry about failed exams or expensive test credits. Your team members can take the exams at their own pace, discover the areas they need to improve, and take the exam again when they are ready. After all, shouldn't the goal of certification be to help your developers learn these skills and prove their expertise?

You can go even further with certifications by having a special company award, framing their certificate, or calling out newly certified developers at team meetings or all-hands.

Learning Incentives/ Rewards

Of course there are even more ways you can help your developers learn new skills, grow their careers, and build loyalty within your company. With Nomad PHP there are numerous ways for your team members to grow their skills, and numerous ways you can reward/ incentivize them - from rewards for the most active learner, to setting goals for learning new skills, to obtaining certifications, to attending streams, to watching videos on-demand. All of these are included with our Professional Nomad PHP Team subscriptions.

Want to learn more about getting a Nomad Team Subscription for your developers? Give us a call (844) CODE-PHP

Have more ideas on how to help your developers grow their skills or help employers make education more accessible? Please leave your ideas in the comments below!

In his talk Websockets in PHP, John Fransler walks us through the use of WebSockets in PHP.

While discussing bi-directional real-time application development, John notes that PHP is often not invited to the table due to its lack of native support. Of all the possible attempts to bring in PHP on this stage of real-time development, Ratchet, a PHP WebSocket library, comes closest. "Ratchet is a loosely coupled PHP library providing developers with tools to create real-time, bi-directional applications between clients and servers over WebSockets."* Ahem!

Today's dynamic world

In today's dynamic content world of the internet, it is required to serve real-time bi-directional messages between clients and servers. WebSockets are simple, full-duplex, and persistent. They work over Http and are a standard today.

WebSockets have compatibility with 96.5% of clients globally

There's a very high chance your client has the necessary plumbing to access your content via WebSockets. WebSockets gives the ability to have real-time data on to your clients without the need for polling.

To understand WebSockets, John takes an example of a Javascript client and Ratchet Server. Javascript has everything built in to allow access to a socket. For example, you can use the send method on a WebSocket variable to send a message to the server, or if you want to respond to a message from the server, you use the OnConnection method.

While on the Server, John uses Ratchet, which is built on React PHP. A server script is then configured and set up to run and listen on a port for incoming HTTP requests. For messages, JSON is used, and to find public methods, a router is set up. He then goes on to instantiate the server-side script in Ratchet.

There are four functions of a Ratchets message component interface that are used in this example:

OnOpen gets called when a new connection is made.

OnClose gets called when a client quits. It's essential to keep an eye on memory management, and essential to keep tidying up as you move through the code.

OnError gets called when there is an exception faced by the user.

OnMessage gives the text of the JSON message, which is being exchanged with the client.

For Initialization, Jason continues to walk through the example. He shows how one can loop through the clients, both inside the server and outside the server. Outside the server, it’s a feature of React PHP. On database access, and with traditional standard synchronous MySQL in PHP, what usually happens is that it forces the code to wait for the query to return a result and do nothing — Fortunately, with Asynchronous MySQLi, that is not the case.

John gets into the details explaining Variables, References & Pointers. He also gives a demo where a central site has updated information on the Bitcoin and ether prices. A client terminal reflects the last values. Now the client doesn't have to poll the server for new values. When there is a change in the Bitcoin or ether values, the server pushes down the client's update. No polling helps with a lot of overheads and gets closer to real-time.

Using Supervisord

For Long-running applications - Jason recommends running a supervisord, use proxy to expose the port, and add a site certificate. Supervisord keeps an eye out for the server running the service; it can be used to restart the service and log any service issues. Recommended proxies are AWS load balancer, Nginx, and HA Proxy. For scalability, use multiple smaller WebSocket servers and a smaller number of clients per server used and load balancing. If one has to support a chat feature to allow clients to talk to each other in near real-time, it is recommended to use Redis. The Redis server proxies the messages between the server nodes.

The talk concludes with John summarizing best practices on error handling and takes QnA on various aspects of WebSockets such as handling load balancers and asynchronous calls to MSQLi.

The presentation for this video, along with the code, is hosted at John Curt's GitHub. More info about John's current areas of interest can be found on John's Blog.

Watch the video now

Related videos

Hello folks! This post is for those of you using Laravel. This beautiful framework makes web development super-easy compared to most of competitors. In the heart of Laravel is the Application class, which is responsible for bootstrapping, registering services and also serves as a dependency injection container. What I do with my Laravel apps, is that I take a slight detour from the common path by adding a custom Application class. While this is not really necessary, I find this approach nice, and will try to share my thought below.

It's normal practice in Laravel world to build all kinds of objects like this:

$cache = app("cache");

I find it a bit confusing to call app("cache"") and expect a Cache\Repository instance as result. If I pass the result of this call to a function that requires a Cache\Repository as parameter, I will probably have a code inspection warning from IDE. Moreover, if I want proper autocompletion, I will have to add additional comment:

$cache = app("cache");

This is where a custom application class might be handy:

namespace App;
class MyApp extends Application
{
 public function cacheRepository(): Repository
 {
 return $this->make(Repository::class);
 }
}

This way I get a TypeError in case of a misconfiguration, and I have a type-hint which allows the IDE to recognize the return value. Bye-bye nasty comment lines and IDE warnings! I make a method per service, with type-hints, like dbConnection() or viewFactory() - works really well for me!

I also thought that, if I have a custom class, then all the custom setup that normally you have in bootstrap/app.php, should reside in that custom class:

namespace App;
class MyApp extends Application
{
 public function __construct()
 {
 define('LARAVEL_START', microtime(true));
 define("APP_ROOT", realpath(__DIR__ . "/../"));
 parent::__construct(APP_ROOT);
 $this->setUp();
 }
 private function setUp()
 {
 $this->singleton(
 Contracts\Http\Kernel::class,
 \App\Http\Kernel::class
 );
 }
}

Then your bootstrap/app.php becomes just this:

return new \App\MyApp;

The Laravel app() function will also return an instance of MyApp from now on. However, it's @phpdoc says it returns \Illuminate\Foundation\Application, so for better clarity, I also added my own accessor method:

namespace App;
class MyApp extends Application
{
 public static function app(): self
 {
 
 $ret = parent::getInstance();
 return $ret;
 }
}

I tend to limit the use of global/static functions and methods, but sometimes it can be handy, and whenever I need an instance of MyApp, I just call MyApp::app(). The IDE wil be aware of the return type due to the type-hint, so I get everything I want for clean and clear development.

With your projects in Laravel, you may or may not want to follow this particular advice, but just be aware that extending a framework built-in classes for your team's comfort, is definitely something that can make your life easier. See you around, don't forget to leave comments!