サメを支える技術 - ✘╹◡╹✘
写真のサメのぬいぐるみの購入方法についてです。 1. 本体 Original Chumbuddy のやつです。本家サイトでは品切れで買えないことが多いので、Amazon.com: Original Chumbuddy Skin (Stuffing Not Included): Toys & Games で買えます。結構な値段します。 2. 綿 上記の商品は皮だけなので中に詰める綿が必要です。8kgぐらいあると安心でしょう。結構な値段します。自分は Amazon | フックラ手芸綿ソフィア 3キロ（300g入り10袋セット） クリスマス飾りつけにも最適 | 手芸わた 通販 を2つ買いました。お腹のところにジップがあるので簡単に詰められます。もうちょっと綿詰めてふっくらさせたい感じもしますが満足しています。ぐったりしてきたら買い足す予定です。 おわり 以上です。掃除のときとかには持ち上げる必要
ソフトバンクからIIJmioに乗り換えた - ✘╹◡╹✘
iPhone 7を購入するついでにSIMフリー版を選択し、ついでにソフトバンク回線を解約してIIJmioを契約した。 ソフトバンク利用状況 2009年にiPhone 3GSが発売された頃から、iPhone経由でソフトバンクの回線をずっと利用していた。最近の平均的な月額利用料金は8,200円ぐらい。毎月の通信量は3GB強。以下は8月の利用料金の内訳。まあ高い。 通話料 140円 基本料 (ホワイトプラン) 934円 パケットし放題フラット for 4G LTE 5,700円 PCダイレクト 1,000円 S!メール (MMS) 100円 S!ベーシックパック 300円 テザリングオプション 500円 IIJ mio IIJ mioにしたのは、周りの信頼できる人間が利用していたからという感じです。SIM1枚でdocomo回線で月3GBの通信量のプランを選んだので、月額利用料金は税抜きで1,60
最強のTwitterクライアント戦争情報 - ✘╹◡╹✘
kkosuge 最強のTwitterクライアント作り始めた - 9mのブログ kkosuge/slack-like-twitter-client r7kamura 最強のTwitterクライアント戦争に参戦 - ✘╹◡╹✘ r7kamura/retro-twitter-client k0kubun ElectronでYoruFukurou風のTwitterクライアントを作った - k0kubun's blog k0kubun/Nocturn airtoxin 最高のツイッタークライアントを求めて airtoxin/twitter-client rhysd rhysd/Stream khrtz ツイッタークライアント「light」を作り始めた - インターネットの人になりたい khrtz/light-twitter-client bokuweb 最強のTwitterクライアント戦争にこっそり
コード読むとき - ✘╹◡╹✘
コード読むとき普段どうやってるんですか、って今日聞かれた。そのときは喫茶店でお茶飲みながらiPhoneでGitHubのページ開いてぼーっと見ているような感じで、特にツールとかなくてlib/vagrant/bundler.rb とか lib/vagrant/pre-rubygems.rb とか見てた。ページ遷移するときにまた見たいファイルのときは必ず次のタブで開いていって履歴を視覚的に残す的な小賢しい細工は適宜やっていっているかも。コードジャンプする機能とかは使ったことなくて、雑にファイル開いたり閉じたりしながら見てることが多い。ボトムアップに読むほうなので、CLIツールだったら実行ファイルとか、Webアプリだったらリバースプロキシとの通信部分から処理の順序にしたがって読んでいくことが多い。あまりツールを使わない方なので、逆に命名規則が統一されていないとか、ファイル名とクラス名の対応が取れて
リモートワークの地味な知見 - ✘╹◡╹✘
華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
他のホストのコンテナに接続するパターン - ✘╹◡╹✘
他のホストのDockerコンテナには接続しづらい 1つのホストの上で複数のDockerコンテナを動かす場合、あるコンテナからあるコンテナに接続するためにはコンテナに付けた名前が利用できる。具体的には、コンテナの名前をもとにDockerが環境変数を提供してくれて、そこにアドレスとポート番号が入っている。しかし、複数のホストの上で複数のDockerコンテナを動かす場合、他のホストで動作しているコンテナに接続したいのであればこの方法は利用できない。単純に接続先のホストのアドレスとポート番号をコンテナ起動時に指定する方法もあるが、この方法では他のホストに接続する全てのコンテナに対して逐一指定する必要がある。 ホストごとにリバースプロキシを置く 他のホストのコンテナへ接続するためのリバースプロキシとなるコンテナを各ホストごとに設置する。これにより、他のホストのコンテナに接続したい場合でも、あたかもコ
全てがJSONになる - ✘╹◡╹✘
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
スター・ウォーズ内の英単語全部再生するやつ - ✘╹◡╹✘
ARST ARSW: Star Wars sorted alphabetically - YouTube よく出る単語は出た数だけ再生してくれるし、動画見てたらどういうコンテキストで使うか思い出せるし、 ABC順で覚えやすいし、とにかく便利。
Ruby + Bot = Ruboty - ✘╹◡╹✘
https://github.com/r7kamura/ruboty RubotyというRuby製のChatterbotをつくった。 Herokuで動かす Herokuにデプロイすれば無料で動く。 Slackというチャットサービスで動かすならこういう感じ (部屋名とかは適宜変える): $ mkdir mybot $ cd mybot $ echo 'source "https://rubygems.org"' >> Gemfile $ echo 'gem "ruboty"' >> Gemfile $ echo 'gem "ruboty-slack"' >> Gemfile $ echo 'bot: bundle exec ruboty' >> Procfile $ bundle install $ git init $ git add . $ git commit -m "Initial
XMPP界 - ✘╹◡╹✘
XrcというRubyのXMPPクライアントライブラリをつくったので、XMPP界の知見を共有します。 WHY RubotyというBOT開発用のフレームワークを最近つくっていて、 これをSlackというチャットサービスで利用していた。 SlackにはXMPP GatewayとIRC Gatewayが用意されており、 どちらかのプロトコルを利用すればBOTとして動作するにはひとまず十分だった。 Rubyで一般的なIRCライブラリと言えばnet-ircだけど、 自分でZirconというIRCクライアント用ライブラリを作って、 ruboty-slackでは最初はこれを使ってた。 IRCは雑に全部屋に適当にJOINしてくれたりするのでBOTとして運用するにはわりと楽だったんだけど、 メッセージに改行を簡単に含められないというところが気に入らなくてXMPPを検討することにした。 改行が含められないとどう
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
雑なレビュー - ✘╹◡╹✘
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
技術力がないから - ✘╹◡╹✘
つらいことがあったときに上手くいく呪文です。 人に唱えてダメージを与えることも出来る。
Immutable Infrastructureという考え方 - ✘╹◡╹✘
昼に起きて、溜まった家事を片付けながら、最近Immutable Infrastructureという言葉をよく聞くなと思って、語感と雰囲気から内容を考えてた。食器もまともに片付けられない人間はいるし、そういう人間はどう言っても変えられないし、最初から紙皿だけ使うようにした方が良いのかもしれない。元の状態にきちんと戻せとか文句付けるより、そもそも毎回全部捨てた方がいい。そうすることで、いつも同じ人間が片付ける羽目になるという属人性を排除することが出来る。要点は、ある種の人間を排除するのではなくて、どんな人間でもまともに生きていける社会にしようということ。紙皿のような技術が進化し、環境ごと簡単に破壊するような時代になってきたからこそ、こういう考えが生まれるようになった。
体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
Go言語のテスト用ライブラリとGospel - ✘╹◡╹✘
先週初めてGo言語を触る機会があったので、テストの書き方を調べた。 要約すると、標準ライブラリのtestingが好きになれず他に調べても気に入ったものが見付からなかったので自分でつくった。 testing Go言語にはtestingという標準ライブラリが用意されていて、 「go test」コマンドを実行すると「*_test.go」という名前のテスト用ファイルがそれぞれ実行される。 具体的には、そのファイル内で定義されたTest*という名前のテスト用関数がそれぞれ実行されるようになっている。 公式サイトの例ではこういうコードが紹介されていた。 type doubleTest struct { in, out int } var doubleTests = []doubleTest{ doubleTest{1, 2}, doubleTest{2, 4}, doubleTest{-5, -10}
家の実装 - ✘╹◡╹✘
家にインターネットが来たのでAmazonでポチッたりして色々と環境を整えた。 ダイニングテーブル みんなでごはん食べるのに大きいテーブルが欲しかったので、とりあえず卓球台ポチった。 食後とか軽く運動したいときにすぐ打てて便利。 AppleTV リビングに良さ気なTVがあるのでAppleTVを導入してみたところ、想像以上に文化的な生活になった。 SoundCloudの音楽を流したり、YouTube見たり、AirPlayでMacの画面を流したりするのに使ってる。 ハッカソンとかやる時はプレゼンしたりするのに便利かもしれない。社のラウンジにもこれあったらいいのに。 MacはMountain Lion以降だとAirPlayが使えるようになるけれど、2011年より古いMacのGPUは対応していない。 普段TV見ないけど音が無いのは寂しいので、適当なコンテンツが流れ続けるソリューションがあると良い。
自分のコード綺麗って思ってんの？ - ✘╹◡╹✘
guideline.gem https://github.com/r7kamura/guideline 恐怖体験があって、震え上がり、少しでも綺麗なコードが書けるようなGemつくってる。複雑過ぎるメソッドや、使われていないメソッドが定義されていないかとか、長過ぎる行を書いてないかとか、簡単なチェックを自動化できる。こういうコードは綺麗ではないみたいなことがふわっと言われているよりは、綺麗ではないコードというのがコードで表現されている方が安心感があると思った。もしコーディングルールとして文書化したのでみんな守ろうみたいな感じにしても、コードを書くときに常にそれを覚えていなければ意味がないし、常にそういうことを気にしながら、ずっと緊張しながらコードを書かないといけない。そういう風に常に何かに気を配りながら作業するというのは、意識は高いけど、疲れるから極力やりたくないし、そもそも新しくその文化に
音の鳴るエディタことVim - ✘╹◡╹✘
音の鳴るエディタ - ✘╹◡╹✘の技術的解説。 おさらい 音の鳴るエディタ 眼を閉じた状態で"Hello"と入力して、画面を見ずに正しく"Hello"と入力されていることを確認したい。 そこで、キーを叩く度にそれぞれ固有の音が鳴るようにした。 プログラミングしながら演奏できる。 開発者集めてジャムセッションとかできると思う。 人月の神話っぽくならないように注意したい。 仕組み Vimはキーイベントが取れるので、キーを押したときにカーソルの下にある文字を取得して、それを非同期でRubyのプログラムに渡す。objective-c調べて書くの面倒だからRuby使った。Rubyの方は、文字列の文字コードと見て適当に半音階ずつの周波数を決める。a, b, c, d, ...と半音ずつ上がっていく。キーイベントでキーが取得できて非同期でシステムコマンド呼び出せるエディタだったら何でも使えると思うけど、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
