筋肉はオートスケールのか?について

  • 筋肉に負荷をかけると組織が破壊されたのち肥大化することが知られている
  • オートスケールと呼ばれる仕組みがある
    • 一定の負荷がかかるとシステムが動的に拡大し,システムが耐えられる負荷を大きくすることで,過負荷により不安定な状況に陥らないようにする仕組み
  • 筋肉はオートスケールしているのか?
    • オートスケールといった場合、スケールアウトによって処理能力を増加させることが多い
      • 同じ仕事をする人をたくさん雇うみたいな感じ
    • 筋肉はそういう増え方をしない
      • 上腕二頭筋が3つあるみたいなことは普通ない
      • すでにある筋肉が強くなる
        • このような「シンプルに強くする」作戦をスケールアップと呼ぶ
          • 仕事の例なら10人分の仕事ができる人間をどっかで見つけて雇ってくるみたいな感じ
            • 例えばデスクが一個しか置けないとか,人数がいっぱいいると情報共有だけで一仕事になってしまうタイプの仕事はこっちの方が有効見たいなことです
      • 筋繊維に注目するとスケールアウトと言えるのではないか
        • 筋肉は筋繊維が束になってできている
        • 筋繊維が一部壊れても全体としては正常に機能し続ける
          • これ Datacenter as a computer でみたやつだ!

福岡

太宰府行ってから糸島行った


https://www.instagram.com/p/BWBtCMoBa1Z9eiZ1axPIxxWTmGRaHzomzt1Oc00/
リゾートじゃん


糸島,ガイドブックだと海が綺麗な写真がいっぱいあったけど、こんな南の島みたいな景色ないでしょって気持ちで言ったらめちゃくちゃ綺麗でびっくりした

Slackについて

気持ち

  • 個人メッセージはなるべく使いたくない
    • 秘密に必要のないものまで見えなくすると、共有漏れや追加の共有などが必要になりコミュニケーション効率が悪化してしまう
    • 知りたいと思った人が自分で情報に到達できる状況を保っていきたい

なんか発言しにくい! と思う瞬間

  • 別の話題について話している
    • しかし私は別件の相談がしたい
  • デザイナーの人に相談したいがデザイナーチャンネルみたいなところに書き込むのに心理的障害がある
    • 居心地の悪さ(?)
      • 他の人の家に上がり込んでるみたいな?
    • 個人の感覚によるところが大きそう

状況

  • チャネルは組織単位の物が多い
  • 一部、ソースコードリポジトリと対応するような単位のものがある
    • iOSチャンネルに iOS エンジニアと担当のデザイナがいるみたいな感じ

コンテクストに応じてチャンネルをばかすか作ってガンガンアーカイブしていく運用はどうか?

  • 急にそういう雰囲気にするのは難しそう
  • 課題感を共有してじわじわやっていく?
  • 一定期間発言がなければアーカイブを提案する仕組みが欲しい
    • 可能なら Slack App のような形でボタン一発でアーカイブしたい
  • チャンネル新規に作ったことが通知されない問題
    • 最近はたまに Slack bot が「このチャンネル参加しない?」 とか「このチャンネルもう使ってなくない?」 みたいなの言ってくれるけど、それで十分かと言われると、もっと即時性が欲しい気がする
  • チャンネル作るのめんどくさい、みたいな気もする




と言ったことをぼんやり考えていたのですが、みなさんはどう思われますでしょうか?
ちなみに私自身としましては、最近異動がありましてかなり人数の少ない部署へ移動したこともあり、この辺の悩みはないです。が、過去の経験や他の人から聞く悩みなどから、どうするのがいいんだろうな〜と気になった次第。



ご意見




sureddo 可愛い


Slackについて - インターネット海

JIRAチケIDでばかすかチャンネル作ってガンガンアーカイブをする運用しています。よく消し忘れる。基本エピックのだけでバグとかのチケットでは作らない。

2017/06/16 09:27
b.hatena.ne.jp

良さそう

美女と野獣みた

見てきた。

www.disney.co.jp

子供の頃、姉が好きだったのだと思うのだけれど、家でよく見ていた、というか、流れていた。ので、大きな流れとかここそこのカットは覚えていたのだけれど、あれ、この後どうなるんだっけ、次のシーンはわかるけど繋がりがわからない、、、みたいなところははちょくちょくあって、そういう点の記憶が線になって繋がるのは面白かった。というかそもそも、アニメのシーンだとこれだよな、みたいなのがわかるのがすごい。アニメ版のテイストがきっちり生かされていたのだと思う。

ガストンに結婚を迫られたベルが歌いながら丘の上へかけていくシーンが好きだったのだけれど、映画版でもきっちり表現されていてよかった。後CGがすごい。このシーンもめっちゃよかった。

最近は映画を見るとその作品に携わったエンジニアリングスタッフのことを思って二重に感動してしまう。モデリングモーションキャプチャVFXパイプラインエンジニア*1たちよ.....

ところで見てる途中にディズニーが本格的にCGを使い始めた初期の作品が(アニメ)の美女と野獣だったのを思い出した。後半のボールルームでのダンスシーンで、全体を俯瞰したところからぐるっと回り込むところの背景がそうだった気がする(気がする)。

そういう作品が2017年の技術で改めて見られるのは本当に嬉しいことだなあと思ったりしてた。

*1:パイプラインエンジニア、名前は聞くけどどんな仕事してるかよくわかってない、教えて欲しい

恋は光

読んだ。一巻完結系のやつだと思って間違って6巻を予約で買ってしまい,返品するか~と思っていたのだけれど,一巻がポイントでほぼ全額帰ってくるアレで買えたので試しに読んだらピンと来て2巻買って気がついたら6巻まで普通に読んでしまった.

途中で気づいたんですけど煩悩寺の人だった,なるほど,と言う感じ(煩悩寺も大変良い漫画です)

もちろん6巻を買った時は気がつかなかったんですけど,2巻の表紙だと光ってない北代さんが6巻だと光ってるんですよね.これが意味するところとは!? (読みましょう) (次の7巻が最終巻らしいので安心して買いましょう)

プレゼンツール作ってる 2

f:id:side_tana:20170514223627j:plain

変な角度なのは机の上が散らばってるからです。これでもなんか映り込んでるので、画面外はお察しという感じ。

異なるWindow間のデータの同期みたいなのがどうしてもテーマになってしまっていて,今は知見もないのでとにかく愚直にやっている.具体的には

ウィンドウ間で共有が必要なデータはメインプロセスで管理し,

  • メインプロセス
    • REQUEST_<何かしらのリソースの名前> イベントを受け, 現在のリソースを SYNC_<何かしらのリソースの名前> イベントで送り返す
  • ブラウザウィンドウ
    • ipcRenderer.on('SYNC_<何かしらのリソースの名前>') みたいな感じでデータを受ける準備をし
    • ipcRenderer.send('REQUEST_<何かしらのリソースの名前>') みたいなのを送る

みたいな感じ.実際にはこのウィンドウとこのウィンドウでは共有したいけど,別のウィンドウでは共有したくない,みたいな状況があるので (複数のドキュメントを開いている時にウィンドウ間でドキュメントの内容は共有したらはちゃめちゃになる,みたいなことです),もうちょっと丁寧にやっているのだけれど,丁寧というか複雑な感じで険しい.

ゴールデンウィーク中に redux middleware でガバっとやろうと取り組んでいて,値を外に送り出すところは簡単に出来たのだけれど,action をどこで発行するかで悩んでしまい進まなくなったので, 結局 redux ごと剥がしてしまって, componentDidMount で ipc 待ち受けて setState すればいっか,みたいな気持ちになって素朴な構造を積み上げまくる,みたいな方針になった.

プレゼンツール作ってる

r7kamuraさんの日記見て,おもしろそう〜という気持ちになったので,今月の16日からプレゼンツール作り始めた.

f:id:side_tana:20170424084218p:plain

f:id:side_tana:20170424084253p:plain

レイアウトの部分結構難産で,先週の前半は仕事以外の時間ほぼレイアウトの仕様を考えていて,後半は体調悪くて帰宅後寝込みがちだったのだけれど,寝込みつつレイアウト定義ファイルの仕様とか考えてた.土曜は調子が良かったので,それらを一気に実装に落とし込んだ.

プレゼンモードとプレゼンタービュー作ったら使えるレベルまで到達しそう


趣味プロダクト,自分は三日以上かかるものを完成まで持って行けたことがないので,如何に継続させるか,みたいな課題感がある*1.今回は GitHub Projects を積極的に使っている.

f:id:side_tana:20170424085049p:plain

こういう感じで, todo, wip, done のカラムを用意して,wip が空の状態で作業を中断しない,というのを心がけている.こうすると,次にやるぞ,となったときに「何をやるんだっけ?」見たいに悩まなくて済む.

あと,作業してると別の子としたくなることがあって,たとえばエディタ部の部分作ってるのに,急にファイルの入出力まわりをやりたくなる,みたいなことがあるのだけれど,そういうことをするとワケわかんなくなるので,今やってること以外のことがしたくなったら取りあえず todo に積んでおく,みたいなことをしている.

前は issue でやってたけど, issue でやると他のタスクとの粒度が違ったりしてつらくなりがち(個人の感想です).

プレゼンテーションモード,とくにプレゼンタービューをつくろうと思うと,異なるウィンドウ間で状態を共有したくなるので難しい,今週はちまちまそういうのやるんだと思う.

*1:と思ってたけど前作ったやつはちゃんと2週間ぐらい掛けてリリースまでしてた