Hawk's Laboratory » Ajax イン・アクションは6章もけっこう酷い
このドメインを購入する。 hawklab.jp 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
いつきログ(2006-06-15)
◆ [ネタ] ハルヒ１１話の… 長門が打ってる（？）プログラムを読んでみた。 スローモーションで見た。１→２→３の順で表示されるんだが… 右下のsub_3に注目 拡大してみる ちょ、これって（笑） とりあえず読める範囲内でソースにおとしてみた このコードでやってることは、Windows上で「確認メッセージ」だして、「プロセスリスト」を取得して、（読めなかった部分でターゲットか否かを解析して）*1、「InjectHookとゆー関数を一致した全プロセスに対して呼び出す」…うわ、めちゃ普通に、リアルタイムで動いてるプログラムにフックできるジャン！*2（笑） まぁ、実際に画面上に流れていたときは、時々文字の順序が狂ってたりエラー処理が甘かったり、同じコードが何回も流れたりしてましたが…… … ……まさか、長門、これをcopy con SimInject.ccあたりで書いてましたか！？ 実際に上のコ
最上の日々 - 数学を表現するのに最適な媒体はコンピュータである
▼ 数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 （これだけ書くのも大変だろうなあ。いつもお世話になってます。） 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな： 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると
2006-06-07
どうも気に入った表現を使いすぎる傾向があるような。 だから、使い過ぎた表現は控えるのではなく、もっと、こう、ローテーションするような感じが必要なんじゃないか。 http://www.coins.tsukuba.ac.jp/~i021216/diary/?date=20060606#p02 ふむ、ここで、 豆知識: 関西人の納豆嫌いは減少傾向にあるというようなネタを思い付いたのだけど、あまりにアレなので心にしまっておこうとおもった。 けど、しまいきれてない。 数学を勉強すると、とりあえず、「僕には数学は無理だ」と、いうような結論になってしまうのだけど、それはおいといて、数学用語には、素晴らしい日本語訳があるというような気がしたというような。 例えば、functionは関数…関数！！この命名センスはいかほどのものか？ 最初に関数っていう単語を適用した人間の日本語センスは大変に素晴らしいもののよ
Kickstart my heart: APIとUIはともにIである
こんなおいしそうな議論をしていたとは、さっき飯食ってたときはぜんぜん知らなかったな（苦笑）。アンテナが下がってる。 naoyaさんの文章を読んでいてふと疑問に感じたのが、APIというときのIと「インタフェース」と書いたときとで、それぞれ異なる意味で言葉を使っているように読めるってこと。miyagawaさんのエントリのタイトルが「API, UI as Commons」と2つのIを並列して書いているのと並べて読むと、そこんとこを深読みしちゃうなぁ。 Catalyst の View::JSON とかは渡したデータ構造が勝手に JSON になって Web API になりますよ、というものだけども、これだけだとまだ開発者は「どういう API を持たせて、どういうデータ構造を返して」というのを自分で考えないといけない。なのでインタフェースに制約が欲しい。 APIというのはアプリケーションに対してサービ
プログラミングと臨床心理学は妙に似ている - アンカテ
私が多少なりとも体系的に勉強しているのは、プログラミングと臨床心理学だ(後者は体系的ではあるけどほんの少しだけだし、前者も実はアヤしい所がたくさんあるが)。この二つには妙に似ている所がある。 合意された業界地図がない 再現可能性と実効性の間で引き裂かれている ノウハウがデザパタ的、フレームワーク的 達人はどの言語(技法)を使っても同じ 仕事の本質はモデルを作ることではないか 誇大妄想的に「自分のやり方で全て解決できる」という馬鹿が定期的に出てくる 合意された業界地図がない どちらも、業界地図の書き方が、人によって違うんですね。 → アンカテ(Uncategorizable Blog) - ソフトウエア業界の「バカ世界地図」 臨床心理学もこういう雰囲気があって、業界地図の書き方や対立軸の選び方でその人がどこに所属する人かだいたい読める。 再現可能性と実効性の間で引き裂かれている 教育してある
2006-04-08
世の中は広い*1です。補助ツールに過ぎないはずのMakeでプログラミングする人もおられるぐらいです。キーカスタマイズツールに過ぎないはずの窓使いの憂鬱でプログラムが書けたっておかしくありません。 プログラミング言語に最低限必要なものは、入力と出力と計算能力です。入力はキーボードからのキー入力、出力はアプリへ渡すキー入力、あとは計算ができれば.mayuでアプリが書けちゃいます。 例えば、足し算をしてみましょう。 key D-~L0-~L1-~L2-~L3-~L4-~L5-~L6-~L7-~L8-~L9-_1 = _1 &Toggle(LOCK0, on) key D-~L0-~L1-~L2-~L3-~L4-~L5-~L6-~L7-~L8-~L9-_2 = _2 &Toggle(LOCK1, on) key D-~L0-~L1-~L2-~L3-~L4-~L5-~L6-~L7-~L8-~L9-_
浮ついた「ギーク」への説教（※老害注意） - ZEROBASE BLOG
「ヱブ弐点零デ、マツシユアツプ」とか言ってる場合じゃないんですよ。Nintendo DSのカートリッジ自作ハックくらいしろと。OSカーネルやコンパイラを書けと。 本職のプログラマを名乗るなら、「珠玉のプログラミング」を読んで問題を解いて欲しい。Perl/PHP/Ruby/Pythonしか書けないようでは、本物のプログラマと呼びにくい。JavaとLispとC/C++（まあ、いまならC#ですかね）も覚えてほしい。ちなみにWrite Great Codeも良いらしいです。 本書でいうグレートコードとは「高速・コンパクトかつ、リソースを無駄使いせず、可読性に優れ、保守が容易で、一貫したスタイルに従った、系統的に設計され、拡張性に富む、十分にテストされ、確実に動作し、ドキュメントが整備されている」コードです。 つまり、要点としては、コンピュータ・サイエンスとソフトウェア工学は、みっちりおさえてこそ、
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
Pattern Languages of Functional Programs
These pages are for people interested in applying the ideas of patterns and pattern languages to the doing, understanding, and teaching of functional programming. This is just the beginning of what some hope will be a productive area of study. The web pages here are in a beta-release state. Why Patterns? Pattern languages describe how to build things. As such, patterns can be a good tool for helpi
ささださんのタブブラウザのソース - babie, you're my home
久しぶりに C# のソースを読んだよ。C# もわかりやすいなぁ。ソースがドキュメントだなぁ。スキ。 のっけからパーシャルクラス ktkr パーシャルクラスの全てで親クラスを明示的に書いてあげないといけないのかなぁ？ のっけから p() ktkr ぼそ1。メソッド名が Java っぽい。UpperCamel ……。 さらに navigate とか tabTree_AfterSelect とか混血児がいる。 そういや *_AfterSelect は IDE が生成する名前だ。 ぼそ2。getter/setter が Java っぽい。プロパティ……。 インライン delegate カワユスなぁ。 ちなみに C# 1.0 の delegate はさっぱりわからなかった！えへ。サンプル見ながら作ってた。まだるっこしすぎるよ。 これ(1) void Hoge() { ... }と、これ(2) voi
分裂勘違い君劇場 - 劇的に生産性を向上させるメタオブジェクト技術とRuby on Railsの陳腐化の宿命(Java、C#)
■この記事で取り上げているトピックハイライト■ なぜ、メタオブジェクトを自分自身で使いこなせるようになると、日常のプログラミング生産性が大きく向上するのか? なぜ、メタオブジェクト技術を使うと、分散オブジェクト、Rails、DI、ORマッピング、Webサービスなどの、大きく生産性を向上させる仕組み自体を自分でつくれるのか? C#のどのメタオブジェクト機能をどのように使えば、簡単に「C# on Rails」を作れるのか? なぜ「Ruby on Rails」は陳腐化してしまう運命にあるのか？ 「Ruby on Rails」を陳腐化させるアーキテクチャとはどのようなものなのか? ■構成■ まず、Ruby on Railsと同様のフレームワークを、C#で作ったとしたら、どのようになるのかという例題を通して、メタオブジェクト機能、つまり、リフレクション、カスタム属性、CodeDOM、パーサジェネレー
分裂勘違い君劇場 - 「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている
この記事で主張しているように「同じことを2度しない（Only and Only OnceあるいはDRY：Don't Repeat Yourself）」と無条件で考えてしまうと、逆に生産性が大きく低下するケースがたくさんある。この記事のテーマは主に自動化の話だが、それは自動化だけでなく、ソフトウェアモジュールの再利用についても同じことが言える。ソフトウェアを、再利用可能な形で設計したり、プラガブルなアーキテクチャに設計するコストが、そう設計することで得られるメリットを上回るというケースなど、いくらでもある(ようは、投資効果の問題なので、投資しろとか投資しすぎは禁物とかいう話じゃなく、トータルメリットとトータルコストを計算して投資しろという話)。とく小規模のWebサイトを、さっと作る必要があるときなど、その傾向が強い。余分な工数をかけて再利用可能だのプラガブルだのに設計したところで、あとから起
従うべきでないプログラミングのアドバイス10個 | 秋元@サイボウズラボ・プログラマー・ブログ
Top Ten of Programming Advice to NOT follow 新人プログラマーにアドバイスを求められた筆者が考えた、「聞くべきでないアドバイス」のリスト。 10) 例外は使うな(by Joel on Software 等) 9) 負にならない値には unsigned int を使え 8) 実世界に対応したクラスを設計せよ 7) チームでコード記法を統一せよ 6) コメントをたくさん書け 5) public フィールドよりアクセサメソッドを使え 4) 一個しかインスタンスができないなら Singleton パターンを使え 3) 入力は寛大に受け付け、出力は厳しくせよ 2) 最初から重箱の隅までプログラムせよ。後でやろう、は実行されない 1) コードを書く前に設計せよ 7), 5) は聞いてもいいと個人的には思う。10), 8) は僕も聞きたくない。3) は聞きたくな
三項演算子の正しい書き方
C・C++・Java・Perl などのプログラミング言語では、条件演算子として三項演算子?:が用意されている。条件演算子の書き方として、以下のような説明がされることが多い。 condition ? true-expression : false-expression この説明は、以下のプログラムと同じ程度、間違っている。 #include <stdio.h> main( ){printf ("hel" "lo, world\n" );} 条件演算子は、正しくは以下のように書く。 condition ? true-expression : false-expression 使い方の例を示す。 compare = obj1 == null ? obj2 == null ? 0 : -1 : obj2 == null ? 1 : obj1.toString().compareTo(obj2.to
「インデント」の反対は何というか？:プログラマー日記(2006-02-04)
This domain may be for sale!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://cappuccino.jp/keisuken/logbook/20060411.html
システム・エンジニアの基礎知識
IBM Developer
Amazon.co.jp: CodeZine傑作選 Vol.1: SE編集部: 本
