moe - CLI based editor inspired by vi/vim written in Nim - Qiita
はじめに この記事はNim Advent Calendar 2020 2日目の記事で自分がNimで開発しているテキストエディタの宣伝です. 今回の記事では技術的な内容にはあまり触れません. 技術的な内容についてはそこまで大したことはしていないのですが要望があれば別の記事で書くかもしれません. 自分がNimを使って趣味で開発を行っているvim likeなCLIベースのテキストエディタです. GitHub: https://github.com/fox0430/moe moeはまだ開発で十分に安定していません. 自動バックアップの機能などはありますが重要なデータを編集する際は自己責任でお願いします. 名前について テキストエディターに詳しい方ならすでに気づいてる方もいらっしゃるかもしれませんがGNU moeと名前が被っています. しかも同じくテキストエディターです. 名前を付けたあとに被ってい
VimでGitHubを操作するプラグインgh.vimの紹介 - Qiita
gh.vimではgh://xxxといった仮想バッファのみ提供していて、Exコマンドは用意していません。なので一般的なプラグインとちょっと異なる使い方をします。 たとえばgh://golang/go/issues?state=allというバッファ名を開くと、そのバッファにissue一覧が表示され、キーマップが設定されます。 仮想バッファというのは、実際ファイルを作成せず一時的なバッファにデータを表示したり、キーマップを設定したりする手法です。 仮想バッファのみにした理由はこれまでにない形のプラグインを作ってみたかったからです。 あとは実装しやすさがあります。詳細については仕組みの項で解説します。 現在gh.vimが提供している仮想バッファは次になります。大体機能ごとにバッファが別れています。 buffer description
webpack で moment.js の無駄なロケールファイルを除去する - Qiita
と書いて webpack でビルドすると、生成される bundle ファイルのサイズが非常に大きくなってしまいます。これは、moment.js が持つすべてのロケールファイルが bundle ファイルに含まれてしまうためです。ファイルサイズにシビアなフロントエンドではかなり大きな問題です。 (上図は source-map-explorer を使って生成しました） 解決策 webpack の IgnorePlugin か ContextReplacementPlugin を使えば、この問題を回避することが出来ます。 IgnorePlugin を使う場合 「デフォルトの en 以外にロケールファイルは必要ない」という場合は、IgnorePlugin が使えます。 const webpack = require('webpack'); module.exports = { //... plugi
Next.js 4年目の知見：SSRはもう古い、VercelにAPIサーバを置くな - Qiita
Next.js by Vercel - The React Framework 画像は Next.js サイコー！っていう顔です。 Webフロントエンドエンジニアであれば、「Reactのフレームワーク」と聞いて真っ先に思いつくであろうNext.js。僕は小規模の趣味開発から中規模の業務まで、4年程度Next.jsを使い続けてきました。触りはじめの当時はバージョン4で、”SSR（Server-side Rendering）を提供するReact製フレームワーク”だったものが、執筆時時点の最新バージョン（10.0.1）ではガラッと異なるフレームワークへと進化しています。 この4年間は実務で利用するだけでなく、新しいものや廃止された機能、RFC止まりになった機能など、Next.jsに関する情報を追いかけており、ある程度の知見をためつつも、Next.js並びに開発元のVercelが目指す方向性を何と
憧れのTypeScriptフルスタック環境がコマンド1発で作れる超軽量フレームワーク「frourio」 - Qiita
今年6月のTypeScript Meetup #4で初公開されたTypeScript製フレームワーク「frourio (フルーリオ)」が今月のアップデートでめちゃくちゃカッコいい感じに仕上がっているので紹介します frourioはフロントからバックエンド・ORマッパーまでのアプリ全体を一つのTypeScriptとして統合型チェックが可能になるフレームワークです 1つのディレクトリで完結するので一見するとモノリシックのようですが、型で繋がっていること以外はフロントとバックが個別のプロジェクト扱い（それぞれに別のpackage.jsonがある）なのでフロントはVercel、バックエンドはDockerでAWSにデプロイするみたいなことが可能です 新しいfrourioの特徴 TypeScript製で最速のフレームワーク コマンド1発でフロントSPA + RESTサーバー + ORマッパーの環境構築
react-firebase-hooksを使ってみた（Firestore Hooks編） - Qiita
はじめに 前回の記事でreact-firebase-hooksのAuth Hooksを使ってみたのですが、今回はFirestore Hooksに挑戦したいと思います。 リポジトリはこちらです。 このライブラリは、4種類のAPIを提供しています。 Auth Hooks Cloud Firestore Hooks Cloud Storage Hooks Realtime Database Hooks 今回対象とするのは2つ目のFirestore Hooksです。 テストデータの作成 最初に、Firestoreのコンソールでコレクションといくつかのドキュメントを作成します。コレクション名はtodosとしました。 コーディング モジュールのimport 今回使うモジュールをimportします。 import React, { useState } from "react"; import Reac
API Gateway 開発者に読んでほしい、意味がわかると便利な実行ログ - Qiita
API Gateway (REST API) では、開発やトラシューに役立つ実行ログ (Execution Logs) を出力することができます。 AWS サポートに問い合わせる際にも、この実行ログがあるとスムーズです。 実行ログは、ステージから設定できます。 設定後、API Gateway にリクエストを投げると、CloudWatch Logs に出力されます。 ロググループ名は、API-Gateway-Execution-Logs_<API ID>/<ステージ名> です。 こちらの実行ログの内容を解説していきます。 リクエスト/レスポンス API Gateway に Postman から以下のようにリクエストを投げます。 パスパラメータ groupId=111、クエリパラメータ userId=222、本文に name=hoge を指定しています。 API Gateway はこのリクエス
C#でテキストエディタエンジンをフルスクラッチで実装してWebAssemblyで動かした話 - Qiita
デモ 以下のリンクから試せます。 https://crash.jp/apps/crash-editor/ 未圧縮版（5MB） https://crash.jp/apps/crash-editor-br/ Brotli圧縮版（2.1MB） 環境によっては表示まで数秒かかります。二回目以降はキャッシュから読み込まれるので、表示に時間はかかりません。 キャッシュはブラウザの開発ツールから削除可能です。以下はChromeの場合。 開発ツール > Applicationタブ > Cache > Cache Storage ※デモを何度か上げなおしているので、エラーになる場合にはキャッシュを削除してみてください 動作環境 WebAssemblyに対応したブラウザが必要ですが、最近のブラウザであればまず問題ないです。 自分で確認した環境 Windows 10 Pro, Chrome/新Edge/Fire
Emacs の起動時間を""詰める"" - Qiita
おしらせ ： 長い記事は本形式になっていた方が読みやすそうなので、 Zenn に お引越し してみました。ここにも記事は残しておきますが、最新版はあちらになります。 Emacs はプラグインを増やしていくと起動に何秒もかかって重い、という話をみることがあります。 しかし、考えてみれば Emacs には 1000 以上の Emacs Lisp ファイルが初めから同梱されているわけで、そこに数十のプラグインを足しただけで爆裂に遅くなるのは、なにか設定にも問題がある気がします。 この記事では、 Emacs の起動時間を詰めるために今までに試してきた、小技や大技たちを紹介します。 自分用にメンテしているフレームワーク setup.el で活用しているテクニックが主なので、そちらを試してみて欲しい気持ちもありますが、それぞれの Tips 単体でも価値があると思うので記事にもまとめてみることにしました
過去の自分に教えなければならないVSCodeのショートカット - Qiita
以下はVitor Paladini ( Twitter / GitHub / dev.to ) によるVS Code shortcuts that I would teach myself if I had a time machine with limited fuelの日本語訳です。 VS Code shortcuts that I would teach myself if I had a time machine with limited fuel 「やあ俺だ。黙って聞いてくれ。時間がないんだ。」 「待って待って、お前誰だ。どうやって部屋に入ってきた。あとどうして俺そっくりなんだ。」 「俺は未来のお前だ。ここまで来たのは、特別にVSCodeのショートカットを教えるためだ。さあいくぞ」 「正気か？ロト6の番号でも株式情報でもなく、わざわざVSCodeのショートカットを教えにやってきた
Atom の PHP 補完を vim-lsp で使う - Qiita
Vim で PHP を書くときは vim-lsp で Intelephense を使っているのですが、プロプライエタリなソフトウェアなのでサーバサイドのコードが公開されていません。Intelephense のウェブサイトはあまり親切ではなく、初めてインストールしたときは正しく動かせているのかよく分からなかった事を覚えています。 そのため OSS の PHP LSP を探していたところ Serenata というソフトウェアを見つけました。 Serenata は Atom エディタのプラグインとして公開されていたようです。サーバ型の Serenata 本体と、Atom プラグインの php-ide-serenata の2つで構成されています。バージョン4までは Atom エディタ用ですがバージョン5で Language Server Protocol をサポートしたようです。 対応している L
Safariは危険なJavaScriptに対応しない - Qiita
Firefox / Safari 先日Appleが、Safariは幾つかのWebAPIに対応しないと公言しました。 日本語記事も幾つか出ています。 しかし、どのサイトも対応しないAPIの一覧を並べてはいるのですが、それぞれのAPIが具体的にどのようなものなのかを記載した記事が見当たらなかったので、以下はそれらについて調べてみたものです。 対応しない理由 a threat to user privacy、すなわち、あくまでブラウザフィンガープリントなどの手段によって個人を特定・追跡できてしまうからという理由です。 セキュリティ的にも問題なAPIが並んでいるのですが、そちらは理由ではありません。 対応しないWeb API Web Bluetooth caniuse RFC 非公式日本語訳 解説 ブラウザからBluetoothを通して接続先のデバイスにアクセスすることができます。 データ転送形式
Vim で Prettier かけながら、TypeScript の型チェックを行う（with vim-lsp） - Qiita
Vim で Prettier かけながら、TypeScript の型チェックを行う（with vim-lsp）VimLSPLanguageServerProtocol この記事は Vim Advent Calendar 2019 向けに書かれました。 もう一つネタがあって記事を書いていたのですが、 なんか微妙な出来だったので Advent Calendar とは別として投稿しようかなと思っています。 はじめに この記事は Vim を使っている vim-lsp を使っている TypeScript を書いている prettier/eslint を連携させたい！ な人向けの記事です。 本題 vim-lsp を使って TypeScript の開発をしているならば、 使っている言語サーバは typescript-language-server ではありませんか？ よく出来ていますよね。快適です。 し
「(HTML) + CSS」のみを使って、今「リアルな電卓」を作ってみた - Qiita
続編を書きました。CSSも大幅改善してるので、一度見てみてください。 【小数点実装】「(HTML +) CSS」のみを使って、今「もっとリアルな電卓」を作ってみた - Qiita 完成品 まずは、CodePenで完成品を紹介します。ボタンを押して計算を試してみてください。 ※ スマホだと反応が悪い場合があります。 See the Pen qiita_calc_last by j5c8k6m8 (@j5c8k6m8) on CodePen. はじめに はじめて、CSS カウンター の存在をはじめて知ったときは驚きました。 テーブルの行番号は (必要であればJavaScriptで動的に) HTMLに記載するしか方法がない と思っていたからです。 Qiitaにも、CSSカウンターのサンプルを載せた良記事があります。 CSS でテーブルに行番号を振る - Qiita CSSで見出しタグに連番をつけ
TypeScript 製のフレームワーク FoalTS を使ってみる - Qiita
FoalTS とは TypeScript で作られている Express ベースのウェブアプリケーションフレームワークです。 多くの Node 向けフレームワークはマイクロフレームワークで、気軽に始めるのはいいのですが、ちょっと込み入ったアプリにしようと思った時にあまりに自由度が高いので意外と開発が難しくなる傾向がありますよね。 その点、FoalTS は軽量なスタートから、堅牢なアプリケーションを開発するために必要な基本的な機能を提供してくれるフルスタックフレームワークとしても使える (とドキュメントには書いてある) ということなので、サーバーサイドを Node で運用したいときに Express に代表されるようなマイクロフレームワーク以外の選択肢として結構良いかもしれないと思い、少し試してみることにしました。 プロジェクトを作る 多くのフレームワークと同じく、プロジェクトを作成したりで
Reactのレンダリングに関する完全ガイド - Qiita
この記事はComplete Guide to React Rendering Behaviorの翻訳記事になっています。 ご本人(Markさん)にも許可を頂いて翻訳しております。 こちらの記事がReactのレンダリングを理解する上で今までで一番体系的で一番分かりやすかったので、ぜひ紹介したく翻訳させて頂きました。 翻訳ツールにもたくさん助けてもらいながら行い、意訳が出来ていない部分が多々あるかと思いますので修正依頼を出して頂けると幸いです！ Twitterでも、フロントエンドに関する事や、アメリカでのエンジニア経験に関してツイートしているので、よかったらフォローお願いします。 Twitter: @hellokenta_ja 下記から本文です。 Complete Guide to React Rendering Behavior この記事は、Reactレンダリングがどのように振る舞うか、Co
GitHub の issue を見逃さないようにするツール - Qiita
はこです。こんにちわ。 GitHubのissueを、いわゆるチケット駆動開発のチケットとして使っているような場合や、そうでなくてもPullRequestを活用する開発の場合、割当られたissueの見逃しって難しい問題ですよね。 シンプルかつ使いやすい＆gitのコミットに連動するので、issueは手放せませんね。ただ、標準機能だとissueの通知・閲覧がちょっと不便なので、いろいろなアプリを入れていると思います。 今日は、そういったGitHub issueビューワーを色々と比較してみます。 Github issueビューワー一覧 良かったやつ Gitscout https://gitscout.com/ 無料 内部実装はElectron。なのにmacにしか対応していない。 Jasper https://jasperapp.io/ 12ドル 内部実装はElectron 日本の方が作ってるだけあ
DjangoでModelChoiceFieldのquerysetを動的に指定する - Qiita
はじめに マスタ参照してるリストボックスについて、ログインユーザーの権限に応じて選択可能なアイテムを制御したい…というケースが発生。 ↓のモデルとフォームをサンプルに、調べて試してみたやり方のメモ。
Working out Loud, Working in Progress - Qiita
デジタルツールで組織をKaizen シリーズ vol. 1 はじめに こんにちは、@shootaです。 デジタルツールでのコミュニケーションの理想像について、フルリモートで培った経験や知見をまとめていこうと思い立ちました。今回はvol. 1ということで、「うまく働くひとたちのチャットコミュニケーション」について、ひとつ書こうと思います。 まず考えてみよう 仕事をするときに、同じ場所にいる場合とそうでない場合の違いについてまずは考えてみましょう。同じ場所にいないとき、何が失われるでしょうか。「話合いで得られる情報や知見」はもちろんですが、実は無意識に受け取っている情報の多くを気づかぬうちに失っています。 たとえば、 相手がいま作業をしている・いないという視覚情報 相手の作業に求められる集中度 お互いの音声をつかったニュアンスの伝達 表情や雰囲気から読み取れる情報 あせりや疑問、我慢などのスト
このFat View Controller、あなたはリファクタリングできますか？ - Qiita
iOS アプリ開発において、 Fat View Controller はよく知られたアンチパターンです。 iOS アプリ開発では View Controller が大元にあるので、 View Controller になんでもかんでも実装していると、どんどん View Controller が肥大化してしまいます。 Fat View Controller には、たとえば次のような問題があります。 UI とロジックが分離されておらずテストしづらい。 コードの見通しが悪く、可読性が悪い。 状態管理が複雑になり、修正時の影響範囲を見通しづらい。 みんなで同じファイルを触ることになり、コンフリクトが起こりやすい。 そんな Fat View Controller との戦い方の知見を共有し合うために、たくさんのiOSエンジニアで同じ Fat View Controller のリファクタリングに取り組んで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
