真面目に、強く、上品に

たのしく、げんきに

24時間365日働くためには

概要

24時間365日働くための方法について考察する。

24時間365日働くとは

睡眠中・食事中・入浴中・移動中なども含めて常に仕事のことを考える、または仕事の実作業を行うこと。

睡眠中に仕事のことを考えるというのは想像が難しいが、睡眠中も脳は活動しており、 その活動の成果として、記憶の定着や夢を見る、という現象が発生する。

睡眠中に仕事のことを考えるとは、いかにして記憶の定着や夢をみやすい環境を作るか、ということを意味する。

24時間365日働くためには

前述した通り、仕事に対する思考または実作業が必要であるため、ベースとなる脳の活動量・体の健康・精神面での健康が必要不可欠である。

趣味は仕事に関連する以外のものについては、時間を大幅に消費するため、仕事に関連のない趣味は全て捨てる必要がある。

人間関係においては、仕事に関連しない飲み会の誘いを基本的に断る必要がある。

ただし断ることにより、人間関係には大なり小なり影響を与える。

仕事を進める上で過去の人間関係が重要になる局面は多々あるため、断ることによりその人との関係例が終了しない、を判断基準とする。

また、情熱や執念、心の底から楽しむ、と言った喜怒哀楽が無ければ、生きている間常に仕事をし続けるというモチベーションを保つのは難しい。

24時間365日働ける人は、働くことがが自然となっており、だからこそ続けていけているのだ。

まとめ

まとめると以下のとおりである。

  • 健康な身体がある
  • 健康な精神がある
  • 趣味を捨てる
  • 断ることによりその人間関係が終了しないなら全ての飲み会は断れている
  • 仕事に関わることにより喜怒哀楽に関わる感情が維持される
  • 働くことを当然と思う

「マンガでわかるプロジェクトマネジメント」を読んだ

概要

「マンガでわかるプロジェクトマネジメント」を読んだため、要点と感想を記す

なぜ読んだか

ITに限らない、より一般的な意味でのプロジェクトマネージメントに関する本を読んだことがなかったため、一度汎用的に使えるプロジェクトマネージメント手法について目を通しておきたかったからだ。

マンガで解説しつつもそれを補う形で文章での説明があり、amazonでの評価も悪くなかった。

以上から、必要最低限のプロジェクトマネージメントについて最速で学べると考えて、この本を購入して読んだ。

内容について

マンガで大まかな流れを説明し、細かい説明は文章解説がされているため、読みやすい。

以下、重要だと思った点についてまとめていく。

プロジェクトとは

今までにない製品などを決められた期限内に作るような仕事をプロジェクトと言う。

プロジェクトは目的や成功基準を明確にするのが重要。

プロジェクトは生き物。常に観察をする。

プロジェクトマネジメント知識体系とは

プロジェクト成功率が上がる経験則。

PMBOK(Project Management Body of Knowledge)がデファクトスタンダード

プロジェクトマネージャーの責任

スケジュール・予算などに制約がある中で、計画・推進指示・調整などを行い、目標を実現し成功に導くこと。

プロジェクトマネージャーにとって最も大切な能力

コミュニケーション能力。

会話がうまいという意味ではなく(会話は下手だが優秀なプロジェクトマネージャーもいっぱいいる)、

相手の考えを正しく理解し、自分の考えを伝える能力のことを指す。

自分の考えを伝える能力とは単に自分の考えを述べるだけではなく、相手の理解度に応じた言葉を選んで話したり、自分の言いたいことが伝わっていない様子を察知し伝え方を変えてみたりといった、状況に応じた対応が出来る能力も含む。

ステークホルダーとは

プロジェクトに直接関わっている人、またはプロジェクトを実施することにより何らかの影響を受ける人。

プロジェクト計画に必要なもの

  • 必要作業の洗い出し
  • 作業手順
  • 作業時間の見積もり
  • 作業スケジュール

プロジェクトを短くする方法

本には書いてないが、以下の手法もある。

  • 機能を見直し、重要度の低い機能を落とす

見積もりで大切なこと

以下の三つ

  • 大きな費用がかかる項目を見逃さない
  • 大きく変動しそうな費用を把握する
  • 予備費をある程度予算に盛り込む

見積もり方法

  • 類推見積もり
    • 過去の類似プロジェクトの総コストと作業量と今回の作業量を比較して、今回の作業量を見積もる
  • 係数見積もり
    • プロジェクトの総コストを y= f(x,y,z....) という関数で定義して、 過去のy1,y2,y3...といったデータから 総コスト評価関数を予想し、見積もる
  • ボトムアップ見積もり
    • 詳細なアクティビティのコストの足し算

検査よりも予防

品質は計画、設計、作り込みにより達成されるものであり、検査によってではない。

リスク対策

以下の四つの対応方法がある

  • 回避
  • 転嫁
  • 軽減
  • 受容

進捗確認の目的

  • プロジェクト計画との差異の発見
  • 将来起こりうるリスクの低減
  • 計画との差異の低減

プロジェクト終了後にやること

成否に関わらず、プロジェクトの反省会を行う。 良かった点と改善点を洗い出しておく。

まとめ

さっちゃんは可愛い。

マンガでわかるプロジェクトマネジメント
マンガでわかるプロジェクトマネジメント広兼 修 さぬきやん

オーム社 2014-06-26
売り上げランキング : 26203


Amazonで詳しく見る
by G-Tools

人にサービスを使ってもらうために意識すること

概要

人にサービスを使ってもらうために意識することについて考察する。

新しいサービスを使う理由について

現状に満足していたらわざわざ大小のコストをかけて新しいサービスを使おうとは思わないので、 新しいサービスを作るということは現状に満足していないことに等しい。

現状に対する不満については、以下の種類に大別できる。

  • サービスの仕様に対する不満
    • 飽きた
    • 使いにくい
    • お金がかかる
    • 時間がかかる
  • サービスを取り巻くコミュニティに対する不満
    • 過疎
    • 年齢層
    • 趣向の違い

新しいサービスが使ってもらえるか使ってもらえないかは上記の不満を解決出来るかに依るところが大きいのではないかと考える (もちろん、この新しいサービスを認知してもらう広報も極めて重要な要素であるが、ここでは一旦おいておく)。

事例

既存のサービスに対する不満とその不満を解消するサービスを開発しそれが広まった事例を記述する。 この事例はとても小規模なものであるが、大規模サービスにもスケール出来る考え方であると個人的に思っている。

チケット作成コストを省力化するサービス

会社ではJIRAでチケット管理をしているが、そのチケットの作成が毎回時間がかかるものであった。 その理由は以下の通りである。

  • チケット作成リンクをいつも忘れる
  • チケットを作成するまでに何回かページ遷移が発生する
  • チケットを作ったことをSlackチャンネルで報告する必要がある

現状のチケット管理に不満があったため自分が使うために即席でSlackbotを開発した。

仕様としては、botに対して発言するとその内容がそのままチケットとして発行される、というシンプルなものだが、 上記リストでかかっていた作業をワンアクションで完了できるようになった。

運用を開始してから当日の次点で他のチームメンバーもそのbotを使用するようになった。

そのチャンネルに入っていた別チームの人もそのbotを使おう、ということでその対応のためにプロジェクトコードに対してプルリクエストを送ってくれた。

なぜサービスが広まったか

サービスが広まった理由としては以下のことが考えられる

  • 新しいサービスを利用することで既存のコストを大幅にカットできる
  • 新しいサービスが簡単に利用できた
  • 新しいサービスを利用することに心理的障壁がなかった
  • 既存ユーザがおり、新規ユーザから既存ユーザを観測できた
  • ユーザ数が増加傾向にあった
  • publicリポジトリとしてコードが見えるところにおいてあり、改変を自由に加えることが出来た

まとめ

ユーザ視点から考えた場合、以下の要素が大きい。

  • コストカット出来る
  • 簡単に利用できる
  • 既存ユーザがいる

既存ユーザがいるという点については、開発者が1番目のヘビーユーザであるのが重要。 開発者が常用しないサービスは誰も使わない。

「スマートフォンアプリマーケティング現場の教科書 リフロー版」を読んだ

概要

スマートフォンアプリマーケティング現場の教科書 リフロー版」を読んだのでまとめと感想をここに記します。

何が書かれているか

スマートフォンアプリに関わる企画、ビジネス、プロモーション、運用、マーケティング、分析について、企画からリリース、リリース後まで順序だてて、解説している。 この本を読むだけで、たとえスマートフォンアプリ開発の経験や質機などが無くても、スマートフォンアプリ開発・運用において必要十分の知識を得ることが出来る。

どの辺りが参考になったか

特に参考になったのは、企画立案手法、プロモーション手法、UI/UX開発手法だ。

スマートフォンアプリだと1人で企画・開発・運用までをやることが多いが、 その場合によく確立された企画手法に頼らずオレオレ開発メソッドで開発してしまうことがある。

そのような開発メソッドでは、ユーザの使い勝手などを考慮せずに、開発者が都合の良い仕様になりがちであるため、 この本に記述された典型的な企画立案手法、プロモーション手法、UI/UX開発手法を実践することで、 単独での開発の際に陥りがちな独りよがりな仕様を回避することが出来る。

覚えておくべき要点

  • ユーザのニーズを把握する
  • UXは超重要であり、UXを元にUI・仕様を考える
  • 競合アプリを調査する
    • 競合アプリに対する優位性・差別化を意識する
  • スマホアプリにおいて、プロモーションは超重要
    • あらゆる手法・媒体を使ってプロモーションを行う
    • 現在のスマホアプリにおいてまともなプロモーションが無ければ見向きもされない

感想

以前リリースしたスマホアプリは、この本に書かれたプロモーション手法を実践することで、固定ユーザをリリース時に獲得することが出来た。

その当時はこの書籍をまだ読んではいなかったが、プロモーションを実施するまではほとんどダウンロード数はゼロに等しかったため、プロモーションは超重要であるということを身をもって体感した。

AppleWatchの音声入力機能を使った処理系を作る

はじめに

これは 第2のドワンゴ Advent Calendar 2016 - Qiita 18日目のために書かれた記事です。

なぜAppleWatchの音声入力機能を使った処理系を作るのか

AppleWatchの文字入力はキーボードやタッチUIを利用することが出来ないため、文字入力方法としては以下の3つが用意されています(数字のパスコードの入力については専用のタッチUIが用意されていますが、あくまで補助的なものです)

  • 定型文
  • 音声入力
  • 手書き入力

この中では個人的に音声入力について一番将来性を感じており、入力には多少癖のあるものの、慣れればかなり精度の高い音声認識を行うことが可能です。

私はこの機能を使って移動中に思いついたアイデアなどをEvernoteに書き込んでいます。

この機能をもうちょっと知的に使うことは出来ないかと思い、丁度良い題材として音声を入力とした簡単な処理系を実装することを思いついたため、実装してみました。

仕組み

f:id:ymizushi:20161218195652j:plain

雑な図ですが、全体構成としては上図のような形になっています。

初めはクライアント側で完結する処理系を書こうと思っていましたが、 Swiftの正規表現処理機能が貧弱でかつ私が慣れていなかったため1日で実装が間に合う自信がなかったこと、 また他のデバイスでも汎用的に使えるようにしたいということから、 慣れたPythonでサーバーサイドで処理系を実装し、クライアントからはAPIベースでの処理系への入力・出力と出力のレンダリングのみを行う構成にしました。

サーバーサイドでは以下のAPIを用意しました。

  • セッション作成API
  • セッション削除API
  • Eval API

セッションIDをキーに処理系が保持する環境をRedisに保存しています。

出来ること

現段階では、以下のことが可能です。

  • 代入
  • 評価
  • 加算

もうちょっと本格的な言語機能を作り込みたかったのですが、直前過ぎて時間切れでした。 今後AdventCalendarに登録する時は、もうちょっと前もって作っておこうと思います。

動画

一応動画を撮ってみました。 prog - YouTube

リポジトリ

展望

今回は最小の機能として代入、評価、加算を実装しましたが、入力を学習して何らかのレコメンドに役立てたり、よりファジーな入力も受け付けられるようにできると、より応用の幅が広がるのではないかと思います。

Apple Watch Sport 42mmスペースグレイアルミニウムケースとブラックスポーツバンド
Apple Watch Sport 42mmスペースグレイアルミニウムケースとブラックスポーツバンド
アップル
売り上げランキング : 9962


Amazonで詳しく見る
by G-Tools
Flask Web Development: Developing Web Applications with Python
Flask Web Development: Developing Web Applications with PythonMiguel Grinberg

O'Reilly Media 2014-04-28
売り上げランキング :


Amazonで詳しく見る
by G-Tools

特定の相手のAmazonアフィリエイトリンクを生成する

何故するか

皆さんはAmazonアフィリエイトIDを持っているでしょうか。

Amazonアフィリエイトは御存知の通り、特定のIDを含んだURLからAmazonの商品を購入することで、IDの管理者にお金が入るサービスです。

何かWeb上の記事を経由してAmazonで商品を購入した場合、たいていこのAmazonアフィリエイトIDが入っていると思います。

アフィリエイトIDの所有者自らが自身のID経由で購入しても利益にはならないことから、 わざわざ自分がamazonで何かを購入する時に、他人のアフィリエイトIDを設定するという人はあまり多くないと思います。

しかし個人的にそれは非常に勿体無いと思うので、是非他人のアフィリエイトリンクを踏んで購入することをおすすめしたいです。

その理由としては以下のとおりです。

購入者が不利益を被ることはない

自分の行為で他人が儲かるのを不快に感じてしまう人が一定数いるとは思いますが、少なくともamazonアフィリエイトリンクの場合は、 他人のアフィリエイトリンクを踏んだことにより購入者が被る不利益は全くありません。

押し売りされるといった場合は話が別だとは思いますが、元々買う意欲があったからこそ購入しているわけで、購入した結果にアフィリエイトリンクのあるなしは関与しません。

利益のシェアが出来る

例えば数人グループでお互いのアフィリエイトIDを使うことを取り決めた場合、そのグループの全体の金額はアフィリエイト収入分だけ少なくすることが出来ます。

Amazonのヘビーユーザ/ライトユーザで多少儲けに偏りが出ることはあるとは思いますが、元々利益にならない予定だったものを利益にしているわけです。

あまり細かいことは気にせず、収入があることを喜びましょう。

喜びをグループで分かち合える

グループでお互いに収入があったことを報告し合えば、世知辛い人生を多少なりとも楽しくすることが出来ます。

その連帯感はいずれ世界を救わないとも限りません。

グループの連帯感を大切にしましょう。

特定の相手のAmazonアフィリエイトリンクを生成する方法

さて、これで他人のアフィリエイトリンクを踏む有用性が理解できたとは思いますが、いちいち自分で他人のアフィリエイトタグを入力するのはちょっとばかり手間です。

ということを少し話していたら、hirokikana (Hiroki Takayasu) · GitHub さんが 翌日 Amazon Affiliate Link Generator - Chrome Web Store 拡張を作ってくれました。

設定も簡単だし、皆さんも是非こちらを活用してみましょう。

終わりに

柄にもなくAmazonアフィリエイトリンクについて語ってみましたが、いかがでしょうか。

アフィリエイトリンクについて毛嫌いする方も多いとは思いますが、大多数の人にとってアフィリエイトリンク収入は雀の涙ほどのものです。

しかし雀の涙ほどの収入でも、利益があるというのは大変うれしいし、素晴らしいことです。

もしかしたら人生になんの希望も愛も感じられなかった人が、とある人からのアフィリエイト収入で生きる希望を見出した、という事例もあるかもしれません。

良いアフィリエイト生活を。

世界一やさしい アフィリエイトの教科書 1年生
世界一やさしい アフィリエイトの教科書 1年生染谷 昌利 イケダ ハヤト

ソーテック社 2015-01-17
売り上げランキング : 19281


Amazonで詳しく見る
by G-Tools

プログラミングはスキマ時間にこそやるべき

概要

プログラミングはゾーンに入るまでの時間が長いため、スキマ時間にプログラミングをやることに対して躊躇いが発生してしまうことがあるが、 以下の理由からむしろスキマ時間にこそプログラミングをやるべきなのではないか。

プログラミングをスキマ時間にやったほうが良い理由

この場合のスキマ時間とは 10分〜1時間ぐらいを指す。

心理的障壁を低減出来る

スキマ時間ならばプログラミングに対するモチベーションが沸かないときにでも、心理的障壁が少ない状態でプログラミングに取り掛かることが可能である。

モチベーションを維持出来る

スキマ時間にプログラミングをすることで、コードは常に中途半端な状態になるため、この作業を終わらせたいという意欲が、じっくり取り掛かれる時間帯まで維持される。 それにより、じっくり取り掛かれる時間におけるプログラミングに対する心理的障壁が少なくなる。

ちりも積もれば山となる

1日30分、スキマ時間にプログラミングするとした場合、1ヶ月で 30 * 30 / 60 = 15時間 のプログラミング時間が確保出来る。

密度の高い時間を過ごせる

時間があると思うとだらだら作業しがちだが、30分なら集中した時間を過ごすことが可能

結論

スキマ時間にプログラミングをやることに対して躊躇いは必要ないし、積極的にやったほうが良い。

「なぜ、あなたの仕事を終わらないのか」を読んだ

概要

UIEvolutionの創設者が実践してきた「時間術」が本書では披露されている。 著者が実績のあるエンジニアであるため、エンジニア視点から実践してきた「時間術」は説得力がある。

要点

  • 期限のあるタスクはスタートから期限までにおける初めの2割の時間で終わらせる
    • それで終えることが出来ないタスクは期限に間に合わないため、その時点でプロジェクトの延期が必要
  • 仕事は難しいことから始める
  • ロケットスタート以外では徹夜はしない
  • 仕事が終わらない理由は以下の3つに集約される
    • 安請け合いしてしまう
    • ギリギリまでやらない
      • ラストスパート志向が諸悪の根源
    • 計画の見積もりをしない
  • 仕事は100%を目指さない
  • 納期に間に合わせることを最優先
  • 設定された締切の前に実質的な締切が存在する
  • 与えられた仕事は絶対に達成する
  • 時間を制するものは世界を制する
    • リスクを測定できる
    • プロトタイプを素早く作ることができる
    • 誤差に対応できる
  • 予習は学習に対する最も効率的な時間の使い方
  • 目的達成のために不必要なことはしない
    • 仕事は規則を守ることではなく仕事で成果をあげること
    • そのために規則を破る必要があるのであれば、規則を破るべき
  • 他の人の仕事が遅れたらモックを作る
  • 勉強のための勉強に意味はない
    • 必要になったときに学習する
  • 楽しくて仕方がないことを仕事にする
    • やりたいことには思い切って飛び込む
  • 「無理だ」という人の多くがじつはそのことについて実際にはほとんど何も調べてもいないし、考えてもいない
  • やりたいことが見つからないなら、アンテナが広い人に話に聞きに行く
  • 何かを成し遂げたり幸せな人生を手に入れるためには、「好きなことに向き合い続けること以外に方法はない
  • 新しいことをやるための期限付きの努力であれば、集中が難しい人も集中して耐えぬける
  • 寝る前にやること
    • 出社する前から仕事をする
    • 明日行うタスクを記述する
      • 15分程度で終わるタスクに分解して記述
      • 15分程度であれば、終えるごとに達成感を得やすく、仕事のリズムをつかみやすい
  • 嫌なことをやりたくなければ効率化する
    • やりたいことをやるためにはやりたくないことを速攻で終わらせる
  • 言葉で説明できなければプロトタイプをまず作る
  • 企画をすばやく形にしたものがチャンスを掴める
  • 仕事は最速で終わらせない
    • いつも全力を出していると、真の実力を発揮できない
    • 仕事を安定して続けることを意識する
  • メール・ルーチンタスクはは流しの時間に対応する
  • 昼寝を18分する
  • 朝に仕事をする
  • マルチタスクをやめる

書籍

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である中島聡

文響社 2016-06-01
売り上げランキング : 1011


Amazonで詳しく見る
by G-Tools

Flask Blueprint における template_folderパス解決の罠

Flask には Blueprintというアプリケーションをモジュール化出来る機能が備わっていますが、このBlueprintのtemplate_folderパス解決にはちょっとした罠があります。

Flaskで以下のようなパッケージ構成を組んだと仮定します。

run.py
admin/
    __init__.py
    views.py
    pages/
        index.html
frontend/
    __init__.py
    views.py
    pages/
        index.html

admin/views.py

from flask import Blueprint, render_template
admin = Blueprint('admin', __name__, template_folder='pages')

@admin.route('/')
def index():
    return render_template('index.html')

frontend/views.py

from flask import Blueprint, render_template
frontend = Blueprint('frontend', __name__, template_folder='pages')

@frontend.route('/')
def index():
    return render_template('index.html')

run.py

app = Flask(__name__)

from admin.views import admin
app.register_blueprint(admin)

from frontend.views import frontend
app.register_blueprint(frontend)

一見template folder として admin/views.py では admin/pages/ を 、 frontend/views.py ではfrontend/pages/ を参照するように読めます。

しかしこのコードは正常に動作しません。

admin/views.pyfrontend/views.pytemplate_folder が、admin/pages/ になるか 、 frontend/pages/ になるかは不定となります。

Flask Blueprintのマニュアルを参照してみると以下のように記述があります。 Modular Applications with Blueprints — Flask Documentation (0.10)

So if you have a blueprint in the folder yourapplication/admin and you want to render the template 'admin/index.html' and
you have provided templates as a template_folder you will have to create a file like this: yourapplication/admin/templates/admin/index.html.

つまり、以下のようなパッケージ構成にする必要があるということです。

run.py
admin/
    __init__.py
    views.py
    pages/
        admin/
            index.html
frontend/
    __init__.py
    views.py
    pages/
        frontend/
            index.html

admin/views.py

from flask import Blueprint, render_template
admin = Blueprint('admin', __name__, template_folder='pages')

@admin.route('/')
def index():
    return render_template('admin/index.html')

frontend/views.py

from flask import Blueprint, render_template
frontend = Blueprint('frontend', __name__, template_folder='pages')

@frontend.route('/')
def index():
    return render_template('frontend/index.html')

この仕様は度々Flaskの利用者に誤解を与えてきたようで、以下のように Issueでも議論にもなりました。 Blueprint template lookup not documented enough · Issue #266 · pallets/flask · GitHub

なぜこのような仕様になっているかというと、実装上の都合です。

Flaskで指定するtemplate_folderは Jinja2 の FileSystemLoader のsearchpathに渡されます。

searchpathはアプリケーションのトップレベルに追加され、再帰的に検索されるため、template_folderで指定したディレクトリ文字列がかぶっているとどのテンプレートを選択すれば良いのか一意に特定出来ません。

そのため、このような仕様になっています。

Flask Web Development: Developing Web Applications with Python
Flask Web Development: Developing Web Applications with PythonMiguel Grinberg

O'Reilly Media 2014-04-28
売り上げランキング :


Amazonで詳しく見る
by G-Tools
Pythonスタートブック
Pythonスタートブック辻 真吾

技術評論社 2010-04-24
売り上げランキング : 1920


Amazonで詳しく見る
by G-Tools

数万円の炊飯器が1500円で買った炊飯土鍋に負けた

最近にわかに注目を集めている炊飯土鍋。

私も同僚から布教されて最近炊飯土鍋を使い始めたのですが、すっかり虜になってしまいました。

「炊飯土鍋を使うと炊飯器が不要になる」、布教者は口々にそう言います。

しかし元々炊飯は鍋でしていたしそれを淘汰するメリットがあったからこそ炊飯器は消費者に広く普及したはず。

そう考えていた私はその布教の言葉に半信半疑だったのですが、実際その通りになってしまいました。

理由としては炊飯器と炊飯土鍋、どちらにもメリット・デメリットはあるのですが、 総合すると明らかに炊飯土鍋の方が上という結論に至る人が多くなってきた、ということでしょう。

比較するために、私の考える炊飯器・炊飯土鍋のメリット・デメリットなどを項目別にまとめてみました。 3合炊きを前提とします。

価格

炊飯器は安いものは電気釜で5000円ほど、IHで高価なものは5万ほどします。 炊飯土鍋は安い商品なら1500円ほどで購入でき、高いものでも1万円以内であることが多いです。

価格の面では明らかに炊飯土鍋に優位性があるでしょう。

耐久性

炊飯器は機械的に壊れるリスクがあり、炊飯土鍋は割れるリスクがあります。

炊飯器が機械的に壊れた場合は、新品を正規のルートで買えば1年のメーカー保証があります。 炊飯器を1年より長い期間使用した時の故障率については、明確な資料がなかったため不明です。

ただ経験的に言うと私は、炊飯器はそれほど壊れやすいものではないと思います。

炊飯土鍋のAmazonレビューで安い商品は「炊く時に割れた」という評価がされている時もあるので、 意外と割れるリスクは高いのかもしれません(私の身の回りで割れた人はまだいませんが)。

ただ割れても安いものであれば1500円ほどなので、あまり故障率は気にしなくても良いと思います。

物理的に落として割れるリスクが一番高いと思うので、炊飯器よりは慎重に扱ったほうが良いでしょう。

美味しさ

これは圧倒的に炊飯土鍋の方が良いと考えています。

炊飯器は高級なものであればあるほど美味しく炊けるのですが、最上位の炊飯器でさえ1500円の炊飯土鍋に敵わなかったです。

そして炊飯土鍋はおこげを簡単に作ることが出来、おこげの量で風味も変わってくるので、 味のバリエーションを簡単に出すことが出来るというメリットもあります。

また、私の経験的には炊飯土鍋で炊いたお米は冷蔵庫で冷やした後温めなおしても美味しさが劣化しにくいです。

設置条件

炊飯器(電気釜)の場合は電源の確保ができるところ、炊飯土鍋であればガスが使用できるコンロが前提となります。

電源がない家屋はあまりないと思いますが、ガスコンロが使えない家屋はそれなりにあるため、設置条件は炊飯器の方が緩いです。

手軽さ

これについてはだいぶ人によって評価が変わりそうです。

炊飯土鍋は基本的に米を30分以上水に浸すのが前提になりますが、炊飯器ではそういう前提は無いです。 ただ炊飯器で炊く時も水を30分以上浸したほうが美味しく炊けるので、これについて私は特に炊飯器との違いを感じませんでした。

炊飯土鍋に比べ炊飯器は、安全に炊ける、予約機能が使える、炊きあがるまで時間管理をしなくて良いという長所があります。

炊飯土鍋の場合は火を使うため、時間を測って安全と炊きあがりに注意して炊く必要があります。

炊飯土鍋は3合炊きの場合、火にかけるのは15分ほどです。 コツを掴めば15分タイマーで測ってあとは火事にならないように気をつければいいだけです。 むらす時間を併せても30分ほどで炊きあがるので、炊飯器と比べてそれほど面倒だとは私は感じませんでした。

まとめ

以上のようにまとめてみましたが、どの要素に重きをおくかというのは人によって変わってくるとは思います。

ただ多くの炊飯土鍋愛好家は、明らかな美味しさと手間はそれほど炊飯器と変わらないという認識から、炊飯土鍋を選択しているように感じています。

そして私の周りでは、炊飯土鍋を試してから、炊飯器を使う生活に戻った人は一人もいません。 そう、ただひとりとして。

既にちょくちょく炊飯土鍋の紹介記事が出ているので、私があえて宣伝する必要は無いかもしれませんが、 この記事で炊飯土鍋愛好家が増え、よりよい自炊生活を送るきっかけとなれば幸いです。

和平フレイズ ほんわかふぇ 炊飯土鍋 二重蓋 3合炊 HR-8382
和平フレイズ ほんわかふぇ 炊飯土鍋 二重蓋 3合炊 HR-8382 炊飯 ごはん土鍋 3合炊き(二重蓋) 大黒 万古焼有田焼 遠赤セラミックス ご飯用保存容器 おひつ君(1500cc)

ニコニコ動画にartihata動画を投稿しました

株式会社ドワンゴの運営するニコニコ動画にEmoji組版編集サービス artihata の紹介動画をアップしました。

artihata では言語はClojureClojureのWebアプリケーションフレームワークである Luminus を採用しています。

ほとんどの実装はJavaScriptで記述されているので、Webアプリケーションフレームワークはあまり関係がないのですが、Luminusはテンプレートが豊富でぱっと実現したいサービスがさくっと作れるのが良いですね。

Clojureで一番のオススメWebアプリケーションフレームワークです。

Clojureは覚えることも少なく、プログラミング経験があまり無い人でもアプリケーションをさくさく書けます。

とりあえず、以下の書籍を読んでおけばアプリケーションを書くには必要十分だと思います。

プログラミングClojure 第2版
プログラミングClojure 第2版Stuart Halloway and Aaron Bedra 川合 史朗

オーム社 2013-04-26
売り上げランキング : 341785


Amazonで詳しく見る
by G-Tools

Clojure日本語書籍まとめ[2015年6月時点]

Clojureの日本語書籍も数冊出るぐらいになりましたので、ここで一つ2015年6月時点でのClojure日本語書籍についてまとめてみました。

プログラミングClojure 第2版

Clojureの日本語書籍といえばまずコレ。

ハワイ在住Lispハッカーとして有名な川合史朗さん訳なだけあって、こなれた日本語での正確な記述は他のClojure日本語書籍の追随を許さないです。

内容も特別難しい訳ではないので、関数オブジェクト、ポリモーフィズム、マルチスレッドプログラミング辺りの概要が把握できていれば、 プロトコル、ソフトウェアトランザクショナルメモリ、エージェントなどのClojure特有の機能についてもすんなり理解できると思います。

おいしいClojure入門

プログラミングClojure 第2版 に比べて、周辺ツールフレームワークに焦点を絞って解説したのが本書です。

Clojureは言語自体の魅力もありますが、デファクトスダンダードとなっているLeiningen、Clojureらしいサウンドプログラミング環境Overtoneなど、Clojure独自の周辺ライブラリ・ツールも魅力のうちの一つです。

本書ではClojureでよく使われる一通りのツール・ライブラリが解説されているので、どのようなツール・ライブラリを使えば目的を達成できるかを考えるときに本書は指針になるでしょう。

ただしClojureの周辺ライブラリは結構個人依存のプロジェクトが多いので、メンテされなくなるものも多いです。 本書を参考にしつつも、今流行っている・メンテが継続されているプロジェクトを把握するためにはgithubを巡回したほうが良いでしょう。

はじめてのClojure

dic.nicovideo.jp で有名になったニャンパス株式会社代表が執筆したのが本書。

内容自体は悪くないと思うのですが、 プログラミングClojure 第2版 の内容が素晴らしいので、領域がかぶる部分についてはこれより見劣りしてしまいます。 ただ プログラミングClojure 第2版 よりも価格は安いので、それなりに安い価格で言語の概要を把握したい方には良いと思います。

Clojureによる、初めての関数型プログラミング

Kindle専売のClojure日本語書籍です。 なんと100円。 題材となるゲームをClojureで実装していく過程を追えるので、体当たり的に学習したい方はこの本がオススメです。

Clojure Essentials: 入門書では飽き足らない人へ

プログラミングClojure 第2版 のそれぞれの単元を少し補完・踏み込んだ形で解説したのが本書です。

Effective Clojure的なものが欲しい方にオススメです。

まとめ

私が把握している限りで日本語でのClojure書籍をまとめてみました。 他にもClojureの日本語書籍を知っている方がいらっしゃれば教えていただければ幸いです。

さて、どの本を買えば良いかですが、個人的には プログラミングClojure 第2版 さえ読んで、あとは Clojure - home を読んでいくで十分な気がします。

あまり踏み込んだ解説はしませんでしたが、とりあえず現時点での選択肢として以上にまとめてみました。

興味がある方の参考になれば幸いです。

ClojureのAgentで生成されるスレッドプールのサイズを変更する

ClojureのAgentの実装では、2 + Runtime.getRuntime().availableProcessors()で得られるサイズでスレッドプールを生成するが、このスレッドプールのサイズはset-agent-send-executor!に任意のExecutorServiceを渡して書き換えることが出来る。

set-agent-send-executor!が追加されたのはどうやらClojure1.5からのようだが、実装は、

(set! clojure.lang.Agent/pooledExecutor executor)

しているだけ。

以下のように使えばAgentのsend関数で使用されるスレッドプールを変更出来る。

(set-agent-send-executor! (Executors/newFixedThreadPool 20))

Flocking - Web Audio APIを使用した音響合成エンジン(その1)

FlockingとはJavascriptで実装されたWeb上で動く音響合成エンジンです。

日本語での紹介記事が現時点で皆無なので、紹介したいと思います。

Web Audio APIをラップする形で実装されており、 ブラウザが対応さえしていれば、Flashなどのプラグイン無しでマルチプラットフォームの音響合成処理を行えるのが特徴です。

このFlockingを使用し、実際にどのようなことが出来るかというのは、まずデモを見ていただいた方が早いと思います。 http://flockingjs.org/demos/interactive/html/playground.html#amp_mod

上記のデモにあるコードはブラウザから直接書き換え・実行することが出来ます。 そのためしばらく触っていれば、どのようなことが出来るのかはおおよそ把握できると思います。

JavaScript連想配列で柔軟な設定が行えるため、 ひと通りの音響合成を複雑なコード無しに実現することが可能です。

Flockingを使用する上で最低限理解する必要がある概念は下の4つです。

  • Unit Generators

Unit Generatorsは音声合成のベースと波形を生成します。 このUnit Generatorsによりシンセサイザーをコントロールする波形、シンセサイザーの入力波形を生成することが可能です。 Unit Generatorsは複数の入力と1つの出力を持ち、複数のUnit Generatorsを繋げることが可能です。

  • Synths

Unit Generatorから生成された波形を元に実際の音を生成します。 Synth自体にUnite Generatorが内蔵されているものもあります。 DAWなどでいうインスツルメントに近いです。

  • Environment

Unit GeneratorsとSynthsがそれぞれどのように繋がっているかを管理します。 DAWなどでもEnvironmentという名前で同じ名前が使用されます。

  • Scheduler

Synthsの実行タイミングを制御することが可能です。 DAWなどでいうシーケンサーに近いです。

今回は単純にFlockingの概要についてだけ説明しました。

次回は実際にFlockingを使用し、どのように音響合成を行うかについて説明をしたいと思います。

Homebrewでantがインストール出来ない問題に対処

HomebrewでAntをインストールしようとbrew install antを実行したところ、 以下の様なメッセージが表示された。

==> Downloading http://www.apache.org/dyn/closer.cgi?path=ant/binaries/apache-ant-1.9.2-bin.tar.gz
==> Best Mirror http://ftp.tsukuba.wide.ad.jp/software/apache/ant/binaries/apache-ant-1.9.2-bin.tar.gz

curl: (22) The requested URL returned error: 404 Not Found
Error: Download failed: http://www.apache.org/dyn/closer.cgi?path=ant/binaries/apache-ant-1.9.2-bin.tar.gz

どうやら、リンク切れなようである。

対処するため、とりあえず/usr/local/Library/Formula/ant.rbの 5,6行目のurlを1-9.3に変更して、sha1も変更。

再度、brew install antでインストール完了。

brewのコマンドを駆使するともっとうまいやり方がありそうだが、 ぱっと調べて出てこなかったのでとりあえずこの方法で対処。

もっとスマートなやり方あれば教えて下さい。

追記) Homebrewのmaster見たら2013-12-29に1.9.3にupdateされていたので、単にリポジトリをmasterに合わせれば問題ないっぽい。 https://github.com/Homebrew/homebrew/blame/master/Library/Formula/ant.rb#

以下のプルリクエストで修正されていた。 https://github.com/Homebrew/homebrew/pull/25537