Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P

BASEアドベントカレンダー2021 10日目の記事です。 BASEアドベントカレンダー2021 10日目 BASE BANKでエンジニアをしている @budougumi0617 です。 マイグレーションファイルが含まれたPull Request（PR）が作られたとき、自動更新したER図をPRに追加するGitHub Actionsを作りました。 本記事では紹介するGitHub Actionsを利用すると次のようなメリットが得られます。 マイグレーションファイルをPRに出すだけでPRに更新されたER図が追加される 開発者は面倒なER図の更新作業から開放される レビューアはマイグレーションファイルを含んだPRをER図を見ながらレビューできるようになる プロジェクト関係者は常にメインブランチのマイグレーションファイルの状態と一致したER図を確認できる サンプルPR 自動生成したER図 TL;DR

固定を募集する際のパッチノート風テンプレートです。 タイトル例 【Mana DC】5.0エデン零式固定メンバー募集【メレー（竜以外）】 攻略期間 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ≪踏破目標≫ ✒2週以内 ※2週以内に踏破できなかった場合、活動期間を延長します。 ≪活動日時≫ 攻略期間中 ✒毎日21時〜24時 ※場合によって延長します。 ✒休日昼の攻略は相談 クリア後 ✒8週消化 ※4.xオメガ零式と同様に、武器分のトークン要求数が8個の場合の予定です。 なお、消化日の調整には「Googleスプレッドシート」を使用します。8週後の消化活動は各自にお任せします。 募集要項 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ≪FFXIV内≫ ✒Mana DC内にキャラがいる方 ✒自ロールのうち、攻略に最適なジョブを

この連携は、すべての Asana Premium、Business、および Enterprise プランのお客様にご利用いただける機能です。 概要 Asana for GitHub の連携を使用すると、GitHub のプルリクエストのステータス更新を Asana のタスクに自動的に同期できるため、部門間のコラボレーションがさらに容易になります。 この連携を使用すれば、技術チームと非技術チームの間でエンジニアリング業務の可視性と透明性を高めることができます。また、開発者は Asana を介して簡単にコミュニケーションをとれるようになるため、チームや他部門の関係者にも情報を提供できるようになり、仕事の見落としも防げます。 Asana と GitHub Actions の連携のインストール Asana と GitHub を連携してプルリクエストのステータスを同期します。この連携を活用するための設

最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした

A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team

The year was 2012 and operating a critical service at Netflix was laborious. Deployments felt like walking through wet sand. Canarying was devolving into verifying endurance (“nothing broke after one week of canarying, let’s push it”) rather than correct functionality. Researching issues felt like bouncing a rubber ball between teams, hard to catch the root cause and harder yet to stop from bounci

開発者じゃない人がみてもわかるような機能区分です。1sprintで完了する粒度です。 Storyのタイトルは「在庫管理ができるようになる」という類。 Task or Bug こちらは完全に開発マターの作業単位です。タイトルは開発にお任せしますが、見積もりの工数はタスクの積み上げなので、一度の作業で終わる単位に分解することをお勧めします。 担当 一般的な開発プロジェクトは下記の構成 - 依頼主（ビジネス側） - 依頼一次受け・受取窓口（プロマネ） - 開発（開発＋テスター） Epicは全員が認識するべき項目で、日付が決まっています。 プロマネは、Epicにまつわる要件(requirement = Features)を整理し、そのFeaturesをStoryに分解して全員と認識をすり合わせます。 それを理解した開発者もしくは開発責任者は各Storyに対して必要なTaskを入れ込み、各Taskの

こんにちは、エンジニアの @s_tajima です。 今回は、技術的なトピックから少し離れ、僕たちが今取り組んでいる「金融サービスの開発」というのがどんなものなのかを、少しでも具体的にイメージしてもらうための記事を書いてみることにしました。 「普通に使える」金融サービスの開発が難しい理由僕は先日、とある金融サービスを利用するためにとあるWebサイトにアクセスしました。多くの不要な情報の海からなんとか目的の場所にたどり着きますが、「この手続きはインターネットからはお受けできません。0x-xxxx-xxxxにお電話ください」という案内がされていることに気づきます。めんどくさいと思いながらもその番号に電話すると、今度は自動の音声案内が流れます。「xxxのお手続きをされる方は 1 を…」という案内に従い番号を押すと、なんと驚くことに、「この手続きはインターネットからのお申し込みが可能です。 xxx

カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。 カミナシには現在CTOがいません。 ただ、採用活動は進めておりますので、近い内に採用活動が花開くことを切に願っております。 本記事では、将来のCTOを迎えるにあたり、EMである私が直近半年で何を考え、どんな対応をしてきたかについてまとめました。 カミナシが求めるCTOとはCTOを採用したいという話が挙がった際、カミナシは具体的にどういった方をCTOとして迎えたいのか議論になった事があります。 ここでよく議論の分かれ目になるのが、実務者のTOPとしてのCTOか、経営者としてのCTOか、という2つの観点です。 当然、両方の性質を備えているのが望ましいのですが、究極的にどちらの要素しか満たさざるを得ない場合、どちらを選択すべきか関係者の認識を揃えておく必要があると思います。 結論、カミナシでは経営者としてのCTOを優先した

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。第11代黒帯（Webフロントエンド／ヤフー内のスキル任命制度）の伊藤（@koh110）です。 普段はCTO室にあるWebフロント技術室で、全社のフロントエンドに関わる仕事をしています。 最近の仕事のひとつとして、IE11 の非推奨の案内 がありました。 Yahoo! JAPANでは、Internet Explorer 11を推奨ブラウザーとしていましたが、Microsoft社のInternet Explorerサポート終了に伴い、2021年9月7日をもってYahoo! JAPANにおけるInternet Explorer 11でのご利用を非推奨とさせていただきます。 この案内についてTwitterや記事などで触れていた

自分の携わるプロダクト「ABEMA」にて、UIにおける文言のガイドラインを定めて運用している。 しかし、一部難しいなぁと思うテーマがあったのでメモ。 それが体言止め（名詞）と動詞についてだ。 ちなみに、その文言ガイドラインで何を記しているかはコチラ。 - 本ガイドラインのゴール - 簡潔に、正確に - 謙譲語・尊敬語について - 体言止め（名詞）と動詞 - 過去形と現在形について - 一人称と二人称（あなた or わたし） - 句読点について - 伝わりやすい言葉を選ぶ - 単語レベルでの表記ルール それぞれの項目について結構詳しく定めているのだが、本記事では体言止め（名詞）と動詞についてどのようなガイドラインにしたか、どこに悩んでいるかをメモってみる。 体言止め（名詞）と動詞について、どんなガイドラインにしているか 基本的にはテキストエリアが不必要に大きくなるのを防ぐために、ボタンやリス

はじめに GitHub で Mermaid がサポートされました。 Mermaid は図やグラフを描画するの独自の記法を持ちます。 その記法を Markdown のコードブロック中に記述するだけで図を描画できるのが便利です。 ...便利なのですが、記法が独特なことや機能が豊富なことから、とっつきにくいところもあります。 弊社[1]では みんチャレ 開発の情報共有ツールとして esa.io を活用しており、 esa も Mermaid をサポートしており以前から活用していました。 この記事では、私がこれまでに活用してきた中から特に便利だと感じた機能を紹介します。 ちなみに Zenn も Mermaid をサポートしているため図を描画できます。 Gantt ガントチャートです。 私が Mermaid を使いたいと思ったきっかけの機能です。 まずは、一番シンプルな例を書きます。 gantt Co

(There is good discussion on this article on Hacker News and Reddit) Reddit is currently the most popular search engine. The only people who don’t know that are the team at Reddit, who can’t be bothered to build a decent search interface. So instead we resort to using Google, and appending the word “reddit” to the end of our queries. Paul Graham thinks this image means Reddit as a social media sit

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ひとり情シス・ワーキンググループの発起人で座長を務める清水博氏は、企業・組織で情報システムの運用業務を少人数で担当する“ひとり情シス”の経験談やアドバイスを集めた伝記「ひとり情シス列伝」を同人誌として作成した。 清水氏によると、昨今のデジタル化の流れの中、これまで情シス担当者が全くいない“ゼロ情シス”状態の企業がひとり情シスを配置する傾向が強まっており、経験のないひとり情シス担当者からの問い合わせが増えているという。また、従来のひとり情シスもデジタル変革（DX）やシステム内製化などの新しいチャレンジが求められている。 ひとり情シスは会社の環境や仕事の範囲がさまざまであり、「具体的に即時回答ができるものが少ない」のが現状としつつ、同氏は「

月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ 本記事は豊田菜保子さんによる寄稿です。豊田さんは、楽天をはじめ、国内外の企業で人材育成やダイバーシティ推進を専門としてきました。現在は、スタートアップや起業家人材の支援プログラムを主に自治体と協力して企画・運営する傍ら、スタートアップやテック企業向けに「人」「チーム」「コミュニケーション」に注目した研修やアドバイザリーを提供しています。 逆境をポジティブに乗り切るメンタルスキル 知り合いにたまたま出くわして「こんにちは」と声をかけたのに、相手は冷たく塩対応……。そんなとき、あなたの頭には直感的にどんな言葉が浮かぶでしょうか？

提供社の都合により、削除されました。 関連ニュース ランキング 総合 国内 政治 海外 経済 IT スポーツ 芸能 女子

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗