オープンセミナー岡山 2017/05/13 講演資料
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」=「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
遊びに使えるWebサービスを友人と一緒に作成中。 仕事じゃなかなか使えないようなツールやサービスを無料の範囲内で使ってみてるんですが、かなり便利。 忘れないようにまとめてみます。 なおJavaとJavaScriptを使ってるので、それに関する内容が多いかも。 なお、次のような感じで開発進めてます。 週に1回集まってミーティング兼もくもく会 集まらない日は各自のペースで作業 機能などを作ったらプルリクエスト出して承認もらって取り込む サーバー側がJavaでクライアント側がJavaScript BitBucket Gitリポジトリをホスティングしてくれるサービス。 他にも類似サービスはいろいろあったけど、非公開リポジトリを無料で作れるってのが決め手。 基本的にソースコードはここで一括管理して、各自が作った機能とかは必ずプルリクエストを出す運用で活用中。 ReadmeとかWikiも便利で、ここに
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
2015.05.18 ITニュース 弊誌では先月、「New Order—現代のゲームチェンジャーたち—」と題した大型特集を組み、テクノロジーを駆使して新しいスタンダードを生み出そうとする各界の「ゲームチェンジャー」の仕事術や思考法を紹介した。 しかし、そういった学びを得たからといって、現実には全ての人や企業が、ゲームのルールを決める側に立てるわけではない。むしろゲームの一プレイヤーとして、めまぐるしく変わるルールに翻弄されながらも、自分たちにしか生み出せない価値を追求し続けるのが大半の立場だろう。 先ごろエンタープライズ向けクラウドサービス『知話輪(chiwawa)』をリリースしたシステム開発ベンチャーのドリーム・アーツもまた、時代の変化に直面し、このほど一つの大きな決断を下した。1996年の創業からCTOを務めてきた前川賢治氏が退任し、ひと世代下の石田健亮氏へと世代交代したのだ。 人の出
絶対に押さえておきたい、超高速システム構築5要件と3つのテクノロジ:クラウド時代のアジャイルシステムインテグレーション(2)(1/4 ページ) 多くの企業にとって“クラウドファースト”がキーワードとなっている今、クラウドを「適切に」活用する能力はSIerやIT部門のエンジニアにとって必須の技能となっている。今回はビジネス要請にアジャイルに応える「クラウドファースト時代のシステムインテグレーション」に必要な要素技術を解説する。 連載目次 クラウド時代のアジャイルなシステムインテグレーション 前回はクラウドが多くの企業に浸透している現状とともに、従来の「システムごとに最適化された、手作業を前提としたシステムインテグレーション」と、「クラウドを前提としたアジャイルなシステムインテグレーション」の違いを解説しました。今回はもう少し踏み込んで、後者のスタイルを実現するための要素技術を解説したいと思い
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 これから話すことは――少なくとも今年いっぱいは――他言無用、と念押しし、私たちが全員うなずくのを確認した後、瀬川部長はゆっくりと話し始めた。 もう何年もうちの会社の業績が落ち続けているのは、全社員が痛いほど認識している通りだ。本来ならとっくにAS/400などのメインフレーム開発から、Webシステム開発にシフトしていて然るべきだったのだが、CS、公事の両部門の反対、とまではいかなくても、消極的な態度から実現してこなかった。むしろ、Webシステム開発部をコスト部門として切り捨てる道を選ぼう、という意見が大勢を占めていたのだ。瀬川部長はCS部の部長も兼務しているから、その意見を押しとどめていたものの、Webシステム開発部の連続した赤字、という事実は、いかんともしがたくのしかかっていた。
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
【書評】『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』(細川義洋・著) 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら?」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
Analytics Toolbox: 50+ Ways to Track Website Trafficというエントリーより。 From analyzing your RSS feed to counting page views to visual representations of where your visitors are clicking, there is no shortage of companies looking to help you better understand your web site’s traffic. ウェブサイトのトラフィックを分析するための、50の方法が紹介されているエントリーです。 一口で言うと、アクセス解析ということになるのだと思いますが、様々なサイトがあるのですね。 カテゴリーとしては、 ・Web Traffic Visualizati
最終更新日:2001年5月1日 第1章へ webmaster@snap-tck.com Copyleft (C) 2000 SNAP(Sugimoto Norio Art Production)
こんにちは! やまもと@テスト番長です。 プロダクトの品質を上げるには、会社ぐるみで品質管理に取り組む意識が重要です。 より良いソフトウェアテストを実現する為の企業文化として、大事だと思うことを幾つか挙げてみたいと思います。 新人にまずやってもらうことは? 新人テスターをいきなりテストに参加させるのは良くありません。製品への理解が深くないと有効なテストは出来ないからです。 まずは製品の仕様を覚えてもらったり、バグレポートの書き方を覚えてもらったりしなくてはいけないのですが、仕様書をポンと渡して、「これを見ながら製品を全部動かしてみて」といった指示を出しても現実味がなくモチベーションは揚がらないでしょう。 最初にやってもらうことは、先輩テスターの書いた障害報告の再テストか、 画面遷移図の更新など手探りで学習しながら行えることが良いと思います。 極力固定したビルドでテストする テスト対象の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く