Goで作ったJSON文字列をPHPに食わせたらエラーになったので、そのへんのまとめです。
ちなみに上の表現はちょっと正確ではないんですが、まあ気にしないで下さい。あとでわかります。
Goで作ったJSON文字列をPHPに食わせたらエラーになったので、そのへんのまとめです。
ちなみに上の表現はちょっと正確ではないんですが、まあ気にしないで下さい。あとでわかります。
タイトルの通りです。正確にはひっかかったフリをしてみたという、いわゆる「やってみた系ブログ」です。そんなジャンルあるのか知りませんが。
なお、いまのところオチも何もない尻切れトンボ状態です。それでもよければ話の種にどうぞ。
以前、WebAPIのパラメーターにキャメルケースを使うかスネークケースを使うかという記事を書きました。
そこでは「統一されていればどっちでもいい」という当たり障りのないことを書きつつ、URLにではアンダースコアが使えないよー的なことも書きました(RFC952のことをすっかり忘れていてお恥ずかしい)。
今回はそれに対する補足です。
昨日11月27日は日本最大級のJavaScriptカンファレンスJSConf JP 2021の開催日でした。去年はコロナの影響で中止だったのですが、今年はオンラインで開催です。
そして、今年はなんとスタッフとして参加しました。いや前回もでしたが。
発表内容は他の参加者が各々ブログにまとめてくれていると思うので、今回はスタッフとしての
多分初めてのC++エントリーです。
ここ何年もC++でまともにコードを書いていないんですが、最初に見たときからどうしても全身がムズムズする文法があります。
純粋仮想関数、お前のことだ。
TypeScriptのenum
について。
あちこちで「enum
はアカンからunion型を使え」と言われていますが、その理由や「本当にenum
はいいところないの?」「unionはenum
の移行先として適切なの?」などをいろいろ検証してみましょう。
最後に「こういう仕様ならいいのに」という妄想もあります。
今年の10月にLet's Encryptであんなことが起こってしまい、Windows Updateをしていない世界中の古いマシンでLet's Encryptを使ったサイトが表示できなくなってしまいました。
それはそれとして、古いサーバーマシンでも似たようなことが起きているんじゃないかと思います。
具体的には、サーバーがスクレイピングやAPIコールなどのために外部サイトにアクセスする際に、サーバー側に古いルート証明書(DST Root CA X3)がインストールされていたために外部サイトへのアクセスに失敗したというパティーン。
今回はこの対処法について。ちなみにこの方法はUbuntu 14.04で確認しています。
POSIX sed(macOS標準)とGNU sed(Linux標準)とで微妙に書き方が違うので、どちらでも動くようにシェルスクリプト等を書きたい場合の注意事項をちょっとまとめてみました。
縛りプレイとして、sedコマンドだけで対応するものとします。つまり、パイプやリダイレクト、他のコマンドとの併用などは行わないものとします。
以下の内容は、macOS(POSIX sed)とLinux(GNU sed)の両方で動くことを確認済みですが、どちらも割と新しいバージョンで確認したので古いバージョンでは使えない可能性もあります。ご注意ください。
現在TypeScriptで作っているウェブアプリケーションがあるんですが、先日ESLintのバージョンを7系から8系に、typescript-eslintのバージョンを4系から5系に上げたところ、今まで出なかったエラーが出てきました。
問題を指摘されたのは以下のようなコード片です。
class Foo { @decorator bar: number; }
一見問題なさそうに見えます。実際文法的には問題ありませんし今までは特に指摘されてきませんでした(ここだけ見るとbarが初期化されていませんが、あくまでコード片です。実際にはコンストラクターで値を割り当てています)。
何がアカンのかというと、barのインデントだそうです。こうしろと。
class Foo { @decorator bar: number; // ←こうしないとエラー }
えっ。こんなコーディングスタイル見たことない。
新しいルールが追加されたのかと思って、これを無効にするオプションを探してみたんですが特に見つからず。
文字列はシングルクォートとダブルクォートのどちらで囲うべきか、ときどきコーディングスタイル論争に上がりますね。もちろん、JavaScriptとかPythonのようにどっちを使っても文法上問題ない言語に限ります。CやJavaでは必ずダブルクォートを使わなければいけません。
今回のテーマは、そんな今更感あふれる話題です。
コロナの影響で中止となった幻のTSConf 2020で、TypeScriptとES Modulesについて登壇する予定でした。
最近のTypeScriptは、モジュール関連で新たな仕様が出てきたようなので簡単にまとめておきます。前職同僚でNode.js Core Collaboratorのshisamaおよびdeno-ja Slackコミュニティーからの情報を勝手に集約しました。みなさんありがとうございます。
Node.jsとDeno界隈に一大センセーションを巻き起こした(※個人の感想です)データ検証ライブラリーvalue-schemaの新バージョンがリリースされました。
今回の目玉はenumeration()
です。名前の通り、TypeScript(Deno含む)でenum
等の列挙型を使うときに真価を発揮します。
SequelerというLinux用のDBクライアントがあります。名前が似ていますがmacOS用のSequel ProとかSequel Aceとは別物です。
Linux用のツールですが、Gentoo用のリポジトリーに入っていなかったので自前でebuildファイルを作りました。
サクッと作って終わり!というわけではなかったので、ちょっと苦労話でも語らせてもらいます。興味のない方はebuildファイルだけパクってトンズラこいても大丈夫です。
Jestで特定のテストだけ実行したい場合ってあるじゃないですか。
ここに書いてあるとおりjest path/to/my-test.jsのように実行したんですがNo tests found, exiting with code 1というメッセージが出て何もテストできずに終了。テスト対象のファイルもちゃんと存在してるし意味がわからない。
しばらく悩んでも答えが出なかったので放置していたんですが、ある日こんな指摘をもらいました。
「Jestの引数はファイルのパスじゃなくて正規表現パターンだよ!」
どれどれ。。。
引数を付けてjest
コマンドを実行した場合、その引数はプロジェクト配下のファイルを照合する正規表現として扱われます。
ほんまや。
それが何か関係あるの?と思った方。実は、テスト対象のファイルには$
が含まれていたために正規表現のパターンとしてちゃんとマッチングしなかったようです。
解決方法は2つ。要はメタ文字を無効化すればいいので、
$
を[$]
で置き換える$
を\\$
で置き換える
このどちらか。後者は単に\$
だとバックスラッシュがシェルに吸収されてしまい、Jestにはただの$
が渡されます。
偉そうに解説していますが、アホらしいミスをやらかしました。。。
半年以上前にDroneでRedisクラスターを使う記事を書きましたが、localhostでしか動かないRedisクラスターはテスト用とはいえ使い物にならないので、まともに動くようにしてみました。
結論から言うと、横着せずにちゃんと3台以上でクラスター作れよってことです。
タイトルのとおりなんですが、GentooでChromiumをビルドしていると急にマシン自体が落ちました。ビルドエラーが起きたとかビルドプロセスが落ちたとかじゃなくてマシン自体が落ちました。
何が起きたんだと思って再起動すると、「CPUが熱暴走したからマシン落としたよ」的なメッセージが。マジか。
まあ確かにChromiumはビルドするファイルも多いし時間もかかるけど、今までこんなことなかったのになぁ。ちなみにビルド時のnice値(PORTAGE_NICENESS
)は15。とってもナイスな値なんですがそれでも熱暴走しました。
結局どうしたかというと、Chromiumビルド中は扇風機で風を送り込むという極めてアナログ&原始的な方法で解決しました。もしかしたら並行処理の数を減らしてもよかったかも。
goroutineはスレッドのようなものと説明されることが多いですが、一方でノンプリエンプティブ、つまり空の無限ループのようなコードを書いたら他のgoroutineにも処理が移らずにハングしてしまうとも説明されます。処理の切り替わりタイミングはめちゃくちゃ大雑把に言えばNode.jsのasync/awaitのようなものだと思ってください。内部処理は結構違いますが。
今までそう思っていたんですが、どうやらGo 1.14からプリエンプティブになったようです。Goを真面目に勉強している人にとっては今更感が強いでしょうけど、つい最近知ったんで勘弁してください。
見たのはここの記事。今回はそれについての検証です。
現在、とある事情により普通のSSL証明書(Let's Encryptとかで取得したやつ)をオレオレCA証明書でクロス署名するという怪しげなことをやっています。
そんな怪しい証明書はどうやって作るんだと気になった方は今後の記事を楽しみにしていてください。そのうち説明します。
正しくクロス署名できているかを確認するためにopensslコマンドで検証しようと、以下のようなコマンドを入力してみました。
openssl verify -CAfile oreore-ca.pem -untrusted inter.pem server.pem
oreore-ca.pem
がオレオレCA証明書、inter.pem
が中間証明書、server.pem
がサーバー証明書です。
この方法で無事OKのメッセージが出て検証成功したんですが、念のためにエラーケースも確認しようと-CAfile
に全然関係ないルート証明書を指定したところ、なぜかそれでも検証成功してしまいました。
今回はその奮闘記です。上の情報だけで原因と解決方法がわかった方はこの記事はスルーしてください。
なんとなく書きたくなったので、ここに書き散らしておきます。エンジニアに限らない話かもしれませんが。
最初に言っておきますが、退職者が常に大量出ている(そしてそのために常に大量に新規募集をしている)ような職場の話ではありません。人が入っては数ヶ月で辞めるを繰り返している職場はなにか慢性的な問題を抱えていると思いますが、そのあたりの話はここではしません。
退職は必ずしも後ろ向きな理由だけではなく、さらなるステップアップのために退職することもあるので一概によくないことというつもりはありませんが、短期間に大量に退職者が出るということはステップアップ以外に何かしらの理由があると思うので対策を打ったほうがいいかもね、という話をします。
結論から言うと、会社の内部に理由があることもあれば外部に理由があることもあり、それ以外の理由のこともあります。「全部言えばどれか当たるに決まってるだろ何いってんだこのクソ雑魚無能手品オタク」と思うかもしれませんが、理由がいろいろあるということは理由を見誤らないようにしないといけないということでもあり、見誤るとさらなる退職者が出る可能性があります。
それでは見ていきましょう。
Install SSH Keyの最新版v2.3.1を公開しました。上がったのはパッチバージョンということから推測できるとおり、割とショボ目の変更です。
以前から公開していたInstall SSH Keyですが、「そういえばGitHubのコード検索を使えばどれくらい使われてるかわかるんじゃね?」と思ったので試しにエゴサしてみました。
2019年の12月に、Qiitaで「AmazonのAPI設計方針(The Bezos Mandate)」という記事を書きました。
元々この記事を書こうと思ったのはJSConf JP 2019のセッション「覚醒するアクセシビリティ」を見たのがきっかけで、このブログでも似たような記事を書きました。
その記事がここ数日で急激にLGTMやらストックやらが増えたのでビックリ。多分インフルエンサー的な人が広めてくれたんじゃないかと思いますが、ありがとうございます。
いい記事なので、みなさんもぜひ読んでください。いい記事といっても、発言者のベゾスと一次記事を書いたスティーブ・イエッジがいいだけなんですけど。
タイトルを見て「ああ、アレのことね」と思った方。はい、アレです。というかURLでネタバレしてます。
アレを知っている人にとっては別に目新しいネタではないと思いますが、先日教えてもらったのでメモとして残しておきます。
先日のAPIに関する記事で「Unix系OSではチルダはログイン中のユーザーのホームディレクトリーを指す」と書いたんですが、現在技術顧問をしている会社のインターン生から先日その背景を教えてもらったのでメモ。
ギークおじさんにとっては常識的な話かもしれませんが、二十歳そこらのインターン生が調べて教えてくれたことに感動しました。君が産まれる20年くらい前の話だよ。
Goでクラスっぽいものを実装するときにレシーバーを使うわけですが、これは値レシーバーとポインターレシーバーの2種類があるそうな。
で、何度調べても値レシーバーの使いどころがわからない。
コンパイル方式の言語(TypeScriptとかのトランスパイル方式含む)では、プロジェクトのルートディレクトリーの下にsrc
とかsource
のようなディレクトリーを作って、その下にソースコードを置く場合も割とあると思います。
前まではGoで開発するときもこのようなディレクトリー構成にしていたんですが、別の場所にあるファイルを参照するときやライブラリーを開発しているときに、参照元から
import "example.com/package-name/src/file"
と書く必要があって、なんかsrc
がジャマだなーと思う今日この頃みなさんどうお過ごしでしょうか。
参照パスにsrc
が入るのはなんかモヤっとするので最近ではsrc
ディレクトリーを作らずにプロジェクトルートにメインとなるファイルを入れています。でもやっぱりソースコードは他のファイル(設定ファイルやらリソースファイルやら)とディレクトリーを分けたいという気分です。
多分これはGo固有の話なので、他のコンパイル方式では普通にsrc
ディレクトリーの下に放り込んでも問題なさそうです。
src
以下に入れる。src
つきで参照しようが特に気しない。
src
ディレクトリーは作らずにむき出しで入れる。ビルド結果が別ディレクトリーに出力されれば問題ない。
src
以下に入れてもsrc
をつけずに参照する方法を知っている/使っている。
どれだろう。
以前「Linux版ChromiumでGoogleスライドの表示がおかしい」という記事を書いて、その後のアップデートで直ったんですが、今度は別の問題が出ました。
GoogleドキュメントやスプレッドシートにIMEで「1文字だけ」入力しようとしても、その文字が入力されずに改行だけされます。2文字以上ならちゃんと入力できますし、1文字でもIMEを無効化して直接入力したり、エディターからコピペすれば問題なく入力できます。例によってFirefoxなら問題ないので、多分Chromium側の問題です。
問題を確認したChromiumのバージョンは 91.0.4472.77 です。これもバージョンアップで直るのかしらん。
現在とあるウェブアプリケーションを作っているんですが、REST APIで特殊な条件でリソースを絞り込みたい場合があったので、「こうしたらええんちゃう」という考えをまとめてみました。多分特別あたらしいアイデアでもないです。誰かが似たようなことか、もっといいことをすでに書いていると思います。
一応言っておきますが、これはただの案で正解とは限りません。いろいろ試行錯誤した結果、これが個人的にわかりやすい気がしたというだけです。
REST APIの基本的な設計は理解している前提で書きますので、基本設計が不安な方は適当に調べておいてください。
今回はマジでどうでもいい話です。技術も何も関係ありません。
大阪の梅田駅も東京の新宿駅も日本有数のダンジョンとよく言われています。こういう記事を見ると、梅田が一位だそうです。
でも個人的には何度行っても新宿のほうが難しいようにしか思えないんですよね。東京に7年、関西に10年以上住んでいますが、新宿駅のほうが訪れる機会が少なかったことを差っ引いても新宿のほうが難しいと感じています。
その理由は新宿駅の西側のとある場所。うまく説明できませんが新宿駅に何度か行ったことのある人ならわかるはず。
地下なのに吹き抜けで空が見える場所があるじゃないですか。あそこでいつも地上だと勘違いして感覚が狂います。こいつのせいでまともに新宿を攻略できたためしがない・・・最近やっとこいつのせいだと気づきました。
あと、地上への階段をのぼったところにある陸の孤島(バス停)に何度か迷い込んだ気がする。
以前、さくらのナレッジにいまさら聞けないNode.jsという記事を投稿しました。そこの「C10K問題の解決方法」という項目に
構成によっては、同じウェブサーバー内でApacheの前段にNGINXを配置するだけで負荷が下がることもあります。
と書いたところ「なんで?」という問い合わせがあったので、ちょっと解説します。
単純に考えるとNGINXのプロセスが走る分負荷が上がりそうな気がしますが、どういうからくりがあるのでしょうか。
Denoifyという、Node.js向けに書いたソースコードをDenoで動くように変換してくれるツールがあります。もちろんあらゆるコードを100%変換できるわけではありませんが。
このツールの存在を1年ほど前に教えてもらいました。
本 人 か ら 。
タイトルの通り、LinuxでWiFiが割と頻繁に(数分〜数十分に1回程度)瞬断しています。今に始まった話ではなく、1年近く前からこの問題はありました。
環境を簡単にまとめると、
です。
先日の記事の続報です。
結論だけ言うと、Chromiumのバージョンを最新版の90.0.4430.72に上げたら遡らなくなりました。やっぱりChromiumの問題だったんですかね。
あと、スライドだけでなくドキュメントもちゃんと表示されるようになりました。めでたしめでたし。
久しぶりにGoogleスライドでプレゼン用のスライドを作ろうと思ったらわけのわからないことになっていました。
まあまずこれを見てくれや。Googleスライドで新規プレゼンテーションを作成して、Chromiumでそのまま開きました。一切加工はしていません。
単に文字が重なっているだけじゃなくて、化けているようにも見えます。
心なしか
と言っているようにも見えるのは気のせいでしょうか(※気のせいです)
MySQLのGUIツールとして、公式のMySQL Workbench(以下Workbench)を使っている人も多いと思います。Windows/macOS/Linuxに対応していて、何よりMySQLが公式で出しているという安心感がヤバいです。
そんなWorkbenchは以前まではGentoo Linuxの公式リポジトリーにも用意されていたので愛用していたんですが、公式リポジトリーから削除されてしまいました。Python2.7のサポート終了に伴い、3系列に対応しておらずしばらく更新されていなかったためだそうです。
ある日、Workbenchのバージョン8.0.23でPython3に対応したっぽい情報を仕入れました。しかしGentooの公式リポジトリーは音沙汰なし。仕方ないから自分でebuildファイルを作ってインストールして使っていました。
せっかく作ったんだし公式に導入してもらおうと思って先日pull requestを作ろうと思ったところ、いつの間にか公式に復活していました。
公式が復活したならもはやオレオレリポジトリーを作る意味はない、ということでWorkbenchに振り回された数カ月間でした。特にオチはありません。
今までこのブログでも何度か紹介してきたパスワード管理ツールのEnpassですが、Linux版では割と頻繁に落ちる不具合がありました。
以前調べたときはlibcurlの非同期名前解決を有効にするとマシになったんですが、それでも時々落ちていました。
そんなEnpassですが、2月ごろにリリースされた6.6.0で全く落ちなくなりました。今までは起動させた状態でしばらく何か作業をしているといつの間にか落ちていることがあったんですが、今では数日間起動させたままでも落ちません。やったね!
あとは日本語の翻訳がまともになれば完璧です。
ちなみに、一時期iOS版とMac版でDropboxの同期ができなくなる不具合がありました。ちょっと焦った。
以前LinuxでPIXELA PIX-MT100を使うという記事を書いたんですが、その後継記事です。
PIX-MT100の後継モデルとしてPIX-MT110があります。というより前回の記事を書いた時点ですでにMT110は発売されていました。無知って怖い。
今回のMT110は、MT100と違って公式に3キャリア対応を謳っています。前回の記事で書いたとおり、MT100でも実際は3キャリア使えたんですが、公式で謳っているほうが安心できますよね。
ちなみに今回の記事も前回同様Gentoo Linuxの話です。Ubuntuは多分そのまま動きます。試してませんが。
まあタイトルの通りなんですが、悪さをしているDockerコンテナのIPアドレスだけわかっているときにコンテナを特定したいときなんかがあると思います。
「docker IPアドレス コンテナ」で検索すると「特定のDockerコンテナのIPアドレスを調べる方法」は割と出てくるんですが、その逆、つまり「特定のIPドレスを持つDockerコンテナを調べる方法」がなかなか出てきませんでした。
というわけで無駄に頑張った。
先日、プリンターを買い替えました。ネットワーク接続ができてスキャナーつきで手頃な価格のEPSON EP-713Aを選択。まあ今時はネットワーク接続できない機種のほうがめずらしいと思いますが。
WindowsとmacOSではプリンターもスキャナーも特に問題なくセットアップできましたが、Linux(Gentoo)ではスキャナーのセットアップに苦労したのでメモ。プリンターは大丈夫でした。
本当にただの推測で申し訳ないんですが、babel-plugin-module-extension-resolverのテスト中にタイトルらしき挙動を見つけました。もしかしたらただの勘違いかもしれませんし、あるいはとっくの昔に周知の事実かもしれません。
かなり試行錯誤したので発生条件を詳しく覚えていないんですが、npm install --prefix
で問題が発生した気がします。もうどのバージョンで再現するとか検証するのが面倒なので詳細は省きますが、GitHub
Actionsでカレントディレクトリー以外の場所で古いnpmを使う場合には、--prefix
ではなくworking-directoryを使いましょう。
ただの勘違いだったらごめんなさい。
ラノベのタイトルみたいになってしまいましたが気のせいです。いい要約が思いつかなかっただけです。
要するに、GolangのDockerコンテナからRedisクラスター用のスロットを作成しようとしたら"Invalid or out of range slot"というエラーが出てしまったわけです。
アホらしいオチなので最初の再現手順だけで原因がわかる人もいるでしょうが、思い込みが激しく解決に丸一日かかったので、未来の自分&他のドジっ子のために残しておきます。
原因を完全に把握できていないので、タイトルは不正確かもしれません。
イントラネットに構築した(つまり外部からアクセスできない)GitHub Enterprise Server上のGolangパッケージを取得しようとしたら"connection refused"メッセージが出ました。
最近はエンジニア採用関連の業務もちょいちょいやっているんですが、つい最近までプログラミングスクールに通っていたと思われる人からの応募が来ることがあります。
コロナ鍋禍のご時世、リモートワークに向いているソフトウェアエンジニアに注目が集まるのはとてもよく理解できるんですが、現実はそんなに甘くないと思ってください。
あるいは「プログラミングスクールを出ればスキルが身につくしリモートワークできて定時に上がれて給料が高いキラキラホワイト大手IT企業に就職できる🎶」と思っているのかもしれませんが、どちらにしても現実は甘くありません。
今回は、ソフトウェアエンジニア採用時にどういうところを見られているのかを採用する側の視点でお話しします。言いたいことが山ほどあるのでちょい長いです。
ちなみに今回の内容は、多くのスクール生が目指すであろうウェブ業界を想定しています。IT業界は色々ありますが、プログラミングスクール上がりで基幹系エンジニアになりたい!という人はあまり多くないと思いますので。そのため、以下の文章では特に断りのない限り「エンジニア」を「ウェブ系のソフトウェアエンジニア(フロントエンド / バックエンド)」という意味で使います。