オレンジライオンの足跡

相談ベースでお仕事募集中です。

IoT Kickoff #4を開催しました

こんにちは、ラ、ラ、ラ、ライオンです

動物に等しい知能なので人見知りです

IoT Kickoff #4を開催しました

今回は 下北沢OSSカフェ にお邪魔してきました

工作室を作られたみたいで、中には工房と呼ぶにふさわしいような環境が構築されてました 😲

目玉

AIスピーカーが熱い 🌞

まぁ少し旬を過ぎた感じは否めなくもないですが、 そんなことはどうでもいい

さて、というわけで取り組みますが、この記事では製作しました系は皆さんがやられているので、ハード系のハンズオンをやる上での気づきみたいなものを書いて行きたいと思います 📝

Google AIY Voice Kit

Google AIY Voice Kit

製作しました系の記事を見たい場合はこちら

yuki-no-yabo.com

相変わらずのclassmethodさんは違いますねw

dev.classmethod.jp

気づき1

今回ハンズオンに向けて、8個ラズパイを用意するつもりでしたが、いつ届くか分からず不安から3個追加で買ってしまい、10個のラズパイが積み上がってしまいました 😝

f:id:lion_man44:20180121160402j:plain

(写真は11個ですが、1個は初期不良だったために交換していただいております)

AIY Voice Kitは8個購入しましたが、大量に購入しておいて良かったです 🤗

案の定いくつか壊しました 😑

  • 電源が突然、ダウン。それ以降うんともすんとも言わなくなった
  • ダンボールに格納する際に引っ掛かりを感じるが、硬めのダンボールのせいだろうと思っていたらmicroSDカードが引っかかってたらしく、中折れする。しかし、参加者の方に中折れしてしまったSDカードを抜いてもらい、テストできる状態に(本当にありがとうございます

なので不器用な方、帯電体質な方、は気をつけて作業した方が良いです 😩

気をつけないと1万ぐらいが吹っ飛びます(計算してみたら自分のかけたコストは12,000円ぐらいでした。まぁ関係なく壊れたあたりから「ヘハハヘハ」とかわけのわからない笑いを発していました) 😇

ハード系のハンズオンはやはりコスト感が中々にネックにはなってきますね(これだけで10万近くはかかってますね!アホですね!) 🤑

気づき2

作業スペースの問題が必須 📚

これはそのハンズオンをする場所もそうなのですが、自宅で準備をするための環境もそうです

例えば並べるとこんな感じになります

f:id:lion_man44:20180121160137j:plain

これは中身だけです(写真中は6個ぐらいしか並んでいないですが、机の一角をまさに占有しています。大体広さぐらいにMBPの15インチの作業場所ぐらいでしょうか) 🙄

これに梱包される箱とかそういうのもついてきます

Google AIY Voice Kitの大きさはどれぐらいかと言うと

f:id:lion_man44:20180121160506j:plain

人の顔よりも大きいものが、8つも積もるのです、中々圧巻です 😲

これにさらに

  • HDMIモニタ
  • USBキーボード
  • USBマウス

の要素が必要になってくるので、意外とデスクも簡単に埋まります 😓

かなりハード系の作業は作業スペースの確保が部品スペースの問題にもなってくるので、なるべく広いスペースで作業するようにしましょう 😌

気づき3

public cloud問題

大体登録する時にpublic cloudに登録してもらうのですがクレカ登録が必要になることが多いです 😣

なので、その障壁の高さがあります 

まぁこればっかりは何とも言えないです 🤢

気づき4

先ほどの気づき2と似たような感じになるのですが、これ運ぶ時のキャリーバッグ、 (人数*機材) + 工具 + PC + 他パーツ + 梱包材 という図式になってくるのでかなり大きい容量になっていきます 😨

自分はもう これ を買いました

これでようやく少し余裕のあるような状況でした 🤤

あと持ち運びが死ぬほどしんどいです 😰

気づき5

終わった後の片付け

家に帰ってから気づく、残ったものどうすれば良いかな感 😦

1, 2個程度ならあれなんですが、同人誌とかと同じで全て持ち帰りで在庫状態が豊富になります 😋

まぁラズパイは全然別用途で使えるからあれなんですがVoice Kitの基盤は普通にラズパイとセットしないとダメなので、それをどうするか、ですね 🤔

終わりに

いろいろとハード系のハンズオンは課題感が残ったものの、全体的にやっぱりやってから結果見ないとわかんないな、というところもあり、非常に勉強になりました! 🤗

参加してくださった皆さんもありがとうございました!

IoT kickoff #4 まとめ

「やく見てる」エクステンション作った

クソアプリアドベントカレンダー 13日目の記事です

こんにちは、ライオンです

皆さん、やくみつるはご存知ですか?

ええ、いろいろと炎上したりするコメンテーターですね

自分のリアルを知っている人はご存知だと思うんですが、よく似ているって言われるんですよね

10人中9人ぐらいに似ているって言われるんですよね

そんなに似ているのかなーって2年前ぐらいに実家に帰ったら兄弟に似ているって爆笑されたんですよね

ショックです

そんなわけでchrome extensionを作ることにしました

開発の話に興味ない人用のリンク googleまで戻る









開発の話

最初、imgタグのsrc変えれば余裕でしょって考えてたんですよね

でやってみたら、こんな感じになったわけですね

f:id:lion_man44:20171202195946p:plain

すごいですよね、皆やくみつるですよ

ざまぁみろ

で、ひとしきりゲラゲラ笑い終わって、いやーぁもう仕事終わっちゃったなー

クソアプリすぎるどころか面白さすらないなーとか考えながらおっぱいの画像を探してたんですよね(精神衛生上の健康のためにお医者さんから処方されている)

で、そしたら途中から気づいたんですよ

f:id:lion_man44:20171202232348g:plain

画像が変わってない

でもすぐに気づくんですよね、lazy loadだって

普通の画像ならsrc属性だけで済むけど、data-*属性を使っているならビンゴです

方法までは難読化されたソースコードを読まないといけないので読んでいませんが、クソアプリにそんな時間はかけていられません

で、こうなったらreplaceChildでimgタグを塗り替えてやるしかないですね

で、書き換えて見て見ました

f:id:lion_man44:20171202235047g:plain

クソが

よくよく考えたらインフィニティスクロールに対して、非同期処理してないなんてありえないですよね

こうなったら何が何でも書き換えてやりたくなりますよね

何とか奪えないかと考え始めます

まぁそうするとsetTimeoutかsetIntervalするしかないかなって考えが出て来ますね

非同期でDOMを追加される以上、そこに存在してないのでそれが追加されるまでをwatchするしかなくなりますね(悲しい

(() => {
  'use strict';

  const replaceMemo = {
    src: 'http://www.xn--l8j6cuc0dv605bd1f.jp/yuumeijin/photo/yakumituru.jpg',
    prepare: [],
  };

  const replaceImage = () => {
    const $images = document.querySelectorAll('img');
    replaceMemo.prepare.forEach($el => {
      const $img = document.createElement('img');
      $img.src = replaceMemo.src;
      $el.parentNode.replaceChild($img, $el);
    });
  };

  const onWatch = () => {
    const $images = document.querySelectorAll('img');
    replaceMemo.prepare = Array.from($images).filter($el => $el.src !== replaceMemo.src);
    replaceImage();
  };

  const main = () => {
    setInterval(onWatch, 1000);
  };

  main();
})();

こんな感じのコードになりました

ここまで行くと瞬間的な表示はあるものの確実に変えられますね

しかしまだこれだと直接指定されているstyleなどが反映されていないですよね

cssTextを使ってそのまま持って来ます

f:id:lion_man44:20171203004746p:plain

こんな感じだったのが...














f:id:lion_man44:20171203153804p:plain

こうなります(画像は大槻ひびきさんです)

はーかわいいですね

で、上の画像見た人なら気づいていると思うんですが、左上の画像がとてつもなく邪魔ですよね?

これ開発中にも何度となく邪魔をされて本当に精神を壊しそうになりました

(googleからおっぱい検索をして画像タブをクリックするわけですが、押せないわけですね!)

で、よくよく調べてみると直接widthとheightを指定しているパターンもあるんですよね

$img.height = $el.height; みたいなコードを追加します

f:id:lion_man44:20171203011442p:plain

綺麗に収まりましたね

皆さんの言いたいことはわかります

「大槻ひびきさん見せろよ!!」ですよね?

ですが、もともとアス比の合わないCSSに対して、決まった画像をあてがうので大槻ひびきさんがひどいことになってしまいます

酷い状態になった女優を見たくないですよね?(血涙






さて、この調子で直していって大体変わるわけですね

これは好きなライターさんの小野ほりでいさんの記事です

f:id:lion_man44:20171203012859p:plain

全部やくみつるでカオスですよね

カオス、カオス以外のことばが思いつかない

文字の色がなかったら誰が喋っているかすらわかりません

つまり小野ほりでいさんはこういうことをされることを分かっていて、それでも読みやすい記事を作ってくださっているわけですね!

で、何気なく下までスクロールしていって「あー大体変わっているなー」と思ったら、また変わってないところがあるわけですよ

f:id:lion_man44:20171203013355p:plain

クソがぁ...

何で変わらないんだろうと思ったらcssの中で呼ばれているURLですよね

backgroundで指定するパターンとbackground-imageで指定するパターンの2つですね

直接書き換えても書き換わらずに、 '' を代入するとなぜか空にはなるという現象に見舞われ、今回もimgタグ同様replaceChildを使う強行手段に出ました

  const replaceImage = (images, aTags, divs) => {
    images.forEach($el => {
      const $img = document.createElement('img');
      $img.className = $el.className;
      $img.style.cssText = $el.style.cssText;
      $img.height = $el.height;
      $img.width = $el.width;
      $img.src = replaceMemo.src;
      $el.parentNode.replaceChild($img, $el);
    });
    aTags.bk.forEach($a => {
      const $newA = document.createElement('a');
      $a.style.background = '';
      $newA.style.cssText = $a.style.cssText;
      $newA.style.background = `url("${replaceMemo.src}")`;
      $a.parentNode.replaceChild($newA, $a);
    });
    aTags.bki.forEach($a => {
      const $newA = document.createElement('a');
      $a.style.backgroundImage = '';
      $newA.style.cssText = $a.style.cssText;
      $newA.style.backgroundImage = `url("${replaceMemo.src}")`;
      $a.parentNode.replaceChild($newA, $a);
    });
    divs.bk.forEach($div => {
      const $newDiv = document.createElement('div');
      $div.style.background = '';
      $newDiv.style.cssText = $div.style.cssText;
      $newDiv.style.background = `url("${replaceMemo.src}")`;
      $div.parentNode.replaceChild($newDiv, $div);
    });
    divs.bki.forEach($div => {
      const $newDiv = document.createElement('div');
      $div.style.backgroundImage = '';
      $newDiv.style.cssText = $div.style.cssText;
      $newDiv.style.backgroundImage = `url("${replaceMemo.src}")`;
      $div.parentNode.replaceChild($newDiv, $div);
    });
  };

  const includeBKUrl = ($el) => {
    return $el.style.background.includes('url');
  };
  const includeBKIUrl = ($el) => {
    return $el.style.backgroundImage.includes('url');
  };

  const onWatch = () => {
    const $images = document.querySelectorAll('img');
    const $aTags = document.querySelectorAll('a');
    const $divs = document.querySelectorAll('div');
    const images = Array.from($images).filter($el => $el.src !== replaceMemo.src);
    const backgroundForATags = Array.from($aTags).filter($a => includeBKUrl($a));
    const backgroundImageForATags = Array.from($aTags).filter($a => includeBKIUrl($a));
    const backgroundForDivs = Array.from($divs).filter($div => includeBKUrl($div));
    const backgroundImageForDivs = Array.from($divs).filter($div => includeBKIUrl($div));
    replaceImage(images, { bk: backgroundForATags, bki: backgroundImageForATags }, { bk: backgroundForDivs, bki: backgroundImageForDivs });
  };

  const main = () => {
    setInterval(onWatch, 1000);
  };

  main();

汚い匂いを放ち始めてワクワクしてきましたね!

ですがそのスペルマコードによって、ようやく姿を変えるわけです

f:id:lion_man44:20171203025719p:plain

Amazing!


しかしここまでやってもまだまだ残っている画像やurl cssが残っているわけですね

必殺の技としては onLoad で直す、というのもあるわけですが、効かなかったです

iframeの中にあるimgタグがconsole上で document.querySelectorAll('img') を出力すると取れるのですが、cotent_script内で動いている document.querySelectorAll('img') からは取れず、ここら辺はセキュリティの問題なんですかね?

なので不十分に残ります

次にやっぱり、同じ画像が出てくるのはあんまり楽しくないですよね

で、何か画像検索できるようなやつがいいなーと思ってやっぱりgoogle様のお力を借りたいですよね

Googleの画像検索APIを使って画像を大量に収集する

を見ていたのですが、「やってられるか!」となりましたね

それはもうすごい勢いで

で、考えた結果webスクレイピングすりゃいいんじゃねってなりますよね

クッソ悩みました

もはや禿げていく人の焦燥感並に悩みました

backgroundで実行するEvent Pageで設定した非同期実行処理がContent Scripts内でどうやってタイミングよく受け取れるのか分からず本当に悩みまくりました

そしたら蛇足に書いてある部分があったことによって助かりました

qiita.com

涙しそうになりますよね、こういう時

嬉しかったのでお昼ご飯はキムチ鍋にしました

background.jsにはこんな感じで用意

const parser = new DOMParser();

const onMessage = (request, sender, callback) => {
  const xhr = new XMLHttpRequest();
  const url = `https://www.google.co.jp/search?q=${encodeURI(request.query)}&num=100&safe=off&tbm=isch&source=lnms&sa=X&ved=0ahUKEwiR0sro4-zXAhVKmZQKHaJYDdEQ_AUICygC&biw=1920&bih=983&dpr=1`;
  xhr.onload = () => {
    const doc = parser.parseFromString(xhr.responseText, 'text/html');
    const divs = Array.from(doc.querySelectorAll('.rg_meta'));
    const images = divs.map(div => JSON.parse(div.innerText).ou);
    callback(images);
  };
  xhr.open('GET', url, true);
  xhr.send();
  return true;  // これがchrome extensionが非同期かどうかを判断するライン
};

chrome.extension.onMessage.addListener(onMessage);

そして表側のcontentscripts.jsにこんな感じのコードを埋め込みます

  const regex = {
    base64: /^data:/,
  };

  const onResponse = (yakulist) => {
    choiceYakuMitsuru(yakulist);
  };

  const choiceYakuMitsuru = (yakulist) => {
    const random = Math.floor(Math.random() * 101);
    const url = yakulist[random];
    if (regex.base64.test(url)) {
      choiceYakuMitsuru(yakulist);
    } else {
      replaceMemo.src = yakulist[random];
    }
  };

  chrome.extension.sendMessage({ query: 'やくみつる' }, onResponse);

これでアクセスするたびにやくみつるが変わりますね

f:id:lion_man44:20171203151705g:plain

やくみつるじゃない知らないおっさんが見てますね

調べたら野球評論家だそうで、別のコメンテーターでした

さて、一通りのchrome extensionが作れたので満足しました

webstoreに登録しようかなとも思ったんですが、クソアプリに$5はちょっと冒険が過ぎるな、と思い、やめることにしました

代わりにGitHubには置いておこうと思います

github.com

これをcloneしてきて、chromeのエクステンションに開発中のやつ食わせるだけです

簡単でしょ?




余談1:

中高生、果てはおっさんにまで有名になってしまった動画サイトを見てみたら 全てがやくみつる になったので面白かったです

f:id:lion_man44:20171213005154p:plain

共用パソコンとか使っててクソガキにエロサイト見るのはまだ早いって思うお子さんをお持ちの方は導入して見ると良いんじゃ無いでしょうか

余談2:

これすごいのが、えっちな感じのやつ入れるとど迫力な感じになってめっちゃ面白かったです

普段意識しないで見てる部分とかが違和感になって映るので、女性器やらおっぱいやらが更に強調されて見えます

あとデバッグしてて、やくみつるずっと見てるのも精神的にきついのでAV女優にしてデバッグするのは良いんですが、そのまま閉じてカフェ行かない方が良いです

嫌な汗をかきます


次のクソアプリアドベントカレンダー 14日目は @tokeikun さんです

Webエンジニアです、少し時間が空くので相談乗ります

こんにちは、ライオンです

フリーランスで専属契約していたところを満了を迎えることにしました

理由はリリースを迎えたので、一旦区切りにしたいなーというところです

やったこと

明確な肩書きは持ってなかったですが、フロントエンドのリーダ職のように振舞ってきました(現場の人からは邪魔だったかもしれないですが)

タスク的にはフロント側のアーキテクトの選定、フロント設計、ユーザ側/管理側のデザインのテイストの微調整や仕様決め、他業務委託メンバーのリソースの再分配やタスク割り振りやアド側の方と連携してタグマネージャ管理やアナリティクス計測などなど...

過去から遡れば当時部長だった人と評価制度を作ったり、面談フローを整えたり、人事周りなどに手を入れたりなどもしました

いろいろと経験させてもらったのがホント良かったなーと思いつつ、まだまだスキル不足や体系的な説明がうまくないので、人の説得ということに本当にぶち当たることが多かったように思います

経験

管理画面はVue.js、ユーザサイトはVanilla.js

Vue.jsはハマる時はハマりますが、すんなりといけることの方が多いので学習コストの低さとプロダクトへの取り込みやすさとデザイナーさんとの連携もすごくしやすいので好きです

ただコンポーネント粒度を考えるのには本当に何度もハマりました

いまだに適切な答えが見つかりませんし、アトミックデザインが最適だとも最初は思っていたのですが結局デザイナー作業をする人に浸透していないと意味がないものですし、自分からしてもコンポーネントが増えすぎて管理コストが増えてこれはどこから流し込むんだっけと考えることが多くなり、アトミックデザインの採用は見送り、ブロック単位でのそのプロジェクトでしか活用できない粒度で切ったりしました

しかしそれも捨てられることを優先した結果です

ここで見えてきた結論は捨てやすいこと、そして親と子と孫ぐらいまでのコンポーネントの合成粒度にしておかないと自分では把握できないなーということです(どこかで見たのですが、人間が把握できるクラスは2先祖ぐらいまでだ、っていうのを頑なに信じています)

ただ、自分はその結論にしか至れませんでしたが、他のメンバからはDIコンテナにして流し込む形にした方が良いのでは、とも頂いてまた違ったVueの設計が見れそうでとっても面白そうです

それの完成形を見れないのが残念ですが...

その他にもGoでサーバサイドを書いているのでview helperとかぐらいなら書けるようになったのは楽しいです

癖があって、Timeを弄る時には「え」ってなったりしたのも良い思い出です

あとはElixirも少しだけ書けるようにもなりましたし、Rustも少しだけ書けるようになりました

Rustはもっと使いこなしたいですし、フロントエンドでもEmscriptenを使わずにコンパイルできるようになったらしいので、画像系の計算処理はどんどんとそっちに移行するかもしれませんね

ですが、この間Qiitaで見たのではまだまだwasmが早い、とはならないっぽいのが辛いところですね

qiita.com

個人的にはwasmからdocument.createElementとかdocument.querySelectorができたらもう何も言うことはないんですがね

今回GCPを触れたのも楽しかった一つです

GCP自体全く触ったことがなかったのでgsutilやgcloudが少しでも触れたのは楽しかったなーと

それと社内で業務委託の子がgoland使っていたので、自分も使い始めました

効果としては自分はvimでgoを書いていて こちら を使っていたのですが、定義元の定義元にジャンプができず、困っていました

golandだと定義元の定義元もそうですが、インスタンスからでも元ファイルを辿っていけるので、単純にすごいなと思っていました

それとpostgresqlのslackで質問した時にそーだいさんが「datagrip(有償)便利ですよ。」って言っていたので使い始めましたがこちらはまだまだ道具に使われている感じが否めません

早く使いこなしたい

あと情報系の院に行っているような若い子たちと仕事すると新しい世界が見えるので単純に面白いし、技術の伸び幅が全然違うので本当に理解力が違うし、すごい刺激になる

頭が下がるし、レビューしてボコってくれたのも良い経験だし、そっと出してくれたコードの方が遥かに分かりやすかったりで、目から鱗でした

どうしても書いていると視野が狭くなる、というかなるべくスコープが小さく終わらせようとするか、大体的に変えてあんまり良くない方法で実装しようとしてしまうのでもうちょっと考え方を柔軟に持たないとこの先厳しいなと自分自身感じたのでこの辺は宿題ですね

次したいこと(もともと考えてたこと)

次はいろいろとやりたいことがあって、いくつか書いてみると...(ずっと昔から考えてたこともあります)

  • またサーバサイドの方も、というか一貫して作るフローに戻りたいですね
    • それなりに高いユーザ体験、みたいなのを考えるとフロントエンド側から作ることをしないとダメかなーと思っています
    • もちろんここら辺はプロジェクトによってはサーバサイドとの連携が密なところは全然問題ないと思います
  • プロダクトオーナーもやりたいですね
    • ビジネスセンス無いんですけど、必死に考えられるのもこの歳ぐらいまでだと思っててもう3年もすると多分「ご飯、うんこ、ちんぽ、おっぱい、にゃーん、くぅーん、がおー」とか単純な言葉しか発せられるなくなるような気がするので経験しておきたい
  • フリーランス同士でタッグ組んで、プロダクト作ってみたい
    • これはもう少数精鋭に憧れがある状態なんですよね
    • esaとかすごい「あれあれ!あれなんですよ!」みたいな自分の理想形
    • とにかくもう「8h/1day 週5」みたいな感じの日本奥ゆかしい働き方をやめたい
      • 1日は24時間でその1/3を捧げたくないし、みんなにも捧げて欲しくない
      • 8hもあるけどその内集中してできる時間なんて2, 3hが限界なのはもう分かり切ってるから働く時間を4hにしたい。もちろんフローの状態が長く続くのであればそれは時間を使っても構わない(毎日8時間は全然割に合わないけど、ノッてる時は逆に時間に邪魔して欲しくない)
    • 1社と専属契約する世界観を終わりにしたい
      • 1社勤めが長いとやはりその世界観でずっと続く
      • その会社だと強いかもしれないけど、世界に出ると全然強くないことなんてザラだし、ガラパゴス化が確実に進行する。それは病のように
  • Webに向いていない人と働くのはしんどいのでなるべく波長の合う人と働きたい
    • 自分の作業を標準化する、という事に関心を持ち、品質担保に他の人の作業内容にまで責任を持ち、前行程と後行程の人のことを考え、些細なことでも情報を共有し、物を売り切り型で売らない、というような気概溢れるチームで働きたいと考えています
  • 倫理観を持っている人と働きたい
    • 自分も高いわけじゃないけど、民度が低すぎた(共有ごみ箱に直接唾を吐くのや、椅子の座る部分に載せてある自分のコートを踏んづけて座る、などなど)
  • 意識高い系でいくわけじゃないけど、ユーザファーストであるような現場で働きたい
    • 勘違いして欲しくないが全てをユーザに捧げるわけではない
    • ユーザは神様ではない、ユーザである

まとめ

ここに書いたことが全てではないですが、もっと次は人生が楽しくなるようにお金を稼いでいきたいと思っています

ちなみにしばらくはお休みしようかと思っていて、その間にいろいろな相談事を受けようかと思っています

お仕事のお話は自分を知っている人だったら知っている方法で、それか lion44man at gmail.com まで

大量のメールが毎日来るため、見落とす可能性もありますが、ご返信が無かった場合はご縁がなかったということでお願いします

Webに向いてない人

自分はWebで働いてから、5〜6年ぐらいになるペーペーだが、働いているうちにWebに向いていない人いるなーと思ってそれが何で向いてないんだろうとモヤモヤし続けた

で、何でモヤるんだろうなーと考えてたら一つの答えを得た

Webとは一つの課題に対する標準化/簡略化を目指すシステムをhttp/httpsなどのネットワークで提供しているものだと思っている

なので、標準化と言えばその課題に対してAという解決方法を提示し、その流れに乗せたり

もともと煩雑だったり紙だったりした作業自体をWeb上でデータ入力してポチッとするまでを提供したりする

それが自分の中でのWebだ

もし仮に「それだけじゃねっすよ」と言われようと、本質そのものはこれである

自分はソシャゲを作ったことはあるが、ソシャゲ自体もよくあるシステムはカードゲームシステムでC社やD社が作ってきたゲームなんかまさにそんなようなものだ

標準化されたワークフローを作り、その中で簡略化された娯楽体験というユーザ体験を提供する
(それを1プロジェクトの中で毎度毎度ワークフローを作り続けるので辛いことにはなるが…)

なので、基本はそのワークフローに乗っかったらそれを壊すようなことはしない

単純にワークフローを変えることはすごいコストがかかることなので、一度整ったワークフローにルールを追加していく、というのはよくやるがもう一度壊して作り直すというようなことはしない

Webエンジニアやっている以上は何度でも壊す、ということは大事なのだがやはり一度作ったものを変える、というのはしんどいし、メリットが30%以上上回らければやりたいとは思わないだろう

で、話を戻すが、
結局向いてない、というのはこの標準化/簡略化の流れに乗ろうとしない、というか乗れない人なんだな、と思った

  • 例えば、ソシャゲとしてカードゲームシステムを提供しているところが、これに「RPGを組み込めると面白いと思うんですよねー」っていう人
    • それが面白いかどうかはクオリティによるし、「この運営バカだろwwww(褒め言葉)」みたいなのを浴びたい承認欲求モンスターが一定数以上いる
  • ある一定のパターン(その人の中なので他者には分からない)でそもそものそこの部品を根底から覆すような、UIを提供したがるような人
    • コンテンツ作りしかやってない人やマーケッター、ディレクターに非常に多い(もちろん根底から変えなければいけないケースはあるが、その場合は全体を変えないといけない場合であり、一部のUIパーツを変えたことによっていやー段違いですよ、なんてことはまぁほぼほぼない、ラッキーパンチぐらいはあるだろうね)

コンテンツをコード毎変えにいくんだ!って会社なら知らんが、少なくとも自分はその手の人と仕事をするとよく分からないことで労力を割かないといけないので無駄だなーと思う

ちなみに簡略化の話すると、「じゃあ自分の考えていることを全部読み取って勝手に仕事こなしてくださいよ」とか思う人がいるらしいが正直そういうのは相手にしないし、
標準化の話をすると、「じゃああのシステムのこの部分とか、自分がいつも使っているやつとUIが違って使いづらいので直してください」とか分かることは分かるんだけどそれが最適だと思ってないし、他のメンバーに聞いても使いづらいと思われていないものを 自分の中で使いづらいから直して欲しい と思う人がいるんだなってのは自分の中でWebに向いてない人だなーと思っている

なんかここら辺ってWebエンジニア、Webデザイナーやっている人たちは皆遭遇したことあると思うんだけど、どう折り合いつけているんだろう?

感覚のままにしておきたい性質と言葉にしたい性質

早くあったかくなって欲しい、ライオンです

日本語不自由な感じで書いていくので、あんまりお気にせず

エンジニアをやっていて思うのは「感覚」で感じたままにしておきたい人と「言葉」にしたい人の両方がいると思います

この時の「感覚」っていうのは自分のしている事や何かを見た時の感じ方を言語化するのが苦手な奴ですね

「言葉」というのは逆に得意です

この2種類の分け方は恣意的な分け方なので、この時点で「うっこの分け方は酷い」と思った人はブラウザバック推奨だ

感覚で感じたままにしておきたい人

  • 「直感」で感じることが多い(しかしそれらは知識と経験に裏付けされたものであることが多い)
  • とにかく言語化することより直感的に感じた気持ちの方を大事にする
  • 気持ちなどを分解して言語化して、人に伝えるのが苦手
  • 共感ベースだったりするので、言葉が不要な人同士ではフィーリングが合う
  • 何か新しいことを始める場合でも「外観」から入り、「仕組み」の方には興味が無い

言葉にしたい人

  • とにかく「気持ち」や無形なものを言語化しようとするため、言語のチャンネル(IQレベル)が合ってないと会話が合わないことが多い
  • こういうブログを書いてしまう
  • 自分のやっていることの証拠を残したがる
  • 何か新しいことを始める場合は「外観」から入っても、「仕組み」の方に興味がすぐ向いてしまい、言語化して理解しようとする

で、最近思ったのはデザイナさんにもこれ当てはまる人いるんじゃねーかなと思った次第です

どっちが良いとか、どっちが悪いとか、そういう話をするわけではなく、マッチングさせようとした時にこれらは非常に重要なのでは無いかと思った次第です

例えば「感覚」の人から「言葉」の人を評価した時に「無粋」「野暮」「理知的」「賢い」「すごい」などの評価をしたり

「言葉」の人から「感覚」の人を評価した時に「頭が悪い」「言語野が発達していない」「落ち着く」「言葉ではなくフィーリングが重要」「あいつはきっと馬鹿のふりをしている」などの評価をしたりする

しかし、ここまで書いておいてなんだが「言葉にしたい」部分と「感覚で感じたままにしておきたい」部分などが自分にはあったりする

例えば「人が一体何に興味を示したりするのか」とか「人の気持ち」などの部分はなるべく言語化しておきたい部分である

だけど「人の生理的嫌悪感を示すものや嫌悪感の強いもの」や「倫理的に許されない行為に快楽を見出す」などの部分は言語化したく無い部分でもある

なので何もかも「言語化したい」わけではないし、これは「人」という括りではなく、「性質」の括りなのかもしれないと思う(だから一部だけ「感覚」で一部だけ「言語化」という人の方が一般的なんじゃ無いのかな、と)

そう思うのもできるだけ言語化しておければ良いな、程度なのだ

何故そこにこだわるのか、少し考えてみると20未満の成人前の人が言語化できないでも「まぁわかる」とはなるが、社会人5年も過ぎた人が「感覚」だけで物事を進めていると単純にヒヤヒヤするのである(自分も言語化しようと思うようになったのはエンジニアをちゃんとやり始めてからだと思うので30過ぎてからだと思う)

「行動原理の言語化」ができていない、ということは一体何に刺さるのか分からないし、「何を」モチベーションに動いているか分からないので、ふとした段階で離反するし、普段何をやっているのかが分からない、ということになると思う

普段何をやっているか全てを把握してもらう必要なんて無いのだが、ある程度「あの人はああいう人だ」というキャラクターは社会を生きる上での鉄則だ

他人からの自分を見た時の分かりやすさは生きやすさに直結するとは思っている(自分はそうできてないので苦しんでいるのだが)

だから言語化できる、ということは、暗黙知ではなくノウハウを共有できる、ということだ

人間という不確かで、行動原理もよく分からない、気持ち悪いモノのノウハウ(取扱説明書)を共有できる、ということは自分のためではなく、相手のためであったりするんじゃないかなーと書いている最中に思った

IoT Kickoffの第1回目を開催しました!

もう春ですね、木々が何かを実らせているのに対してプライベートは何も実らせていないライオンです ぐすん

さて、自分とせいごさんで企画したIoT Kickoff #1を開催してきました!

もともと企画としてはエンジニアだけじゃない、いろんな人たちが集まれば良いなぁと思っていたのですが、一応いろいろな人がきてくれましたw

9割がたがエンジニアバックグラウンドにあったので非常に話しやすく、また理解してもらいやすかったので大変楽だったのですが次回以降も純初心者の方が課題かなーと個人的には感じています

ずっとせいごさんも自分も喋りっぱなしだったので、ほぼほぼ写真やらツイートとかそこらへんが残っていないのですが、とりあえずこんな感じで始まりました

人数自体はこれぐらいの規模で喋れたのは非常に良かったです

それぞれのテーブルに分かれて、それぞれの課題がある方たちと意見交換したり、いろいろ触ったり、触れてもらったりしながら、やっている最中です

その中で面白かったりしたのは「トイレのON/OFFとかをWebから確認できるようにしたい」といったような課題を持っている人のサポートを行ったりなど(途中で投げ出してしまったのすみません!)、「どこからIoTを学んでいくのか」といったような勉強方法など、いろいろな話ができたのは非常に面白かったです!!

IoTをやる上で本当に必要なのはいろいろなものを知っていることだな、と改めて実感できた日でもありました

というのはいろいろな方法でできるからこそ、どれだけ自分にとって必要のなさそうなところを省略できるかが勝負だな、と思いました

例えば自分にとって言えば回路設計などをやるのは別の人にお任せして、ソフトウェアの部分で携わりたいなという気持ちがあります(オームの法則とか計算するの面倒くさいという気持ちはありますw)

しかし、オーバーラップすることで自分の仕事が将来的に楽になる場合、新しい発想というのもあるかと思っていますので、そこは勉強を続けていく必要もあるなと思っています

最終的にいろいろ便利なものを教えてもらったり、省略できるところを省略することで本来のサービス(提供したいもの)に集中出来る、ということが知れたので最高な1日だったな、という感想です

次回は5月以降で考えていますので、いろいろな方のご参加をお待ちしています :bow:

追記(2017/3/22):

www.1ft-seabass.jp

せいごさんも書いてくれました! ぜひぜひ、ご一読あれ!

メンヘラ女の能力というより性質の話

なぜ「恋愛メンヘラ女」は男性を虜にするのか?その4つの能力 - Menjoy! メンジョイ

Twitterで流れていたので、ちょっと気になり見てみましたが、一部あってるんだけど違う、と思ったので筆をとりました

ちなみに何故、この手の話が気になるのかと言うと俺も付き合う女性のほとんどはメンヘラ女ばかりだったからです

俺の思い出を語れる中で最高にクソッタレだったのが夜中4時ぐらいに「淀川まで私を探しに来て」というメールをもらったことです
(その後結婚したらしいが、当時の状況を知る知人たちの中では彼女のあだ名が「うさぎちゃん」になっています)

1「隙がある」

これは見出しだけ見れば「確かに」、なのですが「隙」の定義が「悩み」になっています

「悩み」は人間であれば誰しも持っているものです

恋愛メンヘラ女には、常に何かしらの“悩み”があります。その悩みの相談に乗るていで、自然な流れでお茶や食事に簡単に誘うことができるのです。

そうではなくて、「悩みを外に匂わせており、かつ距離感の取り方が近い」のが「隙」です
(悩みを相談してくれたり、悩みを持っているような顔を見せたり、距離感の取り方が近く、不意に男性が張っているテリトリー内にスイッと入ってきたりする)

決して「恋愛メンヘラ女」というカテゴライズではなく、「誰しも」「悩み」はあります

そして男性は「問題解決思考」です

その「悩みを解決したら、ご褒美が何かあるかも」と考えるのは狩猟時代から続く脳みその思考です

f:id:lion_man44:20170212105820j:plain

別に「悩みを解決しても、見返りなんてなくてもいい」なんていう、聖人君子のようなそれはもう神々しい男性がいたりしますが、それは某ゲームで言うような「エミヤ思考」(自己犠牲の精神)と呼ばれているものであり、非常に気持ち悪いと個人的には考えます

俺は問題を解決をしたら、見返りが欲しいですし、それがメリハリ、または対価、というものです

2 「影の部分を知りたくなる」

これもまぁ見出しだけ見れば「確かに」って感じになるのですが…

メンヘラ女に共通しているのが「幸薄そう」、「目がトロンとしている、ないしは斜に構えてみている」です

総じて「自分より若いな」「自分より幼いな」「自分より弱そうだな」「自分になびきそうだな」、という優越感が男性には無意識下にあるのです

で、それらをグルングルンに盛大にラッピングして…それはもう自分が 何をラップしていたか 気づかなくなるぐらいにグルングルンにして「かわいい」と表現するのです

で、さらに最悪なのが それを好きと自分自身で誤解してしまうのです

でもこれって、女の能力って言うより男のダメなところであって、能力では無いと思うんですよね

つまり「隙がある」で説明した距離感の取り方が近い、というのがこの項目に該当することです

3「父性本能を掻き立てる」

もはやこれらは何を言いたいのかわからず、女性の能力では無いだろ…
(守ってやらないといけなくなるような会話術を持っているということだろうか?)

男性は「俺がいなくちゃこいつはダメなんだ!」という女性が、なんだかんだ言っても大好きなんです。

守ってやらなくちゃ!っていう精神は「重要文化財保護の精神」です

自立している女性が好きという男性もいますが、そんな女性は結局「俺がいなくてもお前はやっていけるから……」と理由をつけてフラれるパターンがあります。

これは確かに見た

付き合ったのなら「俺がいなくちゃこいつはダメなんだな!」と思わせるくらい依存しちゃって全然オッケー! 逆に男性の父性本能が働いて相手を放したくなくなります。というより手放せなくなるのです。

いつから「メンヘラ女の能力」から「女性が男性をメンヘラチックに落とす方法」に変わっているんですかね?

4「忘れられない」

もはやこれも…

彼女と別れても、その彼女が恋愛メンヘラであったならば、男性はなかなか忘れることができなくなるといいます。

だからこれは「メンヘラ」に限った話じゃねぇ

いつまでたっても忘れられない女性に男性は別れた後でもつい連絡を取りたくなるもの。それから復縁なんてことも珍しくありません。恋愛メンヘラ女は過去の男までも虜にさせるのです。“恋愛メンヘラ”を甘くみてはいけません!

Oh… これは別に女が問題じゃなくて男のほうがメンヘラなだけだろ

まとめ

最初に筆をとった理由は書きましたが、書いている内に改めて記事の質自体が酷いと思ってしまいました

この著者の方が書いているのは能力ではなく、性質です

批判していてばっかりも何なので、個人的に思うメンヘラ女の能力というより性質を自分も書いてみました

  1. 悩みを外に匂わせている
  2. 距離感が近い
  3. 幸薄そう
  4. 目がトロンとしている、ないしは斜に構えている
  5. 服の上からわかるぐらいには「頬」「耳」「首」「胸」「腕」「背中」「腹」「腰」「尻」「太もも」「ふくらはぎ」「足首」のどれかが「だらしない」感じになっている
     (ここでいう「だらしない」というのは「太っている」という意味ではなく、男性目線で「触ってみたい」「揉んでみたい」「舐めてみたい」「噛んでみたい」という扇情的な「形」をしているということです)

現場からは以上です