背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h

#!/usr/bin/swift import Foundation typealias Failure = (NSError!) -> Void typealias ResultBlock = (NSData!, NSError!) -> Void /// JSONObjectWithDataの戻り値として使用する enum JSONObjectWithDataResult { case Success(AnyObject) case Failure(NSError) } /// NSDataをJSONオブジェクトに変換し、JSONオブジェクトまたはエラーのいずれかを返す func JSONObjectWithData(data: NSData) -> JSONObjectWithDataResult { do { let json = try NSJSONSerialization.J

今、個人でmupsというIFTTTみたいなサービスを作っています。 IFTTTは便利なんだけど、あまり国内のサービスには対応しておらず、その点が個人的には不満だった。 その課題を解決すべく、RubyとNode.jsでIFTTTみたいなものをつくってみることにした。 あと、ここ最近ずっとAndroidアプリ開発ばかりだったので、最近のWeb周辺技術を勉強したかったという目的もあった（Rubyをちゃんと触るのは初めてだった）。 システム構成 ↑は理想図です。実際のところアプリなんてできてないし、サーバもさくらVPS一台のみ。 mups-web Nginx + Unicorn + Sinatraで動く普通のRuby製Webアプリケーション。 最初はRailsを使おうかと思ったけど、今までWeb開発はPHPばかりでRuby自体ちゃんと触るのは初めてだったし、それに加えて学習コストが高いと噂のRai

最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育

私がよく使うコマンド集となります。 参考に頂けたら幸いです。 随時更新するかと思います。 コマンドを打つ前に覚えておく事 ①サーバに負荷がかかるコマンドを打つ場合、下記をコマンドの先頭に付けましょう $ ionice -c 2 -n 7 nice -n 19 # -c 2：ディスクI/Oの実行優先度をベストエフォートで実行 # -n 7：さらにこのコマンドの優先度を低くする # -n 19：プロセスの実行優先度を一番低くする

先日、Wantedlyさん、Oisixさんと合同でSwiftの勉強会を 開催させて頂きました。 プレゼンの内容としてはiOS開発0、Swift学習0の状態からapple申請までの開発フローやSwiftの学習方法といった内容になっておりますので、 これから学習される方やチームで開発するにはどういう所を気をつければ良いんだろう？と気になっている方にぜひ、見て頂きたいです！ Apple審査を一発通過！iOS開発経験0でも出来るじげん流Swift開発のすべて 追記(12/5 現在) この度、 Swiftオンリーで開発した「アルバイトEX」アプリをリリースしました! (iOS7、iOS8両方で動きます！) アルバイトEX

原文：http://npf.io/2014/10/why-everyone-hates-go/ 酔っぱらった勢いで訳出してるので、違ってたら修正リクエストください。 訳者の１行でわかるサマリ それって、Goのシンプルな言語哲学が、ML系言語好きのアイデンティティを挑発しちゃってるからじゃないの？ いや、実際みんなって訳じゃないんだろうけど。最近、なんてGoをみんなそんなに批判的なのかって言うquoraの質問が出たもんで。（わるい、普段はquoraへのリンクを張らないんだけど、それがこの記事のきっかけだからね。）この質問への回答を見るまえにもう、僕には、次みたいなことが書かれていることがわかってた： Goは70年代に立ち往生した言語だ Goは40年間に及ぶプログラミング言語研究の成果を無視してる Goはブルーカラーの凡夫のための言語だ Go使いはJava1.0で仕事しても大丈夫なんだろう。

ssh接続 ビルド結果画面にある「&enable SSH」をクリックすると別インスタンスが起動し、ssh接続可能になる。 「ローカルでは動くか、CI上では動かない」などのトラブル調査の際に便利。 circle.ymlで設定可能な項目(抜粋) Configuring CircleCIからの抜粋。 /etc/hostsへの登録 名前解決できないテスト用サーバ等を設定するとよい。

最近新人研修（プログラミング未経験者・大学で専攻など、ごちゃまぜ）に関わることがありました。 適当なタイミングでEclipseのショートカットキーを教えていたのですが、実演してあげると食いつきがよかったです。 ウケがいい≒新人から需要があるといえそうですし 教えるほうも教わるほうもモチベーションを保ちやすいです。 その点で、ウケるかどうかは大切な視点のひとつだと思います。 なので、ウケのよさランキングの形式で、ショートカットを紹介したいと思います。 環境は、WindowsでPleiadesのやつ（http://mergedoc.sourceforge.jp/ ）を使って、Javaを教えていました。 第20位 ctrl + alt + k スネークケースとキャメルケースの切り替え 変数名やメソッド名を選択した状態でctrl + alt + k 教えていたのはJavaなのですが、C言語のように

非デザイナーエンジニア(Rubyist)の私が、一人でこんなWebアプリを作ってみました。 まだβ版ですが、Pocketやfeedlyの未読コンテンツの中から、 重要度が高いものだけをリマインドしてくれるサービス「Reminderr」です。 Reminderr：http://www.reminderr.me/ 要するに、私自身のPocketとかRSSがカオスになっているので、 その中で重要なものだけ教えてほしかったので、 自分で作っちゃえ！って思って作りました。 そのときに使った便利ツールたちをまとめておいたら便利そうだったので、 今回使ったもの＋αを全てまとめてみました。 紹介するツールたちを駆使すれば、 非デザイナー＆デザインセンス0の私が、 1週間程度でこれくらいのアプリをリリースできるので、 他のエンジニアにも便利なツールがいっぱいあると思います。 Bootstrap系 Boots

というわけでつつがなくMacBook Airより高いキョダiPhone128GBを予約するやいなや、YosemiteがDP8に、XCodeが6.1-Beta2になっていたので。 Swiftが1.1に 1.0が出たばかりだというのになんとも気が早いことです。Xcodeも6.1こそ本命ということでしょうね。 Beta6より引き続き… Optional型に関するさらなる改良はずっとやっているみたいです。 Failable Initializer で、1.0と1.1で最も変わったのがこれでしょう。これまでは

いまはもっと賢くなってる。最適化ﾊﾞﾝｻﾞｲ https://medium.com/a-journey-with-go/go-string-conversion-optimization-767b019b75ef 概要 string を byte スライスにしたり，またその逆だったりをおこなうのに， なんてコードをよく書きます．string は読み込み専用のスライスみたいな物だという認識だったので，キャストしても，ポインタがコピーされるだけで，必要になったらコピーされるだろうぐらいに思ってたんですが，調べてみたらメモリがまるっとコピーされるのでパフォーマンスに影響しそうなときは要注意です． 詳細 string を byte スライスにキャストするプログラムを書いて，アセンブリコードを吐かせてみました．

Goでは文字列は不変（immutable）なので、文字列への文字の追加は常に新しい文字列をアロケートすることになる。ランタイムはまず新しい文字列のためのメモリを割り当てて、そこに既存の文字列の内容をコピーし、新しい文字を最後に足すということを行う。 従って、文字列に+=演算子で文字列を追加していく操作は大変効率が悪い。Javaの文字列も同じだからJavaプログラマにとっては馴染みのある話だろうと思う。 文字列を構築する必要がある場合、[]byte型の値を作ってそれに文字列を追加していって、最後に値を文字列に変換するのがよい。 // サイズ0、内部バッファの長さ10の[]byteの値を割り当てる b := make([]byte, 0, 10) // bに文字列を追加 b = append(b, "foo"...) // ...が必要 b = append(b, "bar"...) retu

Objective-Cを使ったiOSアプリ開発では、C言語のプリプロセッサ命令を使って、NSLogを#ifdef DEBUGで囲むデバッグマクロのテクニックがよく利用されていました。 #ifdef DEBUG #define LOG(...) NSLog(__VA_ARGS__) #define LOG_METHOD NSLog(@"%s line %d", __func__, __LINE__) #define LOG_OBJECT(obj) NSLog(@"%s=%@", #obj, obj); #else #define LOG(...) #define LOG_METHOD #define LOG_OBJECT(obj) #endif

ディレクトリツリーからファイル選択 NERDTreeからvimfilerに乗り換えた。 両者はいずれもディレクトリツリーからファイルを開くという意味では一見良くてい似ています。 しかしそのコンセプトは別物で、自分にはvimfilerのコンセプトが合致したので乗り換えました。 簡単にいえばNERDTreeは常にディレクトリツリーを表示して使用するのに対し、 vimfilerはディレクトリツリーを必要に応じすべてのウィンドウで表示可能な点が異なります。 説明が下手すぎるので、詳細はvimfilerのヘルプにもリンクしてある以下を参照して下さい。 わかりやすい。 http://vimcasts.org/blog/2013/01/oil-and-vinegar-split-windows-and-project-drawer/ なおNERDTree的な使い方も必要な場合は:VimFilerExpl

WebアプリケーションのHTTPレベルでの振る舞いに対してテストを記述するとき、皆さんはどのような考えを持ってテストコードを記述しているでしょうか。この投稿では、この手のrequest-specと呼ばれるテストについて考えながら、テストを書くときの幾つかの方針と、RSpec::RequestDescriberを利用してテストコードを簡略化する方法を紹介します。 request-specとは request-specという、HTTPにおけるリクエストとレスポンスの組み合わせを、言わばブラックボックスとして扱うテスト形式の呼び名があります。リクエストを入力、レスポンスを出力として扱い、ある入力に対して期待される出力が返されるかどうかをテストします。rspec-railsの中では、request-specに対して以下の説明が与えられています。 Use request specs to speci

この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します

個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい！ prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 （以下正確ではないですが簡単に） Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた

はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に