ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
ドキュメントレビューをする際の10のポイント | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか？を決めておく必要がある本当にそのドキュメントは必要か？をよく考える（会社のルールだから！というのは理由にはなっていない）だと思います。 レビューのポイント1. 体裁をレビューするのではなく、中身をレビューするひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェッ
欧米のYAPCの問題点とイベント運営について僕の考え : D-7 <altijd in beweging>
今年のYAPC::Asia Tokyo 2014は海外ゲストの方々と色々話す機会があったのでかなりの時間彼らと話していた。 特にスピーカーの方々とは「日本人に受けるためにはどういうアプローチがいいんだ」という相談をYAPC期間中に（今更！）聞かれて 「日本人は証拠として数値の提示を求める傾向があるから、数値をもっと盛り込め」とか「おまえらの会社日本だと全然知られてないんだからまずそこから変えろ」とか等々の助言をして大分彼らのトークの内容を微調整する業務があった。特にDBICのトークは（見てないけど）YAPC::EUでやったものと全く内容が違う、という報告をスピーカー本人にもらった。ははは、通訳の人たちに迷惑かけたかなーw ともあれ、その流れで海外のYAPCの話。今回話した人たち全員から 「なんでYAPC::Asiaはこんなに人が集まるんだ？」「どうしたら俺たちのYAPC（EUにしろNAにし
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー
Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git
おそらくはそれさえも平凡な日々: 「仕事に対する愛と情熱とプライド」若しくは新卒に向けたスピリチュアルな話
そろそろ新卒研修とかどうしようかとかで、エンジニア陣でわたわたしたりしています。「Songmu先生にはスピリチュアルな話をしてもらわないといけませんね」みたいなことを言われてなんかスピリチュアルキャラとして定着しているのもどうかと思います。 去年も「『仕事に対する愛と情熱とプライド』ってお題でソーシャルゲームチームの新卒向けに話してください」とか研修担当の人に言われて、なんでそんな熱いキャラとして認知されてるか謎だったんだけど、それで30分くらい話しました。 それが結構評判良かったみたいで、直接はあまり言われなかったんだけど「研修の時の先輩の話の中で一番印象に残っている」って言ってくれている人が多いって話を2年目の人から又聞きで知って嬉しく思っていました。 とか思っていたら、hisaichi5518の人は「なんかすごくいい話してた覚えはあるんですけど内容全く覚えてません」とかsoh335の
老害であることを自覚して生きていく - 太陽がまぶしかったから
photo by Tetsumo だるい 一昨日から今日にかけて疲れが取れなくてぼんやりしていました。起きてはいるけど怠くて何もできない状態。私の場合は仕事や家族サービスや合コンなどに忙しい人と較べたら「自由時間」の絶対量が多いとは思うのですが、「自由だけど何も出来ない時間」が増えているようにも思います。 29歳の時ぐらいから自身が身体的に老いていく事を強烈に意識するようになりました。額のシワだとか、痩せにくくなったとか、異常に疲れやすいだとか。定期的にデスマーチ案件に巻き込まれた事もあって夜も休日も働き続け、たまに時間があれば朝まで呑んでみたいな事を繰り返していました。むしろそういう体力には自信があったぐらいなのですが、着実に身体が蝕まれていたということでしょう。 騙し騙しやってきましたが、そろそろ無理だなと思いました。「病気」であれば「治癒」のニュアンスを信じてしまいますが、実態的には
テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
YAPC::Asia 2013 / Github によりバザールモデルへ - naoyaのはてなダイアリー
ブログを書くまでが YAPC、ということなので、書きます。 初日「モダンPerlリファクタリング」 自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。 https://speakerdeck.com/naoya/modanperlrihuakutaringu-number-yapcasia 今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが と @t_wada 御大よりお褒めに与ったので個人的には満足です。 リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。
plagger - otsune FreeStyleWiki
Plagger 注意 このページは単なるインストール手順のメモです。Plaggerは開発が活発なので、ここの情報は古くなっていることが多いです。 Plaggerについての正確な説明は Plagger公式サイト Shibuya.Plaggers Plagger Plugin はてなブックマーク - タグ plagger などを参照してください。 概要を知りたい場合は公式サイトのPresentationsにある「YAPC::Asia 2006 Tokyo」「Plagger Conference 1 Keynote」のスライドを参照するとよいでしょう。代表的なデモとしてElementary, ... Googleで「はらへった」と検索するとピザが届くようにするまでがあります。 解説 Plaggerは、mixiやBloglinesやWebサイトなど様々なところからデータを取って来て、いろいろなフィ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
