タグ

関連タグで絞り込む (578)

タグの絞り込みを解除

開発に関するd4-1977のブックマーク (1,799)

  • Rails開発でやっておくと良かったCI設定集 - STORES Product Blog

    STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 Rails開発で、どのようなアプリケーションでも抑えておくとチーム開発が少し楽になるポイントがあります。今回はいくつか実例を載せながら紹介します。 アプリケーションの設計的な部分や実装には踏み込まず、すぐに導入できます。 あくまでRailsアプリケーションについての記事ですが、他言語やフレームワークを用いていても同様のことができます。 1. シードデータが壊れないようにCIで担保する 新しいメンバーが入って環境構築をしてもらう度にシードデータが壊れており、 db/seeds.rb *1 を直すという作業を何回か経験しています。db/seeds.rbで実行する内容をテスト中に実行しておくとメンテされるようになります。 # db/seeds.rb # 定数データが必要であればここで呼ぶ req

    Rails開発でやっておくと良かったCI設定集 - STORES Product Blog
    d4-1977
    d4-1977 2021/08/22
    review dogきちんと使えてるかなあ、って不安になってきたので設定見直したい
  • 体制を考えるときに意識していること - id:onk のはてなブログ

    1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

    体制を考えるときに意識していること - id:onk のはてなブログ
    d4-1977
    d4-1977 2021/08/11
    ワカル。ワカルけれど、お風呂に浸かる感が減るなあって思う。でも大事な判断を近くの健康ランド?でしていたりする →「風呂場とかで思いつくはずという設定で暮らしています」
  • 大規模な縦割り組織に LeSSを導入するまでの1年間とその後 / ScrumFestOsaka2021

  • ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう|mtx2s

    ソフトウェアプロダクトをビジネスの中心に据える企業にとって、プロダクトの競争力を高めることは、一番の関心事です。だからこそ、プロダクトをより顧客価値の高いものに磨き上げようと、アップデートを繰り返すことに腐心する。 しかし、残念なことに、魅力的なプロダクトというものは、すぐに競合他社に真似されてしまいます。一度獲得した優位性を、長期間持続することは難しい。むしろ、競争優位性など一時的であることが普通だと考えた方が良い気さえします。 だからこそ、「プロダクトの競争力を高めること」と同時に、「プロダクト開発能力の競争力を高めること」が重要だと、私は考えています。魅力的なプロダクトを作ることに再現性があり、それを短期間で実現できる強い開発組織を作り上げるということです。競合他社も、プロダクトを真似することは簡単にできても、開発能力を真似することはさすがに難しいはず。 プロダクト開発に実行責任を持

    ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう|mtx2s
  • 150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話

    Nuxt.js で開発されていたAI受診相談ユビーのフロントエンドNext.js で作り直しました。 まだまだ仮説検証を繰り返すフェーズのスタートアップのため、機能開発を止めて一気に置き換えることはできず、機能ごとに少しずつ置き換えてリリースをしました。結果、5人のプロダクト開発チームによる機能開発と並走して、全体の移行を1人で1ヶ月の短期間で終わらせることができたので、その意思決定や過程、工夫を紹介します。 移行前の課題 まず前提として、移行前の Nuxt.js による実装は 2018 年に立ち上がったもので、当時 toC の Web サービスを持っていなかった Ubie が ほぼ 1 人の小さいチームで PoC 的に作り始めたものでした。また、当時の Next.js は今ほど多機能ではないプレーンなフレームワークでした。 これらを踏まえて、当時の状況で MVP を最速で作るための技

    150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話
    d4-1977
    d4-1977 2021/08/07
    きちんと計画たててやっている印象。 理想と問題と変更によるデメリットの受け入れなど、移行の派手さあるけれど、地道にやる事の大切さを感じます
  • kintoneのフロントエンド刷新に向けた取り組み - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。kintone開発チーム Webエンジニアの村田です。 記事では kintoneフロントエンドの刷新をはじめるに至った経緯と、その取り組みについて紹介します。 はじめに なぜフロントエンドを刷新するのか 小さくはじめる Proof of Concept リリース戦略を考える 移行前と移行後の技術スタック 既存資産の再利用 Closure Library製の複雑なコンポーネントを再利用する E2Eテストを再利用する スタイルを再利用しない 開発体制 フロントエンドエキスパートチームの支援 アクセシビリティチームの支援 生産性向上チームの支援 これからの活動 おわりに はじめに 現在 kintone 開発チームでは、フロントエンドの開発に使用している Closure Tools (Closure Compiler、Closure Library、Closure Templat

    kintoneのフロントエンド刷新に向けた取り組み - Cybozu Inside Out | サイボウズエンジニアのブログ
  • 若手エンジニアの俺がフロントエンドのビルドを早くしてReactも導入しちゃった話 - SMARTCAMP Engineer Blog

    またオレ何かやっちゃいました? こんにちは!!!スマートキャンプでエンジニアをしている吉永です! 自己紹介記事はこちら 前回の記事はこちら 弊社の主力サービスであるBOXILはリリースから時間が経っていることもあり、バックエンド・フロントエンドともに様々な技術的負債となる部分を抱えています。 また、その負債の中には普段の業務時間では手をつけにくいものもあるため、定期的に薪入れと呼ばれる開発改善日を設けています。 先月行われた薪入れはいつもよりも長い1週間の期間が設定されており、今回の記事ではその中で私が行ったフロントエンド改善の内容や、そこに至った経緯について説明します。 やったこと ビルドフロントの短縮 Reactの試験導入 BOXILのフロントエンドについて 現在のフロントエンドを改善するに至った経緯とその背景 フロントエンド負債の認識のすり合わせ 負債を話し合う会の開催 理想を話し合

    若手エンジニアの俺がフロントエンドのビルドを早くしてReactも導入しちゃった話 - SMARTCAMP Engineer Blog
    d4-1977
    d4-1977 2021/07/14
    「React化が途中で頓挫した場合」身に覚えがあります…
  • 「早くリリースして、早く改善しよう」の落とし穴―― 開発畑のプロダクトマネージャーの失敗から学べ

    はじめに はじめまして。ゆずたそ(@yuzutas0)と申します。私はソフトウェア開発者からプロダクトマネージャーへ役割を変更した後、多くの失敗を経て「マインドセットを切り替えること」の重要性を痛感しました。 この連載では、私が学んだ「プロダクトマネージャーのマインドセット」を解説します。 想定する読者・提供価値については、2つのパターンを想定しています。1つ目は「同じように失敗した経験のある人」です。自分の経験を振り返りながら「こうすればよかったのか!」と考える機会になるはずです。2つ目は「これから失敗を経験するであろう人」です。これから起きる課題について「こうすればいいのか!」と考える機会になるはずです。 注意・免責 ①連載の内容は、筆者の個人的な見解にもとづきます。適宜ご自身の立場に置き換えて、読み進めていただければと思います。万が一、誤りや不快な点がありましたら、どうぞ筆者個人宛

    「早くリリースして、早く改善しよう」の落とし穴―― 開発畑のプロダクトマネージャーの失敗から学べ
    d4-1977
    d4-1977 2021/07/12
    問題を見極めるために何を試すか?を決めて、見極めるための何かは、さっさとリリースしましょう、ということなんだと思う…が、エンジニアのどうやって作るとは、切り替えて判断するのが必要で切り替えコストが高い
  • Hotwireとは何なのか?

    はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは?」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として

    Hotwireとは何なのか?
    d4-1977
    d4-1977 2021/06/27
    気になるけれども、触ってない…
  • Spotifyの開発文化とスクラムの比較 - Qiita

    背景・前提 ※この記事は、社内で『ユニコーン企業のひみつ』を薦めるために書いた記事の転載です。mediumに書いていましたが、テックの話でもあるのでQiitaにも書きます。 「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」の記事を読み、『ユニコーン企業のひみつ』というが気になり、読んだ。 エンタープライズ企業の開発手法(アジャイル)と、Spotifyなどのユニコーン企業(※このの独自定義なので注意)の開発手法や文化を比較するような内容だ。しかし、実際には上記のブログタイトルはややミスリードで、アジャイルと全く異なるわけではなく、実際には次のような内容である。 (の中では明言されていないが)アジャイルソフトウェア開発宣言にあるような価値観は踏襲しているので、アジャイルの発展型の一つだと思う。「チームや開発者に権限を!」というモチベーションで、XPに近い雰囲気がある

    Spotifyの開発文化とスクラムの比較 - Qiita
    d4-1977
    d4-1977 2021/06/26
    🦄
  • 今年導入したちょっと捗るコマンド ベスト4

    d4-1977
    d4-1977 2021/06/06
    捗りそう。こうしたコマンド類を用意するのなんか億劫になってやらないでいるの良くないので、やりたい(環境整理中なのです)
  • Railsプロジェクトで好んで使っている便利な処理 - alpaca-tc

    Railsプロジェクトで、自分が好んで使っている便利な処理をまとめてみました。 core_ext編 sort_byは安定ソートではないので、with_indexを組み合わせて安定ソートを行う https://gist.github.com/alpaca-tc/ed793961f2db438abaae3c00b7e303fa RSpec編 partial viewでインスタンス変数を呼び出していないことをチェックするテスト https://gist.github.com/alpaca-tc/c19f00d583234a2c73eda6d8378b8c50 モデルが変更された際に、参照元・参照先の双方に関連が定義されていることをチェックするテスト https://gist.github.com/alpaca-tc/d53dee5977746256717c7522988b13d8 テーブルが変更

    Railsプロジェクトで好んで使っている便利な処理 - alpaca-tc
    d4-1977
    d4-1977 2021/05/30
    熟練さを感じています!プロジェクトが進んできて、あ、ナルホドって思うポイントが詰まってそう
  • クラウドエンジニア(AWS)ロードマップ2021 - Qiita

    お知らせ 2022年初頭に記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル:AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス

    クラウドエンジニア(AWS)ロードマップ2021 - Qiita
    d4-1977
    d4-1977 2021/05/30
    ロードマップが森のようだ!(全部できなくてもどこまで出来たらいいんや…)
  • Deploy Rails apps in 2021

    事業成長を加速させたエンジニアリングのウラ側 https://medpeer.connpass.com/event/211745/

    Deploy Rails apps in 2021
    d4-1977
    d4-1977 2021/05/30
    コレは良いモノそう
  • Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ

    CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま

    Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ
    d4-1977
    d4-1977 2021/05/30
    コレは良いモノそう
  • デザイナーが個人開発をしてわかったこと|りゅー

    こんにちは、デザイナーをしているりゅーです。 Twitterなどで「デザインエンジニアになりたい」などと発信するくらい、デザインとエンジニアリングの両方をやっていきたいと考えていた中で、 ついに「企画からデザイン、実装、告知まで一貫してやった」経験をできたので、そのプロセスをまとめたいと思います。 作ったのは、「つぶやき読書」という読書メモアプリです。 #つぶやき読書 正式リリースしました!🎉 つぶやき感覚で読書メモができて、そのままTwitterなどにシェアできます。 1つずつ学んだり感じたことをメモできるので、10分読んだだけでも使えて 読書のハードルを下げられます🙌 ぜひお試しください! 【AppStore】https://t.co/QbYb9R07j1 pic.twitter.com/hQJ7KTXZkp — #つぶやき読書 (@tsubuyakiRead) March 21,

    デザイナーが個人開発をしてわかったこと|りゅー
    d4-1977
    d4-1977 2021/05/22
    プロトタイピング大切! そして偉業感!🎉
  • GraphQL IDE の “GraphiQL” をカスタマイズして、開発ツールとして活用する - Hatena Developer Blog

    こんにちは.マンガチームの id:mangano-ito です.最近は GraphQL API の開発を担当しており,GraphQL に関することを勉強したり実践したりしています.今回は開発ツールについてのお話です. GraphiQL とは GitHub API での使用例 GraphiQL を導入してみよう ツールバーをカスタマイズしてみよう ヘッダーやクエリをカスタマイズしてみよう 実際に開発ではどう使っているか GraphiQL とは graphql/graphiql: GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools. GraphQL API の使いやすい GUI クライアントです.GUI クライアントなので GraphQL ではなく Graph i QL となっているのが

    GraphQL IDE の “GraphiQL” をカスタマイズして、開発ツールとして活用する - Hatena Developer Blog
  • エンジニアといい感じに連携したいデザイナーの取り組み|taiga / 佐野大河

    こんにちは、デザイナーの佐野大河 @sn_taiga です。今日はエンジニアといい感じに連携したいデザイナーの取り組みについて話します。 社内でC2Cというデザイナー同士で学びを共有し合う場があり、そこで話した内容を社外向けにまとめました。 👉 C2Cについて詳しく書かれている記事はこちら チームのエンジニアにヒアリングしてみた画面を設計するときや仕様を詰めるとき、伝えるとき、動作検証をするときなどなど、日々デザイン業務に取り組む上でエンジニアとコミュニケーションを取るシーンは多いと思います。 そんな中自分が「エンジニアが開発しやすいように」よかれと思ってやっていることを付箋に書き出し、チームのエンジニアにヒアリングをしてみました。 良いと思った付箋に印を付けてもらい、その理由等を聞きました💬 「エンジニアが開発しやすいように」というテーマで書き出してみたものの、むしろデザイナーがエン

    エンジニアといい感じに連携したいデザイナーの取り組み|taiga / 佐野大河
    d4-1977
    d4-1977 2021/05/16
    最近、Figmaでのレビューを眺めていたりしたんですが、デザイナーだけにしておくことは避けたい気持ちと、Figmaに落とし込んでいく過程を邪魔したくない気持ちや、落とし込む前の関わり方とか悩ましい
  • フロントエンドの消失 - または戦争が激しくなる話

    React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド(とは?)の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域をい合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHPRails の領分を侵そうとし

    フロントエンドの消失 - または戦争が激しくなる話
  • ヘッドレスCMSって何?WordPressとの違いや特徴を解説

    企業が自社のコーポレートサイトやオウンドメディア上で定期的な情報発信をする際に、コンテンツの運用・管理をどのような方法にするか悩みますよね。インハウスで、かつマーケターなどビジネス側のメンバーだけで、素早くコンテンツを発信できる運用方法を構築したいと考えている企業も多いのではないでしょうか。 そこで登場するのが、世界中で広く使われているCMS(コンテンツ・マネジメント・システム)です。 CMSと言えば、まずはじめに名前が上がるのが、WordPress(ワードプレス)でしょう。WordPressは2003年に誕生したオープンソース型のCMSで、世界中で圧倒的なシェアを誇っています。しかし、最近ではWordPressや既存のCMSから乗り換えて、2018年頃から注目されはじめたヘッドレスCMS(Headless CMS)を導入する企業が増えています。 そこで、今回の記事では、「ヘッドレスCMS

    ヘッドレスCMSって何?WordPressとの違いや特徴を解説
    d4-1977
    d4-1977 2021/05/09
    わかりやすかった。WordPressでは痛い目にあった経験しかないのでやめていきたい。そういえば、Railsとかで自作したら大変なのかなあ。