本連載では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。

Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従

フローチャートを書く能力はプログラマーにとって必須スキルであり、優秀なプログラマーになるための第一歩です。なぜなら、フローチャートの有無、もしくはフローチャートの内容次第で出来上がるプログラムの品質に大きな差が出るためです。だからこそ、若手プログラマーやSE教育の場で必ず登場するのです。 しかし、フローチャートというテーマは、それだけで書籍１冊になるほどの分野であり、多忙なIT業界においていかに効率的に学習するか悩んでいる方も多いと思います。 プログラマーとしてスキルを高めたいが… 実はそもそもフローチャートのことをよく理解していない 最低限の知識で良質なフローチャートを作りたい フローチャートを書くことに自信がないが、今さら人には聞きづらい このようなことをお思いではないですか？このような悩みから解放頂けるよう、最短ルートで良質なフローチャートを書くための方法を１ページにまとめました。

初めに 新規プロジェクト／既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客＝ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという

※ 本記事は自分が運営するブログに転載しています 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2016』16日目の記事です。 はじめに 私は学生時代は情報工学の専攻でもなければ、趣味でプログラミングをやっていたわけでもなく、 社会人になってWebエンジニアとして初めてまともにプログラミングを勉強し始めました。 入社するまでに独学で勉強の真似事をしてはいましたが、そもそもどうやって勉強していいのか全然わからず、 本を読んで写経をして何故だか理由はよくわからないが動作してしまうミニブログを眺めては、ため息を付いて挫折を繰り返しておりました。 そんな初心者だった自分が、Webエンジニアとして食べていくために本気で努力して身につけたノウハウを、 「プログラミング勉強を加

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

私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント

お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント

Photo by Peter Petrus こんにちは。谷口です。 他人の開発環境って気になりませんか？私は気になります。 誰かの作業を見ていて「何そのツール知らなかった」「えっそのコマンド便利そう」となったことありませんか？ 自分以外のエンジニアは、自分の知らない便利な何かを使っているかもしれない。というか多分使っている。 というわけで、paizaの中のエンジニアたちにそれぞれの開発環境やこれがなくなったら開発できないというハードやソフトや便利な設定、毎日のように使っているコマンドなど、とにかく開発環境について聞きまくってきました。エンジニアの皆さんにとって新たな発見となる項目や参考になる部分があればと思います。 ちなみに弊社のPCは基本的に全員MacBook（3年ごとに買い替え可能）です。ディスプレイも自分の好きなものがあれば買ってもらえます。（だからPCとディスプレイは後から入った人

良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か

（Wikipediaより） ハンガリアン記法のメリット 論理型であるbFlagと、文字列型であるsNameが bFlag + sName となっていれば誤りであることがわかる。 型の記述が2文字程度で済むので、変数名が短く済む。 ハンガリアン記法のデメリット 暗黙の型変換ができない。変数の型を変更するごとに変数名まで変更しなくてはならず、命名法に添って名前を付けるのが面倒。 （同じユーザーIDでも使い方によってはsUserid、iUseridなど） キャメル記法 文字のラインが凸凹になる様をラクダのこぶになぞらえてキャメル記法と名付けられた。 大文字小文字を区別する言語と区別しない言語があるので使う場合は全体を統一すること。 先頭の文字を大文字にするか小文字にするかで2つのパターンがある。 アッパーキャメルケースまたはパスカルケース（1単語目から大文字） 悪い例 $userparamete

クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例

イマイチ理解しきれていなかったDIに関して調べていところ、Google Guiceの解説がすごく分かりやすかったので、和訳してみました。 （ところどころ意訳気味です。明らかに解釈の誤った訳がありましたら、ご指摘ください） ちなみにGoogle Guiceというのは、Googleが開発したDIライブラリです。この例ではJavaが使用されていますが、Scalaでも使用可能です。最近Play Frameworkでも採用されたので話題になっているようです。 用語の定義 本文を読む前に目を通すことで、内容をスムーズに理解できます。 用語 意味 本文中の例

はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定しています。 Qiitaの投稿やブログの記事といったものでも共通する部分は多いのですが、これらには他にも重要な要素があると思うので、ここでは扱いません。 わかりにくいドキュメント=全体像が掴めないものが多い 先ず、わかりにくいドキュメントとはどんなものでしょ

プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう

データベース設計の基本中の基本であるER図。ER図を書きたいけど、「記法が分からない」「どういうステップで書けば良いか分からない」という若手エンジニアも多いのではないでしょうか。 ER図は１０種類近くあり、種類によって記法が異なります。このことが難しいイメージを与えていますが、実はそれほど難しいものではありません。覚えれば良いER図は２種類だけです。 しかも、この記事で解説している基礎知識を押えれば、たった５つのステップで作成することができます。 この記事では、ER図の基礎知識からER図の書き方まで、エンジニアが抑えておくべきER図の全知識をどこよりも分かりやすく解説します。 この記事を読み終えたとき、若手エンジニアもER図を書けるようになっているでしょう。 この記事を参考に最適なデータベース設計を進めて下さい。 １．ER図とは ER図とは、「データベース設計（データモデリング）で使う設計

はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を