Abitrarily Idiosyncratic Randomness

source: unknown

「東山覇権」盛行下的碧池这个词，几乎是个定番的萌点了。双马尾金发碧眼归国麻将日侨的威压统治了円光排行榜数载，
使得麻将军团的地位牢不可破。动画中一有搔首弄姿的镜头，屏幕前众宅男便心领神会。而年度nico某排行榜里，当壮大的BGM配着罗格翻开冠军ako酱的名字时，就能感到这王者风范：就像全屏大赤字弹幕一样霸气。

而在同人薄本界，霸主地位也高高在上遥不可及。《清纯奔放的木静酱》是一部不错的全彩短篇，可惜故事不成气候，难以动摇王座。然而，却有一部作品是円光界独树一帜的经典，震慑了女王新子瞳的王者地位——就是传说中感动2ch全J民的C79本《せめて、あの雪のように》。

这部作品是作者藤丸涉足同人界十周年的作品。虽说藤丸比较低调，并非是脍炙人口的名流。但画风却相当不错，线条俊秀，一本全彩本也相当实用，是个值得称道的绅士。

然而，这部十周年的作品，却并不是以其实用性著称，这正是她不同凡响之处。让这部作品不仅对作者而言纪念作品，更是援交作品界的一座里程碑式的存在。除此之外，同名小说以及MAD亦有爱好者制作，而作品的经典台词和分镜，更是渗入到了匿名基坛。可见《雪》是多么地震撼。

艺术手法上，《雪》是一部大量使用“留白”的作品，甚至可以说完全呈递了一张30页白纸给读者。与其浓墨重彩混体液描绘JK和大叔的床单故事，作品仅仅是让女主角雪和客人拉手让男主目击。余下的，就只是轻轻勾勒男女主间淡淡的青涩。这是一部“没有工口场景的工口作品”，没有一笔一墨淫猥，把故事和故事配套的动作戏码完全在读者脑内展开。也正是如此，原本是看中作者画风的看客，是硬生生把体液从下半身挤到了泪腺里流出来。

如果在这里做人物分析的话绝对属于多余，甚至是对作品的不敬。这部作品是经典，女主是经典的碧池妖精白无垢天使，男主是经典的迟钝缩卵。一个没有意外展开的故事，但确实是经典的故事，也正是一次、又一次碾碎读者心理防线的故事。前几页是Sucubus的开朗笑颜，下几页就是女主的无奈和夙愿。这笔触下的人物味道，不是死甜的糖也不是突兀的苦味，而是银勺轻舀咖啡，在口中化开甜味苦味醇香几个层次，在后味中品咖啡豆是如何烘焙烧制的——作品留白了女主雪的背景，却又提供了她的苦恼，让读者自然地在脑内补完。

因而刻画女主白山雪尤其经典，女主的每句台词都是经典
—— 好羡慕月村同学，真好啊，我也想谈恋爱
—— 花丘君对我没兴趣，所以喜欢，真的喜欢
—— 各种人，各种想法，我都懂，被教会了 (英译本中为 I was made to know真是被动语态在翻译暧昧语言的合适用法)
—— 像我这样的二手货，清仓甩卖也没人要啦
这似曾相识的句子，简直是掩藏在人类集体无意识中的原型，被挖掘出来压缩在几十页中冲击读者的精神。这，就是经典，恒久不变，历久弥新。

和众多薄本一样，《雪》足够给看客带来充分贤者时间。而不同的是，《雪》并不局限在短暂肤浅的生理不应期，而是对人性深层的震撼和拷问。在各处对援交的舌战)，总是能看到在遥遥道德高点上用“干净”“肮脏”的概念，反对援交。在没有论证前就用着“试想蔚然成风后社会还能干净吗”的论调强占高点。然而《雪》这部作品却展现了另一面：少女在成长和生活中的无奈和困苦，迫使少女的早熟和世故。对援交的鄙夷在宏观上或许是大义凛然的，但在微观上却显得无情无义。或许不该忘记，在臆想中或污染社会的援交，恰恰是现实里由龌龊的社会所制造的。

当然，这部作品无法脱离校园恋爱剧的范畴，金钱交易和校园纯爱的反差也是看点之一，合乎心智(尤其异性人际方面)水平(滞留)在中学时代的宅男。而最后女主去向不明，成为男主的回忆，倒也是提供了不少可以意淫之处。这样的结局倒是影射了漫画的特色：任何角色，只能成为看客精神世界里的影子。《雪》确实挖了一道沟渠让读者能意淫出一道爱河了。

《せめて、あの雪のように》是一本让人心酸的本子。其影响已经超过作品本身，演化成了”像我这样的二手货，也不会要XXX”的成句，真是又给这个漫画添加了别样的风味。然而转念一想，可能更增加了一份实用。每每看到年轻情侣亲密时，总是会有难免见不得理还乱的忧愁；又或者看到大叔拉着百褶裙的手在草地上散步时，百感交集。然而重温这个经典的镜头和台词，却瞬间心头感到：这酸爽！
啊，这酸爽！至少、像那老坛酸菜牛肉面一样

作者简介：藤丸 漫画家，原画家， 曾用名F.blue，曾与ひらめ、綾瀬三人组团出本，不过其中一人在C75的时候撂了挑子（迷上了和洛奇很像的一种网游）。藤丸也就在那个时候改了名，自 己一个人单练。藤丸的作品不多，原创气息浓厚，双手磨砺的很充分，仅有的几部同人都有很高的还原度，分镜规矩，笔法公整，平凡的剧情，简直就是一个传统的 漫画家

source: yande.re

By no several pages could one explain or exhausted the absurd bizarre creepy daunting esoteric flabbergasting type system in Scala.
Here are some aspects that Learn Scala by example does not cover.

Digest:

http://twitter.github.io/scala_school/advanced-types.html

Context Bound and Implicitly:

def sort[A : Ordered] => def sort[A](implicit x: Ordred[A])
def implicitly[T](implicit e: T) = e
http://stackoverflow.com/questions/3855595/what-is-the-scala-identifier-implicitly

Type Bound:

=:= <:< <%<
http://stackoverflow.com/questions/3427345/what-do-and-mean-in-scala-2-8-and-where-are-they-documented

Existential Type:

def foo(x: Array[_]) => def foo(x: Array[T] forSome {type T})
http://www.drmaciver.com/2008/03/existential-types-in-scala/

Self Type

class BarUsingFooable {self: Fooable => ....} // yet-to-be Fooable, make this binded to self
https://coderwall.com/p/t_rapw

Structural Type

def Quack(duck: {def quack: Unit})// inline anonymous class like ducktyping
http://java.dzone.com/articles/duck-typing-scala-structural

Abstract Type member

trait Job {type A; def get: A}
http://docs.scala-lang.org/tutorials/tour/abstract-types.html

Type Level Programming:

http://apocalisp.wordpress.com/2010/06/08/type-level-programming-in-scala/

Miscellaneous:

http://stackoverflow.com/questions/1025181/hidden-features-of-scala

Last but not least:

Site significantly serving Scala symbol soup salvage saves spiritually severed souls

TL;DR: Descriptor in Python is just getter/setter

Three ways to implement descriptor:

1. Use a class that implement magic method __get__, __set__, __delete__
2. Use builtin function property(fget=None, fset=None, fdel=None, doc=None)
3. Use decorator form of property, like @property def attr(): ..., @attr.setter, @attr.deleter

Make sure all three methods are done at class level rather than at instance level.
(That is, write my_attr = property(...) under class MyClass(object): statement,
but not self.my_attr = property(..) in __init__)

Because Python’s MRO is:

1. find attr in instance.__dict__ (instance level)
2. if not found, find attr in instance.__class__.__dict__. If found, try return attr.__get__, otherwise return attr (class level)
3. if not found, repeat step 2 on instance.__class__.__base__ until attr found or no base class found
4. if not found, try returning computed attr if __getattr__ is defined

So the descriptor magic is done at class level

Pitfall:

Because descriptor dwells at class level, if one uses descriptor class implementation, all instances may share one common variable.

To fix that:

1. Hoard one hidden variable in the instance
2. Use a dictionary in descriptor class to store info of different instances.

The second solution needs the class hashable. (So a meta class is needed to guarantee hashability)

Personal view: To maintain Python’s one simple way to work Pythonists just introduced much more complexity.

Reference:
http://www.ibm.com/developerworks/library/os-pythondescriptors/
http://nbviewer.ipython.org/urls/gist.github.com/ChrisBeaumont/5758381/raw/descriptor_writeup.ipynb
http://docs.python.org/2/howto/descriptor.html

source: かみやまねき

TL;DR: The most intuitive implementation of BFS is using Queue

Just out of fun, I wonder whether BFS can be implemented without Queue.
While DFS can be easily done by recursion, naive BFS implementation just incurs loop mayhem.

The first solution jumped into my mind is to add a depth parameter into BFS function.
The search function only visits nodes whose depth equals to the parameter and skips nodes whose depth does not.
I am not alone

Generator is sweeping NodeJS community (admittedly this is my exaggeration). I’m quite obsessed with generator’s suspension power. Here’s my try in Python.

'''
    implicit BFS, without queue or depth
    incurs infinite circulation on loop graph
    implement for fun (Really need a queue)
'''
def bfs_gen(node):
    '''
    generator function on a node, yield an iterator of frontier nodes
    the first call yield an iterator contains the node itself
    each subsequent call yields an iterator that is composed of children's gen
    try line chains children's yields, and thus accumulates frontier nodes
    By recursion, the root node's bfs_gen yields all frontier nodes on the graph
    frontier is maintained on callstack, by the suspension feature of generators
    '''
    try:
        yield iter((node.value, ))
        # :( still needs a list to maintain generators
        children = [bfs_gen(n) for n in node.children]
    except AttributeError:
        raise StopIteration

    chain = 0xDEADBABE
    while chain != ():
        chain = ()
        for child in children:
            try:
                chain = (e for it in (chain, next(child)) for e in it)
            except StopIteration:
                continue
        yield chain

def bfs(root, pred):
    '''
    make generator on root node
    call next method to yield frontier nodes
    apply predicate function on it, if any matches, return True
    else continues to yield more frontier
    '''
    gens = bfs_gen(root)
    try:
        while not any(pred(v) for v in next(gens)):
            continue
        return True
    except StopIteration:
        return False

def main():
    '''
    3 4 5 6
     1   2
       0
    '''
    from collections import namedtuple

    node = namedtuple('Node', ['value', 'children'])
    six   = node(6, [None])
    five  = node(5, [None])
    four  = node(4, [None])
    three = node(3, [None])
    two   = node(2, [five, six])
    one   = node(1, [three, four])
    zero  = node(0, [one, two])

    def demo(value):
        '''dumb log'''
        print(value)
        return False

    # bfs(zero, demo)
    for i in bfs_gen(zero):
        demo(i.value)

if __name__ == '__main__':
    main()

Wow, much ugly, very obscure. But a old post on certain unsung site gives me an interesting solution.

def bfs(root):
    yield root
    for node in bfs(root):
        for child in node.children:
            yield label(child)

Tada, done! Let’s peruse this piece of code.
We want a generator that yields a sequence of nodes, this can be done by induction.

1. Given the root of a tree, clearly the first node of the sequence is the root
2. Because the next level of frontier nodes in the sequence is the children of the current level frontier nodes, construct a new sequence that lags behind.
3. yield each child given its parent.

Doing this recursively makes a BFS generator.

The trick part is the second step, for a normal function, this will make infinite loops. But generator is expanded dynamically, execution jumps out of BFS, eschewing looping condition. Suspension of code also implicitly stores searching states, where calling stacks morph into a Queue. Of course, visited nodes also need to be maintained in a list(not checked here). Termination check is absent, as well.

Interestingly, adapting BFS into DFS only requires swapping two lines, just as substituting stack for queue in classical implementation.

def dfs(root):
    yield root
    for node in node.children:
        for child in dfs(node):
            yield child

Whatever fun generators have brought, BFS/DFS should probably never done like this. Storing information in stack does not save space. Static language like C/C++ lacks such generator feature. And, notably, function overhead and slow generator in most script language make developers repugnant to such winding trick.

source: pixiv

Web scrapping is a common task for script languages like python.
Yet Python standard libraries provide twisted utility to couple with this simple task. urllib[23$] ruins my python newbie days.
To achieve cookie support, you have to import cookielib, create a new cookie jar via the factory method, subclass a opener from the urllib, and finally use the forged opener to make a request.

Bloated boilerplate code does not seem pythonic at all. We want a simple scrapping utility that provides concise API like http verbs and, preferably, automatic session management. Request is the library comes to rescue.

The structure of Request:

• model
• session
• adapter
• api
• etc…

model irons response and request parameters into unified objects. Both Request and Response supports generator style and file style. Magic methods empowers Request pythonic syntax. The most dirty works(say, encoding stuffs) lies here.

session acts as controller in MVC design. It combines adapter, which sends request, authentication and cookie session. Request’s streamlined API stems from an interface mocking real browsers.

adapter is a wrapper of urllib3, supporting connection pool management, keep-alive request and proxies.

api is just an alias for 1. open session 2. prepare request 3. send request. And all other modules are helpers that do stuffs like encoding and making auth token.

The design philosophy under Request is : Simple is better than functionality, however, it still grants users plenty of features.
Specific as the library aims to be, the philosophy underlying it applies much wider. jQuery’s almighty $, Chrome’s omnipotent omnibox, Google’s preeminent search engine and etc. Simplicity rocks, Usability counts.

source: pixiv

Exercises: Drink a beer to console yourself about Vim’s coercion of strings to integers.
– Steve Losh, Learning Vimscript the hard way

Vim is a superb and classy text-editor, but VimScript, well, is far from a usable scripting language.

Vimscript is extremely powerful, but has grown organically over the years into a twisty maze ready to ensnare the unwary who enter it.
Options and commands are often terse and hard to read

On the surface, VimL looks like an agglomeration of Lua, Perl and primitive Vim configuration language. A litany of reserved words and special operators, along with Regex line-noises, gives rise to yet another write-only language. VimL supports both function call and primitive command, which seasons VimL with one more layer of complexity and inconsistency.

This is culpable, but is not the most irremediable obfuscation of VimL. The tittle should belong to event system. Vim executes one and only one handler for an event once a time. To bind multiple handlers to one event, users have to write their own custom function.

It seems very easy for anyone, but at field, handling Vim plugin conflicts is a Herculean task. Vim comes out with many plugins loaded, and users’ .vimrc are liable to frequent editing. Maintaining a list of event handlers requires a user to face with plugins’ source code(verbose namespace, illegible syntax, Byzantine structure, or line noises fraught with all the aforementioned three). And this will be users’ chronic concern since Vim’s configuration are constantly changing. What’s more, VimL’s events are not sufficient. Until recent that Vim 7.3 adds InsertPre event, there is no event for pressing arbitrary key. Users have to write recursive function to capture all keys

Lastly, there is little VimL material users can find. Vim’s help doc is the only comprehensive and up-to-date document, but it is awkwardly organized. Vim community also favors Python over VimL, indicating that VImL will have less chance to get enhancement. Over the internet, few complaints and swearings about VimL are heard. It shall be interpreted as few VimL developers instead of few VimL defects.