先日、絶対音感持ちだけど楽典には弱い（楽典に弱い、というのは本人談。ぼくがその人をみていてもそんなにめちゃめちゃ楽典弱いとも思わない。強いとも思わないけど）の友人が、調がB♭マイナーの楽曲のメロディーの中の、m3に当たる音を指して「ド♯」と言っていて、軽い違和感を持った。一般的にはB♭マイナーの楽曲を考えたら「シ♭-ド-レ♭-ミ♭-ファ-ソ♭-ラ♭-シ♭」というスケールを思い浮かべるので、B♭マイナーの楽曲の中で「レ♭あるいはド♯」で表される音が出てきたらそれは「レ♭」と呼ぶことが多いと思う。とはいえ、べつに「レ♭」でも「ド♯」でも、平均律の世界においてはその音高に1Hzの違いもなく、同じ音を指すので、違和感をもつくらいで、コミュニケーションに齟齬が起こることもないのでそれ自体に問題はないし、それが間違いだとは（ぼくは）思わない。 で、ちょっといろいろ考えていたんだけど、じゃあ自分がもし、

builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。 今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。 前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそも

世界とのチューニングを合わせることに苦労する、という感覚は、多かれ少なかれどんなひとでも持ってるのではないか、と思っている。 それはたとえば、飲み会でうまく立ち回るみたいな具体的なことから、なんとなくうまく世界に馴染めないみたいな曖昧なこともあるだろう。それは時には「どう働けばいいのかわからない」という形をとって現れたりもするだろう。そうすると大変だよね。 ぼくの知り合いで、めちゃめちゃ仕事ができるのに、「切手の値段がどう決まるかわからない」と言って封筒を出せずに毎回レターパックを使っているというひとがいる（というかさっきそういう話をツイッターでしてるのを見かけた）。「ググればいいじゃん」と思うことなかれ。おそらく彼にとって「郵便システム」という世界の一部とチューニングを合わせることは、ほかのひとには感じることの難しい困難さを伴うことなのだろうと思う。しかし彼は仕事ができる。それは、彼がほ

今月からClassi株式会社で働いています。まだ試用期間なのですが、所属を明かして良いと許可をもらったので入社エントリ書きます。 前職を退職しようと決意してから（ここにはかなりの葛藤があったのですがそれはまた別の話）、転職エージェントにお世話になりつつさまざまな会社を訪問させていただきました。 わたしが転職に際して重視したのは以下の三点でした。 家族が幸せにごはんを食べていけるための給与 自分のやっている仕事が世界を良くするであろうと自分が思えるかどうか 自分の得てきた能力が求められていて、なおかつ転職先できちんと成長できそうか 幸運かつ大変ありがたいことに、これらの条件を満たしてくれるような多くの会社からお声掛けをいただけたのですが、Classiに入社することを決めた決め手は以下の2点でした。 教育のセンターピンとも言える学校教育をビジネスドメインとしている 面談中にメンバーのことを好き

backlogというのは一般名詞のほうのbacklogではなく、ヌーラボさんのプロダクトのほうのbacklogです。 www.backlog.jp だいたい土日の2日間でできたのでよかった。 作ったやつどこにおいてあるか アプリ BackLogger-darwin-x64_v0.1.1.zip - Google ドライブ ソースコード github.com スクリーンショット タイトルの通り、Scala.jsとElectronで作られています。 なぜ Scala.js と Electron で作ったのか Scala.js がどれくらい実用的に使えるのかを知りたかった Electoron の得意なこと、苦手なことを触ってみて検証したかった というまっとうな理由と、 来年のScalaMatsuriに応募するためのネタがほしいな〜 「で？なんか偉そうに設計の話してるけど、お前はそれで何作ったの？

先週開催されたbuildersconで表題の通りの内容をしゃべってきました。発表内容については、スライドもアップしてますが、いつもどおり実況中継シリーズを会社ブログのほうに書きます。ただ、あれ書くのすごい大変なのでもうしばらく時間かかりますすみません。書きました。 自分のトークについて 弊社はまだまだメンバーが少なく、わたしもJavaScriptが専門、あるいは専任というわけではないという状況の中で、「なるべくJavaScriptに独特の概念などはプロダクトに持ち込まず、他のプラットフォームにも通用するような考え方ややり方で保守性の高いコードを書く」ということを考えて設計/実装をしています。 その試行錯誤の結果得てきた知見を対外的に発表することで、みなさんに「JavaScriptに限らず有用なトークだった」と言っていただけたのは本当に嬉しいです。 ただ、逆に考えると「JavaScript全

新潟県長岡市で開催された、NDSの第52回で、「怖くないし役に立つ設計原則の話」というタイトルで発表してきました。 内容としては、 設計原則は「馬鹿の一つ覚え」でやっていくとむしろ保守性を下げてしまうことを確認する 様々な設計原則について例を出しながら、別の設計原則との有機的なつながりを考る 有機的なつながりを意識しながら設計原則を利用することで、保守性の高い設計を導く というような内容でした。少し誤解を生む表現などが入っているため資料は公開しませんが、機会があればどこかで再演したいなと思っています。お誘いください。 聞いた発表では、 @yuw27b さんの「今日から使えるCSSパターン」が最も興味深かったです。 保守性の高いCSSを書くのがものすごく難しいなか、どうやってCSSの難しさに立ち向かっていくかという話でしたが、BEMに触れつつ「DRYさを諦めてでも結合度を下げたほうがよい」と

Scala 一年生のわたしですが、僭越ながら「みんなで Scala に入門しようぜ！」というハンズオン形式のセミナーの講師を行ってきました。「Scala 入学式」という名前は papix 氏がやってる「Perl 入学式」のパクりです！ この勉強会に使った資料は以下にアップしておきます。 https://gist.github.com/Shinpeim/6740436 一部マークダウン壊れてるけど勘弁してもう燃え尽きた。 東京から jewelve 氏と moznion 氏が参戦してくれたりと、LTもえらい面白かったです。講師役がなんかいろいろ書くのもアレなんで、参加者のみなさんのブログを見ていただければなと思います！（参加者のひとはぜひブログ書いて！見つけ次第リンクしていきます） civic site - NDS第33回NDSに参加してきました！ ナカザンドットネット - Scala入学式

新潟県長岡市では定期的に「NDS」という勉強会が開催されています。わたしも新潟に住んでいるときには非常にお世話になった勉強会で、とても良い勉強会です。 その第52回（52回ですよ！？すごくないですか！？）が6/17に開催されるとのことなので、「怖くないし役に立つ設計原則の話」というタイトルで発表させていただくことにしました。 nagaoka.techtalk.jp まだ内容固まっていないのですが、このトークでは、 デザインパターンとか知識としては知ってるんだけどなぜそれが有効なのかよくわからん 「結局設計パターンとかって役に立たないし勘でやるものでしょ」 MVCとかMVVMとかMVPとか「わざわざ難しくしてる」としか思えない！！！ DRY原則なら知ってる といった感じのひと（2010年くらいの俺だ……）を想定して、 われわれは（主語が大きい）なぜ設計パターンを役立たせることができないのか

前回の記事では、Scala.jsをどのように利用したかについて概観を見てきました。 前回、UI層は素直にVue.jsの単一ファイルコンポーネントで書いて、モデル層はScala.jsで書く、というスタイルを取る、と述べましたが、今回はモデル層がどのようなインターフェイスをUI層に公開して、UI層がどのようにそれらを利用する設計としたのかについて見ていきます。 モデル層の公開するみっつの種類のクラス/オブジェクト モデル層は、UI層に対して、「コマンド」「クエリ」「イベント」のみっつの種類のクラス/オブジェクトを公開します。まずは「コマンド」から見ていきましょう。 コマンドの責務 コマンドは、アプリケーションの状態を更新するような操作（たとえばTodoを追加する、Todoをdone状態にする、など）の窓口を提供します。 なにかを更新するような操作を行う場合、UI層は、 コマンドをインスタンス化

最近はずっとJSでGUIを書くっていうお仕事をやっていて、その中で様々な知見が溜まってきてます。 そのときにひしひしと感じたんだけど、世の中にはさまざまなアプリケーション・アーキテクチャの話が溢れかえっていて、結構混乱を産んでいるように思います。 MVVMだけ見ても、「MVVMで実装しています」って主張しているものがMVVMパターンと違うパターンで実装されていたり、「軽量MVVM」なんて言葉が生まれていたりという状況があって、これはだいぶ混乱が極まっているぞ、と感じる状況です。 また「最近はClean Architectureが熱いらしい！MVVMを捨ててやってみよう！」とか言う発言を目にしたりして、「Clean ArchitectureとMVVMは矛盾しないからMVVMを捨てる必要はないんだよ！」って思ったりもするわけです。 そういう混乱の中にあるひと（それは知見を貯めるまえの自分のこと

最近立て続けにそのあたりの話をする機会があったので。わたしの意見です。 vuexというかFluxに手を出すタイミング Vue.jsを利用していて、相互に関連のある二つ以上の状態を扱う必要が出てきたら、それはもうすでに「十分に複雑な状態管理」である たとえば、APIとの通信中はインジケータを出したいので「通信中かどうか」を管理し、通信が終わったらその結果を表示するために「通信結果」も管理したい、など。 十分に複雑な状態管理に立ち向かうためには、自分でピュアなDomain側をきちんと作ってそこで状態管理するか、vuex利用するべきだと思う 自分で設計からやるにしても、まっとうにMVVMをやれば単方向データフローは守れるので、Fluxの考え方とMVVMは矛盾しない see http://techblog.reraku.co.jp/entry/2016/12/13/080000 vuexを触ってみ

ぼくは最近、大人になるというのは取りも直さず、自らを物語るということなんじゃないか、と思うことがある。 ぼくたちは、自己だとか内面だとかいったものが先にあって、そいつらがぼくたちの選択や人生を駆動している、とついつい思いがちだ。けど、自己だとか内面だとかなんてほんとうは存在しなくて、それは「物語られる」ことによって遡及的に見出させれるようなものなんじゃないかな、ってぼくは思うことがある。 ぼくたちの精神や自己というものは、なんとなく一本筋の通った物語として理解される形で総合されたものとして普段は認識されている。たとえばぼく自身について語るなら、「文学部で哲学を学んでいたんだけど、御多分に漏れず哲学で就職できるわけもなく、趣味で書いてたプログラムでひとまず仕事を始めてみたら、これが趣味でやってたときよりもずっと奥が深くておもしろくてどハマりした。コミュニティ活動とかしていく中で、技術雑誌の記

弊社のwebAPIはRESTを捨てて操作指向のURLにすることが多いんだけれど、ここのところwebAPIだと結構そういう判断するところが増えてるように感じる（個人の感想です）。 SoEとSoRという話があったけれど、webブラウザ上でもスマートフォン上でもリッチなユーザ体験がモノを言うようになり、SoEなサービスが増えてきていることと操作指向のURLが増えていることは実は無関係ではないのではないか。 というのも、SoRの場合その性質上リソースに対する意識が高まるのに対して、SoEの場合はどちらかと言うとユーザ体験みたいなところに意識が高まる。で、ユーザがサービスを捉えるときのメンタルモデルって、「リソースの操作」とあまり一致しなかったりすると思うんですよ。そうすると、どうしてもリソース指向のURLでやっていくのに無理が出てきて、「じゃあいっそユースケース指向というか操作指向のURLでAPI

以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「

表題にあるとおり、Software Design8月号の特集記事を書かせていただきました。GitHub入門的な記事です。 今書店で売ってる号は7月号ですので、今売ってるやつには載ってません（でももちろん買ってくださってもいいんですよ？）。発売日は7/18ですので、その後書店で購入したり、Amazonなどでお求めください。 www.amazon.co.jp 今年に入ってから、web+DB Pressの91,92号、SD8月号と、技術評論社さんの雑誌に記事を書かせていただく機会を立て続けにいただけて、ほんとうにありがたい限りです。 ところで、web+DB vol. 91の記事はYAPC::Asiaでの発表がきっかけでチャンスをいただいたのでした。92はPerlコミュニティつながりで頂いたお話でした。今回の記事に関しては、「Gitをはじめからていねいに」というドキュメントをGitHub上で公開し

なんだか久しぶりの投稿です。前の記事を投稿してからしばらくかなり忙しい日々が続いており、仕事の進捗は出ているのですがブログの進捗がお亡くなりになっていました。逆よりいいと思うことにします。 ところで、「かなり忙しい日々」の中に実は「雑誌への記事の執筆」というものが入っておりました。先に結論をいうと、WEB+DB PRESS Vol.91に「［すぐに使えてずっと役立つ！］データ構造の基礎知識 ── 配列、リスト、ハッシュテーブル、木構造」という特集記事を書かせていただきました。なんと！特集記事です。まじかよ。 www.amazon.co.jp 記事の内容について WEB+DB PRESSは、プログラマとして働き始めてからほとんど毎号購入して読んでいる雑誌で、そのような雑誌の特集を執筆させていただけたことは本当にありがたいことだと感じていますし、とても嬉しく思っています。内容としてはデータ構造

＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり

わたしの立ち位置 今は東京都でプログラマをやっているが、3,4年くらい新潟県でプログラマをやっていて、当時は地元のコミュニティによく顔を出していた、という人間です 以下本文 少なくともわたしが知っている限りの話です。新潟県には優秀なプログラマが一定数います。そして、最近はコミュニティがそういうプログラマにリーチしつつあって、交流は活発になっていると感じます。でも、参加者がレポートとかを対外的に書いたりはあまりしてないように思えます。これはとてももったいないことです。優秀なプログラマを喉から手が出るくらいほしがってる「都会」の企業が、「なんかあの地域めっちゃプログラマたちの活動活発だな、開発拠点作る意味あるかも」って思ってくれるくらいまで、「俺たちプログラマとして楽しいことやってるぜ！」ってのをアピールしていったらいいのにな、と思うんですよ。 これは多分新潟に限らないのではないかと思うんでけ

仕事の都合で東京のはずれに引っ越しました。 新潟にいる間は、新潟のプログラマがとても仲良くしてくれて、おかげでプログラマとしてめちゃめちゃ楽しく生活することができました。なかでも @hayajo さん、@civicさん、@dictavさんには格別にお世話になりました。ズッ友だょ！！ 東京のプログラマのみなさん、今後ともよろしくおねがいします。 wishlistはこちらです。 www.amazon.co.jp