Scalaスタイルガイド¶ EPFLの提供する公式スタイルガイドや，Artimaのようなコミュニティサイトによる非公式ガイドの代わりに，殆どの場合に従うべきScalaのスタイルにおけるガイドラインの概略を示す事を意図してこの文書は作られました。このガイドでは，なぜそのスタイルが推奨されるのか，またその代替案がどのようにしてそのスタイルに関連するのかを，できる限り多くの箇所で詳細に記述するよう努めています。他の全てのスタイルガイドと同様に，この文書もいずれ破られるルールの一覧として扱ってください。ここで提示するスタイルよりも好ましい別のスタイルがきっと現れるはずです。 コンテンツ:

Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) Table of Contents Introduction Formatting: Whitespace, Naming, Imports, Braces, Pattern matching, Comments Types and Generics: Return type annotations, Variance, Type aliases, Implicits Collections: Hierarchy, Use, Style, Performance, Java Collections Concurrency: Futures, Collections Control structures: Recursion, Returns,

この「らくらくISO9001講座」は、できるだけ多くの企業にISO9001やその他のマネジメント

ISO27001,ISO9001,ISO22000,IATF16949,ISO/TS22163の取得なら｜警告！読むまで取るなISO－アイソ・ラボ株式会社 知っていますか？ ISO取得企業のナマの声 「大変！大変！超大変！ダメだこりゃ～ッ！」 ISOを自ら取って、自ら運用した経験を持つ私には、その気持ち、よ～くわかります。私もそう言いたかった。ちっともうまく行かずに嘆きました。周りからいやな顔をされことも多々ありました。 その後コンサルタントとして独立。多くの会社のISO取得をお手伝いし、分かった事があります。 ● 取得後の皆さんの悩みは、ほぼ同じ。 ● 何が原因で大変になるのか、それもほぼ同じ。 ● 規格の解釈でよく間違えるところも、ほとんど一緒。 ● その原因が【取る前の段階から】始まっていること。 ● 誰が原因でうまく行かないか？！ ISO自体が大変なのではありません。ISOを大変な

Copyright © 2004-2025 Impress Corporation. An Impress Group Company. All rights reserved.

上流の会社が最近 PHP_CodeSniffer によるスタイルのチェックを推奨しているらしい。そんなもので縛らなくてもまともなコード書ける人ばかりだといいんだけど・・・うちでもたまにひどい人がいるから文句言えない。（平気で 8 タブでインデントするような人もいたし。見たとき眩暈がした・・・。） PHP_CodeSniffer では自分でコーディングスタイルの基準を定義したりもできるんだけど、組み込みの基準も何種類かあったりする。その基準で PEAR と Zend 以外に言及してる人が少なかったから、まずはそこについて触れておこうかと。 ■インストール >pear install PHP_CodeSniffer-1.1.0RC1 ということで、今回は現時点で最新版である 1.1.0 RC1 で確認してます。 ■--standard オプションについての概要 phpcs を -i オプション

障害処理票の使い方 「第3回：機能をモレなくテストするテンプレート（http://www.thinkit.co.jp/article/140/3/）」では単体テスト、「第4回：要件をモレなくテストするテンプレート（http://www.thinkit.co.jp/article/140/4/）」では結合テストと続けてテストフェーズのドキュメントテンプレートを紹介しました。 その中で出た共通の話題として、品質を把握する際の「定量的な分析」がありました。今回はテストフェーズのまとめとして、定量的な分析にポイントを絞り、品質管理を行うためのテンプレートを解説します。また、顧客側での品質チェックフェーズである受入テストについても、テンプレートとともに、そのフェーズに開発側がどのようにかかわるべきか述べたいと思います。もちろん、今回のテンプレートもダウンロードして活用することができるようにしています

品質の鍵は上流工程にあり SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON（ダンジョン）」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用！業務システムの開発ドキュメント標準化」（http://www.thinkit.co.jp/free/project/4/1/1.html）にて紹介したところ、大変好評でした。 その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、そ

ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第22回は、シーケンス図を使用したモデリングによってECサイトの登場人物と処理の流れを示し、開発対象を洗い出す工程について説明する。

はじめに　大量のドキュメントの執筆作業を複数のメンバーで行うとき、各メンバーの文章表現にどうしても差が出ます。特に、直接ユーザーの目にとまるマニュアルなどは、用語、表現を統一することがとても重要です。　大量の翻訳マニュアルを作成するSun、Microsoftでは、翻訳作業の指針とする『日本語スタイルガイド』を公開しています。本稿では、それぞれの『日本語スタイルガイド』関連情報を紹介します（ガイドラインの内容はそれぞれをダウンロードしてご覧ください）。Sunの日本語翻訳ガイドライン　Sunの翻訳ガイドラインについてまとめたページがあります。Sunの日本語翻訳ガイドライン 　スタイルガイドをダウンロードできます。スタイルガイドのダウンロード（PDF形式） 　スタイルガイドは100ページにおよびますが、4ページにまとめたクイックリファレンスを、翻訳プロジェクトのReiko Saitoさんのブログ

本連載では、製造業の競争力の維持／強化に欠かせないPLMに焦点を当て、データ活用の課題を整理しながら、コンセプトとしてのPLM実現に向けたアプローチを解説する。第4回は「データマネジメントの本質」について考える。

ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と

【楽々デブドックを書こう！】正直使う？ガイドライン 第1回：開発者ガイドラインとはなんだ？ 著者：シンクイット編集部 公開日：2008/02/04（月） 開発ドキュメントはどのように書くべきなのか？ 2月の特集「楽々デブドックを書こう！」では、システム開発の現場で用いられている各種開発ドキュメントについて、さまざまな視点から考察している。この特集を読んでいる読者の方々なら「開発ドキュメントを書く」ことの必要性については、改めて語るまでもなく知識的・体験的に理解しているだろう。 しかし、いざ実際の現場において開発ドキュメントをどのように書くのか、という部分についてはいかがだろうか。実際にシステム開発や運用に携わっている方々に話を聞くと、「何を書けばよいかわからない」「現場では、書いている暇がない」「たとえ書いたとしても活用されることが少なく、その存在意義がわからない」など、問題点も感じている