コーディングに使用するフォントを何にするかは、非常に重要です。コードを記述、読み取る、修正・変更するなど、デベロッパーは多くの時間を費やします。 コーディング用のたくさんのフォントから、自分にとって読み書きに適した一番のフォントを見つけることができるオンラインツールを紹介します。
![コーディング用のフォントから、自分に適した一番のフォントを見つけることができるオンラインツール -Coding Font](https://cdn-ak-scissors.b.st-hatena.com/image/square/68d59639c6000b892c412f9836222832a81d069a/height=288;version=1;width=512/https%3A%2F%2Fcoliss.com%2Fwp-content%2Fuploads-202104%2F2021103010%402x.png)
IDisposable インターフェースの実装に焦点を絞った記事です。 using 構文による自動解放や、Finalizeや、GCのメカニズムについては、本記事末尾の資料をはじめとして、ネット上に良記事が沢山あるのでそちらを参考にしてください。 IDisposable インターフェース https://referencesource.microsoft.com/#mscorlib/system/idisposable.cs,1f55292c3174123d より抜粋 namespace System { [System.Runtime.InteropServices.ComVisible(true)] public interface IDisposable { void Dispose(); } } とてもシンプルです。 IDisposable が求めているのは、void Dispose
以下に示すプロパティは、プロファイルの設定に関係なく、ターミナル ウィンドウ全体に影響します。 これらは、settings.json ファイルのルートに配置する必要があります。 Default profile Ctrl + Shift + T キーを押したとき、newTab に割り当てられているキー バインドを押したとき、プロファイルを指定せずに wt new-tab を実行したとき、または [+] アイコンをクリックしたときに開かれる、既定のプロファイルを設定します。 プロパティ名:defaultProfile 必須かどうか: 必須 値: GUID またはプロファイル名を表す文字列 既定値: PowerShell の GUID 既定のターミナル アプリケーション Windows の既定のターミナル エミュレーターを設定し、すべてのコマンド ライン アプリケーションをその中で実行します。
Windows Terminal Windowsの新しいTerminalアプリケーション。WindowのTab化や様々な設定が可能。デフォルトでコマンドプロンプト、PowerShell、WSL、Azure Cloud Shellを使用可能。2020/5/19に正式版(V1.0)がリリースされた。 Preview版で実装されていた設定画面が、遂にV1.7安定板でも実装された。このページで説明していた設定ファイル(settings.json)の編集方法は、ページの後半に移動した。 How to install Windows 10 20H1 (build 19041)以降であれば、インストール可能。 Microsoft StoreからWindows Terminalを検索してインストール。とっても簡単。 Settings Windows Terminal画面でCtrl + ,を押す、またはTa
それほど大きくは取り上げられていない変更だが、多くの開発者に影響を与えるアナウンスがTwitterのWindows Insiderアカウントを通じて行われた。Windows 10のビルド21337から「Windows Terminal」がデフォルトでインストールされるようになったというものだ。Microsoftはここ数年、Windows Terminalの開発に力を入れてきた。今回のアナウンスは、Windows Terminalがデフォルトインストールのレベルまで到達したことを意味している。 Windows Insiderアカウントによるツイート MicrosoftはWSL (Windows Subsystem for Linux)によってWindowsでLinuxバイナリを実行する機能を提供している。現段階では、WSLを使ったLinuxはコンソールからの利用が前提だ(今後のバージョンでG
Windows ターミナルは、コマンド プロンプト、PowerShell、bash (Linux 用 Windows サブシステム (WSL) 経由) などの使い慣れたコマンド ライン シェル用の最新のホスト アプリケーションです。 主な機能には、複数のタブ、ペイン、Unicode および UTF-8 文字のサポート、GPU で高速化されたテキスト レンダリング エンジン、独自のテーマを作成したり、テキスト、色、背景、およびショートカットをカスタマイズしたりする機能があります。 さまざまなコマンド ライン アプリケーションをサポートする複数のプロファイル コマンド ライン インターフェイスを持つ任意のアプリケーションを Windows ターミナル内で実行できます。 これには、PowerShell およびコマンド プロンプトから Azure Cloud Shell、Ubuntu や Oh-M
はじめに ASP.NETにて入力チェックをするにはDataAnnotationによる標準のValidationフレームワークを利用することができますが、標準機能だけでは業務要件的に全てのケースに対応できない場合には結局自前で検証コードを書くことになる為、検証コードが複数個所に分散することを嫌って標準のValidationを使っていない方もいるかと思います。 また、いろいろな理由でDataAnnotationが使えず、コントローラや業務ロジック側で入力検証をする必要があるケースもあるでしょう。 その際に使用できるシンプルな入力検証フレームワークの一つがFluentValidationです。 https://docs.fluentvalidation.net/ これを使うと、フレームワークでできる部分はフレームワークに任せ、複雑な検証は自前のコードで追加で記述することが容易に可能です。 また、
本連載は、ソフトウェア開発者からプロダクトマネージャーに転身した、ゆずたそ(@yuzutas0)さんが自身の経験を振り返り、切り替えるべきだったと考えるマインドセットを紹介していく連載です。第2回は、「責任から逃げてしまう」という問題を取り上げます。自身の責任範囲は想像以上に広くなるのだ、ということを認識しましょう。(編集部) はじめに こんにちは、ゆずたそ(@yuzutas0)です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 「Not fo
始めに 私たちは極めて優秀なエンジニアかもしれない。 社内であなたは頼りにされているかもしれないし、有名なOSSのコミッターかもしれない。 もしくは勉強会において多少有名な存在として認知されているかもしれない。 だが私たちは普通の人間だ。 コードを書くのは時間がかかることもあるし、丸一日もしくはそれ以上問題解決がまったく進まないこともある。 学び続けなければすぐに置いていかれるし、知らないことも多すぎる。 私たちは天才ではない。 完成されたコードが頭の中にあってそれをコード上に書き写すなんてことはできないし、 驚異的な集中力を持ち合わせているわけでもない。 OSSなど既存のものをより良いものに書き直して使うことはできない。 天才の話を聞きたい方はこの動画を見てみるといい 今回の記事では、そんな天才ではない方がやってはいけないことをいくつか紹介していきたい 今回は自社開発の企業でチーム開発を
はじめに commit はファイル単位ではなく行単位でできることを知りました。 そこで commit の粒度をさげて commit履歴 をきれいにするというお話をしていきます。 対象の読者 今までcommitはファイルごとが限界だと思っていた。 もっと細かくcommitしたいときがあるけど仕方ない この記事でできるようになること 変更点が見やすくなる 先輩がレビューしやすくなる(してもらいやすくなる) レビューにかかる時間を短くすることができる 開発の途中で全部のコードをあげたくないときに上げたい部分だけcommitできるようになる なにを実装したのか明確になる(commit履歴に現れる) 目次 はじめに 対象の読者 この記事でできるようになること 目次 git add -p Stage this hunk [y,n,q,a,d,s,e,?]? 特徴 ? - print help y -
概要 WindowsPCの新調やクリーンインストールをした際に 開発環境をセットアップするための忘備録。 (2021/10/26時点) 0. Windows Updateを最新の状態にしておく 1. WSL導入 公式ガイドを参考に以下手順を実施する。 ⅰ. [WSLの準備コマンド(Ubuntu)]を実行する [スタートボタンを右クリック] -> [A] -> [管理者用Powershellに以下をコピペ & 実行] -> [コマンドの実行が終了後、再起動] ⅱ. [Ubuntu]の準備をする [再起動後、Ubuntuの準備が終了するまで待機] -> [ユーザ名 & パスワードを登録] ※ 初回起動時のみ、時間がかかる。 1. Windows Terminalをインストール & 設定 [Windows Terminalを入手] -> [新たに出現したウィンドウを閉じる] -> [起動] ->
基本的には Windows と Visual Studio を使って Azure Functions や GitHub で公開しているアプリケーションとライブラリを書いていますが、最近は Python や Go を書く必要がちょいちょい出てきたので、色々と観念して WSL 2 の環境を構築して使っています。 特に Python は Azure Functions だと Linux のみ対応となるので、Windows 上での開発は難しくなっています。他にも個人的に PR を投げている Terraform Provider for Azure も Windows 上では一部のテストが通らなくなっているので、WSL 2 を使わないと難しい状況です。 環境構築系はメモっておかないと後ではまるので、自分が必要な範囲で手順を残します。 基本的な WSL 2 環境構築 Visual Studio Cod
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
はじめに 最近、以下のツールの名前を良く聞くかと思います ・Visual Studio Code(コードエディタ、略称「VSCode」) ・WSL2(Windows上にLinux環境を構築) ・Docker(コンテナで環境を分ける) 流行りものの詰め合わせのように見えますが、併用することでシステム開発を大幅効率化できます。 特にPythonにおいては、構成管理や環境差の解決に大きなメリットがあると感じました。 本記事では、これらの組合せによるメリットと使用法を紹介します。 Windowsユーザで**「Docker興味あるのでこの機に試してみたい!」**という方向けに、流れの分かりやすい記事を心がけようと思います! WSL2とDockerとVSCodeを併用するメリット 併用でどのようなメリットがあるか見ていきましょう 前提 まず大前提として 開発環境がWindows、本番環境がLinux
概要 業務で「2つのテクスチャをブレンドするシェーダー」と「クロマキー合成を行うシェーダー」を合成したシェーダーを作ることになり、そこで学んだことを書いておく。 【Unity】2つのテクスチャを合成するシェーダー - Qiita Unity でクロマキーシェーダを作ってみた - 凹みTips シェーダーファイルの構造 テンプレートになりそうな内容を元に説明をコメントに追記した。 Shader "シェーダの種類/シェーダーの名前" { // Unityインスペクタに表示される項目 (マテリアルプロパティ) Properties { // テクスチャの設定 _MainTex("Texture", 2D) = "white" {} // 色の設定 _Color ("Main Color", Color) = (1,1,1,1) } SubShader { // どのようにレンダリングするか Ta
はじめに その昔DelphiやJavaを使っている時に、インターフェースの理解がモヤモヤしている時期がありました。 ググっていても、ふと気付くと何故かCOMの話になっていたりと、説明を読んでも良くわからない、メリットがいまいちピンと来ないという状態でした。 そして実際にインターフェースがなくても特に困っていなかったので、その頃の私には必要ないものだったのでしょう(※)。 ※今振り返ると「あそこは使えたな」という事もあったりしますが(^^; 当時、一番しっくりこなかったのが、 ...のように「変数xにインターフェースが代入できる」という表現でした。 実装のないインターフェースを代入できるって、どういう事!? ...と混乱していました。 前提 多重継承NGでインターフェースが使える言語なら、大体当てはまると思います。 最近はC#の人なので以降はC#で記述しますが、Delphi、Java等も考え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く