はてなキーワード: 管理ツールとは
Ansibleはcowsayがインストールされている場合、cowsayを介してログを出力する仕様になっている。
しかし、cowsayがデフォルトで入っているLinux Mintでは否が応でも大量の牛を見ることに…。
Linux Mintでpackageリソースが動かないからとAnsibleへ移行した。
(原因はItamaeではなく内部で使ってるspecinfraにある気がする)
幸い、roleがcookbookと似ており、移行もそれほど苦労せずに済んだ。
Fedora用のplaybookがあらかた完成したので、
今度はLinux Mint用のものを、と思ってAnsibleを動かしてみたのだが、
何やら動作がおかしい。
PLAY [localhost] ************************************************************** GATHERING FACTS *************************************************************** ok: [localhost]
↓
__________________ < PLAY [localhost] > ------------------ \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || _________________ < GATHERING FACTS > ----------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
最初はLinux Mint向けのパッケージが特殊な仕様になっていると思い、
pipを使って入れなおしてみたが何も変わらず。
疲れたので原因探求をやめ、
「そういえば、Itamaeの記事で同じアスキーアート見たなー」と思って、
なんとなくでItamaeの記事を読み返してみると、
どうやらcowsayというツールを使うことで牛のアスキーアートを出力できるようだった。
http://qiita.com/tbpgr/items/b47510b01db8697f94c1
とりあえず「Ansible cowsay」でググった。
まさかAnsibleのような真面目なプロダクトでそんなことあるわけ…
と思っていたら本当にcowsayが原因だった。びっくりした><
なにか変な夢でも見てるんだろうと思ったが夢ではなかった。
https://github.com/shkumagai/ansible-doc-ja/blob/master/playbooks2.rst#id26
Linux Mintではcowsayがデフォルトで入っている。
そのため、牛が出ないようにするには、
export ANSIBLE_NOCOWS=1
bashrcなりzshrcなりに↑のように書くか、
http://docs.ansible.com/faq.html#how-do-i-disable-cowsay
[defaults] nocows = 1
ansible.cfgに↑のように書くか、
https://support.ansible.com/hc/en-us/articles/201957877-How-do-I-disable-cowsay-
cowsayを削除するかすればいいようだ(やりかたは色々ある)
Ansibleを開発している方々は、
「slやcowsayのようなジョークコマンドがシステムに最初から入ることはない。入れる人は分かっててやっているだろう。」
と踏んでいたのかもしれないが、Linux Mintの場合はそうでない…。
俺も似たような傾向があったからアドバイスするけど薬は飲んだほうがいいよ。
俺はADHDだと自己診断して、こういう風に苦労してると大学病院の心療科で訴えたら
ストラテラを処方してもらった。
それからは計画通りに物事をできるようになったり、そわそわして落ち着かない気持ちになったりというのがなくなった。
もちろん薬だけではだめだから、
締切の管理にはgoogleカレンダーなどデジタルツールを使用したほうがいい。
紙ベースだと散逸しやすいし、自由に記入できる分逆に使いづらいが、
デジタルだとフォーマットが決まっているし、一元化もしやすいので便利。
僕個人としては、ADHDにとってデジタル管理ツールというのはギブスのようなもので、
これが使いこなせると格段に生きやすくなると思う。
ホント似たような感じだな。
あと追加するなら、思いついたタスクはとりあえず紙に書き出す。
どんなに先が長くてもタスクには日付を入れ予定は立てる。
予定に入らないものは削除する。←これが怖くてなかなかできない。
あと心構え的なこと
・言い訳しない。
・すべての失敗は自分の準備不足に起因すると考える。
・完璧にできない部分は必ずある
「ダメな部分もあっていいや、ADHDだから仕方ない」というと周りの人から袋叩きにされる。
「完璧に準備しよう」と思うといつまでたっても実行できず先延ばし。
中庸って本当に大事だけど難しい。白黒つけたがるのがADHDなのか。
かと思えば「死ぬくらいなら、死ぬ気で頑張れ。死ぬ気で頑張れば何とかなる」と開き直ったり、
かと思えば「死ぬ気で頑張れば…なんていうやつは死ぬまで頑張れない屑なんだよ。僕は死ぬまで屑なんだ」
とまた落ち込んで「屑は屑なりに頑張るか」ってところで落ち着いてる。
理想は知足というより求める中に満足を見出すなんだけど
新卒で入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェアを制作販売するソフトウェアハウスだった。
入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページの管理があった。主な業務は、ページの文章の更新と確認、誤字脱字の修正、古く間違ったHTMLの修正など。
会社のホームページには自社のサービスや製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションのセキュリティを勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)
http://tatsu-zine.com/books/sbcr-taiketekinimanabu
この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。
頭から読み進める。1章に用語の整理があるおかげでだいぶ理解しやすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。
なるほど、XSS(クロスサイト・スクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックスに入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社のホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テスト用サーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……
検索ワード: +----------------+ | | | 1 | | [ OK ] | +----------------+
なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性の修正の実習もできるな。
このようにして、徳丸本を読み進め、(テスト用サーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:
ショッピングシステムの中身が、フレームワークやライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性の修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダもエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。
これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性の始末書は、すべて現在の担当である自分が書くことになった。
自分が入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正し始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会とコードレビューとバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。
自分の作業はすべてgitで記録していたので、自分が担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験から、バージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。
こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さらに勉強し、3年目に入るころには情報セキュリティスペシャリスト試験に合格し、転職した。
Webサービスのセキュリティを勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験用環境のCDもついているので、A社でホームページを担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)
情報技術系だということで今さらながら入学祝いに安いノートPCを買ってあげました。
わたしとは違い体育会系なのであまりそっち方面のリテラシーはありません。iPhoneユーザー。
そんな彼でも健やかにネットライフを楽しめるようアドヴァイスを与えたく以下のようなことを書いてみました。
ご助言ください。
===================================
いろいろ危ないから気をつけろ
いろんなサービスがあるけど実名は基本的に使わないように。(Facebookだけは実名にしなきゃいけないが)
SNSは友だちだけとの会話でも世界に丸見えだと思え。twitterは「バカ発見ツール」と云われているぞ。
いろんなとこで同じのを使うともし流出したときにやばい。近頃は一見まともそうなサイトでも個人情報が流出しがちだ。
でもそんなにたくさんのPWは憶えておけるはずがない。
できればPW管理ツールを使うこと。
憶えておくのはマスターPWだけだ。父はkeepasを使っているぞ。PCでもiPhoneでも共有できるし使い方は簡単だからググれ。
あともちろんだけどPW自体絶対誰にも教えないように。万が一知られたらすぐに変えよう。
悪意のあるプログラムを仕込んでいるサイトがあるぞ。広告をやたらめったら貼ってあるようなサイトはとくに怪しい。
あるサイトを訪れただけで勝手にfacebookの「いいね」を押されて友だち全員にキミの趣味嗜好がばれるという最悪の事態も考えよう。
行かないのがベストだが。
ネットのことはネットに聞く。たいがいのことは教えてくれる。検索ワードの選び方も工夫してみよう。
きっと勉強にも役立つヒントを与えてくれるはずだ。
メールアドレスは携帯やプロバイダに依存しないものをメインにするべきだ。もう使っているかもしれないが、gmailかhotmailか。選択肢はそんなにない。
それを「メイン」としてつかうべきだ。そして「サブ」を持つならそれらはメインに転送設定しよう。i.softbank.jpのアドレスは携帯をソフトバンクから別に乗り換えたら終わりだ。
それをメインに使うべきではない。iPhoneでもgmailを使おう。
あと迷惑メール(SPAM)を回避するために、できるだけメインのアドレスは信頼できるところだけに使いたい。なのでどうでもいいところで使う「捨てアド」を持っていると便利だ。
父はyahooやexciteのメールアドレスを「サブ(捨てアド)」として使っている。
IT系でこれからもやっていくなら、ブラウザはwindowsに最初から入っているIEは使わない。これは世界の常識だ。
ChromeかFirefoxを使おう。父はFF派だが、Chromeのほうが将来性があるかもしれない。
そして便利な「アドオン」を使おう。アドオンはブラウザにいろいろな機能を追加する。英単語を簡単に翻訳したり広告をブロックしたりできるぞ。詳しくはググろう。
軽いノートパソコンだから外に持って行きたくもなるだろう。そして街では無料で使えるWifiも飛んでいることに気づくはずだ。
しかし、セキュリティ対策をしていないネットワークに接続することは危険が大きい。
PCに入っている個人情報をまるごとぶっこ抜かれるぞ。詳しくは「フリーwifi 危険性」とかでググろう。
windowsはウイルス対策が超必要なコンピュータだ。かといってわざわざ有料のウイルス対策ソフトを買って入れる必要はない。
windows8にはデフォルトでウイルス対策がされている(Windows Defender)。初回セットアップ時に確認しよう。
むしろ無駄なアンチウイルスソフトの体験版などが入っていたら動作が重くなるのでアンインストールしよう。
またウイルス対策にはシステムを常に最新にしておくことが重要。windowsは頻繁にアップデートしているから、PCを久しぶりに起動したときなどは更新プログラムのチェックをしたりもしよう。
迷惑メールにも悪意あるプログラムが添付されていることがある。迷惑メールは開いてはいけない。
著作物のダウンロードとか。売っているものがタダで手に入るということは違法の可能性を疑おう。
===================================
こんなとこか。
SSD が普及すればこういったことは気にしなくなるだろうけど...
システム管理者として、アンチウイルスソフトの E*ET はとても重宝している。
同時検索させてしまうと重くなる。現在の動作が終わるまで待機させるか、現在の検索を打ち切って(権限管理は必要)新しい指示に応じて検索ジョブを開始してほしいね。リモート管理ツールから現在の検索状況をリモートから知る手段がないので、とりあえず検索指示を投げることのなるのだが、すでに検索中の場合があって、社内のパソコン利用者から嫌がられる。
それとは別に、ファイルコピーのフリーソフト FireFileCopy などは、同じ物理装置で単一の処理になるようにしながら複数の物理装置があればそれぞれ並列に動作させているので、早く検索完了するよう倣ってほしいなぁ。
http://www.tiobe.comで、プログラミング言語の人気ランキングを、どっかで見かけるたびに
俺は、C言語をお遊びではなく仕事として使ってきたわと静かに震えるのがほぼ反射神経になっている。
「C言語一筋で、オブジェクト指向の知識はあるけどCPPもJavaも知りません、あ、C#とVBAは自作ツールを作成する過程で勉強しました。」
業務経歴書を片手に面談で話したときの、微妙な空気を知ってからだ。
C言語は、この業界にいる誰もが一度は耳にしていて、しかし業務として使った経験がある人はあまりいないであろう、不思議な言語だと思う。
組み込み屋のSEとして入社して、教育期間が終わってすぐに回されたのがAndroidのLinuxカーネルのドライバー周りのお仕事だった。
C言語というかLinuxカーネルのAPIばかり覚えさせられて、初めて触った構成管理ツールがgitで、管理任されたビルドサーバーはFedoraで、開発はTeraTerm上でemacsを使ってた。
思えば、すごく先進的な開発現場だったのだ。なんでC言語?と言語のロートルな側面ばかり見ていたが、
毎週のようにリリースされるカーネルパッチには、急速な変化に対応した野心的な取り組みが山のように入っていた。
世の中にはレガシーJava(1.4)で、構成管理ツールがSVNで、開発はEclipseのGalileo、Ganymedeかsakuraエディタという
時代に取り残された場所があるなんて想像だにしていないかったのだ。
最も当時はコミットされたバッチのコメントを追うだけで精一杯で、どうして議論になっているのか分かりもしないLKMLを読んで知ったかぶっていた
だけで、raspberry piを手慰みに遊ぶまでは実を結んでいた自覚なんてなかったのだけど。
思われてる。社会情勢が教えてくれる。いや、そんなことない、それは妄想だ。様々なところで使われているじゃないか。
でも、そこで食える飯はもうほとんどなくなっている。
カーネルのメンテナーにパッチを送ったことすらない、中途半端な技術力しかない俺の市場価値は、今限りなく低い。
だから、いつまでもC言語がプログラミングの人気ランキングにいつまでもいることを苦々しく思う。
C言語を使って、可能な限り先進的なことをやって。それは、C言語という埃をかぶったようなイメージとはかけ離れていたはずなのに。
実際は井の中の蛙で、外から見たらひとくくりに時代遅れとされたのが許せなく、そしてやるせなかった。
自分は今、実際、先にいったような環境ですら、状況の対応に四苦八苦する有様だから。
C言語なんて大嫌いだ。
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ )
チーム生産性・幸福度・メンバーのつながり・1日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか?
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
2つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが2003年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、1980年代以上に決め事・儀式だらけだ。
実際、今のプログラマは1970年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する(多くの場合チームの数名か、一人のいじめっ子が決めるのだが)と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事(その本では「コンセプトの統合」と呼ばれている)が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。(私は必ずしもそうだと思っていないが。)でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
今までプログラマーをやってきて、状況や環境に左右されず有用だったツールを書き残しておく。
基本的に Windows, Mac どちらでも動作するもの。
1. VirtualBox
ローカル PC 上に別の OS (Linux や Windows) を動作させる事ができるツール。複数の OS を同居させる事ができるので、自分の趣味用のサーバと仕事用のサーバを分けて管理したりできる。昔自分が Linux の勉強をした時は、メイン PC とは別にサーバ用 PC を買ってきて設定していたけれど、VirtualBox があればそんな面倒な事をしなくても済む。今は VirtualBox を更に簡単に設定できるたツールもあるみたいなので、それを使うのも良いかもしれない。
名前の通りパスワードを管理するためのツール。1Password https://agilebits.com/onepassword か KeyPass http://keepass.info/ が良いと思う。サーバサイドのプログラムを始めると、ssh やデータベース等、様々なアカウントを管理する必要が出てくる。root パスワードを忘れた時に、他の人がそれを覚えている保証は無いので保険としてぜひ導入して置いた方が良い。
何でも良いので、とりあえず汎用プログラミング向けエディタを使う事をお勧めする。Sublime Text http://www.sublimetext.com/、Eclipse http://www.eclipse.org/、Vim http://www.vim.org/、Emacs http://www.gnu.org/software/emacs/ あたり。Linux に関わるのであれば、Vim か Emacs どちらかは習得しておいた方が良いが、初期学習コストは高い。Eclipse は Java 以外の言語にも多数対応していて機能が豊富なので、最初はここから始めるのが良いかもしれない。もし Eclipse も難しいと感じたら、より普通のテキストエディタ寄りの Sublime Text から始める。
4. git
最近のオープンソースプロジェクトは github で公開されている割合が多い。そうで無くても git リポジトリの採用率はとても高いので、git のインストールは必須と言っても良い。また、個人用のリポジトリを作るのもとても簡単なので、小さいプロジェクトを始める時は最初に git init をしてしまうのが良いだろう。もちろん、svn や mercurial を使っているプロジェクトも存在するので、それらも適宜インストールする。
5. Google Account
これはツールでは無くて Web サービスだが、サイトのアクセス解析にしろ地図機能の実装にしろ、Web サイトの構築を Google 抜きで考えるのは難しい。また、開発メンバーとのコラボレーションを行う場合、Microsoft Excel をメールや DropBox でやりとりするよりも Goole Drive の Spreadsheet を使う方が便利な事も多いので、意識して Google を使うようにすると新しい発見がある。
+α.
こんなふうに思っているのは自分だけだろうか。
「残業をせず、定時に帰り、仕事以外の時間を大切にすることによって
のような表現をしたビジネス書がコンビニの本棚にも陳列されているし、
ネットの記事なんてもうくさるほどある。
こうすれば効率がよくなる、というような情報が氾濫してて、そういうのを
見ていると、ああ人ってみんな働きたくないのだな、と思う。
効率化して生産性をよくするってことより、残業しないことのほうが
えらくなってる。
自分の会社もそんな感じになってきた。たくさん働くと社畜だってさ。
ブラック企業とかいう曖昧な定義をして、自分の市場価値と給与を
天秤にかけたこともないようなやつが、9時から18時まで働いて日本人の
平均給与以上を求めているわけ。
そういう人が、上手に定時に帰るためのハウツー本とかタスク管理ツールとか
自分のデスクに並べまくって、ランチwをちゃんと食べて、たいして仕事も
しないで、定時になると自分はただしい、って胸を張って帰っていく。
会社も上司も、そんな風潮だからそういう社員にもっと働けなんて言えないし、
残業=悪(残業代支給でも)みたいな雰囲気で、会社が大変な時でもまともに
仕事が振れやしない。
長時間働くこと=悪 っていうのは、長時間拘束されて会社から無理に
労働させられている人の構図であって、働きたい人にとって働くなっていう
雰囲気のあるこの感じって、ほんと働きにくい。徹夜や働き過ぎが効率よく
ないのはわかってるよ。んでも、やるときはやらなきゃどうしようもないでしょ。
俺は働きたいので。
やっとありつけた仕事だし。
これって多分周りとの温度差なんだろうね。単純に。
なんだか寂しいや。
働きにくいや。
平成250年って書いてあるところを見つけたので0を取りたい。
これくらいだったらこちらでもできるので手順を教えてくれないかって話から入って
面倒なのでこちらで作業しますんで、って言ってもいやこれくらいの事だからこちらでやりますみたいな事になって
じゃあ手順ですけど、って言うんだけどまず手打ちでやってる時だと、ftpのソフトは入ってましたっけ?から始まって、なかったらインストールさせて
zip解凍できないって人も中にはいて、解凍ソフトのurlを教えて落としてきてもらって、
そんでたいていftpの情報は共有できてないから伝え直して電話越しにそこをクリックしてあそこをクリックして…と伝えて
ファイルを開いたら文字化けするんだけどって言われてじゃあ文字コードを指定できるエディタがあるので
エディタって何?いやその、っていう流れを経て、アップロードしてもらってブラウザ更新して確認してもらって、ああできた、簡単やんって終わり。
wpみたいな管理ツール入れてる時も結局面倒であそこのタブのそこをクリックしてもらって…ってどっちにしても10秒で終わるような事を1時間くらい掛かってしまうので
めんどくさい。
うちの会社はそれなりに名の知れた大企業なのですが、もとがIT系の企業ではないし、体質がものすごく保守的な会社なので、システムの運用管理、いやソフトウェア開発に関してもものすごく保守的です。
使っているテクノロジーはとにかく古臭いし、まぁ「古臭いなー」と思うだけで済むのなら良いのですが、どうにもそのテクノロジーの古さが足かせになっているように思えてならないのです。ITというスピード勝負で競争が激しい土壌で戦っていく気があるのなら、体質を変えないとこのままでははっきり言ってヤバイと入社3年目の若手が冷や汗するほどなんですから。
仮に、“いまのところは”このままで良いとしましょう。じゃあ、これからどうにも行き詰まったときにどうするのでしょうか、それから必死になるのでしょうか。当たり前ですけどそれはバカだし、それどころか人員を投入するとかそういうコストのかかる方法で解決しようとするんでしょ? いま新しいテクノロジーを導入するのは、たしかに負担がかかります。かといって、このまま必要に迫られるまでギリギリのところまで古臭い仕事をしていていいのでしょうか。そんなこと、学生のときに学んでいるはずなんですけどね。
では、僕がいるインフラ部門において、うちの会社の問題点とは何でしょうか。
信じられない人も多いかと思いますが、うちの会社では、監視以外すべて手作業で運用管理をしています。以上。
もう古いというか、それ以前の原始の時代です。これ以上の古さはありませんし、テクノロジーでもなんでもないです。すごく素朴ですよね、仕事が。すごくくだらないルーチンワークに時間をかけて、社員のスキルアップの機会を損失させてるんですから、悪循環にもほどがあります。そのうえ組織が大きくて、セキュリティのためだなんだと膨大な事務的作業に追われていて、この先、暗い未来しか見えてきません。
運用管理ツール、デプロイツールなど、そんなことには目もくれません。ひょっとしたらマネージャークラスでも継続的デリバリーとかナニソレ知らないという人がいる気がする。
そして、もう一つ問題なのが、“その古臭いやり方が、プロフェッショナルで、ベストな方法だと思い込んでいる先輩社員がいること”です。(もちろん、僕と同じかそれ以上に危機感を持っている先輩もいますが、その先輩は最近運用管理の仕事から離れてしまっています。もっとクリエイティブな仕事に行ってしまってる。)
「手作業でやることがいちばん安全でベストな方法だ」という考えを持っている先輩に対して、いつも返す言葉に苦労します。そこにはバカの壁っていうのがあって、言えば理解してくれるなんて大ウソなんですよ。実際、ほんとうに理解してくれません。むしろ自動化するほうが危ない(機械なんて信用できない)とか、自動化しても結局手作業で確認しなきゃいけないとか、言うんです。バカでしょ。過去にデカい失敗をしちゃってトラウマがあるならまだしも…。まぁ、へんに優等生タイプな人かな、こういう先輩は。体制に疑問を持たない人。想像力がない感じ。大局的視点がない。
それにそういう人は「スキルがない若手が生意気なことを言うべきじゃない」と思ってる。そこが間違ってると思うんですよ。大きく間違ってる。
若手は生意気なことを言うべきなんです。そりゃ若いから知らないこともたくさんありますよ。会社のなかの政治的なこととか、マネジメントの視点とか足りないのはあたりまえじゃないですか。それでも、若手が生意気なことを言うのには価値があるんです。その生意気のなかにしかないヒントだってあるんです、ごちゃまんとある。ベテランは生意気なこと言えないんですよ。ベテランが言ったら、それはただのベテランの発言でしかないし、そんなの往々にしてポジショントークになるに決まってるんです。
だから、なにが言いたいのかっていうと、もっと生意気言えよっていうことです。そして、もっと生意気言わせろよってことです。もっと言えば、積極的に若手の生意気を聴いていけよってことです。それが単に取るに足らない生意気ならば、ちゃんと丁寧に説明して玉砕すればいいだけです。取るに足りる生意気ならば、まぁ、レイトマジョリティの保守的管理職のみなさんは首を縦に振らないでしょうが、その方向に進めるようにスタンスを整えるだけでもしてくださいよってことです。
以上
だから、パッケージ管理ツール範囲外の物は、どっちにしたってされないよね。
そうすると、自動アップデート対象になるように、「公的に登録しろ」って事だよね。
そうすると今度、依存関係の問題が出てくる。
Linuxでも毎回警告が出てるが、依存関係で不和が生じた場合、その解決をどう図るのかって問題がある。
アップデートされない古いパッケージは、毎回毎回警告が出るようになるんだろうか。
上と絡むんだが、リポジトリの概念があったって、それがきちんと更新管理されてなきゃ意味がないわけで、それをパッケージベンダーに委ねるわけでしょ。
だからちょっと前に「正しく申告」と書いたんだけどさ。
そうした、外的要因に依存してしまうよりは、少なくともあるバージョンに関して間違いなく動くことを保証できる、「まとめてインストールシステム」は、初心者に優しいよね。
まぁ、誰でも思いつく方法だと思うんだけど、「 自己管理ツール 人生三万日しかない [30thou]」というサービスを使用している人は、『生まれて何日たったか』をツイートしているので、そこから逆算して生年月日を求められるよということ。詳しくはここ。その情報を集めれば約五万人分の生年月日が求められて、同じ年齢や同じ誕生日のTwitterユーザをフォローしたりできるので面白いかな、とか思ったわけ。
で、Twitterでこのアイデアを呟いたら凄い反感を買ったの。生年月日という個人情報を本人の許諾なしに勝手に公開するのは駄目なんじゃないか、とね。僕の直感としては、本人がインターネット上にパブリックに公開した情報なんだからどう扱ってもいいんじゃないかな、と思ったいたのでその反応は意外だった。ただ、「人生三万日しかない」というサービスを使用している人はこういう事態を想定してサービスに登録していたのだろうか?と考えると、イエスとも言えないかもしれなくて、だとしたらこれは倫理的にやってはいけないのかなって思ったり。自分の中でまだ結論が出ません。
今回この日記を書いたのは、ツイトモの件(Facebook内へのリンクです。ログイン必要)見てたら、この件と通ずるところもあるなって思って。みんなの意見を聞いてみたいと思ったのです。勝手に生年月日を逆算してそれをまとめて公開しても良いと思うか、やってはいけないと思うか。そしてそれはなぜなのか。Facebookで論争を交わしている、はまちちゃんやあまちゃんやyakさんの意見も気になるなーなんて。あ、あと空井さんもこれについてはどう思うのかな・・・。
補足:
はてブid:ululunさん > http://twitter.com/#!/search/realtime/%2330thou を見る限り現時点では開示されてないね。
零時を起点にツイートし始めるので、零時まで待っていただければ表示されるかと。こちらに詳細。また、今あるツイートでもリンク先に飛べば『生まれて何日たったか』が表示されています。(ただ、記録を付けずリマインダーのツイートも記録のツイートもされない人は、#30thouのタグでツイートをさらえないので生年月日を知ることが出来ません。前は登録ユーザ全員がリマインダーをツイートするようになってたので、サービスを使っている全員の生年月日を知ることが出来たのですが・・・。現在も過去のツイートをさらうことができれば、サービスを使っている全員の生年月日を知ることが出来ますが、その点ではタイトルに偽りありかもしれません。)# まぁ、個人的にはできるかどうかより、こういうことができたらやっていいのか駄目なのかが重要ですが。
早いとこ、管理ツールのデファクトスタンダードにPowerShellを持ってきたいんでしょ。
Resource Kitも売れなくなったみたいだし。
こんにちは、技術恋愛戦略学を専攻しているユビキタス嬢です。私は学歴もスキルもありませんし偽装請負ですが、情報系の恋愛に関してはプロフェッショナル。今回は、モテる情報系女子力を磨くための4つの心得を皆さんにお教えしたいと思います。
1. あえて2~3世代前の開発言語のスキルを履歴書に書いて行く
あえて2~3世代前の言語を使うようにしましょう。そして会社のマッチング面談で好みの人事がいたら話しかけ、わざとらしくラップトップを出していじってみましょう。そして「あ~ん! このC○B○L本当にマジでチョームカつくんですけどぉぉお~!」と言って、人事に「どうしたの?」と言わせましょう。言わせたらもう大成功。「オブジェクト志向開発とか詳しくなくてぇ~! ずっとコレ使ってるんですけどぉ~! 使いにくいんですぅ~!ぷんぷくり~ん(怒)」と言いましょう。だいたいの人事は新しい開発案件に流したがる習性があるので、古かったとしても1世代前の案件を担当しているはずです。
そこで男が「新しいスキルがほしくないの?」と言ってくるはず(言ってこない空気が読めない人事はその時点でガン無視OK)。そう言われたらあなたは「なんかなんかぁ~! 最近C# 5.0が人気なんでしょー!? あれってどうなんですかぁ? 新しいスキル学びたいんですけどわかんなぁぁああい!! 私かわいそーなコ★」と返します。すると男は「C# 4.0でしょ? 5.0はまだ仕様も決まってないよ。本当に良くわからないみたいだね。どんなスキルが欲しいの?」という話になって、次の営業日にふたりで案件選びのデートに行けるというわけです。あなたの女子力が高ければ、人事が優良案件を紹介してくれるかも!?
「var」とか「temp」などを表現する「hoge」をコードに入れると、コードレビュワーの男性SEは「なんかこの子カワイイなぁ」や「指導してあげたいかも」と思ってくれます。コード管理ツール上では現実世界よりもイメージが増幅されて相手に伝わるので 「hoge」を多用することによって、男性はあなたを可憐で女の子らしいと勘違いしてくれるのです。そういうキャラクターにするとほぼ絶対に同僚プログラマに嫌われますが気にしないようにしましょう。
3. とりあえず営業には「えー! なにそれ!? 知りたい知りたーい♪」と言っておく
ミーティングなどで営業がSE・プログラマに話すことといえば予算話や納期の話ばかり。よって、プログラマにとってどうにもならない話ばかりです。でもそこで適当に「へぇー検収間に合うんですかぁ~?」とか「よくわかんないですけど予算超過しそうですねぇ」と返してしまうと、さすがの営業も「このプログラマダメだな」と気がついてしまいます。ダメプログラマだとバレたら終わりです。そこは無意味にテンションをあげて、「えー! なにその業務要件!? 知りたい知りたーい♪」と言っておくのが正解。たとえ理解できない仕様でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に営業は弱いのです。
いろいろと話を聞いたあと、「〇〇は〇〇扱いで、〇〇が〇〇になるバグは見なかったことにするんですね! 忘れたぞぉ! メモ廃棄!コメント削除!」と該当コードをコメントアウトすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン! キュンキュンキュン!」と言って、「どうしたの?」と男に言わせるのもアリ。そこで「私のバグ発生履歴マスタからレコードを物理デリートしているのでありますっ☆」と言えば女子力アップ! そこでまたマネージャーは「この子おもしろくて使えるかも!?」と思ってくれます。私は学歴もスキルもありません偽装請負ですが、こういうテクニックを使えば知識がない私のようなバカ女のほうがモテたりするのです。マネージャーは自己保身に走りたいですからね。
客先担当者の男とレストランに入ったら、真っ先にATMなどの銀行系SIerを使ったシステムを探して「あーん! 私これ使えないんですよねぇ~(悲)」と言いましょう。するとほぼ100パーセント「どうして? キャッシュカード持ってないの?」と聞かれるので、「カード持ってるし使いたいけど使えないんですっ><」と返答しましょう。ここでまた100パーセント「カードがあるのにどうして使えないの?」と聞かれるので、うつむいて3~5秒ほど間をおいてからボソッとこう言います。「……だって、……だって、ATM使ったらエンジニアが死んじゃうじゃないですかぁっ! 孫請けプログラマかわいそうですぅ! まだ有給とってないのにぃぃ~(悲)。労災すら降りないんですよ……」と身を震わせて言うのです。
その瞬間、あなたの女子力がアップします。きっと男は「なんて優しい労働基準監督官のようなコなんだろう! 絶対にゲットしてやるぞ! コイツはうちの担当SEだ!」と心のなかで誓い、あなたに惚れ込むはずです。意中の会社を担当することになったら、そんなことは忘れて好きなだけATMを使って大丈夫です。「使えないんじゃなかったっけ?」と言われたら「大丈夫になった」とか「もみ消した」、「そんなこと都市伝説です」と言っておけばOKです。
今自分が何をすべきか?というのが Webから表で 上から順に見ればいいみたいなふうにちゃんと管理されていますか?
どうも、作業全体が、口頭指示と思いやり で出来ていて 深度が深い人間(1つの事を深くやる)タイプには不利な指示が出ているように見受けました。
多くのことを浅くやるタイプと、1つの事を深くやるタイプといますので、指示されたことが管理されて、ツールで表になっているといいかと思いました。
個人的には、よくあるケースだと思いました。Tracとか良いですよ。
あと、深度の深い人間の下には、あまり人は付けられないですね。よくも悪くも。
なぜ応用がきかないんだろう? <> なぜ簡単にこの方法を諦めるんだろう
私も、1つのことを徹底的に、すこし、問題があるぐらいでは、変更せずに徹底的にやります。大概の場合はあまりよい結果は出ません。
とはいえ、それが研究ですし、であるからこそ、いくつかの分野では人に期待されるほど特化できているのだと思います。
よく、周囲から、どうしてあなたはコレができないの?と応用を言われるので、じゃぁ、あなたはコレができるの?と返すと、それは専門知識だからと言われます。
しかし、応用ばかりやっていたら、専門知識は身につかないわけで・・・バーターでしょと言いたかっただけなのに、
応用に特化した人たちは、自分達ができることは、簡単なことで、 深い知識は専門知識だから、となぜか、分けるみたいです。 でも、それはおかしい。
初回:http://anond.hatelabo.jp/20101118000033
前回:http://anond.hatelabo.jp/20101122141124
店のHP(Wordpressで構築)をさくらVPSに移転完了。
無事、稼働している様子。
これで旧サーバからおさらば出来る。
某所でもヤバイヤバイ言われており、サポート掲示板でのサービス提供者の発言も
結構ヤバゲな運用状況に陥っているのが透けて見えていた。
まぁ月々500円でmysqlやpostgresqlを使い放題だし、安かろう悪かろうじゃないけど致し方がない面もあり。
さて、今度はさくらのVPSに移ったわけだが、レビューによると性能は良いらしい。
ただし、root権限があるので自分でセキュリティやアップデートに気をつけないといけないわけだが…
現状を羅列してみる。
さすがにこれはヤバイ気がする。
みんなセキュリティはどうしてるんだろ?あと追加でやるとすれば…
本ページの内容は、平均より能力がかなり低い方向け、です。
恐らくほとんどの方にとっては、物足りない、伝わらない内容かと思われます。
例えば、
上記症状のせいで生きる事が辛かったのが、辛くなくなった時点
約半年間、が目安。
治療開始後、何度か「症状が良くなってきている!」と感じるタイミングがあるハズです。
今は「頭が悪い」状態ですから、小難しい治療方法は覚えきれないし、続かないです。
ひたすら独り言を喋りましょう。
自分の頭の中にあるぼんやりした思考をひたすら言葉にしましょう。
初めのうちは独り言を10分続けるのも上手くいかないと思います。思考がループしたり、止まったり。ついさっきまで何について話していたか忘れてしまったり。
もしそういった状態にならないようでしたら、アナタは私が想定している方々より頭が良い部類の人間です。
最初は好き勝手に独り言を喋り続けてみましょう。慣れてきたら、仮想の相手に説明するように喋ってみて下さい。
さらに慣れてきたら、自分の声を確認しながら喋ってみましょう。スマートフォンとマイク付きのイヤホン、「Microphone」などの音声関連アプリだけで実行可能です。
家族がいて独り言しづらい環境でしたら、防音グッズを使用しましょう。もちろん他の方法でも構いません。
プライベートでも、仕事のようにタスク管理をして生活してみましょう。
そんな大変な事ではありません。ゴミを捨てる、日用品を補充する、通販サイトで評判の良い枕を探して購入する、程度の話です。
タスク管理ツールはなんでも良いです。ですが、くれぐれもツール選びに時間をかけないようにして下さい。時間をかけた分だけ、治るのが遅れます。
個人的には、スマートフォンならメモ帳、PCならテキストファイル、それ以外ならノートやポストイットで十分です。
この記事は約5年前に書きました。当時は聴覚障害を疑って病院へ行くほどにヒドイ有様でした。(検査結果は異常ナシ、でした)