コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

GoogleスライドでUnicode絵文字をきれいに出す場合はオフラインにする

雑記 Tips

実はオンラインだと出ないという話。

事象

作成時の状態でやるときれいに絵文字が出るが

f:id:shinkufencer:20190110093211p:plain
編集時

プレゼンテーション状態になると出ない

f:id:shinkufencer:20190110093334p:plain

解決策

オフラインにする ※おそらくインターネット接続状況が変化する契機っぽい

補足

ただしpdf書き出しはどうにもならない。（オフラインでは書き出しできないため）そのためスライドをあとでアップする場合はUnicode絵文字を使うのは微妙。

参考元リンク

AmazonSNSのAndroidへの通知はGCMからFCMに移り変わる様子

AWS

Push通知にAmazonSNSを使っていて、GCMのエンドポイントに叩いている疑いがあったので不安だったが、それらの向け先は変わってくれそう、という話。

概要

  • AmazonSNSはスマートフォンのPush通知ができるが、選択項目が「GCM」と書かれている
  • ただしGCM(GoogleCloudMessaging)は2019年の4月に廃止され、FCM(FirebaseCloudMessaging)に移行する。
  • Amazon側のドキュメントには明記されていないがアナウンスはされている

f:id:shinkufencer:20190110074332p:plain
こんな感じでFCMじゃなくGCMと書かれている

情報ソース

The End of Google Cloud Messaging, and What it Means for Your Apps | AWS Messaging & Targeting Blog

抜きより意訳

GCMからFCMに移行した場合でも、Amazon PinpointとAmazon SNSを使用できますか？


はい。アプリケーションに接続してAmazon SNSとAmazon Pinpointの両方を介してメッセージを送信する能力は変わりません。これらの変更を反映させるために、Amazon SNSとAmazon Pinpointのドキュメントを近日更新します。

GCMからFCMに移行しない場合でも、Amazon PinpointとAmazon SNSを使用できますか？


はい。何もしなくても、既存の資格情報とGCMトークンは引き続き有効です。Amazon PinpointまたはAmazon SNSを使用するように以前に設定したすべてのアプリケーションは、引き続き正常に機能します。Amazon PinpointまたはAmazon SNSのAPIを呼び出すと、FCMサーバーエンドポイントへのリクエストが直接開始されます。

参考リンク

多層アーキテクチャが生まれた利点を考える

雑記

資料集めついでの雑記です。

層の訳としてのTierとLayer

多層アーキテクチャ、層の部分が、Tier と Layer で書かれることが多い。

この2者の違いは物理的な層、例えばクライアントマシンと、サーバーマシンが異なる場合を Tier で表記し、ソフトウェアや概念的な層を Layer と記述する。

今回は Tier に関して掘り下げていく。

2層アーキテクチャと3層アーキテクチャ

昔は各クライアントとデータベースサーバが直接接続する仕組みが存在した。それが2層アーキテクチャと呼ばれるものとしてありました。

2層アーキテクチャは以下のような欠点を抱えていました。

  • クライアントにすべてのロジックを詰め込むので、UIとビジネスロジックが密結合な状態になり、いずれかを変更すると互いに影響を受けてしまう
  • 複雑なことをやろうとすると処理できることがクライアントマシンのスペックに依存するため導入環境によって動きが代わってしまう
  • DBと直接つながるので、人数が増えるとその分アクセス負荷も増大する。

そこで間に中間のビジネスロジックを担当するサーバを間に入れる形が提案されました。それが3層アーキテクチャです。

3層の場合はクライアント側が「プレゼンテーション層」と呼ばれるようになり、ビジネスロジックを担当するサーバは「ロジック（もしくはアプリケーション）層」、DBなどのデータを担当する部分を「データ層」という3層で呼ばれるケースが多い。

層を分けることで何を期待したのか

2層から3層に分けることで、以下のことを期待されていた

  • プレゼンテーション（クライアント）側はUIだけ、ロジック層はビジネス部分の処理を、データ層はデータを管理するという形になり、機能毎に疎になる。
  • クライアントとDBの間に1つ挟むことにより、裏側のデータ層のミドルウェアが変わったり、プレゼンテーション側のUIが変わっても間の層が適切なインターフェイスになっていればメンテナンスが容易。
  • ビジネスロジック層は中央集権になるので、ロジックのミスなどに気づきやすい。

レイヤードアーキテクチャに置き換える

レイヤードアーキテクチャと呼ばれるものも、利点としては同じ。物理的ではなくなった分、機能ごとに層をつくりやすくなり、責務ごとに層をつくることができる。

参考リンク

AmazonSNSをPush通知で登場する言葉たちの関係性をまとめる

AWS 雑記

種類が多くて混乱するのでまとめる

登場する言葉

AmazonResourceName（arn）が存在する単位で記載する

Application

iOS（AppleのAPNs）、Android（GoogleCloudMessaging)などの粒度の配信先プラットフォームを指す。

EndPoint

Applicationに対して、発行されるARN。各Applicationに対して、EndPointARNが発行される1:Nの関係にある。

Topic

購読したい対象のトピック。各EndpointはこのTopicと紐づけて、Topicに対して通知の内容を伝える。

粒度の例としては「全体通知」「更新通知」などがある。

Subscription

TopicとEndPointの関係性を示すもの。EndpointがTopicを購読していることを管理するための情報として捉えると良い。

なお、Topicに紐づくEndPointを外す場合はこのsubscribe設定時に振り出されたarnを使って解除処理を行う。

参考リンク

チームメンバー同士の期待値を可視化する『ドラッカー風エクササイズ』をざっくりまとめる

ざっくりまとめ チームビルディング

「あの人ならコレぐらいやってほしいよね…」とか「あれ、こんなにやってくれなくてもいいのに」みたいな勝手な期待値から気持ちが萎えるのを防ぐために。（やってみたいがやったことはない）

「ドラッカー風エクササイズ」とは

書籍「アジャイルサムライ」にて紹介されたチームメンバーの期待値をすり合わせるプラクティス。

チームメンバーに以下の4つの質問に対して、付箋などで張り出して話合う。

  • 自分は何が得意なのか？
  • 自分はどうやって貢献するつもりか？
  • 自分が大切に思う価値は何か？
  • チームメンバーは自分にどんな成果を期待しているかと思うか？

効果

  • お互いの得意なことが理解できることによって、いまやっていることやってもらっていることの期待値調整ができる
    • リーダーが実はチームリーダー初体験だったりとか、黙々とHTMLコーディング作業する人が実はデータ設計得意とか、お互いの知らない点、頼れる点を発見できる
  • メンバー本人が期待すること、されることを理解できるので、他の人が期待していることの方向性のズレを発見することができる

注意点

  • 腹を割って話せる場を提供することが大事。建前重視になって模範解答みたいなことを書いては意味がないし、疑心暗鬼になって腹の探り合いになってしまう。しっかりとその点ファシリテーターが気を使う必要がある。

アレンジ

参考リンクや三鈷杵席では様々なアレンジがされている。

  • 質問の内容を変えてみる
  • 質問の内容を加えてみる

という感じだが、多くは「自分の考えている得意分野はみんなにちゃんと伝わっているか？」という趣旨の質問が多く、質問を提示後の会話をスムーズにするための設問が多い様子。

参考リンク

参考書籍

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

MySQLでデータは複製せず、テーブル構成だけを複製する場合、no-dataオプションでmysqldumpすると良い

Tips

既存のデータベースにRailsアプリケーションを導入すると、もともとmigrationがないからテスト用のschema作れないとかそういうことがあるので、そこらへんに対するアプローチ。

環境

$ mysql --version
mysql  Ver 14.14 Distrib 5.7.24, for osx10.14 (x86_64) using  EditLine wrapper

やり方

--no-data または省略形の -d を使う。

実例

$ mysqldump -u root sample_app_development --no-data > no_data_dump.sql

試しにオプションをつけないものとdiffをとる

$ mysqldump -u root sample_app_development> dump.sql
$ diff dump.sql no_data_dump.sql 
# (中略)
109,118d78
< 
< --
< -- Dumping data for table `users`
< --
< 
< LOCK TABLES `users` WRITE;
< /*!40000 ALTER TABLE `users` DISABLE KEYS */;
< INSERT INTO `users` VALUES (1,NULL,'2018-12-25 15:54:06','2018-12-25 15:54:06'),(2,NULL,'2018-12-25 16:58:08','2018-12-25 16:58:08'),(3,NULL,'2018-12-25 16:58:57','2018-12-25 16:58:57'),(4,NULL,'2018-12-25 17:02:05','2018-12-25 17:02:05'),(5,NULL,'2018-12-25 17:02:06','2018-12-25 17:02:06'),(6,NULL,'2018-12-25 17:02:11','2018-12-25 17:02:11'),(7,'Taro','2018-12-25 17:12:10','2018-12-25 17:12:10'),(8,'Taro','2018-12-25 17:12:42','2018-12-25 17:12:42');
< /*!40000 ALTER TABLE `users` ENABLE KEYS */;
< UNLOCK TABLES;
129c89
< -- Dump completed on 2019-01-06 23:08:36
---
> -- Dump completed on 2019-01-06 23:08:28

INSERT分が no-data のほうにはないことがわかる

参考リンク

Unity系の更新量がすごいブログ紹介

雑記 Unity

年始のゆっくり運転なので、畑違えど目指したいブログたちのご紹介です。

コガネブログ

平日ほぼ毎日更新、しかも下手すると1日に2記事とか出てくる。そしてスクリーンショットを交えてた丁寧な説明。業務時間に書いている感じするけどそれだとしてもすごい。

テラシュールブログ

Unity界隈ではおなじみの椿さんのブログ。更新頻度は3日に1回程度。昔開発しているときにいろいろとおせわになりました。

Unity AssetStoreまとめ

AssetStoreに出ているAssetを自腹を切って紹介するブログ。有料スマホアプリブログのAssetStore版といっても過言ではない感じ。Assetの貴重な日本語紹介でとてもありがたい