タグ

ブックマーク / udzura.hatenablog.jp (18)

  • メモリの上に置かれているRubyの文字列を覗く - ローファイ日記

    これもフィヨルドブートキャンプの生徒さんの質問からふと思いついた、ちょっとした遊びですが。 (そして、書いてある内容に誤解があったら優しく教えてください) p Object.new => #<Object:0x000055959ddf1910> Rubyのオブジェクトのinspect表示のデフォルトで出てくる、この16進数は、このオブジェクトが置かれているメモリアドレスのことだと知られている。 では、実際にこのメモリアドレスにオブジェクトが置かれていることを確かめるには? さて、以下のコードはLinuxで動かすことにする。 String オブジェクトで試してみる。と言っても、StringのinspectはObjectに定義されたものではなく、自分のクラスで定義しているので、まずはそれを「無効にする」。以下のような方法で Object#inspect を呼ぶように変更できる。 class S

    メモリの上に置かれているRubyの文字列を覗く - ローファイ日記
  • コンテナと人間の一ヶ月 - ローファイ日記

    ブログ、一ヶ月ぶりのようです。 @udzura です。ところでみなさんはコンテナですよね? そういう感じです。 ここ最近のアウトプットをまとめたりしておきます。先に行っておきますがどれもLinuxコンテナの話です。 6月半ばに、第11回 コンテナ型仮想化の情報交換会@大阪 にお呼びいただいて、話してきました。なぜか一時間話しました。 ct-study.connpass.com 割とこの時点での自分がHaconiwaとFastContainerでやってきたことの集大成を出せたみたいな感じで、なおかつ日のオルタナティヴ・ロックの話ができたので良かったです。お呼びいただいた、 @TenForward さんに感謝です。 speakerdeck.com そろそろ numbergirl って名前のミドルウェアを書こうと思います。 コンテナ勉強会は、質問も前向きかつ深いものが多くて、また各社の現場のL

    コンテナと人間の一ヶ月 - ローファイ日記
  • 私のロールモデル: エンジニア立ち居振舞い番外編 - ローファイ日記

    お題「エンジニア立ち居振舞い」 pepabo Advent Calendar 2016 24日目の記事です。 割と飲みの席とか、某ポエムサービスでは語ってはいるんですが、そういえばブログで書いたことがないような気がしたので父の話をします。 実は今年の福岡での新卒研修で同じような話を若者にしていて、でもまあ、あまりに個人の話なのでとスライドも公開していなかったのですが、せっかくなので内容を加えて書き下します。 僕の父は欄間職人をやっていて、6X歳を超えるいまも自営で東三河の片隅に店を持ってやっていってるわけだけど、僕は子どもの頃からそういう背中を見て育ってきたからか、今の自分を振り返ってみると随分自分の仕事ぶりが影響を受けているなと思ったりする。 今日は、6X歳のいまも職人の父を見ていて思ったこと、あるいは直接言われたことなどいくつかをしたためてみる。 生涯、勉強すること これは僕の父の仕事

    私のロールモデル: エンジニア立ち居振舞い番外編 - ローファイ日記
  • ソフトウェアをリプレースする前に考える三つのこと - ローファイ日記

    個人的には三つの基準があるという話。 そのソフトウェアが十分に古く、十分長い間保守されていないか そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか 1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。 ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。 例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。 開発者が退職してしまった Hoge言語に関するドキュメントが全然なくて学習が困難 という感じであればリプレースは検討に入れていいかもしれない。 しかし、こ

    ソフトウェアをリプレースする前に考える三つのこと - ローファイ日記
  • Rubyで別のコマンドをラップしたい時、ptyライブラリが便利 - ローファイ日記

    library pty (Ruby 2.2.0) pty とは、擬似端末(Pseudo tTY)を扱うライブラリ。 典型的には以下のように使う。 require 'pty' status = nil PTY.spawn("for i in $(seq 1 10); do echo progress $i; sleep 1; done") do |pty_out, pty_in, pid| pty_in.close while l = pty_out.gets puts "PTY: #{l}" end status = PTY.check pid end # PTY: progress 1 # PTY: progress 2 # PTY: progress 3 # ... # PTY: progress 10 #=> nil p status #=> #<Process::Status: p

    Rubyで別のコマンドをラップしたい時、ptyライブラリが便利 - ローファイ日記
  • イメージベースのデプロイについて(あるいはIaaSだとこんなんが良いんじゃないと言う意見) - ローファイ日記

    最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである

    イメージベースのデプロイについて(あるいはIaaSだとこんなんが良いんじゃないと言う意見) - ローファイ日記
  • 「それでもRailsを選択する3つの理由」を読んだ - ローファイ日記

    http://ppworks.hatenablog.jp/entry/2015/02/19/223552 ほぼほぼ同意なのですが、フームと思って(ppworksさんプロダクトだから、ということでもないが)ポエムをしたためた。 でもなんかこれをあえてポエムにとどめないで書いたらどういう反応があるかな〜と思ったのでブログにも転載してみよう。 規約縛りの哲学 これは文句なくその通りだと思っていて、Rails以外のフレームワークではこれらの実現が非常に中途半端であると言う印象を持っている。 サービス作りにおいて技術選定やら何やらからの議論をしていてはリリースは当然遅くなるし、あまりしたくないということである。議論するならもっとユーザに近い、正体のよく分からない不安点(このアプリほんとにユーザに受けるの? とか)に関してすべき。 議論は一般的に良いことのように思われているが凄い体力を使うし、当に必

    「それでもRailsを選択する3つの理由」を読んだ - ローファイ日記
  • 東京はもう古い、これからは福岡 - ローファイ日記

    タイトルは言ってみただけだが、若干の補足をする。 元ネタ: 東京はもう古い、これからは京都 - ゆううきブログ とりあえず現在、天神と言うデパートが3軒とパルコその他と12軒程度のスターバックスがある都市の徒歩圏内に3LDKを借りて住んでいるが、非常にQoL高い感じはする。博多という阪急百貨店と新幹線がある駅にもすぐ出られる。 この条件だとインターネット情報では平均13万とか出てくるが、11万ぐらいであると思う。 あと僕はぶっちゃけ魚嫌いだったんだが好きになった。玄界灘はやばい感じがする。 米、鶏牛豚、魚、野菜など、日常の事に必要な材は実はほとんど九州島だけでまかなえるからか、とにかく国産の材がとんでもなくリーズナブルに手に入ってうまい。 福岡に住んでまだ一年なのでおすすめの店は地元民の紹介に譲るが、ベースの材がおいしい。後は分かっていただけるかと思う。大名、赤坂などの地域には隠れ

    東京はもう古い、これからは福岡 - ローファイ日記
  • Railsバージョンアップ大変じゃんへの違和感 - ローファイ日記

    当該の件夜中に色々考えたら ロードマップ指向とエコシステム指向 - アンカテ という話である程度説明できるんかな〜と思った。で、求めてるものが違うんで議論にならないのも仕方ないな〜と言う。 なんかまあ、まず普通に 結局ちゃんと知識を持っている人がいるフレームワークを選んで保守して行くという話で、Railsな人がいればRails、Springな人がいればSpringでいいのでは。どっちかと言うと自分で選んでコミュニティに貢献して寿命延ばすみたいなほうが前向きでいいと思う— Uchio KONDO (@udzura) 2014, 8月 26 と思っていて、 その上で、Ruby on Railsは代表的なエコシステム型FLOSSなので、フレームワークとかに求めているのがただ便利とか、ただ堅牢とかだとそもそもずれが生じるよなあって思う。一時的ならともかくずっと付き合って行く前提ならなおさら。 Ra

    Railsバージョンアップ大変じゃんへの違和感 - ローファイ日記
  • 第二新卒研修をしていた - ローファイ日記

    雇用流動情報の季節ですが、いかがお過ごしでしょうか。雇用流動と間接的に関係のある記事を書きます。 標記の通り、研修をしていたのでその内容をまとめたり振り返ったりする。 思ったより長くなったぞ... 背景とか がっつりとしたWeb開発の経験は無いが、情熱があり、コミュニケーション能力など基的な能力が高そうな、年齢の若い方が応募されたので、いわゆる「第二新卒」と言う扱いで研修を前提に採用した。で、その研修のカリキュラムを主にぼくが考えて実施していた。 といっても、今までに積み上げてきた新卒向け研修のカリキュラムやノウハウを眺めてエッセンスを抜き出すみたいな感じだった。 ペパボ新卒デザイナーとエンジニアの研修ブログ ペパボ新卒エンジニアの研修を開始している - HsbtDiary(2013-05-22) ペパボ新卒エンジニア研修 前編 | blog: takahiro okumura ペパボ新

    第二新卒研修をしていた - ローファイ日記
  • Sinatra frameworkに関する私見 - ローファイ日記

    エクスキューズとか 正直な話をすると、Webフレームワーク自体に関する興味は以前に比べて失われてきているので、最新のSinatraの細かいコミットまでは追っていない。 だが、2年強ほど Sinatra/Padrino 界隈を追いかけてきて得た知見と言うか考えについてまとめるのは一定の価値がある、少なくとも自分に取っての価値は非常に大きいと思うのでここに書いていきたい。 副次的には、ミスコンセプトによってSinatraを利用して、結果必要の無いイメージの悪化を招く事態を一件でも減らせればと思う。 Sinatraはmicroframework、あるいは「フレームワークではない」 公式の説明にある通りである。 具体的にどういうことかと言うと、Sinatra単体ではウェブサービスに必要な要件を満たさないかもしれないと言う話である。Sinatraが持っていないものについては、Sinatra以外の場所

    Sinatra frameworkに関する私見 - ローファイ日記
  • 情報共有おじさん - ローファイ日記

    プロジェクト全体のMLにエラー通知メール飛ばすのうざい」、「〜についてはみんながいるチャンネルで相談すべきことではない」みたいな指摘がある。 個人的には情報は可能な限り広いスコープで公開してほしいし、自分でもそうしようとしている。まだ未熟なので霊力に負けることもあります...。 というのも、「情報が届いていない」ことによる不利は仕事上非常に大きいし、場合によって致命的になるので、むしろ冗長化して届けられているべきなのである。 あと、情報が多ければ多いほど普通は判断が適切になると思うので、情報が広く共有されていると言うことは、チームメンバー一人一人が自分で判断できる材料を持ちやすくなると言うことにもつながる。スクラムとか色々言われているけど「一人一人が自分で判断できる」ということはどういう開発スタイルでも大事だと思う。 なのでむしろみんながいる場で議論していたり、細かい情報をどんどん流して

    情報共有おじさん - ローファイ日記
  • 過去の自分を救いたいプログラマの話 - ローファイ日記

    闇 Advent Calendar 2013では、青臭い話もネガティブな話もして良いそうなので、これから小説を書きたいと思います。 ぼくはプログラマなのだが、ぼくの仕事の考えの真ん中にあるのは、実は技術的なエッジに触れているとか、あるいは給与がいいだとか、そういうことは結構どうでも良くて、たとえば孤独なチームメイトを作らないとか、業務知識を一人で抱え込むのを辞めさせるとか、一人一人に当事者意識を持ってもらうとか、そんな青臭いけど単純なことである。 ただのスクラムの影響、言われればそれまでだが、その根底にあるのは「過去の自分を救いたい」と言う感情だと思っているし、この考えの根底が作られた当時はスクラムなんかろくに読んでいなかった。 過去、とある会社に所属していたとき、辞めるまでの後半の1年ほどは当に辛くて、入社して2年ほどしかたっていないぼくが、2000年代の初めだかに誕生したレガシー

    過去の自分を救いたいプログラマの話 - ローファイ日記
  • もしぼくが採用するなら - ローファイ日記

    今後役立つ日も来るかもしれないのでメモしておく。Rubyist寄り。 CSに全く興味がない人はきつい 計算機に関する学科を出ていなければ門戸を開かないと言うのは、人不足の現実から言っても厳しいだろうが、我々の用いる道具に関する最低限の足腰は欲しい。 エラストテネスの篩を説明できるとか クイックソートの計算量のオーダは何で、それはなぜか説明できるとか サブネットマスクとは何かを説明できるとか 簡単な帳票を見せて、それをすらすら正規化できるとか 別に「たまたま知らない」とかはあり得るんだが、ポロポロ欠けていると、それまでの勉強の仕方を疑わざるを得ない感じがする。 とはいえ、Rubyistならウェッブ系と言うかサーバ寄りだろうからRDBやネットワークの知識はある場合が多い気もする(経験上身に付きやすいですよね)。でも、ぼくも割とアルゴリズムを勉強してるとかは大事だと思う。単純にいろいろな技術的ド

    もしぼくが採用するなら - ローファイ日記
  • 小さなgemの代わりにプロジェクトに含む形で機能をホストすること - ローファイ日記

    理想的には共通化できる機能は切り出してgemにすることだけれど、次の理由から標記のパターンもなくはないのかも、と思いつつある。 外部gemより、同じプロジェクトのlibに転がっていた方が、正直トラブルがあったときに追いやすい 数行で実装できるものを外部gemにするのは大仰な感想を受ける 現実問題、まだbundlerがそこまで賢くない時がある。また、gemであると依存関係を解決できない場合もある 外部gemのオーナーは我々ではなくそのgemの開発者である。よって必要十分な機能をgemが有しているとは限らない。要らないコードが邪魔をするパターンすらあり得る。といいつつむやみなforkはやっぱり不格好 正直、次に挙げる程度の機能はプロジェクトに入っていた方が小回りが利くね、という気がしている。実装のコードを思い浮かべてほしい。ホントに数行だし、ActiveSupport::Concernを使えば

    小さなgemの代わりにプロジェクトに含む形で機能をホストすること - ローファイ日記
  • 「萎える文章」の特徴 - ローファイ日記

    自戒のためのエントリ。 そして、プログラマに関する書き物についてのエントリ。 一つの文が長過ぎる 文章というものは、当たり前だがたくさんの文が機能的に連結することで成り立っている。一文が長いと、一つ一つの文の持つ役割が曖昧になる。結果的に文章全体としての意味が分かりづらくなる。もしくは、文章全体としての主張がねじれる。良いことは、無い。 短ければいいというものでもなく、役割が分かりづらい文が混入していないことが望ましい。オブジェクト指向において、あるクラスの中に全く使われていないメソッドが定義されていると、それは気持ち悪いだろう。文章の場合、より深刻かもしれない。 主語が明確でない 高等学校の授業で「古文」という科目を受けた人は多いはずだ。そして多くの人は、「なんて古文は読みづらいんだろう」と思ってきたはずである。その原因の一つは「主語が無い」ことである。彼らの文章は非常にハイコンテクスト

    「萎える文章」の特徴 - ローファイ日記
  • Rails Girls Tokyo 2nd にコーチとして参加しました - ローファイ日記

    楽しかったです(小学生)。 * * * Rails Girls というのは (女性向けのRuby\ on\ Rails勉強会).succ.merge(:internatinal => true).update(:something => :exciting) な何かです。 どんなことをしてどんな雰囲気だったかは例えばアットマークアイティ〜の太田さんの記事 (Rails Girls Tokyo レポート:キラッキラな「Ruby on Rails」の世界へ――Rails Girls 25人が集結 - @IT) などの方が良いかと思いますので、ぼくはここでは一日目はアレした、二日目は、と言う内容より、ぼくが考えたことをうだうだ書きます。簡潔に書けると良いのですが(… LISTEN on new port 今回でようやくコーチとして参加できたぼくが言うのもなんですけど、ぼくはこのムーベントは割と破

    Rails Girls Tokyo 2nd にコーチとして参加しました - ローファイ日記
  • プログラマ念能力の系統 - ローファイ日記

    個人的に勝手に考えてる奴 放出系(フロントエンドUIとかユーザ体験とかに強い。JavaScript好き。HTML/CSS、あとゲームのクライアント作る人もここに入る 強化系(アプリケーション) ビジネスロジックをコードに落とすのが好きな人。フロント〜アーキテクトまでをつなぎ込んで形にするのが好きな人。なんかRubyとかPerlとかLL系が好き。ここは割と雑多…… 変化系(アーキテクト) データベースとか構成とか設計するのが好きな人。ER図とかデプロイメント図とか図が好きな傾向がある 具現化系(インフラ) 一度デプロイされたシステムをお守りしたり改善したりチューニングしたりする。低レイヤで頑張る人もここっぽい? 特質系(QA) いわゆるテストエンジニア。良いコードとは何かを決めてそれを確実に作れるような各種環境を整備、ツッコミをしていく人たち 操作系(アジャイル・開発手法) 特に上のフロ

    プログラマ念能力の系統 - ローファイ日記
  • 1