TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
Denoで困ったときはZigで何とかなるかもしれない
サードパーティライブラリが無いよ問題 いきなりネガティブな話で申し訳ございません。愚痴みたいなものです。本題ではありませんので読み飛ばしていただいて問題ありません。 Denoユーザーの1人としての個人的な印象として、Denoの勢いは2023年に入った頃から低迷しているように感じます。2022年末からnpm対応によってNode.jsの資産を使えるようになったにも関わらずです。実際のユーザー数はDenoチームではないので分かりませんが、登場から数年経って真新しさも無くなったので、どんなサービスにもありがちなことなのかなと思います。 ありがちとはいえ、ただ低迷しているだけではありません。ここからNode.jsを超えるのはなかなか難しいです。なぜならnpm対応というのは、明示的にNode.jsに対して「生き残っていい」それどころか「あなたが正しい」と宣言してしまったようなものです。Node.jsの
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
vosk-browserのお試し
test.html ���XU � K�XU <html> <head> <title>vosk test</title> <script type="application/javascript" src="https://cdn.jsdelivr.net/npm/vosk-browser@0.0.3/dist/vosk.js"></script> <script> // let model = null // 初期化処理 async function init() { // 権限取得のための素振り const s = await navigator.mediaDevices.getUserMedia({video: false, audio: true}) s.getTracks().forEach(t => t.stop()) // マイク列挙処理 const select = d
【超簡単手順】低スペックローカルPCで大規模言語モデル「LLaMA」を動かす！
ある日、Twitterを巡回していると え...マジで？となりました。自分の専属AIを作りたい！と思い立ち、実際に動かしてみました。 目標 このようにローカルPC上でLLaMAとチャットできるようになります。 ただ、自分が使ったモデルは7Bモデルと言って、パラメータがあまり大きくない＝あまり賢くないモデルだったので出力は変な感じになっています笑 (明らかにネットの会話を推論に引っ張ってきてますね...) なので、今回はとりあえず動かしてみたい人向けです！精度などは気にせずお試しください。 ちなみに、自分はM1 MacBookAir(8Gメモリ)で動きました！信じられないぐらい遅いですが笑 Macユーザー向けに解説しますが、windows、linuxユーザーでもほとんど変わらないと思います。 手順 基本的にはこのgithubでの手順を踏んでいきます。 Node.js (npm) をインストー
TypeScriptではじめるChatGPT API：入門から一歩進んだテクニックまで - Uzabase for Engineers
NewsPicks エンジニアの中村です。普段はデータ基盤や機械学習システムの開発、運用をやっています。 さて皆さん、すでにChatGPTは使っていらっしゃるでしょうか。エンジニア、非エンジニアを問わず世の中を席巻している感のある ChatGPT ですが、今月初めにいよいよ API も公開されて、アプリケーションやサービスに組み込みたいと考えている方も多いのではないでしょうか1。 というわけで、弊社でもこの新しい技術をより多くのエンジニアに使いこなせるようになってもらいたいと考え、ChatGPT API に関する社内勉強会を先日開催しました。本記事ではこの勉強会の内容を再構成してお届けします。 とりあえず使うだけなら簡単な ChatGPT ですが、本記事では、長文を扱ったり、ChatGPT と外部のシステムを連携させたりするテクニックなど、知っている人はすでに知っているが、まだそれほど広く
AzureFunctions + puppeteer でPDF出力 - Qiita
概要 AzureFunctions + puppeteerでPDFを出力する。 生成したPDFはAzureStorageに保存する。 How to 「AzureFunctions + puppeteer」でスクショを撮る方法は以下を参照。 https://anthonychu.ca/post/azure-functions-headless-chromium-puppeteer-playwright/ コード 実際に動かしたコードをちょっと変えています（大人の事情）。 動作確認してないので、動かないかもです。参考程度にご覧ください。 ガーと書いたので、ツッコミポイントは多いですが、スルーしてください。 import * as puppeteer from "puppeteer"; import { BlobServiceClient, BlockBlobClient } from "@az
近年のWeb開発においてjQueryの利用をやめるべき理由
jQuery が広く使われるようになった理由jQuery が広く使われるようになった理由の 1 つに、クロスブラウザの互換性問題があった。jQuery はクロスブラウザで動作するため、開発者はブラウザ毎の互換性問題を意識する必要が薄くなった。また、jQuery の構文は初心者でも使いやすいため多くの開発者が利用し、コミュニティが発展した。これによって、jQuery プラグインやドキュメントが豊富に提供されるようになった。 jQuery の登場とほぼ同時期に、Prototype.js もその役割を担っていた。しかし、jQuery は Prototype.js よりも広く採用され、トレンドが移り変わった経緯がある。 シンプルな構文 両者とも当時のプレーンな JavaScript に比べシンプルな構文を持っていたが、Prototype.js より jQuery の構文が受け入れられた。パフォーマ
Connect for Node.js is now available
Timo Stamm and Steve Ayers on Feb 28, 2023/6 min read When we announced Connect-Web a few months ago, we were thrilled to finally bring Connect to JavaScript and, more specifically, to the browser. Since then, we’ve seen usage continue to grow and have received valuable feedback from the community. When Connect-Web was released, however, we promised that we’d soon provide a solution to extend the
ReactとVueの比較 | 完全に同じアプリのコードの書き方の違い - Qiita
はじめに JavaScript フロンエンドフレームワークは 2014 年ごろから本格的に使用され始め、従来のサーバーサイドテンプレートに対し、現代では一般的な Web 技術としてすっかり定着し、シェアとしては React、Vue が 2 強状態になっています。本稿では、最初に過去から現在の状況を俯瞰した後、React と Vue の関数コンポーネントを使用して、同じ画面と機能を持つコードの書き方を比較していきます。 過去から現在の状況 フロントエンド MVC の衰退 10 年前、フロントエンド MVC を標榜していた Angular や Ember は低迷し、以降のフレームワークはもはや M とか V とか MV なんたらなどのレイヤーを言及しなくなり、ビュー + イベント + ステートを 1 つの責務としてまとめた直感的で分かりやすいコンポーネント指向となりました。以下は State
moment.js・day.js よりも速くて軽い cdate ライブラリ - Qiita
moment.js や day.js と似たインターフェースを実装した高速・軽量の JavaScript ライブラリ『cdate』をリリースしました。→ https://www.npmjs.com/package/cdate cdate の主な特徴： moment.js や day.js、Luxon よりも高速 moment.js と同じ .format("YYYY-MM-DD HH:mm:ss") 出力フォーマットに対応 strftime と同じ .text("%Y-%m-%d %H:%M:%S") 出力フォーマットに対応 moment.js と同様に .add(1, "month").startOf("week").endOf("day") のような計算に対応 .tz("Asia/Tokyo") あるいは .utcOffset("+09:00") のようなタイムゾーン（時間帯）指定に対
WebWorkerでゴリゴリの重い処理をさせて横から制御したい時の手段 | g200kg Music & Software
これは Javascript のかなり細かい部分の話なので似たようなケースで困った事がある人以外にとってはどうでも良い話だと思いますが......。 JavaScript は元々シングルスレッド構造なのであまり重い処理をさせるには向いていないのだ、という事は昔から言われていました。 重い処理をしようとした時にまず影響を受けやすいのは UI 周りの動作です。 UI をちゃんと動かしつつ重い処理をさせるためには、処理を小分けにしてタイマーから駆動する等の手法がとられます。 またこの時、コールバックで小分けにした処理を繋げるとソースが見づらくなるので Promise や async/await を使う、という手段が定石となっていったのですが、そもそも、ひとまとまりの重い処理をやらせたいならやっぱり別スレッドで走らせたい、という事で WebWorker というものが作られました。 これによって J
React Three Fiber Documentation
IntroductionReact-three-fiber is a React renderer for three.js. Build your scene declaratively with re-usable, self-contained components that react to state, are readily interactive and can participate in React's ecosystem. npm install three @types/three @react-three/fiber Does it have limitations? None. Everything that works in Threejs will work here without exception. Is it slower than plain Thr
ブラウザからローカルファイルを操作するターミナルを作った
フロントエンド開発はフロントエンドで完結すべき過激派としてのGWの活動で、ブラウザでローカルファイルを読み書きするターミナルのプロトを作ってみました。 ローカルファイルをマウントして操作してる風景です。 ソースコード mizchi/web-shell 仕組み FileSystemAccess API を使って、FS API を実装 xterm.js 上で FS を叩く Unix 風のコマンドをいくつか実装 monaco-editor で、open <file> した内容を渡して、Cmd-S で保存した内容をFSに書き込む 最初に開いてるのは navigator.storage.getDirectory() の一時的なストレージで、これはブラウザの機嫌次第で揮発します(仕様にそう書いてある)。ローカルファイルを操作するのに mount を使うのがメインの用途です。 FileSystemAcc
「たかがJavaScript」のその先 #TECHPLAY
フロントエンドと自分のキャリア形成について。このスキルツリーとセットで見るといいかもです。 https://whimsical.com/oPYtoDPyho6uWK1gDmD9e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Visual Studio Code を使用して JavaScript 関数を作成する - Azure Functions
Webフロントエンド基礎研修 ~歴史から学ぶ、現場のスタンダードな開発~
three.js docs
マークダウンをtailwind cssでスタイリングする - Qiita
