並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 1577件

新着順 人気順

プログラマの検索結果41 - 80 件 / 1577件

  • 【日本人エンジニア必携】英語命名規則の決定版 - Qiita

    弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists

      【日本人エンジニア必携】英語命名規則の決定版 - Qiita
    • セキュリティエンジニアを3年続けて分かったおすすめ勉強法

      セキュリティエンジニアとして就職してからそろそろ3年経ちます。独断と偏見に基づき、IT初心者・セキュリティ初心者・セキュリティエンジニアの3つの時期に分け、費用対効果の良い勉強法を紹介していきたいと思います。 セキュリティエンジニアとは 「セキュリティエンジニア」という言葉は範囲が広いですが、私が今回記載する内容は脆弱性診断やペネトレーションテストに寄った内容となっています。インシデント対応やアナリスト業務などは専門ではないので、あくまで診断系の人が書いているということをご認識おきください。 そもそもセキュリティエンジニアにどのような職種が含まれるかはラックさんが分かりやすい資料を出しているのでそちらをご覧ください(サイバーセキュリティ仕事ファイル 1、サイバーセキュリティ仕事ファイル 2)。 IT初心者時代 セキュリティを学ぶ以前に基礎となるITを学ぶ時代を考えます。 学校教育 学生の場

      • エンジニアのための自己管理入門 - Qiita

        はじめに 社内でTodo管理の勉強会を実施した際に作成した資料があったのですが、今回自分の中の考えをまとめるせっかくの機会だと思い、字面で書き起こすことにしました。 意外と世の中では語られることのなく、『あたりまえ』として扱われてしまう『自己管理』について自分が半年間運用し、週ごとにカイゼンを続けたどり着いた、現時点でのHowを多くの人に伝えられればなと思っています。 もちろん最適解がこの形とは言いませんし、自己管理は人の数分だけ最適解はあると思っています。「みんな正しい、ただし部分的に」ということを念頭に、楽しんで読んでいただければ幸いです。 タイトルを付けた理由としては、かなりシステマチックな内容になってしまっていると感じてしまったため、「運用レベルが高い」人物を想定した結果、このタイトルになりました。 概念篇 『自己管理』を行っていく上で、確実に「ここは飛ばしてはいけない」と思ったた

          エンジニアのための自己管理入門 - Qiita
        • 現代的システム開発概論

          2023年度リクルート エンジニアコース新人研修の講義資料です

            現代的システム開発概論
          • 近況報告:無職になりました - IT戦記

            みなさんお元気ですか?僕は少しだけ元気ではありません。じんわりとした夏の暑さを感じながらブログを書いています。 実は、数ヶ月前にスマートニュースという会社を退職しました。 しばらく無職 しばらくは就職せずに無職でいようかなと思っています。 すぐに再就職した方がいいんだろうな〜。とは思うのですが少し疲れたかも。 いい時代になったものだ 最近は AI の進化も素晴らしく、昔ソフトウェアで出来なかったことがどんどんできるようになってるなって感じます。 Rust とか、ちょうど欲しかった感じのプログラミング言語もあるし、 ChatGPT は完璧ではないけど何か新しいことを始めるときに素晴らしい洞察を与えてくれる。 時代は確実に良くなってる。そんな時代に「自分は働いていないくていいのか」と少し不安になるけれど、自由気ままにコードを書く、そんな時間が今あってのもいいのかなって思ってます。 オフトピック

              近況報告:無職になりました - IT戦記
            • 「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要

              インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏:ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC(株式会社エーピーコミュニケーションズ)さんが「カプセルト

                「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
              • 業務でAWSを利用する時に知っておくべきポイント10選 - Qiita

                2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro

                  業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
                • 数年間継続している「作業メモ」の話

                  メモを残す習慣 以前、@gorou_178さんが「1日1ファイル、「調べたこと」「やったこと」を日報として残す」という記事を公開していた。 この記事の中に以下のようなくだりがある。 そこでふと思い出したのが元同僚のメモの取り方。 毎日1ファイル作成して、そのファイルにその日にやったこと(事細かくやった作業、実行したコマンドなども)をメモしていた。メモは年単位で残っておりとても驚いたことを覚えている。 この、「元同僚」というのはきっと私のことである。 私はメモを取ることが結構と好きな方で、メモを残すことがわりと習慣化している。 例を挙げると、普段からこういったことをやっている。 Google Keepに「Podcastに出演してほしいゲスト候補」、「勉強会・カンファレンスの登壇履歴」、「来月購入予定の日用品・雑貨」、「自宅周辺の行ったことないラーメン屋」、「読みたい・気になったマンガ本」とい

                    数年間継続している「作業メモ」の話
                  • エンジニアが給料を12倍にする方法 - k0kubun's blog

                    はてブの人気エントリーに日本のエンジニア達は海外に出なければいけないという記事があった。 カナダ在住で経験年数4年のソフトウェアエンジニアで年収1600万円の方らしく、 日本より海外の方がソフトウェアエンジニアの給料が一般に高いので海外に行くべきという話が書かれている。 実際僕も居住地域による給与差を利用すべく渡米し、先月の記事 では新卒から数えて8年で年収が12倍になっていた話も紹介した。 一方、年収1600万円であれば海外に出なくても稼げると思っているので、 国内にいてもできそうなものも含め、ソフトウェアエンジニアとして給料を上げる上で過去に活用したハックを紹介していきたい。 昇給履歴 新卒入社 僕が新卒で入社した会社の当時の初年度給与は450万円だった (公開情報)。 大学の4年間はずっとアルバイトとしてソフトウェアエンジニアをやっていて、 3社を渡り歩いて時給は800〜1350円と

                      エンジニアが給料を12倍にする方法 - k0kubun's blog
                    • 新入社員の呪いの解き方

                      ウェビナー『CTOとVPoEが語る、採用とオンボーディング で失敗しないためのベストプラクティス』での発表資料です。 オンボーディングにおいて 注意すべき力学について共有しつつ、 チームとして工夫していることをご紹介しています。新入社員=中途入社の社員さんを"主に"想定しています。 【運営しているサービス情報】 - ITエンジニアの方向け - https://lapras.com - エンジニア採用したい企業の方向け - https://scout.lapras.com

                        新入社員の呪いの解き方
                      • データ分析のためのSQLを書けるようになるために

                        はじめに 本稿では分析用クエリをスラスラ書けるようになるまでの勉強方法や書き方のコツをまとめてみました。具体的には、自分がクエリを書けるようになるまでに利用した教材と、普段クエリを書く際に意識していることを言語化しています。 想定読者として、SQLをガンガン書く予定の新卒のデータアナリスト/データサイエンティストを想定しています。 勉強方法 基礎の基礎をサッと座学で勉強してから、実践教材で実際にクエリを書くのが望ましいです。 実務で使える分析クエリを書けるようになるためには、実務経験を積むのが一番良いですが、だからといって座学を御座なりにして良いというわけではありません。SQLに自信がない人は、一度基礎に立ち返って文法の理解度を確認した方が良いと思います。 書籍 SQL 第2版: ゼロからはじめるデータベース操作 前提として、SQLに関する書籍の多くがデータベース運用/構築に関する書籍がほ

                          データ分析のためのSQLを書けるようになるために
                        • 2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball

                          タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い(&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1)は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です(結論) スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ~変化を抱擁せよ

                            2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
                          • 大学で読んだ情報科学関連の教科書 - ジョイジョイジョイ

                            先日、博士(情報学)になりました。学部と大学院をあわせた 9 年間で読んだ情報科学関連の教科書・専門書を思い出を振り返りつつここにまとめます。私は授業はあまり聞かずに独学するタイプだったので、ここに挙げた書籍を通読すれば、大学に通わなくてもおおよそ情報学博士ほどの知識は身につくものと思われます。ただし、特に大学院で重要となる論文を読み書きすることについては本稿には含めておりません。それらについては論文読みの日課についてや論文の書き方などを参考にしてください。 joisino.hatenablog.com 凡例:(半端)とは、数章だけ読んだ場合か、最後まで読んだものの理解が浅く、今となっては薄ぼんやりとしか覚えていないことを指します。☆は特におすすめなことを表します。 学部一年 寺田 文行『線形代数 増訂版』 黒田 成俊『微分積分』 河野 敬雄『確率概論』 東京大学教養学部統計学教室『統計学

                              大学で読んだ情報科学関連の教科書 - ジョイジョイジョイ
                            • 【タスク管理術】Notionで全ての仕事を管理する方法を徹底解説

                              はじめに タスク管理はクリエイターの永遠の課題だと思います。 普段の案件に関するタスクはもちろんですが、案件とは関係ない事務作業やデータの整理、後で読みたい記事、試してみたい技術など、私たちには様々なタスクがあります。 膨大なタスクを管理する方法を日々模索し続け、ようやく自分の中で「これ!」というのが固まってきたので、私なりのNotionを用いたタスク管理方法を解説していこうと思います。 Notionとは 様々な情報やドキュメントを一元管理できるサービスです。公式サイトに書かれている通り、様々なドキュメント管理ツールをひとつに集約したのがNotionになります。 日々の業務は「案件に関するタスク」と「案件とは関係ないタスク」の2つに分けられます。 「案件に関するタスク」は期日や案件の詳細情報、自分の担当範囲などを分かりやすく管理することが重要です。「案件とは関係ないタスク」は業務改善や事務

                                【タスク管理術】Notionで全ての仕事を管理する方法を徹底解説
                              • アメリカでソフトウェアエンジニアの職を探した - pco2699’s blog

                                はじめに 前提 アメリカで働くためのビザ 業務経験 2023年のアメリカのテック業界の状況 具体的な就活のステップ ソフトウェアエンジニアのインタビューで求められることの抽象的な理解 レジュメ Job Descriptionから逆算してレジュメを作る 一枚におさめる 数字を用いてスケールとビジネスインパクトを示す なるべく隙間を埋める フォーマット添削ツールにかける レビューを受ける ネットワーキング・リファラル 応募する アメリカの就活はNumber Game 採用のトレンドを追う 時期を見計らう Linkedinで最新の求人を見つける方法 Promotedをすべて非表示にする "Most Recent"順にする 検索クエリを工夫する 設定をブックマークする 時間を決めて巡回する コーディングインタビュー対策 アルゴリズムの地図を脳内に作る 大学やCouseraでアルゴリズムの授業を取る

                                  アメリカでソフトウェアエンジニアの職を探した - pco2699’s blog
                                • 日本のエンジニア達は海外に出なければいけない|Kei

                                  自分は現在アメリカの医療系スタートアップ企業でソフトウェアエンジニアとして働いている。カナダに在住していて、年収は日本円にして約1600万円、エンジニアとしては現在4年働いている。 もしあなたが日本のエンジニアなら、これを読んだ時に心がざわついたと思う。日本にいると表面化しづらい、世界的エンジニアの給与格差を今目の当たりにしたのだから。しかし実際には、自分はほぼぴったりアメリカでのエンジニアの平均給料を貰っているに過ぎない。 日本でのエンジニアの扱い給料Economic Research InstituteをソースにしたCodeSubmitさんの各国のエンジニアの平均給料のリサーチによると、日本は$36,024でランキングの27ヶ国中18位、1位のアメリカ($110,140)とは$74,116、即ち2023年11月現在の日本円対アメリカドルのレートで1100万円ほどの開きがある。ちなみに日

                                    日本のエンジニア達は海外に出なければいけない|Kei
                                  • 複数の企業でデータエンジニアとして求められたスキル - yasuhisa's blog

                                    最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力

                                      複数の企業でデータエンジニアとして求められたスキル - yasuhisa's blog
                                    • マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark

                                      ストックマークの社内研修の公開版※資料です。 (※実際に研修で利用したものとは異なります)

                                        マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
                                      • 更新されたら真っ先に聴いているおすすめポッドキャスト - laiso

                                        ポッドキャストはリスナーの存在が見えづらいらしく聴いてるとアピールしないと更新停止してしまいがちなので定期的に感想を書いていく 聴く環境について ポッドキャストの探し方 BUSINESS WARS / ビジネスウォーズ News Connect あなたと経済をつなぐ5分間 #ニュースコネクト Off Topic // オフトピック fukabori.fm バンクーバーのえんじに屋 texta.fm プログラム雑談 Misreading Chat mozaic.fm kkeethのエンジニア雑談チャンネル 購読一覧 聴く環境について クライアントはGoogle Podcastを使っているんですけど終了してしまうし*1最近はSpotifyに誘導されがちなので、今後移行先をどうしようか迷っている そもそもGoogle Podcastの購読一覧ってどこから見るんだろうと疑問だったが、https:/

                                          更新されたら真っ先に聴いているおすすめポッドキャスト - laiso
                                        • クックパッドを退職しました - 昼メシ物語

                                          2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ

                                            クックパッドを退職しました - 昼メシ物語
                                          • 【特集】 知っ得!企業トップのAI活用法。日本マイクロソフト社長のCopilotの使い方がすごく勉強になる

                                              【特集】 知っ得!企業トップのAI活用法。日本マイクロソフト社長のCopilotの使い方がすごく勉強になる
                                            • PythonだけでWebアプリが作れるライブラリが増えている(2024.05) - Qiita

                                              ※本記事で言及しているReflexのdiscord内に日本語チャンネルをつくってもらいました。もし、興味をもった人がいたら参加してみてください。 1.PythonだけでWebアプリをつくるライブラリが増えている 最近(2024.05)、Python界隈ではPythonだけでWebアプリが作れるライブラリが増えています。詳しくは他の記事を参照してもらえればと思います。 以下の記事がとても参考になりました。ありがとうございます。 2.ライブラリの分類 こうしたライブラリも大きくわけて2つの種類があるように思います。 ①データ解析の結果を表示するダッシュボードライブラリ ②汎用的なWebアプリをつくるローコードライブラリ ①ダッシュボード系ライブラリ たとえば、上記の記事にも出てきますし、ネットでもかなり情報の多い、StreamlitやDashは項番1のダッシュボードライブラリに該当すると思いま

                                                PythonだけでWebアプリが作れるライブラリが増えている(2024.05) - Qiita
                                              • 2023年にブックマークしたページでよかったもの集めた - Really Saying Something

                                                2013年から「その年ごとにブックマークしたページでよかったもの集めた」と題して、1年分の「自分がブックマークしたページ」を振り返り、まとめています。正確には毎年ではなくて、2022年だけ抜けています。いろいろなことがあり抜けました。そしてあきらめて、2023年版を作りました。 完全に「私得」なまとめなのでカテゴライズなどは一切しておらず、主に自分のブックマークした順番となっています。基本的には、以下の基準で選出しています。 当年に作られたエントリーであること Wikipediaや当年に作られたことが明確でない役所のページなどは除外 ブックマークが多く集まっていてもリンク切れであるものは除外 Yahoo!ニュース(掲載終了)、サイトクローズなど 内容が「閲覧する際に1記事単位になっている(ページャーはOK)」になっていること 有料記事、課金しないと全部読めない記事などは除外 今年は入院した

                                                  2023年にブックマークしたページでよかったもの集めた - Really Saying Something
                                                • Macユーザーのぼくがリアルに使っているアプリ12選|やす

                                                  1日中ずっと仕事でMacを使っているぼくがほんとに使っているアプリを順不同で12個あげていこうと思う。 Google、Microsoft、など定番アプリは除外している。 1.AltTab 現在使用しているアプリを一覧表示して選択できるアプリ。 たくさんアプリを開いていて使いたいアプリが埋もれてしまったときとか、2つのアプリを行き来したいときに便利。 Windowsだと標準の機能みたいだ。 「開いているウインドウがないアプリを隠す」という設定にして格段に使いやすくなった 2.Alfred Macのすべての起点となるアプリ。 アプリの起動、ファイルやフォルダ、ウェブサイト、Google Driveの検索、離席時のスクリーンセーバー起動、計算機などできることは数しれず。 ぼくがよく使うのは、 ・Dropbox内のフォルダ検索 ・Google Drive内のファイル検索 ・計算機(地味だが使いやす

                                                    Macユーザーのぼくがリアルに使っているアプリ12選|やす
                                                  • プログラミングというより物事が出来る思考法~実践編|牛尾 剛

                                                    大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ

                                                      プログラミングというより物事が出来る思考法~実践編|牛尾 剛
                                                    • なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog

                                                      CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

                                                        なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog
                                                      • プログラミング初心者がゲーム感覚で楽しく学べる無料サービス16選|苦しんでプログラミングを学んだ柴犬(くるしば)

                                                        こんにちは。 苦しんでプログラミングを学んだ柴犬こと、「くるしば」と申します。 元々コンサルタントの仕事をしていましたが、独学でプログラミングを学習し、Webサービスを作って起業しました。 その後個人で開発したサービスを売却したり、また別のIT系の会社を創業、経営したりしています。 去年の8月から下記のTwitterにてプログラミング学習に関して発信し始め、ありがたいことに10000人以上の方々にフォローして頂きました。 プログラミング初心者に絶対覚えてほしい、ググる時の効率が10倍上がるコツ pic.twitter.com/hK1ZhNavwh — くるしば | 読めば10倍効率が上がるプログラミング学習の教科書 (@shiba_program) September 13, 2022 技術書、Webサービス、QiitaやzennのWeb記事など、最近は本当にプログラミングを学習できるコン

                                                          プログラミング初心者がゲーム感覚で楽しく学べる無料サービス16選|苦しんでプログラミングを学んだ柴犬(くるしば)
                                                        • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

                                                          最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから

                                                            こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
                                                          • システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』

                                                            例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるw」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場

                                                              システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
                                                            • OSSで世界と戦うために - ゆーすけべー日記

                                                              「日本人」を理由にしたくないし、「コードは全世界共通語」なのは分かっているけど、自分が日本人で日本語を母国語としていることはOSSにおいて不利になる。 この2年間のHonoの開発をしてきた経験で分かったことだ。 そこに目を瞑ってはいけないし、自覚することで世界と戦えるかもしれない。今回はそのことについて書こうと思う。 8k 現在、HonoのGitHubスター数は8,000を超えた。 これはとんでもない数字なんだけど、もっと伸びるべきで、早く1万を超えなくはいけない。 npmのダウンロード数は週間「46,000」とこれは相対的に低く、こちらも伸びるべきである。 数字が全てではないが、こうした数字は昨今のOSSにとって「一番の」指標であることは確かだ。 だから戦うことはこの数字を伸ばすことである。 なぜ「戦う」のか なんで「戦う」というおっかない言葉を使い、そして戦わなくてはいけないのか。 ま

                                                                OSSで世界と戦うために - ゆーすけべー日記
                                                              • 個人開発を7年以上続けて分かった技術選択のコツ

                                                                技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな

                                                                  個人開発を7年以上続けて分かった技術選択のコツ
                                                                • 30点で打席に立つ

                                                                  めもりーさんと語るFindy Engineer Lab オフ会@東京 LT https://findy.connpass.com/event/294069/

                                                                    30点で打席に立つ
                                                                  • 本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;

                                                                    最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理

                                                                      本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
                                                                    • 今さら聞けないログの基本と設計指針 - Qiita

                                                                      はじめに 皆さんのログに対する理解はどんなものでしょうか?仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は? ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査

                                                                        今さら聞けないログの基本と設計指針 - Qiita
                                                                      • 「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ

                                                                        先日 エンジニアType さんから取材『牛尾剛さん、『世界一流エンジニアの思考法』って本当に日本でも実行できますか?(仮)』を受けました。私は「日本で出来ないことは何一つありません」と回答しました。私が日本にいるときに実際に実施したアクションや、実際にやってみた事例などをご紹介しました。 それは、私が自信に満ち溢れた人物だからではなく、幼少のころから自己肯定感も低く、何をやっても上手くいかなかった自分を救ってくれたちいさな「マインドセット」があったおかげです。 「何をやっても駄目だった」ポンコツの自分を 救ってくれたマインドセット このマインドセットは『日本では一見難しそうな何かを実現すること』に対しても過去の人生でとても有効でした。同じような悩みを持つ人のために、エンジニアTypeさんの記事のフォローアップとしてこちらにも書いてみることにしました。それは小さなマインドセットのチェンジなの

                                                                          「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ
                                                                        • 元ひきこもり37歳業務未経験女性がバックエンドエンジニアとして地方で採用されるまで - Qiita

                                                                          実務未経験、独学でプログラミングを勉強し、応用情報技術者試験に合格、ポートフォリオとしてのWebアプリケーションを制作し、地方のIT企業に就職にしました。 34歳のころからプログラミングの勉強を始め、ITエンジニアとして就職することに憧れていましたが、まさか実現できるとは…と自分が一番驚いています。どんなことをしたのか、こちらの記事でまとめたいと思います。 結論 34歳(35歳目前)から初めてプログラミング学習を独学で開始 放送大学を卒業、基本情報技術者試験、応用情報技術者試験に合格 ポートフォリオを制作、応募先に提出 37歳で地方(東京以外)のIT企業(Web受託がメイン)に試用期間の3ヶ月間契約社員として働き、正社員に 提出したポートフォリオについてはこちらの記事で解説しています。 就職できたと思う要因 ポートフォリオを完成させ、GitHubでコードを公開、Qiitaで解説記事を書いた

                                                                            元ひきこもり37歳業務未経験女性がバックエンドエンジニアとして地方で採用されるまで - Qiita
                                                                          • エンジニアの心構え

                                                                            2023年度リクルート エンジニアコース新人研修の講義資料です

                                                                              エンジニアの心構え
                                                                            • MRJ計画失敗、技術者が「謙虚さに欠けていた」 元社長が激白 破綻の原因はたった1枚の書類

                                                                              愛知を拠点に三菱航空機が開発していた国産初のジェット旅客機、MRJ。ニッポンの航空産業の中核として量産化が期待されていましたが2023年2月、ついに計画の中止が発表されました。 夢の開発プロジェクトがなぜ頓挫したのか。三菱航空機の元社長の川井昭陽氏が、当時の胸中を明かしました。 【動画・元社長が激白】MRJ計画失敗、技術者が「謙虚さに欠けていた」破綻の原因はたった1枚の書類 三菱重工が国産初のジェット旅客機として開発を決めたのが「三菱リージョナルジェット(MRJ)」です。 100席以下の小型機ながら、部品点数は車の30倍にあたる約95万点。県営名古屋空港を開発拠点にした夢の国産ジェット旅客機の生産は、この地方に新たな基幹産業の誕生を期待させるものでした。 しかし度重なる設計変更で、プロジェクトは6度にわたって計画延期。2019年には名前から三菱の“M”の文字も消えました。そして2023年2

                                                                                MRJ計画失敗、技術者が「謙虚さに欠けていた」 元社長が激白 破綻の原因はたった1枚の書類
                                                                              • もうみんなプログラマーになれるよ|shi3z

                                                                                僕の20年来の親友にnpakaというプログラマーがいるんだけど、彼はもう超凄い。何でもすごい。何でも書けるし何でも早い。本を書くのもプログラムを書くのも、新しいわけわかんない説明書がバグだらけの環境に慣れるのも早い。 んで、これまではちょっとしたことも難しいことも全部npaka(布留川君)に頼んでたんだけど、最近二人とも独立したからつまんないこと頼むのは悪いなと思って「あれはできるんだっけ」くらいのことは自分で何とかしようかなと思った。 それでChatGPTに「Swiftで⚪︎⚪︎やるにはどうすんの?」と聞いたら、Swiftについてほとんど何も勉強してないのに作りたいものが何となくすぐにできてきちゃって、でもまあやっぱりChatGPTだと知識が古いので詰まったらネットで検索すると、だいたい結局npaka(布留川君)のページが出てきてやはり信頼と実績の大先生(仲間内ではそう呼ばれている)です

                                                                                  もうみんなプログラマーになれるよ|shi3z
                                                                                • 「できない理由」を並べる人々は、とりあえず無視して構わない。

                                                                                  コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか?」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか?」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には?クレームが来る、という事でしょうか?」 営業「まあ、そうかもしれません。」 企画「か

                                                                                    「できない理由」を並べる人々は、とりあえず無視して構わない。