みなさんはHomebrewをお使いでしょうか。macOSをお使いの多くの開発者が使っていると思います。 HomebrewのインストーラーはRubyで書かれており、次のコマンドでインストールするようになっていました。 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" HomebrewがRubyに依存していることは良いのですが (formulaの書きやすさはRubyならでは)、インストーラーの話になると事情が変わってきます。HomebrewのインストールコマンドはmacOSの工場出荷状態でも動く必要があります。こういうものにRubyを使っているのはリスクがあります。 将来的にmacOSデフォルトにRubyやPythonが含まれなくなる (参考リンク
先日、メインの開発環境を MacOS から Windows 10 Professional へと移しました。理由としては主に2点で、現在仕事を自宅の固定席で行っており PC を持ち運びする必要がなくなったため Mac より高速で安価な Windows デスクトップ機を使いたいこと(Ryzen 9使いたい!)、WSL2 が正式版となり使ってみた感じ問題なく WSL2 で仕事の開発ができそうだったことが挙げられます。 WSL2 はふつうに Linux なので問題なく開発環境の構築が行なえ、Windows からも VSCode Remote のおかげでで違和感なくWSL2上のコードを編集、実行ができ快適な開発が行えています。(なお、WSL2 についての記事は山程溢れているので、ここでは殆ど触れません。) しかしながら、WSL2 ではないふつうの Windows 上で開発する機会が出てきたので、M
Windowsで開発環境を整えた。 背景 開発環境を改善しようと思い、PCデスクの見直しなどをやっていたら、Windowsでも開発できるようにしようと思い至った。新しい環境を試してみたい気持ちが1割と、新しいゲーミングPCを組みたい気持ちが9割だ。 エディション Windows 10 Homeエディションを利用している。 Windows 10 ProにはHyper-Vという仮想化機能を直接利用できる利点があるが、WSL2で同じようなことをより便利に実現できるようになったおかげで、この点においてPro版の必要性は薄れてきている。今のところ自分のやりたいことはWindows 10 Homeですべて実現できている。 Windows Update WSL2を使うために、Windowsをバージョン2004・ビルド19041に更新した。 日々の自動更新ではバージョン1903で止まっていて、まだ自動では
オンラインイベント「Microsoft Build 2020」を開催中のマイクロソフトは、コマンドラインから利用するWindows用パッケージマネージャ「Windows Package Manager」のプレビューリリースを発表しました。 Windows Terminalのコマンドラインから「winget install」と入力、実行するだけで、アプリケーションがWindows 10にインストールされます。 例えば「winget install powertoys」と入力すればpowertoysが、「winget install vscode」と入力すればVisual Studio Codeがインストールされる、という具合です。 インストールはあらかじめ用意されたmanifestファイルに従って行われます。 Windows Package ManagerはGitHub上でオープンソースとし
追記: 2022年1月11日 2:29 JSTにDoS脆弱性としてセキュリティアドバイザーが出されて、悪意あるバージョン(1.4.1や1.4.2)はnpmからunpublishされ、npmの最新は安全なバージョンである1.4.0へと変更されました。 Infinite loop causing Denial of Service in colors · GHSA-5rqg-jm4f-cqx7 · GitHub Advisory Database 2022-01-08 に colors というnpmパッケージにDoS攻撃のコードが含まれたバージョンが1.4.44-liberty-2として公開されました。 GitHub: https://github.com/Marak/colors.js npm: https://www.npmjs.com/package/colors 問題についてのIssu
christine.websiteのブログより。 または: お金を払わない限り、有用なソフトウェアを書かないのか? 最近、重要なJavaエコシステム・パッケージに大きな脆弱性が見つかりました。この脆弱性が完全に兵器化されると、攻撃者はLDAPサーバから取得した任意のコードを実行するよう、Javaサーバを強制することができます。 <マラ> もしこれがニュースで、あなたがJavaショップで働いているなら、残念ですが、あなたには2、3日が待っています。 私は、これが「オープンソース」ソフトウェアの主要なエコシステム問題の全ての完璧な縮図だと考えています。log4j2が、この問題の最悪のシナリオの1つの完璧な例であると思うので、このすべてについていくつか考えを持っています。この問題に関与したすべての人が、現実世界の問題に対する完全に妥当な解決策のためにこれらすべてを行ったことは完全に合理的であり、
アメリカ合衆国のとある政府機関への抗議のため、Chef関連のGemやGitHub上のソースコードを作者が削除した。 雇用期間に業務にてGemが作成されていたため、Chef SoftwareがGemの所有権を主張してGemを復活させた。 最終的には抗議行動に対してChef Softwareが折れることで決着が付いた。 現在Chef界隈が混乱している。 どうやら政治的問題のためにRuby Gemsに登録されたGemやGitHub上のソースコードが消されたらしい。 なかなか興味深い出来事で、なおかつ日本語圏に情報が出ていないので適当に記録しておく。 用語 Ruby:プログラミング言語の1種。日本においては超広範囲で使用されている超メジャーな言語。 RubyGems:Rubyにおけるパッケージシステム。他人のRubyプログラムやライブラリを簡単に取り込むことができる。 Chef: 構成管理ツールの
(結論はなく、ダラダラ昔話を書いただけ。) サービスやプロダクトの開発にあたって、自社外で開発されたオープンソースソフトウェア(OSS)を外部コンポーネントとして使うという場面は今や当たり前だと思うけど、そのOSSができるだけ長く保守開発を続けてくれるにはどうしたらよいか、ということまで考えることは少ないだろう。 OSSはそのライセンス遵守の上では金銭を支払うことなく自由にサービスやプロダクトに使えるし、うまく機能がハマれば開発の費用・時間コストを大幅に軽減できる。 ただ、そうしてできた素晴しいサービス、プロダクトのアーキテクチャを見返してみると、個人の手弁当のOSSが危ういバランスを支えてSPOF的に存在していることがある。ジェンガの絵がよく出てくるよね( File:dependency.png - explain xkcd )。 Someday ImageMagick will fin
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている 4月10日でサービス開始からちょうど15周年を迎えたGitHubは、当初からRuby on Railsを用いたモノリシックなアプリケーションとして作られてきました。現在では200万行近い規模のコードになっているそうです。 今年1月にはGtHubを利用しているデベロッパーが1億人に到達したことも発表しました。GitHubはまさに世界最大級のRailsアプリケーションだと言っていいでしょう。 そのGitHubは5年前の2018年、Railsのバージョンを3.2から5.2に上げる作業に1年半を費やし。そして二度とこのようなことにならないよう、より頻繁にアップデートを行うべき、などの教訓を得たとしていました。 そして現在、GitHubは毎週月曜日にRailsのアップデート作業
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ギットハブ・ジャパン(GitHub)は4月7日、クラウド上のリポジトリーからソフトウェアを構成するコンポーネントやライブラリーなどの状況を開発者が容易に把握、管理できる「ソフトウェア部品表」(SBOM)の作成機能「Export SBOM」を発表した。GitHubの全てのクラウドリポジトリーで無償利用できる。 SBOMは、企業や組織などで使われるソフトウェアの脆弱(ぜいじゃく)性を悪用したサイバー攻撃が深刻な被害をもたらしていることを踏まえて、2021年5月にJoe Biden米大統領が署名したサイバーセキュリティ対策の強化を目指す大統領令に盛り込まれた。同令では、ソフトウェア開発組織に対し、ソフトウェア製品を構成するコンポーネントやライ
はじめに 画像は記事に全く関係ないカニのフィギュアです👋 近年、善良なパッケージを騙ったマルウェアが配布されているケースが増えてきています。 これらのマルウェアはパッケージマネージャ上で配布され、開発者端末やそれをビルトインしたシステムを利用するユーザー端末で悪事を働きます。 これは俗にいうサプライチェーン型攻撃で、 これらの関連ニュースを目にする機会が増えてきていることを、多くの開発者が体感されていると思います。 ただ、これらのサプライチェーン型攻撃の記事は、 どうしてもエンドユーザー(パッケージを利用する開発者側・それらを組み込んだアプリを実行するユーザー側)の対策に焦点が当てられたものが殆どのように感じています。 そこで本記事では、このエンドユーザー側の対策だけではなく、 パッケージマネージャメンテナーたちがどう対策しているのかも含めて、 「パッケージマネージャ上で行われるマルウェ
追記: 2023-11-19 corepack v0.20.0 にて、CLI のコマンド体系が一新されて多少わかりやすくなりました (PR#291)。新しいコマンドは README を参照。 追記: 2022-02-03 Node.js v14.19.0 に corepack が標準バンドルされました。 corepack がバンドルされていない Node.js v12 系は 2022-04-30 に EOL を迎えるので、あと 3 ヶ月もすればアクティブな Node.js 環境には必ず corepack が揃っているという状態になりますね。引き続き experimental ステータスのままではありますが。 追記: 2021-09-08 Node.js v16.9.0 で corepack が標準バンドルされました。まだ experimental 扱いですが。 デフォルトでは yarn も
2024年1月8日、GitHubはこれまでGitHub/Microsoftの従業員とパートナーのみが利用可能であったGitHub Certifications(資格認定)プログラムを、世界中のすべての顧客も利用可能とすることを発表した。1月8日から誰でも登録サイトにアクセスしてGitHub Certificationsの学習と認定試験の準備を進めることができる。 GitHub Certifications are generally available -The GitHub Blog 利用可能な認定プログラムは以下の4種。 GitHub Foundations Certification GitHubプラットフォームの基本的な概念とGitHub製品を初めて学ぶ人向け。gitの使用方法からリポジトリ管理、コミット、ブランチ、マージ、プロジェクト管理などのGitHubコア機能をひと通り学習で
EDIT: このブログと似た内容の話をPyCon APAC2023にてお話ししました。 こちらの登壇資料も合わせてご覧いただけると幸いです こんにちはWantedlyの樋口です。 Pythonのパッケージングと配布は歴史が長く、多くのツール(ex. conda, pip, pipenv, poetry, rye...)が開発されてきました。これらの多様性はPythonが多くの人に使われ、継続的に改善されたゆえの賜物ですが、同時にこれらの理解を難しくしている要因にもなっていると感じます。 そこで本記事では、Pythonのパッケージングと配布の全体像を紹介します。パッケージングと配布が何か、なぜ重要なのか、そしてそれぞれのツールが何を解決しようとしているのかについて説明します。以下のような疑問を解決できることを想定しています。 パッケージングと配布の仕組みがなぜあるのか 多数あるツールが何を解
もう5年以上続けている取り組みのひとつにデスクトップ環境をdisposableに保つというのがある。いつでも何があっても即座に環境を捨てて作り直せるようにするということ。EC2やVPSのインスタンスに対してAnsibleでプロビジョニングできる状態にしておけば即座に新しいホストを立てて古いホストを捨てられる、そんな状態を目指すということ。具体的には以下のようなことを心がけている。 書類のマスターデータを端末上に置かない デスクトップ環境をdisposableに保つ第一歩は、とにかく手元になんらかのデータのマスターを置かないことにつきる。端末上にマスターデータを置いていると当然新しい環境を用意する際にデータ移行が必要になる。移行をしないためにはこれらを手元に置かないようにする。書類はGoogle DriveやNASに入れる、ソースコードは全てGitHubに上げておく、などなど。現代では機密情
はじめに 今年の 8 月にリリースが予定されている Go 1.13 では、Go 1.11 で導入された Go modules に加え、Go module proxy といった新しいエコシステムが登場します。 そこで、そもそも Go modules は何を行っているのかや、何ができるのか、どういった要素で構成されているのかを紹介します。 また、古い Go バージョンから Go 1.13 へアップデートする場合や、 dep や Glide といったベンダリングツールから Go modules へ移行する際の懸念点も併せて紹介します。 先日発表した "Go Modules and Proxy Walkthrough" はこのポストがベースになっています。 TL;DR な人はスライドを見るのがおすすめです。 speakerdeck.com Go Modules Go modules という仕組みは
週に一度まとめて更新のようなパターンだと、体調が悪いときなどにその週はスキップされ、また次の週も更新しようとして偶然タイミングが合わなかった場合などに、1ヶ月更新が止まるみたいな状態は起きやすいです。 1ヶ月更新を止めてしまうと、そこで更新する習慣が失われて、この書籍でいう逆戻りが起きるのかなと思っています。 そのため、JSer.infoではタスクを細分化して進められる時にやっていけるような形を作っています。 ライブラリのメンテナンスのリズムをツール化する JavaScript周りは顕著ですが、ライブラリが細かく分かれていることが多いため、リポジトリの数も多いです。 そのため、リポジトリのCI設定や依存ライブラリのアップデートなどをメンテナンスするだけで無限の時間がかかります。 このメンテナンス作業を手動で毎回やるととても疲れるので、自分の場合はツール化していることが多いです。 作ったり、
うりうりさんの↓のコメントを見て、そういえばnpm ciって見たことあるけどチェックしてないなぁ。というかnpm installも雰囲気で使ってるなぁ。と思ったので、うりうりさんに教えてもらったことを手がかりに、npm installとnpm ciについて調べた。 これ、node_modulesキャッシュしてたり npm install使ってるけど npmのグローバルキャッシュ(~/.npm)をキャッシュした上で npm ciで早くなったりしないんだろうか GitHub Actions上でテストを約3倍早くした話https://t.co/MpmFktGBxU— wreulicke (@wreulicke) March 14, 2023 ちょこっと検索して見てみたところ、新旧情報があって自分が混乱したのと、公式ドキュメントには概要は書かれているものの詳しい内容は書かれていないので(僕が見つけ
近年のソフトウェア開発では、RenovateやDependabotといった依存関係更新のためのツールが普及していて、ツールの支援を借りながら依存ライブラリを更新していく開発フローが広まってきている。 これらのツールは、package.jsonで管理されているライブラリだったり、Dockerfileで指定しているイメージだったりを自動的に最新版に更新してPull Requestを出してくれるので、人間は内容を確認してマージボタンを押すか、変なところがあったら手直ししてからマージしていくだけでよい。 はてなでの開発フローでも使い倒していて、先月くらいにも、社内で共有して使ってる設定を公開したりしていた。今ではRenovateのない暮らしに戻ることは考えられないくらいに広まっている。 developer.hatenastaff.com 普段、仕事ではPerlやTypeScriptを書いていて、T
こんにちは@watildeです。趣味でnpmへのコミットをたまにしているのですが、最近はNode.js側に比重を置いているのでv7のキャッチアップに少し遅れてしまいました。キャッチアップついでに自分なりに情報をまとめたので、v7における代表的な新機能と破壊的変更について、GitHubの記事よりも少し詳しめに紹介と解説を行ってみます。なるべく参考リンクを付けているので、詳細が気になった際はリンクから一次情報に飛んで読んでみてください。 また、情報に誤りがあった場合はTwitterにて教えていただけると助かります。 背景 npmチームより、2020/10/13にnpmの新しいメジャーアップデートであるところのv7の公式リリースが発表されました。8月からbeta版のリリースを繰り返していましたが、2ヶ月かけて内部的なリファクタリングとスモークテストを繰り返して今回の発表に至ったのかと思います。ま
それっぽいタイトルを付けましたが特に意味はないです。 workspace を使ったコマンドを最適化して実行する Turborepo についてのお話で Turborepo を軽く触ってみた際にnpx create-turbo@latestで作られる構成がとてもわかりやすく、プロダクトの初期段階からモノレポを採用するのは選択肢の 1 つとしていいのでは、と思い続編を書きました。 前回と同じくサンプルのリポジトリはこちらになります。 https://github.com/nus3/p-turborepo/tree/main/yarn 概要 モノレポを採用することで、同一リポジトリ内で自作した汎用的なライブラリやコンポーネントを複数のアプリケーションで使いまわせる モノレポの規模が大きくなってきた場合には、モノレポ内のパッケージを npm に公開することでアプリケーションとパッケージを非同期に開発
名前が1文字の「-」という謎めいたnpmパッケージは、2020年にレジストリで公開されて以来、70万回以上ダウンロードされています。 さらに、このパッケージには有効なコードが含まれていません。では、一体なぜこれほど多くダウンロードされているのでしょうか? npmパッケージ「-」の中身 「-」というnpmパッケージは、2020年初めにnpmレジストリで公開されてから、約72万回もダウンロードされてきました。 パッケージのバージョンは0.0.1のみで、ファイルは3つです。 tar tvf 0.0.1/--0.0.1.tgz package/dist/index.js package/package.json package/README.md これらのファイルは主にマニフェスト(package.json)とindex.jsで、特に面白い点はなく、スケルトンコードが書かれているだけです。 マニフ
(Last Update: 2022/02/03) npm と yarn(v1) と pnpm (とyarn v2)の違いについて記述します。 Versions npm Yarn pnpm 各パッケージの特徴 npm npmはnpm社が提供する、JavaScriptパッケージマネージャーです。 npmというコマンドラインで動作するプログラムでパッケージを管理できます。いわばnpm公式のパッケージマネージャーとなります。 Windows等でインストールするとNode.jsに同梱されています。 Yarn Yarnはnpmより後発のJavaScriptパッケージマネージャーです。 元々、npmにはインストール時のパッケージバージョンの非再現性やパフォーマンス上の問題、セキュリティの問題が山積しており、それを解決するために開発がスタートしました。 いわば、サードパーティのnpmということになります
Docker Hubは、Dockerコンテナのリポジトリとして最も有名かつ活発に使われているサービスの1つです。 おそらく多くのユーザーがDocker Hubに登録されたDockerコンテナのイメージを利用するなど、そのお世話になったことがあるでしょう。 そのDocker Hubにおけるコンテナイメージの保管について「Container Image Retention Policy」として規約が変更されたことが話題になっています。 Docker update ToS: Image retention limits imposed on free accounts | Hacker News Docker Hub の新しいコンテナ・イメージ保管ポリシー(参考訳) - Qiita これまでDocker Hubに保存されたコンテナイメージは期限なく保存され続けていましたが、今後はFreeプランの
シャットダウンが延期されました 読み取り専用として存続します JCenter のシャットダウンについては2022年2月1日へ延期になりました。 https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ UPDATE: To better support the community in this migration, JFrog has extended the JCenter new package versions submission deadline through March 31st 2021. To clarify, the JCenter repository will keep serving packages for 12 months until February
こんにちは、フロントエンドエキスパートチームの小林(@koba04)です。 本記事では、Lerna と Yarn Workspaces を使った Monorepo 管理について解説します。 Monorepoとは 本記事では、単一のリポジトリで複数のモジュールやパッケージ(今回の場合は npm パッケージ)を管理する手法を Monorepo と呼んでいます。 有名なところだと、Babel や Jest、Create React App などが後述する Lerna を使い複数パッケージを単一のリポジトリで管理しています。 他にも React も Lerna は使っていませんが単一リポジトリで複数パッケージを管理しています。 また、上記のようなライブラリ以外にも企業で利用している npm パッケージを Monorepo として管理している例もあります。下記は Shopify の例です。 pack
Amazon Web Services(AWS)は、ソフトウェアパッケージなどのリポジトリをマネージドサービスとして提供する「AWS CodeArtifact」の正式リリースを発表しました。 アーティファクト(Artifact)とはここ数年、ソフトウェアの分野でよく目にするようになった言葉の1つでしょう。一般的には「人工物」や「工芸品」という意味ですが、ソフトウェアの分野ではなんらかの生成物、例えばソースコードのコンパイルやビルドによって生成されたバイナリやパッケージなどのことを指して「アーティファクト」と呼びます。 そして、ソースコードがGitHubのようなソースコードリポジトリに格納されることで、バージョン管理や共有などが行われるように、さまざまなアーティファクトもリポジトリに格納されて管理共有されるようになってきています。 例えばJavaScriptのパッケージマネージャnpmに対応
N予備校iOSアプリ開発チームのyoppieです。 筆者のN予備校での経歴は Androidアプリ開発チーム 2021年4月 - 2022年3月 iOSアプリ開発チーム 2022年4月 - 現在 です。iOSアプリ開発にチャレンジしたくなり、Androidアプリ開発からiOSアプリ開発に移りましたが、iOSアプリ開発とAndroidアプリ開発(以下I/A)でのさまざまな違いがあり、苦労しました。(iOSアプリ開発チームに移り10ヶ月経ちますが、今も苦労しています...) I/Aでのさまざまな違いがありますが、この記事では筆者が特に違いを感じた点をまとめています。 I/Aどちらかのエンジニアの方がもう一方に移りたて、もしくは移ろうか迷っている方に向けた記事となっています。 IDEに関連した各種バージョン 一般的にXcodeでiOSアプリ開発を行い、Android StudioでAndroid
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く