http://post.simplie.jp/posts/34
バグを増やさないためにコードレビューのチェックリストを使う | Yakst
チーム内で良くある間違いなどをチェックリストにし、それをコードレビュー時に使う事で、コード自体のレベルを上げつつコードレビューの品質のばらつきをなくす取り組みについて。Trelloなどを開発するFog Creek社のブログの翻訳。 効果的なコードレビューについて書いた我々のブログ記事の中で、チェックリストを使う事を推奨した。チェックリストを使う事で、レビューが継続的にチーム全体でうまくはたらくようにできる。また、ありがちな問題を見つけたり解決したりするのを確実にする、簡単な方法でもある。 ソフトウェア工学研究所の研究によると、プログラマは15から20の良くある間違いをしてしまいがちだという。そういった間違いをチェックリストに追加しておく事で、問題が起こった時にそれを特定し、確実に駆逐するようにできる。 チェックリスト作りに取り掛かるに当たって、一般的な項目は以下のリストのようになるだろう。
ソースコードレビュー時に意識していること｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
もうすぐ春ですね、下條です。 弊社ではプルリクエスト(以降PRと書きます)ベースのソースコードレビューのプロセスがあります。今回はソースコードレビューをする際に私が気をつけていることをまとめてみます。 レビュー方法について まずはレビュー方法についてです。 普段のレビュー 通常はGitHubなどのPRを皆が好きな時間にレビューしています。PRのコメントでレビューアにメンションを付けておくことになっているのですが、つい見逃してしまう場合があるので午後3時をレビュー時間としています。午後3時にSlackに通知が来るようになっています。 もちろん急ぎの時はお願いして急いでレビューしてもらいます。 対面 or 画面共有レビュー 対面レビューは実施コストは高いですが場合によっては有効と考えています。GitHubなどでのdiffを画面に写して一緒にレビューするというやり方が良いと思っています。私が昔勤
コードレビューの際に気をつけること - Qiita
コードレビューをする際と、してもらう際に気をつけるべきだと思っているをまとめておきます。 レビュイーとして大切なこと コードレビューをお願いする前に レビュアーが高いパフォーマンスを発揮するためには、レビューを受ける人の心構えと事前の打ち合わせが実は最も大切です。 特に大きめの変更のコードレビューをお願いする前にすると良いこととしては、 まず、レビュアーを確保する そのレビュアーと大まかな設計の合意をとる という方針でやっていくのが良いです。 レビューしていても、根本をひっくり返すような指摘はしにくいですし、したとしても、それなら1から書いたほうがはやくて良い物が出来るといったことが簡単に起きます。 「レビュー後に直せるもの < レビュー前に直せるもの」 ということを意識して、Issueなどを用いて、出来る限り事前に設計、打ち合わせをしましょう。そうすればレビュアーもすんなりレビューできる
【江戸時代の身分制度論】士農工商から身分的周縁へ | Kousyoublog
2016年五月の初頭ごろだったか、Twitterで士農工商という表記が教科書から無くなっているという話が話題になっていた。そう。もう江戸時代の身分制を「士農工商」として表記することは退けられて久しいのだ。少なくとも一九七〇年代初頭に疑問が呈され、九〇年代にほぼ否定され、その結果として二〇〇〇年代半ば以降、教科書から消えはじめた。 かねてから近世身分制社会について個人的にまとめたいと思っていたので、いい機会と思い改めて研究書籍や論文を読み直したり、新規に関連文献を読んだりして一気にブログ記事としてまとめてみようと思いたったのが運の尽き。なんだかんだで書き終えるまで三か月ほどかかってしまい、かつ三万三千文字オーバーの超長文記事となってしまった。誰が読むんだ。 というわけで、長文を読みたくない人のための簡単なまとめ ・士農工商は職能分担を表す言葉で、社会通念として身分体系を意味するようになるの
AWS データベースサービスの自動バックアップ設定まとめ | DevelopersIO
データベースといえば、一般的に避けては通れないのがバックアップ運用です。 AWSで提供されているサービスで「データベースサービス」にカテゴライズされるもののうち、RDS、Redshift、ElastiCache(※Redisのみ)については自動バックアップ(自動スナップショット)の機能が提供されています。この機能を使えば基本的にはバックアップ運用をAWSにお任せできるのですが、バックアップサイクル等の設定についてはサービス毎に差異があります。 運用をAWSにお任せできるとはいえ、その仕様を把握しておかないといざリカバリをしようとした際に意図したリカバリポイントまで復元ができない、などという事態が発生する可能性があります。 ということで、今回は各データベースサービスの自動バックアップの設定について、バックアップサイクル、バックアップ開始時刻、バックアップ保持期間の3つの観点でまとめてみました
RDSのリストアまとめ « サーバーワークス エンジニアブログ
マスターユーザー名はとDB名は、 新規ローンチ時に作成したもので、 AWSコンソールに表示される値です。 リストア時には新しく作成されません。 セキュリティグループとパラメータグループはAWSからデフォルトで用意されている設定が適用されます。 RDSの設定を変更する マネジメントコンソールのRDSのダッシュボードから[インスタンスの操作]➝[変更]と進めることでパラメータの設定変更が可能です。 パラメータの設定変更画面に遷移するので、変更したいパラメータの値を修正します。 試しに、セキュリティグループを変更してみます。 値の修正後は、[すぐに適用]にチェックを入れ、[次へ]をクリックします。 変更箇所を確認し、[DBインスタンスの変更]をクリックします。 少し待つと変更が適用されていることが確認できます。 値の修正後に「すぐに適用」にチェックを入れずに進めた場合は、手動での再起動やメンテ
AWS RDSのリストア失敗体験談 | Nedia What's up!
今日も例によってAWSシリーズですが、今回は恥ずかしながらRDSのリストア時に手こずってしまった内容を記事にしたいと思います。 RDSとは RDSはAmazon Web Servicesで提供されるリレーショナルデータベースサービスです。 簡単に言ってしまうとMySQLやらPostgreSQLやらをクラウド上でホスティングしてくれます。 なお今回はRDSのリストアについての記事ですので詳細については省略いたします。 私の失敗 一般的なサーバ上でMySQLやPostgreSQLを使っていると、一旦データベースを削除してダンプしたファイルをリストアするという場面が多くあります。 この感覚のままRDSを使って「一旦インスタンスを削除して今日の○○時に取得した自動スナップショットからインスタンスを復元」しようとしました。 RDS管理画面上での私の誤った操作 RDS管理画面でインスタンスの操作から
2.4 トランザクションと排他制御
Symfoware/RDBでは、トランザクション単位にデータベースの更新が行われます。複数のトランザクションが同時に同じデータベースを参照または更新すると、データの矛盾が発生してしまいます。このようなことを防ぐために、Symfoware/RDBは、排他制御を行います。ここでは、トランザクション処理と排他制御について説明します。 2.4.1 トランザクション制御の概要 2.4.2 トランザクション制御の方法 2.4.3 SQL文の処理結果異常とトランザクション 2.4.4 アプリケーションの異常終了とトランザクション 2.4.5 排他制御 2.4.6 資源の競合が起きた場合の制御 2.4.7 行単位の排他を使用する場合の注意事項 2.4.8 デッドロックの対処方法 2.4.9 トランザクション実行時間の設定
リレーショナルデータベースの仕組み (3/3) | POSTD
データマネージャ このステップで、クエリマネージャはクエリを実行するので、テーブルとインデックスからデータを取得する必要があります。そこでデータマネージャに対してデータを取得するよう要求するのですが、ここで次の2つの問題が発生します。 リレーショナルデータベースはトランザクションモデルを使用しています。この場合、「いつでも・どんなデータも取得できる」というふうにはいきません。どこか別の場所で、ここに格納されているデータを同時に使用したり更新したりしている可能性があるからです。 データの取得は、データベース内で実行する処理の中で最も時間のかかるもの です。従ってデータマネージャはそれを見越して、メモリバッファにデータを取得しておき、それを保持しなければなりません。 このセクションでは、リレーショナルデータベースがこの2つの問題にどう対処しているかを説明します。なお、データマネージャがデータを
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016 数年前にNoSQLが登場した当時、NoSQLにはデータの一貫性を保証してくれるトランザクション機能などが十分に備わっていないため、業務システムのバックエンドとして使うのは容易ではないと考えられていました。 しかしその後、NoSQLをバックエンドにした業務アプリケーションは現実にはいくつか登場してきています。ワークスアプリケーションズが2014年に発表したERPの「HUE」もCassandraをバックエンドに採用した、本格的な業務アプリケーションです。 そのHUEの開発に関わるスタッフが、どういう実装ならばNoSQLが業務アプリケーションのバックエンドに使えるのか、それにはどういう意味があるのか、などについて議論したセッション「
Fluentdで、RailsのログをS3に保存する方法 - Qiita
What is fluentd? ログ収集をプログラマブルに実施し、状況に応じた柔軟な対応が実現できるソフトウェア ログの管理を「インプット」「バッファ」「アウトプット」という3つの層に分けて管理 fluentdは内部で各ログデータに対して「タグ」を付与し、管理 fluentdではログの内容（レコード）がJSON形式になっている そのため、アプリケーション側でのパースが容易であるというメリットがある Why Fluentd? : ログ管理への要求 ログの多様化・肥大化への対応 ログ情報を基にした分析の必要性 fluentdの設定方法 インストール方法 様々なインストール方法がある RPMパッケージからFluentdをインストールする (Redhat Linux) DEBパッケージからFluentdをインストールする (Debian / Ubuntu Linux) DMGパッケージからFlu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kobit.in
