Googleの検索結果に"1年以内"というフィルターを加えるためのChrome Extensionを作った
追記: このあいだ"2年以内"っていうフィルターも追加出来るようにした https://github.com/nekova/drip-search
id:r7kamuraさんのブログを読んで、それ欲しいな〜って思ったので作った
1年以内 - ✘╹◡╹✘
DartやPolymerについてGoogleで検索する時には、"1年以内"というのは必須と言っても過言ではないフィルターなんですが(特にDart)、今まではポチポチしてフィルタリングしてました。
r7kamuraさんの仰る通り、キーボードで出来たら嬉しいのでChrome Extensionとして実装してみました。
インストールはこちらから
https://chrome.google.com/webstore/detail/drip-search/lgjmghgpgnlpcdljdgaplcficabefohd/
(インストール時に「このpackageはgoogle.comにアクセスします」と無駄に不安を煽ってくるので辛い)
Chrome ExtensionのKeyboard Shortcutはインストールした人が手動で設定しないとだめみたいなので、拡張をインストールしたら
chrome://extensions/
にアクセスして、下の方にあるKeyboard Shortcutからご自分の好きなコマンドでショートカットを設定して下さい。
ちなみに、僕は Command + Shift + Sでやってます。
似たようなChrome Extensionを3つほど見つけたんですが、どれも更新が止まってたので自分で作りました。 drip coffee的な意味でdrip-searchってつけたけど、コンポーネントとかを作る度に自分の命名力の無さに反吐が出るのでいい感じの名前ください。
当初はqueryが既に存在するかどうかを調べて追加する実装にしようと思ったんですが
//past month & past year "&tbs=qdr:m&tbs=qdr:y"
この場合だと後ろのqueryの方が優先されるみたいなので現状はこれで良いかなと思います。 内部的にはGoogle searchかどうかを確認して、queryを最後尾にぶち込んでるだけです。 ちなみに、僕は DuckDuckGoで検索することが多いのでそれへの対応もしたいです。 あと、アイコンないのダサいですね。なんとかしたいです。
Chrome Extension作る時はyeomanのgeneratorを使うと、zipで固めるのもやってくれたり、scaffoldしてくれたりするので楽っぽいです。 ただ、リポジトリがごちゃごちゃします。
この拡張、githubにあるので、欲しい機能とかあったらPullRequest投げてください https://github.com/nekova/drip-search
わりと便利です。満足したので寝ます
編集者がGitHubを使えないなら、penflipで本を執筆すればいいじゃない
可能と適切の差異
近年ではブログ記事をGitHubで管理している人は珍しくない。さらには、GitHubを雑誌の連載記事や書籍の執筆に利用する人も増え始めている。 文章の変更履歴管理にGitの差分管理はうってつけではあるし、後者のような複数人での作業時にこそGitHubの腕の見せどころである。 また技術者との共著の場合において、GitHub上でコミュニケーションが完結するのは極めて都合が良い。馴染みのあるUIと手順で本が書けるので、Gitを使い慣れた技術者にとっては不満はないはずだ。 しかし、そこに編集者を介するとなると少し面倒なことになる。 @naoya_itoさんも言及していたように、GitやGitHubを使いこなせる人は多くないという現実に突き当たるのだ。 Gitの学習コストは皆さんが思っているより高くつくので、「編集者の皆さんにGitを勉強してもらおう」という意見は些か乱暴である。 そもそも、GitHubはコードを置くための場所なのであって、本の執筆に最適化されているわけではないということも注意されたい。 ともすれば、Gitを使わないGitHubライクな本を書くためのサービスが必要だ、という話になる。 そして、それがpenflipである。
penflipを使ってみて
この散文を書く際にpenflipを利用したので、以下にその感想を書くことにする。大半がGitHubとの違いの説明が占めている。 感想を述べる前に、「今現在GitHubで執筆をしている人達がわざわざ移行するほどではないが、少なくとも近い将来この手のサービスが求められるだろう」という個人的な見解を述べておく。
全てがWebで完結する
GitHubは優れたサービスではあるが、ほとんどの人がREADEMEの編集であってもローカルのファイルを編集し、terminalからgitにまつわる大袈裟な所作をするはずだ。(webで完結させることも可能ではある。) その点、全てがweb上で完結するpenflipは大変都合が良いし、markdownでの文章入力に最適化されたUIになっている点も素晴らしい。 また、プロジェクトを章で分けた時の見通しの良さはGitHubには無い利点である。 さきにも述べた通り、文章を書くことに最適化されたサービスなので、執筆という行為に集中して取り組むことが出来ると言えるだろう。
commiという概念の欠如
penflipにおいては保存は常に上書きで、最新の文書以外の履歴を参照することは出来ない。 ⌘+S を押すと入力中の文章が保存されmasterが更新される。 恐らくこれは意図的な機能削除だろう。 文章を保存する度にcommit messageを聞かれるのは面倒であるし、少なくとも僕の経験上、散文を書いている時に「あの時の文章を復元したい」と考えることは無い。 そういう意味で、僕はこの機能削除には肯定的である。
共著のための機能はあるが........
さて、commitが無いと聞いて「Pull Requestを送りたい時はどうするの？」と思った人もいるだろう。 penflipではMake Changes(fork)とSubmit Changes(push)を使い、Authorに変更リクエストを送信することが出来る。(Pull Requestという言葉は用いない) AuthorにSubmit Changesする際には任意のコメントを書くことが出来、さらに文章をドラッグした位置に一言のコメントを残すことも出来る。 蛍光ペンで場所を示し、ポストイットを貼ってコメントをするようなものだと考えると分かり易い。 issue機能はないが、Chatと呼ばれるdiscussionをするための場所はあるので、ファイルの変更を伴わないコミュニケーションも可能である。
branchという概念の欠如
さきのSubmit ChangesはいわゆるPull Requestを送る行為と似たようなものだが、branchという概念の欠如していることが大きな違いだ。 penflipでは常にmasterで作業することになる。これはcontributorも同様である。 ほとんどのケースではmasterで作業しても問題は起きないが、プロジェクト参加者全員でプルリク運用しようとすると面倒なことになる。 branchという概念が無い上に、Project(repository)はAuthorに強く紐づくせいで、同じ権限を持ったcontributorが他に居たとしても、Authorはmasterで作業することしか出来ない。 そのため最初にProjectを作ったAuthor、この記事で言えば僕(nekova)は誰かにレビューをしてもらうことが出来ない。 これは大変不便だと感じたが、ダミーのアカウントを作りProjectを作成し、他の全てのユーザをcontributor(権限はadmin)として追加することで相互レビューを実現することが出来るようだ。
より込み入った話をしよう。branchを切れないせいで執筆時に極めて面倒な問題が生じる。 たとえば、僕がpenflipにてRails3の本を執筆したと仮定しよう。今更Rails3.xの本を買う人は多くないので、全ての項目をRails4.xに対応した記述に改訂することにした。 ところがどっこいpenflipにはbranchという概念がないので、新しいbranchを切って改訂作業を進めることは出来ない。また、commitという概念がないため、どこまでがRails3.xの履歴で、どこからがRails4.xの履歴なのか分からず、復元も出来ない。 この場合は、Rails4.x対応のために新しいプロジェクトを立ちあげるしかないだろう。 あなたがする最初の作業はもちろん、本の記述を全てコピーして新しいProjectにペーストすることだ。おそらくChat等のコミュニケーション履歴をimportする機能はないので、必要ならばそれらを逐一コピーする羽目になる。 考えるだけで面倒だが、こうする他ない。
日本語であるが故の問題
Google日本語入力との相性が芳しくない点は非常に残念である。 penflipの場合は、文章を入力している位置の真上にGoogle日本語入力による補完が被って表示されてしまうせいで、かなりストレスが溜まる。 また、⌘+→で移動すると入力位置が正しく表示されなくなる場合があり、これもひどく残念である。 このような日本語の問題は新しいEditorに触ると必ずと言っていいほど直面することになるので慣れっこではあるが、Webサービスなので運営の対応を待つしかないのが辛いところだ。
結論
今現在GitHubで執筆をしている人達がわざわざ移行するほどではないが、少なくとも近い将来この手のサービスが求められるだろう。 この記事を書く前は、commitやbranchという概念があるものだと思っていたが、penflipはよりシンプルな作りになっているようだ。 GitHubライクなサービスというよりは、複数人で書くために拡張されたブログライクなサービスと呼ぶ方が語弊がないかも知れない。 ちなみに履歴はnekova/penflipで管理しているので、誤字脱字等の誤りがあった場合はこちらにPull Request(それに対応する言葉が存在しないのも辛い)を送って頂ければ幸いである。
でも、それでも、Web Components with Polymerに全力で投資する
エモくない話はQiitaに書きました http://qiita.com/nekova/items/30f1e11d6adfa1ff1ba9
WebComponentsって何なの
agektmrさんがWeb Componentsについて詳しくは知らない人に向けて、素晴らしい記事 を書いてくれているので読まない手はありません。
agektmrさんの記事読んだ後はWeb Componentsを使ってみよう！を読むのが良いと思います。
Polymerって何なの
Polymerとは、一部のモダンブラウザが対応しているWeb Componentsの機能を、未対応ブラウザに提供するためのPolyfillライブラリです。
一部のモダンブラウザとはChromeとOperaを指します。つまり、それら以外のブラウザのためにはPolymerが必要です。
先日のGoogle I/Oで発表されたMaterial Designも、Polymerチームお手製のコンポーネントを組み合わせて提供されています。（Polymerの普及も睨んだこの戦略には唸った）
それぞれの小さなコンポーネントはGitHubで公開されています。（リポジトリを数えたら120個くらいありました）
Material DesignとBCE
Material Designについての話をする前に、Twitter Bootstrapについて言及します。
Twitter Bootstrapを使ってクールなボタンを提供するには
<button type="button" class="btn btn-default">Play</button>
という風に、class attributesに複数の独自classを指定して、bootstrap内部のstyleを割り当てています。
Before Components Existed(BCE)まではこうすることが最適解だったこうする他無かったのです。
しかし、今はBCEではありません。僕達にはPolymerがあります。
Material Design with Polymerの場合、クールなボタンを提供するのは極めて簡単です。
<paper-button label="play"></paper-button>
styleはclassでもidでもなく、<paper-button>というタグそのものに割り当てられます。
最大の違いは、<paper-button>がカプセル化されるおかげで、名前空間が汚染されないということです。
Twitter Bootstrapの場合、Bootstrap独自のclassと自前のclassのバッティングに気をつけなければなりませんでしたが、Material Designではそんな心配は不要となりました。
さらに<paper-button>では、独自のraisebuttonというattributesを加えるだけでマウスオーバー時のイベントが変わる、というような機能も提供しています。
Keynoteで"visual language"という言葉が使われたのは、まさにこういった視覚効果までもコンポーネント化したからなのです。
Material Designの発表を受けて、「フラットデザインだ〜」という感想しか持たなかった人は、Web Componentsに関する知識が欠落しているかも知れません。
少なくとも僕にとっては、この発表は衝撃的で、これからのWebUIを支える技術となり得るものだと感じました。
時は来た？いや、ベタ書きしろ
一番初めに紹介したagektmrさんの記事では、twitterのshareボタンのコンポーネントを例に挙げ
<twitter-button></twitter-button>
だけで挿入出来る、と書いてありますが実際には、そんな簡単な話ではありません。
<twitter-button>を作った人も、それを使ってる人達もまだまだプロダクションでガンガン使ってるわけではなさそうなので、わりと初歩的なバグが起きてしまう。
これはPolymerの問題というより、Polymerを実戦投入している人が少ないのが原因です。
もし、このような問題がサービスの根や幹で生じたとしたら、解決するべき重要なバグに出くわしたと言えるでしょう。
しかし、たかがTwitterのボタンなのです。こんなことのために時間を割く必要がどこにあるんでしょうか。
<twitter-button> を捨て、 <a> をベタ書きするようにしたとしても
<a href="https://twitter.com/share" class="twitter-share-button" data-text="タイトル">Tweet</a>
たった一行、これだけなんです。シェアボタンなんかのためにCustom Elementsを使う必要なんてありません。Polymerなんて窓から放り捨てて今すぐベタ書きするべきです。
頭を空にしたままでも使えそうな<twitter-button>でさえこの有り様なので、より複雑なコンポーネントにはもっと深い闇が待っているに違いありません。
(polymer.dartの闇はもっともっと深そう。ただ、僕はDartのことが好きなので応援しています。動かなくて心が折れたけど、Polymer.dartもまた使ってみたい)
ちなみに、<twitter-button>はiframeをwrapしているだけの単純な構造なので、似たようなCustom Elementsを作るのに時間はかかりません。
多少の工夫を必要とはしましたが、<hatebu-button>も短時間で作ることが出来ました。
しかし、それらを上手く使うのは難しいということは頭の片隅に入れておいてください。
最後に
<youtube><google-signin><google-analytics><gplus-one><facebook-button><twitter-button>(forkして使ってる)<hatebu-button>(自作)<markdown-awesome>(自作)
dev環境のScastsでは、これだけの数のコンポーネントを利用しています。
現在、Material Designの導入作業中なので、ますますScastsはPolymerに支えられることになるでしょう。
「無理してPolymerなんて使う必要がない」「ベタ書きしろ」と言いながら、開発中のサービスで多用しているのは、Polymerがより進化した先、Web Componentsがウェブ標準となった先に、より良い未来が待ってるはずだと愚直に信じているからです。
Web Componentsがウェブ標準になった暁には、シェアボタンのような非公式コンポーネントは公式のそれによって駆逐されることでしょう。
その時、僕が作ったいくつかのコンポーネントの多くはゴミになります。世知辛いですね。
手を動かして、作って、使ってみたからこそ「Polymer最高だから皆も使おうぜ！」なんて口が裂けても言えないのです。
心の底では「まだ早い、もっと他にやるべきことがあるはずだ」と思っていますし、これからもっと酷い地雷を踏むことになるでしょう。
「でも、それでも」と言い続け、僕はWeb Components with Polymerに全力で投資します。
だってWeb Components最高じゃん。
個人開発を支える技術Nightのスライドまとめ
オープニングトークでも話しましたが、第一回だけで終わらせる気はないので第二回以降の開催場所を提供して下さる方や、参加したい方は @nekova_ までメッセージを頂けると嬉しいです。
@nekova 個人開発を支える技術 オープニングトーク
@otiai10 個人開発と徳
@KAZZONE Animetick on さくら VPS
@deeeki フィリピンでつくったもの
@9m ツイセーブを支える技術 ほか
@soramugi 同棲生活における個人開発時の問題
@kyo_ago 話すことと作ること
@k2nr_ DokkaaでドッカドッカDocker
@mizchi 骸骨駆動設計
@Linda_pp 草を生やす技術
@azu_re Githubで書く電子書籍
@h_demon
@kjirou エタらないための技術力
はてブのタグ、 <hatebu-button>を作りました
はてなブックマークに追加するボタンのWebComponentWrapper
<hatebu-button>が存在しない世界
<a href="http://b.hatena.ne.jp/entry/"
class="hatena-bookmark-button" data-hatena-bookmark-layout="standard-balloon"
data-hatena-bookmark-lang="ja" title="このエントリーをはてなブックマークに追加">
<img src="http://b.st-hatena.com/images/entry-button/button-only@2x.png"
alt="このエントリーをはてなブックマークに追加" width="20" height="20" style="border: none;" />
</a>
<script type="text/javascript" src="http://b.st-hatena.com/js/bookmark_button.js"
charset="utf-8" async="async"></script>
<hatebu-button>が存在する世界
<hatebu-button></hatebu-button>
見通しが良いし、再利用出来ます。（今回はともかく、一般的にはメンテナンス性が高くなります）
Web Componentsしか存在しない世界
<awesome-navbar></awesome-navbar> <article-title></article-title> <article-body></article-body> <google-adsense><google-adsense> <share-button></share-button> <article-comment></article-comment> <pagination-button></pagination-button> <side-bar></side-bar> <awesome-footer></awesome-footer>
こういう未来もあるかもしれません:p
ちなみに、 Twitter, Facebook, Google+ のcustom elementsは既に存在しています。 個人的に気に入ってるのはGIFを簡単に扱えるクールなコンポーネント
他にどんなものがあるか気になる方は、Custom Elements.IOを見ると良いかもしれません。
さきのような未来が現実になるかどうかはさて置き、便利なライブラリを使うのと同じように、便利なコンポーネントを使う時が来るかも知れません。
お祈りされたのでwebサービスを作りました
スクリーンキャストのプラットフォームです。
https://scasts.herokuapp.com/welcome
コンセプト
オンライン動画学習は2012年に過渡期を迎え、今日では動画での学習が一般的な学習方法の一つとして受け入れられました。
動画はテキストよりもリッチな表現が可能であり、記憶にも定着しやすいコンテンツなので、リベラルアーツの学習方法として動画が好まれることに、何ら不思議はありません。
しかし、受動的なオンライン動画学習こそが最良の学習方法なのでしょうか？
この疑問に対する、僕なりの答えとしてscastsを作りました。
ここで提供したいのは相互学習の場です。
つまり、提供された動画を受動的に観て勉強するだけでなく、動画を通して他人に教えることで理解をより深めるという学習を提供するためのプラットフォームです。
サービスを作るきっかけ
4月18日に、某I社からお祈りメールが届きました。
初めての就職活動だったのですが不思議とやりきれない気持ちはありませんでした。
それだけ箸にも棒にもかからない内容だったということだと思いますし、結果には自分でも納得しています。
(お忙しい中、お時間を頂きありがとうございました.......)
このまま矢継ぎ早に就職活動をしても意味がないと思ったので、祈られた理由を自分なりにリストアップして、当面の間はそれらを改善することにしました。
その中で一番が難しそうだと感じたのは「中規模以上のサービスを作ること」*1だったので、半ばヤケになって作り始めました。
2014-04-18 21:22 nekova I Initial commit
2014-04-18 21:22 nekova o rails new scasts
お祈りメールから6時間後のことでした。
個人開発
個人でのwebサービス開発では、モチベーションの維持が大変難しいです。
「"作りたい"と心の中で思ったなら、その時既に作り終わっている」くらいのスピード感が無ければ、ダラダラダラダラと開発をすることになります。
事実、scastsの幹や根と呼べる機能の実装は4月中には完成しており、それ以降は枝葉の装飾に追われてしまい今日に至ります。
機能は最小限に、と頭では分かっているつもりでも、今振り返れば枝葉に時間を使い過ぎていたように思います。
webサービスの良いところは、完成しないところです。常に変化をし続けるので、全てのサービスは過程であるとも言えます。
つまり、webサービスは、特定の区切りをある種の「完成」と見なしているだけなのです。
完璧主義者が陥りがちな、この沼の存在に気付けるかどうかが、個人開発のリリースにおいて重要だと思いました。
ちなみに、僕は昨晩とある方に指摘されるまで沼の存在に気づけませんでした。
今日リリースすることが出来たのはおしりを叩いてくれた彼のおかげです。
2,3時間ほど話に付き合ってもらえたおかげで、ようやくリリースできましたし、僕自身も前を向けたと思います。
ありがとうございました。
今後
当初の目的である「中規模以上のサービスを作る」にはまだまだ届きませんが、「"実装したい”と心の中で思ったなら、その時既にデプロイは終わっている」くらいのスピード感で開発しながらサービスを育んでいきたいです。
動画コンテンツを少しずつ増やしながら、先日紹介して頂いたいくつかの会社を検討しつつ就職活動再開となりそうです。
「自分のサービスで飯が食えるなら就職する理由なんてない」という考えを持ってはいますが、技術力不足を解消するためにどこかの会社にお世話になって武者修行をしたいと考えています。
武者修行先のご提案をしてくださる方はご連絡いただければ幸いです。
こちらからは以上です。
View無しでModelとControllerをgenerateしたい
いわゆる、viewなしscaffoldをしたい時は
$ rails g resource user name:string
とすればViewは生成されず、ModelとControllerのみが生成されます。
ちなみに、scaffoldと同じように
--no-helper --no-assets
というオプションを付ければ、cssやcoffeeも生成されなくなります。
