こんにちは。エムスリー・QLife(エムスリーのグループ会社)・エムスリーヘルスデザイン(エムスリーのグループ会社)でエンジニアとして各種作業に関わっている山本です! 以前もメール送信の話を書かせていただいたことがありますが、今回もまたメールネタとなります。今回のお題はメールセキュリティです。 大量メール送信のための予備知識 - エムスリーテックブログ すでにご覧になった方もいるかと思いますが、次のようなニュースが流れています。 www.proofpoint.com この「GoogleとYahooの新Eメール認証要件」ってつまりどういうことよ? というところを具体的にどのように進めているかについて書かせていただきたいと思います。2023/12/18追記 :Googleからメール送信にTLSを使うことが追加要件として示されました。 TL;DR とりあえず何から始める? 何はともあれ実際に

はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの?」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書きVue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで

※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。 序 planetter.comをバージョンアップすることにした。数年前にリリースしてからずっと放置していたけど、そろそろ手を付けないとやばいと思った。 しかしウェブの世界はドッグイヤーだ。3年も経てば何もかもが変わっている。しばらく開発から遠ざかっていた僕には、最近の技術トレンドなんてさっぱりわからない。 まずは自分自身をアップデートするところから始めよう。 Atom 最初はIDEだ。以前はEclipseを使っていたけど、いまはもうウェブ系言語の進化速度に追いつけていないようだった。ウェブ開発用のIDEならいまはWebStormが人気のようだ。有料だけど、最新の技術に対応しているし、使い勝手もいい。 でも最終的にはAtomを選んだ。IDE(統合開発環境)ではなくエディタなので、これ自体は単機能だけど、不足分は

この記事でWeb開発の未来を垣間見ることができるでしょう。UIの構築やサーバ、データ・エンドポイントの新しい見解を得ることができると思います。ここで、ブラウザとサーバコードの両側を含めたフルスタックな話をしていきます。これを読めば、 完全に機能するGitHubリポジトリ で紹介されたすべてのコードの検証や実行ができるようになります。皆さまが開発者として次の資質を持っていることを前提に話を進めていきます。JavaScript中級者HTML中級者 クライアント/サーバ間通信の基礎知識 JSONの基礎知識 Node.jsの基礎知識 上の知識がなくても、 おそらく この記事の進行についていけるでしょう。しかし、知識がないと私の紹介するコードを現実的なシナリオあるいは重要なシナリオに応用するのは難しいでしょう。インターネットは情報の宝庫なので、理解に必要な概念などをたくさん提供してくれます。必要

Webのフロントエンドで仕事をしているみなさんに質問があります。あなたにとってWebのプログラミングは、HTMLというマークアップを読み書きすることですか。それともDOM(Document Object Model)というツリー構造の操作でしょうか。今回は、この2つの関係を考えてみたいと思います。 マークアップ主義とテンプレートエンジンHTMLを書くのは簡単です。テキストにいくつかタグを付け足せば最低限のHTMLはすぐにできあがります。プログラミングの必要なDOM操作と比べると、このわかりやすさはHTMLの大きな利点です。 Web開発がマークアップの読み書きだと答えた人の多くは、おそらくRuby 用のERBやJava のJSP(JavaServer Pages)、Python向けのJinjaなど、サーバサイドで動くテンプレートエンジンを使っていることでしょう。テンプレートエンジンはH
いまやFirebugはWeb開発には必須の拡張機能ですが、Flashでも使いたいという方のために「FlashFirebug」という物がありました。 AS3で作れらたFlashのデバッグが、HTMLやJSをデバッグするように簡単に作業できるようになりそうです。 アドオンをインストールすると、FirebugにFlashパネルが追加され、閲覧ページ内のFlashをデバッグできるようになります。 Firebugのようなデバッグ ↑SWFにマウスオーバーした際に、HTMLのように要素を表示してくれます。 ↑YouTubeのサイトで、パラメータを操作している様子。 ↑エラーやトレースの出力ももちろん可能に。 これは開発が楽になりそうですね。 利用にはFlash Debug Playerバージョン10以上が必要との事。 ダウンロードは下のリンクからどうぞ。

前々から書こう書こうと思っていた、FacebookのJavaScriptSDKの解説エントリーです。APIや規格、HipHopやliftといったオープンソースなどの陰に隠れがちですが、このJavaScriptSDKもなかなか面白いです。 3行で解るJavaScript SDK 投稿・認証・署名を含めた全APIアクセスをサポート 公式なUIもついてくる Facebookアプリも、外部のマッシュアップサイトもこれ一つでOK つまり、これ一つで簡単なクライアント機能をもったサイトまたはFacebookアプリが作れちゃいます。 情報を取ってきてなにか書いてもらって投稿するのはもちろん、ちょっとしたクローリングをおまけにつけたアプリまでJavaScriptの範囲内で完結しますので、サーバー側で凝った処理を実装するのではなく、JavaScript側で可能な限り完結させるのがベストプラクティスといえま
去年に引き続きFirefox Developers Conferenceに参加してきました。 一応メモをとりながら聞いていたのでとても読みにくいですが公開。 内容がまとめきれないのは仕様です。 公式に動画と各発表者の資料リンクをまとめたものが公開されました(2010/12/22) Firefox Developers Conference 2010 : http://mozilla.jp/events/2010/fxdevcon/Twitterのハッシュタグ#fxdevconを保存しておいたもの。Togetter – 「Firefox Developers Conference 2010」 : http://togetter.com/li/71239 @teramakoさんによる発表者の資料や参加者の感想などをまとめたブクマはてなブックマーク – 特別でないただのブックマーク – f
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I(Web Services Interoperability Organization)が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました(参考:WS-I Completes Web Services Interoperability Standards Work(pdf))。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST(Representational State Transfer)と呼ばれるアーキテクチ

「LOAD IMPACT」はサーバの負荷テストができるサイトです。 サイトによりけりですが、数分から10分程度で完了します。(途中中断できます) 自宅サーバなどを立ててる方はチェックしてみると面白いかも。 当サイトでもやってみました。 (※悪用厳禁ですよ) 以下に使ってみた様子を載せておきます。 まず「LOAD IMPACT」にアクセスします。 無料登録ができますが、登録なしでも測定可能です。負荷テストしたいURLを入れます。 有料プランがありますが、左側の無料プランで最低限のチェックは可能です。負荷テストの結果です。 ユーザのロード時間がグラフで表示されています。 右側で結果を切り替えられます。 (ちなみにこの機能を使うには、無料登録が必要です。) 帯域幅の使用量でしょうか。 サイトをお持ちの方はチェックしてみてはどうでしょう。 (本記事で紹介したサイト:LOAD IMPACT)
Webアプリにおける11の脆弱性の常識と対策:Webアプリの常識をJSPとStrutsで身につける(11)(1/4 ページ)本連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPやASP.NET、Ruby onRailsなど)の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 【2013年2月25日】編集部より、おわびと訂正のお知らせ本稿において読者の皆さまより多数のご指摘をいただきまして、誠にありがとうございます。編集部であらためて調べた結果、間違いを把握し、あらためて修正版を掲載させていただきます。この度は、長期にわたり誤った内容を掲載したので、読者の皆さまに多大なご迷惑をお掛けしたした点をおわび申し上げます。 通常、記事に間違いがあった場合には、筆者確認後に修正版を掲載するのですが、今回の場

memcachedになにをキャッシュするのか 激遅なレスポンスなんだけど、dormandのmemcached記事。 dormando - Should you cache? この中でキャッシュの使い方でよく見る間違った使い方を指摘している部分があって、ここがとても重要だと思うので書いておく Where would you think to add caching to this system? I hope I've madeit too obvious.(システムのどこにキャッシュ機能を追加するべきだろう?) At the query layer!Use adatabase abstraction class and haveit memcache resultset objects and...No no no, that's a lie. I'm lying. Don't do
初心者にとってはトラブルが発生しやすいケータイWebアプリの開発。携帯電話への対応サイトを初めて開発するときに想定するべき9つの注意点を紹介する(編集部) 携帯対応サイトを開発するときの注意事項 携帯電話が普及してもう随分たちます。いまでは、サイトを作るときにケータイに対応するかどうか、必ず意識されるようになりました。しかし、ケータイ対応のWebアプリを作ろうとするとPC用のサイトと違う部分も多く、Web開発経験はあるけれど携帯の開発経験がない人にとっては取り組み難く、実際に想像できなかったトラブルがいくつも発生します。本記事は、Webサイトのモバイル対応を担当した私が、実際に携帯対応サイトを作ったときに発生したトラブルを踏まえて、携帯対応サイトを初めて開発するときに想定するべき注意事項を中心に説明していきます。 ケータイ向けとPC向けのWebページの相違点 インターネットへの接続方法に
Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 #以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く