Please remember this entry will be public in the community library. This is not your personal regex library! To save, access and manage your personal entries, please go to the account page instead.
This Version: https://www.w3.org/TR/2018/SPSD-html5-20180327/ Latest Published Version: http://www.w3.org/TR/html5/ Latest Version of HTML: http://www.w3.org/TR/html/ Latest Editor's Draft of HTML: http://www.w3.org/html/wg/drafts/html/master/ Previous Version: http://www.w3.org/TR/2014/REC-html5-20141028/ Previous Recommendation: http://www.w3.org/TR/1999/REC-html401-19991224/ Editors: WHATWG: Ia
本記事は英語版ブログで公開された記事の翻訳版です。 2013年7月に、米国テキサス州オースティンで開催されたLonestar Ruby Conferenceで、Rubyによるアプリケーションサーバーについてお話させていただきました。その中でいくつかのRubyアプリケーションサーバーのパフォーマンスや、さまざまな状況における挙動の違いを比較しました。この記事では、講演準備として行ったリサーチの中で分かったことをかいつまんでご紹介します。 実際のカンファレンスの録画をご覧になりたい方は、Confreaksで公開されていますのでそちらをご参照ください。テストに使用した簡単な自作アプリケーションはGitHubに、講演スライドはSlideshareにそれぞれ公開しています。 このリサーチは、Passenger 4のパフォーマンス評価以外すべて2013年7月に行ったものなので、情報が多少古くなっている
みんなのウェディングの高井です。 気軽に開発サーバーにデプロイできると便利なことがあります。 たとえば、開発中のブランチをデザイナーやディレクターに確認してもらいたいときがあります。また、プルリクエストのためのブランチが大きくなってしまったから動作をみながらコードレビューしたいときもあるでしょう。 もちろん、手元のマシンでアプリケーションサーバーを起動させ、そのサーバーで動作確認してもらうこともできます。とはいえ、タイミングをあわせてサーバーを起動させるというのも手間です。 そこで、みんなのウェディングでは、開発ブランチを簡単にデプロイして確認できるようにする仕組みを用意しています。 Capistrano 開発サーバーへのデプロイには Capistrano を利用しています。プロダクションサーバーやステージングサーバーに対するデプロイでは AWS CodeDeploy を使っているのですが
こんにちは。UXデザイングループの今泉です。 みんなのウェディングでは、色々な社内勉強会や読書会が行われています。 社内勉強会とは、業務とは関係のない場と時間で、あるテーマに沿った様々な事を勉強する会です。 そのテーマに詳しい人が先生役になり、そこに集まるメンバーの部署や職種はバラバラです。 勉強会は、業務で必要な知識だけではなく、より深く体系的に勉強したい人に向けて開催されています。 なので、参加者は自由に各々の目的を持って参加しています。 また、勉強会よりもゆるくカジュアルに開催しているのが読書会です。 読書会では皆で読みたい本を、一緒に読んで意見交換をしています。 今回はそんな社内勉強会・読書会の様子をご紹介いたします! HTML/CSS勉強会 HTML/CSS初心者向けのHTML/CSS勉強会は、週に3回、定時後に行われています。 学習動画ドットインストールを皆で見て、勉強した内容
みんなのウェディングの高井です。今回は、みんなのウェディングで構築している継続的デリバリーの仕組みについての話です。 継続的デリバリーとは? インターネットサービスを提供していくうえで、とても重要なプラクティスのひとつに「継続的デリバリー」があります。継続的デリバリーとは、ソフトウェアをいつでもリリース可能な状態にしたままで構築していくというソフトウェア開発の規律です。 継続的デリバリーを採用することで、ソフトウェアのリリースサイクルを短かくすることができるようになります。リリースサイクルを短かくすることは、サービスの仮説検証プロセスを短かくすることにつながります。 サービス開発の本質は、どこにあるのか分からないユーザーのニーズをとらえることにあります。ですから、仮説検証の機会を最大化できる継続的デリバリーはサービス開発にとって、欠かせないプラクティスとなるわけです。 完了条件を定義する
みんなのウェディングの高井です。今回のエントリも、若者との対話シリーズとなります。 あるオブジェクトが別のオブジェクトを呼び出すとき、受け渡される情報のチェックをどちらの責務で行なうかという問題があります。呼び出し側でチェックを行なうのがよいのでしょうか。それとも、呼び出され側でチェックを行なうのがよいのでしょうか。 この問題は、結局のところ設計の問題であり、ケース・バイ・ケースであるというのが正解になります。ですから、どのようにケースを見極めるのかという考え方が重要です。 信頼領域 『オブジェクトデザイン』には、この問題のヒントになるアイデアが書かれています。それが、「信頼領域」という考え方です。 信頼領域とは、システムを「信頼するコミュニケーションが発生する領域に切り分け」た領域のことです。システムは、ユーザーとユーザーインタフェースの境界、外部システムとの境界、異なるレイヤーとの境界
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く