news.livedoor.com 先に ban しておいて、後から規約を変えて「規約違反」が理由だという。後出しジャンケンにも程がある。これでは規約の「変更・改訂」ではなく「改竄」じゃないか。 サードパーティー製のアプリが締め出された理由は Twitter 社が広告で稼げないから、という説が濃厚らしく、だったらそんな無礼な会社にカネを落とすのはまっぴらだと思って、公式アプリをアンインストールし、Web でも見ないことにした。 とはいえ Web で見ないのを自制心に頼るのは心許ない、というか無理なのでコンテンツブロッカーとかでできないかと思って、iPhone Safari での広告ブロックには 280blocker を使ってるのでこれでいけるかと思ったけどダメで、他にないかと調べたらすぐ出てきた。 www.feeloneslife.com AdGuard という広告ブロッカーだとカスタムル

一意のタイトルはつけたくないし、ハッシュタグをつけるのもいや、という気持ち｜佐々木大輔｜note ブログを語れるほど詳しくはないけど。 ブログが登場したとき個人ウェブサイトとかウェブ日記と比べて画期的だと評価されていたのは、トラックバックによって他のブログと繋がれたり、RSSフィードを配信することによって広く情報発信できることだったと記憶している。つまり、ブログはそれまでに存在した「個人のためのインターネット」と比べて「（他者に対して）開かれている」ところに特長があった。 それが今やどうだ。ブログは開かれているどころか、積極的に引きこもるための場所になってしまった感すらある。RSSリーダーは衰退し、人々はRSSフィードを購読するのではなくSNSのタイムラインを眺めることによって情報を得るようになった。誰かがSNSにシェアしない限り、ブログに書いたことは（一部の物好きな人々以外には）基本的に

仕事のあと夜に勉強する意欲が減退している。疲れが溜まってるのか、興味の対象もやたらと定まらなくてウロウロと何をやろうか選ぶふりをしてるだけで時間を浪費してしまったり、選び疲れてしまったり。これも生活リズムが崩れてるということか。無気力なわけではなくて、何かやりたい気持ちはあるけれど空回りするというか、実際に何かを行うエネルギーまでは無いというか。

なぜ嫌いなのかわかった気がする。 「振り返りって、要は内省でしょ？そんなの言われなくても、他人からわざわざ指摘されなくても、もう何十年も毎日毎日、本当に毎日、スキマ時間があるたびにやってるよ、やりたくもないのに無意識に。十数年分のブログが証拠だ。俺がそれだけ時間をかけてやってる内省よりも効果的な「フィードバック」とやらを、たかだか数日、数週間、数ヶ月仕事をしたくらいの赤の他人ができるとでも思っているのか？思い上がりも甚だしい」 って思ってるからだろうな。 「フィードバック」には、確かに自覚してないことも含まれるのだろう、けど、それは自分にとって重要なことではないから内省して改善してないってことじゃないの？それをわざわざ大事なことだと指摘されても腹立つだけじゃん。だって大事じゃないんだもの。自分にとって何が大事かを他人が決めるんじゃねーよ。

開発プロセスを整備していくことは、究極的には「製造」の安定化を目指していくことである。思想的に 変化や不確定な未来に対して柔軟に対応するためには、まず開発者自身が変化や未来に適応できる柔軟さを、精神的にも実際の動き方としても備えていなければならないはず しかし安定した製造による精度の高い計画が変化や未来に脅かされないように、不確定要素を吸収することを、仕組みで解決しようとすると、開発プロセスを厳密化していきましょうということになり、どんどん重厚で複雑な手続きとなっていく プロセスが過度に洗練されることで、人間が都度状況判断していく必要が減り、また推奨もされなくなるので、やらなくなり、できなくなり、応用力の衰えを補うためにさらにプロセスの洗練で解決しようとする、という悪循環がうまれる（かつてこれと似たような事象に「お願いします脳の恐怖」と名付けた） 自分たちが仕事をしやすくするために始めたプ

立場上、否定的な意見を言いづらいけど、 devblog.thebase.in コードを書かないとエンジニアとして死ぬ 昔も今も変わらず、これが真だと思う。エンジニアのマネージャーという存在は矛盾していて、解決することはできない。「組織をエンジニアリングする」とか、そういうのは、詭弁とまでは言わないけど、ポジショントークだと思う。

ギラン・バレー症候群という病気になり、2018年の10/1から11/3まで入院した。 異変に気づいたのは9/30の早朝だった。両脚に力が入らない。膝がガクガクして、立ってまっすぐ歩くのもおぼつかない。仕事のストレスで頭痛が続いていたので、脳の血管が切れたかと思ってぐぐってみたが、その場合は半身（右手右脚とか）に症状が出るらしく、両手ともに無事だったのでひとまず命に関わることはなかろうと判断してその日は一日寝て過ごした。ちなみにぐぐったときにギラン・バレー症候群の名前も出ていたのだが、まさかそんな変な名前の病気であるとは思わず、気にもとめなかった。なおこの日は世界選手権自転車競技大会ロードレースでアレハンドロ・バルベルデが優勝した日で、布団から這い出てゴールシーンだけ観た。 翌日10/1になると症状がおさまるどころか両腕も力が入らなくなった。肘がガクガクして、まるで自分の身体が操り人形になっ

blog.kyanny.me 使い物にならない、とは言わないが、おすすめしない。 遅い もっぱら毎日 GitHub や Google Drive にアクセスしているが、どこも Chrome に比べて体感で明らかにわかるほど表示も動作も遅い 速度がウリって、いったいどこのウェブサイトなら速いわけ？ 一番困ったのが Cmd+W に対する反応が遅くて（処理落ちしてる感じ）気持ち長く押してしまうのか、閉じたくないタブまで閉じる操作ミスが頻発した 開発者ツールが使いづらい 慣れの問題もあるけど、機能の少なさはこなれてなさは否めない minify された .js ファイルを prettify してブレークポイントを設定しても、そこで止まってくれない。デバッグが致命的にやりづらい 拡張がめっちゃ少ない Quantum で過去の拡張を捨て去ったので、拡張を探しても軒並み未対応 Trello の公式拡張が未

同僚の勧めで昨年暮れから読んだ。これぞ外資系、という感じだった。もしアップルに入社できたとしても、やっていけないだろうな。こんな風にドライで厳しい環境なら張り詰めた冬の空気のような気持ちで毎日仕事ができそうだけど、自分もすぐに脱落しそうだ。 「引用ベストスリー方式」にしたがって、三ヶ所だけ引用する。 ハードウェアと同様、デザインはそこにある問題を解決しなければなりません。今まではお客様が何ステップも踏んで行っていたことやマニュアルと首っ引きでやっていたことを、ワン・クリックで自動化できるようにするなど、顧客の問題を具体的に解決していく。それが優れたデザインです。 デザインとは、見た目だけを指すものではない。問題を解決しているか？を問う姿勢を忘れない。 デザインやコンセプトを重視せずに行う製品開発は、構造的にコストが膨らみやすいアプローチです。 その通りだと思う。何度も体験済み。 私が採用時

ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。 おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。 そのシステムが実現するビジネスにおける仕様について（仕様書なのに）触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不

Moving On Parse 使って商用サービスやってるところどのくらいあるんだろう（そして流行ってる・儲かってるところは） MBaaS のサービス終了は利用者にとって非常に難しい状況だと思う。こういうときの退避先が無いからだ。 しかし Parse が偉いのは、データのマイグレーションツールだけでなく、 Parse API 互換のサーバ実装をオープンソースにして公開したことだ。 Introducing Parse Server and the Database Migration Tool データのエクスポートだけなら最低どこでもやるが、 Parse のようなサービスの場合、データだけもらってもユーザーはどうしようもない（クライアント＝ユーザーのサービスそのものを動かし続けるためには自分で API を書かなくてはならない）そこもちゃんと後始末する姿勢はとてもよいと思う（まぁ過去にもそうい

知人の Common Lisp ハッカーから数年ぶりにチャットで近況報告を受ける。結婚し一児のパパになっていて驚く（浮世離れした印象を抱いていたので）。さらにお相手がなんと女優の天海祐希で二度驚く。

「エンジニア組織のトップには最も技術力が高い人が立つべき」という価値観にもとづいて、多くのWeb事業会社においてエース格のスターエンジニアがCTOないし類似の肩書と地位と権力を持つポジションに就いたゼロ年代のムーブメントを第一次CTOブームと呼ぶことにしよう それを踏まえてテン年代に入り、「スタートアップのような小さな組織ではそれで問題なかったけど、組織が大きくなり成熟していく過程では、経営者の視点からエンジニア組織をマネジメントできる人がいないと組織力を発揮しきれないのでダメだよね」という価値観を後ろ盾に、そこそこ年齢を重ねて気力体力的に現場の第一線がつらくなったりライフステージの変化によって以前に比べパフォーマンスを発揮できなくなった元エースや、技能ではエースに及ばないがそれ以外の格（社歴など）で勝るシニアな人材などの思惑が重なり、「次のキャリア」としてCTOという役職に再びスポットが

Quipper 日本オフィス（+ 海外オフィス勤務の日本人）で「チャット以上 Wiki 未満」な情報共有ツールとして二年ほど使ってきた Qiita::Team をやめて、 GitHub Issues に移行した。 Qiita::Team は日本人の間では活用されていたが、グローバル企業なので英語以外のみでの情報共有は好ましくなく、しかも Qiita::Team は個別に invite しないとアクセスできないので海外拠点のスタッフにとっては非常に閉鎖的な場だった。せめてアクセス可能にしようと plan をアップグレードし invite したものの、国際化対応が不十分だったりそもそも日本語の文章を翻訳して読もうというガッツもなかったりして、日本人以外には活用されなかった。 Quipper は外部サービスの導入にポジティブだが、使われていないものはスパッとやめるポリシーがあり、幽霊会員と化して

Scaling Wix to 60M Users - From Monolith to Microservices | StackShareいろいろスケールがでかくてびびる。 400人の開発者は？40人では？と思ったが Java だとそういうもんなのかもしれない。てっきり PHP とかで作ってるものかと思ってたから意外だったMonolith だったアプリをユーザーの作ったサイトを配信する機能とそれ以外の二つに分割するのに4,5年を要したは？4,5ヶ月では？と思ったが Java だと（ryいまは100を超える microservices から成り立つ。ほとんどは Scala で書かれているは？10の間違いでは？と（ryMicroservices はそれぞれ自分自身のみが書き込む専用のデータベースを持つは？てことは100のマイクロサービスと100のデータベースがあるの？正気か？と戦慄を覚えたG

最近「Mixin は避けられれば避けたほうがよいのではないか」と思い始めている。扱いに困るダメ実装の Mixin を簡単に作れすぎてしまうからだ。 Wikipedia の定義によると、 mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。 とのことなので、そもそも Mixin される側の実装と結びつきが強くなるのは仕方ないのだろう。しかし、まれにだが破れ紙の片割れのような実装を持つ Mixin ができてしまうことがある。 一枚の紙を適当に手で破って二枚にする。断面はギザギザだが、破った二枚の紙の断面はぴったり一致する。もともと繋がっていたものを切り離したのだから当然だ。だが破れ紙の断面にぴったり合うような別の紙を用意するのは簡単ではない。別の紙を合わせる必要があるのならば、紙を破るときに

React は昨年末ごろ仕事で少し使ったことがあるが、全貌を知らないままヘルプでちょっと書いた程度だったので、ちゃんと体系的に学びたいと思っていた。ウェブのチュートリアルやドキュメントも読んだが英語なこともありよくわからなかったので日本語訳された本を買った。 付録を含めても 250 ページほどの薄い本だが、内容はコンパクトながら充実している。必要なことが的確に説明されていると感じた。文章の構成もよくて、読み進めるにつれて深く知りたいと思うことが期待通りに次の節で掘り下げられていたりして、あちこち説明が飛ぶこともなくストレスを感じない。 ゼロから手取り足取り教えるタイプの本ではないので全くの初心者だとこの本だけではとっつきづらいかもしれない。自発的に React に関心を持つような人なら Starter Kit をダウンロードして Hello World アプリケーションを表示するくらいまで

自分にできる範囲の努力では「注目されない凡人」から脱却することはできないのだ、ということをようやく渋々認める気になり数ヶ月経ったが、ではこの先自分はどういう風になっていくのか？を考えたとき、ロールモデルと呼べるような存在が見つからず少し困っている。 「カッティングエッジなことをやっていて際立つ存在」を目指したいと思っていたときは前例に事欠かなかったが、平凡だがすごいと思える存在、というのは想像することすらちょっと難しい。自分のいままでの価値観では、すごいと思える部分があったらすでに平凡ではないからだ。 いまさら「スクラムおじさん」みたいな方向性に行くのも気が進まない。そういうことが好きでやりたいと思っているわけではないのに、技能だけで勝負できなくなったから長年の経験みたいなものを活かせるロールに立場を変える、というのは天下りみたいで格好悪く感じ、少なくとも自分はそうなりたくはない。 当面

初心者プログラマーのジレンマがわかった！プログラムに「変数」とか「引数」とかの「日本語」いらないし！ プログラミング歴30年にもかかわらず未だ初心者と豪語しておきながら、「初心者プログラマーのジレンマがやっとわかった」というのはなんかへんなきがする。もっとはやく気づくはずでは。 https://plus.google.com/u/1/+JunMukai/posts/KTp3PLzJf7n?cfem=1 こちらの議論のほうが本題より面白かった。 自分は日本語に訳されていたほうが良いと思う。 初心者にとってはプログラムのコードそのものが英語みたいなもので非常にとっつきづらく、恐ろしく見えるものだ。パソコンに慣れていない一般人にとっては Windows のエラーメッセージダイアログですら怖い。そしてほとんどの人が最初はそういうところからスタートする。 もし初心者がプログラムの入門書を読んで、日本

昨年末から SNS を見るのをやめた。目的は精神の平穏を保つため。誰が退職しただの、誰が本を書いただの、誰と誰が寿司を食っただの、そういう業界ゴシップで心惑わされるのに疲れ果てた。知る価値のある情報もたくさんあるが、 S/N 比が悪くなりすぎた。 また、 SNS に愚痴や攻撃的なことを書いたりしてしまうのもやめたかった。傍目に悪いし、書いてスカッとするわけでもない。いつか炎上するかもと内心びくびくしながらやめられない様はまさに中毒だった。 具体的にやったことは以下。 iPhone から Twitter と Facebook その他 SNS のアプリを削除した。隙間時間についつい見てしまう・書いてしまうのはこれで克服できた。 SNS からの通知メールをできるだけオフにした。特に効き目があったのははてなブックマークのマイホットエントリーお知らせメールで、自分にとって最大のゴシップ情報源になって