タグ

参照に関するkraken_eyeのブックマーク (96)

  • スクラムにおける技術的スパイクの進め方

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady(準備ができている)である必要があります (Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください)。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の

    スクラムにおける技術的スパイクの進め方
  • これだけはやっておきたい〜マイクロサービスのデプロイメント - クラウドワークス エンジニアブログ

    Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ?」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ

    これだけはやっておきたい〜マイクロサービスのデプロイメント - クラウドワークス エンジニアブログ
  • 公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ

    みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります(参照)。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ

    公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ
  • 「寝るのが悔しい、もったいない」と考える原因と2つの対策。 - プロジェクトマネジメントの話とか

    こんにちは、wiz7です。男女比8:2(※Google Analytics調べ)の体育会系の部室のようなブログへようこそ!時期的にも、そろそろ制汗スプレーが必須ですね。焼け石に水ですかね。トイレ用の消臭スプレーにしときますかね。 さて、深夜の24時。もう寝る時間です。 「寝るのが悔しい、もったいない……」 「寝たら朝が来る。起きたら会社(学校)だ……」 「もうチョットだけ遊びたい……」 このようなモヤモヤを解消すべく、インターネット上を徘徊し、漫画ゲームに興じて夜更かししてしまう人たち。そして翌日、特に月曜や連休明けは終日「廃人」と化し、怠惰な自分を強く責めてしまうのです。 睡眠の重要性にについては、あえてここでは触れませんが、たった数時間の投資を惜しんだばかりに1日のパフォーマンスを大きく落としてしまう、というような生活は、もう終わりにしましょう。(特に、比較的自由な学生の方々。) 一

    「寝るのが悔しい、もったいない」と考える原因と2つの対策。 - プロジェクトマネジメントの話とか
  • 人にタスクを手伝ってもらいたい時に提供すべき情報 - 虎塚

    タスクがあふれた時、同僚に助けてもらうには、どうすればよいか。逆に、どんな情報を提示してもらえば、同僚のタスクを引き受けやすいか。 切羽詰まっている時には、こういうことを考える余裕がありません。だから平時に考えておかなければならないと思います。 というわけで考えた。 情報の開示 すべての情報は皆に見える場所に記録する 組織で使っているタスク管理ツールやwikiなどに書く チャットは流れるからダメ 以下の項目も、基的に同じ場所に書く 最新の状況の説明 残っているタスクは何か 着手中のタスクは何か 着手中のタスクの完了目処はたっているか アウトプットの定義 タスクのアウトプットを具体的に定義する ゴール、終了条件といいかえてもよい ダメな例は、"Aの構築"とか、"Bの提案"とか こういうフォーマットでこういう目的の提案書を誰向けに作成する、とか Xの構築とYのインストールをしてfoo様に連絡

    人にタスクを手伝ってもらいたい時に提供すべき情報 - 虎塚
  • プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight

    おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする(アカウント情報) プロフィール情報で条件を指定してユーザを検索・推薦する(プロフィール情報) という2つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ

    プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
  • 金融機関の口座集約アプリの危険性について - プログラマでありたい

    先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。(安全なので安心ですという論調は、どうかと思いますが。。。) 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析(スクレイピング)して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション

    金融機関の口座集約アプリの危険性について - プログラマでありたい
  • 静的コード解析でコードの改善を行う - 水まんじゅう2

    コードレビューはしたことがあるでしょうか。 変なコードを書いていないかを確認するためにだれかにコードを確認してもらうという事はよくやります。 誰かにコードを見てもらえるのが一番良いのですが、その誰かがいない場合、機械的にコードを解析して変なところがないかを確認してもらうことが出来ます。 それが静的コード解析です。 Javaでは多くの静的コード解析ツールがあり、多くは無償で利用することが出来ます。 今回はそのうちのFindBugsとPMDを利用して静的コード解析をしてみたいと思います。 FindBugs FindBugsはコンパイルされたバイナリを解析し、不具合を検出してくれます。 例えば、 if("str" == "str")〜〜 という書き方は良くなく、Javaでは以下のように記載する必要があります。 f("str".equals("str"))〜〜 こういった問題点を検出してくれます。

    静的コード解析でコードの改善を行う - 水まんじゅう2
  • Loading...

  • SQLインジェクション対策もれの責任を開発会社に問う判決

    ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ

  • 「イスラーム国」による日本人人質殺害予告について:メディアの皆様へ-中東・イスラーム学の風姿花伝

    池内恵(いけうち さとし 東京大学准教授)が、中東情勢とイスラーム教やその思想について、日々少しずつ解説します。有用な情報源や、助けになる解説を見つけたらリンクを張って案内したり、これまでに書いてきた論文や著書の「さわり」の部分なども紹介したりしていきます。

  • 「自信を取り戻す」ためのライフハック | ライフハック心理学

    私もTaskchuteで細かく自分の行動を追っていたのですが、やはり視点が違うと見えるものは違うものです。 以下のようなことはとゆさんが何度か書いていることなのですが、もう一つ理解できずにおりました。 記録をつけなくても生活できるような、こんな細かいことまで記録していてよかったと思うのは、気持ちに余裕がない時や、自分に自信がない時。 合間合間で、脳の中の自分が責め始める。「今日1日終わったけど、やることやった?」「何もしていない気がする。自分はだめだなあ」などと言ったように。 そういう落ち込んでいる時は、記憶だけだとぐうの音も出ないのだけど、記録があると冷静に振り返られる。 今日のTaskChuteを見てみると、仕事中は最近先送りしていた小さな頼まれ事を意外と数多くこなせていたし、家では予定していた家事は全部済ませられていた。 とゆメモ: 792:不必要に自分を責めなくなるメリット そうい

  • 開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD

    “なぜ納期を守れなかったのだろうか?” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は当に開発者の仕事が遅いせいでしょうか? Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと(S、M、L、XL)、また種類ごと(ストーリー、テスト、バグ)に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目:開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目:変動があるのは、ほとんどがチケットが開始される前(SomedayからBacklogまで)の段階です。これは、関係者が仕様を理解して作業の優先順位

    開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD
  • なぜ自己啓発・ライフハック記事を読み漁っても行動できないのか? - プロジェクトマネジメントの話とか

    君の部屋、散らかっているでしょう? 突然、失礼しました。。。失礼しちゃったのでついでに言わせてもらうと、 膨大な登録済の「あとで読む」はてなブックマーク。これ、ホントに後から熟読して、自分のモノにしてる? ホーム画面・デスクトップ上のアプリアイコンやファイルは散乱していないだろうか? ブックオフやAmazonで買い込んだ「積ん読」状態のの塔は、もはや倒壊寸前ではなかろうか?むしろ天井まで届き「つっかえ棒」になりそうな勢いではないか? 絶え間なく押し寄せる「情報の荒波」に飲み込まれ、もはや溺死寸前の僕たち。アナタは人一倍、向上心が強いはずのなのに、得た情報をなぜ行動に結び付けられないのだろうか?今回は行動に結びつかない原因と、その対策について考えてみよう。 現代人は「ありとあらゆるもの」について肥満状態 あ、挨拶のタイミングが明らかにおかしいんですが、明けましておめでとうございます! 最近

    なぜ自己啓発・ライフハック記事を読み漁っても行動できないのか? - プロジェクトマネジメントの話とか
  • 知られざる「マルチテナントアーキテクチャ」(2)~スケーラビリティのカギは組織ID

    セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。これによってインフラの共有が容易になり、非常に効率的な運用と低コストを実現しています。 (エントリは「知られざる『マルチテナントアーキテクチャ』(1)~SaaSはみんな同じではない?」からの続きです。) しかし、それだけではスケーラビリティやアベイラビリティを実現することはできません。それらの実現には別の技術が併用されています。それはOracleのパーティショニング機能とパラレル機能による分散処理です。 パーティショニング機能の話をする前に、セールスフォースが採用しているデータベースの特徴を見てみましょう。 すべてのデータに振られる組織ID セールスフォースはすべてのユーザーが1つのデータベースを共有するマルチテナントアーキテクチャを採用しています。ということ

    知られざる「マルチテナントアーキテクチャ」(2)~スケーラビリティのカギは組織ID
  • 我が愛しの蔵書管理サービス「MediaMarker」の引用機能がモバイルに対応!読書メモがめちゃくちゃ捗るぞ!

    決して取っつきやすいわけでもなく、見た目も洗練されているわけでもない。だけど、痒いところに手が届き、やりたいことが全て出来てしまう愛しの蔵書管理サービス「MediaMarker」。 以前、中の人(@coanmm)に無理を言って付けて貰った「引用機能」が遂にモバイル対応して、完璧に求めていた形になったので、満を持して紹介したいと思います。 ■まずは、MediaMarkerってなんぞや?MediaMarkerを一言で言えば「蔵書管理サービス」。 要するに、を管理サービス何だけど、Amazonで買えるモノなら何でも管理出来るし、iPhoneアプリや独自メディア(例えばオーディオブックとか、Amazonで買えない独立系な電子書籍、もしくは通信教育の教材)なんかも管理出来る。 百聞は一見に如かずなので、とりあえず僕のページを覗いてみて欲しい。 家の棚に並んでいるや、既に手放してしまった、これ

    我が愛しの蔵書管理サービス「MediaMarker」の引用機能がモバイルに対応!読書メモがめちゃくちゃ捗るぞ!
  • ユニーク制約の使いどころ - 設計者の発言

    前回記事で説明したように、主キーは「ユニーク制約をともなうインデックス」ではなく、「来的なユニークキー(一次識別子, Primary Key, PK)」である。すなわち、「NULL値をとらないし、レコードのライフサイクルにおいて値が更新されないユニークキー」だ。テーブルはユニークキー(候補キーともいう)をいくつも持ち得るが、その中で少なくとも1個は主キーとして位置づけられる必要がある(*1)。 「来的なユニークキー」はわかった。では「来的でないユニークキー」とはどんなものか。その使いどころや効果的なテクニックについて説明しよう。 まず次のモデルを見てほしい。主キーが「顧客コード」であることが<...>で示されている。これに「顧客名+所在地」の組み合わせでユニーク制約({...}で示してある)を与えた例だ。同名顧客名があり得るため、SKには「所在地」も含めてある(顧客名や所在地は正規表

    ユニーク制約の使いどころ - 設計者の発言
  • テーブル関連の「排他性」をモデル上で表現する - 設計者の発言

    どんなに複雑に見えるデータモデルでも、テーブル関連には親子関係、参照関係、派生関係の3種類しかない。ただし、それぞれの関連には排他的なものとそうでないものがある。これを見かけ上区別できるような工夫を紹介しよう。ここらへんを理解しておけば、データモデリングのスキルがワンランクアップする。 まず、参照関係の例を見よう。あるテーブル(B)に置かれたレコードが、別のテーブル(A)上のレコードに対して対応関係を持つとする。このとき、B上のAへのアクセスキーが、B自身の主キーに包含されていない場合、両者の関係を参照関係という(図1)。この場合、B側のテーブルを「参照元」、A側を「参照先(被参照)」といい、B側のアクセスキーを外部キー(または参照キー)と呼ぶ。 図1 ここで、BがAの他にA'の間にも参照関係を持つとしよう(図2)。ここで、BがAとの対応を持つときはA'との対応を持たず、A'との対応を持つ

    テーブル関連の「排他性」をモデル上で表現する - 設計者の発言
  • パスワード定期的変更の効能について徳丸さんに聞いてみた

    高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、今話題のパスワードの定期的変更について、当のところ効果がないのか、その効能についてご説明いただきます。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。いつもはパスワードの定期的変更にはあまり意味がないと主張していますが、今日はパスワードの定期的変更を擁護する立場なんですね。面白そうです。よろしくお願いします。 高橋: まず問題の整理についてです。IPAより9月3日に『「ID・パスワードのセキュリティ対策促進に関する広告等業務」 係る企画競争 』の仕様書(PDF)が公開されました。その仕様書中の行動喚起を促す対策事例の一つに「ID・パスワードは定期的に変更する」 があったので、セキュリティクラスタが騒ぎ出し、その結果かどうかは分かりませんが、9月9日に同仕様書が改定され、パスワードの定期的変更は対策例から削除されました。一連の議

  • データとして登録されるビジネスルール - 設計者の発言

    ビジネスルール(*1)と呼ばれるものの多くは「データベース構造」としてシステムに反映されるが、一部は「データ(インスタンス)」としてデータベースに登録される。その位置づけはシステム構成を考える際に興味深い論点で、効果的なシステムを設計するためのヒントになるだろう。 なお、ビジネスルールは業務システムの「業務構成」か「データ構成」か「機能構成」のいずれかの様態として組み込まれる。これらの3要素はそれぞれ、「役割分担や業務手順」、「データベース構造」、「プログラム仕様」くらいに理解してもらえばよい。これらのうちの「機能構成」に組み込まれがちなビジネスルールをいかに「データ構成」側に持ち込むか。それが、保守性の高い業務システムを手に入れるための課題である。 さて、ある種のビジネスルールは「データ構造」としてではなく「データ」としてシステムに組み込まれる。ただしこれは比較的特殊なケースだ。たとえば

    データとして登録されるビジネスルール - 設計者の発言