司维的思维 思维比较活跃所以老换地方

今年决定把ACG类作品的总结单拿出来写。动画类因为看得不多，本来计划每部都写写观后感，但一数发现也有20来部，所以挑一些印象深刻的出来，不一定都是评分高的；漫画类因为数量比较大，只进行推荐好了。游戏类……如果想得起来玩过哪些就写。

A

按照观影顺序排列。(试试看bgm.tv的图片能否外链）

嘟嘟猫观察日记 / ポヨポヨ観察日記
年番好棒！大地丙太郎真是奇才。3分钟的泡面番也能拥有如此大的信息量（《网球并不可笑嘛》属于信息量大但是是用语速做到的）。

寒蝉鸣泣之时 煌 / ひぐらしのなく頃に煌，6/10
其实叫“黄”也很贴切。很欢乐，估计是为了平衡正片的阴暗吧。话说龙骑士07的《彼岸花盛开之时》啃了个开头就没继续，有空去补。

对某飞行员的追忆 / とある飛空士への追憶，8/10
制作质量无可挑剔，故事情节很有趣，一直说读小说也没读（acgtalk还在时候就说看民翻）。但CV表现确实不行，不能拿“外行”来做挡箭牌。

黑岩射手 / ブラック★ロックシューター，5/10
谁能跟我说说这片子到底想说什么？还是仅仅为了刷时髦度。

轮回的拉格朗日 / 輪廻のラグランジェ，7/10
第一期8分，第二期7分。搅姬部的故事核心只有三个人，但却代表了三股势力，所以背后的故事还是值得一看的。尤其二期中间部分开始交代黑历史以及超展开，但估计大部分弃片子的都在之前弃掉了。最后需要提一下的是佐藤龙雄说的“高浓度友情”明显已经饱和而产生质变了。顺带一提，我萌石原夏织！

Another，6/10
观感超好，音响和画面一流。故事坑人请找零食老师

Fate/Zero，9/10
制作各方面都被婊的大作，婊BGM说梶浦作品既视感太强没有新意不够燃也就算了，婊监督说节奏感不好该表现没表现也就算了（事实上这两点我都不认同），连虚大爷的剧本和原作都被婊，口味太挑剔了吧？

军火女王 / ヨルムンガンド，8/10
题材很抓眼球。虽然有些场面——或者说大部分战斗场面都变成了超级系对战，但不影响整部作品的质量。人物塑造非常成功。连巧克力小姐这种一部片子没有10个镜头的路人都有大批粉丝。二期的展开喜闻乐见，为了世界和平奋斗吧！

暴力宇宙海贼 / モーレツ宇宙海賊，9/10
科幻描写够硬！角色属性也够多。这是部属于小松未可子的作品，虽然开始阶段被人说太业余了，但三集过后明显感觉声音和感情投入都在进步，这种现象似乎并不多见。到了中期之后，黑CV的几乎绝迹，而完结之时对于小松塑造的香哥形象几乎是一边倒的赞赏。

冰菓 / 氷菓，8/10
“动动嘴皮子就能破案”就是嘲笑的日常推理吧，但恰恰是日常推理才适合改编成TV番组。严格来说，从第二卷开始的部分，比市面上90%的“日系推理作品”都更加本格。这部交给京ANI做实在是太正确了。CV选择和画面是京ANI的强项。

女子落 じょしらく，8/10
20分钟的动画要花1小时看，每集都是如此，因为neta太多啦。对于日本周边各国的吐槽毫不留情，而对于他们自己国家的吐槽更是狠。如果不是画风太萌的话，可以称得上是日本《南方公园》？

人类衰退之后 / 人類は衰退しました，9/10
本来看了PV直接弃掉，以为是各种小清新的无病呻吟类型。但在豆瓣友邻的强烈推荐下看了，发现藏在色彩对比强烈、人物外形可爱之下的却是极其异色的荒诞剧。

少女与战车 / ガールズ＆パンツァー，8/10
作为对坦克感兴趣但几乎毫无了解的外行，看得津津有味。这片子目前销量第一不是偶然的。

JOJO的奇妙冒险 / ジョジョの奇妙な冒険，8/10
观影的大部分应该看过原作，但感觉上也能讨好刚接触JOJO系列作品的观众。大量原作的分镜甚至拟声字的展现太好玩了。

C

星野之宣《宗像教授異考錄》
严肃类考古+推理作品。每话独立但也有伏笔。主要考证日本神话来源，通过地名人名、片段文字、古董或者口头流传的传说寻找和其他地方神话关联。有的故事精彩到让人觉得不改编成影视作品实在太可惜了，有的故事则是以做着自己的考证作为卖点。当然，这并非什么学术类作品，不能对其中的推理过程较真，不过看起来仍然很累，因为会有大量日本神话和西方神话知识以及考古说明。宗像教授系列除了《异考录》之外，还有《东方奇谭秘闻录》，这系列则是以奇想为主，偏重描写现实中不可能出现的事物。另外则有《忽必烈》等单册作品。实际上，星野之宣的作品并不限于考古类，他作品中最好看得是科幻短篇集，例如《2001夜物语》、《星辰之旅》等。

加藤元浩《Q.E.D. 証明終了》
长寿推理作。女主个性很好，吐槽役。男主则负责解决事件和卖呆。可以学到很多冷知识。另外推荐姐妹作《C.M.B森羅博物館之事件目錄》。

酒见贤一 / 森秀树 / 久保田千太郎《墨攻》
从【2012年11月总结】漫画篇看到的推荐，绝赞！历史架空类作品，讲述墨家在春秋战国帮助小国守城的故事。主人公貌不惊人，但从内到外都是纯爷们。墨家贯彻的思想是守，但常用来在科幻类、架空类作品中被描写为掌握黑科技的团体。《墨攻》其实也不例外，但更多则是对于计策的使用，和正面的冷兵器战斗。

福本伸行《賭博堕天録カイジ~和也編~》
故事拖沓得乱七八糟，但里面的心理描写和各种比喻、形容真的太赞了。和也篇把开司扔在游戏之外，实际是更加残忍的做法，开司一直都是在绝境中逆转的天才（逆境无赖），但帮不上忙绝对是最打击他心理的。半年没看了，也不知道连载到哪里了。

ヤマザキマリ《テルマエ・ロマエ》
以浴室文化为中心的穿越剧，总之是大大地夸耀了扁脸族的洗浴文化就是了。里面的各种卖呆和吐槽也是看点。

久慈光久《狼の口 ヴォルフスムント》
13-14世纪瑞士还是旧瑞士联邦时期的故事背景。画风很漂亮，故事却相反地足够黑。

岩重孝《京書店奮鬥記》
描写身为书店店长的中年大叔的奋斗故事。真实故事和略带夸张的演绎是取胜点。

櫻井寬 / はやせ淳《鐵路便當之旅》
写实类旅情作品，但中心点是铁道便当（駅弁），每话介绍一两个各具特色的便当，会专门花一页甚至并页描绘便当的样子，所以说看之前要先备点吃的东西在手边。里面对于火车、铁路的技术性描写也很下功夫，可以看得出原作者是个“鉄（てつ）”。

G

PSV吃灰中=_=，没得可推荐，因为上面的游戏都是草草玩过而已。COD8则是这两天刚开始玩。今年玩游戏太少了。

优酷广告上看到了三全的饺子，和它的新logo：

（图片来源）

等等，这强烈的既视感是怎么回事？

P.S：其实这两个logo的相似度还一般般。老早前还发现过Slipgate Ironworks（嗯，就是John Romero创办，09年倒闭的那个）Logo主体和三联书店的几乎完全一致。

今天将之前写的一个模块移植到了Windows Store App平台的项目上。模块中有UserControl，也有Page。通过Activator生成一个UserControl实例的时候出现了异常：

“System.Reflection.TargetInvocationException”类型的异常在 mscorlib.dll 中发生，但未在用户代码中进行处理

其他信息: Exception has been thrown by the target of an invocation.

查看InnerException，发现是XAML parsing failed。感觉很奇怪，因为还没有添加到主解决方案时候测试是好用的。不仅如此，直接Frame.Navigate()到Page，也会引发异常，这次直接是XamlParseException了，依然是XAML parsing failed。

抱着试试看的心理，把用到的UserControl整个从界面到code behind都注释掉了，还是有异常。再试，新建一个UserControl，还是有。

那么问题肯定出在模块内的UserControl上了，从this.InitializeComponent();跟进去，看到了奇怪的代码：

global::Windows.UI.Xaml.Application.LoadComponent(this, new global::System.Uri("ms-appx:///Carta_UiComponents/LazyLoadListControl.xaml"), global::Windows.UI.Xaml.Controls.Primitives.ComponentResourceLocation.Nested);

“Carta_UiComponents”，这里程序集名称中的点号被翻译成了下划线。就算手动改成点号也没有，因为.g.i.cs属于codgen文件，自动生成。放狗一搜，发现之前就有不少人碰到过相同的问题：Migrating Windows RP application to Windows 8 RTM – XAMLParseException、关于Visual Studio 2012 RTM 中创建windows 8 style类型的应用出现的XamlParseException 异常、http://blog.excastle.com/2012/09/06/xamlparseexception-in-winrt/，而且都提到在微软给出的Hotfix页面上，实际上并没有patch下载，所以目前来说最简单的解决方案就是——新建项目后把默认程序集名字里面的点都去掉，WTF！

一个标题三对书名号，有趣。

先说说《PSYCHO-PASS》的观后感。十月番未播映前就听说虚渊玄又作为原案和脚本作者有新作出品，结果当时误以为是《绝园的暴风雨》，看了一集就扔掉了。后来放到第三集才知道看错了片子。而总监督本广克行（《跳跃大搜查线》的监督）似乎原意就是邀请虚渊作为故事书写者，如果说现在的贴近现实、对犯罪和黑暗面不做遮掩地表现就是总监督试图达到的效果的话，那么可以说非常成功。作为出品过《攻壳机动队》的Production I.G，这次又接手了警察群像剧+SF类型的片子，熟门熟路，至少前几集看来整体氛围渲染得让人满意。但和《攻壳》不同，这部片子其实SF成分都在故事核心上，比如Psycho Pass系统、犯罪系数、Dominator等等，除此之外类似Hologram和Cyborg都是一笔带过，网络中的虚拟空间进化程度也没有《攻壳》中的那么高，基本还是在利用视觉辅助进行VR的程序，脑后插管什么的估计还得等个百十来年。

这部片子的ED《名前のない怪物》实在好听。恰好最近刚刚补完了漫画神作《MONSTER》，所以对于ED的名字非常敏感。在《MONSTER》中“名前のない怪物”是核心线索之一。ED中有句歌词则更加印证歌曲是在向《MONSTER》致敬，即“ほらみて　こんなに大きくなったの”（看吧，已经变得这么大了），这句基本就是《MONSTER》中约翰的名台词“Sehen Sie mich, das Monstrum in meinem Selbst ist so groß geworden”。

（涂黑部分有严重剧透）
除此之外，连续杀人、精神分析法、犯罪Profiling、最新一集里面提到的利用心理学进行“怪物”培养，都可算是《MONSTER》的重要概念，至于后续发展如何，会不会出现其他例如脑部影响之类的新的关联线索，只能拭目以待了。

非硬编码PropertyChanged

之前使用某WP7开发框架时候注意到他们的INotifyPropertyChanged的实现中 ，PropertyChanged不用传字符串，而是可以直接用Property本身作为参数。当时没有太注意。上周在处理一个Bug时候发现，问题出在Property的Set中，传进去的property name是错的，导致界面无法按照期望的更新。于是想到了之前那个框架的做法，找出来后一劳永逸解决问题。

改进后的PropertyChanged则可以利用作为参数存在的expression的返回值提取必要的信息出来：

        protected void NotifyPropertyChange( Expression> expression ) {
            if ( PropertyChanged != null ) {
                var propertyName = ( ( MemberExpression )expression.Body ).Member.Name;
                PropertyChanged( this, new PropertyChangedEventArgs( propertyName ) );
            }
        }

其实方案也并非完美，因为需要传递一个lambda expression进去，只不过参数为空，返回值是property本身：

        public bool AppBarVisible {
            get {
                return _appBarVisible;
            }
            set {
                _appBarVisible = value;
                NotifyPropertyChange( () => AppBarVisible );
            }
        }

但总比之前用字符串的方式好得多，因为这样一来，写错了property name，编译会不通过。在Visual Studio中，点中Property后，所有相同的对象也都会自动高亮，避免写串了的情况。

TryParse<T>

也是为了解决项目中遇到问题的副产品：页面需要解析query strings，每次都写各种类型的TryParse太麻烦了，于是想到直接在Dictionary<string, string>上加一个extension method，用于直接以期望类型返回请求字符串。

最开始写的是：

TryParseInt( this Dictionary queryStrings, string key ) {...}
TryParseDouble( this Dictionary queryStrings, string key ) {...}
TryParseBool( this Dictionary queryStrings, string key ) {...}

等写完第三个才觉得自己有病：难道有几十种type就都写成TryParseType吗！？这种情况用泛型很合适：

        public static T GetValue( this Dictionary queryString, string key ) {
            if ( queryString.ContainsKey( key ) ) {
                string value;
                queryString.TryGetValue( key, out value );
                T...(1)
            }
            return default( T );
        }

不过，(1)处应该怎么利用T进行TryParse呢？直接用T是拿不到方法的。但typeof(T)可以拿到T的Type实例，配合反射机制就能取到期望的方法了：

        private static readonly string TRY_PARSE_FUNC = "TryParse";
        public static bool TryParse( this string value, out T result ) {
            result = default( T );

            if ( !string.IsNullOrEmpty( value ) ) {
                Type type = typeof( T );
                BindingFlags flags = BindingFlags.Public | BindingFlags.Static;
                Type[] paramTypes = new Type[] { typeof( string ), type.MakeByRefType() };
                MethodInfo method = type.GetMethod( TRY_PARSE_FUNC, flags, null, paramTypes, null );

                if ( method != null ) {
                    object[] parameters = new object[] { value, null };
                    if ( ( bool )method.Invoke( null, parameters ) ) {
                        result = ( T )parameters[1];
                        return true;
                    }
                }
            }
            return false;
        }

代码比较直观，不做过多解释。使用的时候只要在刚才的方法(1)处加上下面的调用即可：

                T ret;
                if ( value.TryParse( out ret ) ) {
                    return ret;
                }

显然，这种问题不只我碰到，一定会是个群众基础广泛的话题。在Generic TryParse这个提问中，还可以看到其他有趣的解决方案。

最简单粗暴的可以直接：

TypeDescriptor.GetConverter(typeof(T)).ConvertFromString(input);

以及它的变种：直接传入type，不用泛型。试了一下，在Windows Phone平台上，TypeDescriptor拿不到。除此之外，还有将实际的Parse方法作为function delegate传入的做法，视觉上也不差。

如果有兴趣的话，还可以参考这个Mad Reflection C#的系列文章Generic Parsing，共分四部分，除了TryParse<T>之外，还完成了Parse<T>、ParseDefault<T>和Nullable类型Parse的处理，这个话题上可谓总结完整了，推荐一看。