ネクタイ
2015年、 Live Typingはオーストラリアの友人向けのプロジェクトの開発を開始しました。 このプロジェクトは、従業員の生産性管理のニッチで機能しました。 作業の年の間に、私たちは、クライアントが開発段階ですでに行った新しい変更ごとに、概念を変更し、骨の折れる作業のいくつかの段階を経ました。 プロジェクトの最終段階では、Googleドライブ、Evernote、Togglサービスとの深い統合が行われました。 実際、プロジェクトはこれらのサービスの機能の一部をコピーし、新しいメカニズムを作成しました。
Googleドライブではすべてがスムーズに進みました。 Evernoteを使用すると、いいえ。 何が間違っていたのか、どうやってそれを克服したのかについては、カットの下で読んでください。
タスクは簡単でした：
- クライアントは、モバイルアプリケーションを使用してEvernoteにログインします。
- アプリケーション内にメモを含むノートブックを作成します。
- このノートブックを共有するユーザーのリストを検索します。
- 「共有」ボタンを押すと、ユーザーはこのノートブックの使用を招待するメールを受け取ります。
- ユーザーが招待を確認すると、クライアントのメモ帳がネイティブのEvernoteアプリケーションのインターフェースに表示されます。
問題はステップ4で発生しました。Evernoteのドキュメントが完全に見えたため、設計段階で検出することが困難であったことを予約します。 Evernote APIに必要なリクエストをすべて実装した後、必要な共有方法が機能しませんでした。 StackOverflowでこれについて尋ねると、Evernoteの担当者の1人が次のように答えました。
- メソッドとドキュメントがありますが、使用することはできませんが、Evernoteの担当者のみが使用できます。
- Evernote公式ドキュメントは関連性がなく、SDKの更新後にアクセスする必要がある新しいshareNotebookメソッドがあるため、このメソッドはまったく機能しません。 つまり、SDKはパブリックドメインに存在しますが、無関係です。
すべてのモバイルおよびWeb Evernote SDKは、 Thriftフレームワークを使用します。 ほとんどすべての言語でコードを解釈できます。 SDKが更新されていない場合、EvernoteはGitHubのThriftコードをほとんどすぐに更新することに気付きました。 もちろん、新しいThriftコードにはshareNotebookメソッドがありました。 私たちは現在のコードを自分で更新することを決定し、 プル要求さえしました。 残念ながら、この方法でもメソッドは半分しか機能しませんでした。ノートブックを共有したユーザーにはノートブックが共有されていることがわかりますが、共有されたユーザーには表示されません。
これを試した後、私たちは開発を一時停止し、数か月後にEvernoteのような大企業がモバイルSDKを更新できることを期待して、数か月待つことにしました。 残念ながら、約1億2,000万ドルの年間収入を持つ注目すべきアプリケーションのリーダーの1つであるEvernoteは、2か月間、上記のメソッドを実装したAPIの新しいバージョンの公式SDKを作成しませんでした。 なぜこれが起こったのか、推測することしかできません。
APIの変更方法
これが私たちの小さな勝利の物語の始まりです。 次の2つのオプションがありました。
- 後退するには、Evernoteのようなマシンを移動できないため、何もできないことをクライアントに伝えます。
- すべてのSDKの更新とAPIの更新を実行して取得します。
私たちは引き下げず、どうしてもEvernoteから解決策を得ることにしました。 次の3つの方法がありました。
- LinkedInを通じて意思決定を行う人々を見つけましょう。 事実、これはある程度までEvernoteの評判によるものであり、マネージャーが問題を迅速に解決しようとすることは間違いないでしょう。
- クライアントを定期的に接続して、Evernoteサポートに直接連絡してください。
- すべてを自分の手に取り、EvernoteでSDKのリリースに携わっているエンジニアを見つけ、新しいリリースの計画を見つけ、おそらく彼に助けを提供してください。
LinkedInではほとんど結果が得られませんでした。 Evernoteのサポートに連絡しても、あまり多くのことを達成できませんでした。 彼らは明らかな間違いについて私たちのコメントを忠実に受け入れ、私たちの立場に耳を傾け、私たちに情報を提供し続けると言って、居心地の良いオフィスの壁のどこかに私たちの申し出を埋めました。
もちろん、そのような態度の後のクライアントは激怒し、すでにあきらめ始めていました。 しかし、私たちはこのプロジェクトに非常に根付いており、この状態の最終段階でそれを残したくありませんでした。
私たちに連絡してくれたEvernoteからオープンエンジニアのデータを見つけて、私たちが彼を助ける方法を見つけることです。 彼に関する公開情報から、私は彼のTwitterだけを見つけました。 そして、5年ぶりに、私は彼のチャットの機能を利用しました！ 短い通信の後、彼は現在バックエンドにいたその遺産からの彼の痛みを私と共有しました。
上で述べたように、アプリケーション開発者として、私たちはこの機能を利用できませんでした。 その理由は、サードパーティの開発者のキーと、Evernoteの公式アプリケーション（Webクライアント、モバイルアプリケーションなど）で使用されるキーが異なる方法で作成されるためです。 これはセキュリティの観点から明らかであり、もちろん、Evernoteはアプリケーションに同じマスターキーを提供できませんでした。 また、これらのマスターキーは、SharedNotebookクライアントと、このノートブックが共有されたユーザーのLinkedNotebook間のリンクである、いわゆるsharedKeyを生成できました。 主な問題は、オープンなsharedKeyにより、攻撃者が他の人のノートブックにアクセスできるようになる可能性があり、この機能は優先事項ではなかったと思います。
私たちのコミュニケーションの結果は、この方法が公開ドキュメントにあるという公式の応答でしたが、Evernoteの従業員のみがそれを使用でき、その理由が明らかになりました。 しかし、サポートエンジニアとは異なり、Amar（開発者の名前）は、この機能を実装するためのタイムラインを提供し、現在それが優先事項ではない理由を説明し、APIのこの部分のリリースをうまく調整できました。
1週間後、機能が実稼働環境に展開され、アプリケーションで使用できることを示す別の手紙を受け取りました。 それは勝利でした！
おわりに
このプロジェクトに取り組む際に、チームメンバーはさまざまな理由で数回あきらめました。 ただし、プロジェクトを常に信じており、クライアントを成功に近づけることができることが重要です。 この小さな物語は、クライアントを助けたいという願望、プロジェクトへの信頼、開発者間の個人的なコミュニケーションが成功する結果につながることを示しました。