2015年10月11日

Awesome WM 試用中

自宅PCにはOS(ディストリビューション)としてLinux (Fedora 22) を入れている。Linuxはそれを構成する各種ソフトウェアの独立性が高く、WM――ウィンドウマネージャ。GUI環境下で表示しているウィンドウの管理を行う――も入れ替えることが出来る。

今回、Awesomeというタイル型WMを導入してみた。「タイル型WM」とは、各ウィンドウを画面上にタイル状に敷き詰めて表示するタイプのWMだ。 Windows 8 (或いは Windows 10 のタブレットモード)で画面上に複数のモダンアプリを表示した時のような表示方法で、原則、ウィンドウ同士が重なる事がない。なお、 Windows 10 や、それ以前のデスクトップアプリでのウィンドウ表示の方式は「スタック型WM」とか「コンポジット型WM」という

タイル型WMの良い所は、まさに「ウィンドウ同士が重なる事がない」という点に尽きる。考えてみれば、同時に使いたいソフトだから同時に起動している訳で、それぞれのウィンドウを並べるのは道理であるように思える。メーラーのような例外は、別の仮想デスクトップに配置しておけば問題ない。むしろ、自然と役割毎に仮想デスクトップを使い分ける癖がついて好都合とも言える。大体のタイル型WMはキーボードショートカットが充実しているのも、実に素晴らしい。

AwesomeはLuaというプログラミング言語で設定をカスタマイズ出来る。設定ファイルを0から作る事も出来るが、/etc/xdg/awesome/rc.luaに在るサンプルに手を加える事にした。というか、Luaを勉強した事がないので、サンプルが無いと何も出来ない。今の所の私の設定ファイルはこれ。サンプルはデフォルトの挙動を再現するコードで構成されているようなので、それらを削ればもっと短くなるだろう。

参考にしたページは以下の通り。

現状、かなり満足している。不満点は、キーボード操作のウェイトが増した結果ファイラであるnautilusの使い勝手が悪くなった事、GnomeのActivityのようなGUIソフトを選んで実行する仕組みが無い事ぐらいか。前者は代替品を探すとして、後者はどうしたものかなぁ。

しかし、もうちょっと名前は何とかならなかったものか。検索しにくいぞ。

「スタック型WM」とか「コンポジット型WM」という
厳密には両者の定義は異なるようだが、あまり気にしなくて良さそうだ。
GUIソフトを選んで実行する仕組み
実は、サンプル設定ファイルにはその仕組みが用意されており、Mod4 (Superkey、所謂「Windowsキー」) + p で画面上部に選択用UIが表示される。しかし、ぶっちゃけ使いづらい。
posted by 天井冴太 at 20:23 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2015年09月23日

Node.jsのasync.waterfallの上手い使い方が分からない

最近、お仕事でNode.jsを使っている。Node.jsは、いろいろな処理が非同期処理を前提とした作りとなっており、「ある処理を行った後にする処理」を、「ある処理」を行う関数のコールバック関数として書く必要がある。例えば、ファイルに何か書く場合は、こう。

require('fs');  // ファイルのIOを行うfsモジュール読み込み。

fs.readFile('foo.txt', 'utf8', function(error, data) {
	// エラーの場合は、コールバックの第1引数にエラーを表すオブジェクトが入る
	if(error) {
		console.log("error!");
		return;
	}
	console.log(data);  // ファイルの内容
});

わお! ファイルを読むだけで1つコールバック関数が出てきた。

例に挙げたような単純な物ならば特に問題にはならないだろうが、大体のプログラムは、こんなに簡単ではない。ファイルを読んで、DBのAとBとCテーブル読んで、それらでゴニョゴニョした結果を別のファイルに書き込んで、そんな処理が2つも3つも在って……とやっていくと、出来上がるのは深い深ーいコールバック関数の「谷」である。人はコレを「コールバック地獄」と呼ぶとか呼ばないとか。

コレは拙いよね、どうにかしないとね。という訳で使われるのが、async.jsというライブラリ。というか、その中のwaterfallseriesか。

この内、waterfall関数の効果的な使い方が、イマイチよく分からない。

続きを読む
posted by 天井冴太 at 22:40 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2014年02月15日

やったー!Vimでヒアドキュメント実装出来たよー!

この記事は、「Vim Advent Calendar 2013」の第77日目、通算2回目の担当記事である。

なお、昨日はosyo-manga(@manga-osyo)さんの「Vim Advent Calendar 2013: KaoriYa 版 Vim の +migemo を試してみた」だった。

更に、私のVAC2013担当記事1つめは「closesomewindow.vim – 条件に合うウィンドウを閉じる Vim plugin」だった。


最初に言っておく。

ごめんなさい

ヒアドキュメントとは何か?

シェルスクリプトやその他大体のスクリプト言語に実装されている、以下のような機能のことである。

var = <<EOS
↑こういう風に、
  "<<" + 識別子
という形式で書いたら、
次に識別子と同じ文字列が現れるまでの、
全ての行の内容を、
一つの文字列として取得出来る

↓この"EOS"までがヒアドキュメント
EOS
続きを読む
posted by 天井冴太 at 15:00 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年11月26日

MinGWとMinGW-w64は別の物……らしい

ある思いつきがあって、それが実現出来るのか確認する為に、 Win32 API を使ったコードを書いてる。

MinGWのgcc環境下で書いているのだが、Winternl.hが無いと怒られる。mingw32-w32apiパッケージを導入すればいいのかと思ったがそうでもない。

ググってみると、Rubinius開発者のIRCチャットログと思しき物がヒット。

00:08:29nattesrc/mutex.c:2:22: fatal error: winternl.h: No such file or directory
00:09:02nattestrange seems like the platform SDK is missing, thought that would come with VS Ultimate but I guess not
00:33:46brixenI think you're using mingw
00:33:51brixeninstead of mingw-w64
00:37:13natteoh crap
00:37:17natteyou are correct

どうも、MinGWとは別にMinGW-w64というプロジェクトがあって、そっちを使えばいいらしい。

個々のコンパイラ?Wolfram Mathematica 9 ドキュメント」曰く。

MinGW

CCompilerDriverパッケージはWindowsにおけるGCCのネイティブWindowsポートであるMinGW(http://www.mingw.org)について,Windowsプラットフォーム上でテストされている.このソースのMinGWは64ビットバイナリを生成しないことに注意されたい.この機能は汎用Cコンパイラのセクションに記載のMinGW-w64で提供される.

64ビットターゲット用MinGW

http://www.mingw.orgで入手できるコンパイラはWindowsの32ビットおよび64ビットの両方で動作するが,現時点では32ビットバイナリのみをコンパイルする.64ビットWolframライブラリを生成するためには,MinGW-w64(http://mingw-w64.sourceforge.netから入手可能)という別のプロジェクトを使う.

ううむ、MinGWとMinGW-w64が別物だという事は把握したが、何故、別になっているのか。MinGW-w64が(その名の通り)64ビット環境専用というのならば解るが、そういう訳でもないらしい。理由が分からんので若干モヤモヤする……

というか、導入するのが面倒くさいで御座る! MinGW関係のディレクトリにPATH通してるから、単純にインストールとPATH設定だけだと競合して変な事になるのが目に見えるてるで御座る!

タグ:gcc MinGW-w64 mingw
posted by 天井冴太 at 02:23 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年11月16日

MinGWとGHCは共存出来ないっぽい

あるC++プログラムをMinGWのGCCでコンパイルしようとしたら、吐き気がする程の大量のエラーメッセージが表示された。いやいやエラーになるにしてもこの量は有り得ないわ。何かが悪さしてるんじゃないか。

で、試しに超簡単なコード書いてコンパイルしてみようとしたらコケる。

> type test.cpp
#include <iostream>

int main(int argc, char *argv[])
{
		std::cout << "hello" << std::endl;
		return 0;
}

> gcc test.cpp
C:/Program Files/Haskell Platform/2012.4.0.0/mingw/bin/ld.exe: cannot open outpu
t file a.exe: Permission denied
collect2: ld returned 1 exit status

> g++ test.cpp
Info: resolving std::cout  by linking to __imp___ZSt4cout (auto-import)
c:/program files/haskell platform/2012.4.0.0/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
続きを読む
タグ:C++ Haskell GHC mingw
posted by 天井冴太 at 02:10 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年10月16日

(10 - 5) "type" Command Examples to Manage Files in Windows

大分前になるけれど、上記の記事で、 Linux / Unix で用いられる「cat」コマンドの使われ方について紹介されていた。

catは、専らファイルの内容の出力に使われているイメージがある。しかし、catは「concatenate」(連結する)の略であり、本来はファイルを連結する為のコマンドだった(らしい)。

Linux / UNIX のcatに似たWindowsのコマンドとして「type」が在る。このtypeコマンドでも、上記記事で紹介された使い方の一部は実現出来る。以下でそれらを紹介する。

なお、typeはMS-DOSにも存在するが、そちらではどうかは確認していない(確認出来る環境が手元に無い)。


続きを読む
タグ:CLI SHELL CUI CMD tips
posted by 天井冴太 at 00:44 | Comment(2) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年07月31日

PowerShellの起動時に指定したオプションを取得する(そして対話的な実行かどうかでモジュールを読み込むかどうか切り替える)

コマンドラインシェルの用途は2つ在る。対話的に処理させる場合と、バッチ処理させたい場合だ。バッチ処理用に起動した場合に、対話的環境での利用を想定した処理を行うのは無駄だ。例えばPowerShellでの場合、バッチ処理時にPowerTabモジュールを導入するのは意味がない。むしろ、その為の処理リソースを取られる事になるので、出来る限り避けたい。

続きを読む
タグ:PowerShell CLI tips
posted by 天井冴太 at 01:40 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年05月21日

Windows Script Host から Windows PowerShell へ

先日Windowsの環境変数について調べた際に、久しぶりにWSH用のJScriptを書いた。WSHMicrosoftが提供するWindows用のスクリプト実行環境だ。

WSHの利点はWindowsにプリインストールされているという事だ。Wikipediaに拠ると、 Windows 98 以降であれば確実に入っているという。(RubyPerl等とは異なり、)別途実行環境を用意する必要がないので、作成したスクリプトを配布する際にとても便利だ。

しかし、今となっては甚だ時代遅れで使いづらい。例えば配列の全要素を舐めるのに Array.forEach() が使えなかったり。現代のJavaScriptに触れていると、「あれも無い、これも無い」という点が気になってしまう。

流石にこれではキツイ。そこで Windows PowerShell に目を付けた。PowerShellはMicrosoftが新たに開発したコマンドラインシェル環境だ。これがまぁ意外と良い感じ。 Windows 7 からはプリインストールされているらしいし、将来的には導入コストは0になるだろう。

勿論、WSHはスクリプト実行環境でPowerShellはシェル環境なので、単純に比べられる物ではない。WSHとcmd.exeを合わせたものと比べるべきなのかもしれない。今までこの2つで行っていた作業をPowerShellで行うようにしてみたが、今のところ問題は発生していない。

個人的には、ドライブの機能に注目している。ディスクアクセスに用いるドライブレターのような識別子を用いて、様々なデータへのアクセスを共通のコマンドで行えるようにした仕組みだ。例えば、カレントディレクトリ以下のファイル/ディレクトリの一覧はGet-ChildItemコマンドレットで取得出来るが、Envという名のドライブへ移動した後なら同じ方法で環境変数の一覧を取得出来る。この仕組みはコマンドラインシェル以外にも応用が利きそうだ。エクスプローラのようなファイラ風のインタフェイスを備えたソフトから様々なデータにアクセスしたり。

posted by 天井冴太 at 01:24 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年04月25日

Greasemonkeyの@grantメタデータの意義がよく分からない

amazon-bookmeter-link-adder.user.js ver1.01.20130425を作る時に、「@grant付けりーよー」とお猿さん怒られたので、"@grant - GreaseSpot Wiki"を読んでみたが、イマイチこのメタデータの意義が分からない。

どうもセキュリティ関係の機構のようだが、"If a script does not specify any @grant values, Greasemonkey will attempt to auto-detect the right settings."と書かれているし、自動判定するのに要るんだろうかこれ。

怒られた
しまった、キャプチャ取り忘れた。
タグ:greasemonkey
posted by 天井冴太 at 16:59 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年02月06日

GVimの起動時には幾つかの関数が使用出来ない

ここで言う"起動時"というのは、GVim起動直後の.vimrc処理時で、多分、"has('vim_starting')==1"な時の事。

なお、GVim――つまりGUI用のVimでの話であって、コンソールで使う普通の(?)Vimでは問題ない。

:help input()曰く。

NOTE: This function must not be used in a startup file, for
the versions that only run in GUI mode (e.g., the Win32 GUI).

しかしどうもinput()だけの話じゃ無いようで、以下の関数が使えなかった。

  • input()
  • inputdialog()
  • inputlist()
  • confirm()

ユーザーに何か問い合わせる系統かな……そういう関数って他にも在る?

inputで始まる関数群はまともに動かない(空文字列とか0が帰ってきている模様)だけだけど、confirm()が曲者で、Linux(Crunchbang)だとGVimの起動さえしない。

因みにWindows XPだと、第1引数と第2引数を改行で連結した内容がダイアログボックスで表示された。例えば、

call confirm('prompt', "Yes\nNo")

とだけ書いたファイル(%HOMEDRIVE%%HOMEPATH%\test.vim)を用意して、以下のように実行すると、

Windows XPの

gvim -u "%HOMEDRIVE%%HOMEPATH%\test.vim" -U NONE

以下のダイアログボックスが表示される。

1行目に

:autocmdにするとよさげ。やや意味合いが変わってくるけれど、影響は無いんじゃないかなぁ?

autocmd VimEnter * call confirm('prompt', "Yes\nNo")

どうも、--cmdオプションで使った時も同様の問題が発生する模様(あまりきちんと調べていない)。

バージョン7.3で確認。

タグ:Vim_script Gvim vim
posted by 天井冴太 at 00:35 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2013年01月07日

Gitでtypoしたコマンドの正しい綴りを推測、自動実行させる

Avner Cohen : Git - Autocorrect spelling

へー、知らなかった。というわけで紹介。


Gitコマンドを打つ時(いや、Gitに限らないが)、何らかのtypoを犯してしまう事は良くある。

例えば、

git pusj	# 本当はpush

勿論Gitに"pusj"なんてコマンドは無いので、本来ならばエラーとなる。

エラーを確認し、正しいコマンドを打ち直すのは何とも面倒だ。しかし、ユーザーが意図していたコマンドを推測し、それを実行するようにGitを設定する事が出来る。

その為にはhelp.autocorrectを使う。

git config --global help.autocorrect 1

help.autocorrectの引数は、補完対象のコマンドを実行するまでの待ち時間(0.1秒単位)である。上記の場合であれば0.1秒待つ事を意味する。

先の"pusj"の場合であれば、"push"のtypoである事が推測出来るので、Gitは以下の警告メッセージを出力後、指定の時間だけ待ってから"push"を実行する。

WARNING: You called a Git command named 'pusj', which does not exist.
Continuing under the assumption that you meant 'push'
in 0.1 seconds automatically...

(勿論"0.1 seconds"の部分は、実際にhelp.autocorrectに設定した値によって変動する。)

待ち時間が在るのは、ユーザーの意図と異なる推測が行われた時に、それを(例えばCTRL-Cで)キャンセル出来るようにする為だろう。

なお、値を0にすると候補の列挙のみ(つまりデフォルトの挙動)、負数にすると待ち時間無しに推測したコマンドを実行する。

因みに私は20、即ち2秒待機するように設定している。誤った推測をキャンセルする事を考えると、数秒のウェイトは必要ではないかと思う。

タグ:tips vcs git
posted by 天井冴太 at 02:34 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2012年07月22日

Qiita user following tags feed - Qiitaでフォロー中のタグを付けられた新着記事を取得するfeedを吐くYahoo!Pipesを作った

タイトルは一息に読む(変に長くてごめんなさい)。

作成途中に一度Qiitaに投稿したけど、どうも上手く動いてるようなので公開。"どうも"なんて不確かな表現なのはPipeの動作確認が超絶面倒だから。お察しくださいな。

コレは何?

任意のQiitaアカウントがフォローしているタグを付与された新着記事をfeed(RSS等)として出力するPipe。

例えば私の場合、アカウント名は"AmaiSaeta"なので、AmaiSaetaがフォロー中のタグ - Qiitaでリストアップされる24種(2012年7月22日現在)のタグが対象になる。

使い方

Qiita following tags feedにアクセスし、feedを取得したいユーザーのアカウント名を"Input a user name."テキストフィールドに入力しRun Pipe。後は"Get as RSS"のリンクをフィードリーダーに登録するなりなんなりお好きなように。

稀にtimeoutしている……ような気がする。Pipesレベルじゃ対処法が思いつかないので、仕様って事で。

タグ:Qiita pipes Feed
posted by 天井冴太 at 11:00 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2012年07月05日

コミットログの書き方のアレコレ細かい点

  1. コミットログは現在形?過去形?それとも?
  2. 続: コミットログは現在形?過去形?それとも?

この話題の細かい点。

  • アンケートの2問目で、ついでにログ書く時に使っている言語について聞いてみたんだが、母語でも、住んでる地区の言語でもない、別の言語と回答する人が多かった。やっぱり英語なんだろうか。使用言語とその理由も併せて聞けばよかった。しまった。
  • 某所で「Git使いはコミットメッセージの書き方を気にする人が多い印象が有る」という意見が……そうなんだろうか。真っ当にVCS使い始めたのがGitからだしよく分からない。
タグ:vcs
posted by 天井冴太 at 22:40 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する

続: コミットログは現在形?過去形?それとも?

というわけでアンケートを採ってみた結果。

コミットログは現在形?過去形?それとも……(択一)

現在形
5
過去形
3

現在形で書く人の方が多いらしい事が分かった。

まぁ、回答数が少なすぎて、有効な結果と言えるのかかなり怪しいけど……

とはいえ、役に立つ知見を得られたのも事実。

id:yossiy7yossiy7 現在形・過去形というのは、ちょっと違っていて、実際は「誤:??→正:○○」とかそんな感じで一応過去形なので過去形にしたけど、両方ってのが正解かな。

「文章ではなく、記号的に記述する」というパターンは完全に想定外だった……

コメント欄でid:tyruさんが言及しているStack Overflow上の質問に付けられたこのコメント引用している文章には以下の様に書かれている。

The use of the imperative, present tense is one that takes a little getting used to. When I started mentioning it, it was met with resistance. Usually along the lines of “The commit message records what I have done”. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do.

自分の(悲惨な)英語力を動員して読んでみるに、「Gitは分散VCSなので、(他の開発者の為に?)『そのコミットで何を行ったか』ではなく『そのコミットを適用する事で何が起こるか』を記述しろ」という事らしい。

私は今まで、「コミットログとは(ログの名の示す通り)変更内容を記述する物だ」という認識だったので、このようなコミットログの捉え方は考えた事がなかった。成る程この考え方ならば過去形はおかしいな。

しかし、その考え方は、適用する(pullしてくる)コミットを好き勝手に選べる環境じゃないと意味を成さないような……例えば、オリジナルのリポジトリからcloneし、その後変更点をpullする迄に、オリジナルに複数のコミットが追加されていた場合、「1つ目のコミットは無視するが、2つ目のコミットはpullする」のような場合(そもそも出来るのだろうか?)でも問題ないと保証出来る時に限られるのではないか?

それはかなり難しいと思うので、私はこのガイドラインには否定的。

尤も、件の365Gitには次のようにも書かれている。

Having said all that - it’s your code, your repository: so set up your own guidelines and stick to them.

あんまり気にせずに自分の好きなように運営するのが一番なのかもしれない。

タグ:tool vcs
posted by 天井冴太 at 22:23 | Comment(0) | TrackBack(1) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2012年03月29日

Herokuのconfig varをローカル環境下のスクリプト内で取得するには

2012年11月5日追記

現在、heroku gemのAPIを用いてのHerokuへのアクセスはdeprecatedになり、替わりに、heroku-apiを用いるようになっている(herokuコマンド自体は引き続き利用出来る)。
Herokuのconfig varをローカル環境下のスクリプト内で取得するには(heroku-api版)を参照されたし。


HerokuとGitHubの両方にプッシュできるようになったのはいいけど、例えばTwitterOAuth認証用のトークンとか、何かのAPIを利用するためのAPIキーとか、あるいはもっと大事な何かのパスワードなど、秘密にしておきたい情報は、GitHubにプッシュしてしまうと全世界に公開されるので非常にマズい。

かといって書いておかないと、Herokuにプッシュしたときに情報が足らなくてアプリが正常に動かない。

どうするん?毎回消したり書いたりするの?

config varというのは、上記のようにHerokuとGitHubの両方にプッシュする時の秘密にしたい値の扱い - アインシュタインの電話番号?に記されているような要求をこなす時に使うheroku config:addで追加する値の事ね。
ENVでアクセス出来るし、正体はただの環境変数だと思うが、heroku help configにはconfig varsと表記されてるのでそっちの表記を採用。

さて、このconfig vars、ruedapさんも言及してるように、Herokuの環境下でしか利用出来ない値で、ローカル環境での開発時にはENVに無い。彼も言っているような、ローカル環境かどうか判定して、同一内容をENVに突っ込むスクリプトをrequire、そのファイルは間違ってHeroku側のリポジトリにcommitしないように.gitignoreに書いておく……というのがサッと思いつく対処法か。だが、値の追加/編集時に、heroku configとそのスクリプト、両方を同一内容になるように保持するというのは流石にめんどくさい。

そんな馬鹿な。
おかしい。
あり得ない。
ぜんっぜんprogrammableじゃない。
そもそも、herokuコマンドはgemで導入する物だし、もしかしてライブラリとして利用する方法があるんじゃないの?

という訳で、herokuコマンドのソースを斜め読んでみると、次のようにしてRubyのスクリプトから取得出来る事が分かった。

#!/usr/bin/ruby
require 'rubygems'
require 'heroku'
require 'pp'

EMAIL       = '(Herokuに登録した時に使ったメールアドレス)'
PASSWORD    = '(Herokuのパスワード)'
APPLICATION = '(アプリケーション名)'
KEY         = '(値を取得したいconfig varのKEY)'

heroku = Heroku::Client.new(EMAIL, PASSWORD)

# APPLICATIONの全config varを取得
vars   = heroku.config_vars(APPLICATION)
pp vars	# heroku.config_varsの戻り値はただのHash

# 特定のconfig varを取得
var    = vars[KEY]
p val

……コード中にメールアドレスだのパスワードだの埋め込むのは美しくない。何の為にconfig vars使おうとしてるのやら。

もうちょっとherokuのコードを読み進めてみると、既にheroku loginしているならば、Heroku::Client.newの替わりにHeroku::Auth::clientでも良さそう。

という事は、実際に使う時は次のような感じだろうか。

# 既にheroku loginしている事前提
require 'rubygems'

# ...snip...

if !ENV.key?('VAR1')	# config varのどれか一つでも存在しない場合
	require 'heroku'

	config_vars = Heroku::Auth.client.config_vars(APPLICATION)

	# PATHやLANGといったheroku config:addで登録した物以外も出てくるので、愚直に代入処理をしている
	ENV['VAR1'] = config_vars['VAR1']
	ENV['VAR2'] = config_vars['VAR2']
	# ...以下全てのconfig varについて同様に
end

#...snip...

うーん、ローカルかリモート(Heroku上)かの判定をENV.key?で行うのは何か変だな……もっとスマートな方法が在りそうな気がするが……

タグ:heroku ruby
posted by 天井冴太 at 03:05 | Comment(0) | TrackBack(1) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2012年02月10日

忍者バリアーなんて死ねばいいのに

忍者バリアーは「荒らし」、スパムなどからのアクセスを簡単に拒否、制限できるサービスです。

……というのが、忍者バリアーの趣旨らしいのだが……

『許可したドメインのJavaScriptのみ実行を許可する』アドオンのNoScriptを導入したFirefoxで、忍者バリアーを導入しているwebページを閲覧しようとすると……

[忍者バリアーで飛ばされるページ]問答無用で閲覧がブロックされる。

閲覧出来なかったページのソースコードを覗いてみる。

<script type="text/javascript" src="http://bar1.shinobi.jp/hash.js"></script>
<script type="text/javascript" src="http://bar1.shinobi.jp/s/40/00381.js"></script>
<noscript><a href="http://www.ninja.co.jp/barrier/" target="_blank">アクセス制御</a></noscript>
<noscript><meta http-equiv="refresh" content="0;URL=http://bar1.shinobi.jp/hoge/NoScript?0038140" />
<div style="background-color: #000000;text-align: center;vertical-align: middle;width:100%;height: 100%;margin: -10px;padding: 0px;z-index: 10;position: absolute;">
<div style="color: #ffffff;margin: 0px;padding: 0px;position: absolute;top:50%;left:47%;"><a href="http://www.ninja.co.jp/">NINJA TOOLS</a></div></div></noscript>

スクリプトを実行出来ない環境下で適用する内容を記述するnoscript要素の下で、<meta http-equiv="refresh" />を使い、忍者バリアーが用意したページにリダイレクトしている。

強制的に忍者バリアーの用意したページに移動してしまうので、元のサイトのスクリプト実行を許可する暇もない。

つまり、NoScript(或いは類似機能を導入したwebブラウザ)では、忍者バリアーを導入したページは閲覧出来ない。荒らしやスパマーか否かに拘わらず。

荒らしやスパマーか否かに拘わらず』。
はい、大事な事なので2回言いました。

そもそも、

このホームページはJavaScriptを使っています。
ブラウザの設定でJavaScriptを有効に設定してから
アクセスしてください。

とか言っているが、JavaScriptが必要なのは忍者バリアー自身じゃないか。

また、世の中にはJavaScript使えないwebブラウザだって存在するのだ。そういったブラウザの利用者はどうしろと?

大体、忍者バリアーなんて簡単に通過できてしまうのだ。忍者バリアーで本当に防ぎたい荒らしやスパマーは、これくらいの対策はしてくるだろう。バリアー()

結局、
忍者バリアーは、荒らしやスパマーに対しての効果が殆ど程めず、且つ、悪意の無い閲覧者にとってはページ閲覧の邪魔になりかねないという、全くのクソッタレなのだ。

敢えて言おう。
忍者バリアーは役立たずであると!

posted by 天井冴太 at 22:43 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2012年02月07日

Cygwin←→Windowsのファイルパス相互変換

備忘録ともいう。

CygwinのパスをWindowsのパスに
cygpath -w filepath
CygwinのパスをWindowsのパス(ショートファイルネーム)に
cygpath -d filepath
WindowsのパスをCygwinのパスに
cygpath -u filepath

-uデフォの挙動のようで、省略しても動作する。

他に、Windowsの各種特殊フォルダ(デスクトップとかSystemフォルダとか)を出力させる事も出来たり、結構多機能。

Try `cygpath --help' for more information.

posted by 天井冴太 at 21:24 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2011年09月30日

Visual C++ 2010でQt使おうとして挫折した話

此処で出てくる"Visual C++ 2010"は正確には"Visual C++ 2010 Express SP1"の事ですはい。

以下やった事箇条書き。

  1. Qt のダウンロード ? Qt - A cross-platform application and UI frameworkからQt SDK version 1.1.3のオンラインインストーラーをダウンロード。
  2. インストーラー起動。デフォルト設定でインストールを行おうとするも、あまりのダウンロード所要時間に音を上げ中止。
  3. 再びインストーラー起動。適当に必要不必要そうなモジュールのチェックを付けたり外したり。この時、VC++のサポート対象が2008だと知って少々不安になるも、インストール成功。
  4. スタートメニューからQt 4.7.4 for Desktop (MSVC 2008)を起動。VC++2010のvcvarsall.batを起動。
  5. Qt 4.7: Getting Started Programming with Qt のHello Notepadサンプルと同じコードを入力し、qmake -project & qmake & nmake。成功。

実行すると……

D:\Documents and Settings\AmaiSaeta\qttest.vc>debug\qttest.exe
指定されたプログラムは実行できません。

アルェー?
まぁVC++2010でVC++2008用のバイナリを使ったわけだから、変な事になるのも致し方なし……

仕方無いので、Qtをソースからビルド。

  1. Qt のダウンロード ? Qt - A cross-platform application and UI frameworkからqt-everywhere-opensource-src-4.7.4.tar.gzをダウンロード、適当な場所に展開。
  2. Qt 4.6: General Qt Requirements及びQt 4.6: Qt for Windows Requirementsに有る通り、DirectX SDKとWindows Platform SDK、OpenSSLを導入する。
    今回はそれぞれ、現時点で最新と思われる以下の物を採用。
  3. Qt 4.7: Installing Qt for Windowsを参考にQtをbuild。configureのオプションはconfigure -helpを見つつ適当に決めた。
    "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
    PATH C:\OpenSSL-Win32\bin\;%PATH%
    SET INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE%
    SET LIB=C:\OpenSSL-Win32\lib;%LIB%
    PATH (Qtソース展開先)\bin;%PATH%
    CD (Qtソース展開先)
    configure -debug-and-release -opensource -shared -static -no-qt3support -platform win32-msvc2010 
    nmake
    当方の環境で2時間半というウンザリするような時間かけてbuild完了。
  4. バイナリ版導入と同じくQt 4.7: Getting Started Programming with QtのHello Notepadを作ってみる。今度は正常に動作。
  5. 続いてAdding a Quit Buttonを作ってみる。buildは成功するが、Quitボタンを押すと……
    [Qtサンプルプログラムを実行すると表示されたAssertion Failedダイアログ]

アルェー?
assertion failedしたf:\dd\vctools\ctr_bld\self_x86\crt\dbgdel.cppというファイルはこちらの環境には存在しない。というかf:ドライブなんて無い。という事は、Qtのbuildで使った(C++標準含む)ライブラリの何れかで発生していると思われるが、それを調査する気力は既に残っていないのであった……

posted by 天井冴太 at 18:54 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2011年05月14日

Visual C++ 2010で生じる、warning C4819を退治する

何らかの理由によりVC++のエディタ画面以外でコードを編集したいと言う事はよく有る。そういった時、いざVC++でコンパイルしようとした時に警告が発生する事がある。

例えば以下のようなコードを何らかのテキストエディタで記述し、UTF-8で保存する。

#include <iostream>
using namespace std;

int main()
{
	cout << "このプログラムには日本語の文字列が含まれています。" << endl;
}

で、これをコンパイルすると、以下のような警告/エラーが発生する事が有る。

test.cpp : warning C4819: ファイルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を防ぐために、ファイルを Unicode 形式で保存してください。
test.cpp(6) : error C2001: 定数が 2 行目に続いています。
test.cpp(7) : error C2143: 構文エラー : ';' が '}' の前にありません。

しかし、全く同じコードをVC++IDEにて作成した場合はエラーとならない。

何故か。

どうやら、VC++UTF-8なソースコードをコンパイルしようと思ったら、BOMが必要となるらしい。
エラーメッセージの現在のコード ページ (932)という記述から推察するに、BOMが無ければCP932として処理しているのだろう。

IDE上で文字化けする訳でもないのに、不思議な話である。

[VC++ 2010にてファイルの文字コードを変更するには、"ファイル"メニューの"名前を付けて (ファイル名) を保存"から保存し直せば良い。この時、"名前を付けてファイルを保存"ダイアログの"保存"ボタン右の下向き三角形をクリックし、"エンコード付きで保存"を使う必要が有る。

ただ単に警告が出るだけであれば、無視するなり、#pragma warning(disable: 4819)を指定するなりしても良いのだが、恐ろしい事に、他のエラーや警告を同時発生させる事がある。上に挙げたコードが正にその例となっており、文字コード誤判断の結果、error C2001とerror C2143が発生しているのが分かる。
warning C4819が発生している状態で、なおかつ原因の分からないコンパイルエラーが発生しているのであれば、コードの文字コードに注意を払う必要が有るだろう。

謝辞

THX @cpp_akira!!

何らかの理由により
コーディングにはVim使いたいとか。
VC++でコンパイル
VC++付属のclコマンドも含む。
BOM
UTF-8でのそれは、正確には"Byte Order Mark"という訳ではないが。
posted by 天井冴太 at 20:37 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する
2010年03月15日

Windowsのコマンドライン(cmd.exe)で『何もしない』コマンド

:(コロン記号)で『何もしない』コマンドになる。

bashのそれと一緒だね。もしやと思って試してみてよかった。

Twitterに書いたら「え、それってコメント開始記号じゃないの?」って突っ込まれたが、コメント (コンピュータ) - Wikipediaに拠ると::(コロン2つ)か: (コロンの後に半角の空白)がコメント開始記号らしいので、多分違うのだろう。WindowsXP自身のヘルプには、REMを使ったものしか説明が見つけられなかった。

SAMECOMMAND & :

なんて真似が出来るので、実行後すぐ値が返ってくる事を期待しているプログラムに使ってもエラーにならずに済むという。そう、例えばVimperator:!とか。

タグ:CMD tips
posted by 天井冴太 at 03:01 | Comment(0) | TrackBack(0) | Tool | このブログの読者になる | 更新情報をチェックする
投票お願いします 人気blogランキング - 投票する