近況 あまりに天気が良くて鴨川に行ってみた。 自転車だと意外と近くて15分くらい。道は御池通を選んだ。広いので走りやすい。京都は観光客・自動車がそこらじゅうにいるのでルート選択が大事なのだ。 『うつ病九段』に、「メンタルをやった人は自然に触れることで回復するのだ」と書かれていた。鴨川はまさにそういう場所だと思う。 人はまばらで川は鳥だらけ。人間より鴨が多いことすらあるだろう。 ただぼーっと眺めるだけで癒される場所なので、次は原稿を終えた（はずの）妻氏を連れてくる予定だ。 冷えがつらい季節が終わりつつある。これからは疲れと胃腸の調子が課題である。万能の対策は散歩と睡眠だが、特に胃腸が弱っていたら足三里にお灸をせよ、と鍼の先生に言われた。千利休も使っていたツボである。 鍼の先生は爪楊枝とタオルさえあれば仕事ができるらしい。だから大地震が起きても営業するから、予約どおり来てくれ、と言われた。すご

なぜなのか。それは、哲学が役に立つから。ちょっとわけがわからないと思うので、順を追って説明します。 ソフトウェアエンジニアは何をしているのでしょうか。まずはこの問いからです。ソフトウェアエンジニアは、計算機科学、つまりソフトウェアの設計と実装そして運用の技術で仕事をします。主な用途は自動化されスケールするシステムの構築です。ではこのシステム、ソフトウェアエンジニアがつくるシステムは何のためのものなのか。たいていは実社会の問題を解決するために作られます。会計システムであれば、会計の効率化、自動で計算や仕分けをしてくれたり、ですよね。ソフトウェアエンジニアは実社会の問題をソフトウェアによる自動化の力を借りて解決します。ここまでは簡単ですね。 それでは、彼らは何を作っているのかみていきましょう。実社会の問題を解決するシステムとは何なのか。これは具体化するときりがないものですが、いくつかの特徴があ

昨日の🍺のあとに考えていた雑感。フロントエンドから見たGUIの状態を個人の主観をもとに整理しています。 背景 複雑なJavaScriptアプリケーションを考えながら作る話 と id:Pasta-K がReact + Canvasで色々やっていた話 などなど。 Reactなどの現代フロントエンドはたいへんしんどいGUIであるという前提もあります。 GUIの状態の種類 人間 諸悪の根源。 だいたいこいつが状態を変更してくる。バリデーションが必要なのもこいつのせい。 わかりやすいUIを提供しないと人間が弱る。 View Viewの中の状態。UI上の選択状態とか。 Viewに状態を持ちたくない宗派としては、できれば非永続化層（メインのビジネスロジックと状態を持った層）か永続化層（DB）にすべての状態を持っていて欲しいが、パフォーマンス上の問題でthis.stateに状態を持つことはありえる。Re

はじめに ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。 Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。 react, redux 複雑なGUIを作るためのフレームワークも乱立の時代

nippo.wikihub.io r7kamura Commented on 2016-09-01 何も考えずにReact, Redux使うような気はするのだけど、Reduxを使わない場合は各位どうやってState管理してるんでしょうか？ 親コンポーネントがstateとメンバ関数を持っており、子コンポーネントはpropsかcontext経由でその値を参照しながら描画とイベントバインディングを行っています。 日報で疑問を書いたら、id:r7kamuraさんが答えてくれた。 immutable.Recordに状態とロジック押し込んでそいつをContainer Componentのthis.stateに入れておく設計とか。 — 下京区 (@non_117) 2016年9月1日 facebookが想定してるのはこの用途かな。 DOMサブツリー間で状態の共有が発生するか、設計段階で予見するの難しそう

なぜReactなのか React, Cyclejs, Reduxを学んだ上でこれらの技術が何を解決したのかまとめてみる。発想はオリジナルではなく、今まで私が読んだ記事から拝借した解釈などが含まれている。たぶんReact, Fluxを学んだ人にとっては当たり前の感覚を言語化しているだけの内容となる。 TL;DR Q: なぜReactなのか A: フロントエンドが自由度の高いGUIアプリケーションになった。既存の手法では自由度の高いGUI実装を人間にわかりやすく管理することが難しくなった。 自由度の高いGUIな世界 自由度(複雑さ)の低い時代ではrender済みのDOMの上にDOMを操作する(jQueryによる)UIを載せる設計でも十分だった 現代のwebフロントエンドではVisual StudioやXcodeで作るネイティブGUIと同等の複雑さを求められる時代になっている jQueryだけで

ある日のこと、後輩たちがこんなことを言いました。 「ゆゆ式のコマをランダムに並びかえたら無限にゆゆ式が楽しめるのでは？」 真面目に計算してみると、10の15乗くらいの組み合わせができることがわかりました。 この記事ゆゆ式アドベントカレンダー20日目は、そんな無限にゆゆ式をたのしむためのシステムを真面目に作ってみた話をします。 コマの切り出し 漫画のコマを並び替えるためには、コマがバラバラな画像として存在していなければなりません。 なので、まずは自炊で電子化された書籍をコマの線にそって切り出していく処理を自動化することにしました。 上の図がふつうの4コマの1ページですね。これの枠線を識別して、1ページから8枚のコマを取り出してくる方法を考えます。 ハフ変換で直線検出 OpenCVという画像処理のライブラリに直線を検出するツールがあったので、まずこれを試してみました。 が、結果はこのとおり。