ライブラリを使わずにC#でQRコードを生成してみる - Qiita
はじめに 「QRコードを手計算＆手書きで書けたらかっこいいのでは？」と思い立ち、QRコードの仕組みを勉強しました。 しかしその仕組みは想定の１億倍難しく、到底手計算できるものではありませんでした。 ではせめて…ということで、ライブラリに頼りがちなQRコード生成を１から自分でやってみることにしました。 前提 C#のコンソールで入出力を行います。 QR バージョン1、エラー訂正レベルはH、英数字モード、マスクパターンは011で固定とします。 バージョン1、エラー訂正レベルHの場合はデータコード数9、エラー訂正コード数17です。 バージョン1では21×21マス。下のような構造になっています。数字はビット番号を示します。 生成の流れ データ領域に入れるデータの作成 データをコンソールで入力 データコード語の作成 誤り訂正コード語の作成 QRコード配列の作成 固定領域 データ領域 マスク処理 形式情
【C#】TCP/IPサーバで通信の切断を検出する - Qiita
TCP/IPサーバでクライアントと通信している時、クライアントとの接続が切れた場合の処理のまとめです。 接続が切れたとは、以下の場合です。 クライアントが回線を切った クライアントが強制終了した ケーブルが外れるなど通信経路が切れた クライアントが接続を切った クライアントがshutdownを実行して回線を切った場合、サーバーのNetworkStream.Read()は長さ０の通信を受け取って終了します。
ahamoでは通信の最適化が行われており、非適用するには郵送での書面対応を行う必要がある模様かつ非適用の確認は不可らしい。
これ2014年の頃のふるーい記事なのですが、当時はソフトバンク（44020）にて、通信の最適化を実施しており、JPEGの画像が勝手に圧縮されるという事象が起きていました。 当時の検証では、146.28KBの画像をソフトバンク回線でダウンロードした結果、40.47KBに圧縮（改変）されているという結果が得られていましたね。 それに伴い、スマホゲームなどで「ソフトバンク回線だと正常に動かない！」などの問題が発生してから大きく「通信の最適化」というワードが広まり、散々騒動になってひっそりと最適化を停止したという経緯が有ります。（それで懲りたのかそれ以降再度適用はされず、今では表記が消滅） なおauも後ほど同様に通信の最適化を開始したのですが、ソフトバンクの騒動を見たからなのか解除をすることが可能となっていました。（今では表記が消滅） 2018年にmineoが実施しだして数年ぶりに騒動再発 通信の
Dissecting Performance of Production QUIC の備忘録 - neko--suki’s blog
twitterで見かけた、「Dissecting Performance of Production QUIC」という論文の備忘録 Nice paper on how QUIC being faster in theory doesn't always make QUIC faster in practice, due to implementation details:https://t.co/j4EbEkgPwZ BTW, this kind of thing is why I often find high-level design discussions that don't really dig into the details to be overrated. pic.twitter.com/xPkChrZVVp— Dan Luu (@danluu) 2021年8月7日 htt
フリーランスから法人成り、 やること多すぎヤバすぎの巻｜夏野かおる
Conclusion First（結論から先に）で行きますと、 法人化はめっちゃ大変です！！相応のメリットがないと心折れちゃうのでマジで注意！！って話をこれからします！！！ （本当に大変だったので、いつもより熱量高めの導入となりました。） ■フリーランスから法人成り（1人会社を設立）しました先日、フリーランス（個人事業主）から法人成りしました。理由は後に詳述しますが、仕事の実態的にも、金額的にも、精神的にも、「そろそろ個人では限界があるな」と感じていたことがきっかけです。 現在は会社の設立が終わり、各種の手続きのために登記簿謄本（履歴事項全部証明書）を取り寄せている途中なのですが、会社を作るのって、もう、とにかく、書類が、いっぱい必要です。 （やってられなかったので、謎のネコでデコりました。以降、随所で登場します。） 私は書類への記入および管理がものすごく苦手で、受験では希望学部を書き忘れ
昔ながらのプログラマが躓いた Android アプリ開発のポイント - Qiita
これって何の話？ 私は元々 C/C++ や Java で PC のデスクトップまたはコマンドラインで動作するアプリケーションを主に書いていたのですが、いまは Android アプリを書くことが多いです。 昔ながらのデスクトップアプリやコマンドラインアプリの開発から入ったプログラマから見ると、Android アプリの開発には大きなカルチャーギャップがあります。それが原因で Android 開発が思うように行かなかったり挫折しちゃってる人もいるんじゃないかなと思ったりします。 そこで、そんな昔ながらのプログラマのために、押さえておきたい Android 開発のポイントを書いてみたいと思います。 エントリポイントはどこだ？ 昔ながらのプログラマにとってコンピュータプログラムは「始まりと終わりが明確にあるもの」です。 たとえば以下のような C のプログラムを見てみましょう。 #include <s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
