タグ

2021年12月27日のブックマーク (11件)

  • 僕がPortXの開発を楽しんでいる理由|yu_tomori

    こんにちは。初めまして。 僕は12月からPortXというプロダクトを開発しております。PortXは国際貿易の見積査定業務を自動化するエンタープライズ向けのプロダクトです。 今日は、僕がPortXの開発を楽しいと思っている理由を整理してみたいと思います! 設計力が試されるプロダクトだということ僕は前職で受託開発をしておりました。その会社でエンジニアを始めた頃は、ほとんど設計論を知らないままにシステムを作っていました。結果として、この手で、たくさんのファットコントローラーや、技術的詳細に汚染されたビジネスロジックを生み出してきました。 このままだとコードを書くのが楽しくない日々が続くと思い、設計論を勉強するようになりました。設計論を読むと、それまでに脳内に溜まっていたアンチパターンがきれいに整理されており、時々に応じた解決策も提示されていて、非常に感銘を受けました。それ以降、設計論を読んでは、

    僕がPortXの開発を楽しんでいる理由|yu_tomori
  • スピード?柔軟性?アプリ開発もチームワークが必須!|バグプログラミング

    みなさんこんばんは!バグプログラミングです! 12月25日ですね。メリークリスマス!! でも今回もそんなクリスマスとは何も関係ない話をしますね(笑) 今回のテーマは「チームでのアプリ開発」です!アプリ開発も一人で作業する場合とチームを組んで作業する場合があります。その中で今回はチームごとのアプリ開発スタイルに焦点を当てようと思います。 【チーム開発の2種類の型】 チームでどのように開発を進めていくか?代表的な手法を2つ紹介します。 (1)アジャイル型開発 一度にまとめてでは無く、少しずつ確認をはさみながら開発を進めていくスタイルです。利用者の反応や、関係者からの継続的なレビューを得ながら、計画を調整しつつ進めて行きます アジャイル型 この方法のメリットは手直しにすぐ着手できて、仕様変更に迅速かつ柔軟に対応できるのが特徴です。一方でメリットもあり、進捗が把握しづらいという点もあります。このデ

    スピード?柔軟性?アプリ開発もチームワークが必須!|バグプログラミング
  • 社内の主要バックエンドをGKEに移行したハナシ

    はじめに こんにちは、ノハナのバックエンドエンジニアの野村です。 弊社のフォトブックアプリ「ノハナ」はサービスのMBaaSなバックエンドとしてParseServerを採用しています。 Parse Serverは元々Parse.comという名前のマネージドなサービスでしたがfacebookに買収された後に終了したので弊社ではParse ServerのOSS版をGCE Instance group環境でセルフホストしています。 その経緯は↓の記事をご覧ください。 ありがとう、さようなら Parse.com。ノハナがParse.comと共に過ごした4年間の話 また、元々Parse Server以外の各機能のサービスをGKEで運用しており、色々と課題が出てきたこのタイミングで既存GKE環境に新たに参加させることとしました。 この記事ではアーキテクチャ内容や移行方法などを記載していこうと思います。

  • マネーフォワードで1年間インターンをしてみて - Engineering from Scratch

    この記事はMoney Forward 関西拠点 Advent Calendar 2021の24日目の記事です。 23日目は,大倉さんのスクラムとボクでした。大倉さんの今までの経験,普段の思考が垣間見える素晴らしいポエムでしたね。 初めまして!マネーフォワード関西開発拠点でエンジニアのインターンをしている吉岡です。2020年の10月からインターンをしており,早くも1年以上経過したので,1年間のインターンを通して,どれほど成長することができたのか書いていきたいと思います。 まずは,インターンを始めた時と現状のレベルをざっと比較していきます。 インターンを始めた時のレベル プログラミングを始めて半年ほど 競技プログラミングPythonを使用(AtCoder茶色) Rails,Reactのチュートリアルを終え,ブログぐらいなら作れそう(テストは書いたことなく,動けばいいだろうという考え) クラス

    マネーフォワードで1年間インターンをしてみて - Engineering from Scratch
  • 面倒なドキュメント生成はCIにやらせよう - Gunosy Tech Blog

    こんにちは、koidです。 この記事は Gunosy Advent Calendar 2021 - Adventar の25日目の記事です。 昨日の記事は aitaさんの EKSにJupyterHubを構築した - Gunosy Tech Blog でした。 ドキュメントの更新って面倒だし忘れがち ドキュメントのメンテナンスを自動化しよう コードからドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 状態からドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 まとめ ドキュメントの更新って面倒だし忘れがち 題です。 みなさん、Pull Requestのレビュー時に、 ドキュメント・READMEも修正お願いします! こういったコメントをした/された経験ってありませんか? コメントをする側としても

    面倒なドキュメント生成はCIにやらせよう - Gunosy Tech Blog
  • CircleCIでTerraformする時のベストプラクティス - Qiita

    イントロ Terraformの実行は手動で行うことが多いと思いますが、これだと色々と問題があります。 コードをマージしたけどTerraformの実行を忘れる 毎回手動でやるのがめんどくさい それぞれの環境にTerraoformの実行環境を作る必要がある こうゆう手動作業にまつわる問題を解決するために、CircleCIで自動化しよう!っとなるわけですが実際にやってみると色々な問題に遭遇します。この記事ではCircleCIを使ってTerraformの自動化をする際のベストプラクティスについて解説します。 Terraformジョブの共通化 Terraformはディレクトリ単位でインフラを管理するのが通常なので各ディレクトリでTerraformコマンドを叩きます。forループで全ディレクトリに一つずつ cd して実行する方法もありますが宣言的に書きたいのでCircleCIのParameterize

    CircleCIでTerraformする時のベストプラクティス - Qiita
  • Nuxt アプリを Firebase Hosting + Cloud Run で SSR した話 - Qiita

    概要 Nuxt アプリケーションを Firebase Hosting にホスティングして SPA していたシンプルな構成を、SSR に切り替えたお話です。 Nuxt で SSR し、Firebase で認証&データ管理し、Firebase Hositng x Cloud Run でサーバーレスに配信し、CircleCI で自動ビルドするアーキテクチャについての知見を共有します! システムアーキテクチャ 青がユーザーのアクセスフロー 赤がデプロイフロー 実装手順 【①】アプリケーションを SSR で動作するようにする 【②】docker build&run で動作するようにする 【③】Cloud Run でアプリケーションが動くようにする 【④】Firebase Hosting でアクセスを受けて、Cloud Run にリダイレクトできるようにする 【⑤】ブランチへの push で Circ

    Nuxt アプリを Firebase Hosting + Cloud Run で SSR した話 - Qiita
  • CircleCI から Firebase Hosting にデプロイするまで

    やりたいこと CircleCI によって GitHub の master ブランチへのプルリクエストをマージしたタイミングで Firebase Hosting 環境にデプロイすることです。 Firebase を始めて利用する人向けに説明します。 また、CircleCI の説明については割愛します。 CircleCI について知りたい方はこちらの記事を読んでみてください。 Firebase Hosting にコマンドラインからデプロイするまで CircleCI から Firebase Hosting にコマンドラインからデプロイ前に、まずはコマンドラインから Firebase Hosting にデプロイまでについて説明します。 クラウド上でのプロジェクトの作成 まずは、Firebase のプロジェクトを作成します。 Firebase のサイトから「使ってみる」をクリックします。 <img w

    CircleCI から Firebase Hosting にデプロイするまで
  • 初心者が1人で CircleCI で CI/CD できるようになるまで

    はじめに 「 CI/CD ぐらい一人でできるようになりたい!」と思い、実際にやってみた備忘録になります。 流れ CI/CD 対象のプロジェクトの作成 CI CD CI/CD の結果を Slack に通知する "流れ" に対応する記事 以下の記事を投稿しました。 vue-cliでプロジェクト作成してあれこれ試してみた(初心者向け) CircleCI 試してみた CircleCI から Firebase Hosting にデプロイするまで CircleCI の Job の結果を Slack に通知する 途中で挫折しないためのポイント 3つ CI/CD 対象のプロジェクトは作り込まない CI と CD の仕組みは分けて作成する 興味のあるサービスを選択する

    初心者が1人で CircleCI で CI/CD できるようになるまで
  • CircleCI の Job の結果を Slack に通知する

    やりたいこと CircleCI のJob の結果を Slack に通知することです。 こちらの記事を参考にさせていただきました。 [CircleCI Orbsで、jobの結果をslackに通知する] (https://qiita.com/k_bobchin/items/11f0d778de09502de1f3#3-circleciconfigymlを設定) 記事の流れどおりで作成してみた備忘録のようなものになります。 Webhook URL の発行 CircleCI の対象のリポジトリから右上の「Project Settings」をクリックします。 <img width="1920" alt="qwerr.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/259125/5565f83b-f2f2-3b

    CircleCI の Job の結果を Slack に通知する
  • CircleCI 試してみた

    はじめに Git と連携した CI/CD を勉強したく、GitHub と連携できる CircleCI なるサービスがあるとのことなのでそちらを試してみた内容をまとめたいと思います。 ※初心者の備忘録になります。 やったこと 一旦、適当なリポジトリで CircleCI の使用感を確かめてから、命のリポジトリで試してみました。 とりあえず CircleCI を動かしてみる 適当なGitHubリポジトリで試してみます。 原理は一旦置いておいて、とりあえず試すための手順を説明します。 今回、使用するリポジトリのファイルは以下の通りです(なんでもいいです)。 <img width="945" alt="a.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/259125/d7bb14be-1df5-3f78-7

    CircleCI 試してみた