はてなブックマーク

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

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

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 当初は弊社マネーフォワード京都開発拠点の名物（？）である「京の間」という和室の会議室で行おうと考えてました。 事前に社内メンバーから「座布団やクッションをクリーニングに出してるけど大丈夫？」と聞いていたのですが、「まあなんとかなるだろ」と軽く考えて準備していました。 ……が、イベン

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

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

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

日付的には昨日になってしまったが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万字とかいってた、ヤバい…） イベントの参加ログとしてのエントリはまた後日気が向いたら書く…かもしれない。 ついでに告知をば。 つい最近、というかまさに昨日

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

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

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

プロを目指す人のための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月まで東京にいたのですが諸事情あって今は京都でサーバーサイドエンジニアをやっているので「都落ちした地方エンジニアから見た地方転職事情」を報告しようかなと思います。 転職活動そのものや転職してからみえてきた地方エンジニアのあれこれを思い出しながら書いてるので多分支離滅裂なのでそこは勘弁してくれ(人∀・)ﾀﾉﾑ ところで東京から京都に出戻りしたときも都落ちなんでしょうか？ 都から都に落ちていてこれ

なお、技術書はこう読め！みたいな話ではない。 愛聴？している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は「周りでみてわいわい」するより参加して「ああでもない

なんのこっちゃとなったかた、京アジャ・ビブリオバトルに参加しませんか？というお誘いでございます。 詳細は↓ connpass.com ビブリオバトルとはなんぞや？という方もいると思う。 ぼく自身も名前をとあるライトノベルで知り、図書館にいった際にたまたま同時期に目にしたため覚えていたくらいだ。 ジャンルとしては非常にマイナーなものだと思う、読書好きな方などにとっては噴飯モノかも知れないが。 (ビブリオバトルというものを知るきっかけになったライトノベルがこちら↓) ビブリア古書堂の事件手帖スピンオフ こぐちさんと僕のビブリアファイト部活動日誌 (電撃文庫) 作者: 峰守ひろかず,三上延,おかだアンミツ出版社/メーカー: KADOKAWA発売日: 2017/03/10メディア: 文庫この商品を含むブログ (4件) を見る とまれ、名前は知っているがどんなものかわからない…connpassみてる

mackerelio.connpass.com Mackerel Drink Upに参加してきました。 あまり知り合いがいないので割りとドキドキしながら参加しました。 Drink Up系のイベントは初めてだったので普段の勉強会と違った流れに若干の戸惑いを覚えながらもいろんな話しが聞けて楽しかったです。 なによりいいと感じたのは「実際に使っていて困ったことを開発者に聞ける」という距離の近さが良かったですね。 以下良かったところ。 良かったところ 開発者やMackerelチームに直接質問できる 通常の勉強会のように片方が一方的に教える形でないため初心者が気軽に参加しやすい空気 Mackerel以外のことも聞けたり話してくれるので「Mackerelよくわかってないけど…」みたいな人でも質問しやすい 会場のMotex Cafeが洒落乙、カフェというよりバーラウンジっぽい。オトナな雰囲気！ Mack

Webエンジニアの方なら一度くらいは聞いた(やったことがあるとはいわない)はあると思うWrite Code Every Dayを実践してみた。 ぼくが知る限りにおいてもっとも古い提唱者↓ John Resig - Write Code Every Day 実は過去にも挑戦したことがあるのだがそのときは確か1週間ほどで挫折した覚えがある。 連日のように残業していて(これは単にぼくの手が遅かったことが原因)、 「日付変わる時間に帰ってきて毎日コード書くとかやれるか！！！」となってあえなく撃沈した。 あと日々の疲れを癒やすためにアニメやゲームを優先したというのもある、意思が弱いのだ。 ところが最近割りと頑張って続けられている。 そろそろ1ヶ月ほどなのだが割りと良いぞ！と感じるようになったので実践する前と実践した後でどう感じ方が変わったかを書いておこうと思う。 memo.yuuk.io もともとの

Webエンジニアの最低限必要なスキルってなんだろうか？とぼうっと考えてたらサッカーで例えれんじゃね！ サーバサイドはパスやドリブルで、ディフェンスがインフラでGKがセキュリティー、戦略理解はDBやクラス設計力で最後にシュートがフロントエンドだ！ …とか思ってたんだけどめっちゃ伝わりにくい気がしたのでちょっとだけ書いてたけど破棄した。 それはさておき風呂に浸かりながら電子書籍をダラダラと読んでいた際にふと↑のようなことが頭をよぎって「技術力とはHDDやSSDのようなもの」かもしれないとか考えたら思いの外、的外れでもないのかな？と思ったので忘れないうちにせっかくだから残しておこうと思う。 詰まるところ、技術力というのは選択肢(蓄積できるデータ量*スループットの速度)だということだ。 それがより大容量でスループットが速いSSDなら当然お値段は高い、逆に容量が少なくてスループットが遅いHDDは当然