第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
第5回 チューニングのために理解しておきたいGCの4つのアルゴリズム | gihyo.jp
なぜアルゴリズムを学ぶのか GCによる停止時間が長くなり、アプリケーションの処理時間が短くなると、業務に使える時間が短くなってしまいます。その問題を解決するために、GCをチューニングすることで、アプリケーションの停止時間を短くすることが考えられます。 その際大事なのは、GCのアルゴルズムを把握しておくことです。 GCのチューニングを行うときは、GCで行われている処理の内、どの処理に時間がかかっているかをモニタリング⇒分析⇒チューニングする、という流れになります。しかし、GCのアルゴリズムを知らないと、モニタリング結果を見てもどこに問題があるかがわからず、分析やチューニングを行うことができません。 今回は、以下の4つのアルゴリズムをご紹介します。 マーク＆スイープGC コンパクション コピーGC 世代別GC GCのアルゴリズムはJVMの実装によって異なりますが、多くの場合、上記4つのアルゴリ
第1回 福森匠大（sora_h）～高校に進学せず、週3でITベンチャーに通うはたらきかた | gihyo.jp
右も左もわからないシューカツ中の女子大生・つつみともよが会社訪問。第1回はクックパッドで働き始めたばかりの@sora_h。なんと現在15歳の若きRubyコミッターを訪ねました。 クックパッドの台所にて。この日はクックパッドのみんなと手打ち蕎麦を作ったとか 「うちで働いてみる？」 ともよ：年齢を知ってびっくりしたんですが、そらはーくん、私より7歳も若い（のに働いてる）なんて……！ sora_h：今は高校に進学せず、クックパッドで働いています。中学にも、最初の半年を除いてほぼ行ってないです。学校に行かず家でコード書いてるか勉強してるか、インターネットしてました。 ともよ：勉強は嫌いじゃなかったんですね。 sora_h：単純になじめなかっただけかなあ。話題が合う相手がいなかったんです。高専進学も考えたんですが、中3の秋に高専カンファレンス[1]行ったあたりから、なんとなく、高専行っても一緒かなと
海外テック情報局：あなたのFacebookソーシャルのパスワードは実は3つあります｜gihyo.jp … 技術評論社
毎日の生活に欠かせないサービスになりつつあるFacebookですが、ログインに使われるパスワード認証が少し変わった挙動をしているという事実が話題になっていました。特に意識していなくても実は最大で3通りのパスワードでログインができるということが確認されています。 自分が決めたままのパスワード 自分が決めたパスワードの大文字を小文字に、小文字を大文字に入れ替えたパスワード パスワードの1文字目が小文字だった場合はそれを大文字にしたパスワード この一見不可思議な挙動は、Caps Lockが意図せずに入ってしまっているケースや、スマートフォンなどで最初の1文字目が自動的に大文字になって入力される場合を許容するための挙動であることがFacebook広報担当からの回答として2011年9月のZDNetの記事でも言及されており、実は既知の事実だったようです。 このような入力間違いを許容するという仕様は斬新
第31回 Grailsライクにデスクトップアプリケーションを構築する「Griffon」 | gihyo.jp
Griffonとは 今回はGrailsと同様の使い勝手でデスクトップアプリケーションを構築することができる「Griffon」を紹介します。Grailsは、JVM言語Groovyを使って、Ruby on RailsのようにコマンドラインベースでWebアプリケーションを構築することができるフレームです。Griffonはその使用感をデスクトップアプリケーションの開発に適用したフレームワークで、簡単なコマンドでMVC準拠のアプリケーションを構築・実行することができます。 Griffonの主な特徴としては、次のような項目が挙げられます。 シンプルなコードでMVCアプリケーションを実現できる JavaおよびGroovyの資産が利用できる 各種Groovy Builderが適用できる プラグインによる拡張が可能 AppletやJava Web Startで公開可能なパッケージ生成機能を備えている Gri
日本Scalaユーザーズグループ設立 | gihyo.jp
2011年12月10日、日本Scalaユーザーズグループが設立された。Scalaはオブジェクト指向の関数型言語である。既存のJavaライブラリ資産が利用できるなどJavaとの高い親和性を持っており、Twitter、LinkedIn、VMware、など多くの企業で採用されつつある。 日本Scalaユーザーズグループは、盛り上がりつつあるScalaコミュニティのハブになることを目指しており、コミュニティ間の交流・コラボ促進やScalaの採用事例を集積していく活動をしていく。 日本Scalaユーザーズグループは現在、ロゴ作成や記事執筆・翻訳などの協力者を募集している。 日本Scalaユーザーズグループと第2回Scala会議参加者の皆さん Twitter公式アカウント：@scala_jp 公式サイト：http://jp.scala-users.org/ メーリングリスト：http://groups
日本Ruby会議2011 1日目レポート［更新終了］ | gihyo.jp
本日7月16日(土)から18日(月）までの3日間にわたり、練馬文化センターにて日本Ruby会議2011（略称：RubyKaigi2011）が開催されます。本ページでは、1日目の模様を随時レポートしていきます。 スタッフの皆さんは朝から集まり、当日準備が行われました。 スタッフの方は、専用のTシャツ、STAFF腕章をつけていますので、もし会場で困ったことなどがあれば相談してみましょう。 オープニング 実行委員長、高橋征義さんの挨拶 本イベントの実行委員長である高橋征義さんからオープニングの挨拶があり、そのなかで「RubyKaigiは2006年から数えて6回目で、集大成かつ一つの区切りとなる最後にして最高の日本Ruby会議を楽しんでいってほしい」と述べました。 笹田耕一さん「日本Ruby会議2011［+α］プログラムについて」 続いて、プログラム委員長である笹田耕一さんから、これまでのRu
第2回 業務改善のキッカケ――“気づきのプロセス”と“自分が困るプロセス” | gihyo.jp
業務改善の“やらされ感”をなくする方法とは 傍観者ばかりの“無関心な現場”で進める業務改善。あなたが部門の責任者や、改善活動の事務局など改善活動を率先する立場だったら、どのように進めていくでしょうか？ 一般に、業務改善は即効性のある効果が期待されることが多く、どうしても現場には「改善効果のアウトプット」が早く求められます。しかし、そこには動かない現場。変わりたくない社員という大きな壁が立ちはだかります。あなたはそんな現場に対して、イラッとしてしまうかもしれません。 「二度とやるものか…」と思っている社員に対して、頭ごなしに「やれ！」と言っても、うまくいかないのは目に見えています。改善に対する“やらされ感”をなくし、当事者意識を持たせていくかが業務改善の成功の鍵となります。 今回は、この“やらされ感”をいかに感じさせることなく、自ら積極的に関わっていくようにしていくかを考えてみま
HTTPサーバにJava NIOは必要か | gihyo.jp
金床氏によるブログ記事です。金床氏はWebアプリケーションセキュリティに造詣が深く、書籍を著していたりJavaによるWAF（Web Application Firewall）やHTTPプロキシツールを開発していたりします。その中のWAFである「Guardian@JUMPERZ.NET」のアーキテクチャはスレッドプール＋ブロッキングI/Oを採用しており、世でC10K問題[1]の解決案とされている非同期I/Oを利用したものではありません。そして世間で注目されているJava NIO（New I/O）を利用した場合、本当によりスケールするのか検証を行っています。 実際にNIOベースに書き換えるのはハードルが高いため、NIOで実装しているいくつかのプロダクトを試しています。TomcatのNIOモードとGuardian@JUMPERZ.NETでベンチマークをとったところ、どちらも十分なパフォーマンスを
diffの動作原理を知る～どのようにして差分を導き出すのか | gihyo.jp
UNIXの基本的なコマンドの1つであるdiff。 これに実装されているアルゴリズムは実に興味深い世界が広がっています。 本稿では、筆者が開発した独自ライブラリ「dtl」をもとに「diffのしくみ」を解説します。 はじめに diffは2つのファイルやディレクトリの差分を取るのに使用するプログラムです。 ソフトウェア開発を行っている方であれば、SubversionやGitなどのバージョン管理システムを通して利用していることが多いかと思います。本稿ではそのdiffの動作原理について解説します。 差分の計算の際に重要な3つの要素 差分を計算するというのは次の3つを計算することに帰結します。 編集距離 2つの要素列の違いを数値化したもの LCS（Longest Common Subsequence） 2つの要素列の最長共通部分列 SES（Shortest Edit Script） ある要素列を別の要
マネタイズとアウトプットを意識する～エンジニアの視点から考えるネットサービス：エンジニアブレークスルー#02レポート | gihyo.jp
マネタイズとアウトプットを意識する～エンジニアの視点から考えるネットサービス：エンジニアブレークスルー#02レポート エンジニアがどのようにしてブレークスルーしていけるか エンジニアブレークスルーは、その名のとおり「エンジニアがどのようにブレークスルーしていけるか」をテーマに、株式会社ゼロスタートコミュニケーションズ 山崎徳之氏を中心にスタートした活動。10月7日に、スタートアップデイティングの一企画として第1回が開催され、今回初の単独開催として、第2回目開催の運びとなった。今回は二部構成で、一部がパネルディスカッション、二部がパネリストと参加者の交流を兼ねたエンジニア査定大会が実施された。 イベントの企画者でもあり、モデレータを務めた山崎氏。 エンジニアの視点から考えるネットサービス 今回のパネリストは以下の通り。 米林正明 氏（株式会社Abby） 閑歳孝子 氏（株式会社ユーザーローカル
ソーシャルWebやHTML5/CSS3のポイントが解説された「Web Directions East 2010」レポート（前編） | gihyo.jp
ソーシャルWebやHTML5/CSS3のポイントが解説された「Web Directions East 2010」レポート（前編） 11月15日、Webとビジネスをつなぐ“発想と創造”をテーマに掲げるカンファレンス「Web Directions East 2010」が野村コンファレンスプラザ日本橋にて開催された。本稿では、前後編に分けて本イベントのレポートをお届けする。 なお、イベントは「デザイン」「マーケティング」「W3C」の3つトラックがあったが、本稿では「デザイン」トラックのレポートとなる。 オープニング はじめに、Web DirectionsのオーガナイザーであるJohn Allsopp（ジョン・アルソップ）氏と、Web Directions Eastのオーガナイザーの菊池氏より、今年のカンファレンスの開始が宣言された。 写真1 オーガナイザーのJohn Allsopp氏と、
日本Hudsonユーザー会も発足した「Hudson勉強会」活動報告 | gihyo.jp
11月12日金曜日、Hudsonの生みの親である筆者の訪日にあわせて、法政大学情報科学部、Seasarファウンデーションの後援で、Hudson勉強会（またの名を「日本ビルド職人の集い」）が開催されました。200人以上集まる大きなイベントとなり、様々な発表やLTが行われました。その模様を報告します。 「Hudson初心者向けデモ」 まず、cactusmanさんによる、Hudsonをさわった事のない人向けへの紹介とデモが行われました。「java -jar hudson.war」で起動できるのが大変便利だとし、Hudsonからはスケジューリング、チェックアウト、ビルドの実行、結果のまとめ、ビルドの通知などができると紹介されました。 デモでは、Subversionリポジトリ上に格納されたMaven2プロジェクトをビルドする様子を紹介し、コミット後すぐにビルドが始まる様子や、新しいテストを追加
第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
#4 トークセッション「アジャイルと大規模開発、品質、そしてコスト」 | gihyo.jp
セミナーの最後に開催されたトークセッションでは、アジャイルに関しての研究報告に続き、アジャイルについて、品質や大規模開発、コストなどの課題をパネラーがそれぞれの立場から回答しました。 アジャイル開発QIMP研究会研究報告 第1部のアジャイル開発QIMP研究会研究報告発表について、研究会事務局を務めるテクノロジックアートの代表取締役である長瀬嘉秀氏から、研究報告の概要が紹介されました。 長瀬氏は「2009年10月から4回にわたり、メーカーやSIer、製品ベンダーなどの有志により議論された『アジャイル開発QIMP研究会』の成果報告をまとめました。大規模アジャイルプロジェクトにおける課題への対応策、課題解決の考え方を検討し、非常に踏み込んだ内容になっていますので、アジャイル開発をこれから始める方や、導入を検討している企業、担当者方などにとって大いに参考になると思います」と述べました。具体的な内容
#3 セッション3「ツールを使ったアジャイル」＆適用事例「楽しくプロセス改善」 | gihyo.jp
セッション3「Going Agile with Tool」 マイクロソフトの長沢氏によるセッションでは、アジャイル型開発へのツール適用のポイントと、アジャイル型開発に有効な「Visual Studio Team Foundation Server 2010」の機能を紹介しました。 より導入しやすくなったTFS マイクロソフト（株） デベロッパー＆プラットフォーム統括本部のエバンジェリスト・シニア プロダクト マネージャである長沢智治氏は、セッション「Going Agile with Tool」を行いました。このセッションは、アジャイル型開発へのツール適用のポイントと、「Visual Studio Team Foundation Server 2010（以下、TFS）」という選択肢の存在を知ってもらうことを目的としたものです。 長沢氏はまず、ツールの活用で期待できることは地味なコス
見えてきたHadoopの“使いどころ”─「Hadoop Hack Night Vol.2」開催 | gihyo.jp
見えてきたHadoopの“使いどころ”─「Hadoop Hack Night Vol.2」開催 8月4日、六本木ミッドタウンのヤフー株式会社にて、今回で2回目となるHadoopをテーマにしたイベント「Hadoop Hack Night Vol.2」が開催された。 Hadoop（ハドゥープ）は、いま注目のクラウドコンピューティングなどに利用されているMapReduce技術が使えるオープンソースソフトウェア。大規模なデータの解析処理などに分散システムを利用したい場合に大きな力を発揮する。 このように注目を集めているHadoopだが、実際に数テラバイト以上といった大容量のデータを処理しなければならないケースはまだそれほど多くない。大きな期待を集めながら「生きた実例」に乏しいのもHadoopをめぐる1つの状況だろう。そこで、今回の「Hadoop Hack Night Vol.2」は「ケーススタディ
第1回 WebSocket登場までの歴史 | gihyo.jp
はじめに 初めまして。NTTアドバンステクノロジの金城と申します。幸運にも記事を執筆させていただけることになりました。WebSocketという新しいウェブの規格についての連載を、全4回の予定でお届けします。 用語統一について WebSocketは「WebSocket」「WebSockets」、単語を切り離した「Web Socket」等、表記に揺れがあります。2009年12月22日のワーキングドラフトのタイトルは「The Web Sockets API」となっていますが、2010年4月26日のエディターズドラフトでは「The WebSocket API」となっています。この連載では、最新の仕様書に則り、用語を「WebSocket」で統一します。 HTML5とWebSocketの関係 WebSocketは、もともとHTML5の一機能として仕様の策定が進められていました。しかし、Web S
第43回 Rails 3を支える名脇役たち その1 - Arel - | gihyo.jp
はじめに Ruby on Railsの2年半ぶりのメジャーバージョンアップである3.0の正式リリースがいよいよ間近に迫ってきました。 Rails 3は、アプリケーション・レベルではRails 2.3との互換性をなるべく保ちながらも、メジャーバージョンアップだけあってフレームワーク自体は隅々にまで徹底的なリファクタリングが施されて更なる洗練を遂げています。結果として、Rails 3では融通の効かないフルスタック構造を捨ててすっきりとしたモジュール独立性が実現されているのですが、この際に、Merbとの合併の影響もあってか、いくつかの新たな外部ライブラリに依存する形になっているのも興味深いところです。 そこで本稿では、あえてRails 3そのものではなく、このRails 3の大改造の舞台裏を支える裏方さんにスポットライトを当ててみたいと思います。 Arelによってパラダイムが大きく変わったAct
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gihyo Digital Publishing … 技術評論社の電子書籍