はてなブックマーク

やりきったぞ!!!!! TL;DR 関西Ruby会議08が終わり、疲れ果てていたのだけどid:Pockeさんが書いたブログに触発されたので書いています......と入れてたんだけどやはり体力の限界を迎えてしまったので翌日に続きを書いています。 限界前まででも1万字を超えていたが最終的に2万字を超えたので覚悟して読んで欲しい。 疲労と寝不足とお酒が入っているので支離滅裂な可能性があるし、普段よりもくっそ長文になると思うので読みたいところだけ読んでください。 pockeさんの記事を引用し忘れていたので追記。 commits.hatenablog.com あと今回の関西Ruby会議08でKyoto.rbに少しでも興味を持った人がいたら、とりあえず一度遊びに来て雰囲気を味わってみて欲しい(宣伝)。 次回開催は7月27日です、前日がきのこカンファレンス in 関西なので連日イベントだけどまあ仕方ない。 ky

scrapbox.io 上記を読んだ。 めっちゃいい文章なので未読の人はぜひ読んでほしい。 そんなことよりも、まずは「熱意が前提」ということにしたい。 (中略) 逆に、熱意があれば数字はあとからついてくる(ついてこさせることが可能)だと思う。 (中略) 芝を注文したり、ホールドを作ったり、船を出したりするのは正気では無理。 という話をみて、これは本当にそうだなと思って読んでいた。 カンファレンススポンサーやカンファレンス参加支援は当たり前じゃない で、話は変わるんだけど「会社にこのカンファレンスのスポンサーしてほしいんです〜!」とか依頼が来ることがあるんですね。 お金が無限にあれば「やりましょう!」って言えるんですけどそうじゃないので、だいたい何かしら選ぶ必要があります。 そういうときに腕力で黙らせるためには実績が必要で、そういうときに「有給休暇使って実費で参加します!」みたいな人が大量に

TL;DR マネーフォワード 京都開発拠点に外国籍エンジニアが入社して起こった変化 ガイコクジンに対する苦手意識の軽減 とはいえ異なる言葉でコミュニケーションする壁はまだまだある 英語化への道はまだまだ険しい......。ぼくはようやくスタート地点に立てただけ。 はじめに 先日、弊社マネーフォワードの大阪開発拠点長 1 の @okeicalm がアドベントカレンダー25日目の記事を書いた。 これを読んでいて、「そういえばこういう変化が自分の中でも生まれたな〜」と思うことがあったのでメモしておく。 note.com 前提 まずこれまでのぼくの経歴というか歴史的な背景から。 多くの日本人がそうであると思う(最近は事情が変わってきてるかもしれない)が、ぼくはこれまで外国籍メンバーとあまり働く機会がなかった。 外国籍メンバーと働いてるときもだいたい彼ら、彼女らは日常的なコミュニケーションが可能なレベルで日

先日インターネット上で以下の投稿を見かけた。 技術ブログ、本当に誰かの為になるような技術的に高度だったりニッチだけど貴重だったりする記事はマジで誰からも注目されなくて、バズるのはお気持ち表明系かネタ記事かビジネス書みたいな意識高い系か、技術記事でも キャッチーな言語や技術を使った○しろまる○しろまるやってみた系」というイメージ。— みゅーる (@__muell__) 2024年11月29日 これめっちゃ難しい問題だなーと思っていて基本的にレイヤーを トッププレイヤー 上級者 中級者 初級者 初心者/未経験 のように分けたとき、以下のような図になる。 「卓球のレベルピラミッド 新たな図」より引用 (この図は卓球が題材だがどの業界でも基本構造は同じなのでそのまま持ちいさせてもらった。) 基本的には引用する形でポストしたこれがぼくの答えではあるんだけど「そもそもバズらせる意味がない」になってしまう。 そもそもバ

誤解がないように最初に言っておくが辞めたわけでも、辞めようとしてるわけでもないです。 11月最後の週の金曜に入社当時にメンターをしてくれた業務委託のエンジニアの方の送別会に参加した。 入社当時、メンターをしてくれた @ino_dev さんの送別会に参加してきた。 同じ会社に5年もいるといろんな人とお別れすることになり、少し物悲しい。 コミュニティーとかでお会いするだろうけど惜別という感じだなぁ。 その説はお世話になりました!これからも別の形でよろしくお願いします!🙇‍♂️— luccafort (@luccafort) November 29, 2024 マネーフォワードに入社したのが2020/01なのでもう少しで6年目に突入するわけだけど、いろいろ学ぶところがあったし、井上さんの元でもっと学んでおけばよかったと改めて思う。 最近、社内の人事発令を見ていると「あ、XXXのときにお世話にな

[2024年12月01日 21:30 追記] なんかあまりにも強制参加される社内イベントだと誤解されてるので大前提としてこの話は全て任意参加の社内イベントを盛り上げるのが難しいという話です。 強制参加の話はしてないです。強制された段階でイベントの印象がマイナススタートのそれと自ら参加するタイプの社内イベントは目的が別なので分けて考えています。 君たちの会社が矯正してるかどうかは知らないけど、おま環情報は不要です。 [/追記] ぼくは技術広報という立場なので社外でイベントしたり企画したりが目立つと思うんだけど、表から見えないところで社内の技術イベントやワークショップなどの企画もしている。 今回はどちらかというと社内のイベントや技術コミュニティーを盛り上げるのが難しいと感じているというお話しです。 解決してる課題ではなく、こういう現状があり、どうするといいのか?という脳内のdumpを行っています

TL;DR Kyoto TechtalkやKansai.go、Go Conference mini、OSS Gate、技術書典などなどここ1年ほぼいろいろと試したり失敗したりしながら発信をし続けてきたな〜と思ったのと、最近BuildersConが復活したりさまざまなカンファレンスが新たな産声やリブートをしてるんだけどみんな東京じゃん!地方もやっていこうず!!!という思いからこの記事を書いている。 1年くらい前に飲み屋で id:onk と id:pinzolo と話したこと 当時はコロナ禍が収まってようやくオフラインでのイベントとかできるようになったタイミングだったんだけどあまり参加者が集まらないという悩みを抱えてました。 kyotorb.doorkeeper.jp なんでやったか?についてははてなのonkさんが言った「企業が元気じゃないのにコミュニティが元気なわけがない。コミュニティが元気

先日、およそ1年ぶりにKyoto.rbの活動を再開しました。 それもオフライン限定で......。 kyotorb.doorkeeper.jp オフラインでのコミュニティイベントを主催するのは久々(およそ3年ぶり)で諸々のお作法を忘れていました。 イベントの最後におこなったふりかえりでも「以前は○しろまる○しろまるをやっていた」「これは○しろまる○しろまるしたほうが良さそう」といった過去にやっていたことの失伝っぷりが露呈しました。 ふりかえりの内容は全てKyoto.rbのScrapboxで公開しているので興味がある方はどうぞ。 scrapbox.io 当初は弊社マネーフォワード京都開発拠点の名物(?)である「京の間」という和室の会議室で行おうと考えてました。 事前に社内メンバーから「座布団やクッションをクリーニングに出してるけど大丈夫?」と聞いていたのですが、「まあなんとかなるだろ」と軽く考えて準備していました。 ......が、イベン

TL;DR タイトルが結論。 Kyoto.goのオーガナイザーはやめるけどいまの会社やKyoto.go以外の活動をする...ということではないです。 なんで退任するの? Kyoto.goは2020年1月に発足した、比較的若いコミュニティです。 ぼくが発起人となって、さまざまな方にご協力いただいたり参加していただいたことでいまなお続くコミュニティへと進化してきました。 kyotogo.connpass.com 元々ぼくはあまりコミュニティ運営やマネジメントの能力があるわけではない中で始めたので発足当初から自分がいつか退任することを想定していました。 ただ、退任するにしてもコミュニティは継続してほしいとも考えていたので、できる限りの意思決定のログを残すようにしていました。 1年目はコロナ禍というコミュニティどころか社会全体が激動の年となりました。 2年目はGo Conference 2021 Au

概要 Money Forward Kyoto Advent Calendar 2020の5日目、バックエンドエンジニアのluccafortでお送りします。 adventar.org このエントリは読書する習慣を身につけるテクニックを紹介するエントリになります。 読書によって得られた知識は経験を媒介することで誰にも盗むことができない財産になります。 皆さんの財産が世の中のマネーをフォワードする一助になるとよいと思い、このエントリを書かせていただいています。 結論から まず結論から。 このエントリは以下の書籍から得られたことや試したもの、読書を継続するのに重要そうな要素を抽出したものとなっています。 ですので、もし興味があるかたはこれらの書籍をお読みになられるほうが早くより正確だと思います。 ぼく個人としてもそちらをおすすめ致します。 学習効率のよい読書術を求められているかたは↓がおすすめです

先日kakakakakkuさんのスライドを読んでいて直近で出来てないなーと思ったり指摘されていたことがまさに書かれていてめちゃくちゃ刺さった。 主にメンタルブレイク的な意味で。 個人的に刺さったのは以下。やれてないですねーってところは刺さり方が深くて印象に残りますね。 特に後者は最近お仕事でも指摘された内容であり、刺さり方が深かったです......誰に伝えたいか、何を伝えたいか大事ですよね。 ストーリーの展開は適切か 読者層は誰なのか?なにを伝えたいのか? kakakakakku.hatenablog.com で、それだけならまあやっていきましょうねで終わる話しなんだけど以前知り合いのブログで「アウトプットすればいいじゃんっていうのも一種の生存バイアスじゃん」というようなエントリを読んでいたことをふと思い出していくつかの改善案がありそうだなと思ったので書き出す。 mirai-iro.hatenab

note.mu 前提となる条件の会社で働いたことがないので正直的外れなのかもしれない。 でもぼくはこれを読んだときの素直な感想として「これは違うんじゃないかなー?」と思った。 とはいえ完全に否定したいわけでもなくて同意ポイントと違和感ポイントがあるなという感じです。 追記 ブコメでテスターでもいいんじゃないの?というコメントをみかけて誤解させてしまう文章を書いてしまったなと思ったので訂正です。 id: hotu_ta 自分は、自然とブラックボックステストっぽいことからエンジニアの人生を歩み始めたし、テスターからエンジニア的な理解を深めていくのは悪くないアプローチに感じる。 テスターそのものから開始すること、それ自体はあってもいいのではないか?と思います。 ただ上記エントリでの問題を解決するためにテスターを選択するのは短絡的な解決方法であって根本治療ではないのでは?ということで書いた感じです

anopara.net ↑元ネタ。 この手の話は定期的にあがり、そしてだいたいGW前後に発生してそのたびに「あーこれぼく知らないな...」とかよく思ってたんだけどとりあえず「これ読んどけば頭の片隅にはある」レベルを目指すというめちゃくちゃ志の低いやっていきと今何を理解してるのか振り返りとして書き出して来年どうなってるか計測しようと思って書き出した。 あともしこのエントリをみて「これ読んどけ」みたいなのあれば教えてくれると助かります。 他にも海外版これ読んどけがあったのでそれもあわせて読んでおけばだいたいのところはカバーできるんじゃあないかという目論見です。 medium.freecodecamp.org プログラマだったら当然知っててほしいと思う知識 データ構造 プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 作者: 渡部有隆,Ozy(協力),秋葉拓哉(協力)出版社/メーカー:

日付的には昨日になってしまったがSansanさんのイベントに参加してきた。 最近MoneyForwardさんやSansanさん、LINEさんなどの京都ご新規勢が加入したことで少し京都のIT業界が活気づいていて良い。 sansan.connpass.com 参加した動機としては最近「マネージャーの必要性はわかるんだけどそもそもマネージャってなにする人だったっけ?」とか「エンジニアリングマネージャとテックリードがいて違いがあるのはわかるんだけど結構で共通している権限があると思うんだけどそこを明確に線引するのはなんで?」みたいな疑問があったので実際EMとして働いているひとたちに聞いてみたかったという感じです。 個人的に一番面白かったのが id:y_uuki さんの「SREの組織的実践」で最初SREの話しだったのでそっちがメインなのかと思ったら最終的にきちんとエンジニアリングの話に収束していて話の

tbpgr.hatenablog.com ↑を読んでちょっとそれはどうかなー?と疑問に思ったことがいくつかあったのでアンサーソングとしての書き出し。 エンジニアがHRに関わることに関する自分をポジションの中心に据えたうえでの発言になります。 採用への協力を「好き」とこたえている 採用活動への協力に対してポジティブですか?ネガティブですか?という質問のほうがよかったのではないか? 同じチームメンバーとして働くので無関心ではいられない、小さい会社、小さいチームだとより顕著だし影響度でかい。 一緒にいてイライラするような人と同じ空間にいるのはキツい そもそも採用活動を好き嫌いの二元論で語るのは少し違う気がしている 大事だと思うし、協力できることならしたいと思ってる。でも好きでも嫌いでもない。 採用はチーム全体で行う一種のモブプログラミングみたいなものだという意識があるので好き嫌いは関係ない気がす

sansan.connpass.com Legacy Meetup Kyotoに参加してきました。 元々はこのイベントでの参加ログを書くつもりだったんですがそこであった発表の中に「yahoo!で働くようになってまだ半年なんですが...」という一言に影響されてこのエントリを書いています。 ぼくが株式会社トマルバに実際に入社したのは去年の5月からなのでまだ1年経ってはいないのですが副業の開始時期が去年の2月頃からだったのでまあちょっと多めにサバ読んでだいたい1年として見積もって、いろいろなことがあったこの1年を振り返ろうと思います。 構想段階でポエムが長文になるなという感じなのでサラッと目を通すくらいの気持ちで読んでください。 (書き終えたら1万字とかいってた、ヤバい...) イベントの参加ログとしてのエントリはまた後日気が向いたら書く...かもしれない。 ついでに告知をば。 つい最近、というかまさに昨日

blog.shibayu36.org 1on1でいつもメモをとっているのだけど以前読んだ id:shiba_yu36 さんのテンプレートシートを少しカスタマイズして使うようにしたところ、思いの外使いやすいのでみんな使ってくれよな!と思ったというお気持ち表明です。 カスタマイズした箇所としては「前回の1on1後にやるアクションの経過報告や結果」を最初に追加しただけ。 個人的には相談内容からの雑談派生が割とぼくは発生するので「話したいことなんでも」項目はなくてもいいかもしれないなぁと思ったくらい。 ただなくすにはもったいない項目だなとも思ってはいるので、なにか話したいことがあったときだけ追加するみたいなオプショナルな項目でいいかも。

タイトルはいい感じの内容が思いつかなかったのでダンまちっぽくしようとして失敗したので気にしなくていいです。 TL;DR バズったはいいけれど、リモートでは顧客の問題解決が難しいという肝心な点が伝わっていない🤔— シマリス🐾 (@logsupport_mark) December 12, 2018 このエントリは上記の発言を今朝みてしまい申し訳なくなったので懺悔の気持ちで書いています。 グーメン。 ちなみに今回の件はリモートだからというのはあまり関係ないと思いますまる 発端 先日ひょんなことから下記のブログを拝見し、「ここは正しくないし誤解しているから直したほうがいいよ(意訳)」というコメントをしました。 そのあとで正直な気持ちをはてブしたところ思わぬ方向へバズってしまったらしく、 その一因を作ってしまったという反省の思いから「じゃあどうすれば良かったのか」を書いて許しを得ようという下衆

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ) 作者: 西尾泰和出版社/メーカー: 技術評論社発売日: 2018年08月10日メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る 読んだ。 この本を読んだ大きな目的としては4つ。 技術書を早く読む技術の向上、もしくは問題の解決 モチベーションの維持管理を学ぶことでムラのある管理方法に一定の持続性をもたせる 何を「いま」学ぶべきか?を論理的に行えるようになる学習効率の最大化を図る 大学に入り直すべきか?という学歴コンプレックスに端を発する欲求に区切りをつける 更にいうなら、この中で重要視すべきは読む速度の向上とモチベーションの管理方法を改善するのがマスト、 なにを学ぶか?と大学に入り直すのは可能であればくらいの気持ちで読み始めた。 感想: モチベーションに関

ユーザーストーリーマッピング 作者: Jeff Patton,川口恭伸,長尾高弘出版社/メーカー: オライリージャパン発売日: 2015年07月25日メディア: 単行本(ソフトカバー)この商品を含むブログ (7件) を見る 読了した。 会社で、というかぼくのプロジェクトの進め方やヒアリングの仕方などに問題があって渡された感じ。 「課題図書じゃん!w」って言ってたけど本当に課題がてんこ盛りって感じで学びがあった...。 俺はなにもわかってなかった...みたいな気持ちといままでどうやればいいのか取っ掛かりがなくて途方にくれていたけどこうすればいいのかーという気づきを得られた。 感想 属人性がはっきり分かれそうな本なのでおすすめしにくい。 ただいまの時点のぼくにはいろいろな手法や考え方、プロジェクトの進め方なんかを学ぶところが多くて割と良かった。 章立てのサイズがいい感じなので夜寝る前にちょっと読む...みた

昨日から読んでるがめっちゃいい話しなのでいまのうちに書いておく。 感想はまた後日。 この本は「いまの会社やめようかな...」と考えている人や「うまくチームが回ってないな」と感じている人向け。 どこかで聞いたことがあるようなどう改善していくのか、またその仕組みを取り入れる目的や目指す地点が丁寧に書かれている。 ストーリー仕立てで進行するため「あるある〜」という感じでスラスラ読めていく。 いまのチームや会社で働いている人に対してはないが組織やマネジメントなどで不満があるという人には是非一読してほしい。 そこから何を感じるか、どう動くかは個々人毎に違うだろうけども、その際の1つのガイドブックとしてカイゼンジャーニーはよい手助けをしてくれるだろう。 なお、↑ではアフィリエイトリンクを貼っているが現在出版元の翔泳社では電子書籍半額セールを行っている。 www.shoeisha.co.jp 期限が2/21

先月は中盤くらいまでいいペースだったけど後半に体調不良で一気にペースダウンしてしまった。優先順位の設定とかやろうかな...。 昨年末、やっていくぞ!という思いを新たにしたところ、さっそくフラグを回収してしまいました。 どうしてこうなった...。 やったこと: [x] プロを目指す人のためのRuby入門を読了 [x] 知識ゼロからの小さな会社の始め方を読了 [x] プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化を読了 やり残していること: [ ] テスト駆動開発を読了 [ ] Railsチュートリアルの写経を完遂 元々はWebページみながらやってたが面倒くなって電子書籍版を購入してKindleに突っ込んだ、PDFだと日本語になるのだがKindle形式に変換すると英語になってしまった。完全に謎。 Cloud9がAWSになっていて面倒くさい [ ] Go言語でチャ

紹介: sp.14a【ゲスト: lucca0show】楽しいコミットメントの始め方 shiganai.org sp.14b【ゲスト: lucca0show】楽しい積ん読カンバン術 shiganai.org ゲスト出演しました! ...がいくつか話していて説明不足であったり、うまく説明できていないなと感じることがあったので補足話を書いておこうと思います。 好きなことを仕事に!だけでは難しい: よく「好きなことで食べていく!」とかキャッチフレーズみますよね? ぼくは割りと好きなことを仕事で生活できていると思っているんですがゲーム業界で働いていたときに「ゲームが好きってだけだとこの業界で働き続けるのは難しいなー」と実感したということが伝えたかった主題です。 実際にゲーム業界で働く前は「好きのレベルが低いんじゃない?」という疑念が頭の片隅にあったのですが業界で働く内にその幻想は木っ端微塵に砕け散り

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) 作者: 伊藤淳一出版社/メーカー: 技術評論社発売日: 2017年11月25日メディア: 大型本この商品を含むブログを見る 2017年中に読了する予定だったがゼノブレイド2やってたら諸々あって2週間遅れで読了した。 対象: 本著の冒頭でも語られている通りプログラミングの未経験者がこの本を読了するのはかなり根気がいることだろうと思う。 プログラミング初級者(初心者でない)が次のステップへ行こうとするときに読むべき本であると感じた。 一方で手元にあって困ることがない本だとも実感した。 他の言語である程度プログラムを書くことが出来る、あるいは最低限if文、for/while文、関数がわかる人が対象としてボリュームゾーンであるように思う。 感想: 結論からいってしま

しがないラジオ Advent Calendar 2017 どうも、しがないラジオ Advent Calendar 12日目を担当する@lucca0showこと、るっか和尚です。 11日目は id:radiocatz さんです。 radiocat.hatenablog.com はい、パーソナリティのお二人でもないのに6日目に続きまして2度目の登場でございます、いえーい!!! 実はぼく、去年2016年10月まで東京にいたのですが諸事情あって今は京都でサーバーサイドエンジニアをやっているので「都落ちした地方エンジニアから見た地方転職事情」を報告しようかなと思います。 転職活動そのものや転職してからみえてきた地方エンジニアのあれこれを思い出しながら書いてるので多分支離滅裂なのでそこは勘弁してくれ(人∀・)タノム ところで東京から京都に出戻りしたときも都落ちなんでしょうか? 都から都に落ちていてこれ

今週のお題「今年買ってよかったもの」 よかったもの Inateck ラップトップスリーブケース 以前も紹介したが今年のベストバイをあげるならこれかなという気がしている。 使いやすく、また使い心地も良い。 不満点もいまのところないため、ほぼ満点に近い。 ポーチもついているのだがそれも結構収納力があるので周辺機器くらいならだいたい入る。 不満点の少なさ、満足度の高さからまだ1ヶ月ほどあるがベストバイといいきって問題ないと思う。 Bianchi リュックサック/ディパック NBTC50 スリーブケースとどちらにするか一瞬悩んだが結局スリーブケースをベストバイにあげてしまった。 このディパック自体は決して悪くない...悪くないのだけど2点だけ小さな不満点があるので順位を下げてしまった、それ以外は概ね満足いく品だと思っている。 不満点: タブレット用スリーブがiPad Pro 12.9インチだとギリギリ

なお、技術書はこう読め!みたいな話ではない。 愛聴?しているpodcast の通称しがないラジオで「あなたの技術書の読み方」というフィードバックテーマ(お題?)がでていて 技術書の読み方は読む人のスキルやその技術書でなにを習得したいと考えるか?がバラバラで難しいよなーと思った。 そこでそういえば技術書の読みかたを振り返るのもいいかもしれないと思ったのでKPT形式で振り返ってみようと思う。 元ネタのpodcastは↓、SIer出身じゃないけど割りと楽しく聞いている。 たまに自分のハンドルネームが読み上げられると恥ずかしくて死にたくなる。 (主に会社で聞いているので身悶えしてるときはだいたいそう。) shiganai.org 前提: blog.shibayu36.org ぼくの技術書の読み方のスタンスはshibayu36さんの↑のエントリを参考に自分風にアレンジしたものになる。 目次を見ながら

isucon.net ISUCONとは「いい感じにスピードアップコンテスト」の略。 恐らくISUCON3あたりから観測はしていて本番出場者の攻略エントリや予選敗退者の反省ブログなどを読んで面白そうだなとは思っていた。 今回初参加してみて、あわよくば本戦行ければなーと淡い期待をしていたら木っ端微塵に吹き飛んだ。 「ガトリンガー葉の仲間たち」としてcs_sonar、kawakattsun、luccafortの3名で1日目勢として参加。 順位は暫定55位で当然本戦出場圏外、ぼくは正直全く貢献できなかったと思っていて非常に悔しい。 それでもこの順位なのはほぼインフラ周りをみてくれたcs_sonarのおかげだと思ってる、マジ最高。 ISUCON7の予選問題とその解説は↓、目を通しておくだけでも楽しいぞ! isucon.net 結論: ISUCONは「周りでみてわいわい」するより参加して「ああでもない