  |
はてなキーワード: エラーメッセージとは
先日「飲み会版ソーシャルランチをつくってみた」を書いた者です。
上の記事では、僕がつくった「飲活」というサービスの説明が大半で、どうやってつくったのかとか説明が少なかったので、今回はそれについて書いてみようかと思います。
僕は「「飲活」」を作るまでも、iPhoneアプリを開発したり、webサービスのメンテナンスをしたりとプログラミングをしておりました。
しかし僕も何度かwebサービスの立ち上げを挫折しております。4回くらいかな。
最初はxoopsを使って、ツイッターで登録企業の広告をつぶやいたらポイントをもらえるサービスでした。
なんとxamppで門前払いされました。ローカル環境すらつくれませんでした。「くそ初心者は時間を無駄にするだけだから辞めろ」と言われた気分でした。
xamppだけに2日くらい朝まで格闘してしまい本当に時間を無駄にしました。当時はapacheの設定とかなんぞや状態ですからね。
次にやろうとしたのが、大学受験生向けのサイトで、受験生に教科ごとの講義をするのではなく、勉強のやり方を教えるよ！ってサイトです。
ほとんどｈｔｍｌでできそうなのですが、phpでメールを送ることができず挫折しました。
レンタルサーバーを借りたのですが、レンタルサーバーのphpの設定をしないといけないのを知らなかったり、やっと解決しても日本語化けに悩まされて止めた覚えがあります。これほど母国語が英語だったらどんなに楽かと思った時はありませんよ。プログラミングしてると今でもたまに思います。
次が、キックスターターのようでそうでないクラウドファンディングサービスをつくろうとしました。
ここでjavascriptと出会いました。いや、ちゃんと交際を始めたと言うべきか・・・。それまでjavascriptとすれ違っても虫を決め込んでいたのですが、いざ必要になって呼び止めてみると意外と良い奴でした。
しかし、ajaxにつまづいたり、サイト構成やディレクトリ構成、データベース構成や、デザインの調整などで複雑で面倒になり挫折してしまいました。
こうして書くと、僕がすごい諦めの早いやつで勉強もまともにしないやつみたいに思えますが、半分正解。諦めは悪いけど「ググればいける」という考えで勉強を怠っておりました。
だいたいプログラミング言語はどれも根本は似ているので、先述の３つ以外のプログラミング言語をやりたいと思ってる人でも参考になると思います。
また、以下の内容は、わけわからんけどwebサービスをつくりはじめる方を前提にしています。
まずは開発環境を整えましょう。
開発環境とは、自分の書いたプログラムをローカル（自分のパソコン）でのみ動作させる環境です。
つまり、自分がつくっているものを外部に見られることはありません。
です。
まずはこれらをインストールしてください。設定などの説明は割愛します。
僕はphpを使いました。
僕もそうでしたが、素人は当然プログラミングの全体像を想像できません。やりたいことを思いついても、どういうコードを書いたらいいかなんてすぐに想像できませんよね。
これも当然ですがその原因は、そもそもプログラムでなにができるか知らないからです。
なので、POSTやSESSION、配列などの基本的なものの存在を知りましょう。そしたら、「このページにはこの機能が必要だろう」というのが、"なんとなく"わかります。書き方はこの時点で別に覚えなくて大丈夫です。
例えば、オブジェクトを格納することが出来る「配列」という存在を覚えます。
この時点では、配列の作り方のコードとかは覚えなくていいですよ。「配列という存在を知る」ことが重要です。
基本的なことを学ぶときはネットではなく本を使う事を薦めます。
本は情報が体系的にまとめられていまうので、ネットよりも学びやすいです。
プログラミングは10年以上基本部分は変わっていませんので、「古いものを覚えちゃわない？」という無駄な心配はなくて大丈夫。
一方、発展的なことではネットで学びましょう、というかわからないことがあればネットで探しましょう。
どんなことを実現したいのかというゴールがないと必ず途方にくれます。
なので、まずはゴールを設定します。
例えば「「飲活」」なら、
などなど...。
その後に、各ページ毎に必要な機能と大まかなそのページのやることを決めます。
ログインページには、ユーザーが入力するフォームと送信ボタンがあって、なにも入力されずに送信ボタンが押されたらエラーメッセージを出そう。エラーがなくログインに成功したら、会員専用のエロビデオを見せよう。
とか。
例えば、しっかり考えず適当に、登録ユーザーのプロフィール画面を開発していて、ユーザー名、生年月日、出身大学を表示させるプログラムをつくったとします。
しかし、プロフィール画面が完成した後にメールアドレスも表示させないといけないことに気がついた場合、少しプログラムの変更が必要になります。
最初から、どのデータが必要なのかを決めていれば、こうした効率の悪さは回避できます。
実際は奇麗に開発できることは少ないですが、何も考えずに開発するよりは効率的です。
大まかな機能（ログイン）→具体的な機能（ログインページの機能）→具体的にログインページがやること→必要とするデータ
という流れでサイトの機能を決めることで、自分のやることが明確になりますし、勉強すべき内容も最小限に抑えられます。
ここで、どういうデザインにするのかを決めればもっと後で楽になります。
webサービスには必ず必須となるデータベースについて知る必要があります。
僕は、mysqlを使いました。
サーバーはさくらインターネットのレンタルサーバーを使ったので、さくらインターネットのデータベースを利用しました。
各ページで必要な機能とやることを決めたら、それを実現してくれる方法を本やネットで探します。
先述のとおり、必要な機能を決めていればそれを実現してくれるもののみを探せばいいので効率的になります。
見つけたら、あとはそれを使ってやりたいことをやるだけです。
具体的にはサンプルコードやAPI、フレームワーク（ライブラリ）を探すべきだと思います。
プログラミングに慣れるまではフレームワークを使うと上手く組み込めず、それが挫折の原因にもなりそうなので、主にサンプルコードを探せばいいと思います。
プログラミングってなんのためにあるかというと、人々の生活を楽にするためです。
人々を楽にするプログラミングで、わざわざ辛いやり方をするのは最悪です。
なので、どうぞ堂々と怠けてください。他人のつくったコードを使ってください。API、フレームワークを使ってください。
プログラムを書いたらデバッグしたり、ブラウザ（htpp://localhost）で見てやりたいことができているか確認してください。
特にこのサービスには特別なことや難しいことはやっておらず、正直phpの基本がある程度わかっていれば、このサービスの基本的部分は作れてしまいます。
デザインをつくりましょう。
僕は一から自分でデザインを考えたわけではなく、他の素敵なサイトを参考にさせていただきました。
また、サイトの見た目をつくるにはhtmlとcss、時にはjavascriptを使う必要があります。
オススメなのは、twitter社の提供するTwitter Bootstrapです。
http://twitter.github.io/bootstrap/index.html
ちなみに、「飲活」は、html、css、javascript（jQuery）を使っています。
つくったサイトをみんなに見てもらうためには、外部とネットワークのあるコンピュータにアップロードしなければなりませんし、ドメインもなければいけません。
コンピュータにはIPアドレスがあり、ネットワーク上の住所となっています。これにアクセスすると、「飲活」の住所とか「はてな」の住所とかあったりするわけです。これは数字でできており、これを人間が読みやすいものにしようというのがドメインです。
hatena.jpとかnomikatsu.comとかですね。これを取得しましょう！
自分で作ったり、VPSを使ったりすることもできますが、自分で管理をしなくていいという点で楽なので僕はレンタルしています。
僕は、さくらインターネットでレンタルしています。
僕のようにドメインの管理会社とサーバー会社が別だといろいろと設定をしなければなりません。
DNS（ドメインネームサーバ）というのがあり、「このドメインのあるサーバーはこれ、IPアドレスはこれ」と教えてくれるものです。
お名前ドットコムで取得したnomikatsu.comは、さくらインターネットのサーバにあるよと設定する必要があります。
実際には、さくらインターネットのネームサーバ情報を知り、お名前ドットコムでnomikatsu.comはこのネームサーバだよと設定してあげるのです。
これで、数分から数時間でnomikatsu.comにネットからアクセスすることが出来ました。
あとはサーバーにファイルをアップロードすれば、インターネットで自分のつくったサイトを見れます。
ファイルアップロードの仕方ですが、FTPクライアントを使います。
僕は、filezillaを使いました。
filezillaからホスト名やユーザー名などを設定してサーバーに接続します。
接続できたら、指定のディレクトリにファイルをアップロードすればOKです！
とにかく作り始めましょう。
僕は、本が書いてあるサンプルコードをそのまま勉強としてやるのはオススメしません。
だって、つまらないですもん。あれは、プログラムを書いていて基本がわからなくなったときに見返せばいいんです。
最初はまず作りたいものを決めて、PHPで何が出来るのかをざっくり勉強して、それを実現するのに必要なコードややり方を見つけて、実際に動くものをつくっていってください。
やりたいことをやらなきゃ飽きますし、本のサンプルコードよりも実際にwebサイトをつくった方が覚えます。
やったことがない人が勝手に難しいと思い込んでいるだけで、意外とやってみれば難しくありません。
簡単とまでは言えませんが、正直誰でもできます。
僕の場合は何度かプログラミングを挫折しましたが、こうして一つのものをつくることができるようになりましたし、iPhoneアプリなども会社では開発しています。
こんなやつでもできるので、諦めなければできます。
そんで、とても楽しいです。
本当につくりたいものがあるのなら、一度やってみる価値はありますよ。
明記してありますが、僕は初心者ではありません。初心者の方が勉強がてらサービスを作る一つのやり方というか流れを紹介したいと思って記事を書きました。
僕自身、なにもわからずプログラミングをはじめたときは、どう勉強したらいいかわからず辛い思いをしました。
素人がわけわからずプログラミングを始めると挫折しやすいと思いまして、僕が素人の時を振り返り、そして勉強してきた経験を使って、素人の方にサービスをつくっていく流れを書いたら素人の方も挫折しにくいかと思いました。
なので、僕は初心者ではありませんが経験者として素人がサービスをつくっていく方法を書きました。
また、飲活をつくった実際の流れと書きましたが、飲活をつくった流れを利用して、初心者がサービスをつくる流れを説明したかったんです。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
Project ExplorerでImport ＞ Git Repositoryとかすると上手くいかない。走らせようとしても「The selection cannot be launched, and there are no recent launches.」というエラーメッセージが出る。
正解は、KitchenSinkをDLし解凍しておいて、Project Explorer ＞ Local Filesystemから解凍したプロジェクトのフォルダを選択し、右クリックから「Promote to Project...」する。
このとき表示されるダイアログでは、Project nameとかは適当に設定して良いみたいだ。
Project Typeは、よく判らんからTitanium Mobileのみを選択した状態にしといたら上手く行った。標準ではWebのみが選択されているけど、それでも良いのかどうかは試してないから知らん。
via http://developer.appcelerator.com/question/132777/cannot-build-project-the-selection-cannot-be-launched
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。
ペロペロ
1. htmlのはき出しがあるやつは?>を書いたほうがいいよ。それ以外は最近はかないのがはやりだねさらに昔はevalとかで書いてた
2. configこれはwwwやpublic_html以下にしかconfigを配置できないクソサーバーがあるので、phpにしておいたほうが安全。なぜなら丸見えにしてあれこれパスをさらけ出すバカがいるかもしれないからだ。オープンソースなら特に。
3. コメントは挨拶だ。必要以上に挨拶を繰り返す必要もないし、それ以上でも以下でもない。
4. eclipseのせいと、phpとかが出始めたころのコーディング規約がスペースにするように求めた。{を改行してから書くか、続けて書くかのこれは宗教戦争だ。だが正直スペースは気に食わない。LLのくせに何バイトつかってるのだとおもう。あとスペース２文字インデントのやつは旅立て！
5. phpの0と""の違いは緩すぎる。そういう意味でナンバーの取り扱いにだけは気を配るべきだ。あとはtmpでもbufでもretでもなんでもいい。
6. nullはつっこむな、nullで初期化はすんな。初期化されてないからnullなんだ。issetは有効につかえ。とくに$_系の変数
7. 本当はerrorprocをかけといいたいがLLにそこまで望んでもしゃーない。エラーを投げると鯖ログにまで場合によっては落ちたりしてやっかいだからfalseを返せばいいというものでもないが、trueで初期化するやつは滅びていいと思う。あとarrayを返すようなfunctionの場合、phpのなんだっけisarray?だっけ？がクソすぎて萎える
8. つかダブルクオートのなかに$を書くコードは滅びていい。コンストはすべて大文字でという昔ながらのルールだけ守ってくれればいい
9. 出力系のラップ関数ぐらいつくっておこうぜ。あと、var_dumpとかのほうが見やすい。あと、get_defined_varsとかをラップしておくと便利
10. 三項演算子はつかうな。ifの{}を略すな。可読性がおちるのとしんたっくすで原因の特定がめんどくさい。
12. ++iなんていうコードを書くな。あと、roopの条件文で計算すんな
13. むしろこういうのは文字列の連結以外で使うようなスチュエーションをつくっちゃだめ
14. あら上で言っちゃったよ。ここまでやるんだったらlogファイルに吐き出すところまで拡張しとけば?
15. んー。エラーメッセージを定数化するときは外国版をつくるあてまである時だけだな
16. これも上でいってしまったな。あとリロードされてもいいように初期化でクリアしておくといいぞ。
17. ああそうだな、関数が１スクロールに収まらないときは大抵正規化に失敗してる。つくりをみなおせ
18. えー、こんな風に書くのはどうかしている。public二つチェインで呼び出すぐらいなら、内部でprivateを呼び出すか、継承させてparentにしておくべきか、それともシステムとして共通のstaticで呼び出せるかにしてくほうがいいのでは？$this->setThis()でいいじゃないか。なぜpublic functionをそういくつも定義する必要がある？ 外部からの入り口出口は絞れ
19. グローバルなラッピング関数は最低限にとどめるべきで他は機能ごとにクラスつくってメソッド化しとけ。p(var)じゃねぇよDEBUG::p(var)とかにしとけってことだ
20. 眠くなったからねる。つまりはそんなもんだってことだ。気に病むな。満足してもらえるもんをしっかりつくればいいだけだ
カードの期限が切れるほど入荷に長い時間かけたのはamazonだが
まあここまではいいさ。
素直に更新した新しいカードの情報を登録しようとしたら、アカウントサービスが言うことを効かない。
システムのメッセージで何故か「カードの情報がおかしい」と言われる。
で、
「こんな出てるけど何。新しいカードは絶対生きてるしミスタイプもしてないよ（要約）」とサポートにメールを送ったら
「カードの情報がおかしいからキャンセルしてもう一回注文してくれ（要約）」と返答が来た。
お前それ、エラーメッセージそのまま読んでるだけじゃねえかと。
「それのどこがサポートだボケ！真面目にやれ！（要約）」と送ったら、今度は
「住所情報が正しくないからカードも無効になってる、手続きして直してくだちい（要約）」とかわけのわからないこと言う。
俺は間違った住所なんかamazonアカウントに入れてないし、長年同じ住所に送ってもらってる。
もう意味がさっぱりわからんけど、すでに入ってるのと同じ自宅の住所を入れなおした。
そしたらカードの情報も登録できたので、意味がさっぱりわからんけどまあ解決らしい。
「キャンセルするならここから手続きしてくれ」なんつーメールがきやがった！
じゃあお前、面倒なメール往復して支払い情報登録したのはなんだったんだよ！
だいたい「商品が入荷して発送準備段階に入った」って言ってたよな！？
その商品どこやったんだよ！この数日の間にキープしないで売っちゃったのか！
それとも元から入荷って言うのが嘘だったのか！
前にもおんなじことがあって、
その時はコンビニ支払いを指定してたので
なんなんだこれ？
アマゾンて販売部門は優秀だろうしとっても便利だけど
サポート部門は小学校低学年と文通してるみたいな気分にさせてくれる。
１回だけならたまたまだと思ったが、１回じゃない。
Messenger - 「この kids passport アカウントでは windows messenger はご利用なれません」
なんだこれは！俺をガキ扱いする気か！
http://help.jp.msn.com/announce.aspx#20090907_Mess
平素より、Windows Live サービスをご利用いただき、誠にありがとうございます。
現在、下記のエラーメッセージが表示されてWindows Messenger (*1) に
サインインできない現象が発生しており、ご不便をおかけしております。
(*1 Live Messenger と互換性はございますが別のプログラムとなります。)
＜ エラーメッセージ ＞
この kids passport アカウントでは windows messenger はご利用なれません。
kids passport の詳細および両親の同意の必要については
複数のお客様より、別の Windows Live ID アカウントでは
Windows Messenger にサインインができる報告をいただいておりますため、
Windows Live ID アカウント登録情報に起因した問題であるか
当 Windows Live サービス担当部署にて総力をあげ、調査を行っております。
お客様には、しばらくの間ご迷惑をおかけいたしますが、
調査が完了するまで、お待ちくださいますようお願い申し上げます。
一時的な回避策とはなりますが、改善まで別 Windows Live IDアカウントの
ご併用を検討いただけますと幸いでございます。
＜Windows Live IDアカウント新規登録方法＞
1. http://hotmail.com/ にアクセスします。
2. [新規登録] をクリックします。
3. 必要な項目をご入力ください。
お客様にはご不便おかけし、申し訳ございませんが、
ご理解いただきますよう何卒お願い申し上げます。
[2009.09.07 掲載]
もう1ヶ月半経ってるぞ－。
いや、実際にはもっとあるんだろうけど。 つっこみよろしく。
(1)(2) →アドレス帳に登録して相手の名前が表示されているため、メールアドレスの間違いに気がつかない。
(3) →送信者にエラーコードは帰ってきているが、送信エラー表示に気がついていない。
(6) →いずれも相手先メールサーバでエラーメッセージを返信しない設定になっている場合気がつきにくい。
(10） →自動送信ツールなんかで、あて先を全部BCCに突っ込んで一括送信する場合意外な盲点かも。部門で利用しているようなメールアドレスのときに要注意。
(11) →ホップ数設定が低いサーバが経路上にあると破棄されてしまう。
標準は26くらいで、引っかかることは少ないようだが、昔は10とか6とかあったらしい、
(12) →引越し通知に返信したのが引越し当日でメールサーバの電源きれてますとかな～
(13) →CC同報で送っていても、自分には届いてないと主張されると相当厄介。
自社内であればメールサーバログなどで受信状況確認したりできるけど他社の場合はなかなか証明しづらい。
というか、しらばっくれられて確かに届いていたことを証明しろとかいわれてしまうと正直どうしようもないんだが、、
WinXP機に、ruby on rails インストール中（gem使用中）に下記のエラーが発生した。
ERROR: http://gems.rubyonrails.org/ does not appear to be a repository
一時間ほど格闘した結果、プロキシの設定をしてないだけだった。環境変数HTTP_PROXYを作り、URLを設定する必要があるらしい。
Goto the cmd line
set HTTP_PROXY=http://mycache:8080
http://wiki.openqa.org/display/WTR/FAQ#FAQ-HowdoIgeminstallWatirbehindaproxyserver%3F
ちがうにょー
デバッグに梃子摺る人が初心者に多いわけは、主に次の３つに起因するにょ。
エラーメッセージの見方を知らないからエラーメッセージを全く見ない。エラーが出ている場所と内容まで事細かに記してあるコンパイル時エラーメッセージや実行時スタックトレースを前に絶望してしまい、慌ててソースコードを１から読み直してしまう。特によく耳にするのが『どこが悪いのかわかりません』だけど、数行のエラーメッセージに答えがずばり書いてあることがほとんどだったりします。
特にプログラミングに慣れていない初心者が陥りがちなのが、制御フローばかりに目が行ってしまい、制御フローから類推できるデータフローには気を配らないという現象。例えば値「１」を返す関数が「２」を返してきてしまった。確かにそういう場合には制御フローを辿ることも重要だけど「２の源流をたどってみる」ことをすれば、意外とすんなり原因が見つかることも多かったりです。
見たままの文字にばかり注意してしまい、例えば半角空白と全角空白とタブを見分けていなかったり、他にも行末に１個空白が紛れていて「なんで上手く処理されないんだ」と悩んでしまう人が意外といる。他にもコンパイル時エラーで多いのが ; の有無だったり () の対応だったり。原因の目星がついても、最後の最後で躓くのはおおよそこういうポイント。慣れればぱっと見で気付くことなんだけど、このあたりが前述２つの理由と相まって、意外と疎かにされやすいところなんだよね。
総じて、デバッグを出来ない初心者に共通する原因は「結果から原因を探ることに慣れていない」ということに集約されたりする。そもそも結果を見ていなかったり、結果から原因を逆算する手法を知らなかったりするのが、「慣れていない人」というわけです。
http://news.dengeki.com/elem/000/000/153/153004/
MS、Xbox 360本体の“E74”エラーに関する保証期間を延長
マイクロソフトは、Xbox.comのサポートページで、Xbox 360本体の“E74”エラーに関する保証内容を変更すると発表した。
これは、Xbox 360本体を起動した時に“E74”というエラーメッセージが表示される問題を指す。同社はこのエラーが出た場合、保証期間を購入日から3年間に延長する。保証期間中、ユーザーは無償で修理を受けられるようになる。すでに“E74”エラーで有償修理を受けている人には修理代金が返還される。詳しくは、 Xbox.comのサポートページを参照のこと。
エラーが頻発する事が前提みたいな言い回しはやめてくれ・・・
仕事が忙しく、日中家にいられないためコンビニ受取を初めて使った。
コンビニ受取のヘルプとよくある質問のページを確認して、コンビニで受け取れない商品があるときは
注文途中でエラーメッセージが出るということだったので、欲しい商品を3つほど注文。
Amazonから発送のメールが届いたのでコンビニで商品の受取をしに行ったら、商品が届いていなかった。
配送ステータスを確認したら受取拒否になっていた。
訳がわからず配送業者の窓口に連絡したら、配送された荷物のサイズがコンビニ受取できるサイズを超えていた為
返送されたという事だった。
どういうことだ？受取できないなら注文途中でエラーメッセージがでるんじゃないのか？
Amazonはコンビニに配送するときにサイズを確認してないのか？
意味が解らない。
Amazonに問い合わせようとしたが、携帯電話での問い合わせができなかったためメールにて
問い合わせをしている。しかし返事はまだない。
はやくFallout3がやりたい・・・。
Could not load class (App::Mobirc::Plugin::HTMLFilter::DoCoMoCSS) because : Can't locate XML/LibXML.pm in @INC (@INC contains: /home/pc/mobirc/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /home/pc/mobirc/lib/App/Mobirc/Plugin/HTMLFilter/DoCoMoCSS.pm line 5.
どっか変なところある？
真っ当なエラーメッセージだと思うけど。
Firefoxなら、そんなエラーメッセージをガン無視して入力できるぜ！
もちろんJavaScriptのあたりをごそごそいじった自分の設定じゃないと無理だけど。
まぁ、縛られてなさいってこった。
