読者です 読者をやめる 読者になる 読者になる

ravelll の日記

よしなに

2016 -> 2017

あけましておめでとうございます。今年もよろしくお願いします。

去年の感想やまとめと今年の気持ちエントリです。

2016 と 2017

2015年の7月まで8ヶ月ほど休職し、フルタイムの仕事に戻ったのは去年の2月で、2016年はリハビリ期間という感じだった。

一時は本当に社会復帰できるのか、アルバイト生活になるのでは等々考えていたものの、多くの人に助けてもらいなんとか復帰することができた。感謝しております。

復帰後は後輩の開発サポートから始まり、大きめな機能開発を担当したりWEB+DBへの寄稿機会をいただけたり4万人以上が使うアプリケーションの稼働言語のバージョンアップを単独で任せてもらったり(これはまだ終わってない)と、それなりに立ち回ることができた。

またメンタリティについて、"自分がどうなりたいか" を基準に行動選択できるようになってきたのは大きな変化だったと思う。これまでは周囲の凄く見える人達を見ては無闇に自分と比較し、自身の成果を蔑んで自己肯定感を失いがちだった。

一方で睡眠障害との付き合いはずっと変わらず頭を痛めているところ。

これについては、その日の体調に合わせて出社時間や勤務時間を調整できればストレスを減らせ、余計な悩みで学習が阻害されることも減り、パフォーマンス上昇最高じゃん、という見解があるので2017年中に何らかの方法でフレックスや裁量労働の勤務形態で働ける状態にしようと思っている。

睡眠障害の云々を除いても、多少出社時間がズレても進捗に影響しない業務にあたっている中で、市役所や病院に行くために給与を削って遅刻したり有給を取得したりすることに馬鹿らしさを感じていることも理由にある。

それも含め、2017年は身辺の変化が色々起こる見込みだけど、2016年にできた成長を大きく上回って成長したいと強く思っている。

テーマは「できないことはやらない」と「結婚しても困らない年収にする」の二本立て、やっていくぞ!!!

読書

読了したものが31冊、途中まで読んだものが15冊くらい。読了したものの過半数が漫画。全然読めてないなと思う。

技術書は途中で移ろいがちだった。移ろうことが必ずしも悪いとは思わないけど、1分野くらいはどしっと腰を据えて深い知識を付けるべきだったように思う。結構な頻度で移ろってしまった。

PHPデザインパターンの学習を進めているので、ひとまずこれを集中・継続していこうと思う。成功体験を得たい。

日本酒

お店や人の家で飲んだものは記録漏れが多くあるので自宅で飲んだものに絞ってリスト。

思ったより飲んでなかった。

今年始めて飲んだ銘柄では特に風が吹くや百春、死神が美味しかった。別の造りのものも飲んでみたい。

その他では花陽浴や王祿は安心の美味しさで最高だった。あと奈良萬の酒未来には1升3000円弱でここまで美味しいお酒があるのかと驚かされたことを覚えている。

余談だけど2016年は恐らく10回以上飲んだあと記憶を飛ばしたので、2017年は飲み方を改めたいと思っている。

"品質" ってなんだろう?

このエントリは pepabo Advent Calendar 2016 の23日目のエントリです。

前日のエントリは @Asuforceペパボのエンジニア研修を通しての成長体験 でした。

彼がアルバイト入社していたとき僕がメンターについていたこともあって、エントリを読んで子の成長を見る親のような気持ちになりました。

さて今日はソフトウェアの品質についての話です。ところで僕に子供はいないですし既婚者でもないです。

"品質" ってなんだ?

我々ソフトウェアエンジニアを始めシステムの提供者はみな、提供するシステムの品質を高めたいと思っていることでしょう。しかしながら、"では品質とは何なのか" と尋ねられたとき、答えに窮する人も少なくないのではと思います。品質の不理解は、提供者にとっては高い品質で提供しているシステムが利用者には低い品質とみなされる、といった不幸な認識のズレに繋がることが考えられます。

ここで、品質について何らかの分類モデルがあれば、システムの機能を分類した上でそれぞれをカバーするに適当なチームを構成したりタスクを割り当てたりすることができそうです。そこで今回は、ISO/IEC 25010:2011 で規格化されている "製品品質モデル" を紹介しようと思います。

ISO/IEC 25010:2011 の製品品質モデル

この国際規格では、システムの品質を "システムが様々な利害関係者の明示的ニーズ及び暗黙のニーズを満足している度合い" とし、8つの品質特性、更に各品質特性における副特性に分類しています。

以下の表に品質モデルの品質特性とその説明、属する副特性をまとめます。副特性の説明までまとめると長くなるので省略しています。各特性の説明についてはこちらより引用しています。

1. 機能適合性

明示された状況下で使用するとき,明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い。

  • 副特性: 機能完全性、機能正確性、機能適切性

2. 性能効率性

明記された状態(条件)で使用する資源の量に関係する性能の度合い。

  • 副特性: 時間効率性、資源効率性、容量満足性

3. 互換性

同じハードウェア環境又はソフトウェア環境を共有する間,製品,システム又は構成要素が他の製品,システム又は構成要素の情報を交換することができる度合い,及び/又はその要求された機能を実行することができる度合い。

  • 副特性: 共存性、相互運用性

4. 使用性

明示された利用状況において,有効性,効率性及び満足性をもって明示された目標を達成するために,明示された利用者が製品又はシステムを利用することができる度合い。

  • 副特性: 適切度認識性、習得性、運用操作性、ユーザエラー防止性、ユーザインタフェース快美性、アクセシビリティ

5. 信頼性

明示された時間帯で,明示された条件下に,システム,製品又は構成要素が明示された機能を実行する度合い。

  • 副特性: 成熟性、可用性、障害許容性(耐故障性)、回復性

6. セキュリティ

人間又は他の製品若しくはシステムが,認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように,製品又はシステムが情報及びデータを保護する度合い。

  • 副特性: 気密性、インテグリティ、否認防止性、責任追跡性、真正性

7. 保守性

意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い。

  • 副特性: モジュール性、再利用性、解析性、修正性、試験性

8. 移植性

一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い。

  • 副特性: 適応性、設置性、置換性

特性の多様さを見ると、単一の職種でシステム全体の品質を担保することが如何に難しく、エンジニア、デザイナー、ディレクターなど複数の職種が各々の責任範囲を認識し協力しあうことが品質の向上には欠かせないと分かります。

また、セキュリティのように、チームの単位ではなく会社全体の規模で取り組む必要がある品質特性もあることが分かりますね。

まとめ

このエントリではシステムの品質とは何か、というテーマで ISO/IEC 25010:2011 の製品品質モデルを紹介しました。

明日の担当は @udzura さんです。楽しみですね!!!

book

ここ1〜2ヶ月で買ったり読んだりした本たち。

どうしても複数の本をその時々の気分で読み進めてしまって、相変わらず読み途中の本が複数ある。

読了

のみじょし 3 (バンブーコミックス)

のみじょし 3 (バンブーコミックス)

漫画はシュッと読める一方で財の摩耗も大変スムーズなので安易に開拓しないよう気をつけてる。

途中

The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering

The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

JPEG・MPEG完全理解

JPEG・MPEG完全理解

パーフェクト PHP は2周目。入社1年後くらいに一度ざっと読んだとき以来で、PHP の基礎を固めたい気持ちになりじっくり読み返してる。

人月の神話は原著しか電子版がないので原著を読んでる。英語がスラスラ読めるわけではないので鈍行です。

積読

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

社の Slack でちらりと話題に挙がり、調べてみたら面白そうだったので。

今は会社では Rails アプリにほとんどコミットしてないんだけれど、数少ない馴染みあるフレームワークなので継続して触れていきたい。この本はもうしばらく前に出たんだけどね。

Let's Encrypt を利用して ravelll.org を HTTPS 化した

tech

f:id:ravelll:20161124121117p:plain

Amazon EC2 上で動かしている自身のポータルサイトを Let's Encrypt を利用して HTTPS 化したので手順をメモ。思った以上に簡単にできてびっくりした。


まず Let's Encrypt のクライアントを入手し、証明書を取得します。 Amazon Linux は公式にサポートされていないので実行には --debug フラグが必要です。 実行してしばらくすると term of conduct に従うか聞かれるので yes を選択。

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
./certbot-auto certonly --standalone -d ravelll.org --debug

次に暗号鍵を交換する際に使われる DH パラメータの設定ファイルを生成します。 鍵長は 2048 bit で。

sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl dhparam 2048 -out dhparam.pem

後は生成した証明書を利用したり脆弱な暗号化スイートやプロトコルを利用しないようにしたりすべく nginx.conf を編集します。 自身では以下のようにしました。

server {
  listen 80;
  listen [::]:80;
  return 301 https://$host$request_uri;
}

server {
    server_name 'ravelll.org';

    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_session_timeout 5m;

    ssl on;
    ssl_prefer_server_ciphers on;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_certificate /etc/letsencrypt/live/ravelll.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ravelll.org/privkey.pem;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/ravelll.org/fullchain.pem;
    resolver 8.8.8.8;

    ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!EXPORT:!DES:!3DES:!MD5:!DSS:!aNULL:!eNULL;

    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains;';

    location / {
      root /var/www/;
      index index.html index.htm index.php;
    }
}

nginx を再起動すると、正常に https 接続ができ、http ページへのアクセスが https ページにリダイレクトされることが確認できた。

QALYS SSL LABS の SSL 脆弱性テストをやってみると無事 A+、めでたい!

https://www.ssllabs.com/ssltest/analyze.html?d=ravelll.org

References

"【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜" にてトークしてきました

event presentation tech

ウェブ接客プラットフォーム Karte を運営する株式会社プレイドさんと合同で行われた勉強会 "【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜" にてトークしてきました。

プレイドさんのテックブログにも開催エントリが公開されています。

tech.plaid.co.jp

今回は自動テストと CI がテーマということで、ペパボの CI 環境におけるプロダクトの変遷や drone.io を使った現在の構成、開発現場での利用事例について話しました。

speakerdeck.com

自身のトークについて書くと、今回のトークは20分の枠で、実は過去最長の枠だった(それまで過去最長は YAPC::Hachioji と修論発表の15分)。加えてペパボで drone.io が運用され始めた頃は休職していて導入フェーズの事情をあまり知らなかったり、drone.io の構造や仕様にも明るくなかったので発表が決まってから結構焦っていた。更に開催1週間前に初めて30分のトークセッションも任されていることを知り、心労が凄かった。

それからは当時の Issue を漁ったり drone.io のソースを読んだり社内の有識者にあたったりしつつ、比較的早い時期から資料作成にあたった。おかげで発表もトークセッションはそれなりに上手くこなせたと思うし、質疑応答や懇親会での会話も盛り上がって良かった。

他の方々のトークもどれも面白くて、E2E テストの高速化や安定化はどこも課題になっているんだな〜という学びもあった。同僚の @NAKANO_Akihito さんが話していた xUnit Test Patterns も全く知らず、興味深かったので内容を伺ったりした。発表者と同じ場にいるとあれこれすぐ聞けて便利ですね。

ありがたい機会や会場を提供いただいたプレイドのみなさま、ありがとうございました!お疲れ様でした!

IIDX 23 copula まとめ

game

f:id:ravelll:20161105235029p:plain f:id:ravelll:20161105235036p:plain f:id:ravelll:20161105235041p:plain

プレイの頻度とかモチベーションについてどういう経過があったのか全然覚えてないんだけれど、稼働初期にガッとやって途中3ヶ月くらいほとんどやらない期間があって稼働終了までちょいちょいとやってた感じだったと思う。まさか前作より回数増えるとは思わなかった。 多分 DP より SP の方がやや多くプレイしていて、おかげで DP が前にも増して下手になった。残存した全一は多分30曲くらい、意外と残った。

SINOBUZ は稼働して早1週間以上が経ってるわけだけど、特にやる気が出たりはしていない。あと最近知人からコントローラーを譲って(無料ではない)いただいて、大小問わずゲーセンに行って満たしていた IIDX 欲も多少は家で満たせるようになったので前作以上にプレイ回数が落ち込む気がする。いよいよ今作は全一が1曲も残らず終わるんじゃないだろか。

とは言え、ゲーセン繋がりの知人との交流が薄れるのは寂しいので、少なくともちょいちょいとは各所に顔を出していきたい気持ちです。

最強 TODO リスト

1月前くらいにこのようなやりとりがあって、まだ何も出来てないんだけど、コンセプトについて1人ブレストしたときのメモが出てきたのでシェアします。


  • やりたいことを忘れない
  • やりたいことができる状況になったとき思い出せる
  • やりたいことが思いついても人間が記憶しておく必要がない
  • やりたいことを管理するために何かしたくない
  • いい感じのTODO提案してほしい
  • クソリプと紙一重
  • トド
  • トドゥー
  • TODO作るとSUZURIでTシャツプリントされて勝手に送られてきてTODOを着れる
  • TODO登録するとバックグラウンドでTODOが終わる
  • TODOと金額設定しておくと誰かがやってくれる
  • TODOと思わなくなる
  • 人生は一度切り
  • 明日できることは明日やる
  • TODOが大きいと細分化しろって怒ってくる
  • 小さく早く
  • なんでやるの?って聞いてくる
  • 内省することでTODOがTODOじゃなくなる