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

shobylogy

叩けシンプルの杖

エンジニア向け日頃の疲れを取るおすすめの入浴剤

エンジニア、肩や腰が凝りますよね。

温泉に行きたい…でも忙しくてなかなか行けない。 そんな方は入浴剤を使って毎日の疲れを取るのがおすすめです。

今回は、私が日頃から使っている入浴剤を紹介します。

温泉に行きたい方はこちらをどうぞ

blog.shoby.jp

おすすめ入浴剤

  • きき湯 マグネシウム炭酸湯
  • きき湯 FINE FEAT RESET
  • クナイプ グーテナハト バスソルト

きき湯 マグネシウム炭酸湯

私が一番愛用している入浴剤です。

主成分として、硫酸塩泉に含まれる硫酸マグネシウムが配合されており、炭酸ガスと合わせて血行が改善されます。

硫酸マグネシウム - Wikipedia

製造元のバスクリンは、温泉成分を科学的に分析して入浴剤に生かしており、きき湯シリーズはその最新商品です。

きき湯シリーズには温泉成分が含まれ、擬似的に温泉と同じ効能が得られます。

www.bathclin.co.jp

私は基本的に毎日この入浴剤を使っています。約600円で12回ほど使えるため、常用しても問題ない価格です。

入浴後は、1時間以上は体がポカポカして、使い始める前と比べると、肩こりや腰痛が大幅に改善されました。

きき湯 FINE FEAT RESET

きき湯ファインヒート レモングラスの香り 400g 入浴剤 (医薬部外品)

きき湯ファインヒート レモングラスの香り 400g 入浴剤 (医薬部外品)

きき湯シリーズのハイグレードモデルです。 おそらくアスリートなどの体を酷使する人のために開発されているように思えます。

主要な温泉成分はきき湯シリーズとほぼ同じですが、生姜の粉末が加えられています。

生姜には体を温める作用があり、漢方薬としても使われています。

takeda-kenko.jp

私はひどく疲れた場合や、日頃の疲れが溜まった時にこちらを使っています。

体のコリがかなり改善されるように思います。

クナイプ グーテナハト バスソルト

クナイプBソルトGN850

クナイプBソルトGN850

きき湯シリーズは入浴自体で肩こりや腰痛を改善するタイプですが、こちらは入浴後に安眠して体力を回復できるタイプです。

入浴によるリラックスを目的としており、特に温泉成分としての効能はありません。

クナイプシリーズは効能ではなく香りで選ぶと良いと思います。

入浴剤を使った時の入浴の仕方

温泉でもそうですが、入浴剤を使った場合、お風呂に浸かった後にシャワーで洗い流さずに出るようにしてください。

体の表面に残った温泉成分が入浴後も作用し、体を温め続けてくれます。

まとめ

なかなか温泉に行けない時は入浴剤がおすすめです。

きき湯シリーズは温泉成分が含まれ、擬似的に温泉と同じ効能が得られます。

きき湯 マグネシウム炭酸湯は日常の疲労回復に効き、 きき湯 FINE FEAT RESETは日頃の溜まった疲れに効きます。

また、クナイプはリラックスによる安眠が期待できます。

SwiftとObjective-C混在のプロジェクトで、BridingHeaderのビルドが低頻度で失敗する問題を修正する

iOS

SwiftとObjective-C混在のプロジェクトで、CI上でBridingHeaderのビルドが低頻度で失敗する現象に悩まされていました。(失敗した場合もRebuildすると成功します)

常に失敗するのではなく低頻度で失敗するケースの場合、Headerのimport周りが怪しいことが多いようです。*1

特にBridingHeaderでimportしているHeaderファイル上で、別のHeaderファイルを読み込んでいると、多重importになってしまい、ビルドが失敗します。

これを解決するには、Objective-C側を修正し、.hファイルでは他のHeaderをimportせず、.mファイルでimportするように書き換えると問題なく動作します。

エラーの例

このようなエラーが出ます。

/Users/UserName/RepositoryName/AppName/Classes/MYViewController.h:10:9: 'LibraryName.h' file not found

error: failed to import bridging header /Users/UserName/RepositoryName/AppName/Supporting Files/Fril-Bridging-Header.h

上記のエラーの場合、CocoaPods経由で読み込んでいるライブラリのヘッダーが多重importになっていました。

解決例

以下のような修正を加えることで問題を解決しました。 プロトコルを継承している場合でもInterface extensionを使うことで.hファイルに書かずに.mファイルにプロトコルの宣言を移すことができます

Before

MYViewController.h

#import <UIKit/UIKit.h>
#import "LibraryName.h"

@interface MYViewController : UIViewController <LibraryNameProtocol>
@end

After

MYViewController.h

#import <UIKit/UIKit.h>

@interface MYViewController : UIViewController
@end

MYViewController.m

#import "MYViewController.h"
#import <LibraryName/LibraryName.h>

@interface MYViewController () <LibraryNameProtocol>
@end

*1:仮説ですが、ビルドされるファイルの順序やキャッシュの有無により結果が不安定になるのかもしれません

心理的安全性を向上させる「ドラッカー風エクササイズ」を自分のチームでやってみた

最近、良いチームには「心理的安全性」が必要だということが話題になっていて、個人的に気になっていたところに、ninjinkunさんが「ドラッカー風エクササイズ」を紹介してくれたため、自分の所属するチームで試してみた。

ドラッカー風エクササイズのすすめ - けんちゃんくんさんの Web日記

(「心理的安全性」とは、思いやりがあり、どんなことでも率直に言い合えて、何を言っても自分の立場が悪くならないような状態を示しているらしい。)

個人的には、この取り組みで以下のことが改善できたら良いなと思っていた。

  • チームメンバーの入れ替えによるチームの変化を受け入れる
  • 今やっている仕事と、客観的に見て自分に向いている仕事のミスマッチを防ぐ

目的を伝えた

以下のようにエクササイズの目的を伝えた。

  1. 自分の得意なこと、自分がどうやって会社に貢献したいかを皆に知ってもらう
  2. 皆が自分にどういうことを期待しているかを知る

あくまでもこのエクササイズの目的は「知ること」なので、それ以上は何もしないということを伝えた。

進め方

  1. 自分の得意なこと、自分がどうやって会社に貢献できるかを書く
  2. 他のチームメンバーそれぞれについて、自分が期待していることを書く
  3. 共有
  4. 話し合う

「得意なこと」については、「自分が他の人より上手くできること、得意だと思っていることを書いてください」

「貢献できること」については「自分が会社やチームに貢献できることは何か書いてください」

「期待していること」については「チームでどう活躍してくれるか、期待していることを書いてください」というように伝えた。

また、「期待していること」は無記名にした。(恥ずかしがらずに書いて欲しかった)

感想

チームメンバーの変更があったタイミングや、達成すべき目標が変わったタイミングで是非やるべき。 チームメンバーについて深く理解でき、自分の仕事に対する納得感が出る。

チームメンバーの入れ替えによるチームの変化を受け入れる

顔合わせとしては、一緒にランチを食べるよりも良い方法だったと思う。 一緒に仕事をしたことがない間柄でも、お互いの得意分野や人柄が深く理解できる。

今やっている仕事と、客観的に見て自分に向いている仕事のミスマッチを防ぐ

全体を通して、自分が貢献できると思っていることと、他の人が自分に期待していることに対して、大きなミスマッチはなかったが、それが知れたのは大きいと思う。 客観的に見た向いている仕事(期待されている仕事)と、自分がやっている仕事が一致していることが把握できるのは、納得感が出る。

「意外と皆、自分を見てくれていることに気づいた」という感想が出たが、新チームメンバーを「得体の知れない他人」ではなく「自分をよく見てくれているチームメイト」という認識にできたのは大きいと思った。

iOSアプリの画像を最適化してアプリの容量を減らす

iOS

最近アプリの容量が増えてきたので、容量を減らすべく画像の最適化を行いました。 調べて出てくる情報がどれも古かったため、今だとどうしたらいいかを書いておきます。

以下の情報はXcode 7.2.1環境を想定しています。

概要

  • Asset Catalog を使う
  • ASSETCATALOG_COMPILER_OPTIMIZATIONspaceにする
  • ImageOptimで画像を最適化する
  • PDFではなくPNGを使う
  • PNGではなくJPEGを使う

Asset Catalogを使う

Asset Catalogに入っていない画像をAsset Catalogに入れると容量が減ります。 Asset Catalogに入れるとSlicingが有効になり、デバイスごとに必要な画像のみが配布されるバイナリに含まれるようになるためです。

developer.apple.com

ASSETCATALOG_COMPILER_OPTIMIZATIONspaceにする

Build SettingsのAsset Catalog Compiler > Optimization にあります。

このsettingをspaceにすると、コンパイル後のasset catalogのサイズを最適化してくれるようです。 (timeだと画像の読み込み時間を高速化してくれるようですが、体感ではあまり違いを感じませんでした)

ImageOptimで画像を最適化する

ImageOptimというアプリケーションを使うと画像の最適化ができます。 最適化の設定は最高レベルの「クレイジー」にしておくと良いと思います。

f:id:shoby:20160316164213p:plain

このアプリケーションは、内部ではPNGOUTPngcrushなどのツールを組み合わせて、最も容量が減った方式を採用してくれるようです。*1

注意点として、ImageOptimにより画像を最適化した場合、ASSETCATALOG_COMPILER_OPTIMIZATIONspaceではなくtimeにした方が容量が減る場合があります。

Asset Catalogに含めた画像は、Xcodeでのビルド時に必ず最適化がかけられてしまうのですが*2、ImageOptimで最高レベルに最適化をした画像の場合、space を指定した場合の圧縮だとtimeを指定した場合よりファイル容量が増大することもあるようです。

この辺りはファイルに寄ると思いますので実際にお試しください。

前は COMPRESS_PNG_FILES があり、再圧縮を防止できたのですが、このオプションはデフォルトでは表示されなくなった上、Configurationファイルなどで指定してもAsset Catalogには適用されません。

PDFではなくPNGを使う

PDFではなくPNGを使う方が容量が減る場合があります。*3

体感として、アイコンのようなVector画像向きのファイルはPDFの方が容量が減りますが、スクリーンキャプチャや実写画像などのファイルはPDFではなくPNGの方が容量が減るように思えます。

PDFはビルド時、内部ではPNGとして書き出されているため、書き出しと最適化をXcodeに任せるのではなく、最初から最適化済みのPNGを入れておいた方が容量が減る場合があります。

PNGではなくJPEGを使う

Asset CatalogではPNGとPDFだけでなく、JPEGも扱うことができます スクリーンキャプチャや実写画像などのファイルは、PNGではなくJPEGの方が容量が減る場合があります。

developer.apple.com

まとめ

Asset Catalogに入っていない画像をAsset Catalogに入れるとSlicingが効いて容量が減ります。 また、ASSETCATALOG_COMPILER_OPTIMIZATIONspaceにするとAsset Catalogのコンパイル時に容量が減ることがあります。 ImageOptimで画像を最適化したり、画像フォーマットを変更して、画像ファイル自体を最適化すると容量が減る場合があります。

*1:いつの間にかZopfliにも対応してました

*2:実際にビルド後のcarファイルを解析してみたのですがtimeでもspaceでも再度最適化がかけられてファイルの容量が変化していました

*3:PDFとはなんだったのか…

I'll talk about color detection from fashion images in Fasion Tech Meetup #2

English

I'll participate in Fashion Tech Meetup #2, and talk about color detection from fashion images. The meetup will be held on March 22.

fashion-tech.connpass.com

Sad to say, the event will not be translated into English. However I'll translate my presentation after the event.

My talks contains following contents.

  • Removing background from fashion images
  • Color correction of images taken with a fluorescent lamp
  • Extracting "main color" and "sub color" from a image
  • Color matching between RGB values and color groups

Please check it! Thanks.

第二回 Fashion Tech Meetup (3/22) で商品画像からの色検出について話します

3/22(火)に第二回 Fashion Tech Meetupというイベントに参加します。 フリルにカラー検索という機能を実装した際に、商品画像から色情報を検出した話をする予定です。

fashion-tech.connpass.com

Fashion Tech Meetupは、ファッション x テクノロジーというテーマで ファッション関連のサービスを運営している企業が、日頃得た技術的なノウハウを共有する勉強会です。

MERYを運営するperoliさん、iQONを運営するVASILYさんと共に、フリルを運営するFablicが発表をします。

僕の発表は、以下のような内容の予定です。

  • 商品画像からの背景領域削除
  • 蛍光灯下で撮影された画像の色補正
  • 商品画像から商品のメインカラーとサブカラーを検知
  • RGB値とファッションにおける「色系統」のマッチング

かなり面白そうなイベントなので、僕自身もワクワクしています。 良ければ話を聞きに来てください。

Objective-Cで書かれたメインプロダクトを少しずつSwiftに書き換える

iOS

現在、私はObjective-Cで書かれたメインプロダクトを少しずつSwiftに書き換えている最中です。*1

おそらく奮闘中の皆さんのためにも、私が得た知見をお話ししようと思います。

なぜメインプロダクトのSwift移行が進まないのか

これは、単純にメインプロダクトは巨大で複雑であることと、メインプロダクトでユーザーに新たな価値を届けつつ、同時にSwiftに移行するのが困難であるのが原因であるように思えます。

大きなメインプロダクトは一部を書き換えるだけでも依存関係を解消するのに骨が折れます。 書き換えを進めると「え、このクラスここでも使われてるの…?」というような新事実が後から判明します。

また、メインプロダクトは、新機能の実装や改修でユーザーに新たな価値を届けなければなりません。会社の収益源となっているようなサービスの開発を長期間止め、Swiftへの移行だけに力を注ぐわけにはいきません。

機能開発と同時にアプリを別言語に書き換えるというのは、走っている自動車のタイヤを走りながら付け替えるような荒技のように思えます。なかなか難易度が高いですね。

上記のような理由でメインプロダクトのSwift移行がなかなか進んでいないのだと思います。

そこで、そのような環境下でも、少しずつSwiftに移行する方法をひねり出しました。

メインプロダクトを少しずつSwiftに移行するTips

  • 新規クラスは必ずSwiftで書く
  • 1度に書き換えるのは1回のQAでカバーできる範囲まで
  • Utility -> View -> ViewController -> Model -> APIClientの優先度で書き換える

新規クラスは必ずSwiftで書く

新規クラスは必ずSwiftで書くようチーム内でルールを定めましょう。

既存のObjective-Cのクラスを書き換えるのは大変ですが、新規クラスをSwiftで書くのであればさほど問題ありません。

メインプロダクトの開発の主目的である「ユーザーに新たな価値を届ける」という目的を達成しつつ、Swiftのコードを増やしていけます。

1度に書き換えるのは1回のQAでカバーできる範囲まで

Swiftへの書き換えは、1度に1回のQAでカバーできる範囲内にとどめましょう。 やりすぎると事故が起きます。

例えば、画像周りで機能改修をしている場合、関連するクラスを一緒に書き換えると、機能改修と書き換えを同時にチェックすることができます。

事故は注意していなかった部分で起きることが多いため、注意が向いている部分を書き換えて一緒にQAしてしまうと安心してリリースができます。

Utility -> View -> ViewController -> Model -> APIClientの優先度で書き換える

依存度が低い部分から書き換えましょう。

特にちょっとした処理をまとめたUtilityクラスや、Viewのコードは依存する箇所が少ないため、比較的安全に移行ができます。

ViewControllerはちょっと勇気が要りますが、単体で完結していることが多いため、やる気さえあれば移行ができると思います。

問題はModelとAPIClientです。いろいろな箇所から呼び出され、依存関係も複雑なため、移行にはかなりのやる気が必要になるでしょう。*2

まとめ

メインプロダクトは巨大で複雑であり、機能開発と同時に移行を進めなくてはならないためSwiftへの移行がなかなか進みません。

新規クラスはSwiftで書くようにルールを定めたり、1度に書き換えるのを1回のQAでカバーできる範囲内にとどめる、UtilityやViewなど依存の少ない安全な部分から移行を進めることで比較的安全にSwiftに移行を進められます。

*1:ここでのメインプロダクトとは会社の収益源となっているサービスというニュアンスです

*2:ちなみに私はまだ手がつけられていません。