2017年3月17日

仲間が見つからなかったポエム

日本という国で、保持されているEEZがどれだけ国に利益をあげているのか全く理解できてないけど数百億円かけられたことだけは知っています。そんな沖ノ鳥島ですが、「もしかして俺、なんか消えそうな沖ノ鳥島なの?」という気持ちになりそうなことがありましたようてんです。カウントダウンはそれなりに身を削りつつ順調です。

「あまりにインターネットと仲良くしようとしてない会社環境が限界」

というのが統括的な理由なのですが、もう少し噛み砕いて「仲間がまわりにいなさすぎて」という表現をすると、「増やしていけばいいじゃん」とか「ちゃんと増やす取り組みできてないだけでしょ?(さっさと昇格したら?)」とか「みんな仲間になりたいとは思ってるでしょ?」ってこのタイミングに限らず、めっちゃ言われ続けてきた気がするな、と。


新人研修の最中だったか、最初に配属された課の飲み会ぐらいの非常に大昔の話なんですが。

「家に帰ったら最初にパソコンとテレビの電源どっち先に入れる?」

って話になりまして、もちろん「パソコン」ってこたえたら「ようてんはそうだよねーw」って感じのコメントいただいたんですよ。
# 今現在、そもそもパソコンの電源を落としたりはしないし、スマホが代わってるし、僕は地デジがうつるテレビを持ってない、みたいな展開があるんですが。

これが一番最初に「あっ、もしかして僕みたいな種族この村に住んじゃいけなかったかな」って思ったタイミングでした。

それから長らく「パソコンやプログラミングはとくいだけど基本的には問題児のフレンズ」として暮らしていたわけですが、2005年以降あたりから、「たまたまのLinux」が来て、「モバイルがインターネット」になって「Androidとかでドーン」みたいな波に乗って、顔の広さを手に入れたんです。

それなりに必死に仲間を探しました。
賛同者は結構見つかりました。
「でっかい組織に必要な多様性という観点ではめっちゃ貴重」という感じの評価をしてくださる人も居ました。

GitHubアカウント持ってて、なんでもいいからコードを書いてますな人いないかな・・・ひとり辞めちゃった人が思い当たります。
休みの日もAndroidアプリを書いてて、Playとかで公開したりする人いないかな・・・むしろそれがトリガで同期が一人やめた覚えがあります。
勉強会とか発表とかコミュニティ運営とかがんばってる人いないかな・・・5人ぐらいはカウントできるかな、最近やってないっぽい人になっちゃったのもいるけど・・・他にもいらっしゃるかな。

blogとか、Qiitaとか、社内のWikiとか、どこか業務外でノウハウ残しながら、ドヤ顔しながら暮らしてる人いないかな・・・
若者「やれと言われればやりますけど・・・」
俺「ぐぬぬ」
これについては、今現在はカウントが0です。どなたかやってらっしゃるなら、がんばってください。

GCPやさくらのVPSをちょっと触ったぐらいでHerokuもAWS名前は知ってるだけ、ぐらいだったので、さすがに仕事でさわるのにこりゃまずい、とAWSにも手を出しました。
「タッチパネルと液晶とバッテリついてるAndroidつーLinuxがあるじゃないか」論により、RasPiだいっきらいマンだったのでかたくなに拒んできましたが、Arduinoは手を出してみたら楽しかったです。
VRは・・・お話には聞きますがせいぜい360度動画ぐらいですね。Unityは・・・3回ぐらいかすりました。エディタを起動する必要がある仕事はしたことがないです。

ソフトウェアでお仕事してて、隣のソフトウェアを試してみたくなったりしませんかね・・・?
流行りものが○○でできてるって聞いたら、気になりませんか・・・?
そうですか・・・なりませんか・・・。

まぁ、教え方、誘い方がよかったとは思えません。「俺ぐらいできないと話にならないけどな」と最初っから首を撥ねてしまったのかもしれません。誰かに何かを勧めて始めてもらった経験、あんまりありません。
gitだけはがんばった気がします。世間の必要性が勝手に後押ししてくれたとは思いますが。


ふむ、実は、「勝手に仲間の範囲をせばめてるだけ」な気もしてきました。
3ヶ月一緒にコード書いたら仲良くなれそうかも、何人かは同じ種族に変身してくれるかも、期待は持てそうです。
チャンスさえあれば・・・!

・・・ちゃんす・・・あったっけ?

3人が同じソースコードをレビューできるチームすらつくれる機会がありませんでした。
見積もりだけ、一人プロジェクト、サンプルだけ作ってサポート、二人プロジェクト、見積もりだけ、見積もりだけ、一人プロジェクト、兼務リーダだけ・・・
機会をつくれていない僕のリーダ力やマネジメント力、少ない機会を活かせない僕のヒューマンスキル()が圧倒的に不足している気配です。

そういえば、DroidKaigiのはぐれ2次会でシャープハッカソンの話とか久しぶりにしました。
へっぽこだったので早々に9patch編集するだけの人になりましたが、あれは食べてはいけない果実だった気がしますね。
同じ目的意識、価値観の人とチームを組む機会があれば、チームワークはそれなりに高速に出来上がるという経験でした。

んー、なるほど。なんとなく整理がついてきました。
「俺の仲間になれよ」がものすごく心理的に苦手っぽいです。
最初っから同じ言葉が喋れていれば、「あー、俺ら同類かも・・・」ってシンパシーいけそうです。

それでも、仲間が欲しいのであれば、他の種族の言語を勉強して話かけるしかありませんよね。
よし、じゃあ俺が種族を変えよう、と「あなたの言葉がんばって勉強しました、仲間にしてください!」
と、今の会社の他の方々に言いたい気持ちになるか・・・いやー・・・全くなりませんね。

まぁそもそも僕がそういう気持ちになったとしても、仲間に入れてもらえるのでしょうか。
年寄りですから、そういう機会、少しはあった気もします。

「そっちの方面の才能はようてんさんないでしょー」
「そうじゃないんじゃない?」
「んー、君にそれはどうかな」

思い返してみると、むしろ「お前仲間じゃねーし」ってめっちゃ言われてきた気がしてきましたね。


「両生類ぐらいにはなれると思ったけどやっぱ無理www呼吸できないし魚類は海に還りますwwwバイバーイwww」

これでいい気がしてました・・・ホント?

2017年3月11日

#DroidKaigi 2017感想

DroidKaigi2017に参加しました。
最近のAndroidはよくしらないのでわからないことばっかりだったのですが、まぁわかんなくてもわからんことを気づくこと自体も楽しかったですよ、うん。

○わからない度合い

・知らない:ReactNative
・知ってるだけ:Kotlin, DDD, Chrome Custom Tabs, LayoutManager
・Hello Worldはしたことがある:Orma, Firebase(Realtime DB)
・どんなものかおさえるため少し試したことがある、採用していない:RxJava/RxAndroid, React, Realm
・試作案件で導入した・経験がある:Data Binding, ActiveAndroid, target23
・商用案件で導入した・経験がある:PubSub(EventBus/Otto), OkHttp, system app, BLE
・MV*については「ViewとModelがちゃんと分かれてば他はだいたいどうにかなるんだよ!どうでもいいよ!」サボり派

○聞いたセッション一覧と感想

【1日目】
・マッチョActivityを改善した話
「どうController/Presenterの肥大化を抑えるか」という話かなと思ったのですが、「とにかくでかいActivityをMVPありきでModelを分離してDI可能なようにstatic排除した」staticおじさんへの呪詛が多く「いいものはいいんだよ!わかるだろ!」がわかりませんでした。

・Android Security 最前線!!
ロックと暗号化つらかったのDirect Bootでどうにかなったのね。まぁロックつらいようなアプリは安易にロックスクリーンしがちですが。「いいからデバイス証明書にこれインポートしろ!」しないで済むNetwork Security Config便利そう。

・Androidリアルタイム通信アプリ作成Tips
OkHttpでWebSocket使えるようになったのですね。ただWebSocketはWeb側ですでに・・・とかじゃないと採用しない気がします。FirebaseとかRealm Mobile Platformの話は中身がコードばっかりすぎて密度高くてきつかったですね。
僕は機能なんかより「OSS度」「ロックイン度」「公式度」からRealmをとくにオススメしないマンだったのですが、Realm Mobile Platformはむしろエンプラでクローズドなプロダクトで便利そう。

・Data Bindingで開発を気持ちよくしよう
初心者向けに優しいところから順番セッションでした。「つらいとこでは使いません」がはっきりしてて良い質疑応答だったなと思います。さらばFindViewByIdとかさらばif(isVisible)ぐらいのあたりまでが一番導入コスパフォ高くていいと思ってます。

・実践アニメーション
アニメGIFらしき実例のフレームレートが足りなかったかな・・・。

・オフラインファーストなアプリケーション開発
かなりあとのほうまで聞いて、「マスタがインターネットにあってローカルがキャッシュという話とは逆で、ローカルDBに対するアプリとして作っても、Realm Mobile Platformを使えば+αいけるよ、オフラインファーストの方がよさそうなアプリでは使ってね」というトータルの言いたいことがわかりました。
ざきさん知ってれば予想はついたとは思いますが、Realm Mobile Platformの単語出さずにこれはちょっとRealm前提すぎて騙し討ちだったような・・・

・React Nativeはクロスプラットフォームモバイルアプリ開発の夢を見るか
発表材料をでっかく作った上で丁寧に取捨選択・圧縮してある印象で面白かったです。紹介・導入・評価・実例、オチまで30分枠につめた圧縮手法すごい。

・Android Bikeを作ろう
ようこそBLEへ。

【2日目】
・Android ORMの選び方
丁寧だったけど読み物すぎて書籍で読みたかった感じ。Ormaでマイグレしたことがない(カラム追加以外のまともなマイグレが必要になったことがない)ので今度試しますごめんなさい。

・個人で11個のアプリを公開した結果
参考になるかはさておいて、あるある話満載で楽しかったです。みんな作りたいから作ったしような。

・いまからはじめるAndroid 6.0対応 〜Android 7.0から8.xを見つめて〜
あんまり7,8を見つめてなかった感が・・・「去年採択されなかったのを出したら通っちゃいました」、えーと。

・Systemアプリ開発入門
「AOSPビルドしたことがある人」ぐらいじゃないと話にならなかったと思うのですが、まぁセッション参加者も猛者ばっかりで問題なかった気がします。
どちらかというとマルチユーザ対応さらに需要ないと思うんでおまけのAndroid Studio/debug話の方が聞きたかった感がありました。

・Chrome Custom Tabsをさらに使いこなそう
サンプルアプリとスライド事前公開ありがたい、「WebViewはちょっと武器庫すぎたから遊ぶのはこの砂場で我慢してくれよな」がよくわかりました。

・Fireside Chat
あったまった

・LayoutManagerをつくろう
「もう少しいうこときかせられるつもりでとりかかったけど強かった」セッションになってました。質疑応答の「お前はこう、俺はこう」がよかったです。

○KPTのT

Try
・見知らぬ人に突然押し付けるためのコンテンツを用意しよう
・直前にAndroidについてつらい気持ちにならないように業務や人生をコントロールしよう

○その他感想

・VRとかAndroid Thingsとかなくて多様性についてはもう少し欲しかったな、と感じましたがまぁでも「みんなが(=3割ぐらいの人が)聞きたいコードの出てくる話かと考えた際にそんなに需要はないか」とも思ったので、「セッションで話すべき」ではなくて、スポンサーブースとかゲリラデモとかAfter partyとかセッション外でも場がないわけではない気がしてきました。
・ただ、ReactNative/XamarinあたりのAndroidの多様性というプールでキャッキャ遊んでる盛り上がりと比較すると、Rx, MV*満載で「コードはこうあるべきだ」理想追求はちと抽象化されすぎで、「実際の問題についてコードでどう殴るか」まで落ちてないセッションを引いてしまった印象でぐぬぬでした。
・「どう理想の世界をつくるか」よりは「どうなんとか(スキルがつらい、客がつらい、同僚・上司がつらい)やっていくのか」が必要だと思うんですが、みんななんとかなってるんですかね。
・after partyで全然見知らぬ人としゃべらなかったししゃべるネタあんまりもってなかったの反省。個人として退職芸人中のステータスが悪いといえばそうなのですが:)

いろいろ最善とはいえないコンディションだったけどそれでも楽しかったです。

2017年3月 8日

iOSユーザとAndroidユーザを戦わせなくてもいいじゃないか

【デザイナー向け】これからAndroidのデザインをする人へ
http://qiita.com/AAkira@github/items/02814f337f4eb2d30f2e

なんとなく思うことがあったので。

○全般

【デザイナー向け】という枕詞をつけるのであれば、Android用語をもう少し一般的な表現に直した方が良いかな、と思いました。「Androidに詳しい人へ向けたAndroidのデザインに関する愚痴」のテイストが少し強すぎという印象です。

○個別

・見出しが「Android用語」と「デザイン用語」と「(はじめに、や一番いいたいこと、など)文章を構成する一般的な見出し」が混在していて読みづらいと思いました。

・僕の経験則で言うと、すぐれたデザイナーはiOSのデザインコンセプトがきちんと別の体系に翻訳されていますので、単にAndroidを使っているだけではなかなかそのMaterial Designの全容を体系だって体得するには至らないと思います。そのため、「いいから2台もちしろよ」みたいな乱暴で(コストの高い)提案ではなくて、貸してあげるとか、タブレットにでもどうだい、とか、このアプリは比較して30分使ってみるとAndroidについてよくわかるよ、とか、そのぐらいがイイトコロじゃないでしょうか。

>「Android暗黒時代と呼ばれる2系の端末を所持していた経験があり、Androidに嫌悪感を抱いています。」
あんまり暗黒時代と呼ばれてない気がしますし、真にヤバかったのってIS○3とかIS○4とかではないですかね・・・「葬式UI」ではありましたけど2.3は(とくに2.3.3以降)ほどほどだったと思いますし、Honeycombなら暗黒時代と呼ぶのはわかるんですが、「2系は暗黒時代とよばれていた」みたいな表現はちょっと乱暴に感じます。

あと、俺は詳しいんだアッピルするなら「2系」とか「5系」とか小数点以下ふっ飛ばさないでほしいのです、「4.4系(通称 KitKat)」ももう一息丁寧に

>一旦5系以上の端末(日本, 中国製, 低価格帯は除く)を使用してから言って下さい。
これも「中国」といわゆる「中華端末」が区別されてない印象を受けます。例を挙げるとHuawei、Nexus6Pとか、ね?

>dp(dip), sp
>dp
「密度非依存ピクセル」という説明の前にいきなり「○○は大事である」って入ってて思考ジャンプが強いです。
その割には「pxという言葉は忘れてください」ってこれも乱暴ですし、忘れないでもいいじゃないですか。
さすがに5インチWQHDはアレかなー、って思いますが、6インチFHDぐらいならピクセルパーフェクトは結構狙って価値があると思いますよ?

>dpがない場合はこのように表示されます
>dpがあると同じ様なサイズで表示されます
この表現はなんだかよくわからないです。

>sp
>AndroidではiPhoneとは異なり そもそも複数画面サイズがある前提なので、
「iOSとAndroidのシステムフォント設定サイズへの追従度」について、とくに手持ち情報があるわけではないのですが、iPhoneもSEから6P/7Pまで結構サイズ違っちゃってるじゃないですか。
フォントサイズ設定に耐えられるUIの柔軟性設計は(そもそも他言語の方が鬼ではありますが)どちらでもそれぞれ大切だ、ぐらいの方があってるのではないでしょうか。

>4の倍数
さっき「pxという言葉は忘れてください」って言ったじゃないですかー。

https://material.io/guidelines/layout/metrics-keylines.html
"All components align to an 8dp square baseline grid for mobile, tablet, and desktop. Iconography in toolbars align to a 4dp square baseline grid."
Material Designのテンポがそうだから「8dp(4dp)のグリッドに・・・」でいんじゃないですかね。

>戻るという概念
こんにゃろめ、"Up"という単語を使わずに説明しようとしてわかりづらくするなんてハッハッハ

>下タブ
下タブそのものが悪だったのかはよくわかりません。ガイドライン違反はアレだと思いますが。

>WebView
Chrome Custom Tabで概ね勝利なのですが、「iOSはintentという概念が無いので、よく使われます。」というのも少し首をかしげます。
back to appでcustom URL scheme組み合わせるやつとかiOS9からそれなりにいい感じですよね?

>基本構成
IDEのファイル構成を説明するのは本当にデザイナー向けなんですか・・・?なんのための説明・・・?

>アンチパターン
>プルリクエスト
このあたりクライマックスしてて、(気持ちはわかるんですが)「iOSユーザの気持ち」にも「デザイナーの気持ち」にも寄ろうとせずに「Android開発側の流儀ぐらいちゃんと把握しろよ!」テイストを強く感じました。

iOSとAndroidバトらせるんじゃなくて(いやそれはそれで楽しいのですが)、素直にデザインとUIとプログラミングの良い関係を目指していきたいものです。

P.S.
ドラムロールだけはさっさと滅べ>iOS

2017年3月 6日

良書という概念が理解できた時点で勝ち

books.jpg

「○○に読んで欲しい良書N選」みたいな話が定期的に世の中には流れてきますが、そもそも「良書」というものがどういう概念なのか、そのメリットを体得していないとそういうN選情報って有効に使えないな、って思います。

絵本でも、マンガでも、ラノベでも、音楽でも、アニメでも、「良いメディアを人に紹介される/人に紹介する」経験を積んで、良コンテンツとして認識する練習をしておく必要があって、「良書とは、良書というものがどういう概念なのか理解できるようになるスキル習得率が高い書物」みたいな再帰的なものを感じます。

さて、載せた写真は「もうそろそろ家に持ち帰り始めないとまずいやつ一式」ですが、色々な本を持ってきたり貸したりした感想を3つほど。


1. 積極的に貸しても、メリットは薄い


主体的/受動的、貸す/借りるという2要素の組み合わせのうち、「価値があったな」と感じる順に並べると、不等号は以下の様なイメージです。

「主体的に借りる」>「受動的に借りる」>>>「主体的に貸す」>「受動的に貸す」


以前書いた情報共有の話と似ているんですが、積極的に情報を収集するアンテナが育っていないと砂漠に水をやるようなもので、「新聞くらい読んでおけ」が概ねのシーンで役に立たないのも同じ話だと思います。

反対に、人が良書だと評価したものを借りる・後で買うのはかなり価値が高いです。自分で良書を探すのではなくて、積極的に人から良書を紹介してもらいましょう。アニメやゲームを紹介されて人生が豊かになるやつです。


2. 本がずらっと並んでいると、本人の価値観だけが増幅されて、他の人との認識の差が大きくなる

このずらっと並んでいる写真を見ると、僕本人はそれなりにテンションが上がるんですが、自分の中で既に積んでいる良書体験を思い出して幸福感が生まれる回路が働いてしまうだけで、この本棚を見たほかの人の評価が連鎖して上がるわけでは決してないということです。

あまり気にしないようにしてきましたが、これに対して「うわっ」「全部ようてんさんのですか」みたいな感想が多かったですね。もっと酷い人は「私物のゴミを会社に保管するなよ」みたいな感じのコメントをしてきます。


3. それでも、効率アップには貢献してくれたと思っている

それでも、「顔をつきあわせて2時間×10回」みたいな話をある程度代替できるのが書籍の備蓄・貸与のいいところだと思っています。

特にノンデザイナーズデザインブック、リーダブルコード、yanzm本3冊セットは「あまり本を読みなれていない人にも押し付けてメリットが発生しやすい」運用コストの低い良書だと思っています。僕が本を押し付けた何人かの人が、「良書」の概念を理解するきっかけになっていればいいのですが。

2017年3月 1日

SAO劇場版オーディナル・スケールの感想脳内垂れ流し(※ネタバレ注意)

以下、ネタバレ

続きを読む "SAO劇場版オーディナル・スケールの感想脳内垂れ流し(※ネタバレ注意)"

2017年2月24日

「知識がないと、どれくらい知識があるのか測れない」問題

過去3回ほど、仕事と組織構造が両方一緒に変わるという意味での、おっきな異動がありました。


1回目は「C言語はまぁできる人」というフダがついてドナドナされました。

何も勉強せずにネトスペがとれた直後だったりもしたので、僕本人はIPネットワークとかLinuxとか黒い画面とかマルチメディアまわりについてそれなりの人、のつもりでした。

アセンブラとCで記憶型液晶を戦う世界で、μITRONがーとか言う世界でした。ところが、ある日突然WinCEでMacromedia FlashとかVC++でDirectDrawみたいなのに方針が変わる事件が発生しました。今思い返すとなぜ契約続行したのか、おかしさしかありません。


2回目は「どちらかと言えば問題児で、WinCEをやってた人」というフダがついてドナドナされました。

2年ぐらい上司と面談の時にしか話をしない期間があったので組織に残すべき人とは判断されなかった模様です。この後、DirectShowに泣かされた次ぐらいにJavaEEとDebianと出会って「だいたいインターネットとLinuxで世の中なんとかなる」という世界に出会えたので、ドナドナされてよかったと思っています。問題児だったことは否定しません:)


3回目は「だいたいなんでも屋の、いくつかのジャンルでスペシャリストの人」というフダがついた感じで、異動というよりは仕組みのシャッフルがおきました。

スペシャリストは「どこかが尖っている人」だと思いますが、どのくらい尖っているのか、測るモノサシがないと、鞘が用意できません。

分かりやすいジャンルを挙げると、僕は(ピークが2年前なので現時点ではなまくらがさらに錆びた感じなのは置いといて)

・Android:社外でもそれなり
・iOS:ゼロじゃないけどひよっこ
・Web:社内標準よりははるかにマシだけど世間標準かは怪しい

ぐらいの自覚なんですが、これが今のぼんやりとした会社のモノサシに当てると多分こうなっています

・Android:できる
・iOS:できる
・Web:できる

おーい。


流石に物理的に組織が縦割りになりすぎて。「○階に物差しもって遊びに行く」とか「○○拠点に背比べしに行く」とか機会がなくなっちゃいましたね。

2017年2月23日

共有されないと情報として意味がないのだから、「情報共有」という用語はそもそもおかしいのではないか

mixiクローンなグループ会社向けSNSの利用が推奨になった
→意識高い人から友達申し込まれて疲れた
→特化コミュニティつくって好きなこといっぱい書いた
→反応ほぼないしあっても顔見知りだし、どうせ社内情報書けないし自分のblogでやったほうがよいのでやめた

社内Wiki貸し出しサービスが始まった
→複数のWikiでいっぱいノウハウ書いたりBBS系プラグイン整備してみんなで「新聞や雑誌を読んだ所感を述べよう」日記みたいなのをやった
→○○部/課Wikiみたいなのにするから組織変更のたびに死亡して廃墟となっていった

全社Wikiができた
→ただのぐぐった結果のコピペ寄せ集めになってぐぐった方が早いオチになった
→交渉して権限もらってリニューアルした、各部門のジャンル特化WikiのRSSクロールしてソートするポータルにした
→各部門のジャンル特化Wikiがプロジェクト情報を放置したりして、NDA事故の気配がする危険な廃墟が現れ始めた
→廃止された

PukiWikiに慣れていたのでPerlのFreeStyleWikiは色々ノウハウが足りず、PukiWikiで皆が書きやすいプラグインを導入しようと思った
→IISではPukiWikiは動かなかった。
→UbuntuでWordPressの運用を開始した。
→めっちゃエントリを書いたが残念なことに固定客ばっかりだった。それなりには楽しかったしURL一つメールで投げればいいのはやはり便利だった。
→その後、「みなもすなるblogというものを」な流れで、WordPressが乱立した
→誰も書かない、メンテできない、ただの固定IPなPCを各地で動作させており、アドレスがわからず流入口がない、で寂れた
→LDAP認証必須の流れに従って一斉閉鎖となった

めっちゃCGIって感じの重役やベテラン持ち回り日記はそれなりに機能した
→「いいね!」が「いいですね!」なのは苦笑いだったが慣れた
→閲覧権限整理の流れで縮退したが一応生き延びている気配がする

社外ページがMovable Type製でリニューアルされた
→外注丸投げ後、仕組みを理解していない人が出力されたHTMLを直接編集して耐えていた
→静的HTMLを直接差し替えてデザイン刷新が行われるという事件が起きた
→Movable Typeはどうなったのか知らない。今はおそらく違う仕組みのはず。

GitHubに感動したのでGitLabを立てた
→エクスプローラから右クリックできないと困る亀Subversion勢の迫害を長く受けた
→定着したがWeb UIは特に使われていないようだ

DevOpsの流れでChefとかが盛り上がった
→社内VPSでGitBacket+Redmineイメージ貸し出しサービスが始まったこれは勝つる
→RAM 512MBという貧弱スペックでも割高で、プロジェクトが終わるたびに即座に破棄が必要で、不人気だった
→OSがアップグレードされず他のアプリ(主にnode系)をあわせるのが面倒で形骸化した

Slackを使ってChatOpsが楽しいと思ったので、DevHubでそれなりに遊んだ
→GitLab/GitBucketからのWebHookを書いたが僕しか喜んでいない気配はした
→「ようてんさんいますかー?」「質問があるんですが」とチャットで反応を待つ同期コミュニケーションマンがとても多く、Slackで楽しかったようには使えなかった

テキストノウハウはいい加減git+mdでいいだろう、とGitBucketのWikiで全部書き始めた
→GitBucketはLDAP認証にも対応だ、これで勝つる
→パスワード変更時、MacがOSレベルで認証proxyを越えようとしてロックがかかるので、定期的に必ずアクセスできない日ができるという恐怖のリポジトリになった

顧客からの指定でBacklogやSlackなどを聞くようになり、もう一回ChatOpsだ、とSlackクローンを試行した
→そもそもSlackも含め「Webchat」はWebフィルタリングの対象だった、インストールできず敗退した。


今、ないということは、必要がなかった、ということだと整理している。

2017年2月22日

「認証proxyヤバイ」問題

1. 設定しないとインターネットが利用できない

 逆に言うと設定したら利用できるぐらいならそこまでコストは高く無いです。

2. 種類が何種類もあり、OS・ソフトウェア・バージョンによって設定方法がマチマチ

 IDEとシェル・バッチのうち片方しか越えない、みたいな話はザラで、Ubuntu14.04と16.04で違うとか鬼なラインがあります。

 ぐぐって見つけた解決法で解決しない確率が体感50%を超えます。とくに国外(英語)の情報は勝率が悪いです。
 実現方法に何種類かがあるのが原因なようで、「i-○ィルター」が最恐っぽいです。

3. ブラウザの利用までしかサポートされていないケースがあり、ブラウザしか使わない層はコストが想像できていない

 運用者と責任者がコストを把握できなくて、適切な対策がとりづらくなります。

4. 認証proxyを使っていない人にコストが説明できない

 「認証proxyのせいでセットアップに苦戦して時間がかかりました」とか顧客に言うわけにもいきません。

5. セキュリティ目的で導入されるとそれを理由に詳細仕様が手に入らないため、ノウハウが共有されづらい

 環境のアップデートですぐ形骸化するので、それなりにコストを払ってでも共有すべきだと思うのですが、
 業務情報や個人の情報を省いた形で情報を整備するのが面倒らしく、組織的なサポートは最終的にはほぼなしでした。

2017年2月21日

2段階目以上の組織長は「同じ仕事をする仲間が隣に常に居る」問題

10年スパンといわずもっと短いスパンでも観測できそうですが、「同じ仕様のITシステムを構築するのにかかる時間」というのはなんかやたらめったら短縮されてしまいました。

プログラム開発によるITシステムを用いたサービスを実現するのに以下の3つの工程に強引にまとめて考えるとします。

1) 企てる →人間が相手
2) 作る →機械が相手
3) 試す →人間が相手

「2) 作る」という工程の中にも、機械が相手のものと人間が相手のものはあると思いますが、人間が相手のしくみは世界の歴史上、生産性向上がサチっていますが、機械が相手のしくみは生産性がまだまだ上がり続けています。

その結果、時間の短縮もありますが、体制がガンガンスリムになっている印象です。

<例>
10年前:システムの要素Aの機能αを3人で
5年前:システムの要素Aを機能α・β・γを1人1機能で
 最近:システムの要素Aを1人で
 今後:サービスのITシステム部は1人で

この一人(以下)ってのが強烈にリスクで、ちゃんとしたITエンジニアであればその危機感をトリガとして、「なるべく標準の技術で、ノウハウを共有して、薄く広くでも守備範囲を重複させて」といったリスク管理をすると思います。

さて、ちゃんとしていない「ふつうの」ITエンジニアだった際には、どうなるかというと、これがまぁ驚くほど「あるがままに降って湧いた技術を選択し、ノウハウは共有せず、特定顧客と仕事をしたことを価値と考える」モードになるんです...

僕『何の仕事してたの?』
*「○○(顧客名)の仕事をしてました」
僕『何をしてたの?』
*「XYZ(プロジェクト固有名詞)を触ってました」

こんな感じなので、「この技術は1人しか把握していない(他に居るのか居ないのか分からない)」状態が進んでおり、1段階目の上司は気づき始めている人が多いのですが(プロジェクトの合間にすぐ困りますからね)、どうも2段階目以降の組織長は「客は変わったけど仕事のやり方は変わってない」の範囲で済んでしまっているギャップを観測しています。

まぁホワイトですし、お金さえあればガチャは引けるわけで、なんとかなると思いますが、そこに面白さは感じません。
みんな同じ役割をこなすのは効率がよくないと思いますが、一緒の仕事(目標)をしてない人と同じとこに所属してもメリットは...

僕は
「新しいことがしたかった」
わけでも
「みんなと違うことがしたかった」
わけでも
「みんなに新しいことを教えたかった」
わけでもなくて
「みんなで同じことがしたかった」
んですが、主張や説得が下手だったのであまり理解してもらえなかった模様です。

2017年2月20日

LINE BeaconはBLEビーコンの1種だったのですね

さっぱり知らなかったのですが、RasPiみたいにでかくて電源系のお守りが必要な子でクローンがんばるのも大変だろう、とiBeacon互換(でスマホクローンができるのかどうか)のあたりだけちょっとのぞいてみました


ラズベリーパイでLINE Beaconが作成可能に!「LINE Simple Beacon」仕様を公開しました
https://engineering.linecorp.com/ja/blog/detail/117
LINE Simple Beacon
https://github.com/line/line-simple-beacon/blob/master/README.ja.md

>LINE Simple Beaconは、デバイスのなりすましを抑制するメカニズムが存在していません。 そのため、ビーコンデバイス識別IDでの正真性を前提としたBotサービスには利用しないでください。
うい。

02 # Data length : 2byte
01 # AD Type : Flags
06 # BR/EDR Not Supported(4) | LE General Discoverable Mode(2)

03 # Data length : 3byte
03 # AD Type : Complete list of 16-bit UUIDs available
6F # 0xFE6F固定 LINE corp
FE

0E # Data length : 14byte
16 # AD Type : Service Data
02 # 02固定 [LINE Simple Beacon仕様] Frame Type
XX XX XX XX XX # HWID, Line Botから払い出される
7F # 7F固定? [LINE Simple Beacon仕様]

というわけで比較するとこんな感じ。

iBeacon:
 Flags(3bytes) + Manufacturer Specific Data(26bytes)(UUID+Major+Minor+TXの入ったいつものやつ)

LINE Simple Beacon:
 Flags(3bytes) + Service 16bit-UUID(4bytes) + Service Data(14bytes)(HWID 5bytesのみ)
 または
 Flags(3bytes) + Service 16bit-UUID(4bytes) + Service Data(23bytes)(HWID+Device Message 9bytes含む)

・LINEアプリが勝手に吸ってサーバにあげて、(必要なら認証の上)LINE bot/LINEアプリにコールバックっぽい。
・iBeaconじゃないのでiOSのBackgroundあれこれの恩恵は受けられない。iOSアプリでLINE Simple Beaconクローンも作れない。それで「お店でアプリを起動して、商品でボタン押してね」なのですかね
・Eddystone-UID互換でもない、やる気あるな。
・LINE BOTの「うおおおそこあけてきたか」級ではなくて、LINE MALLぐらいの感覚で期待するのが良さそう:)


○きがむいたらかくにんする

たぶんAndroidでもSimple Beaconは組める
https://developer.android.com/reference/android/bluetooth/le/AdvertiseData.Builder.html#addServiceData(android.os.ParcelUuid, byte[])

ただし、setConnectable(false)で02 01 06のFlagsがちゃんと出てくれそうなら。
https://developer.android.com/reference/android/bluetooth/le/AdvertiseSettings.Builder.html#setConnectable(boolean)
・setConnectable(true)だと02 01 16になって互換があやしい
・んでも本物のLINE Beaconはメッセージ書き換えとかできるだろうし02 01 16だったりしないかな...それとも多重Advertiseかな

2017年2月16日

歴代PCメモ

歴代ノートと歴代PCをよく忘れたり調べ間違えたりしてるのでまとめなおしてみた。
強いて言えばサブノートが好きだったけどスペック厨でもなかったし特に面白味はない。

○歴代ノートメモ

1998
SONY VAIO 505初代 PCG-505 Pentium MMX-133 64MB
http://www.sony.jp/products/Consumer/PCOM/VAIO/Note505/

2002
TOSHIBA Libretto L5 PAL5080TNLN Crusoe TM5800 256MB
https://www3.toshiba.co.jp/pc/catalog/libretto/020424l5/spec.htm

2005
Panasonic Let'sNote R4 Pentium M 753 512MB
http://panasonic.jp/pc/p-db/CF-R4GW5AXR_spec.html

2010
Acer Apsire A3820-A52C Core i5 460M 2GB(のち6GBに増設)
http://kakaku.com/item/K0000163585/spec/

2011
Apple MacBook Air 11inch Mid 2011 Core i5 1.6GHz MC969J/A 4GB
https://support.apple.com/kb/SP631?locale=ja_JP&viewlocale=ja_JP

2012
DELL XPS 12 9Q23(2012) i5-3317U 8GB
http://www.pasonisan.com/xps12/9q23-top.html

2013
Apple MacBook Air 11inch Mid 2013 Core i5 1.3GHz 8GB
https://support.apple.com/kb/SP677?locale=ja_JP&viewlocale=ja_JP

2014
MSI GS60 2PE-040JP i7-HQ4710 GTX870M 16GB
https://www.ark-pc.co.jp/bto/customizer/?pc_id=0234

2015
G-TUNE NEXTGEAR NOTE i5710 i7-6700HQ GTX970M 16GB
http://www.g-tune.jp/note_model/i5710/

○ついでにデスクトップ

1997
IBM PC350 Pentium MMX-166 128MB

1999
Celeron 433 256MBあたりだった気がする

2002
Athlon 1600+ Palomino GeForce MX 400 512MBあたりだった気がする
FX5200かFX5500をもってた気がするんだけどいつ運用したんだこれ・・・

2006.04
Pentium M 750 7600GS 2GBで新規購入
http://b2hs.netgamers.jp/archives/2006/04/pc.html

2007.08
C2D E6750に変更
http://b2hs.netgamers.jp/archives/2007/08/c2dg33.html

2010.01
9600GTGEに変更
http://greety.sakura.ne.jp/redo/2010/01/from-geforce-7600gs-to-9600gtge.html

2016.03
i5-6600K 970GTX 8GB(16GBのつもりが店に間違えられた)でケース以外刷新
https://twitter.com/youten_redo/status/714783130255695872

2017年1月10日

2016年に買ったマンガ・ラノベ

いまさらAmazon購入履歴から思い出しながら書いてみました。・「オススメ・プッシュ」>「普通・すでに取り上げた/今更取り上げるまでもない」>「他」という順番で並べていますが色々抜けてそう。2016年はラノベ少なかったので2017年はもう少し発掘にチャレンジしたいと思います。

続きを読む "2016年に買ったマンガ・ラノベ"

2017年1月 3日

2017.01.03現在のCardboardはUnity5.5.0p3 + Google VR SDK v1.0.3が良さそう

【結論】
Daydream → 5.4.2f2-GVR13
Cardboard → 5.5.0p3 + Google VR SDK v1.0.3

UnityのNative対応、Cardboard向けがダメっぽい印象です。首振り追従が優先されてフレームスキップが強烈に効いてる様に見えますが、計測上40-50fps出ているのに見た目では5fps程度に落ちます。(というかめっちゃシンプルな画面なのでそもそも60fpsから落ちないでほしい。)

以下の試行はSC-05G Galaxy S6(Android 6.0.1)で確認、(Galaxy S6はDaydream not readyなのでもちろん)Cardboard向け。

・5.4.2f2-GVR13 Technical Preview + Native → フレームスキップ低fps
・5.6.0b3 + Native → フレームスキップ低fps
・5.6.0b3 + Google VR SDK v1.10.0 → ビルドエラーが取れず
・5.5.0p3 + Google VR SDK v1.10.0 → ビルドエラーは取れたがAndroidManifest.xmlマージ死。Runtime Permission対応まわりのtargetSdkVersion22だの24だのがうまくいってない。
※どこかManifest探して書き換えれば良いことはわかるが筋が悪いので追いかけない。
・5.5.0p3 + Google VR SDK v1.0.3 → 正常動作。
 ・対象シーンはGoogleVR/DemoScenes/HeadsetDemo/DemoScene
 ・いつものPlatform - Android + Default Orientation - Landscape Left + Other Settings - Bundle Identifierの変更とmin API Levelを4.4(19)に。

Unity 5.5.0p3はここから5.5系最新パッチをダウンロード
https://unity3d.com/jp/unity/qa/patch-releases/
Google VR SDK v1.0.3はここからv1.0.3を掘って
https://github.com/googlevr/gvr-unity-sdk/releases
最終的にはGitHubのここからDownload
https://github.com/googlevr/gvr-unity-sdk/blob/f391c2436426857899af1c37f0720b3985631eb3/GoogleVRForUnity.unitypackage

2016年12月26日

酔っ払ってないWeb昔話

いつも酔っ払った際にしか話をしないので話半分どころか話1/10みたいになってそうな気がしたので、酔っ払ってない際にメモを残しておきます。

B2HS 2010.07凍結 ピーク時UU3k/dayぐらい、おそらく月間10万PVぐらい
騎士Wiki 2009.08閉鎖 ピーク時UU8k/dayぐらい、おそらく月間25万PVぐらい

あともう少し遡るとR-18の端きれをWebの海に投げ捨ててた時代もあったのですが、こちらもたいそうPV効率は良かったです。

Google Analyticsみたいにちゃんとしてるわけではないのと、RSSリーダ・ブックマーク巡回ソフト全盛期だったので真UUだと1/3ぐらいでしょうか。
今のこのサイトがピーク時月間PV12,000ぐらい、今7,000ぐらいなので当時の1/50のパワーみたいな話ですね:)

当時は「職Wikiか人気個別タイプサイトもって、月1000円のサーバ代ぐらいは稼げる」ぐらいが主流だった気がしますね。狩場情報とかダメ計算機とかコアデータを扱っているところはPVに対してもっとシビアだったとは思いますが...。

学生時代に学校設備として借りていたスペースで知人・友人が10人来るのを日記Last-Modified巡回システムでウォッチするあたりから始まって、Geocitiesでバナーを消してBANされる様なの、mixiに始まる大SNSあしあと時代を経てこういうのを覗いてると、たいそうWeb感が歪んだわけで。

これを「あるある」というのか「おかしい」というのか...はてさてみんなどんな感じでインターネットに蝕まれくと仲良くなりましたか?

2016年12月20日

ノクターンノベルズ2016

"なろう"がすっかり現代用語の基礎知識の一つみたいな感じになってしまいましたが、みなさん、ノクターンノベルズは読んでいますか?
一時期R-18なWeb小説界隈の片隅で暮らしていた自分ですが、今年も寝床でスマホをいじって結構な数を読みました。

記憶力もよくない方ですしきっと漏れがいっぱいあると思うのですが、今年は多数「振り込めない詐欺」が解決し楽しい年でした。適当に紹介したいと思います。

おっと今更ですが概ねがっつり18禁です。お子様はおかえりください。

続きを読む "ノクターンノベルズ2016"

Archives(記事一覧はこちら)