奇特なブログ

「殊勝に値する行いや心掛け」を意味する、奇特な人になる為のブログです

2016年8月27日のダイジェスト

最近、すっかり恒例になってますが(笑)


1. バンブロ! ソフトウェア品質特集

準委任で成果完成型を選んだ時の請負との差異(全く同じって事もないと思うんで)と、
瑕疵期間が長くなったけど金額が上がらない時に、
個別契約の方で瑕疵期間を短くする交渉が必要に感じましたね。


2. テキストベースでER図を書く - Qiita

これは神ツールな予感!
いや、最近ER図大事だなぁと、ちょっと思う所があったので、暇になったら検証してみましょう。


3. プログラマーが転職で年収上げたいならwebを出ろ、手を動かすな。これが給料を上げる方法だ | らふらく^^ ~ブログで飯を食う~

web系の人は、ずっとプログラマーでいく意識が強い。生き残るために新しい言語を求めてしまうけど、そうじゃなく、仕様書を書いたり、情報処理の勉強をしたりして基礎的なことを学ぶ方が賢いよ。

ここの前者と後者って、別に対立概念じゃないだろうと思うんですけどね。


4. リオ五輪でプロポーズが大流行 「ロマンチック」か「女性蔑視」か(小林恭子) - 個人 - Yahoo!ニュース

別に、女性側は普通に断ればよろしいと思いますがね。
で、断った事について云々言うなら、
オリンピックにおいて「おまけ」的なものが「主題」にすり替わっているんじゃないの?と。


5. (0ページ目)政府の労働政策の切り札”プレミアムフライデー”の謎|やまもといちろうコラム - デイリーニュースオンライン

給料上がってないのに休み増えたって、個人消費は増えないと思うんですけどね。


6. S-Port|鈴与シンワート株式会社

この記事自体には特に異論はないんですけど、
ここに書いてある事を実現するのに必要なのは、「クラウド」じゃなくて「仮想化」だと思うんですがね。
だって、KVMでもここにある様なサーバ台数増減は出来ますし。
どうも「クラウド」という言葉の定義自体が、最近はよく分からないですね(苦笑)


7. 女性が活躍しないとヤバイほんとうの理由は「労働人口の減少」ではない。 | Girl Power Insight

「いくら優秀でも、女性はすぐに会社を辞めちゃうから」

だから育てても無駄という理屈だ。

ここなんですけど、確かに短期的にはマイナスだと思うんですよね。
ただ、会社を辞めずに子供を産んで育てられるかというと、
子育てってそんなに簡単だと思っていないんですがね。


8. 5時間労働を導入したら、会社が大きく成長し社員が幸せになった理由 | ライフハッカー[日本版]

どうかなと思う所もないではないですけど、
「試しに」やる分には、そうリスクはないでしょうしね。


9. がる on Twitter: "「正社員と同等の金額を稼ぐ」では、何一つとして「正社員と同等」ではない、んだけどなぁ…… https://t.co/Oqpp8TLH0t"

債権の優先順位然り、ボーナスが無い然り、正社員と同条件ではないわけですからね。


10. 消費者は自立できるか~パソコンの高額解除料請求事案を巡って~ - 一般社団法人消費者のみらいを考える会

あぁ、これは「景気が良くなって多くの消費者がサーフィンが出来る余裕を持つ事が出来る様になって、
そしてサーフィンによって騙されなくなって"から"」言ってくださいね。


11. Content Security PolicyでXSSを断ち切る - monoの開発ブログ

確かに、効果は高いと思うんですけど。

ただ、外部のスクリプトをぽんぽん貼っていた今までが安易すぎたとも考えられるのではないでしょうか。ホワイトリストドメインを追加していく中で、本当にそのスクリプトが必要なのか、あるいは信頼できるのか考え直してみるのもいいかもしれません

ここがボトルネックだろうと。


12.SQLアンチパターン

これ、ちょっと「予想以上」に良い本ですね。


13.フルスタックエンジニア

前回も書きましたが、ただ、この問題の根っ子は「フルスタックが出来たとしても、それに合う収入が得られない」の方だと思いましたね。


14.HTML5 & CSS3

一部、CSS3とは関係ない話もありそうですが。
「background-size」「display: table-cell」「メディアクエリ」、知らなかったですね。


15.道具に振り回される

その道具を使わなければ容易に実現可能なのに、
その道具を使った事による副作用から実現不可(あるいは困難)になった・・・どう考えても、道具に振り回されているとしか(苦笑)


16.サーフィンの目的

一時期、話が多過ぎてまとまらないなぁと思ったので、小出しにする事にしました。
まずはコチラ。

(1)サーフィンを行う事によって、誰が嘘を付いているかどうか見抜く

例えば、これは一部では有名でしょうけど、

正規表現:メールアドレスかどうか調べる - phpspot

404 Blog Not Found:「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ

上記の二つのどちらが「本当(この場合、適切かどうかなんでしょうけど)かどうか」と。
いや、真面目な話、「この時点では」分からないと思いますよ。
だから、サーフィンをする必要があると思うんですよね。
勿論、このネタに限らず。あと、ネットに限らず。


17.戦闘予測プログラム

以下の様なのが、結構ハマりましたね(苦笑)

「勇者の剣(2回攻撃)で追撃が出て、通常攻撃2回と必殺2回が出れば倒せる時の勝率を求めよ」

数学の「余事象」を勉強して、何とかかんとかでしたね。


18.ホモ or 腐女子向けエロ小説?

「中学生の時に、スポーツをしていた男子がいて、その男子の短パンからブリーフがはみ出ているのを見るのが楽しい」とかは、これに該当するんでしょうかね(笑)
あと、この辺検証するなら・・・短パンとブリーフ買うしかないか(笑)


19.続・神曲の定義

神曲、良曲の定義ってなんなんだ

定義なんてない
音「学」ではなく音「楽」なんだよ

分からんでもないが、これだと話が終わってしまうので。

マジレスすると、繰り返し聞くかどうか

あぁ、なるほど・・・確かにこれっぽい気が。
ということで、改めて定義を。

神曲:名曲の飽きる条件に当てはまらない曲
名曲:200回繰り返し聞く前に飽きた曲
良曲:30(50?)回繰り返し聞く前に飽きた曲
普通:10回繰り返し聞く前に飽きた曲

正確には、回数ではなく「中央値に対する乖離」の割合で求める必要があるんでしょうけど。
ということで、現在整理中の神曲・名曲「候補」リストを。
最終的には、CD買って神曲・名曲プレイリストを作る予定です。

1.B'zのDon't Leave Me
2.B'zのWonderful Opportunity
3.B'zのF・E・A・R
4.B'zのLiar Liar
5.B'zのもう一度キスしたかった
6.B'zのGOLD
7.B'zの裸足の女神
8.THE YELLOW MONKEYのBRILLIANT WORLD
9.THE YELLOW MONKEYのSO YOUNG
10.DREAMS COME TRUEの雨の終わる場所
11.奥井亜紀の月の繭
12.高橋洋子残酷な天使のテーゼ
13.水戸黄門ああ人生に涙あり
14.ABBAのDancing Queen
15.Jungle Smileの同じ星
16.小柳ゆきのあなたのキスを数えましょう
17.TM NETWORKGet Wild
18.円広志夢想花
19.ABBAのDancing Queen
20.FF6の決戦
21.FF6妖星乱舞(第四楽章)
22.FF7の星の声が聞こえる
23.FF13の閃光
24.DDFFのCantata Mortis & God in Fire
25.DQ3勇者の挑戦
26.DQ3アレフガルドにて
27.DQ4の戦闘~生か死か~
28.ファイアーエムブレム外伝の最終Map Player側BGM
29.ファイアーエムブレム聖戦の系譜の運命の扉
30.女神異聞録ペルソナの夜の女王
31.T-SQUAREのTRUTH
32.パチスロ大花火の七のファンファーレ
33.パチスロ大花火の七のBIGボーナス
34.パチスロゲッターマウスのJACゲーム
35.パチンコCR戦国乙女のプレゼント
36.推定少女の間違い
37.HⅡHのfeels like HEAVEN
38.Juno ReactorのGuardian Angel
39.FireHouseのWhen I Look Into Your Eyes
40.Backstreet BoysのI Want It That Way
41.Bryan Adamsの(Everything I Do) I Do It For You
42.Whitney HoustonのI Will Always Love You
43.MAN WITH A MISSION & ZebraheadのOut of Control
44.MAN WITH A MISSIONのdistance
45.蝶野正洋のCRASH
46.グレート・ムタの愚零闘武多協奏曲
47.中央競馬宝塚記念のファンファーレ
48.魔法少女まどか☆マギカのCredens Justitiam
49.イスラエル民謡のマイムマイム
50.ロシア民謡のコロブチカ
51.ロシア民謡のカチューシャ
52.日本の蛍の光
53.必殺仕事人の殺しのテーマ
54.太陽にほえろのメインテーマ
55.イヴ・モンタンの枯葉
56.ジョシュ・グローバンのYou Raise Me Up
57.Little EvaのThe Locomotion

久々に、B'zの稲葉さんのシャウトを歌いたい所ですね。
「Don't Leave Me BabyBabyBabyBabyBabyBabyBabyBabyBabyBabyBaby Yah Yah Yah Yah DaDaDaDaDaDaDaDaDaDaDaDaDaDaDa Yah」と(笑)

2016年8月11日のダイジェスト

今回は、技術系が多めですね。


1. プログラマーに見積もり頼んだらボッタクリされそうになった話 : IT速報

こういうのを受ける(受けないのが最も良いが)場合は、以下辺りがポイントかと。
まだまだありそうですが。

・お金は有り余っているのだが、実績が無いので実績目当てで受ける。なので、赤字の影響は「全く(人材が流出しないとかも含みます)」無い時。
・今回「だけ」は安いが、2回目「以降」は「適正価格」になる時。
・追加での要求があった際に、追加分の「増額と納期延長(片方ではNG)」が出来る時。

なんですが、実際には上記が成立した試しがないので、「受けない方が良い」となるわけですが。


2.ゼネラリスト

う~む、そうだったか。

d.hatena.ne.jp

上記の、ダメな方のゼネラリストっぽいですし、

「全部プログラムでやる」のか「得意分野はお任せする」のか - がるの健忘録

どうも、この話が分からない模様。
で、この話は、
「比較優位」の考え方では、すべての面で能力に劣る人でも仕事に貢献できる(1/3ページ):nikkei BPnet 〈日経BPネット〉
が前提になっていると思いますので。

フルスタック」と聞いて、ネットサーフィンしている皆さんは「ヤバイ」と思いますよね?
それだと思います。


3. before_filter的なほにゃらら、の想定 - がるの健忘録

う~む、なるほど!
普通に弾いちゃってますが、今後は検討してみましょう。


4. 括弧は欲しいものである… - がるの健忘録

なんだって!!!!
&& と andが違うのは知ってましたが・・・


5. どこに「最適解」を見いだすのか? - がるの健忘録

もちろん見方として「そーゆーのがいるからお仕事がある」ってのもあるんだけど。
「適材適所」が抜けてます。

時々「エンジニアにもっと自由を!!」とかいう発言を耳に目にするんだけど、正直「自分の個性出したいんなら、仕事じゃなくて自分プロダクトでやってください」としか思わんのですな。
個人的に「業務用ペルソナ(仕事の時の顔の様なもの)」というのがあり、
現場では、

ヨーダ記法は使わない(もし、現場のソースの多くがヨーダなら別)
vimはあまり使わない(vimの方が速く書ける様になったら変わりますが)
・論理削除を使う(現場と相談する場合もありますが)
・getter・setterは使わない(現場と相談する場合もありますが)

となっており、「使い分けている」んですけどね。


6.中立の弱点


中立ぐらいの落とし所にするのが良い結果になるなら、それで良いんですけどね。


7. https://twitter.com/gallu/status/757102607764631552

DBの「制約」なんかは、もうちょっと有効活用出来ないものかとは思いますね。
殆ど見たことがないので。


8. 住宅:「原状回復をめぐるトラブルとガイドライン」について - 国土交通省

これは使えますね。


9. https://twitter.com/gallu/status/760630436401848320

小さいでしょうけど、少しはあるんだろうと。


10. https://twitter.com/gallu/status/760649720654012416

「ネットで炎上しても、大勢には影響ないしねぇ」
ので、結局多くの人には伝わらないので効果なし。
あと、茹で蛙茹でガエル - Wikipedia の事でしょうけど、
その炎上内容に実害があるかどうかにもよるのでは。


11. Docker、OCI やめるってよ : 革命の日々 その2

よく分かりませんが、Dockerが10年(5年でもよいけど)後に残っているかどうかの方が重要でしょうかね。


12. 定期的なパスワード変更の効果有無まとめ - pochi-pの絵日記

サイト側がユーザーに定期的変更を強制すると、ユーザーは結果的に強度の弱いパスワードを使いがちなので強制は良くない。
ここは、ユーザーではなくサイト管理者とかが「マスターパスワード」的なものを決めてユーザーに通知しても、
「もう少し簡単なパスワードにして下さい」という要望が出る?のでダメかな。


13. CentOSのPHPは本当に安全か - Qiita

脆弱性といっても、クリティカルなのとそうでないのがあるから、
比較的早く対応出来るソースの方を選んでますね、今の所プライベートはって、あぁココも業務用ペルソナか。


14. https://www.amazon.co.jp/dp/479804573X

あぁ、Redisにロールバックが無いとか良い事書いてますね。
「適切に」使えば、こいつらも使えるわけですし。


15. 高校野球の女子マネージャーをグラウンドに立たせないのは、「安全性」ではなく「理想の萌えと違うから」だと思う件。 : スポーツ見るもの語る者〜フモフモコラム

「区別」と「差別」って「都合」で決まるんだと思うんですけどね。
「風呂やトイレも"分けずに"男女一緒に」ってのは、女性にとって都合が悪いから区別しますし(別に区別してくれて構わない。むしろ、その方が(笑))、
女性専用車両も同じだと思いますし。
逆に、「お茶くみは女性が」は、僕も反対なんですが、ビジネスにとって都合が悪いので、区別しない方が良いと。
と、考えると、この事例は「女性にとって都合が悪い点があるか?ある場合には、その実害は実益を上回るか?」と。


16. プロ管理者の不足

リンクは貼りませんが、なるほど・・・
「コミュニケーション(交渉とかも含む)のプロ」って、技術者以上に聞かないですしね。
「代替え出来ない程、コミュニケーションが上手い人」が、いてもおかしくないわけですし。


17.既に大手が手を出している分野に中小企業が勝てるか?

「相当に分が悪い」ということで。


18.要求を技術者のスキルに合わせて変えてはいけない

まず、技術的に可能なのが前提として。
これは、ちょっと難しいと思いますけど、
技術者が(スキル的に)実装出来ないから、要求を緩和だったり変えるのは、う~んとやっぱり思いますね。
妥当なアプローチとしては、
「その要求を実現しようとすると、弊社的には(技術スキル的に)納期を延期せざるを得ないが、それでも良いか?」か、
「その要求を緩和してでも、納期に間に合わせたいか?」のどちらかでしょうかね。
で、仮に前者(後者の場合、話が変わる)だったとして、それで技術者や開発会社を変更になっても、それは仕方が無いと思いますよ。
こちら 2015年の振り返りと2016年の展望 - 奇特なブログ の3番のクビの話と同じだと思いますけど。
というより、そうしないと「要求を実装出来るスキルの高い人が光りません」し、
「スキルの高い人が光っていないのに、後続の人は頑張れるんでしょうか」ね。


19.神曲の定義

定義付け自体が難しいんですが。

神曲:曲全体の75%以上が、涙腺崩壊だったり思わずノッてしまったり鳥肌がたったりする曲
名曲:曲全体の50%以上が、涙腺崩壊だったり思わずノッてしまったり鳥肌がたったりする曲
良曲:曲全体の25%以上が、涙腺崩壊だったり思わずノッてしまったり鳥肌がたったりする曲
普通:曲全体の25%未満が、涙腺崩壊だったり思わずノッてしまったり鳥肌がたったりする曲

で、上記を前提とした時の、現状での神曲リスト(笑)

1.初代ファンタシースターの、Planet Palma(原曲)
2.椎名林檎の、茎(STEM)~大名遊ビ編~(歌詞が英語)
3.森口博子の、ETERNAL WIND ~ほほえみは光る風の中~
4.FF4の、サンバ・デ・チョコボ
5.FF7の、フィドル・デ・チョコボ

神曲が増えるのは、聞いてる曲が多くなれば仕方ないですね(笑)
あと、「チョコボGO」は出ないのだろうか(笑)


20.PhalconのORマッパー

1.直接SQLを書く
2.findとかでSQLを書く
3.クエリビルダでSQLを書く

と3つあって、3番は不明なんですが、
2の時に流れるSQL(General Logで確認)が、
こちら Webアプリにおけるプログラムのパフォーマンスチューニング - 奇特なブログ の、
パターン2の様なんですよね。
まぁ、「逆に言えば、チューニング余地があるということ」でもあるわけですけど(笑)


21.GMP関数

PHP: GMP 関数 - Manual
これ、どうも「gmp_add(0.1, 1)」みたく「小数の値を入れるとエラーになる」んですよね。
そういうものなら、別に良いんですけど。


22.プライベートタスクがまた増えた

「登場人物の"設定"を大量に盛り込んだエロ小説を書きたい」などなどなどなどなどなどなどなど(笑)
ふむ・・・


23.「特に」気になった記事

ちょくちょくと記事を取り上げてますが、
こちらのブログ 一人ぼっちの漫画工場 の記事の大半(全部ではない)を読みましたので、
幾つか(かなり絞ったんですがね)貼っておくことにします。
仮に一つだけ選ぶなら、「上から二番目」ですかね。

一人ぼっちの漫画工場 根っこを正さなきゃならんと思うんです。

一人ぼっちの漫画工場 根っこを正さなきゃならんと思うんです2

一人ぼっちの漫画工場 「私」しかない。そして思慮が浅い。

一人ぼっちの漫画工場 哲学の重要性(「ザ・ゴール」・「ザ・チョイス」感想)

一人ぼっちの漫画工場 経済はとても簡単です

一人ぼっちの漫画工場 試してみよう経済ごっこ

一人ぼっちの漫画工場 外交は楽観的に、安全保障は悲観的に

一人ぼっちの漫画工場 新自由主義ってそういうことだったのか

一人ぼっちの漫画工場 経済はテーブルの上にあるんじゃなくて人の生活の中にある

一人ぼっちの漫画工場 ちょっとした国家規模の金額の判断方法

一人ぼっちの漫画工場 相対化の悪用

一人ぼっちの漫画工場 言葉の定義

一人ぼっちの漫画工場 マクロ視点

一人ぼっちの漫画工場 倫理とは何か?

一人ぼっちの漫画工場 討論必勝法

長かった・・・

2016年7月16日のダイジェスト

長いので、こちらにまとめて書くことにしました。
短いなら、TwitterとFBで良いんですけどね。


1.プログラマが知っておくべき、メモリ/ディスク/ネットワークの速度まとめ
qiita.com
おお~アプリ「全体」でチューニングをする事の大切さが伺える記事ですね。
・・・ネットワークの速度が気になる所。10Base-Tとか100Base-Txとかのアレ。
あと、モバイルはやっぱり、クライアントとサーバーの間が遅いようで。


2.プログラミング言語の水準について
http://qiita.com/kantomi/items/747aef968d37b5ebeced
「技術者なのに自分の考えを持たず、惰性で使っている」っていうのがポイントなんでしょうと。
対象技術に対して深く考察し、メリットだけではなくデメリットも認識して、
それで、それを使い続けるなら、「道具に振り回される事もなくなる」と思いますから。


3. 日本デジタルゲーム学会2016年夏季研究発表大会|DiGRA JAPAN 2016 Summer Conference
あぁ、今回は頑張って行きたい所。


4.選挙権がメルカリで出品出来た?
・・・典型的な「それをお金で買いますか(本の名前)」的な事案っぽい。


5. Expired
韓国以前に、最初に見た時に「これはヤバイ」って事で、完全にガン無視状態ですね。LINEは。
もう、記憶も曖昧だし、今はどうなってるか知らないですけど、
最初は、自分がアドレス帳に登録している友達の住所も、他の友達に公開されるとかだった様な?


6. http://www.jp.square-enix.com/info/images/image_technical_seminar2014_06/pdf/SQEX_DevCon_sugimoto.pdf
リソース管理の所・・・あぁ、まだまだ詰められますね自分のプログラム。
ただ、やり過ぎると使いにくくはなるとは思うので、一定以上の熟練が要求される話には思いましたけど。


7. PHPのround関数とは一体なんだったのか - hnwの日記
あぁ、期待値計算する所でround関数使ってるなあ。
ここは・・・GMP


8. https://www.amazon.co.jp/dp/B017W1U2CU?tag=bookquote-22
Kindleのみか・・・いい加減に導入しようかとも思う時はあるんですけどね。


9.



シミュレーションゲーム 戦闘予測」で、普通にありましたよ(笑)
こちら http://www.vector.co.jp/soft/winnt/game/se483057.html が。
むしろあった方が、イメージしやすいし良いのでは。
実際、ゲームが違うから全然違うけど、よく似てますし。
あと、「性欲 コントロール」も勿論沢山ヒットしますけど、
オナ禁・・・あぁそっちか、確かに年間500回以上抜くのも、それはそれでどうよと(笑)
・・・3日間、我慢してみましょう。過去にやったことあるから想像は付きますけど(笑)


10. http://headlines.yahoo.co.jp/hl?a=20160623-00004810-bengocom-soci
女優に飯食わせてもらっているんじゃないのかの一言で終わりかなと。


11.オフショアで気になった点
元債権取り立て屋からすると、捕まえるのが難しそうだなぁと。
都合悪くなったので母国に帰ったその後不明、リモートワークなので連絡付かなくなってどこにいったか分からなくなった、
とりあえず二つ思い付きましたね。


12.わかりやすさの技術 - やしお
おお、これは・・・じっくり読む事に。


13. http://alfalfalfa.com/articles/134817.html
デフレはあるんでしょうけど・・・1円なら分かるんですけどね。
まだ、「お金が動く」から。
この辺で一番気になるのは、デフレ脱却政策をしているにも関わらずお金を動かさなかった時ですね。


14.


セキュリティと同じでイタチごっこですから(笑)
実際、パンチラ対策(だと思うが)でのペチパンも「ペチパンツ エロ」でググったら分かる通りの状況になってる様ですし(一部では)(笑)
あとは、個人的には「パズル技」ってのもありますね。


15.


何の技術を使っているかは、クライアントには「関係無い」話なんですけどね。
あと、使っている技術を面談時などに聞くことは勿論あるけど、それは重要度としてそう高くはないですね。
趣味ならともかく、ビジネスなら「上手くいく(継続的なら尚良い)」って事の方が重要かと。
極論、PHP4でも場合によってはアリだと思いますし。


16.


あぁ、そういえば・・・僕の場合はそもそも見れなくなったので、魚拓を取ろうにも取れない状況ですが(苦笑)
有料ユーザーだし、魚拓ももう少し有効活用しませんとね。


17.言葉を使う意味
・・・あぁ、なるほど。
椎名林檎の本能って曲の歌詞を思い出しましたね(笑)


18.消極的支持は暴走も許す?
2/3って結構暴走出来ると思うので、消極的支持なら避けた方が良いんじゃないかって思って避けたんですが。
事前に1/2はほぼ確実に取る事は分かっていましたし。


19.性犯罪の抑止力
http://barpeachpit.blog86.fc2.com/blog-entry-409.html
そういえば、これもありましたね。
あと、こっちはデータですが http://skymouse.hatenablog.com/entry/20140430/1398800010
あるいは、もっと日常的な話として、
「性犯罪をやって”一時的”に性欲が満たされるメリットと、捕まって仕事や家族などの"今の生活"失ったりするデメリットとを天秤にかけたら"割に合わない"よな」
とか。
あるいは、「女性が好きなんでしょ?で、"好きな相手が不幸になるのが良い"ってどういう趣味?幸せになってほしいんじゃないの?」とか。
あるいは・・・今回はここまでで。


20.生産性アップや効率化のデメリット
供給が需要を上回っている時に、生産性アップや効率化をすると、
供給量が更に増え、そして増えた供給量をさばく為に、価格を安くせざるを得なくなる。
そして、価格が安くなるということは、入ってくる収入も減るので、
入ってくる収入を回復させようと、更に生産性アップや効率化を図る・・・以下、無限ループ。
で、今の「供給と需要の割合はどうなっているか」。
「働いたら負け」とか「だらだら仕事した方が良い」だと、
逆に供給が足りない時に困るので、生産性アップや効率化自体が出来た方が良いのは確か。
ただ、状況によっては、「自分で自分の首を絞める行為」だと思いますね。


21.書いてることに意味がある
・・・ちょっとこれは想定外な良い発見でしたけど。
あまり、詳しくは書けないですけどね。残念ながら。
ということで、ペースはさておき今後も書いていく事にはしましょう。

第三回雑談の会開催(4/18~4/24)

そういえば、しばらくやってないなって事で。
先月、以下の記事も見かけましたしね。

wadap.hatenablog.com

あと、今回は用事とか考えて、期間を1週間にしました。
といっても、仮に応募が殺到(間違いなくしないと思うが)したら、
キャンセルさせていただく形にはなると思いますけど。

内容は、以下の第一回と基本変わりません。

kitoku-magic.hatenablog.com

また、連絡は、
Twitter(DMも全体公開中)・Facebook・HP内のコチラ
http://www.kitoku-magic.net/inquiry.html 等からいただければと思います。

システム開発における自動化の一例(あくまで一例)

こちらでは、すっかりご無沙汰しております。
まず、前回 2015年の振り返りと2016年の展望 - 奇特なブログ の年末年始に予告した記事は、
別に忘れてはいないんですけど、
内容があまりにも壮大になってしまいそうなのと、
どう書くかで悩んでいる(&調査中)ので、
時期未定に変更します。すいません。
対象になっている本を読んだ方が早いと思いますね、正直。


さて、本題なんですが、
最近「自動化」について考える事があったので、
これまでに見聞きした自動化手法なんぞをメモしておこうかと思いまして。
なので、「一例」なんですけど、
とりあえず以下の様な感じです。
あと、実装が簡単と思われる順番に書いてます。


1.この時間からこの時間まではイベント(別にソシャゲに限らず)を開催中にして、
時間外だったら、非開催中に自動で切り替わるようにして欲しい

以下が、方法(の一例)です。


方法:
DB(CSVとかでも良いけど)に、
イベント情報のテーブルを作り、その中に開始日時と終了日時を持たせる。
そして、イベントページ(仕様によってはTOPページとかも)にアクセスしたら、
アクセスした「サーバー(クライアントはダメ)」の現在日時が、
イベント開始日時と終了日時の範囲に入っているかチェックする。
入っていたら開催中、逆なら非開催中。


まぁ、これは簡単かなぁと。


2.指定時刻になったら、指定したファイルを自動で本番に反映してほしい

ここ(に限らない気もするが)は、やり方が以下の様に複数考えられますね。
あと、ここの(1)~(3)は、この後も出てくるので注意です。

(1)crontabに指定時刻を登録しておく場合
(2)DB(何度も言うが、別にDBじゃなくても可)のテーブルに指定時刻を登録しておく場合
(3)crontabに定期巡回をさせる場合

で、この場合は(1)が一番自然で簡単かなぁと思われます。
次が(2)で、(3)は出来るというよりやっちゃダメ(高確率で事故りそう)と思われます。
で、(1)だと以下の様な感じで。


方法:
crontabにファイルの反映(デプロイ)を開始したい時刻と、
デプロイするシェルスクリプト(ある現場、多いでしょ)を登録しておく。
デプロイするシェルスクリプトは、反映したいファイルパスが書かれているファイル名リストを参照し、
そのファイルのみを、本番に反映させる。
本番反映が終了したら、crontabの該当行はコメントアウト(しなくても良い気もするが)しておく。


ここは、「ファイル名リスト」って所が若干手間かなぁ・・・
コミットしたら、フックスクリプトで、そのファイル名リストを書き換えれば良いか(笑)
指定時刻も書き換え?出来るとは思いますけど、「こういう系って、あんまりやると事故ります」よ。
なので、この辺までかなぁと。


3.指定時刻になったら、自動でテストツールを実行して欲しい

ここは、例えば毎日何時って決まってるんだったら、
上記の(1)が一番かなぁと。
crontabの編集NGなら、(2)もありでしょうけど。
(3)は「頻度による」としか。


方法:
crontabにテストツールの実行を開始したい時刻と、
テストツールの実行コマンドを登録しておく。


で、ここから( or ここで)、カバレッジを取るだの何だのは、現場の方針次第ということで。
あと、上記2と合わせると、Jenkins不要説(まともに使った事無いので、これだけじゃないのかもしれないけど)も(笑)
いや、だって僕の口癖は「面倒だなぁ」ですから、
「覚えなくて良いなら、覚えたくない」んですよね(苦笑)


4.指定時刻になったら、DBのテーブル内の参照するレコードを変えてほしい

これは、ちょっとマニアック(別に、そう難しくはないと思われますが)かも。
あと、トランザクションデータだと、この辺はどうかなと思いますので、
マスタと履歴データ(さすがに怖いが、こっちは消す方でも使えるかも)が対象かなと思いますね。
あと、上記の(1)だと管理大変そうなので、
(2)か(3)かなぁと。


方法:
DB(何度もry)に、スケジュールを管理するテーブルを作り、
指定時刻になったら、
「このテーブル(テーブルAとする)の、この辺を参照する様にする」というレコードを「開始日時と終了日時」も合わせて登録する。
テーブルA側には、上記テーブルの「この辺を」と一致する列を作り、
列が一致しているレコードのみを参照する様にする。
そして、テーブルAからデータを取得する時には、
事前にサーバーの現在時刻に一致するレコードを、スケジュール管理テーブルから取得(この時、絶対にキャッシュから取ってはいけない)し、
「どの辺を参照するか」を決めてから、テーブルAのデータを取得する。


これ、「どの辺を参照するかを変えるじゃなくて、書き換えたら?」って意見もありそうで、
まぁ、確かにそっちでも全然良いと思いますね(書き換え後のキャッシュ消し忘れに注意)。
なので、ココは議論かなぁと。


5.指定時刻になったら、目覚まし時計代わりに、自分のPC内のアダルトDVDの再生が始まる(笑)自動化版Iot?(笑)

wwwwwwwwwwwwwww
で、ココは、実装は全く思い浮かばないですけど、趣味目的で作ってみるのもアリかも(笑)


ということで以上です。
あとは「番外編」として、
自動化とは全然関係無い、以下の様なモノを考えてみました。
・・・多分、以下の本の「キチガイ(では無いという人も、結構いそうなのが怖いですが)要求」辺りから、連想したと思われます。


www.amazon.co.jp


番外編:ファイルのバージョン管理を、バージョン管理ツールを使わないで行いたい

まず、以下の様なテーブル(書式などは若干適当)を作る。


CREATE TABLE file_version_history (
revision INT NOT NULL COMMENT 'リビジョン番号',
no INT NOT NULL COMMENT '識別番号',
file_name TEXT NOT NULL COMMENT '更新されたファイルのパス情報',
change_type INT NOT NULL COMMENT '追加や削除などの更新種別',
file_bosy TEXT NOT NULL COMMENT 'ファイルの中身の内容',
insert_date DATETIME NOT NULL COMMENT '追加日時',
PRIMARY KEY (revision, no)
) COMMENT 'ファイルのバージョン管理テーブル';


次に、クライアントツールやWebでの管理ツールを作り、
そこに、「コミットする」という項目(Webならボタンとか)を作る。
コミットする機能を使用すると、
上記テーブルにレコードが登録される。
差分を取りたい場合は、
上記テーブルの情報と現在の情報を比較する。
リバートしたい場合は、
上記テーブルの対象リビジョンのレコードをDELETEし、
DELETEしたレコードは、同じ様な構造のバックアップテーブルに入れる。
リバートした内容を更にリバートしたい場合は、
バックアップテーブルから、レコードを取ってきて入れ直す。
フックスクリプト?→あくまで番外編なので、一旦ここまで。

こんな感じですかね。

例によって、ご感想などをお待ちしております。