こんにちわ、サボっていて久しぶりにブログを投稿するURAです。
現在、maker town というデザインシミュレーター付クラウド型オンデマンドEC（長い！）なるものを開発中です。
maker town自体についてはまたの機会にご紹介するとして、今回はmaker townのリリース作業で煩雑に感じていた部分を、最近ちょっと改良してみたお話をしたいと思います。

前提

• GitHub Flowを採用している
• 機能追加・バグ修正をある程度まとめてリリースすることが多いため、事前にリリースする対象のリストを作っている。
• リリース対象のリストはSlackで共有していた（リリースが終わったら流れてもOK）

問題点

• プルリクエスト（PR）を出す人とリリース作業をする人が同じとは限らないため、すべてのPRのレビューが済んだのかが、リリース作業をする人から見て分かりづらい。
• GitHubでリリース対象すべてのPRがCloseしたかチェックする作業が無駄。
• リリースする人以外から見ても、リリース作業の進捗が分かりづらい。

解決策

Slackで共有していたリリース対象のリストを共同編集できるようにして、PRのレビューが済んだらチェックを付けて進捗を見える化する。
⇒
Slackのポスト機能をリストの共同編集に利用する！

「知らんけど、Slackになにかしら共同編集するための機能あるでしょ？」と言ってみたところ
たにすぎと池田がSlackのポスト機能を探してきてくれました。グッジョブ。

Slackのポストの使い方

1. 左のショートカットボタンから「ポスト」を検索して選択する

2. リリース対象のチェックリストを作成

3. 右上の「共有」を開いて「他のメンバーの編集を許可する」にチェックして共有

まとめ

改良したばかりでまだリリース作業がラクになったかは分かりませんが、運用しやすくなるよう開発フローは継続して改善していきたいです。

こんにちわ。今週のテックブログ、担当のURAです。
最近めっきりと寒くなりましたね。私は毎朝子供を保育園に連れて行くのですが、なぜか保育園は暑いのです。外は肌寒いのに、保育園の中で子供を教室に連れて行ったり荷物をセットしているだけで、ちょっと汗をかくくらい暑いのです。これ保育園あるあるだと思うのですが、世のお父さん方どうでしょうか？

ですよね？保育園、暑いですよね？
はい、全力で共感してもらえて満足したので、今回のテーマ「減色」の話に移ります。

Why 減色？

最近、とあるプロジェクトで「減色」の実装をしていました。
弊社は様々なアイテムにオンデマンドでプリントする会社です。
プリント方法にも色々あり、インクジェットプリントであれば写真のようなフルカラーの画像をプリントできますが、プリントする色数が1色のみであったり、2色のみであったりと限られているプリント方法もあります。
そして、注文時に指定された加工方法の色数と、お客様がアップロードしたデザインデータの色数は必ずしも一致しません。
そこで、デザインデータを決まった色数に減らす処理、つまり「減色」が自動的にできると、デザインデータを補正できるというわけです。

Imagemagickで減色してみる

減色処理にはいくつかアルゴリズムがあります。
今回は、Imagemagickを使って減色する方法をご紹介します。
説明のため、とある画像を8色に減色することを考えていきます。

色のビット深度を指定して減色する

「ビット深度」とは、画像の各チャネルを何ビットで表現しているかという数値です。
例えば、ビット深度が8ビットのRGB画像とは、Red / Green / Blueチャネルのそれぞれが8ビット（256色）で表現されている画像であり、1ピクセルはRed / Green / Blueを組み合わせた情報ですので、

256 * 256 * 256 ≒ 1678万

約1678万パターンの色表現が可能な画像という意味です。

Imagemagickの「depth」コマンドを使うと、ビット深度を指定して減らすことができます。
お題は8色に減色することですので、ビット深度を1ビット（Red:2 * Green:2 * Blue:2 = 8色）に減色します。

convert dance.png -depth 1 dance-depth1.png

単純に画像のビット数を減らすと、肌色が消えてしまいました。

パレットを指定して減色する

Imagemagickの「remap」コマンドを使うと、指定したパレットに使われている色のみになるよう、画像を再構成することができます。
今回は、パレットの色は元画像を見ながら大まかに決定し、以下のようなコマンドでパレットを作成しました。

convert -size 60x60 xc:"rgb(0,0,0)" xc:"rgb(255,255,255)" xc:"rgb(255,0,0)" xc:"rgb(0,255,0)" xc:"rgb(0,255,255)" xc:"rgb(0,0,255)" xc:"rgb(255,0,255)" xc:"rgb(254,220,189)" +append palette8.png

remapコマンドは以下です。

convert dance.png +dither -remap palette8.png dance-remap.png

上記のコマンドに「+dither」とありますが、これは色を組み合わせて中間色を表現する「ディザ」処理を入れないという意味です。
減色する8色以外の中間色が表現されてしまうと見づらいので、今回はディザ処理を省いています。

パレットを自身で作成したため肌色は出ていますが、細かくパレットを調整したわけではないので、例えば洋服の水色は色に差が出ています。
また、パレットの8色にしか減色できないため、様々な画像を自動的に減色する用途には向かなそうです。

画像の色分布から似た色を減色する

Imagemagickの「colors」コマンドを使うと、画像の色分布を元に似た色を減らすことができます。
アルゴリズムについて知りたい方は以下をご覧ください。
https://imagemagick.org/script/quantize.php

convert dance.png +dither -colors 8 dance-colors8.png

元画像の主要な色が再現できていそうです。

k-means法を使って減色する

k-means法とは、k個のクラスタに平均を使ってクラスタリングするアルゴリズムです。
機械学習界隈でも登場するアルゴリズムの一つですので、興味のある方は知らべてみてください。
https://ja.wikipedia.org/wiki/K%E5%B9%B3%E5%9D%87%E6%B3%95

Imagemagickでのコマンドは「kmeans」を使います。

magick dance.png -kmeans 8 dance-kmeans8.png

これも元画像の主要な色が再現できていそうです。
「colors」コマンドと比較すると、顔色が良くなった（頬の色がより再現できている）ような…？

まとめ

Imagemagickを使った減色処理について紹介しました。
紹介しておいてなんなのですが、とあるプロジェクトでは減色処理にImagemagickは採用せず、独自実装する道を選びました。
Imagemagickは誰でも使えますし、独自実装することでより直感的な減色の結果が得られるなら、ユーザビリティーの面で差別化できますしね。

こんにちわ。コロナウイルスの影響で電車がガラガラの日々が続いていましたが、GW明けから徐々に出勤している人が増えているみたいですね。
電車混まないでえええ！！ということで、テックブログ今週の担当はuraです。

ドキュメント作るのつらい

皆さんは仕様書やマニュアルなどのドキュメントを作りますか？
私は現在受注プロジェクトのPMをしており、頻繁にドキュメントを作る機会があります。
一般的に、ドキュメントはWordやExcel等で作成するかと思います。WordやExcelは見やすいですよね。好きですか？私は嫌いです。

• Gitで履歴管理しても簡単に文章を検索できない。差分も見えない。
• チームで同じファイルを同時に編集しづらい。（GoogleDocsを使えばなんとかなるけど）
• 書式を整えるのが面倒。気づいたら一部だけフォントが異なるとかよくある。
• 顧客用のドキュメントであれば、修正の度にファイルを送信する必要がある。

ではどうするか？Markdownで作成してGitで管理しよう。
いちいちファイルを送るのは面倒なので、GitにプッシュしたらHTMLに変換してWebページに公開しよう。

いや、でもMarkdownだとテーブルのセル結合すらできないから、ちょっと複雑なドキュメントになると表現力が足りない・・・。

そんなことを考えているときに見つけたのが、今回のテーマのAsciiDocです。

AsciiDocとは？

Asciidocは軽量マークアップ言語の一つです。Markdownの仲間ですね。
以下のような採用事例があります。

• Pro Git
• オライリーの書籍（電子書籍）
• Neo4jのドキュメント

Markdownと比較すると以下のような点が優れています。

• テーブルのセル結合ができる
• 相互参照が使える
• 外部ファイルを読み込める（ソースコードをそのまま読み込んで表示したり、分けて作成したドキュメントをマージしたり・・・）
• PlantUMLを直接書ける

使ってみる

それではさっそく使ってみます。

セクション

「=」の数で表現します。

== セクション1
=== セクション1.1
==== セクション1.1.1
== セクション2
== セクション3

リスト

「*」の数で表現します。

* リスト1
* リスト2
** インデント
*** さらにインデント

テーブル

[cols="1a,1a,1a",options="autowidth"]
|===
|1A|1B|1C
2+|「数値+」で横結合|2C
.2+|「.数値+」で縦結合|3B|3C
|4B
|* 4C
* リストを
* 入れることも可能
|===

画像

image::https://techblog.imagemagic.jp/wp-content/uploads/2018/11/%E6%8E%A1%E7%94%A8%E3%83%90%E3%83%8A%E3%83%BC.png[alt=代替テキスト, width="200" align="center"]

アンカー

アンカーは二重の「[」で表現します。

[[hogehoge]]

リンク

link:https://imagemagic.jp/recruit/[イメージ・マジックではエンジニアを募集中です。]

<<hogehoge, アンカーへのリンクは二重の「<」で表現します。>>

外部ファイルの読み込み

include::hogehoge.adoc[]

まとめ

AsciiDocの特徴や簡単な使い方について紹介しました。
現在マニュアル作成で使っていますが、やはりWordよりはラクをさせてもらっています。

インストール方法や詳しいリファレンスについては公式サイトをご覧ください。

8月に入って暑い日が続いています。脱水には気を付けなければ・・・と思いつつコーヒーばかり飲んでいます。テックブログ、今週の担当は浦です。
最近は開発の上流工程を担当していたので、テックブログのテックってなんだっけ・・・と若干悩みつつ、今回は「使いやすいUI」とはなんぞや？というテーマで軽くまとめてみます。

ユーザーにとっての使いやすさ

人間に合わせたUI設計のルール

1. 関連の高い要素は近づけて配置する

人間は、位置的に近くに配置されたものを関連のある情報として認識します。
例えば、画像とキャプションがその他の要素間より近くに配置されていれば、一目でどのキャプションがどの画像を説明しているのか判断できます。
逆に関連の低い要素間は、意識して余白を大きく取ることで区別しやすくなります。

2. 同じ要素・レイアウトを意識的に繰り返す

3. 重要な要素を左上から右下への対角線上に配置する

4. 重要な要素は大きくする

5. 関連の高い要素を同じ配色にする

まとめ

こんにちわ！やっとこさ入社１ヶ月半の浦です。
毎年この時期は花粉にやられています。ただただつらいです。鼻の粘膜を焼いてアレルギー反応が起こりづらくする治療もあるようですが、ちょっと怖いのでチャレンジできずにいます。花粉面倒なので、どなたかGWまでタイムリープする方法を知りませんか？

今回のテーマ

さて、現在私は【ODPS】 という、工場受注～生産管理までを一括で担うクラウド管理 システムの開発に携わっています。詳しくは以下のリンクをご覧いただければと思います。
https://imagemagic.jp/service/odps/

クラウド管理システムなので、当然ながらWebサービスです。
TwitterでもYouTubeでも何でもかまわないのですが、Webサービスのエンドポイントの設計って気になりませんか？個人的にはけっこう見ちゃうんですよね。
APIを使う際、URIの設計が悪いと使い方を理解しづらかったり、間違って使ってしまったり・・・。ということで今回は、分かりやすいエンドポイントの設計について考えてみたいと思います。

余計な情報がない

例えば、以下のURIを見てどう思われるでしょうか。

• http://example.com/service/users/get

個人的な突っ込みどころは二つです。

1.「service」が抽象的

大抵「サービス」という単語が出てくると、より具体的な機能を当てはめた単語に置き換える必要があるか、その単語自体不要なことが多いかと思っています。

2. 「get」は不要

HTTPのメソッドで使い分ければいいですね。URIの指すリソースと、そのリソースに対する操作は分離できた方が見やすいです。

単語を省略しない

• http://exapmle.com/sv/u

このURIを見て、どんなリソース・機能にアクセスするのか分かるでしょうか。「sv」は「service」かもしれませんし、「supervisor」かもしれません。「u」も省略し過ぎて「user」なのか判然としませんよね。
人間が見てどのような機能なのか理解できないURIは、タイプミスに繋がります。APIを公開してクライアントにアクセスしてもらうことになった場合、上に挙げたような理解しづらいURIは、クライアントの開発効率の低下に繋がると考えます。

大文字小文字が混在していない

大文字小文字が混在しているとは、例えば以下のようなケースです。

• http://example.com/Users/0123

URIのすべてが小文字に統一されていれば、この単語は大文字だったっけ？と迷うことがなくなります。また、ホスト名の部分はすべて小文字での表記が一般的ですので、それに合わせてすべて小文字にするのが良しとされているようです。

集合は複数形

• http://example.com/user/0123

一見上記URIは、意味も分かりますし適切に思えます。しかし、上記URIの示すところは、「ユーザー」という集合の中の、「0123」というリソースです。データベースのテーブル名は一般的に複数形が適切といわれているのと同様で、集合を表すものは複数形にするのが一般的です。

まとめ

簡単ではありますが、今回は分かりやすいエンドポイントの設計について考えてみました。
エンドポイントの設計にご興味のある方は、ProgrammableWebという様々なAPIをまとめたサイトがお薦めです。各サービスがどのようなエンドポイントになっているか眺めるだけでも勉強になります。
URIの設計に限らずコーディングもそうですが、分かりやすさという観点は忘れずに今後の開発に取り組んでいきたいものです。