入社から約4年、Money ForwardのAndroidアプリエンジニアとしての活動を振り返る - Money Forward Developers Blog
こんにちは。Androidアプリエンジニアのsyarihuです。 私が入社したのは2017年10月で、入社してから約4年が経過しました。マネーフォワード MEのAndroidアプリエンジニアとして、そしてスマートデバイス推進グループとしてさまざまな活動をしてきました。約4年の区切りということで、これまでの活動を時系列で振り返りたいと思います。 syarihuの簡単な自己紹介 マネーフォワードには2017年10月に入社しました。 会社としては2社目で新卒2年半ほどからの転職だったのと、前職は主にサーバーサイドJavaエンジニアとして働きつつ、そこまで実装タスクは多くなかったもののAndroidアプリエンジニアとしても働いていました。そのため実務での経験は浅くAndroidアプリエンジニア界隈での知名度もそこまで無い時期でした。 そんな僕を、自身がプレミアムユーザーとしても利用する「マネーフォ
マネーフォワード vs freee、もし名古屋で開発するなら？ - freee Developers Hub
こんにちは、DevBrandingのellyです。11月19日に配信した「マネーフォワード vs freee、もし名古屋で開発するなら？」の様子をご紹介します。 これから名古屋に開発拠点を立ち上げるマネーフォワードと 2020年に拠点を構えたfreee。 なぜ名古屋に開発拠点が必要なのか、作っているプロダクト、本社との関わり方、 両社のエンジニア組織の違い等を対比しながら1時間たっぷり赤裸々に語ってもらいました。 とても爽やかな両社の自慢対決となりました 長島圭祐 (Kei) さん: マネーフォワード 名古屋開発拠点 拠点長兼サーバーサイドエンジニア。 福岡でマネーフォワードクラウド債務支払の開発を担当しつつ、名古屋に新設される開発拠点の立ち上げを進めている。最近はサーバーサイドKotlinに夢中。 moai: freee 中部開発組織長。中部開発組織を2020/7に立ち上げた。地域技術イ
ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
RailsのControllerにApplicationService相当のロジックを書くのはありなしや？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。 Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019 これについてです。 結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。 なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplication
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
自分のプロジェクト管理に関する考えのまとめ - アジャイルSEの憂鬱
ここ最近は色々とあってプロジェクト管理、スクラム開発について勉強していたので、それを整理するためにまとめた。 スクラムガイド スクラム現場ガイド SCRUM BOOT CAMP THE BOOK スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Regional Scrum Gatheringの2018, 2019の全スライド ryuzee.com の2017, 2018のスクラムに関する記事 あたりを読んで勉強したので、スクラムに関する理解はそれなりになっているはず。 ただ、評価や役割に関するところは自分の好みで少し脚色があるので、これが「スクラム開発なのか！」みたいに勘違いしないように注意。 ソフトウェア開発の前提（スクラムはあまり関係ない） 「なぜソフトウェア開発をするのか？」という前提の話を最初に書いておく。 多くの企業の目的は
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog
SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。
スタートアップでのプロダクト開発はRailsで必要十分
僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 本格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドはReact+Redux
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
なぜいま Heroku なのか - Qiita
開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
ソフトウェア開発技術者が知っておくべき５つの法則 - スタジオ・アルカナ技術ブログ
はいどうも～。 本日はhidetarouの番ですが休業中のため代打でしゃしゃり出たエンジニア吉田です。 「○○○な●●つの○○○」なんて感じのタイトルを付けると、 なんだか興味が惹かれるというのを目にしたので活用してみました。 ※個人的にはそうでもない気がしている。 というわけで、今回はソフトウェアに関係しそうな「法則」を５つほど紹介し、 それをソフトウェア開発業務にどう生かしていくかを考えてみます。 本日ご紹介する法則は以下の5つです。 ブルックスの法則コンウェイの法則パーキンソンの法則マーフィーの法則ハインリッヒの法則 でわでわ、早速。 ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 これは、IBMのOS/360（メインフレームOS）の開発者であるフレデリック・ブルックスが 名著「人月の神話」で提唱したプロジェクトマネジメントに関する法則です
社内障害情報共有のススメ - Hatena Developer Blog
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために
開発チームを苦しめるマイクロサービス（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Microservices Will Mess Your Team Up 原文公開日: 2018/01/10 著者: James Thompson 「なぜAmazonはマイクロサービスに舵を切ったのか？」も参考にどうぞ。企業のトップが経営判断としてマイクロサービスを強力に推進したことが重要であると思えます。 マイクロサービスは多くのチームで人気を博しています。しかし、ソフトウェア開発のパターンは、このアーキテクチャパターンの周辺で今も流動を繰り返しています。このギャップはここ数年で相当埋められてきましたが、それでも質の低い実装を生産するチームがあまりにも多すぎます。 マイクロサービスは、しばしばモノリシック（一枚板）アプリの対極に位置づけられます。この対比は有用な反面、素朴に過ぎるとも言えます。マイクロサービスというソフトウェア設
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CI/CDを使い倒して数段上のソフトウェア開発をしよう!
esa.ioの育て方
Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち
