背景 お題 技術の差別化 差別化から分かること 情報資産からToBeを考える 俯瞰的・相対的な技術選定 これまでの話から学んだこと 最後に はじめまして、MonotaROでデータエンジニアをやっています、芝本です。 エンジニアのみなさん、技術を使って何か作ってみるのって楽しいですよね。 私は、公私ともに日々物作りに励んでいます。プライベートだと、最近はマイクロフロントエンドについて学んでいます。 技術を使うためには、技術を学ばなければいけません。 プライベートにおいては、好奇心に従って自由に学びますよね。 とりあえずgit cloneして動かしてみたり、書籍を購入して読んでみたりします。 というようにプライベートでは主に次のような選択肢があると思います。 書籍を読んで好きなものを選ぶ 実際に手を動かしてみて好きなものを選ぶ 人に教えてもらって好きなものを選ぶ 基本的にプライベートの場合は何

計測方法は、(10**6).times{ }のような最小限のコードです。 実際、制限時間が2秒だとして、10の7乗台前後から、想定解法でも厳しくなってくる印象です。 それ以前の1,000,000回(10の6乗)で2秒超えてTLEするなら、自分の書いたアルゴリズムを疑いましょう。 今のC++は10の7乗だと「余裕をもって間に合う」レベルらしいので、C++と比べるとRubyは10倍遅い感じです。 競技プログラミングでは、問題に与えられた要素数も 方針・アルゴリズムを考えるヒントになるので、このあたりの感覚はもっておくとよさそうです。 高速化手法のまとめ・見方 先に高速化のまとめがあった方が親切かと思い、簡単にまとめておきます。 (まとめの方にしか書いてないのもあります……) 本記事は、アルゴリズムの話も少し混じっていますが、アルゴリズムはRubyに限らないので、ほぼ触れてません。 「アルゴリズ

こんにちは。プロダクト開発部の渥美 id:atsumim です。 今回サービス横断で利用できるログインコンポーネントを WebComponents で実装したのでその紹介をします。 1. 背景 今年の2月に電話番号での会員登録及び認証機能をリリースしました。 これに伴って一休の会員基盤も刷新しました。 一休のサービスは主に、宿泊、レストラン、スパとあるのですが、 歴史的経緯により会員基盤が分散してしまっていたので、ひとつにまとめる狙いもありました。 会員基盤 Before/After その一環として、一休のサービスで横断して使えるログインコンポーネントを WebComponents で実装しました。 このコンポーネントにログインや会員登録の処理を集約し、新会員基盤へのインターフェースとするようにしました。 また、電話番号認証や2段階認証設定のモーダルも実装しました。下記が実際の画面です。

開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？　というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ

こんにちは。LIFULLのプロダクトエンジニアリング部の野澤です。エンジニアリングマネージャーをやっています。 LIFULLでは組織構造として部の下に「ユニット」があり、その下に「グループ」がぶら下がっています。 今期からは私はユニット長を拝命し、間接マネジメントを行うようになりました。 マネジメント業務の中でも1on1は部下のモチベーション維持やキャリア形成、戦略理解を促進させるために重要な手法です。 グループ長時代も1on1はやっておりましたが、間接マネジメントをやるにあたり、メンバーからは相談がしにくくなってしまったようで、「特に話したいことはありません」となってしまうことが増えていきました。 そこで改めて1on1を有意義にするためにはどうしたらいいか考えてみました。この記事ではそのための取り組みを紹介できればと思います。 LIFULLでの1on1 1on1は今やいろんな業界や会社で

こんにちは、フルタイムRubyコミッタの遠藤です。 Ruby 3.0が出てもう4ヶ月経ってしまいました。最近のTypeProfの開発ですが、vscode拡張として使えるようにするために、一生懸命Language Server Protocolをいじって遊んでるところです。 今日の成果です。 RBS が .rb と別ファイルなのが面倒という問題、vscode 拡張をちゃんと作れば解決できそう（まだ実現可能性を調べただけで中身はありません）。 pic.twitter.com/tv6xB0Tm59— Yusuke Endoh (@mametter) 2021年4月2日 こっちのほうはまだ実験段階なので、まとまったころに説明するとして、今回は、Ruby 3.0リリース後にほそぼそとやっていたemrubyをご紹介してみます。 emrubyとは ブラウザの上で動くMRI（Matz Ruby Inter

チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー

みなさまの職場では、普段からフィードバックを行っているでしょうか。 フィードバックというと、一般的な企業では人事評価時に受けることが多く、昨今では1on1 の場でも取り入れる企業が多くなっています。 今回の記事では、弊社 Ubie で取り入れている一風変わった「自動フィードバック」の導入経緯や方法についてお伝えしていきます。 フィードバックが組織で重要な理由そもそもなぜフィードバックが重要か、Ubieで実感しているポイントを挙げていきます。 個人と組織の成長を促進させる 一般によく言われるフィードバックのメリットは、個人の成長促進です。フィードバックを他人から受けることにより、個人の足りてない点を認識・変化していくことで、組織全体の成長も加速させることができます。 期待値のギャップを知り、採用を加速させる フィードバックを受けることで、一緒に働いているメンバーの期待値と自分自身のアウトプッ

ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら

スマートロックを活用した法人向けの「Akerun入退室管理システム」をはじめとしたAkerunブランドのクラウド型IoTサービスを提供するフォトシンス（Photosynth）というスタートアップに、なんと80歳の現役エンジニアがいるといいます。 「戦争のことはいまだに覚えています」と語る深谷ヒロカズさん。生まれは1941年。太平洋戦争が始まった年でした。 戦争の怖さを身をもって体験した世代。焼夷弾の下をくぐって逃げたことが、幼いころの記憶に残っています。 そんな人物がいま日本のスタートアップにいます。しかも創業初期のフォトシンスにエンジニアとして参画し、初代のAkerun Smart Lock Robot（現在は生産完了）、提供中の法人向けAkerun Proの設計技術全般に関わってきました。以来約6年、今ではフォトシンスは正社員が150人を超えて成長を続けていますが、社内で技術講座を開く

今の会社に入って1年半が経った。入社してからずっと取り組んでた大きなタイトルが公開されて、それが明日大きな節目を迎える。会社にとっても大きなことだし、僕個人の人生にとってもひときわ大きな出来事かもしれない。 これは、小6でゲーム作りを夢みて大学4年間をプログラミングに費やした僕のゲームが、あした全国のゲーム屋さんに並ぶ話。 1番古いゲームの思い出は『ポケットモンスター クリスタル』だった。 引用元: https://amzn.to/2OCXGlR , https://www.nintendo.co.jp/3ds/pokemon_crystal/index.html 当日のゲームボーイ用のカートリッジは内蔵してある電池を使ってセーブデータを保持してたのだが、僕が持っていったクリスタルはこの電池が切れていたためセーブができなかった。その上、幼い頃に1日中ゲームをやっていて怒られたことがあったら

プロジェクトマネジメントにおいて、見積もりをどのように行うかは結構難しい。僕は理想日見積もりの形式も、相対見積もり(ストーリーポイント)の形式も試したことがあるが、どちらも一長一短であった。 最近色々試す中で、プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行するという方式がやりやすいと感じた。今回はその様子を紹介してみる。 理想日見積もりと相対見積もりそれぞれのメリット・デメリット 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察の記事を読むと、理想日見積もりと相対見積もり(ストーリーポイント)それぞれのメリット・デメリットがさっと把握しやすい。自分としては、それぞれ以下のように思っている。 理想日見積もり : 他の割り込みが全くなく、1日中タスクに取り組んだ場合を1理想日とする見積もり方式 メリット: 他に基準となるタスクがなくてもとりあえず雑に出せる。相対見積

新型コロナを封じ込めた数少ない国である台湾のデジタル担当大臣として日本でも有名になったオードリー・タン氏。関連書籍が何冊も出ている状況は私にとってとてもありがたいことだ。これまで私が彼女へのインタビューなどで聞いた言葉や、彼女が始めた台湾のシビックテックコミュニティ、g0v のメンバーから聞いたコンセプトの背景まで含めて深く理解ができるからだ。 近藤弥生子さんの書いたこの本「オードリー・タンの思考　IQよりも大切なこと」も、大変面白く読んだので、感じたことを記しておきたい。書評、というよりも自分自身の台湾との関わりも含めた感想という感じである。 誰にでも別け隔てなく接するオードリー私が始めてオードリー・タン氏に出会ったのは2017年だ。台湾で行われたCivicTecFestというシビックテックのカンファレンスでのことだった。彼女は壇上で台湾でのシビックテックの広がりについて語っており、「オ

Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が

目指せ脱UE4初心者！？知ってると開発が楽になる便利機能を紹介 - DataAsset, Subsystem, GameplayAbility編 -

言いたいことを言える場を強制的に作っておくことってめちゃくちゃ大事だと感じているのでその話をガッと書く。同じような話はいろんな書籍やブログで書かれているので、体系的なことを知りたい人はそっち読んだ方がいい。 いい感じのチームでは、言いたいことを言える状態をうまく作っているなあと感じることが多い。 例えばプロジェクト中に1週間2週間ごとに振り返りの場を設定していたり、毎日の朝会の中で相談コーナーを設けていたり、ウチでもやってるよというところは多いと思う。1on1もその機能の一端を担っている。一方で、場を設定したからといって言いたいことを言えるかというとそうでもない。場の設計が必要なのである。 例えば、「そもそもこのプロジェクトってやる意味あるのかよくわかってないんですよね」みたいな話をプロジェクトごとの振り返りでポンと言えるかと言うと、なかなか言いにくい。 こういう今さら感のある話や言いにく