Last year I was in a meeting with a client that was pitching us on writing the specs for a mobile app and possibly building it after a bidding process. While everyone in the room furiously pitched grand ideas and starting making lists on the whiteboard, basic questions remained unanswered. I couldn’t let things remain to be unaddressed so I asked the following:
What is the business case for this mobile app? What would it accomplish that you currently don’t (or can’t) offer? What requires it to be a mobile app? Is there a better way to accomplish these things?
To this day those questions are still not answered. Luckily the project didn’t move forward. What was really taking place is some executive said “our competitors made an app and we need one too”. Never mind that it may have been a huge waste of money for the other companies. The client also stated that they didn’t see any value in the competitor’s app. Checkbox envy can be costly.
The web industry can sometimes get a bad wrap for some of the crazy ideas that investors put money into, the outrageous development costs for some government websites (healthcare.gov anyone?) and the the cesspool of people willing to just take your money.
I refuse to take money for projects that I know will fail. Whatever form of karma that I believe in won’t let me do it. I don’t have a formal questionnaire or checklist, but here are some of the questions that I believe should be part of the early project discussion:
What business goal(s) are we looking to support with this project?
What will make this project a success?
What work, time and budget will that require?
What assumptions, risks and external factors are we aware of?
What platforms can this be made available on (mobile/native, web)?
So I could have pitched whatever version of an app the client wanted and been rewarded monetarily in the short-term, but I’ve instead slept well for the last year knowing that I didn’t just take the money and run. That’s helped me build a portfolio that I’m proud of and promotes the world I want to live in.
I’ve recently seen a couple of high profile people publicly give next to zero value for design. I may be a developer but I can’t believe this is going on. When starting up my new venture the first person I called/paid was an accountant, the second a lawyer and the third was a designer.
Logo design, branding, print, or digital work needs to be budgeted for and categorized as a long-term asset for your business. Playing the cheap card on a logo or brand palette shows up when you apply it to your business cards, invoices, promotional swag, or website. That’s why I can’t fathom going to 99designs or odesk upwork for this category of important work. Spending $1,000-2,000+ on an identity shouldn’t be a problem for any serious business. We have no issue valuing the business idea (most likely worthless), development (not complaining about this one) or business coaching/advising, so what makes design so different?
It’s important that we be true to ourselves. PHP had a number of frustrating, dark years and some great developers jumped over to Ruby on Rails, Python, Go and other languages. I can’t fault them for their move.
PHP has me excited again. After being close to making the switch myself, I’m happy that I stuck it out. Working with Composer, Laravel, and a number of great packages over the last couple of years, I can say that PHP is back. The modular direction, open sharing of knowledge and resurgence in energy are all pointing to a great future.
What will the most popular web languages be in 10 years? It’s hard to say. But, PHP is the most used language, has the most common CMS, and I’m comfortable calling it home for the foreseeable future.
P.S. If you happen to reside in Ohio, consider attending ColumbusPHP or OhioLaravel. I’d love to put a real face to your avatar.
As part of my current role at LMG, I’m tasked with bringing the entire team into the digital space, and filling in any knowledge gaps that may exist. I’ve received some helpful feedback from the first session so far, but would always welcome more.
A couple of weeks back I attended a local QA (Quality Assurance) conference in Columbus and I’d like to share some of the topics and insights presented.
#1 Testing Types
These are small tests written by a developer that check a small bit of code functions correctly. An example would be if a request to list all customers in fact returns all customers. There will
typically be a large number of these and they should cover the core of the website or application. These tests are run by a developer during the course of development and before each release. These can and should be setup to be highly automated.
Tests written by a developer that verify modules work correctly together. An example would be that when a user is submitted to the signup service all of the steps in the process complete
successfully (create the user in the database, added to the newsletter, and the welcome email is sent). These tests are run by a developer during the course of development and before each
release. These can can and should be setup to be highly automated.
Tests that check the website or application behaves in the expected manner from within a browser (or API), which includes page elements, interactivity/functionality, and error handling. An acceptance test could cover entering user login data, clicking on the login button, and checking for the result. These may be run manually, but should also be automated when possible. These are run by end users, project managers, and developers.
While manual tests may include acceptance tests, they also should be used to cover UI appearance, and link locations. Manual testing should be completed primary by the end client and project manager, but it’s recommended that all parties participate.
#2 Costs of Failure
The cost of failure gets more expensive as you work through the process (up the triangle), and as such, errors should be caught as early as possible. In an optimal scenario unit tests will cover all of the components, integration tests will test all systems, and acceptance tests will test all interfaces (or at least the user stories), leaving manual testing as an efficient final formality.
#3 Testing Environment
Web testing environments should mirror the production environment as much as possible, guaranteeing the
production environment will be sufficient. Because physical infrastructure can be costly to replicate, most web applications can be efficiently hosted on a virtualized platform, bringing full testing environments into reach for nearly all budgets.
Environments should use a copy of production data and connect to live APIs whenever possible.
#4 Maximize Automation
Whenever possible, opportunities to utilize automation should be taken to decrease testing time, reduce errors, and increase release timeliness. However, automation will take additional time to setup and may not be the best option for short, non-recurring projects. Having a fully automated test suite allows for agile projects, continuous integration, and generally a higher
confidence in quality.
#5 Whole Team Approach
Effective testing includes a whole team approach, shared information, straightforward results, and a commitment to quality. No one party will have full exposure to the entire lifecycle of the project, requiring testing from multiple parties.
Additional QA(ish) Testing
Tests the amount of concurrent traffic a website can handle before becoming unresponsive or unusable. This may also test that a site automatically scales correctly, if the platform is designed to automatically add servers during periods of high activity.
Tests the system for exploits that leak sensitive data or allow unauthorized access. Security tests can include third-party scans, penetration testing, and white-box security testing.
Disaster + Recovery
Tests that cover the procedures when the environment fails and the reliability of backups. If the environment is designed for high availability, this could test automatic or manual fail-overs for
each geographic zones.
Tests the load time for the website or application. These will focus on server response times, number of resources (images, scripts, etc) requested, and optimization techniques utilized.
Tests that accessibility criteria is addressed, which includes image alternate text data, proper headings, and other section 508 guidelines. Many commercial sites must properly handle
accessibility or be subject to litigation and/or heavy fines.
I was excited to receive news that a CD1025, a site I built last year, has been selected as a Webby 2013 Honoree. I’m really proud of what I was able to do with their site, along with Jon Poma, Phil Franks, Michael Waclo, and Andy Hutter. Congrats to the rest of the team and the WWCD/1025 group!
As part of the first project I’m taking on at Fundable, I’ve evaluated a wide range of PHP frameworks. From CakePHP to Zend, I completed the feature/checkbox table, reviewed code within each one, moved on to finalist selections, ran a couple sample projects, and finally made the pick.
#1 Features and Support
Included frameworks: CodeIgniter, Kohana, FuelPHP, Laravel, CakePHP, ZendFramework, Symfony, Yii
Within the features and support phase, I was able to break down the frameworks into three categories – Legacy, Established, and Up-and-Comers. I’m sure someone can nit-pick my classifications, but as someone who’s seen web frameworks come and go over the 15+ years, I’m confident that I’m not too far off.
The legacy group contains those that have a mature core codebase and have been in production for a number of years with a significant number of sites. Any of these frameworks would be a safe choice, but at the cost of the latest language features being absent.
CodeIgniter – As the base for ExpressionEngine, CI is a stable platform and is currently compatible with older versions of PHP (5.x). It has a number of developers via it’s “reactor” program and is wide use by the PHP community.
CakePHP – They are eder statesmen as a project that was started in 2005 and stuck to their primary inspiration of Ruby on Rails. While the framework is still being developed, it has largely fallen out of favor to the newer options.
The established options are those that are in wide use, have an active community, tested codebase, and are frequently chosen for new sites. The established players may be starting to slow down on new language support and clinging onto older PHP version support that other frameworks have chosen to drop (or newer frameworks don’t support out of the gate).
Zend Framework – As the 800 pound gorilla of PHP frameworks, Zend does nearly everything and has the weight to show for it. Many stores and commercial projects are built on top of it, it’s well tested, and constantly being updated. Other than the size, and the processing and memory required, it has few downsides.
Kohana – Beginning CodeIgniter inspired, they began when CodeIgniter clung to PHP4 support. Kohana stays current to new futures, but falls prey to a common issue to software projects – documentation. Saying it’s lacking is gentle. Saying it’s woefully missing is more accurate.
Yii – This framework has consistently flown under the radar but, it’s a solid, small framework for a number of common tasks and it takes advantage of its PHP 5.3+ requirements.
Symfony – This framework has a number of solid third-party libraries in use, such as PHPUnit (testing), SwiftMailer (email), and Twig (templates). They have a quality core, and things are extremely configurable.
The Up-and-comers have come into adoption within the last year or two, embrace new PHP features, have a large amount of active development, and energetic team.
FuelPHP – The team took a number of ideas from CodeIgniter, as well as a handful of other frameworks to create a lighter and more modular option. It has good documentation and a number of CodeIgniter developers have migrated onto the framework.
Laravel -This framework has been around for a while, but seems to have really taken off in version 3, and is being largely remodeled for the upcoming version. While initially heavily inspired by CodeIgniter and a handful of other frameworks, it’s now significantly different in its approach.
#2 Reviewing Code
Beyond the feature matrix, I took a look inside the codebase for a number of the options. I looked at the legibility, complexity, and structure of the code, as well as organizational structure of a base project.
I quickly found a theme in folder structure, though many had their own terminology. The idea of “Application/App” and “System/<framework name>/etc” found it’s way into most of the frameworks.
#3 Thinning Out the Pack
I selected CodeIgniter, FuelPHP, and Laravel for further evaluation. While there were numerous items that factored into this, I’ll cover a few of them here.
The common folder structure that I’ve previously mentioned came into play here. Each of the selected frameworks logically separate code in a way that really helps out on a larger project.
Support for Bundles and Modules
Modularity and compatibility for outside libraries was a must. While I can appreciate a lightweight framework, it must also easily integrate with other code. No significant site exists in a vacum. A project might call for a API call to MailChimp, SendGrid, Vimeo, Facebook, Amazon, etc.
Size of Codebase
While surely feature rich, a iceberg sized framework can put undue processing cycles and memory into your monthly hosting bill (no .Net fanboys here). Obviously this metric must be balanced with the feature set and project requirements, but we can find a healthy compromise. Sorry Zend, this is your exit.
#4 Sample Projects
I continued on to create sample projects for FuelPHP and Laravel. I had a recent CodeIgniter project on hand, so I skipped creating a new project for now. In creating these projects, I found myself impressed with both. PHP frameworks have come a long way in the last 5 years. I couldn’t knock either in a major way, though I did find the module (“bundles”) availability better in Laravel.
#5 Final Selection
In the end it really came down to FuelPHP vs Laravel. As CodeIgniter is primarily an EllisLab project, I don’t have faith that it’ll move at the pace needed for the lifespan of our projects. Not an indictment of the current state, but of the outlook of things to come.
When I looked harder at the communities and momentum of each framework a difference emerged. Laravel is the clear winner here. While they are talking about PSR-2 compatibility, and embracing the Composer system with 3rd party components, FuelPHP is behind. In the end, the team behind Laravel is stronger and moving more rapidly to both stay up to date and push boundaries.
I want to make sure I’m clear here. I found both FuelPHP and Laravel sample projects to be great examples of what a PHP framework can be – something that assists, speeds up, and standardizes the development, while not getting in the way (too much). If I was to come into an existing situation with either one, I feel like it would be a productive result.
With all things said, here are some resources for Laravel should you find yourself making the same selection as I did.