なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介
はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている
サーバーレスアーキテクチャ再考 - ゆううきブログ
2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015
2020年のフロントエンドエンジニアの技術スタックの一例
年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr
はじめに 先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。 ポッドキャストはこちらで聞けますのでぜひどうぞ。 fukabori.fm そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。 なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。 サーバーレスと僕のこれまでとこれから - Sweet Escape 今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。 前提 現在の自分は株式会社Singular
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
【図解】コレ１枚でわかるゼロ・トラスト・ネットワーク・セキュリティ：ITソリューション塾：オルタナティブ・ブログ
「いつでも、どこでも働ける」環境を整えることは、いまや働き方改革の要件となっています。そうなると、社外に持ち出したデバイスで、社内システムやクラウドを活用して仕事をするのは当たり前となり、ネットワークにおける社内と社外の境界は意味を持たなくなります。また、ウイルスに感染したパソコンから社内ネットワークを介して感染を広げ被害をもたらす事故や、内部の悪意あるユーザーが機密情報を漏洩してしまうといった事件も後を絶ちません。 「社内は"善"、社外は"悪"」という前提に立ち、ファイヤーウォールで「社内外の境界を守る」従来の「境界防衛セキュリティ」は、もはや役に立たなくなってしまいました。 また、クラウドの利用拡大により、インターネットを介した外部へのアクセスは益々増大します。これらアクセスの全てを、ファイヤーウォールで守ろうとすれば、処理能力が追いつかずスループットの低下は避けられません。高速・大容
前々からこの手のことを書きたいとは思ってたけど id:k0kubun さんの下記エントリに触発されて書きました。 k0kubun.hatenablog.com tl;dr; 個人アプリ開発歴 前提 Heroku GCP Google App Engine Cloud Run Firebase Cloud Functions GitHub Pages 2022/8/14追記 GitLab Pages 2022/5/7 17:00追記：ブコメレス tl;dr; HerokuやFirebaseを駆使すれば割と無料でいける 若干お金を払えばもっと選択肢は増える 個人アプリ開発歴 2001～2002年あたりから個人HPでアプリを公開。後にVectorにも公開 アカウントは残ってるのでいまだにVectorからのレポートメールが毎月届いてます 2009年くらいから色々ウェブアプリを開発 Google A
はじめにGoogle Apps Script は無料で色んなことが実現できるため、ついつい「全て GAS でやっちゃおう」みたいな話になりがちです。Google Apps Script も万能ではないので、強み・弱みを理解した上で他の選択肢と比較して使うのをお勧めします。 Google Apps Script のプロジェクトを 2–30 個作ってきた中で、自分なりのプラクティスをまとめてみます。 この内容は Cloud Next ’18 in Tokyo で登壇したときの内容を含んでいます。この登壇から半年以上経ったのでアップデート部分も以下にまとめています。 Google Apps Script の強み・弱みまず、強みと弱みについてまとめてみます。 強み 1. Google Apps の API を簡単に呼び出すことができる一番の強みはこれだと思います。Google Apps Scrip
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
だめなITベンダー・SIerの行動特性：ITソリューション塾：オルタナティブ・ブログ
もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く
ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ
僕らを縛る Node.js という呪いについて
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
SaaS、IaaS、PaaS……最近「○aaS」という単語を目にする機会が増えた。何となく「クラウドを使ったサービス」ということは分かるが、詳しい違いを即答できるだろうか。 各単語にある「aaS」は「as a Service」の略で「サービスとしての」という意味。つまり、今までPCで使っていたソフトウェアや演算機能をインターネット経由で提供するサービスということだ。 最初のアルファベット一文字が、サービス化された特定の概念を表す。例えば「SaaS」なら「サービスとしてのソフトウェア」。頭に任意の文字を意味する「X」を付けて「XaaS」（X as a Service）とも総称する。各XaaSはどんな意味なのか。アルファベット順に見ていこう。 なお、「○aaS」と付くサービスは語呂合わせから特定の製品名までいろいろある。ここでは、基本的にクラウド関連のXaaSを取り上げるが、一部それに限らない
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
CDNのエッジで実行する系が面白い
先日の Next.js Conf で Vercel は Next.js の新しいバージョン「12」をリリースした。 興味深いのは、Vercel は同時にEdge Functionsというサービスを開始したことだ。 Edge Functions – Vercel 謳い文句のひとつに Push your functions to the edge とあるように、「エッジ」で実行される「関数」を提供するプラットフォームである。 ここで言うエッジとはなにかというと、Vercel は明言していないが CDN のエッジのことだ。 Vercel の例のように「CDN のエッジで実行する系」が増えている。例えば以下の 7 つだ。 Cloudflare Workers Fastly Compute@Edge AWS CloudFront Functions AWS Lambda@Edge Deno Depl
SIerの輪廻から解脱するための技術｜はまあ
モチベーション最近「SIer界の輪廻からどうやって解脱したらいいですか？」 という話をちょくちょく耳にすることが増えた。 それに対する"解答"というわけではないのだけど、輪廻からの解脱を目指すにあたり、どんな要素技術を学ぶべきかについてはある程度指針を示せると思ったので今回は、選ぶべき技術と、その理由について解説していきます。 SIer界で輪廻転生を繰り返したい人はジャバ言語のラムダ式を禁止にすべきか議論するほうが大事だと思うので、こんな記事にクソリプする前にさっさと帰って、どうぞ。 TypeScript解脱への第一歩は、なにはともあれTypeScriptだろう。 正直、この言語だけ覚えておけば、FaaS(Lambda, Cloud Functions)も書けるし、ReactによるSPAとか、なんならReact Nativeでアプリも書けるし、モダンな開発環境に必要なスキルセットがすべてま
ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ（隙あらばダイマしていく方針）。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝
はじめに 基本的にAWSエンジニアとして仕事していて、Azureは未経験でしたが案件で採用されて触れる事になりました。 Azure Functionsで処理する所があって私に一任という感じだったのですが、まぁAWS Lambdaみたいなもんでしょと（恐らく他の人も）思ってました。 それがこんな事になろうとは… 必要なリソースが多い まず戸惑ったのがこれです。 関数を書くまでに以下のリソースが必要です。 Azure Functionsのインスタンス（という表現が正確か不明ですが。） Lambdaと違って１つのインスタンスに複数の関数を乗せる形になります（１つ１つ作ってもいいですが…） プラン 料金プランの事だと思えば良いかと。なんですが、プランも１つのリソースなんです。。 Azure Storage アカウント コードや一部の設定情報などが保存されています。 Application Insi
秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ
サーバーレスのセキュリティリスク - AWS Lambdaにおける脆弱性攻撃と対策 - Flatt Security Blog
はじめに こんにちは、株式会社Flatt Security セキュリティエンジニアの森岡(@scgajge12)です。 本稿では、AWS Lambda で起こりうる脆弱性攻撃やリスク、セキュリティ対策を解説し、サーバーレスにおけるセキュリティリスクについて紹介します。 はじめに AWS Lambda について サーバーレスにおけるセキュリティリスク AWS Lambda で起こりうる脆弱性攻撃 Lambda での脆弱性攻撃によるリスク 脆弱性攻撃による更なるリスク OS Command Injection XML External Entity (XXE) Insecure Deserialization Server Side Request Forgery (SSRF) Remote Code Execution (RCE) AWS Lambda におけるセキュリティ対策 セキュリティ
AWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や見落としがちな Cognito の穴による危険性 - Flatt Security Blog
こんにちは。本ブログに初めて記事を書く、株式会社 Flatt Security セキュリティエンジニアの Azara(@a_zara_n)です。普段は Web やプラットフォームの診断やクラウド周りの調査、Twitter ではご飯の画像を流す仕事をしています。よろしくお願いします。 クラウドサービスが発展し続ける今日この頃、多くの企業がパブリッククラウドやプライベートクラウドなどを駆使し顧客へサービス提供しているのを目にします。そのような中で、サービスが利用するクラウドにおいて設定不備や意図しない入力、構成の不備により顧客情報や IAM をはじめとする認証情報が脅かされるケースが多々あります。 本記事では、そのような脅威の一例をもとにクラウドサービスをより堅牢で安全に利用する一助になればと、攻撃手法や対策などについて解説をしていきます。 また、私の所属する 株式会社 Flatt Secur
Modern Web Development on the JAMstack を読んでまとめた - console.lealog();
https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本？PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね？と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。（それでも長いけど） はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ
Javaがサーバレスに至るまでの道のり
はじめに 先日、JakartaOne Live Japan 2022というイベントで登壇させていただく機会を頂きました。 QuarkusやHelidonのような新しめのEEフレームワークがこれまでのPayaraやWebLogicとどう違うのか？ CloudRunのようなサーバレス環境でMicroProfileのどの機能が効果的に働くのか？ という点を最近のWeb開発周りのトレンドと絡めながら話ました。上記のようにアーカイブ動画も公開されていますが、せっかくなのでQuarkusがサーバレス環境で実行に最適化されるまでの周辺事情等をまとめたいと思います。Javaだけに留まらず最近の環境事情の整理にも役立つかと思います。 TL;DR Quarkus/Helidonは軽量で高速な新しいEEフレームワーク コンテナや、サーバレス、クラウドネイティブなど最新のトレンドに基づいた設計 GCPのCloud
こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2022年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2022年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの？」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2021年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 223個 です。 まとめるにあ
yagisan-reports開発チームリーダーのterurouです。 デンキヤギでは yagisan-reports という「Webで使うことを前提とした」商用の帳票エンジンを開発しています（厳密にはyagisan-reportsはエンジン単体の製品ではなくクラウドサービスとして開発していますが、この記事では帳票エンジンとして記載しています）。 yagisan-reportsとは 「Webブラウザ単体で動作すること」にこだわっている帳票エンジン です。 2023年11月現在、アーリーアクセス版を提供しています。既に3社5システムで本番稼働しており、一番長いものでは3年ほど本番稼働を続けています。開発中のシステムも含めると、さらに数社あります。 元々はアーリーアクセス版の公開から早めにパブリックベータに移行する計画だったのですが、ありがたいことに早期から大口の導入相談が複数あり、こちらを優
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートで寄付管理サービスを作った philan.netという寄付の予算を決めて寄付した記録をつけるウェブサービスを作ったので、この記事では技術的な部分の解説をします。 philan.net自体については、次の記事で解説しています。 寄付をするために、寄付の予算と寄付の記録をSpreadSheetベースでつける philan.net というサービスを作った | Web Scratch この記事では、Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートを使って動いているphilan.netについて解説します。 あと検証中にCloudflare Workersを色々いじったのでそれについても書いていきます。 Idea phila
こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。（以下AI Worker） 本格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG
Cloudflare Workers それは Frontend / Node.js が CDN Edge Side まで拡張されるもの
最近は Cloudflare Workers が熱くて、週末はずっとその調査しています。この記事はそのまとめです。 注意点として、手元でいろいろなパターンで動かして試してはいますが、プロダクション環境で運用したわけではないです。それを踏まえた上でお読みください。 特に断りが無い限り、引用文は DeepL で翻訳したものです。 Cloudflare Workers とはなにか Cloudflare Workers | サーバーレスコンピューティング | Cloudflare 一言でいうなら 「ServiceWorker の API が CDN Edge 上で動く JavaScript 処理系」 です。 Technology Radar では、まだ ASSESS(調査) フェーズという扱いです。 Cloudflare Workers | Technology Radar | ThoughtWo
はじめに 4年ぶりの開催となるServerlessDays Tokyoに参加してきました https://tokyo.serverlessdays.io/ 「もっとうまくやりたい、誰よりも上手にやりたい」 というメッセージとともに開催されたServerlessDays Tokyo 2023ですが、超豪華なスピーカー陣を国内外から集め、ここ数年のServerlessの成熟と未来をしっかりと味わえる濃いイベントです。 1日目がセッション、2日目がワークショップということで、熱力の高いうちに激熱なサービスを素早く学べる構成になっていて、とても充実した内容でした。 所感 4年前のServerless LambdaをはじめとするFaaSをいかに簡単にデプロイ、運用していくかというツール系の話と S3やSQS,SNSなどのFaaS以外のServerlessなサービスの組み合わせでLowOpsな仕組みを
Nature Remoやその関連サービスで使われている技術と今後の展望 - Nature Engineering Blog
Nature株式会社VPoEのid:Songmuです。当社でもエンジニアリングブログを始めることにしました。 NatureはIoTスマートリモコン製品のNature Remo1を主力製品としていますが、家庭の電力マネジメントのためのIoT製品スマートエネルギーハブNature Remo E2や、電気小売事業のNatureスマート電気3も提供しています。目指すところはクリーンエネルギー100%の世界の実現で、お客様に利便性と同時にエコであるという、気持ちの良いライフスタイルを提供したいと考えています。 先日、Nature Remoは累積販売台数30万台を越えました4が、エンジニアはハードウェアエンジニアが2名、ソフトウェアエンジニアが8名の体制です。ハードウェアも含め、技術領域が多岐にわたっているため、まだまだエンジニアを募集中です。 さて、今回は最初のエントリということで、Natureで使
Vue + TS に触れて2週間でシングルページアプリケーションを作ってリリースした話 - GS2 Blog
みなさん、こんにちは。GS2の丹羽です。 本日 Game Server Services は次世代版のベータテストを開始しました。 これまで提供していた GS2 を GS2 Classic と呼び、次世代版 GS2 を単に GS2 と呼びます。 gs2.io GS2 のリリースにあたっては非常に多くの新しいチャレンジを行いました。 それについては少しずつブログや登壇を通じて皆さんにお伝えしていきたいと思います。 今回は、GS2 のマネージメントコンソールをシングルページアプリケーションとして作りました。 しかも、Vue + TypeScript に触れて2週間で。というトピックで振り返ってみようと思います。 なぜ Vue + TypeScript にいたったか GS2 Classic のマネージメントコンソールは Google App Engine を使用していました。 弊社はフルサーバレ
2020/3/14 追記 昨年、PureSec も加盟している Cloud Security Alliance の Israel Chapter から、The 12 Most Critical Risks for Serverless Applications 2019 が公開されました。 ※本記事の公開時点で既に TOP12 が最新でした・・・ 本記事で記載している既存の TOP 10 の内容に大きな変更はなさそうですが（SAS-9 は Serverless Business Logic Manipulation に改題）、新たに追加された SAS-11、SAS-12 について本文に追記します。 既存の文章にも差分があるようですので、正確な内容は原文をご参照ください。 追記はここまで イスラエルのセキュリティスタートアップ PureSec による The Ten Most Critica
ちゃだいん（@chazuke4649）です。 今社内で改めて名著であるとしてその名前をよく見聞きする「Unixという考え方」。積ん読になっていたので最近ようやく読みました。すると驚くほど気づきが多かったので今回ブログで書いてみることにしました。 前提として日頃考えていること ちょっと自論ですが、IT（情報技術）、コンピューター、インターネット、これらの分野の本質は「課題解決」であると考えます。それを実現するための道具（手段）として現在私たちがありがたく使っている様々な技術が存在すると思うのです。それはどういうことかというと、これらの技術が発達した背景にはいつも何かの課題があり、それを解決するための工程や軌跡がこれらの歴史を作ってきたという風にみて取れるからです。例えば、ワールドワイドウェブの誕生は多くの場面で語り尽くされていますが学会の論文にて引用している文献をいちいちメールや郵送でやり取
すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！ トレードオフこそが設計である良い設計とか読みやすいコードみたいな話題はツイッターではバズりやすい話題です。 読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。 命名規則とか書き方のルール 従うべきクラス構造、アーキテクチャ構成の導入 サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか 名前や命名規則の統一とか書き方の統一とかは用語のリストを作って
Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog
本記事は 【Advent Calendar 2023】 15日目の記事です。 🎄 14日目 ▶▶ 本記事 ▶▶ 16日目 🎅 はじめに 想定している読者 一覧 まとめてみて 参考 はじめに クラウド事業推進部の小野内です。昨年5月にキャリア入社してから早1年半以上が経ちました。 入社以降、AWS、Google Cloud のデータ分析基盤の開発・運用に関わっておりますが、現在はGoogle Cloud メインでやってます。 試行錯誤の毎日ですが、Google Cloud案件をどんどん盛り上げていきたい所存です。 1年ほど前の投稿記事では、 Google Cloudの学び方について触れましたが、本記事ではGoogle Cloud案件を1年半程度経験してみて、 AWSと比較しながら、Google Cloudの主要なサービスについて、違いを整理しました。 想定している読者 AWS案件に半年以
基幹系システムのような社内システムにおいても、オープンソースソフトウエア（OSS）の利用が当たり前になってきた。クラウドサービスを利用する場合や、開発担当者と運用担当者が連携する開発手法DevOpsを採用する場合など、OSSの利用を避けられない。 多くの企業でOSSの利用が進む中、OSSを採用した当初は想定していなかった誤算に直面するケースが浮上している。商用のソフトウエアに比べてサポート期間が短かったり、サポートが充実していないため脆弱性が見つかっても放置してしまったりといった課題だ。ユーザー企業は安易に導入コストだけを見てOSSを採用するのは禁物だ。その後の長期間の運用・保守も含めた体制の検討が求められる。 「OSSの採用がここ数年で周辺システムから基幹系に広がった。その結果、ユーザー企業からは長期間、同じバージョンのソフトウエアを使いたいという要望が増えている」。OSSのデータベース
Google Cloud FunctionsがPHPをサポート開始。PHPでサーバレスの関数が記述可能に Google Cloud Platformにおけるサーバレスコンピューティング環境を提供するGoogle Cloud Functionsで、PHP言語のサポートがプレビューとして開始されることが発表されました。 Today we’re bringing support for PHP, a popular general-purpose programming language, to Cloud Functions. With the Functions Framework for PHP, learn how you can write idiomatic PHP functions to build business-critical applications & integra
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2020 年、 React 軸で学ぶべき技術 - mizchi's blog
Linuxコンテナの「次」としてのWebAssembly、の解説
熱量を失ったサーバーレスという世界（個人の所感） - Sweet Escape
マイクロサービス設計原則: SOLIDではなくIDEALS
なるべくお金をかけずに個人アプリを運用したい - くりにっき
Google Apps Script は何が強くてどんなときに使うべきかプラクティスをまとめてみた
内製化をすすめる知人へのアドバイス - Kengo's blog
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
いまさら聞けない「○aaS」 AaaSからZaaSまでアルファベット順に紹介
マイクロサービスに次に来るかもしれない言葉について - arclamp
AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば
Azure Functionsが辛すぎて泣きそうになった話
データベースと向き合う決意 | フューチャー技術ブログ
【2022年】AWS全サービスまとめ | DevelopersIO
なんで今さら帳票エンジンを新規開発しているのか
React Server Componentsに感じたフロントエンドの消失
Next.js + Vercel + Cloudflare Workers KV + Googleスプレットシートで寄付管理サービスを作った
新規サービスのバックエンド開発で3ヶ月経ったので、試した技術や取り組みをまとめてみた
ServerlessDays Tokyo 2023が最高すぎた！ - Qiita
サーバーレスアプリケーションの最も危険なリスク12選 - Qiita
「UNIXという考え方」から連想されるすべてのアイデア | Developers.IO
ソフトウェア設計のトレードオフと誤りを出版しました | フューチャー技術ブログ
基幹系への安易なOSS採用は禁物、バージョンアップ多発で運用保守が重荷に
Google Cloud FunctionsがPHPをサポート開始。PHPでサーバレスの関数が記述可能に