Advent Calendar

本記事はGo2 Advent Calendar の20日目の記事です。昨日はyaegashiさんによる、jsonx.go でした。 皆さんはOpenAPI Specification というモノをご存じでしょうか。OpenAPI SpecificationはJSONまたはYAMLでREST APIを表現するための仕様で、現在バージョン3.0.2 が最新です。いわゆるSwagger の後継で、バージョン1系、2系がSwagger、3系以降がOpenAPI、ということになっています(Swaggerなら聞いたことがある/使っているという人も多いのではないでしょうか)。 OpenAPI Specificationは人間にも機械にも(比較的)読みやすい仕様書として、コード生成や、ドキュメントページの生成に使用することが可能です。 個人的には専らコード生成に使用しており、Go言語向けの実装としてgithub.com/nasa9084/go-openapi (以下go-openapi)を実装・公開しています。 go-openapiは2017年ごろから細々と実装を続けており、(多分)二番目か三番目には古いと思われるOpenAPIのGo実装です。 基本的にはただひたすらOpenAPIのオブジェクトをGoの構造体として定義、値のバリデーション関数を用意しているといったもので、特別な機能はほとんどありません。 YAMLのパーサも、go-yaml/yaml を使用しており、自前では実装していません。 そんな中、@goccy さんが、encoding/jsonとコンパチなインターフェースを持ったYAMLパーサを開発した、という話を耳にし、これを機に、とgo-openapiの実装を一から書き直し始めました。 もともと、パースは完全にgo-yaml/yamlに依存しており、Unmarshal系のメソッドも実装していなかった(途中から全部書くのはつらかったので・・・)ため、一部バリデーションに必要な関数を埋め込んだりもできなかったので、書き直したいとは思っていたのです。 現時点ではまだマージしておらず 、書いている途中なのですが、大きな変更点として次の様なものがあります。 もともとパブリックだったフィールドをすべてプライベートに変更し、ゲッターをはやした 各構造体に対応するUnmarshalYAML()メソッドをすべてコード生成するようにした YAMLパーサはgithub.com/goccy/go-yaml に乗り換えた rootオブジェクトを各構造体に埋め込むことで、バリデーションをとりやすくした 今後はよりコード生成に便利なメソッドを追加していきたいと思っています。 時間の都合で今日はここまで。技術的な話が全然無い記事になってしまった・・・

tl;dr .gitconfigにもaliasの登録ができる [alias]ブロックにaliasを登録する tagsで単数・複数の悩みを解消する discardで変更を取り消す unstageでaddを取り消す uncommitでcommitを取り消す ignoreで.gitignoreを生成する git aliases この記事は今すぐalias登録すべきワンライナー by ゆめみ① Advent Calendar 2018 の6日目の穴埋め記事です。 こちらのアドベントカレンダーは今すぐalias登録べきワンライナーということで、みなさん.bashrcや.zshrcのaliasについて記事を書いてらっしゃいますが、実は.gitconfigという、gitコマンドの設定を書いておくファイルにもaliasの指定ができます。 誰もshellのaliasとは言ってない！(・・・はず)ので、いくつか.gitconfig用に便利なaliasを紹介していきましょう aliasの登録方法 .gitconfigは基本的にiniファイルです。そのため、次のように登録します。 1 2 3 [alias] aliasname1 = some command 1st aliasname2 = some command 2nd 簡単ですね？ [alias]というブロックを作成し、alias名=コマンドの形で記述します。 このときコマンドはgit xxxの形で実行される、xxxの部分のみを指定します。 例えば、 1 2 [alias] stat = git status と指定すると実際の実行時にはgit git statusという形で実行されてしまいエラーになるので注意しましょう。 gitのつかないコマンドを実行したい場合は頭に!をつけます。 1 2 [alias] ls = !ls このように記載すると、git lsでlsが実行されます。 git tags git tagというコマンドがありまして。まぁみなさんご存知でしょうが、tagの一覧を出したり、新しいtagを作ったりするコマンドです。これ単体では特に問題がないのですが、リモートリポジトリと合わせて使うと、ちょっと悩みが発生します。 git tagコマンドでタグをつけた後、リモートリポジトリにpushするときのコマンドはgit push --tagsです。これはtagをまとめてpushするので、複数形なんでしょう。しかしです。tagの一覧を出すときに使うのもgit tagと単数形なんですね。 ついついgit tagsと打ってしまいませんか？ そんなあなたはこんなaliasを登録しておきましょう 1 2 [alias] tags = tag 地味ですが、これで単数形か複数形か悩まずに済みます。 ...

この記事はGo2 Advent Calendar 2017 13日目の記事です。 昨日は@kami_zh さんの Goで標準出力をキャプチャするパッケージを書いた でした。 go-sqlrow Go言語で標準パッケージを使用してRDBMSからデータを取ってくるには、以下の様に書きます1。 1 2 3 4 5 6 7 8 9 type Person struct { ID string Name string } db, _ := sql.Open("dn", "dsn") row, _ := db.Query(`SELECT id, name FROM person where id='foo'`) var p Person row.Scan(&p.ID, &p.Name) SQL文を発行するまではいいのですが、最後の行、sql.Row#Scanがくせ者です。 上記の例のように、sql.row#Scanは可変長個のポインタを引数にとり、それらにそれぞれ値をセットします。この例では値の数が2つのため大きな問題ではありませんが、値の数が増えた場合などは非常に面倒です。また、テーブルの構造が変わった場合なども非常に面倒です。 この問題を解決するため、go-sqlrow という小さなパッケージを作りました2。 これは上記のrow.Scanを代わりにやってくれるパッケージです。 機能・使い方は簡単で、先ほどの例を次の様に書き換えます。 1 2 3 4 5 6 7 8 9 type Person struct { ID string Name string } db, _ := sql.Open("dn", "dsn") row, _ := db.Query(`SELECT id, name FROM person where id='foo'`) var p Person sqlrow.Bind(row, &p) 後は内部でrow.Scan相当の処理を行います。 unexportedなフィールドはencoding/json同様、sql.Rowとの対応がとれませんので、注意が必要です。 エラー処理やトランザクションなどは省略 ↩︎ godoc: https://godoc.org/github.com/nasa9084/go-sqlrow  ↩︎ ...

この記事は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のお話でした。

この記事は、PyCon JP Advent Calendar 5日目へ寄せて書いた記事です。 執筆は@nasa9084 です。 昨日は寺田さんによる、PyCon JPの立ち上げ という記事でした。 Pythonと私の想い出 PyCon JPアドベントカレンダーのテーマは「Pythonと私の想い出」だそうです。 私が初めてまぁそれなりと言える程度にかけるようになったプログラミング言語がPythonでした。 なんどもCに挑戦しては挫折し、を繰り返していたのですが、Pythonのおかげで簡単なプログラムはかけるようになったんでした。 扨、すでに行き先がよくわからなくなってきているこの記事ですが、もう少し私とPythonとの関わりを書いていきましょうかね。 Pythonを使う理由 もともと、私はHTMLから、ソースコードというものをエディタで書く、という世界に入ってきたんです。小学校高学年くらいの頃だったでしょうか。 最初はホームページビルダーでWebサイトを書いていたんですが、当時(今でもあるのかな？)、小学生でも使えるJavaScript集みたいなサイトがありまして、例えば、headタグの直後にコピペするとなんかカーソルにきらきらしたのがくっついてくるようになる、とかですね、今となってはとっても懐かしい感じのものがたくさんあったわけですよ。 そんなのをコピペするために、ホームページビルダーでソースコードビュー的なものを開きまして、コピペをしていたわけですね。 HTMLなんてまだまだ書けなかった私ですが、なんとなくルールがわかるんですね。そうすると、なんだか無駄っぽいのがあるわけですよ。 そういうのを、ちょこちょこと手作業で消していってみるわけです。 今思うと、リファクタリングのはしりみたいなもんです。これが私のソースコードを編集することの原点だったんです。 ときは流れまして、Pythonという言語に出会います。 聞くところによると、この言語、インデントをきちんとしないと動作しないそうじゃないですか。だれが書いてもそれなりに読みやすいコードになると。 もともとソースコードを綺麗にするのが楽しくてソースコードを触り始めた私ですから、これはとても気に入りました。 そうして私はPythonの世界にずぶずぶと浸かっていくのでありました・・・ GitHub Repository 現在、私のGitHubリポジトリ(https://github.com/nasa9084 )の数は、ちょうど20だそうです。自分が主となって開発しているものの、意味づけという理由があったりしてOrganizationを切り分けているものもありますから、20以上30未満、といったところでしょうか。 このうち、主にPythonで書いているリポジトリは10個程度で、半分には届かないものの、かなりの割合を占めています。 PyCon JP 2016 2016年はPyCon JP 2016のスタッフをしました。PyCon JPは東京開催で、もちろんスタッフの多くは東京(または東京近郊)在住で、オフラインミーティングや作業日の開催地も東京です。 一応、都合のつく限りリモートでも参加をするんですが、これがなかなか難しいのです。 解決方法はまだわからないのですが、来年は東京で就職なので、遠方のスタッフがもっと溶け込みやすいようになにか頑張りたいと思っています。 Eureka 実は、このブログのシステムもPythonで書かれています。構成としては、プログラム部がbottle + beaker + jinja2、アプリケーションサーバがuWSGI、HTTPサーバがnginxという構成です。 現状、JavaScriptは一切使っていないため、(特に管理画面において)残念な仕様の部分が多いです。 なんとかしたい。 ブログ移転で違うシステムになりました。 まとめ的な そろそろ長くなってきましたし、もうなんの話かわからなくなってきましたので、この辺で終わりにしようと思います。 とりあえずですね。何が言いたいかというと、Pythonはいいぞということです。 ぜひPyCon JP 2017にもお越しください。