サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
大そうじへの備え
meihong.work
今、勤務先のフィードフォースではエンジニアのキャリアパスの見直しをしているが、その議論の場で自分が「失敗力」の重要性について熱く語ったので、自分の中にある「失敗力」について書き留めておきたい。 失敗こそが成長の原動力である 失敗力といっても全く真新しい話ではなく、これまで言い古されている話ではあるが、ここのところ自分が常に意識していることではある。 一言で言うと、「失敗こそ成長のきっかけである」ということなのだが、実は非常に難しいテーマでもある。 なぜ難しいのか 特に日本人の場合、教育を通じて常に「失敗しない」「失敗したら即死」といったようなマインドセットが染みついている。そのため、個々人が 失敗を恐れるがゆえに安全マージンを取り過ぎる。失敗を恐れすぎてそもそも何もやらない。 となってしまう。また、ひとたび失敗すると 「何で失敗したのか」という「起こってまったことの理由」にフォーカスしすぎ
2020 年のコロナ禍の中、Apple が ITP での Cookie の扱いの厳格化に引き続いて IDFAの取扱の厳格化を進めることとなった。 今回は、2020 年後半に Facebook がどのように広告でユーザをトラッキングするのかを NDA に触れない範囲で考察したい。 TL; DR まずは結論を先に書いておく。 既存のトラッキング手法は全て死ぬ。ユーザ属性を持たない / 推測できないプラットフォームは名寄せできずにパフォーマンスを落としてしまう。既存のダイレクトレスポンスマーケティングを踏襲する限り、「個人情報が露出してしまうかもしれない」問題を乗り越えつつも、新しいトラッキング方法に早急に移行する必要がある。 また、シグナルを集める観点からも、エンドユーザがログインするタイミングを購買行動というストーリーにあわせて早めに設定する必要がある。つまり、ログインとは単純に認可・認証で
株式会社フィードフォース社員がお届けする、フィードフォースにまつわる色々を書いていくアドベントカレンダーです！(੭ु ›ω‹ )੭ु⁾⁾ 遂に5回目。 去年までのカレンダーも是非。 – [2018年](https://adventar.org/calendars/3235) – [2017年](https://adventar.org/calendars/2155…
この記事は、Feedforce Advent Calendar 2018 24 日目の投稿になる。前日は弊社フォントマニア、mashabow 氏による「typeの話」だった。 今年中盤からバックエンドエンジニアの 1on1 を始めることになった。一般的なベストプラクティスはすでにいろいろなところで書かれていると思うので、Feedforce Advent Calendar 2018 24 日目の記事として 1on1 をやる上での自分なりにどうしているかなどを書き散らしてみたい。 そもそも そもそも、自分は元々 1on1 とか MTG が苦手だった。より具体的に書くと、 他人の話を聞けない。人の話を聞いていると自分の話をぶっ込みたくなる。人の話を大体は批判的に聞いている。批判するのは得意だが肯定するのは大の苦手。他人の成長・悩みに興味がない。「そんなの自分でやること・解決することでしょ?」的発
なぜ違和感を感じるか この件に関して、自分は Twitter と 開発者双方に違和感を感じている。しかし、一番大きいのはこの記事が開発者の視点に立ちすぎているところにある。 自分からすると、タイムラインの読み出しというのは営利企業が運用するネットワークサービスにとって当然制限されてしかるべきものだと感じている。なぜなら、そこは広告価値の一番高い面だからだ。 もちろん、アプリ開発者からすると振り回されて疲弊させられるということも理解はできる。しかし、それはプラットフォーム上でサービスを提供する限りは不可避なもので、別に今に始まったことではない。Twitter は以前からレートリミットが厳しかったし、Facebook / Instagram も 2014 年に権限審査制度を導入と同時にニュースフィードの読み出しも原則禁止、今年 8 月には Facebook に対する API 経由の投稿を一切禁
今年 5 月から Facebook でドメイン認証が導入された。直近はそこまで影響はないが、今後、広告入札に影響が出るので早めに対応、という話は代理店経由で効いたりするケースも多いかと思う。 ドメイン認証とは ドメイン認証については「Facebookページ利用者なら知っておくべき、リンク先URLのドメイン認証機能の使い方｜アナグラム株式会社」が詳しいのでこちら参照。 小粒だが気をつけるべき点 CMS を使っていたり部門が違っていたりすると、<meta> タグを挿入したり認証用のファイルを置いたりするのが困難ということがたまにあるかと思う。正直なところ、Google Search Console でも同じ作業をするので、どう違うのか、なぜそんな困難なのか微妙だとは思うが…… そんなときに、DNS の TXT レコードに登録してドメイン認証するという方法がある。DNS にエントリを追加するので
6 月 5 日、Instagram Shopping が正式にローンチされた。クローズドβ時代にちょっと関わることができたので、ざっくりと説明しておきたい。 そもそもの話 そもそもの話として、Instagram Shopping は広告ではなく、オーガニック投稿である。なので、配信そのものは無料で可能となる。必要なものが用意できるのであれば、配信までは無料でできるのはメリットと言っていい。 どういうものか これはクローズド β 時代から実際に配信されている Gilt Japan のものだが、ぱっと見は普通のオーガニック投稿のように見える。 この投稿をタップすると、こんな感じで紐付けられた商品名と金額を記載したタグがポップアップ表示されるようになる。 ポップアップをタップしてもランディングページに行くわけではなく、さらに Instagram アプリ内で商品詳細ページが表示される。 ここで S
F8 でグループ機能が強化された、Facebook Pixel での履歴をユーザが削除できるようになる、Facebook が出会い系に参入など、色々と大きなニュースがあったが、一方で Graph API v3.0 と同時に一時中断されていた Facebook app の審査がより厳しくなって復活した。 気をつけるべき点 今回の審査で大きく変わる点は以下 3 点。 すでに審査が通過していたとしても、8 月 1 日までに再度審査が必要。 特定のパーミッションにアクセスするビジネスについては、光熱水道費の請求書や定款、法人番号の提出などによる実在確認が必要。 サードパーティとして Facebook プラットフォームにアクセスするようなビジネスについては、収集したデータについて目的外利用をしないという追加の契約が必要。 この記事を読んでいる層にとっては、再審査が一番問題になるだろう。 再審査 たと
CA 問題に関連して、ユーザとして Facebook に投稿するために必要なパーミッション publish_actions が廃止されることになった。これによって Facebook でのレイバンスパムはなくなるが、一方で廃止までの期間が限られることもあり、ベンダーには激震が走るだろう。 変更概要 日本時間 4 月 25 日 (水) 未明に公開された "New Facebook Platform Product Changes and Policy Updates" によると、今回、以下変更が加わることになった。 Facebook ログイン Facebook ユーザとして投稿が可能となる権限 publish_actions が廃止となる。publish_actions 取得には Facebook 側審査が必要となるが、今日以降、審査に提出できない。すでに承認されているものについては、8/1
これまで何度か AMD Ryzen 7 が不安定でなんとか安定させようと頑張ってきたが、カーネル 4.13 以降でもようやく安定してきたので書いておく。 特に原因は判明していないが、RMA した上で CONFIG_RCU_NOCB_CPU=y でカーネルを再コンパイルした上で、カーネルオプションに rcu_nocbs=0-15 などとしてすべての論理 CPU を指定する UEFI / BIOS の設定で C6 ステートを disabled にする と安定するという話が流れていた。 前回までにこれらを試してみたものの、やはりうちの Ryzen 7 1700 では 高負荷をかけると rcu_sched detected stalls on CPUs/tasks で論理 CPU がストールする 高負荷をかけなくてもやはり rcu_sched detected stalls on CPUs/tas
ケンブリッジ・アナリティカ問題で Facebook が急速に仕様を変更していて、特に Instagram を中心として Facebook エコシステム内でのサードパーティビジネスに結構大きなインパクトが出ている。そんな中、さらに個人情報取得に関して大きな変更が入った。 仕様変更概要 日本時間 4/20 (金) 朝に公開された "Facebook Login Changes to Address Abuse" によると、以下の変更点が加わった。 App-Scoped User ID を使って生成した URL から各個人のプロフィールページにリダイレクトしなくなった。 Facebook ログイン経由で取得された各個人のプロフィールアイコン URL へのアクセスについて、レート制限が加わるようになった。 ASID ベースの URL の扱いの変更 まず変更点のうちの前者だが、2014 年の Gra
ケンブリッジ・アナリティカが目的外利用していた属性情報が 5,000 万件ではなく 8,700 万件という話が出ている (Facebook、ユーザー情報の不正取得は最大8700万人分に–数々の対策を発表 – ZDNet Japan)が、一方で、前回少し触れた Facebook app のレビューが厳しくなる件で続報が出ていた。 何が変わったか 今回は Facebook CTO の Mike Schroepfer 氏の記事と Developer News の記事の 2 本が出ているが、内容的にはほぼ変わらない。 An Update on Our Plans to Restrict Data Access on Facebook | Facebook Newsroom API and Other Platform Product Changes – Facebook for Developer
この投稿は feedforce Advent Calendar 2017 の 24 日目、イブ投稿分になる。昨日は新プロダクト中心に活躍している弊社川田の「御徒町・湯島・末広町エリアに勤めるビジネスマンが選ぶランチにおすすめの美味い店10選」だった。 さて、今年 3 月あたりから英会話を始めていて、1 ヶ月経過後に記事を書いていたが、何とか心が折れずに 10 ヶ月続いてきた。前回と被るところもあるが、何となく独学のコツを掴んだので、そのことについて書いてみたい。 大前提 日本にいながら勉強する この記事の大前提は、日本で社会人として暮らしながら英会話をなんとかするというところにある。海外留学する、海外赴任する場合は文字通り英語漬けの生活になるので今回の対象にはしない。 日本人訛りの英語 まず大前提として、社会人が仕事をしながら訛りの少ない英語を話せるようになるには相当の時間が必要になる。な
RMA 公式フォーラムなどでも色々と民間療法が試されていたこの件だが、Linux カーネルコミッタの武内さんのご尽力で RMA できることになったので RMA することにした。 RMA 問い合わせ RMA の問い合わせはAMD の Online Service Request からで、まだ誰も RMA していなかった 6 月 24 日で、日本人スタッフに情報が行き渡っていない可能性を考えて英語で送ることにした。 Dear sirs, I’m using Ryzen 1700 with the latest version of Linux Kernel and AGESA 1006 enabled BIOS but my kernel crashes in a few hours or I have a SEGV during compilation something if I enab
この問題は無事解決した。 AMD Ryzen 7 1700 + Linux でカーネルのクラッシュと SEGV が起きる問題が解決しました → していませんでした AMD Ryzen 7 1700 + Linux カーネル 4.13 以降でカーネルがクラッシュする問題 AMD Ryzen 向け一部マザーボードでは UEFI から C6 ステートを disabled にできない件 我が家の自宅サーバは 10 年近く Xeon X3350 で稼働していたが、 さすがに 10 年も経つと HDD のセクタ置換済みが結構増えてきた。 別に Phenom II 1065T で稼働する KVM マシンがあるが、電気代の関係で 1 台にまとめたい。 1.5TB が溢れそうになってきた。 こともあって、最近リリースされた Ryzen 1700 でリプレイスすることにした。 しかし、実際に稼働させてみると
この記事は、 フィードフォースエンジニア Advent Calendar 2015 11 日目の記事となる。 前日は mgi166 氏による「今更ながら minitest 入門してみた話」。 最近は、オフィスではプロダクトの雑用係、プライベートではお受験だの家の新築だので全くエンジニアっぽいことはしていないという…… さて、もう先月の話になるが、弊社は Facebook Marketing Partner ではないものの、サンフランシスコにある Pier 35 で開催された Facebook Global Partner Summit に弊社社長と 2 人で行ってきた。 なお、2人とも英語はほぼ話せない。 なお、2人とも英語はほぼ話せない。 なお、2人とも英語はほぼ話せない。(リスニングはそれなりにできる、多分) サンフランシスコ入り イベント自体は 11/10, 11 (現地時間) だっ
Graph API v2.2 と同時に Ads API v2.2 がリリースされた。これまで Ads API は事実上 Facebook とコネクションがないと開放して貰えなかったが、バージョニングが導入された 10 月 1 日の v2.1 以降は、申請なしでも 5 広告アカウント、申請すれば 25 広告アカウントまで利用できるようになった。(ただし、API へのアクセス制限はかなり強めに設定される) v2.1 以降、まず Ads API アプリを Development Access で開発し、ある程度完成した時点で Basic Access に submission することになる。ある程度成功してきたら Standard Access に切り替わるイメージだろうか。ただし、Development Access ほどではないにせよ、Basic Access でも API 呼び出し制限は
前回の Graph API v2.1 リリースからわずか 83 日、日本時間の今日 (10/31) 未明に Graph API v2.2 が発表された。細かい点は色々あるにしても、前回までと異なり、今回は規約上または利用上の制限を加える方向のアップデートはほぼないといってよい。 主な変更点は以下の通り。 API 経由で Facebook ページ投稿のコメントの非表示化および非表示化のやり直しが可能となった。これにともない、コメント関連の API に can_hide や is_hidden などのフィールドが追加されている。 複数アプリ間で名寄せを可能にするための新フィールド、token_for_business がユーザオブジェクトに追加された。 Facebook app をビジネスマネージャに登録していれば、token_for_business が取得できるようになる。 ただし、紐付け
[2014/11/18 追記] window.close() できない問題は、iOS 8.1.1 で解消した。 今かかわっているプロダクトでは、JavaScript の window.open() で別ウィンドウを開いた上で Facebook ログインダイアログを表示させ、認証完了時に window.close() で閉じているが、iOS 8.0 がまだベータだったころに検証したところ、window.close() で閉じられないという問題があった。 Apple の場合は突然仕様を色々変えてくるので仕様なのかバグなのか分からなかったが、チームメンバーがフォーラムに書き込んだところ、どうやらバグだということが分かった。 そしてこれの影響が出ていたのが他でもない Facebook JavaScript SDK。類似のチケットがいくつか切られていたが、「iOS8 on Safari: FB Au
ここのところ色々と話題になっている Shell Shock 問題、顧客からの問い合わせで色々大変な思いをしているケースもあると思う。 特に今回の Shell Shock は一度のパッチですべてを解決できなかったこともあり、相当大変だったと思う。JPCERT の脆弱性情報も対応するパッチ情報で「以下」と「未満」を間違えていたりと、どれが正しいのかよく分からない状況だった。 そんな場合に問題になるのが、サポート対象外となってもリプレイスできない、リプレイスするためのリソースを割り当てられない CentOS 4.x の対応。 Miracle Linux の SRPM を持ってきてコンパイルするという話もあるが、個人的に色々追ってパッチを適用していたりすると Miracle Linux よりも速かったので、個人的にパッチを追って RPM を作って対応していた。 Shell Shock 関連の CV
4 月 30 日の Facebook f8 2014 で導入されたパーミッションの Facebook レビューだが、なんだかんだとあまり情報が出てこない。それぞれのノウハウということで門外不出になっているのか、単にレビューに通らないのか…… そんな中、公私ともにある程度レビューが通るようになってきたので、公開できる範囲でアウトラインを紹介してみたいと思う。 いくつかのブログで「一番通りづらいのは publish_actions」と書かれているのをみたが、manager_notification や read_mailbox, read_stream のような、f8 2014 以降は Facebook アプリが存在しないプラットフォームに Facebook クライアントを作成するためだけに提供されている特殊なパーミッションを除き、一番通りづらいのは user_* だと思う。 実際にやってみる
前回書いた、今年 11 月 5 日以降「いいね」必須キャンペーンが Facebook Platform Policies 違反となる件は、週が明けてメディアが記事にしたりして大きく取り上げられることとなった。この結果、「いいね」必須キャンペーンを売りにしている業界では色々と動きが出ていたりするが、今回の件は「『いいね』必須の枠組みが規約違反」だけではないことに目を向けられていない流れがあるように感じている。 例えば、アライドアーキテクツの IR では、 このたびFacebook社より発表されたFacebookのプラットフォームポリシーの改訂において、ユーザーに何らかのインセンティブ(報酬)を提供した上での「ソーシャルプラグイン(※企業のサイトなどにFacebookの「いいね！」ボタン等を設置できるようにFacebook社が提供している機能)の利用」や「Facebookページへの『いいね！』
(8/13、続報を追記。) 日本時間 5 月 1 日の Facebook f8 2014 は相当インパクトが大きかったが、ここで発表された Graph API v2.0 に続き、8 月 8 日に v2.1 が発表された。正直、v2.1 が来るのは来年くらいだと思っていた…… 変更点の概要はこちら。機能面で大きな変更といえば、FQL が使えなくなったことだろうか。個人的には FQL でフリガナを取ったりしていたが、これは Graph API では未だに取得できないのでここが困ったところではある。 なお、FQL で友達総数を取っていたパターンもあるかと思うが、/me/friends で友達総数が返るようになったので、これを使えば同じように取得可能となる。 今回の v2.1 にともなう変更点で一番大きいのは、なんといっても Platform Policies の変更だろう。 変更点は 2 箇所で
かなり以前に Postfix を DKIM 対応にするネタを書いたが、その後、dkim-milter は OpenDKIM にリプレイスされた。遅ればせながら今回、OpenDKIM に乗り換えてみた。dkim-milter のままでも問題はないが、1 MTA で複数のドメインに対して複数の DKIM-Signature を付けられるようになったので、ぜひ乗り換えるべきだと思う。 Gentoo Linux の場合は、何よりもまず emerge する。 ACCEPT_KEYWORDS="~amd64" emerge opendkim 次に、dkim-milter から移行する場合は、鍵ペアを /etc/opendkim 以下に移動する。新しく鍵ペアを作る場合は、OpenDKIM についてくるシェルスクリプトで作成する。 opendkim-genkey -s セレクタ名 -d ドメイン名 ただし
(5/1 19:35) チラ裏風味だったのでちょっと構成を変えてみた。 (5/2 9:40)友達一覧→そのアプリを使っている友達一覧 f8 で発表されたFacebook ログインの仕様変更は匿名ログインにフォーカスされているような感じもあるが、主な変更点は以下となる。 これまでは Facebook ログイン時に Facebook アプリ側が取得する情報が一覧表示されるだけだったが、ここでどの情報を提供するかをエンドユーザが選択できるようになる。Facebook への投稿権限の確認画面のデザインも変更。 公開プロフィール、メールアドレス、そのアプリを使っている友達一覧を超えた個人情報の取得やシェアなどの投稿権限をログインで取得する場合は、Facebookのレビューが必要になる。 Facebook に登録された個人情報を Facebook アプリに引き渡さない匿名ログインの実装。 Graph
Rails3 に限らずセッション情報の格納先に memcached を使うことは多いと思うが、Passenger + Rails3 でセッションストアに memcached を使うとセッションが切れたり他のユーザのセッションにすりかわったりする。実はPassenger のドキュメントにがっつり書かれている。 Because worker processes are created by forking from an ApplicationSpawner server, it will share all file descriptors that are opened by the ApplicationSpawner server. (This is part of the semantics of the Unix fork() system call. You might want
(16:23)この問題はバグということで、既に解消しているらしい。 以前、Twitterで古いエンドポイントが削除された件を書いたが、Facebookでも今日 2/6 で古いログインダイアログのエンドポイントが削除されたらしい。これにより、認証ダイアログにリダイレクトさせても以下のようにエラー表示になる。 バグチケットが切られている(Bugs: Enabling Facebook Breaking Changes Feb 2013 Does Not Work)のでバグかも知れないが、リダイレクト先を変更するだけで対応できる。 Pinterest や Wantedly などもこれに巻き込まれているらしいこの件の対応だが、これまでは認証時に https://graph.facebook.com/dialog/oauth などにリダイレクトさせていた場合、graph ではなく www.faceb
「B.E.A.M.」という名前で Software Design の裏表紙にも広告を出していた spam 配信システムからのメールを叩き落す件について過去何度か記事にしていたが、APNIC 経由でいくつか新しい IP アドレス帯を取得したらしく、Postfix のメールにログが残っていた。 「0day.jp (ゼロデイ.JP): 日本語携帯スパムメールの調査(Part 3)： あるワンクリック詐欺の迷惑メールのソースは『MATCHYOU.BIZ /180.222.53.5』と&『G-GREE.COM/203.142.201.70』のアダルト詐欺サイト」によると SPF を設定しているらしく、いくつかのメールサーバでは通してしまうこともあるらしいが、我が家のメールサーバはまだ抜かれていない。仮に抜かれても某エムゲームジャパンにのみ登録した送信先アドレスは reject 済みではあるのだが…
次のページ
このページを最初にブックマークしてみませんか？
『work::meihong』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
