サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
joker1007.hatenablog.com
Asakusaの方面から来ました 今回、RubyKaigiに来た人は何度かこの画像を目にしたかもしれません。 昔からAsakusa.rbに良く参加している人が発表資料を作る時に、良く使われている画像です。 いかにもシンボリックでアングルが良い写真なので、これが定番として使われています。私とモリスさんも今回のRubyKaigiで使わせてもらいました。 最近のAsakusa.rbに良く参加していて、今回のRubyKaigiに登壇していたメンバーは私が覚えている限りで以下の通り。(id表記 敬称略) @tagomoris & me @hsbt @koic @spikeolaf @youchan @aycabta LT Speakers @tad @284km @youchan 全員の資料を見てないので、全ての発表でこの画像が出てたかは分からないですが、めっちゃ多いですね。1日二人以上のペース。(
仙台で行われたRubyKaigi 2018に参加してきました。 RubyKaigiは毎年最高のイベントなのですが、今年は総合的に今迄で最も良い体験ができたRubyKaigiでした。 実績解除 今回のRubyKaigiで初めてメインスピーカーとして登壇することができました。 私が初めてRubyKaigiに参加したのが、確か2011年で1stシーズンのFINALとして開催された時でした。 そして、その頃からずっとThe RubyKaigiのメインスピーカーというのは憧れの場であったのですが、7年の歳月を経て辿り着くことができたことを本当に嬉しく思っています。 今回の発表内容は「Hijacking Ruby Syntax in Ruby」というタイトルで話をさせていただきました。 Asakusa.rbで雑談してたのが切っ掛けで、@tagomoris さんと盛り上がってRubyのダイナミックな機能
このエントリはRails developer meetup 2017で発表した内容をブログとして書き出したものです。 サンプルのスニペットが多いので資料の代わりにエントリとして公開します。 スライド用のmarkdownを元に起こしたものなので、少し読み辛いかもしれませんがご容赦ください。 ECSとは Dockerコンテナを稼動するためのクラスタを管理してくれるサービス 使えるリソースを計測し、自動でコンテナの配置先をコントロールしてくれる kubernetesではない。最近、kubernetesが覇権取った感があって割と辛い 今はEC2が割とバックエンドに透けて見えるのだが、Fargateに超期待 ECS or EKS :tired_face: RailsアプリのDockerize オススメの構成 実際にデプロイするimageは一つにする 例えばstagingやproduction等のデプ
とてもとても悲しいので、とりあえずやったことと言い訳を書いて気を紛らわせることにする。 敗北した身でグダグダ言うのが格好悪いことは百も承知だが、人間には魂の救済が必要であることをご理解いただきたい。 序盤〜方針決定 最初パスワードのコピペミス等でサーバーからガンガンBANされて、そもそもログインできなくなる。これで10分から20分ぐらい無駄にした気がする。 テザリングにIPを切り替えたり、他のノードから入ったりして、何とか公開鍵でログインできる環境を整える。 適当にベンチ流してスコアを取る前に、nginxのログ設定や構成を確認しalpを使って集計できる準備を整えた。デフォルト実装とRuby実装でベンチを流す。その裏で実装を一通り読む。 ざっくり図を書いて、相談。とにかく/iconsを何とかしないと話が進まないので、静的ファイルとして書き出してCache-Controlだよね、までは即決。
先日、広島で開催されたRubyKaigi 2017に行ってきました。 相変わらず各トークのテクニカル度合いが異常にハイレベルで刺激的なカンファレンスでした。 最近、静的解析やRubyと型の関係がホットトピックであることもあり、ripperやparser gem等のRubyパーサやRubyVM::Iseq周りを触っているスピーカーが多く、コアに突っ込んでいく人のアクティビティにはとても刺激を受けました。 個人的にはIseqのバイナリ表現とソースコードの変換を活用してマクロの様なことを実現していたCompiling Rubyという発表が印象的でした。 後、毎年ラストのキーノートはやってることが凄過ぎて、圧倒されるばかりですね。 私自身は、メインのスピーカーとして登壇することはできませんでしたが、LTスピーカーとして話をする機会がもらえたので、そこで登壇してきました。 From RubyKaig
Twitterでちらっと見かけたので、自分も良い点と悪い点をまとめてみようと思う。 良い点 電車に乗らなくて良い ミーティング開始の5分前まで寝てられる 人の話し声がしない 話しかけられずに済む 疲れたらいつでもベッドにダイブできる ちゃんとアウトプットしてれば、仕事している様に見せなくてもいい 寝間着で仕事ができる ハイスペックなPCが使える WiFiが不安定みたいなトラブルが少ない 良い椅子が使える ヘッドホン無しで音楽が聞ける いきなり歌い出しても、誰も変な目で見ないし、迷惑がかからない 基本的に引き篭りなので、自宅の環境が快適になる様に腐心した結果、大抵のオフィスより自宅の方が執務環境として優秀であり、自宅より仕事に関する物の水準が高い会社というのをほぼ見たことがない。 そして、日常生活において、歌うというのが精神の健康上とても大事なので、音楽を聞きながら突然歌い出したりしたいのだ
Thinkpadが唐突にぶっ壊れたため、自宅のPC環境を早急に何とかしないと色々不便でしかたなくなってしまった。 最近、Ryzenが盛り上がってるし、ここ5年ぐらいデスクトップPCを新調していなかったので、もうこのタイミングで1台作ってしまうことにした。 ちなみに、予算に限界があったため、タイミング的にThreadripperで組むことも可能だったがそれは諦めた。 構成 パーツ 名称 CPU Ryzen 1800X マザー MSI X370 GAMING PRO CARBON メモリ Crucial Ballistix 16GB x2 NVMe CFD CSSD-M2O512PG1VN 512GB VGA GIGABYTE GeForce® GTX 1070 G1 Gaming 8G 電源 Seasonic X Series 860W SS-860XP2S クーラー Corsair H11
書籍紹介は既にいくつか書かれているんで、私は自分の担当した箇所の話を書こうかと思います。 本日(5/17)改訂2版 パーフェクトRubyが発売されます - すがブロ 改訂2版 パーフェクトRubyが出版されました - esm アジャイル事業部 開発者ブログ 改訂2版 パーフェクトRuby:書籍案内|技術評論社 私は、どっちかというと大きく書き直す所をメインで担当していました。主にテストコードの章です。後Refinementsについても少し書いてます。 テストコードの章では、書籍紹介にある様にtest-unitを採用しています。 fluentdプラグイン関連のテストコードはtest-unitで書かれていることが多いのですが、最近その辺りを結構触っているので、私が書きますよと手を挙げさせていただきました。 Refinementsについては、恐らく数少ないproduction環境でもRefine
Macを捨ててThinkpadにGentooを入れて開発環境としてから2ヶ月が過ぎた。 世の中にはMacから離れようとしてThinkpadを買ったら、矢印キーボード押しにくいとかタッチパッドがクソなので、Macに戻っていった人も居るみたいですが、私としては至極快適に過ごしております。 そもそもThinkpadのタッチパッドは基本無効化するものなのでどうでもいい。まあそのスペース邪魔なんだよ、とは思いますがw Wi-Fiの無効化キーを誤爆するという危険があるらしいが、Gentooだと頑張って設定しないとそういう特殊なキーはそもそも動かないので、そんな危険もなく安全ですね。 Gentoo入れてタッチパッドを無効化すれば、Windows10というOSも使わなくていいし、全て解決するんではないでしょうか。 前置きはこのぐらいにして、色々と使うものが安定してきたので今の環境について書いていきます。
英字キーボード配列にできて開発ユースに耐えうるノートPCがとても選択し辛い昨今、なんとなく安牌ポジションだったMBPについにさよならしました。 元々、Macを好んで使っていたというより、解像度が高くて英字配列にできて電池の持ちが良いというノートPCがMBPだっただけで使ってたのですが。 一番大きな要因がコンテナの利用頻度が増えて開発環境も含めてDockerを使う様になったので、Macだとどうにも面倒だという点です。 docker-machineのデフォルトとかdocker for Macのデフォルトが遅過ぎて話にならないし、dinghy使ってもdocker-sync使っても微妙でかつ面倒くさい。 普通にLinux上で直接動かせるなら、無駄な苦労だと思って、まず開発用PCをLinuxにしようと決めました。 そしたら新しいMBPが30万越えるのに、一世代前のCPUとメモリでドヤ顔してくるわ、キ
もう2週間ぐらい経ってしまったが、tagomoris & tnmtとチームを組んでISUCON本戦に出場してきた感想を書こうと思う。 中々ブログ書いてる暇が無くて、えらく遅くなってしまった。 ちなみに結果は6位。3位以下は割と団子状態で、後一手ぐらい刺さってれば3位は行けただろうなあと、残念な思いがある。 まあ、どっちにしろ1位はちょっと難しかった。 細かい流れはモリスさんのブログに既に書かれているので、そちらに譲る。 今回のお題はdockerがバリバリ活用されていたのと、SSE + Reactによるサーバーサイドレンダリングの組み合わせという非常にモダンな構成だった。 お題の発表後は、流石にうわー……マジかーって感じになった。 そもそも、現時点のRubyのWebフレームワークというものはSSEの様なストリーム配信と余り相性が良くない。 なので、あんまり使わないし、最適化のノウハウも溜まっ
少し前にtagomorisさんと飲んでたらISUCON出ようぜーって誘われたので、一緒に出ることになりました。 メンバーは、私(joker1007)、tagomoris, tnmtの3人。 今までの職場で一緒にISUCON出ようって感じの人が周りに居なかったので、今回何気に初参加だったのでえらい緊張してました。 特にモリスさんはISUCON無敗神話を持ってたので、足引っぱらないか不安でしたね。 前日に素振りした感じでは、Webアプリとして真っ当にチューニングしてスコア出せる感じなら大体いけるやろーと思ってたんですが、当日のあの問題の感じでは割と焦りまくりでした。 やった事は大体以下の様な感じ。 isutarを統合する (不要なマイクロサービスは殺すべし) keywordリストを全部redisに乗っける 瞬間的に各keywordに大量のアクセスが来てunicornが詰まるのでpumaに変える
近況報告、というかタイトル通りなのですが、CTOとしてデビューすることになりました。 7月から、最近お世話になってたReproという所のCTOという肩書を得ました。 自営業の個人事業主からいきなりCTOですよw まあ、CTOといっても、そこのフェーズ次第でやることってのは色々と変わってくると思います。 私の当面のミッションは、中長期的なアーキテクチャの方針決定とそれを実際に形にすること。 そしてリクルーティング、つまり転職斡旋おじさん業です。 なので、責任とコミットする割合が増えるだけで、そんなに今までとやってることは変わらないと思う……多分。 まさか自分がCTOになるとは全然思ってなかったんですが、30歳も越えたし肩書きと共に仕事するのも新しい挑戦としては良いかと思いました。 後は、収入ラインとかIT健保の任意継続が切れた後の社会保障の確保ですかね……。まあ、金は大事ですよね。 他にも色
そろそろ忘年会シーズンですね。年末の飲酒予定がちらほらと埋まってきている頃だと思います。 というわけで、日本酒を飲んだ経験ならRubyist界の中でもトップクラスと勝手に自負しているこのjoker1007が、年末に向けてオススメの日本酒を紹介したいと思います。 居酒屋で日本酒を選ぶ時や、酒屋で買って宅飲みする時の参考にしていただけると幸いです。 ちなみに、書いてる内容は私の主観であって明確な根拠があるわけじゃありません。 私の味覚が適当な場合もあるし、同じ銘柄でも作り方によってはかなり違った味わいになるし、年によっても味は結構変わりますので最終的には勘に頼ってくださいw 鉄板 まず、ここ最近の俺的鉄板銘柄をいくつか。自分が旨味のしっかりした銘柄の純米吟醸が好きなので、その辺りで美味しい所が多いです。 東洋美人 (山口県) 少し前に大規模な水害に遭って蔵元がかなりの被害を受けましたが、その後
Electronで動作する動画ファイル及びJPG in Zip向けのファイルブラウザを作ってみました。 構成としてはElectron+React+Reduxで、gulpfile以外はbabelを使って書いてます。 そこそこ今風な感じを目指して、一部flowtypeとかも取り入れてますが、割と適当な感じで使ってます。 実は以前Node.jsで同じもの作ってたんだけど、せっかくちゃんとデスクトップアプリとして作れるようになったしReactにも慣れたのでElectronと今の技術で作り直してみたのがこれです。名前も同じだったりする。 https://github.com/joker1007/blackalbum https://github.com/joker1007/blackalbum/releases/download/v0.2.0/BlackAlbum-darwin-x64-0.2.0.
実はこれが初「で、お前だれよ?」エントリです。 最初の転職の時は、書くと愚痴と怒りしか出てこなさそうだったので書かなかったw およそ3年半ぶり二度目の転職、というか初の失職です。会社員を辞めてフリーランスになりました。 実は、年末の時点で退職を考えてたんですが、ちょっとタイミングが微妙に噛み合わなかったんで、1月から3月までの間は週に半分フリーランスという形で仕事してました。 で、4月から本格的に退職して完全にフリーランスです。 ITゼネコンの頂点みたいな会社に心疲れて2年半ちょっとで転職したので、もうプログラマーになってからの方が長いのかーと思うと感慨深いですね。 プログラマーとしても4年目に突入して、いよいよ中堅というかおっさん界の中でも中ぐらいのおっさんになってきた感じです。 今回会社を辞めたのは別に仕事に不満があったわけではないです。流石に完全にゼロでもないですがw 基本的には受託
既に大きい書店の店頭には並んでいる所もあるようで、自分もアキバの書泉で現物を見てきました。 立ち読みして、ほほーうとやってる著者の図って感じです。 献本させていただいた方にも、既に届いていて読んだよーって言ってくれてる方がちらほら。 参考になったと言っていただけて、とても嬉しく思っています。 さて、今回はちょっと自分の担当した部分と思ってた事について少し書いてみたいと思います。 私が担当したのは、3章のアセットについてと4章のlibディレクトリ周り+Railsのロードパスについて、そして9章のモデル実践編みたいな所です。 一応それぞれありますが、主に言いたいのは9章についてですw 3章について CoffeeとSassについて、どの程度解説するか非常に悩みました。 実際、書くとなるとリファレンスマニュアルを日本語で解説する、以上の事はページ数的にできない。 かといって、昨今のRailsアプリ
どうもAmazonがフライングでパブリック状態にしてしまったのが補足されてしまったので、想定してないタイミングで世の中に通知されてしまいましたが、Railsの本を書かせていただきました。 パーフェクト Ruby on Rails: すが まさお, 前島 真一, 近藤 宇智朗, 橋立 友宏 元々はパーフェクトRubyを書いた後にスペースの都合で削ったRailsの章があって勿体無いという話から出てきた本です。 タイトルは最初決まってなかったんですが、最終的にパーフェクトシリーズの一つということになりました。 タイトルこそパーフェクトって付いてますが、この本は他の言語解説系の本とはちょっと雰囲気が違う感じになっています。 まあ、執筆スケジュールとかページ数によるスペースの限界という理由もありますが(Rails本の中ではかなり薄い方)、網羅性というより仕事でRails使ってる人達の知識とか考えに重
年末のjava-ja忘年会に出た時にyamashiroさんの訃報を聞いて、訳の分からないまま飲み明かした日から1ヶ月半、今日はyamashiroさんの送別会に参加してきました。 その送別会でyamashiroさんを送るための花火が上がりました。 自分がいきなりこの世から居なくなった時に、花火を上げてまで馬鹿騒ぎしてくれる友人が居る彼を心から尊敬します。 今日LTしていた皆さんほどyamashiroさんと付き合いがあったわけではなく、ちゃんと話をする機会があったのは2013年になってからでした。何度か勉強会の懇親会で喋って、やっと顔見知りぐらいになったぐらいです。 多分、最後に会ったのはこわいscala勉強会の受付の時だったかな。 あの時、体調が良くなかったので、本編が終わった後にすぐ帰ってしまったのが悔やまれます。 java-jaの忘年会の日、訃報を聞いて何が何だか良く分かりませんでした。
この記事は闇 Advent Calendar 2013 - Adventarの19日目です。 なんか前回の記事を書いたjugyoさんが非常にインパクトの強い話をぶち込んできたおかげで、次の俺どうしようかって感じで困ってますが、私は普通に鬱屈してる感情を書くだけなんで、そんな面白い話は無いです。自分語りのオナニーをして終わりです。 変な期待をしてる人が居るかもしれませんが、私はマジで何も関わってないのでコメントのしようが無いし。 俺の経緯 私は大学生になるぐらいまで、ただPCでゲームして、エロ動画を見て2chを眺めているだけだった。 貧乏だったので、バイトして金溜めてPCを新調した時、古いPCを活用する方法を考えて、Linuxでルーターを作る事にした。 そこからLAMP構成ってやつでプログラミングの真似事をやりだした。 実際の所、私はエロ動画及び画像の収集と管理を楽にするためにプログラミング
この記事はVim Advent Calendar 2013の14日目です。 前の記事はVim on Android | 高級粗茶2。でした。 Vimを使っているとWeb上に存在するリソースもVimで扱いたくなることがあります。 そんな時の強力なお供がmattnさん作のwebapi-vimです。 webapi-vimを利用することで簡単にWeb上のリソースをvimに取り込むことができます。 let res = webapi#http#get(s:pull_request_list_url(a:repo), {}, s:github_request_header) if res.status !~ "^2.*" return ['error', 'Failed to fetch pull request list'] endif let content = webapi#json#decode
この記事はジョジョの奇妙な冒険 Advent Calendar 2013 - Adventarの7日目です。 土曜日中に書くつもりだったのが日曜日になってしまった…。 まあ、最終的に書けばよかろうなのだァーッ!ってことで。 ドイツ軍人は締め切りを過ぎてもうろたえないッ! 最近のジョジョでグッときたところは常秀のスタンド「ナット・キング・コール」とカツアゲロードの「オータム・リーブ」ですね。狙い過ぎ感があって、ニヤっとしてしまった。 やっぱ枯葉と言えば、ナット・キング・コールです。 ジョジョリオンはスティール・ボール・ランより好きかもしれない。 やっぱ杜王町は良い。 さて、エンジニアはジョジョを読んだ方が良いと思う理由について、ちょっと書いてみようと思う。 一言でまとめて言うなら、エンジニアが持つべき精神というものと非常に親和性が高いからだ。 ジョジョの登場人物は基本的に前向きであり、過去の
この記事はパーフェクトRuby Advent Calendar 2013 - Adventarの6日目です。 Rubyサポーターズの一員としてパーフェクトRubyという本を執筆する幸運に恵まれました、joker1007です。 そもそもはryopekoさんに指名していただいて途中からの協力者という形で参加しました。 私が主に担当してたのは、12章から14章までの、Rubyの周辺ツールやgem周りの部分です。 原稿が揃うまでは、仕事終わってから夜中に黙々と格闘する日々が結構多くて、中々辛いこともありましたが、形に残るアウトプットが出せたことを非常に嬉しく思っています。声をかけていただいて本当にありがとうございました! さて、こうして世に出たパーフェクトRubyなんですが、技術書の常というか既に古くなってる情報がそれなりに存在します。 特に、発売した後になってふざけんなよ!と言いたくなるぐらいが
週末の遊びとして、Vimにmrubyインターフェースを組込む実験をしてみた。 ほとんどCで書いた経験が無いので、出来るかわからんなーと思っていたが、構文を実行するだけなら何とか実現できたので、とりあえずまとめておく。 ほとんどmrubyというよりVimの話なんだけど。 mrubyについて調べる 流石にもう試してる人は結構居るみたいなので、mrubyをCのプログラムから実行して結果を取得するのはすぐに分かった。 しかし、なんかいくつかパターンがあるっぽいので繰り返し実行するのに良さそうなのをチョイス。 実行方法の違いが良く分かってない。 #include <mruby.h> #include <mruby/compile.h> #include <stdio.h> int main() { mrb_state *mrb; mrbc_context *cxt; mrb = mrb_open()
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
ちょうど、この一つ前の記事について書いた事を余りにも正直にLTで話してしまった事についてです。 Rubykaigi本編でのジェンダー発言については、私は聞いておらず良く分かりませんので、そちらの話はしません。 私の話は、非常に幼稚で多くの人に不快感を与えたことについては、完全にその通りであり、謝罪するしかありません。 申し訳ありませんでした。 当事者として、多少思う事があるので、いくつかツイートしましたが、Twitterで書いてると、断片的になって誤解を生んでしまうので、ちゃんと文章としてまとめておきます。 意図とは違う受け止め方をしているかもしれませんが、ただ謝罪するだけで何も言わない事はむしろ不誠実だと思うので、自分なりに考えた結果を書いています。 私は、どういう内容を語ろうが、どういう表現方法を使おうが、人を不快にさせる時は不快にさせるし、傷つけることもあると思っています。 現実的に
AWSのGlacierは、1GBでおよそ月に1円ぐらいなので、1TBバックアップしても月に1000円ぐらい。 これぐらいなら、まあDropboxのプレミアムぐらいの感覚で、1TBをAmazonさんにバックアップしてもらえますね。 ただ、Glacierは結構利用の手順が面倒なので、それを簡易化するためのアプリを書きました。 GitHub - joker1007/savant_time: Amazon Glacier Backup Wrapper 大体、以下のような機能があります。 ディレクトリを閲覧し、任意のファイルをバックアップするジョブを実行する 複数のファイルを選択し、バックアップジョブの実行キューに追加する インベントリ取得ジョブを実行する インベントリ取得ジョブ完了時のSNSメッセージを受け取り、Glacierにちゃんとバックアップされているファイルの情報を保存する アーカイブ取得
大した話ではないが、Refinementsについてちょっと実験してみたので、結果をまとめておく。 まず、現状のRefinementsについて整理する。 今のRefinementsはファイルスコープという、微妙に分かりづらいスコープで適用される。とりあえずサンプルコードで確認してみる # str_refine.rb module StrRefine refine String do def hoge "str_hoge" + " " + fuga end def fuga "str_fuga" end end end # main.rb require_relative "str_refine" using StrRefine p "".hoge # => "str_hoge str_fuga" refineとusingはRefinementSpecによるとModule#refineメソッド
久々にブログ書く。 何気なくbundle updateをしたらcapybaraが2.1.0になってて、テストが落ちるようになった。 また挙動が変わったらしいので、ググって確認してみる。 Introducing Capybara 2.1を参照すると大体分かるけど、一応日本語でざっくり書いておく。 セレクタによるマッチの厳密性が変更になった capybara2.0から、findメソッドでDOMを探した時に複数マッチすると例外を吐くようになったが、 2.1.0からはマッチングのルールをconfigureで指定できるようになった。 Capybara.configure do |config| config.match = :prefer_exact end マッチングの種類は以下の四つ :one :first :prefer_exact :smart :one 2.0と同じルール。複数マッチすると
次のページ
このページを最初にブックマークしてみませんか?
『joker1007’s diary』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く