「日々の活動をメモしろ」というのは、個人の生産性の文脈やライフログ等でよく言われます[要出典]。 実際に私も古くはA4用紙にメモっていったり、いろいろな手帳を試したり、howmやEvernote、Obsidianで色々やっていた過去がありましたが、最終的にはどれも三日坊主になり継続しませんでした。 というのも、メモをするより作業したほうが早いですし、いつも手を動かす方を優先してつい作業をしてしまいます。 特にOSS活動や趣味開発をしている時などは、仕事の後で時間がないので手を動かす方を優先したいとなりがちです。 実際、ここ1年ぐらいは毎週振り返りの予定をカレンダーに入れているのですが、2,3回ぐらいしか成功した記憶がありません。 入れているがほぼ実行されない予定 正直、「LLMなんとかしてくれーーーーー」と思います。 なのでLLMになんとかしてもらいました LLMによる自動ライフログ こん
読者諸兄はデパートに行ったらどこが気になるだろうか？デパ地下？ファッション売り場？ 増田は搬入口の場所だ。売り場で何売ってるかなんてどこから搬入するかに比べたらどうでもいいことだ。この文書を読んだら君もきっとそうなる。 売り場で物が売れたらそれを補充しなきゃならない。その搬入口は大抵ビルの裏にある。 しかしデパートがある場所というのは一等地だ。バックスペースである搬入口なんかの為に一等地を使うのは余りに勿体ない…。 という事で離れた場所に搬入口が設けられて秘密の通路で結ばれていることがあるのだ。 それを幾つか紹介するよ。 因みにこういう所は仕事でしか入れないもので、増田が仕事で行ったり同僚に聞いた入りした事がある個所に限られるから偏りはあるよ。 池袋LABIヤマダ電機が運営する池袋LABIは元は池袋三越だった。開業は昭和29年の地下鉄丸の内線の前年か同年と古い。 LABIの裏に都道があって
あるアカウントで運用しているドメインを別のアカウントに遷移したので、 未来の自分がまた同じ事をする際に思考を再現できるようにするまとめました。 前提条件 ドメイン(domain)をAWSのアカウントAのRoute 53で管理(domain.com) domainのサブドメインsubもアカウントAのRoute53で管理(sub.domain.com) subはEKS上でAWS Load Balancer Controllerとexternal-dnsを利用して設定している ALBを立ち上げてAレコードを登録するのが自動で行われる subsub.sub.domain.comなどを作る可能性もある subはACMで証明書を作成しており、DNSでの検証をしている subのEKSやRDSを可能な限りアカウントBに移動したい 理由がって残すのは(金額が高くないなら)OK この前提条件のもとで、sub.
「ユニコーン企業のひみつ」という本を読みました。 一見すると書かれていることはひみつという程ではなく、言われると知っているというものばかりですが、 Spotifyはそれを想像を超えるレベルで徹底していて、このやりきる事こそがひみつにあたるのではという感想を持ちました。 例えば本書では「スタートアップは学習する機械」「素早く失敗して学習をする」「ミッションを定義して方向性を示す」「チームに権限をもたせ信頼する」といった、 ある程度ベンチャーの風土に親しんでいれば知っているようなトピックが多数挙げられています。 そのため一見するとそこまで新しいことはなさそうに見えるのですが、実行される内容は生半可ではありませんでした。 例えば決定権をチームに持たせて自走させるといったようなことが語られますが、上位レイヤーは必要な情報を提供したりミッションを伝えるが決定はしないという役割に徹しており、チームに与
1月からIDOLY PRIDE -アイドリープライド-というアニメが始まりますが、 11月の単独イベントに行って凄い可能性を感じて、第1話をリアルタイムで観る人を増やしたいのでめっちゃ宣伝します。 IDOLY PRIDEって何？ サイバーエージェントとミュージックレイン、ストレートエッジが立ち上げた、メディアミックス作品です。 https://idolypride.jp/ プロジェクトのキャッチコピーやティザーサイトのメッセージからするとスポコンアイドルアニメっぽい感じをまとっていて、 伝説のアイドルとして存在する「長瀬麻奈」とそれをめぐる10人の後輩やライバルたちの話です。 (メインメンバーである１０人とプロジェクトのキャッチコピー。引用元) 1年ほど前に始まり、今日に至るまでにいくつかの楽曲と漫画が展開され、 1月からアニメ放送が始まるというフェーズです。 11月に初めての単独イベント
最近、「煽動者 ～徹底プロモーション 仕掛人の哲学～」という本を読みました。 これは今かなり勢いのあるアニメ・ゲームのメディア企業であるブシロードの代表取締役会長の自伝的な本です。 2013年1月出版なのでラブライブ！(同時期にアニメ開始)やBanG Dream!(2015年)がブレイクする前の話で、主にヴァイスシュヴァルツとヴァンガード、新日本プロレスについて書いています。 とはいえコンテンツ制作的な部分にはあまり触れておらず、社長の自伝とどういう戦略でやったのかとか、マーケティング手法とかがメインです。 この本で面白いのはヴァンガードの頃にやっていた広告戦略をBanG Dream!（以下バンドリ）の時や現在でも踏襲しており、かつなかなか他に同じようなことをしているコンテンツ会社がいない手法だなというところです。 その手法というのは大きく分けて以下の2つです。 徹底した再放送 常にリアル
9/12から始まるる技術書典9で「OpenAPI 3を完全に理解できる本 3.0.3対応版」を頒布します。 OpenAPI3に関するおそらく唯一の日本語完全解説本です。 この本ではOpenAPI 3の説明や、実際にどういう風に定義を書いていくかについての説明、および簡単な応用例などを載せています。 こちらは、「技術書典７でOpenAPI 3の完全解説本を出しました」で頒布したものをアップデートし、現在の最新である3.0.3に対応させたものです。 差分はそれほど大きくないため、既に持っている方向けには電子版を最新版に差し替えています。 再度DLしていただくと最新のものに差し替わります。 また、物理本を少量ですが用意しました。 他にも kubectl完全逆引きリファレンスと Microservices architecture よろず本 その三は物理本を若干数用意しています。 Microser
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
まとめ タスクランナーをどうするかは人類共通の課題 自分以外のコンテキストの違う人を考えると大変 フロント・スマホの人がサーバ触るとか 汎用的に使えるツールは表現力や変更が辛い make, シェルスクリプト, 自作バイナリ 表現力が高いツールは環境設定でハマりやすい node/ruby/pythonは手元に入ってない場合がある バージョン・依存関係問題で失敗したりする Dockerで開発環境を提供してもDockerの外の事柄には対応できない Dockerビルドしてデプロイとか cargo-makeがいい感じに使えそう バイナリ一個置くだけでインストールできる rustのツールであるcargoは不要 Makefile.tomlの表現力がそこそこ高い Pythonで拡張可能 npm-scriptsのより汎用的に使えるイメージ 欠点も少ない 表現力は豊か Dockerと組み合わせばだいたいなんと
技術書典 応援祭で頒布した「kubectl完全逆引きリファレンス」が加筆修正を加えて技術の泉シリーズから出ました。 主な内容は「技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します」の通りで、 kubectlの一通りのコマンドについて説明をしています。 さらに、前回の頒布後にリリースされた最新のkubectl 1.18に対応しており、deprecatedや削除されたコマンドに対応しているため、よりおすすめの一冊になっています。 (同人誌版は1.17対応) 目次やサンプル 【目次】 第1章 はじめに 第2章 kubectlの基本 第3章 リソースを操作する 第4章 定義ファイルに関するコマンド 第5章 Podやコンテナを操作する 第6章 複数のPodを作るリソースに対するコマンド 第7章 ロールアウトに関するコマンド（rollout） 第8章 スケールイン・スケールアウトに関す
2020年7月29日-30日開催のCloud Operator Days Tokyo 2020の講演資料です。 PFNの太田と佐藤が、Kubernetesによるインフラ構築やCI/CDについて説明します。
こんにちは、タイミーデリバリー開発チームの宮城です。 今回は弊社のOpenAPI3ベースのスキーマ駆動開発の運用方法を紹介します。 TL;DR 技術スタックは OpenAPI3, Swagger UI, Committee, ActiveModelSerializers Committeeを利用してOpenAPI準拠のRequest Specを行う OpenAPI3のrequiredキーワードに注意する 背景 タイミーデリバリーでは、RailsによるAPIサーバーと、Web管理画面としてVue.jsによるSPA、ユーザー向けiOSアプリとしてSwiftを採用しています。 1つのモノリスなRailsで利用者別にネームスペースを区切り、それぞれエンドポイントを提供しています。 サーバーサイドとクライアントサイドを分離し並行して開発を進めるためにスキーマ駆動開発を導入しました。スキーマ駆動開発の
FiNCではマイクロサービスを6年前から採用しており、順調にサービスも成長したおかげで、現在では稼働しているマイクロサービス数は50を超えるほどになりました。 マイクロサービスの採用により、限られた範囲での開発においては速度を落とさずスケールすることが可能という恩恵を得られましたが、一方でサービス数の増加は安定性、メンテナンス性をはじめとした様々な問題も生みました。その1つにアーキテクチャ全容の理解が困難になるという問題があります。例えば「ユーザが食事を投稿した際に食事アドバイスのプッシュ通知を送る」という機能1つをとっても、アドバイス管理サービスが食事投稿のイベントを検知するためにイベントを購読し、同サービスがアカウント管理サービスやユーザのライフログデータを管理するサービスなどからユーザデータを集め、そして非同期のジョブキューに通知サービスのAPIを利用するジョブを積みワーカーが実行す
こんにちは、ECプラットフォーム部の権守です。普段はZOZOTOWNのリプレイスに関わるID基盤とAPI Gatewayの開発を行っています。 ID基盤やAPI Gatewayの中身についてもいずれ紹介したいと思いますが、本記事では、ID基盤のAPI開発で取り入れているGo言語におけるOpenAPIを使ったレスポンス検証について紹介します。 OpenAPIを使ったレスポンス検証 OpenAPI Specification（以下、OpenAPIと表記します）はREST APIのためのプログラミング言語に依存しない標準的なインタフェース記述言語です。OpenAPIについては以前にこちらの記事でも取り上げましたので、合わせて読んでいただければと思います。 弊社では、新規で開発するAPIについてはOpenAPIを用いて仕様書を作成しており、ID基盤もそうして社内にAPI仕様書を提供しています。 O
まとめ 秘密情報をEKS上で楽に管理したい。 これまでは秘密情報を暗号化したファイルを使って注入してた 変数ごとに何が変更されたかを確認するのが面倒 AWS KMSで暗号化してたのでAWS CLIのインストールのためにPythonを入れるのが微妙 KubernetesのSecretをそのまま使うのは避けたい Base64してるだけで暗号化してない k8sの権限の強い人からは見えてしまう 環境変数の値だけを暗号化してPod内で複合 リポジトリに読める形でコミットできる 追加・変更されたか否かのレベルでなら確認できる Pod以外は複合できないためマルチテナントなk8sだと権限管理が楽 shushならバイナリ一個入れるだけですむ GKEに移っても実装できそうな規模なのでなんとかなりそう。 欠点もある バイナリを一個置く必要がある entrypoint/commandの変更が必須 起動時に暗号化し
GitHub、チームでの利用も無料に。プライベートリポジトリ数も制限なく、チームディスカッション、ActionsによるCI/CDも可能 GitHubは無料で利用できる「Free」プランを見直し、個人に加えてチームでも無料で利用できる新たなFreeプランを発表しました。 Today we’re announcing free private repositories with unlimited collaborators for teams with GitHub Free, and reducing the price of our paid Team plan to $4 per user/month. All of the core GitHub features are now free for everyone. Learn more: https://t.co/fQ3r2ABt
3/7から始まっている技術書典 応援祭で「kubectl完全逆引きリファレンス」を頒布していました。 技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します 4/5で終了したので、新刊の販売冊数と集計結果をまとめてみました。 なお、紙＋電子はとらのあなでも販売しています。 https://ec.toranoana.jp/tora_r/ec/item/040030816901/ 電子版のみはBOOTHでも販売中です。 https://ota42y.booth.pm/items/1854936 まとめ 定期的にポツポツ売れている 送料がかかっても電子＋紙のほうを求める傾向がありそう 技術書典公式の物理本特集も効果が出てそう 最後の追い込みがある 実際の即売会だと無いのでネット特有の減少 集計方法 前回の「#技術書典 応援祭の集計スクリプトと中間集計」と同じスクリプトを使って集計しま
3/7から始まっている技術書典 応援祭で「kubectl完全逆引きリファレンス」を頒布しています。 技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します 3/21で開催からちょうど二週間たったので、新刊の販売冊数と集計結果をまとめてみました。 まとめ 定期的にポツポツ売れている 送料がかかっても電子＋紙のほうを求める傾向がありそう 技術書典公式の物理本特集も効果が出てそう ただしデータが少ない(26件) 集計方法 以下のスクリプトを使いました。 サークルの販売履歴ページに移動 3/7以前のデータが出るまで「もっと読む」を押す デベロッパーコンソールから以下のスクリプトを実行 出力されたcsvを集計する 日付、種類、本の名前、価格 の４データになります 集計結果 売上がなかった日もあるため棒がないのは正常です。 考察 電子版は初日にピークを迎え、後はゆっくりと買われています。
3/7のから始まる技術書典 応援祭で 「kubectl完全逆引きリファレンス」を頒布します。 https://techbookfest.org/product/5767351924424704 kubectlの様々なコマンドを、実際にやりたいことから逆引きが出来る本です。 Kubernetesを始める際、運用していく際に手元に置いておく事で安心の一冊になっています1。 Podの操作はもちろんのこと、スケールアップ・ダウンしたいときやクラスターの外部に公開する場合、Nodeを停止したい場合など様々な利用シーンから、対応するkubectlコマンドの逆引きができるようになりました。 形式は紙＋電子で、とらのあなでも販売しています。 https://ec.toranoana.jp/tora_r/ec/item/040030816901/ 電子版のみはBOOTHでも販売中です。 https://ot
機械学習について業務で培った知見や経験、苦労を共有する「Machine Learning Production Pitch」が2019年12月10日、「Machine Learning Night」を開催しました。同イベントでは機械学習を実際の製品やサービスとして提供している、メルペイ、エムスリー、Preferred Networksの3社が登壇し、具体的な取り組みについて語りました。パネルディスカッションに登壇したのは、Preferred Networks谷脇大輔氏、エムスリー西場正浩氏、メルペイ竹原一彰氏。モデレーターはSansanのCTO藤倉成太氏が務めます。 メルペイ、エムスリー、Preferred Networksの3社が登壇 藤倉成太氏（以下、藤倉）：藤倉：では、さっそく始めていきたいと思うのですが、パネルディスカッション、全体で時間としては30分程度を予定しています。 谷脇大
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く