GitHub purintai
Comment5
Like
Created atMarch 24, 2018 13:13
Updated atMarch 24, 2018 13:13

Questions and feedbacks (5)

purintai
purintai commented 4 months

はてなの人はプログラミング言語とかフレームワークを選り好みせずになんでもどんどん触ってみるイメージがあったので Rails 導入に際して「待った」がかかったのが意外でした。主な反対理由はどんな内容でしたか?

Like(0)

purintai
purintai commented over 1 year

自社サービスのベンチャーにおいて特定のエンジニアがバス因子になってしまうのはよく起こりがちだと思います。

もし、エンジニアに依存する他チームがなかなか自立してくれない、しかしそのチームがワークしないことには事業として危ぶまれるといった場合にはどのようなアプローチを取ることが望ましいと思いますか?

Like(0)

purintai
purintai commented over 1 year

MobaSiF と Rails で共通で処理できないと困る部分(例えばユーザなど)は共通化するメリットあるかと思いますが、そうでない箇所については思い切って Rails に挙動を揃えてしまう ( MobaSiF を Rails に合わせる ) という手段もあったかと思います。

MobaSiF からの移行作業が完了したとしても、 Rails に残ってしまった辛い移行対応コードを解決する作業が残ると思いますが、実際にはどのような移行プロセスになっているのかを教えて頂けるとうれしいです。 (例えば Rails を MobaSiF に寄せる -> nginx で Rails にリクエストを振るようにする -> 問題が無ければ MobaSiF 対応を Rails からパージする、など)

Like(3)

purintai
purintai commented over 1 year

選考フローにおいて、応募者に10時間以上かかるような課題を課す形式では応募者に対する負担がかかるかと思います。

1社だけの自己応募などあれば問題ありませんが、エージェント経由等で並行して選考を受けている場合、多くの会社がこの手法を採用しだすと応募者は複数の会社の課題を並行してこなすことになり、日常の業務を行いながらの転職活動が非常に厳しいものになるかと思います。

実際に10時間以上かかるような課題を出す形式を通して、良かったと思うこと(課題を通して実力を測れた)や悪かったと思うこと(課題を出した時点で選考を辞退された・見たかった観点を判断できなかった)はありましたか?

Like(7)

purintai
purintai commented over 1 year

以前の職場における話なのですが、新規に Rails + PostgreSQL のプロジェクトを立ち上げる際にDB設計に協力頂いた DBA からトリガーやマテリアルビューの使用を推奨されたとき、 Rails と DB に業務ロジックが分散してしまい将来のメンテナンス性が低下するリスクを懸念して結果不採用としました。(ロジックは Rails 側に寄せました)

仮に、 Rails プロジェクトでこれらデータベースの機能と付き合っていく場合、保守性を考慮した最適なベストプラクティスとはどのようなものがあるでしょうか。

Like(3)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano