Docker を利用して Jupyter を構築した理由 使用している PC の環境を汚したくないため 他の人への共有を簡単にするため(若手メンバーに教材として払い出す際の手間を減らしたい) Docker の実用的な使い方を確認したい GitHub リポジトリ 前提条件 Docker Desktop を既にインストールしていること Docker Desktop の状態が Engine Running になっていること 開発環境 項目 内容 備考
![[Docker / Python / M1 Mac]Docker を利用して Jupyter を構築 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/00b134f5e9a471466a4c890a4193d05602df9117/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUVGJUJDJUJCRG9ja2VyJTIwJTJGJTIwUHl0aG9uJTIwJTJGJTIwTTElMjBNYWMlRUYlQkMlQkREb2NrZXIlMjAlRTMlODIlOTIlRTUlODglQTklRTclOTQlQTglRTMlODElOTclRTMlODElQTYlMjBKdXB5dGVyJTIwJUUzJTgyJTkyJUU2JUE3JThCJUU3JUFGJTg5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zN2EzODZjZmJjZDdhYmRiOWRiZWQyNWFmODE3OTBhNw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwdGFuYWthZGFpY2hpXzE5ODkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTJkOGUwZDk4ZTA5NjMwYzU0MDNlYjMyZDhkZmQ2ZTMy%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D51c52fb3771f7494ffaa81e3e4cbf1f3)
1. GitHub Copilot Labs「GitHub Copilot Labs」は、「GitHub Copilot」の実験的な機能を提供するVSCode拡張です。 以下の機能を提供しています。 ・コードの説明 ・コードを別の言語に翻訳 ・コードの編集 ・読みやすさの向上 ・型の追加 ・バグ修正 ・デバッグコードの追加・削除 ・コードをステップ毎に説明 ・コードの堅牢化 ・コードの分割 ・ドキュメントの追加 ・カスタム ・テストコードの生成 また、「GitHub Copilot Labs」では「GitHub Copilot」とは別の規約が適用されます。より多くの情報を収集する可能性があります。これは、実稼働ではなく、学習を目的として設計されているためになります。 2. GitHub Copilot Labsの開始「GitHub Copilot Labs」の開始手順は、次のとおりです。
Code interpreter のキラーソリューションは表データの可視化っぽいけど、入力テキストとファイルソースによってテキスト生成とファイル出力ができるという点に着目すると色々活用の幅が広がる。 中でも、今までは入出力トークンに含まれる必要があったソースコードデータを外部ファイル化できるので、「リポジトリを丸ごと食わせる」などの従来トークン制限上実現できなかったことが外部システム連携なしで簡単に可能になったのが嬉しいポイントだった。 この特性を生かして最近OSSの静的コード解析というかコードリーディングをChatGPTにやってもらっている。 以下のサンプルでは脆弱性診実習用アプリ(通称「やられサイト」)のSQLインジェクションを発見してもらうという会話をした。 chat.openai.com 以下ではaws-load-balancer-controller や openai-pr-re
Dockerfileを作る時、最初は以下の方法でやってました。 Dockerfile書く ビルドする(動かしたいアプリ含め) 起動してみる 動かなかったらDockerfile修正する またビルドして試す こんな感じでしたが、これは非常に効率が悪いです。修正して検証を行う度にビルドが発生してしまい、待ちが発生してしまいます。 どうするか? ベースイメージにアタッチ 動かしたいアプリの実行に必要なコマンドを入れて、成功したらコマンドをメモっていく アプリが動くまで「コマンド実行→成功したらメモ」を繰り返す アプリが動いたらメモったコマンドでDockerfileを作る つまり、いきなりDockerfileを作るのではなく、ベースイメージに入ってコマンドを実行して動作確認をしながらDockerfileに記述する内容を固めていき、最後に1回だけビルドします。 なぜ? Dockerfileに記述するの
ビジュアルアーツが手掛けるスマホゲーム「偽りのアリス」が、7月31日のメンテナンスをもって新規コンテンツの更新停止を発表しました。同時にサービスの行方を示す「謎のカウンター」の実装も告知され、「斬新だわ」などと注目を集めています。 偽りのアリスは、2019年10月に配信された「Key」ブランドなどで知られる老舗PCゲームメーカー「ビジュアルアーツ」によるスマホ向けゲーム。童話をモチーフにしたキャラクターが登場し、「失敗作」の烙印を押された少女たちのふしぎな世界が描かれます。 「偽りのアリス」公式サイト 2023年7月15日に更新された公式Twitterで、7月31日に行うメンテナンスを最後に新規コンテンツの更新を停止すると発表。今後は過去に開催したイベントやガチャを定期的に復刻開催するとしています。 また、このメンテナンスで「サーバー代カウンター」と「何かのカウンター」を実装すると予告。「
はじめに はじめまして。インターンをしているイナです。 今回は初心者がGo言語の例外処理がないって本当なの?という部分について概念を中心に調べたものをまとめました。 Q. 例外処理とは まずは兎にも角にも、例外処理とはなんぞやってところからです。 いくつかのサイトで例外処理の定義について調べてみましたが、サイトによって言ってることはバラバラでした。 例外とエラーは一緒です or 違います!例外は想定外 or 想定内&想定外のエラーのことです!など人によって言ってることが違いました。 最初から壁が高すぎ...?と戦々恐々としていましたが、IT用語辞典 e-Wordで気になる部分がありました。 例外は「エラー」(error)と同種の概念で、普遍的に成り立つ両者の明確な違いは無く、同義として扱われる場合が多い。ただし、プログラミング言語や処理系によっては両者に異なる意味合いが与えられている場合も
最近、週末の趣味プロジェクトとして Cloudflare Workers(と Vercel Edge Functions)向けの Slack アプリ開発フレームワークを作りました。 私は普段 Slack の Developer Relations Engineer として Qiita の Slack チームの公式な記事を書いているのですが、この Cloudflare Workers 向けのものは業務で開発した公式ツールではなく、完全に個人プロジェクトなので、Qiita の Org ではなく Zenn に個人的な記事として書くことにします。 ・・・そして、書き終わってみると、随分と長い記事になってしまいました。興味のあるところだけでもぜひ読んでみてください。 この記事で説明するもの この記事では、Slack アプリ開発の基本と、以下のライブラリの使い方について解説していきます。 「Slack
こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない?と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの本質は、「KubernetesのAPIを使
いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター(社内でスクラムマスター的なロール)さんから、あのチームのディレクターさんに共有してもらってもいいですか?」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ(社内のプロダクトオーナー的なロール)さんから、他のチームに確認してもらってもいいですか?」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬(え?エンジニアどうしで話して認識合ってるのに?)って反応をされるし、僕自身も(大企業っぽいかなぁ?)って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー!やっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く