タグ

ブックマーク / d.nekoruri.jp (5)

  • #ssmjp で最近のサーバーレスの話をしました - めもおきば

    2/16のssmonline #32にて、「最近のサーバーレスの話」を話してきました。 スライドはこちら: 最近のサーバーレスの話 #ssmjp by @nekoruri おさらい:サーバーレスってなんだっけ? まずは軽くおさらいからです。 サーバーレスは性質をあらわしているので0/1であてはまるものではないですが、やはり完全従量課金という課金モデルに近づける努力をしているものをそう呼んでいきたいところですね。 最近のサーバーレス開発 サーバーレスといえば、FaaS(AWS LambdaやAzure Functions)で様々なサービスをイベントドリブンでつないでいくアーキテクチャが注目されてきました。「もう古い」はちょっと盛りましたが、単純にFaaSで処理をつなぐのでは、そういったイベントドリブンな「ピタゴラ装置」を管理するのが大変です。 失敗時の再送や、異常データの除外(DLQへの積み

    #ssmjp で最近のサーバーレスの話をしました - めもおきば
  • AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば

    ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ(隙あらばダイマしていく方針)。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝

    AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば
    mapk0y
    mapk0y 2020/06/09
  • 「通信の最適化」の論点 - めもおきば

    論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード

    「通信の最適化」の論点 - めもおきば
  • Linuxのうるう秒おさらい - めもおきば

    7/1 午前9時(JST)にうるう秒が挿入されますが、注意すべきポイントのおさらいです。 うるう秒って何よ NICTの資料の先頭7ページ目まで読んでください。 ざっくり言うと、現在の時計というのは「原子時計」が基準になっています。太陽の周りを回る公転周期に合わせて微調整するのがうるう年で、地球自体が回転する自転時間に合わせて微調整するのがうるう秒です。 現象としては、「月末」の日付が変わる直前に1秒追加されます。ただし、これはUTC(協定世界時)での話なので、日標準時では9時間の時差があるので朝9時(の直前)になるわけです。 時間の進みを表にするとこんな感じです。 UTC(協定世界時) JST(日標準時) うるう秒を知らない時計 2015年 6月30日 23時59分57秒 2015年 7月 1日 8時59分57秒 2015年 7月 1日 8時59分57秒 2015年 6月30日 23時

    Linuxのうるう秒おさらい - めもおきば
    mapk0y
    mapk0y 2015/07/03
  • 「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば

    定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日レジストリサービス

    「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
  • 1