かっこいいSSH鍵が欲しい - アリ
例えばこのSSH公開鍵、末尾に私の名前(akiym)が入っています。 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFC90x6FIu8iKzJzvGOYOn2WIrCPTbUYOE+eGi/akiym そんなかっこいいssh鍵が欲しいと思いませんか？ ed25519のSSH公開鍵の構造 SSH鍵の形式にはRSAやDSA、ed25519などがありますが、最近のssh-keygenではデフォルトでed25519の鍵を生成するということもあり、ed25519を利用していることを前提として進めます。なにより、RSAの公開鍵に比べると短いので末尾部分が目立つはずです。 そもそも、ed25519のSSH公開鍵のフォーマットはどのようなものになっているか確認してみます。まずはssh-keygenコマンドで秘密鍵と公開鍵を生成します。 % ssh-keygen -t ed25
「シェア乗り時刻表」について - NearMe Tech Blog
はじめに 先日、空港送迎のシェア乗りサービスの空席を埋めるための時刻表機能をリリースしました。 構想は昔からあったのですが、ようやく開発を進めて世に出すことができました。 ここではその機能概要やシステムについて説明します。 時刻表について NearMeではユーザー同士がタクシー/シャトルの車両をシェアして乗車するサービスを構築してきました（※同じシェアですが、昨今、ドライバー不足で議論されている"ライドシェア"は一般ドライバーと乗客のマッチングによるもので、それとは異なります）。 特に、空港送迎のような事前に予約するシナリオにおいて運行効率を高める機能を作ってきました。 ユーザー同士のマッチングを最適化したり(参考、参考)、 車両と運行のマッチングも最適化して密な運行セットを作ったりしました(参考)。 また、既にある運行の空席を埋める施策として、時間をずらしたら乗れるというレコメンド機能も
Web開発者たる自分が「プロダクトマネージャーのしごと」を読んでみて - No Purpose
www.oreilly.co.jp 読み終えた瞬間の熱い気持ちのまま感想文書こうって思ってたのになかなか書けないままだいぶ時間がかかってしまった😇 この本を手に取ったモチベーション 僕はプロダクトマネージャーではないが、良きプロダクトマネージャーの仕事については興味を持っていた。 以下のような理由による。 PdM不在のプロダクトプラットフォーム開発の立場から 業務ではプロダクトプラットフォームチームに在籍している。"Platform as Product"*1の考え方で業務に臨む一方で、PdMという専門職がチームに置かれているわけではないので、開発チームがプロダクトマネジメントを主に行っている。どのようなプロダクトプラットフォームを目指すべきかという検討にあたって、もう少しプロダクトマネジメント的な方法論を学んだ方がいいだろうか、ということを考えていた。 (各社が、プロダクトプラットフォ
続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ
先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。 この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。 DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。 前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告以後の経緯と講じた対策を記したいと思います。 また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けていると
大きなプロジェクトがコケるときには『受け身』をとりましょう - LIVESENSE ENGINEER BLOG
これは SRE アドベントカレンダー 2023 15日目とLivesense Advent Calendar 2023 番外編の記事です。 システム移行などの大きいプロジェクトでは、スコープも大きく、かかる時間も長いです。結果、つきまとう不確実性も大きくなり、残念ながらプロジェクトを途中で中止することになってしまうことも多いです。 完成形を目指して最短距離で進んでいたプロジェクトが途中で止まり、残骸をそのままにしてしまうとシステムに残す傷跡が大きくなります。 プロジェクトを中止したり方向転換する決定をしたあとの、限られたリソースの中でシステムに残すダメージを可能な限り抑えましょうというのが今回の話の要旨です。 今回の記事では、どのような『受け身』を取ればシステムに残すダメージを抑えられるかを考えていきます。 とあるシステム移行プロジェクトでの受け身 ここでは、ある途中で止まってしまったシス
B/43のサーバーサイド開発の醍醐味と伸びしろ - inSmartBank
こんにちは！サーバーサイドエンジニアの mitani です。 2023年に技術広報を始めたことで、少しずつB/43を知ってくださっている人が増えてきました。辰年の今年は、サービス名だけでなくB/43の機能やその実装の背景など、B/43を開発する楽しさや醍醐味をどんどん発信して、もっともっとB/43のエンジニアリングを好きになってもらえる人を増やしていこうと思います！ ということで、このブログではB/43のサーバーサイドエンジニアが最近開発していることを紹介しながら、Fintechサービスを開発する醍醐味と今後取り組んでいきたい伸びしろについてお伝えします！ できるだけ赤裸々に今の状況を “Be Open” していきたいと思うので最後までお読みください！ 最近のB/43の開発事情 B/43はVisaプリペイドカードと家計簿アプリを組み合わせたサービスなので、決済システムと支出管理システムにざ
たった1行のPRでチームの"速さ"を可視化できる計測基盤を作った話 - Classi開発者ブログ
こんにちは、データプラットフォームチームの鳥山(@to_lz1)です。エンジニアの皆さん、自分のチームのパフォーマンス、計測していますか？ DevOps Research and Assessment（DORA）の2019年のレポート により、開発チームのパフォーマンスを示す指標として提唱された「Four Keys」。この中に「デプロイ頻度」「変更のリードタイム」という指標があります。 『LeanとDevOpsの科学』など有名な書籍で取り上げられたこともありFour Keysそのものが広く知られるようになりましたが*1、この度Classiでもこれらの指標を可視化するダッシュボードを構築し、社内提供を始めました。 計測の事例がインターネット上に多くある中でも、 横展開を極力容易にするための設計 リリースをしてみてから「実際に役に立てる」までの工夫とフォローアップ といった辺りに独自性があるか
ソフトウェアエンジニアのライブラリアップデートの向き合い方 - Uzabase for Engineers
こんにちは。ソーシャル経済メディア「NewsPicks」NewsPicks Stage.事業のエンジニアをしています、林です。 業務では Next.js / Rust / Go などを用いて、経済・ビジネス情報に特化した動画配信サービスであるNewsPicks Stage.の開発・運用を行っています。 はじめに 突然ですが、皆さんは自身のソフトウェアのライブラリアップデートは行えていますか？ 皆さんはどのようにライブラリアップデートを行なっていますか？ 新機能を試したくて？ npm iで失敗してから頑張る？ Renovate / dependabot が自動Mergeされる環境？ もしくは対応担当が特定の日にまとめてMergeする運用？ しかし多くの開発者は、アップデートに対して「うまくいっている」と言えないのではないでしょうか？自身も様々なプロダクトを開発してきた経験上、日々の中ではどう
フィヨルドブートキャンプの最終課題で作ったアプリを閉じた - らいむぎばたけ
lime1024.hateblo.jp フィヨルドブートキャンプの最終課題で、メディレコという医療費控除の申請書類をかんたんに作れるアプリを作った。リリース時から昨年までずっと確定申告の時に利用していた。わたしの両親も使ってくれていた。 デジタル庁のおかげでマイナポータル連携によって、医療費通知情報が連携されるようになり、保険診療分の医療費 (治療費・医薬品費) については自分で記録をとる必要が無くなった。 去年の時点でもうそうなっていた気がする*1けれど当時は使わず、自分で作ったアプリを利用して医療費をまとめていたが、いよいよ今年は使ってみたらめっっっっっっちゃくちゃ楽だった。 自費で支払った治療・ドラッグストアで購入した薬・治療のための交通費については手入力で追記した。これについてはそんなに数が無いので手間では無かった。 そして、メディレコの恩恵なしに今年は無事、医療費控除を含む確定申
GoでMySQLを使ったテストを書くときにつかうユーティリティーライブラリを作った
GoでMySQLを使ったテストを書く場合、MySQLのデータベースを初期化する処理や、使い終わったデータベースを削除する処理が必要になります。 毎回似たような処理を書いているので、そろそろライブラリとして切り出せそうだなと思って書いてみました。 shogo82148/go-mysql-pool 背景 弊社ではデータベースに関連したテストを書く場合、ローカルでMySQLを起動し、実際にMySQLへ接続する手法を取っています。 SQLの文法エラーを検知するには、実際にMySQLで処理するのが手っ取り早いからです。 この方法を採用する場合、次の問題は「いつMySQLのデータベースを初期化するか」です。 Goでは TestMain 関数を用意することで、テストの開始前の処理、テストの終了後の処理を書けます。 初期化しているコードは CREATE DATABASE するだけの単純なものです。 そんな
MySQL でテスト用データベースを高速に空にする (information_schema.tables の table_rows の話)
全テーブルを TRUNCATE して、必要なデータを流し込んでテストを実行するみたいなのがひたすら繰り返されるコードがあって、とにかく遅くてつらかったので高速化できないか考えてみました。 全テーブル TRUNCATE というのは、要するに一度データベースをまっさらな状態に持って行きたいという話なのですが、巨大なプログラムの1つ1つのテストは一部のテーブルしか使わないことがほとんどであるため、TRUNCATE せずともまっさらな状態のままテストを終えるテーブルは多いわけです。そこで、まずテーブルごとに TRUNCATE が必要かどうか判定して、TRUNCATE が必要と判断したテーブルに対してのみ TRUNCATE を発行するコードを考えてみました。 MySQL だと information_schema.tables に独自に便利な情報が格納されているので、これを使うのが手っ取り早いです。
「1円でもずれてはいけない」フィンテックだからこそ細部へのこだわりを突きつめられる──サーバーサイドエンジニアmitani【SmartBank Members#13】 - inSmartBank
「人々が本当に欲しかったものをつくる」── そんな想いで集まっているスマートバンクのメンバーたちを掘り下げる企画【SmartBank Members】。今回は、本企画の13人目として、サーバサイドエンジニアのmitani（三谷昌平）さんに話を聞きました。 スマートバンクの4人目社員として創業期から活躍し、YAPC::Hiroshima2024ではベストトーク賞を受賞したmitaniさんに、B/43の入金周りの開発から、5年間で変わってきたスマートバンクのカルチャー、そして今後の展望まで語っていただきました。 プロフィール 三谷昌平｜@shohei_mitani サーバーサイドエンジニア 新卒で、IoTのSaaSを開発するSIerに新卒で入社後、Fablic → 楽天に転職し、フリマアプリ「フリル」（現 : ラクマ）の開発を担当。その時のファウンダーとの繋がりから、2020年にSmart
GitHub ActionsでファイルをS3にキャッシュするアクションを作りました - プログラムモグモグ
GitHub Actionsでは依存パッケージやビルド結果などをうまくキャッシュすることで、テストやビルドの時間を短縮できます。 actions/setup-nodeやactions/setup-javaなどの各言語のオフィシャルアクションは各パッケージマネージャーのためのキャッシュ機構を提供していますし、actions/cacheを使って任意のファイルをキャッシュすることもできます。 これらは内部で@actions/cacheパッケージを使っており、キャッシュの機構はGitHub自身の機能と密に結びついています。 しかし、GitHub Actionsのキャッシュはリポジトリごとに10GBまでという制限があり、開発者の多いリポジトリではsetup-nodeのキャッシュだけでもすぐに上限に達してしまいます。 私の所属するチームのリポジトリはGitHub Enterprise Serverにホ
jsx, tsx のシンタックスハイライトにも対応しました。また、JavaScriptのハイライトを改善しました - はてなブログ開発ブログ
はてなブログでは、ソースコードなどを構文（シンタックス）に応じて色付け（ハイライト）表示する シンタックスハイライトに対応しています。今回、シンタックスハイライトに関する改善を行いました。 jsx, tsx形式のシンタックスハイライトの追加 JavaScript形式のシンタックスハイライトの改善 jsx, tsx形式のシンタックスハイライトの追加 jsx 及び tsx 形式に新たに対応しました。 はてな記法、Markdownでのハイライト方法は以下のとおりです。 はてな記法 >|jsx| ...ソースコードを記述する... ||< Markdown ```jsx ...ソースコードを記述する... ```詳しい利用方法やその他の形式の対応につきましては、下記のヘルプをご参照ください。 JavaScript形式のシンタックスハイライトの改善 JavaScriptのシンタックスハイライトの改善
なぜゲームプランナーは、ディレクターになるのが難しいのか？隠されたクラスチェンジ条件とは｜かえるD
最近、新米のディレクターにディレクションを０から説明している。noteではいろいろディレクターについて書いてみたが、ディレクターの持つジレンマは、ある程度成長したタイミングで出てくる問題で、初期に感じるものではないため、説明としては不十分だと感じた。なので、今回はもう少しディレクター初心者、または将来ディレクターになりたい人向けに全体像を把握できるよう書いてみる。 今回の記事は、結果として５回ほど書き直すことになった。理由は、全体像が何度書いても見えなかったためだ。最終的には、このnoteの最初の記事であり、テーマでもある「なぜゲームづくりをまるごと理解できる人が増えないのか？」にたどり着いてしまった。そして、自分の盲点が見つかり、ようやく解法がみえたのである。そして回答は２番めの記事に書いてあった。 結論を最初に書いておこう。 ・プランナーからキャリアを始めた人は、その次にディレクターに
ゲーム作りで「第１世代目はなぜ一線級を保ちつづけるのか？」と、そのなり方、落とし穴
モノづくりの２つの世代の違い私は、モノづくりの中では２種類のタイプがいて、それは大きく違う性質を持っていると考える。２つの人は初期値としての才能や能力は大きく違わない。だが、５年１０年と進んでいくにつれて差がとても大きくなっていく。 第１世代：一人で全部やるため全てのスキルを身に着けることができ、全体感を獲得できる 第２世代：第一世代が敷いた分業化のレールの上に乗るため、高い専門性を獲得することができる 違いはこれだけである。ただ結果として、チームリーダーやコアメンバーは第１世代に任され、第１世代のビジネス経験がより強化される。第２世代は、専門性を磨いていけばいつかは自分も第１世代みたいになれる筈と思いながら、いつまで立っても何故かなれない。いつしかあの人は特別だ、または、自分には才能がなかったと勘違いをしてしまう。 第１世代の最初は、すべてが足りないし、わからない中で行うため、足りないも
技術選定氏「俺がすべての責任を引き受ける」｜laiso
exitしたスタートアップの起業家のインタビューを読んでいたら「マイナーなフレームワークを選んでしまったのでエンジニア採用に苦労して後悔した」というようなことが書かれていて、当事者にもステークホルダーにもなりえる私はそうやね〜と共感していたんだけど実態を確認したらFlutterを使っていてFlutterか〜いと思った てっきりNativeScriptみたいな変なやつ(失礼)を掴んだのかと思って読んでいた それでもFlutterを選んだことが反省点としてあげらえるのも分かって、構造上の問題なので分析の結果として上げやすいというのがある あとは試行を繰替えしているうちに隣の芝が青く見えるという効果もあるとか(ネイティブ・Webならいけるんですけどね〜と何回か言われた、とか) そう考えると物言わぬ技術選定結果であるアーキテクチャの視点に立つと(ここでは人格を持っているものとする)すべての責任を背
“LLM for SRE“の世界探索 - ゆううきブログ
ChatGPTが登場した当初、対話や要約、翻訳、コード生成などの典型的な言語タスクができても、SREやAIOpsの研究開発にはあまり関係ないのではないかと正直思っていた。AIOpsでは典型的にはいわゆるObservabilityデータ（メトリクス、ログ、トレースなど）が入力となるため、自然言語ではなく数値のデータを解析することが求められる。自然言語のタスクを研究対象としていなかったため、AIOpsとChatGPTに強い関係性は見いだせなかった*1。 しかし、自分で大規模言語モデル（Large Language Model: LLM）を日常的に使用したり、表題にあるようにSREのためのLLM（LLM for SRE, LLM4SRE）に関する論文を読むうちに、LLMのテキスト生成器としての性質よりもその優れた推論機械としての性質に注目するようになった。特にSREの障害診断は、人間の専門家が推
SREエンジニアのSLI/SLO導入への挑戦 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進してきました。このプロジェクトは組織内で発生するあらゆるイベントを「機能」として定義・実装し、それらを束ねてサービスとして組織内外に提供するプロジェクトです。 ※ 詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください これまでの通常業務をサービスとして提供するという考え方は、我ながらとてもユニークかつ俊逸な発想だったと感じています。なぜなら、このサービスベースな考え方により組織にSLI/SLOを導入しやすくなったためです。 SLI/SLOの導入は個人的に難しいと考えています。導入するためにはさまざまな「ハードル」を突破する必要があるためです。しかし一方で、SLI/SLOを導
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
11 Years of Docker: Shaping the Next Decade of Development | Docker