Local Production Environment Choices for WordPress: DesktopServer

Photo of Man at Computer

DesktopServer

This product is essentially a WAMP / MAMP application that has been extended to include some additional WordPress oriented functionality.

In its free version the customizations that stood out to me are

  • its inclusion of Xdebug,
  • support for Domain Name Mapping,
  • auto-creation of Apache Virtual Hosts,
  • and its auto-install of WP.

I was surprised to note that they list PHP 5.5 as being included but no mention of PHP 7.

When one moves up to their premium product ($100) one receives

  • a trace utility for PHP debugging (which one?),
  • LAN sharing for mobile testing,
  • a few plugins (bypass login, airplane mode, enhanced Coda2 preview, Adobe Dreamweaver),
  • “blueprints for automated WordPress configurations”,
  • the ability to direct deploy to a live server,
  • and the ability to import (from BackupBuddy, Duplicator, BackWP Up, BackUp WordPress, InfiniteWP, ManageWP), export, and archive sites.

I didn’t spend a ton of time with it, as at the time I was looking for something that was virtualized – e.g., using Vagrant or Docker.

I’d want the premium version –  but $100 is quite pricey, imho, especially when much of the product consists of open source components.

Don’t get me wrong, I understand this has had some significant time and effort put into it, but I’ll blog about a few other solutions available that are free and open source and you’ll see how they can stand shoulder to shoulder with DesktopServer.

Setting Up A Development Workstation

What Is This?

I wrote this primarily for myself – sometimes I don’t remember everything I do when setting up a workstation for development purposes…it may be of interest to others.

You’ll note that there are several areas missing from this arena – no build automation, task runners, etc. Maybe I’ll get around to adding them once I settle on some…but in the meantime, this still works for me.

[See bottom of this document for a list of revisions to this document]

Everybody Uses…

Version Control

  • Install Git for Windows for version control, ensure that Windows PATH is selected during the install so that you can use git from the command-line without needing to use Git’s special CLI.
  • I’d recommend also getting yourself a GUI to manage Git. Personally, I prefer that the editor I’m working in provide Git integration, but sometimes this isn’t available – in which case Atlassian’s SourceTree seems to do a good job.

Editor / IDE

IDE stands for Integrated Development Environment. This software offers numerous tools to expedite code development.

Editors on the other hand are much simpler, yet some people prefer them. We’ll look at a few of each of these.

Editors

  • NotePad++ – This is my base editor. The User Interface isn’t amazing, but it works beautifully. Especially awesome when it comes to working with large files.
  • Brackets – An open source project by Adobe, has a number of useful extensions. UI is attractive, I use this one over NotePad++ usually, except for note files (NotePad++ remembers the text you enter even if you don’t save the file) and large files.
  • Visual Studio Code – Another open source option by Microsoft.

IDEs

There are a huge number of options, Wikipedia has a fairly extensive list.

  • JetBrain’s phpStorm – JetBrain makes a number of different IDE’s and unfortunately isn’t the clearest on which IDE one should purchase. phpStorm handles most web-based languages, but lacks a clear emphasis on JavaScript that webStorm has (but which lacks some of the php integration).
    • See Gary Hockin’s Debugging VVV Vagrant Setup with PhpStorm for helpful instructions on integrating one’s VVV setup into PhpStorm for interpreter and xdebug purposes.
      • If you are wondering where your xdebug.so file lives: /usr/lib/php/20151012/xdebug.so
      • And Code Sniffer:
        /usr/local/bin/phpcs
      • And PHPUnit:
        /usr/local/src/composer/vendor/phpunit
      • And Composer:
        /usr/local/src/composer/vendor/
      • And www folders:
        /srv/www/
      • And PHP:
        /usr/bin/php/
  • Microsoft’s Visual Studio – An IDE with a long and venerable history, more recently integrating a number of Xamarin cross-development features into the IDE. The Community Edition is free.
    • WARNING: Depending upon options selected, this installs Hyper-V; if you are running another virtualization technology (Virtual Box) expect to experience BSoD errors. Unfortunately, I know this from personal experience and I am not alone.
    • Supports Visual C++, Visual F#, Python, C#/.NET, Android/iOS.
  • Google’s Android Studio – For the creation of Android apps.

Interacting with Databases

  • You’ll want something that provides a handy way for interacting with databases, in which case I recommend HeidiSQL.
  • If you don’t have a database server currently, you’ll need one. A couple options include MySQL, MariaDB, Microsoft SQL Server, and PostgreSQL.

Virtualization

Image Management

  • You’ll need something to create/edit images with, I recommend paint.net. Despite its connection to a very basic predecessor (Windows Paint), this software can work miracles.
  • JPEGmini – Usually I wouldn’t recommend using lossy means of reducing image data footprint, but JPEGmini manages to offer significant lossy compression without any visible deterioration to the image, unfortunately it only works on jpeg files.
  • FileOptimizer – Offers compression for numerous different file formats in a lossless manner.

File Transfer

  • FileZilla is a good FTP client.
  • However, FTP is a plain-text protocol, so I’d look at using something SSH based like SFTP. In this case I’d recommend WinSCP or built-in functionality in your IDE (phpStorm for example).

Other Tools

  • You’ll also want a copy of ConEmu or another command line interface (CLI). This software is so much better than the default Windows console.
  • A good archive/compression application will make life much easier, and 7-Zip is the perfect application.
  • Hosts File Editor – While it hasn’t been updated since 2011, I find this software extremely handy when I want to make edits to the hosts file. It offers a nice GUI front-end for the hosts file and enables a number of different nifty features not built into the file itself.

Revisions To Document

  • 10/18/16
    • Added location of www pages on Vagrant.
  •  10/16/16
    • Moved VVV under Vagrant.
    • Added link to Louie R.’s article on using Vagrant/VVV.
    • Changed Basics for Developers to Version Control.
    • Added link to VVV Wiki Article about Connecting to MySQL.
    • Added section on database servers.
    • Added link to article on integrating with PhpStorm, location of xdebug.so.
    • Added location of Code Sniffer; PHPUnit, Composer.

Why the Healthcare.gov fiasco SHOULD teach us to Open Source Government Application Development.

We Spent How Much?!

According to The Daily Beast the United States Government has spent $118 million to build Healthcare.gov and another $56 million in fixing it…and based on the fact that the site isn’t expected to be fully patched for some time yet I wouldn’t be surprised if the total cost in “fixing” exceeds that of building the system in the first place.

Image courtesy of OpenClipart.org and Iwan Gabovitch
Image courtesy of OpenClipart.org and Iwan Gabovitch

I’m not going to take a position on the Affordable Care Act (ACA) – I try to avoid speaking publicly on controversial issues…but I would like to suggest a lesson we can learn from the ACA that I don’t think will be (very) controversial across party lines – that the Government should utilize open source in the development of applications as a standard rule.

Now, I’m not particularly interested in arguing that every government project should be open source – I’ll be happy if 95-99% of them are. I understand that some people rightly or wrongly believe that using open source in sensitive areas could cause security risks. I’ll let Kevin Clough and perhaps Richard Stallman[1] argue that point.[2] But for the vast majority of projects (Healthcare.gov for example) I can see no reason why the development should not be open source and believe there would be significant advantages to such a course of action.

Lets take a look at the specific ways in which open source development could have reduced or eliminated the issues involved in the Healthcare.gov launch:

Transparency

The government (not just one department, but its entirety – e.g. the white house and congress) and the public could much more readily have seen that issues were arising, deadlines were slipping, etc.  and made necessary adjustments.

It is a constant problem within organizations that individuals at higher levels make decisions without the proper knowledge base upon which to make such decisions. This can result in unrealistic timelines and even if the timelines are realistic, if unexpected issues arise and there is slippage, there is a temptation to “gloss over” the setbacks and “hope” that the timeline can still be met.

This oftentimes results in extreme pressure on those actually working on the application as they are pressured to produce more, quicker – which, especially in the case of programming – is unwise. The more you pressure programmers the more likely they are to make mistakes, to take shortcuts and the more hours you demand of them the less productive they will become and, again, the number of bugs will grow exponentially.

Bug Fixes

Open Source software is oftentimes very stable and secure because of the number of eyes looking over the code. Further, individuals who are amateurs can make small contributions that allow the programmers to development on system architecture and bigger issues instead of stomping out bugs and making aesthetic improvements.

It would make sense for the Government to take a similar approach to Microsoft, Google, and Yahoo! on this front – each offers cash rewards for the discovery of issues. This is a relatively inexpensive way to get folks to pour in their energies – and individuals receive (for them) a significant compensation (hundreds to thousands of dollars – depending on the issue discovered).

Load Testing

The failure to properly load test the Healthcare.gov site is shocking. An open source project still needs robust methods of load testing performed by the core team – but it also benefits from other individuals and organizations implementing the application and discovering bottlenecks.

An open source, distributed team, also could have easily simulated the significant load that the site experienced upon launch – exposing the load issues early enough for remediation.

Code Reuse

When a project is open source the code can be reused by others for all sorts of purposes. The code to this project would certainly have applications in other government projects as well as the private sector. Reuse of code can significantly streamline development timeframes and even if someone in an entirely uses a portion of code for an entirely different project in a different industry – they will oftentimes contribute their version of the function (with enhancements/bug fixes) back to the original project (resulting in better, more flexible, secure, and robust code).

Cost

I really am just spitballing here – but I have a hard time believing that the development of an open source system to perform the Healthcare.gov functions would have cost anywhere near the costs expended thus far upon this closed source system. I’d guess that $10 million could have completed the project in a more robust and timely manner via open source.

Lesson Learned?

Please, let us take a lesson from this fiasco. We want more affordable healthcare – we can start by not wasting millions developing an application as a closed system which lacks robustness and stability.

I know some areas of the Government are already working with open source (and that is great) – but this needs to be a greater emphasis. Perhaps (I don’t know) there should even be some legislation that makes the (required) standard for new applications be open source and any applications which are desired as closed source systems should require review by a panel to determine if there is actual, substantial reasons for developing in a closed source system.

[Apparently I’m not the only one to think OSS could have made a huge difference. See this article by Christina Farr over at VentureBeat. Not directly related, but still interesting is Dylan Tweney’s article “Healthcare.gov costs show that feds have literally no idea how to build a big web site” also on VentureBeat. Another article comes from NBC News staff writer Gil Aegerter and can be found here.]

[11/4: Good article from Matt Asay entitled, “Sorry, Open Source Isn’t the Panacea for Healthcare.gov” on ReadWrite.]

  1. [1]Though Stallman would argue for free software rather than open source, but I leave that semantics argument, however important it may be, aside for the time being to focus on an area in which a relatively minor change in procedure (moving to open source development) could make a significant change in cost and efficiency.
  2. [2]There are some excellent arguments on how and why open source technology can be more secure than closed source technology. Specifically, the additional security in closed source systems usually isn’t b/c the systems are actually more secure but a function of “security by obscurity” – in other words, security holes exist, no one knows about them (including those who wrote the software). But I digress…