GAS（Google Apps Script）の使い方 まずは 基本的な GAS（Google Apps Script）の使い方から解説します。GAS の使い方についてすでに知っているという方はこのセクションを飛ばしてください。 GAS（Google Apps Script） とは GAS（Google Apps Script）とは、Google が提供しているプログラミング言語で、Google アカウントとブラウザ（インターネット環境）があれば無料で利用可能です。GAS（ガス）と呼ばれています。Gmail や Google カレンダーなど、Google 関連のサービスを連携、自動化させることができる上に Web API を活用すれば Notion など、Google 以外のサービスとも連携が可能です。 Google Apps Script エディタの開き方 まずは、スプレッドシート（スプ

はじめに 会社員として働く上で評価は最も大きな関心事の1つでしょう。評価によって自身の職位や給料が決まるのでそれも当然です。 しかしながら、「納得感のある評価を受けられていますか？」と問うと明確にYesと答えられる人は稀でしょう。「成果を出したのに正しく評価されていない」と不満を持っていたり「評価は偉い人が勝手に決めるものだから…」と諦めている人もいるのではないでしょうか。少なくとも過去の私はそうでした。 そもそも、評価をどのように受けるべきか指導や研修を受けたことはありますか？私にはその記憶はなく、自身が評価者の立場になって初めて評価というシステムに真剣に向き合うことになりました。 評価の際に被評価者としてできることは、評価者に自分の成果や成長を適切にアピールすることです。そして、アピールの方法として最も確実かつ重要なのは伝わる自己評価を書くことです このエントリは、被評価者が評価者に正

「GitHub Copilot 導入時に考えたセキュリティのあれこれ」というタイトルで登壇したのは、freee株式会社のただただし氏。タイミー社主催の「GitHub Copilotで拓く開発生産性」で、「GitHub Copilot 」を全社一斉導入する際に考えるべきセキュリティリスクについて発表しました。 freee株式会社 PSIRT マネージャーのただただし氏 ただただし氏：freee株式会社のただただしと申します。 今日は、「GitHub Copilot 導入時に考えたセキュリティのあれこれ」ということで、Copilotのセキュリティリスクについて語るわけですが、考えてみたら、GitHubの中の人を前にこんなことをしゃべるのは相当大胆な話だと思います。最後にいいことで締めるのでちょっと我慢してください。 自己紹介をいたします。ただただしと申します。PSIRTという組織でマネージャー

形状認識処理のディレクターを務めている寺田です。昨年10月よりDTダイナミクス（ミスミグループ出資の戦略的IT子会社）のお世話になっています。 私が入社した時点では meviy の形状認識はすべて C++ で書かれていましたが、そこに Rust を導入したというお話です。 Rust で何作ったの？ ゴチャゴチャと御託を並べる前に、まずは Rust で何を作ったのかを簡単に紹介しましょう。 大きく分けて下記の3領域に Rust を導入しました。 溶接リモデル機能 平板展開機能 自動テストツール ここでは先頭の「溶接リモデル」について簡単に紹介します。 この機能の内部実装を C++ から Rust に置き換えて、またロジックも大きく変更することによって、溜まっていた不具合を大幅に解消しました。 溶接リモデルとは 溶接リモデル 上図の左がリモデル前、右がリモデル後です。 板金製品は、平らな板金材

Goのテストについていくつかまとめを書いていた。 Goのtestを理解する in 2018 #go Goのtestを理解する in 2019 触れるのを忘れていたhttptestパッケージについてまとめる。 https://golang.org/pkg/net/http/httptest/ TL;DR net/http/httptestパッケージ https://golang.org/pkg/net/http/httptest/ net/http/httptestパッケージはサーバ/クライアント両方のHTTP周りのテストで使う サーバのHTTPハンドラーのテストを書くとき https://golang.org/pkg/net/http/httptest/#NewRequest https://golang.org/pkg/net/http/httptest/#NewRecorder ダミー

Go で testing/fstest を使うと，ファイルシステムに依存したテストコードを書くときに実際のファイルシステムへの依存度を減らせる．テストコードを書こうとすると，テスト項目（バリエーション）ごとにファイルを用意する必要があるため，ファイルの管理が面倒になることもある．最近使う機会があって簡単にまとめておく📝 pkg.go.dev io/fs interface と testing/fstest.MapFS{} testing/fstest の fstest.MapFS{} を使うと任意のファイルで構成されるファイルシステム（仕組みとしてはインメモリとドキュメントに書いてある）を作れる．そして，ファイルシステムを抽象化した io/fs.FS interface を満たすオブジェクトになっているため，ビジネスロジック側で fs.FS を受け取るように実装しておけば，テストコードで

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯（ヤフー内のスキル任命制度／ネットワーク・セキュリティ）に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書

ITはもう面白くなくなってますね。 技術が面白いときには、いろいろ新しいものが出て性能あがったりできることが増えたりします。調べたらどんどん新しいものが出てくるし、新しいものもたくさん作るし、面白い。ですが、IT技術は一通り出そろって、成熟期に入っています。そうすると新しい技術に出会うことも新しいものを作ることも減っていきます。その結果、いままでの変化のあった状況を知っていれば、つまらんってなりますね。 ※2024/8/24 追記 言いたいことをまとめると、IT素振りのネタ探しに苦労するようになったよねってことです。 結局のところITというのは新しいハードをどう動かして社会に実装していくかというものなので、新しいハードが出ないとどうしようもないのです。けれどもだいたい飽和してしまった。 雑にいえば、これまで1980年くらいにBASIC搭載8bitパソコンが普及するとBASICプログラミング

はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた

こんにちは、じゅんじゅんです。先日、社内の勉強会で JavaScript の DOM について発表を行いました。社内での発表とはいえとても緊張しました（笑）。説明やスライドなど課題がたくさん見つかったので、回数をこなして上達したいと思います。 DOM 操作についての練習問題を作成しているとき、書き間違いから偶然 getElementById で取得をしていないにも関わらず id 属性で要素を参照できてしまうことに気づきました。今回はなぜこのようなことが起こるのかについてお話しします。 実際のコード 実際のコードがこちらです。 <div id="element"></div> <script> element.textContent = 'こんにちは、じゅんじゅんです'; </script> これだけでしっかり「こんにちは、じゅんじゅんです」というテキストが表示されます。 getElemen

CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R

最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

スタートアップブームの「終わりの始まり」は、VC のファンドサイズが小さくなり始めることだと考えています。それを契機に悪循環が始まるからです。 理屈はこうです。 ファンドサイズが小さくなると、スタートアップが調達できる資金も小さくなります。そうすると、大きな挑戦ができなくなり、大きな事業や成果も出づらくなります。するとさらにファンドサイズも投資も減って、スタートアップが挑戦できる事業の規模感も小さくなり、小さな事業しか目指せなくなります。 こうした悪循環が起こり始めると、エコシステムは縮小均衡へと向かっていくことになるでしょう。 今、日本のスタートアップエコシステムは、そうした悪循環に入る瀬戸際の場所にいるように思います。 そうした危機感を共有したく本記事を書いています。 リターンが返せる見込みが薄くなってきた 毎年 1.8 兆円のリターンが必要 現状は総リターンが 1 兆円に達していない

はじめに 様々な曲の楽譜をデータとして扱えたら楽しそうだと思いませんか？ かといって手動で入力するのも大変です。どこかでダウンロードできると嬉しい… 調べてみたところ、クラシック音楽の楽譜データの多くがCC Zeroライセンスで公開されていることが分かりました。この記事では、 好きな曲の楽譜データを検索・ダウンロードする方法 楽譜データのファイル形式・解析方法 Pythonを使って楽譜データをプログラム中の配列として取り込む方法 取り込んだ楽譜データをグラフで可視化する方法 を紹介しています。 目次 はじめに MusicXMLファイルのダウンロード MusicXMLファイルの展開 拡張子を.mxlから.zipに変更 解凍 確認 MusicXMLの内容 どこが重要か パートリスト パート 1. <measure number="1" width="***">：小節 2. <attribute

多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん

プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命