今回は言われました！「ブログを書くまでがYAPC!」 と言うことで、YAPC::Kansai 2017 OSAKA (行ってきたときの記事はこちら )に引き続き、YAPC::Fukuoka 2017 HAKATA に行ってきました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。 福岡および九州は初めてでしたが、いや、暑いですね。 特にYAPCの翌日は非常に天気が良いものの、梅雨の湿気もあり、観光をしていて汗だくでした。 今回も大阪同様ホテルはとらず、適当にやっていくことに。 意外となんとかなるものです。 YAPC::Fukuoka 2017 HAKATA 今回も例に漏れず(?)寝坊でオープニングには間に合わず。 今回はPerl6の話は余り多くなかった印象です。 セキュリティの話、コンテナの話、テストの話など、非常に多様なセッションがありました。 今回のノベルティはなぜかモバイルバッテリーが二つも入っていたり、米が入っていたり、染み抜きペンが入っていたりととても面白い内容でした。 あ、いつものサイリュームも入ってましたよ。 個人スポンサーノベルティはビーチサンダル。これからの季節に良いですね。 LTをしてきました。 今回はLTもしてきました。 タイトルは「嗚呼素晴らしきemacs 」です。 ベストトーク賞 YAPCでは恒例のベストトーク賞ですが、今回は徳丸さんのゲストセッションがベストトーク賞に選ばれました。 しかしご多忙な徳丸さん。クロージングの時点ですでに帰還してしまってました。 仕方ないので徳丸さんの会社にお勤めの方が代理で受け取ることに。 なんと賞品を渡す人は徳丸さんのセッションを聞いていなかったようで・・・ ベストトークを聞いていなかった人が代理の人に賞品を渡すという、なんとも面白い事態でした。 ベストLT賞は@codehex さんで、YAPC::Okinawaの宣伝でした。 懇親会 懇親会ではPixivさんから抽選でプレゼントをいただきました。 Pawooのロゴ入りのモバイルバッテリー(これで今回三つ目)です。 次回のお話 次回YAPCは3月に沖縄で開催予定です。

Open Source Summit Fujitsu Museum Tour )で、富士通 沼津工場まで行って、現在動作する世界最古のコンピュータであるリレーコンピュータ「FACOM128B」を見てきました。 Fujitsu FACOM128B は1958年に作られたリレー式自動計算機で、富士通沼津工場に置かれているものは1959年製です。Fujitsu Webサイト から申し込みをすることで、中学生以上なら見学することができます。 圧巻です。エンジニアなら一度は見ておくと、感動ものです。

twitterのクライアントとして、日頃からemacs上で動くクライアントの"twittering-mode"を使用しています。 ところが最近、新しいmacにインストールしたemacs-macでtwittering-modeを起動すると、毎回twitterのPINを聞かれるようになってしまいました。 毎回、毎回、起動時の暗号化フェーズで Encrypt failed Exit と言われ・・・・ 以前使っていたmacではこのようなことが無かったため、困っていたのですが、以下の手順により解決できました。 背景 結論から言うと、これはGnuPGのバージョンが新しくなったことによる問題でした。 GnuPG2.1.0から、gpg-agentとpinentryと呼ばれる二つのソフトウェアの利用が必須となりました。 twittering-mode事態はgpg-agentやpinentryが必須でも基本的に問題なく動作するようにはなっているハズ・・・でした。 しかし、これらのソフトウェアの必須化に伴って、これまで標準入力から入力できていたパスフレーズが標準入力から入力できなくなっており、そのために暗号化に失敗して毎回PINを聞く・・・という状態になっていたようです。 解決策 みんな大好きarch wiki に解決策がありました。 まず、~/.gnupg/gpg-agent.confに以下のように記述します。 allow-loopback-pinentry つぎに、~/.gnupg/gpg.confに以下のように記述します。 pinentry-mode loopback 最後に、gpg-agentを再起動します。 コマンドラインから、 1 $ gpgconf --kill gpg-agent でgpg-agentを再起動できます。 以上で、twittering-modeが正常に使用できるようになるはずです。

MySQLをdocker上に立てることで、ローカルの環境を汚さずにMySQLを使ったアプリケーションの開発を行うことができます。 特に、練習段階や、動作確認などの場合、 test_hogehoge な感じのデータベースやテーブルを作ってしまい、後片付けをしないために汚くなっていく、なんてこと、あるんじゃないでしょうか。 さて、MySQL on dockerへの接続、今までローカルにMySQLを入れて開発していたのでちょっと躓きました。 1 $ docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD password mysql:latest 上記のように起動した場合、次のようにコマンドを実行することで接続することができます。 1 $ mysql -u hoge -p -h 127.0.0.1 --port 3306 特にポイントなのが、-h 127.0.0.1の部分。localhostにしてしまうと、socketで接続しようとして、エラーになっちゃうんですね。 ここでしばらく悩みました。。。 以上、簡単ですがメモがてら。

golangでベーシック認証するのはどうしたら良いのかなー。って思ってたら、net/httpでhandlerに渡されるhttp.RequestにBasicAuth()というメソッドが生えてました。 これはBASIC認証用のユーザ名、パスワード、ヘッダ解析のフラグという値を返してくれます。 なので、 1 2 3 4 5 6 7 8 9 func handler(w http.ResponseWriter, r *http.Request) { username, password, ok := r.BasicAuth() if !ok { return } if username == "hogehogeuser" && password == "fugafugapasswd" { // something } } とすることで認証することができます。簡単、簡単。 なお残念ながらダイジェスト認証はサポートされていない様子。

12月のYAPC::Hokkaido 2016 SAPPORO (行ってきた時の記事はこちら )に引き続き、YAPC::Kansai 2017 OSAKA に行ってきました。 今回もブログを書くまでがYAPCとは言われなかった気がします。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。 私にとって、大阪はもちろん、関西自体が初めてで、かなり余裕のあるスケジュールを組んだために、どう時間を過ごしていいか悩むといった自体に。 空港に降り立ち、まずどうしよう、という状態ですね。困った。 仕方がないので大阪出身の友人に、「大阪観光ってどこいったらいいのかな」と聞いてみたのですが、「まぁたこ焼き食べたりしたら？」と今ひとつ役に立たない返事。まぁ食べますけど！ それでも心斎橋とか難波に向かうとよいと教えてもらえたので、Googleマップ先生に頼りつつ、難波へ向かいました。 結果、何をしたかというと、札幌からの移動前に新しく購入したスマホ用のあれこれをビックカメラで購入するという、大阪まできて何をやっているのかというなんとも残念な行動となってしまいました。 ホテル探し 今回、北海道から関西まで、勿論飛行機で移動したわけですが、実はホテルも取らずに(!)、YAPC以外は無計画での旅行でした。 とりあえずYAPC前日くらいはホテルに泊まらねば朝起きれない！ということで、ホテル探しをしました。 運良く会場(MOTEX ホール )の近くに割と安く宿を取ることができました。 こちらがそのお部屋の写真。シングルの部屋を5,500円(500ポイント適用後)でとったのですが、入ってみてびっくり、ツインの部屋でした。 安かったものの、なんとなく豪勢な感じ。 夜ご飯は近くのお店でたこ焼きを食べました。 十八番というお店で、後で調べたら結構有名っぽいですね。美味しかった。 たこ焼きを塩で食べるというのは初体験でしたが、これもなかなかです。 YAPC::Kansai 2017 OSAKA 開けて翌日。微妙に寝坊したおかげでオープニングには間に合いませんでした。 一番印象に残ったトークは「Vue.jsで作るSPAから学ぶMVVM、非同期処理、その光と影」ですね。 タイトルにVue.jsと入っているにもかかわらず、Vue.jsという言葉が出て来たのは一度きり、SPAの話のはずなのに、「SPAはやめよう」と、なんだかタイトルに釣られた感が半端ない内容でした。 勿論内容も素晴らしく、「ブラウザはドキュメントビューアなんだからリッチなインターフェースを作るものではない」「ブラウザでリッチなインターフェースを作るのはなんでもVimでなんとかしようとするようなもの」「とはいっても作らなきゃいけない時もある」という、SPAはやるべきじゃないけど、現状やらなきゃいけないことはどうすれば良いのか、その時MV*はどのように構成したらいいのかといった、きちんと筋が通っていて、とても面白い話でした。 次に印象に残っているのが、「Webアプリケーションのキャッシュ戦略とそのパターン」です。 こちらも「キャッシュは使わないほうがいい」という、タイトル詐欺みたいな話でしたが、非常に納得のいく内容でした。 ベストトーク賞の投票で票を入れたのは「Webエンジニアに知ってほしいRDBアンチパターン」です。 内容もさることながら、やはり喋りが素晴らしいんです。とっても練習をしていると聞いています。 ランチタイムはスポンサー企業の方と昼食をいただきました。 今回交通費支援をいただいたので、その対価のようなものです。 実際には、企業に関わるお話は結局あまりしなかったのですが、会場の近くはあまり飲食店がない印象で、昼食を取るのも大変そうでしたので、大変助かりました。 YAPC::Kansai 2017 OSAKAのステッカーはこんな感じ。 札幌の時のものと並べてはるには、上下を揃えるのが難しい形状で、ちょっと難儀します。 次回のお話 次回YAPCは福岡で開催だそうです。YAPC::Fukuoka 2017 HAKATA すでにチケットも発売されています。 その後は沖縄、東京が企画されているそうです。 是非回りたい。

NoSQLを使うことも一般的になってきた昨今ですが、NoSQLの一種に、時系列データベース (Time Series Database; TSDB)と呼ばれるものが有ります。 TSDBはその名のとおり、時系列データを取り扱うことに特化したDBです。 サーバ監視したログデータや、センサデータなんかを取り扱うことが得意なDBということですね。 そのうち、DB-ENGINES のDB-Engines Ranking of Time Series DBMS で一位を取っているInfluxDBを触ってみました。 InfluxDBの公式ドキュメントはInfluxData | Documentation | InfluxDB Version 1.2 Documentation にあります。 参考にした資料・実行環境 今回はQiita/DockerのInfluxDBとGrafanaでdweet.ioのデータを可視化する の前半を参考に、Docker上でInfluxDBを実行してみました。 なお、上記の記事中では、tutum/influxdbというイメージを使用していますが、現在はInfluxDBオフィシャルのイメージが提供されていますので、そちらを利用します。 最新の安定版を利用しますので、InfluxDBのバージョンは1.2.0です。 InfluxDBコンテナを起動する 早速InfluxDBコンテナを起動してみます。 1 2 $ docker pull influxdb $ docker run --name influxdb_test -p 8083:8083 -p 8086:8086 influxdb これだけです。簡単ですね。Exposeしているポートの中身は以下のようになっています。 8083: Admin Web インターフェース 8086: HTTP API Admin UIにアクセスする Admin UIにアクセスしてみます。 InfluxDBにはWebアクセスできるUIがついています。 まずはコンテナのIPを調べてみましょう。 1 $ docker inspect influxdb_test HostConfig > NetworkSettings > Networks > bridge > IPAddress にコンテナのIPが記載されています。 今回は172.17.0.2だったとして進めます。 ...

Python 3でbottle-websocket がそのままでは動かなかったので簡単にメモしておきます。 解決方法 通常通りpip install bottle-websocketしてから、 pip install karellen-geventwsすると動作するようになります。 karellen-geventwsはGeventWebSocketのforkで、Python 3に対応しています。

この記事はIT勉強会/コミュニティ運営 Advent Calendar 2016 に寄せて書いた記事です。 執筆者は@nasa9084 です。 前日の記事は一般社団法人LOCALさんの一般社団法人LOCAL のご紹介 でした。 まずはじめに あまりネット上、特にブログで自己紹介をする機会というのは多くなく、このブログ単体で言うならば、とある理由があって以前書いていたブログから移行してきたばかりなので、自己紹介というものをすこしはしているのですが、折角の機会でもあるので、ある程度きちんと自己紹介から始めさせていただくこととします。 どうもこんにちはnasa9084 といいます。 現在試される大地であるところの北海道は札幌市に住んでいる大学生(0x17歳)です。 来春4月から、東京で就職予定ですが、卒業論文の進捗が芳しくありません。 PyCon JP というカンファレンスのスタッフをしたりしています。 「でじぽろ」という勉強会 昨年のから今年の10月まで、札幌ででじぽろ という勉強会を主催していました。 でじぽろはIT技術初心者、もう少し具体的に言うと UNIX/Linuxに興味がある/使ったことがある プログラミングに興味がある/すこしやったことがある といったレベルの方を対象として月に一回開催していた勉強会です。 私と、@chamaharun の二人で主催をしていて、内容としては HTTP入門 SQL入門 プログラミング言語大横断 Linuxディストリビューションの紹介 なんかをやったりしていました。 勉強会を開催するということ 扨、少しばかり前置きが長くなってしまいましたが、そろそろ本題であるところの運営に関する部分の話をしなきゃいけないですね。 今回はIT勉強会/コミュニティ運営 Advent Calendar ですから、多くの大事なところは他の大人な方々が書いてくれてますので、今日は私が特に気をつけたほうがいいと思っていることだったり、おすすめの方法論だったりについて書きましょう。 持ち出しはしない 勉強会を継続的に運営するにあたり、主催者やスタッフの財布からお金が出ていくことは避けたほうがよいと思います。 楽しいことがしたいと思って始める(であろう)勉強会ですが、事前準備や当日の運営、終わったあとの処理など、結構な時間や労力がかかります。これは大きな負担で、この上開催にお金がかかるとなると、金額が大したことない額だったとしても、継続するのは心理的に困難になるでしょう。 せっかく立ち上がった勉強会も、「主催のお金がないので継続開催できません」では悲しいものがあります。 初回開催など、立て替える必要がある場面はあると思いますが、開催後にでも精算を行って、主催者・スタッフのマイナスが無いようにしたほうがよいです。 自分に強制する、という選択肢 多くのコミュニティ運営者は、「勉強会やコミュニティの運営は仕事ではないので、開催しなければならないという意識を持って開催するのはつらいからやめたほうがいい」と言っている様に思います。 わたしも多くの部分で賛成ですが、個人の性格だったり、勉強会の目的次第では、「強制的に開催する」という選択肢もある、と覚えておいてください。 私が主催していたでじぽろの目的の一つに、「主催も勉強する」というものがあります。初心者向けなんて謳っているけれど、主催も学生だから、一緒に勉強していきましょう！ということです。 加えて、主催である私も、@chamaharun も、比較的怠惰な性格をしています。 そこで、でじぽろ運営にあたって、一つルールを決めました。 それが、「つらくても、話すネタがなくても、とにかく月に一回開催する」というルールです。 不定期開催というのは、心理的負担も減りますが、それと同時に、気づいたら二回目の開催がないまま時間だけが過ぎていた、なんてことになりやすい開催方式でもあります。 定期的に開催することを自分に義務付けることで、勉強会を開催することが習慣になります。 継続開催を目標の一つとする場合、この選択は大きな助けともなってくれることと思います。 でじぽろは、このルールのおかげで、一年間毎月開催することができたと思っています。 あまり深く考えない 勉強会を主催するということは、実はそれほどハードルの高いことではありません。「とりあえず気が向いたからはじめてみた」くらいの気持ちで十分です。 でじぽろも、はじめは友人との呑みの席で、「なんか勉強会とかやってみたいよね」で始まったのでした。 皆言ってることでは有りますが、仕事ではないのです。辛かったり、つまらなかったらやめていいんです。 そして、気が向いたらまた新しく始めてみたらいいと思いますよ。 懇親会をする 個人的にこれはとても重要なことだと思っているのですが、懇親会はぜひやったほうがいいと思います。4日のエンジニアコミュニティのつくりかた でも書かれていましたが、懇親会が本編だと考えています。 多くの場合、勉強会で発表されることは、今の御時世ですから、検索したら出てきます。わざわざオフラインで集まってスクリーンの前で発表なんて聞かなくてもいいんです。 それでもやっぱり勉強会/コミュニティに集まるというのは、人と人との出会いが重要だからだと思います。 そして、発表のときというのは、座っているうち8割9割の人は質問もしないですし、発表後に発表者に挨拶に行ったりもしません。 これでは、休みの日に、わざわざ集まっている意味は無いと思います。 懇親会を開催することで、大勢の前の発表では言えないことだったり、発表するほどでは無いけど趣味で触っている新技術の話だったり、そういったものに大きな意味が有ります。twitterやfacebookでつながりを持つことに意味があるんです。 「学生が」勉強会を運営するということ 扨、それなりの量を書いた(気になっている)のですが、他の記事を書いている方々は皆さん大人(学生ではない)の方々ですね。 ココで一つ、「学生が勉強会を運営すること」のメリットを考えてみます。 ...

この記事はEmacs Advent Calendar 2016 の、13日目の記事で、執筆者は @nasa9084 です。 前日はfujimisakariさんのプログラミングに役立つelisp10選 でした。 org記法でブログを書きたい 全国のEmacsユーザの皆さん、org-modeは使っていますか？私は使っています。 普段Pythonを書く私にとって、#はコメントアウトのイメージで、#を見出しに使うmarkdownは(ダメってほどじゃないですけど)なんとなく好きになれません。Emacsユーザということもあり、細かいメモを取るときや、スライドを作るときはorg-modeを使っています。 そんなわけで、慣れ親しんだorg記法。ブログを書くときも使いたいと考えました。 しかし、マークダウンで書くことができるブログや、或いはorgで書いたものをwordpressにアップすることができるelispなんかも有りましたが、どうもしっくり来ません。 そんな折に運用していたWordPressが使えなくなり、このブログシステムを作りました。 Pythonで使えるorg記法パーサも探したのですが、どれもブログで使えるようなものではなく、自分で変換機構も作成することにしました。 最初はブログシステムの中にorgをHTMLに変換するフィルターを作ればいいかな、と思って書き出したのですが、コレがなかなかうまく行かず。最終的にパーサとしてパッケージ化したので、そのお話をさせていただこうと思います。 正規表現の置換だけで実装してみた org記法を使いたいとは言っても、ブログ記事を書くのに使いたいだけなので、チェックボックスや時間に関する部分など、org-modeの大部分は必要ありません。文字の装飾部や見出し、リストが実装されれば十分です。 ですので、最初はわざわざ構文木などを作らずとも、単純に正規表現で置換すればいいのではと考えて実装を始めました。 しかしコレが大きな間違いだったのです。 リスト 問題の１つめは、ネストしたリストを使えないことでした。 単純に正規表現で行ごとに置換していく都合上、ネストしたリストを解析することができません。この段階で、ネストしたリストは使わないことにしよう、と考えました。 しかし、実際に実装してみてわかったのですが(気づくのが遅い)、問題はそれだけではありませんでした。 リストが始まったことや終わったことを判断できないのです。いま置換している行はリストの始めなのか(つまり<ul>が必要なのか)、真ん中なのか、終わりなのか、判断することができないのです。これは困りました。 スラッシュ 更に大きな問題が潜んでいました。斜体とリンクです。 ご存知のように、URLは区切り文字としてスラッシュを多用します。また、org-modeでは斜体をスラッシュで挟んだ形で表します。 このせいで、URLの一部が斜体としてマークアップされてしまう事態が発生しました。 これはちょっと困ったものです。とりあえず斜体を使わないこととしましたが、これには不満が残ります。 結局パーサとしてパッケージ化 更に、テーブルの実装ができないなど、org記法が使える！というには不満点が多すぎました。 そんなわけで、改めて外部モジュールとして、org記法のパーサを書きました。org記法で書かれたテキストを読み込み、解析し、抽象構文木を生成します。そこからHTMLを出力することも可能です。GitHub上でソースも公開しています(nasa9084/py-org )。 コレをブログシステムに組み込むことでorgでブログを書くことができるという寸法です。 また、当初予定してはいなかったのですが、gitのsubmoduleで管理するのはバージョンアップの際などいろいろと面倒なので、パッケージ化してPyPIへとアップしました(pyorg )。 現在はバージョン0.1.3として、見出し、リスト、テーブル、リンク、画像、引用、文字の強調を実装済みです。今後、少しずつ拡張予定ですが、当面はリファクタリングを進めようと思っています。 以上、pyorgのお話でした。