#builderscon 2017で「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてベストスピーカー賞第三位を頂いてきた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先週開催されたbuildersconで表題の通りの内容をしゃべってきました。発表内容については、スライドもアップしてますが、いつもどおり実況中継シリーズを会社ブログのほうに書きます。ただ、あれ書くのすごい大変なのでもうしばらく時間かかりますすみません。書きました。 自分のトークについて 弊社はまだまだメンバーが少なく、わたしもJavaScriptが専門、あるいは専任というわけではないという状況の中で、「なるべくJavaScriptに独特の概念などはプロダクトに持ち込まず、他のプラットフォームにも通用するような考え方ややり方で保守性の高いコードを書く」ということを考えて設計/実装をしています。 その試行錯誤の結果得てきた知見を対外的に発表することで、みなさんに「JavaScriptに限らず有用なトークだった」と言っていただけたのは本当に嬉しいです。 ただ、逆に考えると「JavaScript全
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
Niigata.pm tech talk を開催しました #niigatapm - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
去る 12/13 、JPAさんの支援により Songmu さんを講師にお迎えして、Niigata.pm tech talk を開催しました。 内容 発表内容は、以下のような感じでした。 hayajoさん 「Dockerを使った Perl アプリケーション開発」 タイトルの通り、Dockerを利用して Perl のアプリケーションを開発するためのノウハウについて発表していただきました。実際にテスト用の環境で業務で Docker を利用されているらしく、さらなる知見を今後も発表していただけそうですね。レンサバを提供するという業務上、FTPの利用をやめることができず、そこがボトルネックとなってDockerをなかなか本番投入できない、という話は「なるほどな〜」という感じでした。資料はこちら Dockerを使ったPerlアプリケーション開発 | ストーリーボード - STORYBOARDS mozn
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
猫型プログラミング言語史観(2) 〜あるいは実行コンテキストにどう立ち向かうのか〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
前回のおさらいと今回の話 前回は手続き型パラダイムとオブジェクト指向パラダイムを見比べたときに、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめて守る」という方向に言語が進化していったというひとつの史観を示しました。その中で返答として「構造化プログラミング」の時点でその視点はすでにあるという指摘を頂いたりもしました。ただ、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめる」という発想もオブジェクト指向の「ひとつの側面としては」たしかにありますし、その側面を見ると、オブジェクト指向言語に「言語デザインでもってプログラマーがそれを行いやすくした」という面を見いだすことができそうです。そして、その視点に立ったときに「臭ってくる」ヤバい設計として、「データが露出してる」「別のクラスのデータいじってる」「複数の異なるデータに関心をもってしまっている」というものを挙げてみました
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
やはり俺のMVCは間違えている in Backbone.js - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
昨日のエントリの続き。こっちのほうが有益な情報になってると思うんだけど多分昨日ほどはのびない。 さて、昨日のエントリーでは「Backbone.jsのViewはControllerってことなのか〜それは俺が間違えてたわ〜、えっじゃあ Marionette.js 使う場合はどうなの」という感じになったのだけれど、そのあといろいろ考えて以下のような感じに落ち着いた。 Marionette.jsを使っていたとしても結局考え方はBackbone.jsのときとかわらない。 つまり、Marionette.js の View も C である。ViewControllerと言うべきかもしれないので以下ではViewControllerと書く。 ViewControllerの責務は、以下の通りである。 Model(あるいはCollection)をひとつ保持し、View(HTML片のことである)をひとつ保持する
やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
ウォーターセル株式会社に join します - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
とはいえ、パートタイムです。今までの仕事も今まで通り行ってるので、実情としては仕事を増やしたという感じです。子供できてお金必要だし。みなさんの大好きな転職エントリではありません。具体的な仕事はまだ始まってない（今週金曜日が初仕事です）し、まだ join することが決まっただけなんだけど、なんかいくらでもやらないといけないことあるっぽいし、まあ価値を提供〜〜〜！！できるようになるべく頑張りたいな、と思ってます。 というわけでスピリッチャルなエントリ書きます。 ウォーターセルってなに？ 「アグリノート」という、農業支援のためのアプリケーション作ってる会社です。決して怪しいお水を高値で売ってるみたいなやつじゃないです。そもそも sell じゃなくて cell だしな join の理由 まず第一にお金が必要で仕事を増やす必要があったからです。ここは譲れない。だってお金必要だもん。そもそもなんで私が
Git を怖くなくする 荒技 tips - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プログラマーに対しては「四の五の言わずに覚えろ」でいいんだけど、そうじゃないひとにも使ってほしいみたいなことって仕事であると思う。だから前の記事みたいなやつ書いてるんだけど、どう考えてもコミットメッセージ 書くときにターミナルで使うエディタ使ってもらうのはかなりのつまずきポイントなので、なんか方法ないかなーって考えてた。 で、かなりの荒技なんだけど、open コマンドで mac のエディタ開いちゃうってのを思いついた。 $ git config --global core.editor 'open -t -W' で、エディタを 'open -t -W' にしてしまうという荒技。 "-t" は、「標準のテキストエディタで開く」っていうオプションで、"-W" は、テキストエディタが終了するまでブロックするってオプション。"-W" 付けないと、openしたあとすぐプロンプト戻ってきちゃって、空の
*nixのプロセスまわりについて書いてたやつがついに書き終わった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
プロセスさん最終回書いた。 最終回： https://gist.github.com/Shinpeim/5205353 目次： https://gist.github.com/Shinpeim/4736099 第一回を書き始めたときには、もっとさらっと書けるだろうと思ってたんだけど書いてみたらいろいろ書くべきことがあって、なんだかかなり辛い量の文章書いてしまった。最後のほうとかもう書くのがかなりしんどかったんだけど、プロセス周りの話はだいぶ網羅できたんじゃないかなって思う。 小出しに書いてる間、はげましのブクマとかはげましのスターとか付けてくれたひとがいたから書けたし、「おもしろい」って言ってくれたり「わかりやすい」って言ってくれたひとたち本当にありがとうございました。あなたがいなければプロセスさんは存在しなかった。 なんか噂によると Working with Unix Processes
Redis の expire はいつ実際にデータを消しているのか？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
expire で指定した時間を過ぎたデータが実際に消されるタイミングはいつなのかということを調べた。 どこから調べたの 公式ドキュメントのexpireのところ から調べた で、どうやって消してるの Redis は expire で指定した時間が過ぎたデータを消すのにふたつの戦略を使ってる。 値が取得されるときに消すよ 値が取得されるときに、その値がすでに expire 過ぎてたら消す。 値が取得されなくても消すよ 値が取得されるときに消す感じだと、たまにしか取得されないデータとかあるいは全然取得されないみたなデータはいつまでも消えなくて困るよね 値が取得されなくても定期的に消そうねって感じで消す。Redis さんは以下のような感じで消してるらしい まずランダムに20個のキーを選ぶ 選んだキーのデータが expire 過ぎてたら消す 25 個より多くの key が expired だったら1
後方互換性についてさいきん考えていることを書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
後方互換性を守るべきブロダクトと、そこまで気にしなくていいプロダクトがあると思っている。 後方互換性を守るべきもの これはもうシンプルで、「依存関係の下のほうにあるプロダクト」。下のレイヤーを担うことを狙っているものについては後方互換性を守って行かないとみんなが困る。多くのライブラリがすでに依存してるライブラリとか、あとはまあデータフォーマットとかも変わるとそもそも溜め込んだデータとかが使えなくなったりするので困る。 Perl5 が後方互換性を保つことに熱心なのは、そもそも Perl がシステムツールによく使われていることと無関係ではないはずだ。system perlのversion上げたらシステム動かなくなりましたみたいなことになったら困るからかなり気を使ってる。その点、Python が 2 系から 3 系に移行するときにばっさりと後方互換を捨ててしまったのは失敗だったんじゃないかなと私
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
2012年振り返り - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
Niigata.pm 去年はけっこう肩に力が入っていた感じがするのだけれど、今年は肩の力を抜きつつもtech talkとかもきちんとできて、よかった感じがする。来年もあまり枠に捕われず、刺激的なハッピョーが自分でもできるといいしみんなにもやってもらえるといいと思う。 仕事 ようやくCIを導入したりとそれなりに価値を提供できたとは思ってる。まだまだ甘さがあるのでもっときちんと価値を提供していきたい ブログ スピリッチャルな記事のほうがブクマ付いてるので、来年はもっとちゃんと技術的に面白いものを提供できるようになりたいと思う 総括 今年はけっこうおもしろおかしく生きて行くことができたので来年もこの調子でおもしろおかしく生きていきたい
TypeScriptのファーストインプレッション - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TypeScriptで遊んでみている。 書いてて気持ちいい部分 コンパイル時に型チェックが走るのがすばらしく安心感がある。 素の JS にすごく近い。Coffee とか JSX は 「新言語」って感じだけど TypeScript は better JS って感じ。コンパイル後のソースとの乖離が少ないのでそこに脳力使わなくても済む。 書いてて気持ち悪い部分 素の JS にすごく近い。腐るほどある JS のダメな部分をかなり残している。JSのバッドノウハウ健在。 リスト操作もうちょっとサポートしてほしい。 で、結局どうなのよ 私は TypeScript かなりいい感じだなーと思っている。CoffeeScript とか JSX は JavaScript の「ダメなところ」をきちんと wrap してくれてるのが良いが、CoffeeScriptは型がゆるゆるで深夜のドンキホーテに居そうな感じするし、
意識を低く保つための tips - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ハイ意識でそれを実践してるひとたちのことをわたしはすごいかっこいいなーすごいなーって思って見てるんだけど、世の中には「意識高い()」みたいなアレがあって、わたし自身もある程度それを内面化してしまっていて、たまに「ウッ意識高いひとだ……」ってなることがある(facebookに生息してることが多い気がする)。「ウッ意識高いひとたちだ」ってなるの、結局意識に行動が追いついていないから痛々しく感じるわけで、意識だけが上空 100km を浮遊してるみたいなのはもう完全に事故ってる感じがある。(意識も行動も上空 100km なひとたちのことは本当に尊敬してる)。で、意識だけが舞い上がっちゃうみたいなのを嫌うあまり、意識はなるべく低く運用していきたいなーって思うんだけど、意識が低いままだと優秀な学生たちが卒業した瞬間に私の仕事はなくなり、その日食べるお米さえなくなってしまい破滅する。 あと、わたしがプロ
第28回 長岡IT開発者勉強会に参加してきました #nds28 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
9/22に新潟県長岡市で行われた開発者勉強会に参加してきました。 討論会 今回は「スーツvsギーク」というテーマの討論会で、"対立しがちなマネージメント層「スーツ」と、技術者層「ギーク」。 考え方は違えどもお互いが目指すゴールの共通点はあるはず。そんな二者間の共通点を議論しましょう！"という内容で、いろんな討論が行われていました。 新潟県という土地柄、SIer的なところの話が中心になっていたと思います。私は web 系と呼ばれるようなところからお仕事をもらっており、いわゆるSIer的な文化とは違うところに住んでいる人間ですので、実は結構新鮮な気持ちでみなさんのお話を聴く事ができました。 結構私も発言させてもらったのですが、 SIer と web系ではそもそもビジネスの仕組みが違うので、そのあたりをきちんとわきまえて「ひっかきまわさない」ような発言を心がけるべきだったなぁと今は反省しています
bash,zshのプロンプトをカスタマイズする - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
調べたのでメモ bashのプロンプトをカスタマイズするためには普通に .bashrcとかで PS1='✖╹◡╹✖'とかやればよいんだけど、たとえばここに今使ってるrubyのversionとか現在の時刻とか出したいみたいなことありますよね？ そういうときは、たとえばこういうことをするとできる PS1='$(date)' あるいは PS1='`date`' ``で囲んだコマンドとか$()で囲んだコマンドは、プロンプトが表示される度に実行され、ちゃんと毎回最新の情報がプロンプトに表示される。ただし、このとき右辺をシングルクオートで囲むことに注意。ダブルクオートで囲むと、(当然だが)PS1への代入時にコマンドが評価され、PS1にはその結果の文字列が代入されるため、たとえばdateだったらログインしたときの値がずっと表示され続けてしまうので注意。 一方、zshの場合は毎回コマンドを実行させようとPS
よけいなプライドは捨てたほうがいいという話について書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
雑文を書く。 ぼくはどちらかとプライドが高いほうで、単なる趣味であるところの音楽でも「下手なところは見せられない」とか、「アレを聴いてないことが恥ずかしい」みたいな気持ちを強く持ってる。なんというか、「下手なところを見せたら舐められるんじゃないか」とか「アレを聴いてないとバカにされるんじゃないか」みたいなふうに感じてしまう。 で、こういう話をしてるとよく、「プライドを捨てよ、そして楽になるがよい」みたいなことを言う人間がどこからともなく現れてOSEKKYOを始めたりするのだけれど、そういうのに対しても結構大きな違和感を持っている。こういう「舐められたくない」みたいな気持ちがないと、クオリティの低いものばかり作り出す邪悪な人間になってしまうし、プライドがあるからスキル上がって行くみたいなところはあると思う。 一方で、こういうプライドがじゃまになることもたしかにあって、馬鹿にされるのが嫌だから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
