きゃべログ

プログラミングや電子工作などについての記事がほとんどです

机が狭いと思っていたときにモニターアームを買ったら最高だった話

この話は某ソフトウェアエンジニアが机の奥行きの狭さに嘆いていたところ、モニターアームを買ってみたら色々捗って仕方ないという物語である。

動機: 机の奥行きが足りないと思っていた

私は普段写真のような構成で作業していました。

  • デスク(奥行550mm, 幅1000mm)
  • ノートPC: macbook pro(early 2015)
  • ディスプレイ: acer P193W (19inch wide)
  • Amazonベーシックモニタースタンド

デスクが広く使えなくて、作業できないほど辛いというほどではないですが少し作業しづらいなという感覚でした。どのあたりが困っていたかというと、Macbook Proが机のかなり手前にあって、キーをタイプするとき、机の縁に手首の近くで支えないといけなくて不安定という点です。打ちにくいだけならまだしも、割と腕がつかれるんですね、これ。

そういうわけで、奥行きが700mmくらいあるデスクに買い替えたいなぁ、でもこの机去年買ったばかりだし、新しいの買おうとすると高いしなぁ、でもほしいなぁ、と葛藤する日々が続きました。

もともと私はラップトップのちょうど真上にディスプレイを配置したいという気持ちがあり、最初の写真のように、モニタースタンドを使ってディスプレイの高さを底上げしていました。これを使わなければ正直作業にならないので必要だったのです。仮にディスプレイを机に直に置いたところで、ディスプレイの足は安定性を確保するためにそれなりに大きい足があります。それほど机上のデッドスペースは減りません。この構成はそれなりに気に入っていたのですが、軽い不便さを感じてはいました。

Amazonベーシック 金属モニタースタンド - ブラック
AmazonBasics
売り上げランキング: 1,623

そこで一つのアイデアが浮かびました。
ひょっとしてモニタースタンドをモニターアームに置き換えればデスクのデッドスペースが減るのではないか。

モニターアーム初購入

思い立ったのは昨日の夜22時頃でした。思い立ってからはすぐ行動するのが私の信条なので、すぐさまモニターアームを選定し、Amazonでポチりました。そしたら今日のお昼には届きました。注文した品はこちらです。

レビューを見たところ34型ウルトラワイドディスプレイで使えるとのことだったので、私の19インチのディスプレイであれば余裕があると思い選定しました。あと一つ注意したいのはVESA規格75mm/100mmに準拠しているディスプレイであることです。

参考
VESA 標準について - ERGOTRON

簡単に言えばディスプレイを壁掛けしたり、モニターアームに設置するための穴がどうついているか、どれくらいの重さまで耐えられるかという規格です。

モニターアームの設置はクランプで挟み込む型なので、机の天板が挟める安定性を持っているかは確認したほうがいいかもしれません。

組み立て

組み立てはそこまで大変ではありません。やることは、ディスプレイ本体とアームをマウントする作業と、机にポールを設置する作業、ポールにアームを設置する作業だけです。15分くらいで設置が可能です。作業手順書にはいくつかプラスで組立作業が書いてありましたが、すでに組み上がっている工程もあったのでラッキーな気持ちになりました。

結果

こんな感じになりました。ディスプレイの足元のスペースが空いたことでMacbook Proを奥に置けるようになりました。さらに、期待していなかったのですが、ディスプレイの高さが自由に調節できるようになったこと ディスプレイのうつむき加減の調整の自由度があがったこと、が結構嬉しいです。普段椅子にがっつりもたれかかって作業するので、ディスプレイには結構下を向いておいてほしいのですが、これもいい感じになりました。

問題になっていた腕の置き場もしっかり確保できています。腕の細い部分だけで支えることなく、太めのところでしっかり支えられています。手首付近の動きに自由度が上がったのでタイピングのしやすさは格段に向上しました。

アームを手前に持ってきて角度をつけるとこんな感じになります。ちょっとドラマにでてくるハッカーっぽい気分とか、歯医者さんのモニターっぽい気分になれます。

ディスプレイの裏はこんな感じになっています。ポールの近くに左右に1軸、アームの真ん中で左右1軸、ディスプレイ付近で左右回転方向に1軸、上下方向に1軸の計4軸です。かなり自由度が高いです。

まとめ: まだモニターアームを使っていない人にはおすすめしたい。特にエンジニア。

机を広く取ることで、コーディング中にノートを開いて手書きのメモをしたり、単純に広々と使えたりすることで、ストレスフリーな開発環境が手に入ります。

ディスプレイ付属のディスプレイスタンドがいまいちだと感じている方、テーブルを広く使ってみたい方に是非モニターアームをおすすめしたいです。

今回買ったものは4000円程度で手に入りますので、まずは試してみてはいかがでしょうか。大型ディスプレイをお使いの方はご自身のディスプレイに合ったモニターアームを探してみてください。

Gitのカレントブランチのハッシュ値やブランチ名を取得する方法

Gitのコミットの前後のファイルをブランチ名.zipでまとめるという処理をシェルスクリプトで書きたいと思いました。そこでgitのカレントブランチの名前を取得したいなあを思って、方法を調査してみました。

  • gitのコミットハッシュ値を取得するコマンド
    • git rev-parse HEAD
  • gitのカレントブランチ名を取得するコマンド
    • git rev-parse --abbrev-ref HEAD

もろもろの自動化に使えそう。

Cabbageの2017年を振り返る

あけましておめでとうございます。
今年もよろしくお願いいたします。

時が経つのは早いもので、もう年が変わってしまいました。毎年思うわけですが、今年は特にそう思います。学生からサラリーマンと、ライフスタイルが大きく変わったことが要因だと思います。プライベートの時間が思ったより確保できないのが会社勤めの難しいところ。時間は自分で作らないといけません。あとはやることとやらないことの選別が重要だと痛感しています。2017年はあれよあれよと過ぎていき、やりたいと思っていたことの多くをやり残してしまいました。特に技術的アウトプットが少なかったのが心残り。とはいえ、初めから上手くいくとは考えていないので、2018年はいい方向に進むように、自分マネジメントをしていきたい。

2017年のアウトプット

あっという間に1年が過ぎてしまったので、自分がプライベートでどんなアウトプットを出したかを忘れてしまったので、まとめようと思います。だいぶ忘れたので漏れは何個かありそうです。

5月 [Python]ToAtm:Python用Twitterのアクセストークンマネージャ

cabbage63/toatm: Twitter OAuth Access Token Manager for Python

TwitterのAPIを使うためのアクセストークンを管理するツールです。環境変数に保存しようとか、データベースに保存しようとか、そういうのはプロトタイピングでは面倒なので作りました。アクセストークンをまとめたファイルを作成し、そのファイルをgitignoreすればGitHubにPushしてもいいですよっていうツールです。

学生時代研究で機械学習のためにPythonをこそこそ使っていたので、コーディングにはあんまり苦労しませんでした。ただどうもOAuthとかWebAPI周りが苦手だったのでいい勉強になったなあと思っています。

6月 [C言語]コマンドラインオセロ書いた

cabbage63/reversi: Reversi written in C language

2人対戦用のコマンドラインで動くオセロです。オセロって言ったら権利上ややこしいのでGitHub上ではリバーシと命名しました。

会社の研修でC言語をお勉強させていただいたので、習得に向けて自学自習を進めました。このプログラムではあまり高度な文法を扱っていないので、復習に役立ったかというと疑問があります。リファクタリングもあんまり出来ていないので残念なコードですが、書かないよりましなので良しとしましょう。

6月[Processing]動く!C言語プログラミングスタンプ

動く!C言語プログラミングスタンプ! - LINE スタンプ | LINE STORE

エディタでC言語をカタカタコーディングしてる風のLINEスタンプです。新規性は、それなりに使いやすい意味があるコードを考えたところと、スタンプが動くところです。ご査収ください。

コーディングをしているときにふと、「コードで挨拶出来るんじゃね」と思ったのがきっかけでした。どうせなら「シンタックスハイライトしたいんや」 とか「カタカタ入力してるように見せたいんや」と欲が出てきました。ドローツールでしこしこ作るのは無理だと思ったので、Processingで連番画像生成用のプログラムを書き、apngasmでアニメーションPNGとして結合することにしました。生成は簡単になりましたが、コードのネタを考えるのが超大変でした。

あと、この場をお借りして謝罪したいのですが、実はこのスタンプ

バグがあります

バグといってもLINEがバグるとかではなく、「仮にスタンプに書いてあるコードの内容をコンパイルして実行すると思った挙動をしてしまう」という意味ですのでご安心を。よかったら探してみてください。

9月[Processing]動く!Pythonプログラミングスタンプ

動く!Pythonプログラミングスタンプ - LINE スタンプ | LINE STORE

機械学習とか、入門にいいとかでPythonを使う人が増えてきているみたいなので、「乗るしかない、このビッグウェーブに」と思い作りました。Processingのソースコードはほぼ流用ですが、Python用に新しく挨拶に使えるコードを考えるのが大変でした。C言語が16個入りなのに対してPythonは24個入りです。また、Python版では今のところ大きなバグ報告はいただいておりません。念入りに確認しておいてよかった。お値段は据え置き、動くスタンプの最低価格の240円です。使ったってください。

C言語とPythonを合わせるとおよそ800件近く購入していただいています。毎日世界のどこかで自分が作ったスタンプが使われていると思うと本当に嬉しいです。

LINE Creators Marketでは自分の作ったLINEスタンプの利用統計が見れたりするんですが、日本、インドネシア、韓国、台湾の方に多くお使いいただいているようです。LINEが普及しているのはアジアが中心ということが数字で読み取れますね。

書いたブログの記事

7件でした。2014年は7件、2015年は23件、2016年は15件書いていた事を思うと結構減ってしまっているなあと思います。月に1回も書いていない計算になりますね。特に技術系の話題を扱うことが減ってしまっているので、インプットとアウトプットが足りていない感があります。2018年は技術力を高めていきたい。

2017年の記事リスト

ToAtm:Python用Twitterのアクセストークンマネージャを作りました
Amazon Kindleストアで一部の技術書が50%オフ中「夏のプログラミング特集」
libpython2.7.so.1.0: cannot open shared object file
レバテックキャリア様の「使い勝手のいいおすすめテキストエディタまとめ」に記事を紹介していただきました
Apple公式ドキュメントの「AR Human Interface Guidlines」を日本語化した
人気npmパッケージ25本をサクッと紹介する
Microsoft「ExcelにPythonを載せちゃおっかなー」の話について考えてみた

2018年に向けて

振り返ってみると、2017年もっとできたんじゃないかなって思わずにはいられません。Webでもネイティブでもいいので自分のアプリをリリースするのが2018年の目標です。面白い報告が出来るように頑張ります。

あとは一昨年立ち上げたAffinity DesignerとAffinity Photoの解説サイトAffinity Tipsの更新が滞ってるのでなんとかしたいと思っています。お問い合わせのメールを昨年だけでもかなりいただいたので、日本向けの解説サイトはそれなりに需要があると感じています。クリエイティブの加速に役立つWebサイト作りをやっていきたい。

そこでご相談ですが、誰かAffinity DesignerやAffinity Photoのユーザの方で寄稿してくださる方とかいらっしゃいませんか。もし興味のある方がいらっしゃればContactまでご連絡をお願いします。筆者欄を設けるなどのインセンティブを提供したいなと考えています。

まとめ

2017年は環境の変化が大きく、なかなか前に進めませんでしたが、2018年は慣れた分もっと進化していきたいなと思いますのでどうぞおつきあいください。

今年もよろしくお願いいたします!

Microsoft「ExcelにPythonを載せちゃおっかなー」の話について考えてみた

概要

こちらはpython Advent Calendar 2017 - Qiita21日目の記事です。

今回は技術ゴリゴリというよりはポエムに近い記事です。あんまりまとめることを意識せず、つらつらと書いているので変なところがあるかもしれません。賛同やご意見、議論のある方は是非コメント欄へ!

さてお決まりですが…

※この発言は個人の見解であり、所属する組織の公式見解ではありません

はじめに

ExcelのコミュニティサイトであるExcel’s Suggestion Boxに2015年11月5日にExcelのスクリプトとしてPythonを使いたいという旨のコメントが投稿されました。これはDanielさんという1ユーザの小さな一声。

そして2年後、記憶に新しい2017年12月15日にこのコメントにマイクロソフトのExcelチームから下記の正式なレスポンスが付きました。

Hi folks –

Thanks for the continued passion around this topic.

We’d like to gather more information to help us better understand the needs around Excel and Python integration.

To help us with this, can you please complete the survey below?

https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR7tUuWqOwSJFpBE5ZLhdkgtUMkhZWlkxRjhDRklXSjNTVkNSWkE2WlNQMS4u

Ashvini Sharma
Lead Program Manager
Microsoft Excel

要するに、Danielさんの投稿について熱い議論が長い間続いたので、ExcelにPythonが搭載されることのニーズを知るためにアンケートに協力してくれ、という内容。公式の開発チームがアンケートを取るところまで動き出し、ネット上では話題沸騰です。

PythonがExcelの公式スクリプトになった未来を考える

ここではもしPythonがExcelの公式スクリプトになったらどんな影響があるのかを考えてみましょう。

プログラマにExcelがもっと身近になる

1番最初に思いつくのはこの点でしょう。なぜ身近になるかというと、VBAに比べるとPythonの方がプログラマにとって学習コストが低く、親しみ易いからです。VBAっぽさを感じるDimとかSubといったキーワードは近年一般に使われているC言語、Java、Python、Ruby、JavaScriptでは見かけません。特殊さが他の言語間のそれとは比にならないような気がします。

プログラマにとっては学習することが簡単⇔難しいという単純な尺度だけでは単に学習コストは見積もれません。レガシー⇔モダンなど今後の応用性や発展性に関わる尺度と同時に見積もるべきです。そもそもVBAに対してPythonを習得するのが難しいかというと、簡単なことを実装するレベルであれば大差ないように思います。

情報源の幅が急激に広がる

Web上に情報源が多いのは圧倒的にPythonです。情報源の広がりは、Excelマクロのような軽量プログラム群にはかなりクリティカルに効いてくると思います。なぜならコピペで済むスクリプトが多く流通するから。業務効率の向上が見込まれます。

下記エビデンスから明らか。(結果はすべて2017/12/19時点のものです。)

Google検索結果

  • Python: 60M件
  • VBA: 21M件

PythonはVBAの約三倍です。より多く検索されているということは使っている人もそれだけ多いということが推測できます。

Googleトレンドの人気指数

  • Python: だいたい75
  • VBA: だいたい25

こちらもPythonはVBAの約3倍です。人気指数は検索ヒット数に起因している?

ちなみに地域別の関心度合いを見ると、PythonよりVBAの方が指数が高いのは数ある国の中でも日本(Python:VBA=2:3)とアルジェリア(Python:VBA=1未満:1未満)のみ。 なおアメリカは Python:VBA=4:1 という比率になっている。 普通に蛇の意味でのPythonが引っかかっているかもしれないので、コメントしないことにする。

GitHubのリポジトリ数

  • Python: 2M件
  • VB: 45K件

GitHubのPublicなリポジトリを対象に、様々な統計を出しているnamariというサービスから引用しました。Visual Basicなので厳密にはVBAじゃないのですが、VBAという項目がなかったので仕方なくこれで。

マクロスクリプトの性能が向上する

VBAに比べてPythonの方がプログラミング言語としては明らかに勢いがあることは先述のとおりです。それだけでなく、プログラミングに明るい人が話題に上げるのもやはりVBAよりもPythonです。処理のチューニングや最適化に関する情報はPythonの方が豊かであることは自明でしょう。

ライトなプログラマの人口が急増する

ここでのプログラマとは、「ソフトウェアを生業にして生きている人」ではなく、「コアコンピタンスとは別のスキルとしてプログラミングがこなせる人」のことを意味しています。

Excelでの業務プログラミングをきっかけに、更にディープな技術を学び始める人が増えるかもしれません。企画畑のアイデアマンがパワポを作るような感覚で自分でサービスのプロトタイプを作成し、会議で発表する、なんてことが普通になる未来が来るかもしれません。

マルウェアが増える?

VBAに比べるとPythonは豊富なライブラリが充実しており、複雑な機能も比較的簡単に実装出来ます。それを逆手に取れば、厄介な機能を持つ悪質なソフトウェアを作るのも容易であると言えます。VBA專門のマルウェア開発者だけでなく、他のマルウェア開発の片手間にExcelマクロマルウェアを開発するというシナリオは想像できなくはないでしょう。

VBA職人には生き辛い世界になる

これまでVBAによる業務効率化マクロを生活のあてにしていた人が苦しむことになるのではと考えています。Pythonは言語としての注目度が高く、情報系の学生はもちろんのこと、データ処理を必要とする理系学生の一部も普通に使います。また、ホビーとしてのプログラミングに使う言語としても人気の言語です。ライトなプログラマ層が増えることで、副業やアルバイトとしてのマクロコーダーが発生するのではと考えています。
PythonコーダーがExcelマクロに手を出す分にはそれほど苦労しないと思います。逆にVBAしか使えないひとは唯一に近いフィールドであるExcelマクロの領域を奪われてしまうことになる。VBAの言語としての応用性を考えると、他の領域に取り組もうとすると言語の再学習が必要になり、大変そうです。

蛇足: Excelを扱うPythonライブラリ

Excelが公式にPythonをサポートしていないからといって、マクロスクリプトとしてPythonが使えないわけではありません。現状、色々なライブラリがPythonからExcelを扱う障壁を下げてくれています。

まとめ

色々書きましたが、Excelユーザ、Pythonユーザにとっては今回のニュースは喜ばしいものだと思っています。Pythonユーザであり、業務でExcelを扱う私としては是非Excelの公式スクリプトとしてPythonを採用して欲しい限りです。あと、実現するならPythonをベースにした独自スクリプトとかはやめてほしい。

人気npmパッケージ25本をサクッと紹介する

こちらはNode.js Advent Calendar 2017 - Qiitaの20日目の記事です。

今回はnpm rankの2017/12/12のデータを元に、もっとも権威のある(検索でヒットしやすい)パッケージTOP25を超簡潔に紹介していきます。

node.jsには便利なパッケージがたくさんあり、ほとんどのことはパッケージで効率化できます。しかしパッケージを使うには、どういうパッケージがあるか知らなければサッと使うことができません。とはいえ1つずつググっていくと意外と多くの時間がかかってしまう。そのために頭のなかに索引をつくるような記事を書いてみようと思いました。苦労して調べるのは一人でいい!
私自身ほとんどパッケージを知らないので、サーベイの意味を込めて。

説明の誤りや改善点があればコメントください〜。

Node.js超入門
Node.js超入門
posted with amazlet at 17.12.21
掌田津耶乃
秀和システム
売り上げランキング: 17,840

1. lodash

JavaScriptでで関数型プログラミングをするのに使えるモダンユーティリティライブラリ。配列や数値、オブジェクト、文字列の扱いを簡単にする。関数型プログラミングでおなじみの合成関数も利用できます。あと速い。

参考

Lodash
JavaScriptで関数型プログラミングの入門

2. request

httpコールをシンプルに作成するためのライブラリ。とりえずWeb API叩いてみたいときはこれ使っとけばいい感じ。

参考

request - GitHub
Node.jsのrequestモジュールを使ってHTTPSでPOSTリクエストを行う - Qiita

3. chalk

ターミナルに表示する文字列のスタイルを指定するのを簡単にする。ログの出力を簡潔な表記で色付けしたりボールド体にできる。メソッドチェーンを使って1文でハイコンテキストなスタイリングが可能。

参考

chalk - GitHub

4. async

非同期処理をシンプルなAPIで記述できる。また並列処理と逐次処理を同じインターフェースで記述できる。

参考

async
Node.js asyncの有効な使い方 - エンジニアとして生きる

5. express

高速、オープン、軽量なNode.jsのためのWebフレームワーク。
JavaScriptでデファクトスタンダードのMVCフレームワークです。
REST APIの実装とかチャチャッとしたいとき便利。

参考

express

6. commander

CLIツールを作るためのフレームワーク。
簡単にバージョン指定できたり、オプションが指定できたり。

参考

commander - GitHub
NodeでCLIツール作成時にCommander.jsを使うと便利だった話 - Qiita

7. bluebird

Promiseを実現するためのモジュール。
ちなみにPromiseは非同期処理をベースにした並列処理の実装です。コールバック地獄からの解放。

参考

bluebird
今更だけどPromise入門 - Qiita
PromiseとQとBluebird - Qiita

8. debug

Node.jsとWebブラウザで動作する軽量デバッグユーティリティ。デバッグのときのみログ出力したいときに有効。デバッグログ用にconsole.log()を使ってしまうと、実働コードでコメントアウトor削除する手間が生じる。debugモジュールを使えばDEBUG環境変数をいじるだけでログのON/OFFが可能。

参考

debug - GitHub
Express のデバッグ
debug パッケージの使い方 - Qiita

9. fs-extra

Node.jsにデフォルトで存在するfsモジュールには含まれないファイルシステム関連メソッドを追加するモジュール。fsモジュールにない、mkdirp,rimraf,ncpなどを個別にインポートする手間が省ける。promiseに対応させることも可能 。fsモジュールをインポートする代わりにfs-extraモジュールをインポートすればfsの機能も使えるのが大変使い勝手が良い。

参考

jprichardson/node-fs-extra: Node.js: extra methods for the fs object like copy(), remove(), mkdirs()
node.jsで階層ディレクトリ作成やコピーをしたいときは? - Qiita

10. moment

時間のデータを扱うための軽量ライブラリ。パースしたり検証したり操作したりフォーマットを整えたりできる。

参考

Moment.js
Moment.jsを使う - Qiita

11. mkdirp

シェルのコマンドmkdir -p 相当のことが出来る関数を使えるようになる。デフォルトのモジュールではできないところを解決するシンプルなモジュール。

参考

mkdirp - GitHub

12. body-parser

httpリクエストのbodyをパースするためのミドルウェアという位置づけのモジュール。マルチBodyな構造には対応していない。

参考

body-parser - GitHub

13. react

FacebookのUIライブラリであるReactをサクッと使うためのモジュール。Reactを使用したモジュールをbrowserify(モジュールの依存関係を解決し、1つのjsファイルに)するときに特に有用。

参考

React - A JavaScript library for building user interfaces
react - npm

14. glob

ワイルドカードを使ってファイル名を特定するモジュール。パターンに合うファイルを探すときに使う。拡張子がjsのファイル名が知りたい時とか。

参考

glob - GitHub
【npm】 globとはなんなのか - コンパイラかく語りき

15. underscore

配列やオブジェクトの操作をシンプルに書くための関数などの便利関数がパッケージ化されているモジュール。map, reduceなどの関数型プログラミングもサポートしている。

参考

Underscore.js
第1回 Underscore.jsとは:Underscore.jsの入り口|gihyo.jp … 技術評論社
Underscore.jsの全メソッドを表にまとめてみた - あと味

16. babel-core

ES2015やJSXなどのモダンなJS仕様でコーディングされたものをブラウザでも動作するように生のJSに変換するトランスパイラ(コンパイラ)。

参考

Babel
Babelを使おう - Qiita

17. colors

node.jsコンソールに表示する文字列のスタイルを指定するのを簡単にする。3番目に紹介したchalkと類似のモジュール。chalkと比較するとstringにメソッドを生やすなど影響範囲が大きいらしい。

参考

colors.js - GitHub
良く使うnpmパッケージの紹介 - Qiita

18. webpack

複数のモジュールを1つにまとめてファイルを出力するモジュールバンドラ。類似のモジュールにはBrowserifyがあるが、Webpackがユニークな点は、css、画像、Webフォントなどのアセットをモジュールとして扱って1つのバンドルにして出力する点。

参考

webpack
webpack - GitHub
webpack 入門 (v3系 対応) - Qiita
フロントエンドエンジニア必見!JavaScript開発現場で人気の「Webpack」とは?

19. react-dom

元々Reactで提供されていたDOMのルートノード作成機能を分離提供したもの。reactreact-domはReactを使うのに最低限必要。

参考

react-dom
React - A JavaScript library for building user interfaces

20. babel-loader

webpackのモジュールローダとしてbabelを使うために必要。簡単に言うとローダーは入力したファイルをバンドル(一個にまとめる)ときに生JSにコンパイルしてくれる。TypeScriptやES2015などのモダンJavaScriptだけでなくcssや画像のローダが存在する。

参考

babel/babel-loader - GitHub
モジュール管理、だけじゃない-Webpack入門 〜 JSおくのほそ道 #029 - Qiita

実践Node.js プログラミング (Programmer's SELECTION)
Mike Cantelon Marc Harter T.J. Holowaychuk Nathan Rajlich
翔泳社
売り上げランキング: 189,232

21. yargs

CLIツールを作成する際に引数のパースやユーザインターフェースの作成のための機能を提供するモジュール。6番目に紹介したcommanderに近い。

参考

yargs
yargsを使ってタスク自動化ツールのコマンドにオプションを指定する - dskd

22. babel-runtime

babel-polyfillを使うのに必要らしい。
あんまり深い情報を得られなかったので良い解説求む。

参考

babel/packages/babel-runtime - GitHub
babel-polyfillとbabel-runtimeの使い分けに迷ったので調べた - Qiita
フロントエンドでもES6構文使ってみる【webpack+babel-loader(旧6to5-loader)】 - yutaponのブログ

23. q

Promiseを扱うためのライブラリ。Promiseは関数の返却値と例外を定義するオブジェクト。7番目に紹介したbluebirdと類似。

参考

kriskowal/q - GitHub
PromiseとQとBluebird - Qiita

24. css-loader

webpackであらゆるファイルをJS一本化する際、CSSをJavaScriptに変換するのに必要なモジュール。これはsass やlessなどのメタCSS言語をコンパイルするのではなく、プレーンなCSSをJavaScriptで読み込めるようにする機能を持つ。

参考

webpack-contrib/css-loader - GitHub
なんとなくで理解しないWebpackのCSS周辺 - Qiita
webpackのcss-loaderでCSS Modulesをやる - Qiita

25. inquirer

その名の通り、コマンドライン上でユーザに問いかけるのに使うモジュール。
質問を投げかけたり、入力された内容をパースしたり、入力された内容を検証したり、階層構造を持つ質問を管理したり。

参考

SBoudrias/Inquirer.js - GitHub

あとがき

これ書いてて痛感したんですが、モジュールのREADMEに「Why ◯◯?」みたいにそのモジュールの価値を簡潔に書いてくれてるのはすごくありがたい。

最近よく使われている技術をさらっと俯瞰することは勉強になりますね。私はjQueryでなんでもやっちゃおうという世代なので、モダンJS特有知らない概念を吸収できた点が有益でした。これからモダンJS使えるようになりたい。

あと、人気モジュールを追うことで今のデファクトスタンダードが自ずと見えてくる。ライブラリ導入の判断材料として役立ちそう。

はじめてのNode.js -サーバーサイドJavaScriptでWebアプリを開発する-
松島 浩道
SBクリエイティブ
売り上げランキング: 256,064

Apple公式ドキュメントの「AR Human Interface Guidlines」を日本語化した

はじめに

こんにちは。cabbage(@cab_kyabe)です。 本記事はARKit Advent Calendar 2017 - Qiitaの13日目の記事です。 この内容に近い記事は元々公開していた時期があったのですが、完成度が低かったので、Advent Calendar用にリファインして再投稿しました。

Augmented Reality - Technologies - iOS Human Interface Guidelines
を一通り読み、日本語として要約しました。内容は厳密に1対1対応させていません。平易な表現で要点がわかりやすいように表現したつもりです。原文を読んで解釈が明らかにおかしいというのを見つけた方がいらっしゃればご指摘ください。異論は認めます。原文を読むのは結構骨が折れる作業だと私は感じたので、少しでも皆さんのお力になれれば幸いです。

概要

現実と仮想物体をシームレスに重ねて、没入感があり、魅力的な体験を実現するために、iOSアプリではAppleのARKitを使うことができる。
カメラはスクリーン上のビューに現実世界を表示するのに使用する。3次元の仮想物体はそのビューに重畳され、物体が本当に存在するように錯覚させる。もしその体験が正確であれば、ユーザはiOSデバイスの向きを変えて仮想物体を様々な角度から調べることや、ジェスチャや動きを使ったインタラクションが可能である。

魅力的な設計

人々を惹きつけるに画面全体を使うこと

現実世界を表示したり仮想物体を表示するために出来る限りスクリーンを大きく使うこと。また、没入体験を損なうのでスクリーン上をコントロールのパーツや情報で散らかさないこと。

物体を配置するときは説得力のある錯覚を生み出すようにすること

すべてのAR体験に現実に近い仮想物体が必要なわけではない。しかし配置される仮想物体はあたかも現実世界に存在するようにしなければならない。ベストプラクティスは本物そっくりのテクスチャが貼り付けられた詳細な3Dアセットを作成すること、またARKitが提供する現実世界の平面認識を使用して仮想物体の照明の当たり方に適用し、現実世界の画面に仮想物体の影をつけること、カメラの位置変化に仮想物体の位置を適応することである。

物理的な制約を考慮すること

ARがうまく動かない環境でも人々はアプリを使おうと試みることを心に留めておくこと。例えば、動き回ることが出来るほどのスペースがなかったり広い平らな部分がないような場所でも人々はアプリを開くかもしれない。難題を課せられるシナリオを想定して、明確に制約や例外を人々に率直に伝えるよう試みること。

ユーザが心地よくなるように心がけること

長期間に渡ってデバイスを特定の距離、あるいは角度に保つのは骨の折れる作業である。そのためユーザがアプリを使う際にどんなふうにデバイスを持つのかを考慮し、不快感を引き起こさない楽しい体験を目指すこと。例えば、仮想物体を近くに移動させてくる必要がないように、最初から仮想物体を配置することができる。

ユーザの動きを促進するなら、動きを徐々に紹介すること。

例えばゲームにおいてはARに入り込んですぐに仮想世界を見せないようにする。まずは体験に順応するための時間をユーザに与えること。そして、徐々に動きを促進していくこと。

ユーザの安全に配慮すること

近くに他の人や物体があったら、あちこち歩き回る行為は危険となり得る。アプリの操作が安全になるような方法をよく考えること。たとえば、ゲームにおいて大幅な動きや急な動きを避けるように仕向けることが挙げられる。

没入体験を促進するには聴覚と触覚フィードバックを使うこと

音声や衝突感は物理的表面や他の仮想物体に接触するようになったと確信を得るための重要な方法である。没入感のあるゲームでは、BGMはユーザが仮想世界に包み込まれるのを手助けする。

参考

可能な限りコンテキストヒントを提供すること

例えば、物体の3次元回転のインジゲータ(矢印など)を示すことはテキストベースの指示を配置するよりも更に直感的な方法である。しかし、ARKitが平面を検出する前やユーザがコンテキストヒントに反応していない場合はテキストヒントを表示する方が確実である。

説明テキストを表示しなければならない場合、親しみやすい専門用語を使うこと

ARは先進的な概念であるため、怖がる人がいるかもしれない。ARを親しみやすいものにするために、技術的な言葉やARKitWorld detection, trackingのような技術者向けの言葉を使用しないこと。代わりにほとんどの人たちが理解できる会話体の言葉を使うこと。

AR体験を不必要に妨げることを避けること

ユーザーがARを終了したり再開する度に、環境は解析されて平面が検出される。さらに端末とカメラの位置は変わるかもしれない。結果として、以前に配置された物体の配置場所が変わるおそれがある。物体はもはや実世界の平面上に配置されたままである保証もない。こういった体験の妨害を防ぐ方法の1つとして、ユーザに物体の位置や設定をAR体験を抜けずに変更出来るようにさせることが挙げられる。例えば、ユーザがリビングに置くための椅子の購入を検討しているとする。AR上で椅子を配置したとして、ユーザは他の生地の椅子を色々試すような機能が欲しいと思うかもしれない。

ARの世界に入りこむ

初期化が実行されていることを示し、ユーザを巻き込むこと

周囲の環境を評価する初期化処理はアプリがAR機能を開始するとき毎回実行される。この処理には数秒かかる。ユーザの混乱を減らして処理を早くするために、初期化の際にする行動を示すこと。例えば表面を見つけられるように周囲をあちこち映すように勧める。

仮想物体を配置する

(例)平面検出のインジゲータ
(例)仮想物体配置のインジゲータ
(例)アプリのデザインに合わせたインジゲータ

ARKitが平面を見つけたタイミングや物体を置くタイミングをユーザがわかるように助けること

視覚的なインジゲータは平面検出がアクティブになっていることを伝えるのにとても有効な手段である。例えば、画面中央に台形と十字線を置くことで、ARKitが平面を探しているだろうということをユーザは推測できるだろう。ひと度平面が見つかれば、現在物体を置くことができるこを示すために見た目を変えるべきである。あなたが作るアプリに馴染むような視覚的なインジゲータをデザインすること。

ユーザが物体を配置したときには適切に反応すること

平面検出の精度は、かなり短い時間でしだいに良くなっていく。ユーザが物体を配置するために画面をタップすると、現在使える平面情報を用いて物体を即座に配置する。そして平面検出が完了すると、微妙に物体の位置を調整する。もし物体が検出された平面領域からはみ出て配置されていたら、ARKitは物体を平面上にそっと動かす。

検出された平面の端に整然と物体を並べようとしないこと

ARでは平面の境界線は近似的なもので、周囲環境の解析が更に進むと変わるかもしれないためである。

仮想物体に対するユーザインタラクション

スクリーン上に別のUIを設けるよりは直接操作することが好ましい

物体に働きかける際、画面上に別にボタンなどのコントローラを設けるよりは、ユーザがスクリーン上の物体にタッチして働きかけることができる方がより没入感があり、直観的である。

標準的で親しみやすいジェスチャーを使って物体に働きかけられるようにすること

例えば物体を動かす際に1本指のドラッグをサポートしたり、2本指の回転ジェスチャで物体を回転させるようにするなどが挙げられる。関連情報はジェスチャーの項目を参照。

一般に物体への作用はシンプルであること

(例)物体の移動を2次元平面に制限する
(例)物体の回転を一軸に制限する

AR体験は現実世界の3次元に関わっているが、タッチジェスチャはそもそも2次元である。
仮想物体に対するユーザの作用を簡易化するために次のようなアプローチを検討すること。

  • 移動する方向を物体が置かれている2次元平面上に制限する
  • 回転方向を一軸に制限する

物体近くへ作用する妥当なジェスチャにも反応すること

小さかったり、薄かったり、遠くにある物体上のある1点を正確にタッチするのは難しいかもしれない。あなたのアプリが作用できる物体に近い位置のジェスチャを検知したら、ユーザはその物体に働きかけたいのだと推定するのがふつうは最善である。

ユーザが配置したオブジェクトのスケーリング機能が必要かどうかよく考えること

おもちゃやゲームキャラクターのように物体が固有のサイズがなく、ユーザがそれを大きくしたり小さくしたりしたいと思う場合サイズのスケーリングは一般に適切である。しかし現実世界において固有のサイズを持つ家具のような物体を正確なサイズで配置しようとする場合には不適切である。スケーリングは物体の距離を調整する方法としては使えない。例えば物体が近くに見えるように物体を大きくしても、単に遠くにより大きい物体あるように見えるだけである。

ジェスチャの衝突には気をつけること

例えば2本指のピンチジェスチャは2本指の回転ジェスチャととても似ている。もしこのような2つのジェスチャを実装するならば、アプリはそれらを正確に解釈できるのかをテストして確かめること。

仮想物体の移動は滑らかであるか確認すること

ユーザが物体をリサイズしたり回転させたり新しい位置へ移動するとき、物体がジャンプしているように見えてはいけない。

より魅力的な物体への作用方法を探求すること

ジェスチャだけがARにおいて仮想物体に働きかける唯一の方法ではない。アプリでは端末の動きや物体への接近などの他の要素を使うことができる。例えばゲームキャラクタにユーザが近づくと、ゲームキャラクタがユーザの方向を向くようにするなどである。

問題を解決する

AR体験がユーザの期待に沿っていない場合、ユーザ自身でリセットできるようにすること。

状態が改善するまで待たせたり、物体の配置に苦労させてはいけない。ユーザにもう一度やり直してより良い結果が得られるか確認できる方法を提供すること。

問題が起こったら改善方法を提示すること

暗かったり、平面が光を反射しなかったり、平面のディテールが十分でなかったり、カメラの動きが過剰すぎるなど様々な理由によってユーザの環境分析や平面検出は失敗することがある。アプリが平面のディテールが不十分だったりカメラの動きが過剰であると知っていたら、あるいは平面検出に時間がかかりすぎていれば、問題解決の方法を提案すること。

問題と改善案の例

  • 検出されるディテールが不十分→光をもっと照らし、端末を動かして周囲を映してください
  • 過剰な動きを検出→端末をもっとゆっくり動かしてください
  • 平面検出に時間がかかりすぎている→端末を動かして周囲を映してください。また、端末が十分ざらざらした平面を映しているかを確認してください。

ARの機能は使える端末だけに提供すること

もしあなたのアプリの主な目的がARであれば、ARKitをサポートしているデバイスのみでしかアプリを利用できないようにすること。また、もしあなたのアプリが製品の写真を含む家具のカタログのようなARを二次的な機能として使用し、いくつかの製品をARで見られるようにしている場合、ARをサポートしていないデバイスでその機能を使用しようと試みたときにエラーを表示しないようにすること。もしデバイスがARKitをサポートしていない場合、最初からオプションのAR機能を提示しないこと。開発者の手引として、ARKitキーについてはInformation Property List KeyUIRequiredDeviceCapabilitiesを参照のこと。また、ARConfigurationisSupported - ARConfiguration | Apple Developer Documentationも参照のこと。

ARのピクトグラム

アプリはAR体験を開始するボタンなどのコントロールにARピクトグラムを表示することができる。ARピクトグラムは
Resourceからダウンロードできる。

ARピクトグラムは本来意図されたとおりに使うこと

ARピクトグラムはARKitを用いたAR体験を開始する場合のみに限って使われるべきである。サイズや色を変更するなど以外の変更をピクトグラムを適用したり、他の用途に使用したり、ARKitで作られていないAR体験の開始に使用してはならない。

最小限の余白を保つこと

ピクトグラムの周りに最小限の余白として、ピクトグラムの高さの10%を確保しなければならない。他の要素でそのスペースを侵害したり、ピクトグラムを隠してはならない。

ARバッジ

製品やその他のアイテムのコレクションを含むアプリにおいて、ARKitを使ったARで見ることができる特定のアイテムを識別するために、ARバッジを使うことができる。例えば、デパートのアプリでは家具を購入前に自分の家でその見た目をプレビューできるようになるかもしれない。

ARバッジは本来意図された通りに使うこと

ARバッジ
ピクトグラムのみのARバッジ

ARバッジはResourceからダウンロードできる。これらの画像はARKitを使ってARで製品やその他の物を見ることができることを識別するためにのみ使われるべきである。バッジを変更したり、色を変えたり、他の用途で使用したり、ARKitを使っていないAR体験と関連づけて使用したりしてはならない。
ARピクトグラムよりARバッジを使用することが望ましい。一般的に、ピクトグラムだけのバッジは画面のスペースが限られているときや、ARバッジを配置しきれない場合に使われるべきである。いずれのバッジもデフォルトサイズでうまく動作する。

ARバッジはARで見ることができるものとそうでないものが混ざっている場合にのみ使うこと

もしアプリの中のオブジェクトすべてがARで閲覧できるとすれば、そのときバッジは冗長で不要なものである。

バッジの位置は不変で明確に保つこと

バッジは物体の写真のある隅に表示されるのが最も良い。常に同じ角に配置し、バッジがはっきりみえるのに十分大きいことを確認すること。ただし大きすぎて大事な写真の詳細を覆ってしまうようではいけない。

最小限の余白を保つこと

ピクトグラムの周りに最小限の余白として、ピクトグラムの高さの10%を確保しなければならない。他の要素でそのスペースを侵害したり、ピクトグラムを隠してはならない。

まとめ

さて、日本語でもかなり読むのに苦労する記事だったと思いますがいかがでしょうか。 ユーザにやさしいAR体験にはとても大事な項目が多いです。 初めて使うユーザがストレスフリーにアプリを利用できるよう、ポイントを押さえて置きたいところです。

レバテックキャリア様の「使い勝手のいいおすすめテキストエディタまとめ」に記事を紹介していただきました

丁度3年ほど前に執筆した弊ブログの下記記事を、 レバテックキャリア様のスキルアップ記事「使い勝手のいいおすすめテキストエディタまとめ」 に取り上げて頂きました。主要なエディタについて、色々なブログから情報を引用されています。テキストエディタをお探しの方はぜひご覧ください。

掲載記事
高機能テキストエディタSublime Text3を使ってみた

libpython2.7.so.1.0: cannot open shared object file

最近SonyからNeural Network LibrariesというDeep Learningのライブラリが公開されたので試してみようと環境構築していました。

環境構築当時Python2.7にしか対応していなかったのでpyenvで環境構築しました。
Installation on Linux — Neural Network Libraries 0.9.4 documentation

ぐぐってみたら、どうもシンボリックリンクを貼れば解決するようだ。
Python エラー対処:error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory - 長生村本郷Engineers'Blog

そもそもはいってないからリンクはれない、きれそう

[vagrant@localhost nnabla]$ ldd /home/vagrant/.pyenv/versions/2.7/bin/python
linux-vdso.so.1 => (0x00007ffdbe3a5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f22cb0c2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f22caebe000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f22cacba000)
libm.so.6 => /lib64/libm.so.6 (0x00007f22caa36000)
libc.so.6 => /lib64/libc.so.6 (0x00007f22ca6a2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f22cb2e7000)</module></module></string>

問題発生

pyenvでpython2.7系でnnablaをインストールしたときに、libpython2.7.so.1.0: cannot open shared object fileとなる問題が発生しました。

[vagrant@localhost nnabla]$ python -c "import nnabla"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/vagrant/.pyenv/versions/2.7/lib/python2.7/site-packages/nnabla/__init__.py", line 16, in <module>
import _init # Must be imported first
ImportError: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

解決方法

$ CONFIGURE_OPTS="--enable-shared" pyenv install 2.7.6

インストール時にオプションを設定する必要があるらしい。下記がソース

え?君せっかく Python のバージョン管理に pyenv 使ってるのに Vim の補完はシステムライブラリ参照してるの? - Λlisue's blog

まとめ

ひょっとしたらライブラリ側で解決されているかもしれませんが、同様の問題の解決の一助になれば幸いです。

Amazon Kindleストアで一部の技術書が50%オフ中「夏のプログラミング特集」

久しぶりの投稿になりますが、どうしてもシェアしたいセールがあります。 その名もAmazon Kindleストア、夏のプログラミング特集。 2017年8月31日までなので買い忘れにご注意を。

Amazon.co.jp: 【50%OFF以上】夏のプログラミング特集 (8/31まで): Kindleストア

iOS開発入門書でSwift2時代の少し古い書籍があったりするので、 買うものは選ばないといけないですが、中にもベストセラー級の書籍があるので興奮しています。 いい本は高価なものが多いので今回のセールはかなりうれしいです。

このエントリではせっかくなので私が注目する書籍をピックアップしたいと思います。

Pythonの入門書です。機械学習やRaspberry Piのプロトタイピングなど最近活用の幅が広い言語なので、プログラミング初心者の方にはおすすめしたい1冊です。 ただし他の言語を習得済の方は公式チュートリアルを読んだほうが有意義かと思います。

ゲームアプリの数学 Unityで学ぶ基礎からシェーダーまで
SBクリエイティブ (2015-09-24)
売り上げランキング: 1,930

Unityについての本というよりは、しっかり数学の知識が書かれている印章です。 ぱらぱらめくって見ましたがUnity初学者には向かない本です。 さらに一歩すすんだスキルを身に着けたい方には良い本だと思いました。

実装の容易さからプログラミングはどんどん容易になってきているので、 こういったコンテンツのクオリティを高める書籍は是非今のうちに読んでおきたいと考えています。

これが今回1番の目玉商品ではないでしょうか。 Webアプリのセキュリティ本ではまずこれが出てくるという書籍です。 言語はPHPですが取り上げるセキュリティの問題は他の言語を使う人も知っておきたい内容じゃないかと思います。

以上4冊が今回のセール品全63冊からのピックアップ本です。 ひょっとしたらもっと良い本があるかもしれません。 もしイチオシの本があったら是非教えてください。 今年の夏はあんまりお金を使わないつもりだったけど、一気にお金が飛んでいきそうだ…。

ToAtm:Python用Twitterのアクセストークンマネージャを作りました


credit: Pete Simon

アクセストークンの管理が面倒くさい

今更ながらPythonからTwitter APIを使ってみようと試みました。
複数のアカウントからAPIを叩こうとすると、どのアカウントがどのアクセストークンに対応づくかという管理が面倒でした。そこで今回はアクセストークンを管理するコードを書いてみました。

最初のうちはコンシューマーキーをコード内に直打ちして認証!みたいな力技をやってしまいがちなのですが、それはちょっとリスキーですね。GitHubなんかでソースを公開する場合であったり、あとはセキュリティの観点から1番理想的なのはデータベースに保存して管理することでしょう。

データベースがポピュラーな方法だと思いますが、今回は飽くまでプロトタイプレベルで簡単にコーディングするためにセットアップ不要の外部ファイルによる永続化という方法を取ってみました。本番環境に使えるかはあまり自信がないのでサポートツールだと思ってもらえれば幸いです。

まずいところがあるなーと思った方がいらっしゃればコメントお願いします!

機能

  • 複数アカウントのアクセストークンが簡単に管理できます。
  • アプリのAPIキーも同時に管理でき、簡単に呼び出せます。

注意点

出力されたデータベースファイル(keys.shelve)は外部に漏れないように取り扱ってください。セキュリティの観点からGitHubにPushするときにはkeys.shelveを.gitignoreに指定するなど対処が必要です。

入手

GitHubからクローンした上でご利用頂けます!
toatm.pyを開発したいpythonコードと同じところに入れましょう。そのディレクトリにアクセストークンが格納されるデータベースファイルが生成されます。
cabbage63/toatm: Twitter OAuth Access Token Manager for Python

使い方

Tweepyのインストール

このツールではその後にTweepyを使うことも想定してPythonのTwitter APIにアクセスするためのライブラリであるTweepyを使用しています。まずはTweepyを導入しましょう。

pip install tweepy

Gitからインストールしたい場合はこのような形でマニュアルインストールします。

git clone https://github.com/tweepy/tweepy.git
cd tweepy
python setup.py install

ToAtmを実行

本アプリ、ToAtmを実行します。

$ python toatm.py

使用するアプリのAPIキーを登録します

プロンプトが出るので指示に従って入力していってください。
これでアプリのAPIキーは登録完了です。

Please select mode.
        1 Update API keys
        2 Update Access tokens
        3 Show access tokens
        q Exit
>> 1
CONSUMER KEY: ************
CONSUMER SECRET: *************

アクセストークンを登録する

指示にしたがってブラウザから指定されたURLにアクセスし、そこで得られたVerifierをアプリで入力することでアクセストークンが登録されます。

Please select mode.
        1 Update API keys
        2 Update Access tokens
        3 Show access tokens
        q Exit

>> 2
Access: https://api.twitter.com/oauth/authorize?oauth_token=***************
Verifier: *******
Updated access token for @****** successfully.

Pythonアプリからアクセストークンを呼び出す

@hogeというユーザアカウントを想定して使用例を掲載します。

import shelve
# Open database file
d = shelve.open('keys.shelve')
print d["hoge"]

こちらのコードを実行するとd["hoge"]の内容として次のものが表示されます。

{'access_token': u'****', 'access_token_secret': u'****'}

アプリのコンシューマーキーも呼び出せます。

print d["consumer_key"]
print d["consumer_secret"]

str型で呼び出したい場合は次のように変換しましょう。

str(d["hoge"])

使用例: タイムラインの読み出し

あらかじめ@hogeというユーザのアクセストークンを登録していると想定します。

# -*- coding: utf-8 -*-

import shelve
import tweepy

# アクセストークンを登録したTwitter IDを入力(@hoge)
SCREEN_NAME = "hoge"

# データベースファイルを読み込み
d = shelve.open('keys.shelve')
consumer_key = d['consumer_key']
consumer_secret = d['consumer_secret']
access_token = d[SCREEN_NAME]['access_token']
access_token_secret = d[SCREEN_NAME]['access_token_secret']

# Tweepyをセットアップ
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
auth.set_access_token(access_token, access_token_secret)
api = tweepy.API(auth)

# メイン処理:タイムラインの読み出し
public_tweets = api.home_timeline()
for tweet in public_tweets:
    print tweet.text

まとめ

Python用のTwitter APIを利用した開発者向けのアクセストークンマネージャを作成・公開しました。
普段アクセストークンの管理に悩んでいる方はお試しください。

賛否両論のスーパーマリオランは本当にクソゲーなのか?

ついに発表、しかし賛否両論……

2016年12月15日にNintendoより片手で遊ぶマリオ「スーパーマリオラン」が発表されました。記事を書いていている時点ではレーティングは平均3程度。どでかく広告が打たれていたことが期待を大きくさせ、思ったよりも面白くなかったという反応が多いようですね。それだけでなくゲームの課金システムに一般の方には受け入れがたいところがあるようです。

こちらは2016年12月15日までの1週間の任天堂の株価を示しています。(Yahooファイナンスより引用) 見事にアプリのリリースタイミングに売りが発生していることがわかります。 「スーパーマリオラン」の公開が発表され、任天堂の株価が上昇していたことを考えると、投資家にとっては期待を下回ったものだったのかもしれません。

関連ニュース
任天堂が続急伸、「スーパーマリオラン」12月15日配信開始で再び走る | 個別株 - 株探ニュース
任天堂:スマホ向けマリオ配信、株価は1カ月ぶり日中下落率 - Bloomberg

プレイしてみた

取り敢えずインストールして、一通り遊んでみました。私としてはこのゲームの命運は今後の方針次第かなと思っていて現状はなんとも言えないです。というふうに感じている理由をつらつらとかいてみます。

ゲーム概要

大きくわけて2つのプレイモードがあります。

1つ目がワールドツアーというモードです。これは従来のマリオ動揺、ステージをクリアして楽しむというもの。ゴールに到達すればクリアというシンプルなゲームです。

2つ目がキノピオラリーというゲームで、オンライン上の他のプレイヤーのゴーストとポイントを競って遊ぶというモードです。先にゴールしたほうが勝ちというのではなく、コインの枚数や決めたトリックの回数などから総合的に評価されるスコアに基づいて勝利判定がなされます。

その他にはソシャゲに見られるまちづくりのような「王国づくり」というモードもあります。進度に応じて解禁されるショップアイテムを王国に配置していくというもの。

以降詳細について説明していきます。

ゲーム起動画面

こんなかんじ。
スマホにはとても鮮やかに映る。

メニュー画面

こちらはメニュー兼王国のプレビュー画面です。
マリオ独特の世界観が広がっています。

ワールドツアー

画面をタップするとマリオがジャンプするという実にシンプルな仕様なのですが、タップする長さによって飛ぶ高さが変わったり、2回タップすると滞空時間が長くなったりとシンプルさの中に奥深さがあるデザインになっています。また、小さな敵は自動的に飛び越えるようになっており、初心者の人にもとっつきやすい仕様と言えます。上の図は自動的にクリボーを避ける様子です。

通常のマリオ通りゴールすることが目的ですが、色がついた「カラーコイン」を5枚集めるという遊び方もあります。ある色のカラーコインを集めると別の色が異なる配置で配置されるようになっていて、ピンク→青→緑と順に解禁されていき3度楽しめるようになっています。

さて、Twitterなど世間的に議論を呼んでいるのがこのワールドツアーモードです。その理由は初期で用意されている1-1 ~ 6-4のステージのうち、1-1,1-2,1-3の3ステージしか無料で遊べないという点にあります。それ以外の21ステージを遊ぼうとすると1200円の課金が必要になっています。スマホゲームは無料で遊べるというのが一般的な感覚になっているためか、この点が議論になっているようですね。

キノピオラリー

こちらのモードでは世界中のライバルとランを競うことができます。いかにかっこよくランできるかを競うというのがこのモードのコンセプトですが、詳細には得たコインの数と決めたアクロバットの数でスコアリングされます。タップするタイミングによりアクロバットが発生し、スコアが発生します。

最終的に勝者の王国にキノピオがやってきて、そのキノピオの数によって王国が成長していくというシステムになっています。

なおこのモードをプレイするにはチケットが必要です。これを入手する方法はいくつかあります。

  • ワールドツアーにてカラーコインを5枚集める
  • はてなボックスからたまに出て来る
  • ボーナスゲームの館のゴールで一定確率で入手

これらの条件を満たすことでキノピオラリーに参加するチケットを得られます。

王国づくり

先述の2つのランゲームによって得たコインを使って建築物を購入し、配置するというモードです。キノピオラリーにより王国のレベルがアップしますが、それに伴って新たな建築物が解禁されたりします。

ボーナスゲームの館

通常ステージに比べてたくさんコインが出て来るボーナスゲームをプレイすることができます。8時間に1回プレイできるという仕様です。キノピオラリーのプレイに必要なチケットが一定確率でゴールにて入手できるようになっています。

考察

さて、以上をふまえてスーパーマリオランが良ゲーかはたまたクソゲーか、というところを考えたいと思いますが現状ではどちらとも言えないのではないかと思います。

ワールドツアーモードは課金しなければ3ステージしか遊べないという強い制限があります。いわゆるスマホのゲームは通常プレイは無料というものが普通になっている現状としては少しギャップがあるかもしれません。

ですがキノピオラリーというモードがある点でこの問題は埋め合わせ出来ているのではないかと思います。こちらはプレイできる回数に制限はあるものの、その点ではスタミナというシステムを導入している通常のソシャゲと大差ありません。またこのモードはプレイできる内容について課金如何によって大きな差は生じないので、この点でもソシャゲとしては良心的な部類だと思われます。

通常家庭用ゲームは購入して遊ぶものということを考えるとワールドツアーモードのステージ解禁に1200円かかるというのはそれほど不自然ではないでしょう。Nintendoとしてもワールドツアーモードは従来の据え置き型ゲームのソフトと同じような立ち位置で買い切りのゲームとして制作しているのではないかと思います。対してキノピオラリーというモードは完全に無料で遊べるものとして切り分けているのではないでしょうか。

私個人としては課金システムについては有料・無料のゲームがパッケージングされていると考えれば特に不満を抱いてはいません。ただし1点問題だと感じているのが、キノピオラリー参加に必要なチケットの入手が困難なことです。先程これを入手する3つの方法を挙げました。(ほかにもあるかもしれません。)

  • ワールドツアーにてカラーコインを5枚集める
  • はてなボックスからたまに出て来る
  • ボーナスゲームの館のゴールで一定確率で入手

1つ目の入手法は各ステージ、カラーコインの種類の数と同じ3回×2枚しかチケットを手に入れることができません。つまり1200円の課金をしていない場合は「2枚 × 3種類 * 3ステージ = 18枚」に限られます。

また2つ目については出現する確率が高くないため、手に入れようと思ってすぐに手に入れることができません。筆者は20回ほどゲームをしましたがまだ一度も出てきていません……。

3つめについてはボーナスゲームは8時間に1回しかプレイできない上、最終的に2分の1の確率でしか手に入れることがかなわないのでこちらも確実とは言えません。

上記のようにチケットの入手条件が厳しすぎるような気がします。すなわちチケットが手に入るまでは3ステージしかない体験版のような状態がある程度続いてしまうことになるのです。これが改善されればユーザの満足度が向上するのかなと思っています。

ゲーム自体はNintendoらしいシンプルな面白さがあります。したがって無課金ユーザの権利バランス調整次第でスーパーマリオランは良ゲー、クソゲーいずれにも転ぶかなと感じています。