![人気のGoogle Chrome拡張機能「PushBullet」が存続の危機 ~ストアの再承認に奔走/PCやタブレット、スマートフォンをシームレスに連携させるサービス](https://cdn-ak-scissors.b.st-hatena.com/image/square/524c38f9df851372322eb2844c815ca437adb9e4/height=288;version=1;width=512/https%3A%2F%2Fforest.watch.impress.co.jp%2Fimg%2Fwf%2Flist%2F1252%2F928%2Fimage1.png)
Quick startAdd Shrine to the Gemfile and write an initializer which sets up the storage and loads integration for your persistence library: require "shrine" require "shrine/storage/file_system" Shrine.storages = { cache: Shrine::Storage::FileSystem.new("public", prefix: "uploads/cache"), # temporary store: Shrine::Storage::FileSystem.new("public", prefix: "uploads"), # permanent } Shrine.plugin :
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo! JAPAN研究所 坪内と申します。今日は通知の話です。 プッシュ通知に気づかなかったり、タイミングが悪くてイラっとしてしまうことはないでしょうか? 最適なタイミングで通知する研究結果をご紹介します。 みなさんが目にする、ヤフーの広告の表示や、オススメの情報は、パーソナライズされています。つまり、過去のユーザーの行動履歴から「この人は釣りが趣味の人だ」と推測し、釣りに関するニュースや、釣竿のレコメンデーションをしています。これはプッシュ通知もしかりです。プッシュ通知は表示できる文字数や送信できる通知数に制限があります。ユーザーの興味などから、この人にはこの通知だ! というのを送ります。ここまでは、広告やレコメンデーショ
スペシャルサンクス @sega_yuu @frodo821 とある休日 娘(4歳)「ねえパパ」 ワイ「なんや、娘ちゃん?」 娘「非同期って何?」 ワイ「ひ、非道鬼!?」 娘「そうそう、非同期処理とかいうやつ」 ワイ「非道鬼を処理やて・・・!?」 非道鬼「ヴォ〜〜〜!!!」 娘「!?」 娘「・・・現れたわね、非道鬼」 娘「処理してあげる」 ワイ「娘ちゃん、まだ4歳なのに、もう厨二病か・・・?」 よめ太郎「おい」 よめ太郎「お前まさか、非同期も知らんのか・・・?」 ワイ「いやいや、まさかまさか」 ワイ「流石に知っとるわ」 ワイ「それはそれは・・・極悪非道な・・・鬼のことや・・・」 よめ太郎「お前が非道鬼に喰われてしまえ」 非同期処理とは よめ太郎「ええか、娘ちゃん」 よめ太郎「まず、同期って言葉は」 よめ太郎「タイミングが合うって意味や」 娘「じゃあ、非同期っていうのはタイミングが合わないって
最近、社内のいろんなプロジェクトのリポジトリを眺めているとスタイルシートの記述にstyled-componentsとかwebpackのcss-loaderとかで頑張っているものを頻繁に目にする。 んで、Lintとかどうしてるの?みたいな話をすると「〜はこの『A(どこかのCSS-in-JS派閥の一つ)』は対応してないんだよねー」という返答が返ってくる。 そのたびに思う。「BEMで問題解決してたんだからBEMでいいじゃん」と。 このようなことを言うと「JVMのJITコンパイラの仕組みを聞いた後に『アセンブラを生で書けばいいじゃん』と言い出す痛いおじさん」感がするので自分でもあんまり好きじゃない。ただ、CSSに関してはBEMで問題が底に達してしまっていて、そこから先の標準化されてないwebdevツール群は問題を再発明しているだけに過ぎないなと思う。 書き味をどう頑張ろうが結局我々はCascadi
Random musings on React, Redux, and more, by Redux maintainer Mark "acemarke" Erikson This is a post in the Blogged Answers series. Details on how React rendering behaves, and how use of Context and React-Redux affect rendering I've seen a lot of ongoing confusion over when, why, and how React will re-render components, and how use of Context and React-Redux will affect the timing and scope of tho
はじめに Cloud Runはサーバーレスなコンテナ実行基盤です。この記事ではフルマネージド版のCloud Runのみを対象とし、フルマネージド版のCloud Runを指して、単にCloud Runと表記します。 Cloud Runの料金プランの特徴として、リクエストの実行中のみ課金対象になるという点が挙げられます。しかし、リクエストのたびにコンテナの起動と終了を繰り返すわけではなく、起動したコンテナはある程度使い回されます。リクエストが無い間は、コンテナが起動していても課金されないというわけです。 課金対象の時間 (https://cloud.google.com/run/pricing?hl=ja より引用) だからと言って無料で使い放題というわけではなく、コンテナランタイムの契約として、リクエスト中しかCPUが使えないと明記されています You should only expect
Opens in a new windowOpens an external siteOpens an external site in a new window By Jay Lim and Gannon McGibbon At Shopify, we believe in highly aligned, loosely coupled teams to help us move fast. Since we have many teams working independently on a large monolithic Rails application, inefficiencies in code are sometimes inadvertently added to our codebase. Over time, these problems can add up to
webpack を使った code splitting のベストプラクティスとして,v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました. これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching | Web Fundamentals | Google Developers でも説明されている通り,「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで,キャッシュ効率をよくすることが主な目的でした. しかし時は流れ,いつしか「ライブラリのコー
この記事の目的 課題: Webサービスの各機能の仕様に関するセキュリティ情報があまりない Webサービスを設計するにあたり、よくある機能というのが存在するかと思います。 ユーザ登録 ログイン・ログアウト パスワード復旧 URLで共有 SNSログイン お気に入り登録 いいねボタン マイページ 通知 等・・・ これらに関して、自分の認識をまとめておきたい・意見をもらってブラッシュアップしたいと思い、記事を書きます。 大きい記事たくさん書くの大変なので、機能ごとに書こうかな・・・と思ってますが一つを育てていくかもしれないです。 前書いた記事が個人的には好評だったことも受けて、書いています。 ユーザ登録機能の仕様とセキュリティ toC向けサービスならかなりの割合で存在する機能です。よくある仕様パターンについて考えてみます。 この機能でユーザから取得するもの 認証情報(ID/パスワード) 連絡手段
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く