On the Laravel News site there's an article posted from Sharon Steed covering some habits of highly productive tech teams including topics like trust, meetings and understanding roles.

There’s always a lot of talk about “culture” on tech teams. And that makes sense: managers generally hire people that will fit in well with the group they’ve assembled because they know there’s more to work than just doing the job. Being able to get along with your coworkers, being reliable, and looking the part are also important. A big part of building a solid company culture is about creating an environment which helps your employees be productive. Unfortunately, a lot of what we do in tech has the opposite effect.

She talks about the role of perks in an effective workforce and how, despite some seeming very nice on the outside, can cause burnout as it encourages longer work hours than normal. From there she moves into some suggestions about "meeting culture" and some of the major drawbacks to meetings (including how they can distract from "real, paying work"). There's a nice flow chart included in the post too that can help you determine if a meeting is really necessary or not. From there she goes on to talk about the other two topics mentioned above - employees knowing and understanding their roles and fostering trust between them through things like delegation and effective listening.

On the Laravel News site there's a recent post by Sharon Steed talking about building a culture of trust and why sharing is good on both a personal and corporate level for your career (and not just in technology).

I speak about empathy on teams and why vulnerability is a great asset in your professional life. Sharing ideas falls right in line with my own ideology, but I also understand why people are so terrified to offer up opinions.

[...] I’m constantly amazed at how many people refuse to talk about projects they are working on for fear of others trying to swipe the idea. I’m even more so surprised at people who go out of their way to not share ideas with bosses or coworkers. Yes, there is absolutely a chance that someone else will take credit for that idea. The nature of working with other people, however, is that of collaboration.

She goes on to give some example situations, how sharing and trust between people plays and role and how many are realizing the value of being open. She gives examples of companies that are following this same idea on a corporate level like Buffer, Zappos and Landmark (an oil and gas software company). She ends the post with some practical advice on how you can help foster this culture of trust in your own company and career.

In a recent post to his site Marc Morera discusses the topic of package dependencies in PHP applications. While a lot of the concepts and terms he use are more related to Symfony-based applications, the concepts are good and could apply anywhere.

I’m part of this group of people that consider themselves addicts to open source. [...] want to expose my personal experiences about what I learned over the time by leading an open source project, several small open source bundles and PHP libraries, and I want to do it by explaining how we should take care of our Symfony bundles or PHP component dependencies.

He starts by pointing out that he's talking about framework-agnostic packages and their dependencies here (but his own experience is, again, Symfony-centric). He talks about identifying true dependencies through both use statements and composer.json configurations. He points out that the tricky part comes when your dependencies have dependencies and conflicts that may come up because of these relationships. He also talks about another way to identify dependencies (through adapter use) and package versioning problems. He then gets into talking about Symfony bundle dependencies specifically and links to a tool that can help you map out your required packages. He ends the post with a look at development dependencies and the idea of "trust" in the open source software you use.

In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don’t trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don’t use xDebug in production.

In a recent post to his blog Brian Teeman asks the question of Joomla users and developers - "can you trust your Joomla extensions?"

Sadly in the last 6 months there have been two published circumstances where an extension provider has been hacked and malicious code inserted into the extensions that they offer. This meant that as soon as you installed the extension your site was vulnerable to defacement etc. If there have been two published cases perhaps there have been more that we don't know about. So is there anything we can do to prevent this?

There is a sort of checking system in place with the md5sum matching but it's not widely supported currently. Sites like the Joomla Extension Directory would be prime candidates for sharing this sort of information to help protect those with Joomla installs all across the web.

Brian also suggests a way to make it even more seamless - integrate the md5sum checking into the Joomla code itself to make it even simpler for users to verify they they've gotten the write package from the right source (with the right code inside).

As finding good, qualified local PHP developers becomes harder and harder for some companies, they're slowly realizing that they might need to look outside their area for good talent. If you're a developer and are wanting to promote yourself as someone who can work as a remote employee, you might want to read this post (the first of a series) from Chris Hartjes on telecommuting.

My current position as a "software engineer" for XML Team Solutions is a 100% telecommuting job. [...] Now, when you have a company where none of your fellow employees works in the same city, let alone the same country, you quickly find out what the key issue really is: trust

He goes on to talk about how to build up that trust, not just with the other developers on your team but with the manager you're working with to show them you're the qualified employee they think you are. He also points out one of the big hindrances some companies take issue with on not having all their people in one place - easy meetings/collaboration.

This post was inspired by these thoughts from Cal Evans.

In some of his research into PHP and Windows recently, Cal Evans has come across two surprising things about the (usually dismissed) combination of the two:

• It actually runs well if setup properly

  I don't have a spare computer so I'm not going to discuss performance or show benchmarks. I am talking about ease of use in getting things setup. [...] No, I'm not nearly ready to give up my Linux servers in production and despite Sam Ramji's recent pleas to their open source vendors not to compete on price but compete on value, I can still fail fast and cheap using open source software and operating systems.

• A lot of open source developers just don't trust Microsoft, just because.

  I am, however, willing to give them the benefit of the doubt. I am part of the slim majority on the above poll who thinks they are sincere. The reason I am willing to give them the benefit of the doubt is not because I believe that the core of Microsoft has changed in any way [...] but because I believe that inside of Microsoft, there are pockets of brilliance.

Check out more of Cal's thoughts on the matter and the results of his "unscientific" polls he mentions in the rest of the post.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.