Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月11日

furusin

指定したURLへのアクセスをcronのように定期実行する

こんにちは。ピクトリンク事業部の古川です。

この記事はフリューAdvent Calendar 2018の12/11分となります。

今回は、URLへのアクセスを定期的に実行してくれるWebサービス「cron-job.org」についてです。

はじめに

自分でWeb APIを立てて、GETやPOSTを定期的に実行したい時はないでしょうか。

私の場合、個人的にFirebase Cloud FunctionsにRest APIを作ったものの、定期的に実行する方法が無かったので色々な方法を探していました。

Firebase Cloud FunctionsのAPIを叩くためだけに別のサーバを建てるのは…うーん…

と考えていた時に出会ったのが、このcron-job.orgでした。

ちなみに日本語版はありません。英語とドイツ語のみです。

ですが非常に簡単なので、下記に説明しますのでご安心ください。

あ、あとオープンソースなのでコントリビュートも可能なようです。

実際に使ってみる

cron-job.org にアクセスしましょう。英語ですが大丈夫です。

スクリーンショット 2018-12-04 15.19.49

ユーザー登録する

登録は簡単ですので、画面右上の「Signup」から必要事項を入力して「create free account」をクリックしましょう!

スクリーンショット 2018-12-04 15.27.58

実際にジョブを作成する

画面右上の「Members」から「Cronjobs」を選択し、「Create cronjob」を押下します。

スクリーンショット 2018-12-04 15.30.27

cronを実際に作成する画面は以下のようになっています。

設定できる項目

  • HTTPの認証
  • 定期実行の時間的条件
    • ◯分ごとに実効する
    • 毎日◯時◯分に実行する
    • 毎月◯日の◯時◯分に実行する
    • 自分で決める(複数選択可)

私がやりたかったのは「5分毎にFirebase FireStoreの情報を更新する」ことだったので、

「Every 5 minutes」として設定して実行しました。

時間の色々な選択肢があるのはステキです。

スクリーンショット 2018-12-04 15.38.31

 

リクエストに失敗し続けたらどうなるの?

たとえばRest APIサーバが死んでいて、リクエストが失敗し続けたとしましょう。

その場合、以下のような内容でメールが来て「めっちゃ失敗してるからCron-Job止めたやで!」と知らせてくれます。

まとめ

いかがでしたか?

cron実行だけのためのサーバを建てずとも、簡単にHTTPリクエストを送り続ける設定を作ることができました。

失敗したときもメールで知らせてくれますし、個人で使うには便利なツールかと思います。

ちなみに、つい先日Google Cloud Platformに「Google Cloud Scheduler」が登場したようです。

cron-jobsと似たような動きをしてくれるもののようですので、そちらも試してみてもよいかもしれません!


2018年12月10日

awata

社内のproxyサーバと折り合いを付けたやりかたの紹介

こんにちは。
ピクトリンク事業部開発部インフラ課の粟田です。

フリュー Advent Calendar 2018の12/10分の記事になります。

今回はみんなが大嫌いな(はずの)proxyについて書きます。

問題

弊社のproxyは管理部署が違うため、設定変更できないです(前提)。
なので、proxyの設定変更をすれば良いという意見は聞きません!

  • 社内のproxyがDIRECT接続を設定していない。
    • proxyを設定したままだと社内のサーバに繋がらない。
    • 設定を消すとgithubなど外部のサービスに繋がらない。
  • ブラウザ設定(Windowsの場合はIEから設定するシステム用)のproxy設定にproxy.pacを設定している。
    • Linux上のコンソールで作業する時、http_proxy環境変数などにproxy.pacを設定できない(しても効かない)。
    • 最近はactive directoryで自動配信(IE上などで「自動的に設定する」となってる)になったので、proxy.pacの在処がわからない。

といった事が発生しますよね。

特にDIRECT接続が設定されていないのは問題があります。
たとえば、プログラムのコンパイル時など、社内/社外両方のリポジトリからライブラリを引っ張ってくる時とかに非常に困るんです。

暫定対策

自分一人だけが、手っ取り早くなんとかするというのなら、proxy用の環境変数の設定が早くできれば良いので、以下を実施していました。

  1. 社内のproxyサーバの情報を取得する
    proxy.pacをダウンロードするなり、人に聞くなりの手段にて。
    以降の説明では社内proxyを“192.168.100.10:3128”とします。
  2. proxy設定用のスクリプトを作成する
    proxy.shみたいなファイルを~/binとかに配置
  3. ~/.bashrcとか~/.zshrcとかにaliasを設定

    ’.’ を指定してあるので、sourceを指定しているのと同じ意味合いになります。
    なので、呼び出したshellに環境変数が設定された状態を作ることができるようになる訳です。
  4. proxyの要否をコマンド実行時に切り替え

    とか

    してからネットワークを使うコマンド実行

ビルドプロセス中とかでない場合、またはビルドプロセスでも外部のリポジトリに依存している物をローカルに先にキャッシュしておく、などで同時接続を防ぐ事ができるなら、まぁこれで許容できるかな、という感じですね。
これで一旦は切り替えが楽になったけれども、やっぱり一々切り変えるの面倒じゃないですか?

今実施している別の対策

多段proxyを自分のローカルPC上に建てました。
普段の作業をLinuxのコンソールで実施しているので、パッケージでsquidインストールして常に環境変数設定しとけば良いやん、と。

って、.bashrcか.zshrcに書いときゃえーやん、と。

なので、ローカルPCにsquidをインストールして、設定を記述。
ローカルなネットワークドメイン名とかは当然知っているものとして、squid.confのコメントを便りに設定しました。

以降では社内ドメインとして以下の2つを使用します。

  • example1.com
  • example2.com

また、社内LANのIPレンジとして以下の2つを使用しているとします。

  • 192.168.20.0/24
  • 192.168.100.0/24

2つづつ定義してあると、自分の環境に併せて編集する際に書き方わかるので良いかな、と……

proxy設定はiptablesなどの設定とかでもある様に定義する順番が重要だったりします。
ちゃんとサンプルファイルやコメントを見ながら自分の環境に併せるの重要ですよ!
以下、軽く解説

  • 1〜12行目は、ポート設定ですね。パッケージデフォルトの設定にも入っているかと。
  • 13〜15行目でローカルのネットワーク情報を設定してあります。
  • 16〜25行目で許可設定ですね。順番大事(許可してから全部塞ぐ)です!
    特に重要なのは23行目で、ローカルのセグメントには必ずDIRECTアクセスさせる所ですかね。
  • 26行目で新しく建てるproxyのポートを設定(デフォルト!)
  • 27〜28行目で社内プロキシ(転送先)を指定します。
  • 29〜35行目は無視するとして(よくわかってない)
  • 36行目でPCのホスト名をちゃんと設定しましょう。
    squidが返すエラーページにこのホスト名が載ってきます。localhostは適当過ぎる!
  • 37行目は無視するとして(よくわかってない再び)
  • 38行目でローカルのセグメントではない物のDIRECTアクセスを拒否してます。
  • 39行目はいらないかもしれないけれども、過去に上手く動かないものがあったので、サーバ名(ドメイン名指定なし)でブラウザアクセスした場合などに、サーバ名(ドメイン名指定あり)に変換する際のドメイン名になります。
    ※ 逆に邪魔になる時もあるので注意する。不要なら消しても影響ないはず。
  • 40行目は記載の意味が良くわからないですが、キャッシュしない(キャッシュプロキシとして動作しない)為の設定だそうです。
    (「キャッシュしない」のを「全て」で「拒否」する、と読んだら全部キャッシュしそうな気がしません?)

あとがき

長年戦ってきた社内proxyと折り合いを付ける為だけに頑張ってみた結果こうなりました…

本当はもう1つ問題があるけれども、完全に弊社の問題なので割愛。

 


2018年12月6日

adachi

Github project の導入事例

こんにちは。
ピクトリンク事業部の足立です。

ピクトリンクはプリントシール機で撮影した画像データを使ったコミュニケーションツールで、私はそのiOS版のアプリの開発を担当をしてます。

 

この記事は フリュー Advent Calendar 2018 の 12/07(金) の記事になります。
今回はiOSアプリ開発チームでの Github project 導入事例の紹介です。
 

ちなみに今日は私が在籍している京都事業所の忘年会なので楽しみにしています🍻🍷
テーマが 南国気分🏝で ほっこり☺️ リフレッシュ らしいので、夜は南国🏖に行ってきます。

 

Github project

Github が2016/09に開催した GitHub Universe 2016 で発表された新機能の一つです。
タスクをカンバン形式で管理してくれるツールです。

詳しくは About project boards をどうぞ。

 

きっかけ

導入したきっかけとしては、アプリの新機能開発を進める際に、iOSチーム内でタスクを分割し作業を進めることになったタイミングでした。
個人的には何回か使っていたので、せっかくなのでチームとして使ってみたいと思い提案しました。
 
新機能が大規模改修だったため、誰が何を担当していて、関連する Pull request がレビュー中 or マージ済みなのか?などの状況把握を簡単に管理できる状態が必須でした。
チャンスだと思い Github project はとても理想的なツールだと説明しました。
 

チームとして使うことは初めてでしたが、結果から見れば 導入したことは大成功🎉✨ だったと言えそうです。

 

Github project のよかったところ

使い方などの前に、まず良かったところを書かせていただきます😉
 

  • あとで見返したときにどんな対応をしたかが一目でわかる
  • Column が好きなだけ作れる
  • Card は Github Markdown形式で入力可能
  • Card に Pull request や Issue の番号を書くとプレビュー表示
  • Automated の設定だと Pull request や Issue の状態によって自動でカラムが移動される
     

などが挙げられそうです。

 

使い方

Github project の作り方

  1. Github で対象のリポジトリを選び Projects を選ぶ
  2. New Project クリックして新規作成する
    github-projects_toppage

  3. Project board nameDescription に必要な情報を記入

  4. Project template を選ぶ
  5. Create project クリックで完了
    github-projects_new-project

ここで重要なのが Project template を選ぶ です。
 

Automated kanban または Automated kanban with review がチョーおすすめです💕
これを設定しておくことで Pull request を紐付けていると、レビュー状態になった時や、マージされたタイミングで自動でカラムの移動をしてくれます。
動かし忘れなどもないので、とても便利でしたね。

Column / Card の使い方

Project を作った後は、使うだけです。
使い方も簡単でテンプレートで出来上がったものをそのまま使うもよし、必要な Column を追加しても良いです。
最近使用した例としては以下のような構成にしました。
 

  • Bug: 開発中に見つけたバグのタスク
  • Enhancement: 機能開発するタスク
  • Refactoring: 開発中に見つけたリファクタしたいタスク
  • In progress: 作業中タスクや Pull requestカード
  • Done: 作業が終わったタスクやマージされた Pull requestカード
     

複数人で作業していても(ほぼ)リアルタイムで同期されるので安心です。
他の人が動かしているのを見てちょっと感動したり・・・😂✨
 

Card は Markdown 形式で記述できるのも良いです。
1タスク1カードにするのがおすすめです。
 

全てが Github の中で管理されているので Card に Pull request や Issue の番号(#1234)と書くと参照情報としてプレビューもしてくれるのとても便利でした。

 

まとめ

Github project の導入事例というか使い方になってしまいましたが、簡単にまとめてみました。
はじめに書いた よかったところ に挙げているようにとても使いやすく、これからのチーム開発で活躍してくれそうなツールでした。
 

この記事では書けませんでしたが iOS開発チームでは大規模な機能開発の時は Epic branch 運用 も取り入れているのですが Github project とはとても相性も良い感じでした。
 

Epic branch 運用 についてはまた別の記事で紹介させていただきたいと思います。
 
 

みなさんもぜひ Github project を導入してチーム開発の効率をあげてみませんか?
 


2018年12月6日

いしはら

エンジニアが知っておいたら楽になる配色知識

この記事は フリューAdvent Calendar 2018 の12/06分です。
 

はじめに

こんにちは。ピクトリンク事業部開発部のいっさんです。
普段はWebAPIの開発などをやっていますが、
趣味でフロントやデザインの勉強をやっています。
むしろ趣味のほうが得意分野で色彩検定2級をもってます。
 

今日はエンジニアが知っておけばいい、色に関する豆知識を紹介します。
 
 

色相環

モックなどを開発していて、配色にこまること、ありませんか?
配色に困ったときは「色相環」を見てみると便利です。
 
「色相」とは赤、黄、緑、青、紫といった色の様相の相違のことで、
「色相環」とは色を円状にならべた図のことをいいます。
 

色相環
 
 

ダイアード

この円の向かい合った色同士が「補色」と呼ばれ、
この色の組み合わせをするとインパクトが強くなります。ダイアードと呼ばれています。
例えば赤だと反対色は緑になります。
なのでワンポイントで目立たせたいときに反対色を使うと良いでしょう。
 
 

アイデンティティ

無難な組み合わせを選びたいときは、
隣接した左右を選ぶと無難になります。アイデンティティと呼ばれています。
例えば、オレンジだと赤や黄色になります。
ただ似たような色になるので単調になりがちです。
 
 

トライアド

バランスを取れた配色の組み合わせで
トライアドというものがあります。
色相環を三等分した位置にある3色で配色します。
例えば、黄色の場合、赤紫と青になります。
 
 

気をつけること

使う色は3色以下にすることおすすめします。
3色以上になるとごちゃごちゃしてしまい、見にくくなってしまいます。
色数が少ない方がまとまりのあるスッキリしたデザインになります。
 
 

さいごに

このように、色相環を見て配色を決めるととても便利です。
紹介したのは主な3つでしたが、
他にも色相環を四等分した位置でカラフルな配色にするテトラードなどがあります。
興味ある人は調べてみてくださいね。


2018年12月5日

araki

AndroidのIn-app Billing APIのバージョンについて

この記事は フリューAdvent Calendar 2018 の12/05分です。

はじめに

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。携帯は、Googleブランドの最新スマートフォンPixel3を使っています。非の打ち所がない良い端末なので、みなさん買いましょう。

今回の記事では、Androidの課金APIである In-app Billing API のバージョンについて書きたいと思います。

In-app Billing API とは

公式ドキュメントは以下です。日本語ドキュメントは情報が古かったので、英語ドキュメントを貼ってあります。2018/12/05現在、日本語ドキュメントの最終更新日は2018/4/25、英語ドキュメントの最終更新日は2018/7/17でした。

https://developer.android.com/google/play/billing/api?hl=en

ひとことで言うと、AndroidアプリでGoogle Play課金を実施するためのAPIです。AIDL(Android Interface Definition Language) と呼ばれるインターフェース定義言語によって定義されるAPIで、 .aidl ファイルから生成されるJavaのインターフェースによって利用することができます。

In-app Billing API は、 Google SamplesのIabHelper や Play Billing Library  のように上手くラップしたものがあり、それらを使う分には基本的に意識する必要はないのですが、バージョンごとに使えるメソッドが異なります。日本語ドキュメントや日本語の記事では単に In-app Billing API version 3 と書かれていることが多いので、一度整理してみようというのがこの記事のモチベーションです。

各バージョンで利用できるメソッド

https://developer.android.com/google/play/billing/billing_reference?hl=en

上記のドキュメントを参考に、In-app Billing API version 3 以降のバージョンについて、各バージョンでどのようなメソッドが利用できるかを説明します。

 

 バージョン  メソッド  説明
 3以降  isBillingSupported()  端末がIn-app Billing APIの特定バージョンに対応しているかを調べるためのメソッドです。
 3以降  getSkuDetails()  商品(SKU)の詳細情報を入手できます。
 3以降  getBuyIntent()  このメソッドを利用することで、Google Playによる購入フローを開始するための PendingIntent が取得できます。
 3以降  consumePurchase()  アプリ内アイテムの消費を実施します。たとえば、ゲームなどで有料のアイテムを消費して効果を得た時にこのメソッドを呼びます。
 3以降  getPurchases()  ユーザーが所有する商品(未消費の商品、有効期間内の定期購読)を返します。
 5以降  getBuyIntentToReplaceSkus()  定期購入のアップグレード/ダウングレードに利用されるメソッドです。購読したい商品に加えて、購読解除したい商品を指定することで、新しい商品の購読と、古い商品の購読解除を同時に実施します。
 6以降  getBuyIntentExtraParams()  getBuyIntent() に追加のパラメータを渡せるメソッドです。getBuyIntentToReplaceSkus() と同様に購読解除したい商品を追加パラメータで指定できるので、実質 getBuyIntentToReplaceSkus() のバージョンアップ版と考えられます。
 6以降  getPurchaseHistory()  ユーザーの購入履歴を返します。期限切れの定期購読や、キャンセルされた購入、消費済みの商品も含まれます。
 7以降  isBillingSupportedExtraParams()  isBillingSupported() に加えてアプリ課金のタイプについても調べることができるメソッドです。アプリ課金のタイプとして VR の購入フローを指定して、サポートしているかを調べられます。

 

Play Billing Libraryについて

Googleから提供されている課金のライブラリ Play Billing Library と In-app Billing API のバージョンについても言及しておきます。

2018/12/05 現在リリースされている Play Billing Library の最新バージョン 1.2 の課金周りのコードを見てみましょう。

このコードにあるように、Play Billing Library は、現在 In-app Billing API のバージョン3〜8に対応しているようです。現在の最新APIに対応できていると思われます。

さいごに

この記事では、In-app Billing API のバージョンについて書きました。普段ラップされていて意識しない部分ですが、内部のAPIを調べてみると意外と知らなかったパラメータがあったので、興味深かったです。アプリ課金に関する情報は定期的にアップデートされる印象があるので、しっかりとキャッチアップしていきたいと思います。