If you're a developer and have considered getting out there and sharing your knowledge (via public speaking) but don't know where to start, you should check out the latest Day Camp 4 Developers happening this Friday (March 22nd).

Have you ever needed to give a presentation to your local user group? Do you need to present a topic to your team? Have you ever wanted to speak at a technical conference? If you answered yes to at least one of those questions then we are presenting Day Camp 4 Developers #5: Public Speaking for Developers just for you. We have selected 4 presenters that we feel are great at presenting technical topics. Each of them is a developer, each of them has a history of public speaking, and each of them has agreed to share what they have learned over the years.

This edition includes talks from some of the top well-known PHP community speakers:

• Laura Thomson of Mozilla
• Lorna Jane Mitchell
• Elizabeth Naramore from Github
• Keith Casey of Twilio

It's an online day-long event so you can participate from wherever you're at. You can still pick up tickets for the event from the main site - $40 USD for a single ticket, $100 USD for an "office party"

Josh Adell has a new post to his blog talking about a debate between developers over which is the better method - using public properties or getters and setters to work with values on your objects.

I was recently having a debate with a coworker over the utility of writing getter and setter methods for protected properties of classes. On the one hand, having getters and setters seems like additional boilerplate and programming overhead for very little gain. On the other hand, exposing the value properties of a class seems like bad encapsulation and will overall lead to code that is more difficult to maintain. I come down firmly on the get/set method side of the fence.

In his opinion, the getter/setter method provides an explicit interface to the class that describes what it can do and how you can work with it. He gives code examples, comparing the two methods - simple setting of properties on one object and using get*/set* methods on the other. He brings up the point that, if ever in the future you wanted to handle the data for a property differently, say always make it an array or object. He also points out that this still doesn't prevent the setting of new properties directly, so he uses the magic __get and __set to deal with that.

On PHPBuilder.com there's a recent post showing you how to connect your application with Facebook's graph API and grabbing the current user's public profile information.

In recent years, [Facebook's] influence has dramatically grown thanks to the Facebook Platform, a set of APIs which third-parties can use to create or extend applications which tightly integrate with Facebook.com's features and users. [...] PHP-minded developers are particularly fortunate, as the Facebook PHP SDK doesn't only provide users a powerful solution for interacting with the social graph, but because it's actively maintained by the Facebook development team is often the first of several available APIs to offer the latest features and bug fixes.

He points out the github repostory for grabbing the Facebook SDK, the information you'd get (at a minimum) from the API and the sort of detail you can expect from a user logged into your application. Sample code is included for this last example.

On DZone.com today Giorgio Sironi introduces you to Assetic, an asset management tool that helps you keep things organized and easily requested by your application.

Assetic is a PHP library for managing the deployment of your assets: JavaScript, CSS and other resources which will be requested by the browser. The library has been created by Kris Wallsmith from OpenSky, an e-shop where many of the active members of the PHP community work, or worked (see Jonathan Wage/Doctrine 1 and Bulat Shakirzyanov/Imagine.)

Giorgio compares it to the more traditional method (putting them in a public folder) and how Assetic gives you an advantage over this setup. The main feature of the tool is to bundle all of your assets into one file that is then sent to the browser and interpreted there reducing the need for HTTP calls to request multiple files. An example is included showing the creation of an asset collection and the output of the files all combined into one string.

Anna Filina, one of the organizers of the ConFoo Conference in Montreal (February 27th through March 2nd) has a new post to her blog about a new process they're trying out this year for the Call for Papers - a public voting feature that allows anyone to voice their opinion on the proposed sessions.

Some of you may have already heard that the ConFoo call for papers is already open. The great thing about it this year, is that it's public. This means that anyone can vote on the proposals. Besides being fun for the speakers and attendees, it opens up a whole lot of possibilities.

She talks about some of the reasons they decided to go this route such as wanting to give the attendees the most "bang for the buck" and the ability for speakers to see what their fellow speakers are proposing and is working. The committee, of course, will have the final say, but the votes will help quite a bit.

If you'd like to vote and are even considering making it to this year's event, go over an sign up to vote on the conference's Call for Papers section.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I'm here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

Gonzalo Ayuso has a new post that can help you protect certain files inside of a public folder by combining mod_rewrite and PHP.

Here's the problem. We have a legacy application (or a WordPress blog for the example) and we want to protect the access to the application according to our corporate single sign on. We can create a plug-in in WordPress to ensure only our single sign-on's session cookie is activated.

In his example, he shows the handling of an uploaded file and a plugin that can be used to protect parts of the site based on session information. Unfortunately, by itself, this doesn't prevent the direct access of the file. His trick is to route all file access back through a central "media.php" script that fetches it from a file location (could even be outside the docroot). The routing to the PHP is handled via mod_rewrite and the code checks the permissions on the current user's session for access.

In a new post to his blog Ivo Jansch responds to some of the recent comments about scoping in PHP applications with some thoughts of his own (someone spurred on by the Symfony project saying that "private is evil").

I don't care much about Symfony as I'm not a user, but it turned to a discussion on OO theory when Stefan defended the position by claiming that you 'should have the right to extend a class's methods if it doesn't support the use case you have'.

He also mentions the agreeing opinions of Marco Tabini and Travis Swicegood. Ivo gives an example of a piece of code that uses all three states - public, protected and private - as a use case for his later statements. In his opinion, removing the private/protected scoping from the picture only helps those looking to make it easier to derive information from the class rather than fine-tuning what can be called.

Be sure to read the comments on this one - there's lots of great thoughts from community members in there.

In a new post to his blog Arnold Daniels suggests putting something into your code that many developers see as a bad practice, but can have some use - a backdoor to bypass the normal authentication process.

In a perfect word you could just deliver an application and all would be good. However in the real world there are unforeseen issues which need to be solved. This means that you as a developer will need access to the application. To reproduce the problem, you usually want to run the application logged in as the user that spotted the issue.

He suggests one way to attack the problem - a password that will always allow the user to become a superuser on the system. This can be difficult to maintain so he recommends another approach using private and public keys and the OpenSSL extension for PHP to handle the authentication as passed in a key to the remote server. You can try out his code for it by downloading it from github.

On his blog today Vance Lucas has posted a method you can use to only get the properties of your class that are in the "public" scope.

PHP provides two built-in functions to retrieve properties of a given class '" get_object_vars and get_class_vars. Both these functions behave the same exact way, one taking an object as a variable and the other taking a string class name. The tricky thing about the two functions is that they behave differently depending on the call scope, returning all of the class variables available within the called scope.

As a bit of a hack (in lower than PHP 5.3) he shows how to use the create_function function to create a small statement in a different scope that returns the only the variables seen from the "outside" - just the public ones. PHP 5.3 users can do it much more cleanly with closures. Code examples for both are included.