エンジニアがスキルアップするための勉強を業務時間外でもするべきかどうかについて、「教育してエンジニアを育てるのは企業側の責任だ」「エンジニアであればスキルアップのために当然自分で勉強すべきだ」といったような議論を度々見かけます。 この問題についてはどちらが正解というわけでもないかもしれませんし、企業やエンジニアのポリシーによるところも大きいかもしれません。 いずれにしても今後うちの会社の求人に応募してきてくれる方に向けて、企業として、または会社トップとしての私の考えを明確にしておくことはやっておいた方が良いなと思いましたので、この記事に私の考えをまとめてみたいと思います。 プライベートで勉強しなくても何とかなります 仕事をこなしていくという観点から言えばプライベートでの勉強を一切やらなくても何とかなります。たとえ未経験で入社してきた人であってもそれくらいの教育は行っています。 でも最初にこ

なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ

はじめに この記事は Building Data Pipelines with Python and Luigi の和訳です。 元記事がよくできていたので、自分の理解も兼ねて、拙いながらも訳してみました。 誤り等ありましたらぜひコメントでご指摘おねがいいたします。 データサイエンティストにとって、日々の業務はエンジニアリングというよりも研究開発の色が濃いことがしばしばある。にもかかわらず、プロトタイプから製品までのプロセスには、素早く泥臭い決定が次善の策1であり、けっこうな数のリエンジニアリングの努力が必要となる。これはいつも革新を遅らせ、一般的に言えば、プロジェクト全体を遅らせる。 この記事はデータパイプライン構築の経験について議論する：データの抽出、洗浄、結合、前処理などデータ駆動製品のためのデータを準備するのに必要となる一般的なすべてのステップである。特に焦点を当てるのはデータの配管

OSS-DB 技術者認定試験の勉強で PostgreSQL を Mac のローカルにインストールすることにしたのでその方法をメモっとく。 大したこと書いてないんだけど brew services というので起動できるということを知ったので記事にした。 PostgreSQL を Homebrew でインストールする Homebrew を最新にしてから PostgreSQL をインストールする。

統計学、パターン認識等で、ROC(Receiver Operating Characteristic；受信者動作特性)曲線という概念が出てきます。また、データ分析・予測のコンペティションサイトKaggleでも、提出されたアルゴリズムの識別性能評価にこのROC曲線に基づくAUC(Area Under the Curve)というものを使っています。（例えばココ） このROC曲線、ちょっとわかりにくいので、まとめてみました。また、アニメーションでグラフを動かしてイメージを付けるということもやってみます。 1. ROC曲線に至る前説 まず、例として健康に関するとある検査数値データがあったとします。 この検査数値は健康な人は平均25, 標準偏差2の正規分布に従い分布しています。（下記図の緑の曲線） 病気の人は平均30、標準偏差4の正規分布に従い分布しています。（下記の図の青の曲線） グラフにすると下

イントロ baseplot を始めとしたパッケージで相関図のための散布図（scatter plot）を描こうと思えば、便利なlibraryが幾つかあります。 下記に代表的な例を示します。 GGally(ggpairs)やPerformanceAnalytics, psychなどです。 美しいペアプロット図を簡単に作る（teramonagiさま） R package for identifying relationships between variables （stats.stackexchange） ですが、沢山の相関図を描きたいときには、図が小さくなってしまいます。 そこで、一枚一枚を描き出すプログラムを書いて見たかったのです。 スクリプトコード 今回、ggplotとfor文，combn関数を用いて次のようはスクリプトコードを書きました。 （データは、irisデータです） #iris

いきなり自分でハードル上げてみました（笑）。ちなみに何故単純パーセプトロンを最初に持ってきたのか？というと、id:echizen_tmさんのブログ記事でも触れておられる通り 機械学習には大きく分けて「識別関数」「識別モデル」「生成モデル」の3つの種類がある。このなかで識別関数は確率を使わないので初心者が入門するのに最適。 識別関数で有名なのはSVM(Support Vector Machine、サポートベクターマシン)。名前を聞いたことがある人も多いと思う。そこで早速SVMを学ぼうとすると敷居が高くて挫折しがち。 実はSVMは(大雑把に言うと)パーセプトロンという基礎的な識別関数に「マージン最大化」と「カーネル関数」という考え方を導入したもの。なので機械学習入門者は最初にパーセプトロンを学ぶのが良いと思われる。 それゆえ、実際に僕も以前Matlabで糞コード書きながら勉強してた時はやはり単

まず、nil?とempty?はrubyのメソッドで、blank?とpresent?はrailsで拡張されたメソッド（つまりrubyでは使えない）ってことを覚えておく。 - nilは存在しないという意味。 対して　""は「何も無い」が存在している。空白の存在。

Mechanizeはスクレイピングを行うためのgemです。 gemの追加 gemファイルに下記を追記して、bundle install

本日2016年7月15日、はてなはサービス開始から15年を迎えました。これもひとえに、ユーザーの皆様のおかげです。誠にありがとうございます！今後とも、はてなをどうぞご利用ください！ 今年もTシャツプレゼントキャンペーンを実施します！ 15周年を記念して制作・受注生産した「はてなTシャツ2016」に、非売品グッズの「はてな手ぬぐい」をセットにして10名の方にプレゼントします。応募方法は、この記事をはてなブックマークに追加するだけ。ぜひご参加ください。 はてなブックマークに追加して応募する キャンペーンは終了しました。たくさんのご応募、ありがとうございました。 キャンペーン概要 応募期間 2016年7月15日（金）～7月22日（金）AM11:00 キャンペーンは終了しました。たくさんのご応募、ありがとうございました。 賞品・当選者数 はてなTシャツ2016＋はてな手ぬぐいセット × 10名様

追記1: コメントでの指摘を受け、gvmに関する記述を削除 この記事は、日経ソフトウェア 2013年 06月号 04/24発売 のステマ記事です。 6月号に、@keiji_ariyama(前座部分担当) と 僕(Gradle概要担当) と @sys1yagi(Android対応部分担当) という分担でGradle入門的な記事を書きました。 ですが、僕の目的としてはトップゲート社員への布教を主目的と考えて書いたため、本来要求されている分量を(わざと)大幅にオーバーして書いていました。雑誌に掲載されなかった溢れ分をネットで公開して良いか打診した所、「全文掲載でも良いですよ」という豪気なお許しを頂いたのでここに公開します。この場を借りてお礼申し上げます。 プロの編集さんの手を経て、だいぶわかりやすく噛み砕かれたものが雑誌のほうには掲載されていますので、ここに書いてある内容が難しいなぁ…と思ったら

KaggleのチュートリアルにもなっているDaniel NouriさんのUsing convolutional neural nets to detect facial keypoints tutorial という記事の流れに沿って、Facial Keypoints DetectionをKerasで実装していきます。単純なモデルから徐々に複雑にしながら解説していきます。多少の機械学習の知識があることを前提にしますが、なるべく分かりやすく解説していきたいと思います。間違い・質問・提案などあれば遠慮なく連絡してください。 KerasはPythonで書くことができるTheanoとTensorFlowベースのライブラリです。直感的に書くことができる人気急上昇中のライブラリです。2015年3月に初公開され、2016年4月にKeras 1.0が公開されました。 Danielさんの記事ではLasagne

読んだことあるものについて、いくつか抜粋でおすすめしてみますね。 リーダブルコード 圧倒的大差で1位を獲得したのは、『リーダブルコード』。 良いコードを書くために必要な基本的な知識が詰まった良書ですね。 リブセンス社内でも、他のエンジニアのデスクや本棚などいろいろな場所で、この特徴的な青い背表紙を見かけます。 ランキングには入らなかったけれど『コードコンプリート』もよろしければどうぞ。 Team Geek 良いものを作るには良いチームであることが必要だ。 「だったらどうしたら良いの？」が書かれた本。 結局、決まりきった絶対的な方法はなく、問題解決のためにはお互いを尊敬して、諦めずにコミュニケーションを取り続ける必要があるんだと感じました。 たまに読むと大いに反省したくなること請け合いです。 ハッカーと画家 良いソフトウェアを設計、デザインするハッカーのマインドが散りばめられたエッセイ。 「

※前回記事にてトラブルシューティング実施にあたって準備しておきたいこと(作業ログの取得方法など)を記載しておりますので、本記事では割愛します。 はじめに 前回の記事の続きとなります。 新米エンジニア(アプリ・インフラエンジニア問わず)に知っておいてほしいトラブルシューティング入門 はじめの一歩編 前回に記事を書いたあと、現場でも意外と基礎を押さえた切り分けができない人が多いのではと思い、よりいろんな方に読んでいただきたくタイトルをかえてみました。 前回の記事では、トラブルシューティングの前に実施しておきたい事や心構えについて記載しました。 今回はそれを受けて実際にトラブルが起きた際の簡易的な切り分け方法についてまとめてみます。 本記事の対象と扱う範囲 前回記事と同様に、初めてエンジニアとして働くことになった方々向けです。 本記事のゴールが「○○できないですのですが、、」といった事象に対して