  |
はてなキーワード: VSCodeとは
転職先のパソコンがガチガチにロックダウンされている上に、外部通信も割とガチガチにブロックされているのでコードで遊べない。
SSHもダメ、DynamicDNSもダメだったけど、ドメインを登録してshellinaboxとかgottyとかでブラウザでアクセスできるようにした（nginxとbasic認証、modsecurityでセキュリティ対策）。
が、もっと簡単な方法はVS CodeのTunneling Server(https://code.visualstudio.com/docs/remote/tunnels)を立てて、vscode.devからブラウザでアクセスするだけで良かった！
この方法だと、egress 443さえ空いていればよいのでPort Forwardingさえ不要だ。
しかしそういえば、今日は「動かなくなっちまった」が 2 連続したんだなあ。
昼は Visual Studio Code の拡張機能「Markdown Preview Enhanced」の PlantUML 機能が動かなくなっていた事に気づいた。
どうやら plantuml.jar のパスを設定してやる必要があるらしい。
以前までは MPE をインストールしたままの状態で動いていたはずなのに。
まあ設定は簡単。MPE とは別に、同じく VSCode の PlantUML 単独の拡張機能も入れていたので
そいつが抱えている plantuml.jar を MPE でも使うように設定。こちらはすんなりと解決だ。
（いや、待てよ。拡張機能は自動でアップデートされていくもの。そして拡張機能のディレクトリ名にはバージョン番号を含んでいる。
つまり PlantUML 拡張機能のディレクトリ名、いつか気づかないうちに変わっちゃうんじゃないか？解決になってないなこれｗ）
社会人歴は相手の方が上だけど、開発経験はこっちの方が上。だから私が立場的な上司。
WebアプリだからJavaScriptがメイン言語的な立ち位置。
終わってないのに勝手に「月曜日にやります」だけチャットに残して上がりやがった。
私の感覚では、想定された予定よりオーバーしてしまう場合は上司にその旨を相談して「残業するor工数を増やしてもらう」かを選択するのが普通だと思っていたんだけど、そのおばさんは違うみたい。
あまりにもその人が無能だからだんだん自分が有能に思えてきたわ。
VSCodeのカスタマイズに明け暮れてる前にさっさと仕事してくれ。
元々小チーム組むとき、リーダーが「あの人、外面は良いけど仕事が雑。放っておくとすぐにサボるからイタズラに工数伸ばしがち、でも理由は教えてくれない」って言ってたけどさ。
うちの社員に下を育てられない、具体的には「部下が工数オーバーしそうな時は勝手に巻き取る」「部下が出してきたコードを勝手に修正してそのまま終わらせる」奴がいるんだけど、なんか気持ち理解できてきたわ。
こりゃあ前途多難って感じ
Unity5から長く離れていたほぼほぼ今となっては初学者とみなしてよい者なのですが、
開発環境と最初から選定すべきライブラリのベストプラクティスについて教えて欲しいです。各々のオレオレベストプラクティスで良いです。
想定されるテンプレは
バージョン管理システム:
入れておくべきライブラリ:
入れておくべきアセット:
みたいな感じです。
例えば
コーディング用エディタ: VSCodeになんかよさげなプラグイン
入れておくべきライブラリ: UniRx,UniTask
入れておくべきアセット: 画像や音楽、3DモデルというよりはRewiredなどのロジックを補強するアセットなどが知りたいです
こんな感じでしょうか。
https://www.python.jp/train/index.html
3. 文字列と入出力
https://www.python.jp/train/string/index.html
以下、気になったところ。
特になし。
特になし。
いや、Pythonだけじゃなくて、他のプログラミング言語でも、文字からなるデータは「文字列」って呼ぶだろ？
文章や人名など、文字からなるデータをソースコードに書く場合には、数値と違って、文字の前後を "(ダブルクォテーション) か '(シングルクォテーション) で囲んで記述します。
文字列の "ABC" と "DEF" を足すと、"ABCDEF" になります。
これはPythonに限った話ではなく、プログラミング言語全般に共通の話。
数値型同士のデータは四則演算ができるけど、違う型のデータでは四則演算ができない。
データ型を他のデータ型に変換することを「型変換」とか「キャスト」（cast）などと言ったりする。
数字だけからなる文字列は、次のように int() を使って整数に変換できます。
text = "123"
int(text)
123
数値の文字列化
int() を使って文字列を整数に変換するのとは逆に、str() を使って数値を文字列に変換できます。
num = 123 # 整数値
str(num)
'123'
処理するデータの型違いによるエラーは、基本的なうっかりミスの１つなので、常に型は意識してデータを扱いたい。
特にPythonのような動的型付け言語は、型を意識しなくてもプログラムが書けてしまうが、その分バグになりやすいので注意が必要だ。
いちいち型を気にするのは面倒くさいので、「型推論」というズボラな人向けの機能もある。
型推論（かたすいろん、英: type inference）とはプログラミング言語の機能の1つで、静的な型付けを持つ言語において、変数や関数シグネチャの型を明示的に宣言しなくても、変数宣言における初期化のための初期値や、関数呼び出しにおける実引数などといった、周辺情報および文脈などから自動的に（暗黙的に）各々の型を決定する機構のこと。
言語によってはtype deductionと呼ばれることもある。
推論に失敗するとその時点でエラーを報告できるため、少なくとも誤った型を用いることによるバグは回避できる。
また、アルゴリズムの記述に集中できるのでプログラムの抽象度が上がるというメリットもある。
ただし型推論と関数の多重定義（オーバーロード）は相性が悪く、オーバーロードをサポートする言語では型推論による恩恵が十分に受けられない（型推論ではシグネチャを一意に決めることができない）ケースがある。
Pythonには型推論の機能がないので、プログラマーが工夫して型によるバグをなくすしかない。
「Python 型推論」で検索すると、いろいろなTipsが紹介されている。
【Python】VSCodeが型推論結果を自動で表示してくれるようになった【TypeHinting】
https://zenn.dev/yosemat/articles/36638f17e9ded8
最初のうちは、型によるエラーはあまり気にしなくても良いと思う。
エラーが出たらその都度つぶしていけばいいし、あとでテスト方法を学んだら、型を検査する方法も分かってくるはずだ。
特になし。
特になし。
嘘の説明があるなー。
初心者向けに便宜的な説明をしておこう、という趣旨は仕方がないかもしれないけど、後で訂正するというか、詳しく説明するという注意書きは必要だろう。
何が嘘かって、用語の定義の問題なんだけど、「メソッド」という言葉は一般的に、オブジェクト指向プログラミングの用語で、クラスに定義されている関数のことをメソッドと呼んでいる。
しかし、教える順番として、クラスとかオブジェクトは後の方に出てくるなら、今の段階ではメソッドをどう説明すればいいのだろうか？
Pythonの文字列は、実はStringクラスのオブジェクトであり、Stringクラスには文字列を操作するための様々なメソッド（処理）が用意されている、ということをクラスの説明なしにするのは、ややこしいかもしれない。
なので、オブジェクトのことをここではざっくりと「データ」という言い方でごまかしている。
私のようなPython素人の場合、もっと良い説明方法が思い浮かばない。
とりあえず、ここではメソッドをデータに紐づけられている関数ということにしておこう。
メソッドは 関数 の一種です。これまで見てきたように、特定のデータに結びつき、
↓
https://www.python.jp/train/list/index.html
Pythonでは、これまで紹介してきたような、整数や実数、文字列などのデータのことを、オブジェクト(Object) という用語で呼びます。
Objectは英語で「物」とか「対象」とかいう意味の言葉ですが、Pythonでは、Pythonが操作するいろいろな種類のデータやプログラムなどのことを、まとめて オブジェクト と呼びます。
ここまで読んで、はじめてデータの種明かしがされて、Pythonのデータはオブジェクトであり、オブジェクトに用意されているメソッドが使えると。
せめて「詳しくは第8章のオブジェクトの説明を読んでね」ぐらいは書いておいた方が良いと思う。
なんでオブジェクトというデータ構造、仕組みを用意するのか？という根拠の説明がスッポリと抜け落ちている。
一般的にオブジェクト指向プログラミング（OOP）の説明方法、教え方は様々だが、単純にはC言語の構造体が出発点であり、「データに処理をくっつけたもの」という説明でいいだろう。
ちなみに、その反対に「処理にデータをくっつけたもの」をクロージャ―という。
オブジェクトもクロージャ―もPythonだけの仕組み、話ではないので、他にもっと分かりやすい説明方法があれば、そこから引用した方が良いだろう。
問題は説明の順番で、前提となる知識がない段階では、どのようにごまかした説明で切り抜け、後で詳しい種明かしをするか？という教え方の設計（インストラクショナル・デザイン）が問われている。
あまりうまくごまかせていないところを見ると、もしかしたらPythonを教えている教師たちは、あまり頭が良くないのかもしれない？
・スコープを限定することができなくてデバッグの時に訳が分からんくなる。
・メソッドを分けて切り分ければよいのか？でもこれをするとパフォーマンスが低下するしな。
・型の情報がほぼ無いから知識を引き出す為の取っ掛かりがつかめない。
・Github Copilotに頼り切りになってる。それが無かった時はフレームワークの機能を丸暗記してたのか？
・RustやTypeScriptではVSCode上に表示されるドキュメントの情報を読みながらコードを書いていたので、それができないのは本当につらい。
・nullがあるのが気持ちが悪い。Optionが無いとエラーハンドリングでバグりまくりそう。
自分は、月並みにgoogle keepメイン。
markdownやらTeXやらplantUMLやらを使いたい内容の場合は、google colaboratory。
本当はテキストエディタが使いたいけど、スマホやタブレットのウェイトが上がってきて諦めた。
NotionかVScodeかどっちかなあ
色んなメモツールとか試してて、ようやく重い腰を上げて、 Obsidian に移行してみて試してみてたんだけど、
数日前から日本で話題になってたVSCode の拡張機能の GistPad に変えることにした。
GistPad は簡単にいうと GitHub の Gist を VSCode で分かりやすく管理できるツールなんだけど、
保存すると同時にコミットしてくれたりするので、 GitHub 使ってる人ならすごい取っつきやすいと思う。
VSCode の拡張機能なので、Pritter とか textlint とかの拡張機能も使えるし、Obsidian よりも色んな機能が使えるはず
日本語の情報が少なかったり、iPhone とかでの使い方とかはまだ試していて何が正解か分からないけど、
無料でこれだけできるのは、めっさ便利なので一回試してみて欲しい。
https://github.com/lostintangent/gistpad
https://marketplace.visualstudio.com/items?itemName=vsls-contrib.gistfs
