IntellJ IDEAが起動しなくなった時にすべきたった一つのこと

タイトルは釣り。 最近IntelliJ IDEAがスプラッシュ画面で進捗率80％くらいで応答しなくなることが多くなった。 キャッシュクリアで直るかと思って下記ディレクトリを削除して起動してみた ~/Library/Caches/IntelliJIdea12 ちゃんと起動するようになった。 コードの補完が遅くなった時とかも有効そう。 ただ、ちゃんと起動してる場合は `File -> Invalidate Caches` の方が安全だと思います。

Gmailのマルチ受信トレイを使う際につまづいたこと

この前、こちらの[Gmail(に限らず)受信トレイはキレイにしよう](http://d.hatena.ne.jp/syonbori_tech/20100922/1285138602)という記事を読み、Gmailの受信トレイをキレイにしようと思い立ちました。 前々から整理したい整理したいと思っていたのでいい機会でした。 タグ付けしてないメールがたくさんあって躊躇していたのですが、頻繁に来るメールは次回来た時に自動振り分け設定すればいい、と割りきってまずは受信トレイを空にしてみました。 そこから先は上で紹介した記事に書かれている通り、マルチ受信トレイで受信トレイとPendingタグ、未読メールを表示する設定にしてます。 ただ、マルチ受信トレイを設定する際に1つだけ詰まったので共有。 それは、設定の「受信トレイタブ」で、「受信トレイの種類」を「クラシック」にする必要があるということです。 ここを優先トレイや未読メールを先頭、というような「クラシック」以外の設定にしていると、マルチ受信トレイが有効になりません。ご注意を。

ブログのTwitterタイムラインウィジェットをAPI 1.1に対応させる

2013年3月に、TwitterはAPI 1.1に移行する。 それに伴い、ブログ等に設置するウィジェットも[新しいものに変える必要がある](http://blog.jp.twitter.com/2013/02/join-conversation.html)。 リンク先にも書いてあるけど、一応メモ程度に手順書いとく。 1. Twitterの[ホーム](http://twitter.com)から、[設定画面](http://twitter.com/settings)にいく。 2. 左側の設定一覧から[ウィジェット](https://twitter.com/settings/widgets)を選択する。 3. 新規作成ボタンを押し、ウィジェットの設定画面でお好みの設定をする。 - ドメイン名は自分のブログサービスのものを指定(Bloggerなら`blogspot.jp`) 4. 「ウィジェットを作成」ボタンを押す。 5. ウィジェットのプレビューエリア下部に表示されるコードをブログにコピペする - Bloggerなら設定→レイアウトから「ガジェットを追加」で基本の「HTML/JavaScript」を選択してコードをコピペ、任意の場所に貼り付ける。 以上こんな感じ。 前作った時よりも手続きが簡単になってたような気がする

Frontrend vol.4に参加してきた

[Frontrend vol.4](http://atnd.org/events/35720)に参加したのでメモをまとめてみる。 #JavaScript Development Tools ##JavaScript開発の効率アップ ## GUI tools - Chrome Developer Tool - Shortcutを覚えると便利 - 複数の方法でデバッグできる - ブレークポイントはれる。ステップ実行も。 - DOMの属性が変更になった時、 - Error発生時、 - 特定のイベントが発生した時等にもブレークできる - Timeline - Chromeでどのようにイベントが起きているか、いつ描画されているか、等が時系列でわかる - Profile - 重い処理とか調べられる - Chrome url - 様々な情報が閲覧できる - chrome://net-internals、その他いろいろ… - Charles - デバッグ用のProxyサーバをローカルでたてられる - MapLocal - 指定したファイルをローカルのものと置き換えられる - Throttle - 3G回線等の速度のシミュレーションができる - [DocHub](http://dochub.io/#css) - JavaScript, CSS等のAPIのリファレンスサイト - [JSFIDDLE](http://jsfiddle.net/) - オンラインでjsやhtmlを書いてテストできる - jsdo.it等の類似サイトと違い、公開する必要がない - mobileブラウザでもデバッグできる - [jsPerf](http://jsperf.com/) - jsのパフォーマンスを調べるテストをのせられるサイト - 他の人が実行すると、それが蓄積されていく - 他人のテストを改善して公開することもできる - [browserling](http://browserling.com) - 指定したブラウザをエミュレートしてサイトを表示してくれる - 有料サービス。制限ありの無料版もあり ##CUI tools - [JSHint](http://www.jshint.com/) - jsではやってはいけないことを指摘してくれる - サイト版、node.js製のCUIアプリがある - 最近のjsエディタはjshintが組み込まれていることも多い - .jshintrcで警告レベル等設定できる - [./jq](http://stedolan.github.com/jq/) - JSONプロセッサ - JSONの出力結果をクエリで操作 - 最新版は1.2だけど、homebrewだと1.1 - Doctor JS - jsのtagファイルを生成 - Yeoman - Webアプリケーション作成支援ライブラリ - Googleの中の人達で開発(Google製ではない) ##Conclusion - 最近のJavaScript開発には便利なツールがたくさんある - 「不便だな」と思ったらツールを探してみるサイクルを作ると幸せになれる - CUIだからと食わず嫌いしないほうがいいよ！ --- #jQuery Performance Tips - 早くするには、マシンの仕事を少なくしろ - パフォーマンスチューニング == 限りなくネイティブなJavaScriptに近づけていく - ファイルサイズをへらす - jQueryは次第に大きくなっている - 1kbにつき1msのパース時間(モバイルデバイス) - IEのバージョンによって1.9と2.0を使い分ける - gruntを使ったカスタムビルドツールが提供されているので、最初は最小構成で開発していくといいのでは。 - セレクタのチューニング - $('#id') < $('tag') < $('.class') < $('e:first-child') < $('その他の拡張') の順で早い ``` $('#target p') //querySelectorAll() -> $('#target').find('p') //getElementById() + getElementsByTagName() $('#target').find('p:first') -> $('#target').find('p:first-child') //getElementById() + querySelectorAll() -> $('#target').find('p').first() ``` - キャッシュの活用も忘れずに - リフローの影響を考える - DOMツリーはマークアップと一対一 - レンダーツリーは視覚要素だけ(headとか、display:noneとかは入らない) - リフローが起きるプロパティの変更はなるべく避ける - border-radiusとかtext-shadowとかはリペイントだけだけどコスト高い… - WebKitではリフローはlayoutと表される - リフローが発生しうるトリガー - CSSの変更、取得 - css(), addClass()... - DOM要素の操作 - html()とか？ - 特定のプロパティの取得 - offset()とか - ユーザの操作 - windowサイズの変更とか - 描画する前にプロパティを変更する - 描画の領域を明示しておく - imgは出来る限りwidthとheightを指定する - `</body>`の手前に`<script>`タグを書くと… - scriptタグをhead内に記述する - しかしそれでは全体的に遅くなってしまう - スタイル要素は全てcssファイルに - requireJS等の非同期ローダー - scriptタグのasync属性を指定した上でheadタグ - スタイルの変更はできるだけ末端要素で - アニメーションはposition: absolute, fixedで - テーブルレイアウトは使わない - ボトルネックになりやすい処理 - アニメーションとか色々 - ボトルネックを見つけたい時はchromeのcanaryが便利 - css3のアニメーション使えるところは使う - requestAnimationFrame - throttle/debounce #Conclusion ## "小さな効率は忘れよう ## 時間の97%について語ろう。 ## 早まった最適化は諸悪の根源だ" - TONY HOARE? --- #Testable JavaScript - そもそもなぜテストする必要があるのか？ - アプリケーション言語として成長してきた - 本物のプログラミング言語になってきた - 本物？ - 今動いているのだからそれでいい、はもはや現実的ではない - リファクタリングを前提で考える - First draft of everything is shit - Ernest Hemingway - ロジックにもデザインがある - BEST PRACTICES - オブジェクト指向 - デザインパターン - MV*構造 - テスト - TDD（テスト駆動開発） - TESTING IS A TOOL - どう使いこなすかは個人の自由 - うまく使いこなせば様々な作業が楽になる ##テストしやすいコードとは? - テストしづらいコードとは - コードの役割分担が複雑で、コードの役割が密接な関係を持っていると、テストを行うことが難しくなる - テストを書くのが難しい、のではなくてテストを書いているコードに問題がある場合が多い - TDDではテストを最初に書くのでテストしづらいコードにはならない、しかし… - テスト書き慣れてない人には難しい… - そこで… - テスト駆動リファクタリング - テスト駆動開発はデザインプロセス - 「JavaScriptパターン」という本がオススメ - モジュールパターン - テストはDOM操作が多いのでQUNITで - 一つのことだけをするメソッドにする(単一責任の原則) - コード量は増えるが、テストしやすく、リファクタリングしやすいコードになる ##ユニットテストツール - Jasmine - BDD(behavior driven development) - QUnit - jQueryが使っている - DOM周りのテストがしやすい - gruntがデフォルトでサポートしているのもQUnit - 結果表示用のHTMLは自分で用意する必要がある - Mocha - もともとNode.jsで開発するために作られた - AssertionのAPIは自分で選ぶ - PhantomJs - ヘッドレスWebkitブラウザ - コマンドラインで実行するブラウザ - [js testing boilerplates](github.com/studiomohawk/js-testing-boilerplates/wiki) - ここでjsのテストツールについてまとめていく予定 - ユニットテスト設定 - テストの自動化 - 面倒な繰り返しは自動化し、大事なことに時間を割けるようにする - grunt - 設定ツールを[js testing boilerplates](github.com/studiomohawk/js-testing-boilerplates)で公開している - [JavaScript-Koans](https://github.com/liammclennan/JavaScript-Koans) - ユニットテストを使ってJavaScriptについての勉強ができる #Conclusion ## テストを書くこと自体よりも、テストしやすいコードを書くのが大事 ## まずはテストを書いてみよう ## どのツールにも得手不得手があるからとりあえずやってみよう ## 自動化すると幸せになれる ## "Why do we fall, sir? So that we can learn to pick ourselves up." --- #jQuery to backbone - backbone - 構造化の手段を提供してくれるライブラリ - 1500行程度の軽量さといじりやすい柔軟さ(コメント込み) - 国内外を問わず利用が広がっている - 依存するライブラリ - jQuery/Zepto.js(lightweight clone) - Underscore.js/Lodash(more faster) #jQuery(これまで) - DOM APIを隠蔽して、簡潔に記述する(write less, do more) - クロスブラウザ対応の諸問題を解決する - プラグインの充実と、エコシステム形成 #フロントエンド実装の変化 - Webサイト - 静的HTML, CMS利用 - 従来のWebサービス、Webアプリ - サーバサードで画面遷移を設計 - 新し目なWebサービス、Webアプリ - シングルページ、リッチインターフェイス -> フロントエンドの比重が上がる jQueryでは解決できない問題が増えていく -> 構造化された設計が必要 #アーキテクチャ - アーキテクチャと言えば猫も杓子もMVC - 1979年に概念が生まれる(smalltalk) - ただし、今のものとは少し概念が違う #Backbone.jsとは - 厳格で多機能で生産性を担保する強いフレームワークではない - 1500行くらいの軽いコード - View Model Collection Router - Controllerはない - 優しい構造化 - MVCを気にしすぎることはない - Todo MVC - 様々なライブラリやフレームワークで同じTodoアプリをつくることで特性を比較 - Todo MVCにあるだけで30以上 - しかし、ほとんどがMV*ではない - 大きな問題を小さく分割して解決する - モジュラーなJavaScript - デザインパターンやアーキテクチャの価値 - View - 見た目とUIにおける入出力 - DOM要素の処理 - Model - 取り扱うデータのいち単位 - ストレージとの通信、同期 - APIや情報のレコードを表現 - Collection - Modelが集合したリスト - リスト操作…where, filterなど - Modelと同様の通信・同期 - Router - URLによるルーティング - hashchange, pushstate - 遷移処理のnavigate - DEMO - GitHub APIを使ったGistのビューワーアプリ - how 1. とりあえずinitializeに全部突っ込む 2. renderに描画を分離 3. templateを分離 4. eventを分離 5. データをModelに入れてみる - Backboneの構造に従って作っていけば、自然とテストしやすいコードになる - ライブラリの利用強度とパフォーマンス - jQueryにも言えるが、使い方によっては簡単に重くなる - パフォーマンスを考えて慎重に使うことが重要 - ライブラリの努力を無駄にしない！ #アーキテクチャを考えるためのBackbone - 学習手段としてのライブラリ - Backbone has made me a better programmer - フルスタックではないので学習コストは低い - もちろんデフォルトの機能は限られる - 良い習慣のために、*とりあえず*分けてみる - ものはためし - ライブラリの利用が学習につながる - RequireJSも学習に良い感じ - 派生ライブラリ - Marionette - Chaplin - Vertebrae - ぼくのかんがえたさいきょうの… - 車輪の再発明的な… - 複雑性を増しているだけでは？ - 学習目的であればむしろやっていいのでは ##Conclusion #アーキテクチャやデザインパターンは自分で手を動かして覚えていくのが近道 --- こんなかんじで。いろいろ便利なツールの紹介があったので業務でも使っていこうかな。 あと、backbone.jsのソースは読もう。

[JavaScript]任意の数の引数を受け取り処理を行う

JavaScriptの関数は定義されていない引数も受け取ることができる。 全ての引数は`arguments`という配列からアクセスできる。 var doSomething = function(verb, something) { console.log(verb + ' ' + something); } doSomething('write', 'foo'); //...1 //output: write foo doSomething('write', 'foo', 'bar'); //...2 //output: write foo //実際に処理できるのは'write', 'foo'のみだが、'bar'も引数として受け取っている 上記の`doSomething`という関数は、通常は1つめの例のように、引数を一つだけ受け取ることを想定されている。 この関数を、例2のように3つ以上の引数が渡された時、'write foo, bar'と表示できるように改良する。 var doSomething = function() { var verb = arguments[0], somethings = 2 <= arguments.length ? [].slice.call(arguments, 1) : []; console.log(verb + ' ' + somethings.toString()); } doSomething('write', 'foo', 'bar') //output: write foo,bar doSomething('write', 'foo', 'bar', 'hoge') //output: write foo,bar,hoge こんな感じ。 重要なのは、 somethings = 2 >= arguments.length ? [].slice.call(arguments, 1) : []; この部分。 配列`arguments`の長さが2以上の時(つまり2つ目以降の引数が渡されている時)、配列`arguments`の2つめ以降の要素を切り出して`somethings`に詰めている。 この処理によって、`somethings`は2つめ以降の引数が入った配列になっている(2つめ以降の引数がない場合は空の配列)。 あとはこの`somethings`内の各要素に対して処理を加えていけばいい。

GitHub創設者が語るイベントに参加してきた

先日、[GitHub創設者が語る"立ち上げから利用者300万人までの軌跡"](http://github-onlab.peatix.com/)の東京講演に参加してきた。 遅ればせながら公演中のメモをまとめたので一応公開。 公式のレポートは[こちら](http://onlab.jp/blog/archives/2013/02/open-network-lab-gitHub0130.html) 講演者はGitHub COOのPJ Hyett氏。 Q&Aセッションでは、PJ氏に加えてCIOのScott Chacon氏も話していた。 --- #what is github - 一人で作業するよりも複数で作業したほうがいい - たった数人の夢からはじまったプロジェクトが、今では300万人が使うプロダクトになっている #GitHubの始まり - 初めてプログラミングを学んだのは14歳 - 父親が買ってきたPC - はじめはゲームばかりしていたが、もっと役に立つことをしたほうがいい - 高校時代のインターンシップでDitto.comを作成 - phpやasp, 大学ではC++を学び、そのうちRuby(on Rails)に出会い恋に落ちた - Rubyを使った実践的な経験がほしい - ちょうどメーリングリストにWayfaring.comの技術者募集メールが来て、そこで経験を積むために無料で参加した - そして、Wayfaring.comの創業者が、PJの最初の仕事を紹介した - それがCNET NETWORKの仕事 - そこで出会ったクリスが、GitHubの共同創業者である - 彼と一緒にブログ(ERR THE BLOG)を立ち上げ、そこでいろいろ書き始めた - そのうち大企業にいるのがつかれて、ERR FREEというRubyのコンサル会社を立ち上げた - 自由に働けるんだと思いきや、クライアントがボスになるようなもの - そんな仕事の中で、犬のためのSNSを作る仕事があった。(いいクライアントだったが、犬のためのSNSをつくるのはそんなに楽しい仕事ではなかった) #FamSpam - 初めて作った自分たちのサービス - 家族のためのメーリングリストのようなものだったが、お金にならなかった #Ruby meetup - サンフランシスコのRuby関係のミートアップ - このミートアップの開催される飲み屋で、クリスがGitHubの三人目の共同創業者のトムに出会い、GitHubのアイディアが生まれた - トムはデザイナーでもある #GitHub - GitHubが今の形になるまでに様々な過程があったが、最も重要なものは*fork*の機能をつけたこと - 当時は*fork*にネガティブなイメージがあった - 作者がOSSの開発をやめ、他の人が管理を引き継ぐようなかんじ - しかし、PJたちは*fork*を肯定的な意味にしたかった - 改善し、よりよいプロダクトをつくるための*fork* - もともとGitHubはサイドプロジェクトで、三人とも別々の仕事があり隙間時間にやるようなものだった - 自分たちのための開発 -> 他のVCSよりも便利なものがほしい！ - 最初会社を作ったときは*LOGICAL AWSOME*という社名で、GitHubは多数のプロダクトの中の一つになると見込んでいた - しかし、ある日あるユーザーが「お金を払いたい」と言い、これは事業になるんじゃないか、と思った - GitHubの初期の頃のパートナーで重要なものに*Engine Yard*がある(ロゴをフッターに入れればタダでホスティングしてくれる)。この関係もRuby meetupで培われた - 最初GitHubをローンチしたときは登録フォームもなく、メールで問い合わせる形だった - その後登録フォームができた時も、最初は招待コードを入力する必要があった。登録した人は別の10人を招待することができる - この方法は、サービスをバイラルに広めていくには効果的 - GitHubの最初の二年間はオフィスがなく、近場のコーヒーショップや自宅が仕事場だった - オンラインでコミュニケーションをしていた - キャンプファイヤーとGitHub - 自らのプロダクトを実際に使うことにより、改善点が見つかる - 2008/4/8, PUBLIC LAUNCH - 初めてRuby on Railsのプロジェクトがホスティングされた - 特に不具合もなく、友だちと飲んだりしていた - チームビルディングのためにポッドキャストとかしていた - GitDown - いろいろな人を招待してGitHubについて話し合う - お酒も出て、ある意味DrinkUpだった - このDrinkUpを通じて初めての従業員、スコットと知り合った - GitHub創業者の三人よりもGitに詳しい - 毎週Gitを別の言語で書きなおしたりするおかしい奴だった - GitHubをローンチして最初の数ヶ月は報酬のない状態だった - スコットを雇った頃から自分たちにも報酬を払いはじめた - 最初は少ない額から初めて、目標を達成する毎に報酬を上げていった。 - 一年後には、コンサル会社をやっていた頃よりも多くの報酬を得ていて、ローンチした時と同じくらい嬉しかった #Q&A - GitHubは今まで社員を解雇したことがないと聞いたが、雇うまでにどれくらいの時間をかけるのか - 誰もやめないことを特にKPIにしているわけではない。信頼出来る人からの紹介を重視している。あとは面接やコードレビューを通じて技術や人柄を見ている。 - GitHubは採用するときに社員が投票するシステムがある。+1, -1, +100がある。+100は「自分が責任を持つからこの人と仕事がしたい！」という表明 - 60-70%がサンフランシスコではなく、リモートで働いている - 面接時にサンフランシスコに招待してもてなし、よい印象を持ってもらう - リモートで働いている人が多いが、なにか秘訣はあるのか - GitHubはオンラインで会社を立ち上げた。すべてのコミュニケーションは非同期で実行される。 チャットやキャンプファイヤーなどで。サンフランシスコにいる社員でさえ、会社にくることも特に必須ではない。そういうフローをつくることが重要 - GitHubの利用者が増えた要因で最も大きなものはなんだと思うか - おもしろいオープンソースのプロジェクトがGitHubでホスティングされたことがきっかけ。 GitHubはYouTubeのプログラマ版。YouTubeでも面白い動画は拡散される。それと同じ。 - プログラマが働きたくない環境にしないためにどうしているか - OSSの流儀がそのままマネジメント法。好きなときに、好きな場所から働ける。 やることを自分で決められる。 プログラマが課題を定義して、新しい機能はみんなで決める。 - 売上が上がる毎に給料が上がっていた時期はどのように昇給を決めていったのか - 一年後自分の欲しい給料から必要な目標を逆算して、それが達成できたら昇給 - 全世界から不具合報告や要望があると思うが、どう対処しているのか - 特にフローはないが、不具合等はGitHubにサポートチケットをだしてほしい - PJはなぜRubyに惚れたのか - 読みやすい。二年前に書いたものでもすぐ理解できる。 (もしかしたら私がひどいJavaプログラマなだけかもしれないが)Javaではわかりづらかった - スコットはGitを様々な言語でGitを書いたらしいが、なぜRubyがいいのか - ActionScriptやErlang, Pythonで書きなおしてみた。 Gitは非効率な部分がたくさんある。 そのため様々な言語でプラグインを書かなければならなかったりするのがめんどくさい。Rubyはわかりやすかった。 - 日本ではGitHubを使って婚活をした女性が話題になったが、GitHubが想定していなかった使われ方をされた例を何か知っているか - 様々なユーザーが様々な使い方をしている。 ドイツの法律がGitHubにホスティングされていて、みんなでforkして改善を目指している。 他にもISSUESを家事のTODO LISTに使っている人もいる - repositry hostingからsocial codingにキャッチフレーズを変えて意味、きっかけは - GitHub自体が進化している。 repositry hostingよりもcooperaitonにコミットしていっていた。 これがGitHubにとって重要なものだ！　(ロゴの下にうまく収まった、という理由も) --- こんな感じで。 OSSの流儀がそのままワークスタイル、というのは素敵だなあ。 自宅警備員したい。 まあどこから仕事してもいいよ、だと仕事とプライベートの切り分けが難しくなりそうだけど、それは日本固有の問題なのかしらん

ディレクトリを簡単に移動できるz.sh入れてみた

最近、z.shというディレクトリ移動を簡単にできるスクリプトの存在を知ったので入れてみた。 `cd`コマンドの履歴を取ってるみたい。 インストールはhomebrewからサクッとこんな感じで。 brew install z インストールするとターミナルに以下のような文章が表示される For Bash or Zsh, put something like this in your $HOME/.bashrc or $HOME/.zshrc: . `brew --prefix`/etc/profile.d/z.sh ZSH USERS BACKWARD COMPATIBILITY WARNING: z now handles 'precmd' set up for zsh. z (<=1.3) users using zsh should remove the precmd function that was described in the installation instructions for previous versions. In short, this: . /path/to/z.sh function precmd () { _z --add "$(pwd -P)" } should now be: . `brew --prefix`/etc/profile.d/z.sh いろいろ書いてあるけど、ほとんどは1.3以前のz.shを入れていた人むけのメッセージ。 今回はじめてz.shインストールした人がやることは至ってシンプル。 以下の一文を.zshrcに追加するだけ。 . `brew --prefix`/etc/profile.d/z.sh 追加したらシェルを再起動するとzコマンドが使えるようになっている。 `cd`コマンドで何回か移動した後、おもむろに`z <TAB>`と入力すると、移動したディレクトリパスが補完される。 便利！