痔になりやすい生活習慣とは?

大企業のライブラリやAPIのドキュメントは非常に読みづらいと思いますがどうしてなのでしょうか?
特にAWSは非常にわかりづらい。
同じ内容でも個人が書いたブログを読んだほうがよほど分かりやすいです。
MSDNなどは機械翻訳だからでしょうが、人が翻訳していると思われるものでも読みづらいです。
逆に大企業のドキュメントでも読みやすいというものはありますか?

このQ&Aに関連する最新のQ&A

A 回答 (3件)

> 中小企業ではとっつきにくいドキュメントだと誰も使ってくれないけれど、大企業は「どうせ誰かが解説記事を書いてくれるから初心者に分かりづらくても構わない」と考えているのでしょうね。



いいえそういうことでは無いです。誰向けかと言うことで、一般ユーザー向けは正確さより分かりやすさ優先だし、技術者向けは、わかりやすさより正確さ・厳密さと言うことです。わかりやすさと、正確さ・厳密さは両立しません。中小企業が作っていても、技術者向けは正確さ・厳密さ優先でないと誰も使ってくれません。

まあ、技術者向けと、一般ユーザー向けを両方書いてくれればいいのでは?というのは言えますね。ただ、一般ユーザーというのもレベルは様々なので、「初めてプログラミングします」という人からすべてをカバーするのは無理でしょう。
    • good
    • 0

本家のドキュメントは、それが全世界のプログラマの拠り所なので、正確・厳密であることが重要であり、初心者に分かりやすいかどうかは最初から目的にしていません。


なので、初心者には分かりづらいのだと思います。
機械翻訳が読みづらいのはまた別の問題ですが。

特定の環境で特定の目的について書かれた個人のブログは、その条件が自分と合致するのであれば、役立ちます。合うのを探すのが大変ですが。
あるいは、初心者向けに書かれた解説の文章ということであれば、初心者がとっかかりをつかむのには良いかと思います。
上級者には役立たないので、本家のリファレンスを読むことになります。
    • good
    • 0
この回答へのお礼

中小企業ではとっつきにくいドキュメントだと誰も使ってくれないけれど、大企業は「どうせ誰かが解説記事を書いてくれるから初心者に分かりづらくても構わない」と考えているのでしょうね。

お礼日時:2016/09/02 00:58

APIの仕様を完全かつ正確に記述するためですね。


コンピュータや言語に関する専門知識と読解力がないと読みづらい、解らないという結果になります。

>同じ内容でも個人が書いたブログを読んだほうがよほど分かりやすいです。
不完全かつ不正確で良いからですね。
一般的にはそれでAPIを使用する事は出来るが異常時の対処や使いこなすことは無理と言う事でしょう。
    • good
    • 1
この回答へのお礼

正確さは当然としてかつ分かりやすく書くこともできると思うのですけどね。
完全さが必要なリファレンスはともかく、それが必要でないチュートリアルでも分かりづらいと思うのですよ。
例えばこのAWS OpsWorksのドキュメント
https://docs.aws.amazon.com/ja_jp/opsworks/lates …
タイトルが「AWS OpsWorks とは何ですか?」なのでOpsWorksを知らない人が最初に読むような文書だと思います。
しかしOpsWorksとは何なのか簡潔な説明が無いので、OpsWorksを知らない人がこれを読んでも分かるようにならないんじゃないでしょうか。例えAWSの他のサービスを使っていても。
一方、第三者が書いた記事はこちらです。
https://codezine.jp/article/detail/7304
「OpsWorksを用いると、短時間で手軽にアプリケーションを動かす環境一式を自動構築することができ、要件に応じて柔軟に構成を変更できます」
分かりやすくないですか。

異常時の対処といいますが、エラーの説明などは詳しく書いていなく、大体ググッてフォーラムで情報を見つけることになるんじゃないでしょうか。ある件では結局バグで数ヶ月以上放置されていました。

お礼日時:2016/09/02 01:17

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Qホストする?

webプログラミングの分野で
「ホストする」という言葉をよく見かけます。
例えば以下のページで使われていました。
http://adwords.google.com/support/bin/answer.py?hl=jp&answer=55939

ホストってずっと名詞だと思っていたのですが・・・
これはどういう意味なのでしょうか?

Aベストアンサー

>間貸ししてあげる(間貸しする)
すみません。両方同じ意味でしたね。
⇒間貸ししてあげる(間貸しさせてもらう)

Q.NETアプリを作ったときの .manifest ファイルって必要なの

.NETアプリを作ったときの .manifest ファイルって必要なのですか?
現在、Visual Studio 2010でソフトを作っているのですが、
ビルドをすると、[Appname].exe.manifestというファイルが必ずできます。
ネットで検索したところ、GUIのスタイルに関する事らしいんですが、
manifestファイルが無い状態でもこちらの環境でも、他の環境でも変わったところは見当たりません。
このファイルは絶対に必要なものなのでしょうか?

また、どういうときに使うものなのでしょうか?

わかる方お願いします。

Aベストアンサー

自動生成された .manifest ファイルが XP Visual Style になっていないのではないでしょうか?
XP Visual Style になっていないと、ある場合とない場合とで見た目に違いはないと思います。
C# や VB ではプロジェクトのプロパティー画面に XP Visual Style の設定があるんじゃないかと思います。( Visual Studio 2008ではありました。)
C++ とかだと、.manifest ファイルを直接編集しなければならないかもしれません。( Visual Studio 2008ではそうでした。)
あと、ビルドの時に .manifest ファイルの内容を .exe ファイルに埋め込むようになっていると、実行時にはあってもなくても何も変わりません。
.manifest ファイルは、使用する DLL のバージョンの指定なんかも可能だったと思います。

QCloseとDisposeの違い

みなさまこんばんわです。よろしくお願い申し上げます。

VB.NET 2008でコーディングしています。
CloseとDisposeの違いについて教えていただきたいのです。

これらのメソッドは、開いたファイルを閉じるときなどにも使いますが、今回お尋ねするのは、フォームを閉じるとき、しかも、自ら呼び出すとき(Me.Close() と、Me.Dispose() )のみに限ったこととしてお話しさせていただきます。

たとえば、ShowDialog() で呼び出したフォームは、そのフォーム内でMe.Close() しても、プロセスは残り、たとえば、タイマーコントロールのイベントに記述していますと、それは実行され続けます。

これを防ぐために、Me.Dispose() を使います。すると、きれいにプロセスは終了し、イベントは発生しない模様です。

そこで、「フォームを閉じる」意味のMe.Close() をすべてMe.Dispose() に変えてしまいました。確実にプロセスを破棄出来ると思ったからです。Webで調べると、違いは「再利用できる、できないの違い」という答えがありましたが、それはきっと、ファイルやオブジェクトのことで、フォームの場合は、再びShowまたはShowDialogで表示させることは可能でしたので、特に問題は感じていませんでした。

ところが、アプリケーション設定で、「最後のフォームを閉じるとき」にアプリケーションがシャットダウンする設定になってるのに、シャットダウンしてくれないことが起こりました。調べてみると、Me.Dispose() が原因。Me.Close() に変えるとうまくいきました。

わけわからなくなってきました。。。

ちなみに、その残ったフォームは、スタートアップフォームであり、別のフォームからShowまたはShowDialogメソッドで呼び出したものではありません。

ここで4つの仮説を立ててみました。

1. ShowDialogで呼び出したフォームは、Me.Dispose()、Showで呼び出した、あるいは、スタートアップフォームは、Me.Close() すれば破棄できる

2. ShowDialogで呼び出したフォームは、Me.Dispose()、スタートアップフォームは、Me.Close()、Showで呼び出したフォームは、どちらでも、破棄できる

3. 呼び出し方ではなく、別の要因が存在する

4. 併記する必要がある場合がある

Me.Close()
Me.Dispose()

または、

Me.Dispose()
Me.Close()



どれが正しいのでしょうか?どなたがご存じの方がいらっしゃいましたら、ご教授いただけませんでしょうか? どうぞよろしくお願い申し上げます。ありがとうございました。

みなさまこんばんわです。よろしくお願い申し上げます。

VB.NET 2008でコーディングしています。
CloseとDisposeの違いについて教えていただきたいのです。

これらのメソッドは、開いたファイルを閉じるときなどにも使いますが、今回お尋ねするのは、フォームを閉じるとき、しかも、自ら呼び出すとき(Me.Close() と、Me.Dispose() )のみに限ったこととしてお話しさせていただきます。

たとえば、ShowDialog() で呼び出したフォームは、そのフォーム内でMe.Close() しても、プロセスは残り、たとえば、...続きを読む

Aベストアンサー

Me.Close()
Me.Dispose()
は根本的に違うものです。

formについて、Close()メソッドはフォームの表示を終了させるメソッドです。

ほかのクラスも同様。すべてのDispose()メソッドについて、これはインスタンスの破棄を明示的に行うものです。

>再利用できる、できないの違い

Dispose()はインスタンスが破棄されるため、再びコンストラクタを用いて、インスタンスを生成しないいけません。

一方Close()はインスタンスが残っているので、それを利用することができます。

>1. ところが、アプリケーション設定で、「最後のフォームを閉じるとき」にアプリケーションがシャットダウンする設定になってるのに、シャットダウンしてくれないことが起こりました。調べてみると、Me.Dispose() が原因。
Me.Close() に変えるとうまくいきました。

通常はどちらでもうまくいきます。

>2. ShowDialogで呼び出したフォームは、Me.Dispose()、スタートアップフォームは、Me.Close()、Showで呼び出したフォームは、どちらでも、破棄できる

ShowDialogの場合は、メソッド内部で、ハンドルが破棄されているため、Close()メソッドの際にDispose()メソッドが呼び出されます。

>3. 呼び出し方ではなく、別の要因が存在する

そう思います。

>4. 併記する必要がある場合がある

インスタンスを明示的に破棄したほうがよい場合は多く存在します。
Disposeが使えるメンバはIDisposableをインターフェースとして持っているメンバです。
これらのメンバは、外部とのやり取りを行うものが多くあります。
たとえばSQLClientに含まれるようなメンバです。

外部とのコネクションを確実に破棄を保障してほしいなどという場合がありますよね、このようなときに使用します。

Using構文を使用するのとまったく同じ理由になります。
正確にはUsing構文を使用できるメンバには条件があります、IDisposableをインターフェースとして持っているメンバに限るというものです。

ほかにもガーベージコレクタによるファイナライズを伴うかどうかという違いがあります。
Disposeの場合はファイナライズが同時に行われるため、使用していたメモリ空間を開放することができます。

上記のような理由により、
Me.Close()
Me.Dispose()
は両方書いたほうがよいと思います。

蛇足ですが、
Me.Dispose()
Me.Close()
はエラーになります。
Me.Dispose()により、Me本体(インスタンス)は削除されてしまいます。
存在しないMeに対してCloseメソッドを要求することはできないためです。

Me.Close()
Me.Dispose()
は根本的に違うものです。

formについて、Close()メソッドはフォームの表示を終了させるメソッドです。

ほかのクラスも同様。すべてのDispose()メソッドについて、これはインスタンスの破棄を明示的に行うものです。

>再利用できる、できないの違い

Dispose()はインスタンスが破棄されるため、再びコンストラクタを用いて、インスタンスを生成しないいけません。

一方Close()はインスタンスが残っているので、それを利用することができます。

>1. ところが、アプリ...続きを読む

Q仕事についていけない(システムエンジニアです)

社会人5年目のシステムエンジニア(女性)です。
プログラミングやプログラム設計を中心に、仕事をしていますが
新入社員や後輩にどんどん抜かれている気がします。

集中力があまり無いことが災いしているのかもしれませんが
とにかくプログラミングがぜんぜんわかりません。もう、わけがわかりません。
プログラミングがわからないので、その設計も当然できません。
元々集中力が無く、楽器や勉強もそこそこで
何かひとつのことを成し遂げた経験がありません。
そういった中途半端で飽きっぽい性格のせいかもしれません。
読書も苦手なので、読解力もまったくありません。

これまで何とか5年も続けてこれたのは、周りの人たちが優しくて
毎回助けてもらってきたからに相違ありません。
でも、もう5年目なので、あまり堂々と質問したりできませんし
つまらないことを他の人に質問している姿を見た上司は
あきれた顔をしています。

でも、プログラミングの考え方がまったくわからないのです。
努力して自習するのも、もう疲れてしまいました。
来期から、同じ会社内の別の仕事(事務職など)に
配置換えをお願いしようと思っています。

このままエンジニアで居ても、なかなか成長しないし
何より、仕事についていけないという理由で
会社に行くのがとても辛いです。
辛いあまり、周りに泣き言を言いそうになってしまいます。
泣き言を言われる側も迷惑だと思います。
私なんかいない方がいいと思います。

私はもう少し粘ってシステムエンジニアを続けるべきでしょうか?
それとも、一度休職などしてリセットするべきでしょうか?
また、今考えているように配置換えをお願いするのがいいでしょうか。

今後に自分の身の振り方を考えています。
色々ご意見をください。よろしくお願いします。

社会人5年目のシステムエンジニア(女性)です。
プログラミングやプログラム設計を中心に、仕事をしていますが
新入社員や後輩にどんどん抜かれている気がします。

集中力があまり無いことが災いしているのかもしれませんが
とにかくプログラミングがぜんぜんわかりません。もう、わけがわかりません。
プログラミングがわからないので、その設計も当然できません。
元々集中力が無く、楽器や勉強もそこそこで
何かひとつのことを成し遂げた経験がありません。
そういった中途半端で飽きっぽい性格のせいかもし...続きを読む

Aベストアンサー

私は、まだまだくじけずに頑張って欲しい、と思います。

あなたの文章を読む限り、プログラムでつまずいているものの、
SEとしての適性は十分あり、頑張り次第ではこれから十分に活躍できると思えるからです。

以下その理由を述べていきます。

SEにとって必要な能力はいろいろあり、
プログラミングというのはそのうちの一つに過ぎません。
コミュニケーション力、柔軟性、設計力、イマジネーション、組織マネジメント力など色んな能力が必要ですが、
・このシステムは何のために必要なものか
・どうあればもっと良いものになるか
・良いものにするための工夫
・みんながもっとうまく仕事をすすめられるための工夫
というようなことを考えて、自発的に課題を発見し、対処していく、
そんなことを頑張ってくれる人であれば、プログラミングが少々苦手であっても、
素晴らしいSEといえるでしょう。

私は大手SIerでSEをやっていますが、周りにはプログラムが不得意だけど優れたSEもたくさんいますので、
得意なことをもっと頑張っていけば、組織に必要な人材に十分なれるのではないでしょうか?

また、プログラミング・設計能力はもちろん重要で、あると活躍の機会は増えますが、
それはいわゆる「システムに強いSE」のタイプです。
もうひとつは「業務に強いSE」のタイプで、システムと業務の得意な割合が9:1であればプログラマー寄りですし、1:9であればコンサルタント寄りといえます。5:5はバランスの良いSEですね。
いずれも組織に必要なタイプですので、得意なことを頑張って強みを発揮できるようになれば、苦手も気にならなくなるかもです。

あとは、プロジェクトマネージャーを目指すという考えもあります。
組織をまとめて人を動かす、ということに特化したタイプですが、大きめなプロジェクトとなれば、こういった能力を持った人が重要となります。プログラマータイプには、マネジメントが苦手なタイプが多いです。(コンピュータとは何時間向かい合っていてもいいけど、人間は苦手、な~んてね)

いろいろと可能性はありますので、もっと視野を広げて勉強して、
自分の得意なこと、興味のあることを頑張ってみると良いのではないでしょうか。
もちろん、プログラミングも、もう一回初歩の初歩まで戻って勉強しなおして、
ある程度苦手は払拭しておきたいところだな~、とは思いますが。

私は、まだまだくじけずに頑張って欲しい、と思います。

あなたの文章を読む限り、プログラムでつまずいているものの、
SEとしての適性は十分あり、頑張り次第ではこれから十分に活躍できると思えるからです。

以下その理由を述べていきます。

SEにとって必要な能力はいろいろあり、
プログラミングというのはそのうちの一つに過ぎません。
コミュニケーション力、柔軟性、設計力、イマジネーション、組織マネジメント力など色んな能力が必要ですが、
・このシステムは何のために必要なものか
・どうあればもっ...続きを読む


人気Q&Aランキング