You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
I had an idea. Here's a little backstory. Many services provide a REST API on top of a SQL database. For certain datasources, flexibility in terms of queries is key. Often those use-cases are dashboard prototyping, for example with Grafana. This data is usually read-only statistical datasets where the user needs to run many queries in order to troubleshoot an issue or just find the best visualizat
まとめ netlify_lambda を使う Lambda の Docker イメージサポートを利用する aws-lambda-rie-gateway を使う この構成で Slack の interactive message や block kit で遊んだサンプルがこれ https://github.com/eagletmt/misc/tree/master/rust/slack-slash-command-sample Rust 向けの Lambda Runtime lambda-runtime という準(?)公式の crate がある https://github.com/awslabs/aws-lambda-rust-runtime が、リリースが滞っている。 現在リリースされている中での最新版では async/await の対応すら入っておらず、現在の Rust では正直使い物
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって間
こんにちは、 https://boxil.jp を作っている徳田(haze_it_ac)です。 先月に今風?な構成のAPIを業務で作ったので、その紹介をしようと思います。 作るもの・要件 雑な図 外部のAPIを叩くためのアプリケーションです。 BOXILのAPIサーバから今回作るAPIを叩き、そこから外のAPIを叩いて情報を取得したり、処理をしたりするものです。 現時点ではBOXILのみで使われていますが、それ以外からも使用されることを予定・想定しているため、BOXILとは別の基盤で作成しどこからでも実行できるように構築する必要があります。 なお、今回のサンプルリポジトリは以下になります。ソースコードと合わせて読んでみてください。 github.com 全体構成 概要 雑な構成図 AWS CDKを中心に据えた、AWS Lambdaで実行されるアプリケーションです。 実行環境 Webアプリケ
OpenJDKプロジェクトは、ソースコードのリポジトリをGitHubへ移行する作業が完了したことを発表しました。 jdk/jdk repository transition to Git, GitHub, and Skara is done https://t.co/uLKvfY8i5l — OpenJDK (@OpenJDK) September 7, 2020 これまでOpenJDKのソースコードは分散ソースコード管理ツールのMercurialを用いて、OpenJDKのWebサイト上(https://hg.openjdk.java.net/)で管理されていました。 2019年7月に提起された「JEP 357: Migrate from Mercurial to Git」で、コミュニティのソースコードリポジトリに関してMercurialからGitへの移行が提案され、同年11月の「JEP
先日の v-tokyo #11 の懇親会で質問されたので、Native TSX Support される Vue 3 でなぜ tsc だけで TSX が動作しないのかを聞かれたのでメモとして残しておこうと思います。 ちなみに Vue 3.0 beta が出た頃に既に検証し終えているコードは以下にあります。 https://github.com/potato4d/vue-next-tsx-only-tsc TL;DR Vue 3 にて、render function の h 関数が分離された h 関数の分離に伴い、 API が React のに近いインターフェースとなった この2点によって tsc だけで Vue TSX が動くようになったが、 近いだけで微妙に違う仕様によって実用は難しい 具体的には children のとり方が VNode[] か ...VNode かの違いがある Vue
この記事はpushをトリガーとしたGitHub Actionsのワークフローを前提として書いています。 概要GitHub Actions、簡単便利で良いですね! ぼくも遅まきながら使いはじめ、先日、Git pushをトリガーにデプロイしてSlackで通知、とよくあるワークフローを追加して運用しはじめました。 Slackへの通知も Marketplace に数ある既存Actionを選んで利用すれば、すぐに実現できました。すごい! ぼくはこんな感じにしたかったとはいえ、贅沢を言えば、ぼくは レガシーなCustom integrationsのIncoming Webhooksでなく、きちんと新しいIncoming Webhooksでやりたいref: https://api.slack.com/legacy/custom-integrations#incoming-webhooksAction独自
Breaking change: Puppeteer no longer uses Node’s EventEmitter library As part of our work to make Puppeteer agnostic of its environment we are removing the dependency on Node’s EventEmitter in favour of an event emitter that is not tied to Node. Under the hood we use Mitt, but we extend Mitt with additional functionality to match most of the methods that Node’s EventEmitter provides. The following
Microsoft Build 2020 で、Azure App Service の新たなオプションとして 静的サイトのホスティング を実現する Static Web Apps が発表になりました(執筆時点で Public Preview)。JavaScript で開発する Web フロントエンドのメインストリームである SPA(Single Page Application))や 静的サイトジェネレータを使う JAMstack の運用に最適化されているそうです。 詳細は 公式アナウンス や 公式ドキュメント: Azure Static Web Apps documentation を読んだ方がいいですが、ざっと現在わかっている機能や特徴を書いておきます。 App Service Static Web Apps の概要App Service Static Web Apps(名前が長いので以
あなたの頑張りや継続を記録し、育てたい。 そのすべてを、APIで。 Pixela はAPIサービスです。このサービスを使えば、あなたの日々の様々な活動量を GitHub のような鮮やかなグラフで表現することができます。 そのすべての操作を、APIで。もちろん、無料です。 スポンサーについて Pixela はほとんどの機能を無料で利用できますが、 有料の支援登録をしてくれた人だけが使える機能もあります。 そして、それよりもう少し多い金額を支援してくれているのが、ロゴ/アイコンスポンサーの方々です。 Pixela は世界の人々の頑張りや継続を応援しています。 あなたやあなたの会社もそれを応援していることを、ロゴやアイコンの掲載でアピールしませんか? もっと詳しく ロゴスポンサー - 企業
フロントエンドエンジニアからみる、この界隈で今どんなIssueが話題になってるのかと、この先どういう動きがありそうかについて。 そこまで自分に先見の明があるとも思ってないけど、アウトプットしておかないと忘れてしまいそうなので・・。 ちなみにここでいうフロントエンドは、いわゆるブラウザとかJavaScriptのAPIのことです。 プロトコル的な側面はそこまで詳しくないのであまり触れません。 WebRTC 1.0 GitHub - w3c/webrtc-pc: WebRTC 1.0 API まず、RTCといえばズバリのWebRTCから。 昨年末にWDからCRへ格上げということで、もうAPIが激変したりはしない・・はず。 実際のところ、ここ半年くらい大きな対応した覚えがないです。(WebRTCそのものを実装してる人は、地味にいろいろ対応してると思うけど) ガワのAPIという観点でいうと、最近はも
フロントエンドなエンジニアの皆さま、ご機嫌いかがでしょうか。 唐突な質問ですが、Internet Explorer 11というブラウザはお好きでしょうか。勿論大好きであられるかと存じ上げます。Webの歴史をまさにその身をもって築き上げてきた由緒正しきブラウザであります。唯一無二の王道です。昨今は様々なブラウザが溢れてあそばせております。しかし所詮それは一時的なこと。やがて全人類は母なるInternet Explorer 11の元へと還っていくことでしょう。 我々が目指したこと Internet Explorer 11(以下、IE11)を目にすること、操作すること、その他あらゆる接点を限りなく減らしつつ、プロダクトがIE11でも動作可能なことの検証と保証を行いたい。 これを成し遂げるエンジニアリング的な手段、つまりIE11環境でのE2Eテストを自動化することを目指します。 環境 自動化を行う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く