Dromomania and the Permanent Traveler

Permanent Traveling is a well-documented Personality Disorder, and there are additional unsavory related compulsions. These people need help.


Ah, the digital nomad. Those who have left the rat race behind, or perhaps they have taken it with them? Digitized its essential nature? Is in fact a symptom of the problem and not a purported cure? Perhaps this behavior is better understood, as it should be, and has been, documented since the late 19th century.


The compulsion to travel, as it is manifested in the disorder known as Dromomania, also called Traveling Fugue: an uncontrollable psychological urge to wander.

More generally, the term is sometimes used to describe people who have a strong emotional or even physical need to be constantly traveling and experiencing new places, often at the expense of their normal family, work, and social lives. —Wikipedia

As one who lives in a place known for these itinerant travelers and wandering digital workers, their rather odd behavior makes a lot more sense from the perspective of a compulsive mental disorder. First, though, we have to disassociate the behavior from the pretty wrapping and trappings of a fantasy of getting away from the mundane world, and living in exotic locations, but without actually settling down there. The life of the hobo has held sway over romantic (the literary movement, not the psychological state) notions of nature and escape from civilization.

So what other compulsive or dysphoric traits and conditions persist?


One such is living as cheaply as possible – Miserliness. Technically this is Obsessive-Compulsive Personality Disorder-related Frugality — what Freud called the anal-retentiveness or a problem with toilet training. For example, all-day Internet access purchased for the cost of a single cup of coffee. Yes those squirming digital itinerants are squirming about more than their dose of caffeine or digitalia.


Another disorder is Hypergraphia, an intense desire to write. But not only write as in a private avocation but public writing, or picture taking (or a combination) combined with a strong desire to popularize this material, if even among a set of acquaintances.


This is a sort of literary Exhibitionism, albeit perhaps without malicious intent. What is exhibited, besides the physical writing or picture taking (moving and otherwise), is not so much a sexual organ, but something akin to the organ of travel, and its related erogenous zones.

Dietary Exhibitionism

As is now well-know, the obsessive-compulsive disorder to photograph and display the undigested contents of ones meals has become increasingly common. The memorializing of the most trivial thing as lunch, is sad indeed. It well may be related to expeditionary travelogues and the digital nomadic lifestyle, as by itself it may constitute an uncontrollable urge to wandering in miniature: Gastronomic wandering, the wandering of the stomach.

Dromomania and the Permanent Traveler originally published at mcneill.io


Mary Meeker – Internet Trends – ReCode Conference 2016

Takeaways – Macro and Micro

It was great to get some macroeconomic trends in this year’s report, so we can see not only inside the industry but externally. And folks, it does not look good for many.

  • 3bn global internet users, growth flat at 9%, decelerating if exclude india
  • Global smartphone users slowing, 21% vs. previous 31%, shipping units up 10% down from +28%
  • GDP growth slowing, commodity prices down
  • Emerging Asia + China is 2/3rd of global growth
  • Debt loads on governments are growing faster than GDP, global debt is a problem
  • Population growth slowing, 1.2% per year
  • Adjusting to slower growth, rising debt, and an aging population introduces risk
  • US Internet Advertising is accelerating, up 20% vs. 16% the previous year
  • Google and Facebook accounted for 3/4s and rising share
  • Internet ads largely ineffective, especially video. 81% of users mute their ads.
  • 420 million users use ad blocking software on mobile, up 100% year on year
  • Great ads on snapchat: authentic, entertaining, in-context, and brief
  • Millennials, largest generation in the US, 27% of population
  • The messaging secret sauce is the magic of the thread, conversational, remembers identity, time, specifics, preferences, context
  • Voice interface improving
  • We may be entering a second golden age in the automotive industry, to be determined

Slides from Mary Meeker’s Internet Trends Report


Remarks about WordPress Development Lifecycles

This is a set of notes and remarks rather than anything comprehensive or systematic. The main point is learning from the fact that there is a development lifecycle in terms of consuming software products, and make better adoption decisions through a set of heuristics.

By development, we need of course to expand this to encompass what is generally known as design, development, devops, sysops and ongoing maintenance. The key to reducing risk in WordPress development is to understand the lifecycle.


WordPress Development

By WordPress development, we can include all of the following:

  • Selecting a new theme or theme framework
  • Making a choice between plugins
  • Deciding at what point custom development is needed
    • Themes
    • Plugins
  • Hosting decisions
  • Security issues
    • hosting and operating system configuration
    • security plugins
    • secure plugins

Obviously the term development is being used in its very generic sense. Still, we can separate it from marketing and from content, which are the two other legs of the WordPress three-legged stool we use as a platform for publishing.

Development Lifecycle

By lifecycle we understand that there is birth, growth, decline, and death. Development itself can be understood as the building up of something. We usually understand development as a period of time for building and a period of time for maintaining. This is obviously an architectural metaphor. However, it is really not useful or apt when looking at software development. Why is that?

  • Software can be refactored
  • Software can be loosely coupled or integrated with other software
  • Software versions are released over time, which tends to include more features
  • Software can become obsolete when it is rendered incompatible with other systems, software, or coding practices
  • Software can become unusable when new versions introduce new problems
  • Software can become a greater risk to use when it is abandoned by its original developers

Finally there are financial considerations such as when free versions of critical plugins or themes are no longer available, forcing all users to pay or to spend considerable time migrating to others.

Risk Management

All of this comes down to the basic concept of risk management. Risk is danger to an organization, in terms of the likelihood and severity of present or future costs. While deciding which plugin to use for a contact form seems fairly innocent (and generally it is), things like multilingual, ecommerce, or elearning systems require a much greater investment in installation, configuration and maintenance, with much higher switching costs.

Lifecycle Heuristics for WordPress Development

Because a lifecycle deals with unknowns in the future, it is never perfect and there is always risk. However, there are certain heuristics — rules of thumb — that can be used to help mitigate and minimize risk. The following are an assortment of heuristics that, while not always accurate, do help minimize risk.

WordPress Theme and Theme Framework Heuristics

Most themes are not maintained for long. The average half-life of a theme (the amount of time by which the probability of it being abandoned is 50%) is most likely immediately after the first version is released. Many try to minimize this risk by paying for a theme, but the same is true of paid themes.

Theme frameworks have a much longer lifecycle, as they are made for designers and developers who will pay maintenance fees in order to get some stability and continuity. Regular subscription fees are a motivator for theme frameworks to incrementally improve and maintain compatibility with the every changing panoply of plugins as well as WordPress core (which has major releases three times per year).

However, yearly maintenance fees do not remove all risk, and the lack of yearly maintenance fees are not a sign of impending abandonment. Ultimately, one should consider any theme framework from the perspective of the following question:

If this framework is abandoned tomorrow, will it meet my needs and is it worth whatever maintenance I need to do myself, for the next two years or more?

Since a framework will eventually be replaced (i.e., it has a lifespan, and is not immortal), risk management consists of a clear-eyed assessment of the functionality vs. maintenance costs (in time and money) as well as opportunity cost for going with a different system.

Ultimately, one should build one’s own theme and child themes. The risk of course is building something that does not meet present or future needs, and/or is too time-consuming to maintain. Several years working with other themes and theme frameworks for a given website or set of websites are the ideal approach to understanding the design space. Indeed, working with an incomplete or aging theme framework can be extremely informative in terms of producing a set of requirements for a theme and child themes that will provide excellent value for years to come.

Some of the following may help flesh out the requirements from a functionality perspective:

  • No javascript or gracefully degrades without javascript
  • Support for screen reader CSS
  • Responsive design with target viewport dimensions
  • Plays nicely with all current plugins, especially those with important functionality, e.g.,
    • WooCommerce
    • ALO EasyMail Newsletter
  • Can potentially replace one or more plugins where that makes the most sense, e.g.,
    • Custom search and 404 pages
    • Remove author pages
    • Custom templates that display lists of all posts organized by category
  • Single CSS file

WordPress Plugin Heuristics

Plugins are a boon and a bane in WordPress. One needs many of them (some for a single tweak here or there to WordPress Core), they constantly age and require updates, are abandoned, conflict with one another and with new versions of WordPress Core. Here are a few heuristics that might help with risk management:

  • Older, massively popular plugins are in general a better bet (even if abandoned), because the large userbase will come up with fixes when problems arise.
    • There is one huge caveat to this, and that is monolithic plugins that continue to add features. This usually means ongoing problems and the introduction of new bugs. Yoast is the biggest poster child for a very popular plugin that breaks continually over the years.
  • Simpler plugins rather than more complex (best-of-breed vs. all-in-one)
  • Plugins that operate with shortcodes rather than wysiwyg drag-and-drop interfaces
  • Plugins whose configuration is stored properly in custom tables or extending custom posts and metadata
    • Examples include Redirection and ALO EasyMail Newsletter
  • Using custom posts, metadata and shortcodes makes the functionality more abstracted and does not require the front-end to use parameters such as ?variable=value
  • Plugins which, if removed, either degrade gracefully in terms of the content or data left behind, and/or are easy to work with using regex search-and-replace (e.g., unique shortcodes)
  • Plugins which do not have a pro (paid) version
    • Plugins which have a core part that is free and additional plugins that are paid are a better source of stability and risk minimization, as the core part needs to be maintained in order for the paid plugins to remain viable
  • Plugins with active development (even if sporadic)
    • That said, some of the most important plugins I rely on have not been updated for years (occasionally requiring I do a little hacking)
  • Plugins made by a supergenius who uses the plugin themselves (note the supergenius requirement, along with dogfooding)
  • Plugins around which an ecosystem has formed to extend and enhance
  • Plugins that use or can interact with the latest security standards and configurations
  • Plugins where support on WordPress.org is available (rather than requiring using an offsite system for help and support)
  • Ratio of 5 stars to 1 star reviews (should be around 10:1, whereas when it gets around 4:1 this signals poor quality)
  • Retention rate (Active installs / All time downloads)
    • Note that over time this ratio gets smaller naturally, so for very old plugins this doesn’t work, but for 1-3 year old plugins it is a good indicator

In some cases a set of plugins need to be replaced because of a need (or opportunity) for speed and/or security and/or functionality. For example, Postman SMTP allows for OAuth2, a new security standard. But this has knock on effects in that some Newsletter plugins don’t support this, so it would require migrating to a new newsletter plugin. So a final heuristic is keeping up with good coding practices (without simply embracing every new (not necessarily good) idea.


Originally published at https://mcneill.io/wordpress-development-lifecycle/

Release Cycles and Lifecycles

Release Cycles and Lifecycles of software (and hardware) are interesting. How these releases are structured, who does them, and the planning and development process is fascinating from a rollout-of-features perspective. Development release cycles can also be applied to services.

Operating System Release Cycles

Of course we know how Microsoft is getting into trouble with their multi-year release cycle. Apple seems to beat them quite handily with a yearly release, but that is about hardware more than anything. My current comment on Apple’s OS is that it is pretty much like Microsoft, in that we get shitty releases, some patches, and then a better version (or not) in a year. Everything post-Lion has been a huge disappointment, little gadgety enhancements notwithstanding. The fact that the designer guy has had a complete run over Safari, not to mention Safari’s lagging technical chops should indicate how the helm of the software shop is undermanned, to say the least.

In any case, the 6-month release cycle of Fedora and Ubuntu is a pretty good timeframe (for an operating system). Of course Fedora server and Ubuntu LTS versions have a longer and different lifecycle due to stability and security issues.

Application Release Cycle

The 4 month WordPress release cycle is good for fairly complex applications (server or desktop/mobile). It should be obvious that bug fixes and point releases should be liberally sprinkled in to keep everyone aware of the relevance of an application (or operating system). They key of course is to provide value (not introduce new bugs), definitely squash current bugs, and of course security updates.

Unfortunately most organizations don’t do this well. Two recent examples spring to mind. CyberDuck’s MountainDuck which was a poor attempt at copying Transmit’s Disk functionality — and broke the base CyberDuck application functionality every other release or so. As well, the OSX implementation of CloudMagic, which also went on a yo-yo of implemented and broken functionality. (CloudMagic is a silly name, and ultimately a failed approach which is to remove information and the advantage of a large screen, essentially upsizing (slightly) the iOS app.)

Release Cycles and Professional Services

Release Cycles can be implemented in ongoing professional services. The key is to provide visible value (even if only conceptual) rather than a monthly task list and invoice. Here is a sketch of how one might approach this, with new and current clients.

  • Begin with a version 0.1 which is a baseline, where we are
  • If one has already been at work for 4 months or so, stretch back that amount of time. (April, August, and December are good months to have releases in.)
  • Next major release is in the next month. Note that a major release doesn’t have to have major changes, just a numbering to put a stake in the ground and indicate a milestone for measurement.
  • Now that there is a release cycle, one can put some structure around that (known process)
  • Finally, add items to the development roadmap which consists of the major releases (and their point releases).
  • Of course weekly meetings, email, chat, and wiki work should always take precedence, but now there is a set of time horizons around which to structure discussions.

Originally published at mcneill.io/release-cycles/

The future of Web development isn’t MVC, it’s MVM

Yes, finally MVC Smalltalk discussion, thanks!

Dan Newcome, blog

When Ruby on Rails hit the Web development world in 2005, it changed everything practically overnight by bringing a pattern rooted in Smalltalk to the Web. I’ve been playing with the recently-released Meteor Web framework and I think that an important and equally momentous shift is taking place in the Web world.

It started with Node.js

More recently, Node.js changed everything again with the idea that the Web could evolve beyond the model where every request/response pair was fully cached on the server before processing was complete. Unfortunately for all of the interesting new possibilities that Node offered it was pretty low-level if you were coming from a mature Web framework.

Node allowed you to write Web services that were difficult or impossible to write previously. Streaming services that made long-running connections and broadcast-style chat apps became trivial to write instead of requiring lots of tweaking and custom server configurations.

View original post 598 more words

De-Institutionalization of Education

This brief report could just as easily be called The Status of Education 2.0 but I think we are over this versioning. What is really at work is a de-institutionalization of education as an institution. What we are witnessing is the reorganization of learning outside of the organizing principles of the Medieval University.

The Education of Achilles

Institutional Decline

While still quite revered and heralded as a place of learning and innovation, there is serious institutional decline in the university in general. While one can always point to exceptions and exceptional institutions, the organizing principle of higher education (along with that of medicine and the modern hospital) has been in serious decline for perhaps 30 years. Without point to obvious actors involved in this kind of institutional malaise, suffice it to say that these institutions are incapable of meeting the increasingly dynamic needs of individuals and organizations. This is part and parcel of the increasingly information-intensive nature of work in general.

The Internet of Learning

At the same time as educational institutions have provided largely ineffective, if any, response to the increasing needs for learning in general, information and communication technology has proliferated. This has the salutary effect of providing a different kind of space for co-presence, collaboration, and the dissemination of information. The very nature of the medieval university is founded in a physical place where experts and apprentices were gathered together. The Internet and its various communication technologies can provide virtually the same space, but at a much reduced cost and with a much greater reach.

With the decline of institutions and the increase in communication technology that is not tied to the institutions or to physical locations, learning and education will naturally leak out of institutions and into spaces forged with information and communication technologies.

Current Status of De-institutionalized Education

There are several trends which will likely accelerate as quasi-institutions (organizations collaborating together to deliver learning and education) continue to develop these new learning spaces and develop functional education systems.

  • Professional schools that provide intensive training (at a high price) and deliver skilled and employment-ready graduates. Example Hack Reactor 12 weeks, full time, in-class, ~17,500 USD
  • So called Nano Degrees, essentially certificates which take a year or so to complete. Example Udacity 1 year, part time, online, ~2,500 USD
  • One week or less bootcamps which focus on a particular, somewhat narrow topic/skill. Example Coded Online 2 days, full time, online, ~500 USD
  • Online courses with content that free or premium with unlimited access or monthly. Examples Learning Indonesian unlimited, part time, online, ~150 USD; Udacity Web Development course Monthly (about two months, could be shorter), online, 150 USD/month
  • MOOCs (massive online open courses) are still quite popular and are from a few weeks to a few months in length. These are generally free or inexpensive.
  • More open learning platforms such as Udemy which has found a good niche in enabling the creation of online courses by any expert (or so-called expert) and social ratings to help filter out low quality content. Note that by offering free courses, many people may improve their social reputation and help create additional revenue streams. Example Udemy a few days, weeks or months, part time, online, free to 500 USD.
  • Skill sharing sites, which tend to be the same as open learning platforms, but very low quality (for anyone with Seth Godin or Guy Kawasaki as premiere contributors, the 1990s are calling and want their bubble boys back). Some amount of money, some amount of time, best to ignore these.

via Jeff McNeill http://ift.tt/1qZg15B

Adaptive vs. Responsive vs. Multi-Platform

These misleading terms Adaptive and Responsive don’t matter much, but rather the result which is an experience of the user (and higher conversion rates) across various platforms (including operating systems, browsers and screen resolutions). For authors and publishers (both book and web formats), design is a rather important topic. Hardcover, paperback, ebook, web are physical/digital format issues (not to mention pricing/paywall discussions). But the real question is does the content (information) and how it is presented (design) change based on device, platform, or screen resolution.

Veiled Chameleon

What Matters in Adaptive and Responsive Design

We at Parliament Press have a slightly different take. First, we need to clearly understand what decisions need to be made, and what changes to implement, and finally, how to really think about device proliferation and ubiquity.

Design Complementary Experiences

Complementary experiences can indeed be identical. But they should at the least inform each other. Recall with experiences we want to reinforce and enhance a brand. Therefore do not contradict expectations which one platform has created. A big example of this is the fragmentary and contradictory experience for Bloomberg apps and website. It is obvious that entirely different teams created these various apps and they likely took as a goal the desire to not duplicate or even enhance what one platform provides in terms of navigation, interface, and information.

Start with a Single Design for All Platforms

The exercise of designing for all platforms makes it abundantly clear where the boundaries of usability and information consumption is. Tradeoffs should be made to provide a reasonable experience at the smaller mobile screen sizes, while having a reasonable experience at the most common desktop display sizes. Mobile should have the slight preference here, since it is the growth platform. This will also help make less is more decisions on removing clutter from the interface.

Learn from Actual Navigation on Different Platforms

Look at how the different platforms in terms of operating system, browser and screen resolution are consuming the content, then take that as the point of departure for special design, however implemented, for different platforms.

Client-side vs. Server-side Customization

Obviously everything comes from a server, but Client-side customization is use of CSS and Javascript only rather than a distinct template (with unique HTML) being served to unique platforms. It doesn’t really matter, per se, as long as there is a good amount of accuracy, that is specific platforms delivered specific content. This is an implementation detail that is best hashed out in the back room between developers and administrators. Ultimately unique content (inclusion or exclusion of content) based on a platform (operating system, browser type, screen resolution) should become not only possible but used in all cases where that makes sense, in terms of increasing conversions.

Multi-platform Design (MPD)

The words Responsive and Adaptive should in all cases be eschewed for a category that is descriptive to its end goal, that is multi-platform. And because three letter acronyms are all the rage, we can call this MPD.

In discussing MPD, we don’t actually focus on this, but rather use the language of mobile. Not mobile first but rather mobile friendly. If a site is mobile friendly, visitors can achieve their goals in the same way as on another platform (desktop/laptop). That is the first step toward multi-platform design. Second is having a feedback loop of mobile friendliness into the design in general. What happens in this process is that design elements and constraints shift from being one platform, then another platform, then a third platform, to that of multi-platform-ness.

via Jeff McNeill http://ift.tt/1xSwME4