タグ

ブックマーク / blog.mwed.info (9)

  • OSS になった Kuroko2 をどこよりも早く導入したので紹介したいブログ — みんなのウェディングエンジニアリングブログ

    こんにちは、技術部開発基盤グループの小室 (id:hogelog) です。 みんなのウェディングは OSS となった Kuroko2 を早速導入したので、その Kuroko2 の導入方法をブログにて共有します。 何故 Kuroko2 を導入したか みんなのウェディングではジョブ管理ツールとして主に Rundeck を利用していました。汎用のジョブ管理ツールとして開発されている Rundeck は非常に多機能で様々な処理を柔軟に実行できます。雑多なバッチ処理が稼働していたみんなのウェディングのシステムを一つのジョブ管理ツールに集約させるには非常に便利なものでした。 しかし運用を続けるうちにいくつかの難点が見つかってきました。 スケジュール実行がいきなり過去のジョブ定義に巻き戻る(ことが稀にある) https://github.com/rundeck/rundeck/issues/1447 M

    OSS になった Kuroko2 をどこよりも早く導入したので紹介したいブログ — みんなのウェディングエンジニアリングブログ
  • プロトタイピングの仕組みを用意して確認しながらサービスを改善する — みんなのウェディングエンジニアリングブログ

    みんなのウェディング 松久です。 みんなのウェディングでは、常にサービスを改善するために、新しい機能を加えたり、既存の機能を変更したりします。しかし、実際にその機能を公開してみると、想定していた数字の変化が起きなかったり、思わぬところに影響が発生したりすることもあります。 そこで、みんなのウェディングではプロトタイピングを行える仕組みを取り入れてサービス改善を進めるようにしました。 Motorhead プロトタイピングは、既存の機能を提供しつつも一部の機能を特定の人にだけ公開する仕組みです。このような仕組みを実現するために、Motorhead という Ruby の gem を利用しています。Motorhead の説明には下記のように書かれています。 Motorhead is a prototyping framework for Rails. It’s something akin to

    プロトタイピングの仕組みを用意して確認しながらサービスを改善する — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2016/06/03
    Motorheadを使ったABテスト。Railsエンジンを使う
  • Embulk をつかって検索ログを抽出する — みんなのウェディングエンジニアリングブログ

    みんなのウェディング 高井です。 先日、当社で開発した embulk-filter-query_string という Embulk のフィルタープラグインをオープンソースとしてリリースしました。今回はその Embulk のプラグインをつかって、検索ログを抽出する方法を紹介します。 Embulk のユースケースとメリット たとえば、下記のような一般的なアクセスログがあったとします。このログは、ダミーのログを生成するスクリプトで生成したもので、よく利用される Combined Log 形式のものです。 200.198.91.50 - - [09/Mar/2016:06:34:01 +0900] "POST /search/?c=Software+Games HTTP/1.1" 200 101 "/category/toys" "Mozilla/5.0 (compatible; MSIE 9.0

    Embulk をつかって検索ログを抽出する — みんなのウェディングエンジニアリングブログ
  • 開発ブランチをデプロイする — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。 気軽に開発サーバーにデプロイできると便利なことがあります。 たとえば、開発中のブランチをデザイナーやディレクターに確認してもらいたいときがあります。また、プルリクエストのためのブランチが大きくなってしまったから動作をみながらコードレビューしたいときもあるでしょう。 もちろん、手元のマシンでアプリケーションサーバーを起動させ、そのサーバーで動作確認してもらうこともできます。とはいえ、タイミングをあわせてサーバーを起動させるというのも手間です。 そこで、みんなのウェディングでは、開発ブランチを簡単にデプロイして確認できるようにする仕組みを用意しています。 Capistrano 開発サーバーへのデプロイには Capistrano を利用しています。プロダクションサーバーやステージングサーバーに対するデプロイでは AWS CodeDeploy を使っているのですが

    開発ブランチをデプロイする — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2016/03/09
    開発環境をブランチごとにデプロイ
  • みんなのウェディングで日々行われている社内勉強会・読書会 — みんなのウェディングエンジニアリングブログ

    こんにちは。UXデザイングループの今泉です。 みんなのウェディングでは、色々な社内勉強会や読書会が行われています。 社内勉強会とは、業務とは関係のない場と時間で、あるテーマに沿った様々な事を勉強する会です。 そのテーマに詳しい人が先生役になり、そこに集まるメンバーの部署や職種はバラバラです。 勉強会は、業務で必要な知識だけではなく、より深く体系的に勉強したい人に向けて開催されています。 なので、参加者は自由に各々の目的を持って参加しています。 また、勉強会よりもゆるくカジュアルに開催しているのが読書会です。 読書会では皆で読みたいを、一緒に読んで意見交換をしています。 今回はそんな社内勉強会・読書会の様子をご紹介いたします! HTML/CSS勉強会 HTML/CSS初心者向けのHTML/CSS勉強会は、週に3回、定時後に行われています。 学習動画ドットインストールを皆で見て、勉強した内容

    みんなのウェディングで日々行われている社内勉強会・読書会 — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2016/03/09
    社内勉強会の参考になる
  • みんなのウェディングの継続的デリバリー — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。今回は、みんなのウェディングで構築している継続的デリバリーの仕組みについての話です。 継続的デリバリーとは? インターネットサービスを提供していくうえで、とても重要なプラクティスのひとつに「継続的デリバリー」があります。継続的デリバリーとは、ソフトウェアをいつでもリリース可能な状態にしたままで構築していくというソフトウェア開発の規律です。 継続的デリバリーを採用することで、ソフトウェアのリリースサイクルを短かくすることができるようになります。リリースサイクルを短かくすることは、サービスの仮説検証プロセスを短かくすることにつながります。 サービス開発の質は、どこにあるのか分からないユーザーのニーズをとらえることにあります。ですから、仮説検証の機会を最大化できる継続的デリバリーはサービス開発にとって、欠かせないプラクティスとなるわけです。 完了条件を定義する

    みんなのウェディングの継続的デリバリー — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2016/03/09
    リリース可能要件を明確にする
  • 引数チェックの責務を設計する — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。今回のエントリも、若者との対話シリーズとなります。 あるオブジェクトが別のオブジェクトを呼び出すとき、受け渡される情報のチェックをどちらの責務で行なうかという問題があります。呼び出し側でチェックを行なうのがよいのでしょうか。それとも、呼び出され側でチェックを行なうのがよいのでしょうか。 この問題は、結局のところ設計の問題であり、ケース・バイ・ケースであるというのが正解になります。ですから、どのようにケースを見極めるのかという考え方が重要です。 信頼領域 『オブジェクトデザイン』には、この問題のヒントになるアイデアが書かれています。それが、「信頼領域」という考え方です。 信頼領域とは、システムを「信頼するコミュニケーションが発生する領域に切り分け」た領域のことです。システムは、ユーザーとユーザーインタフェースの境界、外部システムとの境界、異なるレイヤーとの境界

    引数チェックの責務を設計する — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2016/03/09
    呼び出し側、呼びだされ側、チェックをしないという指針
  • クラス設計の原則 — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと

    クラス設計の原則 — みんなのウェディングエンジニアリングブログ
  • みんなのウェディングはAWSで動いています — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。当社でもエンジニアブログを始めることになりました。よろしくお願いします。 AWSへと移行しました 私たちのサービスは、先月の2015年9月29日早朝にAmazon Web Services(AWS)へと移行しました。 AWSへ移行することによって、ユーザーのみなさんに、より素早く、より安定したサービスをお届けできるようになるというのが総合的な判断理由になります。そして、その背景にはいくつかの技術的なメリットやコスト的なメリット、そしてその他に忘れてはいけないメリットがあると考えています。 技術的メリット まず、AWSに移行することで、柔軟にサーバー資源を確保したり、構成することが容易になるというのが挙げられます。 以前の環境では、料金体系や納期の関係で、簡単にサーバーの追加や廃止ができる状況ではありませんでした。なので、一台のサーバーが複数の役割を担っている

    みんなのウェディングはAWSで動いています — みんなのウェディングエンジニアリングブログ
    takaesu
    takaesu 2015/10/07
    itamae, roadwork, piculet, kelbim などのAWSの連携ツール
  • 1