Atom Editorへの乗り換えを考えている その2

やっぱり機能拡張があると嬉しい

AtomにはPackageと呼ばれる機能拡張がたくさんあるみたいで、8月30日（日）時点で2,600件ほどあるみたい。いろいろと入れて便利にしようと、Packageを探す旅に。

とりあえず、色々と入れてみて試したものを記します。

atom-runner

編集中のプログラムをショートカットキーで実行できる。実行結果は画面が分割されて右に出てくる。

file-icons

ファイルのアイコンを変更できます。視認性だいじ。

file-types

拡張子とファイルの種類の関連付け。積極的に入れた覚えがないんだけど、なにかの依存関係で入ったのかな？

git-control

AtomにGitのGUI環境を提供してくれる。とりあえず入れてみた感じ。あんまり活用していない。エディタの部分で右クリックして「Toggle git-control」を選択すると出てくる。

git-plus

Gitの操作をコマンドパレットから行うことができるPackage。Atomでは「cmd-shift-p」でコマンドパレットというものが呼び出され、現在開いている画面に関連した内容が列挙されます。

そこで、「git」と打てば、Gitに関するコマンドが入力できるというのがこのPackage。

language-javascript-jsx

Reactのコードを書くときにSyntax Highlightが欲しかったので。

linter

シンタックスチェックなんかを行ってくれるPackageの基盤となるもの。実際には、言語に合わせたPackageが必要。

linter-jshint

JavaScriptのLinter。JavaScriptのLinterって色々種類があるようだけど、特に思いはなかったのでJS Hintで。こんな風にエラーが出ます。

linter-ruby

RubyのLinter。こんな風にエラーが出ます。

open-recent

最近使ったファイルを開くってもの。

tabs-to-spaces

タブとスペースとの相互変換。

まとめ

とりあえず、現状で入れているPackageを書いてみました。まだまだAtom一本で生活するってほどではないのでこれぐらいの数で済んでますが、依存度が高くなるとPackageが増えてくるかもしれません。

Atom Editorへの乗り換えを考えている

はじめに

ある日何を思ったのか、Vim Pluginの更新をしようとneobundle updateをかけたらよくわからないエラーメッセージが出ちゃいまして。

そこでエラーメッセージを解決するのが正しい姿かと思うのですが、「おれはエディタのメンテをしたいんじゃない、単にコードを書きたいだけなんだ」という思いのもと、Vimからの脱却を考えるようになりました。

そこで目につけたのがAtom。周りでも乗り換えている人が多いので、自分も乗り換えてみることにしました。

なお、ここでは、Atom 1.0.7を使いました。

エディタに求めること

普段の生活を見直すと、エディタを使うシーンは色々ありました。

• WindowsとMacで動いて欲しい
  • 会社ではWindows、家ではMacを使っているので。
• 設定が楽であること
  • なんちゃらrcとかのファイルをあまりメンテナンスしたくない。
  • とはいえ、複数のマシンで使ったりするので、設定は何らかの形で共有化したい
• RubyやGo、JavaScriptのコードを書くこと
  • ある程度補完が効いて欲しい。do - endとか{を入れたら}が入力されるとか。
  • ショートカットキーを入れたら、スクリプトが実行されると嬉しい。
• Markdownを書く
  • プレビューしたいなぁ
• VMやサーバにあるファイルを編集する
  • これはVimかなぁ。

Atomでやったこと

• [Atom] - [Preference]で[Settings]画面を出し、フォントとThemeを設定
  • [Font Family]の欄に直接「Ricty」と入力する。ここ、フォント設定パネルとか出してほしいなぁ。
  • Themeはhttps://atom.io/themesからよさ気なものを選択してインストール。
  • インストールは、[Install]で[themes]を選択してキーワードを打つと出てくる。インストールすごく楽。
  • Themeの適用は[Themes]から。
    • Macだとデフォルトでよさ気なんだけど、自分のWindows環境だと黒がだいぶ強め。入力欄が見にくい。
    • スタイルシートをいじるっていう手もあるけど、あまり手を掛けたくないので、Themeで頑張ることに。
    • いろいろと試して、[UI Theme]は「Atom Light」に、[Syntax Theme]は「Monokai」にしてみました。
    • たぶん、ちまちまと適当に変える予定。
• 会社でのインターネット接続にはProxyという山があってですね...
  • .atom/.apmrcに「https-proxy = http://ユーザID:パスワード@ホスト:ポート番号」と書けばOK

今日はここまで

ここまでで私のブログを書く気力が尽きたので、続きはまた後日。

GitHubのContributionsを緑にすることで承認欲求を満たしかつ、ぱっと見すごく勉強している人のように見える勉強法

はじめに

先日、「技術書の読書ログとかどうしてます？」って話から飛躍して、題記のようなことを編み出したのでそのことのご紹介です。

やりかた

勉強のログをGitHubに上げることだけです。勉強のログは、README.mdにMarkdown形式で書けばよいでしょう。サンプルプログラムがあるものは、そのプログラムも写経しておいて一緒にpushしておきましょう。きっと役に立ちます。

結果

毎日続ければ、Contributions欄が緑にうめつくされます。業界用語で言えば、「草を生やす」って状態です。パッと見、すごい人として認識され（るかもしれない）ます。

不安なこととか

• コードを見られて恥ずかしい

多分、誰も見ません。

• IssueとかPull Requestとかで罵倒されたりしないですかね？

大丈夫です、誰も見ませんし、誰もそんなコメント書きません。

まとめ

Contributions欄が緑に埋め尽くされるのは、ちょっといい感じです。承認欲求を確実に満たし、かつ、第三者からはすごい人として認識される（かもしれない）かもしれない方法は、最初の一歩を踏み出すにはお勧めです。

Growing Rails Applications In Practiceを読み終わった

はじめに

毎週土曜日の朝に有志でやっている横浜技術書朗読会。本日の読書会で「Growing Rails Applications In Practice」を読み終わりましたので、その感想エントリを記します。

leanpub.com

本の特徴

この本は、

• コード量が増えるにつれて、Railsアプリケーションのメンテナンスが辛くなるという話はよく聞くが、それをどうやって解決するかについて、著者の考えを記した一冊。
• Rubyだけでなく、途中でCSSの話も出てくる。
• 英文は比較的平易。
• ページ数があまりなく、挫折しにくい。
• コード片は記されていますが、写経して手元で動かすって感じではない。
• 対象読者としては、2,3個ぐらいRailsアプリケーションを書いた人が読むと良いかと思います。

という特徴があります。

感想

ここで示されているRailsアプリの改善例は、あくまで著者の考えを記しただけなので、それをそのまま踏襲するのも良いし、違う考え方があっても良いと思います。横浜技術書朗読会の中でも、経験豊富な @1syo さんや @satococoa さんのお考えがあり、この本をとっかかりに話題が膨らむことが多くありました。

ソースコードが写経の形になっていないので、手元で試すことが出来ないのはいわゆる初心者にはつらいかなと思います。自身で2,3個ぐらいのRailsアプリケーションを書いたことがあると、本文中に書かれている苦労話が同感でき、また改善案も全体を示さなくても分かることが多いと思いますので、それぐらいの技術力は求められるかなと思います。

第10章「On following fashions」からはソースコードは殆ど出ずに概念的なお話が中心となります。実際には、以降の章について詳細を書こうとするとそれぞれ1冊ずつ別の本になりそうですので、コンパクトに纏めるために今の形にしたのかもしれません。個人的には、読み飛ばしても良いように思います。

Podcastにリモート参戦した時の録音環境

はじめに

先日、RubyistclubというPodcastに出演させていただきました（しかも第1回目）。きっかけは、神奈川Ruby会議の振り返りの時に「もっとトークセッションの話を深堀りしたいよね」という一言から。

内容はPodcastのものを聞いていただくとして、ここでは私の録音環境について記します。

録音環境

Podcastの収録は、Skypeで司会の@chezouさんと話しつつ、自分の声は自分で録音するという形で行いました。

で、ここで問題になるのが「自分の声は自分で録音する」という方法です。Podcastへの出演はたぶんこれっきりだと思われるので、あまり高い機材を導入するのは躊躇しました。なにか今ある機材でどうにかできないかな？と試行錯誤した結果、次の構成に落ち着きました。

• Skypeでの通話はiPhoneで行いました。
• 録音はiPadで。Voice Recorder HDというアプリを使用し録音することにしました。

Voice Recorder HD － 録音・再生・共有の多機能ボイスレコーダー

• eFUSION Co., Ltd.
• ビジネス
• ¥200
• 

• 音声はSONY製のワイヤレスヘッドセットBluetoothレシーバー（SBH20）を使って音を拾う形にしました。

SONY ワイヤレスステレオヘッドセット SBH20/B ブラック

以下、それぞれの詳細について。

工夫点と詳細

工夫したところの一つは、MacやパソコンでSkypeや録音をやっていないところです。これは、途中で冷却ファンが回ってその音がPodcastに入るのを防ぎたかったためです。1時間ほどの収録になると、ファンが回ってしまうことはどうしても避けられないため、そもそも冷却ファンがついていないiPhone/iPadを活用することにしました。

自分の音声の録音方法についてはちょっと悩みましたが、もともと持っていたSONY製のワイヤレスヘッドセットBluetoothレシーバー（SBH20）を使って音を取るようにしました。

SONY ワイヤレスステレオヘッドセット SBH20/B ブラック

これをピンマイクのように胸辺りに引っ掛けて置くことで、自然とマイクの位置が固定化されます。マイクに近づきすぎたり遠すぎたりすることなく、安定して雑音なしに音を拾うことが出来る環境がこれで整いました。

あとは、このBluetoothレシーバーで撮った音を録音するものが必要となります。これには、Voice Recorder HDというiOSアプリを使うことにしました。

Voice Recorder HD － 録音・再生・共有の多機能ボイスレコーダー

• eFUSION Co., Ltd.
• ビジネス
• ¥200
• 

このアプリを選んだ理由は以下の3点。

• Bluetoothでの録音に対応していることが明記されていた
• wavファイルとして音声ファイルを保存する
• アプリの値段が200円（2015年3月1日時点）と安い

これを使って録音することにしました。

あとは、Skype通話をiPhoneで実施。念のため、通話内容をマイクが拾わないようにイヤフォンをiPhoneに付けて会話を聞き取るようにしました。

反省点

後で聞き直して気がついたのですが、ちょっと音が小さかったように思います。Voice Recorder HDには後で音を増幅させる機能が有償ですがありますので、それを活用しても良かったのかな？とも思います。

他には機器としては問題なかったように思います。手元にあるものだけを活用して、今回のPodcastの収録に費やした金額はアプリ代金の200円だけだったので、思った以上に安上がりにできました。

ただ、しゃべり自身はもう少し頑張りたいなと思います。受け答えが「そうですね」から常に始まっていたり、身内トークを間に挟んだのは改善の余地があるなと思ったりします。これは次回の機会があれば、改善したいですね。

『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』を読んだ

はじめに

『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』という本を読みました。ちょっと古めの本ですが、よりよいデータベース設計・テーブル設計というものを感覚だけでなく、言葉で説明できるようになりたいと思い、手に取りました。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

私が買った時は、紙の本しか無いのですが、今ではKindle版もあるようですね。

結構稀有な存在？

世間では、SQLのテクニックやプログラミングのテクニックばかりが注目され、それに特化した本も多数出ているのですが、本書はその前段であるテーブル設計について焦点を当てて書かれています。

SQLやプログラミングに対する知識は当然必要なのですが、正しいテーブル設計を行うとトリッキーなSQLやプログラムを書く必要性はなくなります。トリッキーな技術をうまく使いこなせた時は嬉しいものですが、その直後から高いメンテナンスコストと終わりなきバグとの戦いを続けることになりそうです。

そのため、本書で設計について学ぶことは大変意味があるように思います。

くどい

ただ、ちょっと最初の正規化のところはくどいぐらいに記載されています。正規化の重要性やそれを学ぶことの必要性についてこれでもかとばかりに書かれていますが、ページを取り過ぎな感がありました。

本書の第7章から9章までに書かれているテーブル設計の話がもっと読みたかったのですが、前半のところでページ数が取られている感じがしました。

今後

この本は足がかりで、次は『SQLアンチパターン』が良い感じかなと思います。

SQLアンチパターン

また、同じ指向としては2月に発売予定の『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL』が該当しそうです。

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

まずは『普段何気なく使っているテーブルの列の定義ってどう考えて設計しているの？』と疑問を感じた時に手に取るといい本だと思います。

神奈川Ruby会議にるびま班＋登壇者として参加してきた（追記あり） #kana01

はじめに

神奈川Ruby会議にるびま班＋登壇者として参加してきました。るびま業はまだまだ続くのですが、ひと通り区切りがついたのでメモを記しておきます。

運営業

はじめに

元々は、大江戸Ruby会議に出た時に「るびま班として参加してみない？」と声をかけられたのが最初でした。みなとRuby会議02をやろうかなぁと思っていた頃合いなので二つ返事でOKし、そこから運営業に色々と関わることにしました。

コミュニケーション

運営者が全員バラバラの所属だったので、意思の疎通を取るのは結構難しいところがあります。このツール選びにひと月以上費やしたものもあり、意外と揉めました。

結局、Facebookメッセンジャーをよく使ったのですが、Facebookメッセンジャーは日常のコミュニケーションを取るために使うものであって、打合せなどのコミュニケーションツールとしてはちょっと違うかなぁと思います。通知の頻度がちょっと違うかなぁと感じたのた原因でしょうか。

たぶん、決定的なツールは存在しないので、あるツールをいい感じに使うっていうのがベターなアイディアなのかもしれません。最初は「いまどきメールはないよね」っていう声も有ったのですが、コミュニケーションを取るためには有効な手段なので、とりあえず、始めてみればよかったのかなぁと思ったりもします。

後はオフラインコミュニケーション。オフラインコミュニケーションは10回も満たなかったのですが、顔を合わせて話をするというのは文字だけのコミュニケーションだけでは補えきれないものがたくさんあります。移動というコストがもったいなく感じる時もありますが、全員が揃わなくてもやったほうが良かったかなぁと思ったり。

ペアプロ

神奈川Ruby会議の技術的なエッセンスとしてペアプロを入れました。問題の難易度についてはいろいろとご意見があるかと思いますが、参加者が少なくとも隣の人と話すためのきっかけ作りとして、また、Rubyでなんらかの達成感を得てほしいためにペアプロを用意したので、若干難しめなものを作り、ペアと相談したり、TAからのアドバイスを貰うという形を狙っていました。

狙いがうまくハマったのか、開始早々に各ペアが活発な議論を交わし、コミュニケーションを取られていたのは感動的でした。

仲間たち

運営は一人ではできません。実行委員長の有賀さんだけではなく、会計の川口さん、会場の長住さんはじめNTT-ATのみなさん、るびま班の徳田さん、アドバイザーの高橋さん。カメラを向けたらみんないい顔してました。みんな、ありがとう。

発表業

さて、るびま業だけではなく「トークセッションで登壇してください」と言われました。幾度と無く断りましたが、どうしても外せない牌だからと言われ最後には腹をくくりました。

葛藤

自分はごくごく普通のSIerに勤めるSEだと思っています。技術的に光るものがあるわけでもなければ、なにか代表作となるGemやサービスが有るわけではない。そんな自分が登壇して、自分の生存戦略なんぞ語っても意味があるのかと散々悩みましたが、Yokohama.rbの運営業を何故しているのか、オンライン・オフラインの読書会をなぜ続けているのかを考えて話してみました。

Rubyに関する生存戦略

自分のRubyに関する生存戦略は単純で、「Rubyに投資する時間を増やしてそれを続けること」です。

Rubyは生産性の高い言語ですが、文法を知り、記述パターンを覚え、使いこなせるようでなければ仕事や武器としては使えません。自分にはその力を身につけるために、時間を費やす必要があると考え、そのためには強制的に勉強する場に自ら参加することをやり続けています。

偶然にも、高橋正義さんが同日の講演の中で話されていましたが、自分は「勉強会は受け身でいると何も技術は身につかない。モチベーションも翌営業日にはしぼんでしまう」考えていて、そのためには強制的に勉強をする時間を設けようと思ってました。

ただ、あくまでRubyに関する生存戦略なので、会社で生きること、世間で認められるための生存戦略はまた別です。Rubyに関する生存戦略を含んでいますが、世間で認められるための生存戦略はまた更にあるので、話す機械があればちょっとまとめて話してみたいですね。

質疑応答に対するちょっと長い回答

最後に「なぜ、今の会社に？」と言う質問をいただき、それに対して「お金」と答えました。

お金が全てではありませんが、お金がないと生きてはいけません。やりがいを強調されてもそこに対するベクトルが合わなければ意味ありませんし、なぜ自分を評価してくれているのかについて説明しないところには、単なる人集めとしか映りません（SIer出身者だからっていうのは、説明不足ですよね）。

今のところ、自分がやっていることと、やりたいことのベクトルが多少あっていて、生活できる程度のお金を頂けており、安定性もある程度は見込めているので、これを崩すためには...あとは省略。

まとめ

多くの方々に参加して頂き、大変ありがとうございました。次回があればですが、よりよい会議を開きたいと考えています。