Home

技術日記Lamblog
フルサーバレスCMS: Lamblog 開発中Edit

概要

  • 一番安いコースのさくらのレンタルサーバーでずっと動かしていたWordPressを撤収した
  • 安いサーバーで動かすWordPressは動作が重くて使いたくならないね
  • ブログ以外の自分のサイトを、静的なサイトとしてFirebase上に置いたまま放置していた
  • git管理してコマンド一発で更新できるようにしたんだけど、やっぱりオンラインで更新できないと面倒くさいね
  • 何が欲しいのか考えてみた
    • サーバー管理したくない→サーバレスがいい
    • オンラインで気軽に更新したい→CMSにする
    • 重いのはいや→軽快に動作する環境を選ぶ
    • どうせ大してアクセスなんてないんだから0円スタート無料枠ありの従量課金がいい
  • というものを作って自分のサイトを移行することにした

Lamblogの構成

構成イメージ

AWS Lambda with Ruby 2.5

実行環境はAWS Lambdaです。

ちょっと前までは、周辺のミドルウェアが一通りセットになっていて、無料スタートしやすいFirebase押しだったんですが、Firebase Functionsは(日本から使うと)微妙に重いし、ちょっと古いnode.jsが標準でそれ以外を使おうとするとさらに制約が上乗せされるし、深く使おうとするとFirebaseからはみ出てGCP側のコンソールでごにょごにょする感じが分かりにくいし、その辺にうんざりして一押しから脱落しました。

一方のAWS Lambdaはいろいろな言語(特にRuby)が使えるし、(ちゃんとメモリを割り当てれば)日本で使っても軽快な動作だし、Firebase Functionsみたいに中途半端な隠蔽がないし(その分、最初からフルセットで見えているから初めて扱うときの敷居は高そう)、いまいち使いにくいAPI GatewayのREST API以外に、ALB直接マウントやAPI GatewayのHTTP API(beta)とか使いやすいHTTPマウントの方法が揃ってきて、だいぶ重しが取れました。

Rubyはまだまだ初心者に毛が生えた程度な習熟度なんですが、普通に動くコードを書けるくらいには使えるようになったんで、まあ練習がてら。

API Gateway HTTP API

LambdaをHTTPで公開するのに一番便利なのは、ALBに直接マウントしちゃうやり方だと思うんですよね。

ただ、ALBを作っちゃうと時間制の利用料金が発生しちゃって、個人でお手軽に運用するにはちょっとなーというのが唯一の欠点でした。まあALB 1個動かしたところで、月2〜3000円程度しか発生しなかった気はするし、1個のALBで複数のサービスをマウントできるから、税金的に払ってしまうのも悪くはないんですが。

API Gateway REST APIはAPI向けなんで普通のサイトをあの上で無理矢理公開する気にはまったくなれなかったんですが、最近HTTP APIというのが(betaだけど)でているんですね。で、ちょっと触ってみたらかつてのREST APIの欠点がだいぶなくなっていて、これなら個人が気軽にHTTP APIをサーバレスで公開するためのミドルウェアとして使いやすそう。

ただ問題は、API Gateway HTTP APIはHTTPSのサイトしか運用できないっぽいんですよね。まあ普通はそれで全然問題ないんですけど、過去のサービスとかを移行する場合とか、HTTPでのアクセスがあることもある程度想定しておかなければならないんで、せめてHTTP to HTTPSのリダイレクタくらいは仕込んでおきたいじゃないですか。ALBなら一瞬なのに。

CloudFront

というところで思いついたのがCloudFront。

Lambda+API Gateway HTTP API構成ならば、個人レベルではまったく問題ないレベルのハイパフォーマンス&スケーリング能力を持っているから、CloudFrontなんていらないよねーと思っていたんですが、こいつってHTTP/HTTPS両対応な上にバックエンド側へHTTP/HTTPS振り分けする能力も持っている。しかもCDNとしても使える(ついでかよ)。

CloudFrontも無料枠があるんで基本無料+従量課金で使えるから、こいつを使えばいいんじゃね。

と思ったら、実はCloudFrontの無料枠は最初の1年だけだった。くそー、この最初の1年だけ無料枠があるやつ分かりにくいなー。まあ完全従量課金でも個人レベルではたいした額にならないからいいんだけど。

あと、Lambda→API Gateway HTTP API→CloudFrontは、最終的には思った通りに動いたんだけど、結構はまりどころが多かった。ポイントとしては、

  • API Gateway HTTP APIのちょっとバギーな挙動に気をつける
  • CloudFrontの裏側は全体的にHTTPSで正しくつながるようにセットアップする
  • セッションCookieとかを維持するためにはCloudFront、API Gateway HTTP API、Lambdaまで正しくドメイン名(HTTP_HOST)が伝わらないといけない

というあたり。

Amazon S3

コンピューティング能力の話ばかり語ってきましたが、CMSとか使う際にはもう一つ重要なリソースがありますよね。もう一つというか、場合によってはコンピューティング能力よりも重要かも知れない。そう、データベース。

が、今回はデータベースは使っていません。だって個人のサイトで必要なデータなんて、今どきのコンピューティングパワーを考えれば、専用のデータベースアプリケーションが必要なほど複雑で巨大なデータなんて使わないし。

というわけで、データストレージはAmazon S3を使い、そこにすべてのデータを置いておくことにしました。ただ、さすがに毎回記事ファイル一つ一つをS3 APIごしになめて検索したのでは、ネットワーク的なスピードに問題が出そうなので、普段は1ファイルにまとめたインデックスファイルを使って必要な記事を検索し、その後詳細な記事ファイルを取得する感じにしておきました。これなら個人のサイトが扱う程度のデータ量ならば余裕で捌けるでしょう。

ちなみに私はむかーしむかし、PHPでブログツールを作る書籍を出したんですが、そのときもデータベースを使わずに、ローカルファイルシステム上に記事ファイルとインデックスファイルを置いて捌く構成にしました。三つ子の魂百までってやつですね(?)。ちなみにローカルファイルシステム上だったら、インデックスファイルなんてなくてもかなりのスケールまで動くとは思いますが。

ドッグフード食べながら開発してみます

ひとまず大まかに動くようになったんで、

の3サイトをlamblogに入れ替えてみました。

特にここは過去のwordpressからエクスポートしたデータをインポートして、全部で3000記事くらい突っ込んであるんで、負荷テスト的にもちょうどいいんじゃないでしょうかね。

そういえばかつてブログツールと言えば、RSS、Trackbackとかついているのが普通でしたけど、今更あんなの作る必要あるんでしょうかね。なんか別になくてもいいかなー感。

ソースコードは、 https://github.com/heavymoons/lamblog のdevelopブランチに公開しています。ドキュメントは全然まとめていないし、周辺ツール類もまだ作りかけなんで、私以外がセットアップするのはかなり難易度が高いとは思いますが。

Published At2019-12-31 01:07Updated At2020-01-01 03:44

日記
転職しました 2018Edit

2月1日付で転職しました。

前職はソシャゲ屋さんで4年ほどマネージメント成分多めのエンジニアをやっていましたが、

  • ゲーム系の技術ばかりやっていると、Web/アプリ系技術に触る機会が少なすぎて、技術的なトレンドの(私にとっての)メインストリームに疎くなる
  • 会社が大きくなるにつれマネージメントの比重が重くなり、ますます現場レベルでの技術に疎くなる
  • ソシャゲ的なお客さんとの向き合い方、コンテンツの作り方がどうもしっくりこない
というあたりに行き詰まりを感じていました。

ゲーム系の技術もそれなりに面白くはあるんですけど、ゲーム系の技術はやはりフロントエンド寄りのほうが華という感じで、バックエンド方向への興味が強い私にとっては、それだけで満足という感じにはならなかったんですよね。

で、やっぱり自分の志向としては、マネージャーよりもエンジニアのほうが好みだし、ゲーム系よりもWeb系だよなーということで、現場レベルのWeb系技術をやらせてくれるところを探していたところ、roomclipというサービスをやっているTunnel株式会社に声をかけてもらい、そちらでお世話になることになりました。

もういい年齢でこういう志向の人間を雇ってくれるというのは、なかなか懐の深い会社だと思います。エンジニア35歳定年説? なにそれおいしいの?

そっち方面に転職するのにあたって、あんまりWeb系へのブランクが大きすぎるとまずいかなーと思い、転職前にリハビリがてらFirebaseを使ってtwEssayというサービスを作ってみたりしたんですが、Web系フロントエンド技術からずいぶん離れていたため、mBaas+Vue.jsで開発するのになかなか手間取り、結局作りかけのまま時間切れになってしまいました。

本当は、今は亡き日記猿人(才人)テキスト庵みたいな日記/雑文サイトのコミュニティをTwitterベースで再現する、みたいな感じのものを作ってみたかったんですけど、データ設計的にもコミュニティ設計的にも行き詰まってしまいました。

というわけで、twEssayは単に長文テキストを画像化してTwitterに投稿するだけのサービスになってしまっています。

そのうちモチベーションが上がったら続きを作りたいところですが、業務で色々覚えたり慣れたりしなければならないことが多く、しばらくの間は技術的な興味はそちらで充足してしまう気もするので、手をつける気になるのは大分先のことになるでしょう。

でもFirebaseならば維持費もほとんどかけずに放置できるのがいいですね。一昔前ならばサーバー維持費もおもりをする手間もかけなければならなかったのに、Firebaseならば低コストで維持しておけるし、まかり間違って流行ったところで勝手にスケールしてくれるはず。

レンタルサーバー→自宅サーバー→個人向け専用サーバー→VPS→クラウドサーバー→○aasと、個人でWeb系サービスを立ち上げる環境もずいぶんと変わってきたものですなー。

なんかインターネット老人会濃度が高い。

久しぶりのブログで発散気味なので、これにて終了。今後はちょっとは発信頻度が高い感じになるといいな。

Published At2018-02-12 01:00Updated At2018-02-12 01:00

日記
1470.netをまとめサイト化Edit

ドメイン売らないかメールが来たのをみて、放置していた1470.netドメインのことを思い出し、最近仕事以外ほとんど何もしない状態が続いているんで、twe-tdからネタを抽出して一言コメントをつける形のまとめブログを始めてみました。

ゆるいネットの話題を追う作業を習慣化して、オンラインリハビリします。

Published At2015-05-16 19:49Updated At2015-05-16 19:49

日記
あけましておめでとうございますEdit

去年の4月に、SIer風何でも屋からオンラインゲーム制作会社に転職し、初めての正月を迎えました。

開発部門を社内に持たずにやってきた会社に、新しく社内で完結した開発体制を構築するため、技術基盤整備と人員確保にばたばたしつつ、合間に開発業務を行っているうちに過ぎ去った半年ちょっと。

ネット徘徊やブログ書きなどもろくにやれませんでしたが、ようやく人員も八割方確保できたので、今年はもうちょっと余力がある感じでやれるんじゃないでしょうか(でもまだ人材募集中です)。

もともと、SIer系のお仕事では使うことができなかった、最新技術を実践できることを期待して転職したんですが、やっぱりオンラインゲーム関係はその辺りの技術が使いやすくていいですね。

前職の頃は、業務ではできない最新技術もろもろは、個人の趣味の範囲でいろいろ試してみたりしていたんですが、数十台規模のサーバーを使ったあれこれなどはなかなか実践できませんでした。

また、個人でやっているサービスではアクセス数なども知れていますし、ユーザーのバリエーションやリアクションもあまり期待できません。

一方オンラインゲームでは、アクセス集中時の負荷は個人でやっているサービスとは比べものにならず、かつては技術要素だけは試してみたことがある各種負荷分散対策を、実践でいろいろ試すことができました。

また、ユーザーのバリエーションやリアクションも多いので、それらに対しての事前準備や事後対応、それらを行うための環境整備など、技術的な課題としてやりがいのあるあれこれを実践することができました。

といった感じで、あれこれブログに書いても良さそうなネタは転がっていたんです。

しかし、ゴミが多すぎてGoogle様を使ってもまともな記事を見つけるのが困難な昨今、中途半端なゴミ記事を追加するのも気が引けるし、かといってそれなりのクオリティの記事を書くほどのモチベーションもない。

特に、技術的な記事の内容が現状に即しているかどうか識別することが難しい状況が多すぎるので、そろそろGoogle様は記事の内容の鮮度を明示する仕組みを導入するべきじゃないでしょうか。更新日時ベースだとコピーブログにやられちゃうから、ちゃんと内容を見る仕組みが必要だよね。あと、技術系ブログはできるだけ記事執筆日時を目立つようにレイアウトしておいてくれると助かりますよ。

とか昔同じようなことを書いた記憶があるな。もう7年まえから状況変わってないのか。

転職する前に最後の個人サービスとして作ったtwe-tdですが、ほぼノーメンテで済ますつもりが、集計結果テーブルだから大丈夫だと思っていたら、1年も持たずにint(11)があふれてしまいbigintでprimary keyを付け直す羽目になりました。やはりTwitterのデータ流速はなめちゃいけません。

今年はほとんど巡回することもないまま、いつの間にか存亡の危機を迎えて乗り越えたらしいLivedoor Reader改めLive Dwango Readerを久しぶりに使おうかと思い、ついでに更新が途絶えた登録フィード群を整理していったところ、ブログ系フィードが半分くらいに減りましたよ。

面倒くさいので,自動移転に対応していない引っ越しをした人は追わなかった(ブログ系サービスはフィードの301 redirectに対応するべき)のですが、オンラインから姿を消した人もたくさんいるんでしょうね。逆に、昔と全く変わらない感じで活動し続けている人達も見かけて感心。

Ruby界隈は息が長い人が多いのはtDiaryのおかげでしょうかねー。「日記」は続けやすいけど「ブログ」は続けにくいしねー。あと今ではTwitterが個人が持つ日記的なコンテンツを吸収しちゃうあたりも、ブログを続けることを難しくしている。

遙か昔のWeb日記界隈の人で生き残っている人って、どれくらいいるんでしょうね。日記猿人とか各種アンテナ群にかつて登録されていた方々の、現在の動向をまとめたページとかないかな。ネットストーカー度が高いコンテンツだけど。

今年もプロテニス観戦はまめにやってました。錦織人気がすごくなると天邪鬼が出てブログとかに書く気になれない感じですが。自分でプレイする方のテニスは頻度が1/3くらいに落ちてだいぶぐだぐだです。身体能力がた落ちです。F1は遂に一戦もちゃんと見ませんでした。まあフジテレビNEXTは解約しちゃってたんで、もともとライブでは見られなかったんだけど。motoGPの方がよほどちゃんと見たかも。

BUFFALOのゼン録は2回の故障交換を乗り越えた後1年間もったんですが、年末差し迫った頃にまたエラーで停止していたので、パナソニックのBXT970買っちゃいましたよ。一週間全録から一ヶ月全録にステップアップですよ。一ヶ月だとそう簡単に消えないんで、前よりもテレビを見る頻度は逆に落ちちゃいました。

紙の本を買うのをほぼ辞めました。今家にある本もほとんど全部処分して、欲しかったらデジタルで買い直すことにしました。今度ブックオフを呼んでまとめて処分します。今まで紙で買っていた本も、ほとんどがデジタルで続きを買えるようになってくれたのですが、たいてい紙より発売が遅れることと、ごく少数いまだにデジタル化しない出版社(あるいは作者)があるのが腹立たしいです。

思いつきがだいぶ発散しているので、そろそろおわります。今年もよろしくお願いします。

Published At2015-01-04 19:38Updated At2015-01-04 19:38

技術日記
Twe-td client for iPhoneを作ったEdit

というか、作ったのはTwe-td client for Androidよりも前なんだけど、ようやく公開されたんで。

機能としてはAndroid版とほぼ同じで、画面左右端あたりをタップするとアイテムの前後移動。画面下にある言語とタイプの左右の「<」「>」をタップすると、言語やタイプが切り替わる。画面右上にあるゴミ箱をタップするとそのアイテムが非表示になる。

Web版だと過去の日付を指定して、「○○語で○月×日に話題になった○○」とかを見ることができるけれども、アプリ版は「○○語で現在話題になっている○○」しか見ることができない。

単にユーザーインターフェースをシンプルにするために、それだけに機能を絞っているだけで、作れば簡単に作れるんだけど。

ところで、Android版にもiOS版にもGoogle Analyticsのアプリ版を仕込んでいるんだけど、プラットフォームごとにGoogle Analyticsのプロパティをそれぞれ別に設定してある。けど、同じアプリの別プラットフォームバージョンを作る場合って、別プラットフォームでも同じプロパティIDを使うのが普通なのかな?

せっかくGoogle Analyticsがその辺を識別して集計してくれるのに、わざわざ別IDに分けてしまうのはアホらしい気がする。と、公開されてから思った。

それにしても、Androidアプリの公開までのスピード感と比べると、iOSアプリのスピード感のなさは、自分で軽量の(作成に一週間もかからない)アプリを作るときには、致命的なくらいきついな。

Androidアプリは実験的なWebサービスを公開するのと大して変わらないスピード感でいけるけど、iOSアプリの10日近いタイムラグは、公開されるまで待っている間に、次のバージョンを開発するモチベーションがなくなるくらいだ。

こんなに間が空くと、既存のアプリをアップデートするよりも、別の新しいアプリを作ったほうがましな気分になってしまう。

Published At2014-03-18 10:53Updated At2014-03-18 10:53

技術日記
Twe-td client for Androidを作ったEdit

Twe-td(http://twe-td.net/)のAndroidクライアントアプリを作りました。Google Play Storeからダウンロードできます。

howto

機能としては単純で、起動すると前回表示した言語/種類の最初のアイテムが表示されます。画面左右の端にある「<」「>」で表示するアイテムを前後に切り替えることができます(「<」「>」が表示されている部分だけでなく、画面端のほぼ全体でタッチに反応します)。

画面下側にある「Engilish」「Tweets」の部分が、現在表示しているアイテムの「言語」「種類」の設定で、その左右にある「<」「>」で切り替えることができます。種類は「Tweets(ツイート)」「Movies(ムービー)」「Pictures(写真)」「Goods(商品)」「All Types(すべてのURL)」が選べます。

スマートフォンでWeb版を表示すると、一度に表示するアイテム的に厳しい端末もあるのですが、アプリ版だと一度に1アイテムずつを素早く切り替えることができるので、たいていの端末で軽快に動作するはず。

iPhone版も1週間くらい前にAppleStoreに申請に出しているんだけど、いまだにWaiting For Reviewのままだなー。iPhone版を作った後に作り始めたAndroid版の方が先に公開されるとは。

Published At2014-03-15 15:37Updated At2020-01-01 04:24

日記
【PC遠隔操作事件】第2回公判傍聴メモ・最初の検察側証人は「ファイルスラック領域」を強調(江川 紹子) - 個人 - Yahoo!ニュースEdit

【PC遠隔操作事件】第2回公判傍聴メモ・最初の検察側証人は「ファイルスラック領域」を強調(江川 紹子) - 個人 - Yahoo!ニュースを読んでの感想をTwitterにいくつか書いたんだけど、なんか端的に書くと中途半端感が否めないんで、もうちょっとちゃんとまとめておく。

警察側の証言の要旨は、『押収したPCを調査した結果、OSレベルで見えるファイルシステムからは、事件に関連する情報はほとんど得られなかったが、HDDのセクターレベルに残された情報からは、事件に関連すると思われる情報がいくつか見つかった。それらは、そのPC上の暗号化された仮想Fドライブにおいて、問題のウイルスを開発した可能性が高い痕跡だった』と言うもの。

この仮想Fドライブの存在に関しては、片山氏も身に覚えがあるが、そこにウイルスのソースコードが置かれていたことには気がつかなかった、と言っている。そして、それらの情報は自分のPCが犯人によって遠隔操作されてできた、偽の証拠だろうと主張している(のだと思う)。

しかし犯人が、氏を犯人に仕立て上げるために偽の証拠を残そうとしたのだとしたら、どうして『暗号化ドライブ』のような『証拠が残りにくい』場所に証拠を残そうとしたのだろう。

暗号化されているため捜査側がそこから証拠を取り出すことは難しいし、実際警察は暗号化ドライブ自体から証拠を取り出すことはできていないようで、OSやプログラム開発環境が非暗号化ドライブ上でテンポラリ的に使用するファイルの痕跡から、暗号化ドライブ上での作業内容を推測している。わざわざ偽の証拠を残そうとしたにしては、あまりにも証拠が弱すぎる。

もちろん『犯人はわざとそういう遠回しな証拠を残したのだろう』という主張もできなくはない。しかし『自分のPC上で開発した痕跡をできるだけ隠そうとした』と考える方が自然だ。このあたりは犯人の能力をどのくらい大きく評価するか、でどちらの説が有力に思えるかが変わってくるだろう。

あるいは『犯人は、自分のPCでウイルスを開発して自分のPC上に痕跡を残すことを恐れて、すべて他人のPC上でウイルスを開発したのだ』という考え方も、あり得るかもしれない。偽の証拠を残そうとしたのではなく、片山氏のPCが犯人のメイン開発環境であった、という主張だ。

その場合は、できるだけ(普段PCを使用している片山氏にも)痕跡が見つからないように、暗号化ドライブ上で開発を行うことも十分にあり得るだろう。

ただその場合、Visual Studioのような比較的重い開発ツールを使って(しかもVisual Studioのインストール自体も犯人がリモートでやった? この辺片山氏はどう主張しているんだろう)、ウイルス関連の様々なプログラムの開発およびテストを、完全に氏のPCの遠隔操作のみで作る、というなかなか難易度が高い作業を犯人が行ったということになる。

また、Visual Studioを平日午前中に使用した形跡が残っていることを考えると、その日片山氏がそのPCで作業していたかどうかはわからないが、普通に会社が営業しているであろう時間帯にも、犯人は遠隔操作でウイルス開発作業を行っていた、という推測されるため、かなり状況の妥当性に無理が出てくる(それとも片山氏も、Visual Studio自体は(C#以外の言語で)使っていたと主張しているのかな?)。

推測も多いし、どちらにしろ決定的な判断基準となるような証拠はないわけだけど、今までマスコミ報道で出てきた怪しげな証拠と比べると、今回の話はとても真っ当な内容で、警察が片山氏を犯人と考えている理由は納得できた。それが裁判で有罪になるくらいの証拠なのかどうかはわからないし、ましてやコンピュータおよびプログラミングについて深い知識がない人間にどこまで通じるのかわからないけど。

あと、「遠隔操作ではファイルスラックのスペースは自由に残せない」というのは、警察が証拠を見つけ出したのはOSのインストールドライブからだと思われるので、遠隔操作するためのリモート接続プログラムは、OS上のアプリケーションやサービスとして動作している以上、遠隔操作している状況下でOSインストールドライブに対してHDDの低レベルアクセスはできないから、ということだと思われる。

chkdiskみたいなHDDへの低レベルアクセスが必要なプログラムを実行しようとすると、いったんWindowsを終了し、オンメモリで動作するDOS互換な環境で起動し直してから、そこで実行されるよね。あんな感じ。

Published At2014-03-11 22:10Updated At2014-03-11 22:10

技術日記
Twe-td - what is tweeted in the world ? -を作りました。会社を辞めましたEdit

Twe-td(ツイーティド) [http://twe-td.net]というサービスを作りました。

これは何かというと、Twitter上でつぶやかれているツイートに含まれるURLを収集・解析し、世界中でどんなWebサイト、ツイート、ムービー、写真、グッズなどの話題が注目を集めているのかを、シンプルなインターフェースでみることができるサービスです。

「世界中で」というところがポイントで、Twe-tdでは収集した情報をつぶやかれた「言語」を軸に区分しています。

たとえば、トップページから「Let's go!」で飛んだ先は「表示する種類:ツイート(Tweets)」+「表示する言語:全言語(All languages)」となっており、この記事を執筆している時点では、以下のような内容になっています。

表示する内容は、画面上下にあるナビゲーションから変更することができます。

twe-td-selector

一番左が表示する種類の選択肢で、「All(全種類)」「Tweets(ツイート)」「Movies(ムービー)」「Pictures(写真)」「Goods(グッズ)」から選べます。

真ん中が、対象となる言語の選択肢で「All languages(全言語)」「English(英語)」「Japanese(日本語)」を始め、Twitter上でツイートされている様々な言語が選択できます。一応投稿されているツイートが多い順に並んでいます。

一番右は対象の日付(GMT)となります。データ収集プロセスを動かし始めたのは2014-02-20くらいなのですが、いろいろ試行錯誤があり、まともにデータが取れ始めているのは2014-03-02以降となっています。

たとえば「表示する種類:ツイート(Tweets)」+「表示する言語:日本語(Japanese)」にしてみると、以下のような内容になります。

これをスペイン語(Spanish)のムービー(movies)に変えると、以下のようになります。

「ツイート」などは知らない言語だと内容がさっぱりわかりませんが、「写真」や「ムービー」ならば違う言語でもなんとなくわかるもの。言語圏の違いによって、流行にどのような違いが出てくるのか、わからないなりに眺めていても楽しいものです。

また、もうちょっと情報がたまってきたら、同じ言語でも「何月何日頃にはどういうものが流行っていたっけ?」みたいな探索にも使えるかもしれません。

ちなみに、ツイーター上に流れる大量のツイートから無作為にデータを収集しているため、収集結果にはいわゆる「公序良俗に反するもの」が含まれている場合があります。その場合、各URLのそばに表示されているゴミ箱マークをクリックしてもらえると、そのコンテンツを画面から削除することができます。

この削除行為は運営側にも通知が来るようになっていて、ユーザー削除が多いコンテンツはサーバー側でも削除されますので、やばそうなコンテンツを見かけたらまめに削除していただけると助かります。

「公序良俗に反するもの」の規定は明確に定めていませんが、ひとまずは「日本の法律的にNGなもの」は削除していこうかと思っています。また、「自動生成アカウントによる大量操作」「釣りアプリによる権限奪取を使った大量操作」なども、スパムとして削除対象にするつもりです。

まだ開発し始めたばかりですが、自分で使ってみてなかなか面白そうな感じにできてきつつあるので、興味を持った方は是非使ってみてください。

あと私事ですが、長い間お世話になった株式会社ジョルスを3月一杯で退職することになりました。在職中にお世話になった方々、今までありがとうございました。

Published At2014-03-03 15:55Updated At2020-01-01 04:25

日記
充電しながら使えるBluetoothレシーバー+ケーブルが絡まないイヤフォンEdit

Bluetoothレシーバーのバッテリーが切れるのにうんざりしている人、ポケットとかに適当にしまったイヤフォンを取り出すたびに、いちいち絡まったケーブルをほどくのにうんざりしている人にオススメ。最近買って大当たりだった組み合わせ。

まずは、micro USBケーブルで充電しながら使えて、バッテリー持続時間も8時間程度と長めのBluetoothレシーバー『BTTC-200』。値段も3000円ちょっとと、Bluetoothレシーバーとしてはお安め。

IMG_0106 micro USBで充電しながら使えるBluetoothレシーバー『BTCC-200』[/caption]

私は普段移動しながらiPhone/Androidの音声を、仕事をしながらPC/Macの音声をイヤフォンで聞いている。そうやって一日中音声を聞くとなると、どんなにバッテリー持続時間が長いBluetoothレシーバーでも、短くて4時間、長くて8時間程度でバッテリーが切れてしまう。

しかもたいていのBluetoothレシーバーは、充電しながら使用することはできないので、せっかくBluetoothレシーバー経由で音声を聞いていても、バッテリーが切れるとBluetoothレシーバーを充電器にセットして、iPhoneやPCにイヤフォンを指し直す必要が出てくる。

でもBluetoothレシーバーで音声を聞くのに慣れてしまうと、iPhoneに直接イヤフォンをつないだ状態でのケーブルの取り回しがうざいし、PCなんかだとちょっと席から離れるときなんかに、いちいちイヤフォンを外すのも面倒くさい。Bluetoothレシーバーならばトイレに行くくらいの距離ならば、そのまま音楽を聴き続けることもできるのに。

というわけで、このBluetoothレシーバー『BTTC-200』。これならば普通に使っていても比較的バッテリーの持ちがいい上に、使っている最中にもmicro USBケーブルをつないで充電することができるので、PCで使っているときに時々micro USBケーブルをつないで充電しておけば、バッテリー切れの心配がなくなる。

小さくて軽いのでどんなに小さいポケットに入れても大丈夫。イメージとしてはちょー軽い懐中時計サイズ。

充電しながらの利用は、バッテリーの寿命にあまり良くない影響を与えるという定説があるわけだけど、まあ値段も大して高くはないんで、バッテリーが劣化したら買い直せばいい。

おまけとして、この『BTTC-200』はレシーバーとしての機能だけでなく、トランスミッター(送信機)としての機能も持っている。Bluetooth機能を持たないミニコンポとかのイヤフォン端子にこれをつなぐと、他のBluetoothレシーバーでその音声を受信することができる。バッテリーが劣化してきたら、micro USBケーブルつなぎっぱなしにして、そういう用途で使うのもいいかもしれない。

ずいぶんBluetoothレシーバー『BTTC-200』の紹介が長くなってしまったが、もう一つのオススメ商品は靴ひも風のケーブルを使ったイヤフォン『アルペックス クツヒモコードイヤフォン SLYP』。

ポケットにぐしゃぐしゃに突っ込んでから取り出した状態[/caption]

普段から外出中も仕事中もイヤフォンを使っているんで、常時イヤフォンを持ち歩いていて、普段使っているイヤフォンは使わないときはポケットに突っ込んでしまうことが多い。そうすると、使おうとしてポケットから取り出すと、イヤフォンが絡んでしまっていて、それをほどいてから使わなければならなくなる。

じゃあ、ケーブルが絡まないような、巻き取り式のイヤフォンとかを使えばいいんじゃないか、と思っていくつか買ってみたのだが、どうも巻き取り式イヤフォンは、巻き取り部分の機構がなめらかに動かなかったり、最初のうちはちゃんと動いていても、そのうちだんだん動きがしぶくなっていったり、巻き取りの仕組みのためか普通のイヤフォンよりも断線などの故障率が高い(3、4個使ってみての経験談)など、今ひとつ満足いくものがなかった。

ポケットから取り出した状態からでも、すぐに使える状態に[/caption]

そこで、この『アルペックス クツヒモコードイヤフォン SLYP』。「絡まないようにすることが難しいならば、絡んでもほどきやすくすればいいじゃない(マリー・アントワネット風に)」。

実際、ポケットにぐしゃぐしゃに突っ込んでおいても、ケーブルが太いためか絡んでいることが少ないし、多少絡んでいたとしても、すぐにほどける。これならば使わないときにポケットに突っ込んだり、カバンに突っ込んだりと、気を遣わずにしまっておいても大丈夫。

これをBluetoothレシーバー『BTTC-200』と組み合わせて使うと、いつでもポケットに突っ込んで持ち運び、使いたいときに取り出して接続したいデバイスとリンク、micro USBケーブルが確保できる場所では使いながら充電、といった感じの使い方で、ほぼ充電切れの心配なしに一日中使い続けられる。

というわけで、ここ数年間日常的に微妙なフラストレーションを感じていたBluetooth+イヤフォン関連の問題がすっきり解消されて幸せになれたので、久しぶりに物欲日記を書いてみた。

まだ耐久試験が終わっていないから、それによってある程度評価の上下はあるけれども、Bluetoothレシーバー『BTTC-200』の方は1年程度もってくれれば上等、『アルペックス クツヒモコードイヤフォン SLYP』の方は半年程度もってくれれば十分だ。もちろんそれ以上使えるならそれにこしたことはないけど。

Published At2013-12-18 19:25Updated At2020-01-01 04:31

技術日記Laravel4PHP
LaravelをWindows環境で使うEdit

最近メインマシンをMacbookに移行したんだけど、Laravel4で作ったアプリケーションをWindows環境で動かさなければならない要件があったんで、Windows環境にセットアップして問題ないかどうか試してみた。手元にあるのがほぼまっさらなWindows8.1(on Parallels)だったので、それをベースに。

まずXAMPP for Windows をインストール。今だとXAMPP 1.8.3(Apache 2.4.7/MySQL 5.6.14/PHP 5.5.6)だった。

インストール後、XAMPPコントロールパネルからApacheを起動して、http://localhost/にアクセスできるかどうか確認。

続いてLaravelをcomposerを使ってインストールするために、まずはPHPにパスを通す。コントロールパネルのシステムの詳細設定-環境変数から、システム環境変数のPathにPHPのパス(C:\xampp\php)を追加する。

試しにコマンドプロンプトを起動して、php -iとか実行してちゃんとPHPにパスが通っているかどうかを確認。すでにコマンドプロンプトが起動済みだった場合、環境変数の変更を反映させるためにコマンドプロンプトを再起動。

続いて、composerをインストール。コマンドプロンプトで、

cd C:\xampp\php
php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

を実行してcomposer.pharをダウンロード。これだけだと使い勝手が悪いので、C:\xampp\php内にcomposer.batファイルを作成。内容は、

@echo off if "%PHPBIN%" == "" set PHPBIN=C:\xampp\php\php.exe "%PHPBIN%" "C:\xampp\php\composer.phar" %*

にしておく。これでコマンドプロンプトから、

composer update

みたいな感じでcomposerを実行できる。

でcomposer create-project laravel/laravelしようと思ったら、途中でgitがなくてこけた。gitも必要だったっけ。

Git for Windows(msysgit)をインストール。コマンドプロンプトから使いたいんで、インストールオプションで実行スタイルを選択するところで、「Run Git from the Windows Command Prompt」とか、gitにPathを通してくれるオプションを選択する。

もう一回コマンドプロンプトを再起動。Laravelアプリケーションプロジェクトを作りたいディレクトリを適当に作成する。

mkdir c:\laraveltest
cd c:\laraveltest

あとは、

composer create-project laravel/laravel .

今度はエラーも出ずにプロジェクトの作成に成功。Apacheからこのプロジェクトディレクトリを参照したい場合は、C:\xampp\apache\conf\httpd.confから、

DocumentRoot "C:/xampp/htdocs"
<Directory "C:/xampp/htdocs">

となっている部分を、

DocumentRoot "C:/laraveltest/public"
<Directory "C:/laraveltest/public">

なんて変えてから、Apacheを再起動すると、http://localhost/ で今作ったプロジェクトにアクセスできる。まあC:\xampp\apache\conf\extra\httpd-vhosts.confとC:\Windows\System32\drivers\etc\hostsを使って、バーチャルホストにしておいた方が便利だろうけど。

前にWindows環境でLaravelを動かしたときは、mcryptとかのPHPモジュールを有効にしたり、timezone設定を追加したりとかしないといけなかったような気がするんだけど、今はそういう問題はないんだな。

このくらい手軽に動くなら、ピュアPHPで作れるようなアプリならば、Windows環境でも作りやすそうだ。

Published At2013-12-13 18:16Updated At2019-12-30 15:03