サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
qiita.com/hinom77
背景 DIとDIコンテナを調べてみるも、"どういうものか"や"メリット"がパット見よくわからなかった。 そこで、先輩に聞いたら解説がすごいシンプルで目から鱗だったので記載する。 本題の前に DI(Dependency Injection)は「依存性注入」と直訳されるが、以下の英語版Wikipediaからの引用のように、「オブジェクト注入」という解釈のほうがより理解しやすい。 A dependency is an object that can be used (a service). 参考: Dependency Injection - Wikipedia DI(Dependency Injection) - オブジェクト注入 1) 以下のように、コンストラクタで他のオブジェクト(Sampleクラス)を参照するClazzクラスを考えるとする。 class Clazz { private $
この記事は Recruit Engineers Advent Calendar 2017 の1日目の記事です。 ちなみに、昨年もRecruit Engineers Advent Calendar 2016を開催しており、2016年版の締めは@kpkpkpさんの「数十社、数万人規模の組織のエンジニア交流会の話」でした。 今年もこれから1ヶ月に渡り、様々な知見共有のポストを見れる事、一個人としても非常に楽しみにしております。 何卒よろしくお願いいたします。 はじめに 基本、エンジニアでは多い特性かと思うが、自分自身もその例に漏れず亀でのんびり屋さんな側面があります。 しかし一方でスピードも求められるのがこのエンジニアという職種。 『より仕事を効率的に、スマートに、スピーディに出来るようになりたい。』 その中で、チリも積もれば山となっている単純作業。 これを効率化しまくれば、より無駄なところに足
はじめに ここまでの流れを見ていると、将来的にアプリからWebまで、KotlinとSwift(あとJS)で全て完結みたいな将来が起こり得るかもしれないなと勝手に推察している。 一体どういうことか以下に書いていく。 ここまでの流れ 1. Single Page Applicationの台頭 最近のトレンドとして、バックエンドでは全て共通のAPIを使用して、 Web, iOS App, Android Appをそれぞれを全てフロント側で表現するアーキテクチャが模索されてきている。 2. Kotlinが、Android公式言語に 2017年5月KotlinがAndroidの公式言語になる。 https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-now-official/ そして、以下の理由からも今後Kotlinを使う機運が上がると
背景 目標到達プロセスが、他のアナリティクスツールと感じが異なるので共有したく記事を作成した。 具体的にどういうことかというと、以下に例を書く。 「A→B→C」という画面経由のPVを測定したい。 そのため、上記のようにFirebaseの目標到達プロセスを設定する。 PV数を以下のように考える A: 総計100 B: 総計200(うちAを経由したものは50) C: 総計300(うちAとBを経由したものは25) このとき、目標到達プロセスでは、 100 → 50 → 25 となっていることが期待される。 しかし、実際は 100 → 200 → 300 という表示になる。 どうやらこちら「オープンな目標到達プロセス(Open Funnel)」という考え方でFirebaseの仕様らしい。 一方で、あるイベントを経由したもののみの場合の目標到達プロセスを「閉じた目標到達プロセス(Closed Fun
はじめに 2017/04/05にリクルートテクノロジーズで行われた和田卓人(@t_wada)先生の『エンジニアとしてこの先生きのこるために』の講義録です。 講義内容が大変面白かったのですが、共有されているスライドだけでは講義内でカバーされてない内容もあり、せっかく喋られていた良き内容を詳細な部分までフォローできかねてると感じること 和田先生自身が、本講義の内容をどんどんWeb上に投稿することを講義内で推奨されていたこと(下部、"質疑応答"の項参照) 上記理由より、この講義録を投稿します。 講義スライド 自己紹介 @t_wada(2004年辺りからこのネーミング) ※ハイフンのアカウント、アンダースコア使わないアカウントも 『プログラマが知るべき97のこと』監修 『SQLアンチパターン』監訳(共に監訳している和田省二は実の父親) gihyo.jpの連載、power-assert-js(非英語
はじめに Firebase、そしてFirebase Analyticsを理解する上で、Firebase公式のドキュメントとサンプルコードは用意されているものの、思わぬところにハマりどころがあったり、仕様がわかりにくい部分があるため、 初めてFirebaseを導入し、運用する上で必要と思ったポイントを自身の主観でまとめました。 1章 Firebaseの導入 1.1 そもそもFirebaseとは? Firebase概要 Firebaseトップページ Firebaseの始め方 Firebase導入のメリット それでもFirebaseを使うべき5つのメリット 1.2 公式ドキュメント スタートガイド 1.3 リンクしておくページ Firebase開発者ブログ Google Developers Japan: Firebase Firebaseコミュニティ Firebase Community on
ユーザープロパティはFirebase運用の一番のボトルネック いきなり怒りから入る文体もなかなかないが、ユーザープロパティはFirebaseの運用を考える上でコアの機能(特にRemote Configと組み合わせてのABテスト)でありながら、ボトルネックになるリスクが非常に高い。 特にやばいのが以下の仕様である。 ユーザープロパティは一度作成したら、ユーザプロパティ名を修正できない。 ユーザープロパティは一度作成したら、削除できない。 ユーザープロパティの作成上限は25個である。 ユーザープロパティ名の文字上限は24文字である。 引用: ユーザー プロパティを設定する setUserProperty() 上記より運用に際し、慎重に戦略を練らなければいけない。 ユーザープロパティで使用されると想定されるのが、そのままの意味だがユーザーのプロパティ(例えば、性別・地域など)、ABテストのフィル
背景 先日、『Firebaseをやめた4つの理由』という記事が出ていて、注目を集めていた。 確かにFirebaseではこちらに書かれているような圧倒的に弱い部分があるのは確かである。 しかし、以下に示す5つのメリットを考えたときに、本当に導入しないのは適切かという想いがあり、この記事を書き起こした。 5つのメリット ① 機能の組み合わせで他ツールで難しいことが可能に! 例えばFirebase Analyticsのはじめにのページに以下の記載があるが、このように特定のユーザーにのみ絞って画面の出し分け/ABテストや通知を送ることが可能になる。 また、その特定のユーザーをクラッシュしたユーザーやある通知を受け取ったユーザー、コンバージョンしたユーザーとすることもできる。 そして、これらはFirebaseだからこそ容易に実現できることであり、他のツールでは労力を要したりそもそも実現が難しかったり
このページを最初にブックマークしてみませんか?
『@hinom77のマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く