In a post to his site Matthias Noback looks at an interesting idea when it comes to the structure of your code: the idea of negative architecture and making assumptions.

In "Negative Architecture", Michael Feathers speaks about certain aspects of software architecture leading to some kind of negative architecture. Feathers mentions the IO Monad from Haskell (functional programming) as an example, but there are parallel examples in object-oriented programming. For example, by using layers and the dependency inversion principle you can "guarantee" that a certain class, in a certain layer (e.g. domain, application) won't do any IO - no talking to a database, no HTTP requests to some remote service, etc.

[...] A negative architecture is what's "between the lines". You can look at all the code and describe a positive architecture for it, but given certain architecture or design rules, there's also the background; things we can be sure will never happen.

He goes on to give a few examples of "negative architecture":

• "An object does nothing meaningful in its constructor"
• "An object doesn't also fetch dependencies statically if it also gets any number of dependencies injected"
• "If a class is not marked final, it has at least one subclass"
• "If a property is not marked "private", it's used by at least one subclass"
• "An abstract class won't use methods that aren't part of its published interface"
• "If an object has one public method, it won't have any public static methods"

For each item in the list there's a summary (and sometimes code) included to help clarify the point.

In a new post to the SitePoint Business & Marketing blog Chris Ward asks an interesting question that applies to both the business side and development: do you need an API?.

API stands for ‘Application Programming Interface’ and as the name implies, creating one is a technical process. This article will talk very little about how to create an API as there are a myriad of methods to undertake that. This article aims to focus on the business side of APIs and supply advice for non-technical folk. [...] You may be a forward thinking individual inside of an organizational structure that doesn’t share your views. How can you convince others around you that having an API may be good for your business?

He talks about three of the main kinds of organizations out there that usually have APIs including government, civic and science organizations and most other online services that integrate them into their core services. He also tries to help you answer the question for your own organization by listing some of the positives it can provide as well as some of the negatives that could balance them out. He ends the post with one final recommendation if you do choose to implement an API: "Don't reinvent the wheel".

Sameer Borate continues on his theme of Twitter-related development (part one is here) with his latest post showing how to do sentiment analysis of Twitter feeds. His "sentiment analysis" analyzes a string to determine if it's generally negative or positive based on the AFINN word dataset.

In the last post we looked into accessing Twitter API v1.1 from PHP. In this post we will see how we can add sentiment analysis for the tweets. Generally speaking, sentiment analysis aims to determine the attitude of a writer with respect to some topic. A basic task in sentiment analysis is classifying the polarity of a given text, whether the expressed opinion in a sentence is positive, negative, or neutral. In this post we will use a simple sentiment analysis library to analyze the sentiment of tweets.

His example uses the viracore/caroline library to do the actual analysis. He shows how to install it via Composer and how to make a sample checker, returning the score and the comparative ranking. With that working, he shows how to integrate it into the Twitter connection originally created in the first post, extracting tweets from his own timeline and returning their scores.

If you're a part of a development team anywhere, chances are at one point or another you've asked for someone else to take a look at your code and give their opinions. Maybe it was you looking over a coworker's latest addition and it was...somewhat lacking. How can you say it in a constructive and nice way? The Inviqa techPortal has some suggestions.

Feedback on performance matters. It not only maintains quality, refines and hones performance, but it can also improve morale and trust, and build relationships. It can stop minor problems from escalating into major capability issues. It’s something that every people manager or team leader should be doing as standard, and yet it’s so hard to get right. For some people, giving good feedback is easy. [...] Delivering negative feedback can be a tricky process so how do you give negative feedback, or (as the much hackneyed phrase would have it) “constructive” feedback?

The post includes a list of six things to think about as you provide feedback to other developers (and even as a manager to your employees). The list suggests things like making it timely, listening to their side of things and setting a plan for resolving the issue.

In this recent post to Reddit.com there's some commentary about an older article sharing a negative spin on dependency injection and how it could cause more trouble that it's worth.

The attitude of these pattern junkies doesn't work with me. *I* will decide whether or not I will use a particular design pattern, and *I* will decide how I implement it. This usually means that I don't use design patterns at all, and those that I do use are implemented in my own unique way. Because of this I am widely regarded as a maverick, a heretic and an outcast by those who consider themselves to be "proper" OO programmers.

Comments in the Reddit post talk about DI not being a "silver bullet", how it "empowers polymorphism" and how design patterns should not be done for the same of using design patterns

Michael Babker has a new post to his blog talking about how recent opinions might be the death of Joomla! and how, unless things change, it could take its toll on the project.

It's quite obvious that the state of Joomla! is not one of stability, as evidenced by recent threads on the Joomla! Bug Squad. Threads such as Help in admin menu, Thanks but no thanks, and The purpose and tone of the bug squad list all demonstrate that there is a severe rift between the leadership and the community, and within members of the community as well. Simply put, now is not the time for the Joomla! community, especially the volunteers of the Joomla! Bug Squad, to fall apart.

In his opinion, the Joomla community can't continue to function like this without causing the project to collapse under itself. Pushing away the new developers just wanting to help and putting egos ahead of good contributions only hurts things.

The Joomla! Project CAN NOT go on in this state. Chasing away the volunteers will not do anything productive. Putting your own ego before the collective Joomla! ego will not do anything productive. Not having an open mind will not do anything productive. And being overly offended by the use of a certain term by a non-English speaker certainly will not do anything productive. Change needs to happen.

Emran Hasan has a recommendation for those looking to hire on a "senior PHP developer" - beware.

With the rise of PHP developer as career, many are trying to get their share in the pie. Lately I've met a number of developers who have worked for more than one/two years in developing PHP applications in various companies and they consider themselves as "senior" developers.

Key things to keep an eye out for are the "more talk, less code" they tend to do and the lack of dedication to the tasks at hand. These bad developers then follow up with the typical blame to the junior developers, noting that it was them being difficult that caused all of the "real" problems.

Felix Geisendorfer has come across something interesting in his coding - an issue where false might not be false in the right situation.

So far I've always thought false would evaluate to 0 when used in a computational context. Turns out that this isn't always the case.

His code example tries to check is a false value is greater than or equal to a negative number. The result, however (despite the thinking that false is a zero value) turns out to be false.

I randomly stumbled upon this when arguing with Mariano today if setting Model::recursive to 'false' has the same effect as setting it to '-1'. Turns out that cake uses a statement like this: if ($recursive > -1) in the core which in turn makes -1 and false do exactly the same thing.

Felix Geisendorfer has come across something interesting in his coding - an issue where false might not be false in the right situation.

So far I've always thought false would evaluate to 0 when used in a computational context. Turns out that this isn't always the case.

His code example tries to check is a false value is greater than or equal to a negative number. The result, however (despite the thinking that false is a zero value) turns out to be false.

I randomly stumbled upon this when arguing with Mariano today if setting Model::recursive to 'false' has the same effect as setting it to '-1'. Turns out that cake uses a statement like this: if ($recursive > -1) in the core which in turn makes -1 and false do exactly the same thing.

Stefan Esser has released the latest version of his Suhosin security patch for PHP:

Yesterday I released Suhosin 0.9.17 in response to a bug report by Ilia Alshanetsky and some crash problems with PHP 4 that were reported during the last weeks.

The issue dealt with a method to "bypass the hard_memory_limit of Suhosin due to a bug in PHP" that could result in memory consumption up into the gigabyte range for a single script. The patch takes care of the issue by not allowing negative memory_limit settings, preventing the problem from happening.