feedlyで保存した記事を取得する
feedly APIを使ってみるにて、APIの使い方を書きました。
もともとfeedlyで保存した記事(Saved for Later)をAPI経由で取得したいなという思いからやってみたのですが、結果的にこの機能はサポートされていないことが判明しました。
なので別の方法で保存した記事を取得するべく、Web側の要素から情報を引っ張るようにしました。(APIは使わないので、前の記事に書いてあることは不要です!)
できたもの
使い方
feedlyのSaved for Laterにアクセス
一番下にスクロールダウンし、"End of feed"を表示する
ブラウザの開発ツールを開き、コンソールを表示する。
GitHubにあげている"getSavedFeedlyArticles.js"をコピーして、コンソールに貼り付けEnterで実行。
最初の画像のように、保存した記事一覧とJSON文字列が現れます!
最後に
APIが使えなかったのでスマートではないですが、もともとの目的であるfeedlyで保存した記事を取得することができました!
Webコンソールはこのように使い勝手がいいので、今後もいろいろ試してみたいと思います!
ちなみに、実際に私が保存した記事を全部乗っけてみました!今までfeedlyで保存した記事を並べてみる
『MTL勉強会「UX Sketch」vol.7』に行ってきた
Media Technology Labにて開催されたUX系の勉強会に行ってきました。
今回のテーマとして「UXと事業計画」が掲げられており、
についてのお話が聞けました。
以下内容と感想です。
AWA
目指すべきところとそのPoint
- ワクワクするリコメンドの精度
- おしゃれなデザインと初心者でも感覚的に使いやすいUI/UX
- ストレスフリーのクイックな反応と音質
1. リコメンドの精度
- 自分向けじゃないと主されたら終了
- 特定の感性のみで楽曲を表示しない
- 音楽は人それぞれ独特の世界観を作りやすい
2. おしゃれさと使いやすさ
- 現実世界にある動き(ギャップレス)
- 伸びる表現はしない
- 前後関係を表現
- 位置関係の統一
- 動きとスワイプの速度を連動
- 要素を遷移に合わせてアニメーションさせる
- プラットフォームの標準に準ずる
- Apple Music / Google Play Music の挙動に合わせる
- サービス内の要素に統一詠を落たせる
- 同じ要素の形は同じ
- 色も統一
- ヘッダーもページの役割にあわせて色・フォントを使い分ける
3. ストレスフリー
ユーザーの行動を阻害しない
与える体験
- 音楽を聞く、に直結したアクションが最上級
- 人それぞれの世界観があり、フラットに
まとめ
- 押し引きをシンプルに、メリハリつける
- サービス側のエゴの排除
- 表面のダサさはコンテンツの印象にも影響する
質疑応答
主観の排除は?
- アメリカ、イギリスのAppStoreのおすすめアプリを片っ端から使ってみる。
ビジネスプランとして、ターゲットはどこ?デザインの焦点はそこにあてた?
- メインターゲットは全員(世界中の人)であり、メインターゲットはいない。
- だからこそ、今日話し合ったような内容を通して、誰が使ってもわかりやすいようにするというのが結論。
感想
実際に使ったことのないアプリだったのですが、なんとなく「かっこいい!いけている!」プロダクトだという認識はありました。その感覚がどのようにして創り出されていたのか、ちょっとわかったような気がします。
自分がダサいと思うものはダサい、というわかりやすい軸を指標にしつつ、コンセプトとしては非常に現実的に実世界から漏れないように注意が払ってあるものでした。
事業計画的な観点で考えると、音楽と言うもののイメージが人それぞれで異なることに対し、どうそれを許容するデザインをつくるか。というものがキーであったのでしょう。
ちなみに、内容についてはこちらを参照するとより知れるかもしれません。
BrainWars/BrainDots
デザインとは
- 装飾でない
- コンセプトを磨くこと
編集業界にいた時、先輩に言われたこと
- 徹底的なリサーチ
- 企画は3行
- 企画は100本ノック
ITでは?
- 類似サービスの研究
- 人目でわかるデザイン
- デザイン案は100本ノック
方針
- シンプルなフラットデザイン
- 直感的に老若男女が楽しめる
- 非言語化で翻訳コストカット
まとめ
- コンセプトが強いほどいいUX/UIが導かれる
質疑応答
-ローカライズはどこまで? - 殆ど無い。絵で表現してしまう。ピクトグラムとかそういう考え方。
感想
世界に脳トレアプリを打ち出したいけど、翻訳とかにリソースを避けないので非言語化を徹底した。というこここそ、事業計画とUXの交差点であったのだろうと思いました。
具体的な方策は一切示されていなかったですが(終始両アプリの宣伝でした)、言語の壁を取り払うことで世界をマーケットに出来るんだという実例を目の当たりにできました。
世界にユーザーをもつ日本製のアプリを知らなかったので、嬉しく思いました。
くらしの基本
ユーザーの気持ちがわからない問題
スタッフかつヘビーユーザーという存在
- 異質な存在
- 仮設「ヘビーユーザになればユーザーファーストな開発ができる」
カッコイイデザインにしない理由
- 100年価値のあるアーカイブにしたい
- 最新のウェブデザインはすぐ廃れる
- カコイイデザインは、親しみづらい印象を受けう人がいる
気をつけていること
- 自分が素敵と思った瞬間を伝える
- ユーザーに楽しさを疑似体験してもらう
まとめ
- ユーザーファーストを追求することで、デザインも経営も確度の高い判断ができる
- ユーザーの楽しみを増やすために、まず自分たちが楽しむこと
質疑応答
- デザイナーをしながらエンジニアリングの知識をどうやって得たか
- 実務を通してやってみた。コードレビューの文化がその土壌をつくってくれている。
- クックパッド本体とのデザインやターゲットが違うと思う。どういう相乗効果が?
- ユーザー向けの効果:クックパッドの物足りなさを埋める。
- 社内向けの効果:社内でコンテンツをつくる文化により、会社の「できる」意識をもたせる。
感想
お話の中で、「〜〜〜問題」というタイトルを掲げており、そのやわらかさに一目惚れしました。いつか人前に立つ際は真似したいと思います。
どうやったらユーザーのことが理解できるか、という悩みに対し出した仮定「ヘビーユーザになってみる」に至るは非常に納得ができ、一方で当たり前のように思えました。
しかし、この方のすごいのはそれを「体現」したことだと思います。3ヶ月間毎日クックパッドに投稿をし、料理の楽しみを知り、ユーザーの気持ちを得て行ったそうで、その覚悟は本当に恐れ入るばかりです。。。
どうやったらより良くなるか、を今後考えるとき、その悩みを切り開いてくれそうなアイディアを得たような気がします。
Yahoo! Messengerのログイン状況を得るAPI的なものの使い方
チームの配属が10月にあり、それ以降業務中の連絡手段の一部でYahoo! Messengerを使っています。
といってもご存知のとおり(?)Yahoo! JapanとしてのYahoo! Messengerは終了しており、アメリカのYahoo!のサービスを使っています。
今回はこのYahoo! Messengerのログイン状況を簡単に知る方法を書いてゆきます。
今回の内容
方法
アクセスポイントはこちら。
http://opi.yahoo.com/online
パラメータとして次の3つがあります。
u | m | t |
---|---|---|
対象のID | gもしくはa | 数字 |
パラメータu
ログイン状況を知りたい、ユーザーIDを指定します。
パラメータm
ここでAPIの返却値を、画像でもらうか、テキストでもらうかを指定します。
gの時はhtmlが返却され、その中にはimgタグが入ってたりします。
aのときは、テキストで結果が返ってきます。
パラメータt
このパラメータは種類を指定します。
m=gの際はtが受け付ける範囲は0〜24で、
m=aの際は0〜1です。
実際にやってみる
ブラウザからやってみる
http://opi.yahoo.com/online?u=testid&m=g&t=0
で試しにブラウザからアクセスすると、(たぶんこんなIDはないから)
という画像が返ってきます。(具体的なHTMLの中身は各自でご確認を。)
実際ユーザーがログインしているときは、
と画像が変わります。
実際のログイン判定
上記のような画像が返ってくる指定の際、実はユーザーがオンラインかオフラインの判断がやりづらいです。というのも、返ってくる文字列は同じなんです。
ということで、おとなしくm=aを指定し、文字列で返却してもらいましょう。
http://opi.yahoo.com/online?u=testid&m=a&t=1
ブラウザからアクセスすると、
00
が返ってきます。(実際はpreタグの中にある。)
これがログイン時は
01
となります。
ということで、これをサクッとphpで書くと、次のようになります。
Yahoo! Messengerのログイン状況をチェックする
簡単ですね!
注意点
最後に注意点です。
冒頭にもお伝えしましたが、この方法は非推奨なものかもしれません。理由としては次のとおりです。
- 公式ドキュメントを探してみたのですが、記載が見つからない
- いつ使えなくなるか不明である(ドキュメントがないので)
- 使用済みアカウントの探索に使えてしまう
とくに、3つ目のおかげでこのやり方のグレー感がものすごくあります(個人的な感想ですが。)
なので使う際は、このあたりの理解をもって、試してみるようにしましょう!
参考にしたサイト:http://shareourideas.com/2010/03/25/yahoo-messenger-status-api/
「プロダクトオーナー祭り2015」に行ってきた
プロダクトオーナ祭り2015に行ってきました!
ここでいうプロダクトオーナとは、アジャイル開発手法でいうところのプロダクトオーナがそのままドンピシャのものです。
ですがアジャイルそのものに囚われるのではなく、良いプロダクトを創るるために、ディレクターやマネージャー(あともちろんプロダクトオーナも!)はどんなスキル・マインドが必要か、についての話しがたくさんありました。
会場に来られていた方も、プロダクトを何かしらコントロールする立場にいる方が多くいられるようで、おそらくこの辺りのズブの素人は私だけだったように思っています。
初めて聞く言葉たち
プロダクト作成のための方法論の話では、今まで私が聞いたことのない言葉ばっかりで戸惑いました(というか、場違い感を強く覚えましたw)。
- ポジジョニングマップ
- バループロポジションキャンバス
- リーンダイアグラム
- 事前期待設計
- ゴールデンマンダラチャート
- ビジネスモデルキャンバス
新卒研修でスクラムを1ヶ月やってみた程度の私にはなんのことやらサッパリ...
ただこのようなモノたちがあると分かったので、今後これらの勉強をしていくステージに行かねばと思いました。
要求開発方法論
講演の中で印象深かった「要求開発」という言葉。意図としては、要求はその辺に散らばっているものではなく、作り上げていく必要がある!というものでした。
ユーザーの要求は全て「正しい」ものであるが、ビジネスや経営に繋がる「真の正しい要求」は一部でしか無い。
ユーザビリティーテストをやった時のことを思い出したのですが、その際、テスト結果から考えられる改善案の良し悪しを決めるのにかなり戸惑いました。
このようなときに、いかに "ビジネスや経営につながっているか" を軸にするのは正義なように思います。
100円プロトタイプ
今回のイベントにはワークショップも多くありました。その中で「100円プロトタイプ」というUX/UIまわりのワークショップに参加しました。
世の中にプロトタイピングツールは沢山あれど、紙ベースのプロトタイプ作成は、非常に楽に・早く・触らせながら意見を求めることができると人気です。今回は、付箋を使って画面遷移を表そうというものでした。
実際に渡しが作ったものがこれです。iOS版のヤフー天気アプリの模写(?)です。
色の違う付箋を使ってユーザーのアクション状態を見える化し、またレイヤーを明確に表すことができます。
下記のようなメリットがあると感じました。
- 見た目で状態がわかりやすい
- UX/UIの検討の際に色々いじりながら理解を深めていくことができる
- 汎用性の高いパーツを洗い出せ、実装者もそれを意識してコードに落とし込める
実際に作っている時もたのしく、意外と手早く出来たのでおすすめです!
おわりに
私にとっては少し背伸びした感満載のイベントでした。
ですが、会場で聞いた色々な手法や考え方が当たり前になっている自分を目指します!加えて、今できることは何かを考え、「見える化」もしていきたいと思います!
素敵な場を提供してくださった皆さん、ありがとうございました!!
イベントの関連資料
- Twitter #postudy
- POStudy 〜プロダクトオーナーシップ勉強会〜とは
- 次世代のディストリビューテッド・ワーキングとその中でプロダクトオーナーとして活躍する事とは何か
- POとPOじゃない人の勉強会 出張版 / po-matsuri-2015-b8
- ユーザーの時間軸を含めたプロダクトデザイン
- 外部環境分析のためのコンテクストマップ
- メトリクスによる「見える化」のススメ:No 見える化、No 改善
きっと他にもあるはず...(見つけたら更新します)
「DMM.Study Night フロントエンド勉強会」に行ってきた
「DMM.Study Night フロントエンド勉強会」に行ってきました!
就職で地方から上京してきた私としては、東京での勉強会というのは憧れでした。
インターネットやWebが発展し時間や場所への制限が少なくなってきたとはいえ、こういう機会というのは地方では難しいのが現状だと思っています。このあたりの問題はどうにかなってほしいと思ってますし、どうにかしていかなければと思います。
それはさておき、今回はDMM.comさんが主催する勉強会「DMM.Study Night」。恵比寿ガーデンプレイスタワーにあるDMM.comのオフィスで行われました。
既にこの勉強会を開催しているそうですが、フロントエンドに全面に押し出した勉強会は初めてとのことでした。
4人公演されましたので、それぞれ書き下したメモを載せていきます。
DMMで新規サービス作ったらフロントエンドエンジニアの重要性が浮き彫りになった話
DMMにおいて、フロントエンドエンジニアという役割が明確になったのは1・2年前とのことであり、フロントエンドエンジニアは何をコントロールすべきかを整理してお話してくださいました。
以下内容。
全体
JSよりもCSSのルールぎめが重要。
下記を使っている。
css
- Sassを採用
- 設計はFLOCSSを採用
- 覚えづらいルールは極力排除
- 書式はLinterで制御
- 英名規則はBEM
- スタイルガイドの導入
Sass
ガッツリやると複雑なので、簡易的に以下に限定した
- 変数
- ネスト
- 親セレクタの景初
- コメント
下記は不採用 - 関数 - mixin/extend - などなど...
FLOCSSという考え方
- Foundation
- Layout
- Object
- Component
- Project
- Utillity
Object以下は、作業者のみが触る範囲。リードエンジニアは全体を触る。
- Component: パーツは全て個々
- Utillity: 設計者が用意・作用者は使うだけ
- Project: パーツとは無関係な独立ページ用
ComponentとUtillityで基本的に全て賄う→スピードの向上
スタイルガイド
- Gulpを使って.sccsファイルから直接スタイルガイドを自動生成
設計者が管理するために必要なもの
- CSS import
- Webpac Entorypoint
- などなど
フロントエンドエンジニアがいると
- メンテしやすい
- パフォーマンス高い
- バグが出にくい
Developertools表示しておけばネトゲやってても仕事してる感でる
タイトルからネタ的な話をするかとおもいきや、すごくためになる話でした笑。ChromeのDevelopertoolsを使うことはあっても、単純なブレークポイントくらいしか使ってなかったので知れて良かったです。
以下内容。
条件付きブレークポイント
通信のブレークポイント
- XHR Brakepoints
- call stack で一覧見れる
- 任意の通信を引っ掛けられる
- ポート番号も指定可能
- typeがXHRのリソースは右クリックからリプレイできる
計測ツール
- Networkパネル:コンテンツのダウンロード時間
- Timelineパネル:ダウンロードやレンダリングの時系列
- Profilesパネル:CPUの利用料など
通信周りから調べてみる
次にAuditsパネルを見る
- ネットワーク/ページパフォーマンスの2方向から検査してくれる
- JSまとめろ
- gzipで送れ
Chromeオンリーブラウザゲームがマルチブラウザ対応するまで
マルチブラウザ対応が大変とは聞くけど、その内容を初めて聞くことができました。実際には、はじめからChrome向けに書かれたものを後からマルチブラウザ対応にするのは大変だってのが今回の根本なんですが。
以下内容。(気になった言葉だけ抽出)
- Autoprefixer: CSSのマルチブラウザ対応に使える。ベンダー接頭語を自動付与する。
- Can I Use: 各ブラウザのCSS対応状況を確認できる
- pleeease: Gulpのプラグインで、utoplefixに圧縮、メディアクエリーをまとめてくれる
DMMの闇に触れた話
DMMには金沢にも拠点を持っており、そちらで活躍されているフロントエンドエンジニアの方のお話でした。勉強会後の懇親会でもお話したのですが、非常に楽しい面白い方でした。あちらの方で働き口を見つけたいときには、DMMさんにお話を聞きに行こうと思いました。
以下内容。(気になった言葉だけ抽出)
feedly APIを使ってみる
RSSリーダーとして使っているサービス、feedlyのAPIを使おうとしたところ意外と引っかかったので、使い方を書き残しておきます。
今日(2015/11/19)時点のAPI 、V3で確認をしています。
アクセストークンを取得する
Web APIは様々にありますが、企業が公開しているAPIを利用する際は往々にしてアクセストークンというものが必要になります。
各ユーザーに紐付けられた文字列であり、公開元がアクセスの管理・解析をする目的として必要であるという理解を私はしています。
手順は簡単です。
認証
https://feedly.com/v3/auth/devにアクセスし、いずれかの方法(すでに自身が使っている認証方法)を選択して認証を行います。
メッセージの確認
認証後の画面に記載されている連絡先をチェックします。
リンクへのアクセス
メッセージがfeedlyから送られてきているので、記述されているURLに飛ぶと、
アクセストークンが表示されています。
表示欄は小さいですが、横にスクロールされて結構な文字数となります。(今回試したところ242文字ありました。)
使ってみる
curlで問い合わせ結果をGETで取得してみましょう。
問い合わせ形式はこんな感じです。
$ curl -s -H 'Authorization: OAuth [トークン]' [アクセスURL]
取得したトークンを今仮に "MyToken" という文字列、
アクセスURLをhttps://cloud.feedly.com/v3/categoriesとすると、
$ curl -s -H 'Authorization: OAuth MyToken' https://cloud.feedly.com/v3/categories
となります。
アクセスURLは欲しい情報により異なるので、公式ドキュメントを見てみてくささい。
結果はJSONで帰ってくるみたいなので、あとはこれをパースしてうまく活用すればOKです。
curlのオプションである -s と-H はそれぞれ、
-s : 進捗状況やエラーを表示しない
-H : HEADER HTTPヘッダにHEADERを追加もしくは変更する
という意味らしいです。参考
これでとりあえずアクセスが出来るようになりました!
AndroidのMediaRecorderで録画・録音する際はクラス関数の順番に注意を!
Androidで動画の保存(録画)や音声の保存(録音を)する際、MediaRecorderを使用します。
さくっと使えて便利なクラスなのですが、クラス関数の利用順番がしっかりと決められているので、使用例を載せておきます。
一瞬ハマったので。
AndroidのMediaRecorderを使った録画・録音の設定
順番については公式ドキュメントを読めば一発なんですが、録音のあり/なしをif文分岐で2度書くのがめんどくさく感じて、つい何も考えなしにまとめてしまったりするんですよね。
反省。
MaterializeのCharacter Counterの重複解消方法
前回紹介したデザインフレームワークMaterializeの便利機能に、文字数カウントがあります。
サンプルはこんな感じです。
しかし、ドキュメントにしたがってそのまま書くと、下図のようにカウンターが重複してしまいます!
修正するのは簡単です!
デザインフレームワークMaterializeのcharacter counterの重複解消
.removeで生成されたelementを消してあげましょう!
たったこれだけで、スッキリ解決です!!
Webでマテリアルデザインを簡単につくれるMaterializeを使ってみた
Googleが言い出したマテリアルデザイン。
Android 5.0:LolipoのCMを最近目にしたりしますが、Lolipopが広まってくるにつれ、世の中にのなんとなく認知されてきたかなと思ってます。
このマテリアルデザインをWeb上で表現する際に強力にサポートしてくれるMaterializeというものがあり、最近ちょっとした経緯でこれを使いました。
サンプルとhowtoをまとめたので御覧ください。
github.ioにあげてます。 github.com
公式のドキュメントはかなりしっかりしてていい感じです。が、
- 何ができるか
- どうしたらできるか
という情報の所在と知らされる順番がいまいちにように感じてしまい、だったらせっかくだしと思いまとめた次第です。
間違い等なにかあれば教えて下さい!
角度や方向に対する評価関数
角度や方向に対する評価関数について考えました。
使用例
サッカーを例に考えます。
今ボールを持ったプレイヤーに対して、近くにいる仲間A,Bがいるとき、どちらにボールをパスしたらいいでしょうか?
ゴール近くにいる仲間Aにパスする!と皆さん考えるでしょうが、例えば仲間Aと仲間Bに能力差があり、
能力差:仲間A<仲間B
という場合では答えは難しいです。また、仲間までの距離も考慮に入れたくなります。
いろいろな要素が考えられますが、今回はこのうち「角度」に注目して角度のみに関する評価関数を考えてみました。
普通の考え方
プレイヤーを中心にゴール方向を0度とし、仲間が360度中のどこにいるかを元に考えます。
単純に考えると、0度に近いほど良い評価値を与えればよく、
となり、負数を無視しゼロと置換えて次のようになります。
提案
考え方
先の例で充分な例もあるでしょうが、
- もっとシビアな評価
- もっとメリハリのある評価
を求めるケースもあるでしょう。そこでシグモイド関数を使いこれを解決します。
評価関数
は仲間の角度、
は評価値半減点、
はシグモイド関数のゲインを示します。
評価値半減点とゲインはパラメータ(設定値)であり、評価値半減点に評価値0.5を取る角度の値を、ゲインにはとりあえず5~10の値入れておけばいいです(後述)。
関数をプロットすると、次のようになります。
図の通り、パラメータ評価値半減点により高い評価を与える角度の範囲設定を、ゲインにより評価値のメリハリの変化をつけることが出来ました。ゲインについては実際に試してチューニングすることをオススメします。
注意点
この手法は評価値が極めて低い値を取ることが理論上仕方ありません。プログラムに起こす際は、評価値半減点を閾値として、今回の関数に掛けるかどうかを判断するとよいでしょう。
この点だけを気をつけて頂いて、今回の提案手法をぜひ利用してみてください。