タグ

2015年3月10日のブックマーク (9件)

  • チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ

    こんにちは!ChatWork CTOの山です。 先日このブログにて「チャットワークの新しい開発言語とフレームワークを決める開発合宿を開催!その全貌を丸公開します。」という記事で、チャットワークがScalaを採用することを発表しました。 ありがたいことにこの記事はたくさんの方に読んでいただき、大きな反響がありました。セミナーなどでお話する時も、Scala採用について話を聞きたいと言われることが増えています。 今回は、Scala採用にいたったより詳しい背景と、現在の状況、そしてこれからのことについてご紹介できればと思っています。 Scala採用にいたった背景現在のチャットワークは、「PHP + 自社開発の独自フレームワーク」で構築されています。 もともとチャットワークの開発は、社内用のツールとして1人のプロジェクトからスタートしました。そのためあまり工数をかけることはできず、既存の社内システ

    チャットワークがScalaを採用する理由、これからのチャレンジ。 | チャットワーククリエーターズブログ
    WhatAmILookingFor
    WhatAmILookingFor 2015/03/10
    "この1年は、高まるサービスの負荷と戦い続けた1年でした。次々と現れるボトルネックを解消し、たくさんのSPOFをなくし、重たい処理を非同期にして疎結合化することに多くのリソースをかけてきました"
  • チャットワークの新しい開発言語とフレームワークを決める開発合宿を開催!その全貌を丸公開します。 | チャットワーククリエーターズブログ

    みなさんこんにちは、技術部Webチームリーダーの田中佑樹です。 みんなからはたなやんと呼ばれています。Vimが大好きです。 さて、今回は先日開催した2泊3日のChatWork開発合宿の全貌についてご紹介したいと思います。 「開発合宿をやってみたいけど、どうすればいいのかよくわからない」という方の参考になれば嬉しいです。 なぜ開発合宿をすることになったのか? チャットワークは2011年3月の公開以来、順調にユーザー数を伸ばし2014年4月時点で世界170カ国42,000社の企業に導入されるまでに成長しています。 そんな中、現在チャットワークのバックエンドで動いているプログラムが今後の運用において最適ではないのではという懸念があり、言語とフレームワークの再選定をしようという声が上がりました。 ただ、なかなか日頃の業務の中で時間を取るのは難しく、今後のチャットワークを左右する重大な選択なので

    チャットワークの新しい開発言語とフレームワークを決める開発合宿を開催!その全貌を丸公開します。 | チャットワーククリエーターズブログ
    WhatAmILookingFor
    WhatAmILookingFor 2015/03/10
    "最初は一部の特殊な書き方に戸惑うこともあったが、慣れるととたんに書きやすく&読みやすくなる"
  • ATOMエディタの初期設定(vim mode) - Qiita

    軽く使ってみたら意外と好きになれそうだったので、メモ的に残しておきます。 初期設定〜vimモードを入れてみます。 Atomをインストール Atom atomのシェルコマンドのインストール メニューよりAtom → Install Shell Commands vimプラグインのインストール atomではなく、Macのターミナルより下記コマンドを実行します。 apm install vim-mode Atomの再起動 escキー押下時に日本語入力をやめて英数入力にする インサートモードを抜けたときに日本語入力のままだと発狂しかねないので。 KeyRemap4MacBookを使用します。 vimでも同じ設定をしていたので、com.github.atomを追加するだけでした。 Misc $ Uninstallタブを選択し、Open private.xmlを押下。 XMLの編集 Change Ke

    ATOMエディタの初期設定(vim mode) - Qiita
  • Redisのメモリ使用量がmaxを超えた場合の挙動 - Gaishimo

    Redisのメモリ使用量がmaxを超えた場合の挙動について検証してみた。 環境: version: 2.4.16 Redisではタイムアウト時間を設定したキーは時間を超えると自動で削除され、タイムアウト時間を設定しないと永続的に保存される。 また、メモリの空き領域がなくなった場合、期限のあるものから削除されていく(デフォルトの設定の場合)。 注意すべき点は、期限が設定されていないキーは削除対象にならないということである。 実際にその挙動を検証してみた。 まず、検証しやすいようにメモリの使用可能な量を以下の値に設定しておく(redis.conf) #新たにキーを保存した際にmaxmemoryエラーにならないぎりぎりの値 maxmemory 910KB maxmemory-policy は 以下を設定 #LRUアルゴリズムを使用して期限切れになったセットのキーを削除 maxmemory-pol

    Redisのメモリ使用量がmaxを超えた場合の挙動 - Gaishimo
  • Practical DDD #4: ユビキタス言語とモデル

    ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。 思考を図にする書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。 ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理(コンテキストマップや大規模な構造など、第14章と第16章で説明するもの)に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。 エリック・エヴァンスのドメイン駆動設計 第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25) この文章が言わんとしていることを私の理解で図にしてみました。 この図は、上に挙げた段落の

    Practical DDD #4: ユビキタス言語とモデル
  • ドメインモデリング - やさしいデスマーチ

    ユースケース駆動開発実践ガイドの第2章のまとめになります。書籍を読む際の参考になれば幸いです。 ICONIXでの最初のプロセスは、ドメインモデリングになります。ドメインモデルはクラス図のプロトタイプとなる静的な設計図です。また、動的な設計であるユースケースを作成する準備作業になります。 このドメインモデリングで最も重要な事は時間をかけすぎないという事です。これはICONIXが設計を段階的に作成していく特長が大きく現れている所でしょう。また、学習する場合もあまり時間をかけすぎない方がいいと思います。この後のプロセスであるユースケース・ロバストネス分析までの一連の流れを把握することで、ドメインモデルは重要であるが最初のステップで時間をかける事が無意味だということが理解できます。 目的 ドメインモデリングの主な目的は2つあります。 1つ目の目的は、ドメインモデルを用語集(ライブディクショナリ)と

    ドメインモデリング - やさしいデスマーチ
  • StarUML

    StarUML A sophisticated software modeler for agile and concise modeling

  • Redis の仮想メモリはどうなったのか - akishin999の日記

    一時期 Redis の特徴として良く挙げられていたものに、搭載している物理メモリ量以上のデータを扱える Virtual Memory という機能がありました。 仮想メモリ技術仕様 ― redis 2.0.3 documentation http://redis.shibu.jp/hacker/virtualmemory.html 個人的には結構便利そうだと思っていたのですが、公式ドキュメントを見ると 2.4 の時点で非推奨となっており、 バージョン 2.6 ではついに削除されてしまったようです。 Virtual Memory – Redis http://redis.io/topics/virtual-memory 検索しているとその代わりとして diskstore を開発中、といった情報が出てきますが、こちらもインメモリデータベースとしてより良いものを作っていく、ということに注力するため

    Redis の仮想メモリはどうなったのか - akishin999の日記
  • master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成

    GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste

    master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成