「誰がこんなネーミングにしたんだ……。」プログラミングのネーミングルールを決める時に参考にしたい情報まとめ
サイトのメンテナンスにおいてしばしばネックになるのは、どんなネーミング・構成で制御しているのか分からなくなってしまうことです。しっかりと基準に則った、誰がいつ見てもわかりやすいネーミングでコーディングしていくことは、非常に重要なことです。 今回は、プログラマーがネーミングを考える際に参考にしたいサイトを選んでご紹介いたします。 1. codic - プログラマーのためのネーミング辞書 https://codic.jp/ 様々なサイトに紹介され、「ネーミング」で検索しても上位に表示される素晴らしいツールです。例えば、Webサイトの背景に動画を設置する際に、class名をどうしようか悩んだとします。そこでcodicに「背景動画」と入力すれば「background_videos」と提案してくれます。提案されたネーミング以外にも、その他の候補も出てきます。 考える労力を省くことができるという点で優
今さら聞けない、変数や関数の命名規則と、まず覚えるべき英単語200
（Wikipediaより） ハンガリアン記法のメリット 論理型であるbFlagと、文字列型であるsNameが bFlag + sName となっていれば誤りであることがわかる。 型の記述が2文字程度で済むので、変数名が短く済む。 ハンガリアン記法のデメリット 暗黙の型変換ができない。変数の型を変更するごとに変数名まで変更しなくてはならず、命名法に添って名前を付けるのが面倒。 （同じユーザーIDでも使い方によってはsUserid、iUseridなど） キャメル記法 文字のラインが凸凹になる様をラクダのこぶになぞらえてキャメル記法と名付けられた。 大文字小文字を区別する言語と区別しない言語があるので使う場合は全体を統一すること。 先頭の文字を大文字にするか小文字にするかで2つのパターンがある。 アッパーキャメルケースまたはパスカルケース（1単語目から大文字） 悪い例 $userparamete
「組織的負債」を貯めないための、プログラマの哲学によるチームのマネジメント術 | Social Change!
プログラマの世界には「技術的負債」という言葉がある。ソフトウェアを開発していく中で、時間がなくて妥協したり、技術力が足りなかったりして、適当に作ってしまった部分が、後々になって不具合を引き起こしたり、改修にかかるコストをあげたりすることを言う。 後になればなるほど、悪影響が大きくなることから負債と喩えられる。そんな技術的負債と同じように、組織やチームのマネジメントでも、後になればなるほど悪影響が出てくるような「組織的負債」とも言えるような現象が起きてしまうことがある。 本記事では、私たちソニックガーデンで「組織的負債」を貯めないようにチーム経営してきた経験をもとに、プログラマの哲学を応用したマネジメント術について書いた。（今回の記事では「である」調にしてみた） 技術的負債と組織的負債の生まれる背景 技術的負債が生まれるのは、スタートアップの初期段階に多い。その時期は得てして、経験豊富な技術
これから先もプログラマーを続けるために重要なこと - nigoblog
先日こんなニュースが MozillaやApple、Javaの未解決の脆弱性に対処 Javaプラグインを無効に - ITmedia エンタープライズ 【速報】Javaに未修正の脆弱性、無効化を促す警告出される ネットベンチャーニュース 要はJavaは危険です、だから使わないように。 的な!! 個人的にはJavaはあまり使うことがなかったんですが、まぁどの言語にもこんなことはありえるなと思っています。 それは単に流行ってなくて使われてないだったりもそうだし、 こういう時困るのはその言語しか知らない、使えないっていう人ですよね。 例えば今回のを受けてJavaを書く機械が全くなくなったと。 Javaしか書けないAさん →仕事ない JavaとRubyが書けるBさん →Rubyで仕事する 仮にRubyが使えなくなった場合 JavaとRubyが書けるBさん →仕事ない RubyとPythonが書けるCさ
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
現役エンジニアに贈る、これからの生存戦略｜大場光一郎氏のキャリア論＠エンジニア転職MTG | キャリアハック（CAREER HACK）
1月25日にエン・ジャパン主催で開催されたエンジニアMTG。クラウドワークス・CTO 大場光一郎氏が、自らのキャリアを基に講演を行なった。ソフトハウスからCTC、グリーを経てクラウドワークスにCTOとして参画した彼が、自身のキャリアから後進のエンジニアに伝えたいメッセージとは。 クラウドワークスCTOがエンジニアに伝えたいこと 1月25日にエン・ジャパン主催で開催されたエンジニアMTG。1月にクラウドワークスにジョインした大場光一郎氏が、自らのキャリアを基に講演を行なった。今回、その内容の一部をCAREER REPORTとしてお伝えしようと思う。ソフトハウスからCTC、グリーを経てクラウドワークスにCTOとして参画した彼が、自身のキャリアから後進のエンジニアに伝えたいメッセージとは。 ▽記事ハイライト ・「インターネットがみんなのものに。非ネット企業のテクノロジー企業化」 ・「業務効率改善
サーバエンジニアが「開発力」を持つ意味 - Gosuke Miyashita
初出: Software Design 2009年4月号（2009年3月18日発売） 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア（OSS）をメインで扱うエンジニ
若い時にプログラムを書こう、必ず人生の豊かさにつながる
システムインテグレータ最大手NTTデータを率いる山下社長は若い頃、汎用コンピュータ用のデータベース開発に取り組み、プログラムを自ら作っていた。その経験から山下氏は「人生のどこかで手を動かしてプログラムを作る仕事を経験した方が絶対に面白い。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、それがその後の人生の豊かさにつながる」と同社幹部としては異例の発言をする。（聞き手は谷島 宣之＝日経コンピュータ編集長、写真は小久保松直） 2009年度、100億円近い投資を計画していると聞く。狙いは何か。 100億円のうち、40億円くらいかけようと考えているのが、「倍速開発」という案件です。これが一番大きい投資になります。我が社としてぜひともやらないといけないのは、お客様のお気の召すまま、ご希望のオーダーメード・システムを、パッケージ・ソフトを使った場合と同じスピードで作って差し上げる、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
