エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
ReactNative + Scala.jsファーストインプレッション - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ちょっと訳あって仕事の一貫としてReactNative + Scala.js の技術検証している。あたまには「全部C#」のライフベアさんの事例がある。弊社、最近メンバー増えてきたけどまだこの規模だと「あのひとはあれができるけどあのひとはこれができなくて」がボトルネックになりうるので、 筋の良い 共通の基盤技術を持つという選択肢のひとつとして検証したいというのがモチベーションとしてある。というわけで、 Reduxは使ってない。「Scalaを基盤技術にしてどこまでできるのか」が検証の目的だから。 Vue.js + Scala.jsでElectronアプリ作ったときと同じ感じで、MVWhateverのVとWhateverの部分は素直にJSで書いている。分厚いMをScalaで書き、UIだけReactNativeで記述する。 以下ファーストインプレッション pros Vue.js + Scala.j
Vue.js + Scala.js + Electron でMac用backlogクライアントを作りました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
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に応募するためのネタがほしいな〜 「で？なんか偉そうに設計の話してるけど、お前はそれで何作ったの？
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Scala.jsについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに オフラインファーストへの要求 近年、オフラインファーストというか、「オフラインのときにも普通につかえて、オンラインになったら同期する」みたいなことに対する要求が高まっているように感じます。 その場合は、ローカルにもきちんと永続データを持っておき、オンラインのときにバックエンドと通信をしながらバックエンドのデータと同期していく、というスタイルを考えるのが自然だと思います。 また、普通のJSアプリケーションであっても、「サーバーに投げる際に失敗したデータはローカルでメモリ上にもっておいてリトライしたい」などの要求もあるでしょう。 さらに、ここでモバイルアプリも視野に入っているとなると、どうしても「オッRealm Mobile Platformか！？」という感じが出てきますが、Realm Mobile Platformにロックインされるのと引き換えに開発の速を選ぶのか、それとも、という
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
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
続・結局型クラスって何がうれしいのっていう話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
今回は時間がないので簡単に見ます。 型クラスによってアドホック多相が実現されるとどんな柔軟なことができるのかという例を見ましょう。 たとえば、List#max について見て見ましょう。これ、要素が String だったら辞書順での最大値を返すし、Int だったら数的な意味での最大値を返しますよね。もし「そもそも比べられない型」が要素に入ってたらコンパイルエラーになります。 class Nyan(val value: String) //比べることのできない型 println(List(1, 2, 3).max) // => 3 println(List("a", "b", "c").max) // => c println(List(new Nyan("a"), new Nyan("b"), new Nyan("c")).max) // => error:No implicit Order
で、結局型クラスって何がうれしいの、ということの説明 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回の記事では、Scala では implicit parameter を利用することで型クラスと同等のことが実現できることがわかりました。しかし前回の疑問として、「で、それの何がうれしいのよ」というのは残っていましたね。 今回はそのうれしみをなるべくわかりやすく説明したいと思います。 たとえば、色んなクラスに flipFlap メソッドを生やしたい まず、前回と同じく「値をひっくり返す」という flipFlap について考えてみましょう。 前回は関数を作りましたが、Scalaらしく、こういう動きにしたいですね 1.flipFlap // => -1 true.flipFlap // => false "string".flipFlap // => gnirts Scala ではクラスを拡張するときには implicit conversion を使うのが一般的ですね。 class IntF
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
TcpPipelineHandlerで管理してるコネクションを切るの術 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
解決したい問題 Akka でネットワークサーバーを書く場合、エンコード/デコードの部分は Pipeline を利用し、TCPレイヤーの IO をその Pipeline に流し込む場合は TcpPipelineHandlerを利用するのが定石だと思いますが、ではサーバーがレスポンスを返したあとにすぐにコネクションを切ってしまいたいみたいな場合はどうすればいいでしょうか？ 簡単なエコーサーバーを例に見ます。 class ServerHandler(port: Int) extends Actor with ActorLogging{ IO(Tcp)(context.system) ! Tcp.Bind(self, new InetSocketAddress("localhost", port)) def receive: Receive = { case Tcp.Bound(localAddr
日本一わかりやすいというほどでもない Akka2.2 の IO まわりと Pipeline まわり - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
！！！！！！この記事は古い情報を扱っています！！！！！！ Akka 2.3 からは Pipeline はなくなっています。この記事の内容は古いです。気をつけてください 前回までのあらすじ 自信満々で日本一わかりやすい Akka の IOManager と SocketHandle(やServerHandle)、それに IO.Iteratee と IO.IterateeRef というブログ記事を書いたしんぺい a.k.a. 猫型蓄音機。しかし彼を待ち受けていたのは、「それ 2.2 から deprecated になるよ」という無慈悲な現実であった。Akka 2.2 から使われることになる akka.io と Pipeline という新しい敵が待ち受ける中、しんぺいは日本一わかりやすい記事を書けるのだろうか？ という感じでした。それでは書いていきます。Akkaのバージョンは2.2.0-RC1です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
