自分のバンドで使いたいから作った。 ニーズ ライブをやるときに、セットリストが足元にあると便利。 BPMも同時にわかると便利 便利なんだけど、ふつうBPM:88ですって言われてもそれがどれくらいの速さなのかはパッとわからない 楽譜アプリとかで、視覚的にBPMがわかる（丸が点滅してくれる）やつもあるんだけど、ライブしてる途中にスマートフォンとかタブレットとかいじってるところあんま見られたくない できればペダルボードの横とかに放置しておくだけで全曲のBPMを視覚的に教えてほしい。 機能 ライブでやる曲のリストをformタブから入力できる prompterタブではそのリストが表示され、「signal」というカラムでその曲のbpmに合わせて「●」が点滅してくれる share linkをコピーすると、アプリをインストールせずにバンドメンバーに展開可能 その際入力しておいたセットリストとbpmはURL

前回の記事の続きです。 前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの？」って話をしたいと思います。 基本的にはサーバーでもってあげたほうが楽 さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライ

先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と

twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基本非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて

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に応募するためのネタがほしいな〜 「で？なんか偉そうに設計の話してるけど、お前はそれで何作ったの？

yapcasia8oji-2016mid.hachiojipm.org YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa という、八王子なのか品川なのかよくわからない名前（正解は「品川は八王子（哲学）」という態度です）のカンファレンスに、スタッフ、そしてスピーカーとして参加してきました。 スタッフとして 飛び入りトラック、通称Dルームを担当させていただきました。なんかのときに「今回アンカンファレンス的なことやりたいです」とわたしが発言したため、わたしが担当になったといういわゆる「言いだしっぺの法則」というやつですね。 飛び入りトラックは、事前トーク応募には応募しなかった（あるいは、したけどリジェクトされてしまった）方が「それでも俺は喋りたいんだ！」という熱い気持ちをぶつけるための枠として、当日トークを受け付けて当日話してもらう、という枠で

まずはこちらをごらんください。 shinh.hatenablog.com すごすぎる……。恐ろしいですね。 なぜこんなことになるのか、解説していきましょう。まずはPerlの気持ちになりましょう。 Perlの気持ち編 ポイントその1 barewordを数値コンテキストで評価するとどうなるのかということ 件のプログラムは、base64 っぽい文字列が書かれていますが、これを前からPerlコードとして読んでいくと、大きく2つのパートに分かれることに気づきます。というのも、前から一文字ずつ読んでいくと、「+」という演算子にぶつかるわけですね。 それに気づくと、このコードは前半部分 dXNlIE1JTUU6OkJhc2U2NDtwcmludCBlbmNvZGVfYmFzZTY0IGpvaW4nJyw8PjsKX19FTkRfXwo と、 s//v62/e+s//v60/e+s//v44/e+s//v

一般に流通してない本なんだけど、下のリンクから買える。 【販売ページ】Traditional Music Theory For Contemporary Musicians | Music Theory Workshop Japan 公開されてる分は全部読んだ。 著者が自分でも言ってるんだけど、「猿でもわかる！！音楽理論」みたいなタイプのやつだと演奏や作曲に活かすことができないくらいレベルが低くて役に立たないし、かといって芸大和声みたいなやつだとそれを役立たせるまでの道のりが遠すぎる & ポピュラーミュージックに応用するまでの道のりが遠すぎるというのがあって、なかなか「演奏や作曲の役に立ちやすい音楽理論の本」ってのは今までなかった印象がある。この本はそのちょうど間を埋めるような立ち位置の本で、バンドマンやDTMerにとってはかなり参考になるのではないかと思った。 ただ、結構ストイックに進ん

「Niigata.pm って死に体なんじゃないの？」「しんぺいさん Niigata.pm やる気ないでしょ」「新潟にPMなんてあったっけ」「あいつもう Ruby と Scala しか書いてないしダメだな」「猫型さん完全にやる気ない」などの発言がそこかしこで聞かれる Niigata.pm ですが、単に子育てが忙しくて余裕なかっただけだよ！というわけで Niigata.pm やります！ NDS#39 Niigata.pm tech talk - connpass すごい！2ヶ月先だ！！！ 2ヶ月先なので、まだまだ未定なことも多いですが、なんといっても目玉は、東京ははてなから id:Songmu さんをゲストにおよびしていることです！songmuさんにしていただく発表は現在調整中ですが、続報をお待ちください。 また、songmuさん以外にも @hayajo さんと @ritou さん（ふたりとも

なんか型クラスとか言うと型の怖いひとたちが怖い話をワイワイしてるイメージがありますよね。わたしはあります。「で、それって何がうれしいのよ」とか、そういう話はあまりされていないような印象がありますね（あくまで印象です）。その上 "Scala の implicit parameter は型クラスの一種" とか言われると「暗黙的な引数がなんで型クラスの一種なんや！！！意味がわからん！！！！」となります。わたしはなりました。 というわけでそのへんについて勉強したので書きます。 そもそも型クラスってなんや Haskellとかにあるやつですね。アドホック多相を実現するもの、らしいです。すごい、いきなり意味がわからない。 というわけで、まずは「アドホック多相ってなんなの」という話からして行きます。 さて、まずは「多相」から行きましょう。この文脈で言う多相とは、簡単に言えば「引数にいろんな型を取れる」とい

きっかけはこのツイート。 基礎的なことなんだろうけど理解できてないこと。 読み取り権限のない実行権限だけのファイルってどういう扱いになるんだろう。— ゑぬぽい改@電探が出（ん）たん？ (@NPoi) March 27, 2014 実際にやってみるとわかるけど、実行権限だけついてるファイルは実行可能です。でも、「読み込めないのに実行できる」というのは直感に反するような気もしますね。だって、実行するためにはプログラムをメモリに読み込む必要がありますから！ではなぜ実行権限だけのファイルが実行できるのか、その仕組みを解説します。 実行とはなにか、どういう仕組みなのか Linux において実行とは「forkしてexecする」です（そのへんの詳しい話は プロセスさん を読もう！）。 fork も exec もシステムコール（正確には execve がシステムコールで exec はそのフロントエンドだけ

著者のひとり id:uzulla　さんから「webアプリエンジニア養成読本」という本を献本頂きました。うれしい！ Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者: 和田裕介,石田絢一(uzulla),すがわらまさのり,斎藤祐一郎出版社/メーカー: 技術評論社発売日: 2014/03/11メディア: 大型本この商品を含むブログ (2件) を見る 目を通させていただきましたが、かなり面白い立ち位置の本でした。 第 1 章 Web技術オーバービュー そもそも Web アプリってなんなのっていうか HTTP ってなんなの HTML ってなんなのとかそういうことが書いてあります。そもそも Web 技術がいろんな技術の集合体であるので、Web技術をざっと見回すだけでもかなりの紙面が必要であろうところを（

友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通

前回のおさらいと今回の話 前回は手続き型パラダイムとオブジェクト指向パラダイムを見比べたときに、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめて守る」という方向に言語が進化していったというひとつの史観を示しました。その中で返答として「構造化プログラミング」の時点でその視点はすでにあるという指摘を頂いたりもしました。ただ、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめる」という発想もオブジェクト指向の「ひとつの側面としては」たしかにありますし、その側面を見ると、オブジェクト指向言語に「言語デザインでもってプログラマーがそれを行いやすくした」という面を見いだすことができそうです。そして、その視点に立ったときに「臭ってくる」ヤバい設計として、「データが露出してる」「別のクラスのデータいじってる」「複数の異なるデータに関心をもってしまっている」というものを挙げてみました

TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん

年末までまだあるし年内の活動まだ確定してないけど、なんか年内忙しくてもうなんもできなそうだから今公開します。 総括 今年は去年に比べると格段にオープンソース活動ができたのでよかった感じがする。 一方、家庭優先にしててコミュニティ活動(Niigata.pm)は滞りぎみでちょっと良くないけど息子マンがもうちょっと大きくならないとちょっとコミュニティ活動難しいですねという感じがある。 勉強会とかで反響大きかったやつ Scala 入学式 Scalaに入学したらすごいよかったからその感動を伝えたくてNDS（長岡市で定期的に行われている勉強会です）の一環としてやらせてもらった。自分で言うのもなんだけどこれはかなり良い勉強会になっていたと思う。入学者各位はぜひ今後も Scala をアレしていってほしいです。そしてわたしに Scala 教えてください。資料はgistに置いてある が、口頭でめっちゃいろいろ

ことの始まり PHP の srand 関数について調べていて、ひょんな拍子にsrandのseedに文字列（numericである必要はあるけど）を渡せることを知った。 では、ここに long を超えるものを放り込むとどうなるのか。 では結果をごらんください。 「！？！？」 なぜこうなるのか 秘密は PHP 処理系の zend_parse_arg_impl 関数にあります。 zend_parse_arg_impl はphpの関数に渡された引数をパースする部分で、longを要求する関数にstringな値が渡された時の処理はこの部分ですね。 https://github.com/php/php-src/blob/master/Zend/zend_API.c#L335 さて、読み進めていくと「ん！？！？」ってなる行があるはずです。 この行ですね https://github.com/php/php-

最近ギョームでジャバスクリッ書いてる。というか CoffeeScript 書いてる。 そんな中で、ある程度以上複雑なUIを動的型付け言語で書くのは狂気の沙汰だという気持ちがある。 サーバーサイドは結構論理的にきれいな設計にできることが多く、そんなに複雑なオブジェクトコンポジションが生まれないように思う。まあ多分これは HTTP がそもそもステートレスなプロトコルなので、複数の操作に対して状態を保持する方法がセッションとかcookie以外にないというところによるのかもしれない。 一方、UIを書くというのは「論理的に整理された世界」と「人間の感覚」の間をつなぐ部分を書くということでもあり、なかなか論理的にきれいな設計にできないことが多い。UI自体の設計をがんばるときれいになるみたいなのもあるとは思うけど。まあ、そうであっても、UIの部分はどうしても状態をたくさん持つ。それをきれいに設計しようと

ruby 書くときの話なんだけど。ずっと emacs 使ってて、そのあと vim に乗り換えて、今 IDE 使ってる。 emacs のときは flymake が便利だなーって感じがあったんだけどなんだかんだで設定とかけっこうしないといけないし rbenv 使ったらハマった〜みたいなことがあったりした。 vim のときはコード編集中にリアルタイムでコンパイルエラーをアレできないのがだるいな〜ってなった。 今は RubyMine 使ってみてるんだけど、キーバインドは vim にできるし（結構重要）、存在しない定数参照しちゃったときとか存在しないメソッド呼ぼうとしてるときとかもリアルタイムで怒ってくれるので楽。 ただ、 IDE とコンソールを行き来しながらいろいろやらないといけないのがだるいな〜という感じがしているのと、型が実行時にしかわかんないという例のアレのせいで、IDE 使ってるわりにあん

とはいえ、パートタイムです。今までの仕事も今まで通り行ってるので、実情としては仕事を増やしたという感じです。子供できてお金必要だし。みなさんの大好きな転職エントリではありません。具体的な仕事はまだ始まってない（今週金曜日が初仕事です）し、まだ join することが決まっただけなんだけど、なんかいくらでもやらないといけないことあるっぽいし、まあ価値を提供〜〜〜！！できるようになるべく頑張りたいな、と思ってます。 というわけでスピリッチャルなエントリ書きます。 ウォーターセルってなに？ 「アグリノート」という、農業支援のためのアプリケーション作ってる会社です。決して怪しいお水を高値で売ってるみたいなやつじゃないです。そもそも sell じゃなくて cell だしな join の理由 まず第一にお金が必要で仕事を増やす必要があったからです。ここは譲れない。だってお金必要だもん。そもそもなんで私が