「松原ガレッジ」のブログ

大阪府松原市にあるウェブ開発・HP制作をするところ。管理人が思ったことや困ったこと、課題についてまとめていきます。

Rails6 で Authlogic を使ったリクエストテストがうまくいかないので調べた

どうも!
大阪府松原市でウェブを中心としたソフトウェア開発を行っています。
コワーキングスペース松原ガレッジ管理人の五島です。

いやーちょっと暑くなってきましたね!
そんなときに少し面白い現象にハマっちゃったので、メモです!

環境

・Rails6 (6.1.3.2)
・Authlogic6 (6.4.1)

現象

テストコードの内容は

①ログインしてないときにはアクセスできないこと
②ログインしているときはアクセスできること

のような単純なテスト しかし、①は成功するのに②が失敗する。

200が返ってくるはずなのに403が返ってくるので、Authlogicが原因かな〜と試行錯誤したのが間違いでした。

カンの良い方はお気づきだと思われますが、Rails6 ではドメインのチェック機能が追加されています。
実際に追加されているプルリクはこちら

したがって Authlogic を使ってログイン処理を行う際に、cookie が発行されます。
その情報を使って次のページにアクセスする際に Blocked host エラーが発生してしまったということです。

つまり対策は、テスト実行時に指定されてるドメインをホワイトリストに登録すること

config.hosts << 'www.example.com'

rspec を実行している際に、response.body を見て気づきました。
403 だからと言って、 Authlogic のせいにしてすみません!

今後も精進していきます!

【読書感想】システム設計の第一歩が踏み出せる本 [はじめよう! システム設計]

f:id:shuto0125:20210509230442j:plain

こんにちは！  コワーキングスペース松原ガレッジスタッフの櫂谷です！ 大阪府松原市でウェブを中心としたソフトウェア開発を行っています。

当事業で課題図書として「はじめよう! システム設計 ~要件定義のその後に」を、生産性保守性の高いプロダクトを作るための知見を得れるよう意識して読みました。

はじめよう! システム設計 ~要件定義のその後に

はじめよう! システム設計 ~要件定義のその後に

  • 作者:羽生 章洋
  • 発売日: 2018/01/25
  • メディア: 単行本（ソフトカバー）

本書の対象者

システム開発において必要な知識・スキルの3点セット(UI・機能・DB)が偏りがちで、得意でない領域は基本的なことであっても不安がある人。

概要

昨今のシステム開発では、デザイナー、プログラマーそれぞれが別の領域の業務を担当することが多いため、全員が知識共有ができる必要があります。

別の領域の基本的なことをお互いにあまり知らないために意思疎通ができない、ということを無くすべく、全員が横断的に知識を共有するできるようにするための本です。

要件定義という仕事

UI、機能、データ を要件としてまとめる為に下記を定めることを「要件定義」といいます。

  • このITシステムを作ることによってどんなふうになることを期待しているのか
  • このITシステムはどのようなものか
  • このITシステムは具体的にはどういう要素（UI、機能、データ）で構成されるのか

要件定義の成果物

クライアントと要件を挙げながら、合意する成果物を作成します。

  • 企画書
  • 全体図
  • ソフトウェアアーキテクチャ
  • シナリオ一覧
  • ビジネスシナリオ
  • アクションシナリオ
  • 操作シナリオ
  • ワークセット一覧
  • UIラフスケッチ
  • IFDAM図 （拡張画面遷移図）
  • 機能定義書
  • ERD ( Entity Relationship Diagram )

この成果物を元にシステム設計を行います。

まずはフロント層から

フロント層だけでユーザの期待に答えられるのであれば、他のバック層・DB層は必要ありません。フロント層だけでは力不足のときに後ろから支えてあげるのがバック層ということになります。

  • フロント層の役割とは「ユーザの期待に応えること」
  • バック層の役割とは「フロント層の期待に応えること」
  • DB層の役割は「バック層の期待に応えること」

フロントが果たすべき要件はユーザの期待、システムに対する要件から決まりますので、最初はフロント層から設計を行います。

UI設計の手順

  1. 項目をUI上に配置する
  2. UIの分割を検討する
  3. 分割に伴う遷移と画面間の機能について検討する
  4. 画面遷移の変更に伴う操作手順の再確認と操作性の検討を行う

上記の工程をループさせて試行錯誤し、下記に作業を行います。

  • ビジュアルデザインを施す(UIデザイナーとの協業)
  • 後工程のためにIFDAM図に修正をフィードバックする

このとき「ユーザはこのUIを使うことによって、何を達成したいのか」を忘れないということを意識すべきです。 UIの役目は「ユーザの期待にシステムが応える」ために「システムの代表としてユーザに向き合う」ことです。

行動別にUIを用意する

複数の機能を1つのUIに盛り込むと、ごちゃごちゃとしてしまい、ユーザが混乱します。 それぞれの行動別にUIを用意しましょう。誤解のしようが無い明快なUIを提供できます。

機能を設計する

「機能を設計する＝コンピュータの行う仕事を定める」＝「プロセス設計」

プロセス設計、仕事を設計する要点は、大きく分けて下記の2つです

  • ゴールから逆算して必要なことを考えること
  • 段階的に詳細化すること

この2つは言い換えると「モジュール化を行う」ということで、部品化するということです。

モジュールのインターフェースを定義し、加えてそのモジュールを小分けにして個別の部品にしていき、それを受け持つ担当の層を決めていきます。

「具体的な実現手段：実装」を小分けの対象として、「順接」「分岐」「反復」+「段階的詳細化」という手法でモジュール分割を進めていきます。

そしてこの機能のインターフェースを「機能名」「入力」「出力」の3つを決めて定義します。

バック層の存在意義

フロント層とDB層が直接やりとりすればいいのでは？という疑問もあります。

単なる社内業務の効率化だけであればそれで済みますが、「サービスがAPIで提供されている」ということによる「事業価値の最大化」が可能になります。

DB層設計の手順

  1. バック層がDB層に期待している機能を集める
  2. 機能ごとにモジュールのインターフェースを定義する
  3. モジュール内でひつようになるテーブルを設計する
  4. モジュールの実装を考える
  5. 全モジュールのテーブル設計を統合・調整する

共通化の罠

「大規模だから無駄なことを減らしたい」ので「共通化の推進」が行われますが、プロジェクト当初から期待通りのパフォーマンスは発揮されるケースは非常に稀で、逆にプロジェクト全体を停滞・低迷に導くこともあります。

「どんなアプリになるかハッキリしないと共通仕様が作れない」という状態と、「共通仕様がハッキリしないと手戻りが怖くてアプリ設計ができない」という状態がぶつかって、プロジェクトが止まってしまいます。

この罠に陥らない方法は、「共通化をやめる」ということで、材料が出揃うまでは共通化を後回しにすることです。 着実に成果が出る道を選びましょう。

インターフェース定義で、データ型の箇所は現在触れ始めている Typescript にも通じるものを感じて興味深かったです。

「共通化の罠」の chapter は実際に以前メンターからお聞きしていたトピックで、設計者と制作者の正義がぶつかってデッドロックになるという仕組みは納得でした。

体系的にシステム設計についての知識が盛り込まれており、中でもフロント・バック・DBの各層での具体的な設計方法などは再読して参考にしたい項目でした。

【読書感想】つよつよプログラマーになるための本 [情熱プログラマー]

こんにちは！ 大阪府松原市でウェブを中心としたソフトウェア開発を行っています。

コワーキングスペース松原ガレッジスタッフの櫂谷です！

前回記事の課題図書に続いて、「情熱プログラマー」という本を読みましたので共有します。

「この本はクビにならずに済む程度の並のスキルを維持しようとあがくためのものではない。素晴らしい存在になるためのものである。勝利するためのものである。」という著者の熱いメッセージと共に、具体的な行動、考え方が盛り込まれていました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

ニッチなテクノロジに注力してみよう

オフショアの市場はシェアの大きいテクノロジに参入し、そのテクノロジでは価格競争が起こります。我々が一人材として戦略シェアの大きいテクノロジに熟練するのは仕事獲得への近道になりますが、価格競争に巻き込まれることになります。 エンジニアの数が少ないニッチなテクノロジに注力して市場の不均衡をつくと、希少価値が生まれて人材としての価値が上がります。 技術のトレンドを見極めて、学習のリソースを振り分けましょう。

1番の下手くそでいよう

「どんなバンドで演るときも、一番下手なプレイヤーでいろ」とうのは、伝説のジャズギタリスト pat metheny が若いミュージシャンたちにアドバイスするときの決まり文句だそうです。 いつも自分より優れた人たちと一緒に演奏すると、周囲の人たちにつられて能力が向上します。 開発者も同様に周囲の仲間に影響され、優秀な言動、思考を真似るようになり、自分も優秀になることができます。 仕事仲間、環境は慎重に選びましょう！

すぐに職場や部署、雇用形態を変えるのが現実的ではない場合、「優秀な人が集まるボランティアに参加する」という代替案を提示してくれています。 普段の環境を客観的に見ることもできますし、良い体験になりそうですね。

万能選手になろう

「自分の目標が解雇やオフショアの嵐の中で最後まで生き残ることなら、自分自身の汎用性を高めた方がいい。」と著者は言っています。チーム規模がわずか数名になったときに単なるテスターや単なるコーダーは必要なくなります。卓越し注目に値する存在になりたいのであれば、大局を見ることが大切です。

サービスを俯瞰的に見て方向性を示すことができるエンジニアやデザイナーのような万能選手はめったにいないため、そこに価値があります。

複数の技術を組み合わせることにより、相乗効果で希少な人材となることができます。 プラットフォームの垣根を越えたスキルを身につけて、自身の市場価値を高めましょう。

スペシャリストになろう

一見、前記の内容と矛盾したことを述べているような題名です。 この「スペシャリスト」は、他に何も知らないこと、と言う意味では無いということです。 バックエンドエンジニアが他のことを知らないから「スペシャリスト」というわけではなく、携わる技術の奥深くまでしっているから「スペシャリスト」なのです。 使っている技術の深い知識も持ってスペシャリストになりましょう。

魚の釣り方を学ぶ

老子「魚そのものを頼めば、それは一日の糧となる。魚の釣り方をを教えてくれと誰かに頼めば、それは一生の糧となる」

教えてくれるのを待たず、自分から訊きにいきましょう。 雇う側は自立した人、自走できる人を雇いたいと思っています。

もっというと、教えてくれと頼むのではなく、自分で勉強し始めて、わからなくてつまづいたところを聞きましょう。

なぜ、どうして を考える

「その仕組みはどうなっているのか」「そうなるのはなぜか」 この二つで領域の深いところまで掘り下げていきます。こうした質問について考えると言う行為そのものが、新しい考えをもたらし、自分が働いている環境について高い意識を持つことにつながります。 前述されていた「スペシャリストになる」手段でもありますね。

師匠を探す 師匠になる

師匠に期待される最も重要な務めは、弟子の手本になること。手本がないともっと上を目指そうという動機も生まれません。また、限りない選択肢から、数個に絞ってくれるというのも師匠の良いところです。

そして本当の意味で何かを習得したいとおもったら、今度は自分が師匠となって誰かに教えてみること。自分の理解をはっきりとした形にする一番の良い方法は、自分の言葉を使って、他の人にもわかるように説明することです。

自動化によって仕事を確保する

ソフトウェア開発の生産性を測定できる方法はまだ存在しません。 開発期間の短縮を実現する為に、作業員を増やすアプローチ、作業員の作業スピードをあげるアプローチは効果の証明が困難です。 「残された道は自動化のみ」と著者はいいます。

自動化を試みることによりプログラミングの技術や手数が増えて、能力向上も狙えますね。 著者は「自分がいつもコーディングしている処理を自動化する、コードジェネレータを作ってみる」という例をあげています。

デイリーヒット

真面目に勉強してれば仕事ができて業績をあげられるわけではありません。 良い方法としては実行予定を立ててそれを追跡調査しましょう。マネージャの期待以上の働きをしたのはいつか、どの作業なのか注目しましょう。

・報告できる成果を毎日あげる

自分にとっての適切な単位で目標を設定し、その達成状況を追跡調査するだけで、自分の行動を大きく変えることができます。 自分の行動をビジネスにおける価値に基づいて評価し、優先順位をつけられるようになります。

失敗する方法を学ぶ

我々はみんなミスを犯します。道理を弁えた人なら、犯したミスで他人を判断しません。どうしたって発生するミスにどう対処するかでお互いを判断します。

・間違いに気づいたら、そのことを直ちに問題として取り上げる。たとえ短い間でも間違いを隠そうとしてはいけない。

・責任を負う。責任の問題はできるだけ早く片付けて次の段階に進むべきだ。

・解決策を提示する。その時点で解決策がなければ、解決策を見出すための方策を計画して提案する。

・助力を求める。自尊心を脇に置いて常識ある態度をとる。

できないことはできないとはっきり言う

相手を失望させないための「できます」は、単なる嘘になります。 もちろん、なんでも「できません」は問題がありますが、正直な応答は信頼につながります。 正直である勇気を持ちましょう。

言って、成して、示す

自分でやる計画を立てて、実行し、結果を記しましょう。 まずは一日単位でリストにし、作業が完了したら「完了」と記入し、実際に声に出してみます。 遅れても、次の日にタスクを移動させます。

最初は週単位の報告から始めて、30~90日の行動計画についてマネージャに報告してみましょう。

計画を作成して有言実行していくと、気概と自立心を獲得することに役立ちます。

また計画報告は、自分自身を売り込むことにも役立ちます。 自分自身を売り込むための目標は、２つ。 みんなに自分の存在を知ってもらうということ。 持て余している難題を解決できる人物だとわかってもらうということ。

業界で名前を売ろう

企業がデプロイしようとしているテクノロジや方法論の本を書いた人物を雇わない手はありません。

平凡なプログラマが本の著者になったり後援者になったりするのは難しいので、Webからスタートしましょう。

まずブログを読む。
↓
アグリゲータを作って目を通し、面白いと思った話について自分のブログで書き込んでみる。文章力を鍛えると自信もつく。
↓
自分の意見が関心を持つ人たちに引用され広まっていく。
↓
コミュニティのWebサイトや雑誌に寄稿した文章がサンプルになり、出版社への売り込みに役立つ。
↓
ネットワークがさらに拡大して書く機会が増える。
↓
やがてカンファレンスでの講演のチャンス！

時期尚早かなと思うくらいでスタートをすること。

まずは、、 ブログにかけそうなトピックのリストを10項目ほど書き出します。 10分か20分くらいで書けそうな話題にすること。

毎日リストから項目を1つ選んで記事を書します。あまり考え込まないこと。とにかく書いて公開します。 これを3週間連続で続けてみましょう。

目立つこと

目立つためには、周囲の人たちとの間に大きな差異がなければなりません。OSSをリリースし、本や記事を書き、会議で講演することが注目度を高めるのに役立ちます。

何かであるだけでは不十分、何かをしなくちゃいけない。

小さなことからでもいいので、今の仕事で何か目立つことをやってみましょう。目立つほどの生産性を目指してみましょう。1週間かかると思われた作業を1日で終わらせてみるなど。注目されたかどうかの効果、検証もやってみましょう。

自分のロードマップを作る

多様なスキルを学ぶことは間違いなく良いことですが、まとまりなく組み合わせただけでは人事担当者を混乱させるだけです。 これから進むロードマップを作ることによって自分の進み具合を確認するのに役立ちます。

どの項目も意識が高く実行していくのはハードルが高い内容もありますが、少しずつこなして偉大なクリエイターを目指します！

【読書感想】Team Geek ―Googleのギークたちはいかにしてチームを作るのか

f:id:shuto0125:20210420191300j:plain

こんにちは！ 大阪府松原市でウェブを中心としたソフトウェア開発を行っています。

コワーキングスペース松原ガレッジスタッフの櫂谷です！

先日、当事業で課題図書として指定されている TeamGeek という本を読みました。

ソフトウェア開発の本だけど全くプログラムの事が書いてない本で、ITの仕事をしていない人にも通じるエッセンスがたくさんありましたので一部共有できればと思います。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

本書のミッションステートメントは

「プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。」

ソフトウェア開発ではプログラミングやデザインなどの技術力が必要不可欠なことは言うまでもないけれど、本書は技術書ではなく、チームでソフトウェア開発をする時の人との接し方の心得・アンチパターンの数々が纏められている本。

プロダクトに関わる人たちといかに潤滑にコミュニケーションを取るかで、成果物のクオリティ、ローンチのスピードが向上するでしょうし、何よりいい気分で仕事ができますよね。

HRTの精神

本書の象徴的なテーマが「HRT」、下記の３本柱。

謙虚（Humility）

尊敬（Respect）

信頼（Trust）

著者は「あらゆる人間関係の衝突はHRTの欠如によるもの」と述べています。ソフトウェア開発だけでなく、すべての人の生活にとって重要な３要素。HRTが欠如すれば自分のエゴが強くなり、周囲の人を圧迫したり、プロダクトを私物化して客観的な行動ができなくなります。

自分のエゴを押し付けるのではなく、HRTの元に「いいプロダクトにしたい」というチーム全体のエゴを優先しましょう。

隠したらダメになる

隠してしまうと失敗のリスクが増えるし、成長の速度が遅くなります。

自分のコードに自信がなくて公開しなかったり、アイデアを温め続けて人に伝えなかったりするのはとてもよくわかります。

だけど、早い段階でアイデア、プログラムを共有してアドバイスをもらった方がいい結果を得られます。 その方が早く解決策を知れるし、もしかしたら手伝ってくれるかもしれません！

積極的に共有して、成果物を磨いていきましょう。

早い段階で失敗・学習・反復する

Google社員の著者は下記の様に述べています。

なんとなく使えるようになったら、生煮えでもリリースして公開する。成功や失敗がすぐにわかるので、プログラミングチームは学習・反復が可能になり、できるだけ早い段階で新しいバージョンをリリースできるようになる。

不具合が出て対応に追われるかもしれませんが、そのリスクを取れば早期でブラッシュアップができます。 リスクを取って攻めていきましょう！

チームに変化を引き起こす

不可能な目標を達成しようとすると失敗する可能性が高くなるけれど、簡単なことをするよりも挑戦する方が成長します。

でも人も会社もリスクに恐怖し、排除する事に必要以上のコストをかけてしまうというのはよくある事。

チームがリスクをとって挑戦しやすくする為に、安心感を与える働きかけをしましょう。

あなたがマネージャーの場合なら具体的には、失敗してもいい（同じ失敗を繰り返さないかぎり！）ということをチームに知らせます。

個人の成功はチームの前で称え、個人の失敗はプライベートで建設的に批判しましょう。

チャレンジングな文化がチームにできるし、スタッフが技術習得に前向きになりそうな、いい働きかけですね。

ユーザーに集中すれば、他のことはすべてついてくる。

Googleの大きなブレイクスルーの一つは、検索広告の効果測定を始めたことだと記されています。

広告主（クライアント）ではなく、検索者（ユーザー）に注目し、仕様をユーザーにとって心地よい物にすることによって、プロダクトの有効性が劇的に高まります。 ユーザーにとって気に入らない広告はボタンで任意に消す事ができる仕様を追加しました。クライアントの身になって考えると広告を非表示にするなんて持っての他だと思いますが、この仕様によってよりユーザーに望ましい広告が届くようになりました。

  • 想定するユーザー層のリテラシー、技術力などの属性を想定してプロダクトの仕様を決める。
  • プロダクトは第一印象が超重要！人も一緒で、第一印象は記憶に残る。とっつきやすい操作感やUIデザイン等、ユーザーフレンドリーな工夫をしたい。

速度は機能

GoogleMapで特に公表もせずに大幅な速度改善が行われた数日後に、利用のアクティビティグラフが大幅に継続的に向上しました。

Googleの創業者たちも「速度は機能である」と述べています。

速度改善は派手さに欠ける印象がありますが、「速度は機能」のセリフを持って向き合っていきましょう！もちろん実施する場合はアナリティクスなどで効果を測定して評価していきたいですね。

他にも、本書には「有害な人を対処する」や「組織的操作」という社内政治的な章もあってバリエーションが多く面白かったです。

HRTが根付いた、お互いを尊重しあえるチームだったら長く一緒に働きたいと思うし、より貢献したいし、仲間に加わりたいと思いますよね。 逆にHRTを欠いたリーダー、メンバーがいるチームからは一刻も早く逃れたいです！！

ソフトウェア開発はいい状況ばかりではないけれど、HRTを実践できれば素敵な人生を送れそうですね！

後からDBにUniqueインデックスをつけるときの前処理のお話〜ダブリのある要素をどうやって見つけるか〜

プログラミング

どうも!
大阪府松原市でウェブを中心としたソフトウェア開発を行っています。
コワーキングスペース松原ガレッジ管理人の五島です。

今日はすでに運用しているサービスのDBのお話。
特定のカラムに対して、ユニーク制約をつける前処理の話を少ししようかな〜と軽快に記事を書いてます!

目次はこちら

ユニークを妨げる要素は存在するか

すでに重複してるデータがある場合、それをまず取り除かないといけないわけです。
pluckを利用して要素をごっそり取ってきた後、配列の処理を行います。

Rubyには配列演算があるので

ary1 = [1, 2, 3, 3]
ary2 = ary1.uniq #=> [1, 2, 3]

ary1 - ary2 #=> OutPutは何?

こんな感じのフローで、重複が存在するIDが探せるのではと思いました。
結果...

[]

まさかの空日!!
そうか...複数入ってる要素も全部取り除いてしまうのか...

パッと思いつく方法だと

ary = [1, 2, 3, 3]
ary.select{|a| ary.count(a) > 1}.uniq

これで重複する値だけ出力できます。
しかし、データ量が多いと計算量が多くなかなか終わりません。オーダーはn2という感じでしょうか。

ここでRubyの便利な関数の登場です。
group_byを使って、値をグルーピング=>2つ以上要素があるものだけ抜き出すという方法を使います。

ary = [1, 2, 3, 3]
ary.group_by{ |e| e }.map { |k, v| v.size > 1 ? k : nil }.compact

これだとざっくりオーダーは2〜3n => nという感じですね!
group_byの方法は、複合ユニークindexを作成する際に二次元配列の形

ary = [[1, 2], [1, 3], [1, 2]]  
ary.group_by{ |e| e }.map { |k, v| v.size > 1 ? k : nil }.compact

#=> [[1,2]]

このような形式でも出力を得られたので、様々なシチュエーションで利用できそうですね

まとめ

というわけで

ary.group_by{ |e| e }.map { |k, v| v.size > 1 ? k : nil }.compact

を使ってみてください