2010年06月24日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1クロールとDoSの違いと業務妨害罪と[法律][無断リンク][電子自治体] このエントリーをはてなブックマークに追加

#Librahack[http://twitter.com/search?q=%23librahack] の議論。多く登場する「スクレイピング」と書こうと思ったけれども、クロールで得たHTMLの後処理がスクレイピングだから、ここでは「クロール」対「DoS」とした。
そもそも、クロールとDoSは行っている側の目的に決定的な違いがある。
クロールを行う際は、クロールによって相手サーバの情報を取得することが目的だ。そのために、リクエストに対する応答を受け取って、そのまま保存するなり、何らかの加工(スクレイピング)を行って、情報を保存する。 情報を得るのが目的だから、サーバが落ちるのは困る立場だ。
一般的な作りとしては、ページのリクエストを出して、結果を受け取ったら、その場で解釈して、次にリクエストを出すページを決めるか、あるいは予め予定している次のページのリクエストを出す。この間に待ち時間を入れる。例えば、 1秒に1リクエストといった、一定間隔でリクエストを出す様な実装は、まずしない 。そういう風にクローラを実装するのは、難しい上に、トラブルを引き起こしやすいからだ。問題のスクリプトも リクエストは同時に複数送信しない、リクエストの応答が返ってきてから次のリクエストを送信する[http://librahack.jp/okazaki-library-case/stress-test-thinking.html] 構造であると言う。
一方、DoSは、サービスを妨害するのが目的で行う行為だ。一般的なサーバでは、ページを取得し続けるだけでサーバ停止することは無いから、ページを大量に順次取得することによってDoSを達成しようとするのは効率が悪い。
複数のプロセスを使って頑張っても、自分の回線の下り帯域幅を埋めるところまでで限界が訪れるし、Webサーバ側は能力を他のクライアントにも分配するから、他のクライアントは遅くなるとはいえ、サービスを受けることができる。
そこで、 DoS攻撃する立場に立つと、他の利用者と同じ様に結果を受け取る必要はない のだから、結果はそもそも捨てて掛って、応答を待たずに次のリクエストを送出してしまえば、より負荷を掛けることができる。
いわゆる F5アタック[http://ja.wikipedia.org/wiki/DoS%E6%94%BB%E6%92%83#F5.E3.82.A2.E3.82.BF.E3.83.83.E3.82.AF] でも、サーバの応答は待たないし、 もっと効率的にとなると、TCPレベルでFIN送らずにコネクション切って次のリクエストを出すとか、何らかの方法で第三者に間接的にリクエストを出させると言ったテクニックを駆使することになるが、いずれにせよ、結果を受け取る必要が無いから取り得る方法だし、ピンポイントでサーバの不具合を突くにしても、DoSが成功すれば、自分も情報が得られなくなるという結果は共通している。
ところで、サーバ管理者は、「DoSの様なクロール」というたとえをすることがあるが、やっていることがクロールだと理解した上で「DoSの様」と言っている。
サーバ側から観測した時に、相手が行っているのが過剰なクロール *1 か、あるいはDoSなのかは、Webサーバのログでも大体見当は付く *2 し、パケットキャプチャして、TCPセッションを時系列にグラフ化してやれば、まず間違いなく *3 DoSを行っているに違いないと断言できる記録が得られるに違いない。
従って、今回のケースにおいても、被害届を出す前に、ログを子細に確認するか、あるいは警察が捜査の過程でログを解析していれば、 過剰なクロールを行われた結果、サーバ停止に至った。 という結論が得られていたか、逆にDoSと判断したのであれば、DoSであることを立証するに足る証拠集めをサーバ側で行う必要があった *4 筈である。
それらの手続きを行わずに、逮捕に至った事は非常に残念だ。 業務を妨害しようとしているに違いないという予断があったのか、とりあえず逮捕して自白を取りさえすれば公判が維持できると考えたのか、警察や検察の判断の根拠にも関心がある。

無断リンク禁止教に新宗派、無断クロール禁止教:

robots.txtに従わなかったこと[http://www.nantoka.com/~kei/diary/?20100526S2] が問題なのか。この点に関心を持っている。
例えば、Webサーバの利用規約に「スクリプト等による自動アクセスは、業務の妨げになるため行わないこと」と書いてあって、実際、このサーバは自動アクセスされると落ちてしまう様なサーバだったとすると、これに反してクロールし、業務が妨げられた場合には、業務妨害罪を構成するのだろうか。robots.txtに書いてあった場合はどうだろうか。
刑事上の判断はさておき、民事上の問題も考慮すれば、一般的な利用者はクロールをためらうだろう。
この議論、変な方向に行くと 無断リンク禁止教[http://www.nantoka.com/~kei/diary/?20050203S3] に新宗派ができて、自治体のシステムを作る時のテンプレとして、自動アクセス禁止を利用規約に盛り込んだり、robots.txtで全てのクロールを禁止したりという事が行われるようになったりしないかと危惧している。
ロボットによるクロールは、知る権利の保証を裏付けするために一定の役割を果たしている。普通の人は辿りつけない様なページに「公開」することで、「Webで公開しているから、情報公開の責務を果たしている」と言う主張を認めても良いものだろうか。

三菱図書館システム MELIL/CS[http://www.mdis.co.jp/case/city-okazaki/200908.html]:

この図書館、 三菱電機インフォメーションシステムズ[http://www.mdis.co.jp/] 社内で 論文[http://www.mdis.co.jp/company/techpaper/2009/0907_melil.pdf] になる程の、素晴らしいシステムが利用されている様で、 このシステムは、 全国多くの図書館で利用されている[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil]
これだけの図書館で利用されながら、今回の様な問題が生じなかったということは、恐らく、Webのフロントエンドをカスタマイズする際に、何らかの手違いがあったのだろう。 いくらなんでも、この品質のパッケージを全国で展開していて、問題になっていないとは考えにくい。
確認した限りでは、岡崎市立図書館だけが、 件の謎の挙動[http://www.nantoka.com/~kei/diary/?20100621S1#T201006211S1] を示すようだ。

7月14日追記:

岡崎市立図書館だけではなく、検索文字列に依存したものでも無いことが分かったので、 続・クロールとDoSの違いと業務妨害罪と[http://www.nantoka.com/~kei/diary/?20100714S1] として、続報を書いた。
*1: サーバにとって過剰。クローラは欲張っているに過ぎない。
*2: DoSの場合、明らかに応答を受け取れないだろうという間隔でリクエストを発行してくる様な特徴がある。効率的な攻撃を行った時ほど、特徴は現れやすい。DDoSはやや見分けにくいかも知れないが、何かが進行中ということについては分かりやすいだろう。
*3: 間違いがあるとすれば、複数プロセスあるいはスレッドを駆使して、TCPを自前でしゃべる様な特殊なクローラを実装しようとした人が、ローカルでテストをせずに他人のサーバにアクセスしたといった、かなり申し開きが難しいケースだろう。
*4: もちろん、利用者のアクセスのプライバシーに対する十分な配慮が必要になるが。

■ 関連記事

詳細はこの日の詳細から

2005年06月24日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 NTT、ミゾのないネジが回せるドライバーを開発[http://www.asahi.com/digital/nikkanko/NKK200506030004.html]次の記事 >> このエントリーをはてなブックマークに追加

どういう仕組みかと思ったのですが、
開発したドライバーの素材には電圧の大きさによって膨らんだり縮んだりする特殊なセラミックスを使用した。この膨張する動きを回転運動に変える。ドライバーの回転体は平らなネジの頭に接触すると、摩擦を利用して引っかくことでネジが回る。ネジ自体は特殊な材質を用いていない。回る強さは押しつける力に比例する。
圧電モーターと似ている原理ですね。面白い。

■ 関連記事

■2 三菱電機、Winnyによる発電所情報の漏洩事件について会見[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8134.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ニュースリリース[http://www.mitsubishielectric.co.jp/news/2005/0623.htm] (pdf)[http://www.mitsubishielectric.co.jp/news-data/2005/pdf/0623.pdf]
社員が情報をHDDに入れて持ち出した点については、「規則ではデータの社外への持ち出しは原則禁止としており、社外に持ち出す場合には上司の許可が必要となっていたが、こうしたルールの徹底が欠けていた」と述べた。
というルールが徹底できるのならば、
「データの暗号化や社外への持ち出しを防ぐ技術や製品などを三菱電機でも開発しているが、社内で使用されていなかった点について反省し、こうした技術の採用も含めて管理を徹底してきたい」
という製品は存在意義が無いのでは無いか。「ウチだけは大丈夫」意識が引き起こした事故と言えよう。

Winnyで原子力発電所の内部情報が流出[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8124.html]:

Winnyを業務に使用した例としては、 秋田県湯沢市[http://www.nantoka.com/~kei/diary/?200504b&to=200504151#T200504151] のケースが有名だが、
同社広報によると「実際にWinnyをインストールし、指摘されたものと思われるデータをダウンロードした。現在は、MPE社員のPCに保存されていたデータと、Winnyからダウンロードしたデータを照合しているところだ」という。
こちらは、確かに業務で使う必要が認められそうだ。

ファイル交換ソフト使用上の注意事項について[http://www.ipa.go.jp/about/press/20050623-2.html]:

ということで、IPAから ファイル交換ソフト使用上の注意事項[http://www.ipa.go.jp/security/topics/20050623_exchange.html] が発表されています。 (プレスリリース)[http://www.ipa.go.jp/about/press/pdf/050623Press2.pdf]
恐らくですが、99%以上の職場では一般ユーザーがファイル交換ソフトをインストールする必要は無いはずなのですが、意外と入っているものの様です。漏洩事件が発生して大きく報道されるケースがこれだけあることを考えると、根拠無く「ウチは大丈夫」と考えるのには無理があります。
ネットワーク管理者がトラフィックを継続的にモニターしていれば、気づくことなのでしょうが、勤務時間外にセットして帰る様なユーザーもいたりするので注意です。

■ 関連記事

■3 新手法「Ajax」登場を機に見直し迫られるWebの操作性[http://itpro.nikkeibp.co.jp/free/NC/TOKU2/20050621/1/][Ajax]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

本誌で先に読んだ。日経コンピュータの様な比較的一般向けの雑誌で特集が組まれた事が興味深い。
全体としてリッチクライアントはまだ普及しているとは言いがたい。野村総合研究所が、無作為抽出した2000社を対象に昨年実施した調査(有効回答数は 275社)によれば、企業システムのクライアントのうち、リッチクライアントの割合は14.4%。HTMLクライアント(Webアプリケーションのクライアント、30.5%)やファット・クライアント(C/S型システムのクライアント、39.4%)の半分以下だ。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.64.
の理由として、
リッチクライアント製品の機能がまだ不十分、ベンダー依存にならざるを得ない、ライセンス料金が発生するといった点が挙げられる。だが、大きいのは「Webアプリケーションの使い勝手に対する問題意識を持つ企業が少ないからだ」と、カールの古賀実 取締役は指摘する。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.64.
としているが、実はもう一つ大きい視点がある。
広く一般に利用されるためのシステムの作成にリッチクライアント製品を採用した場合、リッチクライアント製品のセキュリティ上の問題に関して責任が生じる。
リッチクライアントはWebページからインストールした時点で、通常のアプリケーションとして動作するため、利用者のローカルディスクの内容を盗み出したり、書き換えたりすることを含むあらゆる操作が可能となる。
このため、リッチクライアントの端末への導入は、
1)リッチクライアント環境そのものにセキュリティホールが存在しないこと
2)リッチクライアント上のアプリケーションの作成者に悪意がなく、信頼できること
3)リッチクライアント上のアプリケーションにセキュリティホールが存在しないこと
という条件を満たした場合にのみ安全であり、一部の製品に見られる署名やサンドボックス的なアプローチを用いても、1,3を保証することは不可能である。
何らかのサービスを提供するサイトがリッチクライアント製品で構築されたアプリケーションをインストールさせた場合、ここで導入したリッチクライアント製品あるいはリッチクライアント上のプログラムにセキュリティ上の欠陥があって、これが第三者に悪用され、利用者の個人情報が盗み出された場合、リッチクライアントを導入することを要求したサイトは、責任を追求される可能性がある。
また、リッチクライアント自体にセキュリティホール等が発見された場合、利用者がアップデートを行う必要があるが、新たなプログラムを導入したという意識が薄いこともあり、アップデート情報を把握して、アップデートすることを利用者に期待するのは難しい。
さらに、リッチクライアントの導入を要求することが一般化すると、フィッシング詐欺等の手法によって、継続的にユーザの情報を盗み出したり、特定のサイトを攻撃するDDoS攻撃に悪用される様な機能を持つ、悪意のあるプログラムを送り込む犯罪が発生する危険性がある。
これらの被害は、リッチクライアントを用いてサービスを提供しているページに留まらず、リッチクライアントが導入されている限り、常に発生しうる。
広く一般の利用者に対するサービスでのリッチクライアントの採用には、この様なセキュリティ上の問題がある。
とある提案書から抜粋, MAEDA Katsuyuki, 2005年3月31日
この様な問題を考えた時に、安全性が客観的に確信できるAjaxのアドバンテージは大きい。
一方、Ajaxの課題としては、
Ajaxは、料金がかからないという意味では敷居が低い反面、開発環境が整っていないという点では敷居が高いとも言える。
新手法「Ajax」登場を機に見直し迫られるWebの操作性, 『日経コンピュータ』, 日経BP社, 2005年6月27日, pp.67.
が挙げられるだろう。
ビジネスロジックとhtmlの他に、JavaScriptとも整合性を取りながら開発を進めるとなると、フレームワークの重要度が増してくる。
今年も半分になったけれども、「Webアプリでのフレームワークの必要性が注目される」の予言が実現しつつある。

■ 関連記事

■4 [FreeBSD-users-jp 85444] Linux との違い?(ディスク高負荷)[http://home.jp.freebsd.org/cgi-bin/thread?mesid=%3c018701c576e7%24bfb06aa0%247d03a8c0%40morimotoPC%3e][freebsd]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ウチで運用しているサーバのほとんどは、FreeBSDを導入しているのだけれども、開発用にLinuxを使うと高負荷時の操作性が落ちる感じがあって、これはチューニングに問題があるのかなぁと思いつつ諦めて使っていたのだけれども、実際仕方がないことらしい。
この日記を動かしているサーバみたいは、mrtgでロードアベレージを見ていると一面緑色になる位、酷使されているのだけれど、こういう使い方をすると厳しそうだ。

■ 関連記事

■5 世界最速360キロ…JR東、次世代新幹線お披露目[http://www.sankei.co.jp/news/050624/sha042.htm]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■6なぜ、進捗率が上がらないのか〜進捗が上がらないヒミツ<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

某所での話。
進捗会議の度に進捗率を報告するのだけど、1週目「80%です」、2週目「90%です」、3週目「99%です」、4週目「99.9%です」等と報告して後が無くなりつつあるという話になっていた。
プロジェクトの進捗率報告には、
  • 会議での批判を避けるために
  • 見込みや
  • 希望的観測
が織り込まれるために、こういう事態が生じていると見られているのだけれども、実は、こういった要素を取りのぞいても、「進捗率」はこうなる運命を持っている。
「とあるプロジェクト」の進捗をグラフにしたものを示す。
進捗率のグラフ
プロジェクトは、今はグラフの「期間B」の中盤位、進捗率で50%を超えたところだ。これから先の実際の進捗はもちろん誰も知らない。
「期間A」の頃は、なかなか進捗が伸びていかずに心配したけれども、最近は順調に開発は進んでいて、「期間A」での遅れも完全に取り戻した。特に問題も抱えていない。プロジェクトは順風満帆だ。
進捗会議で完成時期を訊ねられたけども、「希望的予測」によれば、納期よりもずいぶん前に完成できる様だ。もちろん少しサバは読んであるけども「納期には十分間に合います」と言うだけの余裕があった。

「おかしい、こんなハズでは」:

進捗も70%を超えた頃、どうも進捗率が伸びていかない事に気づいた。定例の進捗会議が苦痛になってくる頃だ。
1週目(今週は伸びが悪かったが仕方がないか)「80%です」
2週目(若干サバを読んで)「90%です」
3週目(納期過ぎているし、来週には取り返せるだろう)「99%です」
4週目(進んでいないとは言えない)「99.9%です」
等と報告して後が無くなってしまった。

どうしてこういうことになるのか:

そもそも、進捗率というのは線形に上がっていかないものなのだ。
このプロジェクトの進捗は、実際には波線の様に推移した。開発末期には当たり前にこういうことが起こるものなのだ。
これは、経済学では 「限界効用逓減の法則」[http://www.nikonet.or.jp/spring/sanae/MathTopic/teigen/teigen.htm] として知られている法則だけれども、開発においては、
「進捗率が100%に近づけば近づくほど、進捗率を上げるのが難しくなる。」
『進捗逓減の法則』, MAEDA Katsuyuki, 2005年6月24日
という困った現象が起こるのだ。
例えば、残っているバグが100個あるとする。もちろんこの時点で残りのバグの個数は分からないのだけれども。 そこから任意のバグ1個を取りのぞくのと、最後の1個のバグを取りのぞくのは当然、難易度が異なる。当然ながら、最後に残るものほど難物になりやすいし、それは終わってみて分かるのだ。
取っても取っても新たな敵が出てくる。百鬼夜行の箱を開けた様な感じだ。 小物を倒すと、どんどん強い敵が出現する感じ。百鬼夜行は百匹って分かっているけど、こっちは残りの数が分からない分だけ分が悪い。

一方、プロジェクトの立ち上がりは:

一方、プロジェクトの立ち上がり[期間A]においては、学習曲線があるので、なかなか進捗が上がらない現象が生じる。
この時期を過ぎると、一見順調に進捗率が上がっていくけれども[期間B]、完成に近づくと、再び進捗率の上昇は遅くなってくる[期間C]。
実は、これは当然のことだったのだ。

生産量をグラフに示すと:

この時、単位期間あたりにどれくらい進捗が増加したかを「生産量」として、これをグラフに示すと、
進捗率と生産量のグラフ
の様になる。
労働力は常に一定であるという仮定をすると、最大の生産効率だった時期と比較すると、プロジェクト末期では、数十分の一にまで生産性が低下することになる。
こんな中で、進捗が上がらないプレッシャーと闘うのは非常に辛い。 別にサボっている訳ではない。誰もが必死で働いているのに、進捗は全くと言って良いほど上がらない。 進捗会議では責任者が針のむしろに座らせられる。そのストレスは現場全体に伝わる。誰もがどうしてこんな状況になったのか分からないままに徹夜を重ねる。
そういう辛い状況にプロジェクトの度に直面して、コの仕事を辞めたくなるヒトは多いと聞く。

進捗は上がらなくなるものだと受け入れること:

進捗率が線形に上がっていくという根拠のない妄想がこういう悲劇を招いている。
線形に伸びなければならないのだったら、線形になる様に再定義すれば良いのだ。
幸い、ここで見た進捗のカーブは「ロジスティック曲線」そのものだ。ロジスティック曲線になるものだと思えば、全期間を見積もって、進捗率nn%は、期間進捗率nn%に相当すると再定義することができよう。その方が、みんなが幸せになれる。
先人も言っている。
「百里の道を行く者は、九十九里をもって全行程の半ばとす。」
佐藤一斎
こう定義すると、そもそも「とあるプロジェクト」が納期通りに完了しないということは、早期に判明していたりするのだ。
結局、サイズを見積もっていないのにスケジュールと工数が決まっているという状況では、こうやってなるべく早期に再スケジューリングのサインを発見した方が良い。

ロジスティック曲線だとすると進捗は100%にならない:

「永遠に進捗は100%にならないじゃないか」という指摘は正しい。 でも、プロジェクトは進捗が100%に達したから終わるものではないのだ。

ドラえもん〜のび太のデスマーチ〜[http://pc8.2ch.net/test/read.cgi/prog/1116741745/]:

■ 関連記事

■7 VISAドメイン問題解説[http://www.e-ontap.com/summary/fornondnsexpert.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ドメイン名を確認しても確実ではないこともあるという事例。
安全に利用するためには、必ずSSL証明書を確認すること。

■ 関連記事

■8 携帯番号から名前や住所を特定するサービス[http://d.hatena.ne.jp/magisystem/20050623#1119513799][プライバシー]<< 前の記事 このエントリーをはてなブックマークに追加

こういうのは、せめて名前と電話番号を聞く運用にすべき。
考えてみると、ナンバーディスプレイに偽番号を表示させるテクニックとソーシャルを組み合わせられると、なかなか危険かも知れない。

■ 関連記事

詳細はこの日の詳細から

2003年06月24日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・HTML形式でのお知らせメール配信開始のご案内[http://www.nantoka.com/~kei/diary/?200306a&to=200306082#T200306082][セキュリティ] このエントリーをはてなブックマークに追加

数通のメールのやり取りを行って、返事を頂きました。 結論から言いますと、
BIGLOBEのシステムでマッチングすることにより、会員様の特定をすることは可能
であり、
メールのクリック情報を取得するために付与されたURLの文字列から、
お客様のIDやメールアドレスをBIGLOBE外から特定されることはありませんので、
ご安心下さい。また、これらの情報収集対象・管理につきましては、先日の
メールでもお知らせしました、BIGLOBEサービス会員規約にて詳細を明記させて
いただき、規定の範囲内で運用、管理を行っております。
ということです。
まぁ結論は当然ではあるのですが、ちょっと問題だと感じたのが、一旦。
> 4. このURLは各々の利用者に対して異なる文字列を付与しているのでしょうか。

はい、そうです。


> 5. 異なる文字列を付与している場合、これは個人を特定できる情報を含んでいないのでしょうか。

文字列から個人の特定はできません。
という返信に対して、、
 現在、HTMLメールとWebバグを利用した無断での個人情報収集が
問題となっていまして、私も強い関心を寄せておりますし、個人的に
運営しております日記サイトでも今回のお問い合わせの結果を
取り上げさせて頂きたいと考えております。

「BIGLOBEの今回のメールは、個人情報の収集を行っているもの
ではない。」

 と断言したいと思いますので、上記ご回答頂ければ幸いです。
という確認をした結果出てきたのが最初の回答だという点。
悪い方に取れば、情報を収集していることを隠蔽しようとしている様にも取られかねない言い回しだと思います。
リンクによってユーザ個別の情報や属性情報を収集するのは、ビジネス的にはメリットがあるのでしょうけれども、誤解を与えない統計情報の収集について、何らかの仕組みが 必要な様に感じます。

例えば:

どういう目的でどういう情報を収集しているかをきちんと説明するのは当然として、 何がたたみこまれているか分からない文字列よりも、
ユーザーIDを収集している場合
https://www.nantoka.com/xxxx/yyyy.cgi?user_id=ABC12345(ユーザーIDそのまま)
メールアドレスを収集している場合
https://www.nantoka.com/xxxx/yyyy.cgi?mail_addr=kei%40nantoka.com(メールアドレスそのまま)
年齢・性別を収集している場合
https://www.nantoka.com/xxxx/yyyy.cgi?age=3x&sex=male
みたいな格好で、何が送られるのか明示された方が安心な気がする。
但し、このメールによって、「ユーザID・年齢・性別」という情報がメールに乗って本人の所に届くので、こっちの情報漏洩のリスクとどちらを懸念するかと言う問題はある。
どういう情報が載っているか利用者側にも検証可能な共通の仕組みを作れると良いのだけれど。

■ 関連記事

詳細はこの日の詳細から

以上、13 日分です。

指定日の日記を表示

前月 2019年11月 翌月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project