猶予8時間!脆弱性だらけのサービスを堅牢化する実践型研修

Speeeエンジニアの西岡(@nisshieeorg)です。

去る7/5(水)、Speeeでは社内の全エンジニア向けに、セキュリティ研修を実施しました。本研修では、株式会社リクルートテクノロジーズの西村宗晃様に講師としてお越しいただきました。この場を借りてお礼申し上げます。

f:id:nisshiee:20170718161021j:plain

続きを読む

Bit Journey社に留学してきました

こんにちは
UZOU事業部でエンジニアをしてます@hatappiです。

今回は僕が2016年の9月頃から約半年間株式会社ビットジャーニーさんに留学した時の話をしたいと思います。

留学の経緯

弊社は社内の技術力向上への取り組みとして、Rubyの開発に長けた協力会社の方や業務委託の方に現場の開発に入っていただいていたり、matzさんに技術顧問、そして今回の留学先であるビットジャーニー社代表の井原さんに開発部顧問、gfxさんに技術顧問として入っていただいています。
今回の留学はその技術力向上の施策の1つです。

留学といっても実際にビットジャーニー社で仕事をするのではなくgfxさんが弊社に常駐される日にあわせてリモートで一緒に開発を行いました。

留学内容

留学ではKibelaと呼ばれる情報共有ツールの開発を行いました。
主に開発したものは下のようなものです。

  • Reactを使用したviewの作成
  • Herokuによるレビュー環境の作成
  • インポーターの作成

これらを中の方にレビューしていただいたりgfxさんとペアプロをさせていただきながら開発を行いました。
もちろん開発を通して技術的なことを多く学んだのですが、今回はこんな技術を使ったよ!ではなく留学を通して今までやってきた開発の進め方などを見直す部分があったので、そちらにフォーカスしていきたいと思います。

やってみて思ったこと

Pull Request(PR)が丁寧

これは僕が留学した初日くらいに感じたことですが、PRの中身が分かりやすかったことです。
PRのディスクリプションには目的やったことが記載されており、ディスクリプションを見るだけでこのPRが何を解決するために出されたのか、それを実現するためにどんな変更をしたのかを知ることが出来きます。
さらにコード内で補足がいる部分についてはコメントもされてました。

この新しく入った人が分かりやすいPRになっているというのは重要なことだと思います。

今までの自分のPRを振り返ると、何を変更したかだけが記載されており目的が記載されていませんでした。
これは同じチームであれば変更を記載すれば背景は知っているだろうという認識でやっていたからです。
これだとレビュワー側はまずこのPRはなぜ出されたのかを考えないといけないのでレビューコストがあがってしまいます。
それからは第三者が見ても分かるようなPRを意識して出すようにしました。

この件に関しては下記のブログが参考になりました。
http://techlife.cookpad.com/entry/2015/03/30/174713 http://techlife.cookpad.com/entry/2016/08/17/111500

ユーザーとのコミュニケーションについて

私は今までは社内系のシステムを作成していたので、システムを使用するユーザーは全員顔の知っている人でしたがKibelaを通じて初めてtoCサービスに携わりました。
ユーザーからはKibelaの使い方から機能要望など様々な問い合わせがくるのですが、その時の要望についてユーザーが何を解決したいのかを聞いていたのが印象的でした。

これはtoCに限らずですが、要望はすべて受け入れることも出来ますが、プロダクトの思想から外れてしまうものが出来てしまう可能性もあります。
一方で仕様だから出来ませんと答えてしまうとユーザーからはそれ以上何も得られず終わってしまうのです。
これをユーザーから何を解決したいのかを聞くことで、別の解決方法などが見えてきます。

これはJob to be done(JTBD)と呼ばれ、よくマーケティング界隈で話として出てくるようです。
https://01booster.com/columns/blog/3918

アウトプット

情報を蓄積していくサービスだからというのもありますが、何かの意思決定や気付きなどが社内のKibelaに集約されており、開発を始める時に読むものやなぜこの技術選定をしたのかなどをKibela上からたどることが出来ました。
この1つのサービスに集約されているのは大切で何か困った時に探す時に役立つだけでなく、仮にそこになかった場合はすぐに直接聞くなどのアクションにエスカレーション出来ます。
これが色んな場所に分散しておいてあるとこの仕様はここに、図は別の場所になどに面倒なことになります。

週2の配分は大事

留学をはじめた頃は水、金で行っていたのですが、自社とのタスクを整理する難しさがありました。
やること自体はメモをしておくなどで整理が出来るのですが、自社と留学とで頭をスイッチしなければならないため、どうしてもスイッチングコストがかかってしまいました。
この解決はシンプルで木、金と連続した日にすることで解決しました。

最後に

一言で今回の留学を表すなら「楽しかった」です。
もちろん技術的な学びや今回書いたことのような気付きがあるのですが、大前提としてやって楽しいかどうかの感覚は大切だと思います。

留学を受け入れていただいたビットジャーニー社の方々には感謝しています。また今回留学することを承諾してくださった事業部の方にも感謝しています。
ありがとうございました。

留学は転職をせずとも自社と留学先と同時に2社比較し経験が出来る貴重な場なので広めていきたいです。

RSpec の feature spec でヘッドレス Chrome を使う

Speee エンジニア組織推進室の服部 (yhatt) です。

みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpecCapybaraPoltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。

そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。

そこで今回、社内プロダクトのRSpec における feature spec の実行環境を Poltergeist から ヘッドレス Chrome に移行しましたので、その手順をご紹介いたします。

PhantomJS (Poltergeist) の利用につきまとう問題

PhantomJS は古い Webkit をベースにしているため、最新の JS/CSS の機能に追随できていません。より厳密に言えば、PhantomJS は Qt のコンポーネントである QtWebKit を使用していますが、Qt ではすでに QtWebEngine に移行しています。

実際にあった例として、『ベンダープレフィックスの無い Flexbox を使ったら feature spec が落ちた』ということがありました。今回適用した社内プロダクトの開発では、対応ブラウザを限定できていた ため、実戦投入可能という判断で、ベンダープレフィックス無し Flexbox の採用に踏み切りました。

しかし、PhantomJS では『ただのブロック要素としてレンダリングされてしまった結果、すぐ下にあったフォームの上に覆い被さった』という現象が発生し、該当フォームのクリックを含む feature テストが落ちてしまいました。

f:id:yuki-hattori:20170615104248p:plain:w500

autoprefixer を入れて対処するという選択肢もありましたが、CI のためだけに対応バージョンを広げるのは本質的ではない解決策のため、ヘッドレス Chrome の採用に舵を切りました 。

安定版の Chrome をテスト環境に採用することで、『よりエンドユーザーの環境に近い状態でテストを回せる』というメリットもあります。

ヘッドレス Chrome への移行

もしすでに Capybara を使って feature spec のテスト環境を導入していれば、ドライバを変更するだけで実行環境を変更できるので、移行自体はそんなに難しくありません。

以下、『Poltergeist による feature spec テスト環境が導入されている』という前提に基づいて説明していきます。

selenium-webdriver gem を導入

まず、Capybara で feature spec を実行するドライバを Poltergeist から Selenium に変更します。

 group :development, :test do
   gem 'rspec-rails'
   gem 'capybara'
-  gem 'poltergeist'
+  gem 'selenium-webdriver'
   ...
 end

Gemfile を編集したのち、bundle install を実行してください。

capybara + selenium-webdriver の構成は、Rails 5.1 から標準構成になりました ので、新規に Rails アプリを作った場合、この 2 つの gem は特に意識せずとも入っているはずです。

Capybara のドライバ設定で ヘッドレス Chrome を使う

続いて、Capybara のドライバを Selenium 経由で ヘッドレス Chrome を使用するように設定します。

Poltergeist の設定を外した上で、spec/support/capybara.rb に以下の内容を記述します。

require 'capybara/rspec'
require 'selenium-webdriver'

Capybara.register_driver :selenium do |app|
  Capybara::Selenium::Driver.new(app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      chrome_options: {
        args: %w(headless disable-gpu window-size=1680,1050),
      },
    )
  )
end

Capybara.javascript_driver = :selenium

※ 事前に spec/rails_helper.rb の23行目 にある Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f } がコメントインされていないと、正しく動作しません。

chrome_optionsargs 1 に、headless というオプションが含まれているのを確認してください。ヘッドレス Chrome ことはじめ  |  Web  |  Google Developers によると、現在の最新安定版である Chrome 59 では disable-gpu オプションも必要です。

ウィンドウサイズは必須ではありませんが、レスポンシブなコンテンツなどにおいては挙動が変わってしまう可能性もありますので、テスト環境を揃えるために指定しておくことをお勧めします。

テスト実行環境に ChromeDriver を入れる

テストを実行する前に、忘れずに ChromeDriver を入れておきましょう。最新バージョンの 2.30 が Chrome 59 に対応しています。

macOS ユーザーであれば、Homebrew で導入しても構いません。

$ brew install chromedriver

テスト実行

以上で、ヘッドレス Chrome で feature spec を実行する準備ができました。試しに js: true のテストだけ、狙い撃ちで実行してみましょう。

bundle exec rspec --tag js

実行中は Chrome のインスタンスが立ち上がり、macOS 環境の場合、Dock にアイコンが表示されることが確認できます。

f:id:yuki-hattori:20170615095247g:plain

無事テストが通れば万々歳ですが、現実的には、修正が必要な箇所(=Poltergeist では動くが Selenium で動かない箇所)も少なくないと思いますので、そのようなテストは少しづつ潰していきましょう。例えば、以下のようなテストに要注意です。

  • ドライバ固有のメソッドをテスト中に使用している
    • テスト中に driver を直接使っていたら注意!
  • ウィンドウ関連の操作
    • 新規ウィンドウを開く、リサイズするなど
  • モーダル関連
    • window.alert() window.confirm() など
    • 現時点では Capybara を適切に設定にすることで回避可能 1
      • [2017/06/19追記] Capybara 2.14.3 のリリースにより、ほぼ問題は出なくなりました

ヘッドレスモード中にスクリーンショットを撮る

Chrome 59 のヘッドレスモードで、Capybara の #save_screenshot を使用してスクリーンショットを撮影しようとすると、1x1 の何もない画像が撮れてしまいます。

f:id:yuki-hattori:20170615095522p:plain:w500

これは Chrome 側の問題のようで、以下の Issue を見る限り、既に解決している模様です。

この変更がリリースされるまでは、『スクリーンショットを撮るときは ヘッドレスモードを OFF にする』というのが暫定対策となりますが、待てない方は Google Chrome Canary をテストで使用すると良いでしょう。2

Google Chrome Canary をテストに使用する
Capybara.register_driver :selenium do |app|
  Capybara::Selenium::Driver.new(app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      chrome_options: {
        args: %w(headless disable-gpu window-size=1680,1050),
        binary: '/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary',
      },
    )
  )
end

binary で、実行する Chrome のパスを指定することができます。上記は macOS 環境での例です。

一応、Canary は 常に更新され続ける(毎日更新される)開発版を使用することになる ので、安定版とは挙動が異なる可能性もあることに注意してください。

ベンチマーク

簡易ですが、rspec --tag js -p コマンドにてベンチマークをとってみました。対象は 12 examples の小規模なプロジェクトで、Chrome は安定版 (59) を使用しています。

環境 rspec コマンド実行時間 examples 実行時間
Poltergeist (PhantomJS) 17.81 sec 11.65 sec
Selenium (Chrome 59) 22.75 sec 15.97 sec

rspec --tag js -p を 5 回試行した平均値
※ examples 実行時間 = Total time - files took seconds to load

Poltergeist + PhnatomJS に比べて、ヘッドレス Chrome は コマンド全体で 約 1.37 倍の時間増 となりました。

ヘッドレス特化ブラウザ → フルブラウザ による時間増は仕方ない部分もありますが、体感では、#visit#click などによる ページ遷移 で速度差を感じることが多かったです。例えば、4 回のページ遷移を含む example では、2.71sec (PhantomJS) → 4.32sec (Chrome) と、約 1.59 倍 にまで遅くなりました。

ユニットテストが中心で、E2Eテストがある程度絞られている 小規模〜中規模のプロジェクトだと 気にならないかもしれませんが、大規模なプロジェクトで E2E テストが多く書かれている場合、この時間増がけっこう響きそうです。

まとめ

RSpec の feature spec をヘッドレス Chrome へ移行する手順について解説しました。

これまでも Xvfb を使うことで、実際のブラウザを使ってヘッドレスに自動テストができましたが、今回のヘッドレスモードの実装で、CI でも開発環境でも、より簡単にヘッドレスなテストが実現できるようになり、ハードルが随分下がった印象を受けました。

また、Firefox にもヘッドレスモードが搭載される予定 のようで、今後の E2E テストは、エンドユーザー向けのブラウザを直接動作させる形に収束していくのでは? と思っています。

それでは良き E2E テストライフを。

参考記事


  1. [2017/06/19修正] 初稿では、 args がハッシュロケット記法になっていました。Capybara 2.14.2 時点では、Capybara の ヘッドレス Chrome 判定が特定の構造の Hash しか受け付けない ようになっており、Symbol キーにしてしまうと accept_confirmdismiss_confirm の挙動に影響が及ぶ(該当 Issue comment…)ためです。この問題は 2.14.3 で修正されています。該当 Commit…

  2. Chrome は ベータ版 や開発版も提供していますが、既存の Chrome 安定版を上書きする上、戻すのも面倒なので、開発環境での導入はあまりお勧めできません。Google Chrome Canary であれば、安定版と共存することが可能です。

roppongi.rb #3 "Rails x Frontend-Tech" まとめ

Speee技術顧問の id:gfx です。 2017/05/31 に Roppongi.rb #3 開催のためSpeee Loungeを提供いたしました。私も「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」と題した発表をしましたが、普段使っているReactベースの環境とはまたったく別のAngualrやRiotなどの話を聞けましたし、大変すばらしい勉強会だったと思います。

セッション

オープニング by toshimaru

オープニングでは、主催者の @toshimaru_e さんからの挨拶に変えてRailsフロントエンド技術の今とこれからについてのエントリの紹介がありました。

Railsフロントエンド技術の今とこれから - Hack Your Design!

Rails x Frontend は今後ますます重要になっていく技術なので、上記エントリはいいまとめですね。

RailsエンジニアがReactを始めてSSRとReduxを導入するまで by gfx

私の発表で、最近のKibelaのフロントエンドで実践していることについて話しました。詳しくは次のエントリをご覧ください。

登壇エントリ: Roppongi.rb #3 で「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」という発表を行いました - Bit Journey’s Tech Blog

社内で初SPAをAngularで完成させるまでとその後 by hatappi

弊社のエンジニアである@hatappiさんによる発表で社内でAngularでSPAを作成した話でした。 詳しくは次のエントリをご覧ください。

『社内で初SPAをAngularで完成させるまでとその後』という話しをRoppongi.rbで話してきた - hatappiのブログ

Universal JavaScript by mizchi

mizuchiさんによる発表でした。Sprocketsの殺し方やこれからのJavaScript bundle技術の行く末などに関するお話でした。nativeのES modulesがブラウザに実装されるとwebpackが廃れてるだろうという予言は私も同意します。

Universal JavaScript // Speaker Deck

片手間JS on Rails by tricknotes

tricknotesさんによる発表でした。フロントエンドのビルドツールは多様過ぎるし進化も早すぎるというのはよくいわれることですが、作るもの次第ではRails標準のSprocketsもそんなに悪くないよという話でした。実際のところ、KibelaでもSprocketsはまだまだCSS周りでも使ってますし、適材適所というのは本当にそのとおりだと思います。

片手間JS on Rails

そのSPA、本当に必要ですか? by nishaya

弊社エンジニアのnishayasさんによる発表でした。nishayaさんもSpeeeのエンジニアです。SpeeeのエンジニアのひとりはSPAを作った話をし、もうひとりは無闇にSPAにすべきでない話をするという結果になりました。攻めてますね。もっとも、「軽い気持ちでSPAに手を出さない」というのは私も同意します。

そのSPA、本当に必要ですか? // Speaker Deck

ReactをやめてRiotに移行した話 by pompopo

pompopoさんによる発表でした。Reactはデザイナとの協業が難しけどRiotだとデザイナに抵抗感少なく触ってもらえるというのが移行の理由ということですが、確かにそのあたりはReactの課題だとは思います。Reactを使い続ける場合でも、React Storybook のような仕組みを整備して抵抗感なく触ってもらえるなどの工夫が必要かもしれないですね。

ReactをやめてRiotに移行した話 // Speaker Deck

【PR】Speee Loungeについて

SpeeeではラウンジをIT技術に関する勉強会や交流会のために貸し出しています。詳しくは次のエントリをご覧ください。

Speee Lounge 会場貸出について - Speee DEVELOPER BLOG

勤怠打刻機をRaspberry Pi 14台で本気で作ってみた

こんにちは、プロジェクト推進室でエンジニアをやっている 山本 (id:bino98) です。

毎日のお勤め、お疲れ様でございます。皆さまが、日々の業務を行われる合間に

  • 有給休暇を取得したり
  • 遅刻の連絡をしたり
  • 出張の申請を行ったり…。

様々な場面で自身の勤怠をその組織のやり方で管理されていると思います。弊社では、今年4月初頭から 社内で開発した新しい勤怠管理システム「 SpeeePORT 」による勤怠管理が始まりました。

弊社の新しい勤怠管理システム(以下、PORT)に関する詳しい記事は、ITproさまがこちらの記事にまとめてくださいましたので、ご覧頂けますと幸いです。

今回、PORTの ウリ の1つの 打刻機 について、まとめました。Raspberry Pi で打刻機を作りたいという、結構ニッチな要求を持つ方のお役にたてれればと思います。

Raspberry Piで打刻機を内製した経緯

こちらの記事にあるように、打刻忘れの問題は以前から発生していました。PORTを利用前の勤怠管理システムでは、出勤・退勤打刻をWebブラウザ上で行う必要がありましたが、その存在は忘れられがちだったのです。

打刻が忘れられないように、ICカードによる打刻の実現が社内で強く求められ、 アップデートされてきた弊社の新しい勤怠制度に適合できる勤怠管理システムを内製で開発することとなりました。

Raspberry Piを利用した理由は、

  • 安価で入手容易である
  • 自分たちの用途に応じてカスタマイズできる
  • PasoriとRaspberry Piを連携された事例がインターネット上に存在する

などの理由で使用することを決めました。

打刻機の利用方法

まず、打刻機の種類の話からですが、PORTでは2種類の打刻機を用意しています。1つは、打刻機。 f:id:bino98ty:20170605101952j:plain

もう一つは、打刻登録機です。 f:id:bino98ty:20170605102119j:plain

打刻機を利用して、勤怠打刻を行うためにはユーザには下記のフローを実施してもらいます。

  1. 個人や会社で利用している 交通系ICカードを用意 してもらう
  2. 打刻登録機 にICカードをタッチしてもらう
  3. 画面にQRコードが表示されるため、手持ちのスマホ等で読み取ってもらう
  4. 読み取ると、カードの登録がされる*1ため、あとは 打刻し放題 になる

打刻登録機はカード登録時に必要ですが、頻度はきっと多くないはず。普段使いの打刻にはディスプレイもキーボードも不要ですね。故に、普段は極力小型で、低コストで量産できるRaspberry Piを用いた打刻機を利用してもらっています。

ピッとすると打刻される仕組み

f:id:bino98ty:20170605110135p:plain

打刻機と打刻登録機は実は使用しているアプリケーションは同じです。まず、Pasori*2を利用するためのライブラリnfcpyをPythonを利用した読み取りプログラムを記述し、そのプログラム上でPORTのAPIに打刻リクエストを送信します。カードが未登録の場合はその旨のレスポンスが返ってくるため、打刻機側でそれを解釈し、同一リクエスト内に含まれるワンタイムURLをQRコードにして、イメージファイルとして保存しておきます。打刻機の場合は、ここまでです。

打刻登録機の場合は、発行されたQRコードを表示するためのプログラムも起動しており、node + expressで動かしてます。nodeでは、QRコードが保存されるディレクトリを常に監視し続け、ファイルに変更があれば(すなわち、QRコードが新たに発行された場合)画面を再描画するような仕組みになっています。

十数台の打刻機があるとたまにサボるやつが居るものだ

Raspberry Piを用いた打刻機ですが、不意に停止してしまうことがあります。例えば、

  • WiFiとのコネクションが切れたまま、復旧せず打刻できなかったり。
  • 一定以上使われないと勝手にプロセスが閉じて打刻できなくなったり。

打刻をするタイミングは朝出社前がほとんどであり、その時間帯に「 打刻機動かんけど、どうなってるの? 」などとお問い合わせを受けると、なかなか辛くてお腹が痛くなると思います。

そこで、PORTの打刻機には監視プログラム、自己診断送信プログラム、再起動プログラムの3つの仕組みを作って対応しています。

監視アプリケーション

監視プログラムでは、読み取りプログラムと表示プログラム、自己診断送信プログラムの3つのプロセスが生きているかを監視し、生きていなかった場合再起動させます。これによって、例えばプログラムに不調が出ても、「Pasoriを一度取り外してもう一度打刻機に接続したらプログラムが正常に動く*3」状態を実現でき、万が一朝に問題が合っても利用者自身で打刻機のプログラムを再起動できるようになっています。

自己診断送信プログラム

自己診断送信プログラムでは、プロセスの状態やインナーIP、GitHubのリビジョンなどを定期的にAPIに送信し続けます。PORTには打刻機監視画面があります。その画面に、このプログラムから送信されてきたデータを基に打刻機が稼働しているか、異常が発生しているかの診断を行い、画面に表示させています。

f:id:bino98ty:20170605112625p:plain

万が一、打刻機が停止している場合は、Slackにその旨のアラートを飛ばし、山本が飛んで直しに行きます。

再起動プログラム

再起動プログラムでは、1時間に1度、読み取りプログラム、自己診断送信プログラム、表示用プログラムの3つを終了します。長時間プロセスを起動し続けると、時たまゾンビプロセス化するプログラムがあるため、定期的に終了しています。しかし、上記の監視プログラムがプロセスを監視しているため、自動で再起動します。

ユーザにどうやって打刻成否を伝えるか

打刻機にはディスプレイがないが、どのように打刻の成否を伝えるか。肝は です。スピーカーはディスプレイよりはるかに安価に調達できますし、打刻機から返されるレスポンスは、ディスプレイほどの情報伝達力を必要としない量のため採用しました。

スピーカーは、100均のモノラルスピーカーを利用するか、 アンプ内蔵のお手製スピーカー を利用します。100均で売られているスピーカーを使うと、Raspberry Piから音を最大音量で出力ししても、ちょっと音が小さいのです。そのため、アンプ内蔵のスピーカーを打刻機を設置する場所によっては採用しています。

アンプ内蔵のスピーカー

安価なアンプ内蔵のスピーカーは、その当時調べた限り、見つけることができませんでした。なので、こちらのパワーアンプキットと、こちらのスピーカーを調達し、自前ではんだ付けし、使っています。現実的な音量になるため、全ての打刻機をこのタイプにしたいのですが、できればはんだ付けしたパーツは使いたくないところ…(打刻機運用の引き継ぎのハードルが途端に上がる)。アンプ内蔵のスピーカーを探しているところです。

f:id:bino98ty:20170605114147j:plain f:id:bino98ty:20170605102237j:plain

音のユーザ体験

また、打刻音にもこだわりが。

当初、打刻音は 打刻成功時に一度「ピッ」となるだけ でした。しかし、打刻成功時だけではレスポンスが帰ってくるまでの1〜2秒を長く体感される方が社内には多く(と思うと、鉄道の改札機ってマジリスペクトするぐらい早く ピッ となってくれますよね)、API側でリクエストの負荷のかかる部分をメッセージキューイングさせ、応答時間そのものを早くしたり、プレ打刻音をならしたりして、ちょっとずつユーザ体験の質の向上を実施してたりします。社内で作っていると、すぐにユーザの反応を受け取れるので、やりやすいです。

無機質な電子工作感を脱したい

また、Raspberry Piをそのまま執務室エリアに置いておくと、いかにも電子パーツ感があるため、インテリアしづらいと思います。その電子工作感をなくすため、また100均でケースを買い込み、スプレーニスと電動ドリルで箱を作ってケースを作ったりしました。

f:id:bino98ty:20170605115817j:plain

チーム内でダサいという意見が頻出したため、このケースは採用されませんでした。 レゴでケースを作ったり、3DCADでモデリングしてたりしますが、まだどうするかは未定です。(Raspberry Piを包み込む人形を作るのはどうかという話もあります)

まとめ

内製で勤怠システムを作ったり、打刻機を制作することで、より弊社のニーズに合うプロダクトを作ることができ、ユーザが近いのですぐにその反応も伺えます。もっと簡単に勤怠管理できる日を目指して、引き続き改良を進めていきます。ご覧いただきありがとうございました。

*1:QRコードはカード登録用のワンタイムURLを発行しています。読み取ると、PORTにログインしているユーザのカードとして登録される仕組み

*2:PORTで利用しているICカードリーダー

*3:Pasoriを外すと例外を吐きプログラムが終了するようになっているため