トレジャーデータ、データ転送ミドルウェアFluentdの商用版「Fluentd Enterprise」の提供を開始 ―データの暗号化、認証済み各種プラグインも提供 | gihyo.jp
トレジャーデータ、データ転送ミドルウェアFluentdの商用版「Fluentd Enterprise」の提供を開始 ―データの暗号化、認証済み各種プラグインも提供 トレジャーデータ（株）は、同社が中心となって開発しているオープンソースのデータ収集ミドルウェア「Fluentd」の機能を強化し、エンタープライズ向けに商用化した新製品「Fluentd Enterprise」の販売を7月11日より開始した。 Fluentdはもともと共同創業者である古橋貞之氏がオープンソースソフトウェアとして開発し、企業等にも広く使われているデータ収集ソフトウェアの定番の1つ。2016年11月にはCNCF（Cloud Native Computing Foundation）の管理するプロジェクトに認定、トレジャーデータ在籍のコミッターが80％を占めるコミュニティで開発が進んでいる。 今回販売開始となった「Flu
日本のDevOps変革を促進するバリューストリームマッピング | gihyo.jp
アジャイルとDevOpsを組織全体に適用するための指南書『変革の軌跡』が2017年1月25日（水）に発売されます。本書の発売を記念して、マイクロソフトの牛尾剛さんにバリューストリームマッピングについて寄稿いただきました。 バリューストリームマッピングの重要性 みなさんの会社で、DevOps変革を推進するために、最初の第一歩として何をすべきだろうか。筆者は間違いなく「バリューストリームマッピング」をお勧めする。バリューストリームマッピングは、リーン生産方式の技法の1つであり、製品やサービスを顧客に届けるために必要なプロセスを分析するのに使用される。トヨタで使われていた手法をもとにしている。 バリューストリームマッピングの話を始める前に、Gene Kimがまとめた「DevOpsのThree Ways」についてお話ししておきたい。これは、DevOpsの3つの目的を明確にしたものだ。1つ目はアイデ
第3回 常にそこにいろ | gihyo.jp
コミュニケーション能力 将来アメリカで働きたいと思っている若い人たちに会うとよく聞かれる質問がある。「英語とプログラミング以外で大事なことは何ですか」だ。そういう場合は「コミュニケーション能力かな」と答えている。そうすると「やっぱり英語か」と言われたり、キョトンとされたりする。そうなるのもよくわかる。コミュニケーション能力が大事なのは誰でも知っている。就職支援サイトでいくらでもそういう記事を読むことができるだろう。何をいまさらというわけだ。 しかしながら筆者の頭にあるコミュニケーション能力は、 誰とでもすぐに仲良くなる 社交の場でそつなくこなす あまり話したことない同僚とエレベーターでたまたま一緒になっても平気 などではない。筆者はそのようなものは1ミリも持ち合わせていない（いばれることではないが）。筆者はコミュニケーション能力が高いとは、「常にそこにいる」ことだと思う。今回はこの
第1回 堀江大輔―GitHubが成長の中で培ったチームの作り方 | gihyo.jp
今回より始まった本インタビュー連載では、先進的なとりくみを続ける現場に訪問し、チームや個人としてどう成長していくべきかを考えていきます。今回はギットハブ・ジャパンの設立メンバーであり、現在はプログラムマネージャーとしてサポートチーム、コミュニティ・アウトリーチを率いている堀江大輔さんに「成長を続けるGitHubでのチーム作り」をテーマにお話を伺いました。 【インタビューされた人】 堀江大輔（ほりえだいすけ）ギットハブ・ジャパン合同会社 GitHub：dice Twitter：@dice GitHubのプロジェクトチーム ──GitHubの従業員数は今、全社で560人程度だそうですが、チーム数はどれぐらいですか？ 堀江：バックオフィス、営業、セキュリティ、プロダクト、テクノロジ（開発）、サポートなどにチームが分かれています。特に営業と開発が大きいですね。「プロダクト」というのはプロダ
オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
2016年9月2日紙版発売 2016年9月2日電子版発売 Sandi Metz 著，髙山泰基 訳 B5変形判／304ページ 定価3,608円（本体3,280円＋税10%） ISBN 978-4-7741-8361-9 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 オブジェクト指向設計の名著として名高い“Practical Object-Oriented Design in Ruby”，待望の翻訳版！使いこなせるようになるととても便利なオブジェクト指向ですが，「なんとなく」の理解で使っていると，大きな罠にかかってしまいます。本書は，保守性を上げて運用コストを下げるア
第18回 MySQL5.7のデフォルトのSQLモードを確認してみる | gihyo.jp
長い間MySQLを使ってアプリケーションやサービスを提供していると、セキュリティの都合や機能の高性能化によってアップグレードが求められることがあります。アップグレードを行った際にアプリケーションがそのまま動いてくれる場合もあるのですが、SQLモードの設定によって動かなくなってしまうこともあります。 アプリケーションが動かなくなってしまい、仕方がないのでよくわからないけどSQLモードの設定を空にする、なんて事はありませんか？ 今回はそんなSQLモードの確認方法や、デフォルトの設定がどのような意味を持っているのかを紹介していきたいと思います。 デモンストレーション環境 この原稿を書いている時点で最新版である5.7.12を第5回 Dockerで複数バージョンのMySQLを開発環境に用意するで作成した環境で実行して確認していきます。 また、今回使用するデータは第2回 MySQLにはじめてのデータを
YAPC::Asia Tokyo 2015 前夜祭レポート［更新終了］ | gihyo.jp
2015年8月20日（木）から22日（土）までの3日間、東京ビッグサイト 会議棟にて「YAPC::Asia Tokyo 2015」が開催されています。本日は前夜祭。本稿では前夜祭の模様を随時レポートしていきます。 受付など 前夜祭ではトラックDとトラックEでセッションが開催されます。 参加受付は東京ビッグサイト会議棟6階にあります。開始50分前ですが、すでに参加者で賑わっています。 受付自体は機械にQRコードを読み取らせるだけです。 前夜祭はアルコールを含めフリードリンクやお菓子が提供されています。トラックD会場の入口付近には、フリードリンクで「YAPC」の文字が形作られていました。 今年のスタッフはアロハシャツを着ています。なにか分からないことがあれば気軽に聞いてみましょう。 今年の前夜祭は2トラックなので、前夜祭自体の開始の挨拶はなく、諸注意のアナウンスの後、セッションが始まりました。
インメモリ型クラウドでビジネススケールを拡大 | gihyo.jp
SAP HANA Cloud Platform（HCP）は、SAPが提供するビジネスアプリケーション向けクラウドです。インメモリ技術を中核として、データベースサービスとアプリケーションの構築・運用環境をクラウドサービスとして提供するPaaSで、リアルタイム処理、大規模データ解析といった分野にとくに向いています。サービス領域とビジネス領域の技術的障壁が薄れてきた今、Webアプリケーション開発者にとってもSAP HCPを活用する必然性が高まっていると言えます。本稿では、SAP HCPの特徴とほかのクラウドプラットフォームとの比較、また、実際に無料版を導入して試用するまでの手順を紹介します。 SAP HANA Cloud Platformとは クラウド上でシステムを構築してサービスを提供することは、今やビジネスで成功する上では欠かせません。加えて、さまざまな技術の進化・多様化が進んだため、目的に
Hadoopはどのように動くのか ─並列・分散システム技術から読み解くHadoop処理系の設計と実装 記事一覧 | gihyo.jp
第21回Sparkの設計と実装［2］～Sparkにおけるデータ共有の仕組みと耐障害性の実現方法 猿田浩輔，山田浩之 2016-06-08
第3回 「ポエム」がどうやってピクシブ社内へ広まったか？ | gihyo.jp
ピクシブでは「ポエム」によって開発が駆動しています。第3回は「ポエム」がどうやってピクシブの社内へと広まっていったかを、節目となる出来事やその時の「ポエム」とともにご紹介します。「ポエム」で開発を活性化する際に参考にしていただければ幸いです。 ポエムが会社にやってきた 日常の中で出たエモーショナルな想いを共有して欲しい。そんな想いのこもった「ポエム」とともに、「ポエム」とesa.ioというドキュメント共有サービスがピクシブにやってきました。 図1 esa.ioというドキュメント共有サービスがピクシブにやってきた 導入の経緯については、前々回・前回でご紹介しておりますので、ぜひご覧いただければと思います。 初期の利用状況 さて、新しいツールとしてピクシブにやってきたesa.ioですが、導入初期からエンジニアを中心に、10～20人単位での利用が行なわれるようになりました。初めの1週間ほどで
第5回 蓑輪太郎―Twitter本社で働くエンジニアのキャリア | gihyo.jp
先を歩むエンジニアへのインタビューを通してエンジニアのキャリアについて考える本連載、今回はゼロからOSやScheme処理系を作り、現在はTwitter本社で働く凄腕エンジニアのhigeponこと蓑輪太郎さんにお話をお伺いしました。 ［撮影：平野正樹］ 危機感を感じた1社目 ──higeponさんはいつもさまざまなことを勉強なさっていますが、いつごろから自ら技術を学び始めたのでしょうか？ higepon（以下ひ）：2001年に入った初めての会社が大きいSI系で、技術に長けたチームに入れてもらえました。そこではモデルケースになるような優秀な先輩がいて、たとえばトラブルが起きたときに、自分で率先して原因を解明して、周りにも的確に指示を伝えていて問題を解決していたんですよ。その先輩から「しっかりプログラミングを勉強しないとまずいよ」と言われたんですよね。それで自分で実際に勉強をし始めたら、今
第84回 JavaがLL言語化されていた！ | gihyo.jp
「私の環境がおかしいので動きません。あなたの環境で動かしてもらえますか？」と、ある人が勢い込んで私のところにJSPファイルを持ってきました。 仕方がないのでデバックする前にソースコードを読むと、なにやらif文のORのフォントが微妙に違うような……。 なんと||と書くべきところがllとアルファベットのLでORが書かれている！ その上これを指摘すると、「そっちかー！」という返答が。こいつORの存在すらわかってないのか……。 とりあえず見よう見まねで書けるJavaもLL言語ということでしょうか。 ※LL言語：コードの作成や修正が容易なプログラミング言語のこと。主にスクリプト言語を指す。 コメット（男／34歳／プログラマ・SE） あるあるあるあるある…。他にも0とOとか。:と;とか。何よりも憎たらしいのが全角スペースですよ。なんだあれ！だれだあんな文字作ったの！見えねーんだよ！インデントを全角スペ
なぜ、エンジニアの採用は難しいのか？ 記事一覧 | gihyo.jp
第11回（最終回） エンジニア採用の壁を乗り越えるためにすべき5つのこと サカタカツミ 2013-12-27
第1回 Hubotとは何か | gihyo.jp
本連載では、GitHub社が開発したチャットbot開発・実行フレームワークである「Hubot」を使用して、チャットツールにオリジナルのbotを住まわせ、開発フローに組み込むことで開発を楽にする方法について解説していきます。 botとはなにか 開発の現場で、開発チーム内のコミュニケーションのためにIRCなどのチャットツールを導入することは、よく見る光景だと思います。そんなチャットツールに常駐してチャット経由でコマンドを待ち受けて実行したり、決められた条件に従ってチャットに発言してチャットの参加者に通知したりするようなプログラムのことをbotと呼びます。 Skype、HipChatやChatWorkなどコミュニケーションツールが多様化した現代においても、それぞれのチャットツールに対応したbotが開発されており、botを開発するためのフレームワークも様々な形で提供されています。botを導入するこ
GitHub社謹製！ bot開発・実行フレームワーク「Hubot」 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第1回 神獄のヴァルハラゲートの裏側をCTOが語り尽くす！ | gihyo.jp
C#の非同期構文をフル活用し業界最速の応答速度を実現 現在、多くのソーシャルゲームがPHPやPython、Rubyといった、いわゆるLightweight Languageを使って開発されていますが、（株）グラニではプログラミング言語としてC#を採用し、Windows環境で開発および運用を行っています。実は、現在提供している「神獄のヴァルハラゲート」は、2013年1月のリリース時点ではPHPを利用していました。しかし同年4月にC#への移植を開始し、3ヵ月後の7月16日にはC#への切り替えを完了させています。 このようにC#にこだわっている理由の一つがパフォーマンスです。ソーシャルゲームはユーザがアクションを起こすたびにデータが更新されるというしくみ上、どうしてもViewのキャッシュを効かせられなかったり、1万リクエスト／秒を超えるような高負荷が発生したりしますが、そうした状況においても平
チーム開発実践入門──共同作業を円滑に行うツール・メソッド
この書籍に関連する記事があります！ はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが，チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章 チーム開発とは 1.1 1人だけでも開発はできる 1.2 チーム開発で直面する課題 1.3 どのように課題に立ち向かうか 1.4 本書の構成 第2章：ケーススタディ 第3～5章：基礎的なプラクティス 第6～7章：継続的デリバリーとリグレッションテスト 1.5 本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章 チーム開発で起きる問題 2.1 ケーススタディの前提 プロジェクトの前提条件 2.2 ケーススタディ（1日目） 問題1：重要なメールが多
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
Android Studio最速入門～効率的にコーディングするための使い方 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
