サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
衆院選
blog.uu59.org
有給消化中で時間があったので今まで縁がなかった技術にどっぷり染まることにした。Ruby, JS（フロントエンド）,JS（サーバーサイド）、その他諸々をワンオペで作ったので個別に見てみると低品質かもしれない。ところどころデバッグコードや雑なコメントアウトやTODOが残ってそう。 コード： https://github.com/uu59/jinro-public （意味をなさないコミットや機微情報を含むコミットを乱発していて、それらを取り除いてきれいな歴史にするのが人間業では不可能な水準だったので全部なかったことにしてひとつの巨大なコミットにしたあと公開しています） 基本指針 なるべくコードベースやAPIなどがコンパクトなものを採用する。例えばRails、faye、webpackは候補から外れることになる。 いくらか使ったことのないものにも手を出すが無理はしない 2月中には見せれるレベルに達し
小規模なうちは粗雑なものでも問題ないが、規模が大きくなるにつれ支障をきたすようになり、やがて破綻する、というパターンがよくある。このパターンは視点の違いによって「技術的負債」という象徴で呼ばれることもあるし、茹でガエルの比喩や炭鉱のカナリアといった形でもよく説明される。ぱっと思い出せないだけで他にも無数にあると思う。 すべてが容易に見通せるくらいの初期段階から大規模になりうる可能性を考えて堅牢かつスケーラブルな作りにするのはそれなりにコストが大きく、必要になるかどうかすら不確定なためそれで事足りるうちは粗末なものでよしとされる。問題になってから考えようという姿勢だ。例えば利用者が数人しか居ないうちは安価な家庭用ルータで問題なくても、数十人規模になってくるとネットワークが不安定になる。サーバが1台しかないならsshで接続して生のログを見ればいいが、2台3台の時点で苦痛になり、近いうちに不可能
https://github.com/uu59/atom-twitter-client mikutter使ってたけどどうも複数アカウントだと不安定でしょっちゅう落ちるので作った。以下は日記なので有益なことは書いていません。 ツールとライブラリの選定あるいはyak shavingの軌跡 前に書いたようにnpm run-script用にCoffeeScriptも使ってるけど、アプリのコードはECMAScript6 with Babelに統一した。単にES6書いて知見を得たいというだけの理由でES6にしていて、traceur-compilerじゃなくbabelにしたのも「JSXの面倒も見てくれるしなんとなく」くらいの弱い理由でしかない。 フレームワークはReactとFluxxorを使った。当初はmercuryを参考にしながらMatt-Esch/virtual-domを使おうとしてたけど、babe
webpack for browserify users browserify for webpack users browserify フロントエンド界にCommonJSスタイルを持ち込める 一部Node.jsのモジュールも使える。pathとかurlといった便利な小物から、zlibとかcryptoなどの本格派も移植されてる substackプロダクト。よってUNIX哲学へのこだわりが強く、必要なさそうな機能は本体で持ってない。 本体は単機能だけどwatchifyやdebowerifyやbundle-factorなどと連携して多くのことができる 当然ながらgrunt/gulpに組み込むことも出来る webpack フロントエンド界にCommonJSやAMDスタイルを持ち込める JS以外にもCSSとか色々扱える オプションやモジュールが色々あって気になったことは大抵できると思う grunt,
前に書いたnpm runのやつをしばらく運用してみたけど、やっぱりpackage.jsonだけで頑張るのはつらくなってきた。特にbrowserify/watchifyのオプションがぐんぐん成長していくので、新たなモジュールを使うことになったときwatchタスクとbuildタスクの両方に追記する必要があるけどそれぞれで微妙にオプションが違う、みたいなのが困りどころ。あと単純に横に長くなって読みづらい。 というわけで前回少し書いたように別スクリプトとして切り出すことにした。シェルスクリプトにしようかと考えたけど、windows環境とか複数プロセス（watchするデーモン）の管理とかを考えるとjsで書いたほうが良さそう、ということでその道を探った。 jsで書くといってもvar browserify = require('browserify')して生APIを操作するとかはしたくなくて、まずはCL
http://substack.net/task_automation_with_npm_run これ読んでたしかにという気持ちになったので試してみた。buildが手抜きだけどまあ雰囲気のために用意してみた。 ディレクトリ構成： $ tree src/ src ├── jade │ └── index.jade ├── js │ ├── app.js │ └── foo.es6 └── styl └── foo.styl package.json: { "name": "foobar", "version": "1.0.0", "description": "desc", "scripts": { "watch": "npm run watch-js & npm run watch-jade & npm run watch-stylus", "watch-js": "watch
https://rvm.io/binaries/ から自分の環境にあったディレクトリに進んでインストールしたいRubyのtarballを手に入れる 展開して出来たディレクトリを移動する mv ruby-2.1.3 $(rbenv root)/versions rbenv versionsにさっき移動したディレクトリ名(ruby-2.1.3)が出るのを確認してrbenv shell [name]する ruby -vとかで動作確認 という作業をrbenvが自動的にやってくれるようにするissueが上がってるけど進行が捗々しくない https://github.com/sstephenson/ruby-build/issues/42
社内用のウェブサービスをいろいろhttps化する動きがあるので、とりあえず先陣を切ってnginx.confを書いた。 httpsがらみの設定だけ抜き出すとこんな感じ。 http { server { listen 443 ssl; ssl on; ssl_certificate /etc/ssl/certs/ssl-bundle.crt; ssl_certificate_key /etc/ssl/private/server.key; # http://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # $ openssl ciphers 'HIGH:RC4:!3DES:!AES256:!CAMELLIA:!MD5:!aNULL:!eNULL:!EXP:!KRB5:!PS
https://github.com/fluent/fluentd-ui 開発者としてはあれが足りてない、こうなってると良さそう、などなど理想が次から次へと明確に見えてくるのでなかなか満足できないものですが、今のところ概ね好意的な評価を頂けているようでよかったです。 @kzk_mover, @repeatedly, @kiyototamuraの御三方には大変お世話になりました。社としてのあれは社としてあれされるだろうということでそれ以外のあれを書いときます。 制約について 珍しいものとして以下の2つがある。 RDBMSは禁止（別デーモンのpostgresqlとかは論外。sqliteもwindowsで少し怪しい） coffeescriptは禁止（ユーザーがnode.jsを持ってない可能性は充分ある） RDBMSがないことでバージョンアップとマイグレーションについて悩まなくて済んだ、などのいい
前書き Railsを使いつつJSもそこそこ書きたい、という条件であればまず前提としてjQuery脳を捨てましょう。jQueryスタイルで考えるかぎり何をどうやっても破綻するのでJSを諦めるか保守性を諦めるかして覚悟を決めましょう。 捨てるのは「jQuery」ではなく「jQuery脳」です。jQueryでグローバルな領域に進出してメソッドチェインで狼藉を働いたり、いま現在目の前にあるHTMLだけを考えてDOM操作をしたり、$.onと$.triggerを使ったクロージャ内部へのGOTOなどを記憶から消しましょう。 可能な限りスコープを小さく保つのはプログラミングの基本原則といえます。その原則を思い出し、JSを軽く扱わず、一般的なプログラミングと同様に閉じられた関心事にのみ注力するようにしましょう。 RailsとJSと役割分担 Railsもviewとしてテンプレートエンジンの処理を持っていますが
Jekyllには--lsiというオプションがあり、これを有効にするとベイズ理論がどうとかで関連記事を算出してくれる。pure rubyでも実行できるけど絶望的に遅いのでC拡張であるgsl gemを入れないと実運用は厳しい。ところが「ruby gsl」とかで検索するとわかるように、このgemは色々と厄介で、古めのRubyかつパッチを当ててからでないとインストールができない。gslパッケージも各ディストリにあるけど、最新よりも少し手前のものが必要になる。 ブログのためだけに古いRubyや古いgslを入れたくなかったのでDockerに閉じ込めた。 FROM ubuntu:12.04 RUN echo 'deb http://ftp.jaist.ac.jp/pub/Linux/ubuntu/ precise main restricted multiverse' > /etc/apt/source
前のマシンのディスク容量がかつかつで爪に火をともすような生活だったのでマシンを新調した。ついでに長らく使ってたUbuntuからArch Linuxへ乗り換えた。離れた動機は「Debian系に飽きた」で選んだ理由は「systemdがデフォルト」くらいのゆるい感じ。 Archのインストールは難しいと言われてるけど、自分でcgdiskとか使ってパーティション切るのが職人技でよくわからないといったくらいで、こだわらなければコピペで済む。面倒なのでMBR以外は単一のパーティションにしてswapも作らずLVMにもせず残りまるごとext4にした。 その後のarch-chrootして云々とかも先人の記録がいっぱいあるので省略して、インストール完了後にやったことを適当にメモる。 yaourt有効化 「yaourt 有効化」でググって従う（具体的な手順わすれた） 時刻 $ ln -s /usr/share/z
If at first you don't succeed; call it version 1.0. npmのバージョン指定が少し変わるらしい。 “npm install –save” No Longer Using Tildes npmのpackage.jsonでバージョンを固定するとき、~1.2.3と指定しておくと1.2.x(xは3以上でなるべく大きいもの)をインストールしようとします。これがデフォルトで^1.2.3のようになり、1.x.y(1.2.3以上で2.0.0未満のうち最新のやつ)をインストールしようとするようになったらしい。 semver、Semantic Versioningが定義するところでは、マイナーバージョンアップ(1.2.3→1.3.0)は後方互換性を壊さないはずなので^にしても理論的には問題なく、あったとすればそのパッケージのバージョニングが悪いという感じになり
なんとなくシェルに対してどういう態度で接しているのか思い出した順に書いておく。 こういうポリシーがあるからこうする、というよりも、こうなってることが多いのでこういうポリシーが背景にあるようだ、という知見をまとめた感じ。 dotfilesはこれ：https://github.com/uu59/dotfiles エイリアス なるべく使わない。これはgitのエイリアスなどについても同様。 https://github.com/uu59/dotfiles/blob/c7a44a1699ee82cc07a15d3ea1e2e516b7e17846/.zshrc#L84-L103 $ alias C='| xsel --input --clipboard' aptf='sudo apt-file search' apti='sudo apt-get install' apts='sudo apt-ca
rbenvの初期化が0.5秒くらい掛かる。evalしてるのは公式ドキュメントにそう書いてるから。 $ time (eval "$(rbenv init -)") ( eval "$(rbenv init -)"; ) 0.30s user 0.08s system 82% cpu 0.462 total 一方rbenvを無効化したzshなら、起動から終了までは0.1秒未満（※個人差があります） $ time ( zsh -i -c exit ) ( zsh -i -c exit; ) 0.05s user 0.02s system 89% cpu 0.076 total 素のzshならもっと速い。 $ time ( : > /tmp/.zshrc && ZDOTDIR=/tmp zsh -i -c exit ) ( : > /tmp/.zshrc && ZDOTDIR=/tmp zsh -
http://togetter.com/li/594684 Immutable Infrastructureが盛り上がってるけどproductionサーバでやるとしたらそこそこの規模のサービスになると思う。 小規模なウェブサービスを複数持つ場合にCIするとしたら、それぞれのサービス用にCIサーバを立てるよりひとつのサーバに集約するほうがお金がかからなくてよい。 でもサービスAではMySQL 5.5、サービスBでは5.6、CではPostgreSQL 9.1といったように異なるミドルウェアを要求されることがあり、それらを全部入れてバージョンの違いも考慮して、とかやると管理面で厳しい。CIサーバをCIしたくなってくる。かといってEC2インスタンスを湯水のごとく使うには予算面などで厳しい。 といった事情があり、それぞれの環境をVMにして隔離すれば良いのではないかと思いついた。 https://gi
小ネタ。byzanzを使う。Debian sid、Arch、Fedoraあたりでは公式リポジトリからダウンロードできるらしい。Ubuntuではppaを使う。 http://askubuntu.com/questions/107726/how-to-create-animated-gif-images-of-a-screencast http://stackoverflow.com/questions/15300564/bash-script-to-launch-byzanz-record-in-linux-fedora-xfce スクリプトは上記を参考に少しカスタマイズした。 $ sudo add-apt-repository ppa:fossfreedom/byzanz $ sudo apt-get update && sudo apt-get install byzanz $ git
Digital OceanっていうVPSがあって、最安プランだと月額5ドルで使える。 それだけだと日本国内にあるさくらのVPSとかのほうが高速だしメリット薄い感じだけど、Digital OceanにはAPIがあってvagrantと連携できるらしいので試した。 環境と事前準備 vagrant-digitaloceanを使う。 $ vagrant --version Vagrant version 1.2.2 $ ruby -v ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux] $ vagrant plugin install vagrant-digitalocean Installing the 'vagrant-digitalocean' plugin. This can take a few minutes... Inst
cramという便利なものがあります。これは語弊のある言い方をするとRubyでいうcucumber/turnipのようなテストツールです。サンプルを見たほうが早いと思いますが、普通にMarkdownとかを書く感じでテストを書けて、コマンドの想定される出力と実際のものを比較してtrue/falseを判定するみたいなやつです。想定と実際の出力とのdiffがなければグリーン、期待と違えばレッドです。 Vagrantのテストというとserverspecが勢いありますが、cramはもっと生っぽいテストをかけます。serverspecではshould be_enabledのように、書くのは簡単だけど実際に何をテストしているのかはソースコードを見ないとわからないので、テストがこけた場合の原因調査がちょっと厄介です（例えばRedhat系ならchkconfigの結果を見ています）。とはいえcramでパッケージ
vimの起動時間はvim --startuptime /tmp/vim.logみたいにすると/tmp/vim.logに細かくログが出る。BenchVimrcを使うと.vimrcの行単位で処理時間がわかるようになる。 今までvimの起動に300msくらい掛かってて特に気にしてなかったんだけど、ふとEDITOR="vim -u NONE" git commit --amendしてみたら、いつもの起動に一拍置く感じがなくなって一瞬で起動してユーザーエクスペリエンスがかなり変わったので軽量化してみようと思った。 とはいっても既にそこそこチューニングしてあるし、100ms以下になるくらい速くするには入れてるプラグインを削る必要があって、そこまでして速くしてもあまり意味がない。gitのコミットメッセージの編集では-u NONE(素のvim起動)でもまあ充分だけど、普通にファイルを編集したいときはないと
最近社内ツール（ウェブサービス）のAPIの認証について考えてる。 ユーザーがブラウザからIDとパスワードを使ってログインする伝統的な感じのサービスだけど、Mechanizeとかを使ってブラウザ以外から操作する要望が高まってきているのでAPIを用意しようみたいになってる。そのAPIでの認証をどうするかという話。特定少数用の小規模なものを想像してもらうといい。 ざっと思いつく案は、 ID/パスワードを使ったBASIC認証 ID/パスワードを使ったBASIC認証以外の認証方式 OAuth SSH key pair ブラウザから設定画面でAPIキー/トークンの発行をするやつ くらい。SSL経由なので盗聴リスクやリプレイ攻撃や改竄については無視していいし、TwitterやFacebookみたいに不特定多数のサードパーティが居るわけでもない。1は便宜的にBASIC認証と書いたけどDigest認証でもあ
Ruby 1.8では動かないので1.9.xか2.0以上を指定したい、みたいな意味合いで.rbenv-version, .ruby-versionを置くことがありますが、rbenvではパッチレベルまで指定しないとダメなので「1.9.3-p374は入ってるしそれで問題ないけど指定されたp194がないのでインストールしないといけない」みたいになって面倒です。.rbenv-versionをリポジトリから除去してもいいですが、そうすると「このプロダクトは1.8じゃ動きませんよ」みたいなのを人間の力で周知しなければならず、それもまた面倒です。 たいていのプロジェクトではBundlerの存在を前提としているはずなので、Gemfileでやってしまいましょう。gem "foo", "> 1.9"みたいに書ければいいんですが、Rubyのバージョンは単一指定しかできないみたいなので黒魔術を使います。 sourc
Capybaraというgemがあります。これはrspecなどと連携し、visit "/"; page.body.should have_content "あなたの予想に反して、このページが見えているでしょうか？"みたいに使うためのライブラリで、裏ではレスポンスをSeleniumやWebkitなどに渡してレンダリングしたりJavaScriptを実行するなどします。 Capybaraにはドライバという仕組みがあり、有名なものとしてはCapybaraでwebkitを使うためのgemであるcapybara-webkitがあります。poltergeistはCapybaraでPhantomJSを使うためのCapybaraドライバです。最近v1.1.0でCapybaraの2.x系のAPIに対応しました。 PhantomJSはQtWebKitを使ってheadlessでwebkitを扱うもので、公式に配布さ
選択範囲をそのまま外部プログラムに渡して実行結果で置換したかったんだけど、vim-operator-userを使うのが手っ取り早そうだったので使ってみた。 .error { background-image: url(/icons/gnome_dialog_warning.png); } こんな感じのCSSで、/icons/gnome_dialog_warning.pngをビジュアルモードで選択してるときに任意のキー（ここではBとする）を押すと .error { background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAYAAAAGAB4TK
次のページ
このページを最初にブックマークしてみませんか？
『uu59のメモ | index』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
