Why does JavaScript's parseInt(0.0000005) print "5"?
I've read an article about JavaScript parseInt, which had this question: parseInt(0.5); // => 0 parseInt(0.05); // => 0 parseInt(0.005); // => 0 parseInt(0.0005); // => 0 parseInt(0.00005); // => 0 parseInt(0.000005); // => 0 parseInt(0.0000005); // => 5 Why is this happening?
JavaScriptの反意図性(クソ挙動)を指摘するバズツイ周辺解説 - Qiita
先日このようなツイートが話題になりましたね 無論この件は例のコインハイブ事件で言われるような反意図性とはずれる話題ですが、直感的ではないという点でうなずくものがあります 今回はなぜこれらがこのような結果になるのか、回避方法等順に説明しようと思います というのも、この中のいくつかはJavaScript固有のものではないので、他人事と思わないようにしていただきたく…… その上でJavaScriptの本当の意味でヤバイ箇所も説明できたらいいなと思います。 ①typeof NaN NaNとはNot a Numberの略、なのになんでnumberなんだ！！ この値は他のオブジェクトを数値に変換する関数parseInt(x)が失敗した場合、0*Infinity等の不確定な計算をした時に出力される値で、エラーを表現する値の一つです。 内部表現的にはただの浮動小数(IEEE754)なので、typeofがn
Goのなぜ問答
はじめに Goはできるだけ冗長な機能セットを増やさずに応用の効くシンプルで強力な機能セットに絞り込んだ設計であることを目指した言語処理系です。なのでリッチな機能を持つ言語処理系経験者からするとたくさんの「なぜ？」を感じると思います。 しかし、Goの開発者たちは他の言語処理系にある機能だからGoにも採用しようとは一切考えません。あくまで大きなゲイン（デメリットをメリットが大きく上回る）を示されるまでは採用しません。特に言語仕様についてはより変更を嫌う傾向があります。「Go1の約束」というものがあり、Go1.0向けに書かれたコードはGo1.xでも動くもしくは機械的にコードにパッチを当てることで移行可能にするということをずっと守っています（約９年？）。 最近になりGo2プロポーザルがたくさん書かれ、それらの提案のうち言語仕様に関するものは最終的に２〜３個に絞り込まれ順次採用されていくという計画で
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
【資料公開】アジャイルについてマネージャーが知るべき97のこと
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
TypeScript 型レベルプログラミング フリースタイルガイド - Object.create(null)
TypeScript の型レベルプログラミングのための真面目なスタイルガイドではありません. 型なしラムダ計算で喜ぶような人間が使うための諸刃の剣です. この記事の内容は TypeScript の 2022 年 1 月時点での最新版である 4.5.4 に基づいています. 将来のバージョンでの妥当性は保証しません. 「型〜」「〜型」という用語の「型」はしばしば省略します. 値レベルの話題は一切登場しません. 以前作った型レベル Brainfuck インタプリタはこのスタイルに則っているので参考にどうぞ. いつまでこのネタを引きずるんですか? パラメータに対して制約を付与しない 型定義のパラメータに対して extends を使って制約を付与すると, そのパラメータに与えられる引数を制約を満たすもののみに限定することができます. 例として, 以下の Append には string の部分型のみ
Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
エンジニアのための Figma 知識
本記事の多くは Inspect モードを前提に解説しています。 下記に Dev Mode に対応した解説を書いてみたのであわせてご参照ください。 https://codezine.jp/article/detail/18000 エンジニアにデザインツールの知識・習熟は必要か？ しなくても仕事はできると思うのですが、あるとよりクオリティの高い仕事ができることは間違いありません。 という訳でエンジニアがエンジニアとしての仕事をしていく上で「Figma のこういうことを知っておくと良さそう」という知識をまとめてみました。 ユースケースを考える まず始めにデザインは作らないはずのエンジニアが Figma を使う時にどんなユースケースがありそうかを考えてみます。 デザインを元に実装する時 デザインから何かを生成したい時(コードとか画像とか) 自分でちょこっとデザイン修正しちゃう この辺りがあるかな〜
「メリハリのある TypeScript」で運用しながら型安全性を高めやすい TypeScript リプレースを行う - Mobile Factory Tech Blog
こんにちは、21 卒エンジニアの id:d-kimuson です。 モバイルファクトリーでは、最近のプロダクトではフロントエンドに TypeScript を採用していますが、僕がアサインされているプロダクトは歴史が長く JavaScript で書かれていて、今回 TypeScript へのリプレースを行いました。 既存プロダクトの TS リプレースではしっかり型付けすることは難しいので、型チェックオプションを緩くしてリプレースすることが多いと思います。しかし、既存コードからリプレース後のコードまで全て型安全性が担保できなくなってしまうので、後からの strict 化は非常に大変になってしまいます。 今回のリプレースでは、型チェックオプションは緩くしない代わりに @ts-nocheck や @ts-expect-error を使用することで、段階的に型安全性を高めやすい形でリプレースを行いま
Dockerで安全にnode.jsウェブアプリをコンテナ化する - Qiita
Happy New Year! 年末、年始があっという間に終わり、明日は成人の日。 来週からコーディングのオンラインクラスを受けることになった。4−6ヶ月になりそうであるが、無事乗り切れるのか、少々不安も。javascriptを習得するコースなため、最終的にnode.jsのサーバーサイドでのコーディングもできるようになるまでの知識を得られるよう頑張ろう。node.jsの環境構築に不可欠ともいえるdocker。 今回は、10 best practices to containerize Node.js web applications with Docker の翻訳記事のご紹介です。 今回は、特に翻訳に苦労しました。読みにくい部分もあると思いますが、どうぞ最後までお付き合いください。 Dockerでnode.jsウェブアプリケーションをコンテナ化するための10のベストプラクティス Liran
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
[AWS CDK] APIを呼び出すだけのカスタムリソースならLambda関数は不要な件 | DevelopersIO
APIを呼び出すだけのカスタムリソースであれば、AWS CDKの場合、Lambda関数を使わずにAPIを呼び出してカスタムリソースを作成/更新/削除することができます。 AWS CDKを使えばAPIを呼び出すだけのカスタムリソースならLambda関数は不要らしい こんにちは、のんピ(@non____97)です。 皆さんはカスタムリソースを作成することは多いですか? 私はそこまで多くないです。 CloudFormationやAWS CDKでカスタムリソースを作成する場合、以下記事で紹介されている通りLambda関数を使って行うことが多いです。 ただ、APIを呼び出すだけなのにLambda関数を用意するのもめんどくさいですよね。 そんな時、AWS CDKのAPI Referenceを眺めていたら、ただAPIを呼び出すだけなのであればLambda関数をわざわざ用意する必要がないことが分かりました
![[AWS CDK] APIを呼び出すだけのカスタムリソースならLambda関数は不要な件 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/92a069de3c7b583973daaf530883535d2e2b3e5a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F08%2Faws-cloud-development-kit.png)
変更に強いコンポーネント設計の方針と規約（Webフロントエンド） - Sansan Tech Blog
技術本部 データ戦略部 Newsグループの木田です。 最近、初めて自作キーボードに挑戦しました。ちょうど２枚目のモニターも買ったので、モニター２台と自作キーボードで快適に記事を書いています。 予めお断りしておきますが、この記事は元々、社内向けに設計方針や規約・ツールなどについて共有するために書いたものでした。最近、他チームの参考資料として役立ったこともあり、社外向けに手を加えて公開する運びとなりました。 はじめに 機構改革・人事異動情報(β) とは ⚛️ Atomic Design に従う ⚛️ Atomic Design とは ⚛️ Molecules と Organisms の分け方 ⚛️ コンポーネントの設計方法 📝 規約 📝 Component と Container を分ける 📝 データの繋ぎ込みは Organisms 以上で行う 💡 Tips 💡 Atoms はタグ本
AWSでサーバーレス設計を考える時の手引き書 - Qiita
はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか？ まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ
TypeScriptのdeclareやinterface Windowを勘で書くのをやめる2022
おことわり 個々の関数や変数に正しい型をつける話はしません。TypeScript HandbookのDeclarationの章などを読むことをおすすめします。 かわりに、本稿では関数や変数の型宣言をどこにどう置くべきかの指針を与えます。 モジュールとスクリプト declareを正しく使うにはまずモジュールとスクリプトの区別を理解し、意識することが大切です。 ブラウザやNode.jsは外部からの指定でモジュールとスクリプトを区別しますが、TypeScriptでは原則としてファイルの内容でモジュールとスクリプトを区別します。 import 宣言または export 宣言が1つ以上あればモジュール。 CommonJSモジュールの場合はTypeScript専用構文である import = 宣言、 export = 宣言を使う。 それ以外の場合はスクリプト。 ただし、JavaScriptファイル (
「3種類」で管理するReactのState戦略
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
「メンバーを信用していないのでは？」 “ある指摘”から始まったLINEアプリ開発チームの生産性改善施策
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで竹下秀則氏が、大規模クライアントアプリ開発チームの生産性を改善した仕組み化について紹介しました。まずはチームの成長と課題について。 LINEのクライアントアプリ開発チームの効率化事例 竹下秀則氏：みなさん、こんにちは。今日は「大規模クライアントアプリ開発チームの生産性を改善した仕組み化の数々」というタイトルでお話しします。LINE福岡開発1室所属のエンジニアリングマネージャー、竹下と申します。よろしくお願いいたします。 さっそくですが、本日のアジェンダはこちらになります。まずは私がマネージャーとして所属している、今日お話しする改善の舞台となったチームについて紹介します。 次にそこで直面した課題の数々について赤
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードには型アノテーションよりも要件アノテーションを増やせ！/harajukuts2
アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile
Dockerでファイルをbind mountしたら同期されなかった話
