クロノスを退社しました!

先週、4月から働いていた株式会社クロノスを退社した。

流行の退職エントリということだが、
退職エントリといえば、いい話(ウェブリオを辞めました)の記事を読んで大変感銘を受けた!

同じように、エンジニアとして働く誰かの参考になれば嬉しい:)

会社について

主な業務としてSler支援・IT教育・受託開発を包括的に行っていて、最近は5ヶ年計画を掲げて事業ドメインを自社開発中心へシフトしようと取り組んでいる。

入社のきっかけは、前に働いていた社長による紹介である。
前の記事で書いた通り、僕は大学を辞める決断をした。その際に、先は分からないけれど取り敢えずの勤め先として社長がクロノスを紹介してくださった。

しかし、入れ違いで就職先が決まり、残念ながら2ヶ月だけしか在籍することが出来なかったのが心残りである。

クロノスの特徴

今まで僕はWeb系の会社でしか働いたことが無かったので、驚くほど刺激的な時間を過ごすことができた!

僕の直接の業務はとある医療系(?)Webアプリの開発で、マネジメントの高山さんと僕の2人で行なった。

正直なところ、期間も短く業務も一部だったため他の事業ドメインの事情は疎い。
そのため情報はとても偏るけれど、目に映った事柄については率直な感想を書いていきたい。

悪かった点

良かった点があまりに多かったため、先に悪かった点をざっと書いておく。

1. Slerの文化がやや浸透している

いわゆるエクセルを中心としたタスク管理、バグ管理はWeb系で活動してきた僕にとって初めての体験だった。
僕にはこういったマネジメントが馴染めなかった:(

2. Web技術の浸透度

もともとJavaを中心にしていたため、Web系技術の情報がまだ浸透しきっていないと感じた。
現在はRuby/JS中心へ移行しつつあるので、これから浸透していくと思う。

良かった点

クロノスで働いてみて、何度も感嘆した。。
良かった点が日常に溢れていて書ききれない!

1. 人間力が高すぎる

「エンジニア」としてだけではなく、ただひたすらに「人」として尊敬出来る会社だった!

謙虚さや人の良さというのは、身に付けようとしてどうこうなるものではない。ましてや、会社としてそういった文化を根付かせようと思ったら尚更である。
前向きな言葉に溢れて、常に人を気遣って笑顔で仕事に取り組んでいた。

努力や技術とは別のベクトルにある要素である分、かけがえの無い感動があった。
将来、仕事を依頼することになったら間違いなくクロノスにお願いするだろう。理由は言わずもがな、である。

うーん、もっとあの感動を書き表せる文才が欲しい。笑

2. ホワイトなIT企業

とーってもホワイトな環境だった。
残業はほとんど無いし、同僚は楽しい人ばかり。最高!

3. 技術的な向上心

クロノスには技術本の著者が何人もいる。(一定年齢以上はほとんど?)
会社としても、本の執筆や資格取得を推奨しているので、その気があればかなりサポートしてもらえるはず。

4. 教育体制

IT教育を事業ドメインのひとつとして捉えているだけあって、教育環境が素晴らしかった。
目の前で新卒の方々がメキメキ上達していく様は、かなり焦りを覚えるほどだった。

クロノスは元々エンジニアでなくても、育ててくれる会社なので文系からエンジニアを志望する人にはかなりオススメです。
何より、「教育体制」なんて垣根は関係なくて全ての先輩が親身になってくれる会社ですし。

まとめ

2ヶ月という短い間でしたが、本当にお世話になりました!
クロノスという会社はとても良い会社なので、興味があればぜひ転職してみてくださいw

Railsの補助プラグインを書いた

もうLocaleファイルに迷わない!

screen_shot_1

休日を利用して、久しぶりにRails関連のVimScriptを書いたよ:)

Railsとlocalesファイル

きっかけは、とあるプロジェクトに立てられたIssueであった。

言語ファイルが大きすぎてどこを編集しているのか全く分からなくなる。
もはや人が書くようなファイルじゃない。

便利なエディタがあるならエディタに頼ってもいいけどざっと探した感じ見つけられなかったので、いい解決方法があれば教えて欲しいです。

おっしゃる通り、懸念すべき事項である。
多国籍に対応したプロジェクトをRailsで作った経験があると分かるが、気をつけていてもlocalesはカオスになってしまう。

しかし、次の発言で少し様相が変わる。

issue

SublimeText2が有力…だと?

何を寝ぼけたこt

alpaca-tcはVimの人である。Vimで解決しんぜよう。

Railsの補助プラグイン

丁度、僕も今Railsで開発をしている。
痒いところが幾つかあったので、休日に孫の手を作ることにした。

Alpaca Rails Support

といっても、時間があまり無かったので3つの簡素な機能でまとめた。

I18nの探索

本題の機能である「localesの編集をサポートする」プラグインである。
キーを探索して、Uniteにぶち込んでくれる。

Find_local

探索は少し荒いので、Yamlをキレイに書いていなければ動かない。

Routesの補完

個人的に一番欲しかった機能である
たかだかRoutesのスペルミスで、BetterErrorsと挨拶したくない。

reoute補完

ようやくrake routes | grep ...の地獄から解放されるヾ(*´∀`*)ノ

I18nのプレビュー

特に必要は無かったけれど、思いついてしまったので作った。

preview

( ゚∀゚)o彡゚ギミックかっけー!

vim-easy-motionやvim-overと同じ方法を取り入れていて
while 1getchar()の組み合わせでkeypressを補足している。

新鮮な方法だったので、一番気に入っている。

今後

もう少ししたら、オンラインのlocales探索アルゴリズムを実装しようと思っている。
VimScriptでアルゴリズムらしい手法を使ったことは無いので、楽しみである。

めまぐるしい1年!

退学した!

昨年の6月、1年8ヶ月働いていたベンチャー企業を辞めて、大学に復帰した。

その傍ら、大学と平行して2社の会社を渡り歩いた。

ふと気付けば冬になり、世間は就職活動一色に染まっていたので、思い立って就職活動を始めるも、挫折(?)して1ヶ月休む。

かたや、更に新しい会社で働き始めたかと思えば4月となり、僕は大学を中退していた。

めまぐるしい!

今日は簡単に、中退の報告と振り返りをしたい。

ベンチャー地獄

僕は2回生の後期から大阪の会社で、エンジニアとして働き始めた。

さすがに、立ち上げ時期というのもあってブラック企業の贅の極みだったけれど、めちゃくちゃ楽しかった。2年連続でクリスマスを伊青さんと社畜したのは、哀し良い思い出である。笑

それから1年8ヶ月働いて昨年退社した。

あの頃は、とにかく絶望的に刺激的な毎日で、同僚の方達の考え方は鋭く僕の仕事観・人生観に影響を与えた。退社してから、随分と働き方が変わったのでぜひ今一度一緒に働きたいところである。もう、二度と無茶な働き方は出来ないと思うけれど。

会社の方達には、本当に感謝をしている。

怒濤の日々を終えてふと大学に戻ると、大学生の若さが眩しくて、随分と老いを感じた。笑

就職活動

大学に戻ってからもせっせと働いていたら、いつの間にか就職活動シーズンに入っていた。

僕も思い立って就活を始めようと思ったけれど、リクナビを見た瞬間に就職活動を諦めた

あの体裁には、本当に吐き気がした。

僕は自分の時間の浪費も、人の時間を奪う行為も、同じく悪だと思っている。リクナビのように、ポチポチと平気で時間を奪いあうなんてことは、到底やる気になれなかった。

結局、別の方法で就活するも時間の奪い合いは止められなかった。そして、僕は2月まるまる就活を辞める…。(つ∀-)

エンジニア志望が毎日コードを書けないなんて、おかしいと思わない?

決断のとき

この時期に、問題にぶち当たる。学校に残ることは、就職のために時間を浪費するということに気付いた。というより、確信に変わったというか。

しかし、大学を辞めれば将来は厳しいのだろう。

信念みたいなもの

人生はしょっちゅう選択を迫ってくる。けれど、僕は一貫してシンプルに選ぶことにしている。

危険だ、という道は必ず、自分の行きたい道なのだ

怖かったら怖いほど、逆にそこに飛び込むんだ

岡本太郎を初めて知ったのは、もう10年ほど前のことだ。

選択を迫られる度に、彼のこの言葉がぐんと盛上がってきて、つき動かされてきた。一度飲み込んでしまえば、これほど強力なおまじないはない。

やりたくないこと、反対されること、厳しいことを選んできたら、ベンチャー社畜を止められなかった。笑 お誘いを断る言い訳が出来ない。

22歳になって、この言葉はますます生命力を帯びている。

大学を辞める選択

先日、ついに大学を辞めた。驚くかなぁと思って友人に話したら「ようやくか!」と笑われた。

僕は死ぬまで賢く生きれないだろうなぁと思う。

これからの話

さて、6月からpixivという会社で働くことになった。

pixiv

イラスト系のSNSを運営する会社で、知っている人は知っている会社かもしれない。

長くなったけれど、これで報告はおしまい!

僕もやっと東京進出するよヽ(・∀・ )ノわーい

APIのMockサーバーを構築する「Apiary」を使ってみる

apiary Build beautiful APIs

Apiaryは、美しいAPIのドキュメント(Mockサーバー)が作成できるWebサービスです.

Apiaryの使いどころ

仕事を進める上で、APIの仕様が先に作られることは多々あります.

今関わっている案件でも、APIの仕様表だけ先に届いたので、Mockサーバーを立てて開発を進めることにしました.

ドキュメント(Mockサーバー)を作ってみる

Githubの連携でアカウントを作り、すぐにドキュメントの作成に取りかかれます. markdown(の拡張)でAPIの仕様を書けば、すぐにドキュメントが生成されます.

Apiary Document

う、美しい…

その上、Apiaryではドキュメントと同時に、そのドキュメントからMockサーバーを立ててくれます.

今回は、デモとして簡単なアルパカAPIを実装しました.

10分ぐらいで作成完了.すばらしい!

レスポンスを見てみる

作成されたAPIのMockサーバーは、API名.apiary-mock.comで見ることができます.

さっそくcurlでレスポンスを見てみよう

$ curl https://alpaca.apiary-mock.com/hello

ヽ(・∀・ )ノす…すげぇ便利!

Gemを書くときに知っておきたい3つの事

先日から書き続けていたCommentExtractorが、大枠完成しました。

CommentExtractor

さて、今回Gemを書くときに役に立った、便利なTipsを幾つか紹介します!

内容はバラバラです。笑

  1. READMEに視覚情報を追加する
  2. RubyGemsからGemを削除する
  3. RSpecをキレイに書く

1.READMEに視覚情報を追加する

READMEには視覚的なバッヂを追加出来ます。Gemを書くときには、ぜひとも入れておきたい情報ですね。

  • Gem Version
  • Build Status
  • Coverage Status

もちろん、登録すれば無料で作ることが出来ます。

詳しくはコチラの記事を読んでみましょう。

2.RubyGemsからGemを削除する

間違えてRubyGemsにPushしてしまった!

そんなときに便利なyankコマンド。意外と知られていない。

gem yank gem_name -v 1.0.0

ただ、これをやっても論理削除されるだけのようですねぇ。多分。

このバージョン使うなよ!新しいの使えよ!ってときに使うコマンドだと思います。

3.RSpecをキレイに書く

RSpecをキレイに書く方法は、ある程度伝統があります。

今回は、ある程度RSpecを書ける人向けに、検索してもあまり出てこない情報(検索しにくい?)を提供したいと思います。

Syntaxについて

be_truthy, be_falsy

RSpecが新しくなって、be_true, be_falsebe_truthy, be_falsyとなりました。 今までは、厳密にtrueで無くてもテストが通っちゃいましたからね。

現在の主題であるクラスを取得する

RSpecではdescribed_classというメソッドを使用出来ます。 describe KlassName do...で指定したKlassNameが格納されます。

これを使えば、クラス名に依存せずにテストを書く事ができますね。

ExampleGroupを作る

ご存知の通り、Railsのテストではcontroller, model, viewで使えるメソッドが大きく異なります。 それは、RSpecのexample_groupという機能を使って、テストの種類を元にModuleをincludeしているからです。

これを使えば、複数のファイルで共通する内容を簡単に記述する事が出来ます。 次のような感じですね。

# spec_helper.rb
RSpec.configure do |config|
  config.include ExampleGroupModuleName, type: :optional, example_group: {
    file_path: Regexp.compile(%w[spec comment_extractor extractor .*.rb].join('[\\\/]'))
  }
end
RSpec.configure do |config|
  config.add_setting :source_code_path, default: 'spec/assets/source_code'
end

module ExampleGroupModuleName
  def source_code_path(file_name = nil)
    dir = RSpec.configuration.source_code_path
    file_name ? "#{dir}/#{file_name}" : dir
  end

  def self.included(k)
    k.class_eval do
      let(:instance) { described_class.new(source_code) }
      let(:source_code) { source_code_path(file_name) }

      describe '.new' do
        subject { instance }
        let(:file_name) { 'filename.rb' }
        it { expect { subject }.to_not raise_error }
      end
    end
  end
end

これを使えば、まとまったテストをスッキリ書く事ができますね。

まとめ

ざっくばらんに書きました。 Gemを作るのは簡単なので、みなさんも作ってみてください!

では!