I use Eclipse for my PHP coding. One thing I love about Eclipse is the numerous plugins available. The down side is you have to know about the plugins. One plugin I find a must have on any Eclipse installation is PTI – PHP Tool Integration. You can find it on the Eclipse Marketplace in the Help Menu. It has several components. It allows you to run unit tests through PHPUnit from the editor with a click of the button. It can do a CodeSniffer check and display the results in your editor so you can quickly and easily fix the problems. It also include PHP Depend and PHP Copy/Paste Detector. The system comes with all the stuff needed to run out the gate, but you can use your own versions of the various tools.
Category: Programming
Ideas of March
Ideas of march is a nice idea, especially when you consider the recent moves by Twitter. Controlling your own data on your website gives you more freedom. Services like Identi.ca should help alleviate the pain of moving from Twitter, but your own blog is still your own place.
I used to write a lot more than I do now. I thought I had interesting things to say back then. I was a bit more naive, and a bit less intelligent, and much less wise. Today I suffer an inverse problem: fearing I know to little. ConFoo helped to solve that problem. I came away realising I know more than I give myself credit for. I also discovered that I could hold meaningful conversations with other hackers. The problem was, I’ve been sheltering myself from the local developer community for so long, for one reason or another, and I’ve lost that sense of connection with other like minded developers in a non-work setting.
Ideas of march and ConFoo make me realise that the most important thing for a developer is community, and losing that will cause you to lose your way. The most fun and successful I’ve been has always been a result of community efforts. It’s realising and understanding this that makes me realise more than ever that I need to get out and meet the local community, be involved more online, and contribute back what knowledge I have.
So, here’s my pledge, for the ideas of march, to publish more, comment more, and contribute back to the community as a whole.
Eclipse Color Themes
I recently stumbled on a new website, Eclipse Color Themes, and I’ve been enjoying browsing through the various themes. My favorite so far is the Gedit Original Oblivion by Sepehr Lajevardi. What really makes this theme stand out is that variables passed into a method are underlined. This lets you easily see with a glance where these variables are being used.
The colors are also enjoyable, and care was taken to ensure that every aspect was accounted for. I highly recommend it.
Comments are always failures
Comments are always failures? Followed by a post that explains why comments are failures, and what to do about it. The idea is simple, but requiring an article to explain it is a sign of failure, according to the idea.
I came up with my own phrase, which I believe makes the point clearer.
Comments indicate future refactoring.
Installing and setting up Doctrine ORM alongside Zend Framework
Picking up from my previous article on setting up Zend Framework, let’s start with at the beginning and go grab the latest Doctrine files.
[server]$ cd ~ [server]$ cd src/ [server]$ wget http://www.doctrine-project.org/downloads/Doctrine-1.2.3.tgz [server]$ tar xfz Doctrine-1.2.3.tgz [server]$ mv Doctrine-1.2.3 ../lib/ [server]$ cd ../lib/ [server]$ ln -s Doctrine-1.2.3/ Doctrine [server]$ cd ../ZENDPROJECT/library/ [server]$ ln -s ../../lib/Doctrine/Doctrine [server]$ ln -s ../../lib/Doctrine/Doctrine.php
Pretty simple and straightforward, and mostly setting things so Doctrine will sit alongside Zend. Remember to replace ZENDPROJECT above with the name of your Zend Project directory.
After this, you want to open your application.ini file for Zend, and add this line:
autoloaderNamespaces[] = "Doctrine"
You also want to generate your DSN for your database connection now as well. So, add this to the next line:
dsn = "database://user:pass@db.hostname.com/databasename"
Save the file.
Now, we need to open up the Bootstrap.php file and create the following function:
protected function _initDoctrine()
{
$manager = Doctrine_Manager::getInstance();
$dsn = $this->getOption('dsn');
$conn = $manager->connection($dsn, 'doctrine');
return $conn;
}
This is the bare minimum you’ll need. You can actually get by with less, but we are grabbing the DSN from the application.ini we set before. Matthew has a more complete blog post on the topic, and shares his entire _initDoctrine method with you if you want to initialize your Doctrine instance with additional options set.
From here, you can go ahead and generate your models in application/models and extend them from Doctrine_Record like normal.
Installing and setting up Zend Framework on a Virtual Host
0. Full documentation here:
http://framework.zend.com/manual/en/learning.quickstart.create-project.html
1. Log onto your account. You’ll most like be in your home directory. You should know which directory is your public directory (Web Root). Usually this is something like ‘www‘, ‘public_html‘, or ‘html‘, or maybe even ‘your-domain.com‘. Regardless, you don’t need to be there yet. In the follow examples, anytime you see the directory ‘www‘, assume it’s the Web Root and replace it with whatever your Web Root is.
Also, in the below examples, I’ll use ‘/path/to’. For me, this is ‘/home/jason‘ For you, it might be ‘/home/username‘, or ‘/home/website.com‘. Whatever it is, it’s whatever comes before the rest of the paths. I’ll use ‘/path/to‘ below, just keep in mind, this is different for each person.
If your not sure what this is, when you first log in via SSH, run this command
[server]$ pwd
It will print out the directory your currently in. This is most likely the directory path you’ll want to use for ‘/path/to‘.
[server]$ mkdir src [server]$ mkdir lib [server]$ cd src
2. Download and ‘install’ the source
[server]$ wget http://framework.zend.com/releases/ZendFramework-1.10.8/ZendFramework-1.10.8.tar.gz [server]$ tar xfz ZendFramework-1.10.8.tar.gz [server]$ mv ZendFramework-1.10.8 ../lib [server]$ cd ../lib [server]$ ln -s ZendFramework-1.10.8/ Zend [server]$ alias zf=/path/to/lib/Zend/bin/zf.sh
You can also place the zf alias in your .bash_profile in your home directory by doing the following
[server]$ cd ~ [server]$ vi .bash_profile
You can also use nano, or any other editor you are familiar with, and add this line
alias zf=/path/to/lib/Zend/bin/zf.sh
After all this is done, you’ve essentially installed Zend Framework on your virtual host. However, now you need to set it up for your site.
3. Creating your project
[server]$ cd ~ [server]$ zf create project PROJECTNAME
If you have an existing Web Root, you’ll want to move this or remove it, or change it. Basically, at this point, we want the web root pointing to the correct directory in the Zend Project we just created.
If my Web Root was a directory named ‘www’, I’d do this:
[server]$ mv www www_old
Keep in mind by doing this, I can no longer access my website hosted in that directory. We’ll set this up now.
[server]$ ln -s PROJECTNAME/public/ www
In this case, ‘www’ should be the name of your Web Root.
Now we need to need to make sure the site can find the Zend Framework. Remember, it’s in the lib directory.
[server]$ ln -s /path/to/lib/Zend/library/Zend .
At this point, you should be able to go to your website and check out the default web page. Congrats!
Also, log out, and then log back in. If you entered the alias for your .bash_profile, you should be able to run this:
[server]$ zf show version Zend Framework Version: 1.10.8
Now you can use the zf script helper functions, and proceed with a working Zend Framework setup.
[server]$ zf help
This will also work.
{ openstache and closestache }
I wonder if this will catch on. Seems reasonable enough.
What I know about designing credit card forms
Credit card forms are pretty simple to make when you first think about it. For many online stores, you plug yourself into PayPal and your done. For other people, you plug your shopping cart into your processor, and you accept the defaults. Maybe someone comes along and adds a custom design, rearranging things a bit, but overall, they don’t change much. After all, the checkout process is pretty simple. It’s set in stone. A credit card form is simple. People are used to it, they know what to enter. Credit card forms are simple, common place, and boring.
Checkout my credit card form
The truth is, credit card forms are far from common place, they are far from simple, and while you might consider them boring, a checkout process, and by it’s nature, the credit card entry form, can actually be very, very interesting. I should know. I’ve spent the last 8 years working with them, and every step of the way, I’ve attempted to learn more about how to make them as easy as possible. With that much experience, let me make something clear: the credit card page is the do or die page. It’s the page where a user will either make a purchase, or fail. Your job is to get make it as easy as possible to make that transaction. Every error you present to the user is another chance that user will decide it’s not worth his time and energy to make a purchase at your site.
Too many sites make the credit card form just another form. They provide basic error checking, but let’s be honest, the credit card form is where everything matters. Capture that information, and you can make money. Fail, and you can’t process anything. It doesn’t matter what you do. So much effort is put into the shopping cart, in shopping, in the front page, in the privacy settings, in the product pages, in everything else we do. But at the end of the shopping cart experience, or when the user is about to make a membership purchase, the credit card page is all that stands before them and the final purchase. You want that person to make that purchase. It’s the only way you can get paid.
Don’t believe me? How many people get to your purchase page and bail out? How many get there, get some sort of error, and fail to finish the transaction? What is your most common error? Do you email the user after failing to submit a credit card? How long does it take to complete your checkout or purchase process? How many attempts does a user make before making a successful transaction? How many do they make before not attempting? How many failed transactions do users make if they don’t make any errors?
These are all questions that are important to online retailers. These all provide vital clues in how people are making purchases online. However, I don’t think people put too much weight into looking at numbers like this. After all, what’s so important about how long it takes to complete a purchase?
Time is vital.
Time allows the person to second guess their purchase. It allows for other things to distract the user from making the purchase. Take too long, make the process too cumbersome, and the might not make the transaction at all. Numbers are important here. Find out how long the average user takes to complete a purchase after they start the checkout process. From start to completion. Getting this information lets you know how fast or how slow your form is. Speeding up the process will increase sales. Cutting even a minute off the purchase means the user has less time to decide against the purchase. He makes the purchase, and it’s done, and he’s happy. No more questions, no more concerns.
What about errors?
Common errors are a problem. Common errors are a failure on your part to correct mistakes for the user. Should your users suffer because of a typo? But what kind of common errors could you fix?
Phone numbers. Phone numbers are a major problem. When I was developing my credit card processing system, we were doing telephone authentication long before PayPal and others got on board. The problem is, on a world wide scale, making sure phone numbers are correct can be difficult. After all, we had a single call center making all the calls at the time, so the calls were made from the New York area. Now, for Americans, it was pretty simple to make sure the phone number was correct. However, most people over in Europe or other parts of the world weren’t entering in phone numbers that could be used to call them from New York. They were entering local numbers. I remember spending some long hours reading up on phone numbers and creating a system that would automatically fix their phone numbers, entering in proper country codes, recoding them if necessary, and basically modifying the number they entered to ensure that we could make the call.
Sure, I could have thrown an error and told them they had to enter the phone number correctly. In some ways I did them. I had some helpful information providing country codes in a nice little pop-up window. But since I had the information anyways, I could just automate the fix for them.
Emails were another issue. user@examplecom is not a valid email address, but user@example.com is. It wasn’t uncommon that I would get com without the dot, and fixing that proved to be helpful.
Keep in mind that each of these errors were, at some point, errors that stopped a user from purchasing. Often times they weren’t the only error, but they were an error.
A really easy fix was removing the credit card type selection. This was done early on. After all, I could easily figure out the type of card by the credit card number entered. Selecting the card was useless for me. It was an extra step I forced upon the user. Even worse was when the user would enter in one credit card number and not change the credit card type.
Asking for the credit card name was another problem. It might seem simple that you ask for the name on the credit card, but you’d be surprised at the number of places that require a first and last name. Even worse, some gateways would request the first name and last name rather than as a whole name, while others wanted the full name on the card. The quick and easy solution is to ask for the first name and last name, and combine them as needed. The problem here is the user needs to enter in his middle name, or middle initial. Even worse is that with two fields, the person will probably have to click his mouse into the next field, taking even more time to fill in the form. Sure, tabbing works, but users usually don’t tab through a form. But why even force them to tab?
One field: Name. If you need to split the first and last name, simply split it along the space. If they enter in a middle initial or a middle name, you can detect that and store it as needed. Essentially, you are given more information to work with, and can still provide all the needed information.
The CVV2 is another major problem, though thankfully people are used to it by now. However, it’s still something people need to enter. I found that letting people know about this number and where to find it was best done based on the type of credit card they were entering as well as providing multiple locations to show where the number was.
First, I’d have a little image, about the size of the text box itself, next to the input box, that showed a small credit card with a little circle where the number was. I also had a nice little “What is this?” link next to that. The user could click, and a small pop-up would appear beside the input area. The image was different depending on the type of card, and we tired our best to pin-point where the number could be found. Some cards have 4 digits followed by 3 digits. The 3 digits are in fact the CVV2 or security code, but the previous 4 are part of the credit card number. Usually the last 4 numbers. Sometimes a user would try to enter those 4 numbers along with the other 3. We had set our CVV2 space to a maximum length, but eventually noticed the problem. We allowed the user to enter in more numbers, and just made sure to remove the numbers we didn’t need. Again, why bother the user with providing us with 100% accurate information. If they give use more than we need, we can always strip out the excess.
Email first
While not directly related to the credit card, the email address is something every online e-commerce system is going to collect. Without a doubt, it’s the way to communicate. What I’m about to suggest might be something that some people might consider to be underhanded, but used correctly, it can provide value to your customers, increase sales, and help solve problems you might know ever existed.
I’m talking about moving the email address up to top of the form. Make it the first piece of information that is requested. As soon as the user finishes entering his email address and moves on, a quick ajax call to the back-end stores the email address next to the purchase information. This is where it can get shady. You don’t want to spam the user, but you do want to assist the user in getting what they want. If the user fails his purchase for whatever reason however, you know have a means by which to follow up with that user. Even if the purchase isn’t successful because the form is never submitted successfully. Let’s say even if the user starts to fill out a form, and then stops half-way through for whatever reason, you now have a means to follow up.
One thing you can do is provide the user with an incentive to complete the purchase. Emailing the customer with a different price let us capture even more purchases than previously. Knocking off 20-30% of the price helped encourage the user to come back and complete the purchase. We were also able to use the time the user was going to make the transaction as an indication of when the user was available. I felt it was safe to assume that if the user was browsing at 3 PM and was going to make a purchase, emailing him the next day around the same time asking if everything was okay wasn’t a bad idea.
What do you really need
Credit card forms are simply complex beasts. They are where you either make money or you don’t. While it might not appear that any of these suggestion alone will seriously increase your profits, together, and over time, they will help. Of course, this requires you to keep track. Every transaction, every error, every piece of data. Knowing what people do, how people use it, what information they get wrong, what information they are entering, all of this is vital. You might be surprised at how many little improvements you can make that, in the long run, help increase how much money you make.
To figure out what you need to do, you really need to track everything. Once you fix the problems, you need to track the places where the transaction would have failed if you hadn’t made the changes you did. This is good because it not only provides you with a direct view into what you are doing right, but it also makes you feel good.
With all that said, this is just the tip of the ice berg when it comes to designing and developing for e-commerce systems. But I really think these are the fundamentals. If you aren’t tracking, if you aren’t correcting, if you aren’t taking the basic steps now, you can’t move forward.
TDD: Test Driven Development
One problem I have with the two big TDD sets out there for PHP (SimpleTest and PHPUnit) was the incompatibility of working in the setup I am working in. SimpleTest apparently wanted to take over error control, something my environment was already handling, and PHPUnit didn’t have a web interface by default. Finally, both wanted to do things their way. None of this is bad, but working in a shop were Unit Testing isn’t the norm at the moment (though momentum exists for the change to take place), I didn’t have time to play around with getting them setup properly. But I wanted to test.
So I did what any programmer would do in my place: I started building my own simple testing sweet. Testing doesn’t have to be complicated. It doesn’t have to involved massive amounts of setup and tear down. In reality, at the very heart of it, just getting some form of tests started is part of the path toward redemption.
My current testing platform is very, very simple. It consists of a file that displays all the tests available to run in a directory (or packages of tests in sub-directories of the main test folder). You click a link and it runs the appropriate test. It then prints out a simple page that shows the number of successful tests.
Here is a completed testing screen. As we can see, it ran the test, and seven tests failed, and four passed fine. We can review the test below inside the testing screen, saving us even more time. But all this is fairly useless beyond that. We know quickly that the test failed. Now we have to fix those tests. This gives us a list of things we have to fix, a ‘todo’ list of things that need to be addressed. But, what exactly do we need to fix?
We can click on the text right above the test results and it will give us this information.
Now you can see where the fun comes in. Clicking the text expands the details (using jQuery), and now we can see all tests that failed and passed, where they are by line number, and what they received in testing, and what they expected, as well as why the test failed. We can now trace the errors to each line of code, so we know exactly what code caused this to fail, or more precisely, what test failed. The same works for the tests that passed. Of course, even this isn’t as efficient as it could be. Granted, this provides us with enough information to work with, and in some cases, it’s all the information you need. Information overload is something I wanted to avoid. I don’t need to see more than this, except sometimes I do.
Clicking on the top Failed or Passed boxes will expand all the associated tests to further details (again, using jQuery). We can also click on tests to open them up one by one, allowing us to view only what we want. This lets us see what the offending code was that caused the failure without having to go and look for it. This is most useful when we have an unexpected error.
Getting to this point is quick and easy. Drilling down doesn’t require any real effort, and we review things as we go along. We see the failures, we open them, and we allow ourselves the opportunity to review all the errors without forcing ourselves to become overcome with too much information. We can focus on what we need to work on at the moment.
Finally, at the top of the page, the name of the test is also set to rerun the test. This is done on purpose because this testing page sits inside a frame. I use the frame as a type of bookmark for in-house development tools and sites, frequently used links that I don’t want to put in any one browser. After all, I’m generally working inside Firefox, IE, Chrome, and Safari, usually at least two of the four.
There are some problems with my setup. The packaging of tests is really dirty at the moment. Every tests needs to exist in a certain directory. Each tests also needs to start with ‘test_’, and a name like ‘test_AlwaysFail.php’ turns into ‘AlwaysFail.’ ‘test_Always_fail.php’ would be run as the test ‘Always fail.’ But this also means each test file is self-contained, and considered on test. I’ve setup a way to run all the tests at once, but it’s cumbersome, and doesn’t work like it should: quickly, easily, and efficiently.
I also need a way for tests to better document themselves, and a way to automate this feature.
Tests also run when you click on the initial testing link. While this makes testing easy, testing isn’t always about just running the test. There should be someway for me to allow for a launcher page, a way to go to the test page and let me do something if I want, even if it’s as simple as reviewing the tests that will run.
I should be able to run multiple test pages together in a certain order. Setting up a test is important, but I want to test that setup, as usually it’s using the tools I want to test in the first place to do the setup. At the same time, I want setting up test requirements to be easy. This is where the above idea of having a launcher page might be best. Allow me to go through a series of tests step by step, or all at once.
The general theme here is focusing on using tests as development tools, not just as error checking devices. Of course, being able to run all the tests and get an easy to use report is critical.
I don’t imagine for a second my testing platform is as mature as any of the other ones out there now. However, I didn’t start out with the intent of building one. I just needed a simple way to run tests. Then I needed a way to report tests. As time dragged on, I would add one feature, and then another, and keep adding as I needed them. I didn’t spend time developing this, it just evolved.
This all isn’t to suggest that SimpleTest or PHPUnit are bad. I’m using them as a reference for some of the ideas I’m having. But I always focus on how to take what they do, and make it fit with what I want.
Hello world!
I’ve tried multiple times to restart blogging. I’ve blogged before. The site was newbienetwork.net, and then became phpcomplete.com. Both were fun, new, exciting, and interesting. I was learning to program, learning PHP, and teaching others along the way.
Of course now I’m old and jaded. I’ve been programming for 10 years now, and I’ve been focused on credit card processing for the past 8 years. Specifically, I’ve been focused on credit card processing for the adult industry. 8 years of doing that, in an industry that makes it a challenge as well as interesting. Don’t get me wrong. I love what I do. I find everything I’m involved with to be a challenge. There is a lot more that goes into it then people think. However, I also want to break free.
At least on a personal programming level. PHP programming for so long means I know what I’m doing. I have an easy grasp of PHP. I understand how it works, I understand web development as a whole. I know it well enough that I feel comfortable with it. The problem is, I need to branch out.
Of course, the question is, what do I branch out into? I’ve dabbled with game programming using C# and XNA. This has been a recent bit of fun. I’ve wanted to try Java, but frankly, Java is filled with so many options its rather daunting. Where do I start? Maybe the same place I started with C#? A book! But then why not get back into C++. I’ve done C++ early on, but I stopped when PHP became my focus. I could get back into it, but all this is beside the point.
What would I create? More importantly, why build it in any of these languages? So much is web-focused these days that in many ways, it’s worthwhile to learn the new things coming out for the web. Become more fluent with JavaScript, CSS3, and HTML5. Canvas looks amazing. There is so much room for growth. Seeing what people are creating online makes me wonder why I should worry so much about programming offline.
Consider that I am busy learning Zend and Doctrine. Now, I know them well enough I can work with them, but frankly, I don’t consider myself as knowing something until I can avoid using the documentation and I just hammer out code. Both Zend and Doctrine are big, monstrous pieces of code and each have lots of options, do lots of things. Granted, I don’t think I’ll ever really learn every aspect of Zend. Lots of packages, lots of tools I don’t need every day. But there are also a large number of things Zend does that I should learn.
Of course, after I think about all that, I think about what else I am learning. I’ve been pushing myself to use TDD every day, in everything I program. Constant Integration, Agile development, documentation, version control. So much going on every day, so many new things happening.
In the old days, you got a website, you put up a simple page with SSI header and footer, and you were happy. You copied a Perl script, dumped it into cgi-bin, hoped it worked and didn’t throw up a 500 error, and that was your web page.
Oh the old days. I miss, but frankly, these days are a lot more fun.