技術を活かし、新しい価値を創造する DeNAのエンジニアは、想像を超えるDelightを届けるために何ができるかを考え、技術力と発想力で新しい価値を生み出しています。 多様な専門性を持ったエンジニアが切磋琢磨し、互いに刺激し合える環境や制度がさらなる成長へとつなげます。

pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/　/," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param

Twitterのフォロワーさんが「こんなサービスあったらいいな」と呟いておりまして。 いっちょ俺が作るか！という事で、作業記録を残してみようかと思います。 最近MacをOS再インストールし、ほぼまっさら、xcode(使わないけどgit有効化に必要)とemacsだけが入ってるような状態からのスタートです。 Webサービスってどうやって作っていくんだろと思われてる方の参考になれば幸いです。なお、いつもの通りDjango&Heroku構成です。 ※これ見て何かを作れるという訳ではなく、こんな流れで作ってるよという説明ですので、詳細は結構省き気味です。 ※作るときのポイントを先に言ってしまいますが、いきなり完成系を目指すんじゃなくて、ちょっと作って動かしてを繰り返すのがポイントになってくるんじゃないかなと思ってます。僕はSI屋なんですが、新人君とかでもいきなり全部コーディングして、いざ動かすと動か

こんにちは。安達です。今年も引き続き、張り切って行きたいと思います。 さて、突然ですがみなさんは「プロジェクトマネージャー」を目指してますか？　もちろん、ひと口にプロジェクトマネージャーと言ってもさまざまな方がいます。 大規模な業務システム構築のプロジェクトもあれば、ECサイトやWebサービス構築プロジェクトもあります。LSIのチップ制御ソフトウェア開発もあれば、スマートフォンのゲームアプリ開発もあります。 ただ、共通して必要とされるスキルが、「プロジェクトマネジメント」だということは、みなさんも意見が一致するのではないでしょうか。 しかしそうはいっても、プロジェクトマネージャーになってから独学でプロジェクトマネジメントをゼロから学ぶのはとても非効率です。もちろん会社でOJTをするなり、体系的なプロジェクトマネジメントのマニュアルがあるならば、さしあたっての問題はないでしょう。 でも、ある

ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門：プロジェクト成功確率向上の近道とは？（1）（1/2 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ

私には、目標がある。 『時間ではなく、技術を売る技術者（エンジニア）になる』 この目標を考えた当初はただの思いつきだった。 どうすれば目標を達成できるか模索していくなかで、明確な理由が固まってきたのでここにまとめる。 人月商売への疑問 IT業界以外の人には馴染みがないと思うが、IT業界（特にSIer）には古くから「人月見積」という悪しき風習がある。 簡単にいうと 1人が1日でできる作業量を1人日 1人が1ヶ月でできる作業量を1人月（約20人日） あるシステムを10人体制で半年かけて完成する規模だとすると、10人 × 6ヶ月 = 60人月となり、見積額は 60人月 × 100万円（単価） = 6,000万円 になります。っといった具合。 この「人月」というのが、IT業界の一般的な見積手法であり、諸悪の根源である。 そして、この「人月」には大きな問題がある。 多重下請けも相まって、利益率がクソ

はじめに 「プログラミングに関する雑多な事柄」がテーマの本連載、第5回の今回はソースコードを読むこと、「⁠コードリーディング」について取り上げたいと思います。 なぜコードリーディング? 他人のコードを読む場面には、いくつかのパターンがあると考えられます。 チームで開発しているときに、ほかのメンバーが書いたコードをレビューしたり、理解するために読む ライブラリの動作のしくみや設計などのテクニックを勉強するために読む 「こういう処理をするにはどうすれば良いんだろう?」と参考にするために、類似のプロジェクトのコードを読む オープンソースのライブラリを使おうと思ったらドキュメントがないのでソースコードを読む オープンソースのプログラムを使っていたらバグっていたのでデバッグのためにコードを読む 上の3つは、コードを読んで理解しよう、勉強しよう、参考にしようといった、積極的なコードリーディングであるの

社内表彰式で「ブランディング賞」というものを受賞しました、ハカセです。 金一封として800バーツをいただきましたが、本当に扱いに困ってます。どうしたらよいのでしょう。 さて、今回はLIGのコードレビュー会で使用しているツールについて、活用技術を紹介していきたいと思います。 LIGのコードレビュー会とは LIGでは毎週コードレビュー会を開催しています。 毎回1人がコードを出し、それをみんなで確認して もっとこうした方が、わかりやすいのでは？ こっちの方がパフォーマンスが良い これすごくいいから、ちょうだい！ というような意見を、気軽に言い合う会となっています。 しっかりした品質のためのレビューとは異なり、個々のスキル向上、コーディングルールの意識統一などを目的とした勉強会のような位置づけになっています。 レビューの方法 レビューについては、以前は1台のPCモニターの前で集まっておこなっていま