Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Tuesday, August 21, 2018

Churches (& synagogues) and "When Growth Stalls" by Olson, Bever & Verry

(Please read "church" to include "synagogue.")

This post is about how to increase church membership, over the long and medium haul. Doing so, I believe, inevitably will require churches to attract the Millennial generation—at least some of them—into membership. (Millennials are people born 1982 through 2004.)

In light of that goal, for most mainstream churches, the following, interesting article (quoted for review purposes) is relevant:

"When Growth Stalls", Matthew S. Olson, Derek van Bever, Seth Verry, 2008-March

adapted from the book:

Stall Points: Most Companies Stop Growing—Yours Doesn't Have To, Matthew S. Olson, Derek van Bever, 2008-April

Although truth often is our adversary, it's also our friend (of course). Only by keeping abreast of it, can we securely craft a winning strategy. Please don't feel that this post merely adds insult to injury!

ARTICLE EXTRACTS BEGIN

[A] growth stall [is] a crisis that can hit even the most exemplary organizations. [Characteristic] is the stall's suddenness. [M]ost organizations actually accelerate into a stall, experiencing unprecedented progress along key measures[,] just before growth rates tumble. When the momentum is lost, it's as if the props have been knocked out[,] from under their corporate strategy....Typically, few on the senior team see the stall coming; core performance metrics often fail to register trouble on the horizon.

As part of our ongoing research into growth, the Corporate Executive Board recently completed a comprehensive analysis of the growth experiences of some 500 leading corporations in the past half century, focusing particularly on "stall points"—our term for the start of [long-term] reversals in company growth fortunes[.] The study revealed patterns in the incidence, costs, and root causes of growth stalls.

[T]he vast majority of stall factors result from a choice[,] about strategy or organizational design. They are, in other words, controllable by management. Further, even within this broad realm, nearly half of all root causes fall into one of four categories: premium-position captivity, innovation management breakdown, premature core abandonment, and talent bench shortfall.

In this article we'll offer advice for avoiding these hazards, drawing from practices currently in use at large, high-growth companies[,] to foresee possible stalls and [to] head them off. More generally[,] we will explore why management is so often blindsided by these events. As we will show, a large number of global companies may at this moment be perilously close to their own stall points. Knowing how to avoid growth stalls begins with understanding their causes. Let's look at each of the four categories[:]

When a Premium Position Backfires

By far the largest category of factors responsible for serious...stalls is what we have labeled premium-position captivity: the inability of a firm to respond effectively...to a significant shift in customer valuation of product features.

We use the term "captivity" because it suggests how management teams can be hemmed in by a long history of success. A company that solidly occupies a premium market position remains insulated longer than its competitors against evolution in the external environment. It has less reason to doubt its business model, which has historically provided a competitive advantage, and once it perceives the crisis, it changes too little[,] too late. When the towering strengths of a firm are transformed into towering weaknesses, it's a cruel reversal.

In documenting premium-position captivity in leading enterprises, we saw a cycle of disdain, denial, and rationalization that kept many management teams from responding meaningfully to market changes.

In [some] cases,...organizations...simply don't recognize the importance of an emerging...customer preference in their core markets. They continue to place their bets on product or service attributes that are in decline, while disruptive entrants emphasizing different, underrecognized features gain ground.

Easiest to spot in marketing data are pockets of rapid market share loss, particularly in narrow customer segments, and increasing resistance among key customers[.]

When it comes to management attitudes, your ears may pick up the strongest clues: Listen closely to the tone in the executive suite when conversation turns to upstart competitors or to successful rivals that are viewed as less capable. Is it acceptable, or routine, to dismiss them as unworthy? Do your processes for gathering intelligence about your competitors ignore some of these market participants because of their...perceived lack of quality? Indulging in such behavior is common, but it's a luxury that no market leader can afford.

When Innovation Management Breaks Down

The second most frequent cause of growth stalls is what we call innovation management breakdown: some chronic problem in managing the internal business processes for updating existing products and services and creating new ones. We saw manifestations of this at every major stage along the activity chain of product innovation, from basic research and development to product commercialization.

Where...growth stalls could be attributed to innovation breakdown, the problems emphatically did not center on individual product launch failures[.] By contrast, the [long-term] growth stalls we identified were attributable to systemic inefficiencies or dysfunctions. [W]hen things go wrong here—at the heart of these organizations' most important business process—extremely serious, multiyear problems result.

As we looked at the variety of ways in which problems in the innovation management process can eventually produce major...stalls, we were struck by the fragility of this chain of activities, and by how vulnerable the whole process is to management decisions made to achieve perfectly valid corporate goals.

When a Core Business Is Abandoned

The third major cause of...stalls is premature core abandonment: the failure to fully exploit growth opportunities in the existing core business.

The two most common mistakes we saw in this category were [1.] believing that one's core markets are saturated[;] and [2.] viewing operational impediments in the core business model as a signal to move on to new, presumably easier competitive terrain.

Just as interesting as getting it wrong on core business growth prospects is the tendency of executive teams to simply give up on apparently intractable problems in their core businesses.

Of all the red flags signaling stall risk, one of the most obvious is management's use of the term "mature" to refer to any of its product lines, business units, or divisions....Established businesses should be managed against significant revenue and earnings goals, and business leaders should actively explore the potential of new business models to rejuvenate even the most "mature" businesses.

When Talent Comes Up Short

Our fourth major category is talent bench shortfall: a lack of leaders and staff with the skills and capabilities required for strategy execution.

Few companies formally monitor the balance in the executive team[,] between company lifers and newer hires who offer fresh perspectives and approaches. Furthermore, large companies have a fairly poor track record on incorporating new voices into senior management....And management development programs all too often focus on replicating the skill sets of the current leadership, rather than on developing the novel skills and perspectives that tomorrow's leaders will need[, in order] to overcome evolving challenges.

We have identified a simple way to ensure balance in the senior executive ranks...Our analysis...suggests that the sweet spot for external talent is somewhere between 10% and 30% of senior management.

When What You Know Is No Longer So

One culprit in all our case studies was management's failure to bring the underlying assumptions that drive company strategy into line with changes in the external environment—whether because of a lack of awareness that the gap existed or was widening, or because of faulty prioritization.

The lack of awareness is particularly vexing, because it is so insidious. Strategic assumptions begin life as observations about customers, competitors, or technologies that arise from direct experience. They are then enshrined in the strategic plan and translated into operational guidance. Eventually they harden into orthodoxy. This explains why, when we examine individual case studies, we so often find that those assumptions the team has held the longest[,] or the most deeply[,] are the likeliest to be its undoing. Some beliefs have come to appear so obvious that it is no longer politic to debate them.

Articulating and Testing Strategic Assumptions

What could the company's senior managers have seen in their markets, in their competitors' behavior, in their own internal practices, that might have alerted them to an impending stall? We looked at our detailed case histories for warning signs before the stall point that perhaps hadn't received the scrutiny they deserved, and uncovered 50 red flags, all rooted in the real experience of the companies we studied. Our 20/20 hindsight may enable you to spot signs faster in your own organization[:]

Red Flags for Growth Stalls

Below is a sampling of red flags....To the extent that your senior team and high-potential managers see these as areas for concern, you may be headed for a free fall[:]

  • Our core assumptions about the marketplace[,] and...our strategy[,] are not written down[;]

  • We haven't revisited our market definition boundaries, and [also] therefore our list of current and emerging competitors, in several years[;]

  • We haven't refreshed our working definition of our core market, and [also] therefore our understanding of our market share, in several years[; and]

  • We test only infrequently for shifts in key customer groups' valuation of our product/service attributes.

Also included in our tool kit are four practices[,] drawn from those [which] we've seen management teams use. The first two are effective in making strategic assumptions explicit, and the latter two are designed to test those assumptions[,] for ongoing relevance and accuracy[:]

  1. Commission a core-belief identification squad

    This practice is simple to execute and involves calling on a diverse, cross-functional working group to go hunting for the firm's most deeply held assumptions about itself and the industry in which it operates....The best-functioning squads include a significant share of younger, newer employees, who are less likely to be invested in current orthodoxies.

    Their efforts are most fruitful when the team is prepared to raise thorny issues and challenge entrenched beliefs, using methods ranging from reality checks—["] What industry are we in? Who are our customers? ["]—to more provocative explorations: ["] What 10  [ (ten) ]  things would you never hear customers say about our business? Which firms have succeeded by breaking the established 'rules' of the industry? What conventions did they overturn? ["]

    One leading...company told us that it had used this practice to kick off an inquiry into long-term growth pathways[,] and to challenge conventions that had taken hold through the years.

  2. Conduct a premortem strategic analysis

    Many leaders have found it useful to charge teams with developing competing visions of the future success—or failure—of the company[,] as it would be reported in a business periodical five years hence....By seeing which issues the scenarios have in common, leadership teams can identify the subset of core beliefs that should be most closely examined and monitored.

  3. Appoint a shadow cabinet

    [as in the British Parliamentary system, in order "to discuss alternatives to current strategy(,) and (to) look for red flag indicators." — per comment:

    "Learning from Failure—the Competitive Advantage of Silicon Valley", Ian D. Griffin, 2009-March]

    [B]ecause senior executives are usually most attached to the assumptions underlying current strategy[,] they find the fresh perspectives offered by this creditable, well-informed constituency extremely valuable.

  4. Invite a venture capitalist to your [periodic] strategy review

    An effective way to bring an external perspective to bear on strategy assumptions is to ask a qualified venture capitalist to sit in on...strategy and investment reviews and probe for potential weaknesses. The benefits for...managers come...generally from the practical, payback-focused lens that the VC brings to the review.

    [ (Instead of a venture capitalist, more appropriate for a church may be an outside expert.) ]

Renewing Competence in Strategy

What gives force to our advocacy is that growth stalls can have dire consequences: They bring down even the most admired companies; they exact a sizable financial and human toll; and their impact may be permanent. After a stall sets in, the odds against recovery rise dramatically with the passage of time.

Compounding this urgency, all signs point to an increasing risk of stalls in the near future. Of particular concern today is the shrinking half-life of established business models. The importance of spotting change[,] early enough to react in time[,] is rising exponentially. The practices we outline here create that early-warning capability. As critical, they make the strategy conversation ongoing[.]

Whatever other concerns are on the strategy agenda, guarding against growth stalls should be at the top. The tools we offer will enable the executive team to continually test the accuracy of its worldview and to flag any flawed assumptions that might trigger a stall[,] if they go uncorrected.

END OF ARTICLE EXTRACTS

Copyright (c) 2018 Mark D. Blackwell.

Tuesday, September 23, 2014

Visual project design & reporting & Pivotal Tracker with add-ons

UML

Some business owners wish to see diagrams which can explain the software structure of a project visually. In those cases, UML is a good choice:

  http://en.wikipedia.org/wiki/Unified_Modeling_Language
  http://en.wikipedia.org/wiki/Applications_of_UML

The following (kinds of) UML diagram are useful for that purpose:

  http://en.wikipedia.org/wiki/Activity_diagram
  http://en.wikipedia.org/wiki/Component_diagram
  http://en.wikipedia.org/wiki/Sequence_diagram
  http://en.wikipedia.org/wiki/Use_Case_Diagram

VISUAL PARADIGM

Often, business owners are attracted to the tool, Visual Paradigm. Unfortunately, it is quite expensive.

The tool itself isn't web-based, but the company (free of charge) offers VPository, cloud storage for developers working collaboratively.

IMO, a download for each user is fine in itself if the project data is shared.

Its Professional Edition is the minimum practical level to obtain the features which business owners often are interested in: Requirements Gathering ("uexceler"), Task Management, and Wireframes.

Regarding Visual Paradigm's cost factor, they levy a surcharge to receive bug fixes for their software. (Like all software, I suppose it's buggy.) Therefore, currently the Single Seat License for the Professional Edition is really $838.50 per person (= $699 + $139.50). Floating Licenses—for transient project contributors—are $1,090.00 each (= $908.50 + $181.50. All prices are in US dollars.).

Maybe using Visual Paradigm is really taking things too far.

Basecamp can maintain a project glossary as a versioned, editable file.

For most projects, the database schema diagram can be auto-generated (at least once) and stored in Basecamp.

Perhaps User Stories, and images for each wireframe block, can be tied together in some easy fashion (see "Add-ons adding pictures to User Stories", below).

TOOLS SIMILAR TO VISUAL PARADIGM

I came across this list of tools similar to Visual Paradigm. Of them, the following might be useful:

  http://www.gentleware.com/uml-software-community-edition.html
  http://www.modeliosoft.com/en/products/features.html
  http://www.softwareideas.net/en/features/

PIVOTAL TRACKER

Because Pivotal Tracker is quite successful (or popular), people have contributed quite a large number of add-ons:

Add-ons adding pictures to User Stories:
  http://blog.snapengage.com/2010/03/pivotal-tracker-snapashot-integration/
  https://trackduck.com/en/content/integrations/pivotaltracker/
  https://usersnap.com/pivotaltracker

Add-ons adding User Stories from plain text:
  https://github.com/gabehollombe/Pivotxt
  https://github.com/hashrocket/slurper

Add-ons dumping User Stories:
  https://gist.github.com/glarrain/5861055

Add-ons for bugs:
  http://bugdigger.com/pivotal/
  http://bugherd.com/blog/bugherd-and-pivotal-tracker-best-of-friends/
  http://www.redline.cc/

Add-ons for reporting:
  https://www.dashofagile.com/pivotaltracker
  http://www.easy-insight.com/solutions/PivotalTracker.html
  https://github.com/jimlindstrom/Tracker-Dashboard
  https://www.in-sight.io/
  http://www.just-facts.co/#tabs-services
  http://support.leftronic.com/customer/portal/articles/1120034-create-a-pivotal-tracker-dashboard
  https://www.leftronic.com/services/pivotal-tracker/
  https://www.prodpad.com/2013/05/integrate-with-jira-trello-and-pivotal-tracker/
  http://apps.splunk.com/app/1584/
  http://start-software.com/tracker/modules/tracker-dashboard/
  https://www.tenxer.com/how/
  https://www.tenxer.com/what/
  http://www.timecamp.com/blog/index.php/2012/11/
      log-time-on-a-story-card-in-pivotal-tracker-and-timecamp-integration/


Add-ons for testing:
  http://www.gurock.com/testrail/
  http://www.testlodge.com/

Add-ons liaising other sites with Pivotal Tracker, also with Basecamp:
  http://www.redline.cc/
  http://www.testlodge.com/
  https://trackduck.com/en/content/integrations/basecamp/

Add-ons liaising with Cucumber:
  https://github.com/tpope/pickler

Add-ons liaising with GitHub:
  https://github.com/getvega/Pivothub
  https://github.com/stevenharman/git_tracker
  https://github.com/zauberlabs/gh-pivotal-integration

Add-ons liaising with Redbooth:
  https://help.redbooth.com/hc/en-us/articles/200752732-Pivotal-Tracker-Integration

Add-ons liaising with Redmine:
  https://github.com/capita/redmine_trackmine

Other relevant add-ons:
  http://blog.aha.io/index.php/aha-integrated-with-pivotal-tracker-for-visual-product-roadmaps/
  http://blog.busyflow.com/2012/01/16/the-benefits-of-a-deep-pivotal-tracker-integration/
  https://github.com/bimovidia/planning-poker
  https://github.com/joncooper/lorem-tracker
  https://github.com/nathanmcdaniel/pivotalstuff/tree/master/viewallmywork
  https://chrome.google.com/webstore/detail/
      clone-stories-for-pivotal/mpaldiblbgdmmnolghhbohicignfhimb

  https://chrome.google.com/webstore/detail/
      easy-copy-for-pivotal-tra/mmlaaianjmomeolpmmhdcmjnnmmoalbh

  https://code.google.com/p/mastercontrol/
  http://hojoki.com/
  https://www.honeybadger.io/
  http://sluglug.com/
  https://storymapper.io/

OTHER POSSIBLY INTERESTING PLANNING TOOLS

  http://www.clarizen.com/project-management-solutions/agile-project-management.html
  http://www.clockingit.com/screenshots
  http://www.goplanapp.com/home/features
  http://www.huddle.com/product-overview/
  http://leankit.com/product/
  http://www.mangoapps.com/features
  https://www.planbox.com/tour/
  http://planship.com/
  https://pmrobot.com/features
  http://www.strikebase.com/
  http://www.thymer.com/why/
  https://trello.com/
  https://www.ubirimi.com/
  https://www.ubirimi.com/product/agile
  https://www.ubirimi.com/product/documentador
  https://www.ubirimi.com/product/yongo
  http://www.versionone.com/product/agile-collaboration-tools/
  http://www.versionone.com/product/agile-visualization/
  http://www.webplanner.com/site/index.php
  http://wholemeal.co.nz/projects/fulcrum.html
  http://www.zoho.com/

TRACK DUCK

Track Duck (highly popular) allows people to add comments to any website, after it automatically takes a screen shot.

Track Duck integrates with Pivotal Tracker and Basecamp, etc.

With it, one easily can add (one or multiple) images to Pivotal Tracker User Stories, and also create images for Basecamp. But see other "Add-ons adding pictures to User Stories", above.

Reviews of Track Duck:
  http://techcrunch.com/2014/02/17/
      trackduck-a-tiny-web-site-build-tracking-startup-appears-to-be-on-a-roll/

  http://goaleurope.com/2014/02/04/
      lithuanian-trackduck-launches-new-version-of-its-interactive-website-feedback-tool/


Copyright (c) 2014 Mark D. Blackwell.

Wednesday, July 3, 2013

Use Ruby-like Mirah to develop for Android

I have minimal experience in Android development—I have set up its development environment and merely compiled something that another has written. I work mainly in Ruby on Rails.

However, for the intrinsic joy from developing something on an Android device, I'm particularly interested in the language Mirah created by Charles Oliver Nutter (the developer of JRuby). I keep Mirah in mind, for whenever it will become practicable to use in Android development.

Perhaps Mirah is ready now—a Google search shows plenty of people using Mirah on Android.

Back in 2011, Nutter wrote an article about Mirah in Dr. Dobb's Journal. To sum up, this is a Ruby-like language designed in such a way that, for any program feature (or user feature) a programmer desires to implement, she would create a new keyword or plugin for the language (somewhat directly in the compiler—this being Mirah's main point of departure) rather than add a new Java package. And, it compiles to the JVM.

Therefore in Mirah (unlike in JRuby-based approaches such as Ruboto) no program needs a package or library beyond what is already in standard Java and Android. Programs written in it are extremely tiny (due to running without huge, additional language libraries) and they load and run (both) extremely quickly on Android devices (with their Dalvik Java virtual machine).

To use Mirah to build an Android app, see the Pindah project.

In order for someone to use Mirah (essentially syntax sugar on top of Java) BTW not only should they be familiar with Ruby, but they must also know Java well.

There's more about Mirah here:

For Android development, other JVM languages, Scala, Clojure, etc., as well as Ruboto, are also interesting.

Various StackOverflow questions relate to Android development using Mirah, JRuby, Ruboto, etc.:

Copyright (c) 2013 Mark D. Blackwell.

Friday, September 28, 2012

Frontend experience

Recently, I acquired some practical website frontend experience—which took quite a bit of learning!

For an initial demo for a startup, I analyzed, selected and set up all the infrastructure (Rails, Heroku & Amazon). I wrote all the CSS frontend. I also wrote all the working database backend.

See the demo! See how its layout is fluid?

(Click here, if you missed the above links.)

It doesn't have multiple user capability yet; it's just a demo, at this time.

I made this in the pursuit of becoming a does-everything website developer.

Copyright (c) 2012 Mark D. Blackwell.

Saturday, July 28, 2012

Select online wikis and discussion boards for startups

In GitHub, there's no email notification associated with wiki changes. That's not very good! They specialize in source control, instead. For more:

http://rants.arantius.com/github-sucks

Stackexchange here discusses GitHub wiki change notifications, but only by setting up another server and programming it. Certainly a startup doesn't have time for that:

http://developer.github.com/v3/repos/hooks/

The old Google groups was bad. But not even the new Google Docs has change notification, either.

So today I researched online wikis and discussion boards for startups, and found this Stackexchange answer. GitHub's wiki does not include notifications, BTW.

Zoho's products seem excellent to me! Generally, their collaboration apps are widely used and integrated with Google Docs. They seem quite good (and cheap) both for their wiki and their discussion forum:

http://www.zoho.com/collaboration-apps.html

Zoho wiki: 'Access controls' (private?). Notifications. Comment threads. Free of charge for three (3) users, $12 per month for four (4) users:

http://www.zoho.com/wiki/wiki-pricing.html
http://www.zoho.com/wiki/wiki-notifications.html
http://www.zoho.com/wiki/enterprise-level-security.html
http://www.zoho.com/wiki/google-apps.html

Zoho online forums: Private (by Google Docs integration). Notifications, but I don't know if they're universal. One forum is free of charge:

http://discussions.zoho.com/
http://www.zoho.com/discussions/features.html
http://www.zoho.com/discussions/intranet-discussions.html
http://www.zoho.com/discussions/features.html#topicadministration
http://www.zoho.com/discussions/solutions.html
https://www.google.com/enterprise/marketplace/viewListing?productListingId=2533+14374228673760475061

--------------
Other online wiki sites:

Wikidot: No integration with Google Docs. Non-public. Private for $50 per year ($4 per month equivalent). Free of charge with advertising:

http://www.wikidot.com/plans
http://www.wikidot.com/faq:private-sites

--------------
Other online forum sites:

ProBoards: $7 per month for ad-free. Oriented to public access; seems somewhat disreputable:

http://www.proboards.com/premium-forum-features

QuickTopic: $49 per year ($4 per month equivalent):

http://www.quicktopic.com/gopro?ref=faq

Teamlab: No pricing found!

Wetpaint: No access control.

Wikispaces: $20 per month for restricted access.

Wikimatrix: for comparing wiki software, said they include online but seem to be installable software. It might not be worth running one's own wiki server.

http://www.wikimatrix.org/wizard.php?d[branding]=&d[domain]=&d[flag]=2&d[language]=&d[support]=&d[wysiwyg]=yes&d[history]=yes&d[go]=1&x=77&y=14

Copyright (c) 2012 Mark D. Blackwell.

Thursday, July 5, 2012

User-story presence flags ease split-test metrics for lean startups, howto

This morning I read 'Measure', a chapter of the book, The Lean Startup. It discusses cohort analysis, split-testing, and the triple-A of metrics: Actionable, Accessible and Auditable.

Then I got an idea regarding split-testing the user-story stream in website development.

For split-testing newly deployed stories it's easy to include (in the logs) a (growing) bitstring of indicators for each user story, which indicate their presence (with/without or after/before), and the ordinal number (implicitly) of the story (perhaps from PivotalTracker). All are kept in the same central place (in the source code) usually used for configuration.

Packed together by story number (using standard Base64 encoding), each log line includes them as a short string. (They take up only a single character for each 64 stories, of course.)

With current aggregated logging, remembering which log records came from which active set of stories might be difficult. But at the first level this method eases split-testing (for the impact of) each newly-deployed story.

Going deeper, the flags in the logs categorize the comparison data cleanly and safely, especially if we ever want something more complex (in the current context)—such as to reassess an old story. To disable an earlier story, some special programming is required, but our log data will indicate clearly which stories are active.

For split-testing, we can filter the log data by these story-presence strings. We can split-test for various configurations (of user stories), new-user activation (or usage rates or whatever we desire).

Perhaps we might want to remove an old feature, and split-test that, before we expend the effort to develop an incompatible new feature—good idea? And arbitrary configurations of features can be split-tested.

Copyright (c) 2012 Mark D. Blackwell.

Thursday, June 28, 2012

Planning and developing

Regarding planning and developing in startups:

We should keep open what is open; and go forward with the unproblematic when there are no choices. Some decisions are best done early, some late. For instance, using Amazon for storage is certain, because it's cheapest.

For optional aspects without measured customer interest, action is best delayed.

Developing some aspects puts constraints sometimes on other aspects. Some aspects, certainly needed, are best delayed if multiple possible implementations exist (if other crucial aspects are still undone).

Obtaining the fastest possible overall development mandates choosing (based on actuality) what to work on, and what not to work on yet.

Copyright (c) 2012 Mark D. Blackwell.

Install Postgres on Debian squeeze for Rails, howto

Intro


Here's how to install Postgres, the popular, open-source database server for Rails 3 development on Debian squeeze (I used Rails 3.2.6). I switched to Postgres for maximum compatibility with Heroku (it's one of their '12-factor app' development principles).

This installation procedure keeps safety particularly in mind for anyone (like me) who has never before used Postgres.

Install


Debian squeeze's normal Postgres version (8.4) is unnecessary, unlike (apparently) the case on Mac OS.

Don't install the latest Postgres from source though postgresql.org recommends it—because its setup for Debian is difficult. Likely you will get mysterious errors such as:

$ bundle exec rake db:create:all --trace
  rake aborted!
  libpq.so.5: cannot open shared object file: No such file or directory - /home/mark/.rvm/gems/ruby-1.9.2-p320@global/gems/pg-0.14.0/lib/pg_ext.so
  /home/mark/.rvm/gems/ruby-1.9.2-p320@global/gems/pg-0.14.0/lib/pg.rb:4:in `require'

Instead use the most recent Postgres, backported to squeeze (currently 9.1.4). Here's how:

Remove old versions of Postgres software (e.g. 8.4) with:
$ apt-get purge libpq-dev libpq5 postgresql postgresql-client postgresql-common

Pay attention to messages, especially those warning about directory names containing 'postgres'. Take appropriate action to remove those directories.

Then clean up if you want to:
$ apt-get clean

Note that libpq is part of Postgres. Edit where Debian gets packages:
$ nano /etc/apt/sources.list

Include backports by adding:
  deb http://backports.debian.org/debian-backports squeeze-backports main

Ruby needs package 'libpq-dev' to connect to Postgres. Get the latest backported Postgres packages:
$ apt-get update
$ apt-get upgrade
$ apt-get -t squeeze-backports install postgresql libpq-dev

Expect to see the message, 'Configuring postgresql.conf to use port 5432' (which is the proper port for PostgreSQL *not* port 5433, which can come about if Debian gets confused).

Automatically, installation should start the Postgres server—look at what's actually running to confirm the port:
$ ls -a /var/run/postgresql

Instead of 5433 you should see:
  .s.PGSQL.5432

Minimally alter one of Postgres's configuration files to accept (app-specific) connections from Rails...:
$ nano /etc/postgresql/9.1/main/pg_hba.conf

by changing 'peer' to 'md5' where it says:

  # "local" is for Unix domain socket connections only
  #local   all         all                               peer
  local   all         all                               md5

Restart the Postgres server:
$ sudo /etc/init.d/postgresql stop
$ sudo /etc/init.d/postgresql start

New app


Now that you have Postgres installed, you can use it to create a new Rails app (which I'll call, 'APP'; replace this with something in lower case):
$ rails new APP -d postgresql; cd APP

Tell Rails you'll be using a database password from environment variables:

$ nano config/database.yml

Do this by changing the relevant lines (without moving them) to:

database:   <%=   ENV['DATABASE_USERNAME']   %>_development
database:   <%=   ENV['DATABASE_USERNAME']   %>_test
database:   <%=   ENV['DATABASE_USERNAME']   %>_production

username:   <%=   ENV['DATABASE_USERNAME']   %>
password:   <%=   ENV['DATABASE_PASSWORD']   %>

Repeat the username and password lines three times, once for each Rails environment.

Decide upon (or generate) a new database password for your app. Create the two environment variables above and set them somehow. If you're using foreman, you can set these in your .env file.

Unfortunately, Rails wants to drop the whole test database, not just its tables. Because it seems difficult to change this, we'll let Rails handle database creation:

Create the app's safe Postgres user. This asks you to enter your new app's password twice:
$ sudo -u postgres createuser --echo --encrypted --pwprompt --no-superuser --no-inherit --createdb --no-createrole APP

(If you made a mistake):
$ sudo -u postgres dropuser APP

Confirm your new app is included in the list of existing databases and users (called 'roles'):
$ sudo -u postgres psql
=> \dg
=> \l
=> \q

Rails should now be working. Test it by something like:
$ foreman run bundle exec rake db:create:all

If Rails merely complains that the three databases already exist, then this setup is working fine.

If Rails didn't work and the final error message started 'Couldn't create database' then scroll up: if you see...:

  could not connect to server: No such file or directory
  Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

then go back and redo the above part regarding installing for the correct port 5432 (not 5433).

If after scrolling you see:

  password authentication failed for user {APP}

then go back and redo the above part regarding creating the 'role' (user) for the new app.

Rake


To run tests, with foreman setting up your local environment, remember that you should be running rake by:

$ foreman run bundle exec bin/rake ...

E.g., to run database migrations, do:

$ foreman run bundle exec bin/rake db:migrate

(And similarly for some other commands.)

Heroku


Heroku (e.g.) rewrites your database.yml to use only the single value in DATABASE_URL, which makes it effectively your production database, so beware. Don't set the DATABASE_URL environment variable (locally) in your .env file.

If you want to troubleshoot Heroku's access to your database with a local setup closer to Heroku's method, make a script (call it: my-foreman) containing this:

environment=$1
shift 1
export DATABASE_URL=\
postgres://$DATABASE_USERNAME:$DATABASE_PASSWORD@\
localhost:5432/$DATABASE_USERNAME'_'$environment
foreman start $@

Then you can run foreman in your desired environment with (e.g.)

./my-foreman production -p 5001

Alternative


Alternatively, you could take this approach:
* Make your own Unix username be a Postgres superuser;
* Keep the local authentication line in pg_hba.conf as,  'peer'; and
* Change the database username in new Rails apps to your Unix username.

But that approach is less safe, especially across apps. If you make a mistake in a new app, you don't want it to overwrite the database of another of your apps.

References

http://backports-master.debian.org/Instructions/
http://railscasts.com/episodes/342-migrating-to-postgresql?view=asciicast
http://wiki.debian.org/Backports
http://wiki.debian.org/PostgreSql#Installation
http://www.jquantlib.org/index.php/Upgrading_PostgreSQL_8.2_to_8.3_on_Debian
http://www.postgresql.org/docs/9.1/interactive/install-short.html
http://www.postgresql.org/docs/9.1/static/auth-methods.html
http://www.thegeekstuff.com/2009/04/linux-postgresql-install-and-configure-from-source/
http://xtremekforever.blogspot.com/2011/05/setup-rails-project-with-postgresql-on.html

Copyright (c) 2012 Mark D. Blackwell.

Tuesday, January 10, 2012

Lisp & Ruby metaprogramming

I just reread Paul Graham's article, Beating the Averages, on Lisp being the most powerful computer programming language because of Lisp macros (which, BTW, are not like assembly language macros). It led me to the obvious perception that because Ruby lacks Lisp macros, metaprogramming in it is weaker than in Lisp.

He explains the essence of Lisp macros: '[I]n general, for application software, you want to be using the most powerful ...language you can get, and using anything else is a mistake. ...Lisp code, after it's read by the parser, is made of data structures that you can traverse. If you understand how compilers work, [in Lisp you] write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. [P]ower ...refers to features you could only get in [a] less powerful language by writing an interpreter for [a] more powerful language in it.'

So, for someone who wants to know where to go next after Ruby, and thinks that, in a Ruby code base, having a high proportion of metaprogramming code, like some say Rails 3 has these days, results in awkwardness, the next step is Lisp. Lisp apparently is perhaps a better metaprogramming language.

Copyright (c) 2012 Mark D. Blackwell.

Tuesday, December 13, 2011

Lean Startup book thoughts

Have you read The Lean Startup by Eric Ries yet? good summary.

EVERYWHERE

Entrepreneurs are everywhere, he says, even in large, stolid, companies -- true even of IBM! I hope they exist, where you are now. Disruptive innovation might come from competitors.

WASTE

Just now, in the Amazon preview, I read the book's introduction. I see the book's epilogue: 'Waste Not'. That is so key! (to me, also).

Paraphrasing Ries: startup success, thus changing the world, is exciting. Let's not waste vision, passion and energy.

ACCOUNTING

'A new kind of accounting, designed for startups.' Like any accounting, it's good for measuring categories we want to watch, like how much is devoted to experimentation on customers.

TEAMS

Good to have '[c]ross-functional teams ... accountable to learning milestones ... instead of [specializing people in] ... functional departments.' Good to suggest things across functions. Good to set up a Lean Startup culture and systems.

SOCIAL

Lean Startup circle
Lean Startup at Meetup.com
Lean Startup Wiki

Good to connect socially with the Lean Startup people.

SUMMER

The book's graphs show manufacturing trending downward greatly these last ten years. With much borrowed money, he says we have been throwing our excess effort into many failed products. Hm, a recent Ries post says we are in a software development 'summer', but sometime a 'winter' will come.

LEARN

'Startups exist to *learn* how to build a sustainable business.'

With 'Build-Measure-Learn', steering to the 'destination[:] creating a thriving and world-changing business.' What a good idea!

Are we developing our own companies on Lean Startup principles?

BUSINESS

Like 'Zappos' [experiment,] ... a clear, quantifiable outcome: either a sufficient number of customers would buy or they would not.'

We might 'put [ourselves] in a position to interact with real customers and learn[.]' Right now, we could put a question on a website (and publicize it): are you (anyone browsing) interested in an app (of any kind) to do this?

LEGACY

He says plausible-sounding management theories, even seemingly reasonable (including legacy ones derived from manufacturing), are only as good as how well their predictions work.

Legacy practices (of 'good market research', even 'solid strategy') don't work when there is extreme 'uncertainty'. '[C]haos ... doesn't work either.'

'[N]ew product development ... routinely [and obviously now] requires ... [that which from a manufacturing perspective is] failure to plan adequately[,] failure properly to execute [the plan and a temporary] failure to deliver results ... on the way to greatness.' In other words, people (who learned the manufacturing paradigm) do resist.

Ries, quoting Scott Cook, 'Moving leaders from playing Ceasar with their thumbs up and down on every idea to --instead --putting in the culture and systems so that teams can move and innovate at the speed of the innovation system.'

Emphasizes he does not (just) do whatever customers say, interestingly, but focuses 'on what customers want (without asking them)'. That jibes with (my) experience: customers usually aren't good (naturally) doing breakthrough, useful, product imagining and creating.

SCIENCE

'Validated learning.' 'Scientific method.' It's great to see actual science entering into business management. BTW, science in general took a long time to overcome human nature and be adopted, just as (in particular) it did in business management.

'[O]ne ... lesson ... of the scientific method: if you cannot fail, you cannot learn.'

BOOK

Ries highly recommends The Four Steps to the Epiphany, 'the original book about customer development': dog-eared in his IMVU days.

Copyright (c) 2011 Mark D. Blackwell.

Saturday, November 12, 2011

Lean startup

Recently, a project owner I know read with interest the new book, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, by Eric Ries. It just came out September, 2011; his blog is Startup Lessons Learned. Web searching for "lean startup" found:

From `Taking the guesswork out of startup success' (by Anne Fisher):

`“[S]tart...with a very basic, sloppy site, and...continually change it according to what users tell [you] they like and don’t like.” [E]very single week[,] invite customers in, plunk them down in front of computers, watch them use the site, and ask them questions about it. The (often surprising) answers then get built into the product.'

From Jeff Shuman's comment #40 in `Teaching a “Lean Startup” Strategy' (by Carmen Nobel):

`In Peter Drucker's 1985 book Innovation and Entrepreneurship, he noted that “When a new venture does succeed, (more often than not) it is in a market other than the one it was originally intended to serve, with products or services not (quite) those with which it had set out, bought in large part by customers it did not even think of (when started), and used for a host of purposes besides the ones for which the products were first designed.”'

From `Four myths about the Lean Startup' (by Eric Ries):

`Lean Startups...do not blindly do what customers tell them, nor do they mechanically attempt to optimize numbers. They use...actionable analytics as vehicles for learning...how to make their vision successful.'

From `Top 5 myths about the lean startup' (by Eric Ries):

`Lean startups are driven by a compelling vision, and they are rigorous about testing each element of this vision against reality...with every tool available...They use customer development, split-testing, and in-depth analytics as vehicles for learning about how to make their vision successful. Along the way, they pivot away from the elements of the vision that are delusional [emphasis added].'

`Lean...refers to a process of building companies and products based on lean manufacturing principles, but applied to innovation. That process involves rapid hypothesis testing, learning about customers, and a disciplined approach to product development.'

`[A] startup is [any] human institution creating a new product or service under conditions of extreme uncertainty.'

From Brian Mcfarlane's comment:
`getting out from behind you[r] computer and talking to real people will reward you with unresolved problems you may not of thought of to help you get to a product-market fit sooner.'

From `The Promise of the Lean Startup' (by Eric Ries):

`In parallel to [the] work by the “solution team”...there is a new kind of “problem team”...that is asking the bigger questions, such as: Who will our customers be? What problem does our product solve for them? How many of them are there? And how will we reach them?'

`The promise of the lean startup is that instead of building our companies according to myths, we can guide them with facts and the knowledge required to use those facts well. Or put another way, that we won’t waste our time building products or services that nobody wants.'

`The ultimate goal of a lean startup is to identify where its vision intersects with what reality can accommodate...It tries out new ideas with a fraction of customers in order to prioritize using facts, not opinions. Its unit of progress is that of validated learning about its customers. [Thus] the practice of entrepreneurship can be put on solid, rigorous, footing.'

`Instead of seeing process as a synonym for bureaucracy, it sees it as a synonym for discipline. Focusing all of its energy on only those activities that matter, it frees up time and energy for true productivity.'

Other references:
Why Lean Startups are Hard Part 1 – Our Genes Aren’t Lean - Kevin Dewalt
Perfection By Subtraction – The Minimum Feature Set - Steve Blank

Copyright (c) 2011 Mark D. Blackwell.