「僕をフォローすれば、お金をあげるよ」と言えば、フォロワーはドバっと増える。 「メディアは第４の権力」と言われるように、フォロワー数は一種の権力だが、金で権力が買えちゃうわけだ。 ただし、自分をフォローした人なら誰にでもお金をあげてしまうと、十分に強い権力にはならない。 「自分の気に入らない人間には、お金をあげないようにすること」が、キモだ。 そうすれば、自分にとって都合の悪いことを言う人間の口を封じることができるからだ。 だから、決して「抽選で」お金を配ってはいけない。 中国共産党が、自分たちの権力を維持するために、共産党にとって都合の悪いことを言う人間の口を封じることに熱心であることからわかるように、自分にとって都合の悪いことを言う人間の口を封じることは、権力維持にとって、非常に重要なことなのである。 お金をばらまけるほどの金持ちの多くは、すでにリアルで権力を握っているはずである。 な

背景 windowsとmacを平行して使っているとショートカットキーがごっちゃになるので整理してみた。 windowsのショートカットキーとmacでのいい感じの比較サイトがあれば教えて頂きたい。 個人的に作成したショートカット集とかもいいまとめがあれば教えてください。 特殊キー 本記事では取り扱っていないが意外とショートカット系の記事を見ると書かれている特殊キーたち ⌘ … command ⇧ … shift ⌥ … option ⌃ … control ⇪ … caps lock ウインドウ/アプリ コマンド 概要

TikTokは良い動画が一瞬でバズりやすい。それは例え、あなたの最初に投稿した動画だったとしても。これはYouTubeと対極的である。YouTubeでは無名の人がどんなに面白い動画を投稿しても、そもそも誰にも見てもらえない。YouTubeで毎日毎日面白い動画を投稿し、たまたま見てくれた人が読者登録してくれたりして、数ヶ月、半年と努力を継続しなければならない。 一言で表せば、YouTubeは「信用経済」「評価経済」時代のプラットフォームなのである。 たくさんの登録者数を持つYouTuberが強い。少ない登録者数しか持たないYouTuberは弱い。弱いYouTuberは、たくさん登録者数をゲットするまで、修行する。そういう世界だ。 一旦インフルエンサー級まで自分の信用や評価を蓄積することができれば、後は自由自在に動きやすい。他のYouTuberともコラボしやすいし、企業案件もどんどん舞い込んで

この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

安東弘樹/Hiroki Ando 1967年横浜市生まれ。成城大学法学部卒業。1991年、アナウンサー27期生としてTBSに入社。これまでに「王様のブランチ」「アッコにおまかせ」「はままるマーケット」などテレビ番組のほか、ラジオでも活躍。現在は「ひるおび！」（TV）、「辛島美登里　こころん、ふるさと（ナレーション）」（RADIO）を担当。大のクルマ好きで、これまでに39台ものクルマを乗り継いだ。奥様がイラストを描いた共著『安東さんちの子育てちからこぶ』では二人の男の子の子育てを綴っている。 「クルマの総AT（CVT）化が日本人をクルマ嫌い、クルマの素人にしてしまったんではないかと思うんですよ」 しょっぱなから、彼は熱かった。TBSの看板アナウンサー安東弘樹さんは、世間にはあまり知られていないが実はクルマ好き、いや重度のクルママニアである。最近ではトヨタが運営するWEBサイト「GAZOO」で

刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの

本当にLambda Layersで幸せになれるのか？ 旧式のデプロイ方式からLambda Layersを活用したデプロイ方式への移行を検討する はじめに サーバーレス開発部＠大阪の岩田です。 re:Invent2018でLambda関連の新機能としてLambda Layersが発表されました。 【速報】【アップデート】Lambdaが複数のファンクションで共有するコードを持てるようになりました(Lambda Layer) #reinvent この機能を使うことで複数のLambda Functionから共通利用するロジックやライブラリをLambda Function毎にデプロイする必要が無くなり、共通ロジックの管理が簡素化されるという待望の機能です！！ ・・・本当にそうなんでしょうか？？ マネジメントコンソールから直接コードを編集するようなレベルの小規模なLambda Functionであれば

これは、SREアドベントカレンダー23日目の記事です。 はじめに 昨年、暗号資産（仮想通貨とは呼ばないそうです）は投機性から非常に盛り上がりました。 対日本円への価値の下降や様々な事件から暗号資産自体の注目は下がりましたが、 ブロックチェーン技術自体の改善やブロックチェーンの投機以外での利用は依然とし盛り上がっています。 ブロックチェーンを使ったサービスなどは、Web3と呼ばれたり、限られた巨人たちからインターネットを取り戻そうという流れの後押しもあり注目が集まっています。 多くのブロックチェーンでは、、分散システムで改ざん困難であり、非中央集権であることが利点であり、未来のインターネットと感じて投資をしている人がいます。 私は現在、double jump.tokyoという会社で「My Crypto Heroes」というEthereumを利用したブロックチェーンゲームの開発をしています。

インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い

あーーー 2018年中に終わって良かったーーー Daily UIという、メールアドレスを登録すると毎日お題が送られてきてそのUIをデザインするというチャレンジ企画があるのですが、去年の今頃はこれを途中で辞めてしまっていたのでした。 私の投稿をみてDaily UIを始めた人が立派に完遂するというのに何というふがいなさ...。これはよくないな、ということで再開したのが今年の9月頃。再びできなかった日を挟みつつも、旅行の合間などにもやり遂げてついに今月100個分のお題を終えたのでした。 ↑100個すべてのデザインをTwitterモーメントにまとめました いくつか思い出深いものと共に振り返ります。 🏳 なぜDaily UIを始めたのか？始めたのは、去年の今頃。サンフランシスコのプロダクトデザイナー養成所Tradecraftに通っていた時でした。カリキュラムでは、既に知っていることも多かったので、

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

「もっと給料を上げたい！」――。いま転職を考えているエンジニアが習得しておきたいプログラミング言語は？　人材サービスなどを提供するリブセンスが2018年のプログラミング言語別の市場動向を発表した。 同社が運営するITエンジニア限定の競争入札型転職サイト「転職ドラフト」で18年に行われた指名（スカウト）6536件を対象に、現場で使われているプログラミング言語の経験者人数、スカウトに対する提示年収についての平均値を集計した。 それによると、最もスカウトが多かったプログラム言語は動的なWebサイト構築などに使われるJavaScriptで510件。以下、Java（411件）、PHP（384件）、Ruby（294件）、Node.js（238件）、Python（230件）と続いた。 プログラミング言語ごとのエンジニアのスカウト金額に関しては、1位がScalaで678万円、2位がGoで667万円、Per

あんど( @ampersand_xyz )と申します。 クイズメーカーなど、色々なサービスを個人でリリースしているフリーのエンジニアです。 個人開発を支える技術のアドベントカレンダーではサービスを構築するArchitectureに関する技術の話題が多いなか、周りの方やマシュマロからの匿名メッセージ質問でUIのことに関する質問などが多かったので、本投稿ではUIやデザイン周りに関するTechnic…と言えるほど上等なものではないのですが、そのあたりの技術をお話したいと思います。 なお、自分は正直かなり我流で適当にやっているので、もっといい方法のツッコミなど歓迎しております。 1.画面サイズの最大・最小幅を最初に決めておく まずはじめにここを決めます。 いかにリキッドデザインやレスポンシブで画面を作成するといえども、極端に幅が小さい、または大きいデバイスを相手にする場合、どうしてもサイズ整合性を

TL;DR SlackのAPIから2018年の発言データを取得、可視化をしました 一番発言されたChannelや使われたリアクション 💪 、Channel数の増加などを調べました Doc2Vec、t-SNEを使って類似Channelの探索をしました 使ったコードは記事の最後にあります はじめに アプリケーションエンジニアの池田@つくば (@ikedaosushi Follow me! )です。 2018年もいよいよ終わりですね。皆さんにとってどんな年だったでしょうか。僕は人生初の転職とリモートワークワークを経験し、かなり刺激的な一年になりました。 年の瀬ということで、SlackデータをPythonを使って可視化することによってKaizen Platformにとって2018年がどんな1年だったか振り返ってみたいと思います。ちなみに以前、弊社ではQiita:Teamの解析を行っていたので今回

CDとかDL版で買うこともあるけど、買ったところで結局youtubeでしか聞かない PCやタブレットなどが複数あると今使ってるのに音楽データが有る必要がある 曲数が多いと全部に同じのを入れておくのは面倒すぎるし、ストレージの無駄 普段聞く曲だけに絞り込むと、ふと聞きたいと思った曲が手元になくて聴けないことがある オンラインストレージという手はあるが、ログインが必要な上に、無料だとそこまで大きな容量じゃないので手持ちの曲を全部アップロードは難しい そう考えるとほぼなんでもあってローカルのストレージを使わず検索もしやすくログイン不要なyoutubeが一番なわけだ ただマイナーゲームのBGMとか、youtubeといえども存在しない音楽はあるわけでそういうのに限定して、オンラインストレージとか使うのがベストだと思う

これまでの経緯 アイデアソン このイベント(わたし達の未来をつくる「アイデアソン・ハッカソン」～世の中を変える商品開発【視覚障害を持つ方編】～)は、障害のある当事者の方々が自らの直面する課題をエンジニアに共有し、その解決を図るプロダクトやサービスを実際に開発するイベントです。 今年の8月18日にアイディア出しのイベントがありました。 わたし達の未来をつくる「アイデアソン・ハッカソン」～世の中を変える商品開発【視覚障害を持つ方編】～に参加しました 私たちのグループでは、京都福祉情報ネットワーク 園様のお話を伺いました。その中で、普段の生活で困っておられることの一つとして「必要だと思った時にサッとメモが取れないこと」を挙げておられました。 普段、健常者なら気にしないポイントですが、視覚に障害があるとメモができないということは新たな気づきでした。 では、視覚に障害があっても、サッとメモできるソリ

このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで