タグ

githubとworkに関するkasahiのブックマーク (7)

  • 「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話 - 生涯未熟

    記事は ミクシィグループ Advent Calendar 2021 の22日目の記事です。 前置き 私が現在所属しているプロジェクトでは「アプリケーション × 4 + 開発環境 × 3」という環境で開発しており、機能開発後のQA作業などのため常に3つある開発環境がどこかしら使われているという状況でした。 (ちなみに Fansta(ファンスタ) というプロジェクトですので、興味のある方は @syossan27 までご連絡を!) そのため開発環境の使用状況をtrelloを使い管理していましたが、新しく開発環境へデプロイする際にはSlackでデプロイしても大丈夫か尋ねる、という流れが定常化しておりました。 このままでも良いのですが、ここはエンジニアとしてこのような冗長コミュニケーションを無くすために技術を使おうじゃないかと思い立ち、カッとなって掲題の「開発環境の使用状況分かるくん」を作成し始め

    「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話 - 生涯未熟
  • 大きな組織で情報共有するためのOSSつくってみた - Qiita

    この記事は、Fujitsu Advent Calender 2016の6日目の記事です。 はじめに 仕事柄、沢山の人が関わるお仕事の効率化に関心があり、プライベートで研究や開発をしています。システム・インテグレーションをはじめ沢山の人が関わるお仕事は、人海戦術で行なわれる事がよくあります。しかし、経験上ITが関わるお仕事の人海戦術はおすすめできません。効率面、品質面、労務管理の面で問題が発生する事が多いからです。 人海戦術にならないようにするには、「人間的な仕事」と「機械的な作業」を切り分けて、機械的な作業をIT化するのが近道ではないかと考えています。 ITの現場における機械的な作業の例 情報を記録する(課題とか、バグとか、更新履歴とか) 情報を探索する(あの資料どこだっけ?とか) 情報を収集する(進捗どうですか?だめですか?とか) 情報を転記する(メールからエクセルとか) 情報を伝達する

    大きな組織で情報共有するためのOSSつくってみた - Qiita
  • 「リモートワークは手段でしかない」GitHubが作りだす“幸せの最適化”

    2016年2月25日、世界をログする書き起こしメディア、ログミーが初のリアルイベント「ログミーLIVE」を開催しました。第1回目のテーマは「働き方」。1人目の登壇者、ギットハブ・ジャパンの堀江大輔氏は、同社が最も大切にしている“幸せの最適化”という価値観を紹介。その上で、社員の半数以上がリモート勤務を導入するGitHubのワークスタイルについて語りました。 第1回 ログミーLIVE「GitHubの働き方」 堀江大輔氏(以下、堀江):今日はGitHubがどういう働き方をしているか、どうしてそういう働き方をしているかを紹介しようと思っています。 いきなり言い訳から始めるんですけど、花粉症がすごいひどくて、じゃあ薬を飲もうと思ったら、いつも以上にとろんとしていて、忘れそうなのでここにコンピューターを置いておきます。 堀江氏のプロフィールとGitHubの社風 まず自己紹介なんですけど、私、堀江大輔

    「リモートワークは手段でしかない」GitHubが作りだす“幸せの最適化”
  • Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog

    Quipperに入社して2年経った。 転職するにあたり、最も心配だったのは英語だ。当時は英検もTOEICも受験した経験すらなく、自分の英語力がどの程度のものなのか客観的に知る術がなかった。日常的に英語を使う機会も乏しく、果たして当に外資系企業でやっていけるのか甚だ不安だった。 2年働いてみて、なんとかやってこれたと思うし、今後もやっていけそうだという手応えもある。2年間の振り返りとして、自分が体験した「グローバル企業で求められる英語力の現実」を綴ってみたい。 前提と特有の事情 仕事英語にまつわる話を見聞きするときいつも、「帰国子女とか海外留学とか長期出張・駐在とかの経験がある、とかいう人たち、元々普通に比べて英語力が高かったんだからチートじゃんか」と感じていた。自分はそういう経験が一切ない。Quipperで働き始めるまで外国人と仕事をしたことはないし、海外旅行すら一度しか行ったことがな

    Quipperで2年働いてわかった、グローバル企業で求められる英語力の現実 - @kyanny's blog
  • 会社を作った - clock-up-blog

    何でもホイホイ作ってみれば良いと思う 物作りを生業とする以上は何でもかんでも呼吸のように生み出していきたい。 今回はホイホイ会社を作ってみた。 プログラムの設計をするように組織の設計をしていきたい。 パケットの送信をするように役所手続きをしていきたい。 オープンソースにコミットするように社内ノウハウを放出していきたい。 定款は Markdown で作った。 2015年度の目標は事務所を持つことだ。志高い方から見たら糞みたいな目標だと思う。 指摘を受ける前に先に自ら言及しておくが、既に会社の質と手段と目的を履き違えている。でも僕はそれで良いと思う。 そもそも僕の会社の主業務はツール開発だ。手段が目的であり目的が手段なのだ。 モリモリとやっていきたい。 体験は確実に大きな糧となる。 会社サイト 歩元株式会社 登記申請までのアクティビティ GitHub の Issues で管理している。 会社

    会社を作った - clock-up-blog
  • GitHubのissuesをカンバンにするやつ - laiso

    Huboard https://huboard.com/ Demo: huboard/project_awesome HuBoard Huboard - お勧め!GitHubの課題管理をカンバン化 MOONGIFT Huboard を使ってみた - \sqrt xx ソース公開されてる: https://github.com/rauhryan/huboard Waffle.io https://waffle.io/ Demoではない: openworm ZenHub.io https://www.zenhub.io/ GitHub issueに、かんばんボード機能を追加できるZenHubがマジ神 | IsaB Githubでカンバンが使えるようになるZenHubが素晴らしすぎる - 新・たけぞう瀕死の日記 なんかブラウザ拡張を使わされる TaskTub http://tasktub.com

    GitHubのissuesをカンバンにするやつ - laiso
  • Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー

    先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう

    Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
  • 1