はじめに 最近話題になっている browser-use について自己理解のために基本的なところをまとめてみます。 公式リポジトリはこちら browser-use とは？ browser-use は、Python で作られた「AI エージェントがウェブブラウザを操作できるようにする」ためのライブラリです。具体的には、下記のような機能を提供しています。 ビジョン機能や HTML 抽出 ブラウザで読み込んだページの DOM（要素構造）を解析、スクリーンショットやテキスト情報を取得できます。 マルチタブ管理 自動で複数タブを開き、それぞれのタブを並行して操作できます。 カスタムアクション機能 たとえば「特定のファイルを保存」「データベースへ登録」「社内チャットに通知する」など、ユーザー独自のアクションを定義できます。 自己修正機能 操作が失敗したり、要素を見つけられなかったりした場合に、自分で修正
こんにちは、メディアサービス開発部Webアプリケーション開発課のシゲタです。普段はRuby on Railsによるバックエンドの開発に携わっています。 先日とあるRubyメソッドの仕様が気になりコードリーディングに挑戦したのですが、当該メソッドがどこに何という名前で定義されているのかわからず、定義にたどり着くのに時間を要してしまいました。 同じようなポイントでつまづいた方、これからコードリーディングを始めようと思っている方のために、本記事ではRubyメソッドの実装を参照する方法をいくつかご紹介したいと思います。 pry-docで参照する リファレンスから参照する Rubyリポジトリをgit cloneしてローカルから参照する githubで検索して参照する まとめ 最後に pry-docで参照する pryにpry-docをインストールして$コマンドを使うことで、C言語で実装されたRubyメ
CircleCI + GitHub + Amazon Elastic Container Registry (Amazon ECR) + Amazon Elastic Container Service (Amazon ECS) (+ AWS Fargate) で継続的デリバリー環境を構成する クラウド事業部の上野です。 AWSにあるコンテナサービスを使ってみたい！今後の弊社のサービスで活用できるかも！ついでにCIツールでデプロイまで自動化したい！ ということでAmazon ECSとAmazon ECRで継続的デリバリー環境を作ってみました。 今回はCIツールとしてCircleCIを利用してみます。 簡単に各サービスを説明しますと、 CircleCIはCI／CD(継続的インテグレーション／継続的デリバリー)を行うサービスです。 Amazon ECSはDocker コンテナをサポートするAW
※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
資産価値が高まるオープンソースを未来のために厳重保管するプロジェクト 私たちはGitHub Universe 2019で、北極圏にソースコードを厳重に保管するプロジェクトGitHub Arctic Code Vaultを含むGitHub Archive Programを発表しました。GitHubは、コードを1000年間アーカイブ（保管）することで、次世代にオープンソースソフトウェアを残すというプロジェクトに着手してきたのですが、やっとそのその準備が整いました。GitHub Arctic Code Vaultが実施段階に入りました。 Vaultに何を保存するのか？ 2020年2月2日、vault（貯蔵庫）内にアーカイブ保存するため、GitHub上に公開されているすべてのリポジトリのスナップショットを取りました。スナップショットには以下のリポジトリが含まれています。 2019年11月13日に開
Git は大変便利なのですが、 clone では基本的にすべてのディレクトリが同期されます。 不要なものを削除すればそれはそれで変更として追跡されてしまうので、一部のディレクトリだけを取得したい場合は sparse-checkout というテクニックを使います。 一旦 clone しない sparse checkout Git 特定のフォルダのみcloneする - Qiita 先人の情報によれば「とりあえず普通に clone する」という例が多いのですが、ファイル数が多い場合など、すべてを clone したくない場合もあります。 そのような場合は下記のようにして sparse checkout を有効にします。 空の Git リポジトリとして初期化 sparsecheckout を有効にする リモートリポジトリの URL を origin として登録 チェックアウトする対象のディレクトリを
Bitbucket はソース ファイルの保管や変更の管理に最適で、チームでの作業の際にはそのメリットをさらに発揮します。しかしながら、実行ファイルやその他のビルド アーティファクト、動画、その他のメディア ファイルなどの、大規模なバイナリ ファイルの保管には適していません。 弊社のサーバーでユーザーに十分な応答性やダウンロード速度を提供するためにも、リポジトリ サイズを 1.0 GB にすることを推奨しています。Bitbucket Cloud のリポジトリには 2.0 GB の制限があります。この制限に到達した場合、直前のコミットを取り消すための変更のプッシュのみを行えます。また、5.0 GB のハード制限があります。この制限に到達した場合、変更をプッシュすることはできず、リポジトリは読み取り専用になります。 Bitbucket で大規模なファイルを保持する必要がある場合、ワークフローの一
Amazon EC2ではもっぱらRightScaleが提供するCentOSを使っています。特に癖もなく使いやすく満足です。１点不満があるとすれば、デフォルトで設定されているRubyのGemのリポジトリサーバが遅くて、Rubyのモジュールインストールに時間が掛かることくらいです。 ということで、参照先の変更の仕方です。 現状の調査 # gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.6 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [i686-linux] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECT
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
先日、スタートアップの方からGitHubの使い方について質問を受けたのでまとめてみます。この記事を読んで役に立つ可能性があるのは これからGitHubを使ってみようとしている ソースコードを管理したいが公開はしたくない エンジニア歴が短かったり非エンジニアだったりする という方々に対してなので、これらに当てはまらない方はそっとブラウザを閉じていただければと思います。 まず最初に、「Organizationを作る or 作らない」によって手順が若干異なるので、決めてしまいましょう。Organizationというのはいわゆる「会社用のアカウント」みたいなもので、権限の管理（◯◯さんはソースコードを見るだけ、△△さんはソースコードを改変することもできる、等）が楽になるというメリットがあり、毎月の利用料金がかさむというデメリットがあるもの、と考えていただければ概ね間違っていないかと思います。 リポ
趣味チーム？ 趣味チームに所属している方はいらっしゃるでしょうか。 お仕事関係なしに友人たちと趣味で開発するような人たちです。 趣味と言えどもチームですから、チームで使える開発環境を整えたくなります。 「 趣味チームの開発環境を整えたい 」 そう思った時に課題になるのが お金 です。 もちろん投資だと思ってお金を出せればいいのですが、基本線は趣味ですから中々そうもいきません。 ここはひとつ趣味の一環として、 無料縛り という制約を貸した上で、趣味チームの開発環境をどこまで整えられるのかを考えてみたいと思います。 環境イメージ 先にネタばらしをしておくと、以下のような感じに落ち着きました。利用量の制限はありますが 無料 です。 * * 簡単に言うと以下のようなことができます。 メンバ数 制限なし プライベートリポジトリ 作成可 任意のデバイスからのチャット(～1万メッセージ)、ファイル共有(
GitHubダイスキー！ ということで、知った時に「おっ！」と感じたGitHubに関する事項を選出してみました。 あなたに「おっ！」と思ってもらえたら幸せです。 １．入れておくと、意味を持つファイル名がある。 README.md README.mdは有名ですよね。リポジトリのトップにREADME.mdという名称でマークダウンを入れておくと、GitHubで解釈されて表示されます。 それ以外にも、あるのです。意味のあるファイル。 ISSUE_TEMPLATE.md トップか、.github/というフォルダにISSUE_TEMPLATE.mdという名のファイルを入れると、GitHubでIssueを作った時にこのファイルの内容が入ります。書くべき項目を羅列しておくとルール化できていいですよね。 それ以外にも PULL_REQUEST_TEMPLATE.md を入れておくと、Pull request
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
サードパーティリポジトリについて サードパーティリポジトリとは、ざっくりまとめるとCentOSが標準で用意している以外のサードパーティが作成したパッケージを「yum」でインストールできるようにする為のものです。 有名な物では、FedoraProjectが作成している「EPEL」や、RepoForgeプロジェクトの「RepoForge」（旧RepoForge）、mysqlやPHPの新しいバージョンを集めている「remi」リポジトリなどがあります。ここではそれらのリポジトリを使用できるようにする方法をまとめています。 リポジトリ一覧情報 CentOSで使用できるリポジトリ情報が、英語ですが下記のWikiにまとめられています。 http://wiki.centos.org/AdditionalResources/Repositories ここの情報をみると、各リポジトリの特徴や導入する際の注意点
引き継いだプロジェクトが、foo_pc, foo_sp, foo_commonみたいなかんじでリポジトリが分かれていて、同じ機能の開発やっているのにそれぞれにPullReqだしたり、リリースノートを書いたりするのがしんどいので、統合した。以下に統合した時の手順をまとめておく。 まず、新しくリポジトリを用意して、以下のように統合したいリポジトリ毎にディレクトリを作成して(.gitkeepとか用意して)、コミットする。 foo ├── foo_common ├── foo_pc └── foo_sp 次のようなスクリプトを実行する。git 2.9 から無関係なヒストリもってるブランチ同士をマージするときは --allow-unrelated-histories つけないとエラーになるのがハマりどころ。 for repo in foo_pc foo_sp foo_common; do git r
yumのリポジトリの設定は、repository セクションに記述します。オンラインリポジトリだけでなく、ローカルにあるリポジトリや、DVDのパスを指定する事もできます。repository セクションの書き方、リポジトリの追加手順を説明します。 Last Update : 2015年01月16日 yum｜yum リポジトリの設定と追加 項目 yum リポジトリの追加 yum リポジトリの設定で使えるその他のオプション 1. yum リポジトリの追加 yumのリポジトリを追加する場合、最低限必要となる以下の３項目を、～.repo というファイルに記述し、/etc/yum.repos.d ディレクトリにファイルを保存します。 /etc/yum.conf の [repository] セクションに記述してもリポジトリを追加できますが、/etc/yum.repos.d ディレクトリに、.repo
プルリクエストのレビュー時に 「規約では１行あたり最大８０文字なので、１文字削ってください」 などと一々指摘していると人間関係が破綻する可能性があります。 こういう定量的なものに関してはロボットに任せるのが一番です。 そこでHoundCIを使いましょう。 これはRubocopにリポジトリを監視させるというコンセプトのサービスです。 HoundCIを使うメリット コーディング規約違反のコードがmasterに入る前に必ず検知できる チームメンバー全員でRubycopを使う必要がない ダルいコーディング規約に関する議論が可視化できる 人間関係が壊れない（重要） 気軽にみんなでRubocopを使える Rubocopをsyntasticを使ってVimから自動実行する Rubocopを使ってコーディングルールへの準拠チェックを自動化 Qiitaの上のような記事を読んでから、暇があったら導入しようと思っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
