REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい

ソフトウェアエンジニアとして新しく技術やフレームワークを身につけようした時に、今まで自分が使ってきたいくつかの方法について整理してみます。なんとなく。 方法1: ドキュメント読む + 写経 公式ドキュメントやWeb上の記事、書籍を読みつつ、そこに書いてあるサンプルやチュートリアルに沿って、自分でも手を動かしながら(写経)、新しいことを学んでいくパターン。 自分で手を動かして新しい技術に取り組むのはすごく楽しいことです。達成感もあります。また、体を使って学習するので、学んだことが身につきやすく、理解も深くなります。 一方で、他の方法と比べて、一つの技術を身につけるのに長い時間がかかってしまいます。技術を身につける目的にもよりますが、技術の移変わりが激しい昨今、ひとつの技術の習得にあまり時間かけたくないのは事実です。 方法2: ドキュメント読むだけ サンプルやチュートリアルに沿って手を動かすこ

※仕様の細かいツッコミはご勘弁を…。 オブジェクト指向で解く みんな大好きオブジェクト指向では、物単位で考えます。言わずもがなですね。やり方はいろいろあると思いますが、まずお弁当という単位で集めると 唐揚げお弁当クラス 状態 主食名 唐揚げ個数 値段 … 振る舞い： つまみ食い() 値段取得() 唐揚げ個数取得() … のような感じで、弁当に必要な要素と必用な処理をひとまとまりにして扱うというのがオブジェクト指向です。 お弁当スーパークラスを作って継承で唐揚げ弁当クラスを、というように拡張を考えた設計にするというのも汎用性が必要な場合は良いと思います。 では早速コードにしてみましょう。 言語はJavaScriptにしています。 (function(){ window.onload=function(){ ////////////////// // クラスの定義 // ///////////

この記事は Math Advent Calendar 2015 の 14 日目の記事です。 他のブログが本格的な数学のお話を記事にしている中、僕はというとそんなに高度な数学の話ができるわけではないので、自身の数学との関わり方や、また今年に入って開催してきた プログラマのための数学勉強会@福岡 の振り返りとその今後についてを書いていきます。同じような境遇の人が少しでもこっち側の世界に足を踏み入れれるようになることを願って。 プログラマから見た数学の楽しさ アルゴリズムやディープラーニング、ビッグデータ、WebGL など、よく聞くいわば流行りのワードについて、そういうものを使った技術やサービスを見つけた時「実際、中身はどういう風に動いているんだろう？」という好奇心はプログラマであれば潜在的には誰でも持っているのではないでしょうか。それは私達プログラマが、普通の人よりもより身近に普段からそういう

$k$は定数で、だいたい0.04~0.06くらいです。Rの値によって以下のように分類できます。 Rが大きい: corner Rが小さい: flat R < 0: edge 図にすると、以下のようになります。 CSE/EE486 Computer Vision I, Lecture 06, Corner Detection, p22 これで手早くcornerを検出できるようになりました。ここで、corner検出についてまとめておきます。 cornerは複数のedgeが集まる箇所と定義できる 変化量をまとめた行列の固有ベクトルからedgeの向き、固有値の大きさから変化量の大きさ(edgeらしさ)がわかる 2つの固有値の値を基に、edge、corner、flatを判定できる 固有値の計算は手間であるため、判定式を利用し計算を簡略化する なお、Harrisはedgeの向きである固有ベクトルを考慮す

(訳注:2016/3/3、頂いたフィードバックをもとに記事を修正いたしました。) オープンソースプロジェクトでバグを見つけたとします。まずは、慌てずに落ち着きましょう。これは実によくあることです。ソフトウェアは人間の手で書かれるし、人間はミスを犯すものです。 または、こんなふうに考えるかもしれません。「やったね、バグの修正は大好きだ」。さっと現れて、何百万人とまではいかなくても、何千人もが使っているプロジェクトのバグを修正してしまうようなヒーローになりたくない人なんていますか？　オープンソースコミュニティに恩返しできたという温かな喜びを感じられる上に、一連の Github 履歴 ^(1) に追加得点を上げられるわけです。 *訳： 人気のあるプロジェクト 典型的なバグ しかしコーディングの初心者にとっては、オープンソースプロジェクトにコントリビュートするなんて恐れ多いことに思えます。私の友人

ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な（陳腐と言ってもいい）3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1：習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Qiita などの技術系の記事を読んでて「あ，ココちょっと残念」と思うポイントを書いてみます。自らの反省も込めて。 日本語表現・表記 「値を返却する」という表現 関数やメソッドが値を return することを日本語で「返却する」と表現した記事がたくさんありますが，ものすごい違和感を覚えます。 「値を返す」と書くべきでしょう。 この件は以前書きましたので理由はそちらを見てください。 「値を返却する」って言うな 「可変する」という言葉 「可変する」というおかしな言葉もよく目にします。 「可変」というのは，読んで字のごとく「変わりうる」とか「

注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS!　：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

結論を先にまとめると、以下の３つです。 1. グローバル変数の宣言をなるべく減らしたい場合 2. ユーザが引数を与えてカスタマイズ可能な自由度の高い「関数」を生成したい場合 3. 前回、呼び出されて実行されたときの演算結果（値）を内部で保存して、次に呼び出されたときに、前回の結果（値）に対して、さらに同じ処理（演算）を行う関数を生成したい場合 以下、「クロージャ」の定義から、頭の整理まで、分かりやすい参考ウェブサイトへのリンクを張りつつ、見ていきます。 【 定義 】クロージャ takeharuさん Qiita記事（2013/07/22）「JavaScriptでクロージャ入門」 「自分を囲むスコープにある変数を参照できる関数」 Wikipedia 「クロージャ」 引数以外の変数を実行時の環境ではなく、自身が定義された環境（静的スコープ）において解決することを特徴とする。関数とそれを評価する環

こんにちは！デザイナーのきよえし(@kiyoe_furuichi)です。 この度10月でConnehito.incに入社して半年が経ちました！めでたい！ ほとんどJSが書けなかった私も今ではフロントもごにょごにょするデザイナーになりました。 良いタイミングなので今回のエントリーは、半年の間に学んだことの共有として、 デザイナーもできる、チーム開発で大切な「おもてなし」についてご紹介したいと思います。 チーム開発における「７つのおもてなし」 0. どうして「おもてなし？」 入社した当時を振り返った時、自分の開発過程やメンバーとのやりとりを見ていかに早く自分のタスクをこなせるかを優先した"オレオレ"デザイナー だったことに気づかされました。その衝撃をきっかけに、"チームとしてサービスを作り上げる"にはどうすれば良いのかを意識して考えるようになったんです。 それから、チーム開発で大切なことはメン

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 ま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

機械学習のモデルを構築した際、データサイエンティストとしての私たちの最終的なゴールは価値の創造でした。モデルが無かった(あっても今より原始的だった)頃よりも、何かしら良いものを生み出すためにモデルによる予測を活用したいのです。結果に焦点を当てるということはつまり、私たちのモデルのパフォーマンスの最終的な評価は、その有効性によって為されるということです。それは、モデルを利用したアプリケーションが生み出した価値の量として計測されます。この投稿では、ビジネスの価値を最大限にするモデル構築による意思決定を、選択したり理解したりする際の強力なツールとして、データの可視化を活用したいと思います。 分類アルゴリズムにおいて、最も一般的な利用パターンの1つが 閾値（しきいち） です。閾値以上のスコアを持つ全てのケースに対して、何らかの特別な処置を行うのです。以下に例を挙げます。 不正の防止： あなたはソー

こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu

(注：2015/11/18、記事およびタイトルを一部修正いたしました。) CNN.com で働いていた2012年6月に、大統領選挙投票日の夜のユーザエクスペリエンス（以後UX）のデザインを任されました。私はそれからの6カ月間を投票日の夜のための仕事に専念しました。しかし、仕事が成功するかしないかは、選挙結果に関係はありませんでした。私が懸念していたのは、情報の見つけやすさやデータの見やすさ、canvasでのオブジェクトの変形、そして一体どのようにしたら、iPhoneでマウスオーバーのフライアウトが動作するのかでした。CNN.com史上初めてWebデザインをレスポンシブにすることにしたのです。さらに史上初めて私が、その デザイン を担当することになったのです。 大きな賭けでした。CNN.comにとって大統領選挙投票日の夜と言えば、スーパーボウル（プロアメリカンフットボールの優勝決定戦）の日曜

俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。 俺が現職に転職してきて一番びっくりしたのはなんといって

(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳：　プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest