Python で from import を reload する。
※ このエントリは Maya Python Advent Calendar 2017 - Qiita の 3 日目です。
※ エントリ中に挙がってるコードの改善版は こちら
Maya-Python といえば reload ですね。
reload といえば from import ですね。
つらいのでなんとかします。
- 前置き
- そもそもなんで reload するのか？
- なんで from import したいのか？
- from import すると何が困るのか？
- 状況の把握
- 状況のまとめ
- 解決策
- 全体のまとめ
JSX (Photoshop) を include 展開してみる。
JSX って基本的には配布後にインストールしてもらう形式になるだろうし、配布済みスクリプトの更新でトラブルになるような気がした。ので、include を全展開して 1 ファイルだけユーザに渡せるようにしてみる。本番配布で使うんじゃなくて、「こんな修正してみたけどちょっとどうよ？」みたいなテスト配布時に使う想定。
……と言っても、技術的にすごいことは何もしてないし、コードも日曜プログラミングレベルなので特に書くことがない。とりあえずこんなんやってみたっていうメモ。
エンジニアTA向けGUIチュートリアルとしてのファイルエクスプローラ実装。
そろそろPySideをちゃんと覚えようと思ってファイルエクスプローラをつくってみた。
これ個人的に GUI ネタとしてはわりといいかんじだと思ってるのでざっくり紹介してみる。エクスプローラっていろんなGUIネタが詰まってるから、チュートリアルとしてはたぶんすごくちょうどいい。
というわけで以下、ファイルエクスプローラをつくるのに扱う主な GUI 要素を羅列してみる。リンク先はすべて PySide 関連。
- その他
さて、まぁこれだけ使えれば基本的な GUI 構築で困ることはあまりないと思う。とはいえ TA 界隈、いわゆるアーティスト（デザイナ）でも人によってはこのくらいふつうに扱えてしまうので、エンジニアが存在する意義は微妙なところ。というわけで、「経験上アート出身の人たちがここまでやることは少ないのかな」という部分をいくつか拾ってみる。今回はそこまでやってないけど、このあたりのテスト実装をするのにも、ファイルエクスプローラはほどよく機能する良いネタだと思う。
続きを読む2回目のP2P、っぽいなにか。
前回の続き。
- サーバからピアへの返信をメッセージングからHTTPに変更した。
- サーバからピアへの返信をJSON形式に統一した。
- 再利用できるように全体的にコードを整理した。
はじめてのP2P、っぽいなにか。
NSQとHTTPをベースにしてトポロジっぽいものを組んでみた。
とはいえネットワーク周りはまったくの専門外なので、とりあえずは
- 個数が動的に増減する複数のクライアントノード間でいいかんじに分散処理できること
- ネットワーク上にサーバがいないときにクライアントだけが起動してても問題ないこと
- 動作パフォーマンスよりの高さよりも実装コストの低さを優先すること
あたりを考えながらやってみた。
想定する用途は、中～大規模のゲーム制作チームで利用できるようなアセット関連のビルドキャッシュあたり。
今回のやり方がどれくらい一般的な構成なのかはよく知らない。ていうかたぶん違う。
続きを読む
Slackとかにおもうこと。
upgrade.all-in.xyz
thebridge.jp
もちろん、全員がマルチタスクでさくさく処理できるようになることは望ましいのですが、 組織が大きくなればなるほどコミュニケーションの設計を最適化すべきですね。
これはまったくその通りだと思っていて、もうちょっと気軽に無視[できる|される]空気が欲しいなぁと思う。
例えばHulickさんが書いてるような「返事がもらえないと支障が出るようなことがらをチャットで伝えようとする」こと自体が問題で、そういうのはメールとかJIRAとかRedmineに逃がしてやるのが正解だと思うんですね。Slackがメールを置き換えるという発想自体が間違いなのではと。というか、世の中の一般的なチャットツールに「通知OFF」の機能がついてるのは、まさにそのためなわけで。この人も書いてるとおり、コミュニケーションがとれるってことが常にすばらしいわけじゃないんですよね。
チャットツールが2個も3個も起動してるような状況はそりゃよくないと思うけど、チャットとメーラーとプロジェクト管理ツールが起動しているような状況は、それ自体は別に悪くないと思うんですよ。ただそれが常に良い状況だとは限らないので、それらが如何に共存すべきかを考えるのが、生産性に貢献せんとする僕らのタスクではないかと思うのです。コミュニケーションチャネルを減らすってのはその結果採用されうる戦略のひとつであって、コミュニケーションの棲み分けができない状況でSlackをやめても、Slackを始める前の状態に戻るだけであんまいいことなさそうなんだよなー……。
ただコミュニケーション最適化ってとても時間がかかるものだと思っていて、なので現場スタッフの自分としては、二度手間になってしまうとしてもまずは、「それJIRAに積んどいてください」「じゃあそっち行くんで口頭で相談させてください」「電話で話してもいいですか？」って言うところから始めるようにしてる。もうちょい責任（というか権力）のある立場だったらまた違うやりかたがあるんだろうなぁとは思いつつ。
