Go言語で、AIモデルに対する推論をコマンドラインで実行するafaというツールを作りました。入出力としてテキストストリームを前提としており、パイプやリダイレクトを用いて他のコマンドと連携しやすいのが特徴です。 $ echo $ERROR_MESSAGE | afa new -p "What is happening?" /path/to/file1 /path/to/file2 与えるプロンプトやコンテキスト情報によってAIモデルが柔軟に振る舞いを変えてくれるので、これまでの個別ツールでは対応が難しかった用途における自動化にも有用でしょう。 また、テキストストリームを扱えるリッチなTUIのコマンドafa-tuiも別途提供しているので、ターミナル上でのチャットも快適です。 デモ リッチTUIによるチャット 快適なインタラクティブチャットのため、Markdownを装飾して描画しつつ、lessコ
はじめに 研究者は、自身の研究の有用性を主張するため論文を発表する。 しかしながら、研究の有用性を主張するために、抜け漏れがなく主張点が明確な文章を書くのは、慣れないうちは難しい（慣れても難しい）。 本エントリでは、論文の構造を見出だす工程とその構造を書き下す工程を明示的に分離することで、抜け漏れがなく主張点が明確な論文執筆を行う方法を検討する。 論文執筆の課題 前述の通り、研究の有用性を主張するために、抜け漏れがなく主張点が明確な文章を書くのは、慣れないうちは難しい。 これは、主張の整理と文章の生成を頭の中で同時にやろうとしていることが原因であるように思う。 第一に、主張の整理は複雑なタスクである。 研究の有用性の主張は、いくつかの課題や提案、評価といった複数の要素と、要素同士の関係性のあり方、すなわち「構造」を持つ。 要素やその関係性の増加に伴い、構造は複雑になるため、頭の中だけで網羅
ペパボに入社したのは確か2012年の10月だったと思うので、かれこれ丸4年が経ったことになる。 転職のきっかけは、新卒で入社した地元の会社での業務の出張の多さと技術面の軽視が自分の考える働き方と合わなくなったからだった。とにかく技術でやっていきたいんだという気持ちはありながらも、その気持ちを消化できる企業がどんなものか分からず、悶々と転職サイトを見ていた気がする。ある日、福岡 おもしろい it 会社 みたいに思考停止甚だしい検索をして、まとめサイトに辿り着き、自社でWebサービスを運営している会社への転職というのが視野に入った。今にして思えばもっとよい探し方があったと思うが、新卒で1社しか見てないあの頃はとにかく世界が狭かった気がする。ともかくそのまとめサイトにあるおもしろい会社を上から順に調べていって当時のpaperboy&co.に行き着いた。 当時、福岡基盤チームを立ち上げていく時期で
去年も相変わらずGoを書いたり、ブログ書いたり、発表したり勉強会開催したり、自分のペースで自分の楽しいことをやってきたし、ふりかえってみれば、自分なりにそれらしい量もやれたかなとも思うけど、どうしても一昨年からの漫然と続く楽な活動であったと言われれば否定はできない感じがあった。活動の前提が個人の枠を超えていない。Go書いたりブログ書いたりも個人の小さな承認欲求を満たしたいだけなのでどうにもつまらんなあという感じ。 個人活動は非常に楽である。自分の好きなときにつくって公開して、たまに褒められてニヤリとして、また次をつくる。当たらなくても趣味なのでという言い訳が自分に立つ。なんと楽なことか。アウトプット最高！ そう、アウトプット最高なのだ。個人のアウトプットをキッカケに色々なところで知ってもらえて、つながりができていく。アウトプットでスキルが洗練される。ペパボに入る前はこういうことが喜ばれる環
Goアプリのデプロイはバイナリをひとつ配布して完了なのでとても楽なのですが、バイナリ自体をどこで管理するかについては意外と頭を悩ませることになります。 Goを使うにあたって、コードさえあればあとはバイナリも簡単に配布できる状態というのが望ましいと思い、仕組みを作ってみました。 2015/08/16追記: CargoはRustのパッケージマネージャーと名前がかぶってたのでTorokko(トロッコ)に改名しました！ TorokkoはGoアプリのビルドと成果物ダウンロード用のAPIを提供するビルドプロキシです。 リクエストのURLで対象リポジトリ、GOOS、GOARCH、バージョンを指定します。 ビルドはDockerコンテナを用いて行い、バックエンドストレージに成果物が保存され、ビルドリクエストと同じURLでダウンロードを行うことができます。 Docker Hub の Automated Bui
Goでコマンドラインオプションのあるツールを提供していると設定ファイルに定義できるようにしてほしいという要望が来ますが、意外とオプションと設定ファイルで定義が冗長になったりして煩わしいのでライブラリにしてみました。 conf+flagでconflagです。 いつものコードに 3行 追加するだけでコマンドラインオプションを設定ファイルに書いておけるようになります。 使い方 以下のような感じで、flag.Parse()を実行する前に、設定ファイルからflagに設定する値を呼び出すコードを追加します。 // フラグを定義します var procs int flag.IntVar(&procs, "procs", runtime.NumCPU(), "GOMAXPROCS") // コマンドラインオプションを解析する前に設定ファイルからフラグに値を設定します if args, err := con
Markdown形式のテーブル記法をいつまでたってもうろ覚えで、毎回検索したり、変換サイトにアクセスするのが面倒だったのでツールをつくりました。嘘です。Go書きたかっただけです。 使い方 CSVテキストを標準入力から受け取って整形済みのMarkdown形式テーブルを出力します。 $ mdt < hoge.csv | headerA | headerB | | ------- | ---------------------- | | short | very very long content | 連携 コマンドラインツールなので、pbpasteやAutomatorと組み合わせて好きなように使えます。 以下は、Automatorのサービスとして登録したmdtをGitHubのIssue作成時に呼び出している様子です。 便利っぽい。 機能 CSV/TSVに対応 タブ区切りにも対応しているのでエク
開発環境で利用するVagrantのVMの数が増えてきたのでpecoでVM選んで起動や停止をできるようにしてみました。 vagrant-peco こんな感じで利用します。 うれしさ pecoでVMを選択できる。Vagrantfileのあるディレクトリに移動しなくてよい VMを複数選択して一括で起動・停止できる 通常のvagrant global-statusよりも高速に表示 direnvとの連携 インストール Vagrant1.6以降でつくったVMとvagrant-peco、vagrant-global-statusが必要です。 # vagrant-global-statusをインストール $ go get github.com/monochromegane/vagrant-global-status/... # vagrant-pecoをインストール $ cd [PATH] # PATHの
Cookbookの共通化（library） 前回エントリではrecipeとdefinitionを用いたCookbookの共通化の手順を紹介しました。 今回はChefのもうひとつの共通化の仕組みであるlibraryを紹介します。 libraryって libraryはRubyコードを用いて、Chefに新しいクラスやメソッドを追加することができる仕組みです。 libraryはクックブック内のlibraries/library_name.rbに定義することで自動で読み込まれ、recipes, attributes, file, definitions, providers, definitionsで利用することができます。 libraryの用途は以下の様なものがあります。 ファイルに格納されている属性値へのアクセス ループのようなプログラムテクニックの利用 Chefのレシピから直接呼び出せるような
半歩進むChef-Solo 最近、Vagrant + Chef-Soloによるローカル開発環境Boxイメージ構築自動化に取り組んでいます。 Cookbookをつくるうえでのノウハウがたまってきたので、まとめの意味も込めて「半歩進むChef-Solo」シリーズでエントリ書いていこうと思います。 今日はChefで行う「共通化」についてです。 Cookbookの共通化（recipeとdefinition） Vagrant環境でChef-Soloによる構築自動化を行なっていると、複数の環境で似たような処理を行なっている箇所が出てくると思います。 例えば、同じResouceの組み合わせた処理が何箇所も出てきたり、特定のサーバソフトウェアに関連するセットアップをいろんなRecipeの中でやっていたり。 Chefにはこれらの処理をまとめるために、definitionとrecipeという仕組みがあります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
