地方都市でエンジニアのコミュニティーを立ち上げた話 - 虎の穴開発室ブログ
福島県いわき市に住みながらフルリモート勤務をしている、エンジニアのJ.Wです。 今年の7月に私が住んでいる地域で活躍しているエンジニア有志でWEBアプリケーション開発の活動を立ち上げました。 その立ち上げの背景や初回のキックオフMTGまでのストーリーを語らせていただきます。 活動を思い立った背景 地域に限定した活動を思い立った背景を説明をします。 1. 地域のエンジニアの技術的知見を広げたい 私の住む地域にも小規模ながら製造メーカーや行政のシステム開発を受託するソフトウェアベンダーが数社活動しています。 ただ、顧客のシステム特性から利用技術も限られ、かつモダンな技術に刷新も容易に行うことができません。 そして、顧客も限定的で新しい技術知見を得る機会が少なくなっています。 そのため、私が今まで経験してきた技術的知見、経験を共有したいと考えました。 2.地域のソフトウェアベンダーの会社間交流を
OSS Forwardするエンジニアにインタビュー！なぜOSS開発文化が育っていないマネーフォワードで活動をおこなうのか？ - Money Forward Developers Blog
企画概要 今回は最近マネーフォワードが公開したOSS開発の消費税計算GemJctを主導したTaKOBKiさんに、なぜ社内ライブラリをOSSで公開しようと考えたのか、を根掘り葉掘り聞いてみたいと思い、インタビュー企画を実施しました。 OSSとは？ オープンソースソフトウェア（英: Open Source Software、略称: OSS）とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である[1]。 wikipedia参照 それでは早速インタビューしていきたいと思います！ 聞き手は技術広報の luccafort です。 プロフィール: 株式会社マネーフォワード CTO室付 前田 喬之（TaKO8Ki） luccafort： まずは自己紹介からお願いします TaKO8Ki：2019年11月からマネーフォワードの京都開発拠点にインターンとし
マネーフォワード vs freee、もし名古屋で開発するなら？ - freee Developers Hub
こんにちは、DevBrandingのellyです。11月19日に配信した「マネーフォワード vs freee、もし名古屋で開発するなら？」の様子をご紹介します。 これから名古屋に開発拠点を立ち上げるマネーフォワードと 2020年に拠点を構えたfreee。 なぜ名古屋に開発拠点が必要なのか、作っているプロダクト、本社との関わり方、 両社のエンジニア組織の違い等を対比しながら1時間たっぷり赤裸々に語ってもらいました。 とても爽やかな両社の自慢対決となりました 長島圭祐 (Kei) さん: マネーフォワード 名古屋開発拠点 拠点長兼サーバーサイドエンジニア。 福岡でマネーフォワードクラウド債務支払の開発を担当しつつ、名古屋に新設される開発拠点の立ち上げを進めている。最近はサーバーサイドKotlinに夢中。 moai: freee 中部開発組織長。中部開発組織を2020/7に立ち上げた。地域技術イ
ペパボテックブログの裏側 - Pepabo Tech Portal
執行役員 VP of Engineering 兼技術部長の @hsbt です。先週発売したモンスターハンターストーリーズ2をプレイしながら、「ティガレックスじゃなくてナルガ亜種出てよ〜」という感じにオトモンの卵探しに時間を費やしています。 今回は「ペパボさんには〜はありますか?」シリーズの第二弾として「ペパボさんではテックブログの執筆方針などはありますか?」という質問をもらったので、GMOペパボ(以下、ペパボ)でのテックブログの運営方針をこのエントリで紹介したいと思います。(第一弾は GMO ペパボでの Slack の使い方 2021 - ペパボテックブログ です) 運営方針 ペパボテックブログは 2015年11月17日にスタートしました。当時の執行役員CTO、現取締役CTOの @kentaro が書いたテックブログ開設の目論見について引用します。 日々の業務から得られた知見を少し立ち止ま
プロダクトオーナーを経験してドメインを理解する感覚が身についたかもしれないという話 - pospomeのプログラミング日記
現在自分は会社の仕事で認証基盤とマイクロサービス向けのアプリケーションプラットフォームを構築していて、 役割としてはテックリードとプロダクトオーナーを兼任している。 自分が開発、運用するシステムは主に社内のエンジニア向けの仕組みなので、 問題解決対象が技術領域となっている。 "技術的な課題を技術で解決する" という性質上、 プロダクトオーナーもある程度技術を分かっていないといけないので現状兼任している感じである （正確に言うと People Management もしているので、Engineering Manager も兼任していることになるが、 今回の内容と関係ないので触れないでおく）。 チームに興味ある方は連絡ください。 1年前にチームを立ち上げて、今は8名体制になりましたが、まだまだエンジニアが足りません。興味ある方は連絡ください。DMMマイクロサービスアーキテクトチームでサーバサイ
情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
褒めるラジオ quipper.fm - スタディサプリ Product Team Blog
こんにちは。quipper.fm メインパーソナリティの @chaspy です。 今回、一緒に働く仲間をただひたすらに"褒める"社内企画をはじめてみました。好評により続いているので、その取り組みについて紹介します。 quipper.fm とは何か なぜはじめようと思ったのか 褒めることの重要性 1. "褒め"によるフィードバックが個人の振る舞いを強化する 2. "褒め"による振る舞いが言語化されることはそれ自体が貴重な学びの機会になる 褒める技術 褒められたひとからの言葉 おわりに quipper.fm とは何か 名前に深い意味はないんですが、ラジオっぽい"雰囲気"でゆるく聞いてもらえたら、という想いで .fm をつけています。実際は社内 Google Hangouts で行っているので、音声だけでなく映像も映ります。 この番組は隔週30分で行われています。各回に1名「褒められるひと」が選
社内勉強会で専門的技術力を高めるには
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯（ヤフー内のスキル任命制度／ネットワーク・セキュリティ）に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書
チェリー本の増刷（第5刷）が決まりました＆これまでに書いたサポート記事のまとめ - give IT a try
お知らせ 先日、技術評論社の編集者さんから「プロを目指す人のためのRuby入門（通称チェリー本）の4回目の増刷（第5刷）が決まりました」と連絡がありました！ 増刷嬉しい〜😆これもひとえに今まで購入してくださったみなさんのおかげです。どうもありがとうございます！ プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus 作者:伊藤 淳一発売日: 2017/11/25メディア: Kindle版 ちなみに増刷というのは、出版社が在庫を補充するために、まとまった部数を追加で印刷することを言います（書籍の内容は同じです）。 言い換えると、「増刷される＝在庫がなくなるぐらい順調に売れている」ということなので、著者や出版社にとってはとても嬉しい知らせになります。 まあ、普通の読者さんにとっては「ふーん」という話題ですよね😅 僕も自分で
マネジメントも「技術」のひとつ。技術志向だったエンジニアが、開発チームのディレクターに挑戦するわけ - Findy Engineer Lab
こんにちは。粕谷大輔（@daiksy）です。インターネット上では「だいくしーさん」と呼ばれることが多いです。現在は株式会社はてなで、Mackerel開発チームのディレクターを務めています。Twitterなどで使っている、地獄のミサワ風のアイコンをご覧になった方もいらっしゃるかもしれませんね。このアイコンは、前職のフロントエンドエンジニアに描いてもらったものです。 今の自分の仕事は、エンジニアとデザイナーで構成される開発チームを指揮し、プロダクトの安定稼働と、定常的なデリバリーに責任を持つことです。「エンジニアリングマネージャー」という言い方をすると、分かりやすいかもしれません。 自分のこれまでのキャリア選択を振り返ると、もちろん結果論のようなところもありますが、ある程度狙いを定めてキャリアを歩んでこられたのではないかと思います。本記事では自分のこれまでのキャリアについて、「どのように狙いを
LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善｜ハイクラス転職・求人情報サイト AMBI（アンビ）
LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 サービス開始から10年近くがたったLINEでは、次の10年のため技術的な負債を解消・改善する取り組みをプロジェクトで行っています。 通信プロトコルをSPDYからHTTP/2に移行 抽象化レイヤーを設置してプロトコル移行のリスクを低減 Long PollingをPushへと切り替えて通信量を最適化 アプリの利用状況に応じて最適なデータ同期の方法を アーキテクチャの改善でアプリの信頼性や拡張性が向上 長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。 この課題を解決するため、LINE株式会社では「『
【ありがとうございます】これから読んでいく本 - えいのうにっき
先日、このようなお知らせエントリを書いたところ、文末のウィッシュリストよりたくさんの方からたくさんの本をお贈りいただきました。本当にありがとうございます。 blog.a-know.me 当然、いただいた本は順次読んでいくことになるわけですが、今日のこのエントリでは、今後どういった本を読んでいくか・なぜそういった本なのか、というその紹介をしつつお贈りいただいた方への御礼とさせていただけたらと思います。順不同でございます。 コードを書く技術に関する書籍 Clean Code アジャイルソフトウェア達人の技 は@hika_riruさんから、リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) は@fd0さんからいただきました。どちらの方も、Twitter上でゆる〜くfavしたり・されたりといった関わり（直接お会いしたことはない...
知らないことを調べる時間がない - hitode909の日記
やりたいことがあって、あれやこれ、といった技術を使えばよさそうなことはわかっているけど、平日は時間がなくて触れず、技術的にキャッチアップできてないので同僚との会話していても曖昧な状態、という状況が1ヶ月くらい続いていた。 妻が出張で東京に旅立っていったのでその間に勉強できた。家の環境に関するステイクホルダが自分だけになったので家事はほったらかしで、台所から不思議なにおいがしていて、時間を短縮するため雑なものを食べている。 技術的負債について非技術者に分かってもらうには、という話がよくあるけど、家の中で誰も家事をせず、全員遊んでいる状態をイメージするとよさそう。ちょっとずつ皿を洗っていれば苦労しないけど、たまってくると草が腐って土ができたりプランクトンから石油ができたりしてたいへん。 調べたいことはいくらでもあるので、定期的に予定をあけて調べたいこと調べられるようにしていきたい。平日や、業務
人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について - HsbtDiary(2019-02-27)
■ 人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について 去年 @pyama86 さんが読みやすくて面白かったと話していたので買ってシュッと読んだ。 確かに面白くて、コンピテンシーという考え方はなるほどなって感じだった。いろんな立場の人が組織にはいるけど、より管掌や責任の範囲が広い人は狭い人ができることは当たり前とした上で、立場にあった評価の基準が重なっていくという話で、自分も含めて「わかるー」という感じだった。 後、この本では評価を決めるのは影響力というくだりがあって、これは特に専門職に分類される人には読んでもらいたいところなんだけど、エンジニアの場合だとシニアエンジニアは「技術力が高い」から評価されるのはなく「技術力が高いので結果として生み出されるアウトプットの影響力が高い」から評価されると置き換えるとわかりやすいと思う。 「アウトプット」と言われると OSS であ
技術顧問ブームの流れを汲んだエンジニアリングマネージャーブーム、という考察 - @kyanny's blog
というか、（かなり偏見を含む）空想。 blog.kyanny.me 「技術力が衰えつつあるおじさんエンジニアのキャリアパスをどうするか」という命題に対して業界は「経営がわかるCTO」「技術顧問」などの回答を示してきた しかしCTOも技術顧問も椅子に限りがあるため、業界は新たな受け皿を必要としていた 業界の平均年齢が上がり、他の業種と同様におじさんエンジニアたちは「管理職」になることを受け入れなければならなくなったが、この業界は「マネージャー（管理職） = 悪」という価値観が根強いため、業界人たちの意識変革が必要だった そういうもろもろの問題意識やら個々人の思惑やらが交錯した結果、どこかの誰かが「エンジニアのマネージャーは無能な管理職なんかじゃない！『髪の尖った上司』なんかじゃないんだよ！」といいだし、キャリアに不安を抱えていたおじさんエンジニアたち（と、そんなおじさんの背中をみてぼんやりと
メルペイのエンジニアリングマネージャーとして働いています - ひつじのにっき
今年も一年、おつかれさまでした。 この日記を書いている時点では12月27日です。弊社の暦に従えばあと2営業日ぐらいありますが、すでに仕事を納めたひとも多いので誤差の範疇でしょう。 あなたは誰？ メルペイでAndroidのエンジニアリングマネージャーをしているmhdiakaです。 日記をよんでいるみなさんが観測できる範囲だと技術書典というイベントの主宰やDroidKaigiというカンファレンスのオーガナイザーやKotlinFestのお手伝い、四半期ごとに2～3冊、年に10冊程度の技術書を執筆したり編集したり、たまに寄稿などしています。これだけよむと働いてるのか？って思いますよね。（このあたりの作業は業務時間もつかっているので）働いてます。 1日に7,500万円分の技術書が流通する「技術書典」の仕組みと挑戦 - マネ会 DroidKaigi 2019 PEAKS（ピークス）｜Androidテス
バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebGLを使ったマンガビューワを作っている - daiiz
