私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生５０年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを２つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ
サーバ業務周りの管理、運用について役に立ちそうなナレッジをまとめました。 長期的に書いているため用語に統一性がなかったり、不足分など随時修正したいと思います。 1. サーバ設計 サーバスペックはどうするべき？ 使用するOSは？ CentOS開発終了について MWは何を使うべきか Webサーバ構築にはどちらを使うべき？Apache？Nginx？ サーバセキュリティで最低限押さえておきたいことは？ listenするポートは最小限にしましょう ファイアウォール設定で送受信IPアドレス、ポートの通信制御はしておきましょう 外部に出る際にはプロキシサーバを経由するようにする 随時パッチを当てるようにする linuxでのアンチウイルスソフトの検討 個人アカウントで変更系コマンドは実行させないようにする ログについて考えること ストレージ容量には気をつける データベースはどう決めたら良いか MySQLか
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
私の愛しいアップルパイへ 8月16日（金）、このTCP/IP網の片隅に新規サービスを産み落としました。「TaskChute Cloud 2」っていいます。 頑張って作ったトップページ去年の8月から本格的に作り始めて、1年間でようやく形になりました。これこそ"俺が考える最強のタスク管理・時間管理サービス"って感じです。 正直タスク管理サービスって有名どころは出尽くしてる感じですし、「いまさらー？」って感じだと思います。この手のサービスは西海岸からいくつも出てますし。 でも、今までの発想のタスク管理サービスって使いづらくないですか？もう実際の仕事に通用しなくないですか？って気持ちもあって、ちょっと違ったアプローチのサービスをガチで作ってみました。 そこそこ借金して1年かけて作りました小学生時代からの友人と作った役員2人だけの極東の極小の会社なんですけど、コロナとか異常な円安とかの影響もあって経
1年と2ヶ月かけて開発していたアプリがリリースできたので記事にしました。 詳しい開発のログは以下のスクラップにまとめています 👌 リリースしたアプリ ダウンロードはこちら。 ■ iOS ■ Android LPサイト アプリを開発したきっかけ 以前から週1で家族の振り返りの時間を設けていて、今週あった出来事を互いに共有して議事録に残すことを習慣にしていました。 ただ、上記の運用をしている間に以下のような問題があることに気づきました。 振り返りの際に、今週の出来事を思い出せない まとまった期間の振り返りたいときに、テキスト情報のみだとピックアップしづらい 良かった出来事のみピックアップしたい 振り返りを開催する時間が毎回ズレる 日付を忘れてスキップしてしまう そこで、上記を改善するためアプリを家族で開発しようという話になりました。 どんなアプリ？ memoirは1週間を振り替えるアプリとし
はじめに こんにちは、kenです。 GWに「暇だな～～、こんな日はVS Codeの公式ドキュメントを読むか！w」と思って何気なく読んでたらデバッグに関して知らない機能がいくつかあったので、今回はそれをご紹介したいと思います。 おそらく今から紹介する機能はあまり知られてないと思います。もし全部知ってたらVS Code完全理解者なので誇ってください。（！？） 以下に記載する内容はVS Codeの公式ドキュメントのDebuggingという章を参考にしています。 注意 デバッグで使える便利な機能 ログポイント機能 行を指定しログポイントを追加すると、その行を訪れたタイミングでログを出力できます。 もちろんログ内には{式}という書式を使えば式も含めることもできます。 既存のコードに修正を加えることなく、ログを出力できるのは嬉しいですね！！ これで 「プリントデバッグしたprint行を消し忘れてPRあ
ログ・モニタリングのやるべきこと AWS CloudTrail の設定 CloudTrail は AWS リソースを「誰が」「いつ」「何に」対して「どうような」操作をしたのかを記録するサービスです。 ログの長期保管の設定をしておくことで、トラブル発生時の解析等に利用できます。 有料です（無料利用枠もあります） [YouTube] AWS CloudTrailを触ってみた CloudTrail Insights を利用することで、機械学習により異常なアクティビティを検出することもできます。 ログは S3 と CloudWatch Logs に転送でき、S3 に保管しているログは Athena により検索することもできます。 Athena を利用する場合は、事前に CloudTrail 用のテーブルを作成しておき、検索方法を習熟しておきましょう。 インシデントが発生してから習熟では対応が遅くな
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基本的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基本的に、外部ログ管理システ
こんにちは、しば田です。 AI を用いたプログラミング、中々難しいです。 日々どうしたら効率を最大化できるかを日々試行錯誤していますが、なかなか正解に辿り着けている気もしないしモデルの登場のたびにチューニングが必要なのでツラいですね。 この記事では、自分の思考整理も兼ねて常日頃から私が意識して行っている Tips に関してまとめてみました。重要なことから些末なことまで全て書いています。 最近、Cursorのコミュニティが出していたTips17選に対して自分の考えを書いたのですが、 反響があったのでもっと網羅的に書きたいなと思い記事を書くことにしました。（30個くらいあります。） ※記事の対象者は Cursor、Windsurf、Cline（Roo）あたりを使ってプログラミングしている人を想定しています。 ※一覧性を優先するのでそれぞれを深くは語りません。 ※多分抜け漏れがあるので適宜追加し
けみとれ @chemicl_t 博士課程でようやく「（基本的に）ヒトは論理ではなく感情によって動かされる」と気づいた 案外ここを勘違いしている人は多いが… 2022-07-09 22:22:51 けみとれ @chemicl_t 博士課程、大体無駄だったがこれに気づけたことは良かった 論理を重視する（とみなされる）科学者たちが「ストーリーを重視して」論文を書くのは、「論文を読むことに伴う感情を快いもの・相手を圧倒するもの」にすることで、査読者がacceptする確率を有意に高めると知っているからであって、（続 2022-07-09 22:26:16
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください！ 【AWS】さいきょうの運用・監
log4jとはJava用のloggingライブラリだ。loggingライブラリというのはログとして記録すべき文字列を受け取り、それをどこかに出力するものだ。文字列の中身を通常のloggingライブラリは気にしない。 log4jが通常のloggingライブラリと違うのは、文字列の中身を見て、一部の文字列を変数とみなして置換することだ。これはlog4jのドキュメントではlookupと呼ばれている。 Log4j – Log4j 2 Lookups 例えばプログラムを実行中のJava runtimeのバージョンをログに含めたい場合は、"Java Runtime: ${java:runtime}"などとすると、"Java Runtgime: Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation"などの
こんにちは、いちび( @itiB_S144 )です。 2021年12月25日にWindowsイベントログ解析ツールとして「Hayabusa」がリリースされました🎉 Hayabusaは事前に作成したルールに則ってWindowsイベントログを調査し、インシデントや何かしらのイベントが発生していないか高速に検知することができるツールです。 私も開発を微力ながらお手伝いさせていただきました。 本記事では多くの方にHayabusaを触っていただきたいため、簡単な使い方を紹介していきます。 We just released two Windows event log analysis tools: Hayabusa and WELA: https://t.co/nFHxSgUl2q #yamasec— Yamato Security Tools (@SecurityYamato) 2021年12月2
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
Jira SoftwareやTrelloなどを中心としたPMが経験してきたプロダクト管理ツールの失敗や改善を語る「本当に使いこなせてる？プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】」。ここで株式会社ビズリーチの菊池氏が登壇。ドキュメント管理とプロダクトバックログの失敗から学ぶツール運用のコツについて紹介します。 菊池氏の自己紹介菊池信太郎氏（以下、菊池）：ビズリーチの菊池から、10分枠で話をします。今日のテーマは「失敗から学ぶドキュメントとチケット運用のコツ」ということで、今まで経験したところで「こういうアンチパターンがあったよ」「こういう改善をしたよ」というようなところをお話しできればと思っています。 自己紹介を軽くすると、（私は）2018年からビズリーチで働いています。ビズリーチサービスを作っていて、プラットフォーム開発部の部長をしています。また、2019
全部主観であり自分の抱えてる感想 およそ3年に及ぶパンデミックによるリモートワークを経験した結果「直接会って話したほうがはやい」といってメンバーの出社を求める組織は徐々に増えていると感じる。 出社だけではなく、例えば不動産仲介業者とのやり取りも、メールで質問した内容に対して電話で答えが返ってくるというように、事あるごとに口頭での同期的なコミュニケーションを取りたがる人はいる。 「話したほうがはやい」という人は大抵伝える時の細かいニュアンスや表情から読み取れるテンションが直接会ったほうが伝わるしお互いレスポンスを待たなくて速くて楽だと言う。 それは全く否定しない。間違いないと思う。そもそもタイプミスや誤変換を気にしながらキーボードを打つよりも発話したほうがコミュニケーションは速いに決まってる。レイテンシーが発生するのは声を届ける媒体だけだ。 だけどそれは速い、もしくは楽なだけだ。わざわざ言わ
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
エージェンシー事業でリードデータエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3にログ転送
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs（以下CW Logsと記載）とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
広告技術部のUTです。 最近はカービィディスカバリーをゆっくりやってます 概要 過去の失敗 どうやったか 仕組み 結果 まとめ 概要 昨今ではデータドリブンな意思決定を重視する企業がどんどん増えており、データを活用することにより事業成長へのインパクトを出そうとしています。 データを事業へと活用するためには、蓄積されるデータを分析するために保管しておく必要があります。 弊社も創業時からデータを蓄積し事業に活用することに力を入れてきた企業の一つであり、日々大量のログが収集されています。 またAWSアカウントを複数運用していますが、一番データ量の多い広告アカウントのS3にはペタバイトレベルのデータが保管されています。 普段何気なく使っているデータレイクとしてのS3ですが、少量であれば無視できるくらい小さいので、コストを気にせず使っておられる方も多いのではないでしょうか？ そのようなS3でも巨大な
＜この記事の著者＞ ばんか（bamka） - Tech Team Journal Web制作会社の会社員（Webディレクター）として働きつつ、個人でブログ／メディアライターとしても活動するパラレルワーカー。 ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。 タスク管理、得意ですか？ 自慢じゃありませんが、私は苦手です。あまり好きではありません。 Webディレクターとしては、プロジェクト管理・タスク管理は必須スキルなので、一般的には「上手にやれている方」なのかもしれません。ですがいまだに苦手意識は抜けないままです。 なんで苦手なのかなぁと思い返してみると、要因はいくつか思いつきますが、中でも最も根深い問題は「気持ちに頼りすぎる」という点にあるように思います。 【目次】 やる気の高いときに設定するから長続きしない
VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します！ ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード：https://miro.com/ja/online-scrum-agile-tool/ マインドマップ：https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 （「4月1日に夢を語る」という PR TIMES の企画だそ
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
# Event データモデリングとデータ基盤の構築・運用 （第14回ちゅらコラボ）CARTA HOLDINGS x ちゅらデータ 合同イベント https://churadata.connpass.com/event/254417/ ぼくのかんがえる最高のレポーティング基盤 …
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
【変更履歴】 1/6 10:33: ウィークリーページのテンプレート内の「プラン」のビューのフィルタを修正しました 1/5 18:00: プロジェクトページのテンプレート内のタスクのフィルタを修正しました 1/5 14:05: ウィークリーページのテンプレート内のボタン名とアイコンを微調整しました「タスクシュート」の考え方に影響を受け、Notionでタスク管理できるようにデータベースを最適化したことで、自分史上最高に使いやすくなった話。 【注記】このテンプレートは、一般社団法人タスクシュート協会公認ではない非公式のものになります。また、公認の「TaskChute for Notion」テンプレートもありますので、タスクシュートに興味が出た方はそちらを試すのをおすすめします！ タスク管理アプリをいろいろ試したけど…やることをリストアップして、それが期限内に終わるように進めることができる"タス
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章 せっかくのインシデントを無駄にする 10
そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr
兵庫県神戸市で生まれ育った。大学進学を機に東京に来て、それから現在に至るまで住み続けている。なので関西出身なんだけれど、実はあんまり大阪のことは知らない。もちろん当時住んでいたときには梅田とかなんばで買い物したりとかしたことはあったが言うて10代である。神戸に帰るときにも大阪の飯屋とか行ったりはしたことも当然ある。だけど、ちゃんと泊まって満喫したことないなあ、ということで、泊まってひたすら飯を食ったのでその記録。ちなみに特に綿密に計画を決めたわけではなく、だいたい行き当たりばったりである。 BOTANI CURRY@梅田 いわゆるスパイスカレーというものを東京でも提供する店が増えているけれど、ルーツ的には大阪が元祖らしい。んで、その大阪スパイスカレーでめちゃくちゃ評価が高いのが今回行ったBOTANI CURRY、らしい。らしい、というのは大阪に行くときの新幹線で食べログ見てて「大阪ナンバー
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOであ
こんにちは！イーゴリです。 AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ) AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。 とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。 AWS Well-Architected Framew
Twilogを運営しているTogetterの代表、およびエンジニアの @yositosi です。 4月にTwilogの課金プランを改定、さらに先月には「いいねインポート」機能も提供させていただきました。おかげさまで、多くのユーザの皆様にご利用いただけており、TwilogおよびTogetterの危機的な状況もかなり改善しつつあります。サポートいただいている皆様、本当にありがとうございます。 さて、今回は、Twilog初のAIプロダクトがリリースされましたので、そのプロモーションとなります。 MCPサーバーとは？皆さんは、最近話題のMCPをご存知でしょうか？AIのプロダクトを追いかけている方やエンジニアの方々はその盛り上がりを把握されていると思いますが、多くのTwilogユーザの方々は、知らないワードなのではないかと思います。簡単にいってしまうと、ChatGPTなどのAIクライアントが、MCP
はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの
Parquetは便利なファイル形式で、列志向のフォーマットとしてはデファクトの1つと言っても過言ではないでしょう。 ですが、jsonやcsvとは違い、ファイルを見ただけでどんな構造かわかるものではありません。 この記事は、Parquetの具体的な構造について記述します。 はじめに この投稿は、Parquetの構造について、バイナリを見ながら確認するものです。 ただし、Parquetの大枠に注目した投稿なので、delta encodingやrun-lengthなど、個別の圧縮方法については取り扱いません。 ※ Parquetの作成には https://github.com/parquet-go/parquet-go を使用していますが、goの知識は必要ありません tldr Parquetは以下の構造を持っています。 ファイルはRowGroupとメタデータに分かれている RowGroupの中に
はじめに この記事では、モノタロウの基幹系を構成するシステムの一つである、商品情報管理システム（PIM：Product Information Management システム）の導入プロジェクトで、商品情報を基幹系と同期するシステム（商品情報同期機能）の性能や運用環境の改善を行った話をご紹介します。 背景 モノタロウの基幹系は、長年内製のシステムで支えられてきました。基幹系のシステムは、少数のWebアプリケーションと多数のバッチから構成されています。中でも商品情報の管理に関するシステムは、在庫や仕入先に関するシステムと一体化していて、商品情報に関する数多くのマスタメンテナンス画面を備えたやや複雑なシステムです（図１）。 図1 基幹系の概略図 当社のシステムは、もともと自分たちのビジネスに必要な機能を提供する手頃なパッケージ製品がなかったため、すべてを内製でまかなってきたという経緯があります
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く