第18回Redmine大阪の感想をメモ。 疲れているので、ラフなメモ書き。 書きかけなので、また後で書く。 【参考】 第66回 SEA関西プロセス分科会＆第18回 Redmine大阪 - connpass 2018/2/3 第66回 SEA関西プロセス分科会＆第18回 Redmine大阪 - Togetter 第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス！ 【１】気象庁のRedmine利用事例の話は、本当に面白かった。 JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。 第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索 第13回東京Redmine勉強会の感想～『Redmineの今と未来』 #redmineT: プログラマの思索 気象庁

第18回Redmine大阪の見所～「チケット管理システムによるソフトウェア開発支援と今後の課題～気象庁のRedmine利用事例報告」 来年2月3日に開催予定の第66回 SEA関西プロセス分科会＆第18回 Redmine大阪の見所を書いておく。 【参考】 第66回 SEA関西プロセス分科会＆第18回 Redmine大阪 - connpass 気象庁の数値予報課におけるRedmine利用事例: プログラマの思索 【1】（引用開始） テーマ～「チケット管理システムによるソフトウェア開発支援と今後の課題」 今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。 気象庁｜数値予報課報告・別冊 第63号（平成28年度）　数値予報モデル開発のための基盤整備および開発管理 気象庁におけるソフトウェア開発プロセスの事例で興味深

Pittsburgh-based Astrobotic’s first lunar lander is set to take off on United Launch Alliance’s new Vulcan Centaur rocket on Christmas Eve, ULA CEO Tory Bruno said. Bruno told the audience at the

ソフトバンクグループが約3.3兆円で買収する英アーム。その最大の強みは「省電力の半導体設計技術」…と考えるのは、一面的な見方に過ぎない。 アームが提供するCPUコアの回路が省電力性能で優れるのは間違いないが、ただ省電力を追い求めるだけなら、より機能を限定したCPUコアを採用するなど別の方法もある。米アップルや米クアルコムは、アームから半導体回路ではなくARMの命令セットアーキテクチャー（ISA）のみ提供を受け、省電力化を含めたCPUコアの設計は自社で手掛けている。 企業としてのアームの最大の強みは、スマートフォンからタブレット、IoT、車載機器、サーバーまで、ARMアーキテクチャーを支える「仲間」となる企業や技術者のエコシステムを作り、そのニーズに合うハード／ソフト技術を先取りして獲得する力だ。 例えばIoTの分野では、アームは2015年にBluetoothソフト／ハード開発の米企業2社と

はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ

git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識

ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

BABOKの最重要ポイントは、要求の品質にある。 そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償（ただ）で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと]（とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける）。 しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。