Jason McCreary has continued his series looking at writing "clean code", providing a few helpful hints you can integrate into your daily development work. In part two he goes a bit "deeper" and talks about grouping and encapsulation.

In Part 1 of Writing Clean Code I outlined three simple practices of formatting, naming, and avoiding nested code. All in an effort to improve code readability.

In Part 2, I want to go a little deeper and cover grouping. When I say grouping, I’m really talking about the Object Oriented Programming paradigm of encapsulation. Whether we group the code into a function or a class is often not important. What is important is did we improve the readability of the code.

He starts off by describing the goal of this grouping and lists three motivations for using it as a part of your application's architecture:

• Improving communication
• Couple data
• Organizing code

For each, he includes a brief summary of the topic and some code examples illustrating it in action where appropriate.

In a previous article the SitePoint PHP blog showed you how to use Laravel, the Twilio service and some helpful packages to create an application that allowed interaction via phone calls. In this new tutorial they continue the series and update the application to allow interaction via SMS messages.

In this article, we will modify our Laravel-powered phone-capable weather forecast app so that it is accessible via SMS (text message) in addition to the voice telephone system.

They just add on the functionality rather than creating a new application for the SMS side, adding new routes, controller methods and changing up the service layer a bit. It also includes the messaging that comes back from Twilio and how the response needs to be formatted. Finally, the article shows (with screenshots included) how to configure your Twilio application to allow messaging as well as phone calls. The post ends with screenshots of the application on a mobile device sending the requests for the weather information based on the zip code provided.

The SitePoint PHP blog has a new tutorial posted by author Christopher Thomas showing you how, with the help of Twilio, create a Laravel-based application that lets users communicate with it via phone calls.

Twilio is a SaaS application which enables developers to build telephone applications using web technologies. In this two-part series, we will leverage Twilio to build a weather forecast app that is accessed using the telephone system. The backend will be written with the Laravel framework (an exploratory video course is available for purchase here, or in the form of written tutorials here).

In this part, we will create a simple program that will allow a user to call a phone number that we buy from Twilio, enter a zipcode, and receive the current weather forecast.

You'll need to have a Laravel project already set up and a development environment to work in as well as Composer installed versions of Guzzle and the Twilio SDK. With that all set up, he dives right into the code, setting up routes and creating the "Weather" service class. This class is what's used to interact with the Twilio API and respond to user prompts with weather data from the weather.gov API. Next up is the controller that provides the endpoints for Twilio to hit and return the weather data back to their waiting connection. A bit of middleware is set up to sent the Twilio request signature each time and instructions are included on how to test the local system with the public Twilio API (using Ngrok).

The SitePoint PHP blog has posted a new tutorial by Viraj Khatavkar showing how to use the phpseclib library to securely communicate with remote servers directly from your PHP code.

PHP has an SSH2 library which provides access to resources (shell, remote exec, tunneling, file transfer) on a remote machine using a secure cryptographic transport. Objectively, it is a tedious and highly frustrating task for a developer to implement it due to its overwhelming configuration options and complex API with little documentation.

The phpseclib (PHP Secure Communications Library) package has a developer friendly API. It uses some optional PHP extensions if they’re available and falls back on an internal PHP implementation otherwise. To use this package, you don’t need any non-default PHP extensions installed.

The first step is getting the library installed (via Composer) and a few example use cases including generating SSH keys dynamically and testing a SSH/SFTP connection. The tutorial then talks about three methods you can use with phpseclib to connect to remote servers: using an RSA key, using a password-protected RSA key and just the normal username/password combination. With the connection made they then show you how to:

• execute (single and multiple) commands on the remote server
• exit on the first error
• gather the output from the commands

There's also a bit included about some other interesting configuration options and a few alternatives to the library if phpseclib doesn't work exactly right for your application.

On the Source blog there's a great post that reinforces something that all developers should keep in mind when developing their applications: good code runs on good communication. "Tech language" barriers can make this difficult, but this post gives you a few suggestions on places to start improving.

When I started the interactive team at the Sun Sentinel in 2013, I thought the biggest challenge would be the code. I was wrong. [...] It wasn’t always easy. When you need someone on your side, but they don’t speak the same tech language, it can be very difficult. Investing (not necessarily financially, but emotionally and mentally) in creating a space where teams can work better together is key. Here are some strategies for overcoming the language barrier to make collaboration smoother.

They recommend things like:

• having face-to-face conversations to work out the best solutions
• avoiding assumptions about skill levels
• pausing to check and ensure everyone understands the current state of conversation
• agreeing on common terms and naming

Finally, they make a recommendation that could make some of the developers out their cringe a bit: "document the madness". As they point out, having good documentation of not only the result of the work but also the process along the way can be crucial for future work and others not directly involved in the process to review.

On the SitePoint Web Blog there's a recent post by George Fekete with a few suggestions about how to be a good developer, regardless of the language or technology you're using.

As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day. What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art. In this article, you’ll learn about how to be a better developer by following the “etiquette” of programming and you’ll learn how to use this information to perhaps teach others to better themselves.

He starts with some tips about "being professional" overall that include things like being responsible and having a strong work ethic. Then he moves into writing good code. This isn't about actual code examples, more about good practices and tools. He also shares some tips about how to keep things (and yourself) on track and tips on how to "be a master" when it comes to social interactions and the work you're doing.

Joshua Thijssen has shared his toolbox for less than $100/month that includes a complete set of development and project tools "on the cheap" but still good.

There are a lot of tools out there which can help you as a developer / self-employed contractor. And even though most of these tools are free (as in beer), I don’t mind spending a certain amount of money on tools that help me do my business. So with all the tools out there, all the paid plans, the freemiums and the trial periods, what can a crispy 100 dollar bill every month buy?

His list includes hosting (ServerGrove), issue tracking (Jira), team communication (HipChat) and online storage (Dropbox). His list is made up of eight services with almost all of them having a small cost. The online collaboration (Basecamp) and hosting (from ServerGrove) are the highest costs at $20USD/month.

On the Engine Yard blog today PJ Hagerty has a new post sharing some of his suggestions to help improve your local tech-related group and promote growth.

There are hundreds of User Groups across North America and around the world. These groups are primarily socially based or hacker groups who gather regularly to work on group or individual “toy” projects. Most groups will remain small and insular. It’s easy to stick with what is familiar and keep recycling the same format every month. Unfortunately, this leads to stagnation and apathy by group members. People will eventually stop showing up and the group will either suffer along or just cease to exist.

He suggests things that are easier when there's more than one person involved in making it a success - things like "diversify responsibilities" and having a "coordinator for outside the group activities", but they're helpful tips. He also points out a few other things to remember - that communication with the group is key, "thinking globally" to get your group involved outside the local scope and getting sponsors involved.

Anthony Ferrara has written up a new post that looks beyond design patterns. He suggests that more emphasis should be put on learning proper methods for abstraction and communication between objects and structures.

Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate's OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication.

He briefly covers the three types of patterns most people are introduced to - creational, structural and behavioral - and his suggestions of other patterns that answer more of the "what the problem is" question:

• Shim patterns (Flyweight, Iterator, etc)
• Compositional patterns (Adapter, Builder, Facade, etc)
• Decompositional patterns (Bridge, Command, Mediator, etc)

He spends some time later in the post looking a bit more closely at four specific patterns, Adapter, Bridge, Facade and Proxy. He points out that they (essentially) do the same kind of thing and boils it down to a more refined set of implementation patterns and the problems they help solve.

On the Smashing Magazine site there's a new article talking about coding style matters with developing projects with multiple people (or even possible contributors in the future) involved.

Coding style is how your code looks, plain and simple. And by “your,” I actually mean you, the person who is reading this article. Coding style is extremely personal and everyone has their own preferred style. You can discover your own personal style by looking back over code that you’ve written when you didn’t have a style guide to adhere to. Everyone has their own style because of the way they learned to code.

They talk about how everyone has their own personal "style" to their code and how, when working with a team, everyone needs to communicate and make sure their styles match. They also make a few recommendations for your code like leaving "clues" (comments) and making errors easier to spot. There's also a few links to tools that can help keep your code standardized including CSS Lint and the Eclipse code formatter. PHP, of course, has its own - PHP_CodeSniffer with its own rules.