エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
モンキーパッチよりも古式ゆかしいpatchのほうが良いシーンがあるという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
労働の現場においては、gemにオレオレパッチを当てたい、ということがまれにあります（あ、いい忘れてましたがこれからRubyの話をします）。もちろん、オレオレパッチは基本的には避けるべきものですが、そうも言っていられない深遠なる事情というのが、労働においてはある……。労働にはいろいろあります……。 さて、オレオレパッチの是非については一旦おいておいて、gemにオレオレパッチを当てたいとき、オープンクラスを利用してモンキーパッチを当てることが一般的には多いのではないでしょうか（繰り返しになりますがここではオレオレパッチの是非は問いません）。Railsを利用している場合、config/initializers以下にモンキーパッチのためのファイルを入れて、Rails起動時にgemの挙動を拡張、あるいは変更する、というような手段が多くの場合取られるのではないかと思います。 しかし、Railsを利用し
ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない？って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか？」という話をします。 結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。 まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。 その上でReduxの特殊性は Stateがピュアなオブジェクトで表されている Stateの更新はイベントを契機に常に同期的に行われる 以上2点により いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Vue.jsによるUI層とScala.jsによるモデル層のコミュニケーション - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事では、Scala.jsをどのように利用したかについて概観を見てきました。 前回、UI層は素直にVue.jsの単一ファイルコンポーネントで書いて、モデル層はScala.jsで書く、というスタイルを取る、と述べましたが、今回はモデル層がどのようなインターフェイスをUI層に公開して、UI層がどのようにそれらを利用する設計としたのかについて見ていきます。 モデル層の公開するみっつの種類のクラス/オブジェクト モデル層は、UI層に対して、「コマンド」「クエリ」「イベント」のみっつの種類のクラス/オブジェクトを公開します。まずは「コマンド」から見ていきましょう。 コマンドの責務 コマンドは、アプリケーションの状態を更新するような操作（たとえばTodoを追加する、Todoをdone状態にする、など）の窓口を提供します。 なにかを更新するような操作を行う場合、UI層は、 コマンドをインスタンス化
VuexとPDS、immutable modelの所感 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
Twitterに書いた内容再掲。 最近Vuexについて考えてるのは、Vuex使ってPDS実現するとなると、状態はVuexのレイヤーで持つことになるから、モデル層はステートレスで作るのが相性良い（というか自然とそうなる）だろうな その時にJSでイミュータブルに寄せて行く辛さがどれくらいキツいものなのかの知見が自分にはない ある程度以上に複雑なアプリケーションでは、サーバーサイドからpushされる情報のためにコネクション握りっぱなしにする部分とかも出てくるであろうと思っていて、モデル層以下をイミュータブルに寄せて行った時にそういうのをどうハンドルすれば良いかも自分に知見がない Vuex少し触ったところとても筋が良いと感じるんだけど、そのあたりみんなどうしているのか知りたいなあ まあある程度の複雑さまでなら「Vuexの層に全部書く」でよいからそれでええやん、というのはありそう イミュータブルモデ
Vue.jsとvuex、Fluxについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
最近立て続けにそのあたりの話をする機会があったので。わたしの意見です。 vuexというかFluxに手を出すタイミング Vue.jsを利用していて、相互に関連のある二つ以上の状態を扱う必要が出てきたら、それはもうすでに「十分に複雑な状態管理」である たとえば、APIとの通信中はインジケータを出したいので「通信中かどうか」を管理し、通信が終わったらその結果を表示するために「通信結果」も管理したい、など。 十分に複雑な状態管理に立ち向かうためには、自分でピュアなDomain側をきちんと作ってそこで状態管理するか、vuex利用するべきだと思う 自分で設計からやるにしても、まっとうにMVVMをやれば単方向データフローは守れるので、Fluxの考え方とMVVMは矛盾しない see http://techblog.reraku.co.jp/entry/2016/12/13/080000 vuexを触ってみ
リソース指向と操作指向のURLに関する最近の思い - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
弊社のwebAPIはRESTを捨てて操作指向のURLにすることが多いんだけれど、ここのところwebAPIだと結構そういう判断するところが増えてるように感じる（個人の感想です）。 SoEとSoRという話があったけれど、webブラウザ上でもスマートフォン上でもリッチなユーザ体験がモノを言うようになり、SoEなサービスが増えてきていることと操作指向のURLが増えていることは実は無関係ではないのではないか。 というのも、SoRの場合その性質上リソースに対する意識が高まるのに対して、SoEの場合はどちらかと言うとユーザ体験みたいなところに意識が高まる。で、ユーザがサービスを捉えるときのメンタルモデルって、「リソースの操作」とあまり一致しなかったりすると思うんですよ。そうすると、どうしてもリソース指向のURLでやっていくのに無理が出てきて、「じゃあいっそユースケース指向というか操作指向のURLでAPI
プログラマとコミュニティ あるいは SD8月号に記事を書かせてもらいました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
表題にあるとおり、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上で公開し
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
Perlの黒魔術を解説するよ〜〜〜〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
まずはこちらをごらんください。 shinh.hatenablog.com すごすぎる……。恐ろしいですね。 なぜこんなことになるのか、解説していきましょう。まずはPerlの気持ちになりましょう。 Perlの気持ち編 ポイントその1 barewordを数値コンテキストで評価するとどうなるのかということ 件のプログラムは、base64 っぽい文字列が書かれていますが、これを前からPerlコードとして読んでいくと、大きく2つのパートに分かれることに気づきます。というのも、前から一文字ずつ読んでいくと、「+」という演算子にぶつかるわけですね。 それに気づくと、このコードは前半部分 dXNlIE1JTUU6OkJhc2U2NDtwcmludCBlbmNvZGVfYmFzZTY0IGpvaW4nJyw8PjsKX19FTkRfXwo と、 s//v62/e+s//v60/e+s//v44/e+s//v
テンプレートをDRYにするのは慎重にやったほうがいいですよねというお話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
社内でレビューおじさん業してて書いた内容ですけど守秘する必要ない情報なんでちょっと内容書き換えてオープンアンドシェアーします。 本文 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品（些細な変更されることが多い部品）なので、「同じような部品だから共通化しちゃおう」ってやると失敗することが多いです。 特に気をつけるべきなのは、たとえばコンテンツをランキング形式でテーブルで表示する画面と、新着から順にテーブルで表示する画面があって、このふたつのテーブル部分は一緒だからパーシャルにしちゃおう、みたいなやつです。 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品、というのがここで効いてきて、「新着とランキングは基本的に同じ表示なんですけど、ランキングのほうではランクがアップしたかダウンしたかのアイコンを表示してほしいんですよね〜」とか言われたり、「今見てるページ
で、結局型クラスって何がうれしいの、ということの説明 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事では、Scala では implicit parameter を利用することで型クラスと同等のことが実現できることがわかりました。しかし前回の疑問として、「で、それの何がうれしいのよ」というのは残っていましたね。 今回はそのうれしみをなるべくわかりやすく説明したいと思います。 たとえば、色んなクラスに flipFlap メソッドを生やしたい まず、前回と同じく「値をひっくり返す」という flipFlap について考えてみましょう。 前回は関数を作りましたが、Scalaらしく、こういう動きにしたいですね 1.flipFlap // => -1 true.flipFlap // => false "string".flipFlap // => gnirts Scala ではクラスを拡張するときには implicit conversion を使うのが一般的ですね。 class IntF
読み取り権限がなく実行権限だけのファイルが実行できるのはなぜ？ - カーネルのソースを読む - - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
きっかけはこのツイート。 基礎的なことなんだろうけど理解できてないこと。 読み取り権限のない実行権限だけのファイルってどういう扱いになるんだろう。— ゑぬぽい改@電探が出（ん）たん？ (@NPoi) March 27, 2014 実際にやってみるとわかるけど、実行権限だけついてるファイルは実行可能です。でも、「読み込めないのに実行できる」というのは直感に反するような気もしますね。だって、実行するためにはプログラムをメモリに読み込む必要がありますから！ではなぜ実行権限だけのファイルが実行できるのか、その仕組みを解説します。 実行とはなにか、どういう仕組みなのか Linux において実行とは「forkしてexecする」です（そのへんの詳しい話は プロセスさん を読もう！）。 fork も exec もシステムコール（正確には execve がシステムコールで exec はそのフロントエンドだけ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
