タグ

2021年9月26日のブックマーク (15件)

  • 機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス

    スタディスト 開発部 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2021年上半期、およそ6万行の JavaScript コードを TypeScript に置き換える作業を、半年間単独で行いました。 記事では、機能開発自体を止めずに、どのように走り切ることができたのか、ふりかえりたいと思います。 なお、記事の内容は、移行開始直後の登壇資料 “大規模 Vue アプリケーションの TypeScript 移行” と、移行完了後の登壇資料 “6万行の TypeScript 移行とその後” と重複する内容を含んでいます。 Teachme Biz と TypeScript弊社が開発している、マニュアル作成・共有システム Teachme Biz は、iOS/AndroidWindows など、マルチプラットフォームで提供されています。 その中でも、作成・管理に多く使われて

    機能開発を止めずに、6万行の TypeScript 移行を完了させた開発プロセス
    Tomato-360
    Tomato-360 2021/09/26
    状況が比較的恵まれているとはいえすごい話だ
  • 「MySQLのフェイルオーバーテストをする」と聞いてぼんやり思ったこと

    TL;DR 負荷をかけながらフェイルオーバーテストをするなら、負荷クライアント側で「どの書き込みが成功したのか」のログは必ず取っておく でないと、フェイルオーバー起因でデータロストが発生するのかしないのかのチェックができない フェイルオーバーシナリオ スイッチオーバー(手動での切り替え)を含めてざっと思いつくのはこれくらい。 スイッチオーバー mysqldの正常終了 mysqldの異常終了、特に、mysqld_safeやsystemdmysqldを再起動させてしまう環境 mysqldのハングアップ カーネルパニック ファイルシステムのハングアップ 電プチ スイッチオーバー たぶんHAソリューションを作る時にちゃんとテストするからこれはそんなに問題にならない気がするけれど、(レプリケーションベースのソリューションの場合)「レプリケーション遅延が起こってる時のスイッチオーバー」で何が起こるか

  • "6年分"のRailsバージョンアップをなめらかに行う方法! - AppBrew Tech Blog

    こんにちは、id:r7kamura です。業務委託という形で1年ほど関わりながら、美容のクチコミサービスLIPSに利用しているRuby on Rails (以下Rails) というWebアプリケーションフレームワークのバージョンを、4.2から6.1に上げました。 Rails 4.2のリリースは2014年、Rails 6.1のリリースは2020年なので、およそ6年分のバージョンアップを一気に推し進めたことになります。 今回はこれを題材に、この手のフレームワークのバージョンアップ時に起こりがちな諸問題や、やって良かったこと悪かったこと等について振り返ろうと思います。 あまりRailsに限った話はしないように心掛けて書いたので、こういったバージョンアップ作業に興味がある方にはぜひ読んでいってもらえればと思います。 変更の粒度など レビューのやり方 複数データベース対応で困った話 テストがなくて困

    "6年分"のRailsバージョンアップをなめらかに行う方法! - AppBrew Tech Blog
    Tomato-360
    Tomato-360 2021/09/26
    いい話だ
  • ついに、Webアプリでの帳票印刷のベストプラクティスを編み出しました💡

    PHPカンファレンス 2021 1週間前イベント 〜 帰ってきたPHP勉強会@東京 の発表資料です。 https://phpcon.connpass.com/event/224128/

    ついに、Webアプリでの帳票印刷のベストプラクティスを編み出しました💡
  • Rails 7はESモジュールをどう扱うのか? - @ledsun blog

    www.youtube.com の手順で作成したRailsアプリケーションの動作を見てみましょう。 このRailsアプリケーションの http://localhost:3000/posts のHTML、特にheadタグを見ます。 Post一覧画面のheadタグ なかでも気になるのは次の行です。 <script type="module">import "application"</script> アプリケーション用のJavaScriptとして読み込まれているのはこれだけです。 しかし、ダウンロードしているJavaScriptファイルはほかにもたくさんあります。 Post一覧画面で取得するJavaScriptファイル import "application" を実行してダウンロードしているJavaScriptのURLは http://localhost:3000/assets/applica

    Rails 7はESモジュールをどう扱うのか? - @ledsun blog
    Tomato-360
    Tomato-360 2021/09/26
    おもしろい仕組みだ
  • CIOpsとGitOpsの話 - inductor's blog

    はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ?」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub

    CIOpsとGitOpsの話 - inductor's blog
  • 資本主義以外の選択肢を模索する、経済学者・政治家によるSF経済書──『クソったれ資本主義が倒れたあとの、もう一つの世界』 - 基本読書

    クソったれ資主義が倒れたあとの、もう一つの世界 作者:ヤニス・バルファキス講談社Amazonこの『クソったれ資主義が倒れたあとの、もう一つの世界』は、『父が娘に語る 美しく、深く、壮大で、とんでもなくわかりやすい経済の話。』などで知られる経済学者にして政治家のヤニス・バルファキスによる、資主義に代わる制度についての提言を記した書というか、SF経済書というかといった感じの一冊である。 体裁としては完全にSF小説で、物語で中心になる時代は2025年と現代よりも少し先の未来。中心人物であるギリシャに住むコスタは、ユーザーの欲望を読み取り、それを擬似的に(脳内で)体験させる装置であるHALPEVAMと呼ばれるシステムを構築する過程で、偶然にも平行世界の自分と通信を確立することに成功し、自分(同名の人物でややこしくなるので、作中ではコスティ)とのやりとりを開始することになる。 で、このコスティ

    資本主義以外の選択肢を模索する、経済学者・政治家によるSF経済書──『クソったれ資本主義が倒れたあとの、もう一つの世界』 - 基本読書
  • ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白

    の問題意識 ソフトウェアの設計スキルはどのように獲得する(させる)ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは? ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更

    ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白
  • オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena

    定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

    オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
  • GitHub Actions + google-github-actions/auth で GCP keyless CI/CD

    GitHub Actions + google-github-actions/auth で GCP keyless CI/CD 追記 2021/10/08 v0.3.1 にすると aud 周りの設定変更が必要 ソース 追記 2021/10/07 OIDCトークン発行元のURLが変更になったようです ソース 要約: GitHub ActionsでCI/CD的なことやろうとしたとき、SecretsとかにGCPのService AccountのKeyとか置かなくてもデプロイとかできるようになったらしいのでやったらできた。 経緯 AWS federation comes to GitHub Actions という記事が出て。 GitHub ActionsのOIDC id tokenでGCPにアクセスしてみた といってGCPでもやれるか確かめた人が出て。 Use gcloud with creden

    GitHub Actions + google-github-actions/auth で GCP keyless CI/CD
  • 初心者でもわかるコンテナ / Docker / ECS 話 | DevelopersIO

    こんにちはクラスメソッドのスジェです。 今回、devio 2021 decadeでECSに関する内容で登壇するので、その内容をブログでまとめてみようと思います。 ECSというサービスがあることも分かっているし、たくさん使っていることも分かっているけど、どんなサービスなのか? なぜ使うのか?コンテナは何か? などコンテナについてよく知らない初心者でも理解できるように、コンテナとDocker、ECSについてご説明したいと思います。 始まり Amazon Elastic Container Service (Amazon ECS) は完全マネージド型コンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケールするのに役立ちます。- AWS ECS 公式ページ紹介文 コンテナについてよく知らない初心者に「コンテナ化されたアプリケーション」、「コンテナ

    初心者でもわかるコンテナ / Docker / ECS 話 | DevelopersIO
  • 設計に悩みすぎる前に手を動かしてみる話

    私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 題 次のような経験はないでしょうか? 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた

    設計に悩みすぎる前に手を動かしてみる話
    Tomato-360
    Tomato-360 2021/09/26
    とりあえず手を動かして考えるのって大事だな
  • JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー

    対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方

    JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー
    Tomato-360
    Tomato-360 2021/09/26
    思った以上に内部の話だった
  • 「良いコード」を書くための10のポイントとは?

    プログラマーがコードを書く際は、メンテナンス性を確保したり、パフォオーマンスを最大化したりと、なるべく「良いコード」を書くように努める必要があります。Uberでエンジニアリングマネージャーを務めた経験を持つチャールズ・アクセル・ダイン氏が、「良いコード」を書くために重要な10のポイントを解説しています。 10 principles for good code | dein.fr https://www.dein.fr/2015-10-01-10-principles-for-good-code.html ◆01:良いコードは革新的である コードを書くことで解決しようとしている問題が「都市間の人々の移動」といった古典的な問題である場合、ソフトウェアやハードウェアによって革新的な解決法を提供できる可能性があります。また、すでにコンピューターが用いられている分野でも、ユーザーにこれまで以上に優れ

    「良いコード」を書くための10のポイントとは?
    Tomato-360
    Tomato-360 2021/09/26
    良いコードは短い。それな。
  • リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ

    結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖

    リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ