Upgrading from Sagepay protocol 2.23 to Sagepay protocol 3.00

I have recently been involved in upgrading a sagepay integration on an ecommerce site from Sagepay Protocol v2.23 to Sagepay Protocol v3.00.

Once this has been actioned, I am to update this blog as a point of reference for anyone else working on a similar update.

LinkedIn offer ability to block 'friends'

LinkedIn on Friday announced a new feature that members have been requesting for quite some time: the ability to block other members. It’s a feature that will no doubt be incredibly useful, especially on a social network where many can be relentless in their pursuit of making a professional connection.

In a post on the matter, Paul Rockwell, LinkedIn’s head of Trust & Safety, said they built the feature not only because it was requested but simply because it’s the right thing to do. The feature is being made active as of today to all members, Rockwell noted.

To enable member blocking, simply head over to your LinkedIn profile and navigate to the profile of the person you wish to block. Select “Block or report” in the drop-down menu located next to the Connect and Send InMail buttons.

Pro tip – if you want to avoid an awkward moment, enable anonymous profile viewing before doing so. That way, you can visit and block the person’s profile without them knowing about it.

Once blocked, neither you nor the person you blocked will be able to view each other’s profile. In the event that you are already connected with said person, that connection will automatically be severed. What’s more, you will no longer be able to communication with said person (not that you’d want to anyway) and all recommendations and endorsements will be removed.

PHP refactoring in legacy code

http://www.tomslabs.com/index.php/2012/01/php-refactoring-in-legacy-code/

The story we’ll talk about is a true story. It happened to be challenging and helped the team keep testing its beliefs in XP, iterative developments and code quality.

Product elevator statement

Imagine a well legac”ied” project you don’t know.

• Product is a web forum with millions of messages.
• We want to rebuild the categorization mechanism (messages are “categorized” meaning they are assigned to a category that best describes their content).
• Mission : fix all bugs
• “Short delay” and “no regression” are the words.
• Only few people share the knowledge of the categories system to be refactored.
• Numerous bugs (useless to mention that several generations of developers brought contributions to the project).
• 20 commiters.

Background

From the team’s point of view, here are the goals we anticipated we needed to achieve:

• Understand the expected behavior of the categorization mechanism
• Bring no regression to the actual behavior
• Replace the old mechanism by a new one

First decision we took was to use Git to work on that project. We won’t explain in details that choice (20 commiters, we wanted to avoid working in a dedicated branch for weeks and commit in the HEAD trunk of the project…). It has already been discussed here.

Refactoring strategy

As a Team, we decided to do the refactoring as follow:

1. With the Product Owner, write BDD scenarii describing how the categories mechanism works
2. Switch on the “Test Harness” by automating (implementing) the BDD scenarii
3. Encapsulate ALL calls to the old categories mechanism behind an API (adding Unit Tests to that new API aswell)
4. Based on the API contract, build the new mechanism relying on a new categories data model

1. Write BDD scenarii to describe the categorization behavior

First two weeks were spent “extracting” all the possible knowledge from the Product Owner about the product and translate it into BDD scenarii.
Example:

Given I am a visitor
When I go to url "http://www.infos-du-net.com.sf/forum/"
Then below the meta-category "Multimédia", I have the following sub-categories with content
| cat name                 | decrypted url                                      |
| Image et son             | http://www.infos-du-net.com.sf/forum/forum-20.html |
| Appareils photo, cameras | http://www.infos-du-net.com.sf/forum/forum-47.html |
| Consoles                 | http://www.infos-du-net.com.sf/forum/forum-29.html |

At the end of this step:

• 100 BDD scenarii written
• Shared knowledge of the expected application behavior

2. Switch on the “Test Harness”

We used Behat (PHP based) to implement the scenarii.

Some of the scenarii written with the Product Owner describe a behavior involving integration with third-party systems. They were not implemented because such tests, seen as “integration tests”, were seen as complicated and hard to maintain. We preferred to invest on Unit Tests by Contract (as well explained byJBrains).

Some scenarii were implemented but not automated because describing a behavior that highlights a bugor describing the future behavior. They got RED at the time of the implementation and would go GREEN by the end of the project.

At the end of this step:

• The “Test Harness” is switched on !
• Thanks to the Continuous Integration Platform, we are able to frequently test the categories behavior and ensure we will not break anything during the refactoring.

3. Encapsulate old categorization mechanism behind an API

Example of code BEFORE encapsulation (old DAO was FrmCategoryTable)


public function executeIndex(sfWebRequest $request) {
…
$categoryList = FrmCategoryTable::getForumList($idSite, $culture, $user);
…
}

In order to better test and avoid perturbation with other commiters, we’ve encapsulated all calls to the old category mechanism behind a new API.

We keep the calls to the old category mechanism, but we isolate them into a dedicated API.

Example of code AFTER encapsulation (new API is categoryProvider)


public function executeIndex(sfWebRequest $request) {
…
$categoryList = $this->categoryProvider->getAllCategories($culture, $brand, $country, ICategoryProvider::SERVICE_FORUM, $user);
…
}

Code that implements the new API


class CategoryProvider implements ICategoryProvider {
public function getAllCategories($culture, $brand, $country, $service, $user) {
$categoryList =
CatBrandAndCountryTable::getInstance()
->getAllCategories($culture, $brand, $country, $service, $user);
return $categoryList;
}
}

At the end of this step:

• The old mechanism is isolated behind an API
• The “Test Harness” is still switched on !

4. Based on the API contract, build the new mechanism relying on the new categories data model

During the encapsulation step we’ve created the API that is the CONTRACT of our categories mechanism.
At this time we made the choice to start the implementation of the new API. It was probably not the best choice because for several days the new behavior was only partly implemented. We should have worked on another implementation of the API based on the CONTRACT we had extracted from the previous step.

Only once this is done, we should have switched from one implementation of the API to the other.

Code that implements the new API


class CategoryProvider implements ICategoryProvider {
public function getAllCategories($culture, $brand, $country, $service, $user) {
…
$categoryList = FrmCategoryTable::getForumList(
$siteId, $culture, $user, $categoryLevel);
…
}
}

At the end of this step:

• The new mechanism is plugged (new DAO CatBrandAndCountryTable)
• The “Test Harness” is still switched on !

Conclusion

• Quite a big system was refactored without service interruption
• No merge conflicts because we always committed in the trunk/HEAD
• No projects conflicts because we isolated the pieces of code that were aimed to be re-factored
• The writing of BDD scenarii WITH THE Product Owner helped implementing the right behavior and sharing the knowledge.

Kali Linux

Kali Linux Features

Kali is a complete re-build of BackTrack Linux, adhering completely to Debian development standards. All-new infrastructure has been put in place, all tools were reviewed and packaged, and we use Git for our VCS.

• More than 300 penetration testing tools: After reviewing every tool that was included in BackTrack, we eliminated a great number of tools that either did not work or had other tools available that provided similar functionality.
• Free and always will be: Kali Linux, like its predecessor, is completely free and always will be. You will never, ever have to pay for Kali Linux.
• Open source Git tree: We are huge proponents of open source software and ourdevelopment tree is available for all to see and all sources are available for those who wish to tweak and rebuild packages.
• FHS compliant: Kali has been developed to adhere to the Filesystem Hierarchy Standard, allowing all Linux users to easily locate binaries, support files, libraries, etc.
• Vast wireless device support: We have built Kali Linux to support as many wireless devices as we possibly can, allowing it to run properly on a wide variety of hardware and making it compatible with numerous USB and other wireless devices.
• Custom kernel patched for injection: As penetration testers, the development team often needs to do wireless assessments so our kernel has the latest injection patches included.
• Secure development environment: The Kali Linux team is made up of a small group of trusted individuals who can only commit packages and interact with the repositories while using multiple secure protocols.
• GPG signed packages and repos: All Kali packages are signed by each individual developer when they are built and committed and the repositories subsequently sign the packages as well.
• Multi-language: Although pentesting tools tend to be written in English, we have ensured that Kali has true multilingual support, allowing more users to operate in their native language and locate the tools they need for the job.
• Completely customizable: We completely understand that not everyone will agree with our design decisions so we have made it as easy as possible for our more adventurous users to customize Kali Linux to their liking, all the way down to the kernel.
• ARMEL and ARMHF support: Since ARM-based systems are becoming more and more prevalent and inexpensive, we knew that Kali’s ARM support would need to be as robust as we could manage, resulting in working installations for both ARMEL and ARMHFsystems. Kali Linux has ARM repositories integrated with the mainline distribution so tools for ARM will be updated in conjunction with the rest of the distribution. Kali is currently available for the following ARM devices:
• rk3306 mk/ss808
• Raspberry Pi
• ODROID U2/X2
• Samsung Chromebook
• EfikaMX
• Beaglebone Black
• CuBox
• Galaxy Note 10.1

Kali is specifically tailored to penetration testing and therefore, all documentation on this site assumes prior knowledge of the Linux operating system.

Help! I'm drowning in legacy code!

It can be easy to feel dejected when looking at a pile of code you inherited from four generations of programmer ago. None of the best practices or principles. No tests. Hell, you're lucky if you even have objects that don't rely on PHP 4 style constructors. You're in legacy code hell.

But there's hope.

Software as a long game

Even though it can feel hopeless when starting at such a massive pile of crap, there is in fact hope. There is a redemption waiting for you. That redemption is found in a simple revelation: software is a long game.

Consider: that steaming pile of detritus you're working on didn't get that way overnight. In fact, it took a long time to get a code base that big together in the first place. Code takes time to grow. Rome wasn't built in a day, and neither was your application.

PHP has been around for a long time, over 10 years. Much of that time, PHP didn't many of the features that now make it a world class programming language. Add to that the fact that PHP's low barrier to entry means that best practices we now take for granted weren't known let alone followed means there's lots of in production business-critical code that we're now responsible for maintaining.

What can you do, today?

But everything doesn't need to be fixed overnight. In fact, it can't be fixed overnight, so relax.

Writing software is a long process that takes time. It's okay - in fact, it's expected, that you'll take time to make incremental changes. The first step is to make something better, today, that wasn't better yesterday. Refactor something small. Create a group of objects that talk to each other a little bit more reasonably. Decouple a few small things. Make incremental improvements.

As you move through the code, you have an opportunity to improve each part of it in small ways. Combined with the fact that new additions you make will adhere to current best practices, over time the code will begin to dramatically improve. That's how you make a difference in a legacy code base - through small, incremental changes over time.

To defend everything is to defend nothing.

And even though it's easy to be a perfectionist and think "everything has to be perfect", that kind of thinking won't get you where you need to go. Frederick the Great told his men, "to defend everything is to defend nothing." You have to pick and choose your battles. Maybe you can't refactor the entire database logic section this week. But if you can refactor one model, one controller, one function or one algorithm, you can make steady, incremental progress. And that's something.

Good luck!

Google Launches Project Tango

Google have today announced an experimental Android-powered smartphone with powerful 3D sensors called Project Tango. The phone is the latest project out of Google's Advanced Technology and Projects (ATAP) group.

"The goal of Project Tango is to give mobile devices a human-scale understanding of space and motion," Johnny Lee, ATAP's technical program lead, wrote in a Google+ post announcing the project.

The 5-inch phone will run Android and be equipped a series of 3D sensors capable of taking more than a quarter of a million measurements each second. Google envisions these sensors will have a number of applications from gaming to indoor navigation.

The phone is still in early stages of development, and the first prototypes will only be available to a limited group of developers. The first 200 prototypes, which Google expects to be distributed by mid-March, will go to a group of developers hand-picked by Google.

Google says many of those first devices will go to companies focusing on creating gaming, data processing and navigation and mapping application, but some units have been set aside for "applications we haven't thought it yet," Google said. Interested developers can sign up on Project Tango's website for a chance at getting one of the early prototypes.

Project Tango, though experimental, will likely play a big role in the upcoming Google I/O Developer Conference, which will take places from June 25 to 26.

Why do object oriented principles matter, anyway?

Last week I was chatting with a friend who was asking me about object oriented programming. He asked me a pointed question that I thought deserved a broad and public answer. His question? "Why do these object oriented principles matter, anyway?"

It's a good question. You probably came to PHP writing procedural code, never caring about object oriented development. And maybe you've heard that object oriented development is the way of the future, but for now you haven't seen much of a need for it. You wonder, why does it matter?

There are three reasons you should care about understanding and mastering object oriented programming.

Object oriented programming is about reuse.
Writing object oriented applications is about being able to reuse code that you've written elsewhere.

For example, if you've developed a great database API, you may want to take that along to other applications. Rather than starting from first principles, this object gives you a starting point that you can use in other applications.

Reusing code reduces the time it takes to write new code. Period.

Frameworks are impossible without object oriented development.
Imagine Zend Framework or Laravel without the object oriented model. Would it be possible to create these frameworks with straight procedural code? WordPress has tried; diving into that code base is a sure way to end the day with a headache.

Simply put, the patterns and practices used in modern frameworks rely upon and require understanding object oriented principles. It's difficult if not impossible to work effectively within these frameworks without understanding these concepts.

PHP isn't the only language you'll ever use.
For most of us, we use PHP regularly, but it's far from the only langauge we'll ever use. In fact, most of us will work with Javascript, Python and maybe even some Ruby at some point or another. Those three languages I listed are all 100% object oriented.

PHP allows us to work with procedural code, but in the scheme of modern languages this is an exception, not a rule. You can write procedural code with Python or Javascript, but it's incredibly difficult. And since everything in Python and Javascript is an object, well, you're doing object oriented programming whether you want to or not.