「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
管理画面と業務フロー - UNIX的なアレ
最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。 社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。 それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。 管理画面からオペレーションを設計する まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい 組織の最適化より管理画面の最適化のほうが合理的に行える エンジニアの合理的な思考が
lsyncdで上限ファイル数を超えた時の対処策 - UNIX的なアレ
lsyncdで監視できる対象のファイル数は制限されています。lsyncdのlogに以下のようなlogが吐き出されていたら要注意です。 Fri Jan 22 14:11:51 2010: ERROR: Cannot add watch /foo/bar/ (28:No space left on device)このまま読んでしまうと容量が無いのかなーとも思ったのですが、そういうわけではないそうです。lsyncdは、inotifyというAPIを利用してつくられているので、そのあたりの設定ですね。 というわけでドキュメントを調べてみました。 /proc インターフェース 以下のインターフェースは、inotify で消費されるカーネルメモリの総量を制限するのに使用できる: /proc/sys/fs/inotify/max_queued_events このファイルの値は、アプリケーションが inot
スタートアップにおける点の正義と線の合理性 - UNIX的なアレ
テストを書くかどうかみたいな話がよく議論に上がりますが、毎回賛否両論なわけです。CTO向け1on1を続けていく中でも近い話がよく議題としてあがりました。 wadap.hatenablog.com 当然な話でどっち側の意見も間違っているわけではなく、話している背景が違うのが根本的な原因なんだと思っています。そこを自分なりに考えをまとめてみました。 点で語る正義 これはまず一方からだけみた正しい回答のことを指します。まずこの点でみたらテストの議論に関して言えば当然「書いたほうが良い」という結論になります。会社の経営的な話で言えば「赤字よりも黒字のほうがいい」ですし、人事観点だけで言えば「人はやめないほうが良い」という事になります。 点で語ることは非常に大事なことですし、世間に様々な先人の知恵があります。点だけでみると変数は少なく、判断しやすいと思います。一方で圧倒的な正義になりやすく、これを振
技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ
ITに携わる人たちの間で、エンジニアが大切でエンジニアを中心とした組織づくりをしようとしている会社がすごく増えてきました。実際にいま存在感がある会社はどこもエンジニアが活躍している会社です。 なぜ非エンジニア向けに技術を学ばせるのか nanapiでは非エンジニアむけの技術研修を毎週実施をしていて、コードのかけない人はいないようにすることを目標にしています。これはコードを書けることでそれを普段の業務に活かせるようにしようというだけではなく、技術そのものに対してリスペクトしてほしいという思いがあります。 nanapiのエンジニアはコミュニケーション能力が非常に高いので非エンジニアのレベルに合わせて技術の話をすることができますが、実際はエンジニアが遠慮せずに話してそれを非エンジニアの人が理解しようとするほうが圧倒的に仕事のレベルは上がるはずなです。やっぱり普段の仕事の会話は高いレベルに合わせたほ
個人的なShellTipsをまとめてみた - UNIX的なアレ
naoya_itoの火を噴いたシェルtips - Togetter これを読んでふと書きたくなったので。ちなみに僕はbash使っています。 CTRLを使った便利系 まず、UNIXな操作あたり。 キーバインド 意味 CTRL + s キー入力を受け付けなくする 画面出力抑える CTRL + q 上記解除 CTRL + z バックグラウンドに. fgで戻る CTRL + l 画面をクリア。clearと同等 CTRL + c 現在の処理を停止 CTRL + d exitと同等 CTRL + r historyからコマンド検索 emacsっぽいやつ どっちかというとキー操作に近い。基本はemacs。metaは僕はoptionに割り当ててる。とりあえず触りたい人はESCでOK。 キーバインド 意味 CTRL + a 行頭 CTRL + e 行末 CTRL + f → CTRL + b ← CTRL
Unixに関するいろいろな略称とその意味 - UNIX的なアレ
いろいろな略称が多い！ コマンドやディレクトリ名など、UnixなOSはとにかくいろいろな略称が多いです。特にさわりはじめの人はこの略称がいみわからずに心が折れてしまうことは多いと思います。実際にSchooでUnixの授業をやったときもこの略称を説明しました。 というわけでまとめてみました。なぜ略称が多いのかが気になる人はこちらを読んでみてください。 UNIXという考え方―その設計思想と哲学 作者:Mike Gancarzオーム社Amazon ※ちなみに、Linuxにもほぼ通用すると思いますがMacをベースに書いているのでUnixという表記にしています。 ディレクトリ名 名称 本来の意味 備考 usr User Services and Routines これは若干怪しめです。Userという説も var Variable ログやメールの情報など、変わりうる情報を扱うもの tmp Tempor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
