サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
ja.stackoverflow.com
現象 vscodeでpythonファイルを開いた状態でターミナルを開くと、 source /home/{USER}/anaconda3/bin/activate conda activate base という二行のコマンドが自動的に実行されてしまいます。 この自動的なコマンド実行を止めるにはどうすれば良いですか? 説明 condaのバージョンは4.7.12 bashrcはconda initを行った直後の状態 vscodeのpythonインタープリタにはpython3.7.4 64-bit('base': conda)が指定されている
たとえば「要素Xをクリックしたら何かしらの問題が発生する」といったバグの解析時に「クリックされた時にどのjsファイルの何行目あたりが実行されるか」が知りたいのですが、いい方法は無いでしょうか? 現状では、やむなく要素Xのidやclass値でgrepをかけてしらみ潰しに調べています。 ポイントは、各種ライブラリ内部のjsというより、現在調査中のブロジェクトのjsファイル・行番号を突き止めたいという点です。 ブラウザはChrome, Safari, Firefoxです。
github の PR の diff 表示では、行ごとの diff に加えて、行中のどこの部分に差異があるのかを表示してくれます。例えば linux の PR から適当に拾ってきたこのページ などが具体例です。 今、コマンドライン上の diff においても、このように色付けができたら便利だろうと思い、その方法を探しています。 diff に色を付けようとして、見つかったパッケージは、 colordiff というツール で、これを使うと、例えば + の行は緑色、-の行は赤色といったように、行ごとに色を付与してくれますが、最終的に実現したい github 的な diff の再現において、「行中の差異の部分の表示」はやってくれていないな、と思っています。 質問 github の PR ページの diff のように、行中の差異の部分まで色わけしてくれるような diff を、ターミナル上で実現したいの
具体的にどのようなAPIなのかは調べていないですが、ユーザ認証やAPI利用に関する認可に関する手続きで出てくるRedirect URL(URI)やCallback URL(URI)についての質問だと思いますので、その前提で答えます。 2つは同じ意味でしょうか? 同じ意味です。 これらはなぜ必要なのでしょうか? どちらも「TwitterやInstagramのDomainから、ユーザ認証結果やAPIを利用したいアプリ/サービスのDomainに制御を戻すために必要となります。 アプリ/サービスがユーザ認証結果やAPIを利用したい場合、Twitter内やInstagram内のどのユーザがアクセスしてきたのかをまずは特定する(これをユーザ認証と呼ぶ)必要があります。その特定のために、例えばメールアドレスやパスワードといった「第3者に知られたくない情報(ユーザクレデンシャルと呼びます)」をユーザに入力
「way」とは ここでの「way」とは、マージする際に "見て" いる場所のこと。3-way merge は 3 つの場所を見ている。 2-way merge:「マージの起点コミット」「マージさせたいコミット」を見てマージする 3-way merge:「マージの起点コミット」「マージさせたいコミット」「2 つのコミットの最近共通祖先となるコミット」を見てマージする アルゴリズムの概略 ここでは Git のデフォルト・マージ戦略である「recursive」にしたがった 3-way merge のアルゴリズムを書きます。簡単のために省略して書いています。 入力: コミットグラフ。マージの起点としたいコミット X。X にマージしたいコミット Y。 出力: マージできるかどうか。マージできるなら、マージ済みコミット Z を含む新しいコミットグラフ。マージできないなら、コンフリクト箇所。 手順 X
"testあ"のUTF-8表現は、74 65 73 74 e3 81 82 (1バイトデータの表記は全部16進、以下同様, python3風に書くとb'\x74\x65\x73\x74\xe3\x81\x82')で、chardetが判定するのは「文字列」ではなく、このバイト列です。 ちなみにこのバイト列をUTF-8, Shift_JIS, EUC-JP, ISO-8859-1, Code Page 437, Windows-1254で解釈すると、以下のようになります。 UTF-8 testあ (まぁ、当たり前) Shift_JIS (不正) EUC-JP (不正) ISO-8859-1 testã (81 82 は制御コードにあたるので見えないが不正ではない) CP437 testπüé Win1254 testã‚ (81は未定義なので本来は不正、chardetは未定義にあたるバイトが現
sshに関係なく公開鍵暗号一般での話と考えた場合、それぞれの方式で行える事は RSA: 暗号化と署名 EdDSA: 署名のみ なので、上位互換とは言えないでしょう。 SSHでの公開鍵認証で考えた場合、利用するのは署名のみとなります。 以下はSSHでの公開鍵認証に絞った話となります。 同等のセキュリティを提供するために必要な暗号鍵の長さは RSA 以下で これは何を基準にするかによって答えが変わると思います。 ECDSAやEdDSAは利用する曲線により強度が変わります。 SSH で使われる Ed25519 の場合は Curve25519 という曲線を使い、この場合の鍵長は 256 bit です。 RSA で同等の強度と言われているのは 3072 bit なので、これを元にすれば Ed25519 の方が鍵長は短いと言えます。 この辺りの詳細については"等価安全性"で検索してみて下さい。 一方、
Gunicorn → アプリケーションサーバー ApahceやNGinx → Webサーバー Flask → PythonのWebアプリケーション フレームワーク になるかと思います。 Flask には、サーバー機能が組み込まれてはいますが、開発やテストをすることを主眼に用意されており、性能、安定性、セキュリティなどは考慮されておらず、簡素な物です。 本番運用する場合は Gunicorn などの アプリケーションサーバー(WSGI サーバー)を利用するのが推奨されています。 Gunicorn は Pythonで実装された WSGI サーバーで、Webサーバーとしての機能もあるので Gunicorn単体でも動きますが、Nginx と組み合わせるのが強く推奨されていて、外部からの攻撃に強くなるのが理由として挙げられてます。 http://docs.gunicorn.org/en/latest/
peer dependencyとは Peer dependencyは,パッケージ間の依存の一種であり,依存先が自動的にはインストールされないものを指します. パッケージAがパッケージBに(peerではない通常の)依存をする場合,Aをnpmでインストールすると依存関係が解消され,自動的にBもインストールされます.一方,AからBへの依存がpeer dependencyである場合,AをインストールしてもBは自動的にはインストールされません. Peer dependencyの使い所はいくつかありますが,peer dependencyはAがBをrequireするわけではないような場合に適しています.むしろ逆に,直接的もしくは間接的にBがAをrequireするような場合に,AからBへのpeer dependencyを設定するべきです.npmのドキュメントでも言及されているように,このような状況はAがB
Chefの情報を探していると ::Chef::Recipe.send(:include, Foo::Helper) という表記のものに出合ったのですが、クラス名の先頭に::をつけるとどのような効果になるのでしょうか? ドキュメントを探してみたのですがうまく検索する方法がわかりませんでした。
そのライブラリのビルド設定において、Module Stabilityが有効になっていないからです。 Swift 5におけるABI Stabilityというのは2つのパートに分かれていて、1つはABI Stabilityでもう一つはModule Stabilityです。 ABI StabilityはSwift 5.0で実現されました。これは異なるバージョンのコンパイラから生成されたバイナリ同士を「リンクできる」というものです。 これにより、Standard Libraryをアプリごとに同梱する必要がなくなりました。 一方Module StabilityはSwift 5.1で実現されました。これは異なるバージョンのコンパイラから生成されたモジュール(≒フレームワーク、ライブラリ)を「インポートできる」というものです。 Swiftがフレームワーク、ライブラリを利用可能にする(=インポートする)た
*解決したいこと git push時にerror: failed to push some refs toと出てくるのでそれを解決したいです。 *前提 RailsでWebアプリケーションを作成中です。 作業ブランチ:implement_bookmark_for_post エラーが出るまでの流れ 変更したファイルをコミットする→上記のブランチにpush→やり残しがあったのでgit reset --soft HEAD^をコマンドラインで叩く→再びコミット→作業ブランチにpurh(ここでエラー) *エラー内容 ! [rejected] implement_bookmark_for_post -> implement_bookmark_for_post (non-fast-forward) error: failed to push some refs to 'https://github.com
1,「sudo」コマンドはrootのパスワードを入力せずともroot権限でコマンドが実行できるものですが、よくよく考えたらそれだとrootでログインせずとも色々なことができてしまうのであまり意味がないのでは? 2, ちょっと調べたところ、実行できるコマンドをvisudoで割り当てる、と書いてありましたが、大抵は/usr/のようなフォルダ名のフォルダを指定しているのですか?システムを破壊してしまう可能性のあるコマンドってどこにあるんでしょう? 1,2の認識で間違いないでしょうか?システム管理者がどういう風にユーザーを管理しているのかよくわかっていないため、なんとなくそうなんじゃないかと思っていても自分の中ではっきりしません。なので解説がほしいのですが、どうぞよろしくお願いいたします。
TCP/IPというのはTCPとIPの組合せのみを指している言葉ではなく、TCP及びIPを含むプロトコル群の総称です。 1974年にはTCP/IPの最初の仕様であるRFC675が制定されましたが、その当時はUDPというプロトコルは存在しませんでした。 UDPは1980年にRFC786が制定されTCP/IPに含まれることになりました。 歴史的な経緯で「TCP/IP」という表現になっていますがその中にはUDPも含まれているということです。 また、総称的な意味であれば「Internet Protocol Suite」という表現をする方が適切だとされることもあるので質問者さんと同じことを思っている人はそれなりに居るのではないでしょうか。
まず、クオートは、(quote hoge)の略記、シャープクォートは、 (function hoge) の略記になります。 この、'hoge (quote hoge) と #'hoge (function hoge) の違いはEmacs 特有ではありません。 最初期のLISPである、LISP 1.5 から連綿と受け継がれているものです。 詳しく書くととても長くなるので、大きく2つに分けて、乱暴に箇条書きにしてしまうと、 Quote vs Function スコープ篇 初期のLISP (1959年)で関数を引数にした場合意図しない動作となることが指摘される LISP 1.5では、上記に対応するため、functionとfunargを導入し、quoteと使い分けるが、本当に実現したかったものは、Schemeのようにレキシカルスコープを持つ方式だった Common Lispや最近のEmacs 24
その記法は、SwiftのImplicit Member Expression(定訳は知りませんが、ここでは「暗黙のメンバー参照式」としておきます)と呼ばれるものです。 Implicit Member Expression An implicit member expression is an abbreviated way to access a member of a type, such as an enumeration case or a type method, in a context where type inference can determine the implied type. (拙訳)暗黙のメンバー参照式というのは、型のメンバーをアクセスする際の省略記法です。列挙型のケースや型メソッドなどを、型推論がその型を間違わずに判定できる場合に使用できます。 さらに意訳する
可能です。実際に複数のバイナリを1つのリポジトリで管理しているソフトウェアも存在します。 解決法 それぞれのアプリを別ディレクトリに格納すれば良いです。たとえば、以下のような形で管理します。 cmd/app1, cmd/app2 というように、あるディレクトリ以下にそれぞれのアプリのソースコードを用意する。 共通のライブラリは pkg や internal や lib など他のディレクトリで管理する。(あるいはルートディレクトリに置く場合もあります。) こうすると以下のように使えます。 それぞれのアプリのビルドのためには、各アプリのディレクトリの中で go build する。一括で go build するための Makefile や build.go を書くこともある。 リポジトリのルートディレクトリで go install ./... すれば一括でインストールできる。 また、複数のバイナ
@hinaloe さんのコメントや、 ksaito さんの回答を参考に、以下の方針で可能そうです。 方針 AuthorizedKeysCommand を利用する。 authorized_keys_command から実行されるプログラムの中で aws コマンドで iam から pubkey を読み込む AuthorizedKeysCommand とは何かというと、 authorized_keys を file に記述するのではなく、プログラムの標準出力でもって指定できる sshd の設定オプションです。 また、 IAM ユーザーは、 ssh の public key をひもづけることができます。これは、主に CodeCommit で用いられますが、今回はこれを上手く利用できるので、これを活用します。 手元では検証できていないですが、これをやることで、各ユーザーが、それぞれの IAM ユーザ
Nginx でサイトごとの設定をする際に、 site-available フォルダに hoge.com.conf というファイル名で設定を書き、 それを site-enable フォルダにシンボリックリンクを貼って、site-enableの *.confの設定を反映するという形にしております。 これはいくつかのサイトをこのやり方が定石というような形で書いてありました。 直接 site-enabled に書いてしまうことによる弊害はあるのでしょうか?
htmlページをブラウザ標準の印刷機能で印刷する場合、縦向きのA4用紙に入る横幅は最大何ピクセルになるでしょうか? css * { box-sizing: border-box; } .test1 { width: 1366px; border: 10px solid red; } .test2 { width: 1280px; border: 10px solid green; } .test3 { width: 1024px; border: 10px solid blue; } html <body> <div class="test1">test1 1366px</div> <div class="test2">test2 1280px</div> <div class="test3">test3 1024px</div> </body> 上記のようなページでプレビューを試したとこ
asyncの挙動について、MDNのドキュメントだけでは分からなかったので教えてください。 例えば、以下の try-catchはPromiseのrejectをcatchしません。 try { (async () =>{ await Promise.reject() })() }catch (e){ console.log('ERROR!', e) // これは出力されない。代わりに... /* (node:66365) UnhandledPromiseRejectionWarning: undefined (node:66365) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function
現在、Embedded Framework で複数ターゲットに分割して開発しているのですが、 CocoaPodsでFirebaseを複数ターゲットにインストールすると起動後にクラッシュしてしまいます。 objc[97307]: Class FIRMessagingLog is implemented in both /Users/yuto/Library/Developer/Xcode/DerivedData/App-bgkajtjdcnvxnxexzeaimkikirwu/Build/Products/Release-iphonesimulator/App.framework/App (0x10393ad98) and /Users/yuto/Library/Developer/CoreSimulator/Devices/871E1A28-1266-4B31-BF14-A84577AA5
Googleフォームのフォーム送信時にフォーム投稿内容を自動返信するようスクリプトを組み、今まで問題なく使っていたものを、コピーして新しいフォームを作ったところ、トリガー登録画面が新しくなっており、困っています。 (GsuiteDevelopperHub画面になります) 新しい画面で、一応、トリガー追加ダイアログで、以下のように設定してみました。 実行する関数を選択 「submitForm」 実行するデプロイを選択「Head」←変更できない イベントのソースを選択「フォームから」 イベントの種類を選択 「フォーム送信時」 エラー通知設定 「今すぐ通知を受け取る」 が、これで実行させると、以下エラーとなり、イベントが今までのようには渡されていないようです。 「TypeError: undefined のメソッド「getItemResponses」を呼び出せません。 at submit
要素を位置指定して他の要素の上に重ねて表示すると、背景を設定しなくてもマウスイベントは重ねた要素の方に取られてしまいます。 例えば次のコードではborderを設定したdivの上からではボタンが押せません。 div { position: absolute; top: 0; width: 50px; height: 50px; border: 2px solid blue; } <button onclick="alert('hello!')">Click me!</button> <div></div>
ほとんど同様のトラブルを相談された方がいるのは承知しておりますが、表面的なエラーメッセージが同じでも解決策はどうも異なるようなので、質問させて下さい。 Virtualbox5.2.16で仮想マシンをRedHat64bitで作成して、CentOSのイメージをアタッチして起動しようとしたのですが、初回の起動の時から添付のスクリーンショットのエラーが出て起動しません。 説明のためにスクリーンショットの画面が多くなってしまい申し訳ありません。 どのようにすれば解決するか、皆さんの知見を拝借したくご質問させて頂きます。 エラーのログファイルである、VBoxHardening.logをコピペサイトに掲載しました。 この内容から原因を推察できる方がいらっしゃればと思います。 https://pastebin.com/ecKXChUX ATOkがエラーの原因になっているようにも見えるため、MS-IMEに切
環境: Rails: 5.1.5 Ruby: 2.5.0 capybara: 2.18.0 rspec-rails: 3.7.2 selenium-webdriver: 3.10.0 Docker初心者です。現在docker-composeで以下のように開発環境を作っており、その上でrspec(system spec)でcapybaraのテストを行っていますが、サブドメインのテストの方法がわからなくて困っています。 docker-compose.yml services: nginx: image: nginx:alpine container_name: my_nginx links: - app ports: - "80:80" volumes: - .:/app depends_on: - chrome app: build: context: . command: bash -c
Windowsが当初使用していたFATファイルシステムの影響です。 FATファイルシステムのディレクトリエントリの構造としては、ファイル名8バイト、拡張子3バイトの固定長フィールドとなっており、それぞれの長さに満たない場合は空白で埋められる仕様です。このため、ファイル名と拡張子の間に.は格納されていません。 例えば空白を_で表すと、ファイル名README.TXTであればREADME__TXTと格納され、READMEであればREADME_____となります。 このような事情があるため、Windows APIでは暗黙の.を許容します。つまりREADME.、README.*、*.*などで検索を行うとファイル名READMEがヒットします。現在はNTFS等、他のファイルシステムが使われていますが、ファイルシステムに依らずWindows APIは上記振る舞いを継承しています。 ではどうすべきか 実は使
iota(イオタ)はギリシャ文字 ι を指す単語です。iota によって「ひとつずつ増える整数値の列」を示すプログラミング言語は Go 以外にも C++ の std::iota や Scheme の iota、そして APL の ⍳ などがあります。 Go の iota は APL に由来していると言って良さそうです。というのも Go の設計者の 1 人である Rob Pike 氏の話によると、まず同じく設計者である Ken Thompson 氏が iota という名前を提案したところ設計者 3 人(Ken、Robert、Rob)全員が APL のインタプリタを実装したことがあったため合意に至った、と書いているからです。 では APL の ⍳ はどういう由来なのでしょうか。APL の作者 Kenneth Iverson 氏はチューリング賞講演 "Notation as a Tool of
リモートレポジトリのHEADは、そのリモートレポジトリのデフォルトのブランチを表します。これが設定されていると、リモートレポジトリのレポジトリ名だけ指定したときに、そのデフォルトブランチが指定されたものとして振る舞います。 例えば、origin/HEADがorigin/masterを指しているとき、git checkout -b test originは、git checkout -b test origin/masterと同じ意味になります。デフォルトブランチが指定されていない場合、上記のコマンドは(originというブランチがない限り)エラーになります。 リモートレポジトリのHEADは、git remote set-headコマンドで指定できます。
次のページ
このページを最初にブックマークしてみませんか?
『スタック・オーバーフロー』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く