さて年末ですよっと

今年はいろいろありました。

会社の命令により、東北沿岸部に飛ばされる。
主な業務は営業SE
最初は３ヶ月間だけ…と聞かされてたのになぜか６ヶ月に延長

まだここまではよかった。

１年になりました　−>　５年になりました。

…え、なにそれ聞いていない。
５年間なんていられません。
しかも開発業務とはほど遠い業務だし、もたされたPCはVISTAのノートで調子が悪いもの。
正直会社の求めることと、自分のやりたいことが毎回毎回ズレていたので
先を決めずに退職をしました。

その後にすぐに内定を数件ゲット

いろいろ悩んだ挙げ句、上流SEとしての進路を選択しました。

その後、２ヶ月の研修期間を得た後にデスマ化したPJに関わることになるわけですが…
そのせいで読書も進まない進まない。

デスマでわかったことは。
　・上流と下流を分断した受託開発は不幸しか生まない。
　・オフショアは小さなカスタマイズならともかく、１からの開発は齟齬が発生しやすい。
　・知識不足、経験不足、どちらが掛けていても駄目。知識と経験を両方ふまえた上で開発しないと失敗する。
　・レガシーな環境はレガシーなSEが発生しやすい。（Ex.OOPを理解していない…など）
　・政治力、ほんと大事。「正しいことをしたければ偉くなれ」は真理。

ってーとこでしょーか…なんにせよ不幸をまき散らすだけの人にはなりたくないんで…

昔に比べて凄まじくコードは奇麗になったし、悪い設計といい設計の区別はつくようになった。
けどやっぱりアルゴリズムに対する苦手意識がコードを書く気力を奪っているので
来年はそのあたりの強化を行えるといいなー
今年メインに読んだ本

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

SQLアンチパターン

アジャイルサムライ−達人開発者への道−

来年は絶対アルゴリズム強化する。絶対に…ぶつぶつ

DevQuizに挑戦してみたでござる。

やってみたのは一人ゲームというゲームです。

ルールは以下の通り。

・10個以下の整数をプログラムに渡す。
・このプログラムでは以下の作業が行われる。
　全ての5の倍数(0を含む)を取り除く
　全ての数字を半分にする(端数切り捨て)
・問題の整数を取り除き、終了までの最短の操作回数を表示する。

案外簡単そうじゃね？と思ったけど再起処理を上手く書けずに全然だったorz
仕事上、現在技術営業サポートに回っちゃったんでプログラム全然書いてないから
リハビリがてらやってみたけど、トホホの出来；

# -*- coding: utf-8 -*-
def InputDigitList(digitlist):    

    digit = 0    

    while(len(digitlist) <= 10):

        digit = raw_input("数字を入力してください。")

        if digit == "":

            break                

        digitlist.append(int(digit))

    return digitlist
def RemoveFiveMultiple(digitlist):    

    for digit in digitlist:

        if digit % 5 == 0:

            digitlist.remove(digit)    

    return digitlist
def IsRemoveFiveMultiple(digitlist):    

    ModsCount = 0

    for digit in digitlist:

        if digit % 5 == 0:

                ModsCount += 1

    return ModsCount != 0
def IsAllRemoveFiveMultiple(digitlist):    

    ModsCount = 0

    for digit in digitlist:

        if digit % 5 == 0:

                ModsCount += 1

    return ModsCount == len(digitlist)


def HalfNumber(digitlist):

    DisplacementDigitList = []

    for digit in digitlist:

        DisplacementDigitList.append(digit / 2)    

    return DisplacementDigitList    
def CreateDigitList(digitlist):

    newdigitlist =[]

    for digit in digitlist:

        newdigitlist.append(digit)

    return newdigitlist
def CountStep(digitlist,step):    

    step += 1    

    if IsAllRemoveFiveMultiple(digitlist):

        return step

    print digitlist    

    

    HalfDigitList = HalfNumber(digitlist)

    StepHalf = CountStep(HalfDigitList,step)

        

    if IsRemoveFiveMultiple(digitlist):

        ModDigitList = RemoveFiveMultiple(digitlist)

        StepMods = CountStep(ModDigitList,step)

        if StepMods > StepHalf:

            return StepHalf

        else:   

            return StepMods

        

    return StepHalf            
if __name__ == "__main__":

    

    DigitList = []

    DigitList = InputDigitList(DigitList)
    Step = 0
    Step = CountStep(DigitList,Step)

    print Step

    

↓作った奴はここにおいときます。
https://github.com/sigunerion/SelfGame

年明けました。

新年の挨拶

あけましておめでとうございます。今年もよろしくお願いします。

今年についての抱負だのなんだのと語ろうかとおもったけど、結局は
去年やってきたことを引き続きやっていくだけなんで
立てる必要もないかな、と。
（既に計画は立てていると楽だよね！）

正月はずっとCiv5やってました。モンテスマかわいいよモンテスマ。
なんで彼、すぐに戦争仕掛けてくるんでしょうね？

TOIECもやるべきか？

別にわたしゃ資格至上主義ではないです。
やりたいことを実現したいための手段と考えてます。
ただまぁ、英語の文献を読みつつ・・・ということも最近増えてきそうな予感はするので。

そんなわけで。

今年を振り返ってみる。

とりあえずそろそろ書かないと今年が終わってしまうので。

振り返ってみると色々ありました。

1月、休職から復帰

こっそりやってた転職活動とデスマが重なって体調崩してしまいました。
実際に去年の6月あたりから、会社のやり方に疑問を感じつつあったので
逃げ出そうと思ってもなかなかうまく行かず・・・

2月〜3月、再びデスマ

復帰直後、めちゃくちゃな設計書の上で開発工程に引きずり出されたわけで。
客とやり取りする側のメンバーの意思疎通が上手くいかず、非常に大変でした。
ここでも残業100〜120時間ちょっと。
4月、会社から再休職の要望
事実上の休職指示。
4月でだいぶ落ち着いたので体調は取り戻しつつあったのだけどね。

5月、課題をこなせとの会社からの指示

これ1週間でコミットは絶対無理！って量の課題を出されました。
なんだかんだでコミットはしましたが。
ですが評価基準を予め提示されてない上に「業務上に支障をきたす」という判断が下されました。
後々で考えてみると「福利厚生に問題はない職場」を演出したかったそうで。
給与改定もありましたが、評価基準を明確に提示せず、やはり抽象的な評価しかしませんでした。
入社時点でも車を強制的に購入させられたこともありましたし
この時点で今の職場に対する信用はなくなりました。

6月、再び休職に

非常に悔しい思いをした上での休職でした。
が、ここで某にゃとらん先生やずさの人に励まされます。
一番効いた発言がコレ

22:39 (nyatla) だって、就職といってますけど
22:39 (nyatla) ｱﾚ、労働契約ですよ？
22:39 (nyatla) 社員って言ってますけど、従業員ですよ。本来は
22:40 (nyatla) 雇用契約して従業員やってる連中が、勘違いして”正社員”がなんか特別なものだと思ってるだけで
22:41 (nyatla) 正社員なんて、慣習以外のなにものでもないお

よくよく考えると、ああ正社員至上主義ってもう古いよねって。
そしてこっそり転職活動をしつつ、9月までマイクラtekitで遊びつつ・・・
上手くいきませんでしたけど；
この間、設計についての重要性を認識させられました。

9月、復職後

とりあえずC#系の案件をこなしつつ、という形で仕事をやっていましたが・・・
戻ってからというものの、顧客と会社、納品物がEXCEL主体の現場に頭をなやませました。

とはいうものの、休職中に設計の重要性を知り（むしろ興味を持ち始めたというか）
UML中心に学習を始めました。

9月以降、読んだ本はこちら

アジャイルサムライ−達人開発者への道−

Clean Code アジャイルソフトウェア達人の技

UMLモデリング入門

Clean Coder プロフェッショナルプログラマへの道

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

OMG認定技術者教科書 OCUPファンダメンタル

オブジェクトデザイン (Object Oriented SELECTION)

C#クックブック 第3版

プログラマのためのSQL 第2版

が…どれもこれも業務と関係ない！！！

10〜12月、やっぱり延々と続くEXCEL業務。アジャイル勉強会にも参加するように。

勉強会に参加してみると、自分で勉強を進めている人達がたくさんいてびっくりしました。
ワークショップ形式だと自分の不甲斐なさをさらに感じることに。
「勉強会って自分が糞虫野郎ということを理解するために行くんだZE」とよく言われるのを体感しました。
もっと成長したいし、深く知識を付けたい。

12月、やってきたことに実感を覚える。

他の人がC#で作ったアプリの保守等も担当もしましたが
なによりも今の自分が書くソースコードに比べて圧倒的に汚い。
…ちゃんと設計したの？って
でもこれを書いた人、自分が開発部転属直後にプログラミングの研修担当してくれた人だったわけで。
たった3ヶ月で勉強したことが力になるって、業務経験上から身につくものって一体何だったんでしょうね…

思えば9月〜12月、怒涛のように過ぎていった感じがします。

来年は

ようやくアプリを作れるところまでにたどり着いた気がします。
来年はここまで行けたらいいなあと思ってます。

• ネットワークの知識を身に付ける（CCNA程度には）
• TDDについての知識を身につける
• AndroidやiOSのアプリを作る
• 公開できるWebアプリを作成する

そして…なんとしても転職したい。
確かに現状の環境を巻き込むことも大事かと思いますが
何よりも1つの組織、会社の意識を帰るのは非常にエネルギーがいることです。
政治的な運営でガッチガチに固められた今の職場に長くとどまるには
それだけでパワーを使いきってる部分はあるので…。
もっと外に出ていろんな人と話してみたいですね！

というわけで皆様よいお年を！

UMLについて学習中です。

UMLにで設計書が書けるように
現在必死で勉強中です。


で、この本が今はすごく自分に合ってます。

UMLモデリング入門

図や実践等の解説はないけど（実践は別書籍）
言葉が１つ１つ丁寧に書かれています。
まさに「The教科書」


会社からはクラス図を書くためにこちらの本を紹介されました。

やさしいオブジェクト指向 やさしいシリーズ

が…あとで確認したところ、インターフェイスの定義が間違っている。
Javaとしてのインターフェイスの定義は正しいのだけど
UMLとのインターフェイスの定義とごっちゃになってない？
両方をあわせて解説しているからなのだろうけど。


ソフト設計についてはきっちりできるようになりたいです。1年くらいかけて。
ま、なんで設計スキルに対して傾倒し始めたのかのお話はまた今度ということで。


もうちょっとできるようになったらこっちを読む

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

設計のお話（忘れないうちにメモっとく。

とある人からの伝授。すごく重要なので復習のために。
（眠れないから暇つぶしだろ？とか言わない！

・PJで現物を作る時にはパワポ２，３枚でいいから設計概要とクラス概要を書く。
　打ち合わせを重ねるごとに水増して持っていけばいい。
　進捗報告を書き加えるだけでもGood

・フォーマットが間違っていてもシンプルに要件を説明できるようにしろ。


・設計書は読者を想定して選んで作る。


・一般的に作成する設計書は以下の通り。
概要設計書
詳細設計書
インタフェイス設計書
配置設計書
APIマニュアル
ユースケース設計書
テスト設計書
プロジェクト設計書

・ユースケース設計書があれば作業の優劣を絞込みしやすくなる。


・プロジェクト設計書にコードの実施基準を書いておくと意味のわからないコードの混入を防ぐことができる。


・設計書を書かずにコーディングする場合、管理しなくても作れる作れる程度のことしかやってない。
管理をしない場合、自分の実力以上のものを作ることは不可能である。
この場合、メンテナンスが不可能なものが完成してしまう可能性が高いので控える。

・上記のことより、プログラムの耐用年数を考えて作れ。
ソフトは固定された部品ではないことを肝に銘じろ。

・リリースはゴールではない。
時間と共に変化するソースコードのスナップショットがリリースである。
ゴールとは方向であって、座標でない。





結論
沢山うんこ（ーど）作れ。失敗しろ。うんこは肥やしになる。

Pythonで使うBox２Dモジュールをインストールしてみた。

かなり手間取ったので自分用にもメモ

PyBox2Dインストール
対象となるインストール環境
Windows7

利用するツール
MinGW
TortoiseSVN
SWIG


必要モジュール
Pygame


インストール方法
基本は公式ページに添ってインストールを行うが、記載されていない落とし穴があったのでメモ。

ビルド時の注意点
・MinGWのインストールの注意点
インストール画面にて、g++にチェックを入れてインストールを行う。（C++ラッパを利用するため、こいつが必要）
・SWIGのインストールの注意点
基本ダウンロード形式なので保存先はどこでもいいが、日本語の含まれないパスが望ましい
環境変数PATHにswig.exeの存在するパスを追加する。
・Pygameのインストールの注意点
Pygameのモジュール自体、32bit形式のOSでないとインストールができない
つまり32bit形式のOSでないとpybox2dのインストールは不可。

インストールの注意点
特に詰まったところはなかったので省略。

ビルド環境を整えるための条件が非常に厄介だった気がする。
大事なのは
１―公式Webから情報を得ること
２―ビルド時にエラーが発生した場合、エラーメッセージから問題を推察すること。
という２点を守れば導入できます。

さてさて、とりあえず使って遊んでみましょうかね・・・