Tag: Development

I’ve been contemplating a phrase for a few days now. It applies to writing code, as I do for a living, as well as a whole host of other things… from relationships, to home life, life goals and endeavors… the list goes on.

Don’t let perfection stand in the way of progress.

I know what some people are immediately going to think when they read that. You’re asking me to settle for less than the best, Aaron? Let me say, emphatically, no. In fact, settling is the opposite of what I’m suggesting.

You may have heard of the Lean Startup concept of building a new business or product. I’ve talked about it before. The basic idea is you don’t wait to be feature perfect… you build, iterate, gather feedback, iterate on that feedback and continue the process. That philosophy hedges your bets around building something nobody wants by not waiting for the final, polished product before launching into the world. It relies on the concept that you don’t have to have something perfect in order to release into the wild.

Too often when making engineering decisions in a product, the risk is that you will want to make sure everything is perfect right now. Make sure the classes are all structured perfectly. Perfect object oriented methodologies are in place. Every edge case considered. An entire code-base unit tested.

All of these are extremely important, but they are also things that can be iterated on. Sometimes you can’t write code that relies on code you haven’t yet written yet! So you write shitty code that does the job in order to get ahead, and then return to that shitty code to refactor later.

Sometimes in your personal life, you may find yourself in a relationship that doesn’t have all the ideology of “The One” (Note: What the fuck does “The One” even mean?). That person is perfect in every way. They get your hearts. Understand your twitches. Empathize and support you through all your difficulties and struggles. Yet there’s just a couple things you just can’t stand. Do you give up and move on to the next, expecting next time that you’ll find perfection? Or do you buckle down and realize what you have is pretty damn good and it will be even better than that later on?

Do you let perfection get in the way of progress?

You shouldn’t. You should release, iterate, get feedback and release again. In code. In life.

For years, as a developer, I used the fantastic Textmate software for writing code. I got used to it. It’s a power editor for Mac OS X and has bundle support (think of bundles as extensions or plugins) that enhance the functionality of the software) for just about every technology, from Subversion to Git to a bunch of things I don’t use in a PHP environment like C/C++ mallloc (memory allocation), Python, Ruby, etc. It’s even got a WordPress bundle!

The problem with Textmate, however, is that active development is slow. Like, extremely slow. Like, molasses slow. After five years of using version 1.5x, an alpha version of 2.0 finally emerged last year. It’s still in alpha. Pace of development is still painfully slow, and what is in the 2.0 alpha version is not ground-breaking compared to what is in the current stable version.

Along came Sublime 2. This is, by far, my favorite text editor ever. I’ve been using it for about six months. It emulates virtually everything Textmate does. Textmate does snippets (think of them as macros). Sublime 2 also does snippets and supports the Textmate style. (Hint: If you’re a WordPress developer, my favorite – and still most commonly used – snippet comes from Mark Jaquith who wrote this snippet to create WordPress widgets on the fly. It works in both Textmate and Sublime 2).

The great thing about Sublime 2 is that it is truly a hacker’s paradise. All the config files are JSON objects, so if you can write JSON, you can configure Sublime 2. None of this namby pamby UI/click/select from dropdown bulldookie. Write your code and mean it. Related is that the master configuration file is extremely well documented and you can override everything in it, not by editing this file, but by providing new values in the user configuration file.

Ok, let’s back up and get y’all up to speed on what I do when configuring my Sublime 2 environment.

Config Files

First, I recommend you look at the entire Default configuration file. Read all the settings and comments and understand all the possibilities you have. Your most comfortable environment won’t be mine. For me, I see the following configuration settings that I’m going to want to override. Keep in mind, I never edit the default configuration file. It gets overwritten on upgrade.

Note that I have included the related Sublime 2 default comments along with the settings I wish to override.

1234567891011121314151617181920212223

// While you can edit this file, it's best to put your changes in// "User/Preferences.sublime-settings", which overrides the settings in here.//// Settings may also be placed in file type specific options files, for// example, in Packages/Python/Python.sublime-settings for python files.{// Note that the font_face and font_size are overriden in the platform// specific settings file, for example, "Preferences (Linux).sublime-settings".// Because of this, setting them here will have no effect: you must set them// in your User File Preferences."font_size":10,

// OS X only: When files are opened from finder, or by dragging onto the// dock icon, this controls if a new window is created or not."open_files_in_new_window":true,

// Characters that are considered to separate words"word_separators":"./\\()\"':,.;-&lt;&gt;~!@#$%^&amp;*|+=[]{}`~?",

These settings and their related comments may seem self-explanatory, but in case they are not…

font_size: This setting controls the font size in the editor. Derp.

open_files_in_new_window: As a developer on an 11″ MacBook Air, I hate this setting. As the name suggests, everytime you open a file, it’s going to be in a separate window. This may be okay if you have a ton of screen real estate, but if you don’t… well, I like to have windows open up in a new tab of my editor so I can access them quickly and easily without consuming precious real estate.

word_separators: This is a list of characters that serve as word separators. I don’t mean code word separators. We’re talking about in the editor. I want to be able to click a CSS selector that often comes with a dash in the middle, and highlight/select the whole selector. By default, if there’s a hyphen, only the portion of the word clicked will be highlighted.

For instance, if a <div> has a class="foo", and I click on foo, foo will, by default, be selected. But if that div has a class="foo-bar", then clicking on foo will only highlight/select foo (up to the hyphen) and not all of the, more contextually accurate, ‘foo-bar’. In my user configuration file, I’m going to remove the hyphen, and thus remove this annoyance from my life.

drag_text: This is an edge case setting, but it has bitten me a few times. If you’re in a window in Sublime 2, and you have a block of code selected, when this default configuration is in play, you can drag that text into another window. I can see the use for this, but it’s also thrown me for a loop more times than it’s been useful. I override this to prevent that from happening. If I really want text in another window, I’ll jkust do the traditional copy and paste.

Overriding Defaults

Knowing I want to change these settings, I can write my own JSON object into my User configuration (Preferences > Settings – User):

Installing Packages

There are a million and one different packages out there, depending on what your needs are. Installing a package is as simple as going to Preferences > Package Manager > Install Package. Note that you can also add new external repositories of external packages that Sublime 2 can also search.

Sublime 2 – 4 Pane Grid View

Summary

Sublime 2, of course, has hundreds of different setups. It kinda just depends on your taste and not being afraid to try things. Because everything is based on text file configurations and settings, everything can be reversed. Don’t be afraid to break things. You can always back out. You can even set it up so that you have multiple files open in the same tab. Set it up the way you want it and go be more productive!

Notes:

Sublime 2 works on Mac OS X, Windows and Linux. All options will be similar, if not identical, to what I’m providing here from an OS X perspective. If you can’t find what I’m referring to, think about where logically it might be in your menus. ↩

Today, I went about setting up a local WordPress install for some development I am doing at work. The problem that existed is that I didn’t want to bring the database from the existing development server site into my local MySQL instance. It’s far too big. I figured this could be done via an SSH tunnel and so, I set abut trying to figure it out. The situation worked flawlessly and so, for your sake (and for myself for the future), I give you the steps.

Setting up the SSH Tunnel

I run a local MySQL server and that runs on the standard MySQL port 3306. So as these things go, I can’t bind anything else to port 3306 locally. I have to use an alternate port number. I chose 5555, but you can use whatever you want.

The command to run in a Terminal window is:

ssh -N -L 5555:127.0.0.1:3306 remoteuser@remotedomain.com -vv

A little bit about what this means.

the -N flag means that when connecting via SSH, we are not going to execute any commands. This is necessary for tunnelling as, we literally, will not execute any commands on the remote server. Therefore, we won’t get a command prompt.

the -L flag tells SSH that we are going to port forward. The following portion, 5555:127.0.0.1:3306 combined with the -L flag means, literally, forward all traffic on localhost (127.0.0.1) connecting on port 5555 to the remote server’s port 3306 (standard MySQL listening port).

The remote server and ssh connection is handled by remoteuser@remotedomain.com. This seems obvious, but just in case. You may be prompted to enter your SSH password.

The final part can be omitted, but I like to keep it there so I know what’s happening. The -vv flag tells the SSH daemon to be extra verbose about what is happening with the connection. It’s sort of a good way to debug if you need to, and to know that the port forwarding is actually taking place.

Configuring WordPress to use the Tunnel

Now that we have a successful SSH tunnel, you have to configure WordPress to use it. In the wp-config.php file, simply modify the DB_HOST constant to read:

You need to add two more variables, though, to override WordPress’ existing siteurl and home options to allow you to work with the localhost domain, instead of redirecting to the remotedomain.com that is configured in WordPress.

BOOM!

With these configurations in place, loading up WordPress should now load in the database content from the remote host and you can get to work on local development. Word to the wise… don’t close the terminal window with the tunnel or the tunnel will be severed. If you have to minimize it so it’s not annoying you, go for it… just don’t close it.

As the holidays kick into full gear, and people start looking at a short sprint to gift times with family, I am offering a 30 minute phone consultation related to WordPress for $100. This is a great thing for someone who needs to figure out how to do something that may be unfamiliar for them or if they are just getting setup with WordPress and need plugin recommendations, or the like.

To setup your 30 minute appointment or to inquire about gifting that appointment, fill out this form. For the description, just reference this deal.

For longer term commitments or consulting engagements, including custom plugin development, I am booking clients for Dec and Jan, so feel free to ask about those opportunities as well.

This offer is only good today, Friday Nov 23, 2012 until midnight Central Time.

This offer is good through Midnight, Monday, November 26, 2012 – Cyber Monday.

I don’t often write tutorials but since the rebuild of the WP Engine website some months ago, I have been turned on to the use of a brilliant combination of tools made for development in a Ruby on Rails environment. That doesn’t mean we can’t make it work for WordPress too.

The tools are Compass combined with Sass (which means Sytactically Awesome Stylesheets or some random crap like that).

Sass is cool because it lets you do a whole bunch of stuff with CSS that you couldn’t normally. It’s a kind of abstraction layer above CSS which means you can write normal CSS if you want, but then why wouldn’t you just write normal CSS instead of using Sass?

I’m getting slightly ahead of myself, but With Sass you can do awesome things like variable/placeholders which is awesome for things like defining core elements of a stylesheet such as a palette of colors.

When I talked about using Sass and Compass on Twitter, other WordPress devs made comments that made me want to write this tutorial. One person said that they were tired of Rails developers having all the toys – and it’s true. There are so many awesome things out there for Rails developers that we as PHP and WordPress developers don’t benefit from. This tutorial is non-exhaustive. There are tons of things that you can do with this that I won’t cover. But this should get you going with Mac OS X Lion, developing WordPress locally on your own machine and uploading to a theme file called “test” on a remote server.

Prerequisites

First of all, you need to have a local version of WordPress running. There are a variety of ways to do this, but I use the approach of installing XAMPP. Here’s a tutorial on that. Follow the rabbit trail to configure Apache to look to your Sites directory, as I have, or make that translation in your head to what the default is. There’s plenty of instruction on how to do that on the internet.

For the specifics of this tutorial, it’s very important that you have the latest version of Ruby. The best way to do this is with a tool called rvm, or Ruby Version Manager. Install this with the following Terminal command:

Once rvm is installed, use it to install 1.9.3-p0, the only current version compatible with OS X Lion, and refresh your Terminal profile settings. The last command sets 1.9.3-p0 (or whatever future version you choose to use) as your default.

If you wish to verify that you’ve got the proper version of Ruby active, verify it with the ruby -v command.

My system reported:

1

ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

Now, there are some gems that need to be installed. For developers unfamiliar with Ruby – or Rails – gems, are essentially additional libraries that are installed into the Ruby framework, much like PHP PEAR or PECL modules.

Creating a Sass Project

Once we have everything installed properly, we can start a new project. I keep this out of my web directory (i.e. WordPress structure). Personally, I’ve created a sass directory under my user profile (/Users/aaron/sass) and run my projects out of it with a separate directory for each project.

Now we have to create our compass project. We do that with compass create from our ~/sass directory and then moving into the newly created directory.

Good. Our project is created but we need to make some changes to make this work with WordPress. To do this, we need to edit the config.rb file which is the project configuration file. You can edit this file in Textmate, vi, or whatever you choose as your preferred text editor.

The http_path is a relative path to my DOCROOT – for some reason, things got whacked when using an absolute path.

The css_dir is a relative path to the css directory in my WordPress theme directory. At this time, there is no configuration option to control the name of the CSS files being generated so we will have to use @import inside the required WordPress style.css template file to incorporate Compass generated CSS files.

You can change the images_dir and javascripts_dir as needed to reflect your taste. Personally, I prefer shorter names, so that is reflected in the config file.

The project_type flag is required because, if omitted, Compass assumes we are working in a Rails environment on a Rails project with Rails conventions… WordPress is none of that.

The output_style flag has been set to :nested but could be :expanded, :compact or :compressed depending on your tastes.

The line_comments flag has been set to false to remove debug information from the generated CSS

Having modified the config file, we can take one of two approaches to generating the CSS in our WordPress theme. We can use the compass compile which will generate the files one time. Everytime modifications are made, however, this command would have to be re-run. I prefer, instead, to use compass watch which is a small process that remains running and watches your Sass project for changes and recompiles automatically when changes are made.

Uploading to a Remote WordPress Install

Fortunately, with a little Ruby magic and some built in Compass hooks, we can also upload these newly created CSS files to our WordPress theme. In order to do this, you have to make sure the remote server has the theme directory created and if you are uploading to a subdirectory of that theme (e.g. theme_dir/css), that that directory is created as well.

In our case, the theme directory is test/ and I want to upload to a subdirectory test/css/.

Next we have to install two new gems – the Net::SSH and Net::SFTP gems. Installing these is as straightforward as the earlier gems:

12

gem install net-ssh
gem install net-sftp

Once this has done, include these in your config.rb file. I did this at the top which is best practice with Ruby.

12

require'net/ssh'require'net/sftp'

Below all the previous configurations, add some configuration lines and replace values as needed for your own project:

12345678

# note that this is the directory that CSS files will be written. It can be the theme dir# or a subdirectory (e.g. theme_dir/css). Whatever this path is MUST exist
remote_theme_dir_absolute = '/home/sites/emmense.com/httpdocs/wp-content/themes/test/css'

# note that this is the directory that CSS files will be written. It can be the theme dir# or a subdirectory (e.g. theme_dir/css). Whatever this path is MUST exist
remote_theme_dir_absolute = '/home/sites/emmense.com/httpdocs/wp-content/themes/test/css'

Conclusion

Rails developers have all the fun. It’s true. But with Compass, Sass and a little bit of Ruby, PHP developers (including WordPress theme developers) have a great tool that will make workflows more efficient, CSS more readable and structured and central management more coherent.

Obviously, I did not get too far into the details of using Compass and Sass. That’s a whole tutorial to itself. For information on that, I’d recommend checking out these fine articles written on the topic:

The other day, I wrote the popular 10 Things You Need to Know About WordPress 2.9. As usual, most people are very excited about the new release which is now in beta and available for testing. In the article, I made a few fundamental errors which I have since corrected.

Notably, I mentioned that WordPress 3.0 would be going to PHP 5. This was based on conversations I had with a core developer which I now realized I misunderstood. Kinda. WordPress will probably not be dropping PHP 4 support in WordPress 3.0 but as core developer Mark Jaquith suggests:

Some things already require PHP 5, like time zone support or oEmbed. There are no plans that I know of to remove PHP 4 support in 3.0 “” last I checked we still had 12% of WP installs using PHP 4.

I see more of a natural and gradual deprecation of PHP 4. We’re very much open to making new features require PHP 5 if it would be a pain to make them PHP 4 compatible.

As a PHP developer, I am on board with calls for PHP 5 support. PHP 4 has been end of life (EOL) since August 8, 2008. That basically means that there will be no more releases, no more security patches, no more nothing. It’s done. Stick a fork in it. However, as Matt mentioned on stage at WordCamp NYC this weekend, there are still 12% of WordPress installations using PHP 4 hosting. He breaks that down as approximately 2M installs, the size of a major American city. More precisely, that’s approximately the size of Philadelphia.

This is not to defend WordPress development. I’d leave Philadelphia behind in a minute if I could get access to real object oriented PHP, reliable XML parsing, better HTTP transports and so much more. Yes, Philadelphia… I just threw you under the bus. That’s for signing Mike Vick. However, as Mark suggests, increasingly more features are being added to the core that require PHP 5.

oEmbed, which will ship in WordPress 2.9, requires XML or JSON parsing. XML parsing sucks in PHP 4. JSON ships by default in PHP 5.2. It is easier to backport JSON support to PHP 4 than try to engineer XML parsing for PHP 4. Some in the PHP community feel like backporting a PHP 5 feature to PHP 4 disincentivizes PHP 5 movement. It may, I’m not here to argue that.

Time Zone support is handled via the PHP class DateTimeZone, a PHP 5 class. Of course, on PHP 4 hosts, the user simply has to set the UTC offset (say, UTC-5 for Eastern Standard Time) manually. Graceful degradation.

I personally was one of the first people to write code for the SSH2 portion of the one click automatic upgrade feature. I, of course, did not go very far with it, but I was the one who first took a stab at creating that.

It is not worth it for PHP developers to throw mud at WordPress developers and the PHP 4 requirement if they are not willing to write code to make it better. Writing code does not, of course, mean that your feature will be incorporated. But this is an open source project. If you want to see new features, and the developers have indicated willingness through not only words, but also action, to include PHP 5 features, then you need to be the champion of those changes. In other words, you need to write the code, submit the ticket and state your case. Even if you can’t write the code, open a ticket and be a champion for the case.

Effective arguments, however, do not include holy wars over PHP 4 or PHP 5. Effective arguments do include security, usability, and feature requests that reflect “must have” features. Is it plugin territory or should it be a core feature? Why? State your case.

I will admit not being overly active in the ongoing development of WordPress. I have client work built around WordPress, so that takes up most of my time. Understanding that, I also have no room to throw mud unless I’m willing to step up and write code too. It’s sort of like voting. If I don’t bother to go vote, then I can’t complain about my elected officials.

If you want to see change in WordPress, be that change and put your words into action.

It has been a long time since I got downright giddy about something developer-oriented. Lots of new APIs are coming out all the time and I usually take a once over look at them to determine if there is something cool there. A lot of time there are cool things and I promise myself to come back and explore the possibilities later. I rarely do.

However, with the announcement of GNIP today, I finally feel like my incessant mulling of API frameworks might be coming to an end.

Let me back up. A few weeks ago, I was fiddling with a bunch of APIs trying to create some mashup I was working on. I sent Keith a direct message pitching a “crazy idea”. An API for all APIs. One API to rule them all. His response, “A meta API?”

That made sense and made me laugh because I know how much he hates the word “meta”.

My idea quickly dissipated as I realized it was probably pretty futile to create an API for all these varied services that all had different data formats and types and my need for it wasn’t all that important at the time anyway.

I could have also used the concept when I was working on Mokonji, the project that now sits dead because Trackur beat me to the punch.

The idea with GNIP, bringing this story full circle, is that it is a meta-API. It sits in front of “data producers” (Digg, Flickr, Disqus) and provides a standardized API for “data consumers” (Plaxo, MyBlogLog, even Lijit!) to exchange data.

Since this is still so very early, there are bound to be other data producers and consumers. Also notable is that the only data format is XML. XMPP and JSON are missing. That will likely change over time too.

At the end of this post, this site is going into a twitter free period of two weeks. I’m sensitive to the fact that we talk about Twitter quite a lot and not always doing a good job of reaching into all of real life like we’d like. So after this post, Twitter will not be mentioned here until June 12. :-)

However, I wanted to get this out the door for devs to knock on and bang out. Awhile ago, I created the dctwits Twitter group and released the generic code. It included a Twitter class created by David Billingham and slightly modified for our use.

A few days ago, I released the WP-Twitterpitch plugin which also used the same class. It’s a very useful class but, to be honest, was a little messy, didn’t support XML and JSON and didn’t have support for all the Twitter API.

So I cleaned it up, extended it, fleshed it out a bit more, brought in Keith Casey as a developer and we’re basically launching the class as a version 1.0-beta today.

I’ll work on documenting things a bit more but there is some basic usage on the site and the code itself is pretty well documented. I need testers to bang on this code and submit issues back, via the Google Code page. Patches welcome as well. And I’d love to see how you use this. You can download direct or via SVN.

When Keith gets done with the DC PHP Conference, we’ll look at pushing it out as stable.

The other day, I was talking to the CTO of a company that is working to build a web technology solution for a problem that exists due to the arcane infrastructure and systems already in place in the niche target industry. He was mourning the fact that, after spending gobs of time wireframing and re-wireframing a solution, the parties who initially expressed interest in licensing the technology, had decided to walk away from the table for a variety of reasons.

The big conglomerate that had decided to walk had expressed concern over the fact that they already had systems for billing and other management aspects of their company and didn’t want to invest in something unknown and untried over their long-standing, yet antiquated, solution.

Over the course of an hour or so, and even since then, we looked over his wireframes determining what the company should look like in order to make some sales, if not all the sales he wanted. I realized that his product was designed in such a way that dependencies were created everywhere. If a customer wanted just this one portion that does employee management but not the other part that does billing, there was no productive way to do this so he could make a sale without making the big sale.

In the web world, we talk about mashups. Take a google map and mash it up with Twitter and you have Twittervision. Mashup Basecamp with FreshBooks and tie in Salesforce and you’ve got a complete back-office CRM-Billing system to build your company on top of.

The strength of mashups is the distributed nature of the work. I no longer have to store my own video files because YouTube will do it for me and give me a means to access it, thus eliminating the overhead and cost of doing business associated with that video. I no longer have to worry about the development time and money needed to distribute a widget containing my content to other websites because Clearspring does that work for me. The trick is in APIs which allow others to innovate on top of the technologies created by others.

My advice to this entrepreneur was to create APIs between his various modules and build out-of-the-box products that he could sell that utilize those APIs. In fact the APIs can be open and still be paid access, which provides another stream of revenue – especially when his clients have the money to pay top dollar for those APIs if they consider the alternative cost of throwing out entire chunks of their existing infrastructure and using an out of the box solution that may not meet their unique needs.