読者です 読者をやめる 読者になる 読者になる

真面目に、強く、上品に

真面目に、強く、上品に

特定の相手のAmazonアフィリエイトリンクを生成する

何故するか

皆さんはAmazonアフィリエイトIDを持っているでしょうか。

Amazonアフィリエイトは御存知の通り、特定のIDを含んだURLからAmazonの商品を購入することで、IDの管理者にお金が入るサービスです。

何かWeb上の記事を経由してAmazonで商品を購入した場合、たいていこのAmazonアフィリエイトIDが入っていると思います。

アフィリエイトIDの所有者自らが自身のID経由で購入しても利益にはならないことから、 わざわざ自分がamazonで何かを購入する時に、他人のアフィリエイトIDを設定するという人はあまり多くないと思います。

しかし個人的にそれは非常に勿体無いと思うので、是非他人のアフィリエイトリンクを踏んで購入することをおすすめしたいです。

その理由としては以下のとおりです。

購入者が不利益を被ることはない

自分の行為で他人が儲かるのを不快に感じてしまう人が一定数いるとは思いますが、少なくともamazonアフィリエイトリンクの場合は、 他人のアフィリエイトリンクを踏んだことにより購入者が被る不利益は全くありません。

押し売りされるといった場合は話が別だとは思いますが、元々買う意欲があったからこそ購入しているわけで、購入した結果にアフィリエイトリンクのあるなしは関与しません。

利益のシェアが出来る

例えば数人グループでお互いのアフィリエイトIDを使うことを取り決めた場合、そのグループの全体の金額はアフィリエイト収入分だけ少なくすることが出来ます。

Amazonのヘビーユーザ/ライトユーザで多少儲けに偏りが出ることはあるとは思いますが、元々利益にならない予定だったものを利益にしているわけです。

あまり細かいことは気にせず、収入があることを喜びましょう。

喜びをグループで分かち合える

グループでお互いに収入があったことを報告し合えば、世知辛い人生を多少なりとも楽しくすることが出来ます。

その連帯感はいずれ世界を救わないとも限りません。

グループの連帯感を大切にしましょう。

特定の相手のAmazonアフィリエイトリンクを生成する方法

さて、これで他人のアフィリエイトリンクを踏む有用性が理解できたとは思いますが、いちいち自分で他人のアフィリエイトタグを入力するのはちょっとばかり手間です。

ということを少し話していたら、hirokikana (Hiroki Takayasu) · GitHub さんが 翌日 Amazon Affiliate Link Generator - Chrome Web Store 拡張を作ってくれました。

設定も簡単だし、皆さんも是非こちらを活用してみましょう。

終わりに

柄にもなくAmazonアフィリエイトリンクについて語ってみましたが、いかがでしょうか。

アフィリエイトリンクについて毛嫌いする方も多いとは思いますが、大多数の人にとってアフィリエイトリンク収入は雀の涙ほどのものです。

しかし雀の涙ほどの収入でも、利益があるというのは大変うれしいし、素晴らしいことです。

もしかしたら人生になんの希望も愛も感じられなかった人が、とある人からのアフィリエイト収入で生きる希望を見出した、という事例もあるかもしれません。

良いアフィリエイト生活を。

世界一やさしい アフィリエイトの教科書 1年生
世界一やさしい アフィリエイトの教科書 1年生染谷 昌利 イケダ ハヤト

ソーテック社 2015-01-17
売り上げランキング : 19281


Amazonで詳しく見る
by G-Tools

プログラミングはスキマ時間にこそやるべき

概要

プログラミングはゾーンに入るまでの時間が長いため、スキマ時間にプログラミングをやることに対して躊躇いが発生してしまうことがあるが、 以下の理由からむしろスキマ時間にこそプログラミングをやるべきなのではないか。

プログラミングをスキマ時間にやったほうが良い理由

この場合のスキマ時間とは 10分〜1時間ぐらいを指す。

心理的障壁を低減出来る

スキマ時間ならばプログラミングに対するモチベーションが沸かないときにでも、心理的障壁が少ない状態でプログラミングに取り掛かることが可能である。

モチベーションを維持出来る

スキマ時間にプログラミングをすることで、コードは常に中途半端な状態になるため、この作業を終わらせたいという意欲が、じっくり取り掛かれる時間帯まで維持される。 それにより、じっくり取り掛かれる時間におけるプログラミングに対する心理的障壁が少なくなる。

ちりも積もれば山となる

1日30分、スキマ時間にプログラミングするとした場合、1ヶ月で 30 * 30 / 60 = 15時間 のプログラミング時間が確保出来る。

密度の高い時間を過ごせる

時間があると思うとだらだら作業しがちだが、30分なら集中した時間を過ごすことが可能

結論

スキマ時間にプログラミングをやることに対して躊躇いは必要ないし、積極的にやったほうが良い。

Flask Blueprint における template_folderパス解決の罠

Flask には Blueprintというアプリケーションをモジュール化出来る機能が備わっていますが、このBlueprintのtemplate_folderパス解決にはちょっとした罠があります。

Flaskで以下のようなパッケージ構成を組んだと仮定します。

run.py
admin/
    __init__.py
    views.py
    pages/
        index.html
frontend/
    __init__.py
    views.py
    pages/
        index.html

admin/views.py

from flask import Blueprint, render_template
admin = Blueprint('admin', __name__, template_folder='pages')

@admin.route('/')
def index():
    return render_template('index.html')

frontend/views.py

from flask import Blueprint, render_template
frontend = Blueprint('frontend', __name__, template_folder='pages')

@frontend.route('/')
def index():
    return render_template('index.html')

run.py

app = Flask(__name__)

from admin.views import admin
app.register_blueprint(admin)

from frontend.views import frontend
app.register_blueprint(frontend)

一見template folder として admin/views.py では admin/pages/ を 、 frontend/views.py ではfrontend/pages/ を参照するように読めます。

しかしこのコードは正常に動作しません。

admin/views.pyfrontend/views.pytemplate_folder が、admin/pages/ になるか 、 frontend/pages/ になるかは不定となります。

Flask Blueprintのマニュアルを参照してみると以下のように記述があります。 Modular Applications with Blueprints — Flask Documentation (0.10)

So if you have a blueprint in the folder yourapplication/admin and you want to render the template 'admin/index.html' and
you have provided templates as a template_folder you will have to create a file like this: yourapplication/admin/templates/admin/index.html.

つまり、以下のようなパッケージ構成にする必要があるということです。

run.py
admin/
    __init__.py
    views.py
    pages/
        admin/
            index.html
frontend/
    __init__.py
    views.py
    pages/
        frontend/
            index.html

admin/views.py

from flask import Blueprint, render_template
admin = Blueprint('admin', __name__, template_folder='pages')

@admin.route('/')
def index():
    return render_template('admin/index.html')

frontend/views.py

from flask import Blueprint, render_template
frontend = Blueprint('frontend', __name__, template_folder='pages')

@frontend.route('/')
def index():
    return render_template('frontend/index.html')

この仕様は度々Flaskの利用者に誤解を与えてきたようで、以下のように Issueでも議論にもなりました。 Blueprint template lookup not documented enough · Issue #266 · pallets/flask · GitHub

なぜこのような仕様になっているかというと、実装上の都合です。

Flaskで指定するtemplate_folderは Jinja2 の FileSystemLoader のsearchpathに渡されます。

searchpathはアプリケーションのトップレベルに追加され、再帰的に検索されるため、template_folderで指定したディレクトリ文字列がかぶっているとどのテンプレートを選択すれば良いのか一意に特定出来ません。

そのため、このような仕様になっています。

Flask Web Development: Developing Web Applications with Python
Flask Web Development: Developing Web Applications with PythonMiguel Grinberg

O'Reilly Media 2014-04-28
売り上げランキング :


Amazonで詳しく見る
by G-Tools
Pythonスタートブック
Pythonスタートブック辻 真吾

技術評論社 2010-04-24
売り上げランキング : 1920


Amazonで詳しく見る
by G-Tools

数万円の炊飯器が1500円で買った炊飯土鍋に負けた

cook

最近にわかに注目を集めている炊飯土鍋。

私も同僚から布教されて最近炊飯土鍋を使い始めたのですが、すっかり虜になってしまいました。

「炊飯土鍋を使うと炊飯器が不要になる」、布教者は口々にそう言います。

しかし元々炊飯は鍋でしていたしそれを淘汰するメリットがあったからこそ炊飯器は消費者に広く普及したはず。

そう考えていた私はその布教の言葉に半信半疑だったのですが、実際その通りになってしまいました。

理由としては炊飯器と炊飯土鍋、どちらにもメリット・デメリットはあるのですが、 総合すると明らかに炊飯土鍋の方が上という結論に至る人が多くなってきた、ということでしょう。

比較するために、私の考える炊飯器・炊飯土鍋のメリット・デメリットなどを項目別にまとめてみました。 3合炊きを前提とします。

価格

炊飯器は安いものは電気釜で5000円ほど、IHで高価なものは5万ほどします。 炊飯土鍋は安い商品なら1500円ほどで購入でき、高いものでも1万円以内であることが多いです。

価格の面では明らかに炊飯土鍋に優位性があるでしょう。

耐久性

炊飯器は機械的に壊れるリスクがあり、炊飯土鍋は割れるリスクがあります。

炊飯器が機械的に壊れた場合は、新品を正規のルートで買えば1年のメーカー保証があります。 炊飯器を1年より長い期間使用した時の故障率については、明確な資料がなかったため不明です。

ただ経験的に言うと私は、炊飯器はそれほど壊れやすいものではないと思います。

炊飯土鍋のAmazonレビューで安い商品は「炊く時に割れた」という評価がされている時もあるので、 意外と割れるリスクは高いのかもしれません(私の身の回りで割れた人はまだいませんが)。

ただ割れても安いものであれば1500円ほどなので、あまり故障率は気にしなくても良いと思います。

物理的に落として割れるリスクが一番高いと思うので、炊飯器よりは慎重に扱ったほうが良いでしょう。

美味しさ

これは圧倒的に炊飯土鍋の方が良いと考えています。

炊飯器は高級なものであればあるほど美味しく炊けるのですが、最上位の炊飯器でさえ1500円の炊飯土鍋に敵わなかったです。

そして炊飯土鍋はおこげを簡単に作ることが出来、おこげの量で風味も変わってくるので、 味のバリエーションを簡単に出すことが出来るというメリットもあります。

また、私の経験的には炊飯土鍋で炊いたお米は冷蔵庫で冷やした後温めなおしても美味しさが劣化しにくいです。

設置条件

炊飯器(電気釜)の場合は電源の確保ができるところ、炊飯土鍋であればガスが使用できるコンロが前提となります。

電源がない家屋はあまりないと思いますが、ガスコンロが使えない家屋はそれなりにあるため、設置条件は炊飯器の方が緩いです。

手軽さ

これについてはだいぶ人によって評価が変わりそうです。

炊飯土鍋は基本的に米を30分以上水に浸すのが前提になりますが、炊飯器ではそういう前提は無いです。 ただ炊飯器で炊く時も水を30分以上浸したほうが美味しく炊けるので、これについて私は特に炊飯器との違いを感じませんでした。

炊飯土鍋に比べ炊飯器は、安全に炊ける、予約機能が使える、炊きあがるまで時間管理をしなくて良いという長所があります。

炊飯土鍋の場合は火を使うため、時間を測って安全と炊きあがりに注意して炊く必要があります。

炊飯土鍋は3合炊きの場合、火にかけるのは15分ほどです。 コツを掴めば15分タイマーで測ってあとは火事にならないように気をつければいいだけです。 むらす時間を併せても30分ほどで炊きあがるので、炊飯器と比べてそれほど面倒だとは私は感じませんでした。

まとめ

以上のようにまとめてみましたが、どの要素に重きをおくかというのは人によって変わってくるとは思います。

ただ多くの炊飯土鍋愛好家は、明らかな美味しさと手間はそれほど炊飯器と変わらないという認識から、炊飯土鍋を選択しているように感じています。

そして私の周りでは、炊飯土鍋を試してから、炊飯器を使う生活に戻った人は一人もいません。 そう、ただひとりとして。

既にちょくちょく炊飯土鍋の紹介記事が出ているので、私があえて宣伝する必要は無いかもしれませんが、 この記事で炊飯土鍋愛好家が増え、よりよい自炊生活を送るきっかけとなれば幸いです。

和平フレイズ ほんわかふぇ 炊飯土鍋 二重蓋 3合炊 HR-8382
和平フレイズ ほんわかふぇ 炊飯土鍋 二重蓋 3合炊 HR-8382 炊飯 ごはん土鍋 3合炊き(二重蓋) 大黒 万古焼有田焼 遠赤セラミックス ご飯用保存容器 おひつ君(1500cc)

ニコニコ動画にartihata動画を投稿しました

clojure 関数型 Functional Java JavaScript

株式会社ドワンゴの運営するニコニコ動画にEmoji組版編集サービス artihata の紹介動画をアップしました。

artihata では言語はClojureClojureのWebアプリケーションフレームワークである Luminus を採用しています。

ほとんどの実装はJavaScriptで記述されているので、Webアプリケーションフレームワークはあまり関係がないのですが、Luminusはテンプレートが豊富でぱっと実現したいサービスがさくっと作れるのが良いですね。

Clojureで一番のオススメWebアプリケーションフレームワークです。

Clojureは覚えることも少なく、プログラミング経験があまり無い人でもアプリケーションをさくさく書けます。

とりあえず、以下の書籍を読んでおけばアプリケーションを書くには必要十分だと思います。

プログラミングClojure 第2版
プログラミングClojure 第2版Stuart Halloway and Aaron Bedra 川合 史朗

オーム社 2013-04-26
売り上げランキング : 341785


Amazonで詳しく見る
by G-Tools

Clojure日本語書籍まとめ[2015年6月時点]

Clojureの日本語書籍も数冊出るぐらいになりましたので、ここで一つ2015年6月時点でのClojure日本語書籍についてまとめてみました。

プログラミングClojure 第2版

Clojureの日本語書籍といえばまずコレ。

ハワイ在住Lispハッカーとして有名な川合史朗さん訳なだけあって、こなれた日本語での正確な記述は他のClojure日本語書籍の追随を許さないです。

内容も特別難しい訳ではないので、関数オブジェクト、ポリモーフィズム、マルチスレッドプログラミング辺りの概要が把握できていれば、 プロトコル、ソフトウェアトランザクショナルメモリ、エージェントなどのClojure特有の機能についてもすんなり理解できると思います。

おいしいClojure入門

プログラミングClojure 第2版 に比べて、周辺ツールフレームワークに焦点を絞って解説したのが本書です。

Clojureは言語自体の魅力もありますが、デファクトスダンダードとなっているLeiningen、Clojureらしいサウンドプログラミング環境Overtoneなど、Clojure独自の周辺ライブラリ・ツールも魅力のうちの一つです。

本書ではClojureでよく使われる一通りのツール・ライブラリが解説されているので、どのようなツール・ライブラリを使えば目的を達成できるかを考えるときに本書は指針になるでしょう。

ただしClojureの周辺ライブラリは結構個人依存のプロジェクトが多いので、メンテされなくなるものも多いです。 本書を参考にしつつも、今流行っている・メンテが継続されているプロジェクトを把握するためにはgithubを巡回したほうが良いでしょう。

はじめてのClojure

dic.nicovideo.jp で有名になったニャンパス株式会社代表が執筆したのが本書。

内容自体は悪くないと思うのですが、 プログラミングClojure 第2版 の内容が素晴らしいので、領域がかぶる部分についてはこれより見劣りしてしまいます。 ただ プログラミングClojure 第2版 よりも価格は安いので、それなりに安い価格で言語の概要を把握したい方には良いと思います。

Clojureによる、初めての関数型プログラミング

Kindle専売のClojure日本語書籍です。 なんと100円。 題材となるゲームをClojureで実装していく過程を追えるので、体当たり的に学習したい方はこの本がオススメです。

Clojure Essentials: 入門書では飽き足らない人へ

プログラミングClojure 第2版 のそれぞれの単元を少し補完・踏み込んだ形で解説したのが本書です。

Effective Clojure的なものが欲しい方にオススメです。

まとめ

私が把握している限りで日本語でのClojure書籍をまとめてみました。 他にもClojureの日本語書籍を知っている方がいらっしゃれば教えていただければ幸いです。

さて、どの本を買えば良いかですが、個人的には プログラミングClojure 第2版 さえ読んで、あとは Clojure - home を読んでいくで十分な気がします。

あまり踏み込んだ解説はしませんでしたが、とりあえず現時点での選択肢として以上にまとめてみました。

興味がある方の参考になれば幸いです。

ClojureのAgentで生成されるスレッドプールのサイズを変更する

ClojureのAgentの実装では、2 + Runtime.getRuntime().availableProcessors()で得られるサイズでスレッドプールを生成するが、このスレッドプールのサイズはset-agent-send-executor!に任意のExecutorServiceを渡して書き換えることが出来る。

set-agent-send-executor!が追加されたのはどうやらClojure1.5からのようだが、実装は、

(set! clojure.lang.Agent/pooledExecutor executor)

しているだけ。

以下のように使えばAgentのsend関数で使用されるスレッドプールを変更出来る。

(set-agent-send-executor! (Executors/newFixedThreadPool 20))

Flocking - Web Audio APIを使用した音響合成エンジン(その1)

javascript sound

FlockingとはJavascriptで実装されたWeb上で動く音響合成エンジンです。

日本語での紹介記事が現時点で皆無なので、紹介したいと思います。

Web Audio APIをラップする形で実装されており、 ブラウザが対応さえしていれば、Flashなどのプラグイン無しでマルチプラットフォームの音響合成処理を行えるのが特徴です。

このFlockingを使用し、実際にどのようなことが出来るかというのは、まずデモを見ていただいた方が早いと思います。 http://flockingjs.org/demos/interactive/html/playground.html#amp_mod

上記のデモにあるコードはブラウザから直接書き換え・実行することが出来ます。 そのためしばらく触っていれば、どのようなことが出来るのかはおおよそ把握できると思います。

JavaScript連想配列で柔軟な設定が行えるため、 ひと通りの音響合成を複雑なコード無しに実現することが可能です。

Flockingを使用する上で最低限理解する必要がある概念は下の4つです。

  • Unit Generators

Unit Generatorsは音声合成のベースと波形を生成します。 このUnit Generatorsによりシンセサイザーをコントロールする波形、シンセサイザーの入力波形を生成することが可能です。 Unit Generatorsは複数の入力と1つの出力を持ち、複数のUnit Generatorsを繋げることが可能です。

  • Synths

Unit Generatorから生成された波形を元に実際の音を生成します。 Synth自体にUnite Generatorが内蔵されているものもあります。 DAWなどでいうインスツルメントに近いです。

  • Environment

Unit GeneratorsとSynthsがそれぞれどのように繋がっているかを管理します。 DAWなどでもEnvironmentという名前で同じ名前が使用されます。

  • Scheduler

Synthsの実行タイミングを制御することが可能です。 DAWなどでいうシーケンサーに近いです。

今回は単純にFlockingの概要についてだけ説明しました。

次回は実際にFlockingを使用し、どのように音響合成を行うかについて説明をしたいと思います。

Homebrewでantがインストール出来ない問題に対処

HomebrewでAntをインストールしようとbrew install antを実行したところ、 以下の様なメッセージが表示された。

==> Downloading http://www.apache.org/dyn/closer.cgi?path=ant/binaries/apache-ant-1.9.2-bin.tar.gz
==> Best Mirror http://ftp.tsukuba.wide.ad.jp/software/apache/ant/binaries/apache-ant-1.9.2-bin.tar.gz

curl: (22) The requested URL returned error: 404 Not Found
Error: Download failed: http://www.apache.org/dyn/closer.cgi?path=ant/binaries/apache-ant-1.9.2-bin.tar.gz

どうやら、リンク切れなようである。

対処するため、とりあえず/usr/local/Library/Formula/ant.rbの 5,6行目のurlを1-9.3に変更して、sha1も変更。

再度、brew install antでインストール完了。

brewのコマンドを駆使するともっとうまいやり方がありそうだが、 ぱっと調べて出てこなかったのでとりあえずこの方法で対処。

もっとスマートなやり方あれば教えて下さい。

追記) Homebrewのmaster見たら2013-12-29に1.9.3にupdateされていたので、単にリポジトリをmasterに合わせれば問題ないっぽい。 https://github.com/Homebrew/homebrew/blame/master/Library/Formula/ant.rb#

以下のプルリクエストで修正されていた。 https://github.com/Homebrew/homebrew/pull/25537

nicosearch をPyPIで公開

python

ニコニコ検索APIPythonから使用する簡単なラッパーライブラリを書いたので、試しにPyPIに公開してみました。

https://pypi.python.org/pypi/nicosearch https://github.com/ymizushi/nicosearch

  • インストール方法
pip install nicosearch
  • 使用方法
from nicosearch import SearchRequest, SearchQueryBuilder
query = SearchQueryBuilder(u'MMD').build()
print SearchRequest(query).fetch().get_contents()

optionはSearchQueryBuilderのキーワード引数として渡してやることにより実現できます。

今回書いたのはとても短い簡単なラッパーですが、一応世界中から pip installで簡単にインストールされる可能性があるので、 ソフトウェアを公開している、という実感が湧いてきました。

今まではただ単に楽しいからというだけでコードを書いていましたが、 これからは、公開できるソフトウェアをつくる、という意識を持つことも必要かな、と思いました。

Clojureのevalとmacroのパフォーマンスを比べる

Clojureには他の動的型言語と同様に文字列*1をプログラムとして評価出来るevalという関数があります。 Clojureにはマクロがありますし他の動的型言語と同様にevalは遅いだろうという推測は容易に出来ますので、evalを使わないといけない局面というのはそう多くないと思います。そもそもeval自体害悪であるとも考えられます。

ただプログラムを書いていてふとevalはどの程度遅いのかということが気になったので簡単に計測してみました。

clojureのevalとmacroで実行時間を比較

bashpythonclojure3つの言語が混在していますが、 10 * 10をeval版、macro版、関数版で10000回実行するプログラムを、20回実行しその平均を取っています。 dotimesはdotimesだけでどれぐらいの時間がかかるのかを計測するために入れています。

結果以下のようになりました。(単位はms)

eval: 8666.7311
macro: 2.3436
fn: 7.67685
dotimes: 0.896

実行時の環境、evalする対象、macroにする対象によって数値は多少変わるとは思いますが、 見て分かる通りmacro版、関数版に比べてeval版は1000倍以上遅いです。

あと関数版とマクロ版を比べたらマクロ版の方が早いように思いますが、 これはマクロが呼び出し元で展開され実行されるのに対して、関数版はユーザ定義の関数を呼び出さなければならないことによるものでしょう。 この辺り、ベンチマーク自体が即席のものであり、また実行時間も短いので、信頼性の高いものではありません。この辺りはちゃんと検証する必要があります。

ただ数回実行する即席で実行するプログラムならまだしも、同じような処理が走りパフォーマンスが重要になるような局面ではevalは絶対に使えないとは言えると思います。

*1:Clojureについてはクオートされている必要がある

Racketのdot記法を使う

racket

Racketのdot記法は、基本的にリストの最後の要素の前に付きますが、 (1 . < . 2)と書くと、(< 1 2)等価に評価される*1同様にみなされるようです。

dot記法がペアを生成する(cons x y)の省略記法であることを考えると、 この記法は例外的に感じられます。

しかし、この記法を用いることにより、 中置記法っぽく、式を記述することが可能になります。 例えば、 (< 1 2)という式は (1 . < . 2)という表記をすることが出来るので 中置記法に慣れている方はこちらの方が見やすいのかもしれません。

試しにこの記法を使ってProjectEulerの第1問の解答を書きなおしてみました。

dot notation

しかしこれではいくら中置記法に近いと言っても、 かなり見にくくなってしまったように感じられます。

LISPの場合は、前置記法により、(= 1 1 1)(+ 1 2 3 4)といった、 任意の数の引数に対して、一つのオペレータを適用出来るという利点がありますが、 この場合その利点がなくなってしまいます。

<>といった比較関数、is-a?といった関数を使用時英語の語順に沿った評価順序*2式の構文にしたい場合に限定的に使用できるかもしれませんが、dot記法を使うと、スペースが余分に空いてしまいますし、 評価順序*3式の構文はLISPをしばらく使うだけで慣れによって全く気にならなくなるので、 これから使う機会はあまり無いように感じられました。

Pairs Lists and Racket Syntax

*1:コメント指摘により訂正

*2:コメント指摘により訂正

*3:コメント指摘により訂正

Lispは読みにくい以上に書きにくいと感じている人が多い説

Lispが流行らない理由として「括弧が多い」ということはよく挙げられる要素だと思います。

それでは何故「括弧が多い」ことが敬遠されるかというと、以下の2つが考えられます。

  • 読みにくい
  • 書きにくい

そのビジュアル面から、「括弧が多い」ことで「読みにくい」というイメージを持ちがちですが、 それ以上に「書きにくい」ことがネガティブな要素になっている気が最近してきました。

Lispのコードを書く際に、環境として必要となる要素については最低限以下のものが考えられます。

  1. 対応する括弧を強調表示
  2. 対応する括弧の削除
  3. 指定範囲への括弧挿入
  4. 対応する括弧にジャンプ
  5. 選択括弧のREPL実行

このような構成要素についてはエディタやIDEの設定をちょっと変えたり、プラグインを追加すればすぐに実現可能なことが多いのですが、プログラミング歴がそれなりに長い人でもあまり環境を最適化するという習慣を持っていない場合があり、 環境整備の敷居が想像している以上に高いのではないか。

一般的なプログラミング言語の場合、たとえメモ帳でコードを書くとしても プログラムが書けないということも無いと思いますが、 Lispの場合エディタ、IDEの支援がなければコードを書くのもままならない羽目に陥ることは 容易に想像できます。 個人的に1,2,3が無ければかなりきついです。

ということで、もし仮にLisp系の言語が流行るととなると、 言語以上に開発環境が重要になるような気がしました。

尤も、Lispが流行る、そんな日は未来永劫来ないのかもしれません。

しかし寿命で言うと、Lispは100年後もほそぼそと使われているんだろうなー、と予感させる言語であるようにも思います。

RacketのREPLをマシにする

racket

Racket のREPLは素の状態では履歴もemacs標準キーバインドも使えないため、使い勝手が非常に悪いです。

とりあえず XREPL(eXtended REPL) を設定しましょう。

  • 設定方法
$ echo "(require xrepl)" >> ~/.racketrc

POSIX互換なら

$ racket

でREPLが起動する際に、~/.racketcを読み込みに行くようです。 正確に知りたい場合、(find-system-path 'init-file)で参照パスが取得できます。

XREPLにより、基本的なEmacsキーバインド、コマンド履歴、メタREPLコマンドが使用できるようになります。 どのようなコマンドが使用できるかは、 ,helpで参照できます。

Racketの場合、DrRacketで結構色々できちゃいますが、ちょっとしたスクリプティングならターミナルからREPLを起動した方が早いと思いますし、XREPLの使い勝手はかなり良いのでオススメです。

minosound 1.1 をリリース

minosound 1.1 をリリースしました。

バックエンドの部分はClojureで開発していて結構出来ているのですが、 はもうちょっと作りこみたいなーと思ったので、 とりあえずクライアントの部分だけデザイン、UIを変更したり、 WebVIEWでの更新情報告知機能などを追加したのだけをアップデートしました。

minosoundは結構他のことに浮気しつつまったりと進めていて、 一応開発はそれなりに継続は出来ていますがやっぱりスピードがなかなか出ないので、 がっつり浮気せずにやるのも必要だなーと思いました。

minosound

minosound

  • 雄太 Mizushima
  • ゲーム
  • 無料