「標準規格」を含む日記 RSS

はてなキーワード: 標準規格とは

2020-06-16

anond:20200616031935

電子レシート標準規格ができればいいのになぁ。

店によってアプリが違うとか、(例えば)iOS不可とか言われたら全然おもしろくないし…

2020-05-26

anond:20200526002227 情報処理技術者試験なんて簡単で案外役に立ちます

情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。

前提が違う気がしますよ?

まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験危険物取扱者試験などの国家試験とは異なり、

別に持ってなくても実務に従事できるって言う不思議国家試験であること。

なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。

 

じゃあなんで試験なんか受けるの?

情報処理技術者試験は、ちゃん情報処理のこと勉強してますよ!ある程度の知識は修めてますよ!って言うためのものでしょう。

名刺資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。

たこ資格を持っていることで、ちゃん勉強している人間なのか、その指標にもなるのでマネジメント一助になるです。

なので、エンジニア同士の共通言語って位置付けな気がします。

 

そんなにひどい問題が多いの?

ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、

一方で実務以外のコンピュータ技術本質的な設問であったり、法務関係問題もあったりして、

マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識必要になったときには役に立つかと。

 

そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、

まともな設計知識を持っていたら、このくらいの問題は知っていますよね?ってのが技術試験の一面です。

※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと・・・w

 

ちなみに、UMLの基本や、開発手法MPEGなどの標準規格名称なんかを覚えるのは、設計コーディングにおいて「超大事」なことです。

そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、

システムを構築していくソフトウェア開発手法」でやります!みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。

基本情報技術者試験レベルメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。

 

情報処理技術者試験なんて簡単に取得できます

合格率は基本情報技術者試験で3割弱、応用情報技術者試験で2割強となっています

なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから

そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという・・・)

なのに合格率が低いのは、みんな真面目に勉強(暗記)していないからと思われます

試験会場にいくと分かるのですが、まずスタート時点で1割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。

会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。

暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、1~2か月真面目にやればだれでも取得できますよ。

ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。

範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。

 

情報処理技術者試験は案外役に立つ

上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます

合格率2割の国家試験を、通常業務をこなしながら取得してくるだと・・・!?化け物か! みたいな

雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。

 

受験だってそんなに高くないし、そこまで噛みつくような試験でもないと思いますけど。

2020-05-23

[]2020年5月22日金曜日増田

時間記事文字数文字数平均文字数中央値
006713646203.760
01578080141.856
02294017138.537
0363405064.319
0457415772.945
0538246764.937.5
0659566396.043
07101895288.652
08115993486.436
0913117370132.643
101101091599.262
1112215866130.046.5
121711370580.142
131951504377.144
1413722796166.479
151601161772.637.5
161841241367.541
171751490585.237
181521182077.835.5
1915816994107.636
2012913702106.246
21120806067.230
22110991590.135.5
23107784573.335
1日274726393296.142

本日の急増単語 ()内の数字単語が含まれ記事

ヘテロラブ(6), お茶子(5), FORTRAN(4), 検察庁法改正案(4), ブルースリー(4), 40年(5), 20日(3), ピーコ(3), ジェネレーター(5), HL(9), ロマンスカー(3), 10倍(3), スクール(37), プログラマ(50), プログラマー(54), プログラミング(68), 賭け(19), アジア人(17), 専門学校(12), アルゴリズム(11), 金髪(11), コード(41), Web(25), 白人(31), エンジニア(45), ファイル(12), 職種(11), 滅(8), テレワーク(18), プログラム(20), IT(27), 借金(18), 職業(21), 正社員(15), 分野(15)

頻出トラックバック先 ()内の数字は被トラックバック件数

プログラマーって選民感情持ってる人多くない? /20200521200340(35), ■プログラミング生業としてる人って /20200521175300(28), ■どうして未経験者はそんなにWebエンジニアにこだわるんだい?◕‿‿◕ /20200522005004(14), ■専門学校卒はどこに消えてるのか /20200522133643(10), ■借金ありおたく女、結婚する /20200522180754(10), ■俺が政権をとったら絶対にやる10マニフェスト /20200522202451(10), ■いまだに自民党以外を支持する気になれない /20200522162237(9), ■景気回復してくれ /20200522200945(9), ■アニメキャラ白人説とレイシズム /20200522093502(9), ■2階に住んでて下が床屋なんだけど /20200522114020(8), ■はてなブックマーク象徴するブクマカ 追記追加あり /20200522001329(8), ■ /20200521094511(7), ■高峯のあは一生声がつかなそう /20200522060629(7), ■ChromeFireFox のタブクローズボタン位置標準規格無視している /20200522072657(7), ■先輩が異動させられるかと思ったけど多分コロナのどさくさで無かったことになった /20200522130445(7), ■【追記アリ】今日寿司屋に行くぞお!🍣 /20200522164640(6), ■東大生だけど、高校一年生の数学問題がわからない /20200522180132(6), ■anond20200521094511 /20200522151133(6), ■増田って個人プレーばかりだよね /20200522194409(6), ■みんなで一斉にアンマウントするのはどうか /20200521181610(6), ■MTを選んだ己を呪っている。 /20200521144628(6), ■旦那のやることなすこと全てにイライラする /20200522203320(6)

2020-05-22

ChromeFireFox のタブクローズボタン位置標準規格無視している

Safari → 左側 (正しい)

Chrome → 右側 (違反)

FireFox → 右側 (違反)

敢えて逆にする理由は何なのだろうか

薄気味悪くて仕方ないので Safari 一択になる

2019-07-07

anond:20190706190044

真面目に回答したら良いのかな?

おそらくは日本ネット投票がまともに解禁されるようになるには、インターネットで使われる情報技術標準規格を選定するW3Cが定めたSelf-Sovereign Identity(SSI)というポリシーに則ったDecentralized Identifiers(DID/DIDs)が日本でまともに運用されてからだと思われる。

Self-Sovereign Identity(SSI)

Self-Sovereign Identityとは訳すと自己主権アイデンティティで、これは技術の規格というよりも技術を開発・運用するためのポリシーなんだ。

詳しくすると論文が書けてしまうので要約するけどSSIでは以下の10項目が提言されている。

  1. 存在 - 個人独立した存在でなければならない
  2. 制御 - 個人自身アイデンティティ管理しなければならない
  3. 接続 - 個人自身情報接続できなければならない
  4. 透明 - システムアルゴリズムは透明性がなければならない
  5. 持続 - アイデンティティは持続性がなければならない
  6. 可搬 - アイデンティティに関するサービス情報は可搬性がなければならない
  7. 互換 - アイデンティティ可能な限り広い範囲で利用できるべきである
  8. 同意 - 個人自身アイデンティティ使用権限を持てるべき
  9. 請求 - アイデンティティ請求は最小であるべきである
  10. 保護 - 個人権利保護する必要がある

これらの10項目はまだ上手い日本語訳が無くて俺の意訳が含まれていることに注意してもらいたい。

このSSIが何を言いたいかといえば個人情報の公開を第三者ではなく個人自身管理制御できるべきということなんだ。

Decentralized Identifiers(DID/DIDs)

SSIを定めたW3Cはそのポリシーに則って個人情報管理するためのシステム仕様を定めた。

それがDecentralized Identifiers(DID/DIDs)で、これも訳すと中央集権識別ということになる。

何のことだが小難しい漢字語になってしまったので、より現代人へ理解やす平易な言葉へ置き換えると分散デジタルID表現したほうが理解やすいと思う。

現在個人情報(アイデンティティ)というもの中央官庁巨大企業によって中央集権的に管理されてしまっている。

これでは個人情報本来の持ち主である個人自由に利用することが難しいし、そして自身個人情報がどのように扱われているのかというのを把握するのが非常に難しくなってしまっているよね。

更には中央官庁企業としても日本国法で言うところの個人情報保護法の兼ね合いで個人情報管理に関して大きなコストを支払わざる得なくなっており、もし仮に個人情報流出した際に賠償責任などのリスクを負う可能性があるのが現状だ。

そこでW3CはSSIポリシーに則ったDIDという仕様を定め、これまで問題視されてきた個人情報管理問題点を解消しようと近年動き出している。

DDIブロックチェーンにより分散的に個人情報管理しつつ改竄を防ぐ仕様が取られている。

更に特徴的なのは個人個人意思によって個人情報請求に対して公開したい範囲個人情報のみを開示できる仕様になっているんだ。

これはどういうことかと言えば、現在日本ではタバコ酒類を購入することに関して成人であることが条件になっていて、成人認証には運転免許証マイナンバーカードなど公的機関が発行する資格証明証が用いられている。

この問題点タバコ酒類を購入する際に必要個人情報は「成人である」という証明だけのはずなのに、例えば運転免許証であれば氏名や現住所、許諾されている運転車両範囲など余計な個人情報記載されてしまっていることが問題なんだよね。

しかし、DIDを用いるとタバコ酒類購入者が開示する情報は「成人である」ということができるようになる。氏名も生年月日も現住所も許諾されている運転車両範囲も開示する必要がないんだ。

これは中央官庁企業に取っても非常に安心仕様だ。何故ならもし誤って個人情報流出させてしまっても流出するのは誰のものだか判然としない「成人である」という情報のみから

他にも携帯電話通信契約などの場合でも本人確認や法的に契約できる者なのかを確認しなければ契約の締結はできないけれど、DIDを用いると開示する情報は「本人である」というものだけになる。

契約業務をする目の前のスタッフアナタがどこの誰だか全くわからないけれど、アナタが本人であることを知ることができる。こういうことを可能とするのがDIDというシステムなんだ。

ポイントカードクレジットカードDIDと紐付けば何枚も持ち歩く必要なんてなくなる。

そして選挙は本人であることや、投票できる年齢であるかどうかを確認したり、投票秘密を守らなければならない。更に言えば投票の集計もしなければならないよね。

DID中央集権に寄ることなアナタが本人であり投票できる者であることをアナタの許諾を得て承認し、投票秘密を守り、更にはコンピュータから超高速に投票集計もしてくれるんだ。

SSIの透明ポリシーによって投票集計のプログラミングコードアルゴリズムオープンに公開され公正に選挙が行われる。

これが最も先進的な個人情報管理のために提言されている新しい技術だ。

SSIとDID日本でまともに運用開始されるとネット選挙未来はそう遠くなくなるよ。

このエントリでSSIとDIDに注目して貰えたら俺としては何も言うことないぜ!以上!

2017-10-23

日産の件って氷山の一角だろ

法律違反とかどうかわわからんけど、社内規定が守れてないとか心当たりがありすぎる。

最近コンプライアンスだか標準化?、国際的安全要求の高まりかいろいろルールできすぎ。

ちょっとなんかするとすぐ文書つくれ、エビデンス残せ、承認して組織として責任持つ形にしろ、前工程文書承認降りてから作業しろ

とかそんなのばっか。

正論なのはわかるけど、

いちいち文書なんか作ってたら仕事終わらなくて帰れないし。

承認する人出張いっちゃって中々承認おりないし、ぶっちゃけ日付操作してハンコ押してくださいって頼むことが多い。

工程逆転もしょっちゅうだってあり得ないタイミング仕様変更入るし。

知らんがな。下請法はどうなってるんだろう。こんなタイミング仕様変更受け付けなければいいのに。

本来作るべきタイミング文書作れてなくて、後づけて体裁整えるために文書作るとかよくあるわ。

いろいろ社内規定が守れてないことに心当たりがあるんだけど、

社内規定が本当に社内だけの規格なのか、法律標準規格根拠にしてる社内規格なのか把握しきれてない。

外部監査入ったら、うちの会社ヤバイかもしれんなー

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-09-17

はてブやってるようなクズEVを買えないくらいに貧乏か車に興味ないかどっちかなんだよなぁ

はてなブックマーク - 経産相「いきなり電気自動車にいけるわけでもない」 | NHKニュース

車に興味ないなら黙ってろくそはてブ民。

まともなブコメまとめていくが、これ否定できるならやってみろよ。

どうせ経産省批判する流れが出来てからなんとなく乗っかかって物言ってるだけの思考停止したバカはてな民

ほんまお前ら害悪しかないわ。



gokkie 30kWhリーフ買って一月半で2500km乗ったけど、今のトコ不満はない。先行者特権フリーライダーになれるのは限られた期間やろし、格安で買った車でガンガンフリーライドしまくるで

etr そうなんだ・・・とりあえず私、テスラ乗るね。(モデル3予約してます。)

600以上ブクマついてるのに実際に電気自動車を買って乗る人が二人しかいないはてな民wwww




ちゃんと自動車のことわかってる人のコメント

fusionstar 欧州EV 推進は原子力発電前提なんだけど乗っかっていいのかなあ

u-chan ただの腰巾着かと思ったら、まともなこと言ってる。これで「電気自動車ダー!!」なんて言ったら、後、新設の原発何基作る気なんだ?? だしね

raitu 短い航続距離(最大でも600km)および長い充電時間(40分)をすぐどうにか出来るわけでもないから、そんなに変なことは言ってない

mur2 いきなり電気自動車しろという人はリチウムネオジムを筆頭とした大量のレアメタルをどうやって安定的調達する気なんだろうか。エンジン関連パーツ、燃料系統を作ってる下請け死ぬぞ。

otihateten3510 英仏中がやってるのはあくま政治だと思う。技術置き去りの政治に良い印象はない。支援はわかるが規制に便乗するのはおかしいだろ? どちみちメーカー対応しなきゃならないわけで、経産省立場はこれでいい

Earth_f1 EVに関して過度に期待しすぎるのもどうかと思う。HV/PHEV/水素/にだってモーターとバッテリー技術はあるわけだし悲観しすぎでしょ。あとガラパゴスで言ってる人は日本メーカー海外売上比率を見てみてはどうですか?

ukidousan LNG以外の火力発電所を潰すまではHV優位かなあ https://headlines.yahoo.co.jp/hl?a=20170913-00010007-msportcom-moto

moegi_yg トヨタ水素押し、EVにしなきゃ乗り遅れる、ガラパゴス、云々全部的外れ。中印蘭以外はHV, PHVも可、電動化の肝はバッテリー。日系はそこは進んでるし、スバル/マツダですらロードマップに数年後に導入

Dicer あれ?トヨタEV用の高性能電池を開発中じゃなかったの??→ http://jp.techcrunch.com/2017/07/26/20170725toyotas-new-solid-state-battery-could-make-its-way-to-cars-by-2020/

poko_pen インフラ整備が不要プリウスなどHV20年掛けてやっとシェア30%(世界ではもっと低い)。充電スポット新規発電所建設などインフラ整備が必要不可欠な電気自動車がどれだけハードルいか理解して欲しい

dannier インドフランスEV縛り宣言したけど、ドイツは同じ問題抱えてるから実はEV宣言はしてないんだよね。まあ研究開発と充電設備に巨額の投資はしてるけど。あと中国もいつ急に降りるかわからん、という感じなのだ

ryokujya 日産ノートeパワーを見ましょう。リーフを出した日産エンジンを発電に使うノートを出した意味を。今はハイブリッドが適している




もちろん私だって別にEV否定してるわけじゃないぜ。政治的にもアドバンテージを取らないといけない部分があるのはその通りです。

インフラ整備や普及のための補助金標準規格競争など、適切なタイミングを見て国が参加する必要はありますはてブもそのあたりわかってる人をちゃんとフォローしたいですわ。

awkad いかにも日本だ。作る側が神と思ってる。決めるのは需要側なんだよ。中国アメリカEVだっていったらEVだ。日本需要で負けてるんだから決定権なんてない

mamezou_plus2 充電スタンド規格「CHAdeMO」と別規格を欧米に作られ日本外しEVが普及すると充電負荷が高すぎるのでスマート電力のシステムとかサービスとか。内燃車とは特性が違うから交通などデザインし直さなきゃいけない

giyo381 電気自動車時代って言ってる人の中でwell to wheel知ってる人どんくらいいんだろ。石油が連産品とか、発電効率とか知ってるのかしら

石谷久(東京大学教授)による「Well to Wheel」でのCO2排出量( 2005 )/ ガソリン車:193 / ガソリンハイブリッド車:123 / 燃料電池自動車86 / 電池電気自動車:47 / https://blogs.yahoo.co.jp/zaqwsx_29/18278184.html


お前らみたいなアホが、燃料電池の時も同じことを言ってて、

燃料電池がだめになったらその時応援してたことも忘れて手のひらクルーするわけよ。

おまえらどうせEVについても、EVにさっさと乗ろうとしない政府無能とか言っておきながら、

いざ上手く行かなかったら、「誰だよEVに一足飛びに行こうとしたやつは」とかいい出すわけよ。


2040年になった時、さすがにお前らもはてなをやってないとは思うが、

このブックマークページのコメントは保存しておいて「ほーら20年前にこういうバカなことを言ってる人たちがいたんだよ」って晒してやるから覚悟しとけよ。

2017-08-07

誰か暗記プロセス標準規格作ろうよ

私は現在仕事ソフトウェア開発のプロセス改善活動をしている

そこで考えたのだが、なぜこの世の中には色々なプロセスの規格がないのか

様々な分野でプロセス規格を作ってみた面白そうではないか

例えば暗記方法

暗記方法は「人それぞれ」という言葉のせいで議論が進まなくなっているイメージで、効率の悪いことやっている学生がたくさんいるのではないか

そこで暗記方法ベストプラクティスを集めたプロセスの規格を作るのだ

暗記する者たちは、自分でそのプロセスの規格を読み、暗記方法改善する

または、プロセス規格からできたチェックリストを使って自分の暗記方法改善する

さあ、誰か標準団体を立ち上げよう

2017-04-13

http://anond.hatelabo.jp/20170413225101

続き。BHQの標準化活動

中身見れないけど、山川氏のアクティティはあるのかな。

まあそれなりの人が参加してればそれなりと言えるかもしれない。構成員からないけど。

https://www.itu.int/md/T17-SG16-170116-TD-WP2-0024/en

慶応大川森氏によるQ28/16のプレゼンテーション。(イラストやが世界進出してる)

http://www.itu.int/en/ITU-T/gsi/iptv/Documents/ws/201606Brain/S1P1-Masahito_Kawamori-Intro_to_ITU_and_Q28_work.pdf

NTT出身・・・からITU-Tなんだねえ。

http://www.ttc.or.jp/files/3213/5884/2008/TTCniyosete_kawamori_2013_01_Vol.27_No.4-3.pdf

医学的に十分信頼できる話かどうかは、判定できない。意識低い工学系の研究者からね。

一般論では、使われない"標準規格化"は腐るほどあり、それは最終的にはクソの山なので、これがそうならないことを祈る。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-01-22

日本語なのに読めない

ちまたで日本語なのに読めないと話題の某Web製作会社代表あいさつを理解しようと努めてみたがやっぱり読めない。

ていうかそもそも大事なことは何も言ってないから読む必要もないんだが。

この代表さんはビジネス書マーケティングななめ読みしすぎだろw

()内は私のぼやきです。

http://liginc.co.jp/company/message/

『真の成功企業を目指して』

今、IT業界革命時代突入しています

2000年初頭に起こった枠組みの変化により様々な溝が取り払われ、各社の中核事業経済価値が同質化された結果、先の見えない不況が我々の眼前に覆いかぶさってきています

LIGは自社の強みでもある競争のない未開拓市場での事業展開、

顧客にとっての障害を取り除くことによって利益を創出する事業に集中する事で、安定的な成長を続けています

ソーシャル・ネットワーキングの人気者』

今では誰もがSNSを利用しています

我々の資産でもある、知識として蓄積されたSNSにおける情報マーケティング戦略は、継続することで世の中に多様な影響を与えられると信じています

さら社員ひとりひとりが複数ポジションをこなすことのできる選手として活躍する事により確立されたリスク分散手法は、

他業種との提携積極的に結ぶ事で効率化を図り、いずれ社会における標準規格となっていくと確信しています

(そんな社員を便利に使うことや外注することをリスクヘッジマネージメントって言っていいんかいw)

私たち現実

現実必要ものは、自由な発想、機敏さ、そして創造性だと考えています

縮小される(クライアントWeb予算をどのような企画で獲得していくのか、

その機会を逃さな管理体制こそがカギです。

挑戦を続ける気持ちを持ち続けながら「計画を立てる」「実行する」「行動を評価する」「改善する」という流れで仕事をまわしていくこと、

常に主体性をもって物事を考えて仕事に公平な評価付与していく。

LIG成功はそれらの想いの先にあるものなのです。(←どの想い?)

まあ挨拶とか言ってこれ全部ただの思いつきだけど!(←あっ、最後本音を言ってる)

2015-09-26

政治力呪いドイツ自動車メーカーはなぜディーゼルで失敗をするのか

資源呪いという言葉があります

https://ja.wikipedia.org/wiki/%E8%B3%87%E6%BA%90%E3%81%AE%E5%91%AA%E3%81%84

簡単に説明すると

資源があることで甘えが出てほかの産業への投資が怠る事や、資源があることで紛争汚職がはびこる原因になることです。

資源がある国の多くが途上国であることからそう言われるようになりました。

資源恩恵をもたらすものではなく、甘えや政治腐敗、紛争を引き起こすものであるという発想。

私はこの面白い考えが、今回のVWディーゼルエンジン問題にも言えるのではないかと思いました。

まりドイツ政治力引き起こしたのではないかと。

政治力といえばアメリカです。

日米貿易摩擦の時、ジャパンバッシング日本車をひっくり返すパフォーマンスなどをやっていた時代

関税など、ビッグ3を守るためにあれこれ政治的日本企業妨害していましたよね。

しか結果的ビッグ3がどうなったかみるとわかりますよね。政治力って本当に企業のためになるんでしょうか。

国際的日本企業は、自国国際政治立場の弱さを知っているため、国を当てにしていません。

トヨタなどはそれこそ日本の政治家や官僚以上にアメリカ政治に対して神経とがらせています

おなじくらい気を使っているのは、確かな技術です。技術は誰の目から見ても公平に評価ができる分野です。

なので私は、日本企業がまじめに技術と向き合っているのは、かなしいかな政治力のなさによって起こったものではないかなと思うのです。

なのでそういった理由からなのか日本企業の多くは国際的には技術押しで紳士対応しますが、内政だととたんに横暴な態度とったりしますよね。

政治力が使える相手なら政治で楽に対応する。そんなイメージがあります

かつてのドイツもそうだったのではないかと思うんです。

運よく政治力がなかったと。

僕のイメージするドイツ技術世界一的なイメージというか、

歴史的ドイツ技術力で他国を圧倒するようになるのは第一次大戦以降ではないかと思っています

大航海時代出遅れたために植民地もてなかったドイツが、産業革命出遅れドイツが、第一次大戦に負けたドイツが、

その結果のヨーロッパでの政治的立場の弱さを、技術習得に注力したのではないかと思います

そして、そういったドイツ稲穂の垂れるような態度を作り上げた外的要因が、ことごとくEU誕生、そしてユーロ誕生でなくなったと思います

アメリカロシアに対抗するために誕生したスイミー作戦EUによってドイツ宗主国立場になりました。

ドイツを仲間にすることでヨーロッパの争いを解決するというのもあったわけですが

皮肉なことにユーロのせいでユーロ圏内では、比喩ではなく本当に宗主国状態です。

ナチスに例える人も出てくるくらいですが、けして大げさではないと思いますね。あれはもはや帝国です。

いろいろケチつけましたが、とにかくスイミー作戦EUによってドイツ国際的影響力を持ったわけです。

メルケルもさぞかし楽しい政治ライフを送っていることでしょう。

しかし、その強い政治力が、産業に悪い影響を与えているのではないかという考えが、私のなかにうかびました。

まりドイツEU宗主国立場を利用し、ディーゼルクリーンものだということにして、技術開発競争から目をそむけたのではないかと。

かつてのアメリカのように。アメリカ化とでもいうんでしょうかね。



政治力必要ないとはいいません。軍事産業インフラ分野などは政治力必要なところもあるでしょうね

標準規格の争いも政治ものを言いますよね。アメリカEU、そして中国立場を強めています

日本企業勝手に行動するとむしろ国内の識者からガラパゴスだなんだとたたかますし。

しかし、今のところ一般の車はどこぞの団体が規格を握っているわけではないですし、

政治がかかわるにしても今回のように排気ガス規制などくらいです。

自動車産業自由技術を見せられる分野でうらやましいなと思います

私は家電屋ですが、今になって白物家電がもてはやされているのは規格に縛られずに作れるからだと思います

将来OS重要になり自動運転などが登場したときにどうなるかわかりませんが。

今のところ、日本自動車メーカー大丈夫だと思いたいですね。

日本企業も内政では政治で話を押し通す癖があります原発などもその一つでしょう。

他山の石として考えるべきことだと思います

2014-11-09

http://anond.hatelabo.jp/20141109114746

お前は俺か案件ですね。「伝統で言うなら、タブ幅は8じゃないですか?」と言い返したら、「タブ幅は4が標準ですよ。だいたいタブ幅が8だったら、インデントが深すぎて使えないじゃないですか」みたいなことを言われましたよ。

タブ幅に標準規格はねえし、タブはコードのインデントのためにあるんじゃねえんじゃよー、ぎゃわー!

タブ幅は8のほうが伝統的だし8で固定すべきという意見にはそれなりに同意できるんですが、現状としてタブ幅は固定でないし、もしタブ幅が8だとしたら、インデントにタブを使う人は減るんじゃないすかね。

コードからタブ滅するべし!

 
ログイン ユーザー登録
ようこそ ゲスト さん