(翻訳) GitLab 社で働くのはどのようなものだったか - forest book
本稿は Yorick Peterse 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 yorickpeterse.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Yorick Peterse 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 GitLab 社で働くのはどのようなものだったか 私は2015年10月に GitLab 社に入社し、6年あまり働いて2021年12月に退社しました。 前に GitLab 社を辞めて Inko に取り組んでいることは書きましたが、2015年から2021年までの間、GitLab 社で働いていたことがどのようなものであったのかについては触れませんでした。理由は2つあります。 燃え尽き症候群に苦しんでいて、(当時は) 自分の人生の最後の6
What it was like working for GitLab
I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life (at that time)I w
GitLab Documentation
Use GitLab GitLab Duo AI-powered features and functionality. Manage your organization Users, groups, namespaces, SSH keys. Organize work with projects Project visibility, search, badges, layout. Plan and track work Epics, issues, milestones, labels. Learn Git Common commands and workflows. Manage your code Repositories, merge requests, remote development. Use CI/CD to build your application Runner
Guidelines for reusing abstractions | GitLab
Why these guidelines are necessary End goal Abstractions Controllers API endpoints Service classes ServiceResponse Finders Presenters Serializers Models Model class methods Model instance methods Active Record Worker Guidelines for reusing abstractions As GitLab has grown, different patterns emerged across the codebase. Service classes, serializers, and presenters are just a few. These patterns ma
Railsの設計に迷ったのでGitLabの設計ドキュメントを読んでみた | DevelopersIO
Railsのプロジェクトがそこそこ大きくなり、ServiceやSerializerなどのカスタムレイヤーを追加してコードを細分化しているものの、レイヤーの役割やインターフェイスのルールが明確に決まっておらずふわふわとしていることを課題と感じていました。課題を解決するヒントを探すため、Railsの超巨大OSSプロジェクトであるGitLabの設計ドキュメントを読んでみました。 ガイドラインの必要性 まず初めにガイドラインの必要性が語られています。レイヤーの抽象化ができたとしても、それを正しく使えないと、あっという間にメンテナンスしにくいコードができてしまうということが説明されています。 例として、あるFinder（Finderはデータベースからデータを検索する抽象）の中で別のFinderを呼び出してはいけないということが挙げられています。もしそうしたなら、Finderにどんどんオプションが追加
Making Decisions
Intro to making decisions On this page, we have outlined how we make decisions at GitLab. Making decisions GitLab’s values are the guiding principles for our business. They inform hiring, performance management, and promotion assessments. They also guide other decisions that we make. At times, values may be in conflict. To address this, GitLab has a values hierarchy. At the top of this hierarchy i
Open-core model - Wikipedia
"Open core" and "COSS" redirect here. For the open-source hardware community, see OpenCores. For railway term, see Controller of site safety. GitLab Community Edition The open-core model is a business model for the monetization of commercially produced open-source software. The open-core model primarily involves offering a "core" or feature-limited version of a software product as free and open-so
GitLabがRuby on Railsを使い続ける理由（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Why we're sticking with Ruby on Rails | GitLab（2022/06/08にthenewstack.ioに掲載されました） 原文公開日: 2022/07/06 原著者: Sid Sijbrandij -- GitLab, Inc.の共同創業者、CEO、取締役会議長 Ruby on Railsを作ったときのDavid Heinemeier Hansson（DHH）が道しるべとしたのは、それまでに経験していたPHPとJavaでした（インタビュー）。DHHにとって、JavaのWebフレームワークはJavaが冗長で柔軟性が低く使いにくい点が好みでなかったものの、構造的に統一されている点が高く評価できるものでした。一方、PHPについては敷居の低さが好みだったものの、プロジェクトが泥沼化しがちな点をあま
Why we use Ruby on Rails to build GitLab
When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework. GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice: "It's worked out really
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
でいじ on Twitter: "GitLabの人は毎度いいこと言うなと思いながら読んでる。情報収集と決断をわけるべし。情報を集めたら、DRI(directly responsible individual)が決断すべし。情報を集めた上なら決断は多数決じゃなくても良い。DRIは別に皆に説明しなくても良い。などなど。 https://t.co/cxoNhQCODM"