pplog 非公式 Chrome ゆるふわクライアント情報

@fukayatsu さんが作ってくれました( ˘ω˘)
なにこれすごい便利。そして、かわいい( ˘ω˘)"

pplog

pplog ゆるふわクライアント (Chrome 機能拡張)



昨日、キーボードショートカットがついて、キーボードでほねを回せるのがとてもイカしてたので、さっそく今朝本体にもキーボードショートカットが取り入れられました。
そして、なんと今日は、通知機能がついたそうです。すごいーーー!
購読中のポエムラインの新着をお知らせしてくれます。うれしすぎる。メールボックスがこれで爆発しないで済むよ。すごすぎる。ゆるふわどころかガチムチだ!(ってえびちゃんが言ってた

pplog

通知かわいい( ˘ω˘)" 今のところ、10分に1回まとめてお知らせしてくれる仕様のようです。
ポエムに書いたんですが、ちゃんとした方のインターネットの、残るブログに書いた方がいいのかなあと思って、書きなおした。
はー、マジ、よい。@fukayatsu さん ありがとう、ありがとうございます( ˘ω˘)"

ちなみに

ゆるふわクライアントインスパイヤで、pplog Webサイト本体にもキーボードショートカットがつきました。

  • d: あしあと
  • z または f: ほねを回す
  • n: 新規ポエム
  • h: ホームに戻る

他、なんか色々あるみたい( ˘ω˘)

俺たちのゆるふわインターネット「pplog」 をリリースしました(してました)

自分で言うのも非常に僭越でウザいんですが、本当に今一番面白いインターネットなんです。

pplog



pplog - ゆるふわインターネットにポエムを刻もう
昨年の9/27から突如ベータリリースして仲間内で使い続けてるうちにいつの間にか広まっており、正式?に外向きの物を書くのはこれが初めてなのですが、リリースしてましたのお知らせです。

@ppworks さんがプログラミングのほとんどをやり、私がデザインやってます。
他に @fakestarbabyさん、@soplanaさん、@_tbaba さんが仕事の合間にサポートしてくれており、@satococoa さんが今iPhoneアプリを作ってくれてて、大体できてきてます。楽しみ。

使い方やどんなサービスかについて、ここでは特に詳しい説明をしません。(誰かがnanapiに書いてくれるの待ってる( ˘ω˘))
とりあえず、画面右下のほねを回してればなんとなくわかる気がする。

サービスについての説明のかわりに、自分が最初にGitHubのIssueに書いた、恥ずかしいコンセプトポエムを晒します。けど、こんな意図の説明しなくたって、使ってくれてるユーザーさんたち(ポエマーと呼んでる)は、意図を完全に理解して使ってくれてて、すごいなーと思って見てる。




====== (以下、最初にIssueに書いたコンセプトポエムです)======

なぜ、ポエムなのか

ブログとソーシャルの功罪と向き合う時が来た。

人目を気にしてブログに書きたいことを書けなくなった。もしくは、多くの人のウケやアクセスアップを狙うことしか書けなくなった。他人にとって有用ではない事は書きづらくなった。
そんな事はないだろうか?

ブログがインターネットに及ぼした最大のイノベーション、それはパーマリンクの概念の発明だった。ブログ普及以来、インターネット上のあらゆるコンテンツは、固有のURLを持つ事が当たり前になり、それはこの世に多くの恩恵をもたらした。しかし、それは幸せな事ばかりだっただろうか?

氾濫するまとめ記事、アクセスアップを狙ったライフハック記事。多くの人の検証や言及を恐れ、エクスキューズだらけになった記事。かたや、わかりやすい負の感情やツッコミを煽る記事、それを逆手に取った炎上マーケティング。多くの人が短時間に一定のわかりやすい記事に着目し、言及し、一瞬で忘れ去られる。うっかりした若気の至りも、不意に思わぬ多くの顔の見えない人の攻撃に晒され、一瞬で忘れ去られるが、その傷と証拠はずっとネットに残り続ける。
何やら、インターネットが窮屈になってきたのでは。私達が書きたい事を好きなようにかける場所は一体どこにあるというのだろう。

「私はこう思う、こう感じた。」ただそれだけの事を書いただけなのに、うっかり各種ソーシャルでアクセスを集めてしまい、顔の見えない不特定多数の攻撃を受けてしまう。そういうの、何かが間違ってやしないだろうか?別に誰かの検証や対話を必要としていたわけじゃない。自分がぼんやり思っている事をこの世の誰かに知って欲しかっただけなんだ。

かたや、半ば閉じた世界のFacebookで発言するのも、やっぱり人目を気にしてしまう。いいねつかなかったらクヨクヨしてしまうし、仕事上の繋がり、微妙に遠いつながりの人達の目を気にしてしまう。空気読んで、やっぱり話題を選んでしまう。疲れる。つらい。そして、インターネットならではの、思ってもみなかった人に出会う事もない。それもつまらない。

固有のコンテンツがパーマリンクリンク可能性を持っていることによって、それがソーシャルへ共有されてしまう可能性があることによって、あらゆるネット上へのコンテンツ発信は、常に不特定多数の評価という広義のマーケティングを意識せざるを得なくなった。その評価は無情に定量化され、序列化される。そのことが発信のモチベーションになったり、生活や仕事の糧になったりと、プラスの面はもちろんあるのだけど、同時にそれは発信されるコンテンツを貧しくしてはいないだろうか?私達はもっと自由に、もっと思ったことを言っていい。そして、自分の近しい人や共感できる人のそういうものをもっと読みたいのだ。黙って読みたいし、黙って読んで欲しい、誰かと対話することなくただ黙々と語りたい。そういうものがあるんだ。それがゆるふわポエムだ。

自分の思いを好きなように書ける場所が欲しい。

ブログが生まれる前のテキストサイトは、もっと色んな人が好きな事を好きなように書いていたように思う。そこには直接的な対話もない。大衆の目にさらされ、一度にたくさんの言及や攻撃を受けることもない。一定のファンしか見ない。誰かにとってはつまらないかもしれないが、誰かにとってはクソ面白いかもしれない。それでいいんだ。そんなかつてのテキストサイトのような豊穣を、インターネットに取り戻したい。そのために、一度私達はあのパーマリンクを忘れる必要があるのではないかと考えた。全てがそうなれとは言わない。そういう場所が1つくらい、このインターネットにあってもいいのでは?もっとゆるいソーシャルを、もっと自由なブログを、再発明する必要がある。

ソーシャルに疲れた私達が今欲しいものは、パーマリンクのないゆるふわブログサイトなんだ。

要件とかずらずら
  • 誰も読んでくれていないとそれはそれでつまらない。でも近しい人や、自分が直接は知らないけども共感してくれる人、面白いと思ってくれる人、そんな人には読んで欲しいし、自分もそういうものを読みたい。
  • 対話はなくコメントも付けられない。ただ1つ、「読んだよ」という印としてのスターがつけられる。モチベーションの源泉にもなり、スターでふざけることもできる。唯一のソーシャル要素だ。スターははてなスタークローンがよい。あれ好き。感動したらたくさんスターつければよい。
  • RSS購読のような感じで人のポエムを購読できるけど、自分のポエムを誰が読んでいるかはわからない、ソーシャルのようにフォロー関係を気にすることもない。読みたい人が読めばよいのだ。
  • みんなに人気のポエムとかを抽出できるような機能を付けない。あらゆるマーケ要素を排除したい。好きな人だけが読みにくるような仕組みにしたい。

======(コンセプトポエムおわり( ˘ω˘))======



補足すると、この中から、スター(現在は肉球)をたくさん押すという機能だけ途中で無くしました。スター連打したいという声もあったんですが、一つ一つの読んだ痕跡が大事にされない感じがあったのです。
あと、pplogの記事ごとのパーマリンクは、実は無いわけではなく、書いたユーザーしか読めない状態で存在しています。
それ以外は、この通りの感じのプラットホームが、想像以上の素晴らしさで実現してて、毎日みなさんのポエムを読むのが楽しすぎて楽しすぎて、仕事に支障をきたしています。

ppworksさんのHeroku Meetupでのpplogについての発表資料

ポエム by @ppworks http://decknotes.net/slides/168

プログラマのppworks氏の発表。pplogの技術的なトピックにも触れています。
色んなプログラマさんみてきたけど、@ppworksさんは本当いい技術者だと思う。仕事がびっくりするほどクソ早い上にコードもキレイ、アイデアも豊富で、柔軟性やコンセプトへの理解も深く、実にスゴイ( ˘ω˘)

今も作って終わりじゃなくて、日々色んなところを改善して、毎日デプロイしょっちゅうデプロイしています。みんな思いついたら勝手にコード書いてプルリクするし、とても美しいGitHub Flowのようなものが実現できてると思う。Issueは雑談とポエムと( ˘ω˘)だらけで、すごく楽しいリポジトリです。

ついでに、Google Analyticsをちょっぴり見せちゃう( ˘ω˘)

pplog
今こんな感じです。
UUに対してのPVがちょっとおかしい気がしてる。平均滞在時間もちょっとおかしい。黎明期のサービスってこんなもんなのかな。。

そんな感じで、これからもpplogをよろしくおねがいします( ˘ω˘)"

pplog - ゆるふわインターネットにポエムを刻もう


ポエマーさん、1300人になったよ!

安西先生、ポエムが書きたいです( ˘ω˘)

# 追記

プログラマの @ppworks氏 によるリリースエントリーきてた( ˘ω˘)
わしのよりちゃんと書いてあってオススメです。
プログラマーってのはさ〜、ネクタイ締めて、スーツ来てさ〜、ヒウィゴッってなわけにはいかねーんだよ〜」

まったりと過ごせるおれたちのインターネット、それがポエム pplog.net #pplog

# 追記 2

confwd (iOSデベロッパーカンファレンス)で今日、@satococoa 氏がポエムのiOSアプリについて発表しました。こちらもイイカンジで出来上がってきてて楽しみです( ˘ω˘)

iOS でポエムをつづろう! // Speaker Deck

WCAF Vol.11 in 福井 にて、デザインについて話してきました

前回の大阪に続き、@shirokuro331 さんに、今度は福井に来てしゃべりませんか?というご依頼をいただき、日本海カニにつられて福井に行って来ました。福井の意識高いデザイナーのイベント「wcaf」(ダブキャフ、と読むらしい。カッコイイ。)、イベント自体もとてもおもしろく、また福井のITシーンの熱さに大変刺激を受けました。カニもすごくおいしくて、また福井行きたい。
前回と同様のネタの再演という予定だったんですが、全く同じことを話すのもなんかなあ、申し訳ないなあと思っていたところ、木曜日になって新しいネタを急遽思いついて、前日の夜に急いでスライドを書いたら意外と間に合ってしまったので、両方話させていただきました。おかげで、前半はかなり駆け足の発表になってしまい、ちょっとわかりにくかったかもしれません。。すみません。


こちらは、ズルいデザインの方で前回の大阪と内容はほぼ同じです



新しい方はこちらです。 @ppworks さんの we love heroku のデザインリニューアルについて、アドバイスをした内容をスライドにまとめました。

デザインは、目的のための最適化のメソッドなので、本来は、何か実例をもとにしたケーススタディが一番わかりやすいと思っていたのですが、今までそういうのにピッタリな例を用意できていませんでした。このプレゼンの2日前の木曜日に、@ppworksさんにカフェでご飯を食べながら、we love heroku のデザインの相談を受けて、1時間くらい口頭であーだこうだ言ったら、デザインがかなり良くなり、@ppworks さんもデザインの勘所を身につけてきていたので、こりゃおもしろいと思い、ネタにさせていただきました。
お伝えしたかった事は、エンジニアがデザイン覚えるのは(感心さえあれば)きっと可能だということです。(もちろん、既にデザイン上手なエンジニアさんもいる)。デザインが上手くいくコツというのは、ある程度法則性に基づいた収斂があり、そのパターンの引き出しを増やしていけば上達する。また、デザインのキモは適切な情報設計ということで、これらは理論で展開できるので、エンジニアさんにもとっつきやすそう。そんなことをお伝えするためにスライドを急遽もう一本作ったんですが、会場はデザイナーさんの方が多く、やや内容的に外してる感がありました。

会の内容は、こちらの記事がとても詳しく、大変参考になりました。ありがとうございます。
WCAF vol.11「Design」のレポート(スライド・感想・メモ) - 役立ちぬ開発史、それはただのブログ

コンテンツを意識したデザイン思考 by @toybox_design さん

スキュアモーフィズムとフラットデザインの対比をUXの視点から理論的にわかりやすく説明されており、大変素晴らしいプレゼンで、勉強になり、大変共感しました。そしてスライドが美麗だ!
実世界の比喩を可能な限り排除して、画面内の情報の本質で勝負しようというのが、昨今のフラットデザインと呼ばれるものの試みの思想的背景であると思います。例えば、英語のネイティブスピーカーは、一旦自分の慣れた他の言語に翻訳することなく、直接英語を英語のまま理解して使いますが、それと似たようなことがスクリーンの中でも起こっているのだと解釈するとわかりやすそうです。これからはデジタルネイティブの時代なので、実世界の作法の翻訳ナシでも、直接デジタル界の作法を理解しろよお前ら、という世界観の表明。それ自体は有意義な試みであり、時代の流れの中の必然なのだと思いますが、しかし、iOS 7 とかに限定して思うのは、従来非言語で説明できていたものの多くを、言語説明に頼らなければならなくなってしまったのは、ちょっとそれデザインの敗北なんじゃないかなー的な感じもしており、要は、私も iOS 7 のデザインはあんまり好きくないです。フラットUIそのものを否定するわけではないんですが、iOS 7 は色々つらい。あんまキレイじゃないし白すぎるし動きは大げさすぎて誤動作誘発するし、まあつらい。ユーザーを置いてきぼりにしたデザインのためのデザインという感じがして、しかしそのデザインが言うほどカッコヨクないのがまた腹立つ。iOS 7 のデザインの悪口ならいくらでも出てくるので、iOS 7 をDisる会みたいなのがあったら行きたいです。懇親会でタチバナさんとiOS 7の悪口で盛り上がろうと思っていたのにすっかり忘れてカニに夢中になってしまったのが心残りでありますが、カニ美味しかったしまあいいか。人のスライドの感想に乗じて、iOS 7の悪口を言っただけになりました。

What’s MVP、MVP Global Summit by @xin9leさん

https://skydrive.live.com/view.aspx?cid=6bb303f9b4513bfc&id=documents&resid=6BB303F9B4513BFC%2118721&app=PowerPoint&authkey=!AFzDy04bqjLuJEE&&wdSlideId=258&wdModeSwitchTime=1386968399344
(スライド貼れなかった…スミマセン。。。)

マイクロソフトMVPについてのお話。MVPってカッコイイよなあ。マイクロソフトって最近イケてるっぽい噂はよく聞く。噂だけはよく聞くのだけど、やっぱり自分で殆ど使わなくなってしまったのでよくわからない。そして使う気にまだならない。Web開発者にとって(自分の周辺だけなのかも?)の長年のイメージの蓄積がなんかこうすごくネガティブ寄りになっていてかわいそうな感じがある。ビル・ゲイツだってなんか金の権化っぽい言い方されるけど実際全然そんなことないだろうし、冷静に考えて、ビル・ゲイツスティーブ・ジョブズだったら、断然ビル・ゲイツの方がいい人だと思うし、ギーク感溢れる「こちら側の人」って感じがして好感持てるよなー。ジョブズとかさ、トーク上手いけど、伝記とか読むととにかく突き抜けた嫌な人なんだなあという感想しかない。カッコイイけど、完全にあれ、嫌な奴じゃないですか。まあ、好きなんですけどね。

プログラマ & デザイナのコミュニティの作り方 by @satococoa さん

我らが海老沢さんの #p4d についてのお話。p4d すごいですね。デカくなりましたね。Facebookグループの人数も合計400人を突破したようで、大人気のコミュニティに成長した事を実感します。私も p4dのおかげで、全く誇張ではなく人生が変わりました。RailsもGitもp4dがなければ触れることはなかったかもしれない。仕事も技術の知識も発表の機会もp4dのおかげで頂きましたが、なんといっても一番は、尊敬できる仲間に出会えた事です。p4dのユニークなところに、常連メンバーにバックエンド方面に強いエンジニア(Rubyの人)が多いというのがあると思います。これだけ、バックエンド寄りのエンジニアとデザイナーが積極的に交流するコミュニティは、かつてあんまりなかったんじゃないでしょうか。海老沢さんは、p4dにしても、RubyMotionのコミュニティにしても、本当に良質なコミュニティを運営することに長けたリーダーなのだなあと思います。自分的に主催とかとても無理ぽいし、マジリスペクトです。まさにえびちゃん様様です。割と大らかでありながら、締めるところ必ずしっかり締めてくれる感じのあのバランス感覚が素晴らしいのだろうなあ。
海老沢さんの働きかけもあり、p4d的な動きは各地に波及し、大阪のpmdをはじめ、p4d in 福井が立ち上がりました。楽しみ!

Programmer’s Brain by @xin9leさん

https://skydrive.live.com/view.aspx?cid=6bb303f9b4513bfc&id=documents&resid=6BB303F9B4513BFC%2118722&app=PowerPoint&authkey=!AF2uaMJ5hpN1SbQ&&wdSlideId=258&wdModeSwitchTime=1386968452663

プログラマの頭の中をのぞくという発表。プログラマさん、日々お世話になり接することも多く、まさにあるあると頷かされる内容でした。なんですかね、割と好きな人種なんですよね。理屈で話せば通じるし、理屈がちゃんと通っていれば納得してくれる人が多い感じが好きですね。我々には見えていない世界が見えていて、違う確度から物事を見ていてはっと気付かされる事も多く、ああいうのいいなあと思います。プログラマさんの視点が、自分の中にも欲しいなあと常々思います。

DESIGN for FUKUI のススメ by @taisukef さん

日本のモバイルのフルブラウザの先駆けである、jigブラウザでも名高い、株式会社 jig.jp 社長 福野さんの、福井のアツイ ITシーンについてのプレゼン。感動しました。福井では行政が率先してWeb上にライセンスフリーなデータを公開する「オープンデータ」への取り組みが日本一盛んで、福野さんはその立役者とも言える存在。こういうスゴイ方がとてもフランクにふらっといらっしゃるのもwcaf の凄さだなあ。さらに圧倒されたのはなんといっても「一日一創」、福野さん自ら、1年365日間毎日Webアプリを一つ作り続けるという実践をされている。一日一アプリ、この機動力、発想力、実行力、ヤバイ。そんなコードを自ら書き続け作り続ける社長、福野さんが説くデザインの重要性。いいアプリも、いいデザインがないと使ってもらえない。デザイン次第で、受け止められ方が変わる。福野さん自らデザイナーにもなる!と宣言されており、アツイ。有限実行の方だし必ずや上達されそうだ。
福井のITはなぜこんなにアツイのかとお聞きしてみたところ、福井は民放が4局しかなく、テレビ朝日系列とTBS系列が無いんだそうで、そのおかげか日本一スカパーが早く普及したとか。情報への渇望がITへの関心を促進したのではないかという説もとても興味深かったです。福野さんをはじめ、福井の技術者の方々は、技術だけではなく、ビジネスや地元行政と技術との関わり方を模索しており、技術に対する視野が広い方が多いのではないかという印象を受けました。そしてとてもポジティブで、良いよなあー。
そんな福野さんが今取り組んでいらっしゃる事のひとつが、「電脳メガネ」。ウェアラブルコンピューティングの時代を迎え、IT × 眼鏡で、これからは鯖江の時代だ!世界に羽ばたく福井の鯖江市、そんな未来が本当に来そうだと思いました。はー、楽しみだ〜!

DocPad と Ghostlab で Web 制作をスピードアップしよう by @shirokuro331 さん

今回招待していただいた、wcaf主催のささきさんのプレゼン。実は DocPad も Ghostlabも知らなかったんですが、スゴく便利そうで使ってみようと思いました。DocPadは、Middlemanなどに似た静的サイトジェネレーターなのですが、Bootstrapなどのよく使うテンプレートが、Terminal からダイアログ形式で選べて、すぐにプロトタイプのひな形が立ち上がるというスグレモノ。プロトタイプを速攻で作りたい時なんかは、Middlemanよりも良いかもしれないと思いました。CoffeeScript製というのもオシャレだ。Ghostlabは複数のデバイスやブラウザをSyncしてくれるもので、こちらも便利そう。とても参考になりました。実演も上手だったなあー。ウラヤマシイ。

福井の素晴らしさ

盛りだくさんで素晴らしいイベントだったのですが、何といっても一番感動したのはやはり福井の良さでした。ITに対するアツさ、ポジティブさ。皆さんスキルが高く前向きで攻めの姿勢だ。保守的な感じは微塵も受けなかった。東京ばかりが何かと脚光を浴びがちで、人も集まりすぎだけど、本来、どこに住んでいてもコミットできるのがITの良さだ。これから業界が成熟するにつれて、地方に進出する技術者も増えそうですが、福井は地方とITの関わりあいにおいて、素晴らしいロールモデルだと思いました。
あと、カニカニマジうまい。越前ガニのメスはサイズが小ぶりで、ミソと卵がものすごくおいしく、「せいこがに」と呼ばれる。このせいこがにをごちそうになりました。このカニ、福井の地元の方々に愛されており、福井のスーパーでは数百円で買えてしまうらしい。仕事帰りにカジュアルにカニとビールを買って帰る幸せ、いいなあ。お刺身も東京の3倍くらいの厚みがあり、とてもうまい。
福井は県民の幸福度が全国でナンバーワンの県なんだそうです。そりゃー、食べ物がこんなに美味しくて、さらに人々は前向きで、福井、マジいいよなあと思った。
本当、ありがとうございました。また行きたい。

Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013

常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。

「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話


Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck
GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。

補足とか
  • 「生煮えぷるり」という表現、多分最初にうちのチームで言い出したのは @a_matsuda 氏です。また人の発言をパクってスライドにしました。
  • 「FIXYOU」というコミットコメントについて。FIXMEを修正した時に @_tbaba 氏が入れるコメント。これは、コードが「FIXME! (ぼくを直して!)」って言ってるってことなので、「お前を直してやったぞー」という意味での「FIXYOU」なのだそうです。なんかかわいい。Forkwell チーム、基本、コミットコメントは英語なんですが、絵文字使ったり、お茶目英語表現使ったりして、かわいいコメントを書く人が多くて、開発中にちょっと和んだりする。もちろん、意図が伝わることは前提として、かわいみあるコミットコメントは円滑なチーム開発にとって大事よね〜。という話になった。
  • 「気持ち悪い状態」が続くこと、について。これは、少なくともデプロイ時には、ユーザーにとってはこのデザインが完成形であるように見える形になっていないといけない。ただ、デザイナーとしてもう少しここを良くするとグッと良くなるよねっていう状態はわかっていつつも、先にマージやデプロイをしてしまって後から直すっていうことがままあるという感じのことです。デザイナーじゃないと一見違いがよくわからない(けど、全体として受ける印象を結構変える感じのデザイン変更)が多いです。デザイン的にあんまりクリティカルな欠点を残したままマージ / デプロイするという事はまずないと思います。プログラマにとってのリファクタリングに似たところあると思います。
  • デザインカンプをきれいに完璧に作りこんできたようなデザイナーさんは、上記のような段階的プロセスに拒否感を感じそうだという意見いただいて、私もそうだと思う。どっちが良い悪いではなく、これは受け入れられる人とそうでない人がいるだろうなあと思う。(自分もちょっとつらみを感じる時はある)。
  • デザインラフについて、これはプロジェクトマネージャーが作る場合もあるが、その場合も一度デザイナー側で検討して必要があれば変更したりする。基本、要件をテキストベースでもらえれば、それをもとにラフやワイヤーフレームを書くような感じの流れになってます。ラフはプログラマが描く時もありますね。
  • 開発はリモートか?という質問について。基本、オフィスに集まって開発をしますが、リモートでも可能な体制になってます。私を含め、フリーランスの業務委託でフルタイムではない勤務体制の開発者も数名いて、自己都合で外から対応させてもらう日があったり、自分の勤務日ではない日や深夜などにおもむろにPushしたり、ぷるりにコードレビュー書いてたりとかはよくある。
  • push -f すると、ぷるりのコードレビューコメントがふっとぶ問題について。これについては、完全に消えるわけではなく、Show outdated diff をクリックするとみれるし、大体 rebase する時にはレビューで言及された問題は解決されていることが多いので、さして気にしないでもよいのでは、というのが私の個人的な見解デス。まあ、そのまま残ってた方がより良いかもなあとは思うのですが、それよりも rebase + push -f の利点の方が大きそうな感じがしてます。

前半で、上のスライドを発表させていただき、後半は、デザイナーとGit について、デザイナー数名でパネルディスカッションをしました。濃い話できて良かったし、その後デザイナー4人でずっと飲んでいて、続きの話をずっとしてて、結局 Git は「デザイナー」にとっていいものなのか、ちょっと嫌なものなのかは、実はよくわかんないねっていう話に落ち着いたのが面白かった。私自身はGit & GitHubラブなんですが、確かにピュアな「デザイン」にとって、Gitを使った開発フローは向いてない面もあるのかもって思う時はちょいちょいあって、しかし1人のWeb開発者としてGitは好きだしその思想にも共感できるので、そのジレンマは常に感じているのが正直なところ。

Git って本当にデザイナーを幸せにするの?

従来、純粋な「デザイン」とされてきたものって、伽藍とバザール(古い!)でいうところの「伽藍」的な側面が強く、一方Gitは分散型の「バザール」的な思想だ。そのデザインをいかにバザール的なプロセスでやっていうかというところが、おそらくGitを使うデザイナーの根本的なジレンマの原因なのではないかと思っている。そもそも、頻繁に cherry-pick を使わなければいけないのもちょっと無理矢理感があるのだが、現状それよりベターな解決策が見つからないし、そこも伽藍を無理やりバザール的なプロセスに合わせてるゆえなのかなあという感じがある。
また、Git や GitHub が基本プログラマフレンドリーに作られてるため、そのプロセスにがっつり乗っかると、どうしても自分もプログラマ的思考に引っ張られることになる。その中で、デザイナーとしての役割分担を常に意識しながらチームプレイしていくというのは意外と負荷が高い感じもしてる。
あと、純粋な「デザイン」にかける時間はやはり相対的に減ってしまう。とはいえ、「これは自分の仕事ではないからやらない」という切り分け方を個人的にはできるだけしたくない。しかし、デザインにかけるリソースが減ってしまうことで、プロジェクト全体の利益が少なくなるならそれはよくないこと。意識して、「デザイン」にかける時間を捻出するようにしないといけない。
そんな感じで、Git が本当にデザイナーを幸せにしているのかは、正直なところよくわからないのです。ただ、「デザイン」がどうであれ、Webサービス開発的な視点では、やはりイテレーティブなプロセスは正しいのではと感じる。自分のスタンスとしては、デザインの大切さをちゃんと自覚しながら、デザインをどうやってうまくエンジニアリング的なプロセスに乗っけていくのか、というところでこれからもしばらく悩んでいくべきなんだろうなあという感じ。まだまだ、答え出なさそう…。

個々のプレイヤーにとってアンコントローラブルな状況がなくなるのが Git の一番の素晴らしさでは?

会の後、デザイナー数名で飲みながら話してて、P4Dに来るようなデザイナーは、本来、何かを人に任せておいて分業するのを比較的好まない、全部自分一人でやりたくなっちゃうようなタイプのデザイナーなのに、なんでGitを使うとチームプレイをすごく大事に思うようになるのか、すごく不思議だという話をしてて、これは本当にそう思う。みんな自分1人の小宇宙を作って、そこで自分のやりたいデザインやWebサービスを実現させたくてプログラミングやりたいなーって思うようになったのに、Git以降は、誰かと一緒に作る良さをすごく感じるようになった。不思議だ。
これおそらく、Gitのお陰で、自分にとってアンコントローラブルなブラックボックスがだいぶ少なくなり、何かを変えたいと思えば自分自身の手で変えられる状況が常に手元にあるというのが大きそうだ。この意思決定プロセスの民主化を思わせる設計思想が、自分が一番 Gitを素晴らしいと感じる点。みんなで一緒に作っていながら、全体が個々の意思に沿わない流れになってしまうことが(少なくともコードの中で起きていることにおいては)、GitやGitHubというツールを有効に使うことによってだいぶ減るのだと思う。

もう少しきちんとデザインと向き合わないとな

長年デザイナーをやってるわけですが、デザインは楽しい反面本当にしんどい。自分のレベルも伸びしろも見えてきて、何かちょっと努力しただけで目に見える成長をするのが難しいような状況があり、反面プログラミングっぽい分野は、自分にとって異分野なので、大したない事でも、ちょっと成長しただけで、すごく達成感を感じる事ができる。周りにも、デザイナーなのにすごいねって褒めてもらえる。大したことないのに。あー、こういうのって楽な方に実は逃げてるよね。安易だしズルいよね。っていう話をした。そうなんです。RPGでもレベル低いうちはヘボい敵でレベル上がって嬉しいんですね。こうやってるうちに、デザインがおろそかになり、結果的にどっちも中途半端な人になる(なってる!)のを避けないとまずいなっていうのはすごく思う。
自分や周りのP4Dで会った仲良いデザイナーたちは、プログラマになりたくてコードを書いてるわけじゃなくて、自分のやりたいデザインをやりたいから、自分のデザインでぼくの考えた最強のWebサービスが作りたいからコードを書くようになっただけで、おそらく普通にデザインがやりたいからコードを書くようになっただけなのだよなー(というかプログラミングっぽいことやればやるほど自分にはガチのプログラマは無理だろって思えてくる…)。
そんなわけで、もうちょっとちゃんとデザインをやろうと思ったのが、一番のこの日の成果でした。
Git は素晴らしい!

spacer.gif に Pull Request 送った

ダイエットさせてみました by taea · Pull Request #1 · msng/spacer.gif


64バイトから43バイトにダイエット成功である。
マージされるといいなあ。わくわく(ΦωΦ)



わろた

歴史あるやつと差し替えても面白かったかもしれない。

第27回 #p4d 参加した:omniauth-twitter

前回の続き。おかげさまで、Iteration 周りは自力でも進められそうな感じになってきたので、Twitter でユーザーがログインする機能を作りたいとおもった。 omniauth-twitter を使えば楽にできるけど、楽に出来すぎてよくないので OAuthからちゃんとやった方がいいですよというアドバイスを頂き、どっちがいいのかなあと思っていたのだが、あまり時間もないので omniauth 使うことに。今回、@katton さんに教えていただいたのですが、 OAuth とは?というところからわかりやすく教えていただき、だいぶカバーされた感じなので、下記おすすめ書籍を読んで理解深めたい。
また、@katton さんは、リアルタイムでエディタでお題を書きながら、そのメモをエディタ上で見せながら進めてくださり、さらにそのメモを帰宅後送って下さるなど、大変ありがたく、またこの方法は教えるのに大変よい方法だと思った。頂いたメモをベースに追記する感じで、復習が進められた(下記は、その記録)。ありがとうございました!

0. OAuthとは

リソース保有者が、リソースプロバイダー(Twitterとか)に対して「アプリに自分の情報を教えても良い」と許可すること。
※ 今回はサーバサイドWebアプリケーションフローを採用。

1. twitterにアプリケーション登録

本番用と開発用両方を登録しておく
dev.twitter.com/apps

  • 本番用 Callback URL: domain/auth/twitter/callback
  • 開発用 Callback URL:(pow.cx を使った場合): APPNAME.dev/auth/twitter/callback

omniauth の callback URL は、/auth/[プロバイダ名]/callback


callback
get '/auth/:provider/callback', to: 'sessions#create'

2. Figaro使う

laserlemon/figaro · GitHub
なぜ?:アプリ固有の設定をapplication.ymlというカタチで保存、Figaro.env.xxxで読み込みができる。

インストール
gem 'figaro'


$ bundle

$ rails g figaro:install

config/application.yml に先ほどdev.twitter.com で登録したときの、key と secret を書いておく。

こうすることで、各プロバイダにアクセスする用の key 達が一元管理できる。
config/application.yml はインストール時に自動的に.gitignore に追加されるので、ソースコードを公開してもヒミツにしておけるのもナイスだ。

development:
  twitter_key: xxxxxxxxxxxxxxxxxxxxx
  twitter_secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

production:
  twitter_key: xxxxxxxxxxxxxxxxxxxxx
  twitter_secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Heroku

Herokuに デプロイするときは、この1行コマンド打てばOK


$ bundle exec rake figaro:heroku

3. Omniauth を使う

intridea/omniauth ・ GitHub
arunagw/omniauth-twitter ・ GitHub
※ omniauth-twitter のように、付属機能的な意味合いの場合はGem名の接続子が "-" になる

インストール

Gemfile

gem 'omniauth'
gem 'omniauth-twitter'


$ bundle install

設定ファイルをじぶんで作る

複数プロバイダを使用する場合は、別ファイルに設定を書いたりしないといけなくてめんどい。今回はTwitterだけなので1つのファイルでOK。
config/initializers/omniauth.rb
公式のUsageではこんな感じに、直接KEY と SECRET を書けとなっているが…

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, "CONSUMER_KEY", "CONSUMER_SECRET"
end

先ほど、Figaro を入れたおかげで、config/application.yml に書いたKEY 達をこのように設定から呼び出せるようになってる。ナイスだ。

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :developer unless Rails.env.production?
  provider :twitter, Figaro.env.twitter_key, Figaro.env.twitter_secret
end

4. Userモデルをつくる

必要なカラムを確認

omniauth-twitter の Authentication Hashを見ると、Twitterから取れる情報が一覧できる。いっぱい取れる情報があるんですねー。
今回は、ログインに使うくらいなので、名前とアイコンくらいがあればいいかなー。
uid, secret, token は必ず必要だよ。ってなわけでとりあえず必要なのは以下の5つとなる。

  • uid
  • name
  • nickname
  • image
  • token
  • secret


$ rails g model user uid name nickname image token secret
全部 string でいいので、並べるだけでOKだった。
uid は必須かつユニークにしておこう。
/db/migrate/20130815115856_create_users.rb

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :uid, null: false
      t.string :name
      t.string :nickname
      t.string :image
      t.string :token
      t.string :secret

      t.timestamps
    end
    add_index :users, :uid, unique: true
  end
end


$ rake db:migrate

5. OAuth認証をする

5-1. TwitterへのURLをつくる


= link_to 'Twitterでログイン', '/auth/twitter'
というリンクを仮にTOPのviewに作っておく

5-2. powインストール

Pow: Zero-configuration Rack server for Mac OS X
開発ディレクトリのシンボリックリンクを~/.pow に追加しておくだけで、http://APPNAME.dev というURLでアクセスできるというイカしたもの。みんな大好き37signals 製。CoffeeScript と Node.js でできてるらしい。シャレオツだね。
実際のPowの導入は、P4D時間内に間に合わず、帰宅後になったんだけど、少しハマった。


$ curl get.pow.cx | sh

$ cd ~/.pow
$ ln -s /path/to/myapp
だけで、http://APPNAME.dev
でアクセスできるはずなんだけど、

LoadError: no such file to load -- bundler/setup
っていうエラーが出てる。私の環境は、RVMでなくてrbenv(brew インストールでない)なのでおそらく Troubleshootingに書いてある
~/.powconfig に下記パスを追加する

export PATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH"
というのをやれば大丈夫なはず…あれ、動かない。。上記対処後アプリの再起動的なものも色々試みてだめだったので、一回powをUninstallしたのち再インストールしたら動いた。

5-3. Callbackを受け取って必要な情報をUserへ

logger.info で確認
app/controllers/session_controller.rb

  def create
    puts '==========='
    logger.info(request.env['omniauth.auth'])
    redirect_to '/'
  end

ログにTwitterからの情報っぽいものが出力されたら成功(puts '=========' は、ログの目印的に付加してる)

5-4. User.find_or_create_from_auth_hash の実装

この辺の半ばでP4Dはタイムアップになったので、@katton さんが書いて下さったメモを参考に、家で続きやる
app/models/users.rb に uidからuserを見つける -> なかったら新規にuser を作る という機能に必要なクラスメソッドを作る

  # find_or_create_by_oauth 既存のoauthを見つける -> 無かったら新しく作る 
  def self.find_or_create_by_oauth(auth)
    if user = User.find_by_oauth(auth)
      user
    else
      User.create_by_oauth(auth)
    end
  end

  # uid を使って 既存の user を見つける
  def self.find_by_oauth(auth)
    user = User.find_by_uid(auth['uid'])
    # user = User.find_by(uid: auth['uid']) # Rails4ではこう書ける
    if user
      user
    else
      nil
    end
  end

  # 新しく user を作る
  def self.create_by_oauth(auth)
    user = User.new
    user.uid = auth['uid']
    user.name = auth.info['name']
    user.nickname = auth.info['nickname']
    user.image = auth.info['image']
    user.token = auth.credentials['token']
    user.secret = auth.credentials['secret']
    user.save
    user
  end

同じく app/controllers/sessions_controller.rbにも authから ユーザーを見つけるクラスメソッドを追加
https://github.com/intridea/omniauth#integrating-omniauth-into-your-application

  def create
    @user = User.find_or_create_by_auth(auth_hash)
    #self.current_user = @user
    redirect_to '/'
  end

  protected

  def auth_hash
    request.env['omniauth.auth']
  end

current_user は まだないのでコメントアウトしておく。さきほど作った、Twitterへのリンクをクリックして確認してみる -> 認証ボタン押して戻ってきたら


$ rails c
User.find(:all)
[#
おー、ユーザー情報入ってるーヾ(*'ω'*)ノ゙

5-5. sessionにuser_idを保存して、「ログイン」をさせる

参考)https://speakerdeck.com/takai/login-form-from-scratch
app/controllers/sessions_controller.rb に session[:user_id] = @user.id を追加

  def create
    @user = User.find_or_create_by_oauth(auth_hash)
    #self.current_user = @user
    session[:user_id] = @user.id
    redirect_to '/'
  end
5-6. ログインの確認

app/controllers/application_controller.rbに current_user の メソッドを追加

  def current_user
    if session[:user_id]
      User.find(session[:user_id]) 
    else
      nil
    end

確認してみようー
app/controllers/sessions_controller.rb で loggers.info を書いて確認

  def create
		・
		・
		・
    logger.info("========current_user.name: #{current_user.name}")
    #self.current_user = @user
  end

※ 結局 この self.current_user の行は、別のところで current_user を定義したのでいらなさそげだ
ログに、Twitterの名前が出てきたら成功っぽい!

と、そんなわけで、一連のログイン機能のベースができたっぽいので、ここから、user と task や iteration を紐付けたり、ログインページを作ったりする。公開に一歩近づいた感じが嬉しい。

感想とか

  • omniauth 使うと簡単だと聞いたけど、私のレベルだとそれでもかなり苦労したので、結果 omniauth 使ってよかったのではないかと思う・・・
  • 今回も、@katton さんに大感謝だ・・・本当に、ありがとうございましたm(__)m
  • Pow便利だなー。Powいかすー。
  • 毎回、違うプログラマさんに教えていただくが、プログラマさんによってやり方も色々だったりするので、結果、色んな方法やアイデア、色んなツールが知れることになり、これはかなり素晴らしいのではないかと思った!(ありがたい・・・
  • find_or_create_by_auth はできたけど、これだけだとユーザーネームやアイコンを変えた時とかに更新されないので、それ用のメソッドがまた必要なんだろうなー
  • また、時間いっぱい教わってしまい、こちらからデザインの話とかすることができずに申し訳なす・・・
  • 今回、半分の時間で交代で区切っていただいたのだけど、やっぱり教わるとなると時間が足りずにフルに教わることになってしまう。
  • ので、前回教わった人は次回教えればいいんじゃないか、ってことにもなったので、次回はなにか教える側に回ります。

Middleman で link_to_if っぽいことをやる


ナビゲーションで、現在地を表すナビだけリンクをつけないみたいなことをやる時、Railsだと、link_to_ifとかlink_to_unlessとかを使うと便利だが、Middlemanのヘルパーにはそういうのは特にないっぽかったので、どうにかして似たような事をやろうと思ったらこんな感じになった。

https://gist.github.com/taea/6204099
index, concept, product, contact みたいな4つのページが仮にあったとして、それぞれ同じナビゲーション用のパーシャル source/partials/_nav.html.haml を呼び出すとする。
Middlemanのデフォルトのレイアウトは、ページごとにファイル名と同じ名前(index.html だったら "index" という名前)の class が外側の body につくようになってて 、これが "#{page_classes}" という 変数で呼び出されるようになってるので、これを利用して、この page_classes が、データで指定した page.name と一緒だったら、current ページを表すナビゲーションとして処理するという感じにした。三項演算子のところは、もっとシンプルに書けるんでは?という気もするのだけど、これ以外に思いつかなかった。
ナビゲーションの内容は、マークアップとは別のYamlファイルにdata/nav.yml みたいにして置いておく。Frontmatter でもいいんだけど、複数ページで共通の要素なので、外部に置いた方がキレイに共通化できる。コンテンツを外出しするとマークアップがこれだけで済むのがステキですね。Middlemanステキですね。
マークアップ、Slimでもいいんだけど、Gistで色がつかないのが悲しいのでHamlで書いた。