その文明はわりと現役です(「女子高生プログラマーの大バトル!〜コボール文明の逆襲〜」を解いた件)
いやまあ、別にこのBlogはPOHの結果を貼るためのものではなく、
前回から今回までの間にLTをやったりはしていたのですが、
仕事がなかなか忙しくてですね・・・(´-ω-)
さすがに新しい仕事に移って半年だと、
Blogで書けるような新しいネタも少なくて・・・
まあ、LTのネタを書き忘れていたのは単なる怠慢ですが
それはさておき、6回目です
前回が4月なので、約半年ぶり・・・って、そんなに経ってましたか(lll゚Д゚)
4回目くらいで難易度が下がりはじめ、
5回目でパフォーマンスを気にしなくてもいいレベルまで下がってましたが、
今回はさらに下がっていた気がしますΣ(゚Д゚)ガーン
(仕事が忙しくて)着手がだいぶ遅くなり、
今ならもう皆さん解いているはずなので、
今回は答えを本文に書いてしまいます...φ(・ω・`)
緑川つばめの問題
https://paiza.jp/poh/joshibato/tsubame
難易度の表示とか何もなく、実際は「霧島->緑川->六村」の順で解いたのですが、
Blogでは簡単な順に書きます
・・・とはいえ、この1問目はあまりに簡単すぎますΣ(・ω・ノ)ノ
「プロのプログラマ」がこの問題を一瞬で解けない場合、
「貴様、普段全くコードを書いてないどころか、まともに書いたことないな?щ(゚Д゚щ)」
と疑われるレベルでしょう
(逆に、あまりに単純すぎて、何か罠があるのでは・・・と疑ったくらいで)
ただですね・・・「転職支援サイト」で、
このレベルの問題を「最低ライン」として提示しているということ自体、
「プログラムを書けない人」の転職が増えているのかな・・・とも思います(´-ω-)
正直、残すほどのコードではないですが、一応こんな感じで
https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-tsubame-rb
六村リオの問題
https://paiza.jp/poh/joshibato/rio
さすがに多少難易度が上がりましたが、ご丁寧にも詳細な計算式が提示されているため、
ただその仕様を実装するだけのお仕事です(´・ω・`)
ただ、「小数」を扱う関係上、数値の取り扱いを間違えると誤差が出ます
私も手抜きしたら通りませんでしたし
https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-rio-rb
厳密にいえば、きちっと精度を確認し、
BigDecimalやRationalを検討すべきなのかもしれませんが、
今回はFloatで問題なかったのでこれで
さすがにFloatの方が速いですしね・・・ *1
ただ、誤差で思いもよらぬバグを生み出すこともありますが(´-ω-) *2
霧島京子の問題
https://paiza.jp/poh/joshibato/kirishima
今回のメイン・・・ですが、これも前回よりは簡単な気がします
わりと力技で通ってしまい、アルゴリズム的な小技が不要なので
この問題はとにかく「問題を理解すること」が重要で、
その上で「文章をコードに落とし込めるか?」がポイントであり、
あとはせいぜい効率化を考えるくらいでしょう
ルールに従い、順番に盤面をparseしていって、
ゴールにたどり着けば「Yes」、止まるか外に出たら「No」、
ここまではすぐ思いつくレベルです(効率はともかくとして)
問題は「循環して止まらない場合」です
これを排除できないと、単にparseしていくだけでは終わらなくなります(lll゚Д゚)
要は、「一度通ったところを再度踏むと循環する」ということなので、
通った場所を記憶しておいて、また踏んだら「No」と考えればOKかと
そして効率化ですが、当初は盤面をあらかじめ逆にparseしておき、
「数値が来た時点でO(1)の計算量」的なものを目論んでおりました
ただ、実際は盤面のサイズが大きくなるほど、
無駄な計算が多くなる可能性が高く、コードも複雑化しそうだったので、
単純に「一度計算した結果を覚えておく」程度にしました(´-ω-)
https://gist.github.com/parrot-studio/8fae30021b17177d4ba4#file-kirishima-rb
たぶん、名前のついたもっとうまいアルゴリズムとかあるのだと思いますが、
今回はこれでも0.1秒を切ってますし、気にしない方向で( ゚Д゚)y─~~
まとめ
ということでざっと見てきましたが、
2〜3回目くらいの「TestCase5が通らないのぉぉぉぉっ!(つД`)・゚・。」
みたいな難易度からはすっかり遠ざかった印象です
前回のおまけ問題がそれに近いのかもしれませんが、
あれはあれでガチすぎて手を出す前にあきらめる問題だったので、
「なんとなく手を出したら深淵が待っていた」くらいのが個人的な好みです
まあ、そういう問題を出されると、
一週間くらいはその問題のことで頭がいっぱいになるので、
仕事が進まなくなるのですが・・・Σ(・ω・ノ)ノ
*2: つい先日、Floatの誤差でバグが出まして、原因がわからずに数時間つぶれたこともΣ(゚Д゚)ガーン ロジカルなレベルでは間違いがなく、特定の値が来るとおかしくなるってのは、実にデバッグが難しく・・・
幼なじみと許嫁が修羅場らしいが、それなら両方手に入れればいいじゃない
ということで、5回目です(`・ω・´)
いつもだと・・・
問題を読む -> 仕様通りに書く -> サンプル通りの出力になるか確認する ->
いったんサイトで実行してみる -> 途中で落ちる -> リファクタリングしてみる ->
小手先の修正では通らない -> 奇抜な方法を試す -> サンプルの出力すら出なくなる ->
煮詰まって悩む -> いったん寝る -> ヒントになりそうなアルゴリズムを探す ->
いまいちいいのがない -> でも調べるうちになんとなく見える ->
書き直してみる -> あれ、もうちょっとで通るやん? -> 直す -> ∠( ゚д゚)/
・・・というプロセスを経由してクリアしております(´・ω・`)
なので、過去の記事においては、
「どう試行錯誤したか?」をまとめているわけです
しかし、今回はですね・・・
問題を読む -> 仕様通りに書く-> 先回りして罠を回避する ->
サンプル通りの出力になるか確認する -> いったんサイトで実行してみる -> 通ったΣ(゚Д゚)ガーン
・・・ということで、一発で通ってしまいまして(; д ) ゚ ゚
なので、そもそも今回の問題が(いつもに比べて)簡単という可能性もあります
実際、もっと高難易度な問題は別に用意されてますし
とはいえ、過去の問題の傾向から、
ここを押さえればいけるというポイントがわかっていたのも事実で、
今回は「何を考えたか?」を中心にいろいろ書いてみます...φ(・ω・`)
なお、私の回答は「おまけ」にて
1問目
見た瞬間解けないと・・・とまでは言いませんが、最近のWeb企業を受ける場合、
このような問題を面接で出される可能性はある*1ため、
できれば5分、最低でも15分くらいで解き方を思いつかないと(゚д゚)マズーです
なお、問題文では「ODD」といってますが、
たいていの言語において、配列は0-originなので、
実際のコードでは「EVEN」というのが罠と言えば罠でしょうか
2問目
「周期性のあるものは割った余りを見ろ」ってミルカさん*2が言ってたΣ(・ω・ノ)ノ
この問題は実際の業務でもありそうな話であり、
効率の良いコードとまではいかなくても、全く書けないというのは問題です
3問目:レナルート
先に解いたのはアイドルの許嫁でしたが、
ぶっちゃけ話をきちっと読んでなかったので、
先に目に入った方を解いたという・・・Σ(゚Д゚)ガーン
Excelのような表にあらかじめ値が入っており、
あとから複数指定される領域を結合した領域に含まれる値の合計、
といった問題でございます
ポイントはもちろん「領域には重複があること」であり、
素直に解くならば、まず「領域がどんな形になるか?」を組み立て、
元の表をparseして領域に含まれるかを判定して足す・・・という感じでしょうか
でも、これだと「領域を組み立てる」ので一度parseし、
「合計を算出する」段階でもう一度parseするわけで、
過去の問題だとこのやり方で100点は無理です(´・ω・`)
「読み込み(gets)しながら問題を解く」というのが理想であり、
「最初の表を読み込む」のは仕方ないにしても、
「領域の読み込みと計算」は同時に進めたいところです
要は、「再度読み込まれても値が加算されない」なら良いわけで、
しかも求められているのは「合計」だけです
なので、「一度読んだ領域を0で上書き」すれば、何度読んでもOKです(`・ω・´)
ついでに、素直にデータ構造を組むとHashとか使いたくなりますが、
これも過去の経験から「Arrayのindexアクセスが速い」とわかっていたので、
データをただの配列で保持し、x/y座標からindexを算出する方法を取っています
あと、きっちり問題を読むと、
表領域に対し指定領域のindexが異様に大きいような気がしたので、
一応足切りを入れていますが、どの程度効果があったかは不明です(´-ω-)
<結果>
3問目:ミナミルート
レナルートは業務寄りの問題なので、実行効率はともかく、
全く書けないってことはないと思うのですが、
ミナミルートは「まんま書く」をやろうとして詰む可能性はあります(lll゚Д゚)
いわゆる「落ちものパズル」の話で、
火のついた爆弾が消えると、上にあった爆弾が「落下する」という条件で、
最終的にどんな盤面になるかを出力せよ、という問題です
状態が「空=0」「普通の爆弾=1」「火のついた爆弾=2」と3つあり、
しかも「落下する」ということは「下に何があるか?」を考えなければならず、
普通に解こうとすると結構悩ましい問題です(´-ω-)
しかし、冷静に「出力結果」を見ていただきたいのです
出力するのは「0か1」であり、「火のついた爆弾=2」はどうせ消えるので、
考えなくていいわけです
しかも、「落下する」と考えるから混乱するわけで、
「落下したあとどうなっているか?」を考えると、
「各列ごとに爆弾がいくつ残るか?」がわかればいいわけです(`・ω・´)
つまり、最初の盤面をparseしながら、「各列ごとに1の数をカウント」し、
出力する時にその値に応じた行を出力していけばいいわけです
結果的に、ミナミルートの方が圧倒的に簡単なコードになります
強いていえば、出力時は「盤面の上から」であり、
「下から積み上げ」ではないので、1か0かの判定が多少混乱しますが、
サンプル出力になるように適当にいじればどうにか・・・Σ(・ω・ノ)ノ
(なお、この問題ではカウンターにHashを使っていて、
「そこはArrayじゃないのか?щ(゚Д゚щ)」と突っ込みを受けそうですが、
ええやん、それでも100点だし、直すのめんどいし
そもそも、普段の業務なら迷わずHash.new(0)にしているのもあって・・・)
<結果>
まとめ
過去の問題で学んだチューニングポイントがこちら(´・ω・)っ
- parseやループ回数をとにかく減らす
- 細かなチューニングよりも圧倒的に重要
- 盤面を保持するデータ構造はできるだけ簡潔に
- 複雑な構造を使おうとしている時点で、解き方がおかしいと考える
- 簡単に足切りできそうなら切る
- 結果さえあっていればいいので、過程はどうでもいい
- 結果から逆算して、求められている計算手法を予測する
この辺がわかっていたので、今回は一発でしたが、
やはり本命はSP問題の方でしょう
・・・時間がないのでやりませんがΣ(・ω・ノ)ノ
とあるプログラマの転職記録
別なBlogでそれっぽいことを書きまくっているので今さらですが、
3月から新しい会社で仕事をしております(`・ω・´)
ギリギリまで引き継ぎをしていたため、相当に有休が余りまくりでしたが、
技術者は私一人でしたので、「あとはよろしく」ってわけにも・・・
(在籍中の後半は別なグループ会社の仕事を主にしてました)
で、この手の記事にありがちな「前の会社の実績」とか、
「新しい会社でやること」とか、
私のような無名の技術者の場合はどうでもいいですよね?
むしろ、「私が(読者ならば)知りたいこと」は、
具体的な転職の経緯とかノウハウだと思うので、
その辺をメモしておこうかと...φ(・ω・`)
転職のきっかけ
今までの転職はほぼ仕事への不満100%でしたが、
以前の職場は楽で給料も良かったので、
その意味での不満はありませんでした
ただ、「世間一般の会社」がやっていることに対し、
どんどん遅れていっていることが不安になりまして(´-ω-)
それでも十分な利益が上がっているので、
会社としては問題ないのかもしれませんが、
私個人のレベルではちょっとな・・・と
他に稼げる手段もないので、エンジニアとして一生食っていくという覚悟でやってますが、
基本的な部分でめんどくさがりなので、
過剰なコストを払って「一流」*1になる気はありませんc(・ω・`c )っ *2
ただ、「いざ仕事を探す時に、選択肢がない状況」にはしたくないので、
そのギリギリのラインは維持できるようにと考えていて、
そろそろそれを下回るな・・・というあせりがあったのです
いくらプライベートでいろいろ作っていたとしても、
やはり実務実績がないと説得力に欠けるわけで、
「今の世間一般的な経験」を積む必要があるだろうと
まあ、それでも元の会社が楽なのは事実で、
年齢で面接に通らない可能性も十分にあったので、
元の会社に残る選択肢を残しつつの転職活動でした
ただし、この「技術者としての理由」は半分で、
「プライベートな理由」もかなり大きいのですが、
それはきっかけになった本だけ紹介するに留めます(´・ω・)っ
- 作者: ロースおじさん
- 出版社/メーカー: 一迅社
- 発売日: 2014/08/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- 作者: 二村ヒトシ,青木光恵
- 出版社/メーカー: イースト・プレス
- 発売日: 2012/12/02
- メディア: 文庫
- 購入: 7人 クリック: 125回
- この商品を含むブログ (31件) を見る
エージェントの紹介と書類選考
転職を決める1年前、最近の流れを見るため、
転職エージェントに会って情報を流してもらっていたのですが、
本気で転職すると伝えて仕切り直したのが10月末です
過去の転職でも、特に理由がない限りは転職エージェントを利用しています
企業のHPで募集をしてないって場合でも、
エージェント経由だときっちり募集していたりしますし、
なにより各種調整を代行してくれるってのがとても楽です
書類の提出から面接日程の調整はもちろん、
入社前の条件調整とか、お断りの連絡とか、全部代行してくれます
業務と並行で転職活動をするならとても便利だと思います(`・ω・´) b
もちろん、入りたい会社が最初から決まっているとか、
誰かに誘われたから転職するって場合は不要です
あくまで「漠然とどこかに行きたい」という場合に利用するものです*3
で、早速まとまった数の企業を紹介してもらいまして、
各企業について個人的にじっくり調べまくり、
書類を出し始めたのが11月の頭でした
紹介されたのは流行のゲーム系と普通の業務系で半々くらいで、
この時点ではどちらとも決めていなかったので、
単純に企業情報を調べて「良さそうなところ」に出してみました*4
あと、ずっと前から目をつけていた会社の求人も、
エージェント会社のDBにあったので、
こちらも個人的な興味で出してみました
まあ、最終的に入ったのがそこなのですが・・・Σ(・ω・ノ)ノ
面接のもろもろ
書類を出した時点では、「そこそこの数通るやろ」と油断していたのですが、
予想以上の数蹴られまくったので、相当にあせりましたΣ(゚Д゚;≡;゚д゚)
スキル的には十分だとしても、年齢や希望年収*5で折り合わないケースが思ったより多く、
逆に面接にこぎ着けたのは「年齢よりもスキル重視」の会社だと思ってます
実際、どの面接でも私のBlogやGitHubのリポジトリを「その場で」チェックしてました
「普段Rubyを書いているようですが、C#は触ったことありますか?」という質問に、
「書いたことがあります」と答えるのと、
「書いたことがあり、GitHubにコードがあります」では、全く印象が違いますからね
もちろん、どんな雑なものでもUPしておけばいいってものではありませんが、
普段からいろいろ書いておくのは有利に働くはずです(`・ω・´)
それに、最近の会社でgitを使わないってことはほぼないはずで、
GitHubにコードがあるということは、
最低限の使い方を知っているという証明にもなります
あとはやはり、過去にやったLTの資料とかも役に立ちました*6
あれの話をしつつ、ほとんど雑談のように面接が進んだ会社もあります
一方で、最初に面接を受けた会社は、私自身の心構えも十分でなく、
聞かれて当然の質問にあせって真っ白になるという事態に陥りまして(lll゚Д゚)
他にも鋭い質問が飛びまくり、これはやばいと思ったものの、
後半うまく取り戻したおかげで、その面接は突破したのですが・・・
面接が終わった後、今の人が「社長」だと教えられましたΣ(゚Д゚)ガーン
他の面接に比べると、これが最初にして最大の難関でしたが、
この会社は先ほども書いた「前から興味のあった会社」であり、
面接の翌日には内定をいただき、結果的にその会社に入っております
選考プロセスの違いについて
会社によって選考プロセスが違うため、
先ほどのように1回の面接で内定が出る会社もあれば、
Webテスト等々を経由してやっと面接、という会社も少なくありません
規模の大きい会社ほどプロセスが長いため、
結果的にある会社の一次面接が、
最初に内定が出た会社の回答期限前日って状況だったりもΣ(゚Д゚)ガーン
書類を出す順番を考えるべきだった気がしますが、
かといって出すのが遅れて募集が終わってしまってもあれですし、
こればっかりは巡り合わせとしか・・・
規模の違う会社を同時に志望する場合、
書類を出す順番をある程度調整した方がいいかもしれません
会社を決めた基準
最初に面接を受けた会社から内定が出て、
その回答期限が11月末だったのですが、その段階で私はこのような状況でした
- 内定:2社
- 1次面接突破:2社
- 1次面接待ち:1社
このうち、4社がゲーム関連で、1社がWebサービスの会社です
他にもWebサービスの会社はいろいろ出したのですが、
ここ以外は全部書類で蹴られましたΣ(゚Д゚)ガーン
で、個人的に悩んでいたのが、内定を取った2社(A/B社)と、
まだ面接が先の1社(以下C社)の3社でした
C社のゲームはめちゃくちゃはまっていたのもあり、
入れるなら本気で入りたいと思ってはいたものの、
実際にどのような業務でスキルを生かせるのかが不明確でした
一方、A社は「ゲームプログラマ」としての採用であり、
B社は技術面で有名で、やはりゲームのプロジェクトで採用の予定でした
しかも、どちらの会社もメインの言語がRubyでした
相当に悩んだ結果、A社とB社については、
ゲームの内容で決めることにしまして、実際にプレイしてみた結果、
私好みのゲームを作っていたA社を選択しました
仕事とプライベートは切り離していますが、
どうせ作るなら自分でもやりたいと思うゲームがいいですからね
B社ゲームはどちらかというと「普通の人向け」だったので
問題はまだ面接してないC社ですが、
面接前に「ゲームプログラマの採用か否か?」という基準を決めました
C社の面接ではゲームへの愛を相当に語りまくりまして、
またそういう人が好きな会社であることもわかっていたわけですが、
だからこそ、ゲームそのものの要求技術レベルが高いのもまた事実です
面接の中で「採用するとしたらどのようなポジションか?」と聞いたところ、
やはりバックエンド周りとのことで、仕方なく今回はあきらめました(´・ω・`)
もし、A社の回答期限までにC社の内定が出ていれば、
相当に悩んだと思うし、C社を選んだ可能性も十分にあったのですが、
こればっかりはタイミングですかね・・・
実際に入社してみて
ということで、12月頭には入社が決まっていたのですが、
元の会社の引き継ぎに時間がかかることがわかっていたため、
2月いっぱいまで待ってもらいまして、3月から入社しております(`・ω・´)
1週間過ごしてみての感想は、良くも悪くも「想定した通り」であり、
やはり事前に細かく調べておいたのは正解だったな・・・と
その他、もっと細かいもろもろは、
今月末開催の「NetGamers.dev.talk」あたりで聞いてください(´・ω・)っ
*1: GoogleとかAmazonとか、外資系に入れちゃうレベルの実力
*2: 別に「有名な会社」に入れば幸せとは思ってないので・・・
*3: 余談ですが、一応知りあい経由で打診されたことはあるのですが、一度目は全く転職を考えておらず、二度目は新しい会社の入社直前でしたΣ(・ω・ノ)ノ これもまたタイミングですかね・・・
*4: あとは、スキルセットが合わないのを承知で、「普段お世話になっている会社」にも出しましたが、予想通り書類で蹴られました(´・ω・`)
*5: といっても、前の会社の1割以上減で提示したのですが、それだけ前の会社がゆるいってことかもしれません
*6: やはり関数型のあれは評価されました http://www.slideshare.net/parrotstudio/gunmaweb-5-20110514
モバイルブラウザでクリックの動作が遅い問題の対応(改善編)
相変わらず開発を続けている「チェンクロパーティーシミュレーター」ですが・・・
Get our light! - チェンクロパーティーシミュレーター
・・・昨年末に「部分的でもいいからスマフォ対応が欲しい」という要望をいただきまして
「パーティーを編集する仕組み」として考えると、
スマフォの狭い画面ではいろいろ設計が面倒なのですが、
「データを見るだけ」であれば、専用の画面を作ればいけるかなと
「データを見るだけモード」は元々ToDoに入れて放置していたのですが、
今回の要望とあわせ、イメージが湧いたので、
現在ごりごりと実装しております...φ(・ω・`)
まあ、裏のAPIは同じでViewを差しかえるだけですので、
大雑把なプロトタイプはすぐに完成し、
試しにサーバに突っ込んで実機テストしてみたのですが・・・
・・・いろいろ動作が怪しすぎて、使い物になりませんでした(´・ω・`)
どうもクリック周りの動作が怪しいのです
最初の2回くらいはまともなのですが、
そのうちイベントが取れなくなり、最後には固まるという・・・
そもそも、タブレットで動作させた時にも、
クリック周りで怪しい動きがあったのですが、
見なかったことにしていたんですよね・・・Σ(・ω・ノ)ノ
今回はそういうわけにいかないので、いろいろ調査してみたところ、
たぶん「Hammer.js」が原因、というところに行き着きました
そもそもこのライブラリをなんで使ったのかというと、
タブレットのブラウザでクリック動作が遅かったからなのです
「チェンクロパーティーシミュレーター」を公開しました - ぱろっと・すたじお
Hammer.jsはいろいろなイベントを実装する上で、
クリックの動作も改善していたわけですが、
「汎用的にいろいろ作り込まれていて、影響が大きい」のも事実です
最初のうちはHammer.jsでいろいろやろうとしていたのですが、
今使っているのは結果的に「クリックの反応速度改善」だけであり、
もっと軽いのはないのか・・・と調べ始めました
そして見つけたのがこちらです(´・ω・)っ
JavaScript - FastClickを使った体感応答時間の短縮テスト - Qiita
その名の通り、クリック速度の改善に特化されており、
ライブラリもシンプルで、組み込みやすくなってます
しかも、Hammer.jsと違い、イベントの記述は一般的な
「$(hoge).on 'click'」とかでよく、コードもシンプルで良いです(`・ω・´) b
とはいえ、やはりイベントに割り込んで動作するライブラリのため、
他のライブラリ(盲点なレベルだとBootstrap)等と、
競合しておかしくなる可能性は十分にあります
当たり前のことですが、動作確認はしっかりと(´-ω-)
・・・とまあ、これで終わってもいいのですが、
今回の話には落ちがありまして
サーバに改善版をUPし、実機でテストしてもOKだったので安心していたら、
コードに記述漏れがあり、ライブラリは読み込んでいたけど、
イベントは適用されてない状態でしたΣ(゚Д゚)ガーン
でも、実機でテストしたときにクリックの違和感はなかったわけです
だとすると、元々私が「遅い」と感じたクリックはどこへ・・・
という疑問が湧きます
私のスマフォはAndroidで、ブラウザはChromeですので、
先ほどの実験記事にある「対策済み」のパターンに該当しますし、
元々スマフォでは「編集できない」という表示テストしかしてません
しかし、タブレットはiPad miniで、OSは7で留めてますので、
Safariのバージョンはリリース当初と変わってないはずなんですよね・・・
・・・まあ、今まともに動いているからいいかΣ(・ω・ノ)ノ
「Rubyのしくみ」 "10.times do"から始まる冒険
お正月って、あらゆる気力を奪われる時期なわけですよ
長期休みって意味では夏休みも変わらないはずなのに、
世間の空気感も含めて、全力で怠惰になるというか、
ゲームをやる気力すら削がれるというかc(・ω・`c )っ
そのうち布団から出るのすら面倒になり、
布団の中で積んでいた漫画を崩した結果、読むものがなくなり、
ついに積んでいた技術書を崩し始める・・・そんな時期なのでございます
・・・というのがどこまで本当かはともかくとして、
お正月にだらだらと読んでいた本がこちらに(´・ω・)っ
Rubyのしくみ -Ruby Under a Microscope-
- 作者: Pat Shaughnessy,島田浩二,角谷信太郎
- 出版社/メーカー: オーム社
- 発売日: 2014/11/29
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
Rubyist Magazine - 書籍紹介『Rubyのしくみ Ruby Under a Microscope』
「プログラム(言語)とは、結局のところメモリの書き換えである」と、
某セガの方もおっしゃっていましたが・・・
プログラムはこうして作られる―プログラマの頭の中をのぞいてみよう
- 作者: 平山尚
- 出版社/メーカー: 秀和システム
- 発売日: 2013/09
- メディア: 単行本
- この商品を含むブログ (5件) を見る
「プログラミングを教える」ということ - ぱろっと・すたじお
・・・「言語がどのようにメモリを使っているか?」は、
言語を深く理解する上では重要な概念ですし、
少なくともパフォーマンスチューニングにおいては必須です*1
実際、新人時代からJavaを書いていたものの、
「感覚的に理解した」のはこちらの本を読んだときです
Java 謎+落とし穴 徹底解明 (標準プログラマーズライブラリ)
- 作者: 前橋和弥
- 出版社/メーカー: 技術評論社
- 発売日: 2001/12/01
- メディア: 大型本
- 購入: 8人 クリック: 40回
- この商品を含むブログ (21件) を見る
この本もJavaのメモリ管理について解説されており、
「参照」とは何なのか、GCは何をしているのかが理解できまして、
それ以降ぬるぽ*2を作り込むことが圧倒的に減りました( ゚д゚)o彡゚
その後、Javaを離れてRubyを書き始めたときも、
最初のうちはJavaっぽいコードを書いていたものの、
本質的にRubyっぽいコードに近づき始めたのは、こちらを読んだときです
Rubyソースコード完全解説
http://i.loveruby.net/ja/rhg/book/
この本・・・というかサイト(RHGと略すらしい)は有名でして、
Rubyを深く知りたい方はたいてい目を通しているはずですが、
どうにも解説しているバージョンが古い、という問題がありました(´-ω-)
その「RHGの現代版」と言えるのが先ほどの本でして、
本質的な狙いはほぼ同じです
とはいえ、私自身はC言語に明るいわけではなく、
Brainf**kの評価器を作れる程度の知識*3はあっても、
正直YARVの解説は難しすぎて、完全に理解することはできません(´・ω・`)
とはいえ、表面的にでも「何をしたいのか?」は読み取れますし、
5章以降のオブジェクトに始まる一連の話は、
C言語の細かい知識がなくても十分にわかります
Rubyにおいて全てがオブジェクト=メモリの束で管理されているなら、
オブジェクトの構造が理解できれば、Rubyの本質的な部分が、
かなりのレベルで見えてくるんじゃないかと(`・ω・´) *4
そもそもRuby自体(おそらくはLisp等と同じく)、
「概念」とか「理想」がまずあって、それを「実装」している感じで、
その「概念」自体はわりとシンプルで合理的なわけです*5
つまり、「何に使うか?」という「目的」ではなく、
「こういう言語にしたい」という「理想」が起点だと思っているので、
そのあたりの「意図」を読み取れれば、後は応用なのかな・・・と思います
逆に、「概念」や「理想」が先行しているからこそ、
JRubyやRubiniusのような他の処理系も存在できるわけで、
そのあたりの解説も面白いものになってます
「黒魔術」と言われがちなRubyが、
実際のところ「合理性の塊」であることがよくわかるという意味でも、
この本は面白いですし、おすすめします・・・が・・・
・・・やっぱり難しい本だと思います、ええ(´-ω-)