タグ

ブックマーク / gihyo.jp (49)

  • 自動化エンジニアのロールモデルを探せ!! 「システムテスト自動化カンファレンス2015」参加レポート | gihyo.jp

    さらに開発者サイドからの意見のみならず、マネージャーに扮した水野さんからマネージャーサイドの意見が出ました。マネージャーの思考の流れを説明したあと、開発者は自動化の効果を数値で説明することで、マネージャーと価値を共有する必要があり、さらには『組織が儲かる』という視点からロジックを整理することが重要であると説きました。 開発者とマネージャーの意見がバランスよく織り交ぜられ、良く練られたセッションだと感じました。良いものを作りたいがゆえにコスト意識が薄くなることがある開発者にとってハッとすることが多かったのではないでしょうか?昨年のレポートでも書きましたが、みうみうさんのプレゼンはあまりに熱すぎて文字では半分も伝えることはできません。みうみうさんのプレゼンをライブでご覧になることをオススメします。 広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと/森下 大介(ヤフー株式会

    自動化エンジニアのロールモデルを探せ!! 「システムテスト自動化カンファレンス2015」参加レポート | gihyo.jp
  • 第9回 pt-query-digestを使って遅いクエリーを発見する | gihyo.jp

    遅いクエリーの調査をしてみようとして、実運用環境でスロークエリーログを出力してみたところ、思っていたよりもたくさん出力されていしまい、もはや何が起こっているのかわからなくなってしまうことはありませんか? スロークエリーログにいくら有益な情報が入っているとはいえ、数が多くなってしまうと一個一個確認していくのには気が遠くなるような時間と根気が必要となってしまいます。せっかくのIT技術を使っているのに人手による努力はなるべく避けたいものです。ということで大変なスロークエリーログの集計はPCやサーバにやってもらうことにしましょう。 そこで今回は、PERCONA社が公開しているPercona Toolkitのうちの、MySQLのクエリーから統計を取って教えてくれるpt-query-digestというコマンドツールについて説明をしていきます。 デモンストレーション環境 今回使用する環境は第7回 スロー

    第9回 pt-query-digestを使って遅いクエリーを発見する | gihyo.jp
  • 第8回 Elasticsearchの基礎を学ぶ:聞いたら一生の宝,プログラミングの基礎の基礎 |gihyo.jp … 技術評論社

    はじめに みなさんこんにちは、teratail開発チームの橋佑介です。 昨今のWebサービスでは、以前のようにユーザが努力をして興味のあるコンテンツを探すサービスから、キュレーションサービスのようにユーザの興味を分析し配信することが重要とされています。 以前からも、ユーザの動向を分析するために、開発者はさまざまな手段を用いてユーザの興味に合った情報を配信することを実現してきましたが、得られるデータがユーザのサービス内のアクティビティのみだったため、決して精度が高いものとは言えませんでした。 現在では、莫大で多様なデータを取得することが可能になったため、ユーザの興味に近い情報を分析することが可能になりました。そのため、データをそのまま蓄積するだけではなく、各データに属性や情報を付与するなど、高度で柔軟性の高い検索・分析が行える全文検索システムに注目が集まっています。 Luceneという全文

    第8回 Elasticsearchの基礎を学ぶ:聞いたら一生の宝,プログラミングの基礎の基礎 |gihyo.jp … 技術評論社
  • 第2回 ストリーミング処理とバッチ処理によるデータ収集 ~ Fluentd編 ~ | gihyo.jp

    上記のパラメータを元に生成されたログは下記のようになります。 変更後のアクセスログ time:2015-07-26 08:58:20 +0000 domain:52.69.91.201 host:153.232.253.97 server:172.31.6.70 ident:- user:- method:GET path:/index.html protocol:HTTP/1.1 status:200 size:3256 referer:- agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7 Safari/600.7.12 response_time:795 cookie:- set_cookie:Apache=2a4375

    第2回 ストリーミング処理とバッチ処理によるデータ収集 ~ Fluentd編 ~ | gihyo.jp
  • PHP処理系の未来 | gihyo.jp

    PHPユーザーの皆様、あけましておめでとうございます。稿ではPHPとHHVMの2つのPHP処理系について紹介します。今後のPHPのトレンドを占うのにお役立ていただければ幸いです。 PHPの現在 稿執筆時のPHPの最新バージョンは5.6.4です。最近のPHPはマイナーバージョンアップを1年ごとに繰り返すスタイルになっており、PHP 5.6.0はPHP 5.5.0から14ヶ月後の2014年8月にリリースされました。PHP 5.6ではphpdbgという新デバッガが同梱されるようになるなど注目点もありましたが、過去のバージョンアップに比べると変化が小さいバージョンアップでした。 ところで、PHPの次のバージョンアップではメジャーバージョンアップを予定しており、バージョン番号としては7.0となります。メジャーバージョンが5から7へと一気にジャンプするのは珍しい現象ですが、過去に開発中止となったP

    PHP処理系の未来 | gihyo.jp
  • 第25回 cron周りのベストプラクティス(1) | gihyo.jp

    連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはsongmuさんこと松木雅幸さんで、テーマはcronです。 なお稿のサンプルコードは、誌サポートサイトから入手できます。 cronとは? cronは指定日時にジョブの自動実行を行うジョブスケジューラです。UNIX系のOSであれば実装の違いこそあれ、ほぼ標準でインストールされています。 作業自動化や、タスクを自動実行したいなどといった場合にcronは避けては通れません。Perlでバッチ処理を書く際などに多くの人が活用していると思いますが、ベストプラクティスがわからず恐る恐る使っている人も多いのではないでしょうか。 稿では、cron活用におけるベストプラクティスについてお話します。 cronの使いどころ cronの使い途は、主に次の3つが考えられます。 a.アプリケーションのジョブの実行 b.システムに関わる

    第25回 cron周りのベストプラクティス(1) | gihyo.jp
  • 第1回 自動文書検査ツールRedPenとは? | gihyo.jp

    はじめに 連載ではRedPenという自動文書検査ツールの紹介とRedPenを利用した技術文書の校正方法について説明します。RedPenはオープンソースプロジェクトで、現在もゆっくりと開発が続いています。RedPenのホームページは次のとおりです。 http://redpen.cc RedPenは技術文書をターゲットにした文書の自動検査ツールです。技術文書にはマニュアルやチュートリアル、論文、仕様書等が含まれます。この記事のようなソフトウェアツールの紹介文書はもちろん技術文書の一つといえます。第1回の今回は、はじめに技術文書の特徴を解説し、その後RedPenを開発した動機について紹介します。記事の後半では、RedPenの特徴と利用方法について解説します。 技術文書の特徴 RedPenが対象とする技術文書ですが、作文や日記、文学作品等とは大きく異なる特徴をもちます。 最大の違いは、技術文書に

    第1回 自動文書検査ツールRedPenとは? | gihyo.jp
    wate_wate
    wate_wate 2014/11/17
    後で
  • [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp

    第16回プログラミング言語とTDDは、どちらを先にマスターすべきか? 和田卓人 2007-12-21

    [動画で解説]和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
  • 第4章 何を学ぶか、何を作るか―問題の探し方と成果の出し方 | gihyo.jp

    第2章で、目的を明確にして必要なところから学ぶのが効率が良いと学びました。第3章で、理解を深めるうえで、実際に何かを作ることで理解を検証しながら進むのがよいと学びました。 しかし「何を学べばよいかがわからない」「⁠作って学ぼうにも、何を作ればよいかがわからない⁠」⁠─⁠─そういう悩みをお持ちの方も多いかと思います。章ではその悩みをどうやって解決するかを学びます。 やれと言われたことをやる 「何を学べばよいかがわからない」と言う人は多いですが、その人が何も学んでいないかと言うと、そうではないように思います。たとえば会社や上司から何らかの勉強を要求されて、行っているはずです。ただ、おそらくその勉強は第1章で解説した「応用対象」軸なのでしょう。「⁠応用対象」軸の知識は社外に露出しにくい特徴があるため、たとえば勉強会や雑誌の記事などで露出しているエンジニアと自分を比べたときに、自分が勉強していな

    第4章 何を学ぶか、何を作るか―問題の探し方と成果の出し方 | gihyo.jp
  • 第3章 どうやって深く理解するか―比較、歴史から学ぶ、作って学ぶ | gihyo.jp

    「いろいろ学んだけど浅い気がする」という不安の声をよく聞きます。よく観察していると、この悩みには2通りのタイプがあります。「⁠深い理解」軸の知識が足りていないタイプと、「⁠抽象化」フェーズのやり方に慣れていないタイプです。 自分の知識が浅い気がする原因 「深い理解」方向の知識が足りない 一つは、ある程度経験を積んだプログラマによく見られるものです。いろいろなことを学んで、それを応用して成果も出している、なのになんだか不安、というものです。 このタイプの人は、自分の中では抽象化を行ってモデルを作ることができているのですが、その理解に名前が付いていません。そのため、自分で気付けなかったり、他人に説明できなかったりします。また、そのモデルが世間でどう呼ばれているのかを知らないため、当は理解できているのにそのモデルについての会話についていくことができず、「⁠自分は理解できていない」と感じてしまい

    第3章 どうやって深く理解するか―比較、歴史から学ぶ、作って学ぶ | gihyo.jp
  • 第2章 最初の一歩をどう踏み出すか―必要なところを学ぶ、全体像をつかむ、写経する | gihyo.jp

    章では「勉強したいと思っているが『やる気』が出ない」という状態を解決し、一歩踏み出す方法について解説します。 やる気が出ない場合、「⁠勉強」を漠然とした大きなタスクとしてとらえていて、その大きさに圧倒されていることがよくあります。ゴールの見えないマラソンでは、走り続ける「やる気」を出すのは難しいことです。もっと近いゴールを設定し、そこまで走ることを目標にすることが必要です。つまり「勉強」をもっと細かいタスクに分割することが必要です。 勉強を分割する方法は次の3つです。 必要なところから学ぶ 大まかに全体像をつかむ 片っ端から写経する 上のものほど効率が良いのですが、より多くの前提知識を必要とします。 必要なところから学ぶ たとえば、プログラミング言語を学ぼうとしているとしましょう。その言語を使って作りたいものが決まっているなら、それに必要なところから学ぶと効率が良いです。この方法は「遅延

    第2章 最初の一歩をどう踏み出すか―必要なところを学ぶ、全体像をつかむ、写経する | gihyo.jp
  • エンジニアの学び方─効率的に知識を得て、成果に結び付ける 記事一覧 | gihyo.jp

    第4章何を学ぶか、何を作るか―問題の探し方と成果の出し方 西尾泰和 2014-07-25

    エンジニアの学び方─効率的に知識を得て、成果に結び付ける 記事一覧 | gihyo.jp
  • 第1章 効率的に学ぶには―知識の3つの軸と学びの3つのフェーズ | gihyo.jp

    新社会人のみなさん、こんにちは。特集は、新しいものを学ぶ際に出会う問題について解決するための糸口を提供するために書きました。 みなさんは、「⁠IT業界は変化が激しいので学び続けることが必要だ」と聞いたことがあるのではないかと思います。そしてそのことに異論はないはずです。だからこそ今、サイトを読んで何かを学ぼうとしているわけですよね。それはとても良いことです。 一方で、「⁠学びたいけど時間がない」「⁠何を学んだらよいかがわからない」「⁠社会人として成果を出していける自信がない」などの悩みを抱えている方も多いです。筆者はこの悩みを解決したいです。 限られた文字数では、みなさんの個別の問題を解決することはできません。そこで、みなさん自身で問題を解決していくための糸口を提供します。まず章では、第2章以降でより具体的な問題について説明するための材料となる、ちょっと抽象的な話をします。 知識には

    第1章 効率的に学ぶには―知識の3つの軸と学びの3つのフェーズ | gihyo.jp
  • 第2回 コンテナの仕組みとLinuxカーネルのコンテナ機能[1]名前空間とは? | gihyo.jp

    前回は、Linuxで使えるコンテナの実装を説明したあと、LXCを使って簡単にコンテナの作成、起動、停止が行えるところを紹介しました。今回は、そのコンテナの仕組みを簡単に説明し、その仕組みからくるメリット・デメリットを紹介した後、コンテナはカーネルのどのような仕組みを使って動作しているのかを簡単に説明していきたいと思います。 コンテナの仕組み コンテナをまだ使ったことがない方でも、VMwareやVirtualBox、KVMといった仮想マシン(VM)を使ったことはあるという方は多いのではないでしょうか。まずはVMとの比較をしながら、コンテナの仕組みを説明してみましょう。 図1 VMとコンテナの仕組み(1)仮想マシン VMでは図1のように、コンピュータの上で動くOSやVMを実現するためのハイパーバイザの上で、実際のハードウェアをエミュレートするVMが動きます。つまり実際の物理的なコンピュータと同

    第2回 コンテナの仕組みとLinuxカーネルのコンテナ機能[1]名前空間とは? | gihyo.jp
  • 継続的Webサービス改善ガイド 記事一覧 | gihyo.jp

    第5章ビジネス視点の改善~効果検証に基づく機能改善と、チームでの仕事の進め方 安宅啓 2014-02-21

    継続的Webサービス改善ガイド 記事一覧 | gihyo.jp
  • 情報推薦システムの基本 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    情報推薦システムの基本 記事一覧 | gihyo.jp
  • Mahoutで体感する機械学習の実践 記事一覧 | gihyo.jp

    第2回「ある商品といっしょによく売れる商品は何か?」を見つけるには ~マーケット・バスケット分析の考え方 やまかつ 2013-03-06

    Mahoutで体感する機械学習の実践 記事一覧 | gihyo.jp
  • 第4回 MongoDBのレプリケーションを構築してみよう | gihyo.jp

    はじめに 今回は、MongoDBのレプリケーションについて説明します。 最初にレプリケーションの概要を説明します。次に実際に構築する手順を説明した後、レプリケーションに必要な設定項目について解説します。最後にMongoDBのレプリケーションで重要な機能であるOplog、書き込み保証などについて解説します。 前回の記事の最後に、シャーディングについて説明すると書きましたが、予定を変更しましてレプリケーションから先に説明します。シャーディングは次回取り上げる予定です。 レプリケーションのメリット まずは、MongoDBが採用しているマスター/スレーブ方式のレプリケーションの一般的なメリットについて説明します。マスター/スレーブ方式のレプリケーションは以下のようなメリットをもたらします。 可用性の向上 レプリケーションは主に冗長性を得るために設計され、多くのプロダクション環境で導入されています。

    第4回 MongoDBのレプリケーションを構築してみよう | gihyo.jp
  • 第2回 MongoDB 2.2の新機能 | gihyo.jp

    今回は、MongoDB v2.2リリースノートをもとにv2.2で追加/改善された機能を紹介します。機能についてより詳しく知りたい方は第3回丸の内勉強会の資料を参照ください。コマンドレベルでの手順や、一部機能の検証が載っています。 新機能ダイジェスト 1.並列処理の強化(Concurrency Improvements) ロックの粒度がGlobalロックからDBロックになりました。 PageFaultアーキテクチャが改善されロック時間が減りました。 2.Aggregation Framework 集計処理がコマンドで可能になりました。 3.Replica SetsのReadノード選択 一貫性レベルに応じて、どのノードからデータをReadするかを選択可能になりました。 4.Tagを使用したSharding(Improved Data Center Awareness) データ保存先のShard

    第2回 MongoDB 2.2の新機能 | gihyo.jp
    wate_wate
    wate_wate 2012/12/05
    後で
  • 第16回 生産性を上げるソースコードの書き方 | gihyo.jp

    ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」(⁠death march)と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その

    第16回 生産性を上げるソースコードの書き方 | gihyo.jp