フロントエンド連載の6記事目です。 今年のゴールデンウィーク（STAY HOME週間）に最近話題のSvelteに入門したので紹介を書きます。 Svelteとはなんですか？ 公式のサイトはこちらです。有志の方々が日本語翻訳のサイトを作ってくれています。たいへんありがとうございます！ Svelteは主にブラウザ上で動作するユーザーインタフェースを作るフレームワークで、ReactやVue.jsの対抗馬的な存在です。 特徴とReactやVue.jsなどほかとの違い公式サイトでも、コーディングする際のコード量が少ないという特徴があげられています。 詳しくはこちらのブログに書かれています。コードが多ければ作業時間とバグが増えてしまうため、コードが減らすことはこれらの問題を減らすことができるというようなことが書いてありました。またブログには具体的なコードで量の差について書いていますのでぜひ見てみてくださ

はじめに 参考 Stargz 概要 詳細 HTTP Range 互換性 Stargzまとめ eStargz 概要 最適化 TOC, TOCEntry Footer Stargz Snapshotter eStargzまとめ 実験 トークン取得 インデックス取得 マニフェスト取得 Footer取得 TOC取得 ファイル取得 実験まとめ 余談 応用例 自作ライブラリ 計測 まとめ はじめに コンテナイメージのlazy pullingが各ツールで利用可能になりつつあるようです。以下は stargz-snapshotter のメンテナである @TokunagaKohei さんによるブログです。 medium.com lazy pullingが何かを簡単に説明しておくと、コンテナイメージ全体を最初にpullせずにコンテナ実行後に必要なファイルのみを遅延でpullするものです。docker runしよ

広告技術部のUT@mocyutoです Gunosyではニュース記事を配信運用するメディア部門とアプリ上などに広告を配信運用する広告部門があります。 （本記事では「メディア」とはグノシーやニュースパスなどのサービスを指し、「広告」はそのメディアに出す広告を指します。） 今回は広告部門が運用している広告システムのスケールの仕組みについて紹介します。 課題 解決策 仕組み スパイクスケーリング スケジュールスケーリング スケールのロジックを記述 まとめ 課題 メディア側のシステムは各サービスごとにチームが分かれており、それぞれ別のシステムで稼働しています。 しかし、広告側のシステムは単一のシステムで動いており、各メディアの広告配信すべてを担っています。 そのため、サービスが増えるごとにトラフィックが増える仕様になっています。 特に速報などのプッシュ通知をメディアが送信すると一気にユーザはアプリを

1人で開発したら数ヶ月かかるマッチングサービスを、ローコード・ノーコードで3日で作った(Airtable/Notion/Zapier/Sendgrid/Firebase)zapierAirtablelow-codeNotionnocode Airtable,Zapier,Notion,Sendgrid,Firebaseを使って仮説検証用のプロダクトを3日で1人で作りました❗️ その中身と作り方を共有します。 ISSUEへ移動しました 実際に作ったプロダクトの情報も発信しています。 購読お願いします。 今すぐプロダクトを動かしたかった 考えてるアイデアがあり、そのアイデアをプロダクトを作って検証しようと思っていました。 ですが、すでにお客さんが集まっているのでこれからプロダクトを作り始めていると、 確実に待機時間が発生してしまう状況でしたので、ノーコードとちょこっとコーディングをしてプロダク

Next.js でテスト駆動開発を進める時に必ず関門となる各種機能のモックに関するベストプラクティスを紹介します。 今回は Router などの機能をモックした render を作成して、共通のコンポーネントとして利用することを目標としましょう。 バージョン情報 Node.js：15.11.0 React：17.0.2 Next.js：10.2.2 Jest：26.6.3 React Testing Library @testing-library/react：11.2.5 Router を使用した際の問題点 next/router

クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！　今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう

Transcript SQL 株式会社 AI Shift 三宅 悠太 1. データベース 2. SQL I 3.トランザクション 4. データベース設計 5. インデックス 6. 実行計画 7. SQL II データベース データベースとは “A database is an organized collection of inter-related data that models some aspect of the real-world “ (CMU) データベースとは、実世界のある側面をモデル化した、秩序 だった、相互に関連したデータの集まり DBMS • データベース管理システム（DBMS）は、データベースを管理するソフトウェア ◦ 例：MySQL, Oracle Database, SQLite, MongoDB • DBMSの目的は、アプリケーションが簡単にデータベースにデー

航空券とかホテルを予約する時は旅程を検索する度にブラウザのキャッシュを削除しないと価格が上昇していくんだけど 今それ（キャッシュ削除）をしたら欲しい航空券が525ドル→272ドルに下がった。倍額は詐欺に近い。

(※ 新しい予測を公開しました→ 東京の感染者数を5週間ぶん予測した (6月28日版)) いまこの瞬間にあなたがコロナに感染したとしても、潜伏→発症→検査→確定のタイムラグがありますから、1人の感染者数として発表されるのはずっと先のことです。つまり、ある程度先の未来は、「いま感染したばかりの人々」によってすでに決まっていると言えます。 ここでは、人々の緊張感と行動に影響する「3週前の感染者数の最大値」と、感染に影響する「2週前の人流」という、いずれもこれまで比較的高い相関を示してきたデータを元に、すでに決まっているはずの近い未来である2週ぶんについて、感染者数の推移を予測しました。さらに、予測した結果得られる「今後の感染者数の最大値」を二段ばしごのように活用し、計5週ぶんの未来まで予測しています。(ただし、3週目から先は、いまから変えられる未来でもあります) あれこれ条件を変えたシミュレー

フロントエンドの開発時に仮の API を使いたいってシチュエーションはわりとあると思います。 そんな時に、Mock Service Worker を使うと便利だったのでまとめます。 Mock Service Worker とは？ Mock Service Worker は、ネットワークレベルで API リクエストをインターセプトして mock のデータを返すためのライブラリです。API リクエストを含む処理のテストや、開発時の mock サーバーの代替として利用出来ます。 テストでの利用については以前こちらの記事でまとめました。 今回は開発時のモック API としての利用について書きます。 開発用の API というと、JSON Serverが有名ですが、Mock Service Worker では Service Worker を使ってリクエストを返すため、別プロセスでローカルサーバーを立

こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で

お仕事や, （個人的には）趣味のデータ分析・開発などでpandasをよく使う人です. pandasはPythonでデータサイエンスやデータ分析（解析）をやってると必ずと言っていいほどよく使うライブラリだと思います. お仕事で同僚やインターンが書いたnotebookをよく読む（レビューする）のですが, 煩雑なことやってるけどこれ一行で書けるやで 最初からデータを整理するとそんな面倒くさいことしなくても大丈夫やで ...といったコメントを返す機会が増えてきました. これらは当人たちにフィードバックしているのですが, このフィードバックの内容が案外重要な気がしてきたのでブログに書いてみることにしました. 読んだ方の理解・生産性の向上および, 「つまらない仕事が334倍楽になる」ような感じにつながると嬉しいです🙏 TL;DR pandasのread関数にはとりあえずURLを渡しておけ &使うカラ

連載目次 納品したシステムにSQLインジェクションなどの既によく知られた脆弱（ぜいじゃく）性がある場合、たとえその対応策が要件として定義されていなくても、ITの専門家であるベンダーには、そのことに気付き、ユーザー企業に注意喚起し、提案する責任がある。この問題を「ユーザーvs.ベンダー」という構図で見た場合の裁判所の考え方は、これまでの例を見る限り、ある程度の一致を見ているようにも思われる。 同じ問題を「ベンダーという企業vs.そこで働くエンジニアという個人」という図式で見た場合はどうだろうか。顧客に納品したシステムにセキュリティ上の不備があった場合、その責任はシステムを構築したエンジニアにあるのか、そのエンジニアを選任し、作業を監督する責任のあるベンダーにあるのか。 不備の責任は企業と従業員のどちらが取るべきか？ 「従業員は会社内部で責められることはあっても、対外的には会社が責任を持つべき

やはりデザイナーがアレだとフロントエンドエンジニアの生産性も著しく下がり、逆に良ければ上げることもできると思うので、自分が考えてる「デザインの側面からフロントエンドの生産性を考える」というのは割と筋がいいアプローチなのではという想いが深まった — フロントエンド大好きseyaさん (@sekikazu01) June 15, 2021 思いの外反響があり、もっと具体的に聞いてみたい・ディスカッションしてみたいというお声をいくつかいただきました。 せっかくの機会なので、現状自分が考えるデザインとフロントエンドの接合の最適化、カッコ良くいうと「Design-Frontend Ops論」を語っていこうかなと思います。 ※ 予防線貼っておくと、まだ全然実践できていないので話半分に聞いてください。タイトルに"仮説編"とついているのはそのためです。 ※ 一緒に探求してくれる気概あふれるデザイナーも募集

noteでの大きくなりすぎたNuxt.jsのアプリケーションを分割する取り組みについて

リニアの南アルプストンネルによる大井川渇水に就いてJR東海は「水量減少を最小限にする」と述べ、それを鵜呑みにして「なるべく水が出ない工事をするんだな」と考えている人がいるが、このJRの言い分は出鱈目な嘘である。以下その理由を述べる。 フォッサマグナ西縁を通る南アルプストンネルというと赤石山脈ばかりに注目が行くが、一番の問題点はフォッサマグナの西縁を通る事だ。しかも大深度で。 中学の地学で習ったフォッサマグナは大地溝で、本州を縦に切って断面を見ると西縁が静岡～糸魚川、東縁が千葉～柏崎のU字溝の形をしていて、U字溝の中には富士山、白根山、浅間山、八ヶ岳、箱根などの新しい活火山が入っている。 なんでこんなものが出来たかというとプレートテクニクスと日本海造盆運動に関係していて、太平洋プレートがユーラシア＆北米プレートに巨大な力で押し付けられながら沈み込む際に日本列島になる部分が大陸から離れる方向、