RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

メールディーラーバージョン12.2をリリースしました!

ラクスのメールディーラーの開発を行っている@nerobluebrosです。
5月9日にメールディーラーのバージョン12.2をリリースしました。

今回はそのメールディーラーバージョン12.2とリリースについての紹介をします。

バージョン12.2では33の機能と修正をリリース

12.2では大小合わせて33の機能と修正をリリースすることが出来ました。
主な機能と修正は以下のとおりです。

1.添付ファイルセキュリティオプション機能
 ・添付ファイルの拡張子と実際のファイルの内容をチェックします
 ・ユーザ単位で添付ファイルのダウンロード可否をコントロールできます
 ・期限付きのURLから添付ファイルのダウンロードができます
 ・添付ファイルのみを対象に自動削除できます
2.アドレス入力欄のUI変更などUI改善
3.ミドルウェアPostfixにすることでSTARTTLSに対応します
4.メール本文をRFCに準拠しました
5.不具合修正

リリースは複数回に分割して実施

以降はリリースについて説明します。リリースは複数回(複数日)に分割して行います。
理由は以下のとおりです。

・メールディーラーのサーバは複数台あり1日では終了しない
・メールディーラー内部のミドルウェアの変更があり、より慎重におこなう必要があった

リリース作業は深夜に実施します。
それはリリース中にメールディーラーのサービスが停止するからです。

「サービス停止が発生する=お客様がメールディーラーを利用できない」ということを意味します。
ですので、お客様の日常業務に影響しないように、夜間バッチが開始される朝の4時までにリリース作業を終了しなければなりません。

そのため、リリース作業によるサービス停止時間を極力短くするために、準備作業などは事前に実施しておきます。
リリース作業は「できるだけ遅い時間に開始」し「できるだけ早く終了」する時間との戦いになるので大変な作業です。

リリースについてはまた別の記事で詳しくご紹介します。

なお2回目は5月30日の深夜を予定しています。

以上でメールディーラーの12.2の機能とリリースについての説明を終わりにします。

おまけ

現在ラクスでは新卒採用と中途採用を行っています。
サービス開発に少しでも興味がある方は下記採用サイトをご覧になり、応募をおねがいします。

ラクス採用サイト
http://fresh-recruit.rakus.co.jp/

コマンド不要で超簡単!HerokuでWebアプリ開発を30分で始める【php+postgres】

こんにちは。エンジニアのmickey-STRANGEです。
前回はめんどくさがりによるめんどくさがりのためのスマホアプリ開発についてお話したいと思います。なんて言いながら、全てをJSでごりっと無理やり解決する方法をご紹介しました。 tech-blog.rakus.co.jp はい、タイトル詐欺です、すみません。冷静に考えて、この作りのWebページが世の中にない現状、これよりも簡単な方法が必ずあるはずなんですよね(当時サンプル書きながらコレめんどくさいな、なんて思ってないです)

今回はタイトル詐欺ではなく、Herokuというサービスを用いてWebアプリ開発の環境構築が本当に簡単に出来てしまう方法をご紹介いたします。

Heroku(へろく)とは

Herokuとは、PaaS(Platform as a Service)の1種で、アプリケーションの底にあるプラットフォームそのものを、Webを通じて提供してくれるサービスです。
今回の記事では、Heroku上でphp+postgresをプラットフォームとするWebアプリの構築、が目的となります。

Herokuで環境構築

Herokuを用いて、ということなのでHerokuのアカウント登録は完了している前提で説明を始めます。使用するのは以下の2サービスですので、アカウント登録まだだよ、という方はご準備ください。

  • Heroku

jp.heroku.com

github.co.jp

php+postgresアプリの作成

まず最初に、Heroku上にアプリケーションを作成します。ログインして右上NewからCreate New App、もしくはアプリケーションが1つもない場合は画面真ん中にあるCreate New Appをクリックします。

アプリ名を入力し、Create appをクリックします。これでアプリケーションが作成できました。
といっても、名前と枠組みだけの状態なので、これからphp+postgresで動くアプリケーションだという設定をします。

アプリケーションのページからSettingsAdd buildpackの順にクリックします。

立ち上がったポップアップの中でphpを選び、Save changesをクリックします。

これで作成したアプリケーションはphpで動きますよ、という設定が出来ました。

続いてpostgresを設定します。
ResourcesFind more add-onsからHeroku Postgresを探してクリックし、Install Heroku Postgresをクリックします。

Heroku Postgresはアドオンですので、料金プランの選択があります。というと身構えてしまうかもしれませんが、Hobby Devという無料プランがありますので、これを選択します。そしてpostgresを追加するアプリケーションを選択し、Provision add-onをクリックします。

以上で作成したアプリケーションをphp+postgresのアプリケーションであるという設定が完了しました。あとはソースをデプロイすればWebアプリケーションとして稼働する状態です。

デプロイソースの指定

続いて、ソースのデプロイ元の設定をご説明します。
ソースのデプロイ元として使用するのがGitHubになります。GitHubにデプロイ用リポジトリを作成し、直下にindex.phpをpushします。

今回作成したファイルは以下のものです。php+postgresが稼働していること、phpからpostgresに接続できていることの確認が目的なので簡単なものです。

今回もGitHubへのpushはGitHub Desktopを使用しました。直感でぽちぽちできるデスクトップアプリはやはり強いですね。
GitHub Desktop | Simple collaboration from your desktop

とはいえ、これでGitHub側の操作は終わりです。Herokuの画面に戻ります。
DeployGitHubSearchとクリックし、上記index.phpをpushしたリポジトリの隣にあるConnectをクリックします。

これでGitHubリポジトリからデプロイする設定が完了しました。HerokuからGitHubへの接続が初めての場合は、連携をするかどうかの確認が出ますので、表示されるとおりに進めていけばOKです。

最後に、Enable Automatic deploysDeploy Branchをクリックしましょう。
Enable Automatic deploysは自動デプロイの設定です。ブランチを指定して自動デプロイを有効にすることで、そのブランチにpushされるたびに自動でアプリケーションを最新のソースに置き換えてくれます。
Deploy Branchは手動デプロイのボタンです。アプリケーションの設定とデプロイ元の指定をしただけで、まだデプロイはされていません。自動デプロイを有効にしたとしても、初回だけは手動で行います。

ブラウザからアクセス!

これまでの手順で全ての準備が完了しました。実際に作成したアプリケーションにアクセスしてみましょう。
アプリケーションのページの右上にOpen appというボタンがあるのでクリックしてみましょう。

作成したindex.phpの通りに表示されました!
postgresのバージョンもphpから取得出来ているのでgetAttributeの代わりにSQLを発行して動きをつけていけば立派なWebアプリケーションになりますね。

個人的な感想として、postgresが10.3と最新に対してphp5.6がツッコミどころに思えて仕方がなかったのですが、phpのバージョンを指定する方法がちゃんと用意されています。画面から作っただけではデフォルト設定で作られる、といった感じでしょうか。composer.jsonに改めて指定することでphpのバージョン変更が可能です。
Heroku PHP Support | Heroku Dev Center

【補足】phpからpostgresの接続

ここまでアプリケーション稼働までの手順をご説明いたしましたが、1つだけ補足があります。

最初、phpからpostgresに接続するにあたって、接続情報の取り方に詰まりました。Herokuの画面上から確認は出来るのです。ですが、これだけ環境構築が簡単なのに接続情報はまったく関係ないサービスであるGitHub上のソースにべた書きで持つ、というところが引っかかりました。GitHub上のソースを見れば他の人のアプリのDBにアクセス出来てしまいます。
調べたところ、postgresをアプリケーションに追加したときに、環境変数に追加されているようで、そこから取得する方法が、上記のindex.phpの記述になります。
Heroku Postgres | Heroku Dev Center

終わりに

今回はタイトル詐欺ではなく、めんどくさがりでもすぐにWebアプリ開発が出来る手順の記事になっていると思います。

Herokuを初めて使ったのですが、とても簡単で驚きました。調べるにも公式ドキュメントが多いので、詰まってどうしようもなくなるということはありませんでした。
タイトルの30分というのも嘘ではなく、「よし、やるか」と思い立ってHerokuのアカウントを作成してから、特に調べるでもなく直感でぽちぽち画面を操作して、phpinfo()を画面に出すまでの時間がそれぐらいでした。本当に簡単です。
コマンド要らずの設定の簡単さも素晴らしいのですが、特にpushからの自動デプロイがめんどくさがりの心にかなり響きました。

気を付けないといけないところは、前回の記事で作成したアプリはアクセス者本人の画面にのみデータが表示されるのに対し、Herokuは通常のWebアプリになりますので、脆弱性のあるサービスを公開してしまうと攻撃の踏み台として使われてしまう可能性があります。アプリの作成、公開は気を付けて行いましょう。

さて、これにて今回の記事は終わりとしますが、前回のタイトル詐欺の汚名を返上できたでしょうか。 最後までお読みいただきありがとうございました。


  • エンジニア中途採用サイト
    ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
    ご興味ありましたら是非ご確認をお願いします。
    20210916153018
    https://career-recruit.rakus.co.jp/career_engineer/

  • カジュアル面談お申込みフォーム
    どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
    以下フォームよりお申込みください。
    forms.gle

  • イベント情報
    会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください! rakus.connpass.com

この前記事になった人に追加でインタビューしてみた

こんにちは。開発エンジニアのamdaba_sk(ペンネーム未定)です。

前回は「OWASP ZAPについて調べてみた」という記事を書きました。単体テスト中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。

それはさておき、ひと月ほど前の話になりますが、弊社エンジニアのインタビュー記事が公開されましたね。

周りから信頼されていきいきと業務に励む坂田くんの姿が伝わってきます。この記事を読んで、わたくし不覚にも「楽しそうな職場だなあ、私もそういうところで働きたい……」とちょっと思ってしまいました。いえ、別に今の職場環境に不満があるわけでもないのですが。

まだご覧いただけていない方はぜひに。

ところで実は彼は私の同期でありまして、先日お昼を一緒に食べたついでに雑談に見せかけて追加でインタビューしてみましたので、その時の話を今回は書こうと思います。 (※本人了承済み。ただし写真は気恥ずかしいのでNGだそうです。今さらな感じもしますが)

ある昼下がり

私は前回のブログ投稿からけっこう間が空いていたので、そろそろ新しい記事を投稿したいなと思っていました。技術的なTipsのようなネタもよいけれど、たまにはラクス社員である自分しか書けないようなネタが良い。そしてせっかく書くのだから自分も楽しんで書きたい。業務の傍ら頭の隅で考えるものの、しかしこれだというネタがなかなか見つけられずに少し焦っていました。

混雑を避けて少し遅めの時間帯に昼食をとるのが同期の間での習慣です。業務の切りを見て社内チャットで誘い合い、オフィスから出て外へ。その時は私と坂田くんの二人でした。

そこで、ピンときました。思い立ったが吉日ということで早速アイディアを実行に移す私。その時ちょっと顔がにやけていたかもしれません。

ペンネーム未定(以後 ペン未)「そういえばこの前インタビュー受けてた記事公開されてましたね。見ました。全国デビューおめでとうございます」

坂田くん(以後 坂田)「やめて」

ペン未「なんかめっちゃいい感じのこと言ってたじゃん。あれほんとに言ったの」

坂田「そのままは言ってない。記事の目的に合わせてかなり編集されてるし、後から修正もしたし」

ペン未「まあ、ですよね」

坂田「でもベースはインタビューの時に話した内容」

チャットディーラーのことについて

ペン未「CD1で使ったフレームワークってなんだっけ。ら……ららばい?」

坂田「Laravel。PHPのWebアプリケーションフレームワークだね。あとJavaScriptでVue.js」

何言ってるの? みたいな顔をしつつも坂田くんはちゃんと答えてくれます。ありがたや。

ペン未「そうでした。使ってみてどうだった? 例えばMD2と比べてみて」

MDはCDと同じくPHPで書かれていますが、特にフレームワークは使用していないということは以前坂田くんから聞いていました。

坂田フレームワークがあるとやっぱりかなり楽。面倒なことはやってくれてるし、どこにどんなことを書くといいのかが明確に分かれてるから、作りたい機能のことに集中できる。これはLaravelに限った話じゃないとは思うけど。他にフレームワークを触ったことが無いから他のフレームワークと比べてってなるとよくわからない」

ペン未「Vue.jsは非難殺到だったって話だったよね」

坂田「あー、うん、慣れるまではちょっと大変だったかな。それまで慣れ親しんだ手続き的なJSの書き方とはパラダイムが違うというか。Vue.jsっぽい書き方ってどんなだろうってはなった。開発入る前にもちょっとは勉強してたけど、実装始めてからも公式サイトのドキュメント読んでることが最初のうちは多かった」

ペン未「へー……。先輩に教える場面もあったって記事には書いてあったよね」

坂田「みんなして慣れてなかったからね。LaravelもVue.jsも。何か新しくわかったことがあったらけっこう教えあってた。Laravelだとこう書けばいいみたいですよー、とか、Vue.jsでこう書くとそれたぶんうまくいきます、とか」

話しているうちにオフィス近くの定食屋さんに到着し、食券を購入するために話は一時中断となりました。

かみせん

ペン未「そういえばCDは全社交流会3で表彰されてましたよね」

坂田「そうですね」

ペン未「そういえばあなたもういっこ表彰されてませんでしたっけ。なんででしたっけ」

坂田「そうですね。かみせんプロジェクトですね」

ペン未「それ前から思ってたんだけど、かみせんって結局なにしてるの」

坂田「目標は、なんだっけ……新しい技術とかにチャレンジして、わかったことを普段の業務の改善に活かすこと。具体的にはQCポータル4の段階的マイクロサービス化を今やってるとこで、私はマイクロサービス一つの実装をやってた」

Haskell……?

ペン未「それでHaskell?」

坂田「そうね」

ペン未「なんでHaskell?」

坂田「え、なんかかっこいいから……純粋関数でプログラム書くのってなんか良さそうじゃない? 変なところに副作用が出ないから修正のための影響範囲の調査だって楽そうだし、もし影響があるなら型検査で引っかかるだろうからすぐわかるし」

ペン未「でもそれでアプリケーション作るとかイメージできないんだけど」

坂田「それはライブラリがあるから大丈夫。この前ビアバッシュ5で紹介した本6にはWebアプリケーションを作る章もあるし簡単なAPIサーバーくらいならすぐに」

ペン未「っと、そろそろ時間やね。行きましょうか」

そして仕事はつづく

Haskellについて熱く語ってもらえそうな感じになっていましたがあいにくと時間切れ。ごちそうさまと告げて店を出、そのあとは他愛もない話をしつつオフィスに戻りました。午後の業務が始まります。

自席について先ほどの話の内容をメモしつつ、私が思ったのは一つでした。

Haskell好き、増えるといいね……


  1. Chat Dealer(チャットディーラー)の略称。CDについて詳しいことは商品サイトを参照 → https://www.chatdealer.jp

  2. Mail Dealer(メールディーラー)の略称。MDについても詳しいことは商品サイトを参照 → https://www.maildealer.jp

  3. 年度末に開催される全社員が集まってのパーティ。その年度に特に活躍したりした個人・グループが表彰されたりする。

  4. 社内用システムのひとつ。いくつか機能はあるが、もっぱらその日の仕事はどんなことを何時間やったか入力のために利用される

  5. 月1で開催している開発部の交流会。ビールなどのアルコール(+軽食)を片手にフランクに技術内容について発表したり語り合ったりする。このブログ内でも過去に紹介された

  6. 本間 雅洋, 類地 孝介, 逢坂 時響 (2017)「Haskell入門 関数型プログラミング言語の基礎と実践」技術評論社

新人がDockerを学習すべき4つの理由

f:id:Y-Kanoh:20180424012858p:plain

Y-Kanohです。 社会人になって2年とちょっとが経ちました。

私は、入社してから、会社で得た知識など、新しい技術を試す際、Dockerを使って開発環境を構築しています。 Dockerというと、その手軽さと管理のしやすさから、非常に注目されていますが、新米エンジニア目線だと、技術学習のツールとして大変重宝する点がとても多く感じます。

今回は、新米のエンジニアがDockerを学習することでよかったと感じたことを4つまとめます。

その1:軽量な開発環境として使える

Dockerとは仮想化技術の1つです。 と言っても、VirtualBoxなどのようなホスト型仮想化ではなく、コンテナ型仮想化技術です。 使い古された図ですが、下図のように、 コンテナ型仮想化では、ホスト型仮想化と違い、 ゲストOSを用いず、OS上の区切られたコンテナと呼ばれる空間で動作するプロセスとして仮想空間を扱うことができます。 そのため、ホスト型仮想化より軽量で、CPUやメモリの使用量も抑えることができます。

f:id:Y-Kanoh:20180424005710p:plain

新米のエンジニアとして、自宅で必要になるものは、自分が自由に扱うことができる開発環境です。 会社で得た技術を試したり、ちょっとした下調べ、さらには自宅での開発を行うには、開発環境が必要ですが、 重い仮想マシンを立ち上げることはあまり得策ではありません。さらに、サーバを複数台用いた開発を行いたい場合は...

最初からハイスペックなコンピュータを持っている場合は別ですが、スペックが限られたコンピュータしかもっていない場合なおさらです。

その2:使用するMWを意識できる

Dockerは"Infrastructure as Code"と呼ばれる、インフラ環境をコード化して管理することができる仕組みを提供してくれます。 具体的には、「Dockerfile」と呼ばれるファイルに、コンテナを構成するOSやMWを記述し、「Dockerfile」を基にコンテナを作成することで、何度でも同じ環境を構築することができます。

以下は簡単なPHP環境を構築する際に使用したDockerfileです。とくに難しいことが書いてあるわけではなく、使いたいMWのインストールコマンドがほとんどなため、知識がなくてもハードルは高くありません。。

FROM php:7.2.0-apache

RUN apt-get update
RUN apt-get install -y libpq-dev && docker-php-ext-install pdo pdo_pgsql mbstring

RUN a2enmod rewrite

## 設定ファイルの追加
ADD ./config/000-default.conf /etc/apache2/sites-available/000-default.conf
ADD ./config/php.ini /etc/php.ini

# タイムゾーンの設定
RUN cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

CMD apache2-foreground

あまり知識がないうちの開発では、自分が一体どのMWやライブラリの機能で実装できているのかわからなくなる時があります。 私の場合、自宅の仮想マシンでできていたことが、実はOSにたまたまインストールされていた機能だったのに、知らずに使っていたということもありました。

元々、「Dockerfile」はインフラ環境をコードとして管理することで、MWのバージョン管理や、デプロイの効率化などが目的かと思います。 ですが、学習目的としての環境構築時には、自身が必要とするMWがなんなのか、何の機能を使って開発を進めるのかを自覚することができます。

Dockerfileは、自身の構築する環境をしっかり意識するためにも、役に立つのではないでしょうか。

その3:まっさらな開発環境がすぐ手に入る

学習目的の開発を行う上でありがちなのが、様々なライブラリやMWを試すうちに、 なにをどうインストールしたのかわからず、開発環境が修復できない状態になってしまうことです。 少なくとも、私はそうでした。 インストールしたMWは覚えていない、バージョンもよくわからない、といった状況です。

そのたび、開発環境をリセットするために、OSをインストールしなおすのは、時間もかかり、それに伴ってモチベーションもなくなるため、あまりにナンセンスです。

Dockerでは、「Dockerイメージ」と呼ばれるコンテナのテンプレートのようなものを保存することができます。 「Dockerイメージ」はホスト型仮想マシンのスナップショットのように容量も大きくなく、 コマンド一発ですぐコンテナを作ることができます。 「Dockerイメージ」は、先に触れたDockerfileから作ることもできますし、 インターネットには、たくさんの「Dockerイメージ」が公開されています。

もし、開発環境の構築でいろいろ試したい場合は、ベースとなるOSのコンテナを作成し、 気になったMWをインストールして、うまくいかなかったらすぐ破棄してもう一度コンテナを作り直すといったことを、 短いスパンで繰り返すことができます。

そのため、ツールの選定時には、とても重宝しますし、気軽にトライアンドエラーを行うことができます。

その4:さまざまなOSSツールを試すことができる

Dockerの利点は、なにも開発環境の構築だけではありません。 主要なOSSは、公式のDockerイメージを公開しています。 たとえば、redmineやGitLab、Jenkinsなど、Dockerイメージが用意されており、 コマンド一発で手元にデプロイすることができます。

そのため、もし、配属されたチームにて使っているツールについて、わからないことがあった場合、 自宅でそのツールをデプロイして、自分でいろいろ試すことができます。 私の場合、チームで使い始めたGitLabを自宅で立ち上げ、普段使っていない機能を触ったりしています。

チームで使用しているツールは、開発の中で使いこなせるようになるとは限りません。 かといって、チームで使っているツールを学習目的で弄るわけにもいかないので、自宅で簡単にデプロイし、自由に使える環境はとても重要です。

おわりに

私の場合、最初にDockerを学習したきっかけは、上記のような学習目的ではなく、単純な興味でした。 しかし、Dockerを学習したおかげで、自宅での開発や学習に対して、フットワークが軽くなったと感じています。

Dockerの知識が業務に直接役に立たない場合でも、自身のスキルアップのために、学習してみたらどうでしょうか。

Swiftのクロージャについて

はじめに

こんにちは。ラクスエンジニアのstrongWhiteです。
今回はSwiftにおけるクロージャの書き方をまとめようと思います。
クロージャJavaScriptなどを勉強した方は馴染みがあるかもしれませんが、初めての方は慣れるまで時間がかかるかもしれません。
なお、今回はSwift自体の説明を省きます。過去の記事でSwiftについて触れているので、気になる方はそちらをご参照ください。

クロージャとは

まずは前置きから。そもそもクロージャとは?ですが、簡単に言うと名前のない関数です。
文章にすると余計に混乱されるかもしれませんが、あえてまとめるなら以下のような感じでしょうか。

  • 自身が定義されたスコープ内で解決する関数
  • 実行結果を次の処理で続けて使用する関数を作成したい場合に使用

これを読んでも意味不明だと思いますので、後ほどサンプルコードを書いてみます。

コールバックとは

クロージャとは直接関係ありませんが、この後のサンプルコードにコールバック関数が出てくるので、コールバックとは?という方のためにあらかじめ解説しておきます。
コールバックとはあとで呼ぶという意味で、呼び出し先の関数の中で実行されるようにあらかじめ指定しておく関数をコールバック関数と言います。関数の中で別の関数を呼ぶイメージです。

実例(通常の書き方)

それではサンプルコードを見ていきましょう。まずは通常の書き方から。単純な文字列を出力するプログラムです。

func A() {
    print("RAKUS Developers Blog", terminator: "")
    B()
}
        
func B() {
    print("を読んでラクスを知ろう")
}
        
A()

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

実例(クロージャの書き方)

続いてクロージャを使ったサンプルコードです。処理内容は通常の書き方と変わっていません。

func A(title: String, callback: (String) -> (String)) {
    print(callback(title) + "ラクスを知ろう")
}

A(title: "RAKUS Developers Blog") { (blogName) in // <--クロージャ
    return blogName + "を読んで"
}

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

ややこしそうですが簡単に処理の流れを解説すると、関数Aの実引数titleの値がcallbackの引数になる=blogNameの引数になります。
そしてRAKUS Developers Blogを読んでが足された文字列がreturnされ、関数Aの処理でさらにラクスを知ろうが足され、最終的な文字列が出力されることになります。
高度な書き方に見えますが、Swiftをやっているとよく出てくる書き方なので覚えておいて損はないです。
このとき、関数Aのcallbackが前述したコールバック関数です。関数Aで呼び出されて初めて処理が行われます。

クロージャにすると何がよいのか?

最初に書いたように実行結果を次の処理で続けて使用する関数を作成したい場合に有効です。
例えば、ダウンロードしたCSVファイルを返す関数downLoadCsvがあるとします。サンプルコードでいうとdownLoadCsvは関数A相当になります。
downLoadCsvから返されたCSVファイルをもとに後続の処理を行いたい(例. CSVファイルをパースする)場合、クロージャdownLoadCsvの返り値を記述してあげれば実行結果を引き継げます。
慣れるととても使いやすく、記述もシンプルになるので、クロージャの書き方をぜひマスターしてみてください。

˚✧₊⁎❝᷀ົཽ≀ˍ̮ ❝᷀ົཽ⁎⁺˳✧༚ ← どのように見えますか? ~unicodeをざっくり知ろう~

はじめに

新卒3年目に突入しましたnorth_mkyです。
エンジニアをしていると一度はコンピュータでの文字の扱いについて考えることがあるのではないでしょうか。 今回は、かなりの国の文字をカバーしている符号化文字集合unicodeの特徴について書きます。

※今回はわかりやすさのために厳密性は求めない書き方をしている箇所があります。ご容赦くださいませ。

1. unicodeとは

符号化文字集合のひとつです。
...と書くと頭にはてなが浮かぶかもしれません。

文字というのは世界規模だとかなりの数が存在します。 ただ文字を集めただけではまとまり(ひらがな、漢字、ラテンなど)を表現することが難しかったり形や使われ方の違う文字の統一的に管理することが難しいため、「この位置にこの文字をおいておく」というように文字を系統的に定義し、管理しやすくしています。この位置のことを符号位置(コードポイント)といい、字に対して必ず一意の数値で表される符号位置が存在する、つまり字を数値に表せる「符号化」を行っているため、”符号化文字集合”といいます。

unicodeの他にも符号化文字集合は世界の各地域で存在しています。 こと日本でいいますと文字として、「ひらがな・カタカナ・漢字・アルファベット」を使うため、それらの符号化文字集合の定義が必然となります。国内でこれらの文字に特化した有名な符号化文字集合JIS X 0208があります。

この符号化文字集合は単に字を符号位置という位置づけを付与し文字を定義し集めているだけなので、コンピュータで扱いやすい・処理されやすいよう更に特定のアルゴリズムで符号化をしていることが多いです。この符号化の種類のことを符号化方式といい、具体的には下記のように符号化文字集合を表現する複数の符号化方式が存在します。

符号化文字集合 符号化方式
unicode UTF-16, UTF-8...
JIS X 0208 Shift_jis, EUC-JP, ISO-2022-JP

と、少し長くなりました、話を元に戻しますとunicodeとは符号化文字集合の一つです。 webではデファクトスタンダードの符号化方式(文字コード)、UTF-8の文字はこのunicodeを符号化したものです。冒頭で述べた通り、unicodeは多くの国の文字をカバーしているのですが、それゆえに文字集合の表し方や字の定義の仕方に特徴があります。以下にその特徴を述べたいと思います。

2. unicodeの特徴

unicodeには大きな特徴が4つあります。

  • 特徴1. 4次元で一つの文字を表す
  • 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)
  • 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)
  • 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴1. 4次元で一つの文字を表す

unicodeでは符号位置は4次元で表しています。 擬似的に表現すると下記のようになります。

characterSet[group(群)][plane(面)][row(区)][cell(点)] = 'あ'

unicodeでは各々の次元をおおよそ1バイト(0x00~0xFF)の範囲で表現しており、1文字を4バイトの符号位置で表現しています。 かなりの符号空間を用意しているわけですが、全世界で現在利用している文字のほとんどはgroup:0x00,plain:0x00の範囲に収まっています。 この範囲だけ特別にBMP(Basic Multiligual plane:基本多言語面)というように呼ばれています。

unicodeエスケープ表記で表されている文字で「u\3042」というように2バイト表記されているものは、BMPに属しています。

  • u\3042」=「group0x00/plane0x00の面にある、row0x30のcell0x42の符号位置」

ちなみにBMPにのれず、別のplaneにある文字として日本で使われている一部の漢字があります。 このplaneの文字を実装していないシステムだと文字がただしく表示されない事象が発生します。

  • 文字があるはずの場所が空白
  • □の中に×が表示されている文字になる

特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)

unicodeでは複数の合成用文字(結合文字)を合成して1文字を表す、というのを実現可能にしています。 たとえば日本語の「ぱ」などの半濁音は合成用の半濁点がunicodeに存在するので、「は」+「 半濁点」で表現できます。(※他の符号化文字集合との変換性を考慮して合成用でない半濁点、そもそも「ぱ」だけで符号位置もあります、むずかしいですね...) ですので、たとえば「あ」に半濁点をつけるなど、文字として認識されていない文字を合成して1文字のすることがunicodeを用いれば可能になります。

特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)

漢字を用いる民族、として日本の他に中国・韓国・台湾がなどがありますが、同じ漢字の形で少し書き方が違うものが数多く存在します。(ex. 海|海) このような漢字はunicodeでは一つの字体に統合しています(統合文字)。

特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴3で字体を統合している、といったものの、厄介な問題があります。 別の符号化方式では区別している文字らをunicodeに変換すると、その字体の違いが吸収され、もとの符号化方式での字体を再現することができない事象がおこります。 このような事象を解消するために他の符号化方式との互換性を目的として文字が追加されることがあります。追加したそれらは別途互換文字と呼ばれます。

3. unicodeは進化し続けている ~タイトル回収~

ざっくりunicodeについて特徴を述べたのですが、やはり「すべての文字を網羅する」のは非常に難しく、既存の符号化文字集合との互換性の対応は不可欠となっているようです。ですので、unicodeも進化していっています。最近は文字だけでなく、絵文字の追加も盛んに行われています。それに対してシステムが使っているunicodeのバージョンが異なると文字が表示されない現象がおこります。

タイトルに書いた顔文字ですが、まさしく特徴でお話した結合文字を駆使して作られています。 私の環境ですと、chromeでは一部文字が表示できませんでしたが、safariではきちんと文字が表示されました。

chrome safari
f:id:northmky:20180417095732p:plain f:id:northmky:20180417095728p:plain

4. 終わりに

unicodeのざっくりした特徴を述べました。 何気なく単語として聞いているunicodeがどんなものなのか、掴めるようになりましたら幸いです。

5. 参考文献

今回の記事はこちらをとても参考にさせていただきました。
「第三水準漢字」「サロゲートペア」などの単語がどのカテゴリのどこに位置する話なのか、などがわかるかと思います。


  • エンジニア中途採用サイト
    ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
    ご興味ありましたら是非ご確認をお願いします。
    20210916153018
    https://career-recruit.rakus.co.jp/career_engineer/

  • カジュアル面談お申込みフォーム
    どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
    以下フォームよりお申込みください。
    forms.gle

  • イベント情報
    会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください! rakus.connpass.com

アジャイル開発のプラクティスを取り入れてチームを成長させよう

id:radiocat です。スクラムマスターをやっています。 先月、社内のTechイベントの全社MeetUpで発表してきました。今回はその内容についてあとがき的にまとめてみました。

f:id:radiocat:20180409202902p:plain

終わらないスクラム

私達のチームでは、以前このブログでも紹介されているスクラムレーニングを受講してスクラム開発を実践しはじめました。

tech-blog.rakus.co.jp

その経験を踏まえて得た知見や気づきを元に発表したのがこのスライドです。

speakerdeck.com

事前にトレーニングを積んでいたものの、実際にスクラムを実践してみるとうまくいかない事がたくさん出てきてスクラムイベントが思った通りに終わらない事態に陥りました。そんな状況を改善するためにスクラムコーチの吉羽さんにアドバイスを頂いたり、スクラムガイドや様々な書籍・資料を参考にして、スクラムイベントをきちんと終わらせるように取り組んだのが次のような内容です。

タスクの細分化

スクラムガイドには 作業の単位は1日以下 と書かれています。タスクの粒度が大きいと着手中の状態が長くなり、どの程度進んでいるのか、どれくらいで終わるのかの見通しがわかりづらくなります。そもそも見積もった時点で1日以上かかるということは細かい作業内容が充分イメージできていない事が多いため予定通り進まないことも多くなります。私達のチームでは見積もりが大きい場合は半日以下になるまでタスクを分解するルールにしました。

リファインメントの徹底

開発チームとプロダクトオーナーがしっかり会話してプロダクトバックログの内容を相互に理解しておかないと、何をどうやって実現するかが明確にならず半日以下のタスクに分解することも難しくなります。スクラムガイドにもリファインメントは プロダクトオーナーと開発チームが協力して行う継続的なプロセス であると定義されています。私達のチームでは リファインメント会議を毎週1回定期開催 するルールにしました。

デイリースクラムの改善

私達のチームではスクラムで開発を始める前から朝会で全員の進捗を確認していましたが、改めてスクラムで定義されているデイリースクラムの目的は何かを考えて朝会のあり方を見直しました。スクラムガイドには 自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握 するためのイベントと定義されています。そのためチームのリーダーが進行して進捗を確認するスタイルから開発チームが交代制で進行するルールに変更しました。

カンバンを検査の拠り所に

カンバンもスクラムで開発を始める前から導入していましたが、チームで意見を出し合って少しずつマイナーチェンジを繰り返しています。デイリースクラムを毎朝カンバンの前で行うため、カンバンもデイリースクラムの目的に沿っていることが重要です。チームの状態を検査し今後の状態が予測できる場にするためにより良い使い方を模索してきました。現在、私達のチームが実践しているスタイルは左からToDo、実行中、レビュー中、完了の順にレーンをわけて、優先度の高いタスクを上から順に並べています。右上にいくほどチームとして最も優先度の高いタスクであり、全員で協力して早く終わらせるようにしています。

むきなおりでチームの方向性を再確認

はじめからチームの進むべき方向性がきっちり定まっていて全員の認識が一致しているようなチームは稀です。私達のチームもはじめは手探り状態でどこかで不安を抱えながらスプリントを進めていたため、3回目のスプリントが終わった時に改めてチームの進むべき方向性を議論して目指すべき設計の方針や品質目標を再確認しました。

インペディメントの除去

スクラムガイドにはスクラムマスターはサーバントリーダーであり 、 メンバーが成果を上げるために支援や奉仕をするリーダー であると書かれています。スクラムにかぎらずソフトウェア開発において開発チームには様々な妨害要素が待ち受けています。近年のソフトウェア開発では、今まで使ったことのない新しい技術や外部のサービスを使うことも当たり前となっています。スクラムマスターはそのような要素を妨害リストとして洗い出し、それらを少しだけ先回りしたり、問題が小さいうちに手を打つことでチームが成果を上げられるように支援に徹しました。

2つの気づき

これらの取り組みを実践することで得た気づきは大きく2つです。

アジャイル開発のプラクティスは従来型の開発でも役に立つ

スクラム開発で取り組んだことは従来型の開発にも活かせることが多いと気づきました。実際にこのような手法は、従来型の開発プロセスの中にアジャイル開発のプラクティスを取り入れるということでハイブリッドアジャイルと呼ばれて実践されているようです。つい最近、日経SYSTEMSの最新号でもハイブリッドアジャイルをテーマにした連載が始まっています。

tech.nikkeibp.co.jp

改善の機会はスクラム開発のほうが豊富

スクラム開発では決まったタイムボックスでイテレーティブに開発を進めることによってアジャイル開発のプラクティスを取り入れるための検査・適応の機会がたくさん訪れます。アジャイル開発のプラクティスを実践して改善する機会はスクラムのほうが豊富にあると感じました。

終わらない学びと実践

スクラム開発でもそれ以外の開発プロセスでも、アジャイル開発のプラクティスは活用できます。そして、スクラムで開発する機会が訪れた時にはアジャイル開発のプラクティスを活用する機会は増加します。つまり、いずれにしてもアジャイル開発のプラクティスを取り入れて学びと実践を繰り返していくことがチームが成長していくための道筋の1つだとスクラム開発を通して学びました。スライドではそのようなアジャイル開発のプラクティスを取り入れるための情報源を幾つか紹介しています。

スクラムガイドによるとスクラム開発は 理解は容易習得は困難 とあります。私達もまだまだ終わりは見えていませんが、習得に向けて学びと実践を繰り返すことでチームがさらに成長できると思っています。

f:id:radiocat:20180409203832p:plain

Copyright © RAKUS Co., Ltd. All rights reserved.