$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81

公開してまだ３週間ほどだし、収益としても１０万円でしかないし、大きな事は言えないがここで個人開発サイトとその収益性について考えたことを記しておく。 世の中には＊＊億ドルのバリエーションを獲得したスゲー起業家の話か、個人開発サイトを立ち上げたものの収益なんてゼロに近くサーバー代とトントンの話かの両極端しか無いように感じる。 パッと立ち上げてだいたい１ヶ月でiPhoneXが買えるぐらいのサイト規模というのは、どんなレベルのエンジニアでも手が届く範囲内にあるのが実感だ。「人生賭けて起業！」とかそんな熱い話ではない。普段の仕事が終わったら、ちょこちょこコードかいて個人的にアプリを公開して収益を得る、ぐらいの話でしかない。「１億総クリエイター時代」なんて言われる昨今では、どんなエンジニアもこんな感じのやり方が世の流れに合っている気がする。 サイト内容 今回、開設したのはざっくり言うとこんなサイトだっ

Blazor との出会い 今年2018年2月7日に、自分のソーシャルネットワークのタイムラインに Microsoft のブログ記事が流れてきました。 A new experiment: Browser-based web apps with .NET and Blazor ブラウザベースの .NET による Web アプリフレームワーク、"Blazor" (ブレイザー) だそうです。 これを読んだ当時、自分はこんな感想を持ちました。 「 "ブラウザベースの .NET による Web アプリ" ってなんのこっちゃ? まだ実験段階的なこと書いてるし、急いで試さなくてもいいかー。それよりも、これまで作った Angular 1.x な Web アプリの Angular5 への移行を急がなきゃ...」 ...ということで、何度も import 文を書く苦行や、*[(xyz)] みたいな呪文マークアッ

Webブラウザー「Firefox」を開発する米モジラ（Mozilla）は2018年2月末までに、日本の政府認証基盤（GPKI）が提出していたルート証明書のプレインストールの申請を認めない決定を下した。

昨日炎上してましたね〜 ≫ 投げ銭サービス「Osushi」、サービス開始するやいなやオモチャにされてしまう セキュリティが甘いとかはともかく、うちの会社の何人かが「なんで違法なん？paymoとKyashとpolcaと何がちがうの？」とつぶやいていて、 たしかにどれも体験としては「誰かにお金を送れる」サービスだし、普通は違い分からんよなぁと思いながらその場でおこなった説明を、ちょっと肉付けしてここに記しました。 ちなみに正確にいうと現時点では「アウトっぽい」としか言えないです。 今まで世の中の誰も思いつかなかった、よっぽど革命的な法律の穴をかいくぐる仕組みを思いついたのかもしれないじゃないですか。 推定無罪！！！！！！ 公式の答えもないので断言はできません。僕も大人なので。 （昨日で26歳になりました） Osushiとはなにか？ Osushi（http://osushi.love/） Osu

のようなイメージではないでしょうか？ (灰色と橙色の分け方は作者のおすすめ度（匙加減）な気もしなくないんですが） はい…まさにこの通りですのでこれを参照頂ければなと思います。隅まで目を通していないのがバレますね。 では早速本題 🚀Introduction これが2017版 2018版 左の奴らが軒並みチョーヤバいです。雑だな！ まあここは導入みたいなもんなんで深くは追及しません。最早OSSや仮想鯖、クラウド環境化での開発は必須なんだってことが言いたいんだと思います。（適当） デザインパターンってのはGoF(Gang of Four)というおじさん４人がソフトウェア開発に取り入れたオブジェクト指向プログラミングにおけるこう書くとオブジェクト指向的にええと思う！っていうパターンの集まりです。全23種、知らず知らずのうちに使っているものも多いです。 なんで今追加されたのか僕にはよくわかりません

Contents 1 あらすじ 2 http://localhost:25 No Title - 1user 3 http://localhost:53 No Title - 1user 4 http://localhost:80 はてなブックマーク - ソーシャルブックマーク - 1user 5 http://localhost:25 No Title - 1user 6 http://localhost:53 No Title - 1user 7 http://localhost:80 はてなブックマーク - ソーシャルブックマーク - 1user 8 http://localhost:445 No Title - 1user 9 http://localhost:631 ホーム - CUPS 1.2.4 - 28user 10 http://localhost:901 Samba W

スマホゲーム開発のエイチームは、プログラマー向け技術情報共有サービス「Qiita」を運営するIncrementsを子会社化する。 スマートフォン向けゲーム開発のエイチーム（東証1部）は12月22日、プログラマー向け技術情報共有サービス「Qiita」などを運営するIncrements（東京都渋谷区）を子会社化すると発表した。 代表取締役の海野弘成氏らからQiita株式の100％を25日付で取得する。取得額は約14億5300万円。 エイチームはスマホゲームや引っ越し比較・予約サイト「引っ越し侍」などを手がける。中長期の成長を視野に、自社で参入が難しい事業のM＆Aを積極化する方針。Incrementsの買収で新しい事業展開を加速できると判断し、買収を決めた。 Incrementsは2012年創業。Qiitaを運営するほか、チーム内情報共有ツール「Qiita-Team」を開発している。2016年1

こんにちは。 yuku_t です。Advent Calendar が盛り上がっていますね。皆さんは何個参加していますか？僕は現状 2 つですが、すでに遅延しています… 😱 最近 Qiita に加えた変更内容をお知らせします。 12/1 に記事ページのデザインをリニューアルした際、重要視したのは 「読む人が記事に集中して読めること」でした。リリース後はしばらくコードブロックのカラースキームに Monokai を使っていましたが、記事ページのデザインとの調和がいまいちだったのと、 Qiita はエンジニアのためのサービスなのでコードのカラースキームはこだわりたい、記事に「Qiita 感」を持たせたい、などの思いからオリジナルのものに変更することにしました。 Before After また合わせて Atom と VSCode 用のカラーテーマを下記のリポジトリで公開しました: incremen

※本稿はピクシブ株式会社 Advent Calendar 2017 の9日目の記事です。 さる技術書典で書く原稿のためにHTTPについて調べていたら、こんな記述を見つけた。 HTTP/0.9 は、1991年以来使われている HTTP の最初の版です。 極めて単純ですが、あまりに低機能なので、現在ではほとんど使われなくなっています。 それでも HTTP プロトコルの一部として依然として広く実装されています。 ― HTTP/0.9 - SuikaWiki (強調引用者) 本当だろうか。 HTTP/0.9といえば、HTTP/1.0やHTTP/1.1に上書きされて悠久の昔に忘れ去られた、古のプロトコルであるという認識である。NetScapeもバージョン2.0からHTTP/1.1を実装している。 HTTP/0.9とは GETリクエストしか存在しない HTTPヘッダなんてない HTTPステータスコード

uzura です。 ファーストサーバ Advent Calendar 2017 の8日目を担当させて頂きます。 僕は会社では主にフロントエンドの開発を行っています。 今回 Advent Calendar に記事を投稿するということで、弊社サービスの Zenlogic にも使用されている Ruby on Rails や React.js を使いつつ、せっかくなので以前から作ってみようと思っていたサービスを（個人で）作ってみて、それについての記事を書きました。 rechord https://rechord.cc ソースコード (GitHub) どんなサービスなの？ コード進行を入力するだけで誰でも簡単に演奏/共有することができる Web サービスです。 コード進行って何？？ 音楽の知識が無い方には少々分かりにくい概念と思いますが、伴奏をする時の指針となるものです。 簡単に言うと、これ通りに弾

最近、Webサイトの高速化が話題になっています。 Wantedlyでもサーバーサイドのレスポンス速度はしっかりトラッキングして取り組んでいましたが、フロントエンドはまだまだやれることがあると認識し、悔しさを胸にさっそく動き出しています。 取り組むに当たって、まずは事例を集めていくことから始めました。サーバーサイドの実装を見ることはできないですが、フロントエンドは頑張れば覗けるので、Webサイトの高速化に取り組んでいそうな他のサービスをじっくり観察することで、自分たちのプロダクトに最適な方法を選択できるはずです。 様々な種類のサービスを提供しているサイトを調査してみると、その高速化の手法はサービスごとに結構違っていて、学ぶことが想像以上に多かったので、ブログにまとめてました。同じようにWeb高速化へのモチベーションが高まっている皆さんの参考になれば幸いです。 Netflixまずは、動画ストリ

CAの ahomu/1000ch さんからご恵贈頂き、レビュー書いてくれと頼まれたので、自分のパフォーマンスというものへの思いの丈と共に書評を書こうと思う。 自分も6年ぐらいフロントエンドぐらいやってきたけど、あんまりちゃんと用語定義をしないまま「勘」で調査しがちだったのと、彼ら二人がどの数値見てるんだろう、という視点で読んだ。 gihyo.jp 要約: これはフロントエンドエンジニアの勘を体系化/言語化したものだ フロントエンドエンジニアにとって Chrome DevTools は日常的にお世話になる、「これナシでは生きていけない」という類のツールだ。だが、これの読み方は癖があり、経験的に蓄積してきた積み重ねがなければやや難しい側面があった。 この本は、フロントエンドエンジニアが今まで経験的に蓄積してきたでろう「勘」を、Webの仕様や各社のUXガイドラインの明確な定義を通して再整理したも

dev.toの何がすごいのか、とPWA、CDNの紹介

11/15に開催されたこちらの勉強会に参加いたしました！ デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう - connpass こちらの勉強会は、「WordPress本体とプラグインの脆弱性をデバッガで追跡することにより、脆弱性の中身について詳しく追跡し、理解を深める」という内容のものであり、なんとあの徳丸浩さんが講師をされています！ 私個人としては、仕事というか半分趣味でゆるゆる脆弱性の検証をしており、今回の勉強会はまさに自分の興味分野にドンピシャな内容だったので、非常に楽しんで参加させていただきましたｗ 私はこちらの勉強会にブログ枠として参加いたしましたので、勉強会の内容について本ブログにてレポートいたします。 分析対象の脆弱性について 今回分析する題材となった脆弱性は以下の二つです。 なお、二つの脆弱性とも徳丸さんが詳細な解説記事をブログにて公開されております

90年代後半から2000年代にウェブ制作を経験した者なら『とほほのWWW入門』と聞いて、ピンと来ない人はいないだろう。同サイトは、HTMLやJavaScript、Ruby、Pythonなどの基礎知識が学べる、ウェブ制作初心者にとってはバイブルのような、とてもありがたい存在だ。サイトが開設されたのは1996年。国内でインターネットが普及し始めた初期からある老舗サイトで、お世話になった人も多いはずだ。 2016年10月を最後に更新がされていないようだが、それでも20年間コンテンツを出し続けるのは、かなり大変なことだったのではないか。同サイトの管理人・杜甫々（とほほ）さんは、いったいどのような人物なのか。サイトを開設したきっかけやインターネット初期の空気感などについて、話を聞いた。 「とほほのWWW入門」管理人・杜甫々さんとは？ ――今回は取材に応じていただき、ありがとうございます。杜甫々さんは