YAPC::Hakodate 2024 前夜祭 rejectcon
YAPC::Hakodate 2024 前夜祭 rejectcon
Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における
どうも、まさとらん(@0310lan)です! 今回は、さまざまなWebサービスやデータベースと連携して、独自のWebアプリなどを手軽に開発できるサービスをご紹介します! データソースの連携や画面デザインなどはドラッグ&ドロップの操作で簡単に構築が可能で、ロジックやイベント処理などもわずかなJavaScriptを利用するだけで開発できるのが特徴です。 オープンソースで開発が進められており、セルフホストすることで大きな制限もなく活用できるのでご興味ある方はぜひ参考にしてください。 【 ToolJet 】 ■「ToolJet」の使い方 それでは、「ToolJet」をどのように使えばいいのか詳しく見ていきましょう! まずはメールアドレスを入力したら【Create an account】ボタンをクリックして無料のユーザー登録を済ませておきます。 メールアドレス宛にユーザー登録用のリンクが送付されるの
Jamstackを既存のシステムに導入するかを検討する機会があった。 紆余曲折したものの、未だに暫定的な結論しか出ていない。 とはいえ、わりと頑張った。 今回は Jamstackとはなんぞや? Jamstackの特徴 Jamstackの技術 弱みを解決する策 実際に検討した話 を雑に紹介したい。 個人的なメモなので、間違っているところがあるのを考慮願いたい。 Jamstackとは? JamstackのJamは以下の頭文字をとっている。 JavaScript APIs Markup まず、フロントエンドを持たないAPI群がある。APIはブラウザのJavaScriptから叩かれるかもしれないし、後述するようなSSG =「Static Site Generator」のフレームワークが叩くかも知れない。どちらにせよユーザーに配信されるのはSSGが出力した、Markup。つまりプリレンダリングされた
はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは?」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として
多くの人が気付かないうちにWeb2.0からWeb3.0への移行が進みそうです。アプリケーションの見た目は現在使っているものとほとんど変わりませんが、バックエンドで変化が進んでいきます。未来を予測する人ならば、クラウドを使うSiacoin、ソーシャルメディアのプラットフォームとしてのSteemit、さらに未来を予想する手段としてAugurも頭に浮かぶのではないでしょうか。 適正に動く最初のブロックチェーンがリリースされたことを見れば、人々がWeb2.0を離れWeb3.0へ向かっているのは明らかでしょう。なぜなら、開発者というのはテクノロジーとWeb2.0のユーザーフレンドリーな手法を身につけても、更に使いやすいと考えられているWeb3.0に着手しようとするからです。 上の図の分布では、いろいろな企業とWeb2.0のセグメントが示され、ブロックチェーンに基づいたプロジェクトのどれに勝ち目がある
ここでいうリビジョン管理とは、JavaScriptファイルやスタイルシートのファイル名に、ハッシュ値などのユニークな値(リビジョン)を付与すること。 そうすることで、ブラウザが古いファイルのキャッシュを利用してしまい変更が反映されない、という事態を回避できる。 手動でファイル名を更新することも可能ではあるが、ビルドの際に自動的に付与されるようにするのが一般的。 ここでは、webpackのv4でリビジョンを付与する方法を書いていく。 この記事で出てくるライブラリについては以下のバージョンで動作確認している。 webpack@4.23.1 webpack-cli@3.1.2 html-webpack-plugin@3.2.0 css-loader@1.0.1 mini-css-extract-plugin@0.4.4 clean-webpack-plugin@0.1.19 出力するファイルにハ
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの?という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元: テクニックではなく、今、本気で取り組むべきWebパフォーマンス (html5jパフォーマンス部 部長 竹洞さん) 心得 パフォーマンス向上に対する施策は大別すると以下の2通り 軽量化 (単純にやりとりするデータ容量を小さくすること) 圧縮 削除 最適化 (その時に最も適している実装・実行をとること) 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
初めまして、IT戦略3チームでUIUXデザインと社内プロジェクトのTech Leadを担当している高村といいます。この記事では、React Starter Kitという汎用的なWebプロジェクトテンプレートの実装を参考にしながら、改めて、なぜWebフロントエンドは複雑なのか、その解決方法は何かを振り返ってみたいと思います。この記事をきっかけとして、実際に現場でツール選定を行うフロントエンド開発者の方だけでなく、普段「フロントエンドには時間をかけたくない」と思っているサーバサイド開発者やWebディレクターの方たちに、「だからフロントエンドの課題は収束しにくいんだな」「フロントエンドといっても範囲は広いから、目的やユースケースを絞ってツールを選定しよう」と感じていただければ幸いです。 この記事はLINE Advent Calendar 2017の10日目の記事です。 Webフロントエンドの複雑
09月14日(金)に、僕が主催する勉強会の9回目「WEBエンジニア勉強会 #09」を開催しました。 今回は今まで最多の160人もの方に申込み頂き、当日は70人の方が参加してくれました。 参加者の皆さま、ありがとうございました。 主催者としては「やって良かった」と言う満足感を持って終えることができました。 本稿では、そんな勉強会の内容と運営について振り返ります。 1. 勉強会の登壇内容について 申込者アンケートの内訳 まずは、いつものように開会の際に、勉強会申込み時の「申込者アンケート」の内訳を公開しました。一問目「皆さん、どのような職種ですか?(複数回答可)」と言う問いの内訳は以下の通りでした。 職種 人数 サーバーサイド・プログラマー 91人 サーバーサイド・アプリ基盤エンジニア 14人 フロント・エンジニア 47人 フロント・デザイナー 23人 WEBディレクター / プロジェクトマネ
AirBnb がReactNativeをやめることが話題になってますね。 medium.com RNの未熟さ、社のRNのForkのメンテナンスコスト、JavaScriptのスケールのしなさ、JavaScriptCoreの実装の違い、クラッシュレポートが信頼できない、開発者は主に片方のプラットフォームしか知らないのでOSSのライブラリはバグってる、結局ブリッジを描く人間が必要、人が雇えない、山ほど出てくる…— Hello (@rejasupotaro) 2018年6月19日 以下私見です。 RN採用可否のフローチャート 自分がRN使いたいといって相談された際にはこういう感じで返してます。基本的にはExpo 採用可能か否かで判断してます。 Expo ではじめる ReactNative 開発環境 - Qiita プラットフォームごとにUXを突き詰める必要がある => RN やめとけ Q: 社内に
パリで発表されていたReact向けプロダクトがあまりにも未来に生きていて興奮したので、紹介させてください。 目次 目次 この記事のゴール 想定読者 はじめに 今回ベースとするソースコード React Nativeは何をするツールか Reactは何をするツールか React DOMとReact Nativeの違い Reactアプリケーションを描画するものたち React DOMの役割 React Nativeの役割 1. ネイティブ処理系の上でJavaScript処理系を動かす 2. Reactを動かす 3. Reactから渡された差分をネイティブViewに適用する React Native DOMはどこがReact Nativeなのか React Native DOMのやばいところ6連発 ReactからはReact Nativeに見えてるのがやばい Objective-C実装をJavaSc
普段お世話になっているwebツール達の紹介です。 以下のサイトはすべて 無料 & 登録不要 です。 正規表現 regexper 正規表現を可視化してくれます。 複雑な正規表現を書くときやコードリーディングのお供に重宝します。 Rubular Rubyの正規表現をテストできます。 JSON JSON FORMATTER & VALIDATOR JSON系のツールが集まったサイト。 それぞれ、サイト名とドメインが違うのでリンクはそのうちの1つになっています。 (画像クリックでそれぞれのツールに飛べます。) ひとつずつ紹介します。 JSONをフォーマットしてくれます。 出力結果は折りたたむことができるので、長いJSONを読むときにも便利です。 JSONを含めた様々なデータ形式を変換できます。 Inputの以下に対応。 CSV INI JSON XML YAML Outputは以下に対応。 JSO
ReactとAngular、どちらを選ぶべきか? 使用するJavaScriptフレームワークを選ぶ際、この2つはよく比較対象に挙がります。しかし、両者の特徴をよく理解していなければ、選定は困難でしょう。 今回は、両フレームワークが具体的にどんな強みを持っているのかを、Reactの専門家 小林徹さんとAngularの専門家 稲富駿さんに解説してもらいました。両フレームワークの設計思想から使用において考慮すべき点、今後実装される予定の機能まで、利用者が気になるポイントを網羅しています。 JavaScriptギークである2人のノウハウ、ぜひ選定の参考にしてください!
技術部開発基盤グループの鈴木 (id:eagletmt) です。 クックパッドではほとんどの Web アプリケーションが Amazon ECS 上で動く状態となり、またマイクロサービス化や新規サービスのリリースにより Web アプリケーションの数も増えていきました。 個々のアプリケーションでは Docker イメージを Jenkins でビルドして Amazon ECR にプッシュし、Rundeck から hako を用いて ECS にデプロイし、またその Web アプリケーションからは Amazon RDS、Amazon ElastiCache 等のマネージドサービスを活用しています。 このように多くの Web アプリケーションが存在し、また各アプリが別のアプリや AWS の様々なマネージドサービスを利用している状況では、どのアプリが何を使っているのかを把握することが困難になっていきます
どうも、まさとらん(@0310lan)です! 今回は、面倒な開発環境を一瞬で構築してブラウザ上からWebアプリを気軽に開発&公開できる無料のWebサービスをご紹介します! 完全なオープンソースで開発が進められており、React / Angular / Vueなどのプロジェクトを誰でも簡単にプログラミングできる高度なエディタを搭載しているのが特徴です。 【 CodeSandbox 】 ■「CodeSandbox」の使い方 それでは、まず最初に「CodeSandbox」の使い方から見ていきましょう! サイトにアクセスしたら、画面右上にあるボタンをクリックします。 次に、「React」「Vue」「Angular」などのプロジェクトを選択する画面が開きます。 ここで好きなフレームワークを選んだり、素のJavaScript(Vanilla JS)やCLIツール、GitHubからリポジトリを読み込んだ
・リアルタイムデータベース(Firebase Realtime Database) ・NoSQLデータベース(Cloud Firestore) ・アプリ利用状況の解析(Firebase向けGoogleアナリティクス) ・クラウドを利用したメッセージ配信(Firebase Cloud Messaging) ・ユーザー認証機能(Firebase Authentication) ・アプリのクラッシュ分析(Firebase Crashlytics) ・データ保存先の提供(Cloud Storage for Firebase) ・Webサーバーサービス(Firebase Hosting) ・サーバーレス機能の提供(Cloud Functions for Firebase) 各サービスについて詳しく見ていきましょう。 リアルタイムデータベース(Firebase Realtime Database) 「
会社のブログに書こうと思ったんだけど、ちょっとマイナスイメージを持つ人もいそうな気がしたので、個人ブログに書くことにした。 この3ヶ月くらい、システムのリニューアル(アプリ間で分散したロジックを集約するバックエンドサーバと、用途に応じたフロントエンドサーバを立てるみたいなマイクロサービス構成)をやっていて、そこでサーバ間のやりとりにgRPCを使っていた。すごーく雑な絵を書くとこんな感じです。 しかし、最近になってプロジェクトのスコープについて見直しが入りました。マイクロサービス化ではなく単純にレガシーJavaで独自FWなアプリをリプレースするだけになり、必要なのはSPAとSpringBootのAPIサーバだけに(要するにRails側のロジックをなんとかするのがスコープ外になった)。 で、SPAに提供するAPIのためにgRPC(+ grpc-gateway)を使うのはちょっとオーバースペック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く