タグ

ブックマーク / motemen.hatenablog.com (41)

  • Spreadsheet に送信したスピードキュービングの記録を Slack や Pixela に連携する - 詩と創作・思索のひろば

    ご機嫌いかがでしょうか。以前作ったタイマーアプリ fuTimer はスピードキュービングの測定記録をスプレッドシートに送信できるんですが、 記録をスプレッドシートに保存できるスピードキューブ用タイマーアプリを作った - 詩と創作・思索のひろば スプレッドシートは貧者のサーバレスこと(言い飽きた)Google Apps Script を呼びだせるので、記録データをその他の外部サービスと連携できます。自分が求めているのは Slack と Pixela の2つだったので、これらに投稿する仕組みを作りました。あとは Twitter もあってもいいかもな。 Slack こんな感じで、セッションをシートに保存するたびに、Slack に通知できます。 インストールと設定 fuTimer の記録に使っているスプレッドシートを開き、メニューから [ツール] → [スクリプト エディタ] を選択

    Spreadsheet に送信したスピードキュービングの記録を Slack や Pixela に連携する - 詩と創作・思索のひろば
    oppara
    oppara 2018/11/07
  • AWS AppSync で時刻のソースをエポックミリ秒として扱いたい - 詩と創作・思索のひろば

    サーバレスで GraphQL したかったので AWS AppSync に入門してみた。スキーマを書いてデータソースとリゾルバを追加して……というフローでずいぶんさくさくと進むんだけど、タイトルに書いたとおり時刻をエポックミリ秒として扱おうとすると困ってしまった。 つまり以下のようなスキーマで、データソースに格納されたエポックミリ秒(例えば 1503932400000)を JSON にして返そうとすると: type Entry { createdAt: Int! } こんな感じのエラーになってしまった。 { "data": { "getEvent": { "createdAt": null } }, "errors": [ { "path": [ "getEvent", "createdAt" ], "locations": null, "message": "Can't serialize

    AWS AppSync で時刻のソースをエポックミリ秒として扱いたい - 詩と創作・思索のひろば
    oppara
    oppara 2018/05/08
  • 作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた - 詩と創作・思索のひろば

    おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを MackerelSlack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も

    作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた - 詩と創作・思索のひろば
    oppara
    oppara 2018/01/31
  • 最近のGoプロジェクトのMakefile - 詩と創作・思索のひろば

    最近は仕事でも新しくGoプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール(golint とか gobump とか)であったりのインストールをどうするかという話。 npm であれば devDepende

    最近のGoプロジェクトのMakefile - 詩と創作・思索のひろば
    oppara
    oppara 2017/12/17
  • Google App EngineでGoを動かすときに知っておくべきこと(ソースコード・ビルド編) - 詩と創作・思索のひろば

    Google App Engine(GAE)で Go 製のウェブアプリを動かしたかった話。いっぺん動かしてみると GAE/Go はウェブアプリを動かす環境としてはとてもいい。ただ、中途半端な知識だけで始めると開発者としてはつまずくことが多かったので、分かりにくい点をまとめておく。 Google App Engine Go Standard Environment について goapp は $GOPATH 以下もアプリケーションのソースとしてアップロード/コンパイルする goapp はプロジェクトルート以下のソースコードをすべてコンパイルしようとする go-app-builder: Failed parsing input: parser: bad import "syscall" in ... go-app-builder: Failed parsing input: app file x

    Google App EngineでGoを動かすときに知っておくべきこと(ソースコード・ビルド編) - 詩と創作・思索のひろば
    oppara
    oppara 2016/11/28
  • 型と名前によるGoのコード探索 ― gofind - 詩と創作・思索のひろば

    思いつきでツールを作ってはリスのように忘れ、再発見しては新鮮な気持ちで便利に使う日々です。 一般にプログラミングにおいては、ソースコードを読むことに意外とばかにならない時間を使うもの。特に Go ではデフォルトで標準ライブラリのソースコードが手元にあり、コードを書く際よい教科書になるので、これを読むことも多いはず。 Go は静的に型付けされる言語なのでその点コードは読みやすいけれど、データ構造が不変ではないので、ある構造体のフィールドがどこで書き換わるのかを知るには、処理を追っていくしかない。名前で grep するのもひとつの手ではあるけど、精度はあまり期待できない。 そこで gofind。簡単に言うと、型やパッケージを含めた名前でもって Go のソースコードを検索するツールです。 go get github.com/motemen/gofind/cmd/gofind 使い方は以下の通り。

    型と名前によるGoのコード探索 ― gofind - 詩と創作・思索のひろば
    oppara
    oppara 2016/10/28
  • Go 言語における並行処理の構築部材 - 詩と創作・思索のひろば

    5年前に買った『Java並行処理プログラミング ―その「基盤」と「最新API」を究める―』をようやく読んだ。買った頃には Perl やシンプルな JavaScript ばかり書いていたので並行プログラミングなんてほとんど気にすることがなく、実感がなくて読むのも途中で止まってしまっていたで、家を掃除しているときに見つけたもの。その後も趣味Android アプリを書くなど Java に触れる機会はあったけれど、せいぜいが AsyncTask を使うくらいで、マルチスレッドを強く意識してコードを書くこともなかった。 Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua Bloch,Doug Lea出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/11/22メディア: 単行購入: 30人 クリック: 442回

    Go 言語における並行処理の構築部材 - 詩と創作・思索のひろば
    oppara
    oppara 2016/05/31
  • 第三者のための『リーダブルコード』 - 詩と創作・思索のひろば

    新人エンジニアにオススメののひとつだよねー、などと言いつつ自身は読んだことがなかったので慌てて買って読んだ。 お題「リーダブルコードリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典出版社/メーカー: オライリージャパン発売日: 2012/06/23メディア: 単行(ソフトカバー)購入: 68人 クリック: 1,802回この商品を含むブログ (131件) を見る なるほど当たり前のようなことでありながら短期的に意識して身につけるのは難しかったことばかりで、これがこのようにまとまった形の書籍になっていることはとてもありがたいことだと思う。規約を押しつけてるわけじゃなくて指針の集合なので、気楽さもある。 プログラム中で使用する英語動詞

    第三者のための『リーダブルコード』 - 詩と創作・思索のひろば
    oppara
    oppara 2016/04/06
  • git fetch の裏側では何が起こっているか - 詩と創作・思索のひろば

    git fetch の裏側でどんな通信が行われてリモートリポジトリの内容が取得できるのか調べたのでまとめる。もともとは git の HTTP や SSH といったプロトコルでどのように実現されているか、というところに興味があった。Git v2.7.1 を基にしている。 事前準備 pack プロトコル pkt-line フォーマット Reference discovery Packfile negotiation Packfile の送受信 packfile への圧縮・packfile からの展開 各種トランスポートの実装 file トランスポート ssh トランスポート git トランスポート http(s) トランスポート まとめ 参考資料 事前準備 手を動かしてプロトコルを理解できるよう、gist の小さなリポジトリ を使う。適当なディレクトリ下に bare リポジトリとして clon

    git fetch の裏側では何が起こっているか - 詩と創作・思索のひろば
    oppara
    oppara 2016/03/15
  • Slack のログを自動で Google Spreadsheet に保存する - 詩と創作・思索のひろば

    2020-05-12 22:50 追記 2020-05-05 より、Slack のトークンは作れなくなってるので、このエントリの方法ではストレートに実現できなくなっています。トークンの代替方法についてはサポートしかねる(というか知らない)ので、各自がんばりましょう! 2015-11-13 16:40 追記 以下のスクリプトの利用が Slack の TOS に触れるのではないか……という指摘をいただきました。 No Other Storing. You may not copy or store any Data or capture or store any information expressed by the Data (such as hashed or transferred data), except to the extent permitted by this API TO

    Slack のログを自動で Google Spreadsheet に保存する - 詩と創作・思索のひろば
    oppara
    oppara 2015/11/14
  • Electron で AdSense のレポートをメニューバーから確認できるアプリを書いた - 詩と創作・思索のひろば

    ぼくはその日を善く生きたかどうかは AdSense の収益で決まると思っているので、以前にも AdSense のレポートを CLI で確認できるツール を書き、この記事にもあるように tmux のステータスバーに収益を表示していつでも確認できるようにカスタマイズしている。これは具合がよくてずっと使っていたのだけど、最近 tmux.conf をいじっていたらだんだん表示領域が手狭に感じられてきて、ターミナルから追い出したくなってしまった。くわえて、人にターミナルを見せると「ほうほう motemen さんの今月の収益は 9 円ですか……」といらぬ情報を人に与えてしまう問題もあり、ここはひとつ最近はやりの Electron を使ってメニューバーに表示してしまおうということしたのだ。 使用イメージはこちら。ここ7日分の収益を、日別に集計してメニューに表示している。アイコンの隣の数字はその合計(数字

    Electron で AdSense のレポートをメニューバーから確認できるアプリを書いた - 詩と創作・思索のひろば
    oppara
    oppara 2015/10/07
  • Go のシンプルかつ明快な SQL クエリビルダ go-sqlf - 詩と創作・思索のひろば

    Go でリレーショナルデータベースを利用したアプリケーションを書いているとき、動的に SQL を組み立てたい場合には、いくつかの方法が考えられます: クエリビルダを使う。世の中にすでにいろいろ存在します。(そのためのライブラリなので)動的に生成するにはもってこいですが、この場合、それぞれのライブラリに合わせた書き方をしなければならないので読み手にもある程度負荷がある点、また、Go は言語として冗長に書くことをよしとする思想を持っているため、DSL 的な API との相性が悪いという欠点があります(map の組み立てが冗長、条件分岐する式が書けないなど)。また、一般にクエリビルダから生成される SQL がコードから想像しづらくなる問題もあります。 文字列連結や fmt.Sprintf を使う。発行される SQL は比較的分かりやすくなりますが、動的に組み立てると SQL プレースホルダとバイ

    Go のシンプルかつ明快な SQL クエリビルダ go-sqlf - 詩と創作・思索のひろば
    oppara
    oppara 2015/09/10
  • Go プロジェクトのバージョニングとリリースを CI で自動化する - 詩と創作・思索のひろば

    gobump で Go プロジェクトのバージョニングをおこなう の続き。すっかり書くのが遅くなってしまったけれど、別にもったいぶるような特別なことはないです。 ここでは、Pull Request のマージを契機に、バージョンを進めるコミットをし、push して、GitHub のリリースを進める……ということを CI でおこなうことを目標とします。 これはわりと簡単で、以下のようなスクリプトで実現できます。必要なものは gobump、ghr、jq と GitHub のパーソナルアクセストークン。通常はクロスコンパイルするのに gox も使うことになるでしょう。 set -e repo_owner=motemen repo_name=test-repository committer_email=motemen+gobump-bot@gmail.com committer_name=motem

    Go プロジェクトのバージョニングとリリースを CI で自動化する - 詩と創作・思索のひろば
    oppara
    oppara 2015/08/14
  • シェルスクリプトで Go の簡易ベンダリング - 詩と創作・思索のひろば

    HerokuGo がサポートされたのは良いニュースだったけど godep を使わなきゃいけないのが気に入らないところで、GoHeroku に乗せたい Web アプリケーションを作る時は Docker を使う ことにした(参考)。その際にも Docker コンテナ中で go get をいちいち待つのはストレスなのでベンダリングはしておいたほうがよい。そこで簡単なベンダリングスクリプトを書いた。Go 1.5 で試験的に導入されたベンダリングには特に対応していない。 https://gist.github.com/motemen/bb1fca4a92a29bad78dc このスクリプトは プロジェクトの依存しているサードパーティーライブラリを特定のパス以下にコピーできる 上記のパスを GOPATH に含めて go コマンドを実行できる リビジョンロッキングは行わない なので、複数人開

    シェルスクリプトで Go の簡易ベンダリング - 詩と創作・思索のひろば
    oppara
    oppara 2015/07/30
  • gobump で Go プロジェクトのバージョニングをおこなう - 詩と創作・思索のひろば

    Go に限らず、公開しているプロジェクトのバージョニングは必要だけれど面倒なタスクのひとつで、プロジェクトのメンテナンスを続けていくつもりがあるのなら、ほぼ必ず通らなければならない道でしょう。ここで話題にしているのは Git などによるソースコードのバージョン管理ではなく、たとえばバージョン 3.1.4 といった、リリースされるソフトウェアの公開バージョンをどう運用するか、という話です。 バイナリとして配布する前提のプロジェクトであればソース中で var version string と宣言した変数に、ビルド時に -ldflags '-X main.Version 3.1.4' などとしてバージョンを設定するという方法もありますが、go get による配布ができるのなら、提供側としては楽ができます。たとえば gore は開発者向けということでバイナリの配布をしていませんが、リリース作業がな

    gobump で Go プロジェクトのバージョニングをおこなう - 詩と創作・思索のひろば
    oppara
    oppara 2015/07/20
  • Mackerel + peco + zsh でコマンドラインにホスト名を補完する - 詩と創作・思索のひろば

    複数のサーバが関わっている環境では、ホストに人間が分かる名前を関連付けなければ運用がスケールしなくなるものです。その名前はホスト名だったり、ロールやタグのようなものだったりすると思いますが、仮にホスト名を利用するなら、DNS を用いて名前とホスト(の IP アドレス)の対応をつけるようなこともできるでしょう。DNS が利用できない場合は、/etc/hosts に書くというようなのもありですね。 しかしホスト名を直接利用した運用というのは意外と難儀なところがあって、とくに自分のように普段サーバを扱った作業をあまりしないアプリケーションエンジニアなどは、「前に接続したことあるあのホストは何だっけ……」といううろ覚え状態に弱い。名前の一部は覚えているわけなので、シェルの履歴を検索すればなんとかなるのですが、一度も接続したことがなければ目当てのホストを探し出すことはできません(この、接続したことが

    Mackerel + peco + zsh でコマンドラインにホスト名を補完する - 詩と創作・思索のひろば
    oppara
    oppara 2015/07/01
  • Google Apps Script の TypeScript 型定義ファイルを作った - 詩と創作・思索のひろば

    2015-12-08 追記 TypeScript の型定義ファイルリポジトリのデファクト・スタンダードであるところの DefinitelyTyped に無事 Pull Request が取り込まれました ので、今後は DefinitelyTyped のほうを参照していただければと思います! Google Apps Script は JavaScript っぽい言語で Google 製品の自動化を行える便利環境で、定期実行や外部との HTTP 通信など、意外と痒いところに手が届く出来であり、今となっては身につけておくとよいツールのひとつと言えるでしょう。GAS の開発はおもにオンラインエディタでおこなうこととなっていて、ここで便利なのは補完が効くこと。慣れたエディタで書くこともできるけれど、補完のない環境で、多岐にわたる API をリファレンス引きながら書くというのは心細い。 そもそも JS

    Google Apps Script の TypeScript 型定義ファイルを作った - 詩と創作・思索のひろば
    oppara
    oppara 2015/06/19
  • Polymer エレメントの開発ツールと CI - 詩と創作・思索のひろば

    先日の Google I/O 2015 にあわせて Polymer 1.0 がリリースされました。めでたい。そこで表題のように、自分で Polymer エレメント(コンポーネント)を作るときの構成の話。 始めるにあたっては PolymerLabs/seed-element をベースにすると便利で、この中には以下のような標準的な構成が示されています。 bower による依存の解決 web-component-tester を使ったクロスブラウザのテスト iron-component-page を使った API ドキュメントとデモ web-component-tester web-component-tester は Polymer エレメントをテストするためのツールで、テストを実行するだけじゃなく Mocha や Async.js など便利なライブラリをテストから利用できるようにしてくれます

    oppara
    oppara 2015/06/02
  • コマンドラインでカラーコードの計算・操作ができるツール - 詩と創作・思索のひろば

    何かしら画面を作らなければいけないときには色のことを考える必要があって、たとえばこの色を少し暗くした色が欲しい! と思ったときに、素人としては頼れる方法を持っていないのが問題なのです。ウェブサイトであれば Scss なり Less なりの CSS プリプロセッサを使えばそういった要求に応える便利な機能が用意されているのであまり考える必要はないのだけれど、他の場面でも使える汎用的な道具が欲しかった。簡単に言うと darken(red, 10%) とか与えたら #rrggbb みたいな形式で表現してくれるやつです。 そこで書いたのがコレだ: motemen/node-less-calc。 たぶん Functions | Less.js にある関数がすべて使えます……というので分かるとおり、Less の機能にそのまま乗っかっている非常にエコな実装。オマケで色だけでなく大きさの計算もできる。 %

    コマンドラインでカラーコードの計算・操作ができるツール - 詩と創作・思索のひろば
    oppara
    oppara 2015/05/07
  • 2015年のタスク管理 - 詩と創作・思索のひろば

    今年に入ってからタスク整理のしかたを考えなおして、とりあえず数ヶ月続けてみた結果、現時点で維持はできていて悪くはないと思ってるやり方をまとめておきます。 大方針: 「やりたいこと」と「やらなければいけないこと」を分ける これまでは Remember The Milk なり Google Tasks なりに一元管理して、日々生じる外発的なタスク(あの人に声かけて、とか、文書を準備して、とか)と突然思いつく内発的なアイデア(こんなウェブサービス、ツールを作る、○○について調べる)を一カ所に投げ込んでいたのがよくなくて、もちろんツールの機能で分けることはしていたとはいえ、今ひとつ整理された見た目にならなくてだんだん足が遠のいてしまっていた問題があった。というかそもそも整理したくないというのもある。そこで今年はこれらのタスクやアイデアを二つの場所に分けて管理してみることにした。 やらなければならな

    2015年のタスク管理 - 詩と創作・思索のひろば
    oppara
    oppara 2015/04/21