Dockerもシェルスクリプトも使わずGoのクロスコンパイルを行う : D-7 <altijd in beweging>
moznion.hatenadiary.com 別にDocker使ったっていいんだけど、こっちでもできますよ、ってことで、Dockerもシェルスクリプトも使わない方法の説明。元記事を読んでわかるのは： 1. makeを使ってる 2. GOOS/GOARCHを設定してクロスコンパイルしている（gox等を使っていない） 3. Dockerであげた同一イメージ上で全てのクロスコンパイル結果を吐いている ということなので、であれば別にローカルの環境でクロスコンパイルしても何の差もなさそう。別の環境をたててクロスコンパイルしたい場合もあるが、それは例えば cgoを使っている os.User 関連のコードをコンパイルするとか、そういう時だしその場合はそれぞれのプラットフォームごとに別のホスト上でコンパイルする必要がある。それをする必要がないなら go 1.5 以降であればもうGOOS/GOARCHを設
某オブジェクトストレージでデータをお引っ越し中な話 : D-7 <altijd in beweging>
目的：オブジェクトストレージの旧ストレージサーバーから新ストレージサーバーにデータを引っ越しすること。rsyncやディスクを単純に交換するという方法も考えたが、ついでにデータのリバランスを行いたいので、ツールで移行する方法を採る。 概要：オブジェクトとは、ユーザーから見る「１ファイル」で、この１オブジェクトに付き、1個かそれ以上の実体（entity）が存在する。１ストレージには任意のオブジェクトの実体が最大1個保存される。この実体が複数あることによって、ストレージがダウンしたとしてもオブジェクト自体は生き残る事ができる。複数の実体がある場合は必ず複数のストレージサーバーに実体のコピーが保存されている。これを1ストレージサーバーずつ、新ストレージサーバーのほうに移動する use strict; use DBI; use Furl; my $dbh = DBI->connect( ... );
Plack/Starman Daemontools Run File With Complete Deploy Bundle : D-7 <altijd in beweging>
注１：まだ本番にはデプロイしてませんが、確認テストでは使いました（単位テストでは使わない。あくまで本番さながらの形で動いているのを確認したい時だけ）。 注２：以下スクリプトは開発者の労力を減らすためのスクリプトで、万全なデプロイ方法だとか言うわけではありません。 注３：正直シェルスクリプトは素人です。 追記：envdirはどうか、と言われた件。最初それを思い出せなくてcat ENVなんてしてたんだけど、設定値をもらって後からフックしたいところがあるからenvdirではそれを実現できない・・・気がする。ので、今回は以下で。hirose31 さんが美しい スクリプトを提供してくれたので、それをベースにしてgithubにあげておけました。最新版はここです。
peco（Simplistic interactive filtering tool）を作った話 : D-7 <altijd in beweging>
（pecoそのものについてはここで読むよりREADMEを見た方が早いです） 今月の初めくらいにpercolという便利なものがあるという話を聞き、「ほう、使おうかな」と思ったら普段あまり使い慣れていないpython製ツールでまるでcpanmを使うのがいやなPerlに慣れていない人のような反応で「まぁ必須アイテムじゃないし…」と思って諦めかけたところ lestratt さんはやく！ — mattn (@mattn_jp) June 6, 2014 とか言われ「そこまでいいツールなのかなー」と思ったけど、使ったことないし、まずはツールがどういうものなのかをわかるためにGoで実装する事にした（はい、本当にこういう順番です）。 pythonが駄目でなんでGoが良いかと言えば単純にバイナリ一個で済むから。それだけ。多分オリジナルのpercolはずっと歴史を積んでいるだろうし、色々がんばっているのだろう
Goroutine Synchronization : D-7 <altijd in beweging>
（以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません） これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。 TL;DR; goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。 deferの基本 goではLLのノリでコードを書けるのが売りの一つですが、メモリ管理はしてくれるものの、様々なリソース解放も全て自動というわけではあり
私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>
なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り： これは自分の部署で初めて 本番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log
Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>
tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね！ Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて１時間Goについてしゃべりまくってきた。1時間ぶっつけ本番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます Go事始め そもそもなんでここまでGoをガリガリ書き出したのか。 正直親父ギャグとvimで有名なあの人が「Goいいよ！」と言い出したときにはGoに対してはうさんくさい印象しかなくて特に注意すらしてなかったんだけど、そろそろ違う言語とドメインに向いてみるかーと思って探していた時に「あ、俺もうLL系の言語別にいらないな」とふ
YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
