Your Website Engineer has served many thousands of downloads to the WordPress community and ranks within the top 10 when one searches for the term “WordPress” within the Apple iTunes Store. This episode marks Dustin’s 51st podcast on how to build your own quality website and runs for approximately 30 minutes.

In this episode we discuss our recent blog post Takeaways from Cloud Computing Expo 2011, and report back on cloud computing and cloud application concepts from the recent conference.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

Before beginning my notes, I wanted to express my delight in gaining confirmation that our niche business of building custom WordPress plugins provides immense value to businesses and organizations of all sizes. Independent Software Vendors (ISVs) like ourselves accumulate years of knowledge that simply get lost within larger IT operations. ISVs provide affordable niche skills to clients who are concerned with turnaround speed. The value of custom core applications for businesses far exceeds anything that the cloud itself can provide, simply due to the nature of cloud software being contextual for a wide audience. Also, automation is considered essential for businesses of all sizes to control operating costs and enable superior, unique functionality that puts users in the driver’s seat. Finally, because change delivers business value, we’ll always have work in our industry!

Applications

• Money is in core software applications, not in storage or middleware applications.
• Service Level Agreements (SLAs) should offer different levels, such as levels 1 through 4.
• Successful application stores are noted for being ecosystems for developers and communities.
• Businesses and consumers care about functionality rather than the infrastructure elasticity technicians look at.
• Consumers want applications on demand, so there is power in self-service portals.
• Prepackaged solutions are too rigid. Instead, plan a blueprint (or a wizard) to custom build packages automated in realtime. The package itself becomes irrelevant compared to the manageable, upgradeable instructions that built it.
• Change delivers business value, so make updates efficient to allow the most change.
• Keep resources organized to answer who, what, when, and where. Source code must have version control, continuous integration, agile development.
• Most businesses value speed of delivery above all else.
• Core (custom) applications have immense value versus contextual commodity applications (e.g., accounting, and payroll).
• Usability requirements are increasing due to mobile apps making things more simple and intuitive.

Cloud Infrastructure, Platform, and Software Services (IaaS, PaaS, SaaS)

• Server templates are built of (in layered order): drivers, operating systems, middleware, and management interfaces. These templates do not usually have custom apps as part of them, but there are vendors providing tools to build customized templates for mass deployment. Custom template tools have versioning of every software package within the template.
• Templates cannot have already excepted licenses or regional settings. Leave that for the deployment teams.
• Architecture gets too complex without automation. For example, you are better off getting an address to a destination along with a map instead of somebody’s directions how to get there. Don’t offer a service until you have an automation engine that runs your blueprint.
• Focusing on custom blueprints and automation prevents vendor lock-in. Open automation gives choice and portability, raising the level of abstraction.
• Rollback is the version control of the production environment. Always have an easy way to reverse updates.
• Software-as-a-Service (SaaS) is used by companies to avoid “the IT beast” and quickly get access to software, but that still only provides generic commodity software.
• Most software inventions take place in noncritical department level applications, then they become needed to deploy elsewhere and get rewritten for compatibility, then scale and become commodities, and finally get outsourced by the time everyone else uses it.
• IT often gets asked to “fix” SaaS packages and they have to provide a custom layer to address needs.
• Corporate IT departments loose knowledge at incredible rates, as they bleed into so many skill sets. Independent Software Vendors (ISVs) can focus on their work and accumulate knowledge with better budgets and flexibility.

Cloud Application Programming Interfaces

• APIs expose capabilities to new channels.
• APIs leverage the developer communities to build more and expand the reach.
• As examples, eBay gets 60% of its activity through APIs, twitter 75%,and salesforce 65%.
• APIs enable moving to the cloud by making applications portable.
• The best APIs offer clear value, are simple, well documented, supported, secure, atomic, and collaborative.
• When evaluating an API, developers typically gauge its activity, test it out, then search for answers to errors they run into by consulting search engines and/or forums.
• APIs should get versioned, certify developers for them, offer sandboxing capabilities, and monitor or throttle their traffic to ensure quality.
• For an API to be effective, providers must attract, manage, and support developers.
• Incorporate multi-vendor functions such as OAuth, OpenID, and Federation to attract a wider developer audience.
• Provide realtime notifications of updates or outages via Twitter or other methods.

Business Models

• “You get what you measure.”
• Vendors and providers differ in that the former sells services while the latter usually supplies them.
• Model the value propositions of faster, better and cheaper to various options and consider the network connectedness of these value propositions.
• Value propositions are a function of markets, operation metrics, and strategies for monetization.
• Consider the macro (outer industry) and micro (inner industry) applications of offerings.
• Micro concerns are based on operations, growth and contracts.
• Macro concerns are based on community, channels, and industries.
• Choice of standards drives decision making.

Many thanks to all the speakers including Brett Adam, Mike Jones, James Weir, Alistair Farquharson, and Mark Skilton.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

The default statistics that come with beCounted are a set of mythological creatures, including dragons, mermaids, unicorns, and zombies. Administrators can add any number of statistics to this counter, can customize all of the styling, and can add a custom credit blurb beneath the counter display with the ability to add hyperlinks.

Note: We originally created this WordPress plugin for our client’s website, Animal Rights: The Abolitionist Approach, calling it the Animal Kill Counter.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

Your Website Engineer has served many thousands of downloads to the WordPress community and ranks within the top 10 when one searches for the term “WordPress” within the Apple iTunes Store. This episode marks Dustin’s 48th podcast on how to build your own quality website and runs for approximately 30 minutes.

In this episode we discuss our recent blog post What’s in a Phone Number, an explanation of the differences between marketing requirements and engineering specifications for project management.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

We typically start out with obtaining basic requirements from our prospective clients to understand the scope of their project concept. We want to ensure there is a designer involved, or somebody qualified to make design decisions when they come up. On the back end (wp-admin) we generally stick to the design conventions already there, though there may still be design implications requiring a designer’s input. Once we have all the requirements on the table and design mockups ready, we then ask questions that move us towards specifications, adequate for estimating cost and timeline for production.

As an example of specifications, we could ask the following 10 questions with respect to this single form field—telephone number—which certainly could be part of a larger project.

1. Size/width viewable to user
2. Maximum length (characters) for text entered
3. Label text (e.g., phone, telephone, phone number, telephone number)
4. Contextual help information (tooltips)
5. Formatting requirements (examples)
6. Possible inclusion of an auto-formatter utility
7. Validation requirements or behind the scenes conversions
8. Consideration for numbers that may have extension numbers appended to them
9. International support on prefixes and format considerations
10. Breaking into multiple fields, with or without automatic tabbing and autocompletion

There are three typical groups of answers to the above questions:

1. Simplicity. Some prospective clients may need their users’ telephone numbers for a human to call, and may not care much about the format users enter. These prospective clients want to make the project as cost effective as well as easy as possible for the end user, regardless of administrative work that may be generated as data accumulates.
2. Best Practices. Most prospective clients will have us apply some basic validations to ensure the telephone number is valid. For example we could filter for numeric characters with parenthesis, dashes, and spaces allowed, but disallow letters or other characters.
3. Advanced UI. Other prospective clients may care more about data consistency or user interface and have more advanced requirements. For example, an automated SMS integration may require the telephone number to be formatted consistently in the proper structure. There could also be the need for international prefixes and potentially format recognition and correction validators and feedback mechanisms.

So what’s in a phone number? It’s as little or as much as you want to make of it. The good news is that with custom plugins you are empowered to make these sorts of decisions!

Taking this small example, one might consider the questions that may arise from their own project concepts. We advise making sure that any developers being interviewed are asking these types of questions, and that they do so before asking for money. These questions often times come up sooner or later, and the later they arise the more difficult it may be to address them as budget and timeline progress.

Stepping back and looking at project management in general, it makes more sense to spend time planning up front and building a small project versus building prematurely. Ask yourself: Is it wise to go to a builder and expect them to plan for you, or could you take on more of the planning yourself, or possibly involve other team members in the planning process? These are good things to consider before beginning development.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

• Commitment to quality and doing things in a future proofed manner.
• Being visionary—inventing new approaches, building upon and exceeding requirements.
• Doing the things we love and letting the “dots get connected” on their own.
• Leading the business optimistically on a path to success through hard work.
• Perfecting the entire experience within our control.
• Influencing the tools that the community uses everyday, thinking big and never giving up.

Apple products have been legendary. We use Apple products everyday to do what we do. Steve Jobs will be dearly missed…

Your Website Engineer has served many thousands of downloads to the WordPress community and ranks within the top 10 when one searches for the term “WordPress” within the Apple iTunes Store. This episode marks Dustin’s 44th podcast on how to build your own quality website and runs for approximately 40 minutes.

In this episode we discuss WordPress Plugin Strategy, a comprehensive overview of how WordPress is intended to be extended with plugins via the WordPress API.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

WordPress was traditionally a blogging platform and has evolved into a full featured Content Management System (CMS). It is even more than that to PHP developers. WordPress serves as a PHP framework—providing many tools and resources for developers to design their plugins with.

Despite all that WordPress has to offer developers, many don’t necessarily take the time to learn what all the core can do. This can mean reinventing the wheel by bringing in performance costing library files that otherwise aren’t necessary, making custom User Experience (UX) elements that don’t match WordPress, or creating plugins that are essentially islands to themselves based on how they store data and only mildly hook into WordPress.

Let’s examine the WordPress framework to enlighten ourselves on how core developers built the platform to be extended. To begin, here’s a fairly complete list of current WordPress core API features. These interfaces are built and maintained by the WordPress core team and offered to the WordPress developer community:

• Administrative user experience (icons, messages, buttons, forms, tables, pagination)
• Administrative Dashboard Widgets
• Categorization (taxonomy, tags, categories)
• Conditional tags (situation checks)
• Cron (time based execution) system
• Debugging (logging, unit testing)
• File headers (media detection, thumbnails, storage)
• Hook (action and filter) system (plugins modify behavior of the page generator)
• Internationalization and Localization (translations)
• JavaScripts (jQuery libraries and AJAX capabilities)
• Multisite (networking, sharing users plugins themes across sites)
• Options (general settings storage)
• Plugin activation, deactivation, deletion (action triggers)
• Post Metadata (per post/page custom fields, new post types and meta boxes, attachments)
• Sanitization and Validation (escaping, security)
• Security (roles, capabilities, nonces, validation, sanitization, db abstraction, sql escaping)
• Settings (plugin settings pages)
• Shortcodes (hooks within specific pages or posts)
• Template tags (theme developers)
• Transients (session data)
• User Metadata (authentication, per user roles, capabilities, profiles, additional fields)
• URL Rewriting (manipulating page controller)
• Widgets (sidebar items, footer items)
• Web Services HTTP (API server)

The idea of building to the core is to utilize the above APIs as needed for as many purposes as possible, including: data storage, manipulation, and page rendering. In this way, plugins can interact with the site’s content and with each other as intended by the WordPress core team. A plugin should be thought of as an extension to the core, something that can be enabled or disabled, combined with other plugins, and whose output is compatible with other quality plugins and themes.

Our next building to the core concept is “no hacking”. The idea here is to never alter existing plugins, themes, or core files (code). Doing so will break future community contributions, updates, and security fixes trickling down from those project contributors. The plugins that one uses should perform all the necessary functionality within their scope, ideally a single service, and other plugins can be written to add or change most behaviors that WordPress itself offers control over. Thus, there is little reason to even consider modifying an existing plugin, theme, or core file. The cost of doing so will come back to bite in the short term. You’re better off building to the core with any custom projects you may have, plus for any existing plugins you use stick with only quality projects.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

Not everything is built to last. Often times quality gives way to budget shortfalls or pressures to produce rapidly. Lackluster quality can in the worst case scenario lead to accidents and even death. Accidents cannot always be avoided, but they can often be prevented by planning well, providing detailed product specifications, building carefully, testing rigorously, and maintaining vigorously. With respect to websites, the areas one generally needs to protect are: image, operations, and valuable customer data. It makes sense to take as many measures as possible to prevent one’s Internet operations from ever becoming a train wreck!

We recently discussed the topics of WordPress security and performance as they relate to plugins. These topics aren’t necessarily the driving force behind custom plugin development, but they most certainly should be major considerations throughout the product lifecycle as internal and external forces develop. Changes that occur over time include server software developments, web browser developments, database buildup, WordPress core developments, theme and plugin developments, and JavaScript library developments.

Today’s plugin quality topic is interoperability—how well various plugins work together via the core framework of WordPress over time. Software in general becomes outdated rather quickly. More so with open-source community powered software. Depending on the scope of a project, the intended product lifecycle is usually no more than around 5 years. The higher quality the application, the better chance it will have of satisfying expectations and the longer it will last.

In terms of out of the box WordPress plugins, in particular free and unsupported products, we see all sorts of bugs, performance, security and interoperability issues. A recent statistic was released noting that half of the plugins in the WordPress repository aren’t compatible with WordPress 3.0 or above, and that 85% of the plugins were throwing various PHP notices or warnings. To combat these community plugin quality issues, per a recent policy announcement from WordPress maintainers, plugins will automatically expire once their last updated date reaches 2 years old.

Most plugins simply aren’t built to last more than a year or two. Those short term products do serve a purpose—providing useful functionality at a nominal cost to solve an immediate need, often without much planning, specifications, building, and testing. While the benefits of free apps like WordPress plugins are clear, it is also clear that free and cheap comes with a bigger price—especially when evaluated from the perspective of time.

So here’s how one builds WordPress plugins to last, despite an ever evolving core:

• Plan well: The more you consider upfront, the more you will be prepared for near future business changes. Custom software should not just fill a current niche but also handle growth throughout the near future as well.
• Design well: Most training can be avoided simply by having a sensible and intuitive interface catered to the individual stakeholders. Since the framework is WordPress, make the UI follow common WordPress routines.
• Take security seriously: Security holes can lead to intrusions that result in the stealing or corruption of your valuable data.
• Take performance seriously: Fast performing applications result in happier staff, happier customers, and of course improved efficiency to make management happier as well.
• Take interoperability seriously: Plugins must work with the latest version of WordPress core and must not break current versions of other plugins. If there are problems, find a better plugin, or if the functionality is essential and nothing appropriate exists then have one custom built.
• Prepare for disasters: Maintain readily available backups. Ensure your hosting provider has appropriate measures in place and can get you back online in the event of major faults.
• Build to the core: Rely on the documented and supported core API. That is designed to have legacy support for a reasonable period of time, and developments upstream can easily be traced.
• No hacking: Never rely on combining plugins together for a single purpose. Never alter existing plugins because that will break future community contributions and security fixes to that plugin. If there is an existing plugin that meets your needs and doesn’t intertwine with functionality you are having built, it’s okay to keep the pre-built plugin running separately.
• Keep it in the family: Be very careful piecing together outside resources or third party code. Vendors can point fingers at one another, fail to deliver as expected, and cause communication and scheduling difficulties. It’s best to have a single provider be responsible for a standalone product such as a complete WordPress plugin or theme.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.

Your Website Engineer has served many thousands of downloads to the WordPress community and ranks within the top 10 when one searches for the term “WordPress” within the Apple iTunes Store. This episode marks Dustin’s 39th podcast on how to build your own quality website and runs for approximately 40 minutes.

In this episode we discuss Understanding DNS for Faster Website Migrations, how to best architect your domain name’s DNS hosting and how to manage the various records that point traffic to your various hosting providers.

Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do leave a comment below.