Ansible を使ってみた感想 - tototoshi の日記
ここ数日 Ansible を触ってみてた。 MoinMoin Wiki のセットアップとか試しにやってみた。 tototoshi/ansible-playbook-moinmoin · GitHub Chef の代替というよりも Chef + Capistrano/Fabric という感じ。 インストールが楽。設定ファイルもほとんどなし。 デフォルトでできることが多い。Apache の Basic 認証設定とか PostgreSQL のユーザー作成とかまで最初っから使えるのが良い。 ドキュメントが充実しているしサンプルも併記してくれていて親切。 あまりハマらない。 シンプルで良いツールだと思った。 yaml なので簡単なことは簡単にかけるけれど、手続きっぽいことを書くのは当然つらい。 そこは仕方ないかというところ。まあ数日使った程度ではそこまで困ることはなかった。 シェルスクリプトでは手続
Scala 2.11.3 が生まれる前に死んでしまった話 - tototoshi の日記
↓に関して、https://gitter.im/scalajp/public で盛り上がってた内容をまとめました。 なぜこんなことになってしまうのだろう（未調査） https://github.com/skinny-framework/skinny-framework/issues/193 これ Skinny 側で何か work around できないですかね https://github.com/skinny-framework/skinny-framework/issues/193#issuecomment-58773130 2.11.3 を指定して build した Scalatra を scalaVersion := "2.11.0" なアプリから利用するのは問題なさそうだった。となると Scalatra に 2.11.3 でビルドした 2.3.1 を出してもらうようお願いするのが
「メンテナンス大変なのでサービス閉じたいです」 - tototoshi の日記
Web サービスの会社にはイケイケなサービスの陰に隠れて、かつてイケイケだったけど今はイケテナイサービス、とか、ぶっちゃけ最初っからあんまりやる気なかった☆サービス、これどこで拾ってきちゃったのサービス、などなど、惰性で続いちゃってるようなサービスがごろごろあったりします。 そういうイケテナイサービス群はメンテナンスの手間を取らせる物なので、エンジニアとしては閉じてしまいたい。でも非エンジニアとしては閉じたくない。いや、本当は閉じたい！でもちょっとは儲かってるし、閉じるとわずかながら存在するユーザーからクレームくるし、連携先の企業とやりとりするのめんどいし、まあいろいろめんどうそう。 そこで、「イケテナイサービスにはできる限りメンテナンスの手間を払うな」という話がエンジニアのとこにきて「お前なーっ！そのメンテナンスの手間がなーっ！」となり、話がループを始めます。なぜこういう噛み合わない話に
PHP の file_get_contents は get どころか post も put も delete も upload もできる - tototoshi の日記
stream_context_create と組み合わせて使います。 手元でてきとーに動かしてた REST API とかで試してます。 get 普通ですね。 <?php $content = json_decode(file_get_contents("http://localhost:5000/api/note/161")); post <?php $context = stream_context_create( array( 'http' => array( 'method'=> 'POST', 'header'=> 'Content-type: application/json; charset=UTF-8', 'content' => json_encode( array( 'title' => 'file_get_contents で POST', 'raw' => "file
チーム開発とクソコード - tototoshi の日記
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
