プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本
自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ
動的型付き言語は素早くプロジェクトを立ち上げるのに向いており、静的型付き言語は長期間の保守にむいているという仮説 - kmizuの日記
注：誤解されないように最初にこの記事の意図を書いておくと、古典的な静的型付き言語VS.動的型付き言語の論争をするつもりはありません。これまで色々なプロジェクトを観察（風聞も含む）して来たところ、そういう傾向があるのではないかという仮説です。それと、文脈として主にWebアプリケーション開発する時のことを想定しており、それ以外のケースはいったん脇に置いています。WebアプリケーションだとPHP（動的型付き言語）の方が圧倒的に事例多いのではという感想もありそうですが、その辺りを考え出すと話がこんがらがるので、これもいったん脇においています。 たとえば、色々な事例を見聞きするに、スタートアップ企業において動的型付き言語であるRubyのWebアプリケーションフレームワークであるRuby on Rails（RoR）は好まれる傾向にあります。近年のPythonの動向はさておき、未だにRoRの求人がかなり
TypeScript をより安全に使うために まとめ - Object.create(null)
こういう一連の記事を書きました. susisu.hatenablog.com susisu.hatenablog.com susisu.hatenablog.com TypeScript の型安全性 TypeScript の型システムは健全ではありません. TypeScript Design Goals にある通り, そもそも言語設計の段階で完璧な型安全性は目標になっておらず, 既存の JavaScript の言語仕様や資産を活用しやすいように, 生産性や利便性とのバランスをとることを目標としています. では TypeScript の型システムではどの程度の安全性が保証されるのでしょうか? 型安全性を第一の目標に置いていないとはいえ, TypeScript がまったく見当違いな型検査をしているというわけではありません. したがって, ある制限された範囲内であれば, 安全性を担保するのに十分
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ
YYTypeScript#1「JavaScriptを知らない人がTypeScriptを学ぶ方法を知りたい」「TypeScript初心者がどうやって勉強すると効率がいいか？」「なぜTSが選ばれるのか？」「PHPと比べて、サーバサイドをTSで書くメリットは？」「TypeScriptのバックエンドのオススメフレームワークって？」「定義をinterfaceとtypeどっちで書いてる？」「JSで書かれたプロダクトのTS化ってどうしてる？ 」 - Qiita
YYTypeScript#1「JavaScriptを知らない人がTypeScriptを学ぶ方法を知りたい」「TypeScript初心者がどうやって勉強すると効率がいいか？」「なぜTSが選ばれるのか？」「PHPと比べて、サーバサイドをTSで書くメリットは？」「TypeScriptのバックエンドのオススメフレームワークって？」「定義をinterfaceとtypeどっちで書いてる？」「JSで書かれたプロダクトのTS化ってどうしてる？ 」PHPJavaScriptTypeScriptYYTypeScriptイベントレポート これは2019年9月20日に開催したTypeScriptイベントYYTypeScript#1のイベントレポートです。 YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆる
20年でソフトウェア開発の景色はどのぐらい変わったのか？ - Qiita
PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra
TypeScriptの型推論詳説 - Qiita
TypeScriptはJavaScriptに静的型を追加した言語で、コンパイルエラーを検出することでJavaScript開発をさらに快適・効率的にしてくれるものです。 型システムを備えている言語は、多かれ少なかれ何らかの形で型推論を備えています。大ざっぱに言えば、これは型を明示的に書かなくてもコンパイラがいい感じに型を推測して理解してくれる機能です。型推論は静的型付き言語における花型機能のひとつと言ってもよく、色々な言語がそれぞれの特色を持っています。 この記事ではTypeScriptにおける型推論について詳説します。この記事に書いてあることは、TypeScriptを普段から書いている方ならなんとなく理解している内容が多いと思います。しかし、これらの内容がちゃんと言語化されている記事がいまいち見当たらなかったので今回記事を書くことにしました。 ※ この記事の内容は執筆時点の最新版のType
なぜTypeScriptに失望してしまうのか - Islands in the byte stream
追記: この件に関してエンジニアHubにもTypeScriptの記事を書きました: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に - エンジニアHub｜Webエンジニアのキャリアを考える！ TypeScriptに対する失望は2パターンあって、その理由は理解できるのですが、いずれにせよそこでTypeScriptを捨てる判断をするのはもったいないと思っています。この2つの失望を感じたとしてもなお、TypeScriptには導入する価値があると思っています。 パターン1: 実はJavaScriptに対する失望である そこらのブログやTwitterで観測していると、理由の7割くらいこれです。これは、TypeScriptが独立した言語ではなくJavaScriptへのトランスパイラ（言語変換ツール）であり、独立したランタイムを
漸進的型付け言語の時代に必要なもの - mizchi's blog
最近では、Gradual Typing、漸進的型付けと呼ばれる型システムを備えた言語(拡張)が増えてきています。 次のようなもの JavaScript: TypeScript / Flowtype Python: mypy / pyre-checker PHP: hack / php-storm flow/pyre-checker/hack と facebook 製が多いですね。 この記事は、それらを使う動機と運用について書きます。この記事の出発点として、 おそらく TypeScript/Flow で発生した問題が後発の言語で発生すると思っており、それらを使う方や、設計する人への提言でもあります。 自分は昔 https://github.com/mizchi/TypedCoffeeScript というAltJS作ろうとして、実装のツラミはなんとなく知ってるつもりです。ホビーレベルで作るもの
私と型システムとポエム
最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti
Ruby に型が欲しい理由 - Qiita
Help us understand the problem. What is going on with this article? 2018/07/05 追記 JavaScript と漸進的型付について詳しい mizchi さんが記事を書いたので、併せて読むと良さそうです。 漸進的型付け言語の時代に必要なもの 前置き RubyKaigi2018 の発表で型の導入の検討についての話がいくつかあったものの、 Matz 自身は型アノテーションに否定的であるという発言をしているとのことを受けて、自分の意見の表明として書いている。 筆者は Ruby に育てられて Ruby は好きであるが、業務経験は主に JavaScript(TypeScript) や Python(Type Hinting) が多く、漸進的型付けによるコードの健全化を経験した上で、型付きの方が好きであるという立場である。 なお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
