4.0.0 — Homebrew
Today, I’d like to announce Homebrew 4.0.0. The most significant change since 3.6.0 enables significantly faster Homebrew-maintained tap updates by migrating from Git-cloned taps to JSON downloads. Major changes and deprecations since 3.6.0: Using JSON files downloaded from formulae.brew.sh for package installation rather than local homebrew/core and homebrew/cask taps. Please note: this is the la
フロントエンドのモノレポ構成はスケーリングの夢を見るか | サイボウズ フロントエンドエキスパートチーム
それっぽいタイトルを付けましたが特に意味はないです。 workspace を使ったコマンドを最適化して実行する Turborepo についてのお話で Turborepo を軽く触ってみた際にnpx create-turbo@latestで作られる構成がとてもわかりやすく、プロダクトの初期段階からモノレポを採用するのは選択肢の 1 つとしていいのでは、と思い続編を書きました。 前回と同じくサンプルのリポジトリはこちらになります。 https://github.com/nus3/p-turborepo/tree/main/yarn 概要 モノレポを採用することで、同一リポジトリ内で自作した汎用的なライブラリやコンポーネントを複数のアプリケーションで使いまわせる モノレポの規模が大きくなってきた場合には、モノレポ内のパッケージを npm に公開することでアプリケーションとパッケージを非同期に開発
MacOS ユーザが WSL では無い Windows のコンソール環境を整える - 2nd life (移転しました)
先日、メインの開発環境を MacOS から Windows 10 Professional へと移しました。理由としては主に2点で、現在仕事を自宅の固定席で行っており PC を持ち運びする必要がなくなったため Mac より高速で安価な Windows デスクトップ機を使いたいこと(Ryzen 9使いたい!)、WSL2 が正式版となり使ってみた感じ問題なく WSL2 で仕事の開発ができそうだったことが挙げられます。 WSL2 はふつうに Linux なので問題なく開発環境の構築が行なえ、Windows からも VSCode Remote のおかげでで違和感なくWSL2上のコードを編集、実行ができ快適な開発が行えています。(なお、WSL2 についての記事は山程溢れているので、ここでは殆ど触れません。) しかしながら、WSL2 ではないふつうの Windows 上で開発する機会が出てきたので、M
Perlの依存モジュールのアップデートを自動化するためのCLIツールを作った。GitHub Actions上で動かしてPull Requestも送れる - hitode909の日記
近年のソフトウェア開発では、RenovateやDependabotといった依存関係更新のためのツールが普及していて、ツールの支援を借りながら依存ライブラリを更新していく開発フローが広まってきている。 これらのツールは、package.jsonで管理されているライブラリだったり、Dockerfileで指定しているイメージだったりを自動的に最新版に更新してPull Requestを出してくれるので、人間は内容を確認してマージボタンを押すか、変なところがあったら手直ししてからマージしていくだけでよい。 はてなでの開発フローでも使い倒していて、先月くらいにも、社内で共有して使ってる設定を公開したりしていた。今ではRenovateのない暮らしに戻ることは考えられないくらいに広まっている。 developer.hatenastaff.com 普段、仕事ではPerlやTypeScriptを書いていて、T
LernaとYarn WorkspacesでMonorepo管理 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの小林（@koba04）です。 本記事では、Lerna と Yarn Workspaces を使った Monorepo 管理について解説します。 Monorepoとは 本記事では、単一のリポジトリで複数のモジュールやパッケージ（今回の場合は npm パッケージ）を管理する手法を Monorepo と呼んでいます。 有名なところだと、Babel や Jest、Create React App などが後述する Lerna を使い複数パッケージを単一のリポジトリで管理しています。 他にも React も Lerna は使っていませんが単一リポジトリで複数パッケージを管理しています。 また、上記のようなライブラリ以外にも企業で利用している npm パッケージを Monorepo として管理している例もあります。下記は Shopify の例です。 pack
XcodeGenによる新時代のiOSプロジェクト管理 - クックパッド開発者ブログ
こんにちは。モバイル基盤部の@giginetです。平成最後のエントリを担当させていただきます。 iOSアプリの開発では、Xcodeが生成するプロジェクトファイルである、*.xcodeprojをリポジトリで共有するのが一般的です。 しかし、この運用は大規模なプロジェクトになるほど、数多くの課題が発生します。 クックパッドiOSアプリは巨大なプロジェクトであり、通常の*.xcodeprojによる管理には限界が生じていました。 そこで、昨年秋にXcodeGenというユーティリティを導入し、プロジェクト管理を改善したので、その知見をお伝えします。 従来のプロジェクト管理の問題点 ファイル追加の度にコンフリクトが発生する *.xcodeprojファイルはプロジェクトに含まれるソースファイルの管理を行っています。 開発者がプロジェクトにファイルを追加すると、このプロジェクトファイルが更新されることにな
CocoaPods・Carthageでインストールした成果物はバージョン管理に含めるべきか？ - Qiita
以下のTwitterアンケートを見かけたので、記事書いてみました。 結果は、母数が10人なので参考程度にするのが良いと思いますが、僕も多数派の「CocoaPodsもCarthageも含めている」を特に迷い無く選択しています僕は今ではCocoaPodsもCarthageも含めていない運用にしています。 【iOSアプリプログラマに質問】 あなたはアプリのリポジトリにCocoaPodsで取得したソースコードやCarthageでビルドしたフレームワークを含めていますか？ — りず (r.izumita) (@rizumita) October 6, 2016 ちょうどCocoaPodsのガイドにこのことが記載されているので、まずはその訳を載せます。 (この記載はわりと有名なはずで、ここでオススメされているからバージョン管理に含める選択を取っている人も多そう。) CocoaPodsのガイドの訳 原文
モノリシックなバージョン管理の利点 | POSTD
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
wheelのありがたさとAnacondaへの要望 - YAMAGUCHI::weblog
はじめに こんにちは、Python界のラファエル・ナダルです。全豪オープンテニス、盛り上がりましたね。さて、先日次のようなエントリーを立て続けに書いたんですが、「なぜAnacondaに関しての記述がないのか」という突っ込みをもらったので、参照用にメモを残しておきます。 Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01 - YAMAGUCHI::weblog なおこの記事の作成にあたっては @aodag に数多くのアドバイスをいただきました。この場を借りて感謝。 TL;DR condaの開発者はPyPAともっとコミュニケーションとってほしい。 前提 この記事はPythonを触り始めたばかりだけど、パッケージ管理ツール等々のスタンダードがどのようになっているかな
Windows 10の開発環境を整えた - YAMAGUCHI::weblog
はじめに こんにちは、大正デモクラシーです。年末年始に実家に帰るにあたって、Windows 10がインストールされているXPS 13を持って行ったんですが、実家で庭木の剪定以外にやることがなかったので、それ以外の時間はずっとコード書いてました。しかし、持って行ったマシンの開発環境がまったく整ってなかったのでいろいろ設定しなおしてとりあえずいい感じになったので、その作業メモを書いておきます。 TL;DR これまでLinuxやmacOSで育ててきた環境をWindows 10で使うことはあきらめて、これらのツールをとりあえず入れました。 cmder | Console Emulator Chocolatey - The package manager for Windows GitHub - Microsoft/Git-Credential-Manager-for-Windows: Secure
Glide で Go 言語のパッケージ管理と vendoring - Librabuch
Go 言語の vendoring ツールとして Glide を使い始めました。 Masterminds/glide: Package Management for Golang vendoring とは vendoring とは、アプリケーションが依存する 3rd-Party パッケージ/ライブラリのソースコードそのものを自身のレポジトリに含めて管理する試みのこと、を指す用語の模様です（たぶん）。 Node.js における package.json に依存関係が書かれている状態だけでは vendoring ではないです。node_modules ディレクトリ自体をレポジトリの管理対象に含めることで vendoring ができている状態、と言えるようになります。 Node.js (というか npm) に限らず、node_modules 的な役割のディレクトリは .gitignore で無視す
Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5
Go言語のDependency/Vendoringは長く批判の的になってきた（cf. “0x74696d | go get considered harmful”, HN）．Go1.5からは実験的にVendoringの機能が入り，サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している．なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる． Dependencyの問題 最初にGo言語におけるDependecy（依存解決）の問題についてまとめる．Go言語のDependencyで問題なのはビルドの再現性が保証できないこと．この原因はimport文にある． Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する．このimport文は2通りの
Ruthlessly Simple Dependency Management with Carthage
About the content This content has been published here with the express permission of the author. Carthage is a new dependency manager for Objective-C and Swift projects, intended to be the simplest way to add frameworks to a Cocoa application. Carthage works by delegating tasks to Xcode and Git, minimizing new concepts as much as possible, so you can continue to use the tools you’re already famil
[D] Windowsはターミナルがダメだから使えないってのは過去の話?
気づいたら自宅でもオフィスでもすっかりWindowsユーザーになっちゃって、Win10情報にも一喜一憂してるという、完璧なる転びマカーぶりを発揮してるドリキンです。 基本的にWinである不便もほとんどなくなってしまった（というかむしろ快適に感じる）今日この頃なんですが、唯一にして最大とも言えるWindowsの弱点はいうまでもなくまともなターミナルコンソールがないことですよね? とはいえ、最近はコンソールではNodeJSだけが動けばいいやという状態だったので、コマンドプロンプトでごまかしたりはしてたんですが、流石にコマンド履歴どころかコピペすらまともに出来ないのはどうかなと一念発起してWindowsでZshくらいは使えないかなとググってみたらよさげなモノを発見！ Babun | A windows shell you will love! それがBabunというWindows用のターミナルア
![[D] Windowsはターミナルがダメだから使えないってのは過去の話?](https://cdn-ak-scissors.b.st-hatena.com/image/square/75b0dc449d0b56499a80b7c43cc4bee54c3f1407/height=288;version=1;width=512/https%3A%2F%2Ffarm8.staticflickr.com%2F7317%2F15771156714_4f4cfa61f1_o.png)
npmとクライアント側でのパッケージ管理の議論 - ワザノバ | wazanova
npmに登録されているパッケージ数は10万、月間ダウンロード数も5億を超えました。7月の段階で月間3億程度ですから、こちらのグラフで見てもわかるように、かなり成長が加速してきていますね。 EdgeConf4において、パッケージ管理をテーマにしたディスカッションに、npmのCTOであるLaurie Vossと、npmのpeer dependencyをつくったGoogle Chrome TeamのDomenic Denicola（ES6のPromiseの取組みでも知られた人ですね。）が参加しています。この二人と、BowerのJosh Peekを中心に議論が進んでいます。ちなみにJoshはGitHubの社員で、最近では、左右に並べてdiffを比較できる便利な機能をつくった人でもあります。 「サーバサイドのパッケージマネジャとしては、CPANやRubygem、npmのように開発言語ごとにプレーヤー
GitHub:Enterprise 環境下では CocoaPods を 0.34.0 以上にアップデートしてはいけません
CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。 公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。
Pythonによる CLI ツールの実装と配布 - WonderPlanet DEVELOPER BLOG
こんにちわ。日々の作業の80%がターミナルで完結する原です。 最近、他チームに向けてCLI（コマンドライン・インタフェース）ツールを作成する機会がありました。 ツール動作環境がOS Xである点、モジュールのインストールが簡単である点、内部DSLの実装が比較的用意である点などを考慮し、Pythonで実装・配布しました。 また、自分自身も、普段の開発で行うような定形作業をPythonでスクリプト化することで、効率化しています。 シェルスクリプトでは実装が面倒くさいような外部サービスとの連携も、Pythonであればサードパーティのモジュールや例がたくさんあるため、実装が容易です。 当エントリでは、このように色々なシーンで活用できるPython製CLIツールの実装および配布方法をご紹介します。 サンプルとして「wonder_tool」という名前のCLIツールを作ってみましょう。 サンプルの仕様 こ
Big Sky :: cpanfile とは何か、なぜそれを使いたいのか
超絶意訳 What is cpanfile and why do I want to use it - Tatsuhiko Miyagawa's blog What is cpanfile and why do I want to use it So there seems to be a couple of blog posts and even co... http://weblog.bulknews.net/post/44963580392/what-is-cpanfile-and-why-do-i-want-to-use-it cpanfile について幾つかブログ記事やカンファレンスがある様です。素晴らしい事です。ですがそれは単に、それが何であるか、またそれらがなぜ必要なのか(もしくは必要じゃないのか)を、筆者の説明と共に書かれているだけなのです。 tl;dr 日本の方へ - こ
CocoaPodsを使ってみた - blog.ishkawa.org
以上で導入は完了です。 元々のプロジェクト(Hoge.xcodeproj)とは別にワークスペースが(Hoge.xcworkspace)作成されるので、以降の作業ではこちらを使うようにします。 Project Navigatorは以下のようになっているはずです。 どうやらライブラリ群をlibPods.aというスタティックライブラリにまとめて、リンクしているようです。 CocoaPodsの良いところ git submoduleを直接使っている場合と比較したメリットを書きます。 プロジェクトへの導入の自動化 git submoduleはライブラリのソースコードを管理するのであって、 どのようにXcodeプロジェクトに導入されるかまでは管理していません。 つまり、ライブラリを導入するには手動で以下の手順を行う必要があります。 導入に必要なファイルのみをXcodeプロジェクトに追加 必要に応じてフレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現代開発を加速させる古来の術式
