arveltのソフトウェア技術メモ

Arvelt's software technology memo

2017年を振り返って

前年度たてた目標

コンピューターサイエンスを勉強する
 特にアルゴリズム
新しいプログラミング言語について勉強する
 たぶんelixirかGo
積極的にコードリーディングする
 何かアプリかサービスとかを気軽に作る
漫画を書く
 例大祭と夏コミと冬コミ

 

目標を達したか

  • コンピューターサイエンスを勉強する
  • 新しいプログラミング言語について勉強する
  • 積極的にコードリーディングする
    • これらは全くできなかった
  • 漫画を書く

所感

漫画しか書いてねえなこいつ?
とにかくプログラミングができなくて困っているのだが、できるようになるビジョンが見えないままプログラミング自体を嫌いになっている状況にある。学習行為に手がついていないのは、その極限にまで落ち込んだモチベーションのせいであろう。 プログラミングを初めて10年になるができるようになっているわけではなく、どうにも自分には向いていなかったようだ。とはいえ10年をつぎこんでしまったのでいまから別の業種に転換することも難しい。かなり厳しい状況におかれている状況に間違いない。
仕事においてもデキる人との差が顕著になってきており、なんとかしてほしい的なことを要請されている。ふふふ。。。それができたらとっくに私も圧倒的成長を遂げていたましたとも。
とりあえず色々なものを諦めて、基本からやり直したほうがいいのだろうと思っている。例えば、コードを読んだ絶対量がそもそも少ないのでは?持ってるコードの引き出しが少ないせいで書くときにも困るのでは?ということをボスに言われたりしたのだが、これは私が思っていることとだいたい同じで、おおよく見ていてくれるのだなと感慨深かったりした。コードだけからこういうのがわかるのは私のボスはやはり優秀な人物なのは間違いない。
というわけでコードリーディングをしてみようというのが1つ。コード書かない仕事にシフトしてもいいよということを提案されているのだが、それってコード書けること前提ですよね!?という感じがあるのでやっぱり基礎的なことをおさらいせんことにはどうにもならないだろう。ていうか自分の力にするためのコードリーディングってどうやればいいだろう…?ということがわからなかったのでやっぱり能力がそもそも足らないきがする。というわけでただわかるだけじゃなくて、自分の力にするためのコードリーディングのやり方ご存知でしたら教えてください。
あとは製品作るよりも、コードのメンテナンス、コードを描きやすい環境を整える的な方が、ゴールが明確なので取り組みやすくそっち方面にいってもいいかなと思い始めている。ライブラリのバージョン管理したりメンテナスしたり、既存のAPIに追随したりとか。そういう感じのやつ。
そんなふうに全く暗い話しかでてこないのだが、年いってから始めたお絵かきやら漫画やらは新刊3冊までこぎつけて多分逃避的な意味もあるのだろうが、とりあえず出せたのでよかった。ていうかここで技術ブログで漫画の話してもしょうがないのでさわりだけ。 書くのは結構大変で一ヶ月二ヶ月の可処分時間を全て捧げてやっと1冊という感じなので、春と冬だけとかそういう感じにしたい。漫画描きは趣味の1つとして今後も続けたい。

来年の目標

  • コードリーディングする
    • Django
    • Goole App Engine SDK
    • 自社製品のコード
  • 周辺環境やライブラリについて調べる癖をつける
    • アップデートしたりメンテナンスしたりできるようになる
  • 漫画を書く

Real world HTTPを読んで

私は雰囲気でWebアプリケーションを書いている。 いまだにCOBOLを書いていた時間の方がながかったのだからまだまだひよっこである。 少しでもWebの気持ちがわかるようになりたいのでちまちま読んでいた。

私は以下の項目について内容を思い出せるであろうか?人に説明できるであろうか?できなかったのなら私はこの本を読み直すべきである。

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

「リファクタリング」にみるコードの不吉な匂い

以下は「リファクタリング」Martin Fowler、に出てくる コードの不吉な匂い である。これらを感じるコードは不具合の温床になりやすい、ということらしい。

これらを眺めてなぜいけないのか、どう修正したらいいか。時々思い出そうと思う、思い出せなかったら読み直すのだ。

 

  • 重複したコード
  • 長過ぎるメソッド
  • 巨大なクラス
  • 多すぎる引数
  • 変更の発散
  • 変更の分散
  • 属性操作の横断
  • データの群れ
  • 基本データ型への執着
  • パラレル継承
  • 怠け者クラス
  • 早すぎる一般化
  • 一時的プロパティ
  • メッセージの連鎖
  • 中間者
  • 仲が良すぎるクラス
  • 暮らすのインターフェース不一致
  • 未熟なクラスライブラリ
  • データクラス
  • 相続拒否
  • コメント

 

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

 

 

「USJのジェットコースターはなぜ後ろ向きに走ったのか?」を読んで

最近USJ行ったので、前から気になっていた「USJのジェットコースターはなぜ後ろ向きに走ったのか?」を読んだ。

 

ハリーポッターが当たるのは間違いない、だがそのためには売上の半分をつぎ込む設備投資をする必要がある上に、なによりも完成までの3年間をいかにして持たせるか。そのためにお金を描けずに客を呼ぶ方法は?ということについて頭をひねった経緯がえがかれている。とてもおもしろい。

 

実際行った感じたしかにUSJはよくできていて、ハリーポッターの世界がここにあるということに関してはあふれんばかりの努力を感じ取れたし、そもそも私はジェットコースターには乗れない方だけども、ここでしか買えないグッズなどを大量に買い込んだりして楽しめた。

とはいえ、フィールドは思ったよりこじんまりしているしお城はスケール感が小さいし、雨の日でも楽しめるようにしたというが実際は屋根がある場所がほとんどなく最悪の体験だったし、やはりこんなものかと思ってしまったのである。楽しかったからこそ、気に入らない部分が目につくとかそういったことだと信じたい。

 

この人のアイデアの考え方は、解決しなければいけない問題を正しく前提におくことでそれを埋めるアイデアをひねり出す、というものだ。これはつまり、宮本茂が言うところの「アイデアというのは複数の問題をいっぺんに解決することだ」ということの目的を逆算して実行していることになる。
宮本茂が山内や横井から受け継いだ天性の嗅覚で答えを嗅ぎつけていたのに比べ、この人はアイデアを閃かなければ行けない状況、というものを作ることでその問題を解いていたのである。またそれをただのひらめきで済ませないために、数字の裏付けを必ずとっていたというのは理想的と言える。

この人にプログラミングをやらせたらきっといいプログラマになるだろうと思った。

 

ところで、
イデアの発想法についてはみな色々一家言あるようで様々な人が触れている。たとえば以前読んだもので言えば、「アイデアのつくり方」などは森岡氏が言っている手順ほぼそのものと言っていい。

アイデアのつくり方

アイデアのつくり方

また森岡氏が言うところの、「リアプライ」という概念はこれはつまりすでにあるものを形を変えて実行するということであるが、それは星新一が実践していたところの「アイデアは異なる同士の組み合わせ」のことであるし、そもそもそれはアイザック・アシモフの言葉である。

このようにアイデアとその実践ということについては、多くの人がみな色々な方法を試し実践していたのである。幸い私はそのようなことをしなければ打破できない状況に置かれたことはほとんどないのだが、にっちもさっちもいかなくなったのならこのような偉大な先人のことを思い出したいと思う。

 

2016年を振り返って

去年立てた目標

フロントエンドは諦めたので、サーバー側の勉強をしていく。いかしたAPIはどういうものか?そのための適切な設計は?テストの書き方は?そういう感じのこと。 品質について体系的なことを知りたい、というのは諦めない。 ブログをちゃんと書く。ちゃんと普段から勉強してれば月に1つくらいは書くことあるというのは経験上わかっている。それができるくらいには学習を怠らないようにしなくてはいけない。 やらない言い訳のために自分でハードル上げてしまっている気がするので、もっと気軽にアプリケーションを作りたい。ライブラリだか、ゲームだかはわからないけれど、とりあえず3日くらい勢いで書いて公開方法はあとから考えるくらいの気軽さで取り組めるメンタルに変えていきたい。 あと漫画かけるようになりたい。

目標を達成したか

  • サーバー側の勉強
    • 明確にこのために取り組んだものはない
  • 品質について
    • やっていない
  • ブログ書く
    • 去年よりも減った
  • 気軽にアプリ作る
    • pkmn-tool.appspot.com とか作った
  • 漫画書く

所感

全然やれてないなぁと自分で思った。プログラミングがうまくできなくてとにかくプログラミングができるようになりたいと思っているのだが、だいぶ迷走しているのだと思う。1つには基本的なことを何も知らないのだということについてちゃんと受け入れて勉強するべきだと思っている。

そこで、コンピューターサイエンスをちゃんと勉強したいと思う。とはいえ、じゃあ仕事で目の前のコードを書くときにその価値があるのか?というと多分そんなに差はない。知っていれば役に立つことも万が一ある、程度でしかない。でもだからこそそういう部分の積み重ねで差がついてしまっているのだと考えている。

勉強なくちゃいけない、プログラミングできるようにならなくちゃいけない、と思っていてもじゃあ何をしたらいいのかというのはよくわかっていなかった。そんな中例えば Google Tech Dev Guide こういうページがあって、一人前のソフトウェアエンジニアになるために勉強することが並んでいる。これはとてもありがたくて上から順番にやっていこうと思った。

そして挫折したのだ。私は学生がやるようなこういったものを学ぶことのできるレベルにさえ至っていないということだった。だからそこにいたるまでを1つずつ丁寧に積み上げ直すしかないだろうと思っている。それで仕事ができるようになるかというと多分関係ない。そこまでわかっていてもやるしかない。他にやり方はわからないからだ。

仕事でやるプログラミングをうまくやれるようになるための方法として、いろんなコードを読むようにすることを考えている。これは薄々感じていたのだが、私が今まで読み書きしたコード量はいわいるすごい人と比べたら圧倒的に少ないのだ。そこに問題の本質があるように思う。仕事で使っているdjangoとか、pythonらしいコードとして評判だったGAEのPython SDKとかを読んでみたいと思う。

漫画を書きたいと思って例大祭で同人デビューした。やりたいやりたい言いながら手を付けなかっていなかったことに挑戦したのはがんばったと思う。あとこっちは趣味なので当然だけど、プログラミングの勉強をするよりもずっとずっと楽しいのだ。今後もやりたい。

来年の目標

思考する機械コンピューターを読んで

思考する機械コンピューターを読んだ。とてもおもしろいのでみんな読んだほうがいいと思う。 コンピューターサイエンスを勉強してみたくてやろうと思って講座みたいなやつを眺めていたんだけどまず何言ってるかわからないみたいなことになって困った。そもそもどういうことを考えるのがコンピューターサイエンスなのだろうかと知りたいなぁと思ってたらこれがおすすめされていたので買った。特にCPU、というか演算装置っがいったい何なのかがよくわかっていなくて、読んでも全部わかったわけじゃないけどなんとなくとっかかりがつかめたのが良かった。

  • ブール代数
    • AND
    • OR
    • NOT
  • ビット
    • 違いを表す最小の単位
  • 論理回路の実装
    • ビットを表現できれば物はなんでもいい。木と棒、電流、水流、1と0。
    • 複雑な入力や出力を持つ論理関数も論理回路の組み合わせで表現できる
  • コンピューターの基本部品
    • スイッチ:複数の信号を1つにまとめる
    • コネクタ:スイッチ同士を結ぶ分岐可能な配線
    • レジスタ:情報を保存する
  • 有限状態機械
    • ブール論理で表現されたルックアップテーブルと記憶装置で表現される。
    • シーケンス(連続した処理の手順)を認識できる
  • チューリングマシン
  • アルゴリズム
    • 計算可能なものを計算する手続き。
    • 計算量に基づく処理時間が大きく変わる。
  • ヒューリスティクス
    • アルゴリズムで解くと現実的ではない時間がかかってしまうような問題で、答えの精度は下がる代わりにだいたいの場合に正しい回答を得るような方法
  • データ圧縮
    • グループ化
    • 意味のある情報だけを残す
  • 並列コンピューター
    • 優れた並列処理はデータの違う部分をそれぞれのプロセッサが担当する
  • 人工知能
  • 工学的手法以降
    • 進化論的シミュレーション

文庫 思考する機械コンピュータ (草思社文庫)

文庫 思考する機械コンピュータ (草思社文庫)

P8H67-V REV 3.0をWindows10でスリープから復帰しない話

困ったこと

ASUS P8H67−V Rev3.0がWIndows10でスリープから復帰できない、ブルースクリーンになる。

 

対応方法

Station-Drivers - X99 OC Formula から Intel Chipset Device Software Driversをダウンロードしてインストールしたら直った。

 

経緯

ASUSマザーボード、P8H67−V Rev3.0を使用している。これをWindows10にアップグレードしたときに、スリープから復帰できなくなったり、メモリー系のエラーを出してブルースクリーンを吐いたりするようになった。この異常の直後はUSB周りのドライバが死ぬことは知っていた。 しかし何をすれば解決するのかがわかならなかった。

これを書いた前日の深夜、とうとうあらゆる操作を受け付けずに起動できなくなった。新しいメディアからクリーンインストールしてもうまくいかない、そしてデバイスマネージャーからドライバを更新しようとして、OSに対応するバージョンがありませんという趣旨のエラーメッセージを見た。これで原因がわかった。

 

マザーボードのドライバがWindows10に対応していない。

ならばと思ってASUSのサポートサイトを見に行ってもサポート対象?がWindows8.1までしか用意されていない。これはどうしたものかとおもいきや、すでに同じことで悩んでいた人がいた。

価格.com - 『Windows10 64bit使用でのエラーについて』 ASUS P8H67-V REV 3.0 のクチコミ掲示板 

これによるとStation-Drivers - X99 OC Formula が型番違いだがこのチップセットドライバを使うことができるようだ。このままでは動きやしないしし、いちかばちかいれてみた。結果うまくいった。

 

しかし困難は続いた。Windos10は足りていないドライバを勝手にインストールしてくれる機能がある。動作を確認しているうちにこれが働いたようでグラフィックドライバが入った。しかしすでにnvidiaのドライバがインストール済みであった。深く考えずに再起動した。そして画面は暗黒のまま沈黙した。 

それを見て気づいた。ドライバが競合して死んだらしい…。

セーフモードですら暗黒を保った。散々調べ続け試し続けた結果、ビデオだけが問題であったので、低解像度起動すると操作できることがわかった。グラフィックドライバを改めて入れなおし事なきを得た。

 

これで直ったと信じたい…。

 

<次の日に追記> 

直ってなかった。

再起動したら再び黒い画面。

上記で入ったマザーボードのドライバとビデオカードのドライバが競合状態にあり、うまく表示されない。マザーボード側のビデオドライバを無効にすることでちゃんと表示されるようになった。