do:kalaclism

『輝かしい青春』なんてなかった人のノート

途中で挫折しないための『タグ分類』の仕方

自分の中で、2017年にもなってようやくながら、

はてブやブログでのタグ付けの仕方

が、固まってきたので、今回の記事ではその辺りをメモっておきます。

1. 『主語』は大きく『抽象的』に分類する

例えば、

Javascript を使った○○についての使い方

みたいな記事だった場合、

Javascript, ○○, 使い方

みたいな具体的なタグを付けずに、

開発, 知識

みたいな感じで、『主語』が大きくかつ『抽象的』なタグ付けをすると良いです (自分的には)

2. 『脊髄反射』でタグを付ける

まあ、前にやった失敗なんだけども、

タグを付けるための俺々ルール

みたいなのを新規で作り、かつ、それがその詳細をすぐに忘れる様な複雑さを持つ場合、 大抵、途中でめんどくさくなってタグ付けのルールが崩壊します。

そのため、

タグ付けのルール

みたいなのは、まあ脊髄反射でパパっと付けれる、

自分の中では単純なルール

にしておくが吉です。

まあ簡単に言えば、

心理的コストを極力下げる

という感じですね。はい

3. 細かい内容については検索でカバー

まーこれ、サービスにも依るんだろうけれども、例えば、

開発 タグを付けた記事から Javascript を含む内容を抽出したい

みたいな場合、そのサービスの検索システムが使いモノになるなら、

雑なタグ + フリーワードによる絞り込み

を使った方が後々楽です。

っていうか、情報をストックするサービスで、 全文検索が使いモノにならない 、 と言うのは割と致命的なので、その手の使えないサービスからはとっと情報を引き上げた方が良い気がします。はい。

以上

あとはまあ好みで、

  • タグを英語にする

とかする等して、色々アレンジ加えても良いんじゃないかなーと僕は思います。はい。

macOS Sierra で wine-staging 2.0-rc3 を使って FLStudio 12.4.1 を動かしてみた

という話です。


始めに

最初に断っておくと、

macOS Sierra で wine 使って FL Studio !

は、遊びとしてはとても楽しいのですが、実用するには色々と辛すぎる感が有るので、 ぶっちゃけ、 FL Studio で真面目に音楽を創るなら、素直に Windows の物理マシンか、 あるいは仮想マシンか何かで Windows Instance 立てて、そこで曲作りしましょう。

インストールの流れ

  1. まず、wine-staging を Homebrew cask か何かでインストールします
  2. 次に、後で色々とやり直しが効く様に、FL 用の wine prefix を用意します
  3. wine prefix が用意できたら、winetricks も用意して次の tweak を apply します:
    • dotnet20
    • directx9
    • vcrun2008, vcrun2010, vcrun2012, vcrun2013, vcrun2015, vcrun6sp6
    • corefonts, tahoma
    • あと、好みで osx-wine-inf とか使うとフォント周りが綺麗になります
    • なお、corefonts の apply には cabextract が必要です (Homebrew でインストール可)
  4. そして、FL Studio を先程まで作っていた wine prefix にインストールします
  5. 最後に、wine prefix の system.inimsacm.vorbis=vorbis.acm を追加します
  6. 以上

というのが大体のインストールの流れです。

FL Studio 起動の流れ

えっ? FL Studio を起動する手順とか有るの!?

と思われるかもしれませんが、実は有ります。

というか、まあ実際の Windows だと普通にインストールして起動すれば FL Studio は動くんですが、 今現在 (2016 年 12月 26 日に) 試した範囲での、

FL Studio on wine on macOS Sierra

では、wine が Windows を絶妙にシュミレーションし切れてない関係で、

FL Studio が起動途中でハングアップして操作出来ない + CPU 使用率モリモリ

という状態になります。

なので、その問題回避を行うために、

  1. macOS Sierra の Input method に Unicode 16 進数入力 辺りを入れる
  2. 次に Unicode 16 進数入力 がアクティブ (有効) になった状態にする
  3. 最後に、2の状態を維持したまま FL Studio on wine on macOS Sierra を起動する

という感じの手順を踏む必要があります。

で、なんでこういう訳の分からんおまじないみたいな手順は必要かというと、 たぶん、これは wine 側の実装と FL Studio の挙動の加減だとは思うんですが、

日本語への切り替え可能な Input Method がアクティブ

な状態で、 FL Studio を wine 上で起動すると、 wine が

fixme:imm:ImeHandleNotify

のログを吐いた辺りで、 FL Studio の起動がハングアップします。 つまり、

固まって起動しきらない! FL Studio 使えない!つらい!

という状態になるので、今のところはこのおまじないみたいな手順が必要です。はい。

以上

まー、 これを真似するな 、とは言いませんが、僕はこれを行う手助けとか出来ません し、 また、 wine の開発コミュニティに 再現可能なバグとしてバグトラッカーに持ち込むまでは良し としても、 FL Studio のサポートにこれが動かないよ 、って連絡なげても、そもそも サポート対象外な行為 なので、 サポートされない行動だよ って事は、 声を大にして言っておきます

あとはまあ、どうも FL Studio を macOS かつ wine で動かそうとしているヘンな人 で、 日本語で情報を書いてるのがほぼ僕しかいないっぽい (ググってるマジで自分の情報しか引っ掛らない) のが、なんとも言えない感じ。

それで、最後にもう一度言っておきますが、これのサポートを僕はするつもりもないし、 また、この手の Hack は基本、自己責任で行うモノなので、 これに手を出したい場合には、その辺り弁えた上で行いましょう。


という事で今回の記事は以上です。

あと最後に。

FL Studio が気に入ったなら、ライセンスはキチンと買えよ! ネットで買うと特典も有るぞ!!1

AWS Lambda + Amazon API Gateway の使い道

僕個人としては、

  • AWS Lambda + Amazon API Gateway

という組合せは、現代に黄泉返った CGI みたいなモノだと認識しているのですが、 この AWS Lambda + Amazon API Gateway 、上手く使えば Web サービスの質を向上させたり、 あるいは、経費削減とかも可能になるのでないか (未検証) と思っています。

しかしながら、 AWS Lambda + Amazon API Gateway と言う組み合わせは、 ひとクセもふたクセも有る代物なので、今回はその辺りも含め、 ザックリと AWS Lambda + Amazon API Gateway の使い道について書いてみます。

※ ただし、僕の視点は、あくまで Web 開発者としてのモノです

1. この組合せで出来るコト・出来ないコト

基本的に、

  • AWS Lambda + Amazon API Gateway という組合せ

の、出来るコト出来ないコトは、それぞれのサービスの制約の集合になります。

これは例えば、

  • Amazon API Gateway は UTF-8 なレスポンスしか返せない
  • AWS Lambda は、特別なコトをしなげれば、特定の言語しか動かせない
  • AWS Lambda は、処理時間に制約が有る

という辺りなんですが、逆に言えば、これらの制約が問題と成らなければ、 基本的に何にでも利用できます。

2. Lambda + API Gateway の使い道

今の所、

  • AWS Lambda + API Gateway が向く使い道

として僕が思い付いている使い方は、

  1. Node.js (Lambda) での Server-Side Rendering Frontend としての利用
  2. ランタイムを問わず、Web hook の callback 先としての利用
  3. 簡易フォームなどの、VM の インスタンスを立てるまでもない処理

辺りです。

それで、2番と3番に関して言えば、これは CGI 代わりに使う、という感じのイメージですが、 1番についてもう少し説明と言うかアイディアの詳細を書くと、

  1. Lambda では Node.js v4 を Runtime とする
  2. API Gateway は Routing に用いる
  3. Lambda + API Gateway からの Backend の問合せには GraphQL 辺りを使う

という感じです。

そして、なぜ

  • Lambda (Node.js v4) + API Gateway を Server-Side rendering の Frontend

とするのが良いのかと言うと、理由としては、AWS にインフラを集約している場合、 Node.js での Server-Side Rendering を行うためだけに VM のインタンスを用意する必要がない 、 と言うのと、あとは、GraphQL などの、API 用の Interface を間に挟む事によって、 Backend 側の更新などが行いやすくなる、という辺りです。

まあ基本的には、

  • Frontend と Backend が疎結合となり、コスト削減にも繋がる

という辺りがメリットだ、と僕は思っています。

ただまあ、最近開発とか出来てない影響で、これについては未だに検証出来てないので、 実際のサービス運営でそれが通じるかどうか、については、未知数ですが。

まあでも、基本的には Lambda + API Gateway は、あんまりコストが掛らない、 という認識なので、まあ多少はなんとかなると思いますけども。

3. ただし、やり過ぎには注意

ただまあ、いくら Lambda + API Gateway がコストが抑えられて気楽に使えるから、 と言っても、それですべてを完結させる CGI-like な 環境として使うのは、ちょっとどうかなーって思っています。

と言うのも、特に僕にとっては、

  • AWS Lambda + Amazon API Gateway + 何かのデータストア

で完結させられるサービスを作るのは、楽だしコスト安いし、マネーを投下し続ければ無限にスケールするし、 で、良い事づくめな印象なんですが、いかんせん AWS に強く依存してしまうので、インフラを乗り換えにくくなる、 と考えられますし、また、AWS のインフラがなんらかの事情で止まってしまうと、そのサービスも無論死にます。

そのため、ミッションクリティカルと言うか、完全なサービス停止が要件上出来ないサービスに、 この組合せを用いるのは、ちょっと止めといた方が良いんじゃないかな、と僕は思います。

ただ、そうは言っても、ちょっとした Web Application で、Heroku とかでもオーバースペックな用途だと、

  • AWS Lambda + API Gateway を CGI-like に使う

と言うのは、結構良い選択肢なんじゃないかなー、と僕は思います。

と言う事で以上です

まあ、AWS Lambda + Amazon API Gateway という組合せは、簡単な Web Application を載せたり、 あるいは、フロントエンドサーバをコスト削減しつつ用意する、という用途にはかなり向くのでは? と僕は感じているので、もし案件等に合えば、使ってみるのも手じゃないかなーと思います。