C++では基底クラスにvirtualデストラクタを書こう - ＊「ふっかつのじゅもんがちがいます。」withぬこ
(追記あり/再追記あり) ブクマ経由で、C++で演算子オーバーロードしたときの演算子決定基準について調べたというのを見たのだけど、書いてあるサンプルコードが演算子オーバーロード以前にちょっとダメだった。 昔書いたテストコードと書いてあるので、今は分かってるのかもしれないけど、ある程度経験を積んだC++プログラマは絶対に(というのは言いすぎでした)virtualデストラクタのないクラスを継承しない(追記やTBやブコメの議論を参照のこと)ので、このサンプルコードを載せて違和感を感じない時点で、演算子オーバーロードをいじるよりもまずはEffective C++を読んだ方がよい。 何がダメか。以下のように、virtualデストラクタがないクラスを継承している。これはダメだ。例え基底クラスのデストラクタですべきことがないのだとしても、継承するつもりのあるクラスにはvirtualデストラクタを作らない
[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
![[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ](https://cdn-ak-scissors.b.st-hatena.com/image/square/abd76f3bb0ec0750428a791cbfbf7959c317f97d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127052840568%2F17680117127052842215%2F1555633900)
＊いしのなかにいる＊ - ＊「ふっかつのじゅもんがちがいます。」
最近ECナビの商品検索を作り直したりしてたりする。まあ現状のものがあまりにアレなのがすごくアレなだけに、今作ってるのがリリースされたらかなりまともになったりするのだけど、そこはどうでもいいというか、今言いたいことはそこではない。 それ作るために色々今の検索ワードの統計とか見たりするのだけど、クイジナートなるフードプロセッサが検索されているのを見てショックを受けるわけだ。 クイジナート、というか我々にはカシナートと言った方が通りがよいそれは、本当は有名なフードプロセッサのメーカーな訳だけど、問題はそこではなく、我々にしてみればそれはフードプロセッサではなく名刀であり、Blade Cuisinartであり、中学生の頃にBlade Cuisinartというのは別に名刀でもなんでもなく、アメリカでは有名なフードプロセッサのもじりなのだということを知ったときの衝撃を思い出したりするわけだけど、僕にと
他の言語版accumulate - ＊「ふっかつのじゅもんがちがいます。」
JavaScript function accumulate(func, initial, ls){ var ret = initial; for( var i=0, len=ls.length; i<len; i++ ){ ret = func(ret, ls[i]); } return ret; } accumulate(function(x, y){ return x + y; }, 0, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]); accumulate(function(x, y){ return x + y; }, "", ["a", "b", "c"]); python http://codepad.org/npr7BfQ6 # -*- coding: utf-8 -*- #自分で書く必要はない print reduce(lambda x, y: x +
ブログ引越しを計画中 - ＊「ふっかつのじゅもんがちがいます。」withぬこ
Twitterを使い始めて、Twitterブログパーツを張りたくなった。 はてなダイアリーは設計上未来永劫javascriptやフラッシュを設置できないと思うので、引越しを検討することにした。 そもそもBuzzurlのブログパーツやブクマボタンとかも張りたいし、ちょっとしたjavascriptとかをブログにそのまま書きたい。 従ってRFPは以下 テンプレートが任意にいじれること（ブクマボタンを設置できること） javascriptを書ける/置けること なるべくなら無料で独自ドメインを使えること なるべくならMT形式の過去ログをインポートできること なるべくならMT形式で過去ログをエクスポートできること アメブロは僕のスペックを一つも満たさないのでそもそも対象外。 ライブドアブログは３つ目がダメだった。 seesaaは惜しかったけど、ここの過去ログをインポートしたら日付がおかしくなった。 と
＊「ふっかつのじゅもんがちがいます。」 - Windows Live Carolとかいうブラクラを無効にする裏技
最近特定のサイトを閉じたときにSleipnirがディ・モールト(非常に)よく固まって、「Out of memory」とかダイアログが出るなあと思っていた。 例えば下記サイトをSleipnir2.5.9で見て、タブを閉じようとするとメモリを食い尽くすまでSleipnirが固まる。（なお固まる現象は素のIEやFirefoxでは再現しない。IEコンポーネント系のタブブラウザ全般やられてるかもしれないけど、調べる気はない） http://blog.livedoor.jp/dankogai/ http://www.chikawatanabe.com/ http://www.future-planning.net/x/ 共通点として、Windows Live Carolとかいうブログパーツが貼ってあることに気づいたので、ためしにこいつを読み込まないようにしたら固まらなくなった。 このブログパーツのjs
ソースを読めない人はgreasemonkeyを使ってはいけない - ＊「ふっかつのじゅもんがちがいます。」withぬこ
追記：この記事はgreasemonkeyがそんなに安全なものではないことを訴えるために、あえて極論を述べています。いわゆる釣りです。http://d.hatena.ne.jp/ajiyoshi/20060502/p2もあわせてご覧ください http://diary.yuco.net/20060501.html#p01 http://blog.livedoor.jp/tanahata/archives/50833757.html ここいらを見ていて気になったので。 greasemonkeyスクリプトは危険なことができるので、自分でソースを読んで安全性を確認できる人以外は使用しないでください ということを啓蒙するためのgreasemonkeyスクリプトを書いてみました。(直リンがジオに蹴られるぽいので、IEの人の用のリンクつけました。IEの人がグリモンスクリプトを見るのか非常に疑問ですが) h
Geek脳の恐怖？ - ＊「ふっかつのじゅもんがちがいます。」withぬこ
http://deztec.jp/design/05/11/26_geek.html http://deztec.jp/design/05/11/27_geek.html http://deztec.jp/design/05/11/29_geek.html 驕りや思い込みで8割の消費者が見えなくなっては確かにまずい。高みから技術を消費者に押し付けるなど技術者の自慰にすぎません。むしろ理想はRSSの認知度12%、使用率4%にも関わらず、27%もの人がそれと知らずにRSSを使っていたなんていう状態でしょう。消費者が受け取るものは技術や商品ではなく、ベネフィットと満足感であるべきです。 （自戒を含めて）結論には納得できるのですが、各論がものすごく引っかかります。 カトゆー家断絶の閲覧者がはてなブックマークのトップページの利用者よりも多い理由は、ハッキリしています。ソーシャルブックマークの利用者が
設計を流用したクローンプログラムを作ることはパクリではない - ＊「ふっかつのじゅもんがちがいます。」withぬこ
ただし元の設計なりアルゴリズムなりが特許等で保護されていない限りにおいて。 http://ch.kitaguni.tv/u/116/weblog/0000237260.html JUGEMの設計構造をそのままパクったWeblogツール「sb」が、許可無くライセンス料とか取って商売してることについて、以前俺は「道義的にどうなのか」と書いて作者サイトにTrackback打っといたことがある。 (中略) sb自体はJUGEMがサーバ重くて死にそうなときに多くのサイトを救出したし、創造性を削らない、「イイパクリ」として評価していた。 しかし、これは俺はよくないパクリに思える。JUGEMのpaperboy&co.の思惑は分からないが、開発費書けて設計したソフトウェアなわけです。その構造から全てそのままクローン的に作ったソフトを売って商売されたら、そりゃ普通ソフトウェア作家としては納得いかないと思いま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ロジテックのページに各種ソーシャルブックマークへのリンクがついた件について - ＊「ふっかつのじゅもんがちがいます。」withぬこ