  |
はてなキーワード: tracとは
結論を最初に書くと、作家がやりたいのは「小説のバージョン管理」ではなく「出版プロジェクトのタスク管理」と「成果物の品質管理」なのである。
数年前に「家事をRedmineで管理すると捗る」という記事が流行ったように、それと同じことが作家界隈でも散発的に起きていると考えたほうが実情に近い。
「WordやG Suiteの校正機能じゃダメなの？」に対する返答は「WordやG Suiteにはタスク管理ツールが付いてないからダメ」。
本当はGitHubである必要はなく、RedmineやTracとWordを組み合わせてもいいのだが、「ハンマーを持つ人にはすべてが釘に見える」のでGitHubのためにGitを使おうという本末転倒な議論になりがちな印象がある。
逆に「バージョン管理はあるがタスク管理と品質管理がない」環境の例としてはウィキペディア（MediaWiki）がある。
MediaWikiはすべての版をバージョン管理しており、差分も履歴も見られるが校正にはあまり向いていない。ウィキペディアの文章があまり洗練されないのは支援ツールの不在による部分が実は大きい。
の2つで、それを下支えするためにバージョン管理システムは必要だがGitほど多機能である必要はない。むしろRCSくらいシンプルなほうが理解されやすいのではないかと思う。
今自分が何をすべきか？というのが Webから表で 上から順に見ればいいみたいなふうにちゃんと管理されていますか？
どうも、作業全体が、口頭指示と思いやり で出来ていて 深度が深い人間（１つの事を深くやる）タイプには不利な指示が出ているように見受けました。
多くのことを浅くやるタイプと、１つの事を深くやるタイプといますので、指示されたことが管理されて、ツールで表になっているといいかと思いました。
個人的には、よくあるケースだと思いました。Tracとか良いですよ。
あと、深度の深い人間の下には、あまり人は付けられないですね。よくも悪くも。
なぜ応用がきかないんだろう？ ＜＞ なぜ簡単にこの方法を諦めるんだろう
私も、１つのことを徹底的に、すこし、問題があるぐらいでは、変更せずに徹底的にやります。大概の場合はあまりよい結果は出ません。
とはいえ、それが研究ですし、であるからこそ、いくつかの分野では人に期待されるほど特化できているのだと思います。
よく、周囲から、どうしてあなたはコレができないの？と応用を言われるので、じゃぁ、あなたはコレができるの？と返すと、それは専門知識だからと言われます。
しかし、応用ばかりやっていたら、専門知識は身につかないわけで・・・バーターでしょと言いたかっただけなのに、
応用に特化した人たちは、自分達ができることは、簡単なことで、 深い知識は専門知識だから、となぜか、分けるみたいです。 でも、それはおかしい。
今PJTマネージャーやってるけど、自分のToDo・スケジュール管理できないスタッフがほとんど。
もし、プロジェクトマネージャの意味で書いているんだとしたら、"PM"とか"プロマネ"じゃないのか。
"Java"を"JAVA"って書いたり、"Los Angeles"を"ロス"って略すぐらい恥ずかしい。
だから、彼らのToDoをこちらで管理して、進捗がどうかメール/電話で確認(彼らから報告をあげてこない)して、 期限破った報告してこないからこちらから連絡して。 メールに返信してこないから、送ったメールにこちらからRemindかけて(この管理はかなりめどい)。
開発者が仕事に専念できる環境を用意するのはPMの仕事に含まれると思っていたのだが違うのか？
また彼ら同士の間でToや電話でやりとりして共有されていない全体に影響を与える情報を、電話で聞いて。 なんで全体のスケジュールに影響与える話をToメールでして、管理側に連絡してこねーんだよ。 全体メールに電話で返すのは良いけど、なんでその結果共有しねーんだよ。 結果だけでも共有してくれないとスケジュールや管理に影響するって理解してるのかな。
"To"って何？メールを送信することか？
あと、外注を使うときは、電話なんかでコミュニケーションコストがかかる分、余裕を持っておいて…、
スケジュール建てて、遅延するからリスケして、アウトソージング先の人に謝って。 また遅延するからリスケして。
"アウトソージング"ってどうやったらそんなタイプミスできるんだ。
どんなに酔っぱらっていても、キー配列からそれは有り得ないと思うんだが。
あれか？俺が辞めた会社の上司みたいにブラインドタッチもできないのか？
いや、できなくてもいいけど、投稿する前に文章少しは読み返せよ。
お前、客にも誤字脱字が入った文章送ってるだろ。
そんな文章送られると、読まされる側もイライラするんだよ。
文章を読めば書いた人間の知的水準が分かるというが、これだけ誤字がある時点で知的水準が低いことはあきらかだな。
御愁傷様。
この仕事辞めようと思っている。
学校でC++とかJAVAとかVBとか…色々ごちゃごちゃ習ってたけど、正直現場のノウハウなんぞサパーリな状態だった。
だから、その会社にプログラマが居なかった事は物凄く不幸だった。
WEBシステム開発部門を作るという事で、私を含めプログラム未経験者が二人採用されたんだ。
細かいこと言うと、私と一緒に入社した人は、一応PHPやPerlは組んだことが有るけど、「現場のノウハウを知らない」という点は私と同じだった。
入社してからは、もう全部手探り。
開発環境の整え方なんぞ全然分かってない。
取り敢えずPHPやれ、と言われたから、結構必死で勉強しながらメールフォームとか簡単なコード書いた。
当時は画面が切り替わる度に変数が初期化されたりするのが不思議だった。
一緒に入った同僚は、「Postgre専門だからMySQLはよく分からん」と言う。
仕事の渡され方は大概丸投げ。
その仕様ってのが結構曖昧。何というか、「流れ」だけ説明される。
「管理画面で商品を登録すると、商品一覧に追加されるんだけど、登録する時に一緒にカテゴリを設定できるように…」
「カテゴリは大カテゴリ・中カテゴリ・小カテゴリがあって、管理画面で登録できるように…」
とか、そんな感じ。
こういうのを聞いてプログラミング出来るのが当たり前なんだろうけど、私は凄く苦手だった。
苦手だからってやらない訳にはいかないからやってたけど、難しく考えるからだろう、時間がかかった。
後、基本的に画面イメージがない。
仕事を渡されると、全部任される。
テーブルの設計をしながら仕様を確定していって、画面イメージを作成していく。
最初の内は、正規化すら全然知らなかったからぐだぐだなテーブルばっかり設計して、コードを組む段階になってヒーヒー言ってた。
最初から書き直す事もしばしばだった。
もっと効率良くやりたい、と助言を乞おうにも、先輩なんて居ない。
同僚はその辺の作業進行は上手いものの、開発レベルは私と同じぐらい。コードはスパゲッティ。
友人達もプログラムやってたりするけど、WEBプログラムじゃないから相談しても色々と噛み合わない。
仕方がないから、うまいやり方は無いか、とひたすら暗中模索でやってきた。
で、そんな事を1年程続けた辺りで、長年プログラミングしてきた人と交流する機会が有った。
短い間だったけど、その人が教えてくれた知識でかなりショックを受けた。
開発環境の整え方とか、テストケースとか、フレームワークの事とか、えーと、まぁ、なんて言うか、プログラミングの考え方（みたいなもん）とか。
（ちょっと上手く言えない。現時点でも私は、とてもじゃないが自分の事をプログラマだなんて胸を張って言えない程未熟だと思っているし）
そして、ショックを受けたのは同僚も同じだった。
正直今まで自分がやってきた事の全部をひっくり返された気分だった。
全部が全部無駄だったという訳じゃないが、今まで非効率的で馬鹿で遠回りな事ばかりしていた。
その後はSubversionやTracが導入された。
同時期に私は新しい案件を任された。
その案件の規模は小さめで、私は今まで不安定だった開発スタイルを整えようと、半分賭けでその案件をcakePHPで構築しようと決めた。
無論、全然分からないから参考書とか公開されてるソース見たりとか、ネットの情報とかで勉強しながら、だけど。
symfonyとかZend Frameworkとかでも良かったと思うんだけど、
たまたま先のプログラマの人がcakePHP使ってる、と言ってたから「じゃあそれにするか」とcakePHPを選んだ。
違いも分からんから最初は何でもいいや、と思ったってのも有る。
何度も躓いたり挫折しかけたりしたが、なんとか構築しきった。
つたないものでは有るが使い回しの効くメソッドなりを作れたし、正直凄く嬉しかった。
その頃には、ある程度ではあるがフレームワークでの開発が手に馴染んでいた。
そんでも一人でじめじめコーディングするスタイルは変わらなかったから、コードの中身はお察しくださいなスパゲッティ。
もうこの会社に居続けても意味が無い、と思った。ひとりよがりなコードを量産するだけだ。
だから、「今年いっぱいで会社を辞めようかと思います」と告げた。
それが大体半年前。
今年が終わるまで＠2ヶ月ぐらい。
こんな経験年数半端な人材って、需要有るんかなぁ。女だしなぁ…、というかそもそも転職回数が多いのが一番痛い。ブラック企業ひきすぎ。
無知を乗り越えるという性質のやる気はあるから、がらっと業種を変えても良いかもしれない。
というか、ぶっちゃけ残業時間がえらい事になってたから、IT業界はもうしたくないな、と思う一方で、
やっぱりプログラム好きだからプログラマやりたいという思いが有る。
でもプライベートでやりたい事あるから、あんまり仕事で時間を割かれるのも困る。
後、親が元気な内に孝行しときたい。
こないだ、カーチャンのスレ見てたのがかなり効いてる。
「あんた転職するんでしょ？ 転職前に休み作ってよ。一緒に旅行行きたいから」とか言ってるし…
「仕事が忙しいから」とか「疲れてるんだから休ませてくれ…」とか言って全然孝行出来なかったから、そろそろ生活における仕事の割合を減らしていきたいところ。
でも、
難しいよなぁ。
転職、どうしたもんだかなぁ。
ステータスを最初に語ろう。入社２年目SE。色々見えてきたが、学術とやらの呪縛から未だに抜け出せない２０代後半。
クソッタレ生意気盛りで、酒もクソ飲んでいる今の中で語らせてほしい。
どうやらオレは会社員に向いていないらしい。と、いうのも今、新入社員も同然の今の立場で、酒の力も借りながらこんなことを書いているからだ。
彼ら（先輩社員および、そこから連想する一般社会人、そして、それが正解と思う冷静なオレ自身）が思うなかでどうやら彼らは時間とやらは永遠らしい。そして、時間軸は永遠に（もしくは永遠同然に）思えるらしい。そう、それは独立した概念ではないと。ソコで永遠ってヤツを保証しようって話らしい。
そんな事はなく、決して決して人生の中ではっていうか、今の社会人軸の中で感じる時間というヤツはたかだか64bitくらいにおさまっちまうことに気づかない（イヤ、マジで。tracでも数千万のチケットとかでも浪費するのは難しいのを知ってる？）。
マジで。十分ってヤツにヤツらは満足しない。そしてそれに気づいて満足する値がとんでもなく低い。お前ら、χ０とχを一緒にするなって。
メタって何なの？理解してる？高々十数桁の浪費で理解できちゃうんだぜ？有限に収めちゃうのがドレだけセキュリティに有効かって知ってる？セキュリティ的には有限の方が有効って知ってる？関係ないけどさ、２ちゃんのログのアドレス管理とか見てみろよ、高々数十桁だぜ？
結局は人間がどうこうするって話なんだと思う。こんな感じでデータをやっていこうと思います。と。
そして、しっかり考えられてる形跡がない。とりあえず、発注にあわせろと。
Amazon.comやWikipedia.orgのURLの使い方なんかすばらしいじゃないか。基本、文字ベースで表そうとしている。っていうか、基本、データが（ほぼ）一意なんだ。
そのおかげで結構無駄な事してるけどな。もう少しショートにできないものかね。
SEども(そして、酔いが醒めたオレへ)。あと１００年（適当な数値）はSEは変わらない。っていうか、うん、多分。なにを持ってかわるとするか分かんない。
でも、大工は何千年も変わんない。モノを作る人間ってのはそんなもんだ。評価が欲しければ金を時間とかで割るが良い。（相対評価）÷（絶対評価）がキサマの価値だ。笑っちゃうね。ソコへ絶対評価を求めるなんてさ。おっと、時間は光速へ対する相対評価って言わないようにな。人間にとっちゃソレさえも絶対評価になるモンだぜ？
さぁ、オレへ。酔いがさめたら、来週上司へ謝罪へ行け。お前はそんな人間だ。
独立しても、勉強しても、何をしても、結果はない。クソはクソだ。それは歴史が決めるが、お前は現在でもクソだ。現在から未来に評価をまかされちゃいない。だってお前はそれを実行しようとしない。REST IN PEACE、くたばれ。
うまくやる方法を考えてみた。
【目的】
社内でオープンソースのプロジェクトを行うことにより以下の４つの価値を生み出すことができる。
１．部門間におけるノウハウの共有
２．外部に公開した場合の宣伝効果
４．仕事そのものを作る効果
（４補足）
・新入社員の研修などが発生した場合に効果的に仕事を割り当てることができる。
・在宅勤務をせざる得ない状況における作業の割り当て。
【前提】
基本的に下記の事項を前提として考察を行う。
１．社内の人間であれば、誰でも参加できる。
２．途中で各人の任意のタイミングで抜けても、問題とならない。
３．社内の人間であれば、だれでもアクセス可能なWebサーバー上で情報を管理する。
ただし、必要に応じてアクセス制限をかけることができる。
インターネットに接続されている、Webサーバーは存在しているものとする。
４．各開発者は場所的、時間的に同じところにいないことを前提とする。
以上の前提より、下記の機能を有したWebサーバーの準備を行う。
１．構成管理機能
簡単にソースコードの取得、更新を行えるようにして、その履歴を残す。
２．Wiki
３．フォーラム
これにより、場所と時間にとらわれずに意見交換を行うことができる。
これにより、リリース時期の予測、作業の有無を効果的に確認できる。
５．テスト管理
これにより、リモート環境であってもリアルタイムにテストの進捗状況を確認できる。
案：TestLink
ReviewBoardの使用
http://blog.monospace.jp/2008/03/24/reviewboard_installation/
（※要調査）
７．フィードバックを受ける場
関係者のモチベーションを保つため、成果物に対して、フィードバックを受ける場を作成する。
案：社内のソーシャルブックマーク、アンケート機能
【効果的な手法】
その他、効果的な開発の進め方を考察する。
xUnitでテストコードを記述することにより以下の効果がある。
・修正後でも修正前と同じ動作するかどうかが、確認できる。
これにより、人の作成したコードでも修正を行いやすくなり、前提１、２の人の出入りに対応する。
自動ビルドを定期的に実行する。また、１のxUnitを使用して単体テストの失敗も監視する。
これにより、サーバー上にコンパイルが通らないソースコードや単体テストに失敗したコードの存在をチェックすることができる。
これは不特定の人間がかかわった場合に異常を検知するためである。
３．短期的なリリース
開発者のモチベーションを保つため、一定のめどがついた時点でα版という形でリリースを行う。
だめだまとまらん。
マシン語の話
まず
だいたいそういう人達は人ハードウェア知識云々をもとより人から言われるまでもないだろうし
shi3z氏が檄を飛ばす想定読者もおそらく俺のようないわゆる受託業務システム開発を
しているような人間たちだ。
べつに低レベルアーキテクチャの知識はあればあったで困らないのは事実だし
プロなら最低限は知っとくべきレベルというのは実際あるし
無駄だと言う気はまったくない。
ただ
もし、仕事でその知識を認められたい、あばよくば給料やキャリアの足しにしたい、
などという下心があるのなら、下記のことは知っておくべきだ。
『少なくとも自分のいるチームのNo.1にならなければほとんど評価すらされない。』
はっきり言うと俺らの世界では
規模と場合によっては会社に一人か二人いれば十分なんである。
ある意味ではフルタイムで雇うほどの需要すらないとさえいえる。
たまに必要なときだけ相談したり調査を頼めればすんでしまうわけで、
地味なプログラムを組んだりしてるのだ。
ましてチーム全員がプロファイラやデバッガを使いこなせる必要なんか全然ないんである。
上で書いた「プロとしての最低限のレベル」ってのは
バイナリハッカーに相談すべきときに相談できる判断力があるかってことなんである。
（故にそれはできて当たり前であって評価の対象にはならない。）
しかし別の面から見ると
shi3z氏みたいなバイナリハッカーだけでは全然足りないのだ。
ＤＢのインデックスやパラメータの最適化や分散設定ができるやつは身近にいるか？
Apacheやルータ、ロードバランサの設定や専門家は回りにいるか？
先輩から教わったCVS(やSubversion)の使い方がどうもgoogle様の
ご宣託と違うような気はしないか？
共通ライブラリやお仕着せのフレームワークの仕組みや動作に疑問はないか？
等など、、、
状況によっては
むしろ自分にとって手の届くニッチ（はまりどころ）があると喜ぶべきかもしれない。
上記のほとんど全部をこなせるような人間が稀にいないわけではない。
しかし臆することはない。
目と手は２つづつしかついていない。
人の時間とモチベーションは有限かつ希少な資源であり、
