タグ

2018年5月15日のブックマーク (9件)

  • 異なる 2 つのツリーをマージ - 深い深いそこは、海の森の宇宙の底

    ある機能Aから派生する並行開発をしているんですが、リポジトリの管理が問題となりました。 そこでは、「今までのリポジトリ構成」で書いてあるとおり、もとの機能のトランクからコピーして別のトランクを作る ことが平然と行われていて、マージが全くできない状態だったんです。 そこで、「新リポジトリ構成」にある通り、ブランチにそれぞれ開発を割り当てて、工程すべてが終わったらトランクに 返して、やることを提案し、やってみることになりました。 このへんの、良し悪しは現在進行中なんで、終わるまでわからないんですが、今日問題となったのは、 今まで開発してたものを、ブランチの機能A拡張案件2にマージしないといけない!ってなわけで、 SVNの異なる 2 つのツリーをマージを使ってみた。 まずは、ローカルにコミットしたい場所をチェックアウト(トランク) ポイントは、下記のところ 元って書いてあるのは、マージしたい先。

    異なる 2 つのツリーをマージ - 深い深いそこは、海の森の宇宙の底
  • ソフトウェアの品質特性モデル JIS X 0129-1(ISO/IEC9126) - A Memorandum

    ソフトウェアの品質特性モデルとは ソフトウェアの品質の指標を分類して体系的にまとめた規格で、ソフトウェアの品質に対する評価に利用できる。 品質特性モデル 品質特性 品質副特性 説明 機能性 functionality 合目的性(suitability) 正確性(accuracy) 相互運用性(interoperability) 機密性(security) 標準適合性(compliance) ソフトウェアがユーザからの機能的な要求(明示的機能と暗示的機能)を満たす度合い。 ユーザ目的に合った正確な動作を満たすか。外部IFや規格、セキュリティ基準を満たすか。 信頼性 Reliability 成熟性(maturity) 障害許容性(fault tolerance) 回復性(recoverability) 標準適合性(compliance) 様々な使用条件のもとで、ソフトウェアの機能が正常に稼働し

    ソフトウェアの品質特性モデル JIS X 0129-1(ISO/IEC9126) - A Memorandum
  • 詳細設計書ってあるじゃないですか。 - 室長のひとりごち

    「詳細設計書ってあるじゃないですか。」 「あるね。」 「『必要ですか』って聞かれたんですけど。」 「そう。」 「必要ですかね。」 「何て答えたの。」 「成果物で決めているなら必要でしょう、って。」 「成果物なら必要だね。」 「『じゃあ、成果物じゃなければ必要ないんでしょ』って聞かれて。」 「何て答えたの。」 「詳細設計書で何を伝えたいか決まっているの、って。」 「質問で返したんだ。」 「まぁ、そうですが。でも、質問の意味が解らないし。」 「そしたら。」 「設計する人とコード書く人が同じならいらいですよね、って。」 「質問が変わった気があるね。」 「まあまあ。」 「それで。」 「同じ人なら確かにいらない、って。」 「マジで。」 「はい。」 「とっても限定されている条件下での話、だよね。」 「うーん、そうかも…しれないですね。」 「今のビジネスでそんな条件下、存在するんかい。」 「わからないで

    詳細設計書ってあるじゃないですか。 - 室長のひとりごち
  • 外部設計ですることは何?

    外部設計はプロジェクトによって基設計と呼ばれたり概要設計と呼ばれたりしますが、当サイトでは外部設計の呼称で統一しています。 外部設計においては、要件定義で文書化したシステム構成図やビジネスフロー、ファンクションチャートをもとに、あなたが構築を任されているシステムと外部とのやり取りを設計・定義していきます。 ある程度規模が大きいシステムでは、以下のやり取りがあることが一般的です。 ユーザーにより画面から操作される。 ユーザーに帳票を印刷する。 データを他システムから受け取る。 データを他システムに渡す。 データをデータベースに書き込む。 データベースからデータを読み込む。 これらの一連のやり取りをするのに必要な情報を、外部設計では設計・定義していきます。 外部設計でやるべきこと 以上で分かる通り、基的にはシステムと外部とのやり取りを決めていきます。 画面操作の外部設計 ユーザーとのやり取

    外部設計ですることは何?
  • MarkdownをWord形式(docx)に変換する - Qiita

    考えを整理しながらドキュメントを書くのにMarkdownが便利ですが、資料を印刷して持ってきてとか言われると困ったりします。 そんな時にPandocを使ってdocxなどの形式に変換して印刷すると便利です。(PDFにも出来ますが、フォントサイズなどの微調整も出来るのでdocxにすることが多いです) pandocは、Haskell製のドキュメント変換ツールです。 対応している形式などは以下を参照してください。 Pandoc - About pandoc インストール インストールは以下を参考にしてください。PDFへ変換するには別途依存するライブラリを入れる必要があります。 http://johnmacfarlane.net/pandoc/installing.html MacWindows向けにはインストーラが提供されているので、それを使ってインストールすると楽です。 Releases ·

    MarkdownをWord形式(docx)に変換する - Qiita
  • 基本/詳細設計って呼び方やめませんか - Qiita

    システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう? 各ドキュメントはどうやって関連付けるといいんだろう? 基設計書と詳細設計書はなにが違う? 開発 なんでこういう設計になっているんだろう? 設計されていない組み合わせのデータはどう処理すればいいんだろう? 試験 試験データのパターンや量はどれくらい用意すればいいんだろう? 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や

    基本/詳細設計って呼び方やめませんか - Qiita
  • LINE 桜川さんの話す「もっと読んでもらうための工夫」が実用的すぎてめちゃいい #AWAsia #LINE_AWA - @d_tettu blog

    2018年5月14日〜16日に、東京ミッドタウンで開催されているAd Week Asia。会社の偉い人から関係者向けのチケットをもらったので行ってきました。 何を聞こうかな〜とパンフレットに目を通していたら「スマホ時代のコンテンツデザイン」なる講演を発見。LINE・桜川さんのお話がめちゃ良かったのでメモを残しておきます。 こんな風に「より届けるべき人に届ける、よく読んでもらうために何をするべきか?」を考え続けてるのいいな〜。みんな読んでね。 ちなみにほか記事は以下 Googleは、機械学習でどうマーケティングを変えようとしているのか #AWAsia - @d_tettu blog 6秒でメッセージを届ける方法とはーーYouTube動画広告の効果的な作り方 #AWAsia - @d_tettu blog 「伝える」は奥が深い。メディア編集者3人が語る”これからのストーリーテリング” #AWA

    LINE 桜川さんの話す「もっと読んでもらうための工夫」が実用的すぎてめちゃいい #AWAsia #LINE_AWA - @d_tettu blog
  • MySQLのZero Dateへの対処法

    MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー

    MySQLのZero Dateへの対処法
  • 失敗から学ぶテスト自動化導入で大切なこと

    Cybozu Meetup : テスト自動化 https://cybozu.connpass.com/event/83960/ テストをとりあえず自動化してみたけど、継続的に運用ができなかった。 そんな失敗を分析し、テスト自動化をどのように推進しているかを紹介いたします。Read less

    失敗から学ぶテスト自動化導入で大切なこと