maco's life

主にエンジニアリングと読書について書いていきます。

kramdownというgemについて調べる

programming

最近kramdownというgemを触る機会が増えてきたのですが、使い方など参考にしようとググっても実際に使ってみた例などあまり多くはないようなので公式のドキュメントを参考にしつつ、実際に使ってみようと思う。長くなりそうなので今回は簡単な紹介だけします。

github.com kramdown.gettalong.org

kramdownとは

githubのdescriptionによると

kramdown is a fast, pure Ruby Markdown superset converter, using a strict syntax definition and supporting several common extensions

と書いてあって、稚拙ながら直訳すると「pure rubyで書かれているmarkdown上位変換機能で処理が早い。厳密な構文を使って、幾つかの共通拡張をサポートしています」みたいな感じに書かれています。「???」みたいな気持ちになったので公式サイトの方を見たらわかりやすい図がありました。

https://kramdown.gettalong.org/overview.png 参照: https://kramdown.gettalong.org/

要するに様々なインプットに対して、様々なアウトプットへの変換をサポートしているらしいです。2017年1月時点だと

以上には対応しているそうです。便利。

簡単ですが最近使っているgemの紹介でした。明日は実際に使ってみた例を書いていきます。

【MySQL】idカラムをとりあえずつくる

programming

f:id:Maco_Tasu:20170107162201p:plain

私は新規で作成するテーブルにはほぼ必ずidカラムを作成しています。定義は以下のような感じです。

`id` int(11) NOT NULL AUTO_INCREMENT, ... PRIMARY KEY (`id`)

自分がidカラムつけるのは主に、データ量が膨大なテーブルを扱う時にシーケンシャルな処理ができることです。 実装をそのidを基準に処理をかけばrow readsが少なくDBに優しい処理をかけます。

例えばPKがある場合

  1. idを1から1000までを取得する
SELECT * FROM hoge WHERE id > 0 ORDER BY id asc LIMIT 1000;
  1. 次に1001から2000までを処理する
SELECT * FROM hoge WHERE id > 1000 ORDER BY id asc LIMIT 1000;

みたいな処理をかけば、row readsは1000になると思います。これが例えばindex key基準に処理した場合そのindexでヒットする件数分row readsになると思うので良くないなという時があります。idを追加した場合のデメリットは、その分のデータ量が増えることかとおもいますがそれを許容できるような条件ならば追加しておいても損はないかなと。

ここ数年でRailsプロジェクトに関わるようになったのですが、Railsもmigrationでテーブル作成するとidカラムは自動でついてくるみたいでちょっぴり嬉しい。

勤怠のChrome拡張を社内向けに公開する

programming

先日勤怠のChrome拡張を作ったというブログを書きましたが、一人でしばらく使ってみて便利だったので今回社内向けに公開しようとおもって調べました。

macotasu.hatenablog.jp

社内向けに公開する方法

社内向け = 一部のユーザに限定して公開とした時に現状以下の選択肢があります。

  • URLを知っている人のみの限定公開
  • Trusted Testerというテスターのメールアドレスを明示的に指定し、彼らにのみ公開
  • <ドメイン>のすべてのユーザに公開

今回は社内向けということでドメイン限定の方が都合がよかったのでこの方法を選びました。 ドメインで縛りをつけて公開する方法は公式ドキュメントのこちらに書いてあるのでそちらを参考にしてください。

すこしハマった点

ドメイン限定にしたい場合は、管理者権限が必須

管理者ユーザの方にコンソール上から「Chromeウェブストアに公開することを許可する」を有効にしてもらわないとドメインの選択肢がでてきません。ドキュメントよく読めばわかることですが、よく読まないと？？？ってなります。

必須項目のスクリーンショット入れ忘れに注意

ウェブストアに公開にするには1点以上のスクリーンショットが必須らしいのですが、この項目入れないでも公開ボタンが押せます。この項目を入れなかった場合に、ポリシーに反しているよっていう自動メールと思わしきものが飛んできますがどう読んでも文章が繰り返しの表現とか誤解を招く表現とかしか書いてなくスクリーンショットの問題じゃないか気づくのに難儀しましたが現状そこ以外問題なりそうな点はないので間違いないかと。(※スクリーンショットが必須という点は入力時にフォーム付近にカーソルをあてたらhover?で注意書きがでてきます)

2, 3度失敗したら人力によるチェックに移るらしく数営業日待たされるそうです。

. . . . . . . . . . . .

そして私は今待っています。 （泣）

もし急ぐような場合などでは、管理者だと電話やチャットでのサポートが受けられるそうなので、相談してみるといいのかもしれません。

2017年の目標

other

2017年になりました。年始めということで「今年の目標」と「エンジニアをすることについて」を書こうと思い筆を取った次第です。

今年の目標

の３つになります。

出勤日は毎日ブログを書く

昨年の終わり頃に書いたブログは200日以上ぶりという感じで、「|'-') 今年一年何してきたか振り返れないやん？」みたいな気持ちになったし、対外的に見ても何してるかよくわからない人に見えたと思うので、今年はアウトプットしていこうという気持ちです。このブログはその初めということで。

また出勤日という括りにしているのは自分のルーチンとして生活に組み込みやすいからという意味以外はないです。

個人でwebサービスを一個作る

これは去年他の人のwebサービスを作成したのだけれど、それを経て自分もつくりたいなっていう気持ちからやろうと思った次第。

基本情報技術者試験を受けてみる

エンジニアとして今年で5年目になるのだけれど、基礎的な知識で自分がわからないところを明確にするために受けてみようかなという試みです。とりあえず有名な柏木先生の本を買ったのだけれど早速わからないところがあって何とも言えない気持ちになった！

新しい知識を学ぶ機会だと切り替えて引き続き頑張る

エンジニアをすることについて

今年も改めて自分がエンジニアをすることについて簡単に振り返ると、

  • ものづくりが自分でできる楽しみ
  • 学ぶべきこと多くて成長しかない

以上の２つかなと思います。

ものづくりが自分でできる楽しみ

やっぱり真剣にものづくりするのがすごく楽しいし、そういった環境に近い場所にあるエンジニアという職業は楽しみしかないなというところにつきます。自分で頑張った分だけスキル・できることも増えるし、努力した分だけより多くの表現ができるようになるのは楽しいかなと。

学ぶべきことが多くて成長しかない

この業界に身をおいて5年目ですが、自分がまだまだわからないことあるのにどんどん新しい面白い技術がでるので、常に新しいことに触れている感じで常に成長できるのではみたいな感じが面白い。頑張って成長するように努力はするけど、自分よりすごい人たくさんいてもう我以外皆我師みたいな感じで常に合掌して学ばせてもらっております。

以上です。 本年もよろしくお願い致します。

勤怠のChrome拡張を作った

programming

会社の出勤時にいつも

Chrome起動 -> ブックマーク開く -> 勤怠のページ開く -> 出勤ボタンを押す

としていてこの操作に20秒 ~ 30秒ぐらいかかっていた。会社の出勤時間ギリギリでついた時とかこの時間がちょっと煩わしくてChrome拡張を作った。Chrome拡張にしたことで

Chrome起動 -> 拡張ボタン押す -> 出勤を押す

になったので10秒ぐらいで出勤処理ができるようになった。

毎日のストレスちょっと減ったし、jqueryとか全くわからないけど少しわかるようになったし満足。

小さなチーム、大きな仕事【完全版】

books

誕生日のお祝いでカロリさんから頂いた「小さなチーム、大きな仕事【完全版】」を読んだ。

  • 小さいほうが総じて動きやすい
  • 素直に接しよう
  • 進んでやることみつけて手を動かす人が大事
  • 人をむやみに採用してもコストになるだけ。必要な人を考える

以上の点が印象的だった。

本に書かれた内容自体は概ね共感できるし、実体験から書かれたいい本だった。この本と出会うきっかけをくれたカロリさんに感謝です🙏

Railsでサーバー時刻を任意の時間にする

programming

Railsとかに限った話じゃなくて、開発中のサーバー時刻を任意の時間に変更したいといったことはよくあると思う。

そうかの有名なアニメ、「時をかける少女」でいうタイムリープをしたいということである。

タイムリープする方法は

  • アプリケーションの内部時刻を変更する
  • アプリケーションが動いているサーバー自体の時刻を変更する

以上のような方法があげられるがサーバー自体の時刻を変更するなんて恐ろしすぎるし、かつめんどくさいのでアプリケーションの内部時刻を変更するアプローチで、Railsのサーバー時刻を変更できるようにしてみた

実装方法

時間を操作する際に、よく使うモジュールでTimecopというものがある。このTimecopのread meでrailsで使う場合の方法も書いてある

# in config/environments/test.rb
config.after_initialize do
  # Set Time.now to September 1, 2008 10:05:00 AM (at this instant), but allow it to move forward
  t = Time.local(2008, 9, 1, 10, 5, 0)
  Timecop.travel(t)
end

read meより転載

と書かれていた。

例ではtest.rbで使うようにかいてあったけど、これをdevelopment.rbに書いてあげれば、developmentで起動しているときのみサーバー時間をいじれるはず。そこで以下のように書いてみた

# in config/environments/development.rb
config.after_initialize do
  if File.exist?("tmp/localtime") then
    localtime = File.open("tmp/localtime").read
    if !localtime.blank? then
      t = Time.parse(localtime)
      Timecop.travel(t)
    end
  end
end

tmp/localtimeというファイルをつくってその中にyyyy-mm-dd hh:mm:dd形式で時間を書いて、その時間を読み取ってタイムリープするといったコードです。(あんまり設定ファイルにごちゃごちゃ書くのもあれなんで切り出したほうがよいかも)

このlocaltimeの設定はrakeタスクで行うようにしていて、

# in lib/tasks/server_time.rake
namespace :server_time do
  task :mock => :environment do |t|
    set_time = ENV['RAILS_TIME']
    File.open("tmp/localtime","w") do |file|
      file.puts(set_time)
    end
  end

  task :reset => :environment do
    File.unlink('tmp/localtime')
  end
end

こんな感じに実装しました使い方はシンプルで bundle exec rake server_time:mock RAILS_TIME='2016-01-01 00:00:00'で設定して、bundle exec rake server_time:resetでリセットできます。