はじめに こんばんは！ 皆さんは以下のようなすぐ消えてしまう要素をDevToolsで確認したいときはどうしますか？ 常に表示されるようにわざわざコードを修正してから、DevToolsで要素を確認したりしていませんか？DevToolsをうまく使うことで、わざわざコードの修正をせずとも簡単に要素の確認をできるのでそのちょっとしたTipsのご紹介です！ ① CSSイベントでの確認方法 まずはCSSイベントで要素の表示制御を行っているパターンでの確認方法です。以下のようにCSSイベントのhoverで表示制御をしている要素を例にDevToolsで確認する方法を見ていきましょう！ import "./style.css"; export const Index = () => { return ( <div> <button className="myButton">Button</button> <
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
どうもエラーを出すもしくはエラーが出るのが怖いという人がいるみたい。例えば改修を行うときに既存部分でエラーが出ないことを最優先にして増築を行いいびつな構造を生み出すとか、単純に例外を全然使わないとか。エラーが出ると、「うわ、エラーになった。手間かけさせやがって面倒だなぁ…」みたいな感覚があって、とにかく自分がコードを書くときも一切例外を投げないというスタンスをとりがちなのかもしれない。 私はここで、適切にエラーが出てくれるのはむしろ喜ばしいことであり、自分がコードを書くときも積極的にエラーを出すようにすべきだ、という主張をする。 関数定義のドキュメンテーションの一部 ある関数の中身で一番最初に書くべき処理は何か、それは引数のチェックをして条件を満たさなければエラーを出すことである。例えば文字列は特定の形式になってなければならないとか、数値に最大値最小値があるとか、これらは関数の入力の前提条
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
GithubのISSUE番号や、解決したいチケットの番号をブランチ名にすることがあるかと思います。 その番号を各コミットメッセージに入れておけば、コミットメッセージから関連ISSUEやチケットをたどることが簡単になるので、コミットの意図がわかりやすくなって便利になります。 ただ、手動でコミットメッセージに番号を打つのは面倒なので、git hooksを設定して、自動でコミットメッセージに入力されるようにします。 Templateを設定する まずはコミットメッセージのテンプレートを設定します。 個人的には、emoji prefixが確認しやすいテンプレートを使いたいので、Goodpatchのテンプレートを参考にして、以下のようなテンプレートを使用しています。 {branch} # ==== Emojis ==== # 🎉 :tada: 盛大に祝うべき大きな機能追加 # 🎨 :art: 見た
認定スクラムマスターの資格取得について、ご紹介します。 まず認定資格を取得するためには、認定スクラムトレーナー(CST)の研修を受け、その後テストに合格することで、めでたく資格取得となります。 テストと聞くと、少し難しく思うかもしれませんが、それほど難しいものではありません。 認定スクラムマスターのテスト受講概要認定スクラムトレーナーの研修を受けた後、認定スクラムマスターの資格を提供しているScrum Alliance(スクラムアライアンス)から、Welcomeメールが届きます。 そこからは、メールの内容に従いマイページの設定を完了すれば、テストの準備が完了です。 Welcomeメールから90日以内が、テストの推奨受験期間です。この期間中、オンラインで自由に実施が可能なので、ご自分のタイミングで受験ができます。言語は自由に選択可能でき、もちろん日本語の選択も可能です。 テストは制限時間60
テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。 私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。 チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。 チームの位置づけ UI改善チームとは hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。 私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。 hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。 フロントエンドチームの構成 フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
Pornhubをご存知だろうか。 答えは当然Yesだろう。 ところがその本当の実態について我々は理解しているだろうか。 WikipediaのPornhubページには興味深い事柄が書いてある。 YouTubeに次ぐ世界第2位の動画共有サイト 360度動画を提供しており、PlayStation VRで視聴できる 上下運動で発電できるリストバンドを発明した 宇宙空間でポルノを撮影すると発表した VPNHubというVPNサービスを開始した これらのいくつかを恥ずかしながら私は知らなかった。 この恥ずかしさがモチベーションとなり、私はPornhubのポルノ以外のことを調べた。 出てくるものはアダルトコンテンツばかりだったが、 以下の3つのページに出会うことができた。 Pornhub Insights :: Digging deep into the data Interview with a Por
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの2日目の記事です。 TL;DR TDDの実践方法を実際にコードを書いて解説します TDDの「レッド・グリーン・リファクタリング」のリズムを学ぼう 何度もテストを実行して、プログラムに対する不安を取り除こう TDDはテスト技法ではなく設計手法 TDD Boot Camp Sendai 9thに参加しました。TDDの伝道師和田さん（@t_wada）を講師に迎え、有志たちで開かれた勉強会でした。 午前中は和田さんによるTDDに関する講演とライブコーディング。午後は参加者同士のペアプロで出題されたお題を実装していく活気あるイベントでした。 イベントを通じてTDDはテストファーストのことだと考えていた自分は目を見開かされました。TDDは単にテストファーストでプログラムを実装することではなく、実装（ソフトウェア）が
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
自分の変更は master ブランチに対して行わない．作業用のブランチを master とは別に作って，以降そのブランチに対してコミット Fork 元のリポジトリ（本家）を upstream という名前でローカルのリポジトリに登録 ローカルの master ブランチに upstream/master を pull master ブランチを作業用ブランチに merge 3. と 4. のくりかえし 具体的なコマンド 上の 2., 3. の方法を具体的なコマンドで説明します． 2. Fork 元のリポジトリ（本家）を upstream という名前でローカルのリポジトリに登録 git remote コマンドを使います．たとえば，
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? gitのpush.defaultの設定に関して、他人のを設定してあげることもあり、毎回迷うのでまとめました。 push.defaultは、今まではmatchingというのがデフォルトでしたが、Git2.0からsimpleっていうのがデフォルトになります。なので、何らかの設定をしないと、以下の様な警告が出たりします。 warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
