GitHubが安全性に問題のあるSSH鍵を無効化Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
社内の GitHub Enterprise を OpenStack に移行した, α7s Ver 1.21 にアップグレードした - HsbtDiary(2015-04-06)
■ 社内の GitHub Enterprise を OpenStack に移行した 勤務先のペパボでは GitHub Enterprise(GHE) を全社員使っていて、コードやアイデアや作業記録をすべて集約するようにしているのだけど、全社員となると導入した当初に用意したリソースではどうしても厳しくなってきた。さらに使用していた VirtualBox は GHE 2.x シリーズはサポート対象外となってしまい、未来に向けてなんとかしなくてはいけないということでなんとかした。 取りうる選択肢としては、AWS にのせるとか ESXi をインストールしてその上にのせるなどがあったのだけど、弊グループでは大規模な OpenStack 基盤の運用ノウハウがあるということと、ペパボでもアプリケーション・サーバーは積極的に OpenStack の上に載せていくという動きがある(と言っても動きを作っている
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
FLINTERS Engineer's Blog
2024-08-07 研修終了後ブログ BN研修の締めとして振り返り #エンジニア #新卒 #研修 2024-07-31 【24卒】FLINTERSエンジニア研修を終えて 研修 株式会社FLINTERSに新卒でエンジニアとして入社し、3ヶ月間の研修を終えたのでその概要をお伝えしようと思います。 #24卒 #25卒 #研修 #新卒 #新卒エンジニア 2024-07-24 雰囲気と研修内容：FLINTERSの新入社員の3ヶ月振り返り 2024年度BN研修まとめ 2024-06-21 Webフロントエンドプロダクト用にテスト戦略を考えた話 ブログ祭り梅雨 Webフロントエンドプロダクト用にテスト戦略を考えた話 2024-06-21 今期振り返り ブログ祭り梅雨 今期振り返り #今期の振り返り 2024-06-21 今期の振り返り AWS ブログ祭り梅雨 今期の振り返り #AWS 2024-06-
Yak shaving in Yosemite - Qiita
yak shaving は、ようするに「ある問題を解こうと思ったら別の問題が出てきて、それを解こうと思ったらさらに別の問題が出てきて…」ということが延々と続く状況を表しています。ちなみに、ヤクとは毛が長い、牛の一種です。 yak shaving で人生の問題の80%が説明できる問題 ─ bkブログ 全国のみんな! OSX を Yosemite にアップグレードしたかい! 人柱ヨロシクで俺は早速アップグレードしたぜ、ポチッとな! そして毎日のようにヤク刈りをしてるんだ、今日も土曜日は週末だっていうのに朝からヤクの毛満載だ、ハハッ というわけで、Yosemite にして個人的にハマったところをメモっておきます インストール中残り1分で止まって時間がかかる つらぽよ Yosemiteをインストールする前に/usr/localをどこかへ退避して時間短縮（ただしインストーラ任せの方が安全） に詳しく
Hubot + Heroku + Slack - $shibayu36->blog;
Hubot触ってみようと思って、いろいろ動かして見たのでメモ。 参考になるURL https://github.com/github/hubot/tree/master/docs http://nanapi.co.jp/blog/2014/06/04/slack_with_hubot/ http://odoruinu.net/blog/2014/07/08/how-to-integrate-self-hosted-hubot-with-slack/ https://github.com/tinyspeck/hubot-slack Hubotのrepositoryを作る https://github.com/github/hubot/tree/master/docs これのとおりに hubot --create shibabotとかすると作れる。 bin/hubotとかして動けばひとまず良い
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Japan
偶然にも500万個のSSH公開鍵を手に入れた俺たちは - slideshare
Medium
会社に Github導入した話