「//このコメントを消したら動かない」は大体Shift_JISの2バイト目が原因で発生する - Qiita
TL;DR Shift_JISにしただけでコンパイラが通らなくなる恐ろしい事件とその回避法について。 \ (¥)のASCIIコードは0x5c 表、能は良くない UTF-8は神 2023/12/06追記 誤りがあったので訂正します。こんな読まれると思ってなかったので正直ちょっとびっくりしていますが、いろいろコメントありがとうございました。（ツイート等全て拝見しました。） Shift_JISが悪いわけではない（デフォルトのエンコーディング設定の問題）→追記しました UTF-8にはUTF-FSSという仕様でこの問題が回避されている→マジでタメになる知識ありがとうございます OSによってデフォルトのエンコーディング設定が異なるせいで、デフォルト環境での動作がOSにより異なる→なるほど？（調査中） CRLFとLF問題では→なるほど？（調査中） そんな問題何を今更→UTF-8が出てから生まれたからです
LintオタクによるLint解説 / Introduction to Lints
https://lintnight.connpass.com/event/263931/
名前重要とは何であるか? - kawasima
DDDの世界ではValue Objectということになろうが、引数がintやstringのような型だと、利用者側で使い方を間違えないための方策は、結局その引数名に委ねられる。これをプロジェクト全体に渡って、整合性のとれた名前付けをするのは至難の業なので、その意味を表す名前を付けた型として定義するのである。
命名のプロセス - kawasima
多くの人が、1回で最高の命名をしようとする。これは難しく、うまく行くことなんて滅多にない。問題はネーミングというのは設計であるということだ。あらゆるものに収まりの良い場所を与え、正しい抽象化をしなくてはならない。これを最初の1回で完璧にこなせる可能性は低い。だから進化的ネーミングについて話をしよう。
Your code displays Japanese wrong
A static site to link people to when their code is displaying Japanese wrong. View the Project on GitHub heistak/your-code-displays-japanese-wrong Why am I here? If someone gave you a link to this page, that person probably thinks your code displays Japanese wrong. In short, from a native Japanese eye, yѳur ҭєxҭ lѳѳκs κιnd ѳf lικє ҭЋιs. This page will give you a brief description of the glyph appe
タイムゾーン呪いの書 (知識編)
「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
フロントエンドの
良い設計、良いコードを考える
JavaScript: Past, Present, and Future - NDC Porto 2020
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
乱数チューニングによる動きのコク
乱数チューニングによる動きのコク 1. 一様乱数 いわゆるMath関数による乱数。 雑味や臭みが強く、そのままでは使い物にならない。 2. 雑味を取り除いた乱数 下処理として臭みや雑味を取り除いた状態。一様乱数特有の発作的なガタツキがないのがわかるだろうか？ 過去2フレームに、距離33%以内の重複数が出ないようになっている。 シャッフルやスロットのアニメ処理など、2連続で同じ数字が重なるとバグって見える表現に有効。 3. コクのある乱数 乱数の旨味が濃縮された状態。中心極限定理により、自然な風合いに濃縮されている。 加算式による天然の正規分布は、ボックスミューラー法の養殖された乱数と違い、加算回数で生産者ごとの味わいが出せる。 パーティィクルや自然シミュレーションと相性が良い。 4. 芳醇なまろ味を出した乱数 口に含んだ後に、豊かな香りが広がる乱数。移動平均により連続性を出すことで、揺らぎ
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
「タブ区切りは CSV じゃなくて TSV だろ」問題がついに解決した
CSV ありますね。カンマ区切りのデータ形式。 なんか根強いファンがいて、どうしてもこの形式のファイルをダウンロードしたりアップロードしたりしたいという要望をよく聞きます。 CSV がほしい理由 これをやりたい理由のひとつとして、Microsoft Excel からエクスポートしたデータを読み込ませたいとか、逆にシステムにあるデータをエクセルで見たいとかいうのがあると思います。あると思いますっていうかほとんどそれじゃないかな。 けどこの場合、カンマ区切りである必要はないんですよね。要するにエクセルとやりとりできさえすればいいわけで。 だったらカンマじゃなくてタブですよタブ。 カンマ区切りをやめてタブ区切りにすると、いろいろいいです。 何もエクスポートしなくても、エクセルの画面で「すべて選択」して「コピー」したら勝手にタブ区切りになってるからそのまま貼っけるだけでいい。 テキストエディタなど
末尾再帰による最適化 - Qiita
はじめに ES6 (EcmaScript 6)を試そうと、Babelのドキュメントを読んでいたところ、末尾呼び出し（Tail Call）の最適化をしていることにびっくり。公式リリース（2015年6月）から３ヶ月あまり経ってはいますが、ES6が末尾呼び出し最適化を仕様としてサポートしていることをようやく知りました。 現状で末尾呼び出し最適化をサポートしているブラウザはなく（ブラウザやaltJSなどのES6互換表を参照）、唯一、ES6からES5へのトランスパイラであるBabelのみが部分的（直接的な末尾再帰のみ）ではありながらサポートしているようですね。 今回の記事では、来たるES6時代（いまさらの感はありますが）に備えて、末尾再帰とその最適化について簡単に解説した上で、Babelを利用して実際にJavaScriptでの末尾再帰の最適化を実験してみたいと思います。 ざっくり概要 再帰関数 は関
)
モナド (プログラミング) - Wikipedia
関数型プログラミングにおいて、モナドはプログラムを構造化するための汎用的な抽象概念である。対応したプログラム言語では、ボイラープレート的なコードでもモナドを使って除去することが可能となる。これはモナドが、特定の形をした計算を表すデータ型と、それに関する生成と合成の2つの手続きを提供することによって実現されている。生成は任意の基本型の値をモナドに包んでモナド値を生成する手続きであり、合成はモナド値を返す関数(モナド関数)たちを合成する手続きである。[1] 広い範囲の問題をモナドを使うことで単純化できる。例えば、Maybeモナドを使えば未定義値への対処が簡単になり、Listモナドを使えばリストに入った値を柔軟に扱うことができる。複雑に組み合わさった関数は、モナドを使えば、補助データの管理や制御構造や副作用を除去した簡単なパイプライン構造に置き換えることができる[1][2]。 モナドの概念や用語
モナド入門以前 - Qiita
前書き これはモナドチュートリアルではない、だろう。 この文章を書く動機は、モナドを知らない人がモナドという未知の概念に期待しているものが根本的にずれているかもしれないという懸念である。 命令型言語でプログラミングを覚えた人がモナド、もしくはHaskellや関数型言語（と言われる言語）を学習する際にしばしば受ける助言はこうだ： 「命令型言語で今まで習ったことを全て忘れて取り組むと良いよ」 この助言はそこまで外していないかもしれないが、雑である。 いつか僕の友人がこのようなことを言った： 「プログラマがチームで働く時、必要なのは相手を思いやる気持ちだよね」 この発言は恐らくそこまで外れてはいないが、思いやりで全てを解決しようとすると、全てのコストが非常に高くなる。個々の問題へ目を向け、それぞれの解法を知っておくことによってコストは低くすることが出来ると僕たちは知っている。まあ友人はそんなこと
EnumeratorとEnumerator::Lazyの違い - Qiita
はじめに Ruby 2.0では、Enumerable#lazy というメソッドと、その返り値である Enumerator::Lazy が導入されました。 この記事では、Enumerable#lazy と Enumerator::Lazy によって無限リストをmapできることを紹介します。 また、Enumerator と Enumerator::Lazy の本質的な違いを説明します。 遅延リストとは 遅延リストですが、Haskell などの一部の関数型言語では一般的に使われているもので、 遅延評価といって、値が必要になるまで計算しないことによって、無限に続くリストも扱うことができるというものです。 無限リストをmapする 普通にやってみるとダメ 次のような無限リスト(無限の長さを持つ Range オブジェクト )を map する式[1]を考えてみます。 この式は実行が終わりません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
AtCoderではじめる競技プログラミング|Tech Book Zone Manatee
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
日本人が間違いやすいコーディング上の英語 - Qiita
