[MongoDB] field を削除するコマンド
- 2015 3/23
2014年10月ぐらいでしょうか、Javaのアップデートを促す偽サイトが流行っていましたね。
僕の周りでも家族や知人など数名が感染していて、解決するまでにやったことメモっていたのを公開しておきます。
やったことはこの2つだけです。解決したら IObit Uninstaller は常駐して邪魔だと思うので、これもアンインストールしてしまいましょう。
解決するまでに数時間もかかったので、普段から「変なサイトを開かない」「怪しい広告やリンクをクリックしない」など気をつけてインターネットしないといけませんね。
モチベーションが全く上がらない開発案件が浮上したという話をエンジニアの友人から聞かされました。
ざっとダメな点を列挙してみると、
というような内容です。
話を聞く限り、開発リソースを割くのに値しないのでやらないのが懸命な判断と感じました。既存の顧客のニーズをヒアリングしていなかったり、数字だして考えてない段階で事業案として提出しているのはお粗末すぎるので、もうちょっと頑張って欲しいですね。
久しぶりにモチベーションが全く上がらない開発案件が浮上してきて、とても残念な気持ちでいっぱいと友人は言っておりました。エンジニアが参加する段階の MTG で自分の口から「この開発、やる意味あるんですか?」っていわないといけない時点でどうなのという・・・。
「社内のエンジニアが納得できないような事業案を出してる時点でダメだよね」とその会社の CTO が仰っていたそうです。
事業の発案者にはエンジニアに開発工数を出してもらう前に、自分でも数字出すとかやるべきことをちゃんとやってもらいたいですね。
社内で「ボクのワタシの裏ワザ天下一武道会!」という業務効率化のTipsを共有しあう勉強会を開催しました。
その記念すべき第1回目に「Slack入門」の話をしたスライドです。
口頭やDEMOで補足した内容が多いので後日加筆した資料を作成する予定です。乞うご期待ください。
POSTDの【翻訳】ピアコードレビューの実践的レッスンという記事に実務に取り入れられそうなポイントがたくさん盛り込まれていました。
備忘録として引用とコメントを書き残しておきます。
なぜコードレビューをするのか?
最初に、なぜコードレビューをするのかを思い出しましょう。プロのソフトウェア開発者にとって最も重要な目標の1つは、ソフトウェアの品質を常に向上させ続けることです。たとえあなたのチームメンバが才能あふれるプログラマばかりだとしても、チームとして働く限り、有能なフリーランサーであることを切り離して考える必要があります。コードレビューはソフトウェアの品質を向上させる最も重要な方法の1つです。特に、以下の点において重要だと言えます。
- 不具合やより良い方法を見つけ出すための客観的な視点が得られる。
- 担当者以外に少なくとももう1人、コードの内容を理解する人を確保できる。
- 経験豊かな開発者のコードを見ることは、新人の訓練に役立つ。
- コードのレビュアもレビュイも、他のメンバの良いアイデアやプラクティスに触れることで知識の共有ができる。
- 同僚のレビューを受けると分かっているので、開発者は自分の仕事に対してより完全なものを目指すようになる。
箇条書きになっている重要な点、全てに同意です。
コードレビューはコストが掛かるけど、エンジニアとデザイナーが10人近く関わるプロジェクトにおいてはメリットの方が多いです。今関わっているプロダクトは、開発者が数人の時代は重要な機能以外はコードレビューせずに、どんどんプロダクト開発を進めていました。しかし、10人規模になってそういうフェーズは終わったと感じています。
致命的な問題が起きる確率を下げるためにレビューは有用な手段です。
徹底的なレビューの実施
しかし、適切な時間配分とともに相応の注意を払ってレビューを行わなければ、上記の目標は達成できません。パッチに一通り目を通して、インデントが正しいか、全ての変数がローワーキャメル記法になっているかということを確認しただけでは、徹底的なコードレビューとは言えないのです。よく使われるプラクティスであるペアプログラミングの手法を検討してみることは有益でしょう。この手法では、基本的に開発と同じ時間をかけてコードレビューをするので、所要時間は全体の開発時間の100%増となります。このペアプログラミングに比べれば、どれだけ時間をかけてもエンジニア1人がレビューに費やす時間はずっと少ないのですから、コードレビューには十分な時間をかけることができるはずです。
私の考えでは、本来の開発に費やす時間のおよそ25%をコードレビューにかけるのが妥当だと思います。例えば開発に2日費やすとしたら、レビューには約4時間かけるべきだということです。
コードをレビューする際には、コードの不具合やその他の問題を探すだけではなく以下についても確認すべきです。
- 必要なテストケースが全てそろっている。
- 適切な設計書が存在している。
“本来の開発に費やす時間のおよそ25%をコードレビューにかけるのが妥当”という考え方は、開発工数を算出するときの目安にしています。
コードレビューの過重な負担を防ぐ
チームがコードレビューを義務化して行っている場合は、コードレビューのバックログが管理できないレベルにまで膨れあがってしまう危険性があります。2週間、全くレビューを行わなかったとしても、レビューの遅れを取り戻すための数日間を確保するのは、難しいことではありません。しかしこの状態では、いざコードレビューを行った時に、開発作業が大きな予期せぬ問題に巻き込まれてしまうことになるでしょう。また、きちんとしたコードレビューを行うためには、精神的に集中した状態を保たなければなければならないので、レビューの質を上げるのも大変です。何日も続けてこの状態を保つことは困難でしょう。
そのため、開発者は毎日、レビューのバックログを消化するように努力すべきです。朝一番にレビューを行うことは、それに対処するための1つの方法です。未消化のレビューをその日の開発を始める前に行うことで、レビューしなければならないと思い続けながら開発する状況から逃れることができます。昼休みの前後や、仕事の終わりにレビューを行いたいと思う人もいるでしょう。いつやるにせよ、レビューを開発の邪魔だと考えるのではなく自分の毎日の仕事として捉えることで、以下に挙げるようなことを回避できます。
- レビューのバックログを消化する時間がない。
- レビューが終わっていないためにリリースが遅れる。
- コードの内容が既に変わっているのに、古いコードについて指摘してしまう。
- 大急ぎでレビューをしたために、不十分なレビューになってしまう。
先週から、”朝一番にレビューする”という習慣を取り入れました。
レビューしないといけない Pull Request が20件近くあるという不健全な状態なので、毎日コツコツとレビューとマージをしていくことがプロダクトを健康に保つために必要だと思ってます。
言うまでもないですが、プルリクが20件とか多すぎるので片手で数えられるぐらいにしたいです。
レビューしやすいコードを書く
もしアーキテクチャに複雑なところがあるならば、事前にレビュアに会ってそれについて議論しておくことは道理にかなっているでしょう。これによりレビュアは、コードが何のために書かれていて、機能がどのように実現されるのかが分かるので、コードをより簡単に理解することができます。また、コードを書く側にとっても、レビュアから別のより良いアプローチを提案されたことにより、コードの大部分を書き直さなければならないというような状況を回避することができます。
レビューの段階で大きな手戻りが発生しないように、事前にレビュアーやチームメンバーと仕様について議論しておくことは大切なことです。
大規模なコードのリファクタリング
最善の解決策はコードのリファクタリングを徐々に行うことです。
これに加えて、大規模なリファクタリングをするときは必ずチームメンバーにリファクタリングに取り掛かるということを情報共有するべきです。
論争の解決
あなたのチームは間違いなく知的なプロで構成されていて、ほとんどの場合、特定のコーディング問題について意見が異なっても合意できるはずです。レビュアが別のアプローチを好む場合に備えて、開発者として広い心を持って妥協する準備をしておきましょう。自分のコードに対して自分のものであるかのような態度を取らないでください。また、レビューのコメントを個人攻撃と受け取らないでください。あなたに対して、いくつか重複したコードを他の関数を再利用してリファクタリングを行うべきだと感じる人がいるからといって、あなたが魅力的でもすばらしい人物でもないと否定されているわけではありません。
レビュアとして気を利かせてください。変更を提案する前に、それが本当に優れた提案なのか、それとも単なる好みの問題なのかをよく考えましょう。議論すべき箇所を選んで、元のコードで明らかに改善が必要な箇所に論点を絞れば、もっとうまくいくでしょう。「ペットのハムスターの方がこれより効率的なソートアルゴリズムを書くことができる」と言うのではなく、「~を検討する価値があるかもしれません」や「~を薦める人がいます」という風に言ってください。
妥協点を見つけることができない場合は、両者が尊敬する他の開発者に見てもらって意見を聞くといいでしょう。
自分の仕事にプライドは持ちつつも、謙虚な姿勢は常に持っておきたいですね。
個人的にレビュアとして気をつけないといけないことは「単なる好みの問題」を押し付けていないか?ということです。
コードレビューは奥深いので実務経験を通して、知見が溜まったらまとめて記事にしたいです。
外部ネットワークからのHTTP(S)死活監視サービス Pingdom を紹介します。
このサービスは
1サイト1チェックだけ無料で使えるので個人サイトの死活監視を設定しました。(無料で使えなくなりました)
無料で使いたい方は https://www.pingdom.com/free/ のURLから新規会員登録しましょう。
2015年3月17日時点ではMonitoring pricingのページには無料プランの表記はないのですが、https://www.pingdom.com/free/から登録すると監視対象1箇所のみ無料で利用できるみたいです。
できるだけカンタンにサイトの死活監視を導入したいという方には Pingdom は無料プランがあるので、とりあえずお試しで使ってみることができるのでおすすめです。
以上、外部ネットワークからのHTTP(S)死活監視サービス Pingdom を導入した、現場からお送りしました。
知り合いがホームページを wix.com で作ってて、独自ドメイン取りたいからそれを気にオリジナルホームページを作りたいと相談されて、そもそも WIX を知らなかったので WIX について調べてみました。
ブラウザからウェブサイトを開いても response が返ってこない…
サーバに ssh しても繋がらない…
仕方ないから、さくらのVPSの管理画面から VNC コンソール経由で確認してみると「UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY」というエラーが出ていることが確認できました。
このエラーを見るのは初めてだったので「さて、どうやって復旧すればいいのかな?」と思いながら Google 検索していると、さくらインターネットからメールが届きました。
件名:
【さくらのVPS】障害に関するご報告本文:
■ご連絡日 [2015-03-01]ご利用中のさくらのVPSサービスについて
さくらインターネット株式会社
平素よりさくらインターネットをご利用いただき、誠にありがとうございます。
お客様にご利用いただいておりますサービスが収容されているホストサーバに
おいて、ハードウェアの不具合によりデータの不整合が発生する状況が確認され
ました。そのため、弊社にて以下の緊急メンテナンスを実施いたしました。
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
作業日程 : 2015年03月01日15時30分~2015年03月01日18時30分
影響範囲 : さくらのVPS SSD 4Gプランの一部
IPアドレスが下記の範囲のお客様
133.242.182.135 ~ 133.242.182.184
作業内容 : ハードウェア交換作業
補足事項 : 作業時間中 VPSサービスへ接続できなくなります。
お客様ご利用のVPSに再起動が発生します。【緊急メンテナンス】
http://support.sakura.ad.jp/mainte/mainteentry.php?id=15625=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ハードウェア交換につきましては 18時30分頃に完了いたしましたが、データの
不整合によってお客様ご契約中のさくらのVPSサービスが正しく起動しないこと
が判明いたしました。弊社にて保持している2015年02月17日のバックアップデータから復旧を行う
ことは可能でございます。当該データでの復旧を希望される際は、本メールの返信にてお知らせくだ
さいますようお願いいたします。また、さくらのVPSのコントロールパネルより、OS再インストールを行って
いただくことも可能でございます。弊社による2015年02月17日時点への復旧が不要の場合は、恐れ入りますがOSの
再インストールによる再構築を実施いただけますようお願い申し上げます。この度はお客様に大変ご迷惑をお掛けしましたこと、深くお詫び申し上げます。
—-
ご不明な点やご質問等ございましたら、本メール返信にてお問い合わせ
ください。今後ともさくらインターネットをよろしくお願いいたします。
─── さくらインターネット株式会社 カスタマーセンター ───────
■Twitterサポート
https://twitter.com/sakura_ope■サポートサイト
https://help.sakura.ad.jp/■FAQ(よくある質問)から調べる
https://help.sakura.ad.jp/app/faq■電話・メールによるお問い合わせ
https://help.sakura.ad.jp/app/answers/detail/a_id/2005
電話受付時間 :平日 10:00 – 18:00(土日祝、当社指定休日は休み)
メール受付時間:10:00 – 18:00(土日祝営業、当社指定休日は休み)───────────────────────────────────
メールを読むと対応方法は「2015年02月17日のバックアップデータから復旧」or「さくらのVPSのコントロールパネルより、OS再インストール」と書いてありますね。
この時間から OS 再インストールするほど頑張りたくはないので、取り急ぎバックアップデータから復旧してもらってサービスを動くようにしてもらうことにしました。