ソースとかisoイメージとかを、急いでダウンロードしなければならない場合は、wgetやcurlではなくaxelを使うと分割ダウンロードができるのでとてつもなく便利になる、ので皆使うべき。 ※7/1追記：皆使うべき、というのは語弊がありました。必要に応じて急いでいる人は世界に謝りながら使うべきですね。 インストール Mac OSX Macの場合は超簡単。brewで一発で入る。

Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備：diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s

前置き ちょっと前からLamveryというAWS Lambdaのデプロイや管理を簡単にするツール（OSS）を作っていて、Qiitaでも紹介させてもらったりしていたのですが、結構便利に使えるようになってきてはいるものの、最近出てきたApexの注目度 1 が非常に高くて嫉妬したので比較記事を書いてみることにしました。 Lamveryの説明についてはこちらをご確認ください。 http://qiita.com/marcy-terui/items/1617ab4e20e3339d1930 https://github.com/marcy-terui/lamvery/blob/master/README.md Apexはwikiを見るとなんとなく雰囲気がつかめるかと思います。 https://github.com/apex/apex/wiki 一方が自作なので、できるだけ公平を期したいとは思っています

注意 本件記事ですが、私の不適切な行動（拾ったスクリプトを検証なく走らせる）が原因です。「dockerは（特に何もしなくとも）危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 本件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ

この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実

実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向

前提 環境はMac。boot2dockerが入っているものとする 手順 IntelliJにDockerプラグインを入れる DockerHost等の設定 Run/Debug Configurationにてコンテナの起動設定 Dockerfile書いてアプリケーションを起動 1. IntelliJにプラグインいれる 2. DockerHost等の設定 設定画面からCloudsを開き、Dockerを選択して新規設定を作成。boot2dockerのホストのIPアドレスと証明書を埋める。 3. Run/Debug Configurationにてコンテナの起動設定 あとは起動設定。新規にDocker Deploymentを作成する。Serverには先ほど作成したDockerHostの設定を選択する。 Container Settingsで指定した場所に下記のような設定ファイルが作成されるので、任意の場

はじめに Livesense Advent Calendar 2015(その2) 、13日目を担当します、ktmgです。 ふだんはSEOなどやっております。 さて、Advent Calendar 2015。 「なんかエンジニアさんたちが楽しそうなことやってるなー」とハタから眺めていたのが昨年。 今年は職種不問にしたからなんか書け、という @masahixixi さんの指令を受け、はじめて投稿させていただきました。 本記事では「非エンジニアでもできる簡単スクレイピング 」というテーマにからめて、 Google SpreadSheetの便利な関数：9 Chromeの便利な機能：1（Copy XPath） をご紹介します。 素材・完成形 http://qiita.com/advent-calendar/2014/livesense 昨年の Advent Calendar を素材に、投稿記事一覧の

はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo

この記事について 軽い気持ちで触りはじめたKibanaですが、 Kibanaについて日本語解説も少なく、設定で困った事があったのでまとめておきます。 この記事はKibanaのよく使う設定方法にのみ焦点をあてて説明します。 Elasticsearchのセットアップ方法には触れません。 また、使用したkibanaのバージョンは3.1.0です。 Kibanaとは 一言で言えばElasticsearchの検索結果をグラフ表示するツールです。 抑えておくべき事は以下の3点です。 ダッシュボードの作成方法 パネル(グラフ)の作成方法 クエリ・フィルタの作成方法 ダッシュボードの作成方法 http://${Kibanaのあるサーバ}/index.html#/dashboard/file/blank.jsonでアクセスします。 または、トップページのダッシュボードの下の方に「Blank DashBoard

これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

Rails API rails/railsのPull RequestにRails apiというものがありました． rails-apiの要素をRalis本体に取り込んだものになるようです． いまのところ，RailsでAPIサーバ作るための超絶スーパーかっこいい便利機能が追加されるというよりは，既存のRailsだとAPIサーバ用途にはデカすぎるのでいいカンジにコンパクトにしていくという方向性っぽいです． 以下，Pull Request内のコミットから気になったやつを適当にピックアップしてみます． （本記事は2015/4/29 日本時間午前9時時点での情報です．今後，開発が進むことで情報が古くなることが予想されます．） Add ActionController API functionality · spastorino/rails@a8559ef ActionController::Apiとい

【追記 2016/06/21】 Docker for Macがリリースされました。これでVirtualBoxを使う必要はなくなったので、この記事にあるdinghyを導入する必要はありません。 OSXでDockerを使うときには、VirtualBox + Docker Machineを使う事が多いと思います。しかし、VirtualBoxの共有フォルダ機能は凄く遅いため、その上で動くDockerも共有Volumesを使うと遅くなるという問題があります。 Vagrantの場合には、NFSマウントを使う事で早くすることができますが、Docker Machineにはその機能がありません。 そこで、OSXのDocker MachineのVolumes機能をNFSに入れ替えてくれるdinghyを試してみました。 codekitchen/dinghy: faster, friendlier Docker

fig/docker-compose初心者なので、環境構築、超簡単なdocker-compose.yml、docker-compose xxのコマンドライン辺りを半年後の自分用にチラシの裏しておきます。なお、figはdockerへ統合された事に伴い、docker-composeと名前が変わっています。ここでは(タイトルを除いて)docker-composeで統一します。 docker-compose環境をEC2にsetupする Amazon EC2 + Ubuntu14.04でのsetup手順です(docker-composeの最新verのinstallコマンドは随時ここを参照してください。以下は(現時点の最新の)Ver1.3.3の場合のCommandになります まずはDocker (>v1.3)をいれる #apt-get update #wget -qO- https://get.doc

はじめに このエントリーは ソフトウェアテストあどべんとかれんだー 2014 の9日目のエントリーです。 前日は@urasandesuさんの 『非公開メソッドの入れ替え - from "Prig: Open Source Alternative to Microsoft Fakes" Wiki -』でした。記事内の「迂廻路生成？と思われるかも」という言葉通り私も最初は？となりましたが、読み進めて行くとなるほど納得、以前レガシーコードと格闘していた私にはとても参考になるエントリーでした！ そして初めましての方は初めまして！ @PoohSunnyと言います。TDD、スクラム、ソフトウェアテスト、G*、AngularJSあたりに興味があります。現在はカエルのマークの人事管理Saas作りに奮闘中です。 今日はGebというツールについて書きます。 前置き：Geb紹介 Gebとは プログラミング言語G

追記：openssh-7.3 以降なら ProxyJump や -J が使えます ホスト名を + で繋げることで多段Proxy接続も簡単に、がコンセプトだった本エントリの設定ですが、OpenSSH 7.3 から ProxyJump という設定が使えるようになったので、使えるなら ProxyJump を使う方が健全だし柔軟で使い勝手も良いのでそちらを覚えて帰ることをオススメします。 使い方は簡単で以下のような感じです。多段も行けるし、踏み台ホスト毎にユーザ名やポート番号を変えることも出来ます。 # 1. bastion.example.jp -> internal.example.jp ssh -J bastion.example.jp internal.example.jp # 2. bastion.example.jp -> internal.example.jp -> super-de

tl;dr よく使われるコマンドの一つに cd コマンドがあります。ターミナル生活の 80% 近くは cd と ls である、という英文記事を何処かで見かけました。それを効率化しようという Tips です。 目的 cd はよく使われるのに使い勝手が悪いコマンドである気がしてなりません。cd コマンドは有効なパス（相対パス、絶対パスは問わず）しか解釈してくれないからです。つまり、存在していて尚且つパスが解決できるものに限るのです。例えば、ホームディレクトリにいるときに、/home/lisa/work/dir に行こうとして cd dir とだけタイプしても no such file or directory （そんなディレクトリは見当たらないよ！）と言われてしまいます。きちんとした経路でなければならないのです。いちいちパスを覚えていない場合や、部分的にしか思い出せない場合には結構面倒ですよね

はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール

WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている（検査例外のような形） try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ