  |
はてなキーワード: Svnとは
なにか新しい言語やツールなどをプロジェクトに導入するときに「学習コストが高い」という理由で渋るやつが嫌いだ
学習コストってなんだよ。そもそもエンジニアならそれぐらい勉強しろよ。
別にプライベートの時間削れってわけじゃなくて業務時間内の勉強で事足りるだろ。
いつまで Javaの古いフレームワークにしがみついてんだよ。
お前らがいう学習コストを支払うだけで何十倍ものリターンがあるんだぞ。
単語すら覚えられなくて、意味わからなくて、全然理解できなくて、わかってるやつにバカにされて、ちっとも身についてる気がしなくて
わからなさすぎてイライラして、才能ないのかなって落ち込んで・・・・・・
かならずペイするよ！
LAMPの現場だ。コテコテのウォーターフォールで、ソース管理はsvnだしテストはExcelで手動実施、チームメンバーは現状で15人。
要件定義からのサポートなのだが、やっていることといったらひたすらExcelで画面イメージを作る作業だ。
モックアップはあるのだが、テンプレートエンジンに落とし込むことを一切考慮していないので再利用はほぼできない。
営業上がりのリーダーはそのことを理解していない。スケジュールを見ると炎上がほぼ確定している。部外者にはそれを正すこともできない。
リーダーは謎の打ち合わせで業務時間の8割は席にいない。チャットワークで問い合わせても返事はない。
与えられた仕事はどんなにかかっても1時間で終わるようなことなので、空いた時間はトイレに篭るか瞑想するかはてぶを巡ることでつぶしている。
そして技術系の記事を見ていると、みな楽しそうに新しい技術や働き方について綴っている。
この落差は何なのだろうか。
人売りでしか生きていけないような会社に勤めていることが間違いなのか。
そもそもこの業界にいてはいけない人間なんじゃないかとすら思えてくる。
これじゃいかんと、最近、オンラインのIDEでJSフレームワークをいじり始めた。
楽しそうにしている人たちにしてみれば2周遅れの技術だろうが、それでもコードをいじっていると気がまぎれる。
でも、少なくともなにか1つくらい作りあげてからにしたいな。
git は、サーバ側本体とローカル側でバージョン管理ができる。
つまり、SVNではちょっとした一時的な変更のバージョン管理でもサーバにコミットして、全ユーザでその変更を共有するしかないが、
知る必要もないんだろうけど。
ただ、過去の技術ってこうやって無くなっていくんだろうなって実感する。
みんな使うからgithub使ってるし、なんとなくgithub好きだからエディタはAtomを使ってる。
計算機以前の「技術」って積み重ねていくもので無駄になる知識なんて無かったんだろうけど（切削加工の知識とか設計図の読み書きとか）、
計算機ができてから「これまで大活躍だったのに１０年後には知っていても何の役にも立たない技術」っていうのが増えてきてるんだよねきっと
そんな弊社では以下のようにSVNを使いこなしている
Excelでドキュメント作成することがメイン業務といっても差し支えないがない。
それらのドキュメントをSVNで管理するのだが(今流行りのバージョン管理だ)
その際に hogehoge設計書_20170313.xlsx のように日付をファイル名に含めることになっている。
こうすることで以前のファイルを別ウインドウで開きながら作業できるし、
ディレクトリを見たときにひと目で最新のファイルがどれかわかるからだ。
ちなみにドキュメントには必ず 「更新履歴」 というシートが作成され
全ての変更の履歴はこのシートに集約される。
入社したばっかでまだ何もわかっていなかった頃先輩に
「ファイル名に日付をつけて管理していますがそれってSVN使う意味あるんでしょうか？」
と尋ねたことがある。
答えはその日一日不機嫌な先輩の表情で察した。
あの頃に比べて僕も成長した。
今では何も考えずに hogehoge設計書_20170313_2.xlsx をコミットできる。
2. SVNが本当に最新か常に疑う
SVNで作業していると他の作業者と編集しているファイル名が被ってしまうことがある。
そのため作業時にはチャットで 「今から◯◯のファイルを触りますが大丈夫でしょうか?」 と聞くことになっている。
作業終了時には 「◯◯を触ってコミットいたしました！」 と報告することになっている。
先輩方は忙しいため上記の確認/報告をしないことが多々ある。
たしかに実際最新じゃないことがよくあるのでなるほどと思った
今では作業前にコミットログを見てコミットされていないことを確認してから
「このファイル触っていましたよね？コミット済みでしょうか？」 と確認するようにしている
コミットしていないと決めつけるのは失礼なので、
飽くまでふんわりとコミットしたかどうかを確認するのがコツだ(これも成長した結果だ)
場合によっては
「僕がコミットしておきましょうか？」
と付け加える。
こうすることで最新版のファイルがメールで送られてるくるシステムだ。
ちなみに僕の肩書は
だ。
「ローカルに仮想環境たてて開発するとマシンスペック足りない人いるから
みんなで一緒の開発環境上で開発しようね。
→ アホですか？
「Gitは使い方難しくて工数増えちゃうからSVNでソース管理しようね。
ソース触るときは他に開発中の人いないかチャットで確認してね。」
→ アホですか？
あとで検証環境と本番環境でも同じ手順で構築するからコマンドまで細かく書いてね？
chef?ansible? itamae? 自動化するとミスがあったときにハマっちゃうからね。
手動が確実だよ。」
→ アホですか?
「Java8?使ったことないから不安だね。今回はJava7で行こうか。実績あるから安心だね」
→ アホですか?
「JavaEE?使ったことないから不安だね。今回は大規模案件だから使いなれたJavaSEにしよう。
→ アホですか?
「設計書書くときは知識がない人がみてもわかるように書こうね。
もちろんExcelで書いてね。更新するときは更新履歴シートに更新内容書いてね。
ファイル名は日付をちゃんと書くこと。更新したらチャットで報告してね。」
→ アホですか?
こんな会社は僕のとこだけだよね？
元々HTMLが書けない素人向けの仕組みだぞ。Wikipediaでもゲーム攻略Wikiでも素人が覚えて編集してるのに技術者が何言ってんだ。
第二に、保守以降、一つのシステムに複数の改修案件や故障対応が並行するようなことはままあることだが、ソースはSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である。
案件ごとに設計書分けたり、後でマージしたりは、どっちにしろ面倒だと思うけど。
私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。
UMLなどの作図にツールを使用することはあっても、最終納品物としてはExcelに画像として張り付けて提出していた。
もちろんExcel方眼紙については批判もあるのは理解しているが、開発者、運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。
そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。
設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。
開発者、運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwikiの知識がほとんどない。
彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwikiを用語集として活用していたそうだ。
wikiには顧客業務の専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。
そういった運用をしているうちに彼はwiki自体を設計書とできないか考え、調査したところ実際にwikiを設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。
私も今調べてみたところwikiで設計書を書くという運用をしている会社もあるようだが、メリット・デメリットがwikiの知識があまりない私には判断しかねている。
ぱっと思いつくデメリットとしては、第一に、やはりマークアップを記述するコストが非常に大きいように思える。
記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコストが必要となるように思える。
第二に、保守以降、一つのシステムに複数の改修案件や故障対応が並行するようなことはままあることだが、ソースはSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である。
メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。
第二に、改訂履歴や差分が標準で用意されていることもメリットであろう。
第三に、検索が容易であることがあげられる。この点はExcelと比較して十分大きなメリットだと思っている。
私がぱっと思いつく限りではこんなもんである。
はてな諸兄の中にwikiで設計書を書いたことがある方がいれば、メリット・デメリット、その他運用において気をつけるべきことなどあればご助言願いたい。
なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。
そのため自社の標準の設計書テンプレートを使用する予定だった。もちろんExcelである。
また、設計書作成に使用するツールでExcel、Word以外の素晴らしいツールがあれば教えていただきたい。
どうかよろしくお頼み申し上げ候。
テキストエディタが秀丸推奨。というかエディタに金を出してくれない。
OSSのエディタが増えてきたにも関わらず、意識低いので秀丸メインが多い。
前述の通りようやくSVNが導入されたけれども、Githubの提案は「英語で使いづらい」という理由で却下。
総務だろうと何だろうと全社員がrootで見ようと思えば見られる状態。
性善説に頼りすぎだろ。
ReactやAngularJSといったモダンなものは難しいという理由で俎上にすら乗らない。
既に開発が打ち切られたjQueryプラグインなんかを当たり前のように使う。
当然開発が打ち切られてるもんだから最新版のjQueryでは動かない。
結果、特定プラグインを動かすためだけに複数バージョンのjQueryを読み込ませたりする。
にも関わらず「何で遅いのか」と問題になったりする。
コード見ろよ。
Slackやチャットワークはおろか、Skypeなども使われていない。
受信するメールの量が多いため当然取りこぼしも増える。
当たり前のようにIE8対応が仕様書の必須要件に含まれている。
最新ブラウザ以外の対応に別料金でも取ればむしろ工数と金になるものを、無知なので最低要件に含めてしまう。
何度言っても理解しない。
もちろん、別にこれがダメってわけじゃない。いやダメなのもあるけど。
「これ使えてるだけまし」って人もいるかもしれない。
ただ、数え役満っていうのかな、技術力の低さがインクリメントされていって、現状の「技術に明るくない我が社」を作ってるように思う。
自分が少しずつ会社を変えていけばいいのはわかるけど、決定権持ってる人間が技術に明るくないと、枯れた技術がいよいよ朽ち果てる寸前まで現状をよしとする。
それが、うちの会社。
気がついたら「まともな技術持った人」が全員辞めていた。
いまは別の会社に勤めているが、以前の会社があまりにも残念だった。
ちょっと気持ちが落ち着いてきたのと、落ち着いてきたものの誰かに知っておいてもらいたいので記すこととする。
例によって特定を恐れ、ある程度はぼかすものとする（が、事実である）
昨年の夏頃から転職活動を始め、自分なりに納得した上で初冬に転職した、理由はUターンである。
小生は都内でシステム開発の職に就いていたが、転職先も地方のシステム開発である。
Uターンということもあり、年収や仕事内容が下がることは覚悟の上だった。
仕事の内容が下がるとは、やはり都内でイケイケな技術を使って、イケイケなサービスを作っていた側からすると、劣るということである。
断りを入れると、すべてが転職活動の失敗に紐づくし、それは自分の責任の以上で以下ではない。
が、考えていた以上の煮え湯を飲まされることとなる
一例を出すとする。
まず前提
そこでは、とあるシステムのパッケージ開発とその納品作業（カスタマイズ含む）を行っていた。
納品作業には顧客との動作確認や他システムとの連携テストが含まれる。
うすうすおかしいなっと思うことがあったが、連携テストの際に辞めることを決意する決定打があった。
コレである。
なんかよく分からない叱責の中で、この言葉がでてきたのである。
耳を疑った。
多分人生で初めて、耳を疑った。
いままで信頼してきた自分の耳を疑った。
そもそもこの会社では到底SVNとは思えないSVNの使い方をしていた。
なんせソースコードの改修箇所は、Excelで管理されているのだから。
ちなみに想像つくと思うが、ソースコードに改修番号みたいなコメントがあって、その改修番号でExcelと紐付いているという。
そんなこんなでソースコードにはどこぞの納品先でカスタマイズされた分岐やらループやらが散在して、なんのことかよくわからなくなっている。
まぁやり方はそれぞれだから百歩譲って許そう。
しかし許せないのは、あたかもそれが正解かのように叱責され、でてきたあの言葉である。
これを言ってきた連中は新卒で入ってずっといるor長いこと会社にいるっといったメンツである。
毒されている、というか技術者としての向上心もない、もはや彼らはこの会社でしか生きられないだろう。
「ごめんね、ここでのSVNの使い方はこうなんだ、いま改善しようとしているところだから、とりあえずは我慢してね」
とか言いようがあるだろう。
それもなく、運用ルールを説明もせずに間違っていたら怒るという。
（彼らは説明したと言っているが、間違いなくいっていない。こんなルールを聞かせれて覚えていない訳がない、彼らのなかで常識となっているから言ったと思いこんでいるのだろう。）
ボカしているのでうまく伝わらないと思うが、これがことの顛末である。
もちろん他にも首を傾げるところはある、けしてコレだけではない。
書いてて思ってが本当に内容をボカす必要があったのだろうか。
なぜなら彼らは、はてブも知らなければ当然ながら増田も知らないだろう。
故にこの増田がはてブのトップにきたとしても、みることはないだろう。
もうちょっとだけ、なんだかなーっと思ったことを言わせてほしい。
例によって彼らもソシャゲをする一端のサラリーマンなわけだが、Ingressを知らないことには驚いた。
別にIngressを知らないからレベルが低いと言ってるわけではないが、それぐらい知っておこうよっていうことが多々ある。
どうやったら防げたのだろうか。
（それはない、人のやる気さえを奪う負であったから、ここにいたらマイナスでしかない）
やっといろいろ考えられるようになってきたので、今回まとめてみることにした。
賛同してくれる人がいたら嬉しいです。
最後に
https://moneyforward.com/engineers_blog/2016/07/07/ruby-core-201606/
[#11741] Migrate Ruby to Git from Subversion
またこれか。
いつも「なぜRubyはGitに移行しないんですか」とかいうスレッドが立つんですけど、結論としては簡単で、移行するモチベーションがある人がいない。外野でガヤガヤ言うだけの人がどんなにたくさんいても無意味で、きちんと結果にコミットしていく係になるだけの気概のある人が必要で、そういう人が出てこない限りは何も変わらないと思います。
ひとしきりゲラゲラ笑ったあとゾッとするよね。生産性の低い方法をとりつづけることを変えようとしない、コミッタ陣のその老害っぷりに。
「SVNからGitに移行する」というのはそれ自体は開発手法の変化において本質的とは思わない。重要なのは、パッチをGitHubのpull-requestやGitLabのmerge-requestのような、差分を見ながら細かく議論できるウェブインターフェイスを使って適用していくことだと思ってる。だからGitに移行したいというリクエストを「またこれか」「移行するモチベーションがある人がいない」で済ませるのは、そういうpull-requestベースの開発手法をよしととしていないってことでしょ。それでいいの？
別におれはRubyコミッタじゃないしパッチ送ったこともないし、Git移行の作業を手伝うつもりもないよ。だって関係ないもん。ただ、いちRailsユーザとしてこのRuby開発陣の老害化にはちょっと背筋が寒くなる。自分たちが老害化していることについて、もっと危機感をおぼえたほうがいいんじゃないのかな。
http://anond.hatelabo.jp/20160629082647
な～んかこういう話聞いてるとあまりに世界が違いすぎて胡散臭くなるんだよなぁ。
まず、上場企業なんか近寄ることもないからIRなんか出てないし
公開されてるコードなんてねぇよ。
GitHubなんてまず使ってねぇし、そもそもセキュリティ的にそういうの使えねぇし。
SVNどころかCVS使ってるとこも普通にあったよ。※しかも1年前とか。
デプロイも基本どこ行っても手動だしね。
やってることが良い悪いは置いといて違いすぎて全く参考にならないんだよね。
いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。
これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事。
で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。
公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社の評価という点では使えない。
GitHubに会社のアカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトのコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリにコミットしているかもしれない。
社長はエンジニアを信頼しているか。CTOがいる場合は、CTOと社長に信頼関係があるか。
技術は手段に過ぎない、ビジネスへのビジョンが大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。
技術を目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。
もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいからバージョン管理やインフラなどの下回りを一新したい、既存の社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。
この話は技術者ならば誰から聞いてもいい。もし面談の過程で技術者がでてこなければ、その会社は諦めよう。
ここでいうデザインは「サービス設計」のことね。デザイナー出身のマネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。
企画、デザイン、プロトタイピング、開発、リリース、改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。
これは現役の技術者から聞こう。実際に自分が体験することになる日常になるのだから。
外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋のエンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。
以上。
"見出しでエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。
CTO含む
人によるとは思うけど、俺が関わった会社のプログラマの年齢の傾向から言うと全員あてはまる。
過去の栄光を引きずり過ぎ
過去にそれで納品したか、褒められたかしらないけど、遺物を自慢しすぎ
今の時代にそぐわないプロダクトや、フローを自慢気に話されても何の得にもならない
「自動化とか意味ないでしょ、ドキュメントありゃ誰でもできるよ、DBのマイグレーション？めんどくせえ、スキーマのダンプ管理しろよ」
はあ？どんだけ時代に逆行してるんですか？CTOがそれいっちゃオシマイでしょ。時代の流れ読めないの？
そう言ってるヤツのおかげでどんだけチームが苦労してきたと思ってんだよ
「PHPとか誰でもできんだから、フレームワークとかいらないでしょ、そんなの使わずにスピーディに仕事しろよ」
はあ？ひとりでやってろよ
口は達者だけど、svn や git 使えない。svn も使いたくないけど。
誰かの書いた独りよがりのコードのせいで、リリースはだいぶ辛かったりする。
それが最近は自動化や、フレームワークのおかげで、リリースの負荷は軽減されてる。それを全然鑑みないのはマジでクソ。
技術力はひと昔前のトップクラスなのかもしれない（多分そうではないと思っているが）が、マジで迷惑
属人的な要素を排除しようと、自動化やCIでヒューマンエラーを極力抑えても、俺様な一言でまたプロジェクトが壊れる
あまりコミニュケーションが得意ではないのもあって、入社直後は非常に苦労した。
正直人見知りだったのでわけのわからないことをのたまっていた時期もあった。
とはいえもう4年目であり色々と手馴れてきて精神的にも余裕ができてきた。
しかも、最近の現場は9時-5時で帰宅できるようになり肉体的にも余裕がでてきた。
と、ここらでレベルアップを図りたいと思っており色んな設計書の問題点を指摘した記事とかを読み漁ってきたわけだが
アジャイルだの詳細設計書がゴミだのいろいろ指摘しているのは見かけるのだが今の自分の現場と環境があまりにも違いすぎてピンとこないのだ。
なんせ、入社してからやったのがガチガチのウォータフォール型の開発でアジャイルだのなんだのをまったくやったこともないからだ。
Gitなんて使ったこともないし、eclipseでSVNでソースを管理し、古いシステムならCVSだって未だに現役がちがちだ。
幸いにもドキュメントはがっちり作ってあって過去のシステムがどういうものなのかはよくわかるようになっているが。
もちろん転職しちゃえとか色々まぁ考えようはあるが別に今の会社に大きく不満があるというわけではない。
そこでＳＥ経験の長いお歴々に色々尋ねたいことがある。
http://nantonaku-shiawase.hatenablog.com/entry/2014/05/18/012107
↑上記のサイトでウォーターフォール型開発の例を逐一説明してくれているがこんな一文がある。
ネットで検索すると、みんなが批判している。私も作ったことがない。というか時代遅れと言われがちなSIerの私ですら書いたことが無いのに、書かせる企業 is 何。
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
EXCEL設計書 Vol.1 怪文書大公開 | Same Old Lucky Day
詳しすぎる詳細設計書 - SiroKuro Page
ネットで検索すると、みんなが批判している。私も作ったことがない。
俺は入社してからずっとガチガチに詳細設計書を書いていたし、先輩も皆書いてる。
一体どこの世界の話なんだ。
いくつかの現場にも出向したがそこでも普通に詳細設計書を書いていたぞ？
どういうことなんだこれは。
でもよくよく考えたら、なんだか説明されている詳細設計書と機能設計書は俺が書いている「詳細設計書」ではひとつにまとまっている気がする。
そもそもそんなのないかも知れないが。
そこで尋ねたいのは事例として機能設計書や詳細設計書の具体例が欲しい。
書籍でもWEBページでもなんでもいい。
そうじゃないとなんだかそもそも話に付いていけない。
あと、詳細設計書がかけなくなりそうだ（切実）。
ところが俺の住んでいるところではExcelにテスト項目を俺が書いて俺が単体テストを手動でやって、結合テストも俺が手やる。
結果列に○だの×だの書いて失敗したらまたやり直しだ！
延々とこれを繰り返す。
別にそれがいやだといってるわけじゃなくて（嫌だけど）、皆テストとかどうやってんの。
テストとかそもそもやってんの？
アジャイルだの何だのに手を出すのもいいのかもしれないがそもそもウォータフォールなV字モデルをぜんぜん理解し切れてない。
誰か教えてくれ。
