リアルに出社しなくちゃいけない仕事ってどんなの？

家でも仕事ができるとかって言われて久しいけど、通勤電車の混雑が緩和するほどでもない。じゃぁ出社しなくちゃいけないケースとか、移動しなくちゃいけないケースってどんなの？ってことをまとめる。

• 実際には時間をブロックしたいだけ
• 小説家なんて、それこそ家でできる仕事なのにもかかわらず、編集担当から「かんづめ」にされたりする。いどうしなくちゃならないのではなく、時間をブロックしているだけ
• コールセンターも家でできるタイプのもあるけど、労務管理の観点から物理的に出社をさせている
• 作業スペースが必要なケース
• プリンターやら製本やら
• 合意形成が必要なケース
• 契約を結んだりするときには、直接あって合意をしてもらう必要がある。説得が必要なケースともいえる。リモートで納品物のやり取りをするのは、契約を結んだ後の話
• モノを見せないといけないケース
• ケータイの実機テストとその結果をみながらの仕事とか。インターネットと言えど、モバイル系の開発をしていた人は昔っからこういうことしていた。
• どこでも30分でいけるので
• 東京ならどこでも30分でいける。移動のコストが低いのだ
• 反対にどんなに近くても30分かかるというのが東京の不思議なところ
• 稼働中かどうかを知りたいケース
• 法律で、労働者が働いている時間と休憩している時間を管理しなくちゃいけない。だから稼働しているかどうかを見ないといけない
• チャットがONになっていれば、稼働中ということにしましょうなんてこともできなくはないが、よりさぼりやすくはなる。

以上、メモ。

PowerPoint→でっかいJPEG→写真屋さんで年賀状印刷

プリンタという機器はランニングコストも高いし使用頻度も少ない。だけど年賀状の時には必要っぽい。年賀状は写真屋さんで印刷してくれる。ってことは、JPEGに必要事項を全部入れれば、写真屋さんがちょっとしたキンコーズのように使えるってこと。

組織KPIを高める方法５箇条

例えば、あなたの組織が、「持ち回りでブログを書こう」みたいなプロジェクトが立ち上がったとする。こういうの大概うまくいかない。普段の業務の片手間だと、わがごと感がまるでないからどうしても手抜きになる。

ブログは広報観点では重要なのにも関わらず、現場がそれを大事だと思わなければ、なかなかピントこない。記事にいいねをしてもらえばいいのだろうというのは分かるが、それでも気合いが入らない。そういう時にやるべきこと。

【アイディア】TAKE5というサービス

北米のディズニーランドには「TAKE5」というルールがあるらしい。5分までなら従業員個人の判断でどんなサービスをしてもいいということ。5分くらいなら企業としては労働量のマネジメントをするまでもないのにたいして、5分もあればかなりいろいろできる。エキスパートの5分は場合によっては、大きな社会的価値を生む。

認証なしでPOSTされたデータをGoogleAppsScriptでスプレッドシートに追記する

便利そうでギリギリしんどいGoogleSpreadSheetとGoogleAppsScript。
アンケートフォームとかでも使いたいけどギリギリ使えない。

なんとか、「素のPOSTを受け取ったらそれを限られた人しか見れないドキュメントに保存」という動きが作れたのでここで説明。POSTを送る側は、PHPとかで適当に作るイメージ。だからGoogleAppsScriptをAPI的に動かそうってわけ。

GoogleSpreadSheetのキーを知る方法

APIをあれこれ触る方法もあるが、直接ブラウザからDocsListを眺める方法もある。

https://spreadsheets.google.com/feeds/spreadsheets/private/full
https://spreadsheets.google.com/feeds/worksheets/[SPREADSHEET-KEY]/private/full
https://spreadsheets.google.com/feeds/worksheets/[SPREADSHEET-KEY]/private/full/od7
https://spreadsheets.google.com/feeds/cells/[SPREADSHEET-KEY]/[SHEET-ID]/private/values　

【メモ】なぜ会計が大事か？

社内で、月単位で利益を正確に出すことの大事さを教えなくちゃいけない場面があったのでそのメモ。

【メモ】グラフの持つ「便利」という価値

ソーシャルグラフとかバーチャルグラフとかあって、ＳＮＳが出てきたときに、プロモーションコストが安いという文脈で語られがちだが、そもそもは「便利」という価値があるはず。グラフは人工物なのだから、目的に沿って設計されている。

• 会議室に集める
• 会議参加者もグラフの一つ
• 議事録にずらりと並ぶ名前がそれ
• 連絡網で連絡する
• 今や連絡網自体が不便だが、同じところに行く予定の人達であり、イベントのON/OFFを同時に知る必要のある人達
• 回覧板
• 自治体となるといよいよコミュニティではあるが、回覧板というシステムはノードがあるためグラフである

インターネットで一斉同報すりゃぁ、システムとしての連絡網や回覧板は必要なくなるが、共感を得たいだけのSNSとは別に、利便性を考えたグラフも存在はするということ。

【メモ】低脂質ダイエット

• 胆嚢炎になっちゃって食事制限したら意外になんとかなって体重も劇落ちしたのでそのメモ
• 食事制限が必要
• 肉は絶対ダメ
• カルビの半分は脂
• 乳製品ダメ
• 乳脂肪分は意外に多い。牛乳はダメ
• マヨネーズはダメ
• あれも油
• ドレッシングもダメ
• サラダはＯＫかと思いきや、大概のドレッシングはほぼ油
• ノンオイルを使おう
• 揚げ物はダメ
• パンも厳しい
• 意外にバターを使ってる

【メモ】固定費比率が多いところがビジネスチャンス

管理会計においては、固定費と変動費がある。固定費比率が高い商売は、損益分岐点が高く、参入障壁が高かったりする。既に市場を確保している企業であっても、売上は変動するのに固定費は変動しないというのは、事業リスクでもある。

• 航空会社は席という固定費が課題
• 客数が減っても席が減るわけでない
• だからチケット販売で
• オンラインゲームのサーバ代
• サーバ代は固定費
• 本当はできるだけ負荷を馴らしたいところ
• サーバがクラウドになることで、サーバ代が変動費化する
• 沢山人が来た時だけサーバ代を払えばいい
• コスト削減だけではなく「イベント」という新しい遊び方を発明できた
• オンラインゲームの開発費
• パッケージソフトは先にすべてを開発しきる
• オンラインゲームでは、ヘビーユーザが遊び切ったあとに機能を足すことができる
• ヒットしてからさらに投資ということができることで、参入障壁は下がる
• 会議室は変動費化に成功した
• TKPとかは会議室を変動費化することに成功
• 貸し会議室は共用部扱いなので、変動費化することでの効率化以上に節税のメリットもある
• 税金というシステムは資産にかかるというところが特徴
• 持たざる美徳
• 逆にまだ固定費が多いもの
• 新幹線は同じ値段だよね。
• タクシー代も変わんないよね
• 病院とかも混雑度合いで伸び縮しないよね
• オフィス（土日空いてるのもったいない）
• 省庁の規制が厳しいところは変動費化が厳しいか

凄く当たり前に導入できるのがいろんなものの予約システム。単に予約ができるというだけではなく、繁閑が可視化できることで、固定資産を有効活用できる。調達も計画的にできる。タクシーなんかは配車システムも大事だけど、需給バランスが可視化できると、客も運転手もハッピーになれるはず。そこで、明らかな「供給過多」が分かるだけかもしんないけど。

見出し記号付きテキストを連想配列にする

xmlだとかyamlだとかあるけども、日本人なら見出し記号付きテキストでしょうがと。

●見出し
本文

とか

【見出し】本文

とか、そういうの。ほとんどのテキストがそうなっているんだから、そのままパースしてやりゃぁいい。

パスワードにひらがなを使ってみる

英数記号をくみあわせたパスワードが「お行儀が良い」とされているが、モバイルだとスゲー入力しにくい。覚えにくい上に、手書きでメモったとしても、アルファ別途の大文字小文字まで書ける自身などない。結果、コピペをするしかない。

日本人の入力環境の標準がひらがななのだからひらがなでパスワードをやればいい。

なんなら、初期パスワードでさえもひらがなで生成してやればいい。

さらに、七五調で初期パスワードを生成してやれば、暗記だってできるかもしれない。

PNGが使っている色数を取得する方法

pngは色数を減らして、インデックスカラーにすると容量が小さくなるという。確かにPNG8で保存すると軽くはなるのだが、じゃぁどんだけ色が減って居るかってことは、ぱっと見分からない。

ぱっと見分からなければいいじゃないかというものの、あまりに主観が入りすぎる。

ということで、「色数を減らす前のpngがどんだけ色数を使っているのか」を取得するPHPスクリプト。コマンドラインで、第一引数にファイル名を指定する。

これ。

データバレーにまなぶデータフロー

真鍋監督のiPadバレーとはいうものの、あの仕組み全体はゴリゴリのPCソリューション。監督のディスプレイデバイスにiPadを使っているだけ。

入力と出力のアーキテクチャを明確に分けているというところが特徴。

「見る」ことに特化したタブレットが使われているのがポイント。

てことで、タブレットに外部からプッシュする仕組み（見る人の操作も許す）が、あれば何かと便利そう。大事な会議の資料配付とか。

さしあたって、AJAXスライドショーで、オートページャがあればいいのかな。

自分でめくることもできて、外部からプッシュもできる。両方できるイメージ。

こんなセッションが欲しい

結局のところ、「長めのセッション」で利便性をよくしている例が多い。

セッションをコントロールすれば認証が広がる。

• セッションをDBに持つ
• PHPなら最初からその機能がある
• DBに持った上で以下の項目を保持する
• ユーザID
• セッションを作成するさいに、同一ユーザIDが以内かどうかをチェック
• 同じユーザIDで二重ログイン出来ないようにつくることでセキュリティを高める
• モバイルとPCで両方ログインしっぱなしにしたいとかって人には不便
• IPアドレス
• セッションレコードにIPを入れることで、物理的に別のIPからアクセスしたときにはセッション切れにしちゃう
• 主に企業向け
• モバイルネットワークからのアクセスには不向き（IP変わるはず）
• ワンタイムパスワードの仕組みをいれて以下の項目を保持
• ワンタイムパスワード
• 既にパスワードが疲れたかどうか
• ワンタイムパスワードの寿命

大きめの会議の心がけ

• 会議室の案内は正確に
• ビル名・階数・部屋番号
• ビルの中の案内もできる限り
• 看板がでてるとありがたい
• プロジェクターのテストは前もってやろう
• まずは出力できるか？
• デュアルディスプレイなのかクローンなのか
• パワポは2画面設定なのか？
• 共通のPCか持参PCかははっきりさせる。持参PCの人は前もってテスト
• Macの人はアダプタ持参しているか？
• マイクのテスト
• 充電切れをケアして予備があるか？
• タイムキーパーは必要
• 下手に機械に頼らず人を一人容易した方がいい
• デモする人は居るか？
• プレゼンだけではなく、デモをする人が居る場合にはネット環境に注意
• アンケートの用意
• 筆記用具は持参していただくのか。会場で用意するのか

業績レポートのフォーマット

• 実績・見通し・計画を示すドキュメントを作成
• 過去の情報は実績で示す
• 未来の情報は見通しを入れる
  →見通しは、手なりではこうなりそうというデータ
• 実績＋見通しと計画の差を出す
• 目標が大幅達成の時には、さらなる投資をするかどうかの判断をする
• 目標がギリギリか未達の時には、挽回策を考える

• 以上の作業を週次で行う
• 見通しの先週差を数字で示し、その内訳を説明する
• 挽回したなら、先週言ってた挽回策が成功したのかどうかを報告
• 悪化したなら、さらに出てきた悪材料を報告

• 挽回策って何をする？
• 　「がんばる」は挽回策ではない
• 　業績の足を引っ張っている理由が明確ならそれを解決する
• 　教育で挽回
• 　優秀な人の採用で挽回
• 　コンピュータシステムを入れることで解決
• 　担当を変える。人を入れ替える
• 　コストを削減する。引っ越す。社員旅行を取りやめる
• 　採用計画を変える。採用を抑える
• 　不採算部門から採算部門に人をシフトさせる
• 　来期に花開くような投資をやめて、今期の目標達成のための短期的な施策をうつ
• 　本質的な解決策から、非本質的なその場しのぎまで、選択肢は幅広く持つ

【アイディア】社内研修用のeラーニング

いわゆるスキルアップの研修と言うよりも、どちらかというとコンプライアンス用の研修というのは存在する。
チェックリストによくある「従業員向けの研修は行っているか？」みたいなやつ。個人情報取り扱いのためのやつとか。

それってもう機械的に進めるしかなくて、レベルの問題ではない。そうなると研修担当のスタッフの経験とかそういうのをあてにしていられない。

そういうところこそ、eラーニングが必要。いわゆるCBT。

市場はよく分かんないけど、大企業だとほぼ導入しているはず。

でも、まだまだ課題はあるのではないか？

【アイディア】GoogleAnalytics自動化ツール

●やりたいこと
・GoogleAnalyticsを定期的に別ファイル形式にする

●用途
・社内レポート
　→エクセルで集計して社内の定期モニタリングに使う
・webサイト
　→アクセスランキングを生成する

●方法
・社内レポートの場合
　エクセルでログイン（WebBrowserコントロールを使う）して、テーブルタグをWebクエリで取得
・webサイトの場合
　GDataとかのAPIを使って、サーバサイドで取得する。
　

従業員評価のあれこれ

経営者になるまでに至らなくても、ひとたびマネージャーになったら従業員の評価をしなくちゃならないケースは出てくる。「そこまで他人の人生決められないっす」というのがホンネだろうが、とはいえ誰かが決めてるのは事実。

一番大事なのは「フェア」に評価することと、「フェアに評価していると思われる」ことの二つ。

だから、どうやって評価をしているかはキチンと伝えなくちゃいけない。

Webフレームワークに必要なもの

いろんなフレームワークがあるが、Web制作現場でのニーズをまとめる。

１．稼働サーバが広い
よく「ロリポップでも動くフレームワークにしろ」と言ってる。mod_perlが必要な時点でちょっと厳しい。もちろんPCのローカルでも動く必要がある。常にブラッシュアップを求められるのが、Webシステムなら、そのブラッシュアップするための、開発環境、検証環境は、10分で構築できるのがいい。

ssh接続を許容していないレンタルサーバもある。デザイン確認をするのにはレンタルサーバで十分。フォルダーコピーだけで動くのがいい。

２．ディレクトリを選ばない
よくあるフレームワークでは、ルート相対でないと稼働しない。キャンペーンサイトなどは、
http://クライアントのドメイン/campain/xxx
みたいなディレクトリで動くこともある。だから、ディレクトリを選ばないのが理想。
デザイナーも、ルート相対だとプレビューするのにも一苦労。だから、htmlと画像のパスはテンプレート上は相対パスの方がいい。

３．テンプレートだけを見てもプレビューができる
結構なフレームワークが、デザイナーのデザインプロセスを無視している。.tplという拡張子にしている時点でデザイナーの業務を無視している。カスタムタグも極力使わない方がいい。出来るだけ素のhtmlに近い形でプレビューしよう。

共通化したい気持も分からないでもないが、オーサリングツールにはテンプレート機能が既に備わっている。プレーンなHTMLを大量に作るしごとは多くのデザイナーがやっている。デザイナーの強みを生かそう。

３．２．URLリライターをうまく使おう
PHPはその生い立ちから、素のHTMLタグに機能を付加してくれる。例えば、
a href="index.html"
を

a href="index.html?guid=ON"
に自動的に書き換えたいときには、
output_add_rewrite_var("guid","ON");
で、自動的に書き換えてくれる。まぁ便利。この機能はフォームにも隠しフィールドを自動的に追加してくれるので、アンカーやフォームをヘルパー関数で作りこむ必要がない。

４．デバイス毎にビューの切り替えができる
もはや、PCとモバイルは両方カバーするのが当然。できれば同じURLでアクセスしたい。昨今はソーシャルメディアでURLが共有される時代。そしてソーシャルメディアのアクセスは、いよいよPCとモバイルが同じくらい。どちらも作ろう。
同じURLでもビューを切り替えることで、PCとモバイルの両方に対応が可能になる。


５．ログが取れる
これはフレームワークに限った話ではないが、何か問題があったときのよりどころはログ。開発フェーズでは、画面上にvar_dumpをしまくっていれば良かったかも知れないが、リリースされたらそういうわけにはいかない。そして本番サーバになると、ApacheのログもPHPのエラーログもアクセスできない可能性がある。アプリ開発者が意図的に出すログだけではなく、エラーログこそ「見えやすい」ところに置いておきたい。
phpでは、
set_exception_handler
set_error_handler
という関数があって、このハンドラの中で、エラーログをアプリ開発者が扱いやすい形で出力することが可能。ミドルウェアの管理の方針とアプリの管理の目的は違うのだから、ログの単位で分けて管理出来た方が良い。

プロジェクトの立ち上げ手順

１．プロジェクトのゴールを復唱できるレベルで明文化
２．スコープと優先順位を決める
３．タスクを洗い出す
４．タスクの依存関係を作る（後続タスクのない先行タスクはない）
５．クリティカルパスを見つける
６．エキスパート、経験者、責任者、元気などのバランスで担当を割り振る
７．負荷のバランスを見て、担当を振り直す
８．あり得ないほどの長いスケジュールになっているはずなので、リソースを投下してクリティカルパスを短くできないか検討したり、品質やスコープの調整でスケジュールを圧縮できないかを検討

エントリーフォームのお作法

応募フォームでイライラさせられることは多い。
一回ユーザビリティテストでもすりゃぁ、すぐに分かりそうな仕様バグに近いモノが放置されてることも多い。

何度も言わなくちゃいけないので、まとめておく。

そもそも、チェックを厳しくしても間違いは大して減らない

全角と半角を厳密に入力規制をかけても、それはユーザにとって間違いを減らす要因にはなりにくい。表札をかけてないユーザへの配送はやっぱりそれはそれで難しい。手書きで住所や電話番号を書いているのと同レベルの精度で十分なケースは多い。

えん罪で失うユーザのコスト

わざわざ広告費を使って連れてきたユーザが、やっとエントリーフォームまできたのに、それを失うリスクは割と無頓着。フォーム作成の担当が、マーケティング担当から情報システム担当になるからか。厳しすぎる入力フォームは経済的損失が大きい。

全半角をユーザに強制させない

半角カナはPCでさえも打ち方を知らない人がいる。

住所の番地などは半角で打つ人がほとんど。

スマホの場合は全半角の区別見た目でほとんど分からない。

どうしても全角数字じゃダメで半角数字で入力させたいのなら、システムで全角から半角に変換するプログラムを入れればいい。

フィーチャーフォンであれば、IMEモードが設定できるので、それを使えばいい。

入力欄のフォントはモノスペースで

全半角を強制するなら、せめて入力欄のフォントは等幅フォントで。

input,
textarea{
font-family : "ＭＳ ゴシック", monospace;
}

メールアドレスのRFC標準はやりすぎ

ピリオドは二回連続続かないなどのルールは規約としては存在するが、そのルールから外れて発効されたメールアドレスもある。docomoのメールアドレスは有名。実在するにもかかわらずそれをはじくのはやりすぎ。ユーザの「メールアドレス入力ミス」を本当になくしたいのなら、返信メールのURLをクリックしてもらうのが確実。

余計な項目は取得しない

項目が増えるほどユーザの離脱は多い。あたりまえのこのコトがなかなか浸透しない。個人情報保護観点でも余計な個人情報は取得しない方がいい。

必須入力にしてもムダ

どうしても入力して欲しい項目を必須項目にしてもムダ。都道府県は、一番上の北海道が選択されるし、フリー入力のアンケートなら「あああ」と入れられておしまい。

フィールド長上限は長めに

イマドキのマンションはいやがらせのように名前が長い。フィールド長をけちる時代はとうにすぎた。フィールド長は長めにとっておいていい。ユーザが普通に住所を入力して、max文字数制限に引っかかると言うことは、それはシステムの設計ミス。あえて長さを制限したいというケースがあるとすれば、印刷時の制約ということがありえるが、

フィールドを細かく分ける意味は無い

電話番号をわざわざ3カラムに分けるフォームを見るが意味などない。一つで十分なケースが大半。ハイフンを入力させてもさせなくても全く害はない。ハイフンありなしを制限しているのも論外。

以上。

ディレクトリ個別にクライアント証明書によるアクセス制限を掛ける方法。

1.サイトのSSLの設定に以下を記述

# 認証するクライアント証明書を発行した認証局の証明書。これにより発行者をチェックする。
SSLCACertificateFile /etc/httpd/ssl/ca.crt
# SSL通信においての再認証を許可する設定
SSLInsecureRenegotiation on

2.クライアント証明書によりアクセス制限をかけるディレクトリに配置する.htaccessに記述

# SSL通信を強制する指定
SSLRequireSSL
# クライアント証明書を要求する指定。require以外を指定すると任意とかになるので、requireにする事。
SSLVerifyClient require
# クライアント証明書でチェックする階層の指定
SSLVerifyDepth 1
# 403エラー時のメッセージを指定。定型文の他にURLによる指定もOK
ErrorDocument 403 "Sorry can't allow you access with no ssl"

RapidSSLを使ったSSL証明書の作り方

●全体概要

• pem：中間証明書（RapidSSL共通の中間証明書。使い回し可）
• csr:企業情報＋ドメインを元に作成する。署名。SSL申し込み時にツールを使って自分でつくるもの。
• key:企業情報＋ドメインを元に作成する。秘密鍵。SSL申し込み時にツールを使って自分でつくるもの（csrとセットで作られる）
• crt:SSL証明書を取得するときに、認証が終わった後にメールで届くもの。
  メールで受け取るためには、admin@ドメインでメールを受けれることが前提（他にもサーバにおまじないファイルを置く方法もある）

　　
この4つのファイルのうち。
key
crt
pem
をアップして、httpd.confで設定すればOK。

おさらい

• 最初から共通であるのが、pem   
• つくるのは、csrとkey
• もらえるのが、crt
• サーバにあげるのが、pemとkeyとcrt

●Apacheの設定確認
OpenSSLとmod_sslが入っているかどうかを確認
rpm -qa|grep openssl
rpm -qa|grep mod_ssl

●Rapid-SSLから証明書を買う
http://www.rapid-ssl.jp/index.htm?q=rapidssl
▽特徴
・クレジットカードでも銀行振り込みでも変える
・メールを受信する仕組みがなくても、指定されたファイルのアップロードでドメイン所有者であることを確認してもらえる
・CSR作成ツールがあるのでopensslのコマンドライン作業が不要
▽注意点
・「秘密鍵のパスワード」を設定してしまうとApacheの再起動のたびにパスワードを聞かれるので不便。設定しないでいい。

●confの設定
・listenするポートを設定

●作ったファイルのチェック方法

・keyファイルが正しいかどうか
openssl rsa -in domainname.key -check -noout
⇒「RSA key ok」

・crtファイルの有効期限を調べる
openssl x509 -in domainname.key -noout -dates
⇒例）下記のように、出力される
notBefore=Jul  1 04:13:50 2013 GMT
notAfter=Oct  3 00:20:38 2015 GMT


●最後の最後にテストの方法
・ブラウザでhttpsにアクセスして、証明書の有効期間が更新されているかどうかを確認

●以下、RapidSSLフォーム入力手順例
                                                                                                             
■URL
http://www.rapid-ssl.jp/index.htm?q=rapidssl

■事前対応
・ドメイン取得
・DNSにゾーン追加
・apacheのconfを設定して、該当ドメインにhttpでアクセスできている

■手順
・Rapid SSL2600円、「新規お申込み」から申込み
・申込みの際して、CSRが必要で、CSRの作成に下記情報が必要

○CSR生成情報
　コモンネーム：取得したいドメイン
　正式組織名：社名英語表記
　　※whoisでコモンネームのドメインを検索して、ドメイン登録情報を入力
　　　http://whois.jprs.jp/
　　※参考：ドメイン所有者名(whois情報)と異なると発行が遅くなる場合があります
　部門名：SSL
　　※特に部門名がない場合は、ダミーでSSLと入力
　市区町村名：Sibuya-ku
　都道府県名：Tokyo
　国名：JP

・RapidSSLお申込み画面の注意事項を確認して、お申込みフォームへ
・お申込みフォームのCSR作成ツールからCSRを作成
　※ https://www.rapid-ssl.jp/tools/makePkeyCsr2048.php
　※任意の秘密鍵のパスワードは設定しない
・作成された秘密鍵、CSRはテキストに保存
・お申込みフォームに下記内容を入力して、お申込み内容確認へ

　パスワード：申し込みステータスを確認するためのパスワード
　ご契約期間：２年
　他社からの移転：いいえ
　CSRの貼り付け：上記生成したCSRを貼り付け
　サーバタイプ(任意入力)：Apache＋OpenSSL
　特別コード:入力なし

・内容を確認して次へ
・承認メールアドレス・お客様情報入力
　承認メール受信アドレス：「指定ファイルアップロードによる承認」を選択
　担当者名(日本語)：自分の名前
　担当者英字氏名（名）：mei
　担当者英字氏名（姓）：sei
　担当者メールアドレス：mailaddress
　郵便番号（半角）：999-9999
　住所(日本語)：東京都千代田区千代田１−1
　電話番号（半角）：03-9999-9999

　更新時期のお知らせ：希望する
　技術担当者/代行申請者：証明書管理者と同じ

　経理担当者：以下の情報
　請求先名称（日本語）：経理担当の名前
　First Name（ローマ字名）：sei
　Last Name (ローマ字姓）：mei
　電話番号：99-9999-9999
　メールアドレス：mailadress

・お申込み確認へ
・お支払情報入力
・お支払方法：クレジットカード

・上記内容を入力後技術担当者にメールが届き、「指定ファイルアップロードによる承認」の作業フローが届く
　あとは、指定ファイルを指定された場所にアップすれば、メールでCRTが届く。

プログラム実行系のセキュリティホールに関しての解説

Webセキュリティはもはや収束点ができているのに、まだ誤解が伝授されているケースがある。

ここではそれを正す。

Webセキュリティで結構アウトなのは「プログラムを実行される」ということ

SQLアンチパターン

SＱＬアンチパターンを買ったのでそのメモ。

Webアプリケーションが止まったときの障害の掘っていきかた

Webアプリケーションの障害対策あるある。いわゆるLAMP環境を想定しています。

1. 緊急時は、メールではなく、電話で人を捕まえる
• ありがちなのがメールで必要な人を捕まえようとして、「待ち」の状態に入るという人。悠長なこと言ってられないので、電話で捕まえる
• インフラ周りは、アプリの担当でなくても、障害ポイントが分かるので、己のサービスを復旧させるためには、上司だろうとたたき起こして助けを求める。
2. マシン再起動もためらわない
• がっつり止まっている時には、ためらう必要はない。再起動することで原因を探るための証拠が消えるリスクもあるが、サービス停止のままの方がいいってことはあまりない
• リモートから再起動できないときには、データセンターに電話をして、物理的に再起動してもらいましょう
• たまには再起動の練習をしておきましょう。再起動時に自動起動して欲しいサービスが登録されてないというミスは早めに見つけておきましょう
3. すぐにできる調査あれこれ
1. 別のルートでアクセスしてみる
• 携帯からのアクセスだと、いろんなところを経由していうので、別経路としてPCなどのまるで別のネットワークからアクセスしてみる。
2. エラーログをみる
• アプリのログや、Apacheのエラーログなど、すぐにアクセスできるように。以外にそのまんまの理由が書かれていることが多い。
• いつでも見れるように。ログ参照の権限をあまりケチらない。
3. ロードアベレージみてみる
• ＷｅｂやＤＢのロードアベレージを見る
• cactiなどのツールは過去にさかのぼってみるには便利だけど、障害時は「今」をみなくちゃいけない
• ロードアベレージが高い時には、CPUの使用率とIO待ちを見る。ありがちなのは、CPUをあまり使って無くて、DBのクエリを待つApacheプロセスがずらりずらりと並んでいるという状態。そのときにはすぐにDBを疑う
• PHPでAPCを導入してると、PHPの処理速度がボトルネックになることはほとんど無いけどねー
4. DBでshow procecsslistしてみる
• ダメなSQLが滞留しているかも知れない。だめなSQLがロックをかけているかも知れない。phpmyadminだと「プロセス」タブで同じものが見れる。スローログを見てもいいが、閾値以上のSQLが全部でちゃうので、緊急時はどれがダメな子か見分けにくい。
5. IOが少ないはずのに、IO待ちが多いときにはdstatで見てみる
• 大した処理が流れてないのに、IO待ちが多いというときには、何か悪さしてないかを疑う。dstatコマンドで、IOがリアルにモニタリングできる
• 例えばデバッグ用のログを吐きだし続けていて、そこがIOのボトルネックになっていないか疑う
• Apacheのコネクションを多くしすぎて、メモリが不足し、SWAPすることでディスク書き込みが発生していないか疑う

そんな感じ。ざっとまとめると。

1. ボトルネックは一つ。それを探す
2. 遅いというのは「待ち」が発生している状態。ロードアベレージは「待ち」を表す指標でそれそのものは原因を表さない
3. コンピュータのリソースで、ボトルネックになるのは、CPUとIO。どちらかを特定する。

方眼紙エクセルの光と影の主に光を説明する

方眼紙エクセルという言葉がある。エクセルを表計算ソフトとして使うのではなく、方眼紙として使うことを指す。単に「マス目のいっぱいある書類」だ。

どちらかというと、目的とは違う使い方で揶揄された言い方だ。方眼紙エクセルを普段から使っている人達は、方眼紙エクセルなんて言わない。「ドキュメント」と呼ぶ。

さてこの方眼紙エクセル。嫌いな人は多い。以下嫌いな理由を挙げてみる。

１．エクセルの操作に不慣れ
いくらプログラム腕を磨いていても、表計算ソフトという事務処理アプリにはたどり着かない。事務処理アプリとしては標準でもプログラマーから見れば、門外漢のソフトなのだ。

２．開発ドキュメントに嫌悪感
開発のドキュメントというのはとかく面倒。ソースを見れば分かる、DBを見れば分かる。直接画面を見れば分かることと、なんでエクセルに二重にかかなくちゃ行けないんだと。さらに、要求されるものが、契約書じみたものでやたらと約束事を書かされる。エクセルマス目に書かなくちゃいけない内容がロクなもんじゃないのだ。

そうは行っても、方眼紙エクセルが出回っているのには理由がある。

１．いくらはみ出しても、はみ出さない
例えば、ネットワーク構成図とか作業フローとか、いろんなものが関連している図がある。端から順に配置していくものの、紙のサイズにキレイに収まるとは限らない。ところがエクセルには「一ページに収まるように縮小する」機能がある。

２．吸着機能
あまり知られてない機能だが、セルに描画オブジェクトを吸着させることができる。なんてことはないが、図形のサイズや位置が揃っていると、コネクタでの線ががたつかなくていいのだ。

３．セル罫線だけである程度のワイヤーが作れる
図形を配置するのではなく、エクセルのセルには罫線を各機能がある。罫線だから前後関係という概念がない。ワイヤーなんて、まさに画面と、フォーム要素を罫線で囲っていくだけなので、罫線機能だけで十分ワイヤーが作れる。

４．Office HOMEにもインストールされている
同じくなぜだか会社PCではお絵かきツールとして使われている、PowerPointだが、こちらはOffice HOMEエディションにはインストールされてない。じゃぁってことで。

５．カーソルキーで文字の入力位置が選べる
結構これ大事。マウスというポインティングデバイスを使わなくても、カーソルキーだけでセルを移動することができる。コントロールキーとの組み合わせを使えば、あちらこちらにジャンプできる。キーボードだけでお絵かきが出来るっていい。

６．そもそも開発ドキュメントなんて表が圧倒的に多い
テーブル一覧だの画面一覧だの、開発ドキュメントは圧倒的に「一覧」が多い。仕事というものを計測可能な状態にするのが、プロジェクトマネジメントなのだから、仕事とその成果物に名前をつけて、数えれる状態にしないと行けない。そうなると、システム開発を進めるというのは、一覧作りでしかない。じゃぁ、その付随図表含めてエクセルで作るのはなんらおかしくない。方眼紙のシートと表としてのシートが一つのエクセルドキュメントに共存できる。

そんな感じです。

在宅勤務について

米ヤフーのCEOが在宅勤務の禁止を唱えている。

トリガーの一部となっているのは、「オンラインだから家でも仕事できる」はずが、あんまりオンラインじゃないってこと。これは結構救いようがない。性善説に基づいていたけど善ではなかったという比較的レベルの低い話。

いったん性善説に基づいて家でも人は真面目に仕事をする前提で在宅勤務を考えてみる。

１）会社に居るのと同じくらいコミュニケーションできるから在宅でもいい
２）コミュニケーションを取らなくても成果で判断できるから在宅でもいい

１と２ではだいぶ違う。

１）の場合は結局のところ会社と同じくらいの「割り込み」や「時間のブロック」を許容しなくちゃいけない。家にいても、会議の時間はWebカメラの前に居なくちゃいけない。後輩が相談してきたら答えなくちゃいけない。じゃぁ会社にいくよってなるよね。お医者さんみたいな職業で丸一日いろんな人に対面での相談ごとを受けるのが主な仕事なら、在宅勤務の意味はほとんど無い。

２）の場合は例えばソフトウェアをちゃんと作っていればOKとかそういうこと。それなら確かに会社にいなくていい。でもそれってそもそも従業員である必要があるんだっけ？というところまででさかのぼる。業務委託契約と変わらなくない？本当に成果物だけで判断しても労働者側はいいんだっけ？そこまでのパフォーマンス出せる人ってほんの一部であって、そういう人はもっと早くから独立してるんじゃない？

ということで、ガチで在宅勤務がルールとして整備されると、苦しい重いをする労働者の方なんじゃない？少なくとも「会社に居るだけで働いていることになる。」という方が労働者にとっては楽。

あと、日本の場合には、企業側に労働者の管理監督責任が発生する。通勤時含めて勤務時間の安全は会社が担保しなくちゃいけない。在宅勤務の場合の労働時間って何？ってなるとちょっと分かんない。労働者を子供扱いしましょうってのが国の基本思想なので、「自主性に任せる」というのは割と真逆。

全く仕様の分からないWebアプリの緊急保守をするとき

野戦状態でWebサービスを保守する必要が出てきたりする。そういうときのコツ。

１．少なくとも、ドメインは分かっているはず。
ドメインが分かっていたら、IPアドレスが分かる。IPアドレスが分かれば、どのマシンで動いているかが分かる。

２．Webサーバまでたどり着いたら、ドキュメントルートを探す
Webサーバのconfを見つける。大概は、/etc/httpd/conf　の下にある。confはInludeできるので、丹念に、Includeされているconfを探し出す。confの中にはドキュメントルートが定義されているので、そこでアプリのソースが保存されている実体のありかが分かる。

３．アプリをみたら次はDBのありか
「DB」とか「connect」とかのキーワードを頼りに、データベースサーバのありかを見つける。IPアドレスとユーザIDとパスワードがそこにあるはずなので、それを手がかりにデータベースまでたどり着く。

４．最後はちょこっと触って、アプリ保守を一周させる
例えば、画面をちょっと修正しないといけない場合には、画面に書かれている文言をちょっと修正する。句読点をつけるとか。それを直して、実際にアクセスして反映できるかどうかをみて、「今僕は本物のアプリを触れているよお母さん」ということになる。開発→ステージング→本番とリリースの手順はあるだろうが、それでも、「小さく触って本番でリリース出来る流れ」は一周しておく。

アプリのソースとデータベースまでたどり着けたらあとは、そこに「書かれている」ことが全て。ここからスタートしよう。

一番見つけにくいのは、cron。どのサーバのどのユーザで動いているのかがわかりにくい。てことでcronはできたら使わない方がいい。中間ファイルの削除とかなら、アプリのトリガーで古いファイルを削除するロジックをいれていただきたい。

確定申告書メモ

毎年迷っているのでいい加減メモを残しとく。


対象：株を持ってるサラリーマン編

●提出する資料

• 給与所得の源泉徴収票
• 特定口座年間取引報告書
• 配当等とみなされる金額の支払い通知書

●作るモノ

• 確定申告書B（ところが画面上はこの名前はでてこないので注意）

●利用サイト
所得税（確定申告書等作成コーナー）｜申告・納税手続｜国税庁
http://www.nta.go.jp/tetsuzuki/shinkoku/shotoku/kakutei.htm
IEでないと使えないから気をつけろ！
→確定申告書作成コーナーのリンクをクリック
「書面で提出」を選ぶ。e-Taxは電子証明書をもらうのにめちゃくちゃ手間がかかる。役所に何回も行かなくちゃいけなくて、早くから準備しなくちゃいけない。スピードを求める人は書面をオススメ。
→所得税の確定申告書作成コーナー
→年末調整済みを選択
→確定申告書等を印刷して税務署に提出する。（e-Taxは利用しない）

●「申告書を作成する」の選択
１）給与所得が一カ所の方
２）先に該当しない方
の選択肢があるが、１）の方は株式の申請がないので、株式の申告がある人は「左記に該当しない方」を選ぶ。

●配当の入力の注意点
・上場株式と非上場株式で入力欄が違うので注意

進捗管理の心がけ

「間に合いそうですか」って確認は意味が無い

何%進んでいるかを自己申告させることには意味が無い

あるのは成果物ができたかどうかだけ

完成はもうちょっと先でも、コストの投入は計測できる
例えば材料の費消とか

一番遅れがちなのは「着手」
中間生成物でいいので「着手ポイント」をみる

先行タスクの完了は後続タスクの着手をもって完了とする

Webフレームワークがカバーすべきこと

まず素のPHP・CGIで作ろうと思えば作れる

それで困らないら問題はない。特にPHPに至っては、クリエストリングのパースやセッションやファイルアップロードに関する関数が充実しており、フレームワークがないと困る度合いが他言語に比べると少ない。

エントリポイントの一元化

ほとんどの場合、画面全体で共通の処理が走る。例えばデータベースの接続や、必要なライブラリのrequire。特に開発環境と本番環境での設定の切り替えをここでやっとくといいエラーの画面出力を、開発環境と本番環境でON/OFFを切り替えたりとかね。

イグジットポイントの一元化

途中までは同じであっても、最後には必ず通って欲しい処理というのがある。
例えば、携帯サイトでは、機種に応じて文字コードや絵文字の変換処理が入る。さすがに最近はそこまでするケースが減ってきた。ログの出力とかはここで共通でやっておくといい。

controllerとviewの組みあわせ

「どう機能して欲しいか？」「どんな画面を見せたいか」というのが、controllerとviewの分離ということ。
これが機能するのは、こういう画面遷移。

• 　フォームに入力→送信
• 　エラーがあれば、元のフォームの画面、エラーがなければ確認画面
• 　確認画面から、更新でデータ更新、戻るボタンで元のフォーム

この画面遷移で、同じ入力フォームに「入力を受け付ける」「エラーを表示させながら再度入力を受け付ける」「確認画面から戻りながら再度入力を受け付ける」という3つのルートがある。コントローラーはそのルートを別扱いで判断をするが、ユーザから見える画面はほぼ同じものなのだ。

さらに、PCとスマートフォンの両方をカバーするようなプログラムになると、同じURLで別のHTMLを表示するようになる。この場合はcontrollerが同じでviewが違うというケース。

これがフレームワークで最も必要な機能。

処理の分岐で別画面を表示するときに、リダイレクトを使うという手もあるが、リダイレクトはGETリクエストなので、ユーザが入力したPOSTデータを引き継げない。さらにhttpヘッダの出力で画面を切り替えるために、うっかりデバッグ用の出力をすると機能しない。

モデルの抽象化

モデルという概念がある。大概の場合には,データベースに対する接続を抽象化したものである。モデルの処理は、必ずしもデータベースに実在するものでなくともよく、
　「従業員クラス」の「男女」メソッドは、DB上は、1,2という数字で入っているものを、メソッドでは「男、女」と返すみたいなことをしてもいい。
　ただ、そこまで使いこなしている人も一部で、単にデータベースの接続便利ツールとして使ってる人も多い。

「このテーブルを更新するときには、かならずこのテーブルも更新しとく」みたいなデータの整合性も、モデルが担保しておくといいが、その処理をコントローラーに書いちゃう人もいる。「必ずやってほしいこと」はモデルのクラスでカプセル化して欲しいが、このあたりは保守性の問題であって、ロジックの大きな違いにはならない。

まとめ

ということで、Webアプリケーションフレームワークでいろいろありがたいことはあるが、その価値のかなりの部分をcontrollerとviewの分離が教授しているということ。逆にcontrollerとviewが分離できないフレームワークは、結構しんどい。

授業をクイズ番組にする

学生の時に塾講師をしていた。個人で経営されている塾で、割と自由にやらせてもらえた。

最初は普通に授業をしていたのだが、中学生にもなるとなめてかかってくる。宿題もやってこない。宿題をやってこない子には居残りをさせいてたが、敵もさるもので、適当な答えを埋めて「やってきたふり」をする。

ゴリゴリの進学塾ではないので、中くらいの成績から高校進学から悩んでいる子まで来ていた。

基本的には勉強をする気はない。ちょうど稲中が全盛期だったので、キャッキャしながら休憩時間に卓球をしていた。私も変に卓球は上達した。

そんな塾とはいえ、親御さんは成績アップを願ってお金を払ってくれている。成績の下降を食い止めなくちゃいけない。

最初は宿題の不正解数に応じた居残りをやらせていた。やってこなかった場合も、適当な答えを書いていた場合も居残り対象。

しかしその居残り勉強も、6割の正答率でよしとする子が結構いた。逆に、中くらいの塾にきてる賢い奴ほど、プライドが高いので、知らない問題に取り組まない。6割の理解でよしとしてしまう。因数分解で解ける方程式はやるけど、解の公式は彼の美学に反するのでやらない。共感はできるが、それではギリギリ合格しない。

その対応策として、居残り勉強も、連続で3問正解しないと終われないようにした。途中からは居残りではなく全員が参加にした。要は小テストなのだが、クイズ番組のフォーマットにしている。

1. 黒板に全員の名前を書いて、ポイントを書く
2. 一問出す。1分まつ（それくらいの小さな問題）
3. 10秒前からコールする
4. 回答を発表する
5. 正解するとポイントが上がり、間違うとゼロに戻る
6. １分間の復習タイム

この繰り返しで、３問連続正解すると、一抜けになる。一抜けのファンファーレはアメリカ横断ウルトラクイズ。

こうすることでいろいろ効果が出てくる。

1. 見直しをするようになった
• 「見直し」は苦痛でしかない。その気持は分かる。しかしながら、「一問でも間違うとリセット」なら、見直す方が得なのだ
2. 途中計算を書くようになった
• 賢い奴ほど途中の計算を書かない。ただそれだと見直しがしんどい。だから途中計算を書いた方が有利になる
3. 苦手を放置しなくなる
• ２問までとんとんといくと、３問目は彼が苦手としている分野を出す。彼がそこで問題を捨てたとしても、次の３問目も同じ問題をだす。本人は気付いてないだろうが、こちらは全員の苦手を知ってる。言われなくても、このパターンを克服しないとダメだなってことに気付く。
• 回答を出した後の復習タイム（と言っても１分で十分だが）で正しい解き方を覚えてもらう。
4. 下克上が起こる
• 子供達にもヒエラルキーがある。成績の序列はみんな分かってる。ただ、連続三問方式は、ケアレスミスも命取りになる。低位安定していたコツコツタイプがトップに立つこともある。天才タイプは負けると悔しい。中学生と言えど、「賢くありたい」という気持はあるのだ。かけっこが楽しいのと同様に、テストを通じて一番を決めるのは楽しい。
5. 緊張する
• 普通、塾でまず緊張はしないのだが、一問ずつ時間制限があって、一問ずつ答え合わせをするので、数分ごとに結構な緊張感が出てくる。それを乗り越えて、小さく勝ち負けが決まり、ランキングがダイナミックに変わる。賢くてなめてる奴も、賢くなくて諦めている奴も、そこではプライドをテーブルの上にBETしているのだ。

そんな感じ。

まとめると、「頻繁なフィードバック」が超大事。ゲームで言えば、プレーヤーが死ぬ場面。スポーツで言えば勝ち負け。学習においても「僕って賢いの？」という問いに頻繁に答えることができる場作りが大事。