 
|
はてなキーワード: エラーとは
「受信トレイ フォルダが満杯のため、これ以上メッセージを保存できません。メッセージを保存する領域を空けるには、古くて不要なメッセージを削除するか、フォルダを最適化してください。」
ん？受信トレイは空なんだけど
とりあえず素直に受信トレイフォルダを「最適化」したら、受信が始まって、エラーは出なくなった。
社員の人から問い合わせを受けてから5分もかからず対処できたので、まあよしとしよう。
Thunderibirdは、無料のうえに出来がいいソフトだ。どんなソフトにも１００％は期待してないもん。
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
私も悪いところがあるので、決して相手だけ悪かったとはいいません。
…が、一方的に悪者扱いされて、でも周囲に「反論したりしたら泥沼だよ」と言われて我慢した分のうっぷんをここで晴らさせてください。
あまり面白いものではないのかもしれないので、気分悪くなりたくない方、あと時間のない方（長いっす）は回れ右、でｗ
私は、恥ずかしながら小説を書いたりするのですが、ある小説コンテンツ上で公開した小説に「すごい面白かったです。漫画化していいですか？」と書き込みしてきたのがその相手でした。
ほかにも面白かった、というコメントはあったのですが、実際に絵がうまい人に、漫画化までしてもらえる、というので、私は舞い上がりました。
彼は、自分の境遇とその主人公が似ていると言っていて、かなりのスピードで、実際に漫画を描いてくれました（でも、完璧主義らしくて気に入らないところがあったとか言って消されて結局見てませんが。。。）
なので、私も資料探しなんかに協力していたのですが、そのうちにいろいろ話がもりあがり、ほぼ毎日メールをするようになりました。
ところがあるとき、突然彼が登録していたSNSのアバターを女性のようなものに変えたので、その意図を問うたら、謎を解いたうえで自分に会いに来い、と言ってきたのですが、いろいろ問い詰めているうちに結局性同一障害で、体は女なのだ、と告白してきました。
そして今まで話をしていた内容のほとんども嘘だ、と。
それでも私は仲良くなった相手だし、その時はまだ常識のある人物のように感じられたので、いろいろと嘘をつかれていたことを全部水に流して、そのあとも付き合いを続けていくことにしまた。
けれどおかしくなってきたのはそのあとです。
ちょうど去年の今頃くらいからでしょうか。
彼の作っていたSNS上のサークルに参加したのですが、メールでやり取りしていた時とは違い、気に入らないことがあると雑談版に書き込み、その後とにかく攻撃的なメールを携帯にしてきて、ぼこぼこにされたのです。
そのあまりの内容に、私が泣きながら電話をして謝って仲直りをして、を繰り返していました。
はっきり言って今思えばその内容も、矛盾だらけだったし、「それ私悪くないじゃん」的な内容や、彼が勝手に事実を捻じ曲げて発言していたり、自分が言ったことを責任転嫁していた部分も多かったのですが、人格否定するような言葉の羅列に打ちのめされてしまって反論もできずにいたんです。
そのため、もう縁を切ろう、と毎回思いました。ですが、相手は自分を信じていろいろさらけ出してくれたのだし、それを突き放すのはいけない、と我慢して電話をしてつなぎをつけていました。
そうして、ほぼ月一で、ほとんど喧嘩、というより人格否定のオンパレードのメールが来きて、それに私が電話して謝って、の儀式が続いていたある日、突然『忙しいから』と彼がサークルを脱退しました。
その直前にサークルメンバーへのバッシングを書き連ねていた彼は、新たにサークルを立ち上げる宣言をしていましたが、それらのコメントも全部消したうえで突然の脱退……
管理人は直前に私に委譲されていましたが、実質上の管理者の脱退でサークルは混乱しました。
けれどつながってすぐぶち、と切られる始末。
メールも送ったら「アドレスが不明です」といったエラーメールが返ってきて、ほんの一昨日送った時には通じたメールがアドレス変更されて通じなくなっていたのです。
加え、SNSでは私はブラックリストに入れられて彼のプロフも見れない状態となり、完全に連絡が取れなくなってしまいました。
しかも彼は別のサークルを立ち上げ、そこで楽しく新しいメンバーと活動を始めただけでなく、ブラリしてない旧サークルの一部のメンバーだけそこに誘ったり、していて、私もブラリされたほかの子も「ああ、切り捨てられたんだな、と実感していました」
そんな扱いをされてはもうしかたない、と、私を含めたサークルメンバーは、見切りをつけて自分たちで新しいサークルを立ち上げよう、と動き始めたのです――が、その矢先です。
大体1か月くらいたったころですかね。
それも、恐ろしく普通の感じで。
「ちょっと忙しかったから全部シャットアウトしてたんだ、うん。携帯壊れたからここに連絡くれ」
と番号付のメールが来ました。
ガチャ切り、アドレス変更、理由のわからぬブラックリスト入り、突然のサークル脱退。
それで、かなり頭に来ていた私は、完全に無視していたのですが、そうしたら私の小説を上げていたHPブログ、ヤフブロ、どころかアメーバピグのメッセージも送ってきたうえ、私のピグライフの庭にまで出没し、私の名前のわかるところすべてにコメントをしてきました。
バッシングもあれば、すがるようなコメントもあり、日と時間でコロコロと内容の変わるメッセージやコメントがずらずらとならんだのです。
私はペンネームをそのままハンドルネームにしていたので、簡単に追跡できる状態だったとはいえ、ほとんどストーカー状態で付きまとわれ、しかも彼自身の開設したブログで「あいつの書いている小説は俺の盗作だ」とか「サークルの世界観も似たようなの知ってるしな。パクリと言われないといいけど」といったバッシングには、精神的に参ってきてしまいました。
そこで、サークルで関係したメンバー全員で文面を考え、彼がよくメンバーにやっていたように「返信不要」とつけた一方的なメールを送り、絶縁状を叩きつけたのですが、そうしたら今度はトーンの変わったメールが全員に送られてきたのです。
「このたびは迷惑をおかけして申し訳ありませんでした。一言電話で直接お詫びをさせてください。それができなければ自分は存在する価値がないため、今日中に自殺します」
いや、こけおどしと分かっていたんです。仲間には放っておけ、という人もいました。
でも、自分のせいで死なれるなんていやだ、と思い仕方なく電話しました。
ですが、そこでまた、さらに恐ろしいことを言われたんです。
「いや、実は一回会った時（一回リアで会ってたんです）からマジで好きで、どうしてもつなぎ取りたくて、でもやり方がわからなかったからあんなやり方したんだ」
――正直、馬鹿じゃないの、と思いましたよ。
たとえどんな理由だとしても、一生懸命書いた小説を盗作扱いされ、世界観を馬鹿にされ、それで好きと言われて「本当に？？？」と喜ぶ女がどこにいよう。
その時はとりあえず、すでにリスカしたとかいう相手を刺激しないように、と温和な感じで話をしましたが、もう話をする気ないことは伝えていました。
でも、私の中にはぐるぐると「盗作」「パクリ」という言葉が渦巻いていました。
何時間もかけ、創意工夫を凝らして書いたものをそういわれるのがショックで、それに正直、相手のことはもうどうでもいいと思っていたし『ネット絶ちする』と言っていた言葉を試す意味で、ブログにこの落ち込みを書いていました。
「お前、ブログに書くな言うたやろ。それに、今思えば俺だけが悪いわけじゃないし、手打ちするなら今まで、俺が更けてるとか、描いてる絵は老け顔が多いとか言ってきた件についてそっちが謝ってこい」
とのこと。
古い喧嘩の内容を蒸し返して…というなら、まあブログに書いた私も私なので納得がいく。
でも、自分が老け顔だ、とか絵が老け顔が多い、と最初に言ったのは自分なのに、それをその場のノリでいじっただけの私が悪いことになっていて、それを謝ってこいという。（逆に何かで私がいじられたことも多々あった）
しかも、前の件って一方的に縁を切ってたのは自分なのに、古い昔の件があるから私が悪いっておかしいでしょ。
あと、
「謝ったら許してやっていい」
あの時は私が「許してやる」はずの立場なのに、なぜ下から私が「許してもら」いに行かねばならないのか。
「俺は精神的に普通じゃないんだから、変な行動をするかもしれないって言ってあっただろ」
それらがあまりにばかばかしかったし、周りみんなから無視するようにアドバイスされていたので、数分おきに入っていた着歴もブログコメントも全部無視していたら、
「もうお互いのことは忘れよう」
とか
みたいな内容のメールが来て、それを最後に連絡は途絶えました。
ようやく連絡が途切れてほっとしているものの、おかげで2作ほど盗作扱いされた小説はあげられなくなりましたし、もやもやしたものが私の中に残りました。
そうしてしばらくもやもやしていたのですが、ふとした拍子に「ボーダー」という存在を知り、ああ、全くあてはまるな、と思ったのです。
来歴の嘘をつき、相手の同情を誘う。
きつい言葉を叩きつけ、激怒するくせに、少しするところりと機嫌が変わって普通に接してくる。
逆にきつい言葉を言われたり、無視されたりすると、自分の存在自体を否定するような言葉を言って消えようとする。
何かあると自殺をほのめかす。
自分が悪かったことを捻じ曲げ、相手のせいにする。
などなど。
でも、今境界性人格障害について知ったのちは縁をきれて本当に良かったな、と思っています。
なんていう考えの人間のそばにいられはしないし、そんな人が支配するサークルではやっていけませんからね。
彼曰く、私は悲劇のヒロインらしいですが、別に同情なんてほしいと思ってません。
ただ腹が立つので吐き出す場がほしいだけです(笑)
そして私の場合、吐き出すのに一番いい方法が文章を書く、というだけです。
これ見つかってまたメール面倒ですが、その時はその時です。
近頃人気ですね。一時期のGREE・モバゲーバッシングはどこへやら。
と言う話はさておいて、今までソーシャルゲームとは縁の無かった方々がプレイしている影響か、
このゲームにやたらと夢を抱いている人が多いようです。
特に、『アニメ化されないか』『アイマス新作に誰か出演しないか』等のメディア展開に関係するものや、
『新イベントの提案』『全体的な動作改善』『ゲームバランスの変更』等のゲームそのものに対する要望が目立ちます。
断言しておくと、動作改善がやや望みある程度で、他は「ありえない」ですね。
理由は下記。
・KONAMIの戦国コレクションがアニメ化と言う前例がありますが、
あれはKONAMIが自社で製作しているゲームだから実現できた話です
よって、新作への出演も無理
知っての通りモゲマスは、既存ゲーム（神撃のバハムート→戦国サーガ→モゲマス）の
モゲマス独自の要素（親愛度）もありますが、バグの温床となっています
（しかもそのバグ修正の方法が非常に稚拙かついい加減だったことは記憶に新しいですね、
（ダブルクォートがあったりなかったり、スラッシュで閉じていたり閉じていなかったり）
パーサに掛けたらエラー連発でしょうね
既存ゲームの挿げ替えであるがゆえに、上記2つのゲームの同じ箇所で誤字脱字が存在しています
気付いていないのか、直す気がないのか…
・モゲマスに限った話ではありませんが、
この手のゲームは『人よりお金を多くかけた人』が俺TUEEEEを実現出来ないと成り立ちません
人よりお金を払わない・そもそも一銭も落としていない人に対する運営の優先度は極端に低いです
だからこそSRカードの性能は壊れていますし、今後もっと壊れていきます
これらを理解した上でプレイしたり数万円つぎ込むのは、別段問題があるとは思いません。
近年、有名人などが亡くなった際に、亡くなった方の属する宗教・宗派が分からないのに、気軽に「ご冥福をお祈りいたします」というフレーズを掲示板やコメント欄などに書き込む人が多い。
ぶっちゃけ、よく怖くないな、と思う。「ご冥福」というのは、単純に考えれば「冥土での幸福」ということなのだから、「冥土」が定義されていない宗教では未定義になる。あるいは、「冥福」より広く解釈して「死後の幸福」という意味で使ったとしても、「死後は必ず幸せになれる」という教義の宗教の場合は、心配しなくてもいいことを祈っていることになる。空文と同じだ。
というわけで、未定義エラーまたは空文になる可能性の高い「ご冥福をお祈りいたします」という言葉は、慎重なプログラマなら避けるべき言葉である。「ご冥福」などという教義依存（環境依存）な言葉を持ちださなくとも、「謹んでお悔やみ申し上げます。」に言い換えれば良いだけの話だ。
女 26歳
こっちから送らなきゃね！って送ってみたけど、
宛先エラーもいくつか。
そりゃ、たまに会う上京してった人より
普段から遊んでる仲間と騒ぎたいよね…
って、言い訳くらいしろよ(^^)
卒論の書き方わからないからおしえて〜って気づいたら私が書いてたし、
保育士になりたいんだけどどうしようって、資格の取り方から調べさせたり、
なんだったんだアレは。ああ、利用してたんか。
ひどいぜ真美子
って、だいたいみんなそんな感じ。
私も私で舞い上がって協力して、用が済んだら音信不通
新年早々落ち込む。
高校生の時、新学期にメアド交換して夜にヨロシクメールしたら、
「仲良くしなきゃいけないみたいでキモかった笑」って、
聞こえよがしにいじめられた。
なんなの。あんたが連絡先聞いたんじゃん。
//ダイアログクラスにメンバ変数を定義 std::auto_ptr<CBitmap> m_pbmp; //bitmapを設定するメンバ関数 void C*****Dlg::Set*****Bitmap() { CDC* pDC = GetDC(); CDC memdc; memdc.CreateCompatibleDC(pDC); m_pbmp.reset(new CBitmap()); CBitmap&amp; bmp = *m_pbmp; bmp.CreateCompatibleBitmap(pDC, width, height); CBitmap* old = memdc.SelectObject(&amp;bmp); memdc.FillSolidRect(0,0,width,height, color); memdc.SelectObject(old); ((CStatic*)GetDlgItem(IDC_STAIC_*********))->SetBitmap(bmp); }
スクリーンと同じデバイスコンテキストとビットマップを作成し単色で描画している。描画し終わった後のSelectObjectを忘れてはいけない。
CStatic::SetBitmapに渡した後も実際に描画されるまでCBitmapの寿命を保証しなければならない。
そのためメンバ変数にCBitmapを持たせるがCBitmapが再利用を考慮していないという驚くべき仕様なので仕方なくauto_ptrでラップしている。
いい加減MFC滅びてくれないかな。抽象度が低すぎる。こんな記事自分のブログに書きたくないよ。
さらにVisualStudio 2005のauto_ptrのバグを見つけた operator = にポインタを渡すとおかしくなる。これは本来コンパイルエラーになるべきで代わりにresetメンバ関数を使用するべきだ。
修正するには<memory>ヘッダのauto_ptr_refのコンストラクタのひとつ上の行(642行目)に private: template<class T> friend class auto_ptr; を挿入する。
第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 練習問題
これは、「（他のライブラリが必要な）特殊なモジュール使ってますか？」「環境依存の設定ありますか？」とかを包括した質問かもしれない。
（コンパイラオプションで関数を使う／使わないって切り替えする奴とかで、おまじないとして大量の定義が必要な仕事場はあった）
使ってる検査ライブラリが、ドライバのライブラリを静的リンクしてた時、「なんか（インストールとか）必要なの？」って聞いたこともあるよ。
「この○○ってライブラリが参照してる××ってなに？」じゃなくてね。
まぁ、言語仕様は知ってるけど、開発環境の仕様は知らないって人、多いよ。
んで、そういう事についての感性が低い人は、確かにいる。
完全な初心者の状態から勉強を始めてから大体5ヶ月でウェブサービスが完成したので何を用意したり何をどうやって勉強したらいいのか色々書いてみました。
アイデアはあるんだけど、プログラムとか難しそうで自分にはウェブサービスなんて作れないと思ってる人がいたらその敷居を少しでも低くできたらいいなあなんてと思ってます。
ちなみにボクはぼんやり１年くらいはてなブックマークにのってる記事を見ていてプログラムとかできたらいいよなあなんて思っていてようやく重い腰をあげた人です。
さらに自分は文系で数学も英語もロクにできない人なので、基本的に誰でもサイトは作れると思います。
そもそも中学生でもプログラミングができるんだから大人に出来ないわけないですよね。
これからウェブサービスを作りたいっていう方の参考になればと思います。
※自分も初心者なのでまちがってることがあったら教えてください。
●何を用意すればいいのか
※自分がWindowsなので何個かWindows向けのソフトを紹介しています。
※Macの方は申し訳ないですが、Mac向けのソフトをご自分で探してください。
(1)メモ帳
アドビのdreamweaverっていう便利なソフトがあるらしいですがお金もかかるし別に必要もないと思います。
ただのメモ帳だと使いづらいのでボクは「TeraPad」っていうフリーソフトを使っています。
例えばプログラム言語ごとに表示を切り替えると、関数とかコメント部分の色が変わって見やすくなって便利です。
・TeraPad ： http://www5f.biglobe.ne.jp/t-susumu/library/tpad.html
サイトを作っても各ブラウザごとに見え方が違うのでそれぞれ確認するために何種類かブラウザをインストールしましょう。
ボクはIEとFireFoxとChromeの３つをそれぞれ表示して確認していました。
OperaとかSafariも本当は確認しないといけないと思うんですがこの3つで十分だと思います。
(3)XAMPP
ザンプって読みます。ざっくり言うとローカル環境(自分のパソコン)でプログラムを動かす環境を作るソフトです。
いちいちサーバーにアップロードしなくても、プログラムが動くかを確認できるので便利です。
またレンタルサーバーでプログラムが暴走してしまうと迷惑がかかるらしいのであらかじめ自分のパソコンで確認するのがいいようです。
・XAMPP： http://www.apachefriends.org/jp/xampp-windows.html
(4)ドメイン
何とかドットコムっていうやつです。ネット上の住所的なやつです。example.comとかexample.netとか。
ボクはお名前.comでドメインをとりました。ドメインの個人情報を隠せる？サービスがあるのが理由です。
まあどこで取っても大して変わらないと思うので目についたところで取るといいと思います。
「.com」だったら年間1000円くらいです。長すぎるドメインはとらない方がいいかもです。
(5)サーバー
ネット上にファイルをアップロードするところです。ドメインが住所だとすると土地みたいなイメージです。
ボクはさくらインターネットさんのレンタルサーバー(スタンダードプラン)を借りています。
理由はグリーの社長さんがほめてたから。お金も月額500円なので安いです。
同じ500円だとニコニコ動画のプレミアム会員になれますね。ちなみにボクは一般会員です。
さっきファイルをアップロードとかさりげなく書きましたが、そのファイルをアップロードするソフトがFTPソフトです。
ボクはFFFTPを使っています。最初使い方がわからなくて戸惑いましたが慣れれば簡単です。
・FFFTP ： http://www2.biglobe.ne.jp/~sota/
(7)FireMobileSimulator(FireFoxのアドオン)
携帯電話のサイトを確認するには基本的に実機で確認するのが一番ですが、個人で全部そろえるのは難しいです。
そこでFireFoxのアドオンのFireMobileSimulatorという拡張機能を使って簡易的に確認するのがおすすめです。
XAMPPのようなローカルサーバでも確認することができます。
・FireMobileSimulator ： http://firemobilesimulator.org/
FireMobileSimulatorで確認できるといってもやはり見え方は違います。念のため実機で確認しましょう。
ボクはiphone使っていてそれの確認はしてるんですが、androidの友達がおらんのでまだ確認してなくて実はまだ不安だったりしてます。
上と同じようにやはり実機で確認した方がいいです。特にガラケーは見え方もそうですが、プログラムがうまく動かなかったりします。
例えば、AUだけフォームに「enctype="multipart/form-data"」を入れてると文字化けするという謎の現象が起きたり。
他にも色々あって制作に時間がかかったのは正直このガラケーのせいです。色々３キャリアで統一とかしてくれないんですかねえこれ。。。
友達のY君とMさんとNさん本当にありがとうございました。匿名ブログだけど感謝してます。
●何を勉強すればいいのか。
さて具体的に何を勉強すればいいのかわからない人がいると思いますが、以下を勉強すればウェブサービスが作れます。
ということでひとつずつ説明。
マークアップ言語っていうらしいです。プログラムじゃなくてhtmlファイルを作る言語です。
とりあえずhtmlでサイトの文書の論理構造を書いて、cssでサイトの見た目をキレイにするものだと思ってください。
適当に検索すれば勉強できるサイトがたくさん出てくるのでそこで勉強してください。
本も売ってますけど基本的なところは難しくないので買う必要はないと思います。
調べると、html5とかxhtmlとかあって戸惑うかもしれませんが、とりあえずPCとスマホなら何でもいいと思います。
(ガラケーについては各キャリアごとに対応させる必要があります。書くとすごい長くなるのでガラケー用にサイトが作りたいなら調べてみてください。)
ただhtml5が一番新しいので今後勉強される人はそれの方がいいかもしれないです。
ちなみにボクはたまたま見たサイトがxhtmlの説明だったので今回はxhtmlで作りました。
まだボクは90年代初頭のホームページみたいなデザインしかできないので偉そうなことは言えないんですが(笑)
最初はhtmlだけでサイトが作れると思っていたんですが、はてなのような動的なサイトを作るときは何かしらプログラミングする必要があります。
んで、いろいろ調べるとperlやらRubyやらJAVAやら色々でてきて一体どのプログラム言語がいいのか悩むと思いますがウェブサービスが作りたいならPHPがいいと思います。
理由はウェブに特化した言語っていうのと他に比べると簡単で勉強時間が少なくて済むらしいので。
PHPなんかで本なんか買う必要はないらしいんですが、ネットのサイトだとよく理解ができなかったので本を買いました。
以下の書籍がとてもわかりやすくていいです。おすすめです。やっぱり本は体系的にまとまってるので勉強がしやすいです。
この本の通りやっていけばとりあえずプログラムが動く感覚が得られます。
あとすごい賢そうなことをやってる感覚になるので頭がよくなったような気がしますよ（笑）
MySQLもこの本で勉強ができます。MySQLというのはデータベースで、そういうソフトです。
他にもOracleとかPostgreSQLとかあるらしいですが、
とりあえずMySQLでSQL文っていうのを勉強するとデータの検索だったり、データのアップデートだったりが数行でできたりするのですごい楽になります。
決して簡単ではないですけど、思ったより難しくはなかったっていう印象です。
自分は大抵その時理解できなくてもだいたい一晩寝てから、もう一度頭からやり直すと理解できました。
(3)Apache
ボクはさくらさんのレンタルサーバーを借りていて今回はあまりいじってないんですが例えば「.htaccess」という名前のファイルを作るとapacheの設定をいじることができます。
例えばアクセスされたくないファイルがあったらそういう指定を「.htaccess」というファイルに書いておけばアクセスされないようになります。
基本的にパソコンと同じように作ればいいです。ボクは以下の本を見て勉強しました。
「iPhone+Androidスマートフォンサイト制作入門(たにぐちまこと)」
正直ネットの情報でも十分だと思いますが一度体系的に勉強するのもいいと思います。
ガラケー向けのサイトの制作は特殊で一度頭真っ白の状態で勉強した方がいいです。それだけPCとスマホとは全然違います。
ネットにも情報はたくさんありますが、断片的なものなので以下の書籍で体系的に勉強してから補助的にネットで調べた方がいいです。
この本は実践アプリケーション集というだけあってそのまま使えるコードが収録されているのがとてもいいです。
正直PHPのプログラミング自体はそこまで難しいという印象はなかったんですが、この本に出会わなかったら多分ガラケー向けのサイトは作れなかったと思います。
もしガラケー向けのサイトが作りたいならこの本を買うのが近道だと思いますよ。
CakePHPとかSymfontとかいうのがあるらしいです。
このフレームワークを使うとあらかじめある程度のところまでできてるんで、ボクみたいに全部TeraPadで手書きしなくてもいいみたいです。。。
(2)javascript
PHPはサーバーで動作するプログラム言語ですがjavascriptはブラウザ上で動作するプログラム言語です。
非同期通信なんていうよくわかんないけど何かすごいこともできたりするらしいですよ。
●もし調べまくってもわからなかったら
もし一日中検索してもよくわからなかったらそういう時はネットの頭のいい人たちに質問しましょう。
ボクは以下のサイトで質問していました。
(1)ヤフー知恵袋
巷ではヤフー知恵遅れなんて言われてますが、コンピュータ系の質問に関してはしっかり教えてくれる人がほとんどです。
ポイントを100枚くらい使うとカテゴリマスターなんていう天才が回答してくれます。
(2)２ちゃんねる
どういうスレッドなのかよく読んで質問しないとボロクソに言われますが、２ちゃんねるなのに皆さんすごい優しく教えてくれます。
たまにケンカしてたりすることもありますがそのときはケンカが終わるまで待ちましょう。ケンカの流れで質問がスルーされたりします。
ヤフー知恵袋も２ちゃんねるもそうですけど、質問するときは自分の環境をしっかり書いて何がしたいのか、どんなエラーがでるのか明確に書きましょう。
回答する人もわからないですし、自分がほしい回答がまず来ないと思います。
あと当たり前ですが回答してくれたらお礼をしっかりいいましょうね。
●こうして出来上がったウェブサービス
こうやって今回できあがったのが６人まで登録ができる招待制のレンタル掲示板です。
「ひそり-秘密共有ネットワーク」(http://hisori.com/)です。
なんだ掲示板かよー！！とか言わないでください(笑)これでもけっこうがんばったんで。。。
そういえばサイトを作ろうと思った経緯を書いてなかったんでちょろっと書いておきます。
ボクはミクシィとツイッターをやってるんですが、一瞬その時だけ仲のよかった人の更新とか見たくなかったりするんですよね。
でもマイミクを外したりフォローを外したり小心者のボクにはできなかったりするわけです。
そもそもあーいうソーシャルって自分のキャラに一貫性をもたせないといけないから窮屈なんですよね。
例えば、会社の同僚には真面目を絵を書いたようなキャラだけど学生時代の友達には下ネタ好きのどうしようもないキャラだったりすると
マイミクやフォロワーにその会社の同僚がいたら、下ネタなんか書きたくても書けないという窮屈さがソーシャルにはあるわけです。
だったらあらかじめ人数制限しておいて、例えば同じ学生時代の人しか見ることができないサイトがあれば
下ネタだって気にしないで何でも書けるよねっていう考えに至ったわけです。
今回６人までという人数制限と招待制っていう形にしているのはそういう理由と本当に仲のいい何でも話せるグループに使ってもらいたかったからです。
んで、ネットにそういうのがなさそうだったので勉強がてら自分で作っちゃえ！ってことで今回作りました。
ちなみに何で秘密共有ネットワークなのかというと「招待制無料レンタル掲示板」だとどんなサイトかイメージがつかないと思ったからです。
じゃあ何て名前にしようかと考えた結果、秘密でも何を書いても大丈夫ですという意味を込めて「秘密共有ネットワーク」って名前にしました。
とまあ、そういうことで初心者でボクみたいな完全文系の人でもこれくらいのサイトなら作れるんで
もしプログラムとか難しそうとかそういう理由でウェブサービスの制作を躊躇してる人はぜひチャレンジしてみてださい！！
※もしサイトが変な挙動がしてるとかあったら更新報告用にツイッターのアカウントを作ったんでよかったら教えてください。
http://twitter.com/#!/hisori_com/
ではでは。。。
今回の日本シリーズは第１，２戦を中日ドラゴンズが敵地で連勝してしまい、戦前のソフトバンク（以下ＳＢ）優位
の予想を覆してしまいました。３戦目からのホーム３連戦を迎えて断然優位になってしまったドラゴンズ。
しかし案の定、本質的な戦力差とエラーなどドラゴンズの油断したミスが続き、あっという間にホームで三連敗し、
再び福岡に戻り６戦目は吉見の好投で勝利。最後は手も足も出ず完封されて日本一を逃してしまいました。
悲しいことに落合ドラゴンズ、このシリーズの各試合で２点以上点を取れていない・・・２点しか取れない打線なのです。
もともと若い人にファンが多い落合監督。twitterやmixiやら2chですら落合監督最後を嘆く声や８年間の感謝の声が多く
退任が決まっている落合監督の花道を日本一で飾れず、２年連続日本シリーズ敗退は落合信者的にどうなんでしょうか。
こんな屈辱的な敗北許せないと思うんですが、落合信者は「この戦力でよくここまで来れた」と評価を嵩上げして思考
停止しています。打撃の専門家である人が監督なのに、こんな最弱打線を作り出してしまった問題がスルーされています。
ＳＢ秋山監督は走塁の向上をキャンプから取り組み効果的に実戦に活かしました。
統一球になり長打が見込めない中でこの判断は戦力に大きく作用したと思います。
一方の落合監督の攻撃面でのめぼしい対策は見当たりません。
「負けたのは残念だけれど悔いはない。今までやってきたことを継続してやってくれれば。
これは最後の落合コメントですが、正直、今までやってきたことを継続していくべきなのか迷うところです。
ＳＢの投手ミーティングでドラゴンズ打線がどのように見られていたのか気になっていたのですが、
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
バージョン2.1.8で実装された「reflected script inclusionに対する保護」機能で上記エラーが出る場合
about:config の
noscript.xss.checkInclusions を false に変えるか
noscript.xss.checkInclusions.exceptions に許可したいドメインを入力する
セキュリティ対策めんどくさい
今月も増田への投げ売り堂の10月の結果と雑感を書き込みます。今日は長めになりそうで。
| 項目名 | 10月 | 9月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 4524 | 1983 | +2541 |
| ページビュー | 18736 | 8777 | +9959 |
| 平均ページビュー | 1.40 | 1.60 | -0.20 |
| 平均滞在時間 | 2.47 | 2.59 | -0.12 |
| 新規訪問数 | 27.45% | 29.90% | -2.45％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
今月は引き続き Amazon の仕様変更の対策と若干の機能追加に終始しました。
Amazon の仕様変更も殆ど問題無く修正でき、エラー等もありませんでした。
フィギュアだけ対応してたのですが、DVD・BDとゲームも対応をしました。
特撮DVD・BDは「keywords」ゲームは「Node」でそれぞれ10ページづつ商品を辿るようにしています。
ゲームはさほど商品の差は感じませんでしたが、DVD・BDは商品数が1/4くらいに・・・。
個別ページで Amazon レビューを確認できるようにしました。
とはいえ、API からそのまま iframe に張っているだけなのでいつでも出せるような機能で
今回の仕様変更で出品者情報が殆ど取れなくなった分、他の商品の情報を載せようと思い設置しました。
一応予定しているのが「アニメDVD・BD」復活と「PC関連商品」を新たに追加し
cookie で保存の表示商品を切り替えるオプションを設置する予定です。
URL 登録可能なサービスを運営しているとブラックリストに登録せざるを得ないような URL が登録される事もあるわけだけど、業者としてはそのブラックリストを逃れるために短縮 URL サービスを不正利用してきたりします。
短縮 URL サービス側に不正報告をしても、三流サービスなんかはいつ対応してくれるのか分からない。自前の開発だったらそもそも 301 を返すような URL は一律エラーにする対応も取れるのだけど、いつもそうとは限らない。
というわけで、以前調べた時に生きていた短縮 URL サービスのドメイン一覧を晒します。これをブラックリスト登録しておけば、大概は OK かと思います。
.*.1sta.com .*.24ex.com .*.2fear.com .*.2fortune.com .*.2freedom.com .*.2hell.com .*.2savvy.com .*.2truth.com .*.2tunes.com .*.alturl.com .*.antiblog.com .*.bigbig.com .*.dealtap.com .*.ebored.com .*.echoz.com .*.filetap.com .*.funurl.com .*.go2.jp .*.guild.gs .*.headplug.com .*.hereweb.com .*.hitart.com .*.jpn.ch .*.mirrorz.com .*.office.vg .*.soho.bz .*.tn.st .*.vze.com 007.sh 0oo.be 0rz.tw 1-0x.com 1-9.jp 1bps.biz 1cc.jp 1huji.com 2ch.to 2ch2.net 2z2.biz 34vv.net 3w.to 4649.st 5jp.net 690.jp 7pi.jp 99q.info a.rrweb.jp a6r.org a8-affili.info ac.la adop.jp akb.cx an.to bit.ly c.ly c23.biz d99.biz dwarfurl.com e-safar.com eeg.jp ez.cm fw.iclub.to g.nu gmaru.be goo.gl hyu.jp icanhaz.com ie.to is.gd j.mp j2url.com jpn.ch linkbee.com linkoop.com masl.to mf1.jp mixi.bz mj1.biz mo-v.jp notlong.com nsfw.in os7.biz p.tl php5.jp php6.jp piurl.com qrl.jp qurl.com qurlyq.com r1.gs rurl.jp s78.biz scut.ly sfurl.biz shorterurls.com simurl.com snurl.com ss.st su.pr t.co tens0.net tiny-url.org tiny.cc tinyurl.com to.cx to1.bz tok2.com tr.im traceurl.com twurl.nl ulr.jp ur1.jp url.ms urlenco.de urlz.jp urx.nu utun.jp wb2.biz ww36.com www.estyle.ne.jp www1.to www3.to xfs.jp xtw.me xurl.jp yutn.me z-x.in zz.tc
※色々理由を付けたりしてますが、結局の所、世の中にはこんなにいっぱい短縮 URL サービスがあるんだぜ！という驚きを共有したいだけ、かも。
理由は単純で、他の人に真似されたくないから。
だから結局トライ＆エラーで自分の会社内でノウハウを高めることになる。
または巨額の金を払って外注することになる。
学生の頃は「TwitterやFacebookこそ情強ツール！」と思っていたが、勘違いだった。
ネットで儲かると思われるノウハウや情報はほとんどの場合広告にすぎない。
個人をアピールするためだったり、商材を売りつけるための入口だ。
本当に利益を出す方法は自分達の頭で考え、ノウハウを生み出し続ける以外に無い。
汗水垂らして、一つずつ推論し、実証し、失敗しては改善しての繰り返し
これしか無い。
またそうで無ければ、新たな市場、新たな敵が登場した瞬間に何の防御も出来ずに殺される。