古川勝也（コガワ・マサヤ）

異業種と協業してきた日々

現在の本業であるプログラマーと並行し、料理研究一家「古川家」の活動を開始して今年で４年目になりました。

プログラマーとして業務システムなどを受託開発してきた経験は、そもそも異業種交流のようなものだったのですが、今度は自分から異業種の世界に出て行くという動き方になっています。

しかも持って行くのはITそのものだけでなく、要件定義や運用設計などを手がけて培ってきた情報処理技術です。同業者からは当たり前の行為や知見であったとしても、異業種の世界では特異な存在らしく、その点が強みとなっています。

「くらし」を「なりわい」に

古川家として活動する核の1つには、日々の暮らし、ライフスタイルをそのままビジネスにできるか？という挑戦があります。

料理研究一家と名乗るのは、食卓を彩り、支える、家族という存在が欠かせず、食卓を起点として、それぞれの得意なことを生かし、力を合わせて活動していくというビジョンがあるためです。

日々繰り返される家族との暮らしがとても大切な事だからこそ、消費するのではなく生産していく、そして新たな可能性に向けて投資していきたい。そう考えることで、自分の活かし方、活かされ方への意識が大きく変わりました。

「専門家」から「兼業化」へ

専門家から兼業家へ

プログラマー、SIer、ソフトウェアエンジニア、呼び名は様々あれど未来についてはなぜか暗い話が付きまといがちです。

誇りを持って仕事をし、技術の研鑽に励む日々にも関わらずです。

AIに仕事を奪われる、35歳定年説、海外人材に駆逐される、ネガティブな未来は枚挙に暇がありません。

では、これからどう歩んでいくのか？

プログラマーとしての歩み方にはいくつかあると思いますが、すぐ思い浮かべるのは、新規テクノロジーを生み出し、世間に広めることで人々のライフスタイルそのものが変化する道かと思います。

クラウドやスマートフォンが良い例ですが、世界が一変します。

もう1つは、既存テクノロジーを別分野に適用する方法です。私の場合は、テクノロジーというより人材そのものを応用するという考え方です。これが兼業を指します。

プログラマーでありながら料理研究のような、新たな業に取り組むというスタイルです。規模は小さいのですが、即行動できること、少額投資で済むというのがメリットだと思います。

コンピューターを軸にした情報処理技術を、食という文脈から別業種に適用していくのです。食は裾野が広く、飲食店だけでなく様々な文脈で登場します。そこが魅力であり可能性が大きいと考えています。

当たり前になってしまっているものだからこそ、価値を再発見していきたいという思いも含め、兼業していくことを選びました。

コミュニケーションは不可視コスト

別業種と関わるということは知識交換が必要になります。自分の技術が有用だと分かってもらうよりも、相手の実現したいことや暗黙知となっていることなどを掘り起こして、接点を探しながら相手の知識をこちらの血肉にしていくことが肝要です。

だからこそ、コミュニケーションは必須ですし、とても重要と言えます。

ですが、適切なコミュニケーション設計を行わないと、認識の齟齬や情報の混乱によってストレスばかりになり、プロジェクトそのものが止まったり、最悪の場合は解散となります。

予算、納期、ビジョン。プロジェクトを進める上で確かに重要なものですが、どのようなコミュニケーションをとって進めていくか最初に合意するというのは、同じぐらい重要だと経験から感じています。

かと言って、とりあえず話し合おう、集まろう、アドバイスを求めようを繰り返すのは本末転倒です。ここでのポイントは、コミュニケーションもコストの一種だと考えて、少ない回数にしたり、関係者を最小限にしたりと、削減できた方が良いものという視点です。

協業プロジェクトでは、他のメンバーが本業を持っていたり、案件の掛け持ちをしていることもよくあるため、なかなか進まないことがままあります。

それを問題と捉えるのではなく、必要条件と考えてコミュニケーション設計をした方が、私の場合はスムーズでした。

運用・知識・心理、3つのハードル

3つのハードル

では、こういうツールを使いましょう、こういう運用をしましょうとなった時に出てくるハードルがあります。

プログラマーとしては、このツールを使えば問題をクリアできるなと思いつくのですが、それがこのメンバーに向いているかは別問題ですし、根付くかどうかはその後の動き方にもよります。

まず見えてくるのは知識のハードルです。ITになれた人にとっては当たり前の感覚が、別業種では通らないというのはよくある話です。主な原因は情報の非対称性、つまり得意な知識に差があることです。

ここは先ほどでいう、異業種間の知識交換を積極的に行うことで解消できるのですが、次に出てくる心理的ハードルが立ちはだかります。

ITヘの苦手意識、トラウマとも言える過去の失敗や恐怖心が、知識交換に対する意欲を削いでおり、これが根本の原因であることが多々ありました。

まず最初に越えなければならないのは、この心理的ハードルだと考えています。

既知をもって未知に踏み込む

未知と既知

では苦手意識や恐怖心の根底には何があるのでしょうか？私はそれを未知だと考えています。

知らない、分からない、経験がない、そういう状態が漠然とした不安になり、過去の経験と相まって苦手意識や恐怖心になっているようなのです。

新しいツールを使いましょう、それにはこういうメリットがあってと説明するのは、こちらの領分ですから難しくありません。ですが、いかに合理的な説明であっても相手が受け入れるとは限りません。

1つ自分の中で良い方法だと手応えがあったのは、既知の方法をとるということです。知っている、分かっている、経験があるということは、心理的距離を近く感じるため、抵抗感が薄れたり、安心できるという可能性が高くなります。

例えば、初めて使うツールなら対面で説明しながら動かしてみる、相手が1人で試すのは不安そうなら自分が相談窓口となる、相手にとって未知のことに対して、相手にとって既知の方法をとるとハードルを越えていけます。

初めて使うツールをメールで説明する、これはハードルを越える可能性が低くなります。悪手とは言えませんが、他に既知の方法がないか検討する余地があるのではないでしょうか。

誰のための技術なのか

技術があるとして、誰を中心にして考えるのか？そこが大きな分岐点だと考えています。

職業柄、新しい技術を試し、既存の技術を研鑽するというのは現役でいる限り避けられません。ただ、技術そのものは手段にすぎないというのが私の方針です。

もちろん技術を目的にするというのも楽しい一面があります。ですが、自分だけ喜んでいても前に進むことはできないとも実感しています。

様々な業種、そこで働く人たちがいて、歯車の大きさやスピードも様々です。新規テクノロジーは、それそのものが大きな歯車と言えます。なので強制的に周りを動かしてしまう力を持っており、それによって世界が変わってきたというのは、歴史を見れば明らかです。

兼業という私のアプローチは、潤滑油のようなものです。少し違うのは、存在や意味を知ることで、元々の歯車が加速するだけでなく、歯車そのものが大きく力強くなる可能性を持っている点です。

異業種へと踏み込み、方々で歯車を加速させたり、力強くすることで、世界全体が加速していけるのではと、私は考えています。

また次回に期待して

各地に散らばるCPIエバンジェリストが一堂に会するというのは、発表者側としても刺激になります。

1年に1回というのは、持ち寄ってこれる情報も濃くなっているので、ちょうどいいのではないでしょうか。

また来年、新たな事例や学びを持って、このイベントに臨めたらと思っています。

とても便利なDesigner Content Pro

Designer Content Pro（以下、DCP）は、concrete5でコンテンツを編集・レイアウトするための機能であるブロックを自分で拡張できるプラグインです。

これを利用することで、独自の入力フォームを持ったブロック（カスタムブロック）を作成することができます。

さらにカスタムブロックを作るために必要なプログラミングの量をほぼ無くしてくれるので、HTMLによる表現部分だけに集中することができ、デザイナーの画面作成やなクライアントの運用をサポートすることができます。

使い方・カスタマイズの参考

本番稼動しながらDCPブロックへ入れ替えたい

テスト環境でブロックを作って入れ込んでしまうと、本番環境でまた作成しなおさなくてはなりません。データベースのダンプで入れ替えても良いのですが、並行して稼働したい場合だと難航します。

メンテナンス時間を長くとっての移行はなるべく避けたいところです。

concrete5は下書き保存で変更後のプレビューができるので、本番サーバーは現状を維持しながら編集を進められます。

ローカルではブロックの動作のみ確認し、中身は本番サーバー上で入力して公開すれば、メンテナンス時間をかなり短縮できます。

テーマファイルには、ブロック化する前の内容を静的に埋め込んでおいて、そこに編集エリアを併記します。ブロックの追加と中身の入れ込みも、下書き状態であればログインユーザー以外には見えません。

内容がOKとなった段階で、静的に埋め込んだ部分を削除したテーマファイルを反映し、下書きを公開すれば入れ替えがスムーズです。

ブロックタイプを追加すると自動生成されるファイル群

/blocks/[block_hanle]/view.php
/packages/designer_content_pro_blocks/blocks/[block_handle]/
- tools/edit_repeating_item.php
- add.php
- controller.php
- db.xml
- edit.php
- view.php

ブロックタイプを追加した時点で、後述のインストールが自動で行われます。その際、データベース上のBlockTypesテーブルにブロックタイプについてのレコードが追加されます。

ブロックのインストール、アンインストール、削除

DCPで作成したブロックは、いつでもインストールとアンインストールができます。

インストール

自動生成されたファイルのうち、重要なのはdb.xmlです。インストール時にブロックハンドルのアンダースコアをキャメルケースにした名前で、ブロック用のテーブルをデータベース上に作成します。

テーブルの名前はブロックハンドルがtest_blockだとすると、btTestBlockとなります。

テーブル定義がdb.xmlで管理されることで、データベース上でテーブル編集など直接操作を行う必要がありません。

アンインストール

ページ内で作成したブロックを使用している場合はそれらも削除されてしまうので注意が必要です。

作成したブロックをアンインストールしても、テーブルや自動生成されたファイルは消えません。

削除

削除すると以下の内容が削除されます。
1. /blocks/[block_hanle]/view.php
2. /packages/designer_content_pro_blocks/blocks/[block_handle]
3. BlockTypesテーブルからブロックタイプのレコード

移行の手順

DCPをインストール済みとして、自動生成されたファイルを本番サーバーへ同じディレクトリ構成でアップロードします。
管理画面からDCPのページへ移動すると、アップロードしたブロックがインストール待ちの状態で表示されます
インストールをクリックします
ページの編集エリアにブロックを追加しようとすると、DCPで作成したブロックが一覧に表示されています

by 古川勝也（コガワ・マサヤ）

今後のスタンスを考える機会

技術と戦略という2つの要素がメインですが、どちらがなくとも成り立たないものと思います。個人的なスタンスとしては、開発者・制作者は「作れて当たり前」、それが価値であり存在意義のひとつと考えています。

システム開発者として色々と考えさせられることがあり、いくつかの転機を経て、料理研究一家「古川家」としての活動を軸に据えることになりました。

「作れて当たり前」だけれど、それだけでも通用しない状況に変化していく中で、自分を棚卸しして戦略を立て直すというのは、自然な流れです。

独立当初からスタンスはさして変わっていない

2008年にフリーランスのプログラマーとして活動をし始めてから、スタンス自体は変わっていません。経験を積んで、確信できることが増えてきました。

これだけ流行廃りが早い業界なので、変化と安定という観点から不安になる人も多いと感じているのですが、変化し続けることを受け入れることが大切と考えています。

変化といっても、状況に流されていてはSNS疲れや勉強疲れを起こすだけです。どういう軸で生きていくつもりなのか、まず一個人としてどうあるべきかを問われているように思えてなりません。

変化し続けるという安定

個人力を高める6つのメソッド WDHA #022 New Year Special

あなたはフリーランスとして生き残れますか？

フリーランスの製作者が考えるべきプロジェクトのバランス

今後のWebサイト制作との向き合い方を改めて考える

古川家から見える3つのキーワード

担当したセッションでは、まず「戦略」として、なぜ古川家をはじめようと思ったのか？について共有。

その後、古川家の価値観として3つのキーワードを抽出し、それを実現するために使用しているツールや技術を紹介するという構成で進めました。

”くらし”を”なりわい”に

家族という日常を続けながら、この社会で生きて行くには稼いでいくことは避けられないでしょう。日常、つまり暮らしをコンテンツとして食べていけるように舵を切ってしまえば、暮らすことそのものが生業になります。

もちろん、家族の理解は大事ですし、よくある家族営業とも少し意味合いが違うので、周りの理解も得ていかなくてはなりません。古川家は「食と家族」を切り口に新しいマーケット、居場所を自分たちの手で作ろうと考えています。

食は「非言語コミュニケーション」であり、家族は「人類最小のコミュニティ」。

暮らしに集中するために、大事なこととはいえ作業はなるべく手短に済ませたいもの。最初は「今日の古川家ごはん」として、Facebookページで日々の食卓を公開しました。

暮らしの見える化としては、よくある方法なのですが、自分たちなりの工夫を重ねる中で企画・プロデュースのお声がけをいただいたり。

Webサイトはもはや名刺代わりですが、いざ自分たちのとなり、必要になったタイミングも急だったりすると突貫工事が必要です。そこで採用したのは下記のツール群。

とりあえず立ち上げるに当たって、色々な選択肢はありましたが、できるとはいえ言語や文法のちゃんぽんは効率を下げます。言語（このときはRuby）・文法・設計概念などが揃っていれば、スピードはかなり上げられます。

専門家から兼業家へ

エキスパートという言葉は憧れを抱きますが、技術もツールも手段であり、目的達成のためにどう取捨選択をするべきか？という決断には、幅広い知識やスキルが必要です。

100点と20点より、70点を2つとれば総合力は上回ります。

自分がエキスパートには向かないと割り切り、その上でどうやって結果を出していくか？という問への自分なりの回答です。その代わり、あらゆる知識やスキルを少しずつ底上げするには時間がかかります。

それでもいいのです。暮らしを生業にした以上、一生をかけて高めていけば良いのですから。

とはいえ、兼業が増えれば増えるほど、仕入れるべき情報もアウトプットも多種多様になります。そういった状況では、整理しながら情報収集できたり、下書きしながら清書できたり、一石二鳥以上の効果を持つツールで武装していく必要があります。

Twitterのタイムライン(#megamix2015 - Twitter検索）でMouの代替アプリも紹介されていました。

Mou つかってるなら、個人的には Macdown の方がオススメ #megamix2015

— 久保知己 (@kojika17) 2015, 4月 18

1つ以上のチャレンジを

古川家は基本的に自分たちで企画から何から全部を手がけます。

だからこそ、いつもチャレンジが生まれるのかもしれません。すべてをいつも通りではなく、1つだけでも未知の領域があると、これまでの経験もゼロベースで考え直したり、良い棚卸しになったりします。

それまで「これが1番」と思っていたツールも、時代とともに進化したり、シェアが変わっていたります。新しいことを始めるときは、改めて調べ直す良い機会かもしれません。

古川家の場合、メンバーの得意分野は当然違います。すべてではないにしろ、前提知識や場所を問わず利用できるツールは重宝します。

まとめ

ツール・技術は料理で言うと包丁がそれにあたります。ですが、包丁1本で料理にまつわるすべての工程をまかなっているか？と言われると、まったくそういうことはありません。

適材適所の使い分けが必要です。また、せっかく研ぎ澄ました技術も、振るう場所がなくては意味がありません。今はその技術を振るう場所を、自分で作ることもひとつです。

私自身、プログラマーとしての開発業務は今のところ辞める気もなく、古川家とのバランスを調整していくスタンスです。
多種多様な知識や経験を蓄え、担っていることそれぞれで循環していくサイクル作りをできるように取り組んでいきます。

環境

ディレクトリ構成は、CPI ACE01
SSHではphpコマンドを打てないので、ローカルで諸々の環境を作ってからサーバー上で展開
ローカルのPHPはphpenvで環境にあわせてバージョンを指定

└── html
    ├── blocks
    ├── concrete
    ├── config
    ├── controllers
    ├── css
    ├── elements
    ├── files
    ├── helpers
    ├── jobs
    ├── js
    ├── languages
    ├── libraries
    ├── mail
    ├── models
    ├── packages
    ├── packages
    │   └── example
    │       ├── controllers
    │       │   └── dashboard
    │       │       └── example
    │       │           └── sandbox
    │       ├── laravel
    │       └── single_pages
    │           └── dashboard
    │               └── example
    │                   └── sandbox
    ├── page_types
    ├── single_pages
    ├── themes
    ├── tools
    └── updates

Laravel5の導入

composerインストール

プロジェクトのルートディレクトリにcomposerをインストール
ローカルで運用

> curl -sS https://getcomposer.org/installer | php

Laravel5のインストール

> php composer.phar create-project laravel/laravel html/packages/example/laravel --prefer-dist

composer.jsonにForm・HTMLヘルパーを追加

Upgrade Guide - Laravel - The PHP Framework For Web Artisans

    "require": {
        "laravel/framework": "5.0.*",
        "laravelcollective/html": "~5.0" // 追加
    },

Call to undefined method Illuminate\Foundation\Application::getCachedCompilePath()

先ほど追加したForm・HTMLヘルパーを入れるためにupdateを実行して上記エラーが出た場合の対処

Call to undefined method Illuminate\Foundation\Application::getCachedCompilePath() · Issue #8127 · laravel/framework

> rm vendor/compiled.php
> php composer.phar update

パッケージ内のコントローラーからLaravel5を読み込む

パッケージのパスを取得して、autoload.phpなどをrequireしていく
concrete5 :: Get the Package Path in a Dashboard Single Page Controller

<?php
defined('C5_EXECUTE') or die("Access Denied.");

use \App\User;

class DashboardExampleSandboxController extends DashboardBaseController {

    public $helpers = array('html', 'form');

    public $laravel;

    public function on_start() {
        parent::on_start();
        $packagePath = Package::getByID($this->c->pkgID)->getPackagePath();
        require $packagePath . '/laravel/bootstrap/autoload.php';
        $this->laravel = require_once $packagePath . '/laravel/bootstrap/app.php';
    }

    public function view() {
        // Laravel5標準の認証用ユーザーモデル
        $user = new User();
    }

まとめ

強引な方法だけれども、Laravel5内のリソースにアクセスできた。Eloquentも普通に使えるはずなので検証を継続。

もっとスマートな方法があれば情報求む。

情報提供

パッケージコントローラーのon_start()で読み込むとスッキリだった。あとはPSR-0準拠として、Laravel側のnamespaceを置き換えれば良さそう

@calmtech ずれた回答かもしれませんが、パッケージコントローラーからPSRオートローダーを読み込む例です https://t.co/RiS834aCTb

— Takuro Hishikawa (@HissyNC) 2015, 4月 20

by 古川勝也（コガワ・マサヤ）

[WordPress]寄稿者ユーザーに他者の投稿を表示させない方法

寄稿者の権限で投稿を受け付ける場合、その人以外の投稿を見せないようにするためには、フィルターフックとアクションフックの両方を利用する必要があります。

フィルターフック

プラグイン API/フィルターフック一覧 - WordPress Codex 日本語版

WordPress上で投稿データを表示するときなど、何か表示するタイミングで独自のプログラムを実行させることができます。

アクションフック

プラグイン API/アクションフック一覧 - WordPress Codex 日本語版

WordPress上で投稿ボタンを押したときなど、何か動作が発生したタイミングで独自のプログラムを実行させることができます。

要件

投稿一覧で「すべて」「公開済み」などの投稿状態フィルタを非表示にする
寄稿者が自分の投稿数0件の状態でも、投稿一覧で他者の投稿が見えないようにする

上記を満たすために、フィルターフックとアクションフックをテーマ内のfunctions.phpに記述していきます。

実装

投稿一覧で「すべて」「公開済み」などの投稿状態フィルタを非表示にする

投稿状態フィルタ

投稿状態フィルタの変更後

function show_owned_posts_only( $views ) {
    unset($views['all']); // すべて
    unset($views['draft']); // 下書き
    unset($views['publish']); // 公開済み
    unset($views['pending']); // 保留中
    unset($views['trash']); // ゴミ箱

    return $views;
}
// views_edit-[post_type] カスタム投稿タイプの場合は、投稿タイプを指定する
add_filter('views_edit-xxxxx', 'show_owned_posts_only');

投稿状態フィルタそれぞれの内容はコールバック引数で受け取る、$viewsに入っています。unset()で要素を削除することで制御できます。

今回はすべての要素を非表示にすることで、「所有」という自分の投稿数のみ表示されるようになります。

注意点としては、CODEXにある「views_edit-post」は「投稿（投稿タイプ=post）一覧」のフィルターフックだという点です。カスタム投稿タイプを利用する場合は、「views_edit-hoge」のように投稿タイプ名に置き換える必要があります。

寄稿者が自分の投稿数0件の状態でも、投稿一覧で他者の投稿が見えないようにする

function hide_other_posts($wp_query) {
    global $current_screen, $current_user;

    if($current_screen->id != "edit-xxxxx") {
        return;
    }

    if(!$current_user->roles[0] == "contributor") {
        return false;
    }

    $wp_query->query_vars['author'] = $current_user->ID;
}
add_action('pre_get_posts', 'hide_other_posts');

フィルターフックで投稿状態フィルタを非表示したとしても、寄稿者の投稿数が0件の状態で投稿一覧にアクセスすると、他者の投稿が見えてしまいます。

pre_get_postsアクションフックを使い、ある特定の画面（この場合はカスタム投稿タイプの投稿一覧）で、ログインしているユーザー（この場合は寄稿者）の投稿のみ取得しています。

$current_screenと$current_userで現在表示している画面とログインしているユーザーを特定しています。

ユーザーを特定できれば、$wp_queryからauthorパラメータで投稿を絞り込むことができます。

参考

by 古川勝也（コガワ・マサヤ）

テスト環境の保持期限ってどのぐらい？

約2年前にシステム納品したプロジェクトから障害発生の連絡。
原因をたどっていくと、とあるプラグインの設定に誤りがあったのだが、これに気づくまで意外と時間がかかった。

テスト環境は正常に動作している状態なので、内容を比較していって原因を特定。
管理画面からプラグインの設定をいじらない限りはならないはずだが、いつ誰がやったのかまではさすがにわからない。

設定を変更した履歴まで残すとか、そこまでケアしたシステムではないし、個別にアカウント作ってガチガチの管理というわけではない。ミッションクリティカルでもない限り、そこまで追跡する機能は作り込まないだろう。

テスト環境はクリーンかつ半永久保存

今回はテスト環境が正常な状態で残っていたので分かったようなものの、今の技術スピードだと2年前のものですら化石に見える。.scssとかもう使ってないし。PHP 5.2系なんて、レガシー扱いだ。

といいながらも、開発した案件はほぼすべてテスト環境をのこしたまま、ディスクに眠っている。
最古の環境は7年以上前（カームテックの創業前！）だ。テスト環境として利用しているものも、今となっては同じものを揃えられるか怪しいものばかり。

しかし、これまでの経験では残しておいてよかったと思うばかりだった。

先日も業務端末がWindows XPからWindows 7へ端末ごと変更ということで、商品データ生成ツールの環境構築をしてきたが、当時と同じにしようと思っても色々と環境が違って四苦八苦した。ちなみにそのシステムを納品したのは2005年か2006年あたり。

法人は、帳簿を備え付けてその取引を記録するとともに、その帳簿と取引等に関して作成又は受領した書類（以下「書類」といい、帳簿と併せて「帳簿書類」といいます。）を、その事業年度の確定申告書の提出期限から7年間保存しなければなりません。

また、法人が、取引情報の授受を電磁的方式によって行う電子取引をした場合には、原則としてその電磁的記録（電子データ）をその事業年度の確定申告書の提出期限から7年間保存する必要があります。

ただし、その電磁的記録を出力した紙によって保存しているときには、電磁的記録を保存する必要はありません。

国税庁 | No.5930　帳簿書類等の保存期間及び保存方法

システム構築という責務は予測不可能な未来

法人会計ですら7年間。システムの寿命は思ったより長い。その産業のサイクルに準じており、よほど致命的なセキュリティ対策等がない限り延々と使い続け、それを前提に教育された業務が「文化」「社風」となっていく。

受託システムにおける稼働サイクルというのは、思っているよりも長く息づくことが多い。
そこまでを見通して設計となると、やはりクライアントへ歩み寄り、企業文化を含め知らなくてはいけないことがとても多い。関係者が増えると、同じ温度で案件が進むことは少ない。

東日本大震災でもそうだった。耐震設計の時、どこまでを見通せば良かったのだろうかと、ふとよぎった。システムを設計するプログラマーは、時として予言者のような立ち位置になってしまう。

by 古川勝也（コガワ・マサヤ）

今年一番ヒットだったツールは「TaskPaper」

Aomori Web Advent Calendar 2013の一番手です。私は今年とにかく使い込んだツール、TaskPaperを紹介したいと思います。

TaskPaper便利すぎ・・・

TaskPaperは、シンプルなTODO管理ツールとしてMac、iPhone、iPadで利用できます。ですが、TODO管理だけではもったいないぐらいに便利で、こいつがないとやってられない！というぐらい私には必需品になっています。今はマークダウンでドキュメント管理したり、多様化した時期をすぎて、シンプルな記法や管理方法に落ち着く人が見渡していて多いと感じています。TaskPaperで気に入っているのは、以下の点です。

Dropboxで複数間デバイスの同期ができる
ショートカットがほどよくて、エディタとしてがしがし書ける
後から書いたことを探せる
ついでにTODO管理ができる

管理のこつは1プロジェクト1ファイル

色々と使い方を探ってきた中で、1つのプロジェクト（公私問わず）に対して1つのTaskPaperファイルを作るのが一番しっくりきています。TaskPaperで作成したファイルは、「.taskpaper」形式のファイルとして保存されます。中身を見ると、インデントや記号を活用したシンプルなもので、なるほど！と思いました。

例えば仕事の場合、私はひとつの案件もしくはクライアントで1つのTaskPaperファイルを作っておきます。そこには議事録や仕様やメモなど、なんでも全部いれます。Evernoteでそういう風にやろうとしたときもあったのですが、行入れ替えといったエディタとしての機能やファイル内での検索を考えるとEvernoteの機能では合いません。スキャンデータや画像、静的ドキュメントはEvernoteにプロジェクト用のノートブックをひとつ用意して、やはりそこに全部ほうりこんでいます。つまり、TaskPaperファイルとEvernoteノートブックを見れば、そのプロジェクトに関しての記録は全部いつでも振り返られる状態にしています。見る場所が少なく、特定されているというのは後から探すことがとても楽ですね。

もうひとつ、1プロジェクト1ファイルにする理由は、TaskPaperはタスクバー上に表示されるTaskPaperアイコンから、いつでも他のドキュメントを選択できるからです。1プロジェクト1ファイルだと、その行き来がしやすくなりますし、見通しが良いというメリットがあります。

TaskPaperの構成は「Project」「Note」「Task」「Tag」

Screenshot taskpaper

TaskPaperは上記4つで構成されていて、それぞれショートカットキーで入力できます。

最重要項目Project(command + option + Enter)

Projectの使い方で、TaskPaperの使いやすさは大きく変わってきます。Projectはアウトラインエディタにおける見出しみたいなものをイメージしてもらうと良いと思います。入れ子にしていくこともできるので、見出しレベル1 > 見出しレベル2 > 見出しレベル3 とtabでインデントさせると、アウトラインとして見渡しやすくなります。command + shift + M で全体の様子を見せるサイドバーが表示されます。また、command + ]で、現在カーソルがあるProjectのみに絞り込んで表示できます。

補足にはNote(control + Enter)

個人的に使用頻度がそう高くないのですが、何か補足事項をいれておきたいときに使っています。

基本は1項目1Task(command + Enter)

1項目1Taskとして、がしがし必要事項を書いていきます。もちろんTaskもインデントで入れ子にできますので、箇条書きにしていきます。議事録の場合は、Projectで絞り込んで表示されているTaskを、そのままPDF化して共有しています。

Tagで絞り込みを効率化

最初に登録されているTagは@doneというものです。command + Dで最初から割り当てられていて、これを実行するとTaskに打ち消し線が入ります。すでに完了したこと、状況が変わってなくなった事項は、消去せずに@doneのTagをつけておきます。すると、時系列がのこっていくので振り返りに便利でした。

TaskPaper = アウトラインエディタ + TODO管理 + ロギング

TaskPaperはアウトラインと箇条書きで思考や情報を整理する人には、TODO管理を超えてかなり便利に感じるんじゃないかと思っています。もちろん苦手な部分もあります（添付ファイルとか視覚的なことは無理）ので、やはりツール選びだけじゃなくて、その運用の仕方や思考法が合ってるかも一緒に考える必要はあります。

TaskPaperいかがでしょうか？テキストベースでの操作に慣れている人は、少し触ってみるだけで、「あー、なるほどね」と納得できるかと思います。

by 古川勝也（コガワ・マサヤ）

OSX Marvericks にアップデートしたら MAMP PRO が動かなくなった

現象

MAMP PRO 起動後に MySQL を起動できずハングアップする
上記の状態だと、アプリケーション側からはログを見ることしかできない

原因

Marverics でのセキュリティ強化により、権限の問題で /etc/hosts をサードパーティーアプリケーションが書き換えられなくなっているためのようです。

やるべきこと

MAMP PRO を最新（2.2）にアップデート
Keychain Access で署名を発行する
codesign コマンドで MAMP PRO に署名し、編集許可を与える

電子署名を作成する

Keychain Access を起動する
Menu(Keychain Access) > Certificate Assistant > Create a Certificate...
必要情報を入力して、署名を作成
Name => CalmTech(ここは任意)
Identity Type => Self Signed Root
Certificate Type => Code Signing

Keychain Access で電子署名を作成後

MAMP PRO に適用する

上記で発行した電子署名を MAMP PRO に適用します。ターミナルを起動して、以下のコマンドを実行します。
codesign -s “Your Name(今回の場合は、CalmTech)” /Applications/MAMP\ Pro/MAMP\ Pro.app

適用されたかどかは、以下のコマンドで確認できます。

codesign -v /Applications/MAMP\ PRO/MAMP\ PRO.app -v

MAMP PRO を再起動します。私の場合は、マシンも再起動してみました。

調査の過程で試したこと

デフォルトでインストールされる Apache を停止

Marvericks にアップグレードすると、Apache がインストールされるため MAMP Pro の Apace を起動できないというケースも散見されています。この場合は、以下のコマンドで Apache を停止することで解決。今後も使わないのであれば、自動起動からも削除してしまうと良いと思います。

sudo apachectl stop
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

参考

by 古川勝也（コガワ・マサヤ）

Guard + Compass + Foundation で環境構築メモ

Guardはコマンドラインツールで、ファイル変更を監視してコンパイルや結合などのタスクを実行できます。Middlemanでプロトタイプを構築して、既存システム（PHPベース）に移植という段取りだったのですが、Middlemanのディレクトリ構成をそのまま持ち込むことはできません。

Guardを採用した理由としては以下があります。CoffeeScript、concat、uglifyはまた今度に。

Compass、CoffeeScript、Slimといった様々なライブラリを複合で扱える
BundlerでGem管理ができる
Rubyベースなので資産を再利用しやすかった

まず、CompassとFoundationを導入する段取りについて。

Gemfile

Guardプラグイン各種を入れておきます。

# SASS & Compass
source ‘http://rubygems.org’

# V8 JavaScript Engine (for Uglifier)
gem “therubyracer”
gem "sass"
gem "compass"
gem "zurb-foundation"
gem "susy"
gem "compass-normalize"

# For concatenation/compression
gem "uglifier"

# Guard and plugins
gem "guard"
gem "guard-sass"
gem "guard-compass"
gem "guard-coffeescript"
gem "guard-livereload"
gem "guard-concat"
gem "guard-uglify"
gem "rb-fsevent"

Bundlerでインストールします。

bundle install --path vendor/bundler

config.rb

各種Gemをrequireしておきます。

require 'zurb-foundation'
require 'susy'
require 'compass-normalize'

Sassファイルでは以下のようにインポートしておきます。

@import "normalize";
@import "foundation";

Foundationについては、これですべてのスタイルが読み込まれます。

Guardfile

CompassでSassファイルをコンパイルするタスクを用意します。
正規表現で .scss と .sass 両方をコンパイル対象にしています。

guard :compass do
    watch(%r{sass/(.+\.s[ac]ss)})
end

Guard実行

bundle exec guard init
bundle exec guard

コマンドを実行するとタスクが実行され、さらにファイル変更の監視を始めます。

[1] guard(main)>

by 古川勝也（コガワ・マサヤ）

[参加レポート]Webディレクションはじめの一歩

今回のセミナー、一線で活躍されている方々の舞台裏が生々しく語られました。Togetterにまとめがありますが、完全非公開の内容が多く、気になる方は多くいらっしゃるのではと予想しています。再演の機会があれば、どこかでお披露目できるのかもしれませんね。

ここでは私が発表した内容についてのポイントと、全体を通しての内容について振り返ります。

数値化＆洗い出し

システム導入が必要となり、エンジニアと協業する時のポイントについてお話ししましたが、その中で一貫して重視したのは、数値化＆洗い出しでした。

何かを実現するに当たって「定期的に」「なるべく」「おおよそ」等といった、あいまいな言葉を含んだ状態は決まっていないのと同じという考え方です。

極端に感じるかもしれませんが、人がよしなに動かしていたものを、言われたとおりにしか動かないコンピュータに任せるためには、その下準備が重要になってきます。

要件と要望は違う

ソフトウェア開発の世界では、なにかを作るために必要なものを明確にしていくプロセスを要件定義と言います。よくある失敗として、できあがったものが思っていたものと違うというケースがあります。これは、要件と要望を混同することによる双方の認識違いが原因のほとんどです。

要件は必要不可欠なもの。要望は願いではありますが、なくても問題ないものです。要件を具体的にし、関係者間で認識を一致させていくために、数値化＆洗い出しという観点は少なからず助けになると思います。

人の行動をコンピュータの処理に置き換えていくために、様々なことを具体的にしていかなくてはなりません。それはシステムに限らず、Webデザインの世界でも同じであり、ディレクションの一部として必要不可欠だと思います。

ディレクションには「軸」が必要

講師陣それぞれに、ディレクションする際に基準となる軸が存在していました。何を実現するのか、何を得意とするのかはバラバラです。しかし、軸があることで目的を見失わずに済んだり、比較したりすることができるようになるのだと思います。

私がそれぞれの講師から学んだ軸としては「気遣い」「共有と可視化」など、他にも色々とありましたが、なぜその軸を大事にしているのかを聞けたことが大きかったと思います。思いつきで軸ができたわけではなく、失敗や成功の積み重ねで得た教訓ですから、自分の今後に落とし込んで検証する必要があります。

早速、いくつか試してみたいなと思ったもの、参考となる気になっていた書籍などが出てきたので、また色々と吸収できるようにしていきます。自分にとっても、暗黙となっていた部分を整理する良い機会となりました。

by 古川勝也（コガワ・マサヤ）

CalmTech

古川 勝也 （コガワ・マサヤ）

異業種と協業してきた日々

「くらし」を「なりわい」に

「専門家」から「兼業化」へ

コミュニケーションは不可視コスト

運用・知識・心理、3つのハードル

既知をもって未知に踏み込む

誰のための技術なのか

また次回に期待して

関連

とても便利なDesigner Content Pro

使い方・カスタマイズの参考

本番稼動しながらDCPブロックへ入れ替えたい

ブロックタイプを追加すると自動生成されるファイル群

ブロックのインストール、アンインストール、削除

インストール

アンインストール

削除

移行の手順

今後のスタンスを考える機会

独立当初からスタンスはさして変わっていない

古川家から見える3つのキーワード

”くらし”を”なりわい”に

専門家から兼業家へ

1つ以上のチャレンジを

まとめ

関連リンク

環境

Laravel5の導入

composerインストール

Laravel5のインストール

composer.jsonにForm・HTMLヘルパーを追加

Call to undefined method Illuminate\Foundation\Application::getCachedCompilePath()

パッケージ内のコントローラーからLaravel5を読み込む

まとめ

情報提供

フィルターフック

アクションフック

要件

実装

投稿一覧で「すべて」「公開済み」などの投稿状態フィルタを非表示にする

寄稿者が自分の投稿数0件の状態でも、投稿一覧で他者の投稿が見えないようにする

参考

テスト環境はクリーンかつ半永久保存

システム構築という責務は予測不可能な未来

TaskPaper便利すぎ・・・

管理のこつは1プロジェクト1ファイル

TaskPaperの構成は「Project」「Note」「Task」「Tag」

最重要項目Project(command + option + Enter)

補足にはNote(control + Enter)

基本は1項目1Task(command + Enter)

Tagで絞り込みを効率化

TaskPaper = アウトラインエディタ + TODO管理 + ロギング

現象

原因

やるべきこと

電子署名を作成する

MAMP PRO に適用する

調査の過程で試したこと

デフォルトでインストールされる Apache を停止

参考

Gemfile

config.rb

Guardfile

Guard実行

数値化＆洗い出し

要件と要望は違う

ディレクションには「軸」が必要

古川勝也（コガワ・マサヤ）