電通「2019年 日本の広告費」 インターネット広告費が初の2兆円超えでテレビを逆転
電通は2020年3月11日、わが国の総広告費および媒体別、業種別の広告費を推定した「2019年 日本の広告費」を発表しました。これによると2019年（1～12月）の日本の総広告費は6兆9381億円になりました。 なお、今回の数字には「物販系ECプラットフォーム広告費」と「イベント」領域が追加されており、前年同様の推定方法では6兆6514億円。それでも前年比101.9％となり、8年連続で前年実績を上回る結果となっています。 【訂正】：2020年3月11日午後8時50分 初出時に冒頭の日付が間違っていたため、修正しました。 媒体別広告費では「マスコミ四媒体広告費」（衛星メディア関連を含む）は2兆6094億円で前年比96.6％。これで5年連続の減少となりました。媒体別でもテレビメディアと新聞、雑誌、ラジオの全てが前年割れとなっています。 テレビメディア広告費は1兆8612億円（前年比97.3％）
至高のDockerイメージ生成を求めて -2019年版- - Qiita
この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP
AutoMLで破産しないように気をつけたいポイント - ぱたへね
はじめに AutoMLを使っていたら一気に26万円の請求が来ました。 他の人が同じ事故にあわないようにやってしまったことを書きます。 2019/06/24、2019/06/26 追記書きました。15万円減額してもらえました。請求自体は正しく、トレーニングに関しては一回回すとこれだけの費用が発生します。 natsutan.hatenablog.com やったこと 前回、こんな記事を書きました。 AutoML Vision Edgeが作るニューラルネットワーク この続きで、物体検出のAutoMLを評価してみようと思いました。VOC2012のデータを用意してAutoMLへかけてみました。トレーニングの前に物体検出の方はtfliteへの変換が選べないことが分かったのですが、トレーニングさえ終わらせておけば何か方法がみつかるかもしれずと思い、精度優先と速度優先の2つのオプションでAutoMLを実行し
BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 by @yuzutas0
この記事はGoogle Cloud Platform その１ Advent Calendar 2018 - 18日目の記事です。 以前こういうブコメをしたのですが、言いっ放しだとダサいので、具体的なやり方を書きます。 "アカウントごと/日付ごとのBigQueryコストを可視化できるダッシュボード" なら Stackdriver + BQ + Datastudio を使うと作業時間10分・ほぼ無料で作れるので、うちはそのやり方を採用していますね。… https://t.co/9yoni22iw7— ゆずたそ (@yuzutas0) August 17, 2018 もくじ もくじ はじめに この記事のゴール 解決したい課題 課題の背景 実行方針 完成イメージ 作業手順 1: BQクエリ実行ログを流す 2: DataStudioでダッシュボードに表示する 応用編 1: 全体コストを可視化する 2
やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち - console.lealog();
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
BigQueryで有り金全部溶かさないように、テーブルの日付ごとのパーティション(partition)機能について調べてみた - 唯物是真 @Scaled_Wurm
BigQueryではクエリのたびに対象のテーブルをフルスキャンします スキャンしたテーブルのサイズによって料金が請求されるので、コストの削減のために日付などの単位でテーブルを分割するのがベストプラクティスとして知られています qiita.com テーブルを日付ごとに分割する利点 クエリのときのテーブルのサイズが小さくなるので、費用が下がる テーブルを最後に更新してから90日以上たつとストレージ代が安くなる テーブルが分かれているので、特定の日のデータだけ入れ直すのが簡単 expireを設定すれば一定期間で自動的に古い方から消えていくようにできる 以前このブログでも紹介しましたが、最近テーブルを日付ごとにパーティションする機能がサポートされました sucrose.hatenablog.com パーティション機能の挙動を知りたかったのでいろいろ調べてまとめてみました 以下に書いてあるmkやlo
娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ
この春、末っ子の娘が小学校を晴れて卒業します。 で、卒業式用の服を買うってんで昨日買いに行ったんですよ。 卒業式用の服？ ていうか「卒業式用の服」ってなんなん？という疑問を持ちつつ、カミさんと娘を乗せて車で某イトヨーカドーを軸とするショッピングセンターに向かいました（カミさんがいうには、専門店よりヨーカドーとかイオンとかのが安いから。ごもっとも）。 さて、卒業式用の服。ぼくのイメージはこんなんでした。 そうそう、こんなん。ていうか、中学校の制服でええんちゃうの？と思ってました。 予想外デス でも、甘かった。中学校の制服だなんて、そんな甘っちょろい世界ではありませんでした。 車を降り、目指す売り場でぼくが見た驚愕の光景がコチラ。 なんやねんこれ…。 AKBやん！地味なAKBやん！ 息子らの小学校の卒業式のときは女子はこんなん着てたかなぁ。ヨソの子なんて気にしてなかったわ…。 しかも… お値段
来年はCESに！ コマ数別、海外展示会に出展するのに掛かるコスト一覧 ＆ 金の掛けどころTips – キャズムを超えろ! Rev.2
世界最大の家電・IoTの展示会、CES。そこに出展するのはさぞかし高いんだろうということをものすごい色んな人にものすごい回数聞かれて、ものすごい回数『そんなにかからへんで』と返すのもだいぶ疲れてきたので、CESに出展するにあたってかかるコストをざーーーっとlist-upする。もちろんCES以外の展示会でもほとんど誤差範囲でしかコスト違わないので、NABやIBC、IFAやCeBITなんかにもそのまま応用（誤差20％以内）できるはず。あ、MWCだけは別。あれはボリすぎ高すぎ。 1コマで出す場合 2013年の初CESブース＠LVH（現Westgate） 標準ブースを使ったこと、ポスターが背面全面張りではなかったことなどから超目立たない目立たない。 色々と学習した回だった。 なお、手前の展示台は完全自作。当時はホムセンで木を買って組むスキルがなかったので日本から部材を持ち込むという超絶面倒なことを
自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話 - 僕のYak Shavingは終わらない
元後輩？から「どんな人を創業メンバーに選ぶべきですか？」質問をされたので、自分なりの回答をした。 正直今の会社の創業メンバーは、前職同期である社長の素晴らしすぎる人脈もあって、奇跡的な能力のゴールデンバランスと性格的相性の良さを兼ね備えた6人が手を上げ起業している。 なので、このこと自体は全然参考にならないよという前置きをおいたあとに、自分なりに思ったことを述べた。 コストを払わない人と一緒にやるとチームが自然解散する 起業前によくあったのは、エンジニア1人＋企画2人とかのパターン。 大抵が本職がある状態でのプライベートプロジェクトで、土日のどちらかで1, 2週に一回集まって企画を考えてプロダクトに落として行くということをやっていた。 で、よくあるのが企画中はみんなでかなり盛り上がって笑い合って、じゃあこれで行こう！絶対いける！みたいになるんだけど、はいじゃあ実装開始ってなるとエンジニアが
AWS Lambda を計算リソースとして使う - いもす研 (imos laboratory)
Amazon EC2 は 1 時間単位，Google Compute Engine も 10 分単位でしか借りられず，試行錯誤しながらプログラムを書いている時に計算リソースを使い切ることは困難です．そこで 100 ミリ秒単位で使える AWS Lambda を計算リソースとして使ってみました． AWS Lambda は表向きは Node.js あるいは Java が使えると書かれていますが，実際には最近流行りのコンテナ技術を使っており言語レベルでの制限はかけられておらず，exec 関数を呼び出すことにより（静的リンクされていれば）任意のバイナリを実行することができます．そこで C++ で書かれたプログラムを実行する方法について紹介します． Linux 上で x86-64 向けにコンパイル・静的リンクされたバイナリがあれば，それを AWS Lambda 上で実行することは簡単にできます．コンパ
BigQueryにTwitterのタイムラインを入れる [Ruby]
Twitter のタイムラインを保存しておくとなにかと便利なので、色々と保存形式を変えながら 4 年くらい記録し続けている。ツイートの保存が便利すぎるので、ツイセーブというサービス化までした。かつてはテキストで、MongoDB や MySQL とか Groonga とかいろいろやってきた。どれも問題ないんだけど、増え続けるログデータを保存する場所として考えると BigQuery が現代にマッチしてるようなのでそちらに移行した。 BigQuery に TL を保存するとできること TL の全てのデータをフルスキャンできる。これはかなり便利で、今回このブログ記事を書くにあたっても ‘BigQuery’ を TL から検索すれば、信頼できるフォローイングの人々の声を見ることができた。これにより「某 CA 社では 5000 台の MongoDB クラスタで BigQuery に対抗している」という
![BigQueryにTwitterのタイムラインを入れる [Ruby]](https://cdn-ak-scissors.b.st-hatena.com/image/square/eb99bf7e3074ef0fe5df0ca25a644e696c62ad78/height=288;version=1;width=512/https%3A%2F%2Fs3-ap-northeast-1.amazonaws.com%2Fkksg%2Fblog%2F53b4ac19c38aa5513f47ea75.png)
YAPC運営とビジネス : D-7 <altijd in beweging>
Daisuke Maki@lestrratお金以上に重要なものもあるけど、お金がなくては何もできない。誰かの利を産むことによりお金を集め、それを使って自分の野望の実現するのです。イベント運営や団体運営の究極的な目的はお金儲けではないにしろ、ひとつのビジネスを創造する事が必要なのです。 2013/09/26 12:33:49 究極的な目的がお金儲けではないので当然こういうイベントでは資金はそこまで潤沢ではありません。活動内容自体もあまりお金儲けに走ると本来喜んでもらうべき相手であるコミュニティの反感を買いますし、一部からは「お金をかけない手作り感がいい」と言われる方もいます。 まぁ言いたいことは わかります。崇高な目的を商業主義に汚されたくないというのは確かに感情としては理解できます。 しかし 自分はこれまでスタッフとして参加したり、主催者として色々やってきたりしてその辺りの「汚い」部分をち
くもりのち晴れ、ときどき、コストセンター - たごもりすメモ
直接成果が外に出ない僕らの仕事は大抵、最初は空模様が怪しい。いまいち見通しが悪くテンションも上がらない曇り空が続いたあと、努力が報われれば、ありがたくもそのうちに晴れ間が見えるようになる。たまにとんでもない快晴にめぐりあえることもある。 でも途中で目的地を見失ったり、脚が萎えてその場にくずれおちたりすると、天候はあっという間に変わる。動けないうちに嵐がやってくる。 その嵐には僕の中では、コストセンターというラベルが貼ってある。 http://www.picgifs.com/wallpapers/storm/wallpaper_storm_animaatjes-9-970507/ あまり好きな表現ではないが、コストセンターという言葉がある。この言葉の定義自体いろいろあるらしいというか、明確には定義があるようだというのはこのあたりを読むとふむふむという感じ。 だが、おそらく多くの人の頭には「コ
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアのための経営学
JavaScriptテストの疑問、お答えします #frontrendJS
データベース技術の羅針盤