並び順

ブックマーク数

期間指定

  • から
  • まで

441 - 480 件 / 2296件

新着順 人気順

diffの検索結果441 - 480 件 / 2296件

  • 真の UNIX 標準規格 System V Interface Definition (SVID) について - Qiita

    はじめに POSIX のコマンド一覧を見てやけに少ないなと思ったことはないでしょうか?例えば useradd がないのでユーザーが作れませんしcrontab はあるのに cron がないと中途半端です。重要なものがいくつも欠けおり、あれだけのコマンドでは到底 Unix を使うことができません。実は「Unix に実装すべき最低限の仕様」を定義した標準規格は他にありました。それが UNIX をこの世に生み出した AT&T 自身による標準規格 System V Interface Definition (SVID) です。この記事は POSIX に敗れて消えてしまったもう一つの UNIX 標準規格 SVID ・・・のコマンドの話です。(私の知識不足により C 言語インターフェースの話は含まれません。) SVID と POSIX の歴史 SVID は POSIX よりも早く標準規格を発表しています

      真の UNIX 標準規格 System V Interface Definition (SVID) について - Qiita
    • DeepL翻訳を修正するということ - アスペ日記

      ポール・グレアム "What I Worked On" の翻訳の補足記事です。 ポール・グレアムの長編エッセイ「私が取り組んだこと」を翻訳するにあたって、DeepLの翻訳結果をベースに編集しました。 この記事では、DeepLの誤訳箇所とその修正について書いてみます。 DeepLの翻訳と私の最終版の差分は、GitHubのdiff("Load diff"を押す必要があります)で見ることができます。 こうして見ると、かなり差分が少ないことがわかります。多くの修正は些細な変更ですし、手を加えなかった段落もあります。機械翻訳がここまで来ているというのはすごいことです。 それでも、元の翻訳では、いくつかの誤訳が重要なところを台無しにしてしまっています。ここでは、それらのポイントを見ていきます。 It seemed only a matter of time before we'd have Mike,

        DeepL翻訳を修正するということ - アスペ日記
      • GCPで基本に戻って始める実践 Infrastructure as code再入門#2 - VisasQ Dev Blog

        こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 前回はGCPにCompute Engineのインスタンスとサービスアカウント作成までできましたので次はAnsibleを使って作成したインスタンスに対してProvisionを実行していきたいと思いま

          GCPで基本に戻って始める実践 Infrastructure as code再入門#2 - VisasQ Dev Blog
        • Snyk IaC + reviewdog + aquaではじめるDevSecOps - Gunosy Tech Blog

          はじめに Snyk IaCとは CIでのIaC解析 aquaでSnyk CLIを簡単にインストール&バージョン管理 reviewdogでコメント形式の指摘を実現 まとめ はじめに こんにちは。技術戦略室SREチームのkoizumiです。 最近は、katoさんからオススメいただいた「スクワットの深さは人間性の深さ」という本を読み、日々スクワットに励んでいます(大嘘)。 さて、こちらの記事は Gunosy Advent Calendar 2022 の9日目になります。 昨日の記事はGunosy Tech Lab 石川さんの「リモートモブプログラミング開発の実践」でした。 本日は「Snyk IaC + reviewdog + aquaではじめるDevSecOps」と題して、CIへSnyk IaCを導入した事例についてご紹介します。 先日、私が執筆したこちらの記事でも、「Shift-Leftによる

            Snyk IaC + reviewdog + aquaではじめるDevSecOps - Gunosy Tech Blog
          • あるAIの歌 10年前に他界した妻の歌声と写真を再現する理由──第一回AIアートグランプリ受賞

            「第一回AIアートグランプリ」受賞作となった「Desperado - - Diff-SVC generated 妻音源とりちゃん[AI]」 Koya Matsuo <AIを使ったアート作品を競うコンテスト「第一回AIアートグランプリ」で、グランプリ受賞作が生まれた経緯とは......> 2022年の夏、かつてのパソコンブーム、インターネットの大衆化、スマートフォンの普及に匹敵すると思われる動きがありました。ジェネレーティブ(生成系)AIの登場です。 最初はイラスト・写真をAIで生成することが注目され、現在ではChatGPTをはじめとするテキスト生成によるAIとのインタラクティブなやり取りがマイクロソフトやグーグルなどのビッグテックを中心に、新しい産業革命とも言うべき大きなうねりを引き起こしています。 クリエイティブな世界においても生成系AIという新しい道具の登場で、アーティストたちの心は大

              あるAIの歌 10年前に他界した妻の歌声と写真を再現する理由──第一回AIアートグランプリ受賞
            • カスタマイズで広がるAWS Copilotの実践力 - KAYAC engineers' blog

              SREチームの橋本です。SRE連載の7月号になります。 カヤック社内では弊社藤原のecspressoをAmazon ECSのデプロイツールとして活用していますが、AWS公式のデプロイツールAWS Copilot(現在v1.29)もそのオールインワン的な性質から、開発・運営リソースが限られるプロジェクトでは選択肢に入るようになってきました。 今回はそのAWS Copilot活用のため、背後にあるAWS CloudFormationテンプレートをカスタマイズする手法を紹介します。 AWS CopilotとCloudFormation AWS CopilotはECSなどのデプロイを簡単にするCLIツールですが、実態としてはManifestと呼ばれるYAMLの設定ファイルからCloudFormationテンプレートを生成し、各種リソースを作成・管理するものです。 AWS Copilotは内部的にC

                カスタマイズで広がるAWS Copilotの実践力 - KAYAC engineers' blog
              • たまってしまった .rubocop_todo.yml をGitHub Actionsで継続的かつ自動的に倒す方法 - STORES Product Blog

                こんにちは。heyのCTOをやっている藤村です。 実はCTOになる前はSTORESのRailsのコードを改善する仕事をしていました。その頃に、たまってしまっている.rubocop_todo.ymlをなんとか手間をかけずに消化していきたいな〜と思い、少しづつ自動的に消化する仕組みを作りました。この記事ではその仕組みをご紹介します。 rubocop_todo.yml とは 既存のコードベースに対してRuboCopを適用すると大量の違反箇所が出てしまい使い物にならないという問題があります。それの解決策として、既存のコードで違反しているファイルを無視する設定を .rubocop_todo.yml というファイルに保存して .rubocop.yml で読み込み、既にある違反はいったん無視する、という方法が用意されています。 Configuration - RuboCop: The Ruby Lint

                  たまってしまった .rubocop_todo.yml をGitHub Actionsで継続的かつ自動的に倒す方法 - STORES Product Blog
                • Lit

                  Skip the boilerplate Building on top of the Web Components standards, Lit adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier. Every Lit feature is carefully designed with web platform evolution in mind. Tiny footprint, instant updates Weighing in at around 5 KB (minified and compr

                    Lit
                  • Goで書いたツールの依存管理をdepからGo Modulesに移行した - $shibayu36->blog;

                    昔作った notify-issues-to-slackの依存モジュールはdepのままで管理していたが、勉強がてらGo Modulesに移行することにした。 参考にした資料 Go 1.13 に向けて知っておきたい Go Modules とそれを取り巻くエコシステム - blog.syfm Go Modulesについてざっくり知ることができてよかった Modules · golang/go Wiki · GitHub ざっくり知った上でちゃんと理解するために公式ドキュメントを読む depからgo modulesへの移行と、移行時にTravis CI & GoReleaserでハマる(かもしれない)ポイント · horizoon 移行手順で参考にした Goモジュールでツールもバージョン管理する - Plan 9とGo言語のブログ ツールも含めてgo.modに入れていく手順で参考にした やったこと

                      Goで書いたツールの依存管理をdepからGo Modulesに移行した - $shibayu36->blog;
                    • 医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ

                      こんにちは、ヘンリーの SRE の戸田と Wildcard Engineer の岩永です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 前編の Henry のバックエンドをモノレポ化した戦略やプロセスに続いて、後編のこちらの記事ではモノレポ化の技術的手法を解説します。 dev.henry.jp 実際のモノレポ化の流れに沿って、ポイントを3点説明します。 2つの git リポジトリのマージ アプリケーション・ワークフローのモノレポ対応 モノレポへの切り替え当日に向けた手順書の作成 1. 2つの git リポジトリのマージ 今回のモノレポ化においては、もともと存在していた henry-general-api と henry-receipt-api という2つのマイクロサービスのリポジトリを、1つのリポジトリにマージし、それぞれのマイクロサービスがサブディレ

                        医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ
                      • OSS「Coppe」の公開 〜 BigQuery基盤のデータ監視ツールによるデータ品質担保 - ZOZO TECH BLOG

                        はじめに こんにちは、データシステム部データ基盤ブロックの纐纈です。9月から22卒内定者として、チームにジョインしました。 本記事では、弊社のデータ基盤チームが抱えていた課題と、その解決のために公開したOSSツール「Coppe」を紹介します。Coppeは、以下のような方にお勧めできるツールです。 BigQueryを使用したデータ基盤の監視に興味がある BigQueryの監視ツールとしてRedashを採用しているが、運用が面倒に感じている インフラの設定なしにBigQueryの監視を行えるツールが欲しい なお、本OSSはMonotaRO Tech Blogの記事「SQLを使った監視でデータ基盤の品質を向上させる」で紹介されていた仕組みを参考にし、より柔軟に監視項目を設定できるように新規開発しています。 OSSとして公開しているため、本記事と併せてご覧ください。 github.com 開発の経

                          OSS「Coppe」の公開 〜 BigQuery基盤のデータ監視ツールによるデータ品質担保 - ZOZO TECH BLOG
                        • AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 | Amazon Web Services

                          Amazon Web Services ブログ AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 この記事は、Complete guide to full-stack CI/CD workflows with AWS Amplifyを翻訳したものです。 AWS Amplify は、1) 条件付きバックエンドデプロイ、2) ビルド時のaws-exports.js の自動生成、3) 異なるAmplify アプリケーション間でのバックエンドの共有といった3つの新しい機能をAmplify のCI/CD ワークフローに追加しました。これらの機能を使用することで、より柔軟にフルスタックアプリケーションをデプロイすることが可能です。 AWS Amplify は、フルマネージドな CI/CD およびホスティングサービスを提供し、開発者は Git リポジトリを接続するだけ

                            AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 | Amazon Web Services
                          • GitHub ActionsでJestのログに色をつけられる - hogashi.*

                            Jest は TTY では色つきのログを出すが、そうでないときは色なしになる https://jestjs.io/docs/cli#--colors --colors オプションか、環境変数で FORCE_COLOR=true するととにかく色つきのログを出せる GitHub Actions では色つきのログに対応している A better logs experience with GitHub Actions | The GitHub Blog That’s why we are increasing the color support, including: ANSI colors 8-bit colors 24-bit colors https://github.blog/2020-09-23-a-better-logs-experience-with-github-actions/

                              GitHub ActionsでJestのログに色をつけられる - hogashi.*
                            • オレのおすすめ Git エイリアス 5 選 - アルパカの徒然文

                              Gitのおすすめエイリアス5選を読んで自分も幾つか晒してみようと思った。 シンプルなコミットログとグラフを表示する git l l = log --graph --decorate --pretty=oneline --abbrev-commit git log を利用するとコミットログからメッセージだったり、誰がコミットしたのか読めるけど殺風景だし、あまりどのブランチがどうマージされたのか理解しずらい。 単純なコミットメッセージとブランチの関係性をパッと知りたい時によく利用している。こんな感じで表示される。 人に優しい変更差分を表示する git dsf dsf = "!f() { [ -z \"$GIT_PREFIX\" ] || cd \"$GIT_PREFIX\" && git diff --color \"$@\" | diff-so-fancy | less --tabs=4 -

                                オレのおすすめ Git エイリアス 5 選 - アルパカの徒然文
                              • Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog

                                はじめに こんにちは、クラスター株式会社でソフトウェアエンジニアをやっているid:shiba_yu36です。 クラスターではGoの自動テストをCircleCIで実行しています。入社して以降、この自動テストの実行時間が少し長いと感じたため、調査と改善を進めてきました。結果として速度を改善できたので、この記事でGoの自動テスト高速化のための調査と改善手法について共有したいと思います。 はじめに Goの自動テストで課題だったこと 最終的な結果 自動テスト高速化の流れ テスト実行時間のボトルネックを調査する CircleCIのTIMINGタブで大まかなボトルネックを調査する make testのボトルネックを調査する 高速化でやるべきことを決定する 1つずつ改善し結果を計測する go generateの成果物をレポジトリにcommitし自動テスト上では実行しない: 2分短縮 ビルドキャッシュを用い

                                  Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog
                                • Raspberry Piとカメラを使ってLINE botに混雑度を教えてもらう - Qiita

                                  作ったサービス 「店に行きたいけど、待ちたくはない」 「病院行きたいけど、空いてる時に行きたい」 「あそこは今、混んでるやろか」 そんな思いから、"混雑度をいつでもどこでも確認できるサービスを"というコンセプトで開発しました。 サービスの簡単な流れは以下の通りです。 具体的な実装を以下に示します。 混雑度の算出方法 誰もいない状態の画像をあらかじめ撮影しておきます。 人がいる状態の画像を撮影します。 この画像について、初めの画像と差分をとります。 この差分の大きさを、混雑度としています。 画像認識で人を識別し人数から混雑度を求めたり、人感センサを用いたりする方法も検討しましたが、 今回はシンプルに差分だけにしました。(いつか改良したい。) 環境 - Raspberry Pi 3 Model B - OS : Raspbian Jessie - opencv : 3.4.2 まず無人の部屋を

                                    Raspberry Piとカメラを使ってLINE botに混雑度を教えてもらう - Qiita
                                  • pytest fixtureの地味だけど重要な部分について - 株式会社ホクソエムのブログ

                                    こんにちは。ホクソエム支援部サポーターのPython担当、藤岡です。 最近はデータエンジニア見習いとしてBI周りを触っています。 今回はpytestのfixtureについての記事です。 pytest自体が有名で記事もたくさんあるので、今回は地味だけど重要だと個人的に思っている usefixturesとスコープについて取り上げます。 地味とはいえ、pytestの初心者がfixtureを使いこなすためのステップアップに必要な内容だと思います。 ぜひマスターしていただければ幸いです。 1. 前書き 基礎的なことに関してはこの記事にとても簡潔にまとまっているので、こちらをまず読むのがオススメです。とても良い記事です。 pytestは独自の書き方を持ち込んでいるライブラリです。その機能を使いこなすと「綺麗」なコードにはなりますが、反面それは使われている機能を知らない人にとってはこの上なく読みにくいも

                                      pytest fixtureの地味だけど重要な部分について - 株式会社ホクソエムのブログ
                                    • 大澤昇平 愉快なwikipedia編集履歴

                                      「日本」の版間の差分 https://ja.wikipedia.org/w/index.php?title=%E6%97%A5%E6%9C%AC&diff=prev&oldid=74635875 AI研究者の[[大澤昇平]](東京大学特任准教授)は、『AI救国論』の中で「労働人口の減少を、産業用ロボットによって代替することが可能になる」という説を論じている<ref>{{Cite book|title=Ēai kyūkokuron|url=https://www.worldcat.org/oclc/1120736271|publisher=Shinchōsha|date=2019|location=Tōkyō|isbn=9784106108280|oclc=1120736271|last=Ōsawa, Shōhei.|last2=大沢昇平.}}</ref>。 「落合陽

                                        大澤昇平 愉快なwikipedia編集履歴
                                      • LinuxでもっともF-wordなコミットを探す(git以降編) - Qiita

                                        tl; dr: 近年のLinuxはそれほどファ●ックではない。最大の"F値"は25で、単一のファイルに集中していた。 もくてき ファッ●クと言えばLinuxの風物詩と言える時期もあったが、最近は落ちついてきた印象はある。それでも fuck コマンド やメーリングリスト等では言及は有る。 では、それを印象付けるような出来事としては何があったのだろうか。今回、コミットログおよびそのソースコードdiffにおけるF-wordの登場回数を F 値 (F value) と定義し、最もF値の高いコミット(the most F-valued commit)を探してみることにした。 (ソースコードdiffにおける登場回数であるため、F-wordを削除したコミットも高いF値が与えられることに注意する) 全てのコミットを git show する 最近シェルスクリプト代わりにCMakeを使っているので今回もCMa

                                          LinuxでもっともF-wordなコミットを探す(git以降編) - Qiita
                                        • GCPで基本に戻って始める実践 Infrastructure as code再入門#3 - VisasQ Dev Blog

                                          こんにちは! 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 前回はAnsibleの基本的な用語の説明から初回のAnsibleの実行迄を説明しましたので今回はAnsibleを使った実際のPlaybook,taskの書き方等を説明していきます。 その他のGCP

                                            GCPで基本に戻って始める実践 Infrastructure as code再入門#3 - VisasQ Dev Blog
                                          • キーワード引数の分離への対応にRuby 2.8.0-devを使う - koicの日記

                                            先日のパッチ会で kamipo さんにもらったアドバイスを書き残しておく。 TL;DR としては表題そのまま。キーワード引数の分離への対応にRuby 2.8.0-devを使うというもの。 2.8.0-devを使えばイージーモードだけど2.7.0縛りプレイだと常人にはクリア不能のむずかしさ https://t.co/tpJGTARwAc— Ryuta Kamizono (@kamipo) 2020年1月24日 Ruby 2.7.0 を使ってキーワード引数の分離への警告のみでそれを抑制しようとする場合は、スーパーハードモードルビーとパッチ会で呼ばれた変更箇所の特定が難しいケースになる場合がある。 スーパーハードモード (Ruby 2.7.0) Ruby 3.0 に向けてキーワード引数の分離が必要になる場合は、Ruby 2.7.0 を使うと以下のような警告が表示される。 % ruby -v ru

                                              キーワード引数の分離への対応にRuby 2.8.0-devを使う - koicの日記
                                            • Rustで組み込みプログラミングの第一歩、LチカとHello Worldを試してみた | DevelopersIO

                                              組み込みに向いていると言われるRustで、Lチカを試してみました。環境構築から、サンプルをビルド、実機にダウンロードして実行するまでの一通りを説明します。 最近社内ではRustがちょっと流行ってきていて、社内勉強会を開催したりしています。 一方、社内の研究開発として、組み込みのプロトタイピングをやったりしています(たとえばDevelopersIO Cafeでも使っています)。 Rustは、システムプログラミングに向いているとも言われています。Rustで組み込みするのも一興かと思いますので、実際に試してみました。 やることは、組み込みのHello WorldであるLチカです。 stm32-rs Rustの組み込み関係の状況を調べてみると、STM32というベンダーのチップを使ったツールチェインやライブラリの整備が、だいぶん進んできているようです。こちらのサイトThe Embedded Rust

                                                Rustで組み込みプログラミングの第一歩、LチカとHello Worldを試してみた | DevelopersIO
                                              • jsondiff: JSONの構造の一部を無視して差分をとれるGoのライブラリを書いた - Sexually Knowing

                                                github.com 背景 仕事でお世話になっているkayac/ecspressoの機能の中にローカルのタスク・サービス定義と現在使われている定義を比較して差分を出力してくれるものがある。 github.com これから加えようとしている差分をプレビューできるだけではなく、たとえばデプロイしようとしているわけでもないのに差分があればローカルの定義が古びていることがわかるのでCIに組み込めると便利。 しかし実際に使おうとすると困る点が見つかった。 たとえばタスク定義にイメージタグを書く際に {{ must_env 'IMAGE_TAG' }} のように環境変数を参照している時に「イメージタグ 以外 に差分がない」ことを確認するのが難しいということ。 理想的には image を無視したJSONの構造を比較して差分が出せると良い。あるいは出力されるdiffをパースして image の差分は無視す

                                                  jsondiff: JSONの構造の一部を無視して差分をとれるGoのライブラリを書いた - Sexually Knowing
                                                • Announcing Docusaurus 2.0 | Docusaurus

                                                  Today we are extremely happy to finally announce Docusaurus 2.0! 🥳️ At Meta Open Source, we believe Docusaurus will help you build the best documentation websites with minimal effort, letting you focus on what really matters: writing the content. After 4 years of work, 75 alphas and 22 betas, the next generation of Docusaurus is ready for prime time. From now on, we now plan to respect Semantic V

                                                    Announcing Docusaurus 2.0 | Docusaurus
                                                  • Pull Requestのセルフレビューでやっていること

                                                    この記事は LITALICO Engineers Advent Calendar 2021 その2 の7日目の記事です。 Pull Requestを作るときに割と入念にセルフレビューしてからレビュー依頼するようにしており、また他メンバーのもののレビューをしているときに「これは事前にセルフレビューして修正しておいてほしいなぁ」と思うことがあり、セルフレビューの重要性を感じるこの頃です。 レビュー時に都度指摘してもよいのですが、意外と観点が多いこともあり、思考の整理がてらアウトプットしてみるか、という試みです。 なぜ自分でレビュー? まず、そもそも自分で書いたコードを何故自分でレビューするのか?という点について書いておきます。 よくプログラミング一般の議論で「N日前のコードは他人のコード」と言われます。ということは、Pull Requestを作成した時点の自分から見て、該当コードを書き始めた時

                                                      Pull Requestのセルフレビューでやっていること
                                                    • 差分指向テスト(DOT: Difference Oriented Testing)という考え方 - MNTSQ Techブログ

                                                      はじめに MNTSQ(モンテスキュー)株式会社 フロントエンド担当の安積です。 入社して4ヶ月とちょっと。 コードに取り組もうと入社して、まさに日々格闘しております。 私の後ろの席にはこんなバズ記事書く人や、こんなイカつい記事書く人が座ってまして、そんなプレッシャー期待の中からお送りいたします。 tech.mntsq.co.jp tech.mntsq.co.jp 昨日はこんな記事も公開されています。 tech.mntsq.co.jp はじめに 現在のステータス またはMNTSQ考古学 リファクタリングやるぜっっ! 仕様書大事だよね 差分指向テストとは テスト環境の概要 テストデータ ブラウザ操作自動化 スクリーンショット比較 Playwriteの操作 ちょっとコードのサンプル 最後に この記事を書いた人 現在のステータス またはMNTSQ考古学 コードベースから見たMNTSQのフロントエン

                                                        差分指向テスト(DOT: Difference Oriented Testing)という考え方 - MNTSQ Techブログ
                                                      • Cloudflare Workersで手軽にRESTful APIを公開する - kasuのブログ

                                                        今回は、OpenAPI Specification から良い感じのドキュメントサイトを提供してくれるサービス bump.sh を見つけたので、RESTful API を用意して試してみます。 ドキュメントサイトがあることで、API が公開されていることがより分かりやすくなるでしょう。 こちらはスキーマの差分を解析するツール API Diff · Powered by Bump.sh を提供しており、今後 GraphQL もサポートされるそうなので楽しみです。 RESTful API まずは JSON を返すだけの簡単なAPIを作りたいと思います。 軽量なアプリケーションとなるので Cloudflare Workers をデプロイ先とします。 手書きしたくない ゼロから書くので定義ファイルとサーバーサイドの実装どちらも手書きすることはなるべく避けたいところです。 Node.js では pat

                                                          Cloudflare Workersで手軽にRESTful APIを公開する - kasuのブログ
                                                        • Unified Diff 形式の差分から Go AST を構築して feature flag を自動計装する

                                                          Go Conference 2024 の登壇資料 https://gocon.jp/2024/sessions/11/

                                                            Unified Diff 形式の差分から Go AST を構築して feature flag を自動計装する
                                                          • 色々な生成AIモデルをColabで動かして今年を振り返る - ABEJA Tech Blog

                                                            こんにちは、ラボで研究開発をしたりプロトタイプを作っている藤本(X(Twitter))です。ABEJAアドベントカレンダー2023の21日目の記事です。ここ近年、生成AIの勢いが凄いです。最近は一夜明けたら世界が変わっているみたいなことがしょっちゅう起きています。そんな状況なので、なかなか世の中についていくのが難しいのではないかと思います。そこで今回は、これまでに色々と出てきた生成モデルを振り返りつつ、ひたすら思いつく限りColabで動かしまくってみる企画をやってみようかと思います。流石に全部Colabで動かすのは大変でした・・・。 まずは言語を対象として日本語モデルを含む様々なモデルを対象に推論実験を行います。続いて高速化の実験、更にSFTによるInstructionチューニングや、RLHFもやってみます。最後に、ソースコード生成もやってみましょう。次に、画像を対象として、言語同様に色々

                                                              色々な生成AIモデルをColabで動かして今年を振り返る - ABEJA Tech Blog
                                                            • SwiftFormatを導入してコード記法を統一化 - Mirrativ Tech Blog

                                                              ミラティブでiOS開発をしている福山(@fokotate)です。 今回はSwiftFormatをMirrativのiOSプロジェクト(約1500のSwiftファイル)へ導入したときのことを話します。 導入にあたって 私は当初、SwiftFormatについてよく知らなかったため導入にはあまり乗り気ではありませんでした。 しかし調べてみると、実行タイミングによってはチームにとってほぼストレスなくソースコードを綺麗に保てることがわかってきました。 コミット実行時にSwiftFormatがコードを変更してコミットを中断、その変更を取り入れて再度コミットするといった一手間だけです。 導入したい気持ちが高まってきたものの、いきなり新しいツールを持ち込むのはチームから反発も受けそうだったので、Slack上で様子をみたり、ドラフトPRを書いたり、勉強会を開いて徐々に受け入れられる状況を作りました (実際は

                                                                SwiftFormatを導入してコード記法を統一化 - Mirrativ Tech Blog
                                                              • 精進について - kyopro_friends’ diary

                                                                サーバルだよ! 競プロの精進について書くよ。 精進の仕方や、精進に対する考え方はいろいろあるから、あくまで私の意見だと思って読んでね。 ■3行でまとめて ・復習が大事。解けた問題も解けなかった問題も、解説やいろんな子の実装を見てみる ・典型を身につけるのは大事。ABCは解説ACでもいいので解く ・写経はできればしない。一回自分で書いてみてから他の子の実装をパクる ■モチベーションについて レートがついて他の子と競う以上、やっぱりレートが下がると面白くないよね……。 私も最近は下がってこそないけど全然上がらなくて面白くないよ……。 モチベーションが低いときに無理してコンテストに出ても成績は悪くなりがちだから、そういう気分のときはしばらくコンテストに出ないというのももちろんありだよ。 だけど、私には「コンテストに出て悔しい思いをして、解けなかった問題をちゃんと復習する」って方が合ってるから、で

                                                                  精進について - kyopro_friends’ diary
                                                                • GitHub Actionsで"Files changed"のファイルを取得する - kymmt

                                                                  GitHub ActionsでPRの"Files changed"タブと同じファイルの内容を取得する方法*1。 - uses: actions/checkout@v3 with: # マージベースの探索でコミットをさかのぼるために全コミットを取得しておく fetch-depth: 0 - run: | # ... でPRのFiles changedと同じ差分 git diff origin/main...HEAD # ファイル名のリストだけ git diff --name-only origin/main...HEAD # 必要に応じて追加、変更したファイルだけなど git diff --diff-filter=AM origin/main...HEAD やっていることは次と同じ。 # fast-forwardでない可能性があるのでマージベースを見つけておく merge_base_sha=

                                                                    GitHub Actionsで"Files changed"のファイルを取得する - kymmt
                                                                  • GitHub Enterprise Cloudと GitHub Copilot Enterprise に切り替えた

                                                                    GitHub Team と GitHub Copilot Business から切り替えました。切り替えた理由は GitHub Copilot Enterprise を利用したいという一点です。 雑にまとめを書いてみます。 GitHub の金額 (月契約)GitHub Team は 1 アカウント月 4 ドルGitHub Enterprise Cloud は 1 アカウント月 21 ドル約 5 倍のアップです。GitHub Actions の無料枠が 3000 分から 50000 分になるのは良いです。SSO もそのうち使ってみようと思います。 https://github.com/pricing#compare-featureshttps://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-en

                                                                    • 写真から超リアルな3D空間をどうやって復元するか? 「3D Gaussian Splatting」学習の徹底解説 - Qiita

                                                                      写真から超リアルな3D空間をどうやって復元するか? 「3D Gaussian Splatting」学習の徹底解説Python機械学習数学3D最適化 はじめに 前回の「画像生成の記事」で「3D Gaussian Splatting」による画像生成技術について解説しましたが、ご覧になりましたでしょうか。この「3D Gaussian Splatting」は学習済みの3D Gaussianモデルを用いて、任意の視点から実写に近い超リアルな画像を生成できるすごい技術です。画像の高品質だけでなく、明示的な3D表現によって環境を詳細に表現しており、多様な分野での応用が期待され、高い注目を集めています。 ただし、前回の記事では、画像生成の入力となる3D Gaussianをどのように学習するのかについては触れませんでした。これは「3D Gaussian Splatting」技術の中核であり、最も難しい部分で

                                                                        写真から超リアルな3D空間をどうやって復元するか? 「3D Gaussian Splatting」学習の徹底解説 - Qiita
                                                                      • Visual Testingに最適な画像差分検知ツール「Gazo-san」をOSS化しました - LIFULL Creators Blog

                                                                        こんにちは! LIFULLのSETグループ (Software Engineer in Testグループ)のRueyです。 前回はE2Eテストで使うテストフレームワーク「Bucky」を公開しました! www.lifull.blog そして今回はVisual Testingで使う画像差分検知ツール「Gazo-san」を公開しました! github.com この記事はVisual Testingと「Gazo-san」のポイントを紹介したいと思います。 目次 Visual Testingについて なぜVisual Testingが必要か Visual Testingツールの三要素 撮影機能 📷 差分検知機能 🔍 レポート機能 📑 E2Eテストとの違い E2Eテストは動作の保証、Visual Testingは見た目の保証 Visual Testingはメンテナンス不要 LIFULL SETグ

                                                                          Visual Testingに最適な画像差分検知ツール「Gazo-san」をOSS化しました - LIFULL Creators Blog
                                                                        • TypescriptからMicrosoft Graph API使ってSharePointやOneDrive上のExcelの情報を読み込む - YOMON8.NET

                                                                          TypeScriptからSharePointやOneDriveのExcel Onlineの情報を読み込む方法を書きます。 読み込みたいファイル 認証 App Registration Portalへアプリケーション登録 Tokenの取得 TypeScriptからExcelへアクセスしてみる config.json index.ts 実行してみる 参考 読み込みたいファイル 項目 値 ディレクトリ OneDrive上の /otomo ファイル名 sample.xlsx シート名 SampleSheet Cell B4:C4 このファイルの、 ここ読み込みます。 認証 Graph API使うための準備をします。 App Registration Portalへアプリケーション登録 まずはOAuth2で認可設定するために、こちらにアプリケーション登録します。 App Registration P

                                                                            TypescriptからMicrosoft Graph API使ってSharePointやOneDrive上のExcelの情報を読み込む - YOMON8.NET
                                                                          • Docker Compose 1.27.0以降ではdocker-compose.ymlにversionを書く必要がなくなっていた - hogashi.*

                                                                            あらすじ docker-compose.yml でトップレベルの version 要素を指定していると、 WARN[0000] (...)/docker-compose.yml: `version` is obsolete と表示される。インターネットを見ていくと version は指定しなくて良い、消したらいい、という記事がたくさん出てくるし、たしかに公式のドキュメントにも obsolete と書かれている Version and name top-level elements | Docker Docs。 Version top-level element (obsolete) The top-level version property is defined by the Compose Specification for backward compatibility. It is

                                                                              Docker Compose 1.27.0以降ではdocker-compose.ymlにversionを書く必要がなくなっていた - hogashi.*
                                                                            • Nova

                                                                              Robust Git Support. Powerful Workspace Improvements. Professional Font Feature Support. See the full release notes!! A powerful editor. Flexible workflows. Helpful debugging. Useful tools. Robust extensions. And lots of settings. The Editor. It all starts with our first-class text-editor. It's new, hyper-fast, and flexible, with all the features you want: smart autocomplete, multiple cursors, a Mi

                                                                                Nova
                                                                              • 「まるで研ぎ澄まされた日本刀のような美しさ」 僕がそれでもJetBrains製のRuby on Rails IDEを使う理由

                                                                                ソニックガーデンの執行役員兼プログラマーである遠藤大介氏が、JetBrains製のRuby on Rails IDE「RubyMine」の魅力について語りました。全2回。前回の記事はこちら。 Viewにもブレークポイントが張れる 遠藤大介氏(以下、遠藤):これはたまに、驚かれるんだけど。ControllerやModelにブレークポイントが張れるのは、当たり前じゃん。そんなのができなかったら、とりあえずIDEとしてどうよっていう話だから。 なんだけど、RubyMineはぶっ飛んでいて、Viewにもブレークポイントを張れるの。 植木宏氏(以下、植木):Viewに? Viewにブレークポイント? 遠藤:「どういうこと?」って思うじゃん。 植木:(笑)。 遠藤:ERBファイルってあるじゃん。ERBファイルって、「ここまで来た時、どうなってんのかな? なんか表示おかしいんだけど」とか、たまに、ちょっ

                                                                                  「まるで研ぎ澄まされた日本刀のような美しさ」 僕がそれでもJetBrains製のRuby on Rails IDEを使う理由
                                                                                • チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ

                                                                                  こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。 この記事はエムスリーSREがお届けするブログリレーの8日目です。 このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。 私の所属する製薬企業向けプラットフォームチーム(Unit1と呼ばれています)のチームSREの導入タイムラインは、以下のような感じです。 2020年4月に最初のチームSREが入社 2020年7月ごろに私を含む6名がチームSREとして追加 複数サービスのクラウド移行を実施しつつ今に至る したがって、少なくとも私のチームではこの「チームSRE」と

                                                                                    チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ