  |
はてなキーワード: 例外処理とは
なぜライジングサンコーポレーションのSEってのはプログラマーに対して、仕様書に書いていない事をやらせるのか？
仕様書に記載していなかった事を作りこんでいなかったら、不具合扱いされた。
いや、書いてある事を実現出来なかったらそれは不具合と認めるよ。
「書いていない」というと「常識だろ」と言われる。あんたらの製品の常識かもしれないが、こっちには常識では無い。
ましてや、全てを底辺プログラマーのせいにして、なんとかという精神的追い詰め会議に呼び出すのはどういう事か？？？
それでも、「書いてくれ」と言い続けると、「全てを網羅出来ない」と開き直る精神がすごい。
なら「こちらも全てのエラー処理例外処理等を網羅出来ない」と言い返すのはタブーである。ここまで言うと、ライジングサンコーポレーションのエライ人達はキレる。
品質向上プロジェクトとかあるようだが、プログラマーをいびる事で品質が上がると思っていたら大間違いだ。
君たちのその開き直りを直す方が先ではないかね？
大企業のシステムエンジニアは目の前の膨大なコードの前に立ち尽くし、いかに事故を起こさずに今回の客の要求だけを反映するか四苦八苦し、実装後はただ逃げ切る日を夢見る。俺の腐れ上司もちょこちょこっとシステム修正しオフラインで活躍し……ああつまり飲み会やゴルフで部長に媚びへつらい別の部署へ逃げ切っていった。
そうして俺の直上司は誰もいなくなり、一人か二人の学生上がりＰＧをメンバにもった俺が今度は修正をする番になる。
要求を読む。結構無茶な要求だが、敵はそれだけじゃない。コードが正ならコードを読めばいい。ただこの腐れ切ったコードが本当に正しいとは限らない。
俺は更新履歴の腐れ切ったワードの仕様書を開く。誤字脱字のオンパレード。例外処理云々といった赤字が散見されつぎはぎだらけのゾンビーになっているのがわかる。
腐れ切ったコードと腐れ切った仕様書。この仕様書の記載をしたのはファイルの更新日からすると二代前の部長だ。当時を思い出す。あの異常なスケジュール下でいいかげんな部長が変更仕様を仕込むとすれば、まずここの影響範囲の見込みを漏らすだろう。しかも高圧的な得意先だ。タフな交渉術を持たない部長のことだから得意先の負荷が高いインのテストパターンは申し入れしなかっただろう。ここも危ない。ああ、こっちもヤバそうだ。
そうやって前任者を想像しながら仕様書を読み込んでいくと、そこここに前任者のゴーストを読み取ることができる。俺はこいつをぶち殺すのが好きだ。まるで前任者自身をぶち殺せるかのような錯覚に陥る。
仕様書を生まれ変わらせる。そしてコードを生まれ変わらせる。腐れた部分をぶち殺す。このときの感覚を俺はエンジニアズハイと呼んでるが、この業界、多かれ少なかれみんな似たような体験をしたことがあると思う。
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
議論していて、とても板がみずらいので。
こちらをお借りします。
269 ：（´ー｀）y─┛~~ ◆UxQ8uxJMok：2014/05/31(土) 20:12:01.17 発信元:123.225.138.170
> 全てこちらの論証通りとさせていただくだけですので、
> 私としては問題ございません。
オマエが真似れば殺しに行くだけだからこっちも問題ない。
という訳で、上記のとおり、
下記論証で解決いたしました。
連番召還ではないですが、「場札を出す処理に連番の条件を要す」に該当。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
> 「場札を出す処理に連番の条件を要す」に該当。
との反論がありましたが、
連番とは
複数の番号が連続していること。また、その番号。
とのことですので、１に対する２、２に対する１も連番となります。
２つ以上の整数があれば成り立つ形式ですね。
何をですか？
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
こんな初歩的な質問が来るとは……侮っておりました。
基本的に、「デッキが０枚なら敗北する」というルールエフェクトも
「山札が尽きたときに自動誘発する効果」なのですが、多分聞き入れられませんので具体例を。
Laboratory Maniac / 研究室の偏執狂 (２)(青)
クリーチャー — 人間(Human) ウィザード(Wizard)
あなたのライブラリーにカードが無いときにあなたがカードを引く場合、代わりにあなたはこのゲームに勝利する。
2/2
万が一の保険
[部分編集]
OPERATION
O-73 青 1-3-0 R
CHARACTER(UNIT)
CH-S29 白 2-3-1 R
【(自動A)：自軍本国が0枚になっても、自軍プレイヤーは敗北しない】
【(自動D)：ターン終了時に自軍本国が0枚である場合、そのターンの終了直後、自軍プレイヤーの新たなターンを開始する。新たなターンの終了時、自軍プレイヤーは敗北する】
「山札がつきた際に自動誘発する効果」とやらを具体的に提示してみました。
破壊するって書いてある：それも含めての誘発効果です。「コストの支払い」は行われません。
速度と戦闘力は反比例しない、凄い速度は威力に等しいので前提が崩壊しています。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
すごい！超時空会話が出来ました！
まず、その「当該ゲームシステムについての記述」とやらを具体的に提示できねば反論として破綻。
手札の定義をしてください。
まさか、全てのゲームに手札があると思っているわけではないですよね？
私ですらゲームをつくる際には「このゲームは～～を手札とします」という定義を行います。
ちなみに「最初に選んだ手持ち札」という前提であれば、金色のガッシュベルTCGの魔本でやっています。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
デッキの１枚目と２枚目が手札になる仕様というだけで……「任意に選択できる」のですが。
あれ？ なにか私分かり難いこと言いました……？
一応、ポケットモンスターカクメン列伝という、手札を全て任意に選べるものもありますから、
そういう方向性を話した方がよかったのですかね？
手札の定義をしてください。
ボードゲームとかでは、場にある３枚のカードから好きなのを手札に移していいよ、とか良くありますね。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
◆UxQ8uxJMok ：2014/05/30(金) 23:40:05.89 ID:mGswB6A1
の記載にて反論が認められませんでした。
優先権は元々細分化されているので、そもそも論理が成り立っていないかと……。
ttp://mtgwiki.com/wiki/%E5%84%AA%E5%85%88%E6%A8%A9
ちなみに、この項目がTCGに限っていないので、TRPGやウォーゲームなどでは乱戦処理などで
「標的を指定できない限定的な行使の権利」や遠距離攻撃の一方的に「標的を指定する権利」がありますね。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
↑パクリの兆候を感じた段階で、裏取りせず下記の警告文が送られ、そのトレーディング・カード・ゲーム制作者は～。
↑実物カードゲームhttp://ai.2ch.net/test/read.cgi/entrance2/1395426290/の～。 カードゲームに限定ね。 ほぃ、論破完了ｗｗ
すごい行間を読むと、確かにそうなっているみたいですね、難しいですが。
上記優先権に関しての記載にて反論が認められませんでした。
遊技王の優先権の処理は必然的にこうなるようになってませんでしたか？
ttp://yugioh-wiki.net/index.php?%CD%A5%C0%E8%B8%A2=
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
それであれば、「特に本校に記載されている"特別な許諾行為"を行わずとも"当該行為と同様の処理は行うことができる"」ということですね。
特許権にあります「有用な発明」項目の独自性に含まれないため、特許権としての効力を失います。
もし、「相手に干渉しない場合の行動は続けられる」という場合では他カードゲームよりも優位性はないので、
「有用な発明」項目の独自性に含まれないため、特許権としての効力を失います。
その昔、実際のTCGとして出たアルテイルにはAgi(素早さ)の処理がありました。
どちらのターンであれAgi順に優先権が決定していたと思います。
◆UxQ8uxJMok ：2014/05/30(金) 23:39:14.66 ID:mGswB6A1
> 「クルセイド」には
攻撃順序の判定ではありません、上記に記載した通り「優先権」を得ます。
「移動、待機、スキル使用、攻撃の判定を能動的に宣言できるタイミング」である「優先権」を得ることが出来るのです。
「優先権を持っているプレイヤーが全ての行動ができる」とは限りませんので、覚えておくとよいですよ。
トイレのドアを開けたまま用をたす癖がついちゃってさ～。って言ってわかる？
やあ、当方東京在住30代後半同期入社職場結婚共働住居賃貸男女２児保育園在籍痔主歴15年です。
http://anond.hatelabo.jp/20131130161624
↑に書いたアレコレの一日のフロー＋例外処理は単なる事務処理みたいなもんです。
育児が辛いとも楽しいとも一切書いてないのに何故か子供を愛してないと書かれる不思議。
コーラを飲んだらゲップが出るでしょ？それとコーラが美味いか関係あんのか？無いだろ！？
愛情かけたら子供の熱が治るの？糞まみれの衣類が綺麗になんの？って話ですわ。
まともに子育てに取り組んだ方々からは「それってふつーだよね」ってブコメを頂いていま
すが、そのとおりであほみたいに余裕が無く見える保育園育児だけど、あそこに書いたこと
って保育園に通わせてる親だったらほぼ皆、普通にこなしてることだから我々夫妻が特殊と
いう事では無い。（妻のみが担当している家庭も多々あるが。）
当たり前の育児を読んだだけなのに「ドヤ顔で忙しいアピールうざい」みたいなコメントは最も
んで、もっと工夫して楽すれば？というご意見について書ききれなかった実践している（し
た）事を以下に述べる。
・結婚直後
・妊娠中
0歳時以外の保育園入園は倍率が非常に高く困難であることを調査。翌4月で保育園入園の
方向で決心。（公立保育園は例外以外は4月以外入園出来ない。これ超重有。）
夫も子供の面倒をみれるよう母乳とミルクの混合で栄養を与えることとする。
これにより、夜泣き時や妻寝不足や体調不良時に母乳が出ないから夫には手出しは出来な
いという状況を回避。
・住居
諸事情で当初住まいを引っ越す際に賃貸のメリットを活かし妻実家～保育園の中間地点へ
移動。
あくまで予備としてのみ活用。
急な発熱時。どうしても行って欲しい通院等予備的に月に１・２度は妻母の出番となる。
・食洗機
当然使用。
正直我が園はどの家庭も忙しい。よって飲み会などは少なめと思われるが、開催された
場合は常に夫妻同時出席。
・食事
保育園で出されるバランス栄養食品に便り、正直手抜き気味。特に夫の作る料理はコメ・
肉（OR魚）・作りおきの何か・味噌汁（スープ）・果物。的なものが多い。
・第二子妊娠計画
前回の反省を活かし4月～夏頃の出産を計画（赤子の時間を長時間育児休暇する為）。
子作りを前年夏以後に実施。
計画通り夏前に出産。翌4月に0歳時で入園成功。（第一子がいると二人目の子供は同一保
予定が計画され次第相手に通告。相手の日程が空いていれば機械的に参加可能となる。
何がいいって言うと、育児を大きなストレスに感じる事が無く楽しむ事が出来る。
（もちろん子供にイラッとする事はしょっちゅうだがあくまで一時的な話。）
・一日中子供の世話をしなくていい（デメリットとして、初めてしゃべった。初めて歩い
・通勤時等に会話出来ており、自分の時間が足りないので、夜・休日などにパートナーに
話を効いて欲しい等、思うことは無く自分の時間も少しは使える。
・仕事トラブル発生時等に社内インフラメール等で即時相手に連絡・バトンタッチ出来る。
・相手が昼間なにやってるか気にならない。
もちろんこれらはパートナーとの関係性にや子供の性格や仕事のストレス度等様々な要因が
からむので一概にはいえないのは当たり前であるが、少なくとも我々夫妻は共働きしてい
る事で子供を愛していないという事は一欠片も無く、むしろストレス少なく子育てをエンジョイ
していると自信を持って言える。
よく誤解されるのだけど、素朴な概念同士を組み合わせていくと矛盾を避けることができなくなるのはむしろ当たり前のことだ。
素朴な概念は、複雑な現実世界(巨大情報量)をアバウトな方法(情報量小)で分類などを行うものなので、ある一面からみると合理的になっているようにみえても大抵恣意的なルールが潜んでいる。
だから別な切り口の素朴な概念を組み合わせようとするとほぼ必ず矛盾がでてくるのだけど、文部省の教育要綱が悪いのか、素朴な概念は例外処理も少なくて良い等と思う輩が多くて閉口する。
現実の問題を整合性をもって「正しく処理」するための適切な方法は、基本的にそれなりに大きな複雑性のある概念(情報量中大)で切り分けていってそれなりに多い手順の運用で回すしかないってことを、いい加減みんな理解してくれないものか。
もちろんリソースは有限なので、本来「正しく処理」できることというのはひとつの組織の中でも非常に限られてくる、というところまで理解されている必要がある。
そうして初めて「それなりの正しさ」で妥協するということの価値を理解してもらえるわけで・・・、業務システム開発者の苦悩は深い。
Webブラウザによって，マルチバイトファイル名の取り扱いが異なるというのが問題なんだよね
いままでは，http://kingyo-bachi.blogspot.jp/2012/10/railssendfilechrome.html
を参考にして，ファイル名をURLエンコードすることでお茶を濁していたんだ
でもこれだと，Firefoxでファイル名が文字化けすることに気付いてしまった
気づかなければ放置していたんだけどね ：P
http://rails.hatenadiary.jp/entry/2013/01/31/104006 を発見
（生sjisと，URLエンコードの違いはもう少ししっかり書いておかないと誤解招かないかな？という当ページへの突っ込みはさておき）
つまりは，基本は日本語ファイル名をUTF-8で扱うぞ，ただしIEだけは例外としてSJISに変換してやるぞ
ということだね
ちょっと気になったので，このあたりのブラウザの対応状況をざっと調べてみたよ
なお調べた日本語ファイル名は「今日の予定.doc」．「予」という漢字が入っているのがポイントね
| 生utf8 | 生sjis | url_encode(utf8) | url_encode(sjis) | |
| chrome(win7-64bit) | ok | x | ok | x |
| firefox 18 (win7-64bit) | ok | x | x | x |
| IE9(win7-64bit) | x | ok | ok | x |
| firefox(MacOS X) | ok | x | x | x |
さらにいろいろ調べてみると，正式にはRFC2231に準拠させるのが正しいみたい
http://fgin.seesaa.net/article/30073826.html によると，
IE6は対応してなかったようだけど，私の中ではIE6はもう絶滅していることになっているので！
Railsのsend_file関数でさ，RFC2231準拠のContent-Disposition表記ができたらいいのにな（チラッチラッ）
プログラムはclassに記述します。たとえばSampleという名前のclassを作る場合、Sample.csファイル内に次のように書きます。(C#の場合、ファイル名とクラス名は同一でなくても良い。複数のクラスを書いても良い)
public class Sample { }
プログラムはclass内のMainメソッドの先頭から実行されます。Mainメソッドは次のように書きます。
public class Sample { public static void Main( String[] args ) { // 処理を書く } }
Console.WriteLine( "Hello world" );
コメントです。
// 一行コメント /* 複数行コメント */
// 変数 int num;
データ型です。C#のデータ型には値型と参照型とがあります。以下は値型のデータ型です。
// int(整数)型 int num; // char(文字)型 char c; // float(単精度浮動小数点)型 float val; // double(倍精度浮動小数点)型 double val; // bool(論理)型 bool flag; // DateTime(日付)型 DateTime date;
以下は参照型のデータ型です。
// String型 String s; // 配列型 String[] array;
プログラムをコンパイルするには、コマンドラインで以下のようにします。
csc Sample.cs
プログラムを実行するには、コマンドラインで以下のようにします。
Sample.exe
mono ./Sample.exe
int、float、double型の変数に数値を代入できます。int型には整数だけ代入できます。float、double型には整数でも小数でも代入できます。
int i = 2; int i = 100000000; float num = 1.234f; double num = 1.234;
四則演算です。
num = 1 + 1; num = 1 - 1; num = 1 * 2; num = 1 / 2;
商の求め方です。割る数と割られる数が両方とも整数の場合、計算結果の小数点以下が切り捨てられます。
num = 1 / 2; // 0
割る数と割られる数のどちらかが小数の場合、計算結果の小数点以下が切り捨てられません。
num = 1.0 / 2; // 0.5 num = 1 / 2.0; // 0.5 num = 1.0 / 2.0; // 0.5
余りの求め方です。
// 余り mod = 4 % 2
インクリメントとデクリメントです。
// インクリメント ++i; // デクリメント --i;
String str = "abc";
// 結合 String join = "aaa" + "bbb"; // 分割 String[] record = "aaa,bbb,ccc".Split( "," ); // 長さ int length = "abcdef".Length(); // 切り出し "abcd".Substring( 0, 2 ) // abc // 検索 int result = "abcd".IndexOf( "cd" ) // 見つかった場合はその位置、見つからなかった場合は-1が返る
配列です。
// 配列の宣言 int[] array;
配列の生成です。配列の生成時には要素数を指定するか、初期データを指定します。
int[] array; // 要素数を指定して配列を生成 array = new int[5]; // 初期データを指定して配列を生成 array = new int[] { 1, 2, 3 }; // 宣言と同時に配列を生成 int[] array2 = new int[5];
配列の要素の参照と代入です。
// 要素の参照 array[0] array[1] // 要素の代入 array[0] = 1; array[1] = 2;
array_num = array.Length;
int[] from = new int[] { 1, 2, 3 };
int[] to = new int[5];
from.CopyTo(to, 0);
if文です。
if ( 条件 )
{
}
if ～ else文です。
if ( 条件 )
{
}
else
{
}
if ～ else if文です。
if ( 条件 )
{
}
else if ( 条件 )
{
}
while文です。
int i = 0; while ( i < 5 ) { // 処理 ++i; }
for文です。
for ( int i = 0; i < 5; ++i ) { // 処理 }
int[] fields = new int[] { 1, 2, 3 }; foreach (int field in fields) { // 処理 }
C#では関数をメソッドと言います。メソッドを作るには次のようにします。戻り値を返却するにはreturn文を使います。
static int sum( int num1, int num2 )
{
int total;
total = num1 + num2;
return total;
}
ファイル入出力です。ファイル入出力を行うには、プログラムの先頭に以下を記述します。
using System.IO;
以下がファイル入力の雛形になります。ファイルのオープンや読み込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamReader reader = null; try { reader = new StreamReader(filename); String line; while ((line = reader.ReadLine()) != null) { } } catch (IOException e) { // エラー処理: } finally { if (reader != null) { try { reader.Close(); } catch (IOException e) { } } }
またはC#ではusing ステートメントと言うものがあり、この様にも書ける
String filename = "text.txt"; using (StreamReader reader = new StreamReader(filename)) { try { String line; while ((line = reader.ReadLine()) != null) { // 読み込んだ行を処理 } } catch (IOException e) { // エラー処理: } }
usingをつかうとCloseがなくなったことからわかるようにusing(){}を抜けるときに自動的にDisposeメソッドを呼び出し、オブジェクトを廃棄する。その分コードがスッキリするが、使いにくい場面もあるので考えて使うこと。
以下がファイル出力の雛形になります。ファイルのオープンや書き込みに失敗した場合、catch節に処理が移ります。
String filename = "text.txt"; StreamWriter writer = null; try { writer = new StreamWriter(filename)); writer.WriteLine("abc"); writer.WriteLine("def"); writer.WriteLine("fgh"); } catch (IOException e) { // エラー処理: } finally { if (writer != null) { writer.Close(); } }
こちらもusingを使って書ける。が、割愛する。
C#でよく出てくる知っておいたほうがよい文法の一覧です。
繰り返し文の途中で抜けるにはbreak文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { break; // 条件を満たす場合、for文を抜ける。 } }
残りの部分処理をスキップし、次の繰り返しに進むにはcontinue文を使用します。
for ( i = 0; i < 5; ++i ) { if ( 条件 ) { continue; // 条件を満たす場合、残りの部分処理をスキップし、次の繰り返しに進む。 } }
例外を投げるにはthrow文を使用します。
throw new Exception( "Error messsage" );
try { // 例外が発生する可能性のある処理 } catch ( Exception e ) { // 例外発生時の処理 }
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
なんかと、関係があるかと思ったけどよく考えたらあんまりない話。「ジョブコーチ入門」という本に載っている、仕事を教えるときにやってはいけない7つのこと。
Aを起動させて、えっと、それから何をやるんだったかな……
まずAを起動させて……いや、まず例外処理がないかどうかBを見ておくんだった、あ、でもBを見たってたいてい例外処理なんてないしなぁ。うーんと、ま、とりあえずBを先に起動させておく、ってことで。
よし、まずCのチェックからだ。え、昨日の人からはAを先にって教わった? いや、今日は俺のやり方を覚えてもらうから。
この花びらをひとつずつお皿の上にのせていくんだ。やってみて。……雑すぎるよ、もっと丁寧に。少し下、あ、ちょっと右だな、一つ一つ注意して……
今からやってみせるから、後でまねしてみてね。……（5分無言）……はい終了。ね、簡単でしょう?
違う違う、そうじゃないったら。まったく、何回言ったらわかるんだか。
おお、いいねいいね。こないだよりずっといいよ……
そろそろ四月ということで、職業としての「プログラマ」になる方も、はてな界隈では多いでしょうか。なにはともあれおめでとうございます。マの世界へようこそ。私も４月になるので、心機一転頑張りたいなと思い、働いて学んできたことや言われてきたことなどをつらつらと書き出します。
仕事のルールはたくさんあります。その中で座右の銘ではありませんが、指針となるような一つ目標があるといいでしょう。私が念頭に置いているのは「三年後に気持ちよく転職できるようにする」ということです。結構移り気が激しいタイプなんですよね。でも人には嫌われたくないという。「気持ちよく」というのがポイントで、会社を「気持ちよく」辞めて転職するのは今までに辞めていった先輩をみていてもなかなか大変そうです。「気持ちよく」辞めるための仕事術を「上司」「同期」「後輩」「自分」という点であげてみました。大切なのは「気持ちよく転職できるようにする」ために周りの人を気遣いそれを示すことで「あいつはよく頑張ってくれた」「次も頑張ってもらいたい」「また一緒に仕事をしたいな」と思ってもらい惜しまれつつ転職できるようにすることです。
あなたの上司は仕事全体の進捗の管理とメンバーの割り振りを考えます。そのために各人に割り振った仕事の進み具合や仕事量に無理がないかを把握する必要があります。あなたはそれを考えて、自分が行っているタスクの状態をきちんと上司に報告しましょう。現状に無理があるようなら、その状態と代替策を上司に相談しましょう。
大抵の人は忙しいのと、別の問題で頭を使っているため、きっとあなたが頭を悩ませて質問したいと思っている、その特定の問題について、あなたほど深く考えていないでしょう。そんな時にただ質問も投げられても、相手も一から考えてしまうので、お互いに負荷が高くなってしまいます。それで相手のことを考えて、技術的な質問や方針などの相談の際には質問の後に「こうしてみようと思う」「この点が問題なのでこうすれば解決するはず」など、それなりに自分の答えをもって、質問や意見をすべきです。そうすれば相手もそれをベースに自分の意見や経験を考えながら伝えることが出来るため、あなたの質問に答えることがそれほど重荷ではなくなります。
楽しく笑顔で働きましょう。笑う門には福来るではないですが、多くの人は笑顔に惹き付けられるものです。また上司も基本、自分の舵取りでメンバーが楽しく仕事出来ていると思いたいものです。それに応えましょう。
会社には多くの場合、コーディングルールやドキュメント規則があります。「こうしたほうが早いのになあ」とか「こんなのクールじゃない」とか考えることもあるでしょうが、ルールに従いましょう。３年後に後輩に「ここはクールじゃなかったらこうした」と説明するのは大変ですし、きっと３年もたてば、その「クール」も変わっているはずです。もしどう考えても効率が悪いようなら会社のルール自体の改善を訴えましょう。
上と矛盾するようですが、急ぎ仕事（こればかりやる会社もある）をやる場合は、ドキュメント不要ということもあります。そんな場合でも最低限の仕様等のドキュメントの記録を残しておきましょう。引き継ぐ後輩に口頭で伝えるのは手間というより、忘れている部分も増え、伝言ゲーム状態になります。これは、人日を割当られていないのにやるわけですから、ちょっと大変ですが、意識しておきましょう。
自分がどう考えて、どう上司とやり取りをしていたかを簡単な記録でいいので毎日つけましょう。将来の後輩が見た時にきっとそれが、励ましや何かのヒントになるはずです。
自分についてはこのひとつだけ。失敗をしないのは仕事をしない人だけです。三年後にはどうせ転職するのですから、失敗をおそれずルールを守りながらも常に新しい何かを探して創りだしていきましょう。そうすれば転職の際に自分はこういう挑戦をしてきたという自信が出来ますし、以前の会社で思い切れば未練なく辞めることが出来ます。
失敗は怖いですが、それを少し減らす方法として「失敗を想定する」プログラマ的に言えば「例外処理」を考えておくというのがあります。人はわからないものは怖いですが、失敗した、間違いを犯した場合はこうすればいい、最悪こうなるということがわかっていれば、その恐怖は減るものです。そしてその「例外処理」を書きおわったなら、明日のことを考えて、思い悩むのは辞めて、その日、その日の仕事を頑張りましょう。
仕事の進め方について書いてみましたが、冒頭でも述べたように、プログラマは一サラリーマンである以上に一職人です。プログラムについての勉強を常にしましょう。勉強は会社をやめても人を裏切りません。プログラム言語についてはもちろんですが、それだけではありません。仕事をしているとついつい忘れがちになりますが、基本的なデータ構造とアルゴリズムやデータベースの仕組みやネットワークの仕組み等の計算機科学を知っておくことが大切です。またプログラムの組み方については、デザパタやエンタープライズアーキテクスチャパターンなどを知っておくと仕事をすすめやすいでしょう。
私のおすすめは「勉強会駆動勉強」です。何か勉強したいな、身につけたいなあと思うことがあったら、それをテーマに近くのコミュニティの勉強会の発表申し込みをします。人に教えようとすると自分のものにしなければいけませんから必死に勉強します。するとその知識が身に付くのはもちろんこと、その分野について詳しい人と周りに思ってもらえるかもしれず、また第一人者からアドバイスを受けることもできます。なかなかの一石三鳥です。
勉強のことについて、最初と逆になりますが私たちは一職人ですが一サラリーマンです。ハッカーといえど、社会人としての基本的な知識である英語や数学や経済学をおさえておきましょう。経済学は感覚とは違う部分で社会が動いていることがわかり、おもしろいです。私のおすすめは「スティグリッツ入門経済学」ですね。また習慣として毎日のニュース（日経）や週ペースの経済雑誌（東洋経済等）を読んで、基本的な現代経済をおさえておきましょう。自分の仕事を社会の目から客観的におさえることが出来ます。
最後に。仕事のことや勉強のことをたくさん書いてきました。しかし、仕事に最適化しても人生はおもしろくありません。運動を適度にし、自分の趣味を見つけて興味を持ち（私はアニメとラノベ読み）、いろいろなことを学んで、楽しみながら人生を過ごしましょう。