タグ

ブックマーク / blog.uhy.ooo (6)

  • 積極的な技術選定と消極的な技術選定 - uhyo/blog

    この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される(あるいはされない)技術そのものが原因となる意思決定です。 一方、消極

    積極的な技術選定と消極的な技術選定 - uhyo/blog
    Keisuke69
    Keisuke69 2023/02/14
    業務における技術選定は人員計画とか組織運営における色んな要素に絡んでくるからなー。分けて話せというのは本来正しいが実際には筆者が言うところの消極的な意思決定の項目を前提にして技術選定する必要があるかと
  • ████を退職します - uhyo/blog

    この記事はuhy.oooでも読むことができます。 ████を退職します皆さんこんにちは。この度、████を退職することになりましたのでご報告します。 筆者は2019年に新卒で████に入社して、今年が4年目でした。今回が初めての転職となります。転職先は███という会社です。 ████はどうだったか一言で言えば、良いところでした。特に、チームメンバーと上司に恵まれ、快適かつとても自由な環境で働くことができました。 快適というのはいくつかの側面があります。自分としては、大きい会社ならではの整った社内制度・社内システムは魅力的でした。これにより、事務的な作業はなるべく事務的かつ簡潔に済ませられるようになっていて業務に集中できます。他には、プロジェクトメンバーとのコミュニケーションにおいてストレスを感じることもあまり無く(██████████████████████)、これだけ良い人ばかり集まって

    ████を退職します - uhyo/blog
    Keisuke69
    Keisuke69 2022/08/29
    これは
  • どのようにTypeScriptを使うのか - uhyo/blog

    現在、TypeScriptの重要性は、フロントエンド開発を中心としてますます増すばかりであります。それだけに、TypeScriptをどのように使うべきかという問題については多様な意見が見られます。 これまで筆者はTypeScriptの使い方に、特にコンパイラオプションの使い方について意見を散発的に発信してきましたが、このたび記事にまとめました。この記事では、特に次のような意見に対しての反対意見を述べます。 厳しいコンパイラオプションは型パズル愛好者のためのものであり、普通の人は細かいことを気にせず緩い設定でよい。熟練のJavaScript使いにはTypeScriptは必要ない。例え話最近はTypeScriptを補助輪に例えたりするのが流行っていますので、この記事でも例え話をしてみます。筆者の考えでは、TypeScriptというのは例えるならば料理人が使う包丁のようなものです。コンパイラオプ

    どのようにTypeScriptを使うのか - uhyo/blog
    Keisuke69
    Keisuke69 2021/10/24
    ランタイムエラーになるよりはマシと思うものの書き味が悪くなる感じは確かにする。でもJava書いてた頃はそのあたりが気になることなかったんだよな。IDEが優秀だったからかな
  • 空のdiv要素について - uhyo/blog

    昨日はこちらの記事に端を発する形で、空のdiv要素やspan要素は妥当なのかといった話題が見られました。 中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか? - dskdこの記事は空のdiv要素やspan要素が妥当かどうかという疑問にHTML仕様の観点から考察を加える大変面白い記事です。記事の結論としては、“僕の結論としては「否」である。”としています。 しかし、いくらHTML仕様を読んだといっても、こういった議論には解釈が入りがちです(こちらの記事でも結論の前に“ここからは完全に僕の解釈として書く。”と明記されています)。 仕様なのに解釈を入れる必要があるのはどうなのと思いつつ、実はこの記事でこれから紹介するように、HTML仕様もなかなか曖昧に書かれており解釈が必要なのは仕方のないことです。 筆者はどちらかというと空のdivを肯定する考えを持っていたの

    空のdiv要素について - uhyo/blog
    Keisuke69
    Keisuke69 2021/09/07
  • React ステート管理 比較考察 - uhyo/blog

    こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント(使用者)で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子

    React ステート管理 比較考察 - uhyo/blog
    Keisuke69
    Keisuke69 2021/07/24
    MobXってあったな
  • ユーザー定義型ガード、asで書くかanyで書くか - uhyo/blog

    TypeScriptでユーザー定義型ガードを定義する場合、引数をany型にして中を自由に書く方法と引数をunknown型にして中でasを駆使して書く方法があります。この記事では両者を比較考察します。結論としては、unknownとasを使うのが型安全性の面からおすすめです。また、うまく関数を分割することでasを消すことも可能で、これも有効です。 ユーザー定義型ガードとはTypeScriptのユーザー定義型ガードとは、型の絞り込み (type narrowing) に使うことができる関数です。ユーザー定義型ガードは返り値が引数名 is 型のような形の型述語 (type predicate) になっています1。このような関数は真偽値を返り値として返し、trueを返すならば引数名が型であることを表します。 例えば、与えられた値がstring | number型かどうか調べるユーザー定義型ガードは次

    ユーザー定義型ガード、asで書くかanyで書くか - uhyo/blog
    Keisuke69
    Keisuke69 2021/04/11
  • 1