@domofactor1.GitHub導入時点の話て:導入した理由は?さ:インフラを導入していく仕組みのリポジトリを管理していくにあたり、GitHubを使えなかったのでGHEを使ったて:大規模な企業だが、簡単に導入できたのか?さ:導入には苦労はなかった伊:システム的な問題としてプロプライエタリなVCSはWindowsでしか使えず、Mac/Linuxでは別のものを使っていた。ソーシャルコーディングが開発者から求められていた中で、GitHubEnterpriseを使っている他社の事例を見て憧れを抱いていた。いうCoolなツールを使いたい、という思いが強かった。井:レビューを強化しようという流れの中で、SVN+Redmineで行っていたが、GitHubのPullRequestの方が効率的だったので、導入した。.comの利用にはハードルがあったので、GHEを採用した。:導入で苦労したことは?井:SVNからGitへの履歴を含めた移行はすぐにできたが、SVNの外部参照を多用しており、代替の機能がgitにはなかったので苦労した。最終的にはgit-submoduleを使って実現したが、ディレクトリ構成の変更などを伴い苦労した。git自体の理解と習得に苦労した。伊:プロプライエタリなVCSからの移行だったので、事例がない情報がないので苦労した。ツールを使っていたが、特定条件のリポジトリは必ず失敗する、などが起きて職人芸的にクリアせざるを得なかった。gitに理解のないエンジニアに移行を促す作業は、なかなか骨が折れた。今は古いVCSはシャットダウンできている。:最初は特定プロジェクト向けにgitを導入したが、どんどん周囲のプロジェクトから手が挙がって利用者が増えた。当初はライセンスの購入が追いつかなかった。オープンに公開する文化にシフトするなかで、秘匿化しなければいけないトークンなどまでオープンにしてしまうことを防止したり、そういったポリシーを定めるのに苦労した。2.いま時点の話て:GHE導入して、何が変わりましたか?伊:一言で言うと文化が変わった。自分たちで調べてブランチ戦略を考えたり、勝手にPullRequestでコードレビューを始めたり、そういった変化が自然に起きた。:各プロジェクトが自分たちで作っている製品を管理していたが、今は、チームを横断してPRを投げたりするような文化ができ始めている。井:様々なツールを見ていたのがGitHubに一本化されて効率があがった。PRの時点で仕様や要求の共有ができるようになった。:GHEを管理していて困ったことは?伊:ソフトウェア的に問題が起きたことはない。Org/Teamの管理が自分自身でしかできない点が課題。井:サーバ側でのトラブルはない。gitの勉強コストが困ることがある。git操作での事故がチラホラある。レビューを通すことが必須になったため、本流に入るまでの時間が長くなった部分もある。:弊社はプライベートネットワークとパブリックネットワークが分かれており、それらのインターフェースを毎度設定する必要があり苦労している。:管理者からみてGHEのいいところは?井:安定しているサービスである。サポートが日本語で対応してくれるのも助かる。:安定性はすごくありがたい。他に使っている他社製品はDockerベースのものが多いが、落ちたりバグったりする。管理者用のドキュメントも分かりやすくていいて:ユーザの反応はどうですか?伊:良好。早く作業ができていい、という声を聞く。GHE内のすべてのコードを検索できるため、社内の特殊なノウハウを探して参考にしやすいのが嬉しい。:使い出すと戻りたくない、という声が多い。井:リポジトリをまたいだ検索はありがたい。使うべきではない関数の横断検索などは効率的にできた。(オーディエンスから質問:福留さん)サーバの運用周りについて、手がかからないという話があったが、何か管理面で自動化の工夫をしている点があれば教えて欲しい。:GHEはモニタリングでGraffanaが統合されているが、独自のモニタリングツールと統合したい場合に、モニタリングのAPIを使って情報を吸い出している。:これからGHEを導入したい人へのアドバイスは?井:PRは開発者にとって大きな変化なので、1つの最善の選択だと思う。伊:競合製品と比べるのは良いと思うが、結局はGHEに辿り着くと思う。サポートのレスが早い。サービス開始が2008年、今年でちょうど10年。GitHubという会社は、コラボレーションとリモートオフィスという考えを大事にしている。全世界に社員がいるが、長い間オフィスはアメリカ1つだった。2015年、GitHubのアメリカ以外の最初のオフィスができた。ソフトウェア開発の未来に貢献していきたい。皆様が書いているコードが、今、地球上で大きな原動力となってる。ソフトウェア開発者になるのに、今ほどいい環境・状況はない。数年前の時点で、平均的な自動車は、1億Stepのコードで動いている。私達が最初に作ったもの。信頼性の高いバージョンコントロールシステム、Web経由でアクセス可能なもの。作ったシステムは、次第にコミュニティを構築していった。オープンソースソフトウェアが活発に作られるようになった。人やデータ、ツール、すべてが繋がっていくことで成長・進化していく。Requestだった。新しいテクノロジーは次々と出てくるソフトウェア開発が将来どういうかたちになっていくか、は誰もわからないどのようになろうと、複雑性を排除してシンプルに開発できる環境を整えることに注力したい様々な問題を解決するのは開発者の皆様です。GitHubはそれを支援します。先週、MicrosoftがGitHubを買収した。設計図共有サイトのファンの皆様、こんにちは(会場爆すべてがコンピュータ・ソフトウェア産業になっていく。それを作り、支えていくのは開発者の皆様です。マイクロソフトは変わってきた、あなたのお父さんの世代のマイクロソフトとは違います。言っても信じてもらえない人もいる言葉ではなく、行動で示していきます。GitHubの独立性を保って、すべての開発者が今までどおりGitHubの機能を安心して使っていけるようにする。マインクラフトでも独立性を維持してきたこれが、我々の今のミッションです。これからの我々の行動を見ていただきたい。developer我々がやりたいこと。すべての開発者とともに、未来を作っていきたい。(Rubyアソシエーション)GitHubのソフトウェアエンジニア、アーロン・パターソン(互いに旧知の仲らしく、2人でのセルフィー撮影に始まり、終始和やかなムードで対談)あ:GitHubはRubyで書いてあるので、まつもとさんありがとう。あ:Rubyはいつ生まれた?ま:1993年です。あ:どうやって生まれた?ま:バブル経済が崩壊して景気が悪かった、ソフトウェア会社の社内ツールを開発するチームに在籍していた。いうツールは売上がたたない。景気が悪いのにそんなことをやってられない、プロジェクトが解散した。社内にはツールのユーザが既にいたので、面倒を見るために残されたエンジニアが2人だけ残った、そのうちの一人。何年もかかって作ったツールを2人ではサポートを回せない。自分で作ったもの以外も多数あったので、基本的にトラブルシュートは「再起動してください」で終わらせていた(笑。上司は兼任で忙しかったが、自分たちには時間があった。誰も管理していない状態、そんな中で作ったのがRuby。ま:会社で作ったが、著作権の考え方に厳しい時代じゃなかったのと、上司が許してくれたので、退職時に外へ持っていけた。上司が許可してくれなかったら今のRubyはなかった。ま:GitHubに公開されているRuby/Rubyは、公式のミラーであり、実際はSVNで開発が行われている。ま:なぜGitHubに移行しないのか?をよく聞かれる。RailsもGitHub。PythonのセントラルリポジトリもGitHub。ま:RedmineでIssueを管理していて、RedmineとSVNを連携させる作り込みを相当しているので、使い続けるという状態。あと、GitHubサービス自体はOSSではないので、一部のコアなエンジニアが完全オープンなサービスにしかアカウントを作りたがらない、というのもある。いう人々を離脱させたくない。あ:まつもとさんがGitHubを初めて使ったのはいつ?ま:Ruby本体で使えなかったので、アカウントは作ったが、ほとんど使っていなかった。自分用のメールリーダーを自作している、OSSにしていないのでユーザは自分しかいない。それを修正するためだけにPRを3回だけやった。ま:mRubyは、最近の普通の開発がしたかったので、最初からGitHubにホストしている。リポジトリなどを自分で管理するのはよくない、と改めて思った。あ:Ruby開発のコミュニケーションの問題はあるのか?ま:Rubyのコアコミッターは100名くらいいる。日本人が半分くらいだが、スーパーアクティブな人が日本人なので、日本人がコミッターであるイメージが強い。ま:Rubyの開発は、オープンソースだけどクローズドだ、と海外の人で言われた。日本人が日本語でいつの間にか方向を決めてやっている。それ以降、Redmmineにすべて内容をダンプして、公式言語も英語にして、オープンになるよう心がけている。議事録も英語で書いているので、日本語がわからないとRubyができない、という世界にはならないようにしている。あ:Rubyの未来についてま:頑張って進歩を続けている。RubyやRoRは「ハイプ曲線」を過ぎて、Rubyは死んだ、と言われている(笑ま:Goなどの静的な型がある言語が持ち上げられてきたので、様々な理由で毎年死んだと言われ続けている(笑ま:大きなサイトでRubyが使われているのは事実で、そういったサイトをもっと支援したい、と考えている。性能問題が出たときに独自カスタマイズしたRubyを作っている人々が昔はいたが、大体が残っていないと思うし、本来Rubyユーザが汗をかくべきところではないと思っている。あ:アウトオブバウンズGCの説明。Webサイト利用者にGCによるレスポンス遅延影響を最小化する手法。GitHubで利用することで劇的にUXが改善した。ま:そういう感じでコアチームの努力によって、Rubyユーザが独自にRubyをパッチしなくてもいいようにするのが責任だと思っている。あ:プログラミング言語を作るのが好きなまつもとさんの、プログラミング言語のストリームについて教えてください。ま:言語をデザインする人が、言語をデザインするときにどういう事を考えて設計しているのか、ということが分かるような連載を書いている。そこで作り始めたのがストリーム。200行くらいの文法イメージを書いてGitHubにバックアップ目的でアップロードした。ものなのに、PRは来るわ、言語のアイコンを作って投げつけられたり、色んなことが起こって、OSS時代の開発は全然違うな、と思った。フリーソフトウェアの時代とは違う。あ:まつもとさんの開発環境についてま:普段使っているエディタはEmacs。コンパイラーはgcc。あ:なんでRubyのソースコードの中で同じファイルの中にTabとSpaceが混在しているか?ま:どっち派の人もコミッタにいるが、最後に触った人の修正した行が、その人の行はその人の流派になる。統一しようとしていない。ま:昔はスペースよりもタブ派だった。データ数が少ないので。最近はスペース派になった。効かなくなるので、変換するためだけのコミットをしていない。あ:私は自作キーボードを使っているが、どういうキーボードを使っているか?ま:Thinkpadのキーボード、マイクロソフトのエルゴノミクスキーボードを使っている。最近はレッツスプリットというキーボードを使っている。タップキーボードを最近買ったが、まだ使いこなせていない。activity)」の話。話を聞いている雰囲気から、Matzは細かいことを気にしすぎない包容力があるから、Rubyのコミッタを含むコミュニティを「いい感じにゆるく」まとめていけるんだなーエンジニアにとって窮屈さを感じさせる環境を作らない、というのが非常に感じられる。大事な部分はキッチリ真面目に説明責任を果たすし、Techリードはこうあるべきと感じた。生々しい苦労話とやりがいの話。Matzのストリーム話との共通点は、オープンにすることで多くのフィードバックが生まれプロダクトの成長が加速した、という点かと。今のフラットな組織に合っているメンバーが固定化されづらい新規メンバーが参入しやすい興味のある言語や分野から入っていける各サービスをつなぐ中心になるもの、(ARMS)を用意することをオススメする。(GitHub)36名の応募者、7名が選ばれた。心理を表現できる(私が漫画という手法を選択している理由)漫画でリポジトリを説明してみるフォークとクローンを説明してみるまとめ学習コストが高いと言われるgitビジュアル化されていれば短時間で理解できる所感そういえば、gitの社内説明で絵を何枚も書いたなぁ。git説明に限らず、ビジュアル化は本当に大事。ORACLEに買収された模様。Cloud内のSaaSとしてシナジーを効かせたい戦略ということで、wercker的にはログイン後の画面タイトルが「ORACLE+wercker」と変わっただけで、モダンで素敵なUIやサイトの構成には特に変化は今のところない様子。買収Tweet広告を非表示にするもっと読むコメントを書く2016-10-25携帯のメールアドレスに迷惑メールが来たので通報した2Security今回のメールはこんな感じ。【速報】大切なお知らせ(19時32分)大切なお知らせが御座いますのでご連絡差し上げました。誠に恐れ入りますが、速やかに通知内容をご確認下さい。------個人情報を保護する為、メール本文に詳細を記載しておりませんが、URL(リンク)先は受取人の為の特別な秘密情報を含んでいます。大切なお知らせの為、通常受信していない場合でも配信しております。当メールは送信用途のみで使用しており、直接返信されましても確認しておりません。ご理解・ご協力の程お願い致します。何者かも名乗らずに、さも大事のように「大切なお知らせ」を伝えたがる連中。そんな大事なことは、こんな胡散臭いメールでは通知せんわ!ということで、前回同様に通報しました。読者のどなたかが引用メールにあるURLにアクセスしたからか、続きのメールが届き始めたのでURLパラメータをごっそりマスクしました。Track>Event参加した上での雑なメモ書きです。ファンクションはサーバーレスで実行されるコンテナで実行されるコンテナは実行時に作成され、終了時に破棄される常駐プロセスではない。Lambdaはスケールするし、安いイベント量に合わせてLambdaが自動でスケールステートレスなのでスケールしやすいプロセスが落ちてた。・・・プロセスを作っておいて常駐オーバーヘッドが少なく安全だが、並行性能に難スケーラビリティに難メモリフットプリントが大きい。大幅に分離されたサービスを生み出せるFaaSは自然とコレオグラフィを指向するぶっちゃけどうなの?はまれば強いスケーラブル。運用工数がすごい下がる。EC2より超安い知らんうちに良いアーキテクチャに向かってたりする開発工数はそこまで削減されないかもFaaS特有のノウハウが必要ピタゴラスイッチになるので、デバッグが大変。結合テストが難しいFaaSを用いたサーバーレスアーキテクチャは、マイクロサービスの具体的な実現手段の一つどういう時に使うの?小さなユースケースでは積極的に使えばいい大きなユースケースではいつ使うのか・・・まだ言語化できてないオーバーヘッドは比較的小さいがゼロではないサーバーレスとそうじゃないのを組み合わえる事例が増えてるサーバーレスの今後アーキテクチャ的に真っ当だし、適用範囲は広がる開発環境(フレームワーク)はもう一声欲しい。先進国においては最重要項目にあげられていることも。国家レベルで関心が高い。サイバー攻撃対応の要求事項が記載されている。ビルドとデプロイを自動化することを目的に作られたサービス。ビルドの後続処理をPipelineで繋いでいけるのが醍醐味らしい。して企画に幕を下ろしかけたけども、いやまてよ。導入することで生成されるWebHookのURLを環境変数で設定してあげれば、通知が可能になるhttp://devcenter.wercker.com/docs/notifications/slack.html初めはヒントが少なくて戸惑いましたが、UIもイケてるし、多重度2まではFreeで使えるし、リポジトリ&開発者は無制限な模様。良い感じなのではないかと。03:47Jenkinsオジサンからの卒業その4(werckerを試してみた)Tweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:shiopu明日のワシは忘れてしまうから、コードにはコメントを書くのです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。