タグ

ブックマーク / qiita.com (1,116)

  • TypeScriptの型定義からJSON Schemaを生成するオンラインツールを作ってみた - Qiita

    先日、TypeScript + Tynderから始める宣言的検証生活の記事にて スキーマ検証ライブラリTynderを紹介いたしました。 Tynderとは Tynderは、TypeScriptのサブセット+独自の拡張文法から成るDSLによって 型の検査 単独の項目の必須・値の長さ・範囲や文字列パターンの検証 複数項目の相関や整合性検証の一部 (Union typeによる) を宣言的に行うことができます。 今回はTynderのスキーマ変換機能を使用して JSON Schema、GraphQL、Protobuf3 のスキーマを生成するオンラインツールを公開しました。 (GraphQL、Protobuf3については実験的機能です) TypeScript (Tynder DSL) → JSON Schema | GraphQL | Protobuf Converter Convert schema

    TypeScriptの型定義からJSON Schemaを生成するオンラインツールを作ってみた - Qiita
  • TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita

    同じTypeScriptという言語を利用する場合においても、トランスパイラによってTypeScript自体の機能制限がかかったり、思わぬトラブルを招く場合があります。それぞれのトランスパイラの特徴を踏まえた上で、それにより生じる問題も見ていきましょう。 1-1. tsc TypeScriptの開発元であるMicrosoft純正のTypeScriptトランスパイラです。TypeScriptを利用する際に typescript パッケージをインストールする必要がありますが、それに同梱されています。 公式ツールなだけあって最も早く最新バージョンのTypeScriptに対応したり、言語すべての機能を利用することができる一方で、バンドラではないためminifyやchunkの設定はできません。また、Path Aliasesの未解決や旧ESへの互換性が不完全であることが欠点として挙げられます。 tsco

    TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita
  • 良いコードの書き方 - Qiita

    概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー(特に新規参加者)がコードを理解しやすくする 初心者プログラマー教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が

    良いコードの書き方 - Qiita
  • Full-Stack JavaScript meets DDD. - Qiita

    これは 2020-01-10 に開催された、DDD meetup#3 でのLTの内容を記事化したものです。 Vuex+Express環境でどんなアーキテクチャを採用したか、して良かったこと/悪かったことを発表しました(LT資料はこちら)。 問題提起 フロントエンドでDDDを実践しようと考えて、結局採用を見送った経験のある方は以外に多いのではないでしょうか。ドメイン知識はバックエンドに集中させてフロントはできるだけライトウェイトに…。と、がんばっても、どうしても気になるものの一つがバリデーション。些末なことだけどバリデーションはれっきとしたドメイン知識。これだけ半端にフロントにいるの、気持ち悪いですよね? 折角ドメイン知識をその他と分離するなら、フロントとバックでもそれらを共通化したい!できるんです。そう、Full-Stack JavaScriptでの開発なら。 結論 こんなアーキテクチャを

    Full-Stack JavaScript meets DDD. - Qiita
  • 【Firebase, Nuxt】リアルタイムなスライド共有サービスを作ってハッカソンで優勝した話 - Qiita

    昨年末にFirebaseのアイデアソン/ハッカソンに参加しました。 その場で出会った3名で即席チームを結成して、約1ヶ月でFirebaseを使ったサービスを開発しました。 その結果、最優秀賞を獲得し、更に1ヶ月で機能を追加して、サービスを正式リリースしました! 自分なりに大きな経験になったので、その経緯をサービス紹介を含めて公開します。 個人開発したいと思っているエンジニアで、参考にしてくれる人がいたら幸いです。 どんなサービスか "SlideLive(スライドライブ)"といいます。 勉強会やセミナーのライブ感を飛躍的に高めるリアルタイムスライド共有サービス です。 SlideLiveのコンセプト 勉強会をライブに 私はプレゼンが苦手です。 「アイスブレイク」ってどうやったらいいのでしょうか? 「勉強会でプレゼンしている時にリアクションが無く緊張する」ことってありませんか? そんな課題認識

    【Firebase, Nuxt】リアルタイムなスライド共有サービスを作ってハッカソンで優勝した話 - Qiita
  • Amazon Kinesis Video Streams WebRTC を動かしてみた - Qiita

    はじめに 2019年のre:Inventで、Amazon Kinesis Video Streams (以後KVSと表記) に WebRTCを使ったリアルタイム通信が加わりました。 ブラウザ(JavaScript)向けのSDKだけでなく、組み込み用途のC言語SDKや、iOS/Androidといったモバイルアプリ向けのSDKがあるのが特徴です。 Web用SDK ... https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-js 組み込みC用SDK ... https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c iOS用SDK ... https://github.com/awslabs/amazon-kinesis-video-st

    Amazon Kinesis Video Streams WebRTC を動かしてみた - Qiita
  • io.CopyにはなるべくWriteTo関数を渡してあげた方が良さそう - Qiita

    io.Readerのファイルタイプを判定する を拝見してちょっと気になったので調べました。 io.MultiReaderではWrite関数しか実装されておらず、 WriteTo(w Writer) (n int64, err error)関数が存在しません。 そのため、みんな大好きio.Copyで積極利用されるWriteTo(w Writer) (n int64, err error)関数が働かず少し残念な気持ちがありました。 もしかすると気持ちだけの問題かもしれないのでBenchmarkしてみました。 bufio.Readerには WriteToが実装されいたので、こちらを元のReaderに被せてる事にしました。そうすると都合よくまさにリード位置を進めず先頭から指定バイト数だけ読むbufio.Peek関数が用意されていたのでそちらを利用しました。 元のisGzip関数を書き直したのが以下

    io.CopyにはなるべくWriteTo関数を渡してあげた方が良さそう - Qiita
  • Envoy と Kubernetes で始める Progressive Delivery - Qiita

    記事は 2020/01/08 に開催された Envoy Meetup Tokyo #1の LT スライド兼補足資料です。 原則として、スライドモードでファーストビューに入るものはスライドとして、下にスクロールして表示される部分は補足資料です。 Progressive Delivery とは Continuous Delivery ++ 実装はたいてい Canary Release + Canary Analysis + Automated Rollback "Progressive Delivery is the next step after Continuos Delivery, where new versions are deployed to subset of users and are evaluated in terms of correctness and perfor

    Envoy と Kubernetes で始める Progressive Delivery - Qiita
  • TOMCAT殺害事件 - Qiita

    OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 (この記事はJava8が対象となります。) OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no

    TOMCAT殺害事件 - Qiita
  • 現場で役立つシステム設計の原則メモ - Qiita

    This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ

    現場で役立つシステム設計の原則メモ - Qiita
  • io.Readerのファイルタイプを判定する - Qiita

    概要 Goでファイルを読み込んでいる時に、そのファイルのタイプを判別したいことがたまにあります。例えばGzipかどうか分からないけど、もしGzipならgzip.NewReader噛ませたい、みたいな場合です。雑にgzip.NewReader噛ませてerr返すかどうかで判定とかやってみたんですが、普通に10バイト読み進められちゃうのでerr返ったあとに別のファイルタイプとして処理しようとするとinvalidなヘッダーになって死にます。実は読み進められたバイトを戻す方法あるよ、という場合は教えて下さい。 そもそもGzip以外の判定をしたいときもあるので、NewReaderの方針も必ず使えるわけではありません。もしファイルがos.Fileとかbufio.Readerの形であればReadしてからSeekしたりPeekしたり出来るのですが、io.Readerの場合どうやるのか分からなかったので調べま

    io.Readerのファイルタイプを判定する - Qiita
  • 【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita

    これってなんなの? 【ど素人状態=社会人になって初めてプログラミングを勉強したぜ!(特に新卒)】〜【Webエンジニアの3年生ぐらい】になるまでに読むと良いまとめです。「どんな目的で学ぶか?」*「いつぐらいまでに読むといいか?」を段階的にまとめました。「これだけ読めばいい!」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ?」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m ※続編 【Webエンジニアど素人】が【3〜4年生】くらいになったら読むといいを目的別にまとめた ”Webエンジニアど素人から3年生ぐらいになるまでに読むと良い”の段階的まとめ(一部外部記事あり) ど素人の方々が手を動かしながら1〜6ヶ月以内に学ぼう! ◆どの

    【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita
  • コードの実装から理解するDDDとNot DDD - Qiita

    はじめに DDDとは?という議論が尽きません。 「レイヤードアーキテクチャ、Repositoryなどは軽量DDDでありDDDではない」 「ユビキタス言語に基づいたドメインモデリングこそDDDの質である」 とは言うものの、レイヤードアーキテクチャから先行して理解することが多いのが実情です。 なぜドメインモデリングの導入が進まないことが多いのか考えてみると、初学者にはドメインモデリングを実施したときの最終的な実装とそうでないときの実装の差がわかりづらく、どのような価値があるのかがわかりづらいためだと思います。 「ドメインモデリングをしたからドメインが素晴らしく良い実装になった」という例を紹介できればいいのですが、なかなか適切な具体的な例で説明することが難しいです。 そこでモデリングよりも技術的な視点にはなってしまいますが「集約を意識したDDDな実装とDDDではない実装」を具体的に紹介すること

    コードの実装から理解するDDDとNot DDD - Qiita
  • k8sで、HTTP/2(gRPCサーバ)を負荷分散したい - Qiita

    kubernetesで、HTTP/2を負荷分散してみた はじめに 背景 現在学生プロジェクトでインフラとして、GKE(Google Kubernetes Engine)を利用させて頂いています。 REST APIサーバを、gRPCに換装してみようとした時にある問題にぶち当たりました。 前提知識として Kubernetesのロードバランサ Services are a “layer 4” (TCP/UDP over IP) construct, the proxy was purely in userspace 現行のKubernetesIngressは、OSI参照モデルのトランスポート層(L4)のロードバランサを提供しています。(beta版はその限りではないです!) gRPCの通信の仕方 gRPCでの通信は、 一つのTCPコネクションを使い回します。 つまり、コネクションが確立している間

    k8sで、HTTP/2(gRPCサーバ)を負荷分散したい - Qiita
  • インフラが苦手な人の個人開発(ECS、terraform) - Qiita

    はじめに 記事は 個人開発 Advent Calendar 2019 25日目の記事です。 最近connpassに掲載されている勉強会を地図を見ながら検索できるようなサイトを作りました。 (もともと同僚が勉強会でこんな感じのアプリを作っておりそれに触発された) https://connpass.net/ 使った技術としては フロント: typescriptreact、reduxcircleci、cloudfront、s3、terraform バックエンド: go、gin、dockernginxcircleci、ecs、terraform な感じです。 仕事ではあまりインフラまわりを触ることがなく、CI/CD環境の知見があまりないが、それっぽいものを自分で作ってみようとしました。 フロント アプリケーション アプリケーションの土台はcreate-react-appを使いtypesc

    インフラが苦手な人の個人開発(ECS、terraform) - Qiita
    y_yuki
    y_yuki 2019/12/31
  • Visual Studio CodeでGo言語のデバッグ環境を整える - Qiita

    はじめに Visual Studio Code(以下VSCode)にてGo言語開発のデバッグができるようにするまでを示します。 前提条件 追記 2023年3月7日更新 以下の環境で動作確認済み MacOS OS version: 12.6 Monterey Chip: Apple M1 Goをインストール済み go version go1.20.1 darwin/arm64 $GOPATHを設定済み $GOPATH/binを環境変数$PATHへ追加済み VSCodeをインストール済み Version: 1.76.0 設定内容 delveをインストール VSCodeGoのデバッグをするにはdelveというデバッガツールをインストールする必要があります。delve自体は単独のコマンドラインで利用するGo言語用のデバッガでGo言語VSCode拡張機能がそれを利用しています。 Xcodeにて必要

    Visual Studio CodeでGo言語のデバッグ環境を整える - Qiita
  • DDD くらいできるようになりたいよねって話 - Qiita

    はじめに 私自身は今年の 7 月にドメイン駆動設計(DDD)を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD!2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で記事を書いた。 TL;DR(最初に結論) DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング

    DDD くらいできるようになりたいよねって話 - Qiita
  • リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita

    はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数

    リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
  • Go言語で扱えるデータフレーム厳選4つ - Qiita

    はじめに データサイエンティストでなかったとしても、数値データを使って様々な解析をする際には CSV ファイル等ファイルを読み込み、数値の配列としてメモリに保持して、それらをループ等で利用して解析を行っておられると思います。 その際、配列は1次元目に行、2次元目に列、を格納するのが一般的です。多くのケースではこの方法で事足りるのですが、解析を行ううちに「列としてデータの固まりを扱いたい」「ラベル付けされた列を扱いたい」と感じる事が出てくると思います。 これを簡単にしてくれるのが「データフレーム」です。 データフレーム4種 記事では Go 言語から扱えるデータフレームを4つご紹介します。 QFrame https://github.com/tobgu/qframe QFrame は、フィルタリング、集計、およびデータ操作をサポートするイミュータブルなデータフレームです。 QFrame での

    Go言語で扱えるデータフレーム厳選4つ - Qiita
    y_yuki
    y_yuki 2019/12/18
  • Goで日本語コメントを書く悩み - Qiita

    この記事はGo2 Advent Calendar 15日目の記事です。 コメントの悩み まずは復習から。 とりあえず関数を例にします。Goでは関数などのシンボルの上に、 関数名[半角スペース]内容... という形式でコメントを書くことで、自動的に関数とコメントを紐付けてドキュメント化してくれます。複数行書くこともできます。 // Hoge reports whether the hoge is fuga. // hogehoge. hogehoge. func Hoge() {} ↓ 便利ですね。 問題は、このコメントを日語で書くとき起こります。 社内で使うツールなどは、分かりやすさ優先でドキュメントは日語にすることが多いかと思います。個人的にも、そうした方がベターだと考えます。 そういったときよく見かける(自分の観測範囲内)のがこんなコメント。

    Goで日本語コメントを書く悩み - Qiita