  |
はてなキーワード: バージョン管理システムとは
http://anond.hatelabo.jp/20170126221358
F系子会社。ちょっと前まではF本体にも常駐してた。雑にコメントしてく。
↑これはある。会社や人によってはちゃんとやろうと取り組んでるトコもあるけど、グダグダなのが殆ど。法令違反って認識すら無いやつも結構いたりするから反吐がでるよね。
↑これは現場による。
↑メモリ4GBノートPCがデフォなのは同じ。でも、OSは普通に64bitも指定できるし、デュアルディスプレイがデフォ。
↑普通にGitlab
↑そんな変な規約ない
SubversionやGitだったら迷わずそうしてる
かなり時代錯誤を感じる｡ネタであって欲しい｡もしかしてITリテラシー低すぎ？というか､好きなソフトウェアは何なんだよ｡ノーカンプラ？？？
高い
"Excel" なら安い｡アプリの数百円からデスクトップ版の1.5万程度｡ていうか､¥14,526で売ってる｡
https://www.amazon.co.jp/dp/B015SMNVAK/
重い
Excelが重いとかどれだけ糞スペ｡
よくバグる
それはExcelに限った話ではない｡ソフトウェアである以上多少のバグはしゃーない｡つかリソースが糞なせいじゃねーの？滅多に落ちないが｡
検索性が悪い
ブラウザでOK｡
タブ表示が面倒臭い
ショートカットご存知無い？馬鹿？ページスクロールも面倒臭そうだな｡見なくていいよ｡
バージョン管理システムで管理した場合Diffが見にくい
それはそのバージョン管理システムが糞なんだろ｡Diffを見るだけならWinMerge+xdocdiffで普通に見やすいが｡馬鹿なの？
嫌ならマクロで一括解除＆復元でもしろ｡マクロからでも普通に扱えるし､イミフ｡罫線も死んじゃうの？
知らんがな｡使い方の問題だろ｡ExcelじゃなくてWordならいいのか？馬鹿？
お節介な補完がうざい
Excel方眼より良いものがあれば使わないだろ｡普及度､使い勝手､トータルでExcel方眼より良いものがあればぜひ教えろ｡
むしろ､今の大学でOffice使わないところあるの？マジ？普通の総合大学ならITの授業あるだろ？？レポートもOffice使うだろ？？？
それとも持ってるけど使えない脳足りん系？F欄なのかな｡
つか､Excelの話じゃないのか？
ソフトウェアエンジニアが転職するときに気をつけること http://anond.hatelabo.jp/20160629082647
これを書いたあとしばらくして転職したので、その後の話でも。
とはいっても、この「気をつけることリスト」は結局使わなかった。知り合いのエンジニアがはじめたベンチャーに行くことにしたからだ。
ベンチャーだからIRなんてないし、社長が知り合いだから技術への考え方や開発スタイルは知っているし。だから話としては開発しているサービスの内容と将来性、あとは待遇を聞いたくらいかな。まあ、将来性については自分で判断するしかないんだけどｗ
ちなみに知り合いの会社だからといって「気をつけることリスト」を無視したわけでもない。基本的なスタンスはこれを書いた当初と変わらないし、このリストにある項目について自分の中で納得したうえでの転職だよ。
これははっきりと断言させてもらうけど、この「気をつけることリスト」と照らしあわせたうえで転職したいと思える会社は、都内だったら普通にあるよ。
意識が高いのかどうかはよくわからない、というか周囲と比較すると自分はむしろ意識が低いほうだけどね。好きなこと以外の勉強をあまりしないし。それが自分の弱いところなんだよな。
gitのいいところは、ツールとして優れているというよりGitHub, GitLabなどのgit serverと統合されたウェブサービスがよく出来ているところだと思う。
特に、いわゆるpull-request駆動開発、つまりある程度のコミットのまとまりをpull-requestなどでCIしたりレビューしながら開発できるようになったすばらしい。
だからまあ、pull-request駆動ができるならバックエンドのバージョン管理システムはgitでなくてもいい。逆にいえば、gitを使っている会社でもpull-request駆動できる環境がなければ片手落ちだ。
そりゃ聞くよ。聞くべきでしょう。わざわざ書かなかったのは、さすがに自明だと思っていたから。
ベンチャー特有というと、株の扱いくらいかな。このれはちょっと前にバズってた記事があるので読んでおくといいんじゃないだろうか。
なにかしらOSSを公開していなければ転職は絶対ありえないというわけではないけど、判断材料になるのは確かだし、そういう会社を積極的に探したほうがいいとは思う。
かつ、稀というほど少なくもないと思う。特に昨今のWeb系企業であれば、OSSを開発してるところは沢山ある。そういうのは採用のためのアピールも兼ねてると思うんだけどね。
あとそういう意味では、最近はエンジニアブログを持っている会社もあるからそういうのはチェックしたほうがいい。会社のレベル感や雰囲気を知るにはちょうどいいと思う。
プログラム書くようになってあるプロジェクトで実践でも投入されるようになってから数年。当時の上司にプログラマって名乗っていいんじゃない？とか言われてプログラマという自認もできた。
もともとはSE的な立場として仕様書を書いたりしてた。ゲーム業界だからSEとはいわずに企画とかプランナーとか呼ばれる職種。書類仕事がメインで、自分でツール作るかスクリプター的な役目でないかぎりコードみたいなものを書いたりはしなかった。コード書くの楽しい。VBなんかに戻れないし、もう書く事もできないだろうな。
だからってわけでもないけれど、できる企画とダメな企画ってのがわかるのよね。プログラマ側からみての意見になるから、ディレクターからみて、とかデザイナーから見て、とかはまたちょっと違うのだと思うのだけど。
自分、ちょっとコードの読み書きできるのでわかってます、な体で仕様書書いてくるのだけど、全然穴だらけ。要件が不明なままフローだけ書いてくる。実際にやりたいことは何なの？そこを説明して実装はプログラマに任せようよ、と。
ゲーム作るのにはバージョン管理システムを導入するのが常。subversionとかgitとかあるでしょ。すごく便利なんだけど基本的にテキスト形式のファイルを管理するためのものなので、エクセルみたいなバイナリ突っ込まれると差分じゃなくて全部のバージョンが入るから容量を圧迫するの。
画像データはまだいいよ。githubがpsdの差分さえ教えてくれるからね。
文字情報メインなのに差分を見る事もできない。検索もできない。
ただ、データ管理としてのエクセルは優秀なのよ。ちょっとしたツールもつくれちゃうし。仕様書をエクセル方眼で書いてくるやつはカスだ。
俺も若い頃はよく使ってたけどMarkdownを知ってからは断然こっちの方が書きやすい。そしてなにより読みやすい。検索もできるし成型もできる。強調表示や画像も貼れる。文法も簡単だし覚えやすい。
Markdownは文字列情報だ。文章だ。文章は一次元的に表現される。つまり書く側が完全に整理した思考でないと書ききれない。読む側に理解させるにはどういった順番で説明をすればいいか考えてからでないと表現できない。おのずと書類の内容、精度が上がる。ただの文章だからこそだ。
エクセルはタブやらなんやらで並列なまま多次元情報としたまま表現できる。思考が整理されてなくても表現できてしまうし、表現した気になる。書いてる側の思考がまとまってないまま表現できてしまうあたりはエクセルの自由度の高さでもあるのだけど、通して読む事ができない形式でもあるので、読む側のことを考えていないクソみたいな仕様書も提出されてきてしまうのが難点。
企画「XXファイルのYYタブに書いてありますよ。ちゃんと読んでるんですか？」
殺意が沸くわ。
Photoshopなり何なりで書いた絵図をGyazoにでもあげてリンクだけMDに貼れよ。エクセルでシェイプ駆使して作るより早いだろ。
パワポの方がマシですわ。あれはページにスペースの制限があるから１ページ内にまとめよう、伝えようっていう意思と能力がないとまとめられないから。
要件を伝えるのもいいけどバランス調整するための調整項目だしなよ。調整できるようにするし、こっちも使う変数を見出すきっかけになるから助かるんだよね。
3Dアーティストのあげてくるデータも仕様書書くでしょ？あれの要件とかもまとめられないでしょ。ノードとか意味わかる？揺れもの数とか制限あるのわかる？
なんでもいいからゲームエンジン触れよ。Unityとか簡単じゃん。プログラム書かなくてもいいじゃん。
俺があれだけMarkdown簡単だから覚えろって言ってもエクセルで上げてくるし、古い知識のままアップデートされない人って存在が迷惑ですわ。
プランナーで説明が下手って終わってるよね。俺も下手だわ。よく怒られてた。ごめんなさい。これは別にプランナーに限った話ではないけれど、プランナーて人に伝えてなんぼなので職能としてこれがないのは致命的だよなぁ。
書いてすっきりしたので寝る。星くれ星くれ
で、感想をtwitterでKENSAKUしてて見つけた http://d.hatena.ne.jp/kurutto115/20150307/1425715505 を読んで、おれがこうじゃないかなーって思っている内容を雑に書いてみる。
まとまってないし妄想先行のシステム万能論で思考停止してる部分もあるけどご容赦。
とりあえず、バージョン管理システム(GitとかSubversion)と、自動テストは導入したほうがよい。
http://anond.hatelabo.jp/20140121235137
僕は専門家じゃないからよくわからないが以下のように考えている
たとえばよく言われる
モデル記述言語でモデルを記述したらコードが自動生成されるのでプログラム不要って話は、
C言語が.sを生成するのと同じなのでそれはコンパイラであって概念的には昔からある話。
C言語が抽象度低くてむつかしいというなら抽象度の高い言語を使えばいいというだけにしかならん。
GUIで設計すれば自動的にコードができるようにならんの? って話はUIビルダとか昔からそうだったじゃん。
でもGUIで作ったやつってバージョン管理システムで管理しづらいから、マークアップ言語で記述できるようにほうが便利ってことにみんなが気付いて、結局テキストで記述できるようなのを一般的にしようってのが2004年～2005年くらいの話
先輩だけど「バージョン管理システムの使い方わかってます？」って言うべきかどうか。
それだと直接的過ぎて軋轢産みそうだから
「すみません、このファイルコミットするとき競合発生しませんでした？
私のコードが消えてしまったので、今度から競合が発生したらdiff見てマージお願いしますね。」
で行こう！
できればそうさせたい。
diff見なくても、コミットの時に競合が起こってるはずなんだよ。
その人多分、エラーメッセージ読まないから、競合の解決方法とか理解してないんだよ。
先輩だけど「バージョン管理システムの使い方わかってます？」って言うべきかどうか。
http://d.hatena.ne.jp/yamasawa8911/20120519/1337407233
だそうなので、俺が思うところを書いておきます。
基本的にMacのほうが羨ましいとは思うけれども(まあ、MacBookとかが欲しいんだよね、きっと）、でもきっとMacなんてフルスペックで使えるわけない。
周りの子に自慢したいとかいうのであるならば、あるいはどうしてもiOSアプリが作りたいというんだったら、それしか選択肢がないけれども、そうじゃないんだったら辞めましょう。
あとWindowsも、Windowsアプリとか、C#をいじりたいんです！っていう話であるならば、それに固辞するのも結構ですけど、そうじゃなくて、ITに行きたいなら、Windowsを捨ててLinuxにしましょう。
自分はGentooが好きですけど、ハードコアすぎるので、Ubuntuのほうがいいかと思う。
Linuxとか難しいんじゃないの……とか思うかもしれないですけど、Ubuntuは素晴らしいです。
Ubuntuは、知り合いの絵師のパソコンに入れたら、わりと好評でちゃんと使っていたので、それなりにパソコンが使えるならば、ちゃんと使えます。
プログラミング言語関係は、そのOSに依存するような環境を使いたいというわけではないのなら、Linuxにしておいたほうが、無難に使えます。
CとJavaでもいいとは思うんだけど、どちらもコンパイルが必要だし、コードを書くのに、ある程度の量(書きたいときに気軽に書くという感じではない、という意味）が必要なので、もう一つ言語を覚えた方がいいです。
PHP、Ruby、Python、Perl、Clojure、Haskell、お好きな言語をどうぞ。
ただ、PHPはどちらかといえばWebアプリケーションよりかな？という気がするので、PerlかRubyかPythonがいいかとは思いますが、お好みで。
自分はPythonのほうが好きですけど、Rubyのほうが割と見つけてもらえる確率は高いかもしれません。
あと、パブリックマンも「Railsでいこう！」というブログ名だったので、尊敬する人にあわせるならRubyのほうがいいんじゃないかと。
こわいおじさんににらまれたいならPerlのほうがいいでしょう。
ちなみに、Ruby on Railsは、割とWebサービスを作るのが楽になります。Herokuとかありますしね。Webアプリケーション周りということだったら、ついでにそのプログラミング言語で使われているメジャーなフレームワークとか調べながら勉強するといいかもしれません。
で、上記を踏まえて、エディタをちゃんと使いましょう。
パワーが有り余っているなら、総合開発環境であるところのEclipseでもいいんだろうとは思うんですけど、それはおっくう、というのならば、ちゃんとエディタの使い方を覚えましょう。
もう既にUbuntuを入れていると思うので、EmacsかVimを使いましょう。Vimのほうが好きではあるんですけど、キーバインドや、その他の癖を考えるとEmacsのほうがいいかなあという気がします。
Ubuntuを入れたなら、Geditというエディタも、Windowsのメモ帳の非じゃないくらい極まったエディタなので、それでもいいです。Windowsがそんなに好きなら、サクラエディタを使うといいでしょう。
あなたはどうやら貧乏だけれども、インターネットは使えているようなので、英語を読む練習をするといいです。
英語なんて全くわからない？ノープロブレム。そんなの適当でいいです。「なんとなくこういう意味かなー」とか、あるいは英語を読むだけでクラクラしない程度でいいと思います。
英語を読めると便利です。少しだけ多くの解説が読めるからです。
あと、英語が読めると「pdf Orailly」という魔法の言葉が使えたりするんですけど、何に使うかは想像におまかせします。
で、上記を踏まえてなんですが、コードを書きましょう。
コードなんて書いてなんぼです。「如何に優秀なハッカーになるべきか」という記事はゴロゴロありますが、そんなのは気休めに読むべきで、まずはコードを書きましょう。
なんだかんだいって、コードを書くのは経験がモノをいいます。量を書きましょう。そして躓きましょう。最初から質なんて無理です。
躓いたら、なんで躓くのか考えましょう。また、「こんなところが、コードを書く点で不満だなあ」と思うことがあれば、それも考えていきましょう。
偉い人がいろんなソリューションを考えてくれています。最初からそのソリューションがなぜ素晴らしいかなんて理解できないとは思います。躓いて始めて「ああ、だからこういう開発手法がいるんだ」ということを理解できるでしょう。
ついでに、コードで躓いたら、その躓いたところを、Twitterアカウントに積極的に発信していきましょう。
そのついでに、そのプログラミング言語を学んでいるTwitterアカウントをフォローしましょう。
あなたの呟いていることによっては、その人は興味を持ってくれるでしょうし、場合によっては手助けをしてくれるかもしれません。
あなたがサービスを立ち上げたら、積極的にRTをしてくれるかもしれません。
だいたいなれてきたところで、自分が作りたいものを作ってみましょう。そして公開してみましょう。できるならGithubで。
Githubに載せる理由は、ソースコードを公開したほうが、突っ込まれる率が高くなり、それに応じて勉強になるというところと、あとはGitというバージョン管理システムの勉強をしていたほうが、のちのちに便利だからです。SVNとかありますが。
あと、コードの引き写しに関しては、ブログに書くか、あるいはコードの断片を載せるという意味で、Gistに載せるという点もありますが、その辺りはご自由に。
VPSを借りてみましょう。あなたが貧乏だというのはわかっています。VPSとは、仮想専用サーバーのことです。
別に最初っから何でも揃ってるようなホスティングサービスでもいいんですが、サーバーを一から立てるという作業は、勉強にもなります。下手な技術書より余程勉強になったりします。
最初から借りると宝の持ち腐れとなると思うので、一つのWebサービスでもいいので、それを自分のマシン内でのみ見られるようなったら、借りるというのは一つの手だと思います。
VPSがつらいというのならば、Herokuとかもありかもしれないです。
コードを書くのが辛いなら、コードを読みましょう。人のコードはアイデアの山です。
自分の場合は、割と実例が無いと、挙動がピンとこなかったりするので、コードを読むことのほうが多いです。
特に、その言語で有名なライブラリとかいいかもしれません。ガンガン読みましょう。
あとは若さでなんとかなるでしょう。
ついでに、この文章を「テメーはなんにもわかってねえんじゃボケ」という言い方をして修正してくれる人もいると思うので、そういう人のアドバイスも真摯に受けとりましょう。
http://anond.hatelabo.jp/20120407162253 に便乗して。
それなりに大きなとある会社のプログラマだけど、うちの会社のビルドシステムがおかしい気がする
あまりにも原始的なので違和感を感じるんだけど、自分にビルドシステムに対する知識が圧倒的に不足しているので、今やってる作業に本当に意味があるのかよく分からない。詳しい人に教えてもらいたい。
手動でコピーするからよく事故が発生するし、同じファイルが複数箇所にあるので全然履歴が追えない。
あと、中間ファイルや実行ファイル(.o とか .so とか) も含めてごちゃまぜにチェックインされているので、もっと訳がわからなくなってる。
「ビルドは成功しないのが当たり前」とかいう人ばかりで、正直発狂しそうになる
フォルダツリーがわかりづらいと思うので図を書くと
/ Main/ -- 共通ファイルディレクトリ foo/ bar.c driver/ common.c ProductA/ foo/ bar.c -- ProductA 用の変更が入ってる baz.c -- ProductA 専用ファイル driver/ common.c ProductA_Orig/ -- ProductA/ 内の ProductA用ファイルが丸々入ってる foo/ bar.c baz.c ProductB/ foo/ bar.c -- Main と全く同じ driver/ common.c ProductC/ foo/ bar.c driver/hoge.c ProductC_Orig/ driver/hoge.c
こんな感じになっていて、共通部分は Main/ の中とそれぞれの ProductA, ProductB, ... ディレクトリの中にすべてコピーされている。
チェックインするときはすべてのファイル、例えば bar.c を更新したら Main, ProductA, ProductB, ProductC の bar.c を手動で更新する必要がある。
ビルドするときは Main/ のファイルを ProductA/ にコピーして、 ProductA_Orig/ の中の機種依存ファイルをさらに ProductA/ にコピーする。これは、同名のファイルが Main にもあって、 ProductA のファイルが上書きされるかららしい。
ビルドできないので、最後の最後まで結合テストが出来ずに、みんなローカルPCで開発してる。誰かのPCが吹っ飛ぶとその人が開発していた差分が消失する。
「ツリーを共通部分と依存部分きちんと分けて、ビルド自動化しましょうよ」って上長に提案したら「この会社はこれでやってる。むしろバイナリが入っているのでビルドできなくてもテストできる」という感じであまり真面目に取り合ってもらえなかった。
こんなのシステム開発と言えるのか。
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジックをクライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。
RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語のデバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語で記述した場合よりもはるかに時間がかかる。
また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。
ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。
仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイルで管理し、それをバージョン管理システムに含めたとしても（というか、最低そうすべきなんだが）、あるリビジョンのコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。
トリガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。
さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。
一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合。
バージョン管理していないと、ディスク死んだ時とかに最新ファイルがわからず復旧に時間がかかって恥ずかしいｗｗ
下向いちゃうしｗｗ
男にはせめてSubversion使って欲しい……
.bakとか.oldとかつけてファイル保存とかされたら……もう最悪ｗｗ
常識的に考えて欲しいだけなんです！
「ファイル名に日付付けてバージョン管理してます！」なんて自信たっぷりに言われた時の恥ずかしさとか分かる？
あのね？ たとえば週末10～20人ぐらいで勉強会とかするでしょ？
それぞれ作ったwebアプリをリポジトリにアップして公開するわけじゃない？
みんな普通にgitやcvsやsubversionやMercurialでバージョン管理するわけでしょ
