# ときどきの雑記帖'

### 2013年08月20日

#### ■_

HN経由かなんかで知ったのですが、 Software Design Philosophy - RAMCloud Project - Confluence Added by John Ousterhout, last edited by John Ousterhout on Aug 24, 2012 (view change) あー、一年前の記事かー見ないでもいいかなーとタブをクローズしようとしたときに 編集した人の名前に気がつく。 Tcl のあの人でねーすか。 ということで読む。

Software Design Philosophy - RAMCloud Project - Confluence

This page contains John Ousterhout's recommendations for how to design clean, simple, and obvious software.
As of August, 2012 it is still a work in progress.

Design classes around information, not algorithms or time order. Each class should encapsulate and own
particular design decisions or information, so that code outside the class does not need to be aware of
them. The biggest mistake that people make is to design classes around time: collect all the things that
happen at one point in time into a single class. Read David Parnas' seminal paper On the Criteria to be
Used in Decomposing Systems into Modules, which explains why this is a bad idea, and why "information
hiding" is a better approach. Unfortunately, most people who read Parnas' paper say "d'oh,
that's totally obvious and I learned that in my introductory programming class!", then go on to write
code in exactly the way that Parnas argues against.



お、なんかよさげ。

#### ■_

あー取りあげようと思ったものは幾つもあるのに～

### 2013年08月19日

#### ■_ LLまつり

タイムテーブル - Lightweight Language Matsuri うーむ、最初のセッションどの会場も見たいのだがががが。 今年は最後までLT見ていこうかなあ。

#### ■_

One VM to Rule Them All : programmingOne VM to Rule Them All [pdf] | Hacker News で言及されてるスライドが結構面白かった。 Oracleカラーでいっぱいですが。

One VM to Rule Them All [pdf] | Hacker News

This looks interesting, but I am generally worried about something being owned by Oracle. Simple example; I own
an Openpandora. I wrote a live coding environment in Java with a very basic, lispy language at it's core. Using
any free Java implementation it either; did not start (core dump; suspect; not enough memory to get even the VM
up) or ran very (unusable) slow. With the Java 7 closed source ARM version from Oracle; runs fast (just as
smooth as on my Macbook) and uses very little memory.

I have the same experience on x86, but because of the abundance of resources it's less noticable.

I don't insist on everything being open source (completely), but base languages/VMs should be. Unless something

One VM to Rule Them All : programming

A tweet from Charles Nutter:

Good news: Oracle's Ruby-on-Truffle is 5-6x faster than JRuby. Bad news: it's closed source.
Good news: I can do the same thing for JRuby.



Oracle さんの悪役っぷりと来たら

#### ■_

ちょっと前の話題ですが、これに気がついたのは今日なので。はい。 納涼！ほんとにあった怖いコードの話 - shobuno's blog

納涼！ほんとにあった怖いコードの話 - shobuno's blog

これも大手銀行のシステムでのお話。。。

ある日、リーダーに呼ばれて、直々の命令を頂きました。

リーダー「あのさ、このコードなんだけど、銀行の利息計算をする

超重要なプログラムなんだけど、誰も触れないんだよね。」

リーダー「COBOLじゃなくて、FORTRAN(科学演算が得意なプログラム言語)

なんだよね。」

リーダー「これ、COBOLに直してくれないかな？」

リーダー「あ、そう？　出来たらで良いから。無理しなくてもいいからね。」

たったの１５行でした。

こんなの楽勝じゃん♪

しかし。。。内容の解析に、丸々３日間かかりました。

このプログラム、要するに積分計算のプログラムで、

\int_a^b f(x)\,dx

こんな感じの式をプログラムで解くもので。。。

ものなのですが、0.000001(100万分の一）ぐらいづつxの値を増やして計算していて、

FORTRANの計算誤差と、COBOLの計算誤差が上手く合わなくて、

リーダー「そうか。ありがとう。

じゃあ、このプログラムはまた封印しておこうか。。。」



### 2013年08月18日

#### ■_ ホームドア

そういやあ丸ノ内線はとっとと付いたのに銀座線が一向に…というのは ホーム幅やらの関係なんですかね。などと 東京メトロ、今年度中に有楽町線全駅でホームドア導入完了へ | マイナビニュース

東京メトロ、今年度中に有楽町線全駅でホームドア導入完了へ | マイナビニュース

おり、同社全体で84駅へ導入が完了することとなる。全179駅に対しての設置率は約47%。



#### ■_

スライドが。後で見よ。 Rakudo on JVM や MoarVM の話は miyagawa さんの podcast 最新回でもでてましたね。 YAPC::EU 2013 Slides | 6guts

YAPC::EU 2013 Slides | 6guts

This year I submitted three talks, expecting one or two would be accepted. Instead, all three were! So, I talked about:

Rakudo on JVM – this session explained the motivation for adding a JVM backend, the compiler architecture
that enabled it, how it was implemented, the current status, the support so far for Java interoperability
and the plan from here. Seems to have been well received.

Concurrency, Parallelism and Asynchrony – this session showed the work I have been doing to build basic
support for parallel, asynchronous and concurrent programming in Perl 6. This was the best attended and
also, I believe, the most discussed of my talks this year. There is still much work to do in this area, but
what’s done so far caught some interest. Once I’m recovered from YAPC, I’ll dig back into it.

MoarVM – this session talked about the motivation for building a new VM, its overall design, the current
status and what’s in store. It’s also the first talk I ever gave on MoarVM. The most lightly attended
and most hastily prepared, but still it seemed to be appreciated by those who attended.



#### ■_ awk と gawk

あれ、なんでこれ動作が違うの

kbk@toybox /cygdrive/c/Users/kbk
$seq 1 10 1 2 3 4 5 6 7 8 9 10 kbk@toybox /cygdrive/c/Users/kbk$ seq 1 10|awk '{print $1*2}' 0 0 0 0 0 0 0 0 0 0 kbk@toybox /cygdrive/c/Users/kbk$ seq 1 10|awk '{print $0*2}' 2 4 6 8 10 12 14 16 18 20 kbk@toybox /cygdrive/c/Users/kbk$ seq 1 10|awk '{print $1}' 1 2 3 4 5 6 7 8 9 10 kbk@toybox /cygdrive/c/Users/kbk$ seq 1 10|gawk '{print $1*2}' 2 4 6 8 10 12 14 16 18 20 $1 で数字列が取れてるんだから2をかけて0になるってのは妙だなあ。 実際gawkだと期待通りだし。cygwinだから実体は一緒だよなあ。 ソース見るか。

#### ■_

Technology Radar May 2013 | ThoughtWorks Prepared by the ThoughtWorks Technology Advisory Board - May 2013 5月のまま。5月の記事を今「最近公開」ってのはなんかへんじゃねーのと思いつつ 元記事見たらそっちも8月頭の記事でした。 Latest Technology Trends on the Radar ThoughtWorks recently released a new installment of their technology radar

### 2013年08月17日

#### ■_

Software Design (ソフトウェア デザイン) 2013年 09月号 [雑誌]

sed/awk 特集。awk の方の記事で名前出してくれたのはありがたいんだけど呼び捨て… いやまあ名前間違われるより(今でも根に持っているw)はましだし、 論文の類ならそうするんだろうけども。でもなあ。

#### ■_ プログラマーのジレンマ

Programmer’s dilemma — I.M.H.O. — Medium

Programmer’s dilemma

Recently I interviewed tens of candidates for a kernel programmer's position. These candidates are from big,
good companies, which are famous for chips or embedded OS/systems. Many of them claimed they have at least 10
years on-job experience on kernel. Their resumes look fairly shiny — all kinds of related projects, buzz words
and awards…

But most of them cannot answer a really basic question: When we call the standard malloc function, what happens
in kernel?
しかし彼らのほとんどは本当に基本的な質問、「標準関数の malloc を呼び出したときにカーネル内部で起きることは?」
にも答えることができないのです。

Don’t be astonished. When I ask one of the candidate to write a simple LRU cache framework based on glib hash
functions, he firstly claimed he had never used glib — that’s what I expected — I showed the glib hash api
page and explained the APIs to him in detail, then after almost an hour he wrote only a few lines of messy code.

これで驚いてはいけません。
わたしが候補者のひとりに glib のハッシュ関数を使って簡単な LRU キャッシュフレームワークを

これは自分も予期していたので、glib のハッシュ APIのページを見せてその詳細を説明しました。
それからおよそ一時間経って彼が書いたものといえば、ほんの数行の messy なコードに過ぎませんでした。

I don’t know if the situation is similar in other countries, but in China, or more specifically, in Beijing,
this is reality. “Senior” programmers who worked for big, famous foreign companies for years cannot justify
themselves in simple, fundamental problems.

justify themseleves できないのです。

Why did this happen?
なぜそれは起きたのか?

The more I think about it, the more I believe it is caused not only by themselves but also by the companies
they worked for. These companies usually provide stable stack of code, which has no significant changes for
years. The technologies around the code wraps up people’s skills, so that they just need to follow the existing
path, rather than to be creative. If you happened to work for such kind of code for a long period and did not
reach to the outer world a lot, one day you will find yourself to be in a pathetic position — they called you
“EXPERT” inside the team or company, yet you cannot find an equally good job in the market unfortunately.

This is so called “Expert Trap”. From day to day, we programmers dreamed of being an expert inside the
team/company; however, when that day really comes we trapped ourselves. The more we dig into existing code,
the deeper we trapped into it. We gradually lose our ability to write complete projects from scratch, because
the existing code is so stable (so big/so profitable). What’s the worse, if our major work is just to maintain
the existing code with little feature development, after a while, no matter how much code we’ve read and
studies, we will find we cannot write code — even if the problem is as simple as a graduate school assignment.
This is the programmer’s dilemma: we make our living by coding, but the big companies who fed us tend to
destroy our ability to make a living.

これは “エキスパートの罠”と呼ばれるものです。

How to get away from this dilemma?
このジレンマを回避するには?

For personal —

First of all, Do your own personal projects. You need to “sharpen your saw” continuously. If the job itself
cannot help you do so, pick up the problems you want to concur and conquer it in your personal time. By doing
so, most likely you will learn new things. If you publish your personal projects, say in github, you may get
chances to know people who may pull you away from your existing position.

Do not stay in a same team for more than two years. Force yourself to move around, even if in the same
organization, same company, you will face new challenges and new technologies. Try to do job interviews every
18 months. You don’t need to change your job, but you can see what does the market require and how you fit
into it.

For team/company —

Give pressures and challenges to the employees. Rotate the jobs, let the “experts” have chance to broaden
their skills. Start new projects, feed the warriors with battles.

Hold hackathon periodically. This will help to build a culture that embrace innovation and creation. People
will be motivated by their peers — “gee, that bustard can write such a beautiful framework for 24 hours, I
gotta work hard”.



#### ■_ Elixir Design Goals

Elixir の設計上の目標とか

Elixir Design Goals - Elixir

Elixir Design Goals
August 08, 2013 · by José Valim . in internals

During the last year, we have spoken at many conferences spreading the word about Elixir. We usually started
with introducing the Erlang VM, then went on to talk about Elixir goals, saving some time at the end to do a
live demo, showing some goodies like exchanging information between remote nodes and even hot code swapping.

This post is a summary of those talks, focusing on the language goals: compatibility, productivity and
extensibility.

Compatibility

Elixir is meant to be compatible with the Erlang VM and the existing ecosystem. When we talk about Erlang, we
can break it into three parts:

A functional programming language, called Erlang
A set of design principles, called OTP
The Erlang Virtual Machine, referred to as EVM or BEAM

Elixir runs in the same virtual machine and is compatible with OTP. Not only that, all the tools and libraries
available in the Erlang ecosystem are also available in Elixir, simply because there is no conversion cost from
calling Erlang from Elixir and vice-versa.

We frequently say that the Erlang VM is Elixir's strongest asset.

All Elixir code is executed inside light-weight processes (actors), each with its own state, that exchange
messages between each other. The Erlang VM multiplexes those processes onto many cores, making it trivial to
run code concurrently.

In fact if you compile any Elixir code, including the Elixir source, you will see all cores on your machine
being used out of the box. With technologies like Parallella becoming more accessible and affordable, it is
hard to ignore the power you can get out of the Erlang VM.

Finally, the Erlang VM was designed to build systems that run forever, self-heal and scale. Joe Armstrong, one
of Erlang's creators, has recently given an excellent talk about the design decisions behind OTP and the VM.

Nothing that we are describing here is particularly new. Open source projects like CouchDB, Riak, RabbitMQ,
Chef11 and companies like Ericsson, Heroku, Basho, Klarna and Wooga are already enjoying the benefits provided
by the Erlang VM, some of them for quite a long time.

Productivity


© 2012-2013 Plataformatec. All rights reserved.



なるほどねえ＞ We frequently say that the Erlang VM is Elixir's strongest asset.

### 2013年08月16日

#### ■_

アウグストゥス: ローマ帝国のはじまり

「レアメタル」の太平洋戦争: なぜ日本は金属を戦力化できなかったのか

#### ■_

PDP endian サポートのコードが削られたとかなんとか。

NWCLARK TPF grant May report - nntp.perl.org

Date:
July 26, 2013 14:51
Subject:
NWCLARK TPF grant May report

As per my grant conditions, here is a report for the May period.

This month I simplified part of the implementation of pack and unpack,
removing about 130 lines of code, and reducing the object code size by about
2K. The only casualty was support for mixed-endian systems. Sorry, PDP-11
users.

In the medal stakes for "risk to sanity", the implementation of pack and
unpack are strong contestants, although *only* for bronze. (They're fighting
it out with the implementation of sprintf. Compared with sprintf, they have
the advantage that they've been seen as sufficiently dangerous to nearby
code that they've been quarantined into their own file. The regular
expression engine gets silver, and the reigning champion and gold medal
holder remains the parser itself.)

pack/unpack is one of those pieces of code which has grown organically as
features were added, and so has become too large to easily comprehend the
big picture. In particular, it's hard to look at it at more than one level
at once, and hence see where it could be profitably refactored.

(以下長いので略)


バイトオーダーじゃないけど Ruby のpack/unpack もいろいろ大変そう。

#### ■_

Few people remember it, but the same thing happened at HP. It used to be that HP... | Hacker News

Few people remember it, but the same thing happened at HP. It used to be that HP engineers were expressly given
Friday afternoons and full access to company resources to just play with new ideas. Among other things, this led
to HP owning the printer market.

Then "professional" management came in and killed the proverbial goose. They had to focus more on the
"bottom line". To do what was easy to measure and track, rather than what was necessary for the next
step of the company, and now HP is a mere shadow of its former glory -- directionless and bleeding.

3M and Corning have largely avoided this fate, but it seems that Google won't. This should make a lot of
entrepreneurs happy, as there will continue to be a lot of top-down management-driven products that, if history
shows, will continue to be market failures. Yet somehow, I'm incredibly sad, as it seems that too many companies


そういやあ最近こういう本が 20%ドクトリン サイドプロジェクトで革新的ビジネスを生みだす法

#### ■_

あーなんかいろいろ読む気がおきねー(特にえーご)

### 2013年08月15日

#### ■_

コンパイルに失敗するまでにとんでもなくメモリを食うというはなし 50 Bytes of Code That Took 4GB to Compile : programming

50 Bytes of Code That Took 4 GB to Compile | Random ASCII

While doing evil things with macros and the inline assembler (trying to run a weird test whose purpose is not
really relevant) I managed to write a program that caused Visual Studio’s C++ compiler to allocate 4 GB of
memory and then die.

Not bad for a program that can easily fit into a single 50 column line.

I might not have noticed except that my machine didn’t have 4 GB free at the time, and the frantic paging-out
of data needed to find 4 GB of memory made my laptop completely unresponsive for a couple of minutes. If you
have a machine with more than 4 GB free then this can be a good test case for doing memory analysis with ETW,
to see if you can duplicate my results.

I’ve simplified the code down to its minimal essence because it amuses me:

void test()
{
}

Here is the compiler output:

error C2414: illegal number of operands
error C2414: illegal number of operands
error C2400: inline assembler syntax error in ‘opcode’; found ‘end of file’
fatal error C1060: compiler is out of heap space


50 Bytes of Code That Took 4GB to Compile : programming

Really, it took 4GB to fail to compile :)



Yes, 50 bytes of code that took 4GB to successfully compile would be far more interesting. Could maybe be done
with some template magic.

This just sounds like a rather common type of bug (a loop with an insufficient stop condition), which is not
surprising to find in something as complex as a compiler.



Maybe I didn't read the article properly, but he doesn't seem to explain why this happens? Or is that because
he doesn't know either?



It's an infinite loop in lexer or parser, which allocates some memory on each iteration.



So it is an infinite loop and it just fails at 4 GB because it runs out of heap space? That's less exciting
than the title.


Yes, but more interesting considering the fact it is a well known and used lexer got put into an infinite loop,
not his code.



In 50 characters? I don't think you can do much in that space :-)



### 2013年08月14日

#### ■_ いでぃおむ

while(*d++=*s++); - Yahoo!知恵袋

while(*d++=*s++);
について、keicha_hrsさんは酷い例だと回答されていたかと思います。
＞http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1211173455...

また、"実用では絶対にするべきではない書き方"ともあります。
この点について、どういう理由からでしょうか？
（それほど気にする内容なのかな？と思い、真意を伺ってみたく、質問させていただきました）

* null文字が"\0"（=0）であるとは限らない。
* 評価をwhile内側でやらない。（個人的になるべくしないようにしています）
* 優先順位が混在する書き方はしない（わかりづらいので）
などかと考え付きましたが、どれも違う気がしています。

また、いきなりで不躾な質問と思いましたが気になりましたので。。。



#### ■_ PEP8

ということで PEP 8 Modernisation | Hacker News のリンク先 peps: fb24c80e9afb で変更点を確認するとなかなか面白かったという話です。いまさら。 一行80桁制限がちょっと緩和されたというのはおいといて

    1.34 -Two good reasons to break a particular rule:
1.35 +In particular: do not break backwards compatibility just to comply with
1.36 +this PEP!
1.37
1.38 -1. When applying the rule would make the code less readable, even for
1.39 -   someone who is used to reading code that follows the rules.
1.40 +Some other good reasons to ignore a particular guideline:
1.41 +
1.42 +1. When applying the guideline would make the code less readable, even
1.43 +   for someone who is used to reading code that follows this PEP.
1.44
1.45  2. To be consistent with surrounding code that also breaks it (maybe
1.46     for historic reasons) -- although this is also an opportunity to
1.47     clean up someone else's mess (in true XP style).
1.48
1.49 +3. Because the code in question predates the introduction of the
1.50 +   guideline and there is no other reason to be modifying that code.
1.51 +
1.52 +4. When the code needs to remain compatible with older versions of
1.53 +   Python that don't support the feature recommended by the style guide.
1.54 +

   1.261 -- Use class-based exceptions.
1.262 +- Always use a def statement instead of assigning a lambda expression
1.263 +  to a name.
1.264
1.265 -  String exceptions in new code are forbidden, and this language
1.266 -  feature has been removed in Python 2.6.
1.267 +  Yes::
1.268
1.269 -  Modules or packages should define their own domain-specific base
1.270 -  exception class, which should be subclassed from the built-in
1.271 -  Exception class.  Always include a class docstring.  E.g.::
1.272 +      def f(x): return 2*x
1.273
1.274 -      class MessageError(Exception):
1.275 -          """Base class for errors in the email package."""
1.276 +  No::
1.277 +
1.278 +      f = lambda x: 2*x
1.279 +
1.280 +  The first form means that the name of the resulting function object is
1.281 +  specifically 'f' instead of the generic ''. This is more
1.282 +  useful for tracebacks and string representations in general. The use
1.283 +  of the assignment statement eliminates the sole benefit a lambda
1.284 +  expression can offer over an explicit def statement (i.e. that it can
1.285 +  be embedded inside a larger expression)


かわいそうな lambda …

### 2013年08月13日

#### ■_ TODO

perl-5.18.1 - The Perl 5 language interpreter - metacpan.org をみてて、TODOにどんなもんがあるのか気になった。 意外にたくさんあってびっくり。

todo - Perl TO-DO list - metacpan.org
Automate perldelta generation

The perldelta file accompanying each release summaries the major changes. It's mostly manually generated
currently, but some of that could be automated with a bit of perl, specifically the generation of


Configure Windows using PowerShell

Currently, Windows uses hard-coded config files based to build the config.h for compiling Perl. Makefiles are
also hard-coded and need to be hand edited prior to building Perl. While this makes it easy to create a perl.exe
that works across multiple Windows versions, being able to accurately configure a perl.exe for a specific
Windows versions and VS C++ would be a nice enhancement. With PowerShell available on Windows XP and up, this
may now be possible. Step 1 might be to investigate whether this is possible and use this to clean up our
current makefile situation. Step 2 would be to see if there would be a way to use our existing metaconfig units
to configure a Windows Perl or whether we go in a separate direction and make it so. Of course, we all know what
step 3 is.


Use secure CRT functions when building with VC8 on Win32

Visual C++ 2005 (VC++ 8.x) deprecated a number of CRT functions on the basis that they were "unsafe"
and introduced differently named secure versions of them as replacements, e.g. instead of writing

FILE* f = fopen(__FILE__, "r");

one should now write

FILE* f;
errno_t err = fopen_s(&f, __FILE__, "r");

Currently, the warnings about these deprecations have been disabled by adding -D_CRT_SECURE_NO_DEPRECATE to the
CFLAGS. It would be nice to remove that warning suppressant and actually make use of the new secure CRT functions.

There is also a similar issue with POSIX CRT function names like fileno having been deprecated in favour of ISO
C++ conformant names like _fileno. These warnings are also currently suppressed by adding
-D_CRT_NONSTDC_NO_DEPRECATE. It might be nice to do as Microsoft suggest here too, although, unlike the secure
functions issue, there is presumably little or no benefit in this case.


Write an XS cookbook

Create pod/perlxscookbook.pod with short, task-focused 'recipes' in XS that demonstrate common tasks and good
practices. (Some of these might be extracted from perlguts.) The target audience should be XS novices, who need
more examples than perlguts but something less overwhelming than perlapi. Recipes should provide "one pretty
good way to do it" instead of TIMTOWTDI.

Rather than focusing on interfacing Perl to C libraries, such a cookbook should probably focus on how to
optimize Perl routines by re-writing them in XS. This will likely be more motivating to those who mostly work
in Perl but are looking to take the next step into XS.

Deconstructing and explaining some simpler XS modules could be one way to bootstrap a cookbook. (List::Util?
Class::XSAccessor? Tree::Ternary_XS?) Another option could be deconstructing the implementation of some simpler
functions in op.c.


/w regex modifier

That flag would enable to match whole words, and also to interpolate arrays as alternations. With it, /P/w
would be roughly equivalent to:

do { local \$"='|'; /\b(?:P)\b/ }

See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-01/msg00400.html for the discussion.

optimize tail-calls

Tail-calls present an opportunity for broadly applicable optimization; anywhere that return foo(...) is called,
the outer return can be replaced by a goto, and foo will return directly to the outer caller, saving
(conservatively) 25% of perl's call&return cost, which is relatively higher than in C. The scheme language
is known to do this heavily. B::Concise provides good insight into where this optimization is possible, ie
anywhere entersub,leavesub op-sequence occurs.

Add 0odddd

It has been proposed that octal constants be specifiable through the syntax 0oddddd, parallel to the existing
construct to specify hex constants 0xddddd

Add class set operations to regexp engine

Apparently these are quite useful. Anyway, Jeffery Friedl wants them.



PowerShell でごにょごにょというのは面白そう。

#### ■_ パッチ?

定番テキストエディター「Vim」が7.4にバージョンアップ - 1,000箇所にも及ぶパッチと新しい正規表現エンジン | パソコン | マイナビニュース

8月10日(現地時間)、Vim.orgはUNIX系OSで定番に数えられるテキストエディター「Vim（ヴィム）」の最新バージョンとなる

した」と述べている。その他の変更点はVim 7.4をインストールし、「:help version-7.4」とコマンドを実行することで確



マイナーバージョンアップでも新規リリースのときに「パッチを適用」とかいうのかなあと思いつつ vim のサイトを見ると

welcome home : vim online

[2013-08-10] Finally, after more than a thousand patches, there is a new version of Vim. This is mostly a
bug-fix release. Also, many runtime files have been improved, syntax highlighting and indenting works better.
To find out the details, do ":help version7.4" after installing it. Direct link to the MS-Windows
installer. For Linux you probably want to use Mercurial for convenient building. For MacVim look here.


「more than a thousand」 だから「1000箇所にも及ぶ」よりは「千個を超える」じゃなかろうか というのはさておき確かに「patches」ってありますね。

#### ■_

あ、PEP8ネタまだ書いてなかった。

### 2013年08月12日

#### ■_

うーむ前は通ってるはずなのに見た記憶がないのがいくつか ＵＮＩＸユーザーのためのコミケット84情報ページ

### 2013年08月11日

#### ■_

あ、そうそう。mruby 本を予定していたサークルがあったのですが、 間に合わなかったらしくサンプル本の配布になってたのが残念。 ＵＮＩＸユーザーのためのコミケット84情報ページ

リンクはご自由にどうぞ

メールの宛先はこちら