npm install と npm ci って結局どう使うの？2023年版 - Mitsuyuki.Shiiba
うりうりさんの↓のコメントを見て、そういえば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 ちょこっと検索して見てみたところ、新旧情報があって自分が混乱したのと、公式ドキュメントには概要は書かれているものの詳しい内容は書かれていないので（僕が見つけ
GitHub Actionsの歴史（2021/12/1 更新） - cangoxina
# はじめに GitHub Changelog を元に、GitHub Actions がどのように更新されていったかを簡単にまとめました。 あまり深いところまでは書いてないので、気になった変更があったら各自調べてください（もっと色々書きたかったけど時間なかった）。 わりと雑に作ったので漏れや間違いがあったらコメントとか下さい。 2021/12/01 までの情報をもとにこの記事は書かれています。 この記事は GitHub Actions Advent Calendar 2021 の 1 日目の記事です 🎅🎂 目次 # はじめに # 歴史 ## 発表 〜 正式リリース（2018/10 〜 2019/11） ## 2020 ### 1Q + α ### 2Q ### 3Q ### 4Q ## 2021 ### 1Q ### 2Q ### 3Q ### 4Q ## 2022 ### 1Q #
マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018
2018年11月2日に行われたAWS Dev Day Tokyo 2018での講演「マイクロサービス化デザインパターン」の資料です。
9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
クラウドサービスの Web API とそのユースケース #apijp
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Martin Fowler's Bliki in Japanese - ユニットテスト
http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった （この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ）。 ユニットテスティングは
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
2010年以降の PHP の開発体制(リリースサイクル、RFC、投票)と歴史の振り返り
5月7日: ユーザーノートの投票制度について追記。 2010年以降において PHP コアの開発体制が刷新され、リリースサイクル、RFC、投票が設けられた。 リリースサイクル、RFC、投票制度についてそれらが導入される前の歴史を振り返ることで、理解が深まるだろう。 まずはリリースサイクルについて。 定期的なリリースができるようになった背景にはテストツールおよびテストの自動化ツールが普及したことが挙げられる。PHP コミュニティにおいて2000年代後半においてフレームワークを中心にテストツールが普及した。 PHP 5.2 まではほぼ1年単位でリリースされてきたが、PHP 5.3 でリリース期間が延び、5年以上の開発期間があった PHP 6.0 が2010年に破綻し、開発のビジョンが不透明になったことを受け、あらためて、開発のリリースサイクルが明確にされた。 マイナーバージョン(たとえば 5.x
ノーフレームワークのレガシーPHPがCIに乗るまで
ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHP と HTML と SQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと本番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p
Jenkinsの生みの親が語る、継続的インテグレーションの未来 － ＠IT
2011/06/06 5月24日、日本Javaユーザグループ（以下、JJUG）の主催による「JJUG Cross Community Conference（以下、JJUG CCC） 2011 Spring」が行われた。JJUG CCCはJJUGが年2回開催している定例イベントであり、Javaに関する最新の動向や活用事例などが紹介される。 本稿では、オープンソースのCIサーバ「Jenkins」の生みの親である川口耕介氏による基調講演の様子をお伝えする。 「Jenkins」はソフトウェアプロジェクトのビルドやテストを自動化する継続的インテグレーション（CI：Continuous Integration）サーバの一種である。もともとは「Hudson」という名称で開発・公開されていたが、商標上の問題によってJenkinsに改名された。 JJUG CCCの基調講演は、その生みの親であり現在もプロジェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
