サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
fujimura.hatenablog.com
仕事をしていて文章能力をどう上げるか?という話になったので、よく人に勧めている本を紹介します。といっても二冊ですが…。 ちなみに僕は正確で密度の高い文章を高く評価しているので1、その好みを反映したチョイスになっています。また、仕事に即使える!系の本は挙げていません2。そのかわり、長期的に力になるであろう汎用性の高い本を選んでいます。 戸田山和久『新版 論文の教室 レポートから卒論まで (NHKブックス)』 分析哲学の泰斗である戸田山和久さんが書いた論文の書き方の本。必ずしも正解がない問題について一定の解答を与え、その主張を説得力をもって誰かに伝える、という人文科学の論文のフォーマットと手法は3、そのままビジネスに応用できることが多いです。議論の組み立て方以外にも、パラグラフ・ライティング、文章術など参考になる箇所満載です。 スティーヴン・キング『書くことについて (小学館文庫)』 ご存知ス
基本全公開のesa、例外的に公開範囲限定のGoogle Docsという構成がよいと思っている 細かい公開範囲設定ができるツールを使うと、人間は公開範囲を設定してしまう 人間の行動は環境に規定される 公開範囲の設定が可能なツールを使うと、ドキュメントを書く度に「これはどこまで公開すればいいのか」という問いが無意識に生まれ、公開範囲を制限する、という選択肢が生まれる 全公開 or 制限という判断を迫られると人は安全側に倒れてしまうので、公開範囲を制限することになる 結果、多くのドキュメントは全公開ではなく、公開範囲が設定されることになる これにより細かいところで情報の非対称性が生まれる ドキュメントを読んでいて、そこにある別のドキュメントへのリンクを辿るが見えない、など バックグラウンドを詳しく知りたい、というWhyから考える精神の働きを妨げる esaは公開範囲の設定ができない 標準のドキュメ
歴史、ゲノム、経済学が多かった。哲学はあまり読まなかったな。 おすすめ3選は下記。 遺伝子―親密なる人類史(上)、遺伝子―親密なる人類史(下) あらゆる人におすすめ 「イノベーターのジレンマ」の経済学的解明 仕事で少しでもデータに関わる人におすすめ 維新史再考 歴史に興味がある人におすすめ 個人ベストはこれ。 経済史の構造と変化 では、読んだ本を紹介します。 バルカン―「ヨーロッパの火薬庫」の歴史 (中公新書) 作者: マーク・マゾワー出版社/メーカー: 中央公論新社発売日: 2017/06/20メディア: 新書この商品を含むブログ (3件) を見る オスマン帝国崩壊からバルカンの各国にナショナリズムが生まれる経緯でいろいろ揉め事が増えたよね、オスマン帝国時代はそれなりに様々な民族や宗教が共存できていたのに…というかその頃は民族をアイデンティティとするナショナリズムってなかったんだよね、と
もうすぐ文庫がでる『誰が音楽をタダにした』を読み終わりました。面白すぎて一日で読んでしまった。 CD全盛期に音楽を聞き始めた音楽マニアとしてはなかなか感慨深くも懐かしく、まがりなりにも作品をリリースしているアーティストとしては考えさせられることも多い本でした。 読了後に「音楽を聴く」という行為とそれをとりまく環境の変遷についてツイートしようとしたら長文になってしまったので、こちらにツイート下書き欄からコピペして改行を入れたものを転記してみます。書きなぐりの駄文なので読みづらいのはご容赦ください。 音楽聞き始めの1990年代末はアンダーグラウンドなアーティストや過去のカルトバンドの情報は断片的にしかなくて、音楽雑誌の隅っこの短いレビューやインタビューで挙げられる名前、レコード屋の広告の短いインフォが貴重な情報源だった。あとサンクスリストに載ってるバンドを片っ端から聴くとかしていた。みんなTシ
今年は哲学の入門書が豊作でした。後半は計量経済学に足の指先だけ突っ込んで面白さがわかってきました。小説はあまり読めず。 天才たちの日課 クリエイティブな人々の必ずしもクリエイティブでない日々 作者: メイソン・カリー,金原瑞人,石田文子出版社/メーカー: フィルムアート社発売日: 2014/12/15メディア: 単行本この商品を含むブログ (9件) を見る 面白かった。変な人が多い。仕事の仕方で悩んでる人にはヒントになると思う。 賢い組織は「みんな」で決める:リーダーのための行動科学入門 作者: キャス・サンスティーン,リード・ヘイスティ,田総恵子出版社/メーカー: エヌティティ出版発売日: 2016/09/08メディア: 単行本(ソフトカバー)この商品を含むブログ (5件) を見る 今年ノーベル経済学賞を取ったリチャード・セイラーと『実践 行動経済学』を書いた人、かつ、昨今社会科学の分野
確か年明けに書いたと思われる下書きが出土したので投稿してみます。一年分まとめて書くのは無理ですね…。 会社で「論理的な文章とは」というような話をしていて、若者に一冊読むならこれかなと思い、再読した。よく外銀・コンサル出身の人が言う「ファクトベース」は実証的な学問のやり方がベースになっているので、ファクトベース思考を身に着けたいなら、実証的な学問のやり方を理解するのが正確な近道だと思っている。その作法を知るにはよいテキストだと思います。 ついでにこれも今再読している。『論文の教室』と被る部分があって、そちらは作法がメイン(作法も重要です!)、こちらは主張の仕方がメイン。クリティカル・シンキングの本として、哲学の入門書として、とても良い本です。久々に読んで、自分の思考法のベースは哲学なんだなあと再認識した。もう卒業して10年経ってるんだけどな。実証的な主張がしにくい価値に関する主張の説得力をど
ハーバード大学哲学科のサイトにあった「なぜ哲学を学ぶのか」があまりに良かったので、精度が上がったという評判のGoogle翻訳を試すついでに訳してみました*1。 僕も大学で哲学を勉強していました。もはや半可通でしかないのですが*2、後半にある「哲学があなたに教えるスキル」は僕が仕事をする上で全ての基礎になっています。哲学を勉強してよかった。 原文はこちら。訂正などありましたら是非コメントください。 Why Study Philosophy? | Harvard University Department of Philosophy カリフォルニア大学バークレー校の哲学者であるジョン・キャンベルは、哲学についてこう考えていますー「それは、私たちがふだん凄いスピードで行っていることを分解し、説明し、評価する。すると、別の選択肢が可能であることがあきらかになる」。 哲学を学ぶことは、何千年もの間人
近況報告としては、退職のご報告からすっかり間が空きました。TechCrunchや東京新聞の記事で既にご存知の方もいらっしゃるかもしれませんが、2015年10月にProper, Inc.を共同創業し、現在「近所のつながりを通して、地域の課題を解決する」というミッションのもと、ご近所SNSマチマチを運営しています。 前職をやめてからは結構悩みましたが、こういう時は一番ハードルが高くてテンションが上がるやつを選ぶべきだ!ということで「自分でやる」って選択肢を選びました。パートナーは、直近だとOh My Glassesをやっていた六人部生馬です。複数のスタートアップを経験している、Rubyistと仕事をしている、神奈川出身であるなど共感できるところが多々ありつつキャラ的にも能力的にも補完的という、良いチームになりました。 今、マチマチの開発チームは、現在エンジニア1人(僕)デザイナー1人(元山さん
Hspecベストプラクティス Haskell Advent Calendar 2015 の14日目のエントリーです。 イントロ Hspec はHaskellコミュニティにすっかり受け入れられたテスティングフレームワークと言ってよいかと思います。しかし!まだ確たるベストプラクティスは無いと言えるのではないでしょうか! Hspecの元となったRSpecはRubyコミュニティでデファクト・スタンダードとなっており、ベストプラクティスの蓄積があります。これを、Haskellの事情を鑑みつつ適用してみようという記事です。 Hspecのチュートリアル BDDのチュートリアル ソフトウェア・テストのチュートリアル ではないので、その辺りは別の記事を読んでください。 あと、オフィシャルのexampleがあるので、これに先に目を通しておくと話が早いかもしれません。 気になる点、賛同できないプラクティス、改善
関数型ストリーム処理勉強会で発表したので、ブログにも書いておきます。 元になった資料はこちら Haskellでストリームデータを扱う方法としては、Handleを使う方法、Lazy IOがありました。しかし、それぞれに問題があり、再利用性が高く堅牢なコードを書くことは困難でした。 この状況を解決すべく、Conduit、Pipes、io-streamsなどのストリーム処理ライブラリが現れたのですが、そもそもそれらが必要とされた経緯は具体的にはどのようなものだったのでしょうか? 元ネタ: http://okmij.org/ftp/Haskell/Iteratee/talk-FLOPS.pdf ソースコード: https://github.com/fujimura/functional-stream-processing-meetup-sample そもそもストリームとは 必要に応じて処理されるデ
技術顧問ブームですね。先日退職してから色々な会社を回ってて、これニーズあるんじゃね?って仕事を何個か思いついたので、列挙してみます。 チーム開発を軸にした技術顧問 やること: 開発プロセスの構築・実行・改善、ミーティングのファシリテートを行い、チーム開発を良い感じにする。 必要そうなスキル: チームを作った経験。ソフトウェア開発プロセスの知識と実務経験。それなりの技術力。 GitHubでコードレビューしてCI/CDを回して、っていうスタートアップでよくあるエンジニアリングの型はある程度できているけど、うまく運用できていないところは少なくないと予想している。わかってる人が手伝ったら軌道に乗るまでが早そう。事業や組織の性質・フェーズに合わせる必要もあるし結構難しい。チームで仕事をするというカルチャーを伝えるのも価値がありそう。人間力が問われますな…。 個別技術を軸にした技術顧問 やること: 技
Quipperを退職しました & 求職中です - fujimuradaisuke's blog から一週間弱経ちました。 ありがたい事に沢山のお声掛けを頂きました*1。大変申し訳ないのですが、全てのご連絡にお返事できていない状況です…すいません!気がつけば今月のランチ・夕食の予定がほぼ埋まってしまいました。 で、7/24-7/28まで福岡に行きます。Rails Girls Fukuokaでコーチ。その後7/30から20日ほどタイ中心にアジアのどこかに行く予定です。シンガポールは確定、あとはスリランカかな。 今は部屋でこれを聞いてます。60分間、ひたすらミニマルに変化し続ける音楽。スーフィーの音楽を思い出しました。ジャケがかっこいい。 www.youtube.com wishlistからTシャツと本を送って頂きました!ありがとうございます。記念に着て自撮りを行いました。次の仕事の初出勤はこの
一言でいうと: Quipperを退職しました。Quipperの皆さん、本当にどうもありがとうございました!現在求職中です。ご興味あれば me@fujimuradaisuke.com か https://facebook.com/dfujimura までご連絡ください。Ruby、JavaScript、チーム開発のリード、などができます。wishlistはこちら 2015年6月末日をもって、Quipperを退職しました。 立ち上げ当初のMercariを体を壊して*1辞めて*2入院して手術受けて退院、さて今後どうしようと悩んでいるところで、ひとまずフリーランスで働こうとQuipperで働き始めました。2013年6月でした。 当初からフリーランスはあくまでモラトリアム期間という位置づけで、いずれは正式に会社に入るつもりでした。働いてみるとQuipperは想像以上によいところで、9月には正社員になっ
戦後日本を代表する東洋史学者が、西はシリアから東は日本まで含めたアジアを中心に世界史を論じる。文明間の交通を軸に話を進めるのでとにかくダイナミック。 シリアが古代より世界のハブだった、とか、プロテスタントの改革は既にイスラム教が成し遂げていたスキームの横展開だったとか、中世は近代のための準備期間だった、とか。中世に成功しすぎたイスラム世界は、その成功が故に没落も悲惨だった、とか。今のイスラム世界の辛い感じを見てどう思うんだろうな。 僕はウォーラーステインをちゃんと読んでないんだけど、その影響を受けたと思しき人の本を読む感じだと、とても似ているように思う。ということでニーアル・ファーガソン、水野和夫あたりが好きな人はハマるはず。 以下、面白い所を抜書き p.8 また文化の影響ということが、いつも清水の中にインキを垂らしてこれを染めるようにばかり行われるとは限らない。人類は叡智を持った生物なの
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。 ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。 ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。 ブランチ戦略 developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1 急ぐときはHotfixとしてmasterに直接プルリクエストを出してもOK*2。 リリース手順 HipChatで「リリースするよ」ってアナウンスする developからmasterにプルリクエストを出す HipChatでHubotに頼むと、Jenkin
Haskellでコマンドラインアプリケーション(以下CLI)を作る時の基本的な情報とTipsをまとめてみました。 Haskellは雰囲気で読める、しかしCLIはあまり作ったことが無い、って人が想定読者です。 この記事はHaskell Advent Calendar 2014の16日目のエントリです。 とりあえず何のサンプルコードも無く話を進めるのも雰囲気が伝わらないかなと思って、Gitリポジトリにあるファイルの中身を標準出力に出力するプログラムをls-moreという名前で作ってみました。 module Main where import Control.Monad import Data.Monoid import qualified Data.Version import Options.Applicative import Paths_ls_more (version) import
出張で一週間フィリピンに行きました。ここ数年、毎年一週間ほど海外に行ってるんですが、常に機内持ち込みのバックパックのみです。そこら辺のノウハウが溜まってきたので共有します。 そもそもなぜ機内持ち込みのみで頑張ってるのか? どのサイズのスーツケースを買うか悩みすぎている スーツケース無しでなんとかなってるし、今回も買わないでいいか、という結論に達してしまう 荷物待ち無しは気分が良い 荷物が少ないのも気分が良い 荷物 バッグ これです。35L。 特に不満は無い。PCも入るし。普段から使ってる。35Lが機内持ち込みの限界サイズだと思う。縦に長いと持ち込めないので気をつけて。 衣類 仕分けケースに入れる。それを圧縮袋で圧縮する。ZiplocでもOK。汚れた衣類はZiplocに入れて、圧縮する。そのために空のZiplocを数枚持っていく。仕分けケースは無印にいい感じの色のがある。Ziplocはフリー
変更されたファイルのみ実行 $ bundle exec rspec `git diff --name-only` インタラクティブに対象を選んで実行 peco便利。 $ bundle exec rspec `git ls-files | peco` そういえば、最近GuardやListenで自動実行しなくなってしまった。理由は特にない。 RSpecの変化が速すぎてついていけない。常にRubyを書いているわけではないので(JavaScriptが多くて常にRubyを書いているわけではないので、rspec-mocksも含めると気がつけばAPIが変わっていて、毎回ググっている。APIが安定しないライブラリは辛い。 そもそも、凝ったDSLを覚える事自体が辛い。特定のDSLの理解は再利用性が低いのが良くない。覚えても、そのライブラリ・フレームワークを使えるようになるだけという応用の効かなさが悲しい。逆
"Startup Java"と揶揄されるくらい定着したウェブアプリケーションフレームワーク、Ruby on Rails。情熱的なRubyコミュニティ、スタートアップ業界中心の圧倒的な需要が合わさって、巨大なエコシステムが形成されました。チュートリアルや入門書も充実して、すっかり始めやすいフレームワークになった感じです。 けど、プロダクション・クオリティのものを作るに当たって完成度を上げていくための情報って案外まとまってなかった印象があります。例外通知とか、CIの整備とか、プロビジョニングとか、モデルを整理する方法とか。『パーフェクト Ruby on Rails』はそこら辺がカチッとまとまってます。 ガチRailsエンジニアのいないスタートアップでコードの品質あげる、とか、ぴったりだと思う。 あと、RubyもWeb開発もある程度わかるんだけどRailsが巨大過ぎて手を出せてない人。Rails
デザイナーとかプログラマーという職業の特殊なところは、創作活動に近い面を含んでいる、ということだと思う。完全にその言葉が相応しいとは思わないけど、アーティストに近い面があるとも言える。実際、高い完成度や生産性を目指して、単なる仕事の枠を超えた情熱をもって手を動かし続けている人がけっこうな数いる。そして、それが往々にして本人や組織の強みの源になっていたりもする。 実際の事業の中では、クオリティと時間・人・予算の間のトレードオフが常に発生する。あくまで事業としては、製品の品質はそれ事業の中で果たす役割を全う出来る程度であれば良い。専門家として目指しているクオリティに達する必要がない場合もある。グリッドが多少狂ってても、やたらアドホックな実装が残ってても、必要な役割を果たせていれば十分なのである。 ここにジレンマがある。トレードオフだ何だと言ってクオリティに妥協し続けていると、そのうちクオリティ
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
便利便利と言われつつも使ってみないと良さがわからないのがDeferred Object。身近なところで言うと、$.ajaxが返す、doneとかfailとかを呼べるアレもDeferred Objectです。使いこなすと色々な処理をコールバックを渡すよりもうちょっと綺麗に書けるようになります。 ということで最近プロジェクトで使ったパターンを中心に例をあげてみます。 コードはすべてCoffeeScriptの擬似コードです。 まず最初に便利な書き方を覚える Deferred Objectは$.Deferred()で作るわけですが、これには「作られたDeferred Object自体を引数にとる関数」を引数として渡せます。これを利用すると d = $.Deferred() doSomethingWithCallback -> d.resolve() d を $.Deferred (d) -> doS
このページを最初にブックマークしてみませんか?
『fujimuradaisuke's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く