並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1432件

新着順 人気順

concurrentの検索結果1 - 40 件 / 1432件

  • React ステート管理 比較考察 - uhyo/blog

    こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント(使用者)で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子

      React ステート管理 比較考察 - uhyo/blog
    • 筋トレ男性を対象に、タンパク質の摂取量と筋肉・パフォーマンス・肝臓・腎臓への影響を調査した結果 | スポーツ栄養Web【一般社団法人日本スポーツ栄養協会(SNDJ)公式情報サイト】

      ふだんレジスタンストレーニングを行っている男性を対象に、タンパク質摂取量を1.6g/kg/日または3.2g/kg/日のいずれかとして16週間介入し、体組成や筋力、および懸垂、垂直跳び、持久力のパフォーマンスへの影響に差が生じるかを検討した研究結果が報告された。また、肝機能と腎機能のマーカーも測定し、それらの臓器への負担の違いも評価されている。結論には、「タンパク質1.6g/kg/日の摂取は、肝・腎機能マーカーに影響を与えることなく、下半身のピークパワーを除いた除脂肪体重、筋力、パフォーマンスの最大化に十分であり、若く健康な男性の安全な摂取量として許容される」と述べられている。 タンパク質摂取量とトレーニング内容とで4群に群分けして16週間介入 この研究の参加者は、ソーシャルメディアでの募集に応じた18~36歳の健康でレジスタンストレーニングを行っている男性48人。適格条件として、週3回以上

        筋トレ男性を対象に、タンパク質の摂取量と筋肉・パフォーマンス・肝臓・腎臓への影響を調査した結果 | スポーツ栄養Web【一般社団法人日本スポーツ栄養協会(SNDJ)公式情報サイト】
      • 大規模ゲーム開発で存在感を高めるErlang/Elixir ─ Nintendo Switch™とロマサガRSの事例から|ハイクラス転職・求人情報サイト AMBI(アンビ)

        大規模ゲーム開発で存在感を高めるErlang/Elixir ─ Nintendo Switch™とロマサガRSの事例から 大規模なゲーム開発で、プログラミング言語Erlang/Elixirの存在感が増しています。Nintendo SwitchのErlang活用事例と、ロマサガRSにおけるElixirの導入事例について、アカツキ島崎清山さんに解説してもらいました。 2019年6月1日、永田町JA共済ビルにて、Erlang & Elixir Fest 2019が開催されました。Erlang/Elixirを利用する開発者らを集めて国内で開催されるメインイベントとしては、2017年のElixir Conf Japanから数えて、今年で3回目を迎えたことになります。 Erlang & Elixir Fest 2019 参加費6,000円の一般枠が事前登録で埋まり、当日の来場者も150人を超えたErl

          大規模ゲーム開発で存在感を高めるErlang/Elixir ─ Nintendo Switch™とロマサガRSの事例から|ハイクラス転職・求人情報サイト AMBI(アンビ)
        • マルチスレッド・プログラミングの道具箱

          まえがき クラウド上の仮想サーバから手元のスマートフォンまで、いまや複数のCPUコアを搭載するマルチコアはどこにでもある環境になりました。ハードウェア側が並列(Parallel)・並行(Concurrent)処理に向けて急速に進化する一方で、ソフトウェア側つまりプログラミング言語の進化はさほど追い付いていません。並行処理記述の手軽さを求めた Go言語 や、マルチスレッド処理の安全性を重視する Rust言語 などが登場してはいるものの、「普通にプログラムを記述するだけで複数CPUコア環境で高速に走るプログラミング言語」は遠い夢物語のままです。 モダンなプログラミング言語や並列・並行処理ライブラリは、複雑で難解なマルチスレッド処理を直接記述しなくてすむよう、安全性・利便性の高い抽象化レイヤを提供します(例:Go言語のgoroutineとchannel、Rust言語の Rayonライブラリ)。し

            マルチスレッド・プログラミングの道具箱
          • JSの非同期処理を理解するために必要だった知識と学習ロードマップ

            はじめに JavaScript の非同期処理を学習してみて「ある程度自信を持って理解できたと言える」状態に到達したので、その感想とまとめの学習ロードマップとその中でどのような知識が必要になるかを紹介したいと思います。 あるいは、自分が実際に学習してきた道筋に基づいているのでショートカットとして参考にしてもらったり、使えるリソースなどの情報が共有できると思います。もしくは「JavaScript 初心者が非同期処理を理解できるようになるまでの道筋」というストーリーで1つのサンプルとして見ていただけるといいかもしれません。 ChangeLog 大きな変更のみをトラッキングしています。 2022-11-16 本の内容を反映させた追記・修正を追加 2022-05-21 構成を修正 「V8 エンジンから考える」の項目を追加 2022-04-30 「イベントループの共通性質」の項目を追加 「ロードマップ

              JSの非同期処理を理解するために必要だった知識と学習ロードマップ
            • Build your own React

              We are going to rewrite React from scratch. Step by step. Following the architecture from the real React code but without all the optimizations and non-essential features. If you’ve read any of my previous “build your own React” posts, the difference is that this post is based on React 16.8, so we can now use hooks and drop all the code related to classes. You can find the history with the old blo

                Build your own React
              • ブラウザにおけるメモリリークを解決するために読んでおけると良い資料 - mizdra's blog

                最近趣味や仕事の Web アプリケーションでメモリリークに遭遇して、頑張ってメモリリークの原因を突き止めて修正する、ということがあった。その過程でメモリリークについて色々調べて知見が溜まったので、学習資料の紹介という形でアウトプットしてみる *1。 前置き 紹介する記事がかなり偏っていることに注意 冒頭で触れたメモリリークを解決するために読んだ記事をまとめただけなので、内容にそれなりの偏りがある 例えば id:mizdra が遭遇したメモリリークは全てブラウザ上で発生していたものだったので、これから紹介する内容も主にブラウザにおけるメモリリークに焦点を当てたものになる GC がどうメモリをどう解放しているか、何故メモリリークが発生するのかは全てカット 調べれば色々な記事が出てくるので、必要に応じて読んでください 基本的な知識を抑える まずメモリリークとメモリ撹拌の違いを学ぼう どちらも同じ

                  ブラウザにおけるメモリリークを解決するために読んでおけると良い資料 - mizdra's blog
                • Facebook製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog

                  昨日、Facebook製のReact用ステート管理ライブラリRecoilが発表されました。Facebook製といってもReact公式のステート管理ライブラリとかそういう位置付けではないようですが、それでも大きな注目を集めているのは間違いありません。 そこで、筆者がRecoilに対して思ったことや、筆者の視点から見たRecoilの特徴を記事にまとめました。 なお、この記事の執筆時点では副作用の扱いなどの点はいまいち情報が揃っていません。この記事では速報性を重視し、コアのステート管理部分に絞って考えています。また、まだexperimentalなライブラリなので、今後この記事の内容からRecoilのAPIが変化したとしても悪しからずご了承ください。 この記事を書くときに筆者が色々試していたCodeSandboxはこちらです。 https://codesandbox.io/s/recoil-san

                    Facebook製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog
                  • Netlifyが日本からだと遅い - id:anatooのブログ

                    仕事で Netlify にデプロイしたSPAの読み込みが遅いので原因を調査してほしい、という依頼を受けてウェブパフォーマンス調査を行った。顧客から許可をもらって、この記事ではNetlifyに対してどういう調査をしたのかを書く。 結論だけをまず書くと、NetlifyのCDNのファイル配信パフォーマンスは日本国内からだと非常に悪い。パフォーマンスを改善させるためには、Netlifyに直接アクセスさせるのではなく、前段に他のCDNやキャッシュサーバを挟んだりするほうがいいだろう。 調査の前提 日本国内からのみの調査 サイトには静的なファイルをデプロイしているのみ 該当するNetlifyにデプロイしたSPAをブラウザで試しに開いてみると、確かに初回の読み込みのパフォーマンスがめちゃくちゃ悪い。 Chrome Devtoolsを開いてネットワークタブでどういうふうにリソースの読み込みを行っているのか

                      Netlifyが日本からだと遅い - id:anatooのブログ
                    • Reactのレンダリングに関する完全ガイド - Qiita

                      この記事はComplete Guide to React Rendering Behaviorの翻訳記事になっています。 ご本人(Markさん)にも許可を頂いて翻訳しております。 こちらの記事がReactのレンダリングを理解する上で今までで一番体系的で一番分かりやすかったので、ぜひ紹介したく翻訳させて頂きました。 翻訳ツールにもたくさん助けてもらいながら行い、意訳が出来ていない部分が多々あるかと思いますので修正依頼を出して頂けると幸いです! Twitterでも、フロントエンドに関する事や、アメリカでのエンジニア経験に関してツイートしているので、よかったらフォローお願いします。 Twitter: @hellokenta_ja 下記から本文です。 Complete Guide to React Rendering Behavior この記事は、Reactレンダリングがどのように振る舞うか、Co

                        Reactのレンダリングに関する完全ガイド - Qiita
                      • サービス間通信のための新技術「gRPC」入門 | さくらのナレッジ

                        たとえば次のような「user.proto」というプロトコル定義ファイルを用意し、これを変換する例を見てみよう。 syntax = "proto3"; message Picture { uint32 id = 1; uint32 width = 2; uint32 height = 3; enum PictureType { PNG = 0; JPEG = 1; GIF = 2; } PictureType type = 4; } message User { uint32 id = 1; string nickname = 2; string mail_address = 3; enum UserType { NORMAL = 0; ADMINISTRATOR = 1; GUEST = 2; DISABLED = 3; } UserType user_type = 4; repeated

                          サービス間通信のための新技術「gRPC」入門 | さくらのナレッジ
                        • Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか|ハイクラス転職・求人情報サイト AMBI(アンビ)

                          Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか Reactを取り巻く状態管理のアプローチは変化を続けていますが、いま知っておくべき手法とはどのようなものでしょうか。小林 徹(@koba04)さんに、現在、そしてこの先の状態管理について執筆いただきました。 こんにちは、小林(@koba04)です。 2019年5月に『SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷』という記事を書きましたが、そこから2年以上が経過し、Reactを用いた状態管理は大きく変わりました。本記事ではReactを取り巻く状態管理の変遷について解説します。 広がるReduxの採用 Hooksの登場 コンポーネントツリーから独立した状態管理 Concurrent Featuresによる新しいユーザー体験 状態とキャ

                            Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか|ハイクラス転職・求人情報サイト AMBI(アンビ)
                          • 書評:並行プログラミング入門 - Software Transactional Memo

                            TL;DR 並行処理を実装する人のこれからのスタンダードになる一冊。買い。 並行プログラミング入門 ―Rust、C、アセンブリによる実装からのアプローチ 作者:高野 祐輝 オライリージャパン Amazon 買ったら思いの外早く届いたのでパラパラと読み始めたら一気に読み終えてしまった。 総評 敢えて雑な喩え方をするなら The Art of Multiprocessor Programming (通称TAoMP本) の内容を薄めてRustやアセンブラや計算モデルを足したような本だった。 日本語の書籍としてはかなり珍しくWait-Free, Lock-Free, Obstruction-Freeの違いなどを適切に論じており、TTAS Lock, MCS Lock, TL2といった日本語では希少な情報が書かれているレアな本である。これらに付いて論じている日本語の本は知る限り (TAoMP本と昔僕

                              書評:並行プログラミング入門 - Software Transactional Memo
                            • 【C#】C# の async/await は実際にどうやって動いているか。 - ねののお庭。

                              はじめに 登壇版 Taskの本質 C# のイテレータ async/await Compiler Transform ExecutionContext builder.Start() の重要性 IAsyncStateMachine.MoveNext おわりに はじめに C#er は呼吸するように使っている async/await。 そんな async/await について、先日 Stephen Toub 氏 (.NET の中の人。中心人物の一人。) が How Async/Await Really Works in C# という非常に面白い記事を投稿していました。 この記事では Stephen 氏の記事をベースに、C# において async/await は実際どうやって動いてるの?というお話をしていきます。 以前に C#での非同期メソッドの分析。 という翻訳記事を書いたのですが、元になった記

                                【C#】C# の async/await は実際にどうやって動いているか。 - ねののお庭。
                              • Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog

                                チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な

                                  Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
                                • JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと【Backlog Play化プロジェクト】

                                  ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine(以下、JVM)上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ

                                    JVM上で動くWebアプリケーションがリソースを食いつぶす原因を探るためにやったこと【Backlog Play化プロジェクト】
                                  • Promiseをthrowするのはなぜ天才的デザインなのか - Qiita

                                    ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです(記事執筆時点1)。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした(Promiseが解決されるまでレンダリングできない)ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点

                                      Promiseをthrowするのはなぜ天才的デザインなのか - Qiita
                                    • Go + gRPCによるマイクロサービス構築 - 一休.com Developers Blog

                                      こんにちは。宿泊事業本部の宇都宮です。 最近、とあるマイクロサービスをローンチしました。このアプリケーションの業務的な役割は諸事情により省略しますが、以下のような特性をもっています。 社内の多くのサービスから利用される 一休.com 一休.comレストラン 一休.comギフト 一休.com海外 このサービスが落ちると、主要サービスの予約処理が止まる 😱 想定されるリクエスト数は、平常時で30req/sec、ピーク時には60req/sec程度になります。行う処理はシンプルで、DBにいくつかSELECT文を投げて、ビジネスロジックに沿った結果を返すことです。 また、基盤系のアプリケーションなので、各開発者の開発環境(WindowsとMacが混在)でも動作する必要があります。 したがって、このアプリケーションに求められる要件は、 高パフォーマンス 高信頼性 クロスプラットフォームで動作すること

                                        Go + gRPCによるマイクロサービス構築 - 一休.com Developers Blog
                                      • Facebookが開発した圧縮アルゴリズムZstandardについて調べた(非常に高速)(今日から使えます) - Lambdaカクテル

                                        Common Lispの処理系であるSBCLをインストールしようとしたら、追加でlibzstd-develというのを新たに要求されるようになっていた。見るからに圧縮系のライブラリだけれど聞き慣れないのでちょっと調べてみた。 ちょろっと調べたところ、以下のことが分かった: Zstandard(ゼットスタンダード?)というのが正式な名前。 Facebookが開発した。 Deflateよりも速いことを主眼においている。 BSDライセンス。 Linuxカーネルまわりで使えるようになっているほか、一部のディストロではパッケージの圧縮フォーマットとして使われているようだ。 Webというよりはどちらかといえばバックエンド的な箇所で使われている印象がある。 facebook.github.io zstd コマンド使ってみた 他の名だたる圧縮アルゴリズム同様、Linuxで直接ファイルに対してこれを実行して圧

                                          Facebookが開発した圧縮アルゴリズムZstandardについて調べた(非常に高速)(今日から使えます) - Lambdaカクテル
                                        • オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ

                                          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした(幸いすぐにキャンセルして事なきを得ました)。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確

                                            オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
                                          • 分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO

                                            基調講演「30分でわかるデータ指向アプリケーションデザイン」 ・ スピーカー 斉藤 太郎氏  Twitter:@taroleo / Github:@xerial Principal Software Engineer , Treasure Data 東京大学理学部情報科学科卒。情報理工学 Ph.D。データベース、大規模ゲノムデータ処理の研究に従事。その後、スタートアップであるTreasure Dataに加わり、アメリカ、シリコンバレーを拠点に活動中。日本データベース学会上林奨励賞受賞。OSSを中心にプログラミングやデータ処理を簡単にするためのプロダクトを作成している。 「30分でわかるデータ指向アプリケーションデザイン」最新の論文にも触れながら、分散データシステムの世界の魅力を伝えていきます。後半、@tagomoris https://t.co/TQ2TnsFIOT… — Taro L.

                                              分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO
                                            • React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング

                                              React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい

                                                React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング
                                              • React 18に備えるにはどうすればいいの? 5分で理解する - Qiita

                                                React 18はReactの次期メジャーバージョンで、2021年の6月にalpha版が、11月にbeta版が出ました。また、Next.js 12でもReact 18のサポートが実験的機能として追加されました。React 18の足音がだんだんと我々に近づき、アーリーアダプターではない皆さんの視界にもいよいよReact 18が入ってきたところです。 特に、React 18ではServer-Side Rendering (SSR) のストリーミングサポートが追加されます。現在ReactでSSRを行いたい人の強い味方としてNext.jsが存在しているわけですが、Next.js 12でもReact 18を通してストリーミングの恩恵を受けることができます(Next.jsではSSR Streamingと呼んでいるようです)。また、厳密にはReact 18とは別ですが、React Server Comp

                                                  React 18に備えるにはどうすればいいの? 5分で理解する - Qiita
                                                • Rubyの並列並行処理のこれまでとこれから - クックパッド開発者ブログ

                                                  技術部の笹田です。今日で退職するので、バタバタと返却などの準備をしています。 本記事では、Rubyの並行並列処理の改善についての私の取り組みについて、おもに RubyKaigi 2022 と 2023 で発表した内容をもとにご紹介します。 並行と並列はよく似た言葉ですが、本記事では次のような意味で使います。 並行処理(concurrent processing)は、「複数の独立した実行単位が、待っていればいつか終わる(もしくは、処理が進む)」という論理的な概念で、古典的にはタイムシェアリングシステムなどが挙げられます。 並列処理(parallel processing)は、「複数の独立した実行単位のうちのいくつかが、あるタイミングで同時に動いている」という物理的な概念で、古典的には複数のCPU上で同時に実行させる、というものです。最近では、1つのCPU上で複数コアが同時に動いている、という

                                                    Rubyの並列並行処理のこれまでとこれから - クックパッド開発者ブログ
                                                  • 結婚式のエンドロールを当日作った話

                                                    結婚のお礼と報告 でちょこっと書いた結婚式エンドロールをその場で作ってみたのお話 注意事項# 結婚式のエンドロールを自作したりするには結婚式場の協力が必須です。 作り出す前に式場に必ず確認を取りましょう。 PCからそのままプロジェクトにだせばいいじゃん!と思い込むのだめです(自戒) 動機# エンドロールを式場にお願いしようと思ったら高かったので、最近のイケてるサービスとか適当にガッチャンコすれば作れると思った。 今は反省している。 全体の構成# LINE Botに参加者から画像投稿を投げてもらう S3に保存すると同時に投稿者情報をDynamoDBに保存 投稿された画像にDynamoDBの投稿者情報から名前を追記 画像を全部結合して動画化し、事前に生成したエンドロールで必要な部分を結合 式の最後に流してもらう 全体の構成はこんな感じです。 サーバーレスアーキテクチャのお勉強がてら作ろうとした

                                                      結婚式のエンドロールを当日作った話
                                                    • 令和にふりかえる C10K 問題

                                                      C10K 問題 (the C10K problem) は1999年に Dan Kegel が発表した文章、ならびにそこで提示された「問題」です。文章はその後も2000年代前半に何度か更新されているのですが、さすがに令和に読み返すと、当初の問題意識がわかりにくいところがあります。 2000年からの10年は、 ソフトウェア面では、select(2), poll(2) にかわる新しいシステムコールの実装と、それを使ったアプリケーションの普及 ハードウェア面では、x86 アーキテクチャの64ビット移行、仮想化命令の追加と、マルチコア化 さらにそこにクラウドも登場する、面白い時代でした。ここでは、それらの出来事を中心に、さらに、当時の雰囲気をつたえるような日本国内のブログやインタビュー記事をまとめることで、C10K 問題が、さまざまな側面から解決されていく流れを説明したいと思います。 書き足したいと

                                                      • 並列処理がとても苦手なPythonはプロセスを分けよう コードを書く時に意識したい2つのTipsと2つの落とし穴

                                                        Go、Python、Kotlin、Rust、TypeScript の5つの言語について「並列処理、並行処理の手法」というテーマに絞り解説する「並列処理をGo/Rust/Kotlin/Python/JSで解説!思想の違いを体感しよう」。Python編では橘氏が登壇。Pythonで並列処理を行う際の設計方針と、実装上の癖について話します。 西川氏の自己紹介 西川大亮氏(以下、西川):ここからはPython編の「ちょっとしたデータ分析の並列化」というタイトルで、西川から話します。 GOに勤める西川です。今やっているのは、タクシーやハイヤーの営業支援。「お客さんを乗っけていない時間、どこを走ったらいいの?」とか「どういうところで待っていたら注文来やすいの?」というところのナビをする、「お客様探索ナビ」というサービスのいろいろなことをしています。小さなサービスなのでいろいろやっている感じですね。 P

                                                          並列処理がとても苦手なPythonはプロセスを分けよう コードを書く時に意識したい2つのTipsと2つの落とし穴
                                                        • Introduction to heredocs in Dockerfiles | Docker

                                                          Guest post by Docker Community Member Justin Chadell. This post originally appeared here. As of a couple weeks ago, Docker’s BuildKit tool for building Dockerfiles now supports heredoc syntax! With these new improvements, we can do all sorts of things that were difficult before, like multiline RUNs without needing all those pesky backslashes at the end of each line, or the creation of small inline

                                                            Introduction to heredocs in Dockerfiles | Docker
                                                          • FastAPI入門 - モダンなPythonフレームワークの特性をチュートリアルで手軽に学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                            FastAPI入門 - モダンなPythonフレームワークの特性をチュートリアルで手軽に学ぶ PythonのWebフレームワークとしていま注目を集めるFastAPIは、シンプルにコードが書けるだけでなく、パフォーマンスが高いWebアプリケーションのバックエンドサーバーが構築可能です。同フレームワークの勘所をPythonスペシャリストの杜世橋さんが、初心者向けのハンズオン、そしてより実践的な画像への自動タグ付けサービス実装をとおして解説します。 FastAPIはいま非常に注目されているPythonのWebフレームワークの1つです。Flaskのようにシンプルに書ける一方でPythonのType Hintの機能をうまく活用し、HTTPのリクエスト/レスポンスをPythonの関数の引数/戻り値とシームレスにマッピングして非常に効率的に開発ができるのが最大の特徴です。非同期処理にも対応していてその名

                                                              FastAPI入門 - モダンなPythonフレームワークの特性をチュートリアルで手軽に学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                            • 全てを書き換え続ける。N予備校Webフロントエンド実装6年のあゆみ - ドワンゴ教育サービス開発者ブログ

                                                              はじめに ドワンゴ教育事業 Web フロントエンドチームの berlysia です。 ドワンゴ教育事業が提供するオンライン学習サービス『N予備校』は、この 4 月でリリース 6 周年を迎えました。N 予備校の Web フロントエンドはリリース以来、全面的な書き換えを行い、今も続けています。 この記事では書き換えに伴う N 予備校の Web フロントエンド実装の変遷を説明し、これら書き換えの経験やWebフロントエンドという領域の性質を踏まえて、すべてを書き換え続ける選択をしていることを述べます。 この記事は berlysia が他社様イベント*1にて発表させていただいた話題を元に再構成しています。 speakerdeck.com ※JSConf JP 2021 で発表させていただいた事例とは異なるコードを対象にしています。 はじめに 実装の 5 つの世代 v1 v2 v3 v3(TypeSc

                                                                全てを書き換え続ける。N予備校Webフロントエンド実装6年のあゆみ - ドワンゴ教育サービス開発者ブログ
                                                              • 本当にtransactionは必要なのか? - 急がば回れ、選ぶなら近道

                                                                前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度

                                                                  本当にtransactionは必要なのか? - 急がば回れ、選ぶなら近道
                                                                • Go の sql.DB がコネクションプールを管理する仕組み

                                                                  Go の database/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基本的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接

                                                                    Go の sql.DB がコネクションプールを管理する仕組み
                                                                  • SQLite、複数クライアントからの同時書き込みを可能にする「BEGIN CONCURRENT」文を実装へ

                                                                    SQLite、複数クライアントからの同時書き込みを可能にする「BEGIN CONCURRENT」文を実装へ SQLiteの開発チームは、複数クライアントからの同時書き込みを可能にするBEGIN CONCURRENT文を実装していることを明らかにしました。 これまでSQLiteでは書き込みの同時実行はできず、つねに1つのクライアントだけが書き込み可能でした。 同時書き込み処理は、データベースのジャーナルモードが「wal」(Write-Ahead-log)もしくはwalを改良した「wal2」で、BEGIN CONCURRENT文を実行した場合に可能となります。 どのように同時書き込み処理が行われるのかについては、上記のWebページの説明を引用しましょう。 ロックが延期されることで同時書き込みが可能に まず、書き込み時のロックがCOMMITまで延期されることで同時書き込みが実現されると説明されて

                                                                      SQLite、複数クライアントからの同時書き込みを可能にする「BEGIN CONCURRENT」文を実装へ
                                                                    • GitHub Actions ことはじめ - tech.guitarrapc.cóm

                                                                      GitHub Actions 以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリを GitHub Actions に移行したけど、記事にしようとまとめてたらやった内容以上に調べることになってめちゃめちゃ時間かかった。 目次 目次 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id

                                                                        GitHub Actions ことはじめ - tech.guitarrapc.cóm
                                                                      • React+Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                                        React+Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計 遷移なく表示コンテンツを変更できるシングルページアプリケーションでは、ページの状態管理が重要になります。現在はReactによるUI構築とReduxによる状態管理を選択しているChatworkは、jQueryなどの技術的負債と共存しながら、フロントエンド設計の見直しを重ねてきました。クライアントサイド・アーキテクトの火村智彦(@eielh)さんと、エンジニア採用広報の高瀬和之(@guvalif)さんによる解説です。 クラウド型ビジネスチャットツール「Chatwork」は、2011年3月にローンチされて10年以上にわたり開発を継続してきました。このように長く続くサービスがユーザーに価値を提供し続けるには、時間経過による変化に適応するため設計の見直しが必要になります。 しかし、設計を

                                                                          React+Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                                        • Go製ミドルウェアのメモリリークを解決した話 - Mirrativ Tech Blog

                                                                          インフラ・ストリーミングチームの id:udzura (@udzura)です。今回は、Goミドルウェアのメモリリークを見つけて解決する際に、どのようなプロセスを踏んでいったかを解説します。 Go製のミドルウェアの概要 ミラティブでは、Webアプリケーションのみならず、ミドルウェアに相当する部分についても必要なものは内製しています。その中の一つに、社内で「Radisha」と呼んでいる各種集計とキャッシュなどを行うためのミドルウェアがあります。Radishaは以下のような特徴を備えています。 GET、SET、SETEXなど基本的なRedis互換のコマンドを実装している。そのため、既存のRedisクライアントライブラリから操作が可能である。 ランキング集計、一定時間内のアクセス集計などが行えるよう、Redis にない独自のコマンドを実装している。 高い可用性を志向しており、オンメモリのデータは

                                                                            Go製ミドルウェアのメモリリークを解決した話 - Mirrativ Tech Blog
                                                                          • Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO

                                                                            EC2やECS、RDSなどといったサービス利用時にAmazon VPC(以下よりVPC)が合わせて必要になります。 VPCの設計はCIDRとテナンシーの選択のみとシンプルですが、案外迷ってしまいます。 私が設計時に気をつけている5点をまとめてみました。 RFC1918準拠のIPアドレス範囲から指定する IPアドレスの範囲はrfc1918に準拠した範囲を指定することを推奨します。 少し難しく聞こえますが、下記のIPアドレス範囲から指定するということです。 10.0.0.0 - 10.255.255.255 (10/8 プレフィックス) 172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス) 192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス) よく見るプライベートIPアドレス範囲ですね。 16ビット以上で

                                                                              Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO
                                                                            • AWS Batch ベストプラクティスまとめ | Amazon Web Services

                                                                              Amazon Web Services ブログ AWS Batch ベストプラクティスまとめ この記事はプリンシパル HPC ソリューションアーキテクトの Pierre-Yves Aquilanti、AWS Batch のプリンシパルプロダクトマネージャの Steve Kendrex とプリンシパル HPC アプリケーションエンジニアの Matt Koop によるものです。 更新: 2021 年 10 月 5 日 セクション 2 に於けるサブネット CIDR ブロックのガイドラインを修正。 AWS Batch は、科学者や技術者が複雑なシステム構成を管理する必要なく、自由にスケールできる計算環境を提供するサービスです。2017 年に登場して以来、疫学、ゲームシミュレーション、大規模機械学習といった諸々のワークロードを稼動させる様々な業種や組織といったお客様に採用されてきました。 この投稿で

                                                                                AWS Batch ベストプラクティスまとめ | Amazon Web Services
                                                                              • React 18とSuspenseの基本 ─ フレームワークの選択やReact Server Componentsなど新しいベストプラクティスを学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                                                ハイクラス求人TOPIT記事一覧React 18とSuspenseの基本 ─ フレームワークの選択やReact Server Componentsなど新しいベストプラクティスを学ぶ React 18とSuspenseの基本 ─ フレームワークの選択やReact Server Componentsなど新しいベストプラクティスを学ぶ 群雄割拠のフロントエンドフレームワーク界でも、一歩抜きん出た存在として常に注目を集めてきたReact。2022年3月にリリースされたバージョン18では、Suspenseの安定化やStreaming SSRのサポートなど数々の新機能を取り入れて話題になりました。本記事では、React/TypeScriptのスペシャリストとして幅広く活躍されているuhyoさんが、現時点におけるReactのベストプラクティスについて解説します。 Reactは、Meta社により開発・公開

                                                                                  React 18とSuspenseの基本 ─ フレームワークの選択やReact Server Componentsなど新しいベストプラクティスを学ぶ|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                                                • ロボットエンジニアのためのgRPC入門 - MyEnigma

                                                                                  WEB+DB PRESS Vol.110 目次 目次 はじめに gRPCとは? gPRCの特徴 Protocol buffersでRPCを定義することで、様々な言語のサーバ・クライアント実装が自動生成可能 通信プロトコルにHTTP/2を使うことで高速化、双方向通信、streaming等を実現 通信のデータ量が小さく、データ解釈時の計算時間も短い ProtoファイルでのRPCの宣言 Unary RPC Server streaming RPC Client streaming RPC Bidirectional streaming RPC gRPCのサンプルコード Python Unary RPC Server streaming RPC Client streaming RPC Bidirectional streaming RPC gPRCのgの意味 参考資料 MyEnigma Supp

                                                                                    ロボットエンジニアのためのgRPC入門 - MyEnigma