Big Sky :: Windows ユーザは cmd.exe で生きるべき 2020年版
はじめに 2016年にこんな記事を書きました。 Big Sky :: Windows ユーザは cmd.exe で生きるべき。 [D] Windowsはターミナルがダメだから使えないってのは過去の話? 基本的にはいい感じに見えますが、いくつか問題は発覚してます。 http://blog.drikin.com/2015/01/w... https://mattn.kaoriya.net/software/why-i-use-cmd-on-windows.htm この記事は日常からコマンドプロンプトを使うユーザに Windows で生き抜く為の僕なりの方法を教授したつもりです。最近は PowerShell を使われる方も多いと思いますが、僕はどうしても PowerShell が好きになれず、未だにコマンドプロンプトで生き続けています。 あれから4年 記事の反響は結構大きく、いろいろなコメントも
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える - エンジニアHub｜Webエンジニアのキャリアを考える！
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える 技術的負債、デザイン面での課題など、サービスを構成するシステムを全面にわたってリニューアルしたプロセスを、オミカレの高橋一騎さんが克明に伝えます。 株式会社オミカレでテックリードをしております、高橋一騎（たかはし・いっき／ @ikkitang ）です。私たちが提供する婚活メディアサービス「オミカレ」は、2019年3月にシステムのフルリニューアルに踏み切りました。本稿では、このリニューアルのプロセスをできるだけ詳細にお伝えしたいと思います。 さて、「技術的負債」という言葉を耳にすることがあります。なぜ負債が生まれるのか。「品質を犠牲にしてでも早々にサービスをリリースし、短期的にビジネスの速度を上げる」という判断はその理由の一つに挙げられるでしょう。エンドユーザーへの価値提供スピードを得るための見返り
分散アジャイルチームについて考える会。またはMuralの負荷試験について #distributed_agile_team #オンライン勉強会 - うさぎ組
COVID-19の影響でIT系の人達はテレワーク導入をすすめているけど、どうなんでしょうね。っていうかんじで勉強会を spring_akiさん、TAKAKING22くんの3人でやってみました。 4月21日と5月5日の2回やり、どちらもLTを数本と、OST(みんなでトピックをきめるディスカッション)。 特に、5月5日は、13:30 - 19:00までのほぼ1日やってみるというものでした。 これらの回の概要、そしてどんなツールをつかったのかを紹介します。またツール選定にあたっておこなった負荷試験のスクリプトも紹介します。 イベント概要 利用したツール Muralは50名付箋のみ同時編集なら余裕、80名以上でもたつく オンラインOSTはいいぞ！ 最後に イベント概要 分散して活動していくアジャイルチームについて議論していく場があればいいなと思って、4月頃に某コミュニティで話していて、特に大きな知
俺の webpack.config.js-20200503 - mizchi's blog
基本思想 とにかく薄く。必要なものだけ。基本は ts-loader を transpileOnly: true で使うだけ。最悪これだけでいい。型チェックはIDEか yarn tsc -p . --noEmit でやる。 CRA や parcel は使わない。暗黙な振る舞いが多すぎるので。一切勉強したくない人はいれていいと思うが、その場合 eject しない、dist ディレクトリをそのまま使うこと前提。 style-loader/css-loader は外部CSSを読むときに設定する worker-plugin はなくてもいいけど、 worker もビルドしたいことが多いので、入れていることが多い html-webpack-plugin と webpack-dev-server 組み合わせると、他と組み合わせずに完結して動く。このHTMLを本番で使わずとも、デバッグで使ってることが多いの
ゲームで学ぶ「役に立つ」ドメインモデルの考え方 - Qiita
概要 顧客にとって役に立つソフトウェアを開発するには、モデリングが重要だと言われています。モデリングによってソフトウェアの価値が高まると言われています。 モデリングとは一体何でしょうか。 単にUMLでクラス図を描くだけでしょうか。 本記事は、ドメインモデルの考え方についてなるべく容易に理解できるよう、ゲームを題材に解説を試みたものです。 留意 本記事では実在の製品を例に挙げて解説していますが、モデル図等はあくまで筆者の私見、個人的な推測であり、実際の製品開発で考案されたモデルとは異なるであろうことにご留意願います。 また、「ドメインモデル的な見方をすればこのようなモデルとなるのでは」と私個人が解釈した内容であることにもご留意願います。 ドメインモデルとは何か 「モデル」と言っても文脈により様々な解釈がありますが、本記事ではドメイン駆動設計に登場するドメインモデルに従います。ドメインモデルな
Let's make a contract: the art of designing a Java API
Let's make a contract: the art of designing a Java API 1. Let's make a contract: the art of designing a Java API by Mario Fusco mario.fusco@gmail.com @mariofusco 2. What is an API? 3. What is an API? 4. An API is what a developer uses to achieve some task What is an API? 5. What is an API? An API is a contract between its implementors and its users 6. And why should I care? We are all API designer
エンジニアが成果アピールで意識すると良い4つの観点 | Recruit Tech Blog
はじめに結論 自身やチームの取り組みをアピールする際、以下4つの観点 (Issue度・解の質・革新性・主体性) を意識すると、成果アピールの説得力を高めることができます。 成果 (創出した物事の価値・意義) Issue度: どういった／どのくらいの問題に取り組んだか？ (重要度・規模感・難易度) 解の質: やったこと／結果は、どういった／どのくらいの変化・貢献をもたらしたか？ (価値・意義) プロセス (成果を生み出した理由・背景) 革新性: アプローチ手法の着眼の良さ／工夫点はあるか？ (アプローチ方法) 主体性: アプローチをどのような立場で／どのくらい主体的に推進したか？ (進め方) これらの観点を意識して適切に成果アピールできるようになると、成果面談などの社内イベントのみならず、社内外のプレゼンや転職活動 (レジュメ作成・面接・交渉) など様々な場面で役に立ちます。 そもそもこれは
【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
RDRA２.０についてまとめみた（後編） - Qiita
はじめに RDRA２.０についてまとめみた（前編）の続きになります。 前編ではRDRA２.0へ取り組むモチベーションや特徴、ざっくりした概要を説明しました。 後編ではもう一度RDRA２.0の特徴について理由を添えて説明したいと思います。 また、RDRA２.0で作成する各レイヤーの関係性や成果物についての説明を行いたいと思います。 目次 1.RDRA2.0の特徴について 2.各レイヤーの関係性について 3.各レイヤーの成果物についての説明 1.RDRA2.0の特徴について RDRA2.0の特徴として『RDRA２.0とはシステムの全体像を素早く、整合性を保ちながら明確にする』ことが挙げられています。この特徴について「全体像を素早く」と「整合性を保ちながら」という２つの観点に分けて理由を分析しまとめました。 RDRA２.0が素早く要件の全体像を把握できる理由 ポイント1. 作るモノが明確で、アイ
React/Redux約三年間書き続けたので知見を共有します | Enigmo Life
Enigmo Advent Calendar 2018の4日目の記事です。 この記事の目的 Enigmoが運営しているBUYMAでは古代から運用しているjQueryの他に、2016年頃から一部ページのフロントエンドをReact/Reduxで構築しています。 私自身もEnigmoに入社してからの約三年間でReact/Reduxアプリケーションの開発に多数携わってきましたので、そこで培った知見を共有したいと思います。 React/Reduxの利点 まずはじめに、ReactとReduxを使うメリットを再確認しておきたいと思います。 それぞれのメリットをしっかりと認識しておくことで、実装する際どう書くか迷ってしまった場合などにそのメリットを最大限活かす選択をすることができます。 Reactの利点 コンポーネント化が容易で再利用性が高い 状態をDOMから分離できる(Stateless) Reduxの
Springアプリケーションのテスト道具 使いどころ、使わないどころ - 日々常々
2019-12-18の Spring Fest '19 で登壇させてもらいました。みなさまありがとうございました。 資料 Springアプリケーションのテスト道具 使いどころ、使わないどころ です。タイトルの「使わないどころ」って日本語的に不自由な感じなんですが、「使うべきでない」とか禁止ではなく、プログラマとして「使わない」と意思を込めてる感を出したくてこうなっています。いい名前が思いつかないので変な名前をつけて、結局最後までいい名前が思いつかなかったパターンです。 なおこのセッションは、2019-07-18にこのブログで書いたどこでモックを使おうかを下敷きにしたものです。 補足もしくは蛇足 49-52ページ: テストで動かせる範囲とモックの例です。例なのでテストしたい対象見極めたら何とでもなると言うのと、それができるアーキテクチャが役立つよねと言う感じ。この一連の図は機能面で、ここで話
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita
同じTypeScriptという言語を利用する場合においても、トランスパイラによってTypeScript自体の機能制限がかかったり、思わぬトラブルを招く場合があります。それぞれのトランスパイラの特徴を踏まえた上で、それにより生じる問題も見ていきましょう。 1-1. tsc TypeScriptの開発元であるMicrosoft純正のTypeScriptトランスパイラです。TypeScriptを利用する際に typescript パッケージをインストールする必要がありますが、それに同梱されています。 公式ツールなだけあって最も早く最新バージョンのTypeScriptに対応したり、言語すべての機能を利用することができる一方で、バンドラではないためminifyやchunkの設定はできません。また、Path Aliasesの未解決や旧ESへの互換性が不完全であることが欠点として挙げられます。 tsco
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
ロギングベストプラクティス - kawasima
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「結論をタイトルにする」「最後のスライドには情報」など…プレゼンをするときに気を付けることがタメになる
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだこと
kawasima