目黒 @nokolover 先日鍋をめちゃくちゃ焦がしてしまいTwitterで嘆いていたところ「玉葱の皮を煮て冷ました汁を使って金属たわしで擦ると落ちるかも」という情報をいただいて試した結果がこちらになります。すっげー!! pic.twitter.com/wbYtTrIhoe 2021-12-04 08:07:16
こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに? ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
はじめに 基本的にReact + TypeScriptでフロントの開発をしているんですが、実際にコードを書いている時に気をつけていること、便利な書き方として知っておくと得をするReactコンポーネントの書き方を紹介します。 Propsが多くなりすぎたら やたらpropsが多くなってしまうことありませんか?しかも同じような名称ばっかりを何回も書くことになるという。そうゆうときはできる限りショートハンドで書きましょう。 return ( <SampleComponent type={user.type} name={user.name} email={user.email} image={user.image} /> )
※ Product Manager Advent Calendar 2018 の1日目の記事となります。 はじめにプロダクト・マネージャーの皆さん、PRD(Product Requirements Document)に何を書いていますか? ここでは”初めて”書くPRDとして、一体どういう内容を書けばいいのかを述べたいと思います。具体的な粒度については、Product Huntの例(本文参照)を見ていただければと思います。 PRD Template例えば、プロダクト・マネジメント界隈では知らない人はいないであろう、及川さんのこちらの記事にもPRDについて述べられています。 上記の記事は2017年のものですので、内容もアップデートされていると思いますが、参考になる部分は多々あります。上記の記事の再掲となりますが、記載すべき内容の見出しを以下に列記します。 1. 概要 2. 背景 3. プロダク
[[toc]] ESM & CJS ESM - ECMAScript modules CJS - CommonJS In the past decade, due to the lack of a standard module system of JavaScript, CommonJS (a.k.a the require('xxx') and module.exports syntax) has been the way how Node.js and NPM packages work. Until 2015, when ECMAScript modules finally show up as the standard solution, the community start migrating to native ESM gradually. // CJS const cir
アプリケーションエンジニアのid:tkzwtksです。今回はバッチ処理の冪等性(べきとうせい、idempotence)について、どう考えるか/考えてきたかをご紹介します。 このエントリを書くきっかけとなったのは、はてなエンジニア有志で定期的に開催しているCloudNative推進会です。ここでは、社内のシステムをクラウドネイティブにしていくため「クラウドネイティブなシステムとはどういうものか?」を考えており、この会での「クラウドネイティブなバッチ処理」の議論も踏まえつつ説明していきます。 バッチ処理における冪等性とは メッセージ送信の信頼性を考慮する クラウドネイティブで可用性を高めるために どのような場合に冪等性を考慮すべきか 冪等な実装における3つのケーススタディ ケース1: n分前までに更新されたレコードを集計する ケース2: DB上の対象レコードを更新する ケース3: 対象ユーザー
ページのコンテンツが少なくても、フッタを一番下に配置するCSSのテクニックを紹介します。コンテンツが多ければ、成り行きで配置されます。 フッタの高さは自由で、CSS GridやFlexboxやcalc()は使用せず、追加のラッパーも必要ありません。シンプルなHTMLに、数行のCSSで簡単に実装できます。 A Clever Sticky Footer Technique by Chris Coyier 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに コンテンツが十分な量でなくてもフッタを一番下に配置する方法 はじめに 「スティッキーフッタ」というと、ページをスクロールした時にぴたっと固定表示されるposition: sticky;を思い浮かべる人が多いと思います。 しかし、それはここで話すこととはすこし異なります。 「ス
「関数型プログラミングは関数型言語じゃないとできないんでしょ?」という質問をたまに受けます。答えは「いいえ」です。もちろん、言語のサポートはあれば越したことはないです。 そもそも命令型及び関数型はプログラミングスタイルです。そして、命令型と関数型の間は0/1ではなく、グラデーションがあります。 なので、関数型プログラミングは関数型言語以外でも使えますし、プログラムをよい設計へ導く考え方ですよ、というのがこの記事の主張です。コード例も交えて説明してみます。 関数型へのアプローチ ロジックを書くとき 可変の変数(var)を使わず、不変の変数(val)を使う 可変のオブジェクト(mutable)を使わず、不変のオブジェクト(immutable)を使う voidやUnitなどの戻り値のない関数は使わず、戻り値を返す(高階)関数を使う 関数を定義するとき 参照透明な関数を定義する 必ず意味のある戻り
クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ&集約ファクトリ
Docker Desktopを使っている場合、下記の通りExperimental FeaturesのUse the new Virtualization frameworkを有効にしてDockerを再起動します。 免責 私の環境では常時160%以上CPUを使用してたコンテナが常時60%程度になりました。この機能はまだ実験的機能で本記事の内容で安定性と効果を保証するものではありません。 雑感 筐体の温度やバッテリ持ちも改善すると思う。安定性は特に変わらない。 M1チップって書いてるけど、Intelチップでも改善する気がする。あとで比較してみる。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back us
私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生50年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを2つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ
GitHub にコードを上げてます。 2021-11-17 時点で Go の Generics の機能を使ったキャッシュライブラリはおそらくないでしょう。Generics を使った例の一つとして参考にしてください。 Star をくれると大喜びします。 本記事ではこのキャッシュライブラリを作ってみて Generics に対して気が付いた点と発見した tips や微妙だった点を紹介していきます。 もし Go の Generics って何ができるんだっけ?となっている方は是非こちらの記事にも目を通してみてください。 any でゼロ値を返す これは @syumai さんから教えてもらった tips です。 次のような any と error を返すコードをよく書くことになるでしょう。関数内で error が発生した時に今までゼロ値と error を返すコードを記述していたはずですが、ちょっと頭を捻
9月にリリースされた VS Code 1.60 のリリースノートを読んで、発見した機能です。(1.60 で実装された機能ではありません) 以下でもちらっと触れましたが便利なので別途記事を書いてみました。 code - では皆さん、おもむろにシェルを開いて以下を入力し実行してみてください。 ls | code - bash なら以下のフォーマットで VS Code が立ち上がり、 PowerShell の場合は以下のフォーマットで VS Code が立ち上がったかと思います。 この時シェルは以下の状態で止まっています。 Reading from stdin via: /tmp/vscode-stdin.F5FrMB.txt VS Code を閉じると再びシェルが使えるようになります。 この code - については code -h でヘルプを見れば3行目に書かれています。(今まで見逃してた…
こんにちは、サービス開発課の丸山です。 本日はタイトルの通り、サービス開発課で開発している Cloud Automator の新機能の開発前の段階で行っている取り組みについてご紹介したいと思います。 とは言っても、うまくいっているベストプラクティスというほどのものではなく「今のところ実験も兼ねてこんな感じで回しています」という温度感のものです。 そのため、うまくいった取り組みや利点はもちろんのこと、課題に感じている部分も紹介していければなと思っております。 開発前に行っている取り組み 今回は次の3つの取り組みを紹介したいと思います。 Working Backwards ユーザーストーリーマッピング Example Mapping これらの取り組みは実装に着手する前に1~3の順番で行っています。 Working Backwards 背景 Working BackwardsとはAmazon社内
TL;DR 主にモバイル端末からの利用において、ユーザーが手間取ることが多い エンジニアなど、リテラシーが高いユーザー層を対象にした場合にのみ利用したほうが良さそう マジックリンク認証、使ってますか? マジックリンク認証とは、メール内に記載されたリンクを踏むことで認証が完了する認証方式です。パスワード流出のリスクが無いことから、パスワード認証に比べてセキュアな点が特徴です。 Slackが採用しているため、ユーザーの立場で使ったことがある人は多いと思います。 筆者は一時期Firebaseを多用していたのですが、Firebase Authenticationを使用すると簡単にマジックリンク認証を実装することができ、またパスワード設定/変更/忘れ等を考慮する必要がないことから実装の手間を省けると考え、個人開発のプロダクトで採用しました。 実際開発は短期間で終わり、最小限のコード量で済んだことから
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回:技術的負債はなぜ生じるか。 第2回:ソフトウエア開発を「制御」する意外な処方箋 第3回:技術的負債への取り組みはなぜ「2つのDX」につながるのか。 第1回:技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債(あるいはレガシーシステム)はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
はじめに ある日、クリーンアーキテクチャで定義した各レイヤーの依存関係が正しいかどうかを ESLint がチェックしてくれると楽だよねという話が出た(今のプロジェクトではこのような構成を取り入れております) ESLint に追加したいルールの要件を整理してみるとわざわざ plugin として公開するほど汎用的なものでもないと思い、プロジェクト内で完結する ESLint の独自ルールを作ってみたというお話 ゴール 下記に示すディレクトリ構成で以下の条件をチェックしたい domains配下のファイルはinfrastructures、adapters, usecases, view-modelsを import しない usecase配下のファイルはinfrastructures、adaptersを import しない view-models配下のファイルはinfrastructures、ad
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く