この記事は suusan2go Advent Calendar 2019 - Adventar の7日目の記事です。 少し前に、自分が新卒で入った会社の同期の友人から転職相談を受けて、自分がいたときとは会社の状況とか従業員としての状況とか色々結構変わったんだなと思ったので書いておく。 大きくわけると２つ変わったことがあった。 時代の流れもあって会社自体が当時から変わったこと 30代になって当時から変わっていること 自分は新卒で入った会社に3年くらいいて20代後半でベンチャーに行ったんだけれども、正直一時期は「大企業よりもベンチャーの方が潰しの効く経験詰めるしいい」「給与もエンジニアなら悪くない」「働きやすさもベンチャー企業の方が上」みたいなことを思っていた。しかし友人と話してみると、自分の持っていたイメージは大分古いのかもなと感じた。 大企業ってどこよ 所謂大手のSIer、メーカーで従業員

会社のブログに書こうと思ったんだけど、ちょっとマイナスイメージを持つ人もいそうな気がしたので、個人ブログに書くことにした。 この3ヶ月くらい、システムのリニューアル(アプリ間で分散したロジックを集約するバックエンドサーバと、用途に応じたフロントエンドサーバを立てるみたいなマイクロサービス構成)をやっていて、そこでサーバ間のやりとりにgRPCを使っていた。すごーく雑な絵を書くとこんな感じです。 しかし、最近になってプロジェクトのスコープについて見直しが入りました。マイクロサービス化ではなく単純にレガシーJavaで独自FWなアプリをリプレースするだけになり、必要なのはSPAとSpringBootのAPIサーバだけに(要するにRails側のロジックをなんとかするのがスコープ外になった)。 で、SPAに提供するAPIのためにgRPC(+ grpc-gateway)を使うのはちょっとオーバースペック

最近、機能の設計をレビューしたり話し合ったりするときに、うん・・・？ってなることがあって、でも駄目な理由をうまく説明できなかったのでちゃんと言語化してみる。ちなみにRailsの話です。 DBには事実だけを記録するようにする 色々開発してきて思ったのは、テーブルに状態を持たせるようにするとあっという間に複雑度が増してしまうということ。 status カラムや hoge_flag みたいなカラムを持つこと自体は全然否定しないけど、本当にそれが最適なのかは慎重に考えた方がよいと思う。 これは例ですけど、会員申し込み => 何か審査 => 会員登録完了 みたいなフローのアプリケーションを作る時に、会員情報のテーブルを１つだけ作りstatus 、approved_at みたいなカラムを突っ込んで、申し込み状態と申込み完了状態を アプリ側で頑張って判定しようとしている例はまれによくある。 こうすると何

SIerから自社Webサービスをやってる会社に転職して半年たったのでまとめる。本当は試用期間が終わったころに書こうと思っていたのに、すっかり忘れてました。。。 SIerでは仮想化のインフラエンジニアっぽいことしてました。いまはRubyの会社でRails触ったりReact触ったりしています。 以下は、これをやっておくと転職のときに有利…とかいうものではなく、転職後になってやっておいてよかったなと思ったことですので注意。 やっておいてよかったなと思ったこと Gitの使い方を覚えておく Gitは普通に使いますし、Gitが全く使えないと開発に参加するところから大変です。 当然、仮想化のインフラエンジニアなんてやってたのでGitなんて全然仕事では触ってませんでしたが、趣味の自分一人の開発でも更新はGitHubでプルリクエストを送りセルフマージする感じにして慣れるようにしてました。 以下の本では、なん

前のブログ書いてから2ヶ月くらい立っていた… この2ヶ月なにしてたかというと、転職活動しつつ知人のWEBサイトをRailsで作ったりしてました。自分の備忘録も兼ねてまとめておきます。 何を作ったか イラストレータをやっている知人のポートフォリオサイトを作らせてもらいました。 これまでも作った作品や関わった仕事をまとめたサイトを自分で作っていた方なんですが、一々HTMLを編集してファイル上げたりするのが面倒とのことで、ブログを編集するような間隔でサイトを更新できるよう、Rails + Herokuで一からCMS(であってるかな？)的なものを作ってみました。 ぶっちゃけ簡単にサイトを作れるサービスって普通にあるわけですが、一から作らせて貰ったのはもう完全に自分のスキルアップのためです・・・ 私について Ruby歴=Rails歴=半年くらい 普段はSIerで仮想化のインフラSEやっててます。会社

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子出版社/メーカー: 英治出版発売日: 2014/05/24メディア: 単行本この商品を含むブログ (3件) を見る 一ヶ月くらい前にnaoya_ito さんの記事を急に思い出して読んでみたらとても良い事が書いてあった。この本は、資料の参考文献で強くおすすめされていたので買って読んでみた。 まとめ プロセス知識スペクトル この本で繰り返し言われているのは、仕事の中にも「知識の成熟度」と「不確実性」に応じてルーチンの業務、複雑な業務、イノベーションの業務 があり(本の中ではプロセス知識スペクトルと言われる)、それにより適切なチーミングと学習のあり方を変える必要があるということだった。新規事業のような不確実性の高い仕事と、書類仕事のよ

ソフトウェアエンジニアとして求職中です。以下のブログの時点ではあまり自分の中で次にやりたい方向性がハッキリしていなかったので控えめに求職情報を載せていたのですが、有り難いことに色々とお誘いを頂いてお話するなかで少し方向性が見えてきました。自分の考えを事前にアウトプットしておくと実際にお会いするときにコンテキストを共有できて便利だったので改めて書きます。 suzan2go.hatenablog.com 私について 自分のプロフィールとかアウトプットは以下が一番まとまっていそうです。 lapras.com 自分が現時点でできること、できないことは以下にまとまっています suzan2go.hatenablog.com いまはフリーランスとして働いていますが、3月か4月くらいからフルタイムで働ける会社を探しています。 次の会社に求めること アーキテクチャを考える / チームの生産性をどうあげるかみ

「参照系はGraphQLだけど、更新系はRESTでPOSTにします」みたいな意見を稀によく見る。 もちろん何かしらのトレードオフを考えてRESTを選択しているのだとは思うのだけど、GraphQLのmutation(要は更新系)を誤解している人も中にはいるのではなかろうか。 先日GraphQLのmutationは難しそう……という意見をもらって、詳しく聞いてみるとmutationについて誤解があるようだった。 もしかしたら同じような勘違いをされている方は他にもいるかもしれないなーと思ったのでまとめておく。 あーそれは多分誤解があるような気がしますね！mutationの方は投げるクエリを変えることで、動的に更新対象を変化させる……みたいなことは志向していないと思います。 ここの例のsetMessageをみてもらうと分かりやすいかと！https://t.co/Jq08v5n4x6— すーさん二号

この記事はex-crowdworks Advent Calendar 2018の17日目の記事です。 クラウドワークス辞めて大体一年くらいたちました。辞めるときに会社のブログに退職エントリーを書いたのですが、まあ当然当たり障りのないことしか書いてないし、一年経ったからこそ冷静に見える点も色々あろうということで何か書きます。 注意として、自分がいたのは2017年10月までですので、当然情報も当時のものとなります。今とは異なる部分もあると思いますので、鵜呑みにしないで全部妄想だと思っておいてください。 なぜ辞めたのか 昨日終了してしまったこのサービスの立ち上げからリリース後の諸々が本当に大変で若干燃え尽き症候群になっていて、技術面、環境面で今と違うことをやりたくなったというのが理由の一つ。これはやんわりと会社のブログにも書きました。もう少し具体的に書くと以下です。 Rails + JSでずっと

TL;DR 2019年2月にエムスリーを退職してフリーランスになっていました。 お仕事の相談お待ちしています。 何で今更書くの www.m3tech.blog 2月に前職のRailsアップグレード記事と見せかけた退職エントリを書いていたのだけど、ちゃんと書いてなかったので改めて書きます。 辞める月に某異常にTwitterでフォロワーの多い機械学習エンジニアの方が入社して隣の席にいたので、「俺もnoteで退職エントリ書いて有料にして売りますよｗｗｗ」とかイキってましたが機を逸したのでやめます。 エムスリーでは何をやってたの レガシーシステムのリニューアルを中心にKotlin / Nuxt.jsとかやっていて、その後はAI機械学習チームというところで、新規事業の機械学習部分以外のアプリ / インフラをやったり、次の機械学習基盤の調査のためにGKE使ったCI / CDのPOCを作ったりしていまし