PCがあれば何でもできる!スマートフォン用の表示で見るPCがあれば何でもできる!へっぽこアラサープログラマーが、覚えたての知識を得意げにお届けしますこの広告は、90日以上更新していないブログに表示しています。EncryptでSSL化したサイトに、もうすぐ証明書の期限切れが来るというメールが。cronで期限の更新も自動化したはずなのに...。いうことで調べてみると、以下のようなエラーが発生している。command.どうやらPythonパッケージのpycparserのハッシュが不一致となり、エラーになってしまう様子。下記の記事で、同様の現象が発生しているとの報告が多々あり、解決法まで記載されました。こちらが10/3からの記事で、私がこの問題に直面したのも10/3なので、偶然にもリアルタイムで体験してしまったようです^^;解決法をまとめると、certbot-autoのスクリプトを以下のように修正。お互いにjavascriptなのに、送受信の度にjsonで表現できないオブジェクトを、元の状態に戻すのがめんどくさい。"2016-01-01T00:00:000"}としか表現できない。moment(resData.date);こんな感じにしないといけない。これが、ブラウザのリクエストをサーバーが受け取った際サーバーのレスポンスをブラウザが受け取った際の2箇所で発生するため、サーバー側とブラウザ側に同じような処理を書いているうちに、だんだん馬鹿らしくなってくる。そこで、うまく通信をシリアライズ化して、面倒を減らせないかなという目論見のもと、↓のようなコードを書いてみた。reviver);}やっていることとしては、definitionsに定義された、オブジェクトが見つかると、特殊な記法に変換する。1};console.log(serializer.serialize(reqData));だと、こんな感じの出力になる。1}後は、$serializeというキーを探して、定義をもとに変換しなおしているという流れ。ここまでできたら、expressとangularそれぞれに、このシリアライズ処理をやってもらうだけ。angular側はこんな感じ。transformRequestとtransformResponseを使って、シリアライズ処理を入れる。毎回指定するのが面倒なら、defaultのtransformに設定してもいいけど、他サーバーとの通信も考えると、ラップするような形がいいかも。'text',}).then();express側はこんな感じ。json変換時のreplacerとreviverを指定できる。}));これで後は、definitionsに書いているオブジェクトに関しては、何も考えないで受け渡しができる。deepなクローンでもない、シンプルな処理なので、重くはないはず。Takeuchi氏のjapanese-holidays-jsを発見。holidays.元ソースは、あまり自分に馴染みのないCoffeeScriptで書かれていて、TypeScriptで使うのに、型定義作ったりラップしたりでも良かったのですが、ソース理解や今後弄りたくなることも考慮して、TypeScriptに焼き変えてみました。計算するためのライブラリです。Outの無料化が、被災地の電話回線の輻輳を引き起こす可能性がある。この話題が、炎上しながら一気に広まり、結果的に短い時間で多くの人に伝わって良かったなぁと思っています。批判を通り越してもはや中傷...。Outの無料化は、話題になっている程ひどいものだったのでしょうか?私の結論から先にお伝えすると...。確かに、電話回線が圧迫する可能性があるものを、ばんばん使っても良いように伝わってしまったのは、やはりまずかったと思います。Outの無料化自体は、とても素晴らしい判断だったと思います。理由は、以下の3つのメリットがあるためです。Outから固定電話や携帯電話にかける場合は、発信側がインターネット回線で、受信側が電話回線を利用することとなります。Outで被災地にかけてしまうと、話題の通り被災地の輻輳を引き起こします。逆に被災地から外にかけると、どうでしょう?この場合は、被災地の電話回線に負荷はかかりません。被災地の電話回線が輻輳状態で、緊急連絡すらままならない状況でも、通話が可能ということです。いえ、今度はインターネットの帯域を専有したり、他に未知のボトルネックがあったりというリスクはありますので、やはり緊急時に限定した方が良いことは確かでしょう。金銭面の圧迫を防ぐこれは説明不要だと思います。Outの通話料は前払い制。Outを使う前に、コールクレジット(前払い金)の購入の必要があり、もし月額プランとするなら、プランの選択や、クレジットカード登録等の決済設定までしないといけません。この前払いの仕組みを理解し、決済操作を行うというのは、知らない人にはかなりの負担ですし、そもそも仕組みを理解していても、電池残量を節約したい状況でやりたい操作ではありません。いった状況だったのが、無料化したことによって、決済操作を完全にスキップして、いきなり通話可能となったのです。被災地から連絡したい相手が携帯電話か固定電話以外の連絡手段を持たない緊急連絡したいの3つの条件が揃った場合になります。この条件に合わない場合は、一般的な対応を行うのが良いと思います。パケット通信費を考慮すると、Wi-Fiに繋がる、またはパケット定額に入っているも含めて検討する必要があります。Wi-Fiは、ドコモ、ソフトバンク、AUが、現在00000JAPANというWi-Fiを無料開放していますので、そちらを利用すると良いと思います。Outが大活躍したかもしれない今回は、被災直後に目立った輻輳は起きていませんでした。Outが一方的に悪になってしまいました。輻輳が起きてしまっていて、緊急連絡すらできない状況になっていた場合を想像してみてください。Outで被災地から発信することで、緊急連絡をできた可能性がありました。電話回線に負荷をかけないため、輻輳も少なからず軽減したと思われます。Outは、かなり繋がりにくく、実質大きな問題にはならなかったと思われる)少し都合よく考え過ぎかもしれませんが、可能性は低くないと思います。考えると、被災直後に無料化したLINEのスピード感は、やはり素晴らしかったのではないでしょうか。10分間という制限を設けたか無料で長時間使わせたくない、そういった理由があるのかはわかりませんが、他にも重要な効果があります。Outのサーバーのリソースも有限なのです。使いすぎれば結局、電話回線と同じように混線する可能性があります。いう意味で10分という制限は、長すぎず短すぎず、バランスのとれた時間ではないかと思います。被災地だけ無料化しなかったのか確かに、被災地だけ無料化すれば、外から被災地にかけてしまうリスクも低く、今回のような問題には発展しなかったと思います。しなかったのはなぜでしょうか。想像の範囲になってしまいますが、2つ理由が考えられます。利用者の地区情報を、アプリで取得するのは難しい利用者の地区情報を取得するには、事前に自己申告で登録してもらうか、GPSを利用して取得するのが一般的です。自己申告ではそもそも意味がありません。被災地でGPSをONにして...、なんて手順も複雑ですし、GPS自体が安定性の高いものではないため、プログラムしにくいのも事実です。決済の仕組みを変更するのに時間がかかるLINEは恐らく、日本の地域毎に決済額を変えるような仕組みは設けていないと思われます。今回のような例外がない限り何もメリットを感じません。そのため、被災地のみ無料にしようとすると、決して小規模ではない仕様変更となります。プログラムを組んだことがない人にはイメージがつきにくいかもしれませんが、大規模なシステムの仕様変更は、非常に繊細な作業で時間がかかります。例えると、ジェンガの終盤。した油断で全てが壊れてしまいます。壊さないようにじっくりやるのがコツです。そんな作業を、1分1秒が惜しいこのタイミングでやりたくはありません。デメリットがあっても、全体を無料化したのは、こういった理由からではないかと考えられます。最後に今更ですが、私はLINEの社員でもないですし、LINEに何の思い入れもありません。LINEは今回の無料化にあたり、決して少なくないコストがかかっていますし、システムに普段以上の負荷がかかることから、通常以上の技術者が長時間配置されているはずです。このように前線で支援している企業や技術者を、簡単に中傷してしまう状況は、一人の技術者として非常に悲しいことだと感じました。被災地は大変な状況です。私も、人として、技術者として、微力ながらできることをしていきます。格安SIM皆さん、格安SIM使ってますか!?私は、ちょうど1年前にドコモからIIJmioに乗り換えました!最近は色んな所で言われていますが、やはり安い。1,800円に^^;電力自由化もそうですが、独占が解消するのは素晴らしいですね!そしてこの度、妻のドコモの縛りも切れるため、IIJmioにMNP転入しました。縛り期間について改めてまとめましたので、皆さんにも共有できればと思います。MNP転出時の費用まず、MNP転出手数料がかかります。ドコモは2,000円でした。他社はAUが2,000円、ソフトバンクが3,000円とのことです。2年縛り等に引っかかる場合は、解約時の違約金がかかります。最後に見落としがちなのが、月途中解約時の日割り料金。実は、契約満了の翌月1日に解約しても、カケホーダイやパケホーダイ等の定額プランは日割り料金にならない!!当月分全て払わされます。これって2年以上縛ってますよね...、悪どい^^;ただし裏技として、1日になる前にドコモに連絡し、1日付けでパケホーダイを止める予約をしていれば、パケホーダイ分は払わなくて良くなります。基本使用料と絡んだカケホーダイは止められないし、仮にプラン変更してもさらに2年縛りがついてしまうため、素直に全額支払うのが一番良いとのこと。ひどすぎるorzちなみに、ソフトバンクは締め日が月末ではない場合があるらしいので要注意です!一度、ショップに確認するのが吉です。IIJmio転入時の費用SIM1枚につき、3,240円(税込)の事務手数料がかかります。これは新規契約でも、MNP転入でも同様です。後述のウェルカムパックを購入することで、この事務手数料を格安で済ますことが出来ます。3,240円(税込)の前払いです。店舗や通販でこのウェルカムパックを購入し、記載のコードを契約時に入力すると事務手数料がタダになります。このウェルカムパックの定価は、当然3,240円(税込)なのですが、なんと通販等で比較的安く手に入ります。現在、オススメなのは、セール中の以下の2つです。ネット上で最安ではないかと思います。Connectionという店舗が販売しているため、それが気になる方も、2つ目のAmazonが販売しているパックの方が良いかもしれません。(ちなみに店舗の評判は、かなり良さそうです)2つ目2つ目がこちら!こちらはAmazonが直接販売しているものになります。1つ目と比較すると多少割高ですが、Amazonという安心感はあります。まとめ買いキャンペーンをやっており、対象商品を3,500円以上購入すると、こちらのパックが無料になるそうです!このキャンペーンは、2016年5月9日(月)までの予定のようです。きSIMのみ縛りが発生します。違約金は、残りの縛り期間、◯ヶ月×1,000円。4月に契約し、翌月5月に解約すると、残り11ヶ月なので、11,000円かかります。12ヶ月経ってしまえば、以降は縛りが更新されることはなく、いつでも無料で解約できます。なんて良心的!(いや冷静に考えると、それが普通な気も...^^;)ちなみに、今年の夏にLINEが格安SIMを出すらしいです。なんとLINEやFacebook等の通信料は無料!!めちゃくちゃ期待してます。評判が見えてくるのを待たずに乗り換えるのは怖いので、今のうちにIIJmioに移っておいて、IIJmioの12ヶ月の縛りが切れる頃に、評判を見ながら乗り換えるか判断するのが安心かなと思っています。最後にIIJmioはインターネット事業の老舗。SIMの契約数もシェア2位なのに、速度も抜群に安定しています。JavaScriptTypeScriptでasync/awaitが使いたかったため、こちらの記事を参考にさせていただき、ビルド環境を整えました。参考にさせていただいた記事そのまま。.pipe(gulp.dest('lib')));ビルドしたソースasync/awaitでexpressサーバーを起動。functionが発生。express以外でも、インポートしたものを関数として実行するタイプだと同様のエラーが発生。'commonjs'の指定漏れ。APIを作っていて、エラー時のレスポンスをどうしようかなぁ、とごにょごにょ考えていました。できれば、エラー内容毎に、レスポンスのステータスコードを切り分けたいクライアント側でエラーの種類を判別するために、独自のエラーコードも出力したいエラー内容がなんとなくわかるメッセージは出力したいエラー内容毎に、ログに出力するか否かも切り分けたい(システム的なエラーでない限りログに出てほしくないので)の4点はクリアしたいなと。これって一般的な方法はあるんでしょうか?調べてわからなかったので、自前で実装してみました。ソースコードはこちらにアップしてます。AbstractError;Errorオブジェクトは、nameプロパティにエラー名を持っています。JavaScript標準のRangeErrorだと、RangeErrorという文字列が入っています。このnameプロパティに、this.constructor.nameで自身のクラス名を入れることによって、子クラスが毎回エラー名を定義しなくて良くなります。Original1Error;エラーメッセージが毎回変わるものではない場合、メッセージの引数はなしにして、superに固定で入れたほうが良いと思います。expandError;definitionsにエラー毎の値を設定してきます。配列の1つ目がステータスコード、2つ目がエラーコード、3つ目がログ出力の有無となっています。後は、expandError関数にErrorオブジェクトを突っ込むだけです。${server.address().port}`);});404では、自作したRouteNotFoundErrorをnextに送るだけにし、実際には最後のエラー処理ミドルウェアで処理しています。エラー処理ミドルウェアでは、expandError関数でエラーオブジェクトを拡張後、ログ出力の必要性があれば出力、最後にRESTでレスポンスを返しています。終わりに正しい実装方法があれば、ぜひご教示ください!よろしくお願いします。将範フリーランス/エンジニア(主にサーバサイド、その他広く浅く)自宅の作業場は冷蔵庫の隣。キッチンエンジニアとして日々精進しています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。