  |
はてなキーワード: セミコロンとは
Flashゲームを作りたくてアクションスクリプトの本を買ってもらったんだけど、本の通りに書いてもエラーが出て動かなかった。
今になってみると何故動かなかったのかの見当がつく、セミコロンとコロンを打ち間違えてたんだ。
もし最初の本が初めてプログラミングに触れる初心者向きで、それこそ変数とは？関数とは？どんなことに気をつければいいのか、というところから一歩ずつ書いてある本なら投げ出さずに済んだかもしれない。
大学に入ってからJavaScriptやPHPを少し触るようになった。
小学生の時の挫折があったからなのか、周りの学生よりも多少理解が早かった。
エラーが出たらエラー文でググる、がこの時の私の対処方法だった。
カッコの閉じ忘れや変数名間違いで数十分悩むこともザラだった。
しょーもない間違いを積み重ねていくうち、なんとなくエラーの原因に見当がつくようになってきた。
他人のコードを見ても、どこまでが元から用意されている機能で、どこからがこの人が新たに定義した何かなのかがわからない。
上手な人のコードは簡略化されすぎてて、私にはまるで理解できない。
JavaScript、関数の書き方が何通りかあって、それぞれの違いがよくわからなかった。
困るのは見たことない書き方を見てもそれをググれないこと。記号が入り混じってて検索ワードとして成立しなかったり、そもそもプログラミングやってる人からしたら常識だったりして、わざわざ空は青いですよ、みたいな分かりきったことは書いてくれてないのだ。
たまたまプログラミングの得意な先輩に教えてもらう機会があって、色んなことを教えてもらった。
例えばツール。
閉じ忘れや変数名間違い、全角スペースで数十分悩む必要は無い。だってツールが教えてくれるから…。
それまでメモ帳に毛の生えたようなテキストエディタを使ってたんだけど、SublimeTextとかVS Codeとか色んな選択肢があることを知った。すごいんだよ！コードを補完してくれる機能があったり、閉じ忘れてると教えてくれたりするの…。
こんな便利な関数があるよ、それは古い書き方で今はこんな新しい書き方が主流だよ、とか。
インデントは揃えようって口を酸っぱく言われた。確かに揃えた方が読みやすいよね。
エラーが出た時の対処方法も自分とは違ってた。そうか、これ、原因になる行がエラー文に表示されてたのか…。
どこまで値を渡せてるのか順番にコンソール出して確かめればいいって発想が自分に全く無かった。そうだよね、どこで失敗してるかわからないものね。
んで、就職して社会人になったわけだけど、コードを書く機会はほとんどない。あ、いやたまにある。ランダムでおみくじを表示させる程度のものとか。
プログラミング、まあまあ好きだと思う。
でも自分にはその素養が無いって常々感じる。なんか根本の考え方が上手な人と全然違うみたい。
初心者がエラー文読まない、読んでも見るだけで理解してないのはガチ。
どうやったら上手な人と下手な人の溝が埋まるんだろう、ってたまに考えるんだけど、
人間やっぱ得手不得手ってあるよね。
誰かに教えて貰わずともボール蹴るのが上手な人も居れば、教えて貰っても下手な人もいるわけで。
でも学校の体育ってやり方教えてくれないよね？
跳び箱ぐらいかな、コツ教えてくれるの。踏切の位置や手をつく位置、あれを上手くやれば高い段もするんって跳べる。
そういえば高校のプログラミングの授業でもコツとか教えて貰わなかったな。
入力インターフェースがキーボードからタッチパネル、マイクへとかなりアグレッシブに変化しているのにエディタの入力メソッドが未だにキーボード前提になっているのはちょっとダサい。
コードを書くのに入力補完やフォーマッティングなどは日常的に行っていると思うが、これをキーボードで行わざるを得ないのは最早老人たちのレガシーでしかないだろう。
「クリエイトファンクション、ファンクションネームイズ『てすと』、ブレスオープン、コールプリントフォーマット、オープンパーレン、テキストビギン、『ハローワールド』テキストクローズ、クローズパーレン、セミコロン、クローズブレース、エンドオブパラグラフ！」
って感じで唱えて
function test(){
printf("hello world!");
}
サ「あ、セミコロン…でしたっけ…？」
私「セミコロンで囲むんですか？」
サ「あ、え、えっと…、これなんて読むんですかね。読み方がわからなくて…」
私「これ、と言われても」
というようなやりとりが２回ほど立て続けに（それぞれ別の人）あったんだけど、
読み方って、知らないのが普通なの？
わりと常識的なことだと思ってたんだけど、そうではないのかな。
そういう私も、『〜』の正式名称は知らず、『にょろ』とかいっちゃうけど。
電話に出たサポートの人も、知らないなら知らないで、「ちょんちょん」とか言えば通じるのに、
『ダブルコロン』はないと思うんだけど、私が厳しすぎなんでしょうか。
私はエンジニアではないけど、ダブルクォーテーションくらいは知ってるし、
①セミコロンを使う場合は、セミコロンをはさんでいる二つのセンテンス間に主従の関係がない。
②セミコロンを挟む「 二つ のセンテンスが 共通のテーマで結ばれており」、
forwardとbackwardのように、明暗、天地、苦楽、善悪のような「一対の対照的要素を左右に配置できる」ときにその真骨頂を示す。
③ピリオドで 区切ることのできる独立性を備えていながら他のセンテンスと共通性のある二つのセンテンスをセミコロンで区切ります。
These are my favorite animals: bears, for their strength; lions, for their courage; and monkeys, for their cuteness.
①bears, for their strength
②lions, for their courage
③and monkeys, for their cuteness.
の３つが並列されている。
●「Grammar In Your Pocket Series Introduction」から引用
At home, you learned from Mom and Dad; in school you learned from Teacher. What you learned was what they knew.
→①AT HOME, you learned from Mom and Dad; ②IN SCHOOL you learned from Teacher. What you learned was what they knew.
「英文法を学ぶ場所、状況」という共通テーマで、at home（家庭）と、in school（学校）がセミコロンで並列されてる。
一番最初はCだった。ポケコン付属のstdio.hしか無いCを使い倒して、PCを買って普通のCを始めた。
BCC32のセットアップが分からなくて電子計算機部の同級生にPATHを通してもらった。
セミコロンがなくて1週間止まり、友達に相談したら本当に3秒で解決した。
ポインタが分からなくて1年間止まり、翌年C++を初めてから何かのきっかけで理解した。
あの頃は「黒い画面でカタカタやってる人たち特別感あってかっけー！！！１」ってのが動機だった。
社会人になった。
専攻とは大きく異なるけど、web系の会社でプログラマという名前の職を得た。
土日で書いた趣味のコードをGitHubに上げてボコボコに叩かれたりして楽しく過ごせるんだろうなと思っていた。
確かに研修はそんな感じだった。朝礼が終わったらオライリーを見ながらプログラムを書き、終業時間を過ぎても勝手に書いていた。
それが終わったら、既存のプロダクトを保守するところに配属された。
新しく作るなんてものはもう無かった。
それは別に悪いことじゃない。重要な事なのはわかっている。作って終わりではないのも分かっている。
でも自分じゃない誰かが、よく分かっていないままよく分からないものを作り続けてここまで来たのであろうそれを直すのは辛い。
「新しいコードに書き換えればいいじゃないか」というのはもっともだ。
でも新しいコードに書き換えたところで、新しいものを作っているということにはならない。
その借金は自分のものではない、なのになぜ自分が返済するんだ、というネガティブな考えが頭から離れない。
新入社員だからというのか、コードを書いている時間よりそちらのほうがとても多い。
電話番もしていた。
新卒採用の手伝いもしている。
何のためにどんな仕事をするべきなのかわからないし、自分が何をしたいのかも分からない。
「土日で何か勝手に書けばいい」というのはそのとおりだ。
仕事が遅いし、これと言える成果もあげていない。
また今週も何もしていないという考えで1時間くらいシャワーを浴びている。
水道光熱費がどんどんあがっている。
公開できるような、会社が期待しているようなwebサービスとかでは無い。
会社のみんながこうでは無いのも辛い。
新しいコードを書いている人もたくさんいる。
なぜ自分はそうなれていないのか。辛い。
新しいものを作っていたほうが、新しいコードを書き続けていたほうが楽しいに決まっている。
感謝もされるだろうし、自分が中心にいる満足感だって得られるのだろう。
そのうえで「運用が大事」とか考えるようになるんだろうな と妄想している。
何の論拠もない、僻みしか考えられない。
もう土日でwebサービス作るとか言うのはやめよう。
仕事もろくにできていないのに。
こちらに丁寧に記載されていて、感謝の限りです。
注意は
$ wget -q http://linuxmint-jp.net/linuxmint-ja-archive-keyring.gpg -O- | sudo apt-key add -
$ sudo wget http://linuxmint-jp.net/sources.list.d/linuxmint-ja.list -O /etc/apt/sources.list.d/linuxmint-ja.list
の、最初の行の -0- は、英大文字のオーかゼロ。 2行目は 英大文字のオー。
※最初-O-をオーでやったら「PGPファイルがみつかりません」とエラーになった。ここを数字のゼロにしたらあっさり"OK"と表示。このエントリに「ゼロです」を書いたものの、上記公式ページをみるとどうもゼロには見えない。念のためにもう１回ゼロでやってみたら「無効なオプション」だってさ（なので投稿内容を直した）。じゃあ「オー」が正しいのかよ？けど、おいら数字のゼロでうまくいったんだぜ。最近、いろいろPCに馬鹿にされてるわ。VirtualBoxにインストールしていたので手打ちで実行させたから、コピペ可能環境ならいちいちこんなことで問題にならなかったのかな？まさかコピペのオーはOKで、手打ちのオーはNG？
export http_proxy="http://＜プロキシサーバ＞:＜ポート＞"
さらに
/etc/apt/ のなかに apt.conf というファイルを作成して
Acquire::http::proxy "http://＜プロキシサーバ＞:＜ポート＞";
（最後はセミコロン）の１行を書き込みます。apt-get へ教えます。
※以下、言語というくくりでの話ではなくて漠然とPC用プログラム作成環境全体を指して言っていると思っていただきたい
基本的には.Netが好きだ。
Webを最初から意識して作られているし、標準ライブラリでカバーされてる範囲が広いおかげでVisual Studio入れるだけでサクサクかける処理が多いので再発明を強いられる事態に陥りにくいのが感涙ものだ。
C++/CLIもやりたいことが割とリーズナブルなコストでできるのでありがたい存在だ。
VB6は嫌いだ。
いろいろ拡張してくれた結果なのは知っているが、結局大事なところはダメ言語のままでMSから匙を投げられた存在という認識だ。
MFCも嫌いだ。
ひたすら面倒いし、出来たコードのメンテナンス性も・・・。メリットが今となっては動作の軽さだけだし（昔はむしろ逆の立ち位置だったんだろうが）。
だが、VB.Netは好きだ。
MSILを作るための道具であるがゆえに、VB6の痛い所が根こそぎ取り払われていると感じる。
C#でもいいのだろうが、セミコロンはなくても良いじゃない(あっても良いけど)。あと、オブジェクトを変数宣言しつつ初期化するとき、"クラス名 変数名 = new クラス名()"になるのが
クラス名をSystem.XXXから書いているときには耐えられない。As New万歳。
しかし悲しいかな、VB.NetはC#に押されて絶滅危惧種だ。
TypeOfを使わなくちゃいけない時にはVB.Netが恨めしく感じるけど、そんなに頻繁じゃない。
他のデメリットにしても、表記がウザくなるだけで書けない処理があるわけじゃない（このへんがVB6と決定的に違うところ)
にもかかわらず、VB6のイメージが悪すぎるのか、Javaからの移住人口が多すぎるのか、C#ばっかりもてはやされる。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 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"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
QWERTY配列のキーボードでタイピングするとき、ホームポジションの右手小指の位置にはセミコロン(;←これ)が存在します。
「これここにある必要ある？」と前々から思っていました。せいぜい、泣き顔(；；)を作るときに楽なくらいで、指をまったく動かさなくても打てる位置に置く必然性を感じなかった。(英文だとよく使われるんだと思う)
逆にハイフンのキー(キーボードとかニューヨークとかの伸ばす記号(長音符)を入力するときに使う)は右手ごとひねらないと打てない。セミコロンより圧倒的に使用頻度は高いのに。
というわけでKeySwapというソフトを使って入れ替えてみました。
スムーズに長音符が打てるのがこんなに快適だとは。これは素晴らしい。
自分のパソコン以外でやるわけにはいかないけど、それでも快適です。
今回使ったKeySwapはとても簡単にキーの入れ替えができます。入れ替えたいキーを押して指定するだけ。難しいことは一切ありません。
ただし、使うときはちゃんと同梱のreadmeを読んでくださいね。
