CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
Channelスタイルの並行処理の記述を(もちろん型安全に)可能にするライブラリOxについて調べて試してみた。結論から言うと書き味がめちゃくちゃ良くて面白い。 ソースコードも置いておく。 github.com Ox Oxとは、sttpなどの開発でお馴染のSoftwareMillによって開発されているScala用の非同期ライブラリである。まだ非常に若く、活発に開発されている。 github.com Oxの特徴は、というか目的といっても差し支えないのだが、それはChannel指向の非同期処理、つまりGoroutineをScalaの上で実現している点だ。Goユーザならすぐに理解できるだろう。 百聞は一見に如かず。こんな感じのコードを書くことができる(v0.0.25時点)。 import ox.* import ox.channels.* import scala.concurrent.durat
おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン
この記事はKeployのバージョンv2.0.0-alpha53 を前提に執筆しております。 Keployとは KeployはeBPFを利用して取得できるWebアプリケーションの通信に関するトレース情報を元に、テストとそのテストの実行時に利用するスタブサーバーを生成することができるツールとなります。 公式サイトのトップには以下のようなスローガンが掲げられています。 2 minutes to 90% test coverage! テストに苦労した経験のある方は興味を惹かれるのではないでしょうか。 現在まだアルファ段階のプロジェクトですが、GitHubスター数は2683(2024/01/04現在)、CNCF Landscape にも掲載されているなど、一定の注目を集め始めているOSSです。 開発主体はプロダクトと同名のKeployというインド発のスタートアップで、去年GoogleによるインドのA
追記と修正 2024/01/09: FOR710 についてはプロ視点で賛否両論あったので表現を変えました 2024/01/09: FLARE-VM の構築部分でも書きましたが、解析環境と普段生活する環境は分離しましょう。VMWare or VirtualBox を使ってください。普段使いの環境にここで述べた解析ツールをいきなりインストールするとAnti-Virusに検知される可能性もあります。 TL;DR 将来的にベンダーレポートやカンファレンス発表レベルでの"マルウェア解析"を想定した話です とりあえず FLARE-VM 環境を作ってインストールされたツールを見る・触るところから始めるといいんじゃないでしょうか TL;DR はじめに "マルウェア解析" のスコープと前提知識の明確化 ツールの選択元(プール) : FLARE-VM FLARE-VM に入っている中でもよく使うツール PES
はじめまして。リノベーションデザイナーをしているフジイです。 妻の「狭くてもいいので防音室が欲しい」という一言がきっかけで、約1週間かけて自宅の賃貸マンションに防音室をDIYしました。仕組みさえ分かれば、DIY初心者の方でも比較的簡単に、既製品の約5分の1の予算で製作できるので、時間と根性さえあればとてもコスパのいいDIYです。 「防音室」と言ってしまえばニッチですが、「お隣との防音壁」や「お篭もり用の小さなブース」としても汎用的に使えるアイデアです。 自宅に録音ブースが欲しい人はもちろん、自宅で仕事や作業をする人やビデオミーティングが多い人、お篭もりスペースが欲しい人の一助になればうれしいです。 防音ブースをDIYするキッカケ 2017年に結婚した妻と都内のマンションで生活をしていました。僕はフリーのリノベーション・住宅デザイナー、妻はソロのシンガーでナレーションなどの声を使った仕事を生
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計(DDD)では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
Scala 3におけるデータ指向プログラミング(以下DOP)について深掘りする。久々にScalaの話題を取り上げるが、これはScala Advent Calendar 2023の14日目の内容でもある。 早速だけど、DOPの基本原則は意外とシンプルだ。 コード(動作)をデータから切り離す データを汎用的なデータ構造で表現する データをイミュータブル(不変)として扱う データスキーマをデータ表現から切り離す イミュータブルなデータは採用することは多いと思うが、これをそのまま実践している人はどのくらいいるだろうか。Scalaではクラス中心の関数型プログラミングが主流だと思うし、私もそうしている。 DOPの詳細は下記の本(以下DOP本)を参照してほしい。 データ指向プログラミング 作者:Yehonathan Sharvit翔泳社Amazon ちなみに留意すべき点がある。DOP本とJavaのPro
作業机の配線の記録をまとめておきます。 現在の様子 2020 2020年は牧歌的な時代で、子供の頃から使っていた机の上に、必要な機器を乱雑に並べていました。当時はゲームの録画や配信をはじめた頃だったので、それ以前と比べると、キャプチャーボードやオーディオインターフェースが増えていっていました。 乱雑に積まれた機器達 2021 2021年には作業机を買い替えたり、はじめて自作PCを組んだりしました。この辺りでようやく、配線に真面目に向き合い始めました。この年には、天板下にクランプで取り付けられる、サンワサプライのケーブルトレーを導入しました。 電源ケーブルはカーペット下を通している あらゆる機器が詰め込まれたケーブルトレー 電源タップはマグネットシートで設置 PC裏にはゲーム機 2022 引越しを済ませ、生活が落ち着いてきた頃合いで、半年間、朝6時から12時まで毎日作業配信をやってみました。
また、Rust ではResult で失敗する関数や Option で None になる処理に ? をつけることで処理を short-circuit して抜け出せる. これは TypeScript や Kotlin の optional chaining を Result 型にも拡張したものとしてみることができる. Rust: Result の short-circuit pub fn f() -> Result<i32,String> { let str = may_fail_with_string()?; let i = str.parse::<i32>().map_err(|_| "error message".to_string())?; Ok(i) } fn may_fail_with_string() -> Result<String,String> { todo!() }
カケハシでVP of Engineeringをやっています、ゆのん(id:yunon_phys)です。僕はEngineering Manager(EM)とは何かについて、かれこれ5年ぐらいEM.FMというPodcastや、ブログを通じていろんな発信をしてきました。そうすると色んな質問を各所から受けるわけなんですが、一番聞かれる質問第一位は、「結局EMって何する人なんですか?」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。 マネージャーの本質はチームの足りてない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く