Eight事業部 エンジニアの坂田です。
私は、今年の4月に新卒として入社しました。学生時代はアルバイトでJavaを書いたりしていましたが、Eightで扱っているRailsについてはほとんど扱ったことがなく、未経験でした。
今回はそんな私が「Eightに配属されて最初のタスク」についてどのように向き合い、解決させていったのかについて書いていこうと思います。
続きを読むEight事業部 エンジニアの坂田です。
私は、今年の4月に新卒として入社しました。学生時代はアルバイトでJavaを書いたりしていましたが、Eightで扱っているRailsについてはほとんど扱ったことがなく、未経験でした。
今回はそんな私が「Eightに配属されて最初のタスク」についてどのように向き合い、解決させていったのかについて書いていこうと思います。
続きを読むSansan事業部 プロダクト開発部の宮崎です。
今年4月、我がプロダクト開発部にも3名の新卒社員が入社しました。 そしてそのうち1名が我が顧客データHubチームにJoinしてくれました。 そんなわけで(どんなわけ?)私がメンターになることになりました。
メンターになったからにはお勉強のネタを考えなくてはならないのですがここで悩みが…何にしようかな…
エンジニアとして仕事をしていくうえで学んでほしいと思うものはたくさんあるものの、全部は無理なのである程度取捨選択していかねばなりません。
が、いざ何を?となるとなかなか選ぶのが難しいもので。
正直、技術的なものはランチ勉強会で盛んにいろいろなものが行われていますし業務の中で調べて実践していく中である程度賄えるかなと思ったので、そうじゃないものにしようかと思いました。
エンジニアとして切っても切れないもの、それがプロジェクトです。
複数のメンバーが(たとえ1人でも)チームを組んで、ある目的(リニューアル/新機能追加)の達成のために日々を過ごしていきます。 メンバーとして参画すると初めのうちは細かいタスクを割り振られることが多いため、プロジェクト全体を見て何かを考える機会がどうしても少なくなります。 とはいえ、知らなくていいのか? というとそれもまた違うわけでして。
本を読んで…とかも考えたものの、私が眠くなりそうだったより実践的なものがいいかなと思い探しているとこんなものが見つかりました。
プロジェクトテーマパーク
続きを読むはじめまして。 Sansan iOS アプリエンジニアの中川です。
私は 2014 年新卒として Join し、4 年間はサーバーサイドエンジニアでしたが、直近のスマホアプリ利用率の増加や新コンセプトを体現するためのプロダクトリニューアルでモバイルエンジニアの需要が高まったため、転向しました。
iOS アプリを開発するのは就職活動のために萌えキャラクター育成ゲームを作った以来なので、 6 年ぶりでした。余談ですが、Sansan での面接時にこのゲームのコンセプトを取締役の一人に熱弁していたのを思い出しました。今、思い返すと黒歴史でしかないですね…
今回の記事では、こんな自分が Sansan iOS アプリ開発の現場に飛び込んで、感じたこと、やってきたことをご紹介しようと思います。
Sansan の iOS アプリは 2014/01/08 にバージョン 1.0.0 がリリースされ、今日まで運用保守されてきた 6 年目を迎えるアプリです。プロダクトの成長に伴い、アプリに関わるチームの体制やそのメンバーも千変万化していました。
そんな状況なので、コードベースもその時々で関わっていたメンバーが思い思いの設計やコーディングをしており、とある箇所は Cocoa MVC だったり、また別の箇所では RxSwift を利用した MVVM だったり、責務の分離が画面によって違っていたりと同じアプリなのに設計が統一されておらず、私のような新規メンバーがキャッチアップするには大変難度が高い状態になっていました。また、コーディングのフォーマットも場所によってまちまちでいざコードを書く際にどれを指針にして書いたら良いのか分からず、直近で変更されたコードのフォーマットを参考にして、頑張って書いてました。
このままではプロダクトやチームの成長にコードベースがついていけなくなり、いつかは破綻してしまい、リライトする必要が出てきます。これはエンジニアとしては負債を一括で返せるので嬉しいですが、会社やプロダクトを利用するエンドユーザーにとっては長期間、新機能の提供や既存機能の改善が止まることになるので、利用率の低下につながります。ここで踏みとどまってもらえれば、良いですが、解約になってしまえば、会社としての損失になります。
そのため、運用保守しているアプリはリライトではなく、日々の開発の中での継続的なリファクタが大事になります。*1この継続的なリファクタを自然とメンバーが行えるような仕組みづくりに、今回取り組んでみました。
前置きが長くなりましたが、現在、 Sansan で行っている事例を 2 つご紹介します。各ツールの導入方法については割愛し、どのように運用しているのかに焦点を置きます。
*1:リライトやリファクタについての説明は下記の記事がわかりやすくまとまっているので、知らなかった方は読んでみると理解が深まります。
Sansan事業部 プロダクト開発部の水野です。
最近カワウソとクアッカワラビーの画像を見て癒されてます。
今年の4月に入社しました。現在入社して2か月です。
入社前の2018年8月に、二週間Sansanでインターンをしました。
今回はそのインターンで変わった自分のエンジニアとして考え方やコードとの向き合い方について話します。
どうも、改めましてプロダクト開発部の自称社内関数型担当の福田です。社内でのHaskellの本を読む勉強会を運営しています。
前回は状態を扱う関数を状態計算と定義し、小さな状態計算を連鎖できるような構造を持たせるための定義を行いました。「これで安心安全に状態計算が行える!」と喜び勇んで数多の状態計算を実装しまくるところですが、今回は少し目線を変えた定義を行うことで一風変わった状態計算の表現になる逆状態モナドを紹介します。 前回に比べてHaskellの文法要素も増えるので遅延評価に倣って逆状態モナドが必要になったときに以下を読むことをお勧めします*1。
*1:必要になることがなければHaskellの学習コストも払う必要はありませんのでご安心ください
© Sansan, Inc.