こんばんは。 たーせるです。
ついに@ngrxもバージョン8 になりましたね。
#ngrx のバージョンが上がり、いくつか破壊的な変更が発生している。 むしろなぜ今まで、あの冗長なActionの書き方が許されていたのか。 pic.twitter.com/hS9MKkvRaX
— たーせる (@tercel_s) 2019年6月15日
正直、@ngrxはSingle Page Applicationsにおける状態管理ライブラリとしては永らくvuexの後塵を拝してきた感がありました。 しかし上記のツイートからも判る通り、今回はなかなかどうして本質的なコーディングに集中できるようAPIが洗練されたなぁと思いました。
閑話休題。 今日の記事は、こちらの続きになります。
Guardの中で、遷移元のパス (URL) に応じて認可の可否を制御したい。 そのために遷移元のパスが何だったのかを調べたい！
もう少しだけ具体的に申しますと、直リンクを禁止したい（必ず特定のページを経由してアクセスさせたい）ような場合に使えるテクニックをご紹介したいと思います。
おはようございます。 たーせるです。
ついに Angular の バージョンが 8 になりましたね。おめでとうございます。おめでとうございます。
さて、最近はよく Bootstrap で遊んでおります。 非常にベタな CSS フレームワークですが、それなりに見栄えのするページを手っ取り早く作れるので大好きです。
Bootstrap を用いたレイアウトには 2 つの流儀があります。
1 つはページ全体を .container で包んだ「固定幅レイアウト」、もう 1 つは .container-fluid で包んだ「流動レイアウト」です（→公式ドキュメント）。
ぼくは前者を好んで使いますが、時々「ページの途中にある一部のコンポーネントだけはどうしても .container の枠を無視したい」というケースに遭遇することがあります。
基本は固定幅レイアウトでいいんだけど、ここだけは .container に押さえつけられず、横幅いっぱいにしたい……という。
<div class="container"> (略) <div> <!-- ★ここだけ、.container を無効化したい★ --> </div> (略) </div>
そんなときは .container のマージンを打ち消してしまいましょう。
ここでは、.container-cancellation というクラスを以下のように定義しました。
styles.css
.container-cancellation { margin-left : 0; margin-right: 0; } @media screen and (min-width: 576px) { .container-cancellation { margin-left : calc(-0.5 * (100vw - 540px)); margin-right: calc(-0.5 * (100vw - 540px)); } } @media screen and (min-width: 768px) { .container-cancellation { margin-left : calc(-0.5 * (100vw - 720px)); margin-right: calc(-0.5 * (100vw - 720px)); } } @media screen and (min-width: 992px) { .container-cancellation { margin-left : calc(-0.5 * (100vw - 960px)); margin-right: calc(-0.5 * (100vw - 960px)); } } @media screen and (min-width: 1200px) { .container-cancellation { margin-left : calc(-0.5 * (100vw - 1140px)); margin-right: calc(-0.5 * (100vw - 1140px)); } }
Bootstrap のブレークポイントごとに、.container を相殺するため、左右に負のマージンを設定しています。
これを適用した <div> タグは、常に横幅いっぱいに表示されます。
<div class="container"> (略) <div class="container-cancellation"> <!-- ★ここだけ、.container を無効化したい★ --> </div> (略) </div>
この .container-cancellation は、必ず .container が直接内包する <div> に適用してください。
.container の外側で単独利用すると、ウィンドウを突き破ってしまいます。
また、.row や .col-2 などの中に書くのも NG です。 あくまで、.container の左右のマージンを相殺するクラスだということを理解した上で利用しましょう。
では、また。
この記事は、Qrunchに投稿した記事1) 2)を、はてなブログ向けに再編集したものです。
アプリケーションのコンテンツをユーザに開示するかどうかを制御する仕組みの実装方法と、そのテストに関する手法を取り上げます。
よく混同される概念ですが、認証とは「その人が誰なのかを確認すること」、（狭義の）認可とは「リソースに対してアクセス権を与えること」です。
たとえばログイン処理のように、ユーザIDとパスワードを入力させて、『この人は鈴木一郎さんに違いない！』という判定を下すのが認証。
『この人は管理職ロールを持っているから、××機能に対するアクセスを許可しよう』とか、『キャンペーン期間中だけ特設ページへのアクセスを許可しよう』という仕掛けが認可です。
超お久しぶりです。 たーせるです。
どういうわけか疲労極まっており、いろいろ端折っております。 それでもなんとか書き留めておきたいので、ここに残しておくことにします。
今日は、Angular で Submit ボタンを連打されないようにするにはどうすればよいか考えてみたいと思います。
やりたかったことは、Angularで多重送信を食い止める仕組みを作ること。
— たーせる (@tercel_s) 2019年5月20日
① HttpInterceptorの入り口で、パラメータの HttpRequestをハッシュ化し、非同期通信が解決するまでどこかに保持しておく。
② 既に同じハッシュ値がいたら、多重送信とみなして通信をキャンセルする。
……というのが、基本的な思想になります。
唐突だけど、僕はずっと自分に自信がなかった。 というか今もない。 弱気で、グズで、ちょっとでも強い叱責を受けるとすぐに怯んでしまう。 ときどき自分の言動が正しいかどうか不安になることすらある。
自信がないから、僕はいつも上層部の言いなりだ。 それでいて「自分のやりたい仕事ができない」などと考えるどうしようもなさも持ち合わせている。
そんな僕の転機は、ある日突然訪れた。
どうやら、今回の人事考課で昇進候補者として選出されたらしい。 ── にも関わらず、自分は職権と責任を負う自覚が持てずにいる。 このままではいけないと、今の自分の在りように対して俄かに危機感が湧きあがった。
そんな折、新人時代に研修でちょっとだけ教わった『7つの習慣』というものをふと思い出した。
『7つの習慣』は、スティーブン・R・コヴィーによるベストセラーの自己啓発本だ。 あまりにもメジャーすぎて、おそらく多くの方が一度は耳にしたことがあると思う。
この本が巷に溢れる類書と大きく異なるのは、時代や文化に左右されない普遍の「原則」を意識して書かれている点である。 仕事のコツとか小手先のテクニックなど一過性の成功論は書かれていない。
僕はハッタリで誤魔化すやり方があまり好きではない。 中身がないのに虚勢を張っても、心身を消耗するばかりで誰も幸せにならないからだ。
その場凌ぎの付け焼き刃ではなく、自分の人格を内から育ててもうちょっと自信をつけたいと思い、『7つの習慣』を読んでみることにした。
そんなわけで、今日から数回に亘って内容を紹介していこうと思う。
※ この記事は決して特定の思想や信条を強制するものではありません。
もし今、なんだかうまく行かないなーと感じているなら、自分の根底にある「物の見方」を変えてみる必要があるかも知れない。
自分がいつまでも同じ見方をしている限り、自分の周りの問題はいつまで経っても同じ形をしたままだからだ。
その賢い頭をちゃんと使うんだよ。 見方を変えてみるんだ。
出典: 映画「ベイマックス」
見方を変えると、行動が変わる。 行動が変わると、結果が変わる。 場当たり的に行動だけを変えるのではなく、もっともっと自分の内面の深いところで価値観を支配しているパラダイムから変えてみよう。 ── というのがインサイド・アウトというアプローチだ。
ただし、インサイド・アウトで身の回りの問題がいきなりすべて解決するわけではない。
レベル1の駆け出し勇者が、功を焦っていきなりラスボスに戦いを挑んでも碌なことにならないし、経験値を上げずに装備ばかりを固めてもあまり意味がない。
それと同じように、人間の人格的な成長には段階があり、発揮できる力もそれぞれの段階において大きく異なる。 しかも、成長過程はどれ一つとしてスキップできない*1。
というわけで。
僕はこれから、自分の成長に応じて、内面を見つめ直す 7つの習慣*2を段階的に身につけていく。
実は、他人の許しを得なくても、僕たちには（あくまで責任の範囲内で）自分で行動を選ぶ自由がある。
なのに僕は、大事な決断を他人任せにしたり、状況に流されてばかりいたせいで、どうしてもここ一番というところで決定力が弱い。
現在の自分の姿は、今までの自分の選択と行動の結果なのだ。
主体性とは、自発的に率先して行動するだけを意味するのではない。 人間として、自分の人生の責任を引き受けることも意味する。 私たちの行動は、周りの状況ではなく、自分自身の決定と選択の結果である。
ここに書こうか非常に迷ったけれど、実は数ヶ月前、僕は取引先からの信頼を失いかねない大失敗をしてしまった。 今回ばかりは心底堪えた。
どれだけ打ち拉がれても、過去に戻って失敗を防ぐことはできない。
惨めな帰り道。
電車の中で、唐突に今この瞬間からの行動は僕自身の意志で自由に選ぶことができることを悟った。 突然、降って湧いたのだ。
たしかにつらくて仕方ないのだけど、でも今なら自分をラクにしてやることも、あるいは問題と向き合って根本解決に向けて動くこともできる。
さらに見方を変えれば、実は僕がいるところは思っていたほど窮境ではない ── かも知れない。
主体的でない人は、「関心はあるけど、自分ではどうにもできないこと」に多くの労力を割いてしまう。
たしかに僕も、ライバルへの嫉妬や劣等感に悶えて何も手につかなくなることが何度もあった。 ついさっきだって、自分の失敗を悔やんでいた。
そんなことをぐだぐだ悩んでも状況はなにひとつ変えられないのに。
一方、主体的な人は、「自分が影響力を発揮できること」「自分でコントロールできること」に多くの労力を費やすという。
もちろん、主体性は必ずしも思い通りの結果をもたらすとは限らない。 選択できるのはあくまで自分の行動だけだからだ。
でも。
少なくとも、無意味な苦しみを無駄に味わうことは減る。
単発的な成功体験だが、先日（2018/03/30）、主体性を発揮する局面があった。
残念ながら、弊社にはソフトウェアテストの結果を Excel に貼り付けて納品物に添えるという悪しき文化が残っている。 根拠は無いが、黒幕は IPA だと思っている。
僕は働き方を変えたいのだ。 エンジニアが本来能力を発揮すべき領域にリソースを割けるよう、退屈で機械的な単純労働はとことん自動化していくべきだと考えている。
しかし今までは、『指示されたことを指示された通りに遂行すればよい』という立場だったため、面倒が増えないよう、余計な提言を避けてきた。
だが、ついに先日「影響の輪」を広げる行動を自分で選ぶことができた。
先日、これから新しい案件を始めようとしている若手に、JUnitとEclEmmaの実演を行なってきました(-ωー,,)
— たーせる (@tercel_s) 2018年3月31日
というのはオトリで、若手に教えるふりをしつつ、その子の上司にも同席してもらいました。 真のターゲットはその子の上司です。
こうすると、上司のプライドを傷つけずに布教できるかなーと。
僕は、自分のちいさな影響力を、さらなる上の立場の人間に伝播させることができた。
小さな一歩かも知れないけど、昔の僕より間違いなく「影響の輪」が広がっているな……と感じた。
繰り返しになるけど、自分自身の行動は自由に選ぶことができるのだ。
（つづく）
Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.
