cmd.exe の引数の扱いがあまりにもカオスだったのでちょっと頑張って調べてみた。 本来ならここは公式の資料に当たるのが正しいアプローチだと思うけど、どうしても公式の資料が見つからなかったので、色々試して推測してみることに。 断片的な資料は見付けたけど、完全じゃない。一応URL貼っておく。Windows Server 2003 のヘルプだけど、恐らくそんなに変わらないと思う。 コマンド シェルの概要 コマンド リダイレクト演算子を使用する なので、以下で述べる内容は間違いを含む可能性があります。というか正確さは一切保証されないのであしからず。 検証方法 以下のような引数をただ表示するだけの簡単な C のプログラムを用意した。仮に args.exe とでもしておく。 #include <stdio.h> int main(int argc, char const* argv[]) { in
はじめに この記事では、MySQL を使って簡単なメッセージキューを手軽に実装する方法を解説します。 メッセージキューとは、メッセージを一時的に溜めておき、順次処理するための仕組みです。迅速なレスポンスが必要な Web アプリケーションにおいて、時間のかかる処理を非同期に行うために、バックグラウンドで順次処理していくような場合に利用できます。 簡単なメッセージキューと言っても、大規模な運用にも耐えられる程度の速度と堅牢性を持ちます。 また、ここで解説している方法で作られたメッセージキューは、弊社ウェブサービスであるニコニコ動画に最近追加されたtwitter連携機能でも利用しています。 メッセージキューを作るにあたって 今回実装するメッセージキューは メッセージの追加(push)を高速に行う事ができる メッセージの取得(pop)はある程度高速に行う事ができる 多くのクライアントから同時に p
この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え
配列を返す関数で値が1個もないときは普通に空配列で返しましょう……
JavaにはNullPointerExceptionなどのcatchしなくてもclass load validationを素通りできる例外があります。 バグの多くはそういった例外を考慮しないことのようです。 なので、今回はそういった例外の「IndexOutOfBoundsException」を発生させます。 ボタンをタップすると例外が発生します。 oobBtn.setOnClickListener(new View.OnClickListener(){ public void onClick(View v) { int index = 5; String[] strs = new String[index]; String str = strs[index];//ここでIndexOutOfBoundsException }});
結論から先に。cronlog を使えば、アプリケーションのテストコードと全く同じ形式で、監視用のスクリプトを書くことができます。プログラマが監視ツールの記法を覚える必要はありません。これは、プログラマが運用も行うケースでは特に有効な手法だと思います。 先週公開した Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法 というエントリで、crontab と拙作の cronlog を用いてサービス監視を書く手法を紹介しました。しかし、挙げた例はいずれも ping や http のテストといった外形監視の手法です。RDBMS とウェブアプリケーションのみから構成されるサービスならそれだけで十分でしょう。 しかし、外形監視だけでは、メッセージキューのような非同期処理の遅延を観測することはできません。また、http のログを監視して、エラーレスポンスや平均応答
概要¶ これは Google Python Style Guide Revision 2.29 を日本語に訳したものです。 本家ガイドは CC-By 3.0 ライセンス の基で公開されています。また、本ガイドも同ライセンスを継承します。 本家ガイドの著者は以下の通りです。 Amit Patel Antoine Picard Eugene Jhong Jeremy Hylton Matt Smart Mike Shields また、本ガイドの翻訳者は以下の通りです。 Kosei Kitahara 本ガイドに誤植、誤訳があった場合は issue で教えてください。 その他本ガイドに関する問い合わせは、サイト最下部に記載のメールアドレスか @Surgo にお願いします。 はじめに¶ Python は Google で使われている主要なスクリプト言語です。 このスタイルガイドは Python によ
考えるきっかけになったのは、最近話題になっている以下のエントリ。 人生を書き換える者すらいた。: 人材獲得作戦・４ 試験問題ほか 個人的に、あるアルゴリズムを用いて解くような問題を採用試験にだすのはどうかと思っていた。理由としてはいくつかあるのだけれど、「業務でそういったアルゴリズムを使うことが少ない(為、そういう知識がない」「知っている人と知らない人とで差がでてしまう」などなど。 で、先程Twitterに発言しながら似たようなことを考えていたのだけど、よくよく考えると上記の理由は「採用される側」での意見ということに気づいた。 まず、「採用する側」で一番避けたいのは、「ダメな人を雇ってしまわない」ということ。優秀な人を間違って落してしまうのも勿体無い話ではあるが、ダメな人を雇ってしまうよりはマシだ。そうなると採用試験では、その「ダメな人」を確実に篩い落したいわけだ。 大体において、業務で使
さて試験問題です。 内容は、壁とスペースで構成された迷路が与えられたとき、スタート地点からゴール地点に至る最短経路を求めよ、というものです。 たとえば、S:スタート G:ゴール *:壁 $:解答の経路 としたとき、 ************************** *S* * * * * * * ************* * * * * ************ * * * * ************** *********** * * ** *********************** * * G * * * *********** * * * * ******* * * * * * ************************** という入力に対し、 ************************** *S* * $$$ * *$* *$$*$ ************
3ヶ月ほど学んでいる、PHP初学者の愚痴みたいなエントリです。解決に至ってないので、あしからず。 現状 今、ボクの会社では仕事がないために、所属社員の半数ほどがPHPやらC++などの学習を行っております。ボクはPHP+MySQLでWebサービスの構築を学習しているのですが、プログラム経験がゼロから始めたこともあり、かなり学習スピードが遅くて、いろいろとてこずっているわけです。 たぶん、10月くらいから、学習期間にはいっているわけですが、PHPを書き始めたのが11月半ばくらい。おおよそ3ヶ月間学んでいますが、いまだにサクサク書くことはできません。 ここまでで役にたったモノ 何故か。 その前に、ボクの学習において、役にたったと思われるモノを紹介。 PHP: PHP マニュアル - Manual …… コレを見ないと関数の使い方が分からないことが多々あり。 MySQL :: MySQL 5.1
メソッドのアクセス制御を行う理由は、公開するオブジェクトを限定しカプセル化を堅牢にするため。アクセス制御することで以下の効果がある。 公開するメソッドを複数のメソッドから構成した時、呼び出し側が知らなくても呼び出し手順やオブジェクトの事前準備を行える 実装の細かい変化が呼び出し側に波及しないようにする 外部に公開する意図がないメソッドをprivateメソッド以降に記述する 外部からの呼び出しを受ける少数のpublicアクセスメソッド、その下請け処理をするprivateアクセスメソッドから成り立つ。protectedアクセスメソッドは例外的な利用方法しか使わない。 Rubyではアクセス可能性をインスタンス単位で考えます。C#やJavaと言った他のプログラミング言語が採用するクラス単位のアクセス可能性とは異なる。
基底クラス 共通の処理を実装する 派生クラス独自の処理をからのメソッドとして定義しておく 派生クラス 基底クラスの空メソッドをオーバーライドする ※上記2つのメソッドはprivateをかけて、外部に公開しないようにする
プログラマーとして覚えておくと便利な英語をまとめてみた。 プログラミング系 admission 許可 submit 提出する alias 別名 array 配列 attachment 添付 attribute 帰する、属性 common 共通の compare 比較 complete 完成 confirm 確認する configuration 設定 error prone エラーが発生しやすい create つくる date 日付 directory ディレクトリ、フォルダ dynamic 動的な empty からっぽ enable 可能 exception 例外 exchange 交換 execute 実行 exit 抜け出す explain 説明する fetch CPUがメモリから命令を持ってくる forward 前へ function 機能 grep global regular e
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
いやー、なんか怖い人（笑）が見てるようだ。突っ込み激しそうぜよｗ さて、前回言っていた「判断ロジック」についての答えは各自考えてみただろうか？ 各方面の反応を見ると「1〜4どれでしょうか*1」という問いにすり替わっちゃってる気がするけど、テーマは「1〜4を決めるロジックを考えてください」なんだ。書き方悪かったもしれんｗ まぁつまり、昨日のエントリの時点では1〜4どれでもないのですよ。判断ロジックがないので。 というわけで本題。アプリケーションレベルでのバグとは「実際の挙動が仕様と違うとき」ですね。挙動があるべき姿(=仕様)と違う時にそいつバグとするのが妥当です。そしてそれはコードレベルでも同じ基準で良いんじゃないでしょうか。 じゃあ、仕様とは何か。Javadocコメントですよ。Javadocがないとバグの定義さえもできないんです。だから口酸っぱくJavadoc書けとｗ*2 まぁつまり「Ja
最近こんなやりとりがあった。 「Cって標準のコンテナ（双方向リストや可変長配列など）がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ？ STL“も”いいけど、自分で書きたい」 正直、自分は「え？ 何を言っているんだ？」と思った。 STL“も”いいけど、“自分で書きたい”だって？ その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう？ それを使わされる人の苦労はどうなる？ それともプロジェクトに同一の事をするための複数のコンテナが存在するのか？ 俺俺コンテナを書きたい理由はなんだ？ 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握
繰り返す。Fooクラスを利用するMainクラスを書く時、XはFooの「仕様」に依存すべきであり、Fooの「実装の詳細」に依存すべきではない。 public class Foo { public String bar; public Foo(String bar) { this.bar = bar; } public String getBar() { return bar; } } public class Main { public static void main(String[] args) { Foo foo = new Foo("hoge"); System.out.println(foo.bar); // (1) System.out.println(foo.getBar()); // (2) } } 上記のクラスはbarフィールドがpublicである。しかしFooのインターフ
「ある処理をするコードを書く」というのは「ある出来事を文章に表現する」のと似ていると思っている。 まず表現に使う言語は様々であり、使用人口の大小はあれど、基本的に優劣はない。言語が同じだったとしても、十人十色の表現をし、全く同じ出来事を表現したものであっても、複数人が全く同じ文章を作る可能性は限りなく小さい。同じ人が表現するんであっても、今と昔で「全く同じ文章」を書くとは限らない。むしろ微妙に差異があるのが普通だ。 そんな「コーディング」に一貫性を持たせるのがコーディングルールだ。インデントはスペース4つだとか、braceの位置はどうだとか。複数人で小説を執筆する*1場合は、「ですます調に統一しよう」とか色々な取り決めをすると思う。このあたりの一貫性がないと、非常に読みにくい小説が出来上がるだろう。 とまぁ、ルールってのは、複数人間の意識合わせのために*2存在する。例えば法律もそうだ。そし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
