こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で

Reactでファイルアップロードするなら注意 React.jsでformタグをつかってマルチパートデータとしてファイルアップロードするとき、 属性名は以下にしないといけない。 正：encType 誤：enctype 実例 正しい例 // ソース var SomeComponent = React.createClass({ ... render: function() { return ( <form action="/upload" method="POST" encType="multipart/form-data"> <input type="file" name="file_input" /> <input type="submit" value="Upload" /> </form> ); } }); <!-- レンダリング結果 - enctype属性が存在する😊 --> <f

こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを

碁の対局のログがGitで管理されていて，一手が1コミットに対応する Gitで管理しているので自由にブランチを切ったりマージしたりリバートしたりできる 碁に興味はないしルールも知らないので興味ある人いたらおねがいします

3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as

あけましておめでとうございます。 2016年になり、早速今日から仕事はじめのところも多いと思います。ということで、今年の抱負でも簡単に書きます。 2016年1月付でシニア・プリンシパルエンジニアになった 参照: エンジニアの働き方 | キャリア採用 | 採用情報 | GMOペパボ株式会社 前回の2015年の記事でも簡単にふれたように、ペパボではエンジニア職位制度が刷新され役職名の変更と、新たな上位の役職が追加されました。 hb.matsumoto-r.jp その新たな上位の役職がシニア・プリンシパルエンジニアと呼ばれており、1月付で僕が初めて就任することになりました。ということで現在はシニア・プリンシパルは僕だけとなります。 外での活動は目立っているが、一緒に会社に入ってエンジニアとして仕事をしてみると意外と思ってたより普通…というような印象を与えてしまうのは避けたいという思いがありました

2015年12月23日23:17 AWS JavaScript AWS Lambdaを使ってサーバレスでテキスト抽出するぞ！という気持ち この記事は 今年もやるよ！AWS Lambda縛り Advent Calendar 2015 の23日目です。 「何か書くぞ！」と思いエントリーしてみたもののどうしよう、、と思っていたのですが、そういえば個人的に Apache Tika というのが最近気になっていたので使ってみることに。 Apache Tika これは、PDFやエクセル等のファイルから、テキストデータやメタデータを抽出してくれるという便利ライブラリです。これを使って、ファイルが登録されたら裏でテキストデータを抽出して、それを全文検索で引っかかるようにする…みたいなことが出来ると楽しそうです。 Apache Tika自体はJavaのライブラリなのですが、Node.jsから扱うためのライブラ

TwitterでOAuth認証をしようと思ったら PINコードの手入力 指定したCallback URLへリダイレクト の2通りになると思うのだけど、このうちCallback URLへリダイレクトする方法にしようとしてはまっていた話。 Twitter側でアプリケーションを登録する際にApplication Typeを選択できる。ここで、Browserを選択するとCallback URLを指定できる。 ところが、OAuthの仕様上、oauth_callbackとかいうヘッダをつけて実際にリクエストするときに指定できるので、アプリケーションの登録時には別に空白でよいかと思っていた。 そうすると、何度試してもリクエストトークンを取得する最初の段階で 401 OAuth.Unauthorized が発生するのだった。 どうにもわからないのでレスポンスの中身を見てみると、 Desktop appli

やろうとしたこと 会社でQiita Teamを契約してもらっているのだが投稿してる人がほぼ固定されているので投稿のハードルを下げていろんな人に投稿してもらいたい 副次的にいろんな技術的投稿に目を通すことで技術的な知見を得たり、知識を増やしていくような活用がしたい (弊社ではQiita Teamは技術的内容のみが投稿されている状態にしたいという意向で ガイアックスさんみたいな日報などはアップしない方針になってます。) 提案した内容 週に2時間くらいの技術書を読む時間を就業時間内で確保する 隔週で読んだ技術書の内容をQiita Teamに投稿 読む技術書の選定は上司と相談 細かい点などはあるもののだいたいこんな感じのことをしようと提案したところ 時間をとってみんなの意見を聞いてほしいと言われたので1時間ほど時間をとって概要説明と各個人全員に強制的に意見を聞いてまわりました。 そしたら結構な反撃

私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ

Yoしてますか。 どうやら、Yo APIとやらがある模様。遊んでみます。Yoされたら、ツイッターでやぁするやつを作ってみます。 #ちょっと何言ってんのか 今回は、YAHYAHWORKSにYoすると、@yahyahworks がナンカ言うやつを作ります。 heroku アプリケーションを作成 heroku create ppworks-yo 悲しい事故が起きないようにremoteの名前を変えておく。 git remote rename heroku ppworks-yo これは、複数のherokuアプリケーションを管理していることを考慮して 間違えて別のローカルリポジトリから意図せずherokuにpushしてしまう ことを防ぐためです。git push heroku master でリリースできるのは便利なのですが、herokuのどのアプリケーションにdeployしようとしているかのコンテキ

このページは掲載を終了いたしました。

サーバー選定するときにawsが良いなって思うんだけどaws通信費高いしなってなってじゃあどこにしようかって考えるんだけどあんまり決まらなくて考える時間費やすのが本当に無駄な気がしてて金で解決できる事は金で解決した方が幸せなんじゃないか、金のために働くなんて本当にむなしいし金に働いてもらって想像力を無限に膨らませたいしairbnbで沖縄のペンションみたいなところ借りて海眺めながらTumblrでもしていたい。 なので金で解決するためのAWS Elastic Beanstalkの(多分)最速設定方法 参考 http://dev.classmethod.jp/cloud/aws/eb-sinatra-in-10minutes/ AWS Elastic Beanstalkのcliコマンドのインストール $ eb -h usage: eb {COMMAND} [options] AWS Elastic

The Big Pictureに音楽評論家のBob Lefsetzが表題のエントリを寄稿している（H/T 本石町日記さんツイート）。 アマチュア アイディアに溢れていて、それらのすべてに興奮を覚えるが、いずれも実現しない。 プロ アイディアに溢れていて、そのうちの一つを取り上げて実現に全力を尽くす。 アマチュア 自分は何でもできると思う。 プロ 一つのことさえ達成するのは不可能に近いと知っている。 アマチュア 自分は何でも知っていると思う。 プロ 常に学んでいる。 アマチュア 準備無しに始める。 プロ 研究し、詳細を知悉することに努め、全体像を掴もうとする。そうしたことは始める前に把握しておくべき。というのは、実行しつつ調整するのは困難で、時間とエネルギーを消耗するものだから。三輪で設計した自動車に四つ目の車輪を装着するのは難しい。 アマチュア 完成させない。 プロ 遂行がすべて。確かにこ

最近、個人のリポジトリレベルの開発でも、自分のためのIssueを立て、自分しか見ないPull Requestを作ったりしている。 docker-registry をインストールするぞ〜 · Issue #1 · udzura/docker-playroom · GitHub Install Ruby recipe by udzura · Pull Request #3 · udzura/docker-playroom · GitHub First version of ikachan module by udzura · Pull Request #1 · udzura/ikachan-node · GitHub この際気を付けていることとして： Issue、最初のdescriptionは最初のTODOへのポインタだけ書いておく プルリクエストは 生煮え の状態で出す 思ったこと、詰まった

ご用心: この記事を鵜呑みにせず、末尾に記載された一次ソースを確認してください。 ソースからソフトウェアをビルドしてインストールするときに使う /usr/local ディレクトリだけど、/opt ディレクトリとの住み分けとか、 そもそも標準はどうなっているのかとか、まともに知らんかったので Filesystem Hierarchy Standard を確認してみた。 /usr/local は何をすべきところなのか？ 他のホストと共有されない 既存のシステムの破壊防止 FHS 準拠のソフトウェアをインストールする /usr/local ディレクトリ下自体が FHS 準拠になる /usr/local ディレクトリは、システム管理者がソフトウェアをローカルにインストールするために用いる。 /usr/local ディレクトリとして隔離されるため、同名のファイル名で既存のファイルを上書きするなどして

こういうのをサッと作ってしまうあたりがネットの楽しさですねTwitterで大流行している「◯◯がよく使うハンドサイン」というコラ画像。個性的なものが多くてとても面白いのですが、画像を作るのは手間だなーと思っていた人には朗報です。 関連：【画像まとめ】各都道府県民がよく使うハンドサインがTwitterで話題 以下のような画面が表示され、各番号のところにテキストを入力。あとは「画像に出力」をクリックするだけで簡単に画像を作成できるそうです。 ハンドサイン画像ジェネレーター 興味ある人は是非お試しください。