My interest in Shopify started a few years ago when I was exploring their developer platform while working on the developer experience for the HubSpot CMS. The Shopify ThemeKit tool was one of the sources of inspiration for the what is now the HubSpot CLI and the syntax of the liquid template language is very similar to the HubL template language used in the HubSpot CMS. Since then I continued to follow the company and its approach to building platform through efforts like Polaris, data-based API versioning, and more recently Hydrogen. As I learned more, it became clear how focused the company was on its product, its developer platform, and the merchants both serve. The focus starts with Tobi Lütke, its founder and CEO. Being product and customer obsessed was a natural fit for me. The staff developer role also provided an opportunity to push the pause button when it comes to leading a team and focus more on building product and technical leadership.

It wasn’t an easy decision to leave HubSpot after 6 1/2 years. It is a strong company that puts a huge amount of energy into supporting its employees. I am grateful for all the people along the way that helped me as I learned to be a more effective technical leader and product builder. I already miss having many of you one Slack DM away. All of the effort HubSpot engineering put into developer productivity and autonomous teams created an environment where it was easy to build fast while still keeping performance and reliability top-of-mind. The combination of the two makes HubSpot a great place to work as an engineer.

Back to learning a new stack and problem space. Let’s go!

P.S. I am toying around with the idea of rejuvenating my little home on the web. We’ll see how it goes.

Wow! It has been a year since I joined Automattic, a startup with employees scattered around the world working from wherever is most convenient (e.g. their home, a coffee shop, a co-working space, a beach with good wi-fi, etc…). After spending twelve years as a student, a graduate student, an instructor, and an employee at four different universities, the change was more dramatic than I thought it would be. But thanks to lots of support from my wife and colleagues, I was able to adapt and ended up having a bunch of fun, learning a ton, and accomplishing quite a bit.

Fourteen Things I Learned or Experienced

1. Coming to work everyday is easy when you work on a service with millions of users, and on those rare days when it is harder to start cranking, Automattic’s mission to “democratize web publishing” and the creed are strong motivations.
2. “Be the change you want to see.” A couple months ago during the annual Automattic Grand Meetup a colleague suggested that the most effective way to make an impact was to “be the change you want to see,” which was sound advice. Action is a more economical form of communication because the effort required feeds directly into creating something. Believing in your idea enough to build something also shows a level of commitment that is greater than just posting an idea.
3. In the last year, I have made 574 commits to the WordPress.com source code repository, written 188 p2/o2 posts, commented 696 times, and made a couple small contributions to WordPress core. I hope that in the next year I am able to double my code contributions.
4. “It is not what you say, it is what people hear.”  Understanding when the best time to hit publish, reading what you have written from perspectives other than your own, knowing how to communicate the right tone, and figuring out ways to nudge folks to read what you have written are all skills that need constant refinement.
5. Written communication even via IRC or on Skype is more permanent than a face-to-face chat, which makes reflecting back on conversations easy, but it also makes throwing stream-of-conscience thoughts out more risky because everything is “on record.”
6. I now use emoticons and appreciate their value, which I am sure would shock those that have known me for awhile. I also have a better handle on geek slang and memes.
7. It is fantastic that Automattic trusts employees to make good decisions, to recognize mistakes, to correct them, and to learn from them. Transparency in combination with straightforward policies encourages responsible behavior without requiring the overhead and frustrations that come with layers of bureaucracy.
8. Traveling to places like to San Francisco, Hawaii, Chicago, and Rome when I have to leave behind my wife and cute little girl is not as much fun as when I was single, although the time away is offset with working from home and able to watch Abigail when needed.
9. Javascript is the language of the future (and present). Over the last year, I have written more javascript than PHP, and I now have a much better understanding of closures, promises, Mustache, RequireJS, functional programming techniques, HTML5 technologies, and Backbone.js.
10. With both code and communication, reading carefully requires more concentration than doing the same when writing.
11. Knowing when to take the time to create a reusable abstraction is hard, and creating good ones is even more difficult.
12. Understanding when and how to empathize with your users makes it much easier to be confident that what you are doing will delight users.
13. I don’t miss Microsoft Office.
14. It is fun having a book written about your company.

The Big Picture

While I have learned a lot about programming over the last year, much of what I have learned has been about how to work in a distributed environment. It turns out that the process of creating software in a distributed company like Automattic has a lot of similarities with the process of creating and supporting software in large open source projects. In both cases, individual motivation and accountability in combination with transparency and free flowing communication help keep the train running smoothly. The geographic diversity of distributed companies also better reflects the nature and values of the open web than a company where everyone works out of a single office. It is no surprise that companies like Mozilla, Github, Canonical, RedHat, and MySQL are entirely distributed or have a substantial number of employees that work from home.

Looking Forward

In order to get a feel for how my peers felt about my first year, I decided to conduct my own informal “performance review” by sending out an email with a few questions to a group of colleagues. I received lots of great responses that made me both feel good and also challenged me to do even better. So as I look forward to 2014 and consider what I would like to accomplish, I came up with the following:

Dream big.
Do more.
Think hard.
Be nice.

Highlights

1. PHP is still powering a large percentage of the visitor facing portion of the web.
2. Static arrays coupled with an opcode cache are a high performance way to store application configuration data, translations, and other static data required for an application. The benefit is that the data will be loaded pre-compiled from memory so no disk access or network connections will be needed. Etsy uses this technique for both translations and also feature switches.
3. mPulse is a pretty awesome looking realtime performance monitoring and analysis tool. To collect the data, the service uses http://lognormal.github.io/boomerang/doc/.
4. Wikipedia has a new front-end visual editor built using javascript/nodejs that makes heavy use of contenteditable. While there are lots of challenges to bring front-end editing to WordPress, I think that if done right, you can’t beat the user experience of being able to directly edit your content in the proper context.
5. Building around HTTP (usually RESTful) is basically a no-brainer with the UX of native mobile apps winning right now and the future possibilities around the growing “internet of things.”
6. It was nice to hear some positive mentions of WordPress sprinkled throughout including a compliment by Eli White on the newer code in the codebase in his opening keynote. Web apps are increasingly stitched together using various services and WordPress fits into this ecosystem well.
7. Overall, there was not much said about the future of PHP the language. The only exciting thing that I heard was that HipHopVM will likely become part of the main PHP distribution at some point in the future.
8. Don’t be data-driven, be data-informed. Data-driven takes the human out of the equation.

Slides

Looking to the Past, to Predict the Future- Eli White
http://eliw.com/presentations/2013/ne13/ne13.history.pdf

Practical Responsive Web Design – Jonathan Klein (Etsy)
http://jkle.in/rwd

Scaling PHP to 40 Million Uniques – Jonathan Klein (Etsy)
http://jkle.in/nephp

The UX of URLS – Ryan Freebern
http://blog.rnf.me/ux-of-urls/#/

Pragmatic API Development – Andrew Curioso
http://www.slideshare.net/andrewcurioso/curioso-nephp2013

Agile in the Workplace – Mike Stowe
http://www.slideshare.net/mikestowe/agile-in-the-workplace

Dependency Management in PHP: Better Late than Never
http://sequoia.github.io/composer-talk/#/

Don’t Be STUPID, Grasp SOLID – Anthony Ferrara
http://www.slideshare.net/ircmaxell/dont-be-stupid-grasp-solid

Up and Running with Bootstrap
http://www.slideshare.net/jen4web/up-running-with-bootstrap-3

jQuery Mobile: Sites that Feel Like Apps
https://speakerdeck.com/afilina/jquery-mobile-sites-that-feel-like-apps-3

Workshop: Clean Application Development
http://www.slideshare.net/adamculp/clean-application-development-tutorial

Magic Methods: Spilling the Secret – Matthew Barlocker
http://www.slideshare.net/MatthewBarlocker/magic-methods-25338954

Git Essentials – Matthew Barlocker
http://www.slideshare.net/MatthewBarlocker/git-essentials-25347525

UX

You Can UX Too: Avoiding the Programmer’s User Interface – Eryn O’Neil
http://www.slideshare.net/eryno/you-can-ux-too-avoiding-the-programmers-user-interface-nephp-2013

Workshop: Usability Testing for the Common Man – Heather O’Neill
http://www.abovethefolddesign.com/assets/presentations/usability-testing/Usability-Testing-for-the-Common-Man.pdf

Introduction to User Experience Design – Meghan Reilly
http://www.abovethefolddesign.com/assets/presentations/intro-to-ux-design/Introduction-to-UX-Design.pdf

UI Patterns: A Practical Toolkit – Jim O’Neill
http://www.abovethefolddesign.com/assets/presentations/ui-patterns/UI-Patterns-A-Practical-Toolkit.pdf

The big theme was modules and how to best structure code so that dependencies are minimized, concerns are well separated, and unit testing is easier. With the inclusion of modules in ECMAScript 6 and the maturation of nodejs and AMD/UMD/CommonJS, modules are ready for prime time. Now I just need to figure out the best way to incorporate modules into WordPress, which already has a file-based javascript dependency management system.

Tidbits

1. Underscore has lots of super elegant bits that I should take remember to use:

   // Set default key/value pairs if not included in the passed object (options)
   options = options || {};
   _.defaults(options, {
     showFollows: true,
     showLikes: true
   });
   // take certain options and copy the properties to the destination object (in this case this)
   _.extend(this, _.pick(options, methodArray));
   

2. Use an event bus and postMessage() to simplify messaging between parent document and iframe with embedded Backbone App.See http://benvinegar.github.io/backbone-at-disqus-talk/#/42
3. Use requestanimationframe() and _.debounce() to avoid blocking the UI when doing expensive looping operations by chunking the work.
4. Even when using Backbone, it can be very useful to store visual state in the DOM through using classes. It seems obvious in retrospect, but when in a Model-View-Whatever state-of-mind, it is easy to forget to take advantage of the DOM to store view state. This is especially useful for changing the visibility of certain child views in a collection view.
5. Q seemed to be the preferred library for promises.
6. Mocha, chai, and sinon seemed to be the preferred set of tools for writing javascript unit tests.
7. Use promises to fetch data, templates, and any other dependencies in parallel when building up a page in a single-page app to improve the load time of pages.
8. FastClick is a neat library for improving the responsiveness of click events on mobile if you don’t have any double-click events.
9. IndexDB allows a client side app to store much more data than local storage

Slides

• http://benvinegar.github.io/backbone-at-disqus-talk/
• https://speakerdeck.com/backbonerails/little-opinions-big-possibilities-the-tools-and-patterns-for-building-large-scale-backbone-applications
• https://speakerdeck.com/landau/test-driven-backbone-development
• http://bobholt.me/bbconf-bos-2013
• https://speakerdeck.com/mwunsch/the-geologic-time-scale-of-gilt-dot-coms-view-layer
• http://kristoferjoseph.com/Building-Reflow-BackboneConf-2013/
• http://tbranyen.com/talks/growing-up-with-backbone
• http://johnkpaul.github.io/presentations/backboneconf/2013/toasty-plugins/
• http://slid.es/pamelafox/js-ui-library-design
• http://benvinegar.github.io/csp-talk-2013
• https://github.com/asakusuma/backboneconf-deck-2013

After almost 4 years building the BU CMS on WordPress MultiSite, the BU WebTeam, which consists of staff from IS&T and Interactive Design, has decided to release some of our plugins to the broader WordPress community. The first two plugins planned for release tackle some of the workflow limitations that content editors have been asking us to address for a few years.

The Problem

The BU CMS contains quite a few large websites. In most cases, the bulk of the content comprises of pages (the “page” post_type), so a significant percentage of the day-to-day content modifications are updates to published content. Unfortunately, WordPress does not provide any controls for restricting the editing of published content or limiting what content a particular user is allowed to publish, so if a user has the capability to edit one page, they can edit all pages. For sites that have more than 50 editors and over 1,000 pages, the primary site administrators worry that ill-advised changes will be made to prominent content by an editor with less experience or without the authority to make the change. In addition to cracking that nut, we wanted to provide a mechanism for staging an edit to a published page so that the change could be worked on directly (with its own revision history), reviewed, previewed, and scheduled for publication.

After reviewing some of the existing plugins that provide this sort of functionality, we decided to write two plugins to address these problems. Both plugins will be released under the GPL.

Design Goals

• Blend naturally into the existing WordPress admin UI
• Simple to use
• Manage permissions with a full view of all post content
• Perform well on sites with more than 2,000 pages
• Support custom post types

BU Section Editing

The BU Section Editing plugin creates a new role: Section Editor and adds screens for managing groups of Section Editors. Each group is granted access to publish and edit published content for individual pages.

BU Versions

The BU Versions plugin adds functionality for creating an alternate version of pages, posts, or any public custom post type. After cloning the post, editors are able to make and preview changes. When the changes are ready to be published, the user simply clicks “Replace Original” or schedules the replacement. Users that do not have the “publish_posts” capability are able to create and edit an alternate version, which makes an edit, review, then publish workflow possible even when modifying published posts.

We really want to get feedback from other folks using WordPress on large sites, so don’t hesitate to leave a comment on the original post.

Boston University is hosting WordCamp Boston again this year, and I will be giving a talk. I am particularly excited to share some of the plugins that BU has been developing with the broader WordPress community.  Below is the description:

WordPress includes a well-defined workflow for running a blog with multiple contributors in various roles. It works great; But what if you are using WordPress to run a 1,000 page hierarchical site? Well… the workflows available are a bit limited without getting under the hood. For example, WordPress does not define fine-grained capabilities for controlling who can edit published content. As a result, users have to be granted full editing permissions, which increases the chance that a less-experienced user will make an ill-advised change. Drawing from our experience running large Multisite installations, Boston University has developed a couple of plugins to address some of the limitations. And for the first time, we are planning to release our plugins to the broader WordPress community under the GPL.

This talk will include an overview of the role/capability system presented from both a user and developer perspective as well as overviews of the BU Versions and BU Section Editing plugins. Along the way, various insights will be shared that provide a window into how BU has built an effective content management system on top of WordPress.

For more information, visit the WordCamp Boston 2012 website.

Description

For basic content publishing needs, the ease-of-use of WordPress shines. Unfortunately, once a project exceeds 500 pages, using WordPress is much less straightforward. How has Boston University made it work? From a technical standpoint, building relationships between content objects and creating simple to use UIs for managing the relationships is key. Once established, the semantic relationships can be coupled with bits of meta data to construct menus, indexes, facets, filters, and so much more. Using code examples, this talk will highlight essential parts of the WordPress API and demonstrate various techniques used in BU plugins and themes that help us build better large websites.

The slides from the presentation and a link to code for the proof-of-concept are below:

• slides (slideshare)
• code (github)

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Read Matt’s full post…

The default sshd configuration pulls the port information from /etc/services and sets up a listener on that port. The Sockets dictionary is used to let launchd know when to launch the service. The purpose of this system is to speed up the boot process by launching services on demand instead of automatically.

To change the sshd port as means of provide some additional security simply modify /System/Library/LaunchDaemons/ssh.plist and change SockServiceName from “ssh” to the port number you want sshd to use. You also have to modify the Port number in /etc/sshd_config to match the launchd configuration.

<key>Sockets</key>
 <dict>
 <key>Listeners</key>
 <dict>
 <key>SockServiceName</key>
 <string>40000</string>
 <key>Bonjour</key>
 <array>
 <string>ssh</string>
 <string>sftp-ssh</string>
 </array>
 </dict>
 </dict>