Docker公式のgetting startedが動かなくても慌てなくていい
最後にDocker触ってから大分経ってて色々忘れてたので公式のgetting startedをちょろっとつまみ食いしておこうとして危うく沼にはまりかけた。
Containerize an application | Docker Documentation
Dockerfileをコピペしてimageをビルドしてcontainerを起動、それだけの話なので特に何事もなく済んで…ほしかったけど起動したコンテナがすぐ落ちる（ああこれ懐かしい）
まああまりメンテできてないんだろうな、と色々弄ってビルドと起動を繰り返したりをしたもののdocker container prune -fを何回も打ちこみながらこれこれ懐かしー！ってなっただけで解決せず。
結局
docker run -d -p 80:80 docker/getting-started
で直接イメージ落としてきたら動いたので何が良くなかったんだろうと
GithubのDockerfileを覗いてみたらAlpineベースとかyarn使ってるのとかは同じだったけど行数が結構増えていた。
それだけ。
JSのセミコロン省略について
最近身近で「JSのセミコロンって要るの？意味あるの？」という質問があり、 漠然と「無くてもいいっぽいよ」という認識しかなかったため調べてみました。
ちなみに自分は最近は書かないことが多いです。
2015年なので少し古いですが、この記事が良かったです。
JavaScriptの行末セミコロンは省略すべきか | blog.tai2.net
大体以下のような内容でした。
- 本来は文の終わりを示すのにセミコロンは必要
- JSにはAuto Semicolon Insertionという実行時に必要であればセミコロンが適宜自動で挿入される機能がある
- このため基本的に文の終わりが行末と一致する場合は省略可能
- ただしASIが意図せぬ挙動の原因となる事がある
- このような罠のためASIを動作させるような書き方(セミコロン省略)は良くないとする派閥がある
- ASIの作者自身、積極的にセミコロンを省略するのは安全ではないと言っている
- 一方でnpmやbootstrapの開発者などセミコロン省略派も少なくない
- ASIが悪さをするような改行の仕方はそもそも良くない書き方なので避ければいい
- return後改行の問題はセミコロンを付けても回避不可能なのでしてはいけない
- 関数呼び出しにされるのは
!(function(){...})と書けば回避可能- これについては批判もある
- Javascriptは多様な書き方を許容する言語であり、どちらの流派も一理ある
セミコロン省略したいな派としては、ASIについて知らなかったのは不味かったなと思いました。
以下は感想です。
- 初学者にとっては重箱の隅なので取り敢えずセミコロンは付けさせて慣れてきたら自己責任がいいのかな
- return 直後に改行するな
- そもそも返り値はreturnより上で定義した方が綺麗じゃないですか？
- 即時関数の解釈違いを
!で回避する方法については正直ちょっと苦しいと思った- でもいまはESの時代なのでもう即時関数自体使わないですね… JavaScriptから即時関数を排除する - Qiita
- 綺麗な書き方をすれば綺麗に動くんですよしらんけど
- ESLINT使っとけばまず問題起きないでしょしらんけど
C/C++の宣言時constと型はどっちを右に書くか
興味深い投稿を見ました。
'const int' vs. 'int const' as function parameters in C++ and C
C/C++では定数宣言時の記述って
const intとint const
のどっちが正しかったっけと思ったら、どちらも同じように機能するそうです。
個人的には前者の方がこれはイミュータブルな値だよって明示してる感があるので好みですね。
ところでポインタが絡んでくると微妙に事情が変わってくるみたいです。
const char* is a pointer to a constant char
char const* is a pointer to a constant char
char* const is a constant pointer to a (mutable) char
基本的にはconstなcharへのポインタになりますが、char* constと書いた場合のみ(ミュータブルな)charへのconstなポインタになるということみたいです(機械翻訳みたいになってしまった)
要はポインターがconst、つまり後から変えることが出来ないアドレスを宣言するときは3番目を使うようです。
回答者によれば多くの人はこの理由でconstを右側に書く記法を好むらしいです。
イミュータブルなchar型の値でだよ、ではなくchar型のイミュータブルな値だよ、の方が一般的ということですね。
頭の片隅に残しておこうと思…っても多分残らないと思うのでここに残しておきます。
Visual Studio 2019を入れたりC++触ったり
特に躓くこともなかったので単なる記録。
数年ぶりにC/C++また触ってみようと思い立つ(またといいつつC++は殆ど触ったこと無いけど)。
別にgccでCLIでも良かったけどこの辺でIDEちゃんと使えるようになっときたいのでVisual Studio 2019をインストール。
CodeじゃないVisual Studioを入れるのは数年ぶり。
過去のPC何台かにインストールしたときは使い方よく分かんないくせにクッソ重いソフトみたいな印象しかなかったが、いま入れてみるとVM動かしてる横で起動してもそこまで時間かけずに起動するし(流石にVS Code並とは行かないけど)、動作も特に重いとかもなく普通に使えて少し拍子抜けした。
あとプログラムの実行の仕方が最初からコメントに書いてあって親切だなと思った
初回立ち上げからソリューションがどうこうあたりまでの操作は以下のサイトを参考にした。
ついでに流し読み。
- <<や>>のストリーム演算子は複数連結できる。
- 名前空間はusing namespaceで明示できる。
- ポインタの*は int *p とも int*p とも int * pとも書ける。
- 宣言時の*pと後で使うときの*pは同じ表記だが意味が違う。
- int *pは*pという変数を宣言しているわけではなく、この「*」は「pがポインタ型変数であることを示す」符号。
- *pではなくp自体がポインタ型変数なので、アドレスの代入はp=&xのように「*」抜きで表記。
- *p=5 や cout << *p などと書くときのの「*」は「pのアドレスの場所の中身を操作しますよ」記号。宣言時の「*」とはポインタ関連の操作ですよくらいしか合ってない。
- 配列の宣言時に長さを変数では指定できない。Array[n]みたいなのを作るならnを定数にするか、int* a = new int[n]などのようにnewを使う。
始めました
思いつきで初めました。
Technology Acquisition Log 日記、たるにっきです。
むかし非公開で技術日記というのを一時期やっていたことを思い出しました。
その日出来るようになったことや新しく覚えた知識、解決したりしなかったりしたエラーなどを記録することで励みにしたり後から振り返れるようにするものだったと記憶しているんですが、途中で飽きてしまったものの今にして思えばなかなか良い試みだったような気がします。
また一方で自分の記憶が年々怪しくなってきており、数ヶ月前には苦労して乗り越えたはずの難所の勘所が完全に記憶から欠落していたりして無限地獄常に新鮮な気持ちで環境構築に臨める贅沢からもそろそろ卒業したいねということで、ブログの形で再開してみることにしました。twitterに投下するには文量が多く、Qiitaとかにドヤ顔で書くほどにはまとまりがない、オビタスレンジ*1な内容を想定しています。
メインブログ(いまにいたる)すらろくに更新出来てないのに更に分けるような事をしていますが、早い話本体は近況報告や一般的な話題である程度纏まった内容のもの、こっちは技術メモ代わりの雑記帳くらいの感じで使い分けていければと思います。
さて公開でやるからにはそれなりに継続できないと格好が付かないのですが大丈夫なんですかね…
*1:帯に短く襷には長い
