焼肉リア充

終わりなき思春期の変わらない日常

GEEOKI に Yoすると @geeokibotがツイートするやつ

Yo

Yo Channel - IFTTTでのTwitterの連携が動かないので、作りました

たぶん YOのAPI keyとかTwitterのconsumer keyとかそういうの入れれば他でも使えると思います。使えなかったらごめんなさい。

でもたまにツイートしなくなります。あと連打してもそんなに反応しません。それぐらい雑なものです。

YoApp/heyっていうRubyのライブラリがあるのでラクです。

APIを使うためのアカウントを1つ作ります。今回はGEEOKIにしました。

コールバックを指定して、そのURLに ?username=みたいな感じでユーザの名前が取れるので、Rubyだとparams['username']とか指定してやるとよいです。

そのうち、http://text.geeoki.com が更新されたらYoするとかそういうのやりたいですね。

以上です。

Titanium Mobile から Devise + omniauthのサーバ側でログインする。

まったくこれが良い方法だと思わないので、教えてほしい。

  • Titanium Mobile側からサーバ側のRailsのDevise+omniauthのログイン/新規登録をする。

やったこと

でも良くないってことを教えてもらったのでなんか方法ないかなぁと思ってる。(しっかり内容見てないからあとで見る)→OAuthの認証にWebViewを使うのはやめよう - Shogo's Blog

俺用メモ:DeviseにJSONでログイン、新規登録する。

文章書くのがとてもだるいので、読みにくいものだったらごめんなさい。雑なメモ過ぎるのでQiitaにもかけない…

Devise with token based authentication for API

abhidsm/devise-token-api

ここを見てからやっていると出来たので見ると大丈夫です。authenticaton_tokenのカラムを作って、そこで認証の確認をすれば良いのでは?みたいな話だと理解している。

Rails 4.0だとCSRFトークンでエラーになる - Qiita

protect_from_forgery with: :exceptionprotect_from_forgery with: :null_sessionにする。

でやってみてる。

【Devise3.2 + Rails4】authentication_tokenでiOSからユーザー認証 - source

Completed 401 Unauthorized in 87ms が出ている問題

  • どこでそうなってるんだろうか。
  • validatesがひっかかっていたのが問題だった。

omniauth-twitterでログインする

フツーにアクセスするだけでおっけ。 callbackにしていしているコントローラの部分でjsonを返すようにしておけば何も問題ないと思います。

ほんとに使える「ユーザビリティ」-より良いデザインへのシンプルなアプローチ メモ2

読む目的

  • 自分が作っているサービスに関しての「使い勝手」の良さについて考えさせられることが多いので、「使い勝手が良い」というのはどういうことか知りたい。

  • Tipsの形ではなく、考え方の部分で得られるものがほしい。

メモ

第一部 使いやすさ

機能性

  • 機能性を高める3つのポイント
    • ボタンやリンクは、クリックしたら必ず機能すること
    • ナビゲーションはきちんと反応すること
    • 処理速度が許容できるレベルであること
  • 機能的なフォームを作る4つのポイント

    • 入手したい情報を、ユーザが提供できるようにしておく。
    • 入力形式が柔軟でないと、フォームが失敗する見込みが跳ね上がる。
    • 相互依存型のフォームやログインが必要になると、失敗する見込みが高まる。
    • 誤解を招く操作説明は、ユーザをいらだたせる
  • フォームのテストは、とにかく与えられた操作説明にのみ従うようにすること

  • 反応速度を0.5秒縮めるとコンバージョンもあがるよ

  • そもそもプロジェクトの目的は?

  • その目的を達成を確認するためには、どんなコンバージョンが必要?

反応性

  • ボタンがクリックされると反応するように見えるか
  • ファイルの保存は目でわかるか。
  • マウスオーバーの反応があるか?
  • レスポンシブデザインにより、端末ごとに適した見せ方を実施できているか?

    • できてません…
  • 受け取るべきフィードバックは適切なタイミングでいっているか?

  • 時間のかかる処理は進行状況を把握できるようになっている?
  • その”反応”はだれでも理解できるものであるか?

感想

  • Webの速度周りのことは全然放置してやっているのでとても良くない。
  • フィードバック、「つくった自身がちょっと遅いなと思ったらユーザはもっと遅く感じる」って書いてあって、刺さる…
  • デザイン≠綺麗なサイトではなくて、いかに考えさせないか。言葉ではわかっているけども、実践はまったくできていないなぁと感じる。
  • 目的の部分もいつも逃げている自分がいるので、しっかりそこは抑えていかないとダメだなぁと感じた。

よみましょう

ほんとに使える「ユーザビリティ」-より良いデザインへのシンプルなアプローチ メモ1

ほんとに使える「ユーザビリティ」 -より良いデザインへのシンプルなアプローチ

ほんとに使える「ユーザビリティ」 -より良いデザインへのシンプルなアプローチ

読む目的

  • 自分が作っているサービスに関しての「使い勝手」の良さについて考えさせられることが多いので、「使い勝手が良い」というのはどういうことか知りたい。

  • Tipsの形ではなく、考え方の部分で得られるものがほしい。

メモ

ユーザビリティとは

ユーザビリティ(Usability)とは、調べたり、改善したり、デザインしたりするあらゆる対象(ドアノブや、ウェブページのような”物”を伴うことすらないサービスまで含む)を「利用」しながら、特定のタスクを遂行したり、より幅広い目標を達成したりする各個人の能力を扱うもの (p.15)

本書の形

  • 使いやすさ(要求することをしてくれる)
  • 優雅さと明快さ(期待することをしてくれる)

ボゴ・バトベックの3段階式ユーザビリティプラン

  1. 誰もユーザビリティの話をしない
  2. 誰もがユーザビリティを語る
  3. 誰もユーザビリティの話をしない

良いパターン

ベストなかたちとしては、ユーザビリティ思考が当たり前のことになるため、誰もあえてそれを話題にしなくなること

あまりよろしくないパターン

ギャラの高いコンサルタントが去ったとたん、それまでの騒ぎが嘘のように、みんなユーザビリティのことなど忘れてしまうこと

感想

サービスデザインについて興味が出たのでいくつかサイトを漁っていた。

読み直しましょう

ウェブユーザビリティの法則―ストレスを感じさせないナビゲーション作法とは

ウェブユーザビリティの法則―ストレスを感じさせないナビゲーション作法とは

THIS IS SERVICE DESIGN THINKING.  Basics - Tools - Cases ー 領域横断的アプローチによるビジネスモデルの設計

THIS IS SERVICE DESIGN THINKING. Basics - Tools - Cases ー 領域横断的アプローチによるビジネスモデルの設計

  • 作者: マーク・スティックドーン,ヤコブ・シュナイダー,長谷川敦士,武山政直,渡邉康太郎,郷司陽子
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2013/07/25
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (3件) を見る

Cordova 3.5でiOS用のプラグインを作るときのメモ。

基本的にこちらを見れば作成できますが、その中でもハマったところのメモ。

XCodeで始めるときはPluginsディレクトリに指定して作る。

  • XCodeのGroup(?)に.h, .mのファイルを追加するようにしないといけない。

config.xmlに書く。

こちらの通り作る中で、

    <feature name="Hello">
        <param name="ios-package" value="CDVHello"/>
    </feature>

をconfig.xmlに記載しないと認識されない。

参考

idobataをMacでデスクトップアプリケーションとして使用する

チャットワーク(ChatWork)をMacでデスクトップアプリケーションとして使用する | kotaログ

:%s/チャットワーク/idobata/g

で試してみる。