VRを快適にやるために引越した話

はじめに

この記事はFUN(?) Advent Calendar 2019の25日目の記事です。 (本当は25日に公開する予定ですが、書く時間が取れず4日遅れとなりました…)

お前誰

FUN13期生の雨龍です。 卒業してから3年半が過ぎました。 現職はとあるSIerでエンジニアとして仕事しています。 今年の5月にチーフエンジニア、12月にテクニカルマネージャに昇進しました。出世祝いはこちらから受け付けております。

今年の私の動向

実はつい先日、12/9に引越しをしました。 転職でもなんでもありません。完全に個人的な理由で引越しました。

なぜ引越しをしたか

まぁ列挙すると…

  • 物が増え過ぎて手狭になった
  • 住んでる周りに何もなさ過ぎた
    • 徒歩3分のところにコンビニ、徒歩5分のところにスーパーしかない
    • 何をするにも自転車がないと不便
  • 物件の契約更新月が迫っていた(来年3月)

という、まぁよくある理由ばっかですが、実はもう一つ引越しを決めた大きな理由があります。

6月にVRゴーグルOculus Rift S』を購入しました。 プレイはできたのですが、あることに気付きました。

VRをするには部屋が狭過ぎる。

ということで、VRを快適にプレイしたくて今より広い部屋に引っ越すことを決意しました。

新しい部屋について

前住んでた物件は1K8畳でしたので、2畳分増えて10畳に。 間取りだとわかりにくいですが、収納も少し広さが増えてます。 (以前は収納が不足してベッド下に物置いたりしてたのですが、新しい物件はそういったことをする必要がほぼなくなりました)

部屋の様子

実際にVRをプレイするときは奥のローテーブルと座椅子辺りでやりますが、このままだと当然スペースがないので左に寄せて

こんな感じにスペース確保します。 テーブルと椅子を寄せる必要はありますが、以前はそれに加え机の横のテーブルも片付ける必要があったため、それに比べればだいぶスペース確保が楽になったうえに十分広いスペースでプレイできるようになりました。

実際にプレイすると

快適すぎる。

以前は狭くて家具に足ぶつけたりガーディアン(VRのプレイ領域設定)に引っかかりやすかったり不便でしたが新しい部屋はそういうことが少なくなりました。 ただ、最初に立つ位置は重要で、手を横に広げてもぶつからない位置に立つことで快適にプレイできました。 (今の部屋の場合、テレビに向かって立つのではなく、カーテンを背に向けて立つようにしてます)

プレイしたVRゲーの中でおすすめ2選

Robo Recall

https://xr-hub.com/archives/10812

ロボットになって敵のロボット・兵器を銃や格闘で倒しまくるゲーム。 デフォルトでピストル2本が使えるほか、敵の武器も倒せば奪える。 倒した敵・格闘技で捕まえた敵を盾にできたり、敵の銃弾を掴んで投げれたり、もうなんでもあり。

The Climb

https://www.moguravr.com/vr-the-climb-oculus-store/

ひたすら山を登るだけのゲーム。 景色のリアリティ感がすごい。頂上から見える景色が特に素晴らしい。 意外と腕が疲れるので注意。

まとめ

  • VRを快適にプレイするには広い部屋に住め

就活を採用する立場になってから振り返ってみる

はじめに

この記事はFUN Advent Calendar 2018 part 2 25日目の記事です.
初めてトリを務めさせていただきます.

お前誰

22日に書いたFUN Advent Calendar 2018の記事を見て

アジェンダ

  • 就活してた時の話
  • 採用面接官の話
  • 今の目線で就活を振り返る

この記事を書こうと思った背景

今年の11月から勤務先の会社の新卒1次面接の面接官をしています.
というのも,各部署の20-30代のエンジニアが1次面接に参加することになっていて,その中で経験年数が高いのが私しかいない,という事情がありまして…
その中でここ最近の新卒面接について思うことや就活のときこうしておけばよかったなどいろいろ感じることが出てきたのでここにまとめようかなと思います.

企業の立場でなく、あくまで個人の立場としてかいてますので,そこあたりはご理解いただきたいと思いますw

就活してた時の話

いつ頃から動き始めたか

3年次の1月頃からですね.
東京に出て1社だけ会社説明会受けたり,ワンデイインターン?に参加したり….
これを早いか遅いかとみたら,私的には遅かったと思います.
企業によるところかと思いますが,Web系のベンチャーとなると12月前に選考開始とか普通にあったので,そういった企業を志望する場合はもっと早めに動くべきだと思います.

本格的に動き始めたのは

2月下旬の大学の合同企業説明会(就活時期変更の年だったので私の時はそれくらいでした)に参加してから本格的に動き始めました.
その後,3月に東京で友人とウィークリーマンションを借りて,1ヶ月くらい東京で就活してました.
合同企業説明会・会社説明会に参加したり,書類選考の通ったものは随時1次面接も受けたり.
選考を進めてた会社が多くなって3月中旬で一旦説明会行くのをストップしましたが,これはよくなかったですね.

どのような企業を選んでいたか

Web系の自社サービスをやっているところを中心に.ゲーム作ってるところや一部SIerとかも.
この頃はあまり企業選びの軸が定まっていなくて,「技術に強い会社に勤めたい」という漠然としたものしか考えてませんでした.
これが↓のような状況になる引き金になるわけですが…

しかし

3月くらいから選考を進めていた企業は結果的に全部落ちました.
書類選考で落とされた企業も何社かありましたが,割と1次面接ないし2次面接まで通ったものもありました.
1次で落ちたのはそこまで凹まなかったけど2次で落とされた企業は結構ショックが大きかったです.
敗因はほぼほぼわかってて,『企業選びの軸』をきちんと決めてなかったことにあったのかなと.
面接でも何やりたいのかがわからない,といった感じの雰囲気が強かったので,そこが大きなミスというか,失敗の要因だったのかなと思います.

今の勤務先に出会ったのは

4月の中旬.大学に個別説明会として来てた時ですね.
SIerですが,技術レベルが高そうなのと,この頃から軸を考え始めたところ,合ってそうな雰囲気がしたので,そのまま採用試験を受けることに.

そして

5月中旬くらいに東京にて採用試験を受けて,無事内定.
もう少し他の企業を見ても良いかなという気もしたのですが,もう大分選び尽くした感があったので内定承諾を受けて今に至ります.

採用面接官の話

3年経った今,1次面接の採用面接官に関わることになりました.
基本的に新卒がメインですが,たまに中途面接も.
今年の11月から加わって既に5,6名の面接評価をしてきましたが,いくつか思うことがあったので以下,それについて記したいと思います.

弊社について

いわゆるSIerなのですが,技術レベルは比較的高いと思います.
なによりコードを書くのが好きなエンジニア・技術習得が好きなエンジニアが集まっている感じです.

社員数的にも規模が小さいので新卒の研修は殆どなく,OJTが中心ですね.

弊社の面接について

1次面接は現場の若手エンジニア(20-30代)の面接官と個人面接.書いて来たプログラムとかGithubにソースがあればそれを見せてもらって,それについて質問したりなど.
まぁどの程度プログラムが書けるかを見る感じです.もちろん志望動機とか,人柄なども見ますが.

1次面接でOKが出れば2次面接(役員面接),最終面接(社長面接),といった流れが基本.

応募の形態

会社に直接来る場合が多いですが,paiza新卒とかプログラミングの問題解いてスキルを測る転職サイトからの応募がこの頃増えてます.

数名受けて思ったこと

paizaから応募した学生がとくにそうなのですが,いくらpaizaでランクが高くてもそこまで技術力が高いかというとそうでもないなと.
これは面接で質問するとよくわかるのですが,「paiza以外で何かコード書いてる?」とか「趣味でコード書いてる?」とか聞いても,せいぜい競技プログラミングの問題解いてる・研究でコード書いてるくらいの回答が結構多かったり.
つまり,いくらランクが高くても競技プログラミング・プログラミング就職サイトのコードしか書いていないと言う人が一定数いるようです.
ちなみにそういった学生と面接した場合,僕はほとんど落としてます.
あと,これは大学院生に多いのですが研究でプログラム書くけどそれ以外では何もしていない,というのも落としてますね.

要はプログラミングが好きかどうか,そこを重きに置いて判断してます.

逆に良いと思った人

主に競技プログラミングがメインの人でも,個人の趣味・活動でゲームとかWebアプリ・サイトを作ってる人とか.面接の話題は競プロが中心でしたが,熱心さが伝わる学生なら文句なしにOK出しました.

採用基準

他の会社がどうか分かりませんが,弊社に明確な採用基準は殆ど無いです(現時点では).
ですが,判断する基準はあります.
それは,立ち会った面接官が一緒に働きたいと思えるかどうか.

曖昧に聞こえるかもしれません.
でもこの話,私が就活してた時にある企業から言われたことでもあるんですよね.
その企業に採用基準があるかどうかは不明ですが,あったとしても行き着くところはそこなのかなとは思います.

私個人の採用基準

では一緒に働きたいと思える人材は何か.
私個人的には以下の基準で判断しています.

  • プログラミングが好きでコードを書いているか
  • 技術的な勉強をするのが苦ではないか
  • 採用した場合メンターとして面倒を見ても問題ないか
  • 技術的に未熟であっても教えれば成長が見込めるか

先ほども書きましたが,弊社の研修はほぼOJTなので,コード書いたことのない新卒は残念ながら…って感じです.
ですが新卒は中途と違って即戦力採用じゃないので,そんなに高い技術力を求めているわけではないです(できるにこしたことはありませんが…).あくまで素質的なところが大きいです.

もちろんその裏付けとしてプログラムが書けるかどうかは見なければならないところですが…

今の目線で就活を振り返る

今思うことは,もう少し就活をきちんとやっておけばよかった,といったところでしょうか.
別に今の会社が良くないわけではなく(むしろあってた方),ただ無駄に苦労してしまったなと.
特に会社を選ぶ軸は早めに決めておいたほうが良かったと反省しています.

これから就活する学生に伝えたいこと

いろいろ書きましたが,一緒に働きたいかどうかを判断するのは企業側なので,結果的に運次第・人次第なところはある思います.
あまり参考にならないかもしれませんが,次のようなことをやってみると良いかなと思います.

  • 企業を選ぶ軸を定める
    • やりたいこと,雰囲気,研修とか
  • その裏付けとなるようなことを整理する・やってみる
    • 技術職希望なら何かコードを書いてみるとか
  • やってきたことに自信を持って
    • 自信がないなら就活中に磨くのもあり
  • 動けるうちから早めに動く

わりと普通な回答になってしまいましたが…
結局のところ新卒採用の判断は技術面が少々で内面が大きな割合を占めてると思いますので,そこは自信持って欲しいところかなとは思います.

以上です.

締めにふさわしいかどうかは不明ですが…,ありがとうございました.

Emacsを捨ててEmacsに乗り換えた話

はじめに

この記事はFUN Advent Calender 201822日目の記事です.
今年も書かせていただきます.

お前誰

FUN13期生の雨龍(@prices_over)です.
毎年FUN Advent CalenderのためにWordPressの個人サイトで執筆しています.
都内のWeb系SIerに勤務しています.
主にMicrosoft系の技術(C#, Azureなど)で仕事してます.

昨年の記事

昨年はSwaggerの話をしました.
https://uryu1994wordpress.azurewebsites.net/2017/12/16/swagger-dotnetcore/

アジェンダ

はじめに

僕の使用エディタはEmacsです.Vimは使いません.
しかしこのままEmacsを使い続けることに疑問を持ち始め,別のエディタに乗り換えることを決断しました.それが今年の6月頃の話です.

なぜEmacsの使用に疑問を持ち始めたか?

まぁ色々あるのですが,下記の要因が大きいのでしょう.

  • デフォルトだと色々無効にしたりしないと使いづらい
    • 一時ファイルの生成無効・コード補完プラグインの導入等
  • ~/.emacs.d/の管理が厄介
  • package管理つらい
  • 他の環境との設定共有が地獄

次のエディタについて考える

まず前提条件として,VIMは候補に含めませんでした.
一度は考えましたが,いざ使ってみると指が拒絶反応を示して使い慣れてないせいかこれは無理だなとなり,そっと閉じました.

色々検討した結果

spacemacs

結果的にEmacsに落ち着きました.オチにしてはショボすぎたか…

あれ?Emacsってこんなアイコンだっけ?と思う方がいるかもしれませんが,これもEmacsです.正しくはspacemacsです.

Spacemacsってなんぞや

http://spacemacs.org
Emacsディストリビューション
位置付け的にはEmacsプラグインかもしれませんが,~/.emacs.d/を丸ごと書き換えてるので,Emacsとは違ったエディタと言ってもいいでしょう.
ちなみにサイトの標語にはこう書いてあります.

The best editor is neither Emacs nor Vim, it's Emacs and Vim!

訳:最高のエディタはEmacsでもVimでもなく,EmacsVimだ!

宗教戦争に疲れたのでしょうか?w

参考:Spacemacsの原則

公式ドキュメントには次のように定義されています.

  1. Mnemonic : キーバインドの覚えやすさ
  2. Discoverable : キーバインドの見つけやすさ
  3. Consistent : 首尾一貫性
  4. Crowd-Configured : コミュニティ主導の環境設定

Emacsを捨ててEmacsに乗り換える

ここから本題みたいなものですが,EmacsをアンインストールしてSpacemacsをインストールするところまでの手順をまとめました.

環境

Emacsをアンインストール

前提条件として,macOSのデフォルトのemacsはバージョンが古いため,Homebrewから落としたemacsを使っていました.
公式の見解ではmacOSの場合は通常のEmacsを使わず,emacs-plusを使うようなので,その手順に則りまずはEmacsをアンインストールします.

  1. ~.emacs.d/.emacs をリネームして退避
  2. 今使っているemacsをアンインストール
$ mv ~/.emacs.d ~/.emacs.d.bak
$ mv ~/.emacs ~/.emacs.bak
$ brew uninstall emacs

Spacemacsのインストール

まずSpacemacsのベースとなるemacs-plusをインストールします.

$ brew tap d12frosted/emacs-plus
$ brew install emacs-plus --with-spacemacs-icon
$ ln -s /usr/local/opt/emacs-plus/Emacs.app /Applications

次にgithubからspacemacsをcloneして~/.emacs.d/に配置.

$ git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d

これであとはコマンドラインからemacsを起動すればspacemacsが立ち上がるのですが,emacs-plusGUIアプリなのでそのまま叩くとGUIが起動してしまいます.
GUIで操作したい!!っていう人はそのままでいいのですが,コマンドライン上で立ち上げたい方はshellのrcファイルとかでエイリアス貼っておくといいでしょう.

alias emacs='emacs -nw'

Spacemacsを起動して初期設定

初回起動するとSpacemacsのロゴが表示され,ウィンドウ下部のミニバッファに初期設定ウィザードが立ち上がると思います.
3つくらいのことを聞かれるのでお好みで選んでください.

編集スタイルの選択

   What is your preferred editing style ?
   -> Among the stars aboard the Evil flagship (vim)
      On the planet Emacs in the Holy control tower (emacs) 

キーバインドvimスタイルかemacsスタイルか
vimスタイルの場合,SPCで操作,emacsスタイルの場合M-mで操作する感じになります.
私はemacsスタイルにしました.

ディストリビューションの選択

   What distribution of spacemacs would you like to start with ?
   -> The standard distribution, recommended (spacemacs)
      A minimalist distribution that you can build on (spacemacs-base)

フルパッケージ(spacemacs)かミニパッケージ(spacemacs-base)か.
できないことがあると困るのでフルパッケージにしました.

補完ツールの選択

   What type of completion framework do you want ?
   -> A heavy one but full-featured (helm)
   A lighter on but still very powerful (ivy)
   None (not recommended**

これはどちらが良いかはよくわからかったので,Qiitaの記事を参考にしてivyにしました

これで設定が完了.

Spacemacsの設定ファイル

初回起動してウィザードの手順を踏むと, ホームディレクトリに.spacemacsができているはずです.

いろいろ設定項目がありますが,語るにはこの記事では収まらないのでググれば出てくると思います.

Emacsすごい

ずっとEmacs使っていて,正直イケてないとか設定弄るのこんなにだるいのかとか,使い慣れていくとそう感じてきましたが,Spacemacsに乗り換えたことでその印象が大きく変わりました.
Vimに乗り換えることも一瞬考えましたがこれならしばらく戦えそうです.

Spacemacsによって改善されたこと

  • ユーザ設定の記述箇所が1箇所で済むようになった
    • 普通のemacsだと~/.emacsに書くのか~/.emacs.d/init.elに書くのかで流派が分かれていた
  • パッケージ管理が楽になった
  • わざわざemacsの設定をゴリゴリ書かなくても使用するlayerを.spacemacsに書いて設定読み込みすれば勝手にインストールしてくれる
    • layerで設定されていないファイルを開くとインストールするかどうかも尋ねてくれる
  • 設定ファイルをspacemacsで用意してくれるのでいじる箇所が明確

まとめ

  • 宗教戦争はもう終わった
  • Emacsの時代も終わった
  • これからはSpacemacsの時代
  • Spacemacs最高

しかし

Emacs最高とか言っておきながら,結局はvscodeの使用率が一番高いかもしれない…

参考文献

SwashbuckleでASP.NET Core WebAPIのSwagger-specを生成してみた

この記事はFUN Advent Calender 2017 16日目の記事です 投稿予定日より少し過ぎてしまいましたが,書きます

雨龍(@prices_over)です.卒業して2年と8ヶ月が経過しました. 都内でMS技術寄りのエンジニアをしています. ついこの前はIE8と戦っていました. Azureを使ったクラウドソリューションを扱った仕事してます.

昨年はこんな記事書いてました.今年も書かせていただきます. SICPについていろいろ書く


本題

最近仕事でも触れる機会が増えてきたのでSwaggerの話でも. C#的な話を書いたことなかったのと.NET Core触ったこと無いなと思ってとりあえずAPIサーバでも作って見るかー,ってノリで作ったら案外ネタになりそうだなと思ったので.

Swaggerとは

Swagger

公式では, Open API Specificationを作るためのAPI開発ツールのフレームワーク、といってます. 簡単に言うとRESTful APIのドキュメントを生成してそこからAPI開発者向けコードが作れるなどそういったツール群ですね.

ちなみにOpenAPI Specificationは, Open API InitiativeというRESTful APIドキュメントを標準化しようとする団体がそれを記述するためのフォーマットで,Swaggerをベースにしています.

Swagger Specificationという仕様が先にあって,それをOpen API Initiativeがそれを採択した,という感じでしょうか(話がややこしい…

Swaggerでできること

Swaggerには各種こんなツールが用意されています. - Swagger Editor: OpenAPIの仕様書を編集可能なエディタ. - Swagger UI: Webページ上で見れるAPIドキュメント.各APIメソッドも叩けるようになっている - Swagger Codegen: OpenAPI仕様書から APIクライアントコード・サーバサイドコードが生成できる

中でも注目すべきなのはSwagger Codegenでしょう. SwaggerのAPI定義書(Swagger-spec)を使えばわざわざ自分でクライアントサイドで叩くコードを書かなくて済みます.

Swagger-specの作り方

Swagger Editorでゴリゴリ書いていく…,なんてめんどくさいことはしたくないですよね? 各言語・フレームワーク用向けに作られたSwagger UI生成用のパッケージを使って自動生成があるので,基本的にそれを使うのが主流と思われます. 今回はC#(ASP.NET Core WebAPI)向けの生成パッケージ, Swashbuckleを使っていきます.


ASP.NET Core WebAPIでSwagger-specを生成してみた

開発環境はこんな感じ

APIを作成

まずはざっくりAPIを作るところから。

SwaggerUI生成できるところまでいってからスクショ撮ったのでSwagger関連のアノテーションが付いてますが無視してくださいw

ここで重要なのがメソッド・クラスについてるXMLコメント。 このコメントがSwagger-specに反映されるので書くようにしましょう。

Swashbuckleを使ってSwagger UIを生成

Swashbuckle.Coreのパッケージを追加して、 Startup.cs を編集。

[csharp] /// <summary> /// This method gets called by the runtime. Use this method to configure the HTTP request pipeline. /// </summary> /// <returns>The configure.</returns> /// <param name="app">App.</param> /// <param name="env">Env.</param> public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); }

        app.UseMvc();

        // Add
        app.UseSwagger();
        app.UseSwaggerUI(c =&gt; {
            c.SwaggerEndpoint(&quot;/swagger/v1/swagger.json&quot;, &quot;RemainderAPI v1&quot;);
        });
    }

[/csharp]

このままでも動くことは動きますが,APIメソッドの概要等が抜けてしまうので,下記変更をします.

  1. Webプロジェクトを右クリック -> オプション -> コンパイラにある XML ドキュメントを生成するにチェックしてディレクトリを選択
  2. Startup.csConfigureServices に下記コードを追加

[csharp] /// <summary> /// This method gets called by the runtime. Use this method to add services to the container. /// </summary> /// <param name="services">Services.</param> public void ConfigureServices(IServiceCollection services) {

        services.AddMvc();

        // Add
        services.AddSwaggerGen(c =&gt; { 
            c.SwaggerDoc(&quot;v1&quot;, new Info{ Title = &quot;RemainderAPI&quot;, Version = &quot;v1&quot;});
            var xmlPath = Path.Combine(PlatformServices.Default.Application.ApplicationBasePath, &quot;Remainder.xml&quot;);
            c.IncludeXmlComments(xmlPath);
        });
    }

[/csharp]

ちなみにXMLドキュメントを生成するにチェックを入れるとXMLコメントが付いていないメソッド・クラスは全てWarning扱いになります。 まぁビルドは通るので無視しても構いませんがうざいなぁと思う人は空のXMLコメントでもつけておきましょう(笑)

こんな感じで一通りつくってデバッグ実行でアクセスするとこんな感じになると思います

swagger-ui

ちなみにAPIメソッドのタブを開くとこんな感じ

swagger-ui-open

この画面から試しにAPIを叩くこともできます.便利.

あと,これはSwaggerの設定を追加する必要がありますが,APIにJwtなどの認証設定している場合はメニューバーにある Authorize にtokenをセットすれば認証のテストなども可能になっています. (もちろんこれらの情報もSwagger-specに記載されます)

Swagger Editorで中身を見る

自動生成したswagger.jsonをダウンロードして,Swagger Editor に読み込ませる。

SwaggerEditor

左にOpenAPIのyaml,右にSwagger-UIが表示されます.

編集もできますが,サーバ側で自動生成したものを編集することはまず無いと思われますw まぁエラーチェックくらいには使えるかな程度でしょう。

Swagger-specからクライアントコードを生成する

Swagger EditorのGenerate Client からクライアント側で使用する言語を選択してダウンロード. いろいろ選べますが今回はとりあえずrubyで生成しています.

Swagger-codegen-lib

クライアントコードと一緒にmarkdownのドキュメントもついてきます.

一応APIのコードもちょっとみて見ると,

swageer-codegen-ruby

おお、なんかそれらしいコードが生成されてる.

という感じで,swagger-codegenでクライアントサイドで使う言語に合わせてコードを自動生成 -> クライアントアプリに組み込む といった感じの使い方ができます。

Swagger-specからサーバサイドコードを生成する

こっちは実例が少ないので割愛。 簡単に言うと,定義書からサーバサイドアプリの雛形を作る,感じでしょうか?


まとめ

WebAPIを作る際に、ドキュメントも併せて必要となることが多いと思われますが,Swaggerを使えばその辺りが自動化できるほか,クライアントサイドのコードも自動で作ってくれる(しかもアプリ開発の言語に合わせて)ので,サーバサイド,フロントエンド,それぞれ分業しやすくなるのではないでしょうか? また,Swagger-UIを生成できるライブラリがあれば,サーバサイド・クライアントサイドともに開発言語の自由が効きやすいのではないかと思います.

あと、Swagger-specを作ってからサーバサイドコードを生成するやり方もあるようですが,Swagger-spec自体書きやすいかと言われるとそうでは無いので,個人的にはそういった使い方はしないかな。

明日はmecaotaくんですでした


参考資料

SICPについていろいろ書く

自己紹介

詳しくはこちら 最近更新してないですが…


最近の私

毎週水曜日に社内勉強会でSICP読書会に参加してます.


SICPって何

  • 計算機プログラムの構造と解釈(Structure and Interpretation of Computer Programs)の略
    • 通称「魔術師本」
  • Lispの方言であるSchemeを題材に計算機プログラムを設計・実装していく感じの内容
  • MITの入門コースで使う計算機科学の優れた教科書(らしい
  • 原文は英語だが,和田英一氏翻訳の日本語版がこちらにある

SICPの良いところ

1. 効率の良いプログラムを書く意識が芽生える

アルゴリズムとかSchemeの言語そのものを学ぶのではなくて,コードを書く量を減らすだとかパフォーマンスの良い実装だとか,そういった考え方を身につけれます.

2. 練習問題があって,解答がない

問題ついてると理解度が高まるのはいいですが,解答がついてると詰まった時についつい頼ってしまいがち… SICPは解答が一切ありません.そりゃ実装方法はいろいろあるでしょ.

もしどうしてもわからないだとか,解答が気になる人は,ググればいっぱい見つかると思います(笑)

3. 学習にかかるコストが低い(実質無料

Amazonで買うとだいたい2000円 - 3000円くらい. Web公開版なら0円. ね、安いでしょ?


この本の悪いところ

  • 分量が多い・時間がかかる
  • 数学的知識が必要
  • 日本語訳が変なところもある
    • そのあたりは原文に目を通すか,作者に問い合わせるか,念じるしかない
  • ところどころ難問がある
    • まぁ無理に解く必要はないです.1問くらい飛ばしても理解できなくはないので…
  • 実用性がなくて学習効果が見えにくい
    • 流行はRubyか…

4月から勉強会に参加して週1ペースで読んで、1章を読み終わったのが8月上旬?だったかな.
今週は2.4.3まで読みました.
ちなみにこの本,5章まであります. 長い.

あと,数学的に難しい系の難問がいくつかあるけど,飛ばしてもいいのではないかと思います.


実用性が無いのなら読む意味がないのでは?

実用性が無い=学ぶ気になれない,って人結構いると思うんですよ. 最近こんな記事を見つけました

2017年に学ぶべき年収の高いプログラミング言語トップ15

なんとScalaObjective-Cを挟んで第3位にSchemeがランクイン. SICPが影響しているかどうかは不明ですが,Scheme自体そんな複雑な言語では無く,言語特有の闇が少ないといった感じです. なので,効率の良い実装方法を知るとか,データ抽象化だとか普遍的な技術体系を学ぶ上では非常に良い本では無いかと思います.

あと,最近C#とかJavaでもlambda式が使えるようになって,「lambdaってなんぞや??」っていう人もいると思います. SICPでもlambdaが出てくるので,lambda式知らない人は是非読むと理解ができるかと思います. (私もSICP読むまでlambda式さっぱりわからない人でした)


まとめ

Ruby on Railsとかnode.jsとか,実用性のある流行りの技術を学ぶことは当然有意義だと思いますが, 学習コストがかかるとか次から次へと新しい技術が出てきて学習しにくい人もいるのではと思います.

SICPはそういった実用性はないけど,学習コストはそんなかからないし 変わることのない普遍的な技術を学べるので何か得られるものがあるのではと思います.

技術的勉強したいけど何やったらいいかわからない人は、ここから始めても良いと思います. 結構読み応えあるし,一人で読むの難しい人はみんなで週1ペースで読むとか. 1つの勉強会のネタになるかなと.


よろしかったら参考までに

SICPはいいぞ。

Ghost Party -Welcome To The Night Hotel-

[soundcloud url="https://api.soundcloud.com/tracks/203864664" params="auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true" width="100%" height="450" iframe="true" /]

どんな曲?

暗い感じを出しつつも何気なく明るめに仕上げた曲。 某ネズミの国の、古びた館というかマンションというか… アレをイメージしてます。

収録CD

Sound Create Vol.10

Dreamed Sky

[soundcloud url="https://api.soundcloud.com/tracks/203864672" params="auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true" width="100%" height="450" iframe="true" /]

どんな曲?

飛行機をイメージした感じの曲。旅客機だったか戦闘機だったかは覚えていないが。 余談ですが、小さい頃、近くに空港があったため、空を眺めると飛行機が飛ぶ姿をよく見かけました。 …あ、ジェット機じゃないんですけどね。

収録CD

Sound Create -pre "Vol.9"- Sound Create Vol.9