はじめてのmaven central 公開 - たごもりすメモ
前置き：このエントリはJavaおよびJava周辺の*1開発環境に全く縁の無い人間が、可能な限り依存ソフトウェアを少なく手順をシンプルに保ったままやろうとしたものであり、知識・経験のある人にとっては全く最適な手段でなかろうことをお断りします。 先日のエントリ で書いたとおり woothee 1.0.0 をリリースした。Perl, Ruby, Node.js および PHP などはそれぞれの言語毎のモジュールリポジトリに登録されている。 が、Javaについては自分が Maven Central の勝手がわからず、されてると便利だよなーとは思いつつ放置していた。 が、なんと @making さんからMaven Central登録用の pull requestがきた 。きてしまった。これで最大の問題(xmlを書く)はおおむね解決されてしまったので、覚悟を決めて登録作業をすることにした。 せっかくや
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
PerlでSTDIN/STDOUTを任意のファイルハンドルに置き換える - たごもりすメモ
いま書いてるコードで、forkしてexecするんだけど、execする前にSTDIN/STDOUTを任意のファイルハンドルに置き換えたいなー、もっというとexecするプログラムのSTDINにソケットのREADから流れてくるデータを流し込んで、STDOUTの出力をソケットのWRITEに流し込んでやりたいなー、というようなことを考えていた。 で、これが例えば今のプロセスのSTDOUTの出力をファイルに置き換えるには、以下のようにすればいい。 open(STDOUT, '>', '/path/to/file'); シェルスクリプトでも簡単。*1 exec >> /path/to/file さて、STDIN/STDOUTとconnect済みのソケットを結合したい。connect済みのソケットはファイルディスクリプタは持っているがファイルパスを持っていない、ので、普通にopenし直すだけではうまくいか
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
ネットワークの遅延について真面目に書く - たごもりすメモ
遅延（レイテンシ）とはなにか？ - はてなポイント３万を使い切るまで死なない日記 この記事に果てしなくテキトーなことが書いてあってこれを真っ向から信じられると大変迷惑なので、こと細かに真面目に書くことにする。 ……つもりだったが、なんか果てしなくめんどくさくなったのでテキトーに書き散らすことにした。大学の教科書にそのへん詳しいのがいくらでもあったのに、見付からねーし。どこいったんだ。 信号の伝送速度について まず光速度 3.0*10^8 m/s というのは真空中の値*1であって、光ファイバや電線の信号伝送速度はもっと遅い。一般的には光ファイバが 2.0*10^8 m/s 程度とか言われていて、電線についてもモノによってあれこれある。詳しくは波長短縮率とかの単語でググれ。ざっくりとでも30万キロとか恥ずかしいことは言うな。 またどんな距離の都市間でも直接接続できるわけではない。500kmくら
会社で働く前に確認したいこと - たごもりすメモ
自分が会社で働くときに、何がわかってると安心して検討できるだろう、という内容を考えてたので書き出してみる。 いまの勤務環境について改めて以下の項目を検討してみるとなかなか愉快。 勤務時間・就業形態 時間 実態は？ 時間外は？ 勤務時間じゃないのによくわかんない集会があるとかは？ 有給休暇 実態は？ 雰囲気 多少の遅れはOK？ 厳しい？ ネットワーク Webのアクセス制限は行われてる？ 2ch/mixi/Facebook/Twitter HTTP経由でのsvn/git/hgアクセスは可能？ プロトコルごとに閉じられてたりする？ sshとか 正直、あんまりキツいと生きていけない気がする自分。というかユルくないと干上がるんじゃないかな……。 業態 自社開発？ 下請に出してる？ 自社製品/サービス？ 請負？ SES？ 主に作ってるのはなに？ 技術的なロジック、自社の業務ロジック、顧客の業務ロジック
テストケースのベースクラス GAETestBase を作った - たごもりすメモ
前に書いた記事からはやくも半月たってしまったが、やっと出してもいいかなという状態になったので公開します。ファイルそのものはこちら。 GAETestBaseはPython標準のunittest.TestCase継承クラスとなってます。ユニットテストを書く際に、通常のTestCaseのかわりにGAETestBaseを継承してユニットテスト用のクラスを作り、あとは普通にテストコードが記述できます。 PythonおよびAppEngine SDK以外への依存がゼロで環境を選ばない、はず、なのが売りかな？ ところで出来上がったあと公開用の準備をやってたら、GAE/J側ではslim3がkotoriを組み込んだという話が。おおお。 できること CLIでのテスト実行 開発中のテスト実行が、Python標準のunittestと全く同じようにCLIから実行できます テストケース側で指定があれば各サービスはrem
GAE/Pythonテスト環境に欲しいもの - たごもりすメモ
いまPython on GAEのテスト環境の貧弱さをなんとかするべく、あれこれやってる。とにかくテスト環境がショボいんだよね。 App Engine/Pythonはローカルのデータストアのstubの出来が良くないので、ローカルとプロダクションで動きが違うことが結構あり、ローカルでテストできることが限られてしまいます。Javaの方は、Statisticsの機能を除いては、ローカルとプロダクションの動きはほとんど同じです。stubレベルでは、ローカルでプロダクションと違う部分もあったりしますが、Slim3でおなじになるように実装してたりするので、ほとんど違いがないのです。 プロが仕事で使う場合にApp Engineでどの言語を選べばいいのか - ひがやすを blog ぐうの音も出ない！ 事実だ！ じゃ、プロならJavaを使った方がいいかというとそんなこともありません。好きで慣れている方を使った
GAEUnit試してみた - たごもりすメモ
GAE Python環境でテストどうしよう、という話でGAEUnitを試してみた。簡単に方法と特徴をまとめておく。 使いかた gaeunit.pyをダウンロードして、他のコントローラと同じ場所に置く app.yamlに設定を追記する 内容はGAEUnitのページの先頭に書いてあるまんま HTTPでアクセスできるようにする dev環境ならdev_appserver.pyを起動する production環境ならappcfg.py updateする ブラウザで /test を開く ブラウザでページを開くと作成済みのテストが全部実行される。実行対象はgaeunit.py内に書かれている _LOCAL_TEST_DIR で指定するようだ。(デフォルトは /test)。テストのうち、どれを実行するとか選ぶような悠長なことはない。すべて実行される。 特徴 作りとしては各テストごとに対応するHTTPリクエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
