Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

自ブログより 本記事では、dependency-cruiserというツールを利用してTypeScriptのコードベースに依存関係のルールを設定していく方法をご紹介します。意外と小規模、初期段階から導入しておきたいルールが多くありますので是非参考にしてみてください。 背景 私は現職の入社時に新規プロダクトの立ち上げてから1.5年がったのですが、徐々にコードベースが大きくなってきてコードベースの品質管理の必要性を感じる一方、アーキテクチャーの維持や、チームメンバーとの規約・思想の共有に苦心することが出てきました。 もちろんドキュメントの整備や、ESLint + Prettierの設定などは行ってきていたのですが、それでカバーできる範囲は限定的です。レビューの工数なども考ると、もっと広範において可能なものは自動テストがかけられる状態を作りたいものです。 そこで、最近はコードメトリクスに関心を持ち
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TypeScriptは、2022/10/01に10周年を迎えました。 ということで、それを記念してMicrosoftの中の人が振り返りのエントリーを書いていました。 以下は該当の記事、Ten Years of TypeScriptの紹介です。 Ten Years of TypeScript 2022年10月1日は、TypeScript10歳の誕生日です。 10年前の今日、2012年10月1日に、TypeScriptは初めて公にされました。 The Early Days 初めてTypeScriptが表に現れたとき、それももっともなことでし
先日以下のイベントにお声がけいただき、LT登壇をさせていただきました。 今回はエンジニアリングマネジメントという括りでもあり、我々ARIで行っている若手技術者育成の取組みをご紹介させていただきました。 登壇資料はこちらで公開しておりますが、サマリーや補足用にこちらの記事を用意しました。 我々が目指す理想の技術者像 ずばり「事業をエンジニアリングできる技術者」です。 ベストセラーとなった「事業をエンジニアリングする技術者たち」で紹介されている「フルサイクルエンジニア」の概念がまさに理想像です。 引用:https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 事業ドメインに関心を持ち、社会や顧客の課題を解決できること。 技術をビジネス価値を変換できる力の高い技術者を理想とし、そうした技術者を多く輩出できる組織を目指しています。 ち
要は、手元のMacやWindows、Ubuntuなど開発端末上に直接、複数のプロジェクトを配置して開発しつつ、nodeを共有したり、安易にバージョンアップとかしているとビルドができないなどのエラーが発生したりします。 2.nodeをつかったフロントエンドのビルドの脆さ (1)特定の団体がビルドツールをメンテしてくれる言語 ビルドというのは、Java、Go、Rustなど型付きの言語ではよくしますが、ビルドツール自体が単一のもので特定の開発団体がそれら全体をメンテしてくれています。 もちろん、これらのツールであっても、バージョンが違えばビルドは通らなくなることがあります。ただ、後方互換があって、多少バージョンがあがっても動くこともままあります。 (2)ビルドという行為が不要な言語 PHPやRubyのようなスクリプト言語の場合、ビルドという行為がそもそもありません。ただ、ランタイムのバージョン違
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行
PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」(ヴィテス)を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり
はじめに Pythonはコードが汚くなりがち(個人的にそう思う) そんなPythonくんを快適に書くための設定を紹介します。 拡張機能編 ここでは Pythonを書きやすくするため の拡張機能を紹介していきます。 1. Error Lens before 「コード書いたけど、なんか波線出てるよ💦」 記述に問題があった場合、デフォルトでは波線が表示されるだけ。。。 after Error Lensくんを入れることによって 波線だけでなくエディタに直接表示される。 はい、有能〜 2. indent-rainbow before Pythonくんは インデントでスコープを認識している。 for の f から下に線が伸びてるけど、ちょっと見にくいなぁ after 色が付いてちょっと見やすくなった! 3. Trailing Space before 一見、普通に見えるコード after 末尾にある
Karabiner ElementsでComplex Modificationを書く際に、いつもJISキーボードの記号とキーコードの対応関係がわからなくなって、Karabiner EventViewerで都度調べてしまうので、チートシートとして表にまとめてみた。 特にシフト同時押しの記号は慣れないと相当にややこしく、なかなかシフト同時押しの場合の記載がある記事が見つからなかったので作ってみた。 (なお、表の書き方は、同様の内容をまとめてあるこちらのサイトを参考にした。 https://did2memo.net/2019/03/31/karabiner-elements-symbol-table/ ) 対応表 シフトなし 【凡例】 「記号 (JIS)」:JISキーボードで入出力したい記号 「USでの見た目」: USキーボードで同じ場所にあるキーの見た目 「key_code」:設定すべきキーコ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Design Documentと聞くと何を想像しますか? 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの?」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは? Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する
導きのはじまり おぉ、貴方は…褪せ人ですね。 そして、エルデンリングを求め、この狭間の地にやってきた。 この先、プログラミング学習の攻略に繋がる貴重なアイテム が、7つあるぞ すごいなにかだと思うだろう? 以下の記事を、ご照覧あれい! 1. 強い敵はスルーして先に進む プログラミングを勉強していると、序盤にツリーガードのような強敵が現れることがありますが、 スルーして先に進むことが大事です。 序盤から強敵と戦うと、ボコボコにされて心が折れます #include <stdio.h>は、こういうもんだと「おまじない」としてスルーする。 var body: some Viewや、fn longest<'a>など、 見慣れない表記を見ても、いったん気にしない。前に進む。 強敵は、力を付けてレベルが上ってから再戦しましょう。 目の前に現れたすべての敵と戦う必要はありません。 ボスまでのルートを開通す
本記事ではSIerに所属する著者が3年間にわたり、私たちのグループで実践している「1on1」の内容を紹介します(グループの業務内容は主にAI系の自社製品開発です)。 ・1on1をこれから始める方 ・1on1の取り組みを検討をされている方 ・1on1を実施しており、さらに改善を検討されている上司側の方 ・1on1を実施してもらっているが、なんだかしっくりきていない部下側の方 こうした方々にとって、何らか参考となれば幸いです。 とくにIT系の企業や職種では1on1を開催しているところも多いと思います。 新人プログラマの方にとっても、1on1を実施する側がどのようなことを考えて実施しているのか、ひとつの例として参考にいただければ幸いです。 (なおQiitaでは現在、新人プログラマ応援 - みんなで新人を育てよう!企画も開催中です) 私が自分の頭を整理するために記事化しましたが、非常に長い文章にな
はじめに はじめまして。インディーゲームを作っております、nyorokoと申します。 ゲームづくりの他に読書が好きで、「読書録を簡単に作成・管理することはできないか?」という問題意識があり、タイトルの通りのアプリを作ってみました。 2022/5/23 思ったよりも反響があったため、加筆した第二弾を公開しました! 完成したもの 以前Notion APIを用いて、 本のバーコードを読み取る →ISBNを取得する →ISBNから本の情報を取得する →Notionのデータベースに追加する という一連の動作を行うアプリを開発しました💪🏾(´・_・`💪🏾) pic.twitter.com/GqPBPV7sin — nyoroko (@nyoroko_nyoro) February 21, 2022 Notionとは? Notion公式サイト Notionとは、タスク管理やメモ等を一元的に行うこ
こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇%アップ、CVR〇%アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを片っ端から試していくボトムアップなアプローチも有効になることもあったり、日々のコーディングでパフォーマンスを意識したコードを書くことは大切でしょう。 この記事ではパフォーマンス最適化のハウツーを紹介します。 パフォーマンス改善の施策が思い浮かばない時やフロン
この記事は、KLab Engineer Advent Calendar 2021 の25日目の記事です。大遅刻してしまいました、ごめんなさい。 こんにちは。KLabで今年の2月からCTOをしています@hnwです。 CTOに就いて以降、社内のエンジニアの方とお話をする機会が増えました。1on1だったり少人数の会議だったり形式は色々ですが、興味深い話をたくさん聞けて、自分にとっても会社にとっても必要なことだと感じています。 そうした際にエンジニアとしての将来の理想像やキャリアパスといった悩みを聞くことがあります。私もその場で言えることは言っているつもりですが、うまく伝わったか、もっと言えることがあるんじゃないか、とモヤモヤすることがあります。本稿ではそのモヤモヤを「○○問題」として整理してみました。 最初にお断りしておくと、キャリアの話は基本的には個人の問題ですから、あまり他人の話を真に受けす
こんにちは、食べログシステム本部長の京和です。 昨年のアドベントカレンダーでは 「食べログの大規模なレガシーシステムを段階的に改善していく取り組み」 と言う記事で技術的な取り組みを中心に紹介しました。 今年のアドベントカレンダーでは、食べログのエンジニア組織を段階的に改善していく取り組みについてご紹介します。 食べログの組織構造 食べログの組織はシステム、営業、ビジネスと言った機能ごとに組織が分かれる、いわゆる機能別組織の組織構造を採用しています。 2021年12月現在の食べログの組織は、公式な組織図としては上記の機能別組織を維持しながら、内部ではマトリクス型組織の要素を一部に導入したハイブリッドな組織形態となっています。 今も試行錯誤中の段階ではありますが、現在に至るまでの変遷を、 システム部門を機能別組織として最適化する マトリクス型組織によるクロスファンクショナルチームの導入 「冒険
何番煎じかわかりませんが TypeScript でのエラーハンドリングについて考えてみたいと思います。 この記事で扱う TypeScript のバージョンは 4.3 です。 エラーを型安全に扱いたい TypeScript を書いていれば誰もが一度はぶつかる問題ではないでしょうか。 TypeScript では catch した例外は any として扱われます。 これは JavaScript の仕様上どんな値でも throw できてしまうため仕方のないことなのですが、せっかく型安全性を手に入れるために TypeScript を使っているのに any をハンドリングしなければならないのは苦痛です。 次のように例外を throw し得る関数 foo() のエラーハンドリングを考えてみます。 e は any なので、プロパティにアクセスしようにも危険性が伴います。 そこで型アノテーションを使用して
概要 この記事ではRust初心者が驚いたり混乱させられたりするようなRustの文法を10項目集めてみました。 これらの項目は知らないと理解できなかったりコンパイルエラーに悩まされたりする一見厄介なものたちなのですが、そのような直感的でない挙動を敢えてさせているところには重要な意味が込められていることが多いです。 そのため、これらの項目を通してRustが目指しているものや実現したい機能の一部を垣間見ることができると思います。 1. デフォルトの代入がムーブ Rustの最大の特徴が所有権の概念であることは有名ですが、それでもなお初心者殺しになるのがムーブです。 以下のコードがコンパイルエラーになるメジャーな言語は現状Rustくらいしか無いでしょう。 let mut a = vec![1, 2, 3]; let mut b = a; // ここでaの持つベクタの所有権がbにムーブされ、aは無効に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く