  |
はてなキーワード: aspとは
芸術性って・・・。
だったら言語から作れよ。
芸術性は見る人に訴求するものがあり、人によって解釈が違う。そういう定義の言葉だろ。
素敵すぎるだろそんなソース。
芸術をも感じさせるソースを見て、どうやったらこんな独自進化を遂げられるんだよと何度ヒザをついたことか…。
人を満足させるために作るのか、自分が満足するためにつくるのか。
自分を満足させるために作り出したものが結果的に人を満足させるということは殆どない。
だって最初のスタート方向が違うんだもの。
コーディングにポリシーはもっていてもいいとおもうけど、そのポリシーがアクションの枷になっているのだったら本末転倒だとおもうな。
どんな立派な機能があるクラスだろうが最初で弾かれて落ちてこないだったら意味ないじゃーん。
というかApp Engineってなに？
つかって何かやりたいとまだ思えてこない以前にApp Engineがまだ未チェック。
PythonはGMOの証券会社が外部APIを公開したのがPythonだった。うんこだった。
勉強するには至らなかったが、そんな特殊だったという印象はもってないな。
plのcgiがあって、そっからasp,jsp,cfmという時代をえて、
php5,RonR,Pythonとかになってきているわけだが、時代は違えどひとつ覚えておけば学習コストっていう意味は殆どかわらないと思うよ。Oracleを覚えてからSQL-serverにいこうがpostgresqlにいこうがmysqlにいこうが一緒みたいなもの。
後継に位置するものであれば必ず似た機能はある。
むしろiis-ocxとかtomcat-Servletとか、ns-ldapとかそういう周辺が違うのであって、
基本的な部分に収まっているあいだは殆ど一緒じゃない？
今の時代みたいに殆どがApacheごにょごにょしただけで動く時代ならphpもRonRも殆ど変わらないと思うな。
所詮LL。
いまだってデータ処理はDBに任せたり、画面だってjavaなりFlashにまかせるじゃん。
LLがクラスに対応したときはおお！！と思ったし、どんどん進化しているのは感じる。
そんな感じで、どんどん面白いのがでてくればいいとおもう。
言語なんてこだわりもって選らんだところで変遷は激しいよ。
コールドフュージョンがどれだけすばらしいかについてプレゼンしてた坊を思い出すたびに涙を禁じえない。
いい音楽が売れるんじゃない。
話題になる音楽が売れるんだ。
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
「ウェブを変える10の破壊的トレンド」著者 渡辺氏のインタビュー記事 世界にコンピュータが5つしかない時代がくる があまりにひどい。インタビューイの渡辺氏の発言が事実誤認だらけだというのもだが、それをスルーしている小川氏も本気でこれに同意してるとしたら見識を疑いたくなる。
2004年7月にJETRO経由でニューヨークにいきまして、IT部のディレクターという仕事をしていました。(略)たとえば、まだフィッシングという言葉がなかった時代に、クレジットカードの情報漏えいなどのプライバシーやセキュリティの情報を追いかけていました。
2004年7月にフィッシングという言葉が無かった? 日本語記事ですら 「電子メールのフィッシング攻撃が拡大，2003年の被害額は推定12億ドル」，米Gartnerの調査：ITpro というのがあるんだが。
日本にも優秀なエンジニアがいると思うんですけど、これは（Ruby on Railsの）松本さんがおっしゃってたんですけど
本を書くにあたって、なるべく事実に基づいて、事例を載せた本を出そうと思ったんです。ネットをみれば書いてある話なんですけど
いやー、本を書くならせめて裏をとろうよ。ネットの情報だけじゃなくさ。
たまたま生活圏がそうだったというだけなんでは。都市部のWi-Fi普及率は日本も米国も大差ないんじゃないかな。
新幹線の予約をしようとして、JRのサイトに登録しようとしたら、まずは専用のメンバーズクレジットカードを作れ、というんです。びっくりして、全部のJR系を試したら、JR東日本以外はみんなクレジットカードを作らないとサイトの会員になれない。
いやいや、JRのクレジットカードなんて作らなくても、少なくともJR東日本では新幹線の予約は手持ちの好きなカードで出来てますよ。帰国後の経験が浅い渡辺氏が勘違いするのはしょうがないにしても、記事にする前にインタビューア・編集部が裏を取ってフォローしようよ。
そもそもそれが可能になったのはソフトウェアデリバリの制約から開放されたASPないしSaaSでの特徴であって、欧米企業でもパッケージソフトやハードウェアをベータのままリリースするということは、少なくとも建前上は無いんだが…。
米国のケータイはしゃべる専用、単機能の文化なんだと思います。(略) ただ、iPhoneが出て、変わってきたかも知れないとは思います。アメリカでは革命的なんじゃないですかね。
この方、もともと日本の携帯電話を売り込みにいってたそうだけど、その人の知識がこれというのはちょっとどうなんだろう。Nokia や Samsung や Motorola や SonyEricsson の携帯電話にふれたことが無いんだろうか。Blackberry と言うサービス・端末を使っているビジネスマンと話したことは無いんだろうか。
世界にコンピュータは5つあればいい、とSunのCTOが言ったらしいですけど（Microsoft、Google、Yahoo!、Amazon、 Salesforceなど、クラウドコンピューティングの世界を指す）、IBMあたりはこの兆候にちゃんと気づいていると思うんですけど、日本メーカーは分かってないのかも、と危ぐしたりしています。
これを締めの言葉にするあたりで残念感が溢れすぎている。こういう方が公費で海外に長期滞在して帰ってきて講演して本を書くというのがIT企業人に受け入れられるなら、確かに日本のIT業界は危機敵状況にあるのかもしれない。
同意だよ。
初心者が本当に注意しなければいけないのは、スクリプトの脆弱性よりもサーバーのセキュリティ。
PHPなら大抵どこのレンタルサーバーも利用可能なので殆ど問題がない。
なにがいいって現段階においてはPHPは非常に多くの人に使われている。
だからもし見当違いなことをやっていたら注意してくれる人がいっぱいいる。
そして何よりも大きいのはサーバー運営業者などがノウハウを吸収しているということ。
PHPでシステムコマンドなんかは大体止められているしRFIなんかの攻撃に対しても不正なファイルが埋め込まれたりすたら通報してくれるところもある。
現段階のRubyでそれができるだろうか？
大手のレンタルサーバーでさえまだ設定があやふや。
そのままじゃ動かなかったりしている。
じゃぁ自前サーバーならいけるのかというと、正直初心者には無理なんじゃないの？
Mongrelあたりを入れて、あれ、これメモリ漏れてねぇ？とかそういう心配をしたり、24時間監視できるわけがない。
まだ「いいえ」なんじゃないの？
Rubyをちゃんとできる人や教えられる人はまだ少なすぎる。
PHPをぐだぐだ言うひとはちゃんとできるひとなのかな？
どうなのよ？
まあ異論はあるかもしれないが。。
あと、こっちは、一般的に同意をえられるとおもうんだけど、
スクリプトが垂れ流す脆弱性よりもroot権限のっとられたマシンの方が怖くね？
んでもって、遥かに有害だよね。
そんなに言うならSQLインジェクションの穴のひとつでも見つけて報告してごらんよ。
SQLインジェクションなんて、DBに接続ができるようなレベルになれば最近のマニュアル本には当たり前に書いてあるじゃない。しかもこれは何もPHPに限った話しじゃないじゃない。
穴なんて時間の経過とともに増えるんだから、メンテナンスされてないサービスのほうが怖いわけですよ。
ローカル言語やサーバー使ってそのままになってしまうほうが最悪なんじゃないかな。
もし、素人がぐだぐだにつくったPHPサービスとかで問題があるとすれば・・・
・SQLインジェクションで中の情報が漏れる（そんなサービスに漏れて大切な情報登録するなよ）
・メール送信系でヘッダー偽装でスパムの踏み台にされる（これは意外と多いかもしれないね）
・クローラーが他のサーバに負荷をかけまくる
まあどれもPHP”だから”というわけでもないよね。
97年頃にはperlだって掲示板やアップローダーだって穴だらけだったじゃない。
coderedがでるまでiisで建ってたサーバーだって山ほどあった。
そのころにはSQLインジェクションに対応していないサイトは本当に簡単に見つけられた。
初心者は主流からはいるのがいろんな意味でみんなのためじゃない。
今の主流はphpということでいいんじゃないの？
PHPは発展期
RonRは成長期（すくなくともあと1年ぐらいは）
perlは爛熟期
あとは・・・
pythonからColdFusionのにおいしてない・・・？
あと、なんかLLってあったっけ？
curlがなんかいまさらだけど脚光をあびるような予感がしている。
ところでさ、
PHPを批判しているような人はPHP6の仕様とかちゃんとフォローしてるのかね？
そもそも何かを作り上げることができる人というのは非常に少ない希少種なのに、
そこに入ろうとする前途ある人達のモチベーションを使用言語がどうこうと、
挫こうとするのはなんか憤りを感じるよ。
Matzみたいな人がそれをやってどうするんだよとか、ちょっと思った。
ので、その結果を貼ってみます。とりあえず、はてなブックマークが始まってから１ヶ月(2005/2/10〜2005/3/9,1033エントリ)の、ブックマーク数によるベスト１０を出しました。
ここで皆さんにお願いがあるのですが、今回のベストX以外にどういう観点でデータを抽出したら良いか（どういう一覧がほしいか）、コメントをいただけませんか？データは集めてみたものの、活用方法に困ってます。
====================
でした。
当時はまだ「有名サイトのトップページにとりあえず貼っておく」みたいな使われ方をしていますね。ブックマークをどう使うか、というスタイルを探していたんでしょうか。
「b:keyword:コンピュータ(330回)」「b:keyword:ウェブ(321回)」「b:keyword:一般(147回)」「b:keyword:はてな(77回)」「b:keyword:Google(67回)」「b:keyword:サイエンス(47回)」「b:keyword:blog(42回)」「b:keyword:ゲーム(41回)」「b:keyword:Internet Explorer(33回)」「b:keyword:はてなブックマーク(31回)」「b:keyword:RSS(30回)」「b:keyword:Microsoft(30回)」「b:keyword:JavaScript(29回)」「b:keyword:読書(28回)」「b:keyword:iPod(25回)」「b:keyword:firefox(25回)」「b:keyword:Apple(24回)」「b:keyword:ニッポン放送(23回)」「b:keyword:サービス(23回)」「b:keyword:音楽(20回)」
「b:t:web(88回)」「b:t:blog(65回)」「b:t:ネタ(59回)」「b:t:news(49回)」「b:t:はてな(42回)」「b:t:it(33回)」「b:t:hatena(33回)」「b:t:社会(30回)」「b:t:ニュース(28回)」「b:t:neta(27回)」「b:t:misc(26回)」「b:t:ajax(26回)」「b:t:tool(25回)」「b:t:software(24回)」「b:t:tips(23回)」「b:t:javascript(23回)」「b:t:ブログ(22回)」「b:t:まとめ(21回)」「b:t:livedoor(20回)」「b:t:google(20回)」
でした。当時から「ネタ」タグって多かったんですかね(タグやキーワードは現在の付与状況しか分からないので、当時の本当の状態が分からない)。
”ホームページ製作業者”でいいよね？
ASPサービス提供事業者も含めようとするから複雑になってるんじゃないの？
自分はもともとIT業界にいて今はなぜか商店街に所属してるんだ。
で、隣の芝生の青さがうらやましくなってweb屋ってたのしそうだなって思って辞めたの。
正直webなんてやってもお金になんかならなそうだなとおもったんで、
シノギがひつようだとおもって、お店ももったんだ。
商店街のおっちゃんたちの話しを聞いていると世間のwebというかITに関する認識はこんなものだと痛感しますわ。
いやね、おっちゃんたちっていっても青年団の人たちなんだけどさ。
”親父さん”たちはそもそもインターネット（以前にパソコン）になんか興味すらないから。
で、お店でパチパチとSOHOでソフトの受託なんかもやっていると、
商店街の爺たちからあの店主はパソコンで遊んでばっかりだと陰口いわれたりするんだわ。
ようやく最近わかってもらえるようになってきて、
「おたくパソコンの仕事しているならホームページ作ってよ」と言われるように成長しましたよ。
いや、まるでわかってもらえてないんだけどｗ
ホームページっすか！？みたいな。
難しいというかしても無駄というか……。
自分は自分のお店のホームページだったら作れるんだけど人様のを請負するのを仕事にしてないわけですよ。
今までそういう業務をしてきたわけでもないしデザインが得意なわけでもないしね。
第一たいしたお金になるわけでもないし、それなりにめんどくさいじゃない。
正直そこらの商店のページだってHPつかってなにしようってんでもなく事業目的があるわけじゃないんで、
大学生あたりにアルバイトでちょっとペラのページをつくってもらうぐらいがちょうどいいと思っているんだけど・・・さ。
もうね、なんていうか説明がめんどくさい。
次から次に同じようなことを説明しなきゃいけなくてね・・・。
自分が講師になってセミナーしたいとかそういうモチベーションもっちあわせていないんだけど、
さすがに「ホームページ製作をやるつもりは無いけどホームページは欲しい商店主のためのホームページ講座」
とかいうセミナーでもやらずにはいられないのではないかと思うぐらいめんどくささが先立ってきました。
というのも彼らの話しを聞いてちょっと義憤にかられてきたんですよ。
自分もお店をやっているのでわかるんだけど、お店やってると営業の電話がいろいろ掛かってくるわけです。
「ホームページつくりませんか？」ってね。
ひどいところなんか「ホームページみて電話してるんですけど」とか。
おまえ誰がつくったページかわかって喧嘩うってんのかと内心思いながらね。
「反響はどうですか？もっと反響集めたいとおもいませんか？うちはSEOを(ry」
そんな感じのマニュアルどおりの営業が展開されるわけですよ。
本当に山と・・・。
ひどいところなんか
「うちはYahooの代理店をしているんですが、今キャンペーン中で…(ry Yahoo!に登録しませんか？」なんてのもあるぐらいさ。
でねー…。
こういうのに引っかかるバカいるのかなとおもってたんですよ。
いやほんと。
でもね、
「うちは月々１万５０００円だよ。」
「うち２万５０００円。まあ電話一本で雨の日サービスとか画像いれてくれるから満足してる。」
なんて話が目の前で展開されてるのを見てさ・・・
動的部分が何もないHPに数百万かけたとか、ほんと…、ちょっと待ってくれよと。
このHPに月々…… えーーーー！！？ ちょっとほんとお願いだから待ってくれよと。
ただしホスティング費用が毎月**掛かりますとか。
サポートで…とか、
ほんと山ほどパターンがあるんですわ。
と商店主に何度言いたくなったことか。
もうやっちゃってるところには酷なので言えないんですが・・・
そういう業務をしているのがweb屋ということなのかな？
ユーザー教育じゃないけど、ほんと早急に手をうたねばと思ったよ。
デザインの手間とかバカにならないし、メンテナンスまで面倒みきれないので、
自分はホームページ製作業をやるつもりはないんだけど・・・
商店街の中でバイト５??６人囲ってまわせば済む話しじゃんね・・・。
そんなわけで、だれかバイトでホームページとかつくりたい子いない？
つか、ほんと・・・もう、なんとかしたい。
前時代的な職業っていういうけど、なんていうか日本ではそれが全盛期ですよ。
ちょっとほんと助けて。
あと、ちょっとこれの反論まじえとく。
http://d.hatena.ne.jp/waseda23/20071225/1198573722
自分がSOHOなので弁明するけど、SOHOを地方って括っちゃいけないよ！
あと、SOHO同士でアライアランスくんで億単位の案件も食えるように準備してるんだぜ。
（・・・成功するかは知らん。）
PHPが馬鹿にされる一番の要因ともなっているんだけども、セキュリティの「セ」の字も理解していない「なんちゃってプログラマー気取りのwebデザイナー（？）」が、XSS,SQLInjection,CSRF,SessionHijack等々考えうる全ての脆弱性を垂れ流してるのはどういう訳？
考えうる全ての脆弱性を垂れ流してるのは別に垂れ流したところで問題ないような情報しか扱わないからでは？
さすがにカード番号とか扱うような業者でそんなところはないんじゃね？
あんの・・・？（なんかありそうで怖くなってきた…）
ま、それは発注側の意識が前述のレベルなので…本末転倒ですがユーザー教育が急務です。
らしいね。
でも正直日本国内にはいってきているインド人は相当少ないのでまだ数年は平気かな。
今の日本の仕事のやりかただと開発室の一部をカレー臭くするぐらいの働きぐらいしかできないとおもう。
オフショアというか呼んで来てるだけだしｗ
それよりも今の日本において深刻さをましたのは中国だとおもう。
ほんとその通り。
ずいぶん単価はあがって日本の1/2-1/3ぐらいなんだけど、かなり質があがってきているらしい。
一時期日本でどっぷり開発していた連中が帰国したからかもしれない。
多分同価格で捜すより中国に出したほうが楽というところまできてると聞くようになった。
自分も何か損害かぶれるぐらいの案件があったら一回試してみたいとおもってる。
オフショアブリッジの人に聞くと、日本のカレンダーに合わせてくれるし、日本語ができるひとが会社に1人以上いるそうだ。
スカイプで進捗の日時確認ができて、緊急の場合には携帯に電話が掛かってくる。
インドかー…。
昔いったときは市民レベル的に中国よりも30年ぐらい遅れてるとおもってたのでこの速度は予想外。
昔はムンバイとかの方だけだとおもってた。南のほうの人は質がすこし違うのかもしれないね？
さすがにインドに対してはあと数年はアドバンテージがあると信じたい。
日本人が英語が無理っていうのはあるいみマルチバイト鎖国の成功。
絶対違う
デリヘル向けの業務システム（ASPで運用を前提）を作ってみようかなと思うことがある。色々考え、ある程度用件を確定すると、「ハテナ？」と思うことがある。店（経営者）いらない。投資しないし、商品開発しない、性病対策も女の子任せ。スケジュール管理と電話番しかしない。だから業務システムの作りによっては電話番しかいらなくなる。電話代行は月15,000位で電話番してくれるしね。
いや、今思いついた、業務システムもいらない。女の子がblog立てて個人営業すればいい。料金、OK-NGをプロフィールとして書けばいい。スケジュールはアーティクルとして書けばいいし。電話代行の電話番号さらせばいいし。しかも、月15,000しか抜かれない。
で、デリ好きの人がソーシャルブックマークでXX系（ロリ系、熟女系）などのジャンル付けした物作れば仮想店舗ができあがる。
システム作り（blogの作り方、書き方。電話代行に渡すスクリプト）のノウハウをWiKiにまとめれば、ビジネスが転がり始めるかも。
perlで提供されてるサービスにphpユーザーはつかないのかもしれないね。
はてな界隈だとrubyは話題になっててもそれを扱う人をちゃんと評価できているとも見うけられないし。
いや、居るんだよ。php使いもruby使いもPython使いも。
だって増田にだってたまに湧くじゃない。
はてなダイアリーのユーザーだって、おーと思うようなruby使いとかもいるんだけどね、
でも発言権のあるユーザーにはなりえてない。
http://rails.drecom.jp/award2007
例えば、ここで受賞しているユーザーでaspブログサービスを利用しているユーザーの殆どがhatenaユーザー。
だけど、ここにでてくるような人達がホットエントリーに並ぶことはない。
あと１年ぐらいはdankogaiの天下だし、perl使いの天下なんじゃないかな。
でもperlの案件なんて最近（というかずっと昔しから）殆ど無いとおもうんだけどね…。
IT業界の12兆円の市場規模からしたらon webのコンシューマーなんてほんと微々たるもののはず、
でもそこだけしか注目が集まらない。
つまりはそういうことなんじゃないかな。
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/kyoumoe/20071221%231198247993
これをみて思った。
この人の実名うんぬんが削除されないのって、
これを削除すると、このひとのクレームを処理するよりめんどくさい人がクレームをあげるからではなかったか？
この元増田のかき込みをみておもった。
なんかわからないけどさ、運営が真実がどーだとか確認なんかしようがないんだから、
非難や悪意が読み手がわにすこしでも伝わるような内容であれば、
まるっと削除してもいいんじゃないの？
そういうサービスですってことで。
難解だが愉快なスパゲッティコード
こないだこんなのがあったんだぜ？
というような話題話しにはできても、愉快だったためしは一度もない。
助けてくれ！というどう考えても死亡フラグのヘルプに駆けつけたことがある。
某メーカー子会社だ。コードスタイルを見るに多分以前はコボルとかをやっていた連中だと思う。
コードを見てこれほど唖然としたことはない。
言語は…なんだったかな…時代的にaspだったような気がする。
コードを見て泣いた。functionのひとつもありはしない。
一晩の徹夜の後、3000行あったコードは300行になっていた。
難読すぎてスパゲッティーを解いた結果がこれだ。
何か機能を盛り込み忘れたのではないのかと目をゴシゴシした。
10人ぐらいをつっこんで数十の主要なコードを直した。
目をごしごしして２日間の貫徹だ。
成果物はなぜかボリュームが減っていた。
普段だったら絶対に許されない修正方法だが、
緊急に緊急を要したためコードを見てからの説得はかなり強引だった。
ただのスパゲティは修正するのがムリだと判断したからだ。
このプロジェクトを進行した連中の無駄な努力をただ恨みながら。
自分のところのメンバーであんなコードを生み出されちゃ適わない。
他の協力会社にもずいぶん口うるさくいうようになった。
君が苦労して実装しているところは既に＊＊が＊＊で実装している。
こういうだけで相当数工数が稼げた。
部品にしておけばみんながそれを利用できるからだ。
1人で組み上げるならいくらトリッキーでも構わない。
2人以上でやるならルールを作れ。
話しはそれからだ。
http://anond.hatelabo.jp/20070906231939
返事がもらえた。とてもうれしいです。
そうだね。何をやろうかな？Web系ならPerlとRubyとPHPとASPとRDBなら扱ったことがある。でも最近ほとんど使って無いからかなり能力がさび付いていて、最初は役に立てないかもしれないけど、がんばりたい。仕事のプログラムに疲れたら遊びのプログラムをする、やのさとるさんみたいに僕はなりたいと感じます。せっかくITが今ものすごく面白いことになっているのに、これを黙ってみているだけなのは本当にもったいない。
PHP やってる人間は確かにどうしようもないのも多いのだけどそれは Perl だって一緒だろ？ホントにどうしようもなかったらみんな使ってないって。考えても見ろよ？PHP なかったらみんな ASP か ColdFusion か JHTML（なんて誰も覚えてなさそう…）だぜ？何にも出来ない度は PHP の比じゃないっての。おかしいならおかしいなりで、スマートな人間はなんとかやりくりしてんだよ。だいたいそこまでおかしくない。
あとあれだ。間違いは徹底的に認めない。っていうか、なんか間違った事いっても、あんまり興味ない事だったら、何気なくスルーしてる。文句いってきた相手にもよるけどな！自己顕示欲強すぎ。
きみがそんな書き込みをするから見に言っちゃったじゃないか。
そして思わず' -- で検索しちゃったじゃないか。
Database Results Error Description: [Microsoft][ODBC dBase Driver] クエリ式 '(タイトル LIKE '%' --%' AND タイトル読 LIKE '%%' AND 記事種別 LIKE '%%') ORDER BY 雑誌ID ASC,開始 ASC' の 構文エラー Number: -2147217900 (0x80040E14) Source: Microsoft OLE DB Provider for ODBC Drivers One or more form fields were empty. You should provide default values for all form fields that are used in the query.
くそテキストがたまに日本語名でやってるのあるけど、ほんとにやりやがった！
やっぱりLike検索なんだろうなとは思ったよ。
SELECT * FROM 雑誌 WHERE (タイトル LIKE '%::タイトル::%' AND タイトル読 LIKE '%::タイトル読::%' AND 記事種別 LIKE '%::記事種別::%') ORDER BY 雑誌ID ASC,開始 ASC
入力してない項目にまで検索を掛けているのはどういうわけか。
もちろんindexなんて貼ってるわけないんだろうな。
aspか。なんか懐かしいな。
可哀相だからここまでにしておく。これ増田の良心。
おまえらも絶対insertとか流すんじゃないぞ？
'/** Requestオブジェクトから受信したデータを取り出します。 ' * @return byte配列を格納した連想配列を返します。 ' */ Function getRequestItem() If Request.TotalBytes <= 0 Then getRequestItem = Null Exit Function End If Dim data Dim separator Dim dataArray Dim buffer Dim filePath Dim fileName Dim ix Dim stringIndex Dim myCrLf Dim items Dim itemName myCrLf = convertAsc(vbCrLf) Set items = Server.CreateObject("Scripting.Dictionary") data = Request.BinaryRead(Request.TotalBytes) data = LeftB(data, UBound(data) - 3) & myCrLf separator = MidB(data, 1, InStrB(1, data, myCrLf) + 1) dataArray = SplitB(data, separator) For ix = 2 To UBound(dataArray) Step 1 '1行読み込み buffer = MidB(dataArray(ix), 1, InStrB(1, dataArray(ix), myCrLf) - 1) 'アイテム名の取得 stringIndex = InStrB(1, buffer, convertAsc("name=")) If stringIndex > 0 Then itemName = convertUnicode(MidB(buffer, stringIndex + 6, InStrB(stringIndex, buffer, ChrB(34)) - stringIndex)) Else itemName = "" End If 'ファイル名の取得 stringIndex = InStrB(1, buffer, convertAsc("filename=")) If stringIndex > 0 Then filePath = MidB(buffer, stringIndex + 10, InStrB(stringIndex, buffer, ChrB(34)) - stringIndex) fileName = RightB(filePath, LenB(filePath) - LastInStrB(0, filePath, convertAsc("\"))) Else fileName = "" End If 'データ部の取得、改行コードの切り捨て buffer = RightB(dataArray(ix), LenB(dataArray(ix)) - InStrB(1, dataArray(ix), myCrLf & myCrLf) - 3) buffer = LeftB(buffer, LenB(buffer) - 2) items.Item(itemName) = parseBytes(buffer) Next Set getRequestItem = items Set items = Nothing End Function '/** 文字列の最後尾から指定文字を検索します。 ' * @param Start 検索する開始文字位置を指定します。 ' * @param String1 検索対象の文字列を指定します。 ' * @param String2 検索する文字列を指定します。 ' */ Function LastInStrB(ByRef Start, ByRef String1, ByRef String2) Dim ix Dim lastIndex Dim searchLength searchLength = LenB(String2) lastIndex = LenB(String1) - searchLength + 1 If Start > 0 And Start < lastIndex Then lastIndex = Start End If For ix = lastIndex To 1 Step -1 If MidB(String1, ix, searchLength) = String2 Then LastInStrB = ix Exit Function End If Next LastInStrB = 0 End Function '/** アスキー文字列に変換します。 ' * @param String 対象の文字列を指定します。 ' */ Function convertAsc(Byref String) Dim ix Dim ascii ascii = "" For ix = 1 To Len(String) Step 1 ascii = ascii & ChrB(AscB(Mid(String, ix, 1))) Next convertAsc = ascii End Function '/** Unicode文字列に変換します。 ' * @param AscString 対象のアスキー文字列を指定します。 ' */ Function convertUnicode(Byref AscString) Dim ix Dim unicode unicode = "" For ix = 1 To LenB(AscString) Step 1 unicode = unicode & Chr(AscB(MidB(AscString, ix, 1))) Next convertUnicode = unicode End Function '/** バイナリ対応版Split関数です。 ' * @param String 対象の文字列を指定します。 ' * @param Delimiter 区切り文字を指定します。 ' */ Function SplitB(Byref String, Byref Delimiter) Dim ix Dim lastIndex Dim searchLength Dim start Dim datas() Dim dataIndex dataIndex = 1 start = 1 delimiterLength = LenB(Delimiter) lastIndex = LenB(String) - delimiterLength + 1 '最初から1文字ずつ繰り返します。 For ix = 1 To lastIndex Step 1 'データを比較します。 If MidB(String, ix, delimiterLength) = Delimiter Then 'データを取り出せたら配列に格納します。 ReDim Preserve datas(dataIndex) datas(dataIndex) = MidB(String, start, ix - start) dataIndex = dataIndex + 1 start = ix + delimiterLength End If Next SplitB = datas End Function '/** Byte配列を返す関数です。 ' * @param data 対象のデータを指定します。 ' */ Function parseBytes(Byref data) Const adLongVarBinary = 205 Dim recordset If LenB(data) <= 0 Then parseBytes = CByte(0) Exit Function End If Set recordset = Server.CreateObject("ADODB.Recordset") recordset.Fields.Append "UpLoadBinary", adLongVarBinary, LenB(data) recordset.Open recordset.AddNew recordset.Fields("UpLoadBinary").AppendChunk data recordset.Update parseBytes = recordset.Fields("UpLoadBinary").Value recordset.Close Set recordset = Nothing End Function
