The SitePoint PHP blog has a recently posted tutorial showing you how to send event messages from PHP to a remote Logstash server running your PHP on a system with Windows installed. Logstash's goal is to centralize the logging in your environment, allowing you to input log information from a wide range of sources and stored in an Elasticsearch database.

By opening this article you’ve endeavored yourself to expanding your knowledge of PHP applications as part of event-based distributed systems. You’ll be given a quick intro into what we are referring to when we say event messages, what Logstash is, and why it is so cool.

If you’ve already heard of Beats or understand you can run Logstash locally to ship logs to another Logstash instance or directly to a datastore such as Elasticsearch, this article is still for you and will show you an easy-to-configure-and-run, hopefully more effective and certainly fun-to-use alternative.

They start with the quick introduction to Logstash and how the event handling they'll add in later will relay messages over to the waiting server. A code example is included showing how to manually write to rsyslog, pointing out that it and Logstash use a similar protocol to receive messages. The tutorial then shows how to view the messages in the log to ensure they're making it correctly and how to use this agent to stream messages over to the waiting server.

On the Inviqa techPortal today there's a new post talking about the New Relic monitoring service and what it has to offer PHP developers and their applications to help them manage things like performance and resources.

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance. [...] New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page.

They walk you through a "getting started" with the tool and how to get it running on your server - for PHP this means installing an "agent" extension and a local daemon for it to feed information back to. They then get into some of the data New Relic provides including application performance details, browser information, throughput and an Apdex score.

Following up on his previous post about being an "agent of change" in your organization (work, open source project, etc) Matt Frost has posted his second part of the series focusing on the presentation of your ideas.

In Part 2 we're going to talk about presentation of the pitch you put together for this change. It's important that your pitch be well researched and in some regards provable, as the Agent of Change the responsibility lies with you to prove the value of your idea. As we touched on in Part 1, a well thought out plan is going to go a long way in breaking down the barriers that make change difficult to take hold.

He makes a strong point that you need to identify the problem you're trying to solve (and what solution you're wanting to propose) clearly before trying to present it to a listening audience. He recommends quantifying your solution in terms everyone can understand like "hours of work" or cost. He recommends coming up with a short "elevator pitch" version to entice and the longer version to fill in the gaps.

You've got slides, documentation, statistics and loads of other good information that is going to benefit your development process, sales people in particular are looking for that jewel that helps set your organization apart; you've got that jewel!

Matt Frost has posted the first part of a series he's writing up about being an "Agent of Change" in your development organization with recommendations on how you can make changes for the better happen. In this first article, he looks at working up "the pitch" for new technology and practices.

We all to make changes that make our jobs easier, so if your change isn't meeting a need or helping to ease a pain point, it's probably not the right change. [...] Find something that makes your job harder or less enjoyable, there's a pretty good chance that you aren't the only one.

He recommends doing plenty of research before making your recommendations, especially if it's a "we should be doing, but don't know how to" kind of improvement. He uses test-driven development in his examples, with part of his pitch being that it reduces the number of bugs that make it into production.

When plans are well thought-out and researched, the element of risk that others perceive tends to dwindle. [...] It's not about pointing out the faults of others in the organization or assigning blame, it's about learning and making positive changes from the lessons you've learned.

In a new post to his blog today Sameer looks at a trick or two about detecting the type of browser/client a visitor is using to view your website - one method with the superglobal and another with a helpful PEAR package.

Every time you use your browser to access a website a User-Agent header is sent to the respective server. Detecting user agents on the server can be useful for many reasons: browser quirks, personalize content, preventing illegal access.

He talks about the get_browser function that's included in PHP but that requires a browscap.ini file to work. His other option is the Net_UserAgent_Detect PEAR package. It grabs the user agent and breaks it up into the browser type, operating system information and any Javascript-related headers that come along with it. There's also useful tests like "isIE()" and "isNetscape()" built into the package.

On the Dotvoid.com blog today, there's a new post that shares some handy code to parse out information from the incoming user agent string for the visitors for your site.

Recently I experimented a bit with an Apache log file analyzer written in PHP. It's not all that difficult were it not for trying to parse the browser, or user agent, string. [...] For my purposes I don't care much for the operating system details. This is the result so far. I'm still not very satisfied but I thought maybe other people might be interested and maybe help out.

He provides the code in the format of an encapsulated PHP function that returns the product they're using, the version number of the browser and other various comments.

On the Dotvoid.com blog today, there's a new post that shares some handy code to parse out information from the incoming user agent string for the visitors for your site.

Recently I experimented a bit with an Apache log file analyzer written in PHP. It's not all that difficult were it not for trying to parse the browser, or user agent, string. [...] For my purposes I don't care much for the operating system details. This is the result so far. I'm still not very satisfied but I thought maybe other people might be interested and maybe help out.

He provides the code in the format of an encapsulated PHP function that returns the product they're using, the version number of the browser and other various comments.