社内の2017新卒向けブートキャンプ ( 研修 ) にて使用したスライド資料ですが、せっかくなので一般公開します。
Mastodonが流行り、さくらのクラウドが馬鹿売れしてると聞いて、そんなこともあるのかと驚いた。世間ではp2pといわれるけどMastodon自体は典型的なサーバーだ。昔ながらのクラサバと違うのは他のインスタンスと連携するサーバーだという点だ。id:shi3zはそれをp2p2eといってるけど珍しいトポロジではなくて、みんなも普段から使っているインターネット自体の経路制御とか、名前解決のDNSとか、電子メールのSMTPとか、インターネット上の仕組みはそういう風に設計されてきたし、だから分散システムと呼べたのである。 僕はMastodonをP2P(+Edge)だと思っている。こんな用語は聴いたことないが、P2P2Eと略しても良い。 んで、P2P2Eとはどういうことかというと、少数のサーバント(server + client)が相互に対等な関係を保ちながら、各サーヴァントに対してエッジ(端末)が
通信の安全を保証するプロトコル「HTTPS」が採用されているURLの表記が正しければ、それが正規サイトだと認識するのは自然なことですが、ブラウザのURL表記上からは見抜けないフィッシング詐欺の危険性が指摘されています。このフィッシング詐欺は「homograph attack(ホモグラフ攻撃)」を進化させた手法を用いており、ブラウザに内在する脆弱性を突いたもので、人間が画面表示から詐欺サイトであることを見抜くことは不可能。現実問題として「ブラウザ側の対応を待つしか対策法はない」と言える状況です。 This Phishing Attack is Almost Impossible to Detect On Chrome, Firefox and Opera http://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.htm
nekodemo.com アートマネジメント、舞台照明、表現教育、地域コミュニティ文化、webマーケティング、金融をたしなみたい。趣味だじゃれ。 楽しいPVでおなじみ、割り勘アプリのpaymo。 私も最近は飲みに行くたびにpaymoで割り勘している。 本日時点のMy残高は32,480円だ。 一方で、銀行勤務の友人と飲みにいったときの反応は違った。銀行勤務の友人は、会員登録こそ手間取っていたが、paymoの存在自体は認知していて、「いつか使ってみたい」と思っていたそうだ。銀行勤務だからこそ、FinTech的なものには敏感なのだろう。 日本では、もともと銀行以外の事業会社は、送金業務をおこなうことが禁止されていた。しかし2010年に施行された資金決済法により、登録をしさえすれば事業会社でも送金業務が可能になった。 これはとても画期的な出来事だった。現代社会では、例えば給与が銀行口座に振り込まれ
「Front-End Developer Handbook 2017」がGitBookで無償公開。フロントエンドデベロッパーに求められるさまざまなスキル、要素技術、ツールなどを幅広く紹介する一冊 WebサイトやWebアプリケーションにおいて、ユーザーが操作する部分の開発を担う「フロントエンドデベロッパー」が扱う技術は急速に広がっています。 もちろんその基盤はHTML/CSS/JavaScriptにありますが、より高度で快適なユーザー体験を実現するにはその基盤となるHTTPやDNSといった下位レイヤの技術やSEOやUIデザイン、フォントといった細分化された専門性、そしてもちろんJavaScriptプログラミングやjQuery、React、Angularといったフレームワーク、JSONやAPIやパッケージマネージャ、ビルドツール、エディタやデバッガなどの周辺ツールとそのトレンドなど、とても一人
なんと4年ぶりのブログ更新。 FRILのリリースと同時に『フリマアプリ』が生まれて、早4年が経ちました。 今、世間で一番有名なフリマアプリは何?っと聞かれたら「メルカリ」と答える人が大半かと思いますが、「フリマアプリ」というジャンルも、UIも「FRIL」がはじめて生み出したものでした。(それだけに勝ちきれなかった悔しさは、もちろんあります。) 自分自身、フリマアプリというサービスがここまでスタートアップ業界、スマホ業界のスターダムを駆け上がっていくとは予想していませんでした。 最近、楽天グループ入りしたこともあってか「どうしてフリマアプリを創ろうと思ったんですか?」と質問して頂くこと増えてきたので、振り返りも含めてフリマアプリを創ろうと思った理由を書こうと思います。 起業のきっかけ 僕が起業しようと決心したのは2011年末。 元々、起業したいという思いからネット業界に飛び込み、当時はVOY
先日のデブサミ2016でピクシブの川田さんによるモデレートでGolang(メルカリのbokkoさん) × node.js(古川会長) × Scala(わたくし)という謎の組み合わせでパネルディスカッションをさせていただきました。 event.shoeisha.jp ユーザ層や適用領域が異なる言語ということもあり、噛み合うのか若干不安があったのですが、いい感じにまとまったのではないかと思いますw パネルディスカッションのまとめ 総論としては ハードウェアのリソースを使い切るために並行処理がますます重要になっていく ただし、アプリケーションのレイヤではなるべくそれを意識させないことが重要 という当たり前といえば当たり前の話だったのではないかと思います。ECMAScript7のAsync/Awaitは記述は同期的だけどブロックはしないという意味で理想に近いかもしれません。 普通にWebアプリを書
以前記事を書いてより毎号WEB+DB PRESSをいただいているが、感想を書いてなくて申し訳ない。謝罪から始めたが、11/24発売の第89号に載っていた@kazuhoによる速習HTTP/2という記事が非常に良かった。これはフロントエンド側の人からもっとデザイナーよりの人にまでも薦めることのできるHTTP/2の入門記事だと感じた。 もう結構な量が観測されるHTTP/2についての記事やページは、やはりサーバーを管理する人やネットワーク知識が豊富な人向けのものが多く、出てくるキーワードからなかなかの敷居の高さを演出してくる。それでも必要ではありそうなので頑張って読むが、もちろん僕をはじめとしたフロントエンド側の人に向けて書かれているわけではないので、ちゃんとは理解できない。それぞれの記事で20%くらいわかるというのを繰り返すことで少しずつ分かってきた……つもりという程度のものだった。この辺りはあ
2015/10/18(日)に開催された次世代Webカンファレンスで、WebRTCのセッションオーナーをしてきました。 まず、WebRTCのセッションにお越しくださった皆様・動画をご覧いただいた皆様、どうもありがとうございました。セッション冒頭に申し上げましたとおり、WebRTCに深くたずさわっていないと、チンプンカンプンなセッションだったと思います。当初の予定通り、用語解説などを加えていないので、馴染みのない用語を耳にした方も多かったと思います。 また、セッションオーナーを任せていただいたjxckさん、そして登壇を快諾いただいたVさん、tonofoさん、どうもありがとうございました。 当日の動画はこちらからご覧になれます。 すでに登壇者のtonofoさんが登壇メモを書かれているので、こちらも併せてご覧ください。 以下、このポストでは、セッションを迎えるにあたって私が考えていたこと・ネタ帳な
まずは、会場に来て下さった皆様、本当にありがとうございました。 ご来場の皆様が何か少しでも得るものがあったのであればいいなぁ…と考えます。 面白いイベントを企画して僕を呼んでくれた jxck には感謝しかありません。 このエントリでは、話足りなくてモヤモヤした部分を勢いで書きなぐってる感じなので、無駄に長い割にオチが無いので暇な人だけが読んで下さい。 観客として参加したセッションについて#僕が見ていたセッションは、 server_perfstandardizationhttp2monitoringです。僕の主観としては余り未来の話をしてなくて現状確認に終始した後に、最後の 15 分くらい未来をチラ見せみたいな感じだったかなぁ…と感じています。 しかしもって、未来みたいなものの話をするのは兎に角難しいので、少しでも未来っぽい話出来ればそれで良いんじゃないかと考えます。 セッションについて#僕
10月18日、法政大学にて次世代 Web カンファレンスが開催されました。Web に関わる技術について徹底的に話し合うイベント。セッションすべてディスカッションで勉強会というより話を聞きに行くというニュアンスが近いかもしれません。8 月に UX をテーマに議論する会を開きましたが、今年はこうした『会話』を軸にしたイベントに興味を惹かれます。 今回は、「デザイニングWebアクセシビリティ」の著者である太田良典さん(@bakera)、RDFの専門家でありコントラバス演奏者である神崎正英さん(@_masaka)と Webアクセシビリティをテーマに 1 時間ほど話をしました。私は Web アクセシビティの専門家ではありませんが、株式会社インフォアクシアの 植木真さんとのポッドキャストがキッカケで呼んでいただきました。3 者異なる視点から、Web アクセシビリティの現在と未来について話し合いました。
te = @teppeis wada = @t_wada con = @constellation vv = @vvakame 今JavaScript書く時に何で書いてます? vv = TypeScript + Babel? con = C++ばかり書いて テストはJavaScriptで書いてるのでES6 te = 趣味はES6、仕事はIE8で動くように書いてる IE8は来年1月に終わる wada = 趣味はES6+Babel、仕事はIE8 ES6の印象 vv = hoistingとか面倒な問題が減った wada = Arrow Function、Template Stringなどが便利 IE8対応 IE8対応してるひと = 半分 Babel、BrowserifyとかデフォルトのターゲットはES5以上 予約語の問題とかES3だと動かないことがある stefanpenner/es3-safe
お疲れ様でした。 セッションの内容に関しては動画がありますし、実況ツイートに関してはTogetterさんがしっかりまとめてくれてるのでどうぞ。 togetter.com front_archというテーマで登壇しましたが実況ツイートでも多く見られるように次世代成分が足りてなかったなというのは80分終わった瞬間に自分でも思いました。ので、ブログでちょっとだけ持論を補足しておきます。 標準仕様で繋がるWeb 私が次世代のWebに期待しているのは、異なるライブラリやフレームワークが標準仕様を通してコミュニケーションするのが当たり前になる世界です。 C88で頒布されたTechBoosterの「ジャバスクリプトゥーン」の第1章を書かせてもらいましたが、そのコラムでPolymerとその他のライブラリがWebIDLでコミュニケーションし、独自のHTML要素のAPI定義を他のライブラリから参照できるようにな
はじめに こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。 次世代 Web カンファレンス - connpass 以下自分のメモです。 server_perf (10:00-11:00) #405 メモ パフォーマンスの勘所としてクライアント側の変化があると思う @mirakui: スマホのWebとアプリの比率があがってる @xcir: デスクトップからのリクエストは減って、スマホのネイティブアプリでの処理が増えている。APIアクセスが主。 @cubicdaiya: Webからのリクエストが1割もなくて、ほぼネイティブクライアントからのリクエスト。15000qps。 APIリクエストが主になったことによりJSONのやり取りだけの単純なものになったが、リクエスト数は増えた。 高速化しにくい部分をどうパフォーマンス
その1 と その2 Sprockets の続きです。が、今回の作業は その1 の途中からブランチしてます。 Google Chrome の Dev Tools は Sass/SCSS の Source Map に対応しているので利用できるようにしてみます。が、Source Map は仕様も実装も流動的な状態で、環境によって動作しない可能性も大ありなので、あくまで参考まで。 リポジトリ上では Sprockets も Bootstrap も Compass も導入する前の段階からブランチを生やしました。 https://github.com/cu39/workbench/tree/sass-sourcemap-on-plain 新仕様と旧仕様 CSS リクエストへのレスポンスでブラウザに Source Map の位置(パス)を知らせる必要があり、その方法は2種類あります。 レスポンスの HTT
前回のつづき。 前回作った作業台に Sprockets を導入して assets 提供を分離します。といっても Sprockets 使っていくかどうか自分でも確信持ててないのでリポジトリではブランチにしておきました。 https://github.com/cu39/workbench/tree/sprockets Sprockets を導入するメリットとしては、このままデプロイするケースを視野に入れたときに圧縮機能を追加しやすかったりプリコンパイルできたりするところでしょうか(どちらも今回はやってません)。 というわけで、まずは Gemfile に sprockets 関連の gem を追加して bundle。 gem 'sprockets' gem 'sprockets-helpers' gem 'sprockets-sass' ディレクトリ構成を変更 前回の最後では以下のようなディレク
Slim, Sass/SCSS, CoffeeScript が使えて Livereload してくれるフロント周辺の作業環境がほしいと思いながらも自分にしっくりくる構成ができなかったんですが、最近 rack-livereload を見つけてピースが埋まった感じがしたのでまとめます。 https://github.com/cu39/workbench 記事を書くにあたり naoya さんのひな型に大いに影響されてますが、ここでは npm でインストールするのは bower だけにして基本的には Sinatra と Guard に任せています。 Sinatra, Slim, Sass, CoffeeScript 土台の土台としてシンプルな Sinatra アプリから。Gemfile を書いて bundle。 Gemfile source 'https://rubygems.org' gem '
昨日の続き。 こういうアプリケーションのテンプレートを管理するのに便利な仕組みはないですかねーと言っていたら @teppeis さんや @omo2009 さんに Grunt や Yeoman はどうかと教えてもらった。 Grunt はユースケースとしては JavaScript の連結や圧縮、SCSS/LESS なんかのメタ言語のコンパイルをするときに使うもの、つまり rake なんかと同じようなものと以前にチラ見した程度で知った気になっていたけども、ちょっと違っていた。Grunt は確かにタスクランナーではあるのだが、Node.js で実装している利点を十分に活かして、任意のファイルが更新されたのをトリガに一連のタスクを実行させたり、Grunt で Webサーバーを立ち上げて他のタスクと連携させたりといったことができるようになっている。プラグインの仕組みがあって、エコシステム的に結構活発に
ちょっと jQuery と簡単なサーバサイドの処理を組み合わせた処理を試しに書いてみよう・・・なんて時に、いちいち jQuery を取ってきて HTML を書いて script タグを書いてロードして sinatra 立ち上げて云々・・・というのが毎度面倒なので、ひな形になるアプリケーションを作った。 https://github.com/naoya/boilerplate ひとまず sinatra でサーバーサイドを書き、HTML は slim で、CSS は sass 。JavaScript は CoffeeScriptで書くにあたって jQuery、underscore、Backbone をロードしてある、というような構成にしてあります。 まあ、この類のことは人それぞれ自分なりにカスタマイズしてやっていると思いますが、どういうコンポーネントで構成しているかを、備忘録も兼ねてちょっと紹
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く