プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う
ゲノム的にGCリッチなほうがいいだろうということで0と1にg,cをそれぞれ割り当てて数字を表現するようにしてる。exitコマンドには終止コドンを割り当てようかとも思ったが、なんとなくaaaにしてみた(polyA)。 しかも（というか当たり前だけど）blastでホモロジーサーチがかけられるし、multifastaにしておけばソース管理もできるうえに、データベース化してインデックスはっておけば、NCBIのツール群でコマンド一発で取り出せる。 ただ今回作ったHELLO_WORLDの配列はblastnだといい感じにヒットしなくて悲しかったので、blastxかけたらブラックコットンウッドからなんかひっかかった。 >gb|ABK94795.1| unknown [Populus trichocarpa] Length=229 Score = 33.5 bits (75), Expect = 5.9 I
とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損
Discussion These pages show 8 different sorting algorithms on 4 different initial conditions. These visualizations are intended to: Show how each algorithm operates. Show that there is no best sorting algorithm. Show the advantages and disadvantages of each algorithm. Show that worse-case asymptotic behavior is not the deciding factor in choosing an algorithm. Show that the initial condition (inp
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
ｷﾞｺ猫でもわかるファミコンプログラミング ∧ ∧ ～′￣￣( ﾟДﾟ)＜ファミコン、シロ！ UU￣￣ U U 「ｷﾞｺ猫でもわかるファミコンプログラミング」は、 任天堂ファミリーコンピュータ（ファミコン）のエミュレータで動作する、 8ビットアセンブラプログラムの勉強サイトです。 内容には技術的な間違いがある可能性があります。 サンプルソースはあまり整理されておらず、最適化もされていません。 また、内容は予告無しに修正されます。各自の責任においてご覧ください。 なお、このページには自由にリンクして頂いて結構です。 2010/11/1 iswebのサービス終了に伴い、 hp.infoseek.co.jpにおいてあったソース等のファイルが全て消えました。 ここに全てのファイルをアップしましたので、 ご利用下さい 「ファミコンプログラム入門」更新履歴 ファミコンプログラム入門 第１章 はじめに
高校生の時、数学の先生がこう言いました。 ゲームなんて、開発者が作ったルールの上で遊ばれるだけだ。 と。 その時、ゲーマーな自分はこう思いました。 ゲーマーは、開発者が作ったルールの上で遊ばれたい。 と。 というわけで、普段何気なくプレイしているゲームには、どのようなルール（アルゴリズム）があるのか。それを知るために、いろいろなゲームのアルゴリズムなどを解析しているページへのリンク集を作りました。 ほとんどのゲームのアルゴリズムは正式に発表されていないので、ユーザーの手による逆解析だったり、大学の研究による真面目な考察だったりします。（リンク先には、一部アルゴリズムと呼べないものも含まれています） 各種ゲームのプログラム解析 ドラクエ、FF、ロマサガのプログラム解析 DQ調査報告書（リンク切れ） ドラクエの物理ダメージ計算式は本質的にどれも同じだが、細かい部分で微妙に違う RPG INST
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
