スベリミナル効果

技術的なことを書こうと思ってたけど何でも書くことにします


通常用

ふざけ用
何でもコメントください。誤り指摘コメントなどには「コメン(ゴメン)」ト誤ります(1スベリ)
ダジャレ好きの方はこちらにどうぞ(更新してないけど)→スベリブログ2.0

July Tech Festa 2016 に行ってきました

rebuild.fmの宣伝で聴いたのをきっかけに July Tech Festaに参加してきました。

インフラエンジニアの夏の祭典ということで、自分の業務的にはYAPCなどよりもこちらの方が近く、もっと前から参加してればよかったなあと思う話ばかりでした。ブログを書くまでがJFTということなので、聞かせていただいた話について自分の感想をつらつら書かせていただきます。

 

現実が正解だ!やってみんとわからんことだらけ さくらのIoT企画 開発365日の軌跡 そして次の365日へ

はてなインターネットにて、IoT用のインフラサービス(さくらインターネット、「さくらのIoT Platform」を2016年度中に提供)を提案して実現するまでのお話。色々と気づきがありました。

  • 自分にIoTインフラの視点が無かった

IoT機器が増えるとどうなりますかねー、みたいな話は度々してたんですが、基本的にセキュリティの話ばかりでインフラを提供するという目線の話は全然していませんでした。色々足りてないなあと実感しました。

  • 新しいことを始めるのはどこでも大変

企画を考案し、イメージ化、提案・交渉(予算獲得)、開発人材が入る… に至るまで約3ヶ月を要したと。人によっては長い・短いが違うと思いますが… ということでしたが、個人的には早いんだと思います。会社規模が大きくなるほどここの所要時間が増えていくのだと思いますが… さくらで3ヶ月なら他ではどのくらいかかるんでしょうね… 自分の会社では…考えたくもない…まずそこの流れがどうなってるのかすら分からん

  • 知らないこと沢山

MarathonとかRoLaとか全然知らんかった。天草Xアスロンも知らなった(それはしょうがない)。導入事例の話は興味深かったです。

 

情シス戦線異状アリ!? 自作のパケットレコーダーで海外拠点のLANを自動監視してみた

スライド:http://www.slideshare.net/cloretsblack/lan-64323110

海外拠点を結ぶインフラでのトラブルシュートを自動監視したというお話。インフラではないけど、ネットワークの問題をトラブルシュートしてる身としては非常に共感もあり、勉強になることもあり、すごくためになりました。

  • 海外の事情

海外ならではの問題が印象的でした。国による法律的な問題とか、スイッチ売ってないとか、小数点の区切りがピリオドではないとか、様々なものがあるんだなあと驚きました。国内でもままならないのに、すぐ「海外展開だー」という話が出る昨今、このようなお話はとても貴重でした。

  • 情シスの事情(私は情シスでは無いですが)

Q.最も感謝される場面は? A.困り事を迅速に解決したとき > 障害を未然に防いだとき ←それな

未然に防いでも誰も褒めてくれない…(は言い過ぎかもしれませんが)、これ本当にそうなんですよね、何かが発生してすぐ解決できるほうがポイント高い。海外の従業員相手にはギブアンドテイクが必要という話もありましたが、そうなってくると定期的に問題発生させて自動解決する仕組みでも作った方がいいのではと思ってしまったり…(ダメ、絶対)

迅速な問題解決のために、パケットをキャプチャし続けて異常を検知する仕組みを構築、自身で販売もされているそうです(リンク参照)。確かにこういう仕組みが無いとキツイとようやく気づき始めていた今日このごろなので、見習っていきたいなと思いました。私の所のサービスでは、定常的にキャプチャし続けることは愚か、機器一個追加してもらうのも大変な現状なので、やり方を工夫する必要はあるのですが…

 

人工知能の技術で有名なニューラルネットワークのフレームワークであるChainerを用いた対話Botを使った俺の屍を越えてゆけ

スライド:http://www.slideshare.net/Gushi/chainer-bot-slide-share-64321155

機械学習系は知識さっぱりながら聞いてみました。正直、中盤以降はキツかったです…

  • 対話botについて

対話型botの価値や個性について、分かりやすく説明していただき、ふむふむなるほどと聞いていました。キャラクター性を付けるって難しそうだなあと思ってたらできてなかったw

  • 概念…?距離…?

ゴメンナサイ。

あと、エンティティキリングって強そうなポケモンのわざだなと思いました。

 

CIプロセスにセキュリティ診断を組み込もう!Eclipse CheとOWASP ZAPで実現する、セキュアなシステム開発のすすめ

  • OWASP, OWASP ZAP

名前は聞いたことあったんですが、ちゃんと知らなかった。The Open Web Application Security Projectの略ですね。内容は… 以下のスライドが分かりやすいよ、とのことでしたw

Presentations by OWASP Japan // Speaker Deck

とにかく世の中をセキュアにして、インターネットで余計なものを気にせず謳歌したいと、そういうことみたいです。ZAPはそのためのWebサイト診断ツールです。ローカル環境で使ってみたけど、やはりローカルではイマイチ有用性が分からんですね。借りてるレンタルサーバにぶつけてみたいけど… 怒られそうなので止めておきました。

元々、発表者の方が立ち上げたコミュニティとのこと。勉強会のドタキャンが多くて困っているらしいので、申し込んだら行きましょう(ここで私がいうことか?)。偶然にも話題のDoorkeeperのページだったので今後の動向が気になります(主旨が違う)。

Eclipse Next-Generation IDE!!とのことで、今後ちょっと触ってみようと思いました。本当に思ったよ。

 

サーバ構築をbashスクリプトから自動化ツールに変えてみませんか? 

スライド(公開用):http://www.slideshare.net/deadbeef00/jtf2016

発表用と公開用のノリが違い過ぎてワロタwww それはさておき。

少し状況は違うのですが、スライドと似た課題をどうにか解決すべき立場にいるため、色々考えさせられました。以下の記事は発表者様が書いたもので、スライドの詳細とも言えるものなので合わせて参照すると良いみたいです。

  • ツールを導入すべきかどうかの判断

質問もさせて頂いたのですが、ツールはツールで学習コストがかかります。一方、bashでも少し頑張れば、自動化はある程度可能だと思います。例えば、今回のスライドの「大量のサーバに同一スクリプトを適用してログも残したい」という問題であれば、以下の感じでいけると思います。

servers.txt ここに対象サーバのIPとポートが書かれているとして、

192.168.0.1:2222
10.0.0.1:22

以下のようにssh経由で実行し、スクリプト実行結果をそのまま残すことができます(鍵とか設定済み前提)。

#!/bin/bash
USER=root
SCRIPT=./set_snmpd.sh # yum -y install net-snmp とかやってるシェル
LOG=hoge.log

for server_port in $(cat servers.txt); do
	server=${server_port%%:*}
	port=${server_port##*:}
	echo "#####################################" >> $LOG
	echo "Start install script @ $server_port"   >> $LOG
	echo "#####################################" >> $LOG
	ssh -l $USER -p $port $server 'bash -x ' < $SCRIPT >> $LOG 2>&1
done

まあ、もう少し整形しようはあると思いますが… SCRIPTを変えれば、基本的に使いまわせるはずです。

個人的な話になりますが、自分でできるものは自分で作らないと気がすまないオジサンがいるため、よく分からないツールは基本的にNGを喰らってしまいます。ただ、事実ちょっと頑張れば自動化はできるわけで、使い方を調べる必要のあるツールを使う必要があるのかしら?とも思うわけです。

この辺りを質問というか相談させて頂いたのですが、まずは使ってみてどれだけ楽になるかを示す、証拠を残したり複雑な作業が必要になったときはツールの方が良い、というようなお話をいただきました。

加えて、たまたま見つけた以下のQiita投稿は非常に参考になりました。

「無理をしない」とは

  • chef,ansibleなどのdevopsのツールは、 「開発者がインフラ設定をするためのもの」と解釈されがちだ。

  • しかし、少なくとも自分の周りでは、開発者が、開発者がイキナリ、インフラ設定をすることは想定していない。インフラの知識や構成管理の知識がないためだ。これらのツールを使う人は、通常、インフラ担当者や運用担当者が想定される。

  • 開発を生業をしていない人(インフラ担当者や運用担当者)が、使うツールとして、ゴリゴリとしたコーディングではなく、設定ベースや手順ベースでできる事が重要。

  • 開発している人が忌み嫌うベタ書きを是とした記述で可読性を上げるという考え方です。
    要は「コーディングではなく、手順書の延長としてのツール」が重要です。

多分、それなりの開発者が実施し、かつそれなりに低コストで実現できるのであればツールはそこまで必要でないのかもしれませんね。ただ、一回作った後に、コーディングをしない人に回してもらうなどを考えるならば、このようなツールを検討すべきなのかな、と思いました。

 

なんかエラく話が発展してしまった…このペースだと書き終わらないのでこの辺で… 別記事としてもう少し書くかもしれません。

 

ディープラーニング入門-DQN(Deep Q-Network)の理論解説とTensorFlowを用いたシンプルな実装例

スライド:http://www.slideshare.net/enakai/tensorflowdqn

憧れの?中井さんの発表だったので。DQNが何かはほとんど知らなかったけど… 中井さんのブログにはCentOS7やらDocker絡みの話でお世話になりっぱなしだったので、本人を見たいというミーハー感がありました(なんか気持ち悪いな

  • 分かった気になった

DQNの理論をわりと初心者向けに丁寧に解説して頂いて、なんか分かった気になったぞ!という感覚を得られました。私は、学生の頃に組合せ最適化問題を解く研究をしていたので、基本的な部分(局所解に陥らないよう探索する)は同じだと思うのですが、多段になるとかその辺がまだまだ良くわかってないですね… いいきっかけを貰えたので、学習してみようと思いました。最近になって フェルマーの最終定理 (新潮文庫) を読んでいたのも、数学の話を聞く上で丁度良かったと思いました(笑

  • 学会こわい

質疑応答にて、久々に学会での厳しい質問の感じがあり、少し懐かしさを覚えました… ちょっとハラハラしましたね笑

 

懇親会

今回もぼっちで懇親会に参加しました。人見知り+技術話についていけなさそう、という恐怖で大抵そんなに話せないのですが、今回はDMM.com Laboの方に声をかけて頂いたり、その流れでカッコイイ名刺の株式会社Aimingの方とも話せたり、発表者のSonarmanaさんから色々聞けたり、最後ちょろっと中井さんともお話できて楽しかったです。こんなに話すならちゃんと名刺補充してくればよかった…(4枚しか入ってなかった…)

 

 おわりに

なんか適当に書きすぎた気がしますが… とにかくためになったし、非常に楽しかったです。お弁当や飲み物、お菓子の充実や豪華な景品などもさることながら、運営の方々が凄く親切なのが印象的でした。本当にありがとうございました。

 

しかし、こういう場に行くと完全な受け身状態になってしまって、自分から発信というか、ギブアンドテイクのギブができない人材だなあ、と痛感させられます。なんかこう、もう一段上にいくというか、能動的に発信していく姿勢を持たなければいけないなあとしみじみ思いました(って、2,3年前くらいから言ってる気がするけどね)。

 

ポケモンGOを安全に遊ぶためのひでんマシン60

※8/1 バッテリーセーバーに関して追記してまぁす。早く直してほしい…
※8/14 バッテリーセーバーに関して記載戻しました、バグ直っているようです

 

どうも、30過ぎのオッサンポケモントレーナーです。ポケモンGOが楽しくてしょうがない今日この頃です。

 

ただ、ポケモンGOに関しては色々言われており、特に、スマホを見ながらの移動による事故が危ぶまれております。実際、私もポケモンを求めてだいぶ外をウロウロしましたが、スマホをガン見している人も確かに多く、危なっかしい場面も目にしました。

このままでは「お盆を迎える前にポケモンGO規制ラッシュになってしまうのでは!?(全然ウマくない)」という不安で夜も眠れず、夜な夜な近所のジムでジムバトルを繰り返してしまいそうです。

 

そこで、微力ではありますが、いい大人がウロウロして身につけた「ポケモンGOを安全に遊ぶコツ」を書いてみようと思います。「そのくらい言われんでも分かっとるわ!」という声が聞こえてきそうな内容ではありますが… 禁断の自転車編もあります…

※「ひでんマシン」は、ただのつりざおタイトルです。60はGOに似てたから付けただけです…

 

徒歩編

基本的には徒歩で遊ぶに限りますね。乗り物に比べて幅も取らないし小回りも利きます。とはいえ、大事故の可能性は否めないので注意はもちろん必要です。

1.移動時は画面を見ない

基本の"き"ですね。そもそも歩きスマホがダメなんですから。ただ、ポケモンGOは画面を見ずとも色々と情報が得られます。

 ポケモンが出現→振動

 ポケストップ近くに来た or 近くから離れた→効果音

この2つがあれば大抵の場合は困らないと思います。また、バッテリーセーバーが有効であれば、下を向けることで画面が暗くなりバッテリーを節約できます。※8/1 バッテリーセーバーがiOS版から消えてしまいました…そしてAndroid版でもバッテリーセーブ状態から復帰すると操作不能になるバグが発生し続けています… でも、画面が消えていると思って、ウロウロするときの基本姿勢は、以下の感じが良いと思います

 ・スマホを下に向け、手を下ろして持つ(ネックストラップも有効)

 ・イヤホンで音を聴く(あまり大音量にせず、なくても良い)

手を下ろすことで、ついつい画面を見てしまうことがなくなるため、周囲への注意力が高まります。振動や効果音があれば移動を止めて画面を見る、コラッタだったら無視して歩き出す、といった感じです。是非お試しください。

2.移動を止める時も状況に合わせて

これは普段の生活でもやりがちですが、狭い道や人通りの多い道で急に止まると当然ぶつかります。じゃあ脇に避けようと急に曲がったりすると、自転車が突っ込んできたりします。あえて書くほどでは無いかもしれませんが、一応…

 ・急に立ち止まらない、後ろから人が来ていないか確認して道の端に止まる

 ・急に進行方向を変えない、これも後ろを確認する

 ・狭くて混雑した歩道では開けた場所に出てから止まる

徒歩の場合、一度出たポケモンが急に消えることは(たぶん)無いので、電柱の脇とか、駐車場の一角とか、立ち止まりやすいポイントをまず見つけてから止まるのがよいと思います(基本過ぎると思いつつ、たまにやっちゃうんだよなあ…)。

3.ARモードをOFFにする

これをやってしまうとこのゲームの醍醐味が…という声もあると思いますが… まあこれはどっちでもいいと思うのですが、ARモードを切ることでスマホをどの方向に向けてもポケモンをGETすることができます。余計な動きや方向の縛りが無くなるだけでも思考に余裕がでます。

そして、ARモード切ったほうがぶっちゃけ捕まえやすいし…

 

自転車編

ダメですよ、自転車スマホなんて。でもね、卵育てなきゃいけないじゃないですか。そしてね、ポケモンの世界の中で主人公の少年は颯爽と 100万円のじてんしゃ を乗り回すじゃないですか。あの じてんしゃ のBGMが頭にこびりついて離れないわけです。だから、乗りたいんです、でももちろん安全に。ということでちょっと実践してみました。

1.移動時は画面を見ない

徒歩と一緒やんけ!って話なのですが、制約が全然違います。まず、手でスマホが持てません。町で見かける人たちは片手に持って走ったりしてましたが、非常に危なっかしいです。なので、四の五の言わずこういうものを使うべきと思います(なんかこのために書いたみたいになってきたけど、そういうわけではない…) 。

ポイントは、スマホの向きを回転できる商品を買うことです。普通に取り付け、走らせるときはクルッと逆向きにしてしまいます。

f:id:hijili2:20160725235546j:plain

取り付けた感じ。

 

f:id:hijili2:20160725235554j:plain f:id:hijili2:20160725235558j:plain f:id:hijili2:20160725235601j:plain

走りだすときはクルリと上下の向きを回転させます。これでバッテリーセーブモード(有効にしてね)になるため、画面が消えます。※8/1 同上。でも大丈夫です、バッテリーセーバーが無くても、少し緩めに固定して画面位置を下に下げることで、よそ見もできないし、両手はハンドルで普段と変わりありません。もしポケモンが出たら振動するので、相当な悪路や、車がよっぽど多い道でなければ十分認識できます。

また、もう一つの制約として、自転車に乗りながらイヤホンを使用するのは違反です。よって、音を聞かないか、大音量でSEを響かせながら走るかどちらかしかありません。某公園で、堂々とアプリ音を鳴らしながらポケモンを黙々とゲットするオジサンの姿には感動すら覚えましたが、マネできなかったので私は音無しを選択しました…

ということで、自転車にどうしても乗りたいのであれば、

 ・スマホを固定できるホルダーは必須、手に持ちながら運転しない

 ・走行中はよそ見しないようにホルダーを逆向きにして画面を消す

 ・音による情報は諦めるか、普通に鳴らす

くらいはすべきと思います。徒歩編の「2.移動を止めるとき…」は言わずもがな、自転車でも同じです。

2.ポケストップを探すんじゃない、ポケストップになっていそうな場所を探すんだ

1の対策をしても、やはりポケストップが気になるため注意力が散漫になりがちです。ここは一つ発想を変えて、自転車に乗っているときはポケストップ"候補"探しをしてみると現実世界をしっかり捉えることができる気がします。

例えば「あれ?あそこに神社あったっけ?ポケストップじゃね?」と予想し、近づいて停止し、スマホを回転させて確認します。「やっぱポケストップになってる、ラッキー」てな具合にアイテムを回収します。意外と、こっちの方が面白かったりするかもしれません。(しないか)

ただ、場所探しに夢中になって人を見ていないと本末転倒なので、その辺りは頑張って注意するしか無いんですけども…

3.基本はたまご育成だけにしよう

何だかんだ書きましたが、結局の所、自転車の殺傷能力(自分へのダメージ含む)は徒歩の比ではないので、とにかく人の少ない道を選ぶべきだと思います。ポケストップが無いとか、ルアーモジュール使われてないとか言わず、そういう目的の探索は秋葉原にて徒歩でやりましょう。ホルダーにスマホ付けて、止まらずただ走るだけならば誰も文句の言いようはありません。自転車はそういうふうに使うのがよいと思いました…

 

まあ、そんな感じで、安全に事故なく、報道にいじめられないよう楽しみましょう。以下、おまけ。

 

田舎編

あ、もう自由にやってください。崖とか山道とかだけは気をつけてください。あ、あとリアルポケモン(やせいのリングマとか)にもお気をつけください。

 

車編

ダメに決まってるだろ、バーカ。また風当たり強くなるじゃねーか。運転手はプレイ諦めろ。ってかバスに乗れ。

 

夜道編

深夜徘徊するのはやめましょう。大人でもさ… ただ、人通り多い分には滅多なことも起きなさそうな気はしている。

 

最後に

いやね、ポケモン初代やってたのは小学生の頃だったんですけど、あそこまでハマったゲームってそんなに無いんですよ。確か、大会レギュレーションのポケモン育てるためにタウリン · ブロムヘキシンとかを積むのはもちろんのこと、戦闘回数が多いと能力値が上がりやすいって聞いて、マサラタウンの草むらのポッポとコラッタだけでケンタロスのレベル55まで上げるとかしてたんですよ(大会は結局出なかったですが…)。今こうやってアメを集めて育成してる感じで、その頃の熱意を少し思い出したりして、結構楽しんでるんですよ(すぐ飽きる可能性は大ですけども)。

なので、全国各地でポケモンGOで事故だ事件だと言われると悲しいんですよね。ポケモンGOは13歳以上からということで、そこそこ大人な人たちがメインで遊ぶものなわけですから、各個人が注意してやってればそうそう変なことにはならないはずなんです。ということで、あたり前の注意を当たり前にして、楽しく遊びましょう。

 

 

とかいう記事を書いた翌日に、よそ見して人とぶつかる、とかありそうで怖い…(8/1 大丈夫でしたよ)

 

いまだChangeLogメモで工数集計しているという話

ChangeLogメモってイマドキのかたは使ってるんですかね?
私は5年くらい前に以下のようなサイト様を見て使い始め、まだまだ使っております。

ChangeLogメモの実践
clmemo@aka: Change Log メモを試してみよう

ChangeLogメモとは、以下のようにChangeLog形式でメモをとっていくものです。

2013-07-01 Wed. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: Aさんエスカレ XXX案件
        - 原因調査 1h
        - 対応 30m

    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

2013-06-30 Tue. @hijili2 <hoge_fuga@noexist.com>

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する

    * トラブル対応: Cさんエスカレ
        - 原因調査 45m
            進行中のプロダクトAに影響するかも...


個人的にChangeLogメモは視認性がよくてマークダウンより好きです。

ただ、これだけだと、適当にインデント付ければChangeLogである必要無くない?
って話になるのですが、形式が決まっていることがポイントだと思っています。

先人の皆様もemacs-lisprubyなどで、ChangeLogメモ用のgrep
すなわちclgrepを作っており、私もそれをマネしだしてから、かなり重宝してます。

GitHub - hijili/clgrep: grep command for changelog memo
# 大したコードでは無いです、しかもPerl...

形式があれば何でもできる」と高名なプロレスラーの方も言うように、
ちょいちょい拡張できます。("元気"と"形式"をかけるのは無理があるな1スベリ)


まあ、普通に使おうと思ったらこんな感じです。
「この前 hogeコマンド使って解決したの何だっけ?」みたいなとき。
該当した1ブロックをgrepします。

$ clgrep hoge hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge


「プロダクトA関連の作業だけを一覧したい」みたいなときは
-tを使うと、タグ(と私が勝手に呼んでる部分)だけを対象にgrepします。

$ clgrep プロダクトA hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する

    * トラブル対応: Cさんエスカレ
        - 原因調査 45m
            進行中のプロダクトAに影響するかも...

$ clgrep -t プロダクトA hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する


そこそこちゃんと書くようになってきたので「このまま週報に載せてまえ」
と思い、日付昇順に並べてヘッダだけ出せるようにしてみたり。
また、その際、各行末の \d[mh] をパースして集計するようにしてみたり。

$ clgrep -r . hoge.txt 
2013-06-30 Tue. @hijili2 <hoge_fuga@noexist.com>
    * 設計 プロダクトA: レビュー会 60m
    * トラブル対応: Cさんエスカレ 45m
2013-07-01 Wed. @hijili2 <hoge_fuga@noexist.com>
    * トラブル対応: Aさんエスカレ XXX案件 90m
    * 実装 プロダクトA: モジュールB 180m


お約束の「工数見える化せい」的な話があれば、csvで吐けるようにしてみたり。

$ clgrep --csv . hoge.txt 
# tag,time(minute)
# TOTAL_TIME,375
トラブル対応,135
実装 プロダクトA,180
設計 プロダクトA,60


こんな感じで使っており、個人的には意外と便利だと思ってます。

ただ、結局の所は「いかにちゃんとメモを残せるか」が鍵なので、
そこが面倒で続かなくなりがちではあります…
# 本気で忙しい時は何も書かなくなります…

とはいえ、書くときは結構シンプルで、パースもしやすい一つの形だと思っております。
もしご興味あればお試しください。


では最後に「こんなChangeLogはChangeしろ」をお届けして終わります(は?)


2016-07-19 Tue. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: お客様帰宅時間に間に合わず、明日再調査

    * 実装 プロダクトA: コードレビュー -> 指摘を受け再修正 4日遅れ

    * 出社: 9:15 電車遅延のため遅刻

2016-07-15 Fri. @hijili2 <hoge_fuga@noexist.com>

    * 実装 プロダクトA: 3日遅れ

    * 出社: 9:30 電車遅延のため遅刻


ChangeLogっていうか、遅延時ログだ。(リスケしろ2スベリ)



2016-07-20 Tue. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: お客様が自己解決、追加調査不要とのこと

    * 実装 プロダクトA: 別プロジェクトとの兼ね合いでリスケ、納期1ヶ月延長

    * 出社: 9:45 遅刻かと思ったがシステム故障のため全員9:00扱いになった


ChangeLogっていうか、もはや珍事ログだ。(全てフィクションです3スベリ)




最後のが書きたくてこの記事を書いた気がするのはきっと気のせい。

れがしーしすてむが あらわれた

れがしーしすてむ が あらわれた

 

こまんど

 >すてる

  >きのうA

   ???「それを すてるなんて とんでもない!」

  >きのうB

   ???「それを すてるなんて とんでもない!」

  >きのうC

   ???「それを すてるなんて とんでもない!」

 

 >つかう

  >きのうA

   しかし なにも おこらなかった

  >きのうB

   きのうBは ヘラヘラ わらっている

  >きのうC

   へんじがない ただの しかばねのようだ…

 

 >たたかう(えんはんす)

  >きのうA

   きのうAは なかまを よんだ

   なんと バグA バグB バグCが あらわれた!

  >きのうB

   きのうBは スパゲティコード をとなえた

   あなたは こんらん した

  >きのうC

   もうやめて あなたの こうすうは ゼロよ!

 

ブログを続けさえすればアクセスが伸びる、そんなふうに考えていた時期が俺にもありました

この記事を読ませていただきました。

 

enter101.hatenablog.com

 

そう、PVや読者数なんて関係なく、書き続けることができれば人気ブログになれる!

 

 

 

 

なんて言えないよゼッタイ~♪

 

 

 

それはきっとしかるべき場所で、しかるべき需要に対して書かれた場合なのです。

 

11年細々と続けても、むしろPVが減り続けbotとスパムしか来なくなるブログだってあるんです!!

 

 

久々にあった知り合いの皆様には

 

「え、あれまだやってたの?ブログよりその事実の方が面白いわwww

 

「え?まだ続いてんの?あの内容を続ける胆力が凄いわ…(ドン引き)

 

といった感想を頂きますしね。

 

 

 

さあリンクをクリックし、その内容に刮目するがいい!!

 

 

ameblo.jp

 

 

 

 

うん、まあ、続けたと言っても、休止期間とかありましたけどね。

 

 

せっかくなら、そのまま急死すれば良かったのにね。(1スベリ)

 

質を高めるQCストーリーでも考えたらよかったんですかね。(2スベリ)

 

休止期間開けても、旧式艦のごとく進歩が見られませんでしたからね。(強引な3スベリ)

 

 

 

 

ほら、需要ない。

 

 

 

ということで、質にもこだわりつつ、ブログを続けることをお勧めします\(^o^)/