  |
はてなキーワード: シリアライズとは
割りとマジだよねと思う出来事をふと思い出したので書いてみる。
といっても後輩が俺の思ってもいないところでつまづいて、それに俺がカルチャーショックを受けたというだけの話。
問題の話なんだけど、とある有名サービスのJSON APIを叩いて呼び出し結果を手元のオブジェクトにマッピングするというただそれだけのコードを書くというもの。
普通に考えて一日もしないで出来ると思うような代物だけど、三日以上悩んで彼はそれでも出来なかった。
{ ..., "count": 10000000000000000000000000000000000000, ...}
という感じで多倍長整数がリテラルとして書かれているのを前提として受け取る仕様だった。
JavaScriptの通常の整数と違って、JSONの整数リテラルは仕様上大きさの制限の記載がないので、上のようなのも合法。
で、彼の使ってたプログラミング言語のオブジェクト から JSONの変換ライブラリが、多倍長整数を文字列（""）としてシリアライズするような仕様なことがわかって、彼は行き詰まった。
そこで何をやり始めたかというと、JSONの整数がそのまま1000000000000000みたいにシリアライズされるライブラリ探し始めたんだけど、それは見つからないまま。
というわけで「増田さん、詰まってるんですけど……」と言われて助け舟出すことになったはいいものの、彼のコード見るとJSONの抽象構文木クラスがそのまま使えるようだった。
なので、
String serialiaze(Ast.JsValue value) { return switch(value) { case Ast.JsNull nullValue-> "null"; case Ast.JsInt bigIntValue -> bigIntValue.toString(); case Ast.JsArray arrayValue -> arrayValue.stream().map(v -> serialize(v)).collect(Collectors.joining(", ", "[", "]")); // 他のJSONの木についても同様に処理 default -> throw new RuntimeException("cannot reach") }; }
1時間しない内にこんな感じのコード（言語はJavaじゃなかったけど、だいたいこういう感じ）を書いて無事問題解決。細かいタイポとかあるかもだけど、日記では確認してないのでそれはおいといて）。
結局、JSONの形が期待と違って、しかも既存のAPIじゃいいのがなかったのに延々API探すことしか出来なかったのが問題解決できなかった原因だけど、このくらいのは割りとちょこちょこある。
きっと、それから一週間放置しても問題解決できなかっただろうし、どうも同じチームの同僚も問題を解決できなかったようだった。
最近、APIは叩けるけど、そこでトラブルとどうにもならなくエンジニアにちょくちょく遭遇するんだけど、やっぱりもうちょっと基礎出来てないと駄目だなと思った出来事だった。
具体的には、再帰が相性が良いプログラムを書けるとか、APIに頼れないときはさっさと自作する頭の切り替えとかもろもろ。
小林さんちのメイドラゴンを絶賛視聴中
やっぱりおっぱい特盛は飽きが来ない
それはそうと２期３話で１期ＯＰのミュージックビデオがアニメ化されて流れた
見た人ならわかるけど、なかなかの再限度
そしてとても可愛くなったボーカルの女性（元が可愛くないとは断じて言わない）
この実在する人間をアニメにシリアライズする事で、逆にデシリアライズの可能性も予想する事ができる
つまり人間をアニメにするとああで、あのキャラを人間にするとああなんだから、アニメのキャラが実際に現実にいたらだいたいどんなになるかがわかると思う
似顔絵とかのテクニックでもあるけど、その顔の特徴を足したり引いたり盛ったりする事でよりキャラっぽくデザインする
そういったデフォルメの差し引きを考えられるようになると、胸の大きなあいつは実際にいたら半分の大きさも無いだろうなとか、可愛いから許せてるボソボソ喋る根暗も実際にいたらムカつくだろうなとかを考えるようになって、
２次元があるから３次元は不要って考える人ってのは、そういうデシリアライズができないか拒否してるかのどっちかなんだろうなと思った
インターネットには説明しろおじさんが多い。ブコメやTwitterでよく観られる。対象は政治家とか企業、有名な人。いろんな人に説明しろと罵倒気味に命じる。発祥は国会の質疑だと思われる。いつの間にか説明責任とかいう謎概念ができている。ただ、困ったことに説明をしても、説明しろと言った人は聞いちゃいない。説明を理解する能力がないか、あえて無視している。個人的にダサいと思うのは、質問する側が問いを練り上げてない点だ。ただ漠然と説明しろと言うのは知性に欠ける。何が問題であるのか練り上げて質問したほうが効率的だし楽しい。ただ、曖昧な問いしか投げられないのは、言語化能力の問題かもしれない。研ぎ澄ました本質的な問い、質問された人が簡単には答えられないような問いを投げるのが、かっこいい在りかただと思うのだが、言語化できない人は質問をするだけで満足しているのだろう。権力を持っているのはわれわれ有権者なので質問はしていい。だが、薄っぺらい問いを投げて満足しているのは残念な姿だと思う。
近代社会は言語化できない人に厳しい。国家的な教育を通して国語能力を磨かせているはずなのに、読み書きできる人は少ない。しかし、言語能力が高くないと困る社会にも問題がある。認知特性には人によって偏りがあり、言語より図やイラストによる表現が得意な人もいる。音楽だってそうだ。これだけ国語をやっても変わらないのだから、人によって得意分野が違うとして諦めるしかない。一部のエリートは何も苦労せず読み書きができている。彼らは制度を作る側なので、当たり前のように読み書きを重視する。残念ながら、この構造は変えられない。思考を固定化するには文字が効率的なのだ。新しいシリアライズ形式が出ない限りはこのままだろう。
VisualStudioでローカルで動作するアプリを作ろうと思ってるんだけど
本当に初歩的なことかもしれないことが分からない。
「class」というやつについてだ。
そいつの中には複数のclassさんが存在してもいいのか？SAVACLASSとLOADCLASSが存在しても良いのか？
public class Person { public string name { get; set; } public int age { get; set; } } public class Office { public string name; public ObservableCollection＜Person＞ persons; } private Office office; private void init() { office = new Office(); office.name = "オフィス"; office.persons = new ObservableCollection＜Person＞(); office.persons.Add(new Person { name = "001", age = 11 }); office.persons.Add(new Person { name = "002", age = 22 }); office.persons.Add(new Person { name = "003", age = 33 }); }
OFFICEという属性にはPARSONというものが集まってて、そのPARSONの情報にはNAMEとAGEがありますよ！というのは分かるんだけど
シリアライズも、デシリアライズも、「圧縮⇔解凍」みたいなイメージしかないし
うーん。難しい。
クラスって何なんだ。VBA風に説明できる人いない？（VBAでもClassは使わずにFunctionとSUBだけ使い回してた）
いし→意思 という変換が一筋縄（シリアライズド・ロープ）とならないのは何となくわかるだろ。
いし→意思と素直に変換できた場合でも「こっちの意思ってなんぞや」問題がまたついて回る。「こっちの意思」ワードを出す前に「可否」ワードが無きゃこっちの意思の意味も分からんだろ的な拙い部分もある。
それら含めて「変だ」って感覚は（ワイ視点だと）そこそこコモン・センスだとは思うんだが、そうでないって感覚のコミュニティはあるって事よな。そこは理解する。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 86 | 24247 | 281.9 | 57 |
| 01 | 55 | 5963 | 108.4 | 66 |
| 02 | 18 | 5202 | 289.0 | 111 |
| 03 | 19 | 2475 | 130.3 | 81 |
| 04 | 15 | 1632 | 108.8 | 26 |
| 05 | 9 | 390 | 43.3 | 33 |
| 06 | 11 | 994 | 90.4 | 30 |
| 07 | 40 | 3929 | 98.2 | 68.5 |
| 08 | 73 | 6327 | 86.7 | 73 |
| 09 | 138 | 14812 | 107.3 | 65.5 |
| 10 | 142 | 11691 | 82.3 | 52 |
| 11 | 136 | 12848 | 94.5 | 49 |
| 12 | 95 | 8495 | 89.4 | 45 |
| 13 | 131 | 11443 | 87.4 | 44 |
| 14 | 114 | 11153 | 97.8 | 63.5 |
| 15 | 172 | 15990 | 93.0 | 46 |
| 16 | 198 | 20577 | 103.9 | 44.5 |
| 17 | 116 | 11496 | 99.1 | 59.5 |
| 18 | 142 | 14218 | 100.1 | 41 |
| 19 | 93 | 7758 | 83.4 | 54 |
| 20 | 47 | 9758 | 207.6 | 84 |
| 21 | 70 | 10584 | 151.2 | 70.5 |
| 22 | 86 | 13810 | 160.6 | 55.5 |
| 23 | 86 | 11647 | 135.4 | 63 |
| 1日 | 2092 | 237439 | 113.5 | 53 |
人(258), 自分(224), 増田(135), 女(134), 話(126), 男(100), 女性(88), 問題(81), 今(77), 仕事(76), 男性(75), 子供(73), 人間(73), 場合(69), 気(65), ー(64), 前(63), 必要(59), 時間(55), 社会(54), 他人(53), 収入(50), 意味(49), 関係(49), 相手(49), あと(48), 台風(47), 痴漢(46), 感じ(46), 結婚(44), 男女(44), 他(43), 可能性(43), 世界(43), 普通(43), しない(43), 人生(43), 下方婚(43), 気持ち(42), 馬鹿(42), データ(41), 好き(38), 理解(38), 日本(38), レベル(37), 逆(37), 無理(37), 否定(37), 会社(36), 主張(36), 最近(35), 全部(33), じゃなくて(33), 存在(33), 声(32), 手(32), ネット(32), 理由(32), 周り(32), 趣味(31), 差別(31), ソース(31), 被害者(31), ゲーム(30), 頭(30), 結局(30), 嫌(30), 友達(30), 別(29), 結果(29), 一番(28), 誰か(28), 言葉(28), クズ(27), 今日(27), 根拠(27), ダメ(27), 親(27), 子ども(26), 年収(26), 女性専用車両(26), 状況(26), 毎日(25), 漫画(25), 昔(25), 絶対(25), 育児(25), 自体(25), バカ(25), 意識(25), 確か(24), 作品(24), 時代(24), 家事(24), 批判(24), 本人(24), 時点(24), 金(24), 完全(23), 被害(23), 程度(23), 対応(23), 価値(23), 当たり前(23), 環境(23), 家(23), 奴(23), 最初(23), 一つ(23)
増田(135), 下方婚(43), 可能性(43), 日本(38), じゃなくて(33), 被害者(31), 女性専用車両(26), 障害者(20), リアル(20), マジで(17), ブコメ(15), 東大(14), いない(13), 個人的(13), hatena(12), 就活(12), SNS(12), パワハラ(11), 元増田(11), ツイッター(11), 夫婦(11), スマホ(11), 分からん(11), 痴漢冤罪(10), ヘイト(10), 悪いこと(10), なのか(10), いいんじゃない(10), ブログ(9), わからん(9), 差別主義(9), ブクマ(9), 価値観(9), 知らんけど(9), フェミ(9), カス(9), 1日(8), いつまでも(8), ディストピア(8), はてなー(8), s(8), なんだろう(8), 東京(8), 加害者(8), はてブ(8), ブクマカ(8), 基本的(8), プレイ(8), togetter(7), あなたに(7), 男性専用車両(7), 安倍(7), アメリカ(7), 満員電車(7), …。(7), 毎日(7), ダブスタ(7), 低能先生(7), 自分自身(7), 毒親(7), 脳内(7), gt(7), 1人(7), twitter(7), 飲み会(7), ？？？(7), 中国(7), かもしれん(7), 正義感(7), どんだけ(6), な！(6), 障碍者(6), OK(6), 一緒に(6), 説得力(6), ようじょ(6), 社会的(6), いじめられっ子(6), nekora(6), レディースデー(6), 1年(6), ぶっちゃけ(6), ツイート(6), イケメン(6), ワイ(6), 一方的(6), 男性差別(6), .s(6), 笑(6), 健常者(6), 何度(6), エビデンス(6), 最終的(6), P(6), eスポーツ(6), 大企業(5), 一本(5), 負け組(5), シリアライズ(5), ー(5), キチガイ(5), 女性差別(5), アレ(5), キモい(5), 男女平等(5), 論理的(5), 大阪(5), サイコパス(5), 人として(5), お気持ち(5), 関空(5), まんこ(5), トラバ(5), 非モテ(5), Google(5), 飲食店(5), 100%(5), w(5), GNU(5), 1回(5), デレステ(5), ATM(5), 自然災害(5), 人間関係(5), 生活保護(5), ホッテントリ(5), である(5), 20代(5)
しゃぶれよ (4), ソースなし (2), >そもそも人生が軌道にのってし(2), 台風で騒ぐのべつに悪くないと思うけど(2), 子供が楽しめることを新しい趣味として(2), 子ども産まれたら自分の時間がなくなる(2), 生きた人間が剣で刺し合ってる方がやば(2)
■一日一善の一善ってなにすればいいの /20180905163106(20), ■人は人、自分は自分なんて逃げでしかない /20180905072910(14), ■家庭教師先が教育ママで見てるのしんどい /20180904200821(11), ■中学時代にカースト高くなかった東大卒の奴の扱いは酷いまま /20180904220725(10), ■1000人の学生全員を私服で面接に来させる採用試験案内を考えて下さい /20180905104640(10), ■主語を大きくして話すひとは赤ちゃんなのだ /20180905140221(9), ■ /20180905133951(9), ■友達いない人どうやって生きてる？ /20180905011928(8), ■好きな芸能人の熱愛とか結婚報道で落ち込む人 /20180905185135(8), ■漫画は海外展開しないとジリ貧 /20180905041015(7), (タイトル不明) /20180904191904(7), ■趣味が生きがいの人は子どもを持つ前によく考えろ /20180904233809(7), ■「自分に刺さるコンテンツ」が年々なくなっていく問題 /20180829224019(7), ■ゴキ、ゼロにしたい /20180905011258(6), ■毎日虚無感しかない /20180905164609(6), ■子供が生まれたぞー！！ /20180905025354(6), ■ミリオンライブとかいう声豚用コンテンツと化したアイマスのお荷物（ /20180904235138(6), ■eスポーツの地位を向上させようとしている人たち /20180905165521(5), ■anond：20180904191904 /20180905100655(5), ■id:houyhnhm「増田は匿名！HNは匿名じゃない！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！」 /20180905183506(5), ■結局ダブスタって何が悪いの？ /20180905130710(5), ■「ディストピア」が誤解されている件 /20180905125439(5)
5585765(2637)
クラスは確かなんでも良いんだよね? 性別のクラスがあったり、性格のクラスがあったりとか…。
シリアライズはたくさんのクラスを通って作られたインスタンス（実体)の特徴をまとめたデータってこと？
クラスってのはバーサーカーとかライダーとかキャスターとかいろいろあるだろ。
「属性」と「振る舞い」が定義された人間側の便宜的な区別だよ。
セイバークラスには「顔が似てる」って属性が定義されていて、キャスターには「重いものを運ぶのに便利」って属性が定義されてるだろ。そういうのの塊。
野獣先輩なんかはバーサーカークラスから作られたインスタンス。吉田沙保里もバーサーカークラスから作られたインスタンス。
それは、バーサーカークラスに「乱暴である」という属性定義があるからなんだ。
そして、その野獣先輩の特徴をwikiなんかに箇条書きで纏めていくことを「シリアライズ」と言う。
そうすることでwikiを参照した他の野獣先輩ファンが、自身も野獣先輩になり切ることができるわけだろう。
このようにインスタンスの詳細を言語化することをシリアライズするってことになるんだよ。
分かった？
オブジェクトのシリアライズツールであるプロトコルバッファについて書きます。
Protocol Buffers 本家
http://code.google.com/apis/protocolbuffers/
XMLはもう不要!? Google製シリアライズツール「Protocol Buffer」
http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html
Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)
http://dodgson.org/omo/t/?date=20080712
プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。
独自の言語によりオブジェクトのインターフェースを規定することで、多言語対応を行っています。
例えばこんな感じ。
package tutorial; message Person { required string name = 1; required int32 id = 2; // Unique ID number for this person. optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } // Our address book file is just one of these. message AddressBook { repeated Person person = 1; }
以上のようなprotoファイルから各言語のソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。
googleによってC++, Java, Python用のライブラリが作成されましたが、他の言語に対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。
数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合は符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。
バイナリに保存されるデータは各メッセージのID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。
またオブジェクトを連続でシリアライズ/デシリアライズすることもできます。
すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。
(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)
message PbBase { require int32 id = 1; require int32 value = 2; require Derived derived = 10; // - Point !!! } message PbDerived { require string string_value = 1; }
継承元のメッセージの定義に、継承先のメッセージを持たせます。Baseを継承するクラスをシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。
例えばこんな感じ
Base *Base_DeserializeFrom(PbBase &pbobj) { // Arrange the classes which inherits from Base. if (pbobj.has_derived()) { return new Derived(pbobj); } else ... } class Base { ... virtual void Base::SerializeTo(PbBase &pbobj) { // Set the fields of 'pbobj', } ... }; class Derived { ... virtual void Base::SerializeTo(PbBase &pbobj) { PbDerived *derived = pbobj.mutable_derived(); Base::SerializeTo(pbobj); // Set the fields of 'derived', ... } ... };
protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。
message PbBase { require int32 id = 1; require int32 value = 2; } message PbDerived { required PbBase base = 1; // - Here is the point !!! require string string_value = 2; }
.NETでオブジェクトの永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。
全体的に速度が重要な場合か永続化するオブジェクトが単純な場合はXmlSerializerを、それ以外の場合はSoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター。
あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。
よもや、レスがついてるとは思わなかった。
興味を持ってもらえてサンクスです。
entry = diary.entry('20070712231804')
でエントリー指定してたからなんなんだろうと思って。
editもできるってことなのかな？
書き込んだあとの編集機能はいまんとこなし。
# get entry from id entry = diary.entry('20070712231804') # puts entry title puts entry.title # puts entry content puts entry.content
で、そもそもRubyに詳しくない自分からするとちゃんとした使い方がそれでもわからない。
バカでごめんねなんだけど、どうやって使えばいいの？
たとえば、エントリのタイトル一覧(1ページ目だけだけど)を出力するなら
diary = Masuda::Diary.new diary.entries do |entry| puts entry.title end
こんな感じかな。
新しいエントリを登録するなら
diary = Masuda::Diary.new diary.login('my_id', 'my_pass') diary.post('koko wa title ne', <<EOS) koko ni kizi no honbun wo kaku EOS
とか。
ずらーっと増田らしきものを読み込む。
そりゃそうだわなと思いながら文字化けの山。
文字化けなのは、たぶん増田のエントリ(UTF-8)をそのまんま取得しているせいだと思う。
~$ ruby hoge.rb | nkf -Ws
出力するときにSJISに変換するとか。
require 'rubygems' require 'masuda' require 'kconv' diary = Masuda::Diary.new diary.entries.each do |entry| puts entry.title.tosjis puts entry.content.tosjis end
あと
session[:diary] = diary.raw
diary = Masuda::Diary.restore(session[:diary])
の...って何でしょうか？？
Masuda::Diary#rawはインスタンスをシリアライズするメソッド。
ログイン済みのインスタンスをシリアライズしてセッションにつっこんどいて、次のリクエストでも使いまわすとか。
わかりづらい文章で申し訳ない。
