Fedoraで自宅サーバー構築
ルーター経由接続によるインターネット常時接続環境である(当サイトはIIJmioひかりによるインターネット常時接続環境) 固定または非固定のグローバルIPアドレス環境である(当サイトはGMOとくとくBBの固定グローバルIPアドレス環境) OSのインストール時を除き、サーバーの操作はWindowsからコマンド操作で行なう ■コンテンツ ※ホスト名やドメイン名、IPアドレスは各自の環境に置き換えること ※各目次に表記してあるバージョンは、当サイトで確認をとったFedoraのバージョンを示しており、そのバージョンでないとできないということではない ※各ページのソフトのバージョンは、当サイトで確認をとった時点のものであり、最新版の有無は適宜確認してください スポンサーリンク Linuxをはじめる前の基礎情報 Linux基礎 Fedoraインストール Fedora Core 1インストール FC1固有
ＲＦＣ日本語版リスト
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
Sledge ドキュメント - にぽたん研究所
先日の Shibuya.pm テクニカルトーク #6 で、やっぱり注目のフレームワークは Catalyst なんだなぁーって思いつつ、日頃から Sledge を使っているせいか、あまり良さや真新しさを感じなかったりして。 「メタフレームワーク」という存在定義っぽいので、Catalyst のそれ自体は割と貧相。 なのに Helper まわりとかは妙にゴージャス & 拡張されているので、やる事や Model が決まってればすぐに使え、そうじゃない場合はすぐ使えなさそう。 Rails の対抗馬なのかも知れないですが、Rails な人が wink とか使ってアジャイル開発とか言って見せびらかしているようなのを真似するには向かないかも知れないですね。 まぁ Sledge も Model に制約がなかったりするのでまず向かないですが「10 分でブックマーク作れ」とか言われたら出来るかも知れん。 Cat
Let’s use doxygen!
はじめに プログラマには、ドキュメント、とくにプログラムの内部仕様書を書くのが苦手、 という人が多い。 その理由は明らかであって、そもそも、ソースコードに (バグも含めて)*1 すべての仕様が子細もらさず書かれているのに、なぜ、さらにそれと独立した仕様書が必要なのかと、 (半ば本気で) 思ってしまうからである。 ソースコードと独立にメンテナンスをしなければならないような仕様書は、 いずれソースコードと整合性が取れなくなって、無意味ならまだしも、 かえって害をなす存在となり果てることもある、ということを、 彼らは経験的に理解しているのである。 (*1) Ruby の作者である、まつもとゆきひろ氏は、 その著者『オブジェクト指向スクリプト言語 Ruby』の中の「付録C Ruby 用語集」で、 次のように書いている: ドキュメント まつもとの苦手なもの。彼は普段から「ソースがドキュメントだ。
Sun & Users - オープンソースプロジェクトの翻訳作業を支援するサン 第2回 〜サンの翻訳の方針とノウハウを公開〜
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
エクセルテンプレート無料ダウンロード サイト EXCEL Free
What's New?エクセル ★ビジネス実用文例集を追加しました！！ ★文例は日々追加します。 最近のエクセル情報と無料ダウロード ★ 無料のオリジナル エクセルテンプレートをダウンロード(最新５種) 2023年9月1日 履歴付在庫と入庫金額管理エクセルテンプレート エクセル見積書 横長タイプテンプレート エクセル テレワーク社員 仕事進歩状況テンプレート エクセル週間作業報告書テンプレート エクセル現金移動管理表テンプレート エクセル個人収支総合表テンプレート 新規or更新テンプレート 2024年5月14日 エクセルPower Cache Office（共有快適化）ツール 5/14 エクセル株価取得テンプレートの無料ダウンロード 5/13 Excel給与 エクセルテンプレートの無料DL 5/12 6年分退職所得(一般分.短期分.特定役員分)の計算 5/11 エクセル監督割変換(学校の試
Doxygen
ソースコード・ドキュメンテーション・ツール Doxygen は、C++、C、Java、Objective-C、Python、IDL (Corba、Microsoft 風)、Fortran、VHDL、PHP、C# 向けのドキュメンテーション・システムです。 D にもある程度対応しています。 Doxygen には、次の３つの利点があります。 文書化されたソースファイルのセットから、 オンライン・ドキュメント・ブラウザ (HTML形式) やオフラインのリファレンス・マニュアル (形式) を生成することができます。 RTF (MS-Word)、PostScript、ハイパーリンク PDF、圧縮 HTML、Unix man ページ形式の出力もサポートされています。ドキュメントは、ソースから直接抽出されます。これにより、ドキュメントとソースコードの一貫性を保つことがとても容易になります。 Doxyge
プログラマではない人によるドキュメント(ヘルプ)の使い方:Geekなぺーじ
「How non-programmers use documentation」という記事がありました。 面白かったので一部を訳してみました。 間違いなどがある可能性があるので、詳細は原文をご参照下さい。 この記事は、プログラマではない人がどのようにドキュメントを参照するかをまとめています。 これを参考にして、ユーザフレンドリーなドキュメンテーションを作ってくださいと書いてありました。 Internal and on-line
perldoc.jp
このサイトは Perl の公式ドキュメント、モジュールドキュメントを日本語に翻訳したものを表示するサイトです。 サイト内の翻訳データは、有志が翻訳しているperldoc-jp/translationから取得しています。 最近の更新 / RSS commitログから最新の50件を取得しています。稀に翻訳者とcommitした人が違う場合があります。また、修正のcommit、登録しただけで未翻訳のものも含まれる場合があります。 2024-02-04 github.com ppc0018-module-true / melonsode 2024-02-03 Data::Dumper Dumper(2.183) / melonsode 2024-01-25 github.com ppc0016-indexed-builtin / kobaken 2024-01-08 perlclassguts(5.
C# によるプログラミング入門
C# によるプログラミング入門です。C# 初心者の方はもちろん、これからプログラミングを始めようという方も対象としています。
ドキュメントを作成しないユーザーは、失敗する − ＠IT情報マネジメント
ドキュメントを作成しないユーザーは、失敗する：ユーザーサイド・プロジェクト推進ガイド（15）（1/2 ページ） システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか？ コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか？ 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか？ あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか？ 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に
いやなブログ: Binary 2.0カンファレンス 2005 発表資料とレポート
Binary 2.0カンファレンス 2005 発表資料とレポート Binary 2.0 カンファレンス 2005 は大盛況のうちに無事終了いたしました。開催にご協力いただいた皆様、スピーカーの皆様、参加していただいた皆様、大変ありがとうございました。 当日の発表資料とレポートをこのエントリでまとめています。参加報告などはこのエントリへのトラックバックで受け付けています。よろしくお願いいたします。 Binary 2.0 時代の到来 - 高林哲プログラムはなぜ Ｍona OS で動くか？fork?何それ？ - ひげぽんDynamic Programming Language C -- 私は誰？ - 浜地慎一郎g++と例外キャッチボール - 中村孝史G-Inspector -- GTK+ ランタイムインスペクション - 青笹茂実行時自己書き換え佳境 - 首藤一幸ハードコアバイナリアンへの道 -
プログラマに負担をかけない仕様書の書き方や対応についての質問です。…
プログラマに負担をかけない仕様書の書き方や対応についての質問です。 今後、プログラマに事細かに指示を出す必要がある仕事に自分がつきそうです。いろいろなサイトを見ましたが、意思の疎通がうまくいかず、プログラマに負担がいってしまう事例が多くあり、気を引き締めて取りかかりたいと思います。 自分も若干の言語ならばわかりますが、ほとんど無知の状態に近いです。 自信の勉強ももちろんのこと、ミーティングなども綿密に行う事が必要ですが、その他に気をつけなければならない事や注意点、プログラマから見たやりやすさなどがありましたら教えて下さい。 また、どういう状況での作業がやりやすか、などの環境についてもよければご意見を聞きたいと思います。
PostgreSQL日本語ドキュメント
PostgreSQL日本語ドキュメント 最新版の付属ドキュメント 翻訳作業中の最新バージョン/PostgreSQL 15.0 日本語マニュアル バージョン14 PostgreSQL14最新版 日本語マニュアル PostgreSQL14.5 日本語マニュアル PostgreSQL14.0 日本語マニュアル バージョン13 PostgreSQL13最新版 日本語マニュアル PostgreSQL13.1 日本語マニュアル バージョン12 PostgreSQL12最新版 日本語マニュアル PostgreSQL12.4 日本語マニュアル PostgreSQL12.3 日本語マニュアル PostgreSQL12.0 日本語マニュアル バージョン11 PostgreSQL11最新版 日本語マニュアル PostgreSQL11.5 日本語マニュアル PostgreSQL11.4 日本語マニュアル Post
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apache 2.2 ドキュメント
JSDoc Homepage - JavaScript Documentation Tool
SQLite ドキュメント - Third impact (翻訳文書)