並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 131件

新着順 人気順

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

  • Google本社の方に聞いたいい開発者になるための習慣 - Qiita

    はじめに 以前自分の大学でGoogleの本社で働いている韓国の方の話を聞けるイベントがあったのでその内容をメモとして共有しようと思います。(すべて韓国語で聞いたので多少間違っている内容があったり、変な日本語になってるかもです) 講義してくれた人について 講義してくれた人はGoogleの本社で働いており、今までに韓国のLGやamazonなどでも開発経験のある韓国の方でした(名前は伏せます)。当時はYoutubeのショート動画関連の開発に関わっていたとおっしゃっていました。 ソフトウェアエンジニアとは プログラマー = コードを書く人 ソフトウェアエンジニア = コードを書く仕事を含めた全ての開発業務(データベース, アーキテクチャ, teckleadなど) Googleではソフトウェアエンジニアリングの知識がある人がデータサイエンティストやプロジェクトマネージャーになる。 googleが強調

      Google本社の方に聞いたいい開発者になるための習慣 - Qiita
    • 負荷テスト on AWS のすすめ (AWS Summit Japan 2024 - Ministage session)

      AWS Summit Japan 2024 にて、セキュリティ & One-AWS Zone ミニステージでの登壇資料です。 「負荷テストは、AWS を使ってどう楽になるか?」についてお話しました。スライド内のリンク類はコチラ→https://mabuchs.hatenablog.com/entry/…

        負荷テスト on AWS のすすめ (AWS Summit Japan 2024 - Ministage session)
      • KADOKAWAのハッキングの話が雑すぎるので書く

        まあプロじゃない人たちがわからないのは当たり前なんだけど エンジニアの能力がとかクレジットカードがとかは基本関係ないという話 (関係なくてもアカウント持ってたらパスワードはすぐ変えるの推奨) 会社のシステムはどうなってるかこれはシステムがある会社で働いたことある人はわかるんじゃないかと思うけど 会社のシステムというのはいろんなものがあってそれぞれ全然別 メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるとは限らないというか多分されない さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの(バックオフィス)でスキルが全然違うのでやっているチームは普通違うし、物理的にサーバーがある場所も違うことが多い そのうえクレジットカードや最近ではシステムにアクセス

          KADOKAWAのハッキングの話が雑すぎるので書く
        • 本屋で技術書みてたら人生詰みかけた - Qiita

          はじめに こんにちは。WatanabeJin(@Sicut_study)です。 今回は以前Twitterでも話題にした「成長しないエンジニアほど本屋に行く」という理由について解説したいと思います。 成長が遅いエンジニアほど本屋に行く話 最近、エンジニアとして成長が遅い人たちに共通する特徴を発見しました。それは「技術書コーナーを好む」ということです。これに気づいたのは、自分自身がエンジニア1年目で、同じ行動をしていたからです。… pic.twitter.com/p35NaS6T4a — Watanabe Jin (@Sicut_study) January 7, 2024 もしあなたが説明することに当てはまるところがあれば、それをきづけたのは大きな分岐点だと思います。ここから自分の学習方法などを見直してみてください。 成長が遅いエンジニアほど本屋に行く 私はプログラミングコーチングJISOU

            本屋で技術書みてたら人生詰みかけた - Qiita
          • 開発組織全員が自ら学んで成長していく組織づくり

            「開発組織全員が自ら学んで成長していく組織づくり」という内容で、Senior Engineering Managerの上原が、Lancers Agent様との2024/06/19のイベント(https://peatix.com/event/3959065/view )で発表させて頂いた資料となります。 …

              開発組織全員が自ら学んで成長していく組織づくり
            • 「本を読んでも身に付かない」はどう解消する? 七つの“読書術”を岩瀬義昌が伝授 - エンジニアtype | 転職type

              NEW! 2024.07.16 スキル 岩瀬義昌 書店を覗いたりSNSを眺めたりすると、目に飛び込んでくる技術書の数々。周りのエンジニアたちの「読了」ポストに刺激されて、読書に勤しんでいる人もいるだろう。 「一生勉強」と言われるエンジニアにとって、技術書は取り入れやすいインプット手法の一つ。しかし「頑張って読んでるのに、いまいち身になっている気がしない」「本の内容が頭に入ってこない」という事象に悩まされてはいないだろうかせっかく読んだ本の内容をしっかりと身に付けるためにはどうすればいいのかーー。 そんな疑問に「記憶力の問題じゃなくて、本の読み方に工夫が必要」と答えるのが、技術書の翻訳に数多く携わり、読書の達人として知られるiwashiさんこと岩瀬義昌さんだ。 本を読む「工夫」とは一体何か。岩瀬さんに聞いた。 NTTコミュニケーションズ株式会社 『Generative AI プロジェクト』リ

                「本を読んでも身に付かない」はどう解消する? 七つの“読書術”を岩瀬義昌が伝授 - エンジニアtype | 転職type
              • ソフトウェアエンジニアになってから: 昇進と異動(と最高評価)|Hiro Tsujino

                ありがたいことに、いわゆる文系・ビジネス職からベイエリアでソフトウェアエンジニアになった前回の記事は多くの方に読んでいただきました。改めてお礼を申し上げます。とはいえ、当然ですが、ソフトウェアエンジニア(以下、SWE)になって終わりではなく、SWE になってからもそれ以上に大切であり、実際に SWE 転向後、どのような経験をしたのか、現実的な点も含めて、この記事では書いてみようと思います。 結論から言うと、初めは知識や経験の浅さから苦労しましたが、最終的には社内査定でも最高評価をいただき、なんとか昇進、異動する運びとなりました。 SWE になってみてまず、ポジティブな面から、状況整理も兼ねてお話しすると、自分は多くの方に使っていただいている製品・機能の Android アプリ(≠ Android OS)及び、そのバックエンドを担当することになりました(つまり、Android アプリがメイン

                  ソフトウェアエンジニアになってから: 昇進と異動(と最高評価)|Hiro Tsujino
                • 障害対応を楽しむ7つのコツ

                  フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy

                    障害対応を楽しむ7つのコツ
                  • PdM から見た「スーパーエンジニア」の思考と行動 / Thoughts and Actions of Super Engineers as Seen from PdM

                    「PHPカンファレンス福岡2024」の登壇資料です。 https://phpcon.fukuoka.jp/2024/ # スライド掲載資料 https://speakerdeck.com/kassy1127/qiang-i-enziniatodong-kuzhong-de-xin-zu-1ni…

                      PdM から見た「スーパーエンジニア」の思考と行動 / Thoughts and Actions of Super Engineers as Seen from PdM
                    • エンジニアの成長における過去と現代の違い | 外道父の匠

                      自身の過去の成長過程と現在の環境を思い浮かべたときに、得やすいもの得づらいものの違いを強く感じ、良好な成長のために一考してみた次第です。 といっても既にある Tweet のセルフまとめに、思い出と昔話なポエムを追加したようなチラ裏回です。 時代の変遷によるステータス変化 要約すると、現代は技術力の向上に必要な環境と既定路線があって向上速度が早いのに対し、昔(2010年以前とか)は頭を悩ませまくって乗り越えるべき壁が大量にあったおかげで解決力は相当鍛えられたよねってところ。 個人的には誰であれ、今!自分が!解決しないと!詰んでしまう!! てかもう詰んでるだろコレ!!!! って状況でひたすら悩んでから、寝て起きたら解決したよぉ!みたいのを体験してほしいし、一度は死の淵まで行ってこいって思っている — 外道父 | Noko (@GedowFather) July 17, 2024 これについて、

                        エンジニアの成長における過去と現代の違い | 外道父の匠
                      • エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル

                        スライド概要 スクラムフェス大阪2024の登壇資料です。 スクラムマスターとして、あるチームでエンジニアとQAの間に見えない壁があり、それが崩れるまでを眺めた。しかし、チームは時間をかけて壁を崩すことができ、その結果、よりユーザーと価値に向き合えるようになった。チームの状況は、初めてアジャイル開発やスクラムに触れるメンバーが多くいたよくあるプロダクトチームであった。スクラムマスターは、なぜ壁崩せたのか、なぜ見ていられたのかを語る。この物語は、あなたのチームでも起きうることであり、アジャイル開発に取り組む上での示唆になるはずです。

                          エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka | ドクセル
                        • IT エンジニアが対人関係でしくじらないために - Qiita

                          しくじりエンジニア!私みたいになるな! - Qiita 人間であれば誰しも「しくじったこと」が一度はあると思います。 あなたがエンジニアとして「しくじったこと」で思い浮かぶものは、どんな内容でしょう? を思い浮かべてのポエムです...。もちろん具体的な誰かの顔をイメージする記事ではないですが、社会人も 20 年そこそこになると「余計なこといっちゃったなー」とか、「うわあああ! (頭の中で後悔)」とか、後になって胸にチクっとくる場面を、(割と)(これでも)(幾度となく) 経験しています。 Unsplash 本番サーバー60台のホスト名を全部 cat にしてしまった話 #Linux - Qiita とか、WHERE 句を付けずに DELETE 文を流すとかも記憶のどっかにあるけど、言うて対システムの失敗は「(せいぜい数週間) 頑張れば」どうにかリカバリできることの方が多いのではと感じます。 一

                            IT エンジニアが対人関係でしくじらないために - Qiita
                          • 昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していた話→「WinMergeを知らなかったのだろうか?」「ケースバイケースかな」

                            あや@ほわほわ @aya_howa 昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していたのです。その後PMに「センスがない!」と叱られていましたが、根気があってマメな人なんだろうなぁ…と面倒臭がり&自分の目を全然信用していない私は思ったものでした。 2024-06-25 08:43:11

                              昔、プロジェクトリーダーさんが、とある数百件のデータに差異があるか確認するのに、ウィンドウを左右に並べて目で確認していた話→「WinMergeを知らなかったのだろうか?」「ケースバイケースかな」
                            • Webエンジニアの学習ロードマップが知れるサイト - Qiita

                              エンジニアのみなさま、日々の学習本当にお疲れ様です! また本記事まで足を運んでいただき本当に感謝です。 約2分程度で読めるので最後まで読んでもらえると幸いです。 はじめに 「Webエンジニアを目指したいが、何から手をつけていいか分からない」 「いろんな人が学習ロードマップの情報提供をしているが、どれに手をつけるか判断に迷う」 こんな悩みを抱えている方の一助になれば幸いです...! 結論 こちらのサイトになります。 自分が学習したい分野を選択すると、その分野のロードマップが書かれています。 最近では「言語専用」のロードマップも書かれているため、かなり充実したサイトになってきた印象です。 それでは、試しに「Backend」のロードマップを見てみましょう。 学習ロードマップ|Backend こんな感じです。 黄色塗りのフォームが「仕組み」や「概念」が書かれたもので必ずチェックしたい内容になります

                                Webエンジニアの学習ロードマップが知れるサイト - Qiita
                              • 初心者がおさえておきたいAWS CDKのベストプラクティス 2024

                                「AWS CDKに興味を持ったけれど、なかなかコードを書き始められない」と悩んでいませんか?CDKは簡単に始めることができますが、メンテナンスしやすく、壊れにくいコードを書くためには覚えておきたいプラクティスがあります。しかし、すべてのエンジニアがインフラ構築やプログラミングに精通しているわけではなく、…

                                  初心者がおさえておきたいAWS CDKのベストプラクティス 2024
                                • エンジニアが居着く会社

                                  増田、40代男性、現在非上場だけど大手企業でエンジニアやってる。 何回か転職してたり他社との話で狭い世界だけどエンジニアが居着く会社の条件が自分なりに固まった 競プロが居ない(外に出さなきゃ影響無し)とにかく見下す人多い。あと努力教で効率厨。フリーランスや部署の奥地で最低限の人間とのみ触れ合わせるようにすれば良い。 変に普通のエンジニアと絡ませるとフルボッコにして数名病む。 1人だけにしてお任せとか言わない(しない)初回だけ打合せに一緒に出て以降は自走させる人。管理職に多め。ペアプロとか関係なく2人以上のチームでの心理的安心は大きい。成果も失敗も割ろう 通知表査定しないこれは会社レベルだが、いつでも成果出せるエンジニアなんて僅かなのに3を中心に良い悪いを評価するのは無慈悲。当たり前のように下は上は結果出してないくせにと思う。上のショボい成果を時勢のせいにしたら末期 (スタートアップやベンチ

                                    エンジニアが居着く会社
                                  • 開発生産性指標を向上させるためにやってはいけないアンチパターン - Findy Tech Blog

                                    こんにちは!ファインディでFindy Team+開発チームのEMをしている浜田です。 昨今、開発生産性を高めるための取り組みを行っている組織が増えてきていると感じています。 開発生産性を向上させるためには、まずは定量的に可視化することが重要です。 可視化することで現状を把握して、開発組織の伸びしろを発見したり、課題を明らかにし、改善活動に取り組みやすくなります。 一方、定量的な指標に焦点を当てすぎてしまい本質的ではない対応をしてしまい、指標は向上したものの実際の生産性は向上していなかったり、むしろ悪化してしまうこともあります。 この記事では、開発生産性指標を向上させるためにやってはいけないアンチパターンについて紹介します。 デプロイ頻度を向上させるために、デプロイプロセスは変更せずに実施回数を増やした デプロイ頻度はDORAが提唱するDevOpsの4つの指標(Four Keys)の1つであ

                                      開発生産性指標を向上させるためにやってはいけないアンチパターン - Findy Tech Blog
                                    • ランサムウェアの侵入経路は今はVPN機器とかRDPの脆弱性だった。「怪しいメールの添付ファイル開かなきゃ大丈夫」は時代遅れなのか?→有識者の声が続々

                                      ういにゃん|フリーランスUnityエンジニアDJ Youtuber @ui_nyan 2008年よりツイッター活動を開始。東京を拠点に活動を続け、秋葉原、渋谷、新宿の多数のパーティーに出没している。その幅広いジャンルを吸収したクロスオーバーなプレイスタイルは、国内海外各地の業界人や多数のクラウドから根強い人気を誇る。今、日本で最も注目される2次元アイコンの一人である。icon:@tougehiro uinyan.com ういにゃん|フリーランスUnityエンジニアDJ Youtuber @ui_nyan ランサムウェアの侵入経路、いまはほとんどがVPN機器とかRDPの脆弱性なのね... 「怪しいメールの添付ファイル開かなきゃ大丈夫」は時代遅れなのか.... pic.twitter.com/ulYojHuWdG 2024-06-14 15:44:12

                                        ランサムウェアの侵入経路は今はVPN機器とかRDPの脆弱性だった。「怪しいメールの添付ファイル開かなきゃ大丈夫」は時代遅れなのか?→有識者の声が続々
                                      • 食べログの大規模販売管理システムを財務会計SaaSシステムに置き換えた話 - Tabelog Tech Blog

                                        目次 目次 はじめに 1章 課題の認識とZuora導入の決断まで 販売管理システムの課題 何を最初にやるべきか 実情を知る 理想像を固める 何を作り、何を作らないか どのSaaSを使うか 2章 Zuora導入設計 Zuoraプロジェクトチーム体制 Zuoraを知ろう! Zuoraプロジェクトにおいて何を開発するのか Zuoraの管理画面を使うか、それとも内製で作るか 新設機能のモック作成 食べログとのマッピング 3章 Zuora移行 データ移行 データ検証 突合バッチによる検証 データプールの副産物 最終的なシステム構成 データ切り替え 4章 Zuora運用 財務突合 Zuoraへの切り替え Zuoraでの運用開始 5章 結論 最後に はじめに こんにちは! 食べログ開発本部飲食店システム開発部でマネージャーをしている新井です。 2018年に食べログに入社し現在は販売管理チームに所属してお

                                          食べログの大規模販売管理システムを財務会計SaaSシステムに置き換えた話 - Tabelog Tech Blog
                                        • 身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools

                                          公開日 2024/06/18更新日 2024/06/18身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー!」やD2C型SaaS

                                            身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
                                          • わざとシステムを攻撃させて攻撃手法を観測する「ハニーポット」を30日間設置した結果をセキュリティエンジニアが公開

                                            遠隔でシステムを操作するツールである「SSH」への攻撃をわざと行わせて行動を観察する「ハニーポット」を30日間にわたって設置した結果をセキュリティエンジニアのソフィアン・ハムラウイ氏が公開しています。 What You Get After Running an SSH Honeypot for 30 Days https://blog.sofiane.cc/ssh_honeypot/ ハムラウイ氏はカーネルが「6.8.0-31-generic」でOSが「Ubuntu 24.04 LTS x86_64」のマシンを用意し、ハニーポットとして使用しました。 30日に行われたログイン試行は合計1万1599回で、1日あたり平均386回ログインが試されている事がわかります。 ログインを試す際に使用されたユーザー名のランキングには「root」や「admin」「ubuntu」「support」など、標準で

                                              わざとシステムを攻撃させて攻撃手法を観測する「ハニーポット」を30日間設置した結果をセキュリティエンジニアが公開
                                            • 「開発生産性の教科書」という本を執筆しました - Findy Tech Blog

                                              こんにちは!ファインディ CTOの佐藤(@ma3tk)です。 表題の通り、約1年半ほどの期間をかけて「エンジニア組織を強くする 開発生産性の教科書 ~事例から学ぶ、生産性向上への取り組み方~」(以降、開発生産性の教科書)という本を執筆しました。 本日(2024年7月11日)発売となりましたので、改めて「開発生産性」に対する思いをお伝えしたり、本の内容の一部をご紹介したいと思います。 「開発生産性の教科書」のご紹介 エンジニア組織を強くする 開発生産性の教科書 本の概要は次のとおりです。 項目 詳細 タイトル エンジニア組織を強くする 開発生産性の教科書 ~事例から学ぶ、生産性向上への取り組み方~ 著者 佐藤 将高、Findy Inc. 発行 技術評論社 定価 2,860円(税込) 発売日 2024年7月11日 ISBN 978-4297142490 購入 Amazon / 楽天ブックス 全

                                                「開発生産性の教科書」という本を執筆しました - Findy Tech Blog
                                              • 技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編)

                                                技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編) ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA(命名的問題)より、グループB(構造的問題)の方が正答率が大きいということ。一方でグループA(命名的問題)よりグループB(構造的問題)の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏

                                                  技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編)
                                                • 価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization

                                                  024年6月28日に開催された 開発生産性Conference 2024 の講演資料です。 講演詳細についてはこちらをご覧ください。 https://dev-productivity-con.findy-code.io/2024

                                                    価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization
                                                  • エンジニアのための一生こすれるSEO講座 - Qiita

                                                    エンジニアのみなさま、SEOやってますか? 恐らくふわっと認識してはいるものの、がっつりやってます! という方はあまりいないんじゃないでしょうか。 個人的な感覚ですが、SEOとエンジニアリングとで重なる点は多いながら、再現性の面や計測にかかる時間の面でどうしても敬遠されがちな印象があります。 さらに、そのアルゴリズムはGoogle様による全貌の明かされないブラックボックス。 もはや何をしていれば「やっている」のかさえ不確かです。 とはいえ、何かを世に出せば少しでも見られたいのはマーケターもエンジニアも同じはず。 以下では、トリッキーな要素は極力除外し、パンダやペンギンもさておき、長期的に陳腐化せず、限りなく減点されないためのSEOについてご紹介します。 SEOとは SEOとは「Search Engine Optimization(検索エンジン最適化)」の頭文字をとったもの。 このあたりはさ

                                                      エンジニアのための一生こすれるSEO講座 - Qiita
                                                    • はてな匿名ダイアリー「競プロ出身者の使えなさは異常」に対する反応まとめ

                                                      リンク はてな匿名ダイアリー 競プロ出身者の使えなさは異常 anond:20240624084844を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。うちはメガベンチャーで内製アプリ… 599 users 13 AI要約 競技プログラミング出身者の問題点について、以下のようにまとめられます。 1. 学生時代の競技プログラミングの実績を過剰にアピールする傾向がある。実務では学生時代の実績よりも、与えられたタスクを超える成果を出すことが重要。 メンテナンス性の低いコードを書く傾向がある。処理の効率性ばかりを重視し、可読性の高いコードを書くことができない。指摘しても聞く耳を持たない。 コミュニケーションに問題があり、他のメンバーを萎縮させることがある。的外れなコードレビューをしたり、関係ないリポジトリにPRを投げたりするなど、チームの空気を悪くする行動が見ら

                                                        はてな匿名ダイアリー「競プロ出身者の使えなさは異常」に対する反応まとめ
                                                      • これを知らなければ、C++プログラマを名乗れない。ITエンジニアも驚いた「C言語」の配列の仕組み→「初めて知った」「配列へのアクセスの書き方が糖衣構文」

                                                        二項しいぷ @BinomialSheep C++の「す、すげーー!!そんなことすなーっ!!!!!!」シリーズ 『プログラミング言語C++ 第4版/ストラウストラップ』 pic.twitter.com/KjiDaXe0tj x.com/winter_kyopro/… 2024-06-21 23:42:32

                                                          これを知らなければ、C++プログラマを名乗れない。ITエンジニアも驚いた「C言語」の配列の仕組み→「初めて知った」「配列へのアクセスの書き方が糖衣構文」
                                                        • 意識低い系エンジニアは被害者? 人材不足のIT業界でさえ「気軽に退職したら次はない」 - エンジニアtype | 転職type

                                                          〝流しのEM〟として、複数企業の採用・組織・制度づくりに関わる久松 剛さんが、エンジニアの採用やキャリア、働き方に関するHOTなトピックスについて、独自の考察をもとに解説。仕事観やキャリア観のアップデートにつながるヒントをお届けしていきます! この春、話題になった「退職代行サービス」。IT業界でも利用した人・された人は少なくないだろう。やむにやまれぬ事情で利用する人の陰に隠れて、すっかり辞めグセをこじらせてしまった人もいるかもしれない。 社内での出世はおろかエンジニアとしての成長意欲にも乏しく、居心地が悪くなったら転職を繰り返す……そんな「意識低い系エンジニア」に対し警鐘を鳴らすのが久松剛さんだ。彼らにどんな末路が待っているのか聞いてみた。 博士(慶應SFC、IT) 合同会社エンジニアリングマネージメント社長 久松 剛さん(@makaibito) 2000年より慶應義塾大学村井純教授に師事

                                                            意識低い系エンジニアは被害者? 人材不足のIT業界でさえ「気軽に退職したら次はない」 - エンジニアtype | 転職type
                                                          • SSHハニーポットに対する不正アクセスの最新動向 - Qiita

                                                            エンジニア学生団体IDEAで代表を務めているshuと申します。去年の12月ごろに設立し、最近設立1年を迎えた団体なのですが、おかげさまで150人以上の大所帯となっております。LT会やハッカソンなどを企画・運営しており、優秀な学生がのびのびと楽しんでおります。興味があればぜひご参加ください。 ハニーポットとは ハニーポットは、攻撃者がシステムに侵入しようとする際に、その攻撃を検知、記録します。 中でも今回取り上げるハニーポットはSSHハニーポットというもので、攻撃者がサーバーに対してssh接続を試みるシチュエーションを想定していただければと思います。 Cowrieハニーポット SSHハニーポットとして有名なものはいくつかあるのですが、Cowrieというものが一番有名です。Kippoという有名なハニーポットの改良版なのでこちらを使いましょう。 環境 今回はAWS EC2上にハニーポットを構築し

                                                              SSHハニーポットに対する不正アクセスの最新動向 - Qiita
                                                            • Webエンジニアが「LANケーブル抜き差ししたのにセッション切れてない!」って驚いてて泣きそうになった事がある話→人によって「セッション」の認識が違う

                                                              えび@プログラマー @ebiebi_pg むかーーし、Webエンジニアが 「LANケーブル抜き差ししたのにセッション切れてない!」 って驚いてて泣きそうになった事がある 2024-06-30 13:01:41

                                                                Webエンジニアが「LANケーブル抜き差ししたのにセッション切れてない!」って驚いてて泣きそうになった事がある話→人によって「セッション」の認識が違う
                                                              • 日本のITサービスのダメなところ

                                                                いわゆる日本でトップクラスのエンジニアみたいなところまで上り詰めると、みんなエンジニアやめて投資ビジネスにいっちゃうから なんも開発しなくなるから 高学歴の若手を束ねて自分の過去の実績看板にして「AI開発してます」っていうとバンバン投資して貰えるから もはやそれでビジネスになってんのよ ちなみにこの開発が失敗しても賠償金とかはないよ、ITベンチャーに投資して儲からないのは当然っていう契約だからさ、いくつか投資して一つでも大成功したらお釣りが来るからさ だからその「ITベンチャー」ボコボコ作ってマンション投資みたいなことをして稼ぐようになっちゃって、準トップぐらいのエンジニアは開発しなくなるからさ 日本のITサービスダメなんよね 元〇〇(どっかの大企業)エンジニアです、今は退職してベンチャー支援してますって自己紹介するエンジニア見たことない?あれはそういうことよ。

                                                                  日本のITサービスのダメなところ
                                                                • 日本CTO協会 | エンジニアが選ぶ「開発者体験が良い」イメージのある企業「Developer eXperience AWARD 2024」ランキング上位30を発表  |一般社団法人 日本CTO協会

                                                                  「テクノロジーによる自己変革を、日本社会のあたりまえに」というミッションを掲げ、世界最高水準の技術者育成を図ることにより、日本経済の発展に資することを目的としています。

                                                                    日本CTO協会 | エンジニアが選ぶ「開発者体験が良い」イメージのある企業「Developer eXperience AWARD 2024」ランキング上位30を発表  |一般社団法人 日本CTO協会
                                                                  • Googleが行なった「最高のチームをつくる」調査の意外な結果。メンバーは重要ではなかった | ライフハッカー・ジャパン

                                                                    『アメトーーク!』家電芸人が絶賛したサーキュライトが #Amazonプライムデー に登場! スペパ抜群で、簡単にスマートホーム化

                                                                      Googleが行なった「最高のチームをつくる」調査の意外な結果。メンバーは重要ではなかった | ライフハッカー・ジャパン
                                                                    • 「自分はわかるからOK」というオレオレ表記が開発を遅らせ、プロダクトの評価まで下げてしまう

                                                                      CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

                                                                        「自分はわかるからOK」というオレオレ表記が開発を遅らせ、プロダクトの評価まで下げてしまう
                                                                      • 後輩に提案されたスクラムにうまく適応できなかった私が開発チームのアジャイルを先導できるようになるまでに考え実践したこと - Agile Journey

                                                                        アジャイルに興味を持った1人あるいは数人から始めることは、アジャイルの導入においてよくあるストーリーです。とはいえ昨今では、例えばスクラムを導入する開発チームも増えているでしょうし、ほかのメンバーが主導した取り組みとしてアジャイルを受け入れる方も多いでしょう。そんな経緯でスクラムに触れ、既存の開発プロセスとの違いに戸惑い、むしろ積極的にアジャイルを学ぶことで克服した過程を、岸田篤樹(パウリ)さんに寄稿いただきました。 Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM(エンジニアリングマネージャー)・スクラムマスター・技術広報をしているパウリ(@pauli_agile)です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。 その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属さ

                                                                          後輩に提案されたスクラムにうまく適応できなかった私が開発チームのアジャイルを先導できるようになるまでに考え実践したこと - Agile Journey
                                                                        • ITエンジニア、何かを登録するという意味で「regist」という変数を使いがちだけど、そもそも「regist」には登録するという意味は無い話

                                                                          かわさき@Flutterで個人開発💻 @kwsk_create 本業PHPer。Laravel、CakeでWebアプリ、Flutterでモバイルアプリを開発中の都内在住4年目SE💻。国内旅行好き✈️ marshmallow-qa.com/78pfxt4rgxdjsq… かわさき@Flutterで個人開発💻 @kwsk_create ITエンジニア、何かを登録するという意味で「regist」という変数を使いがちだけど、そもそもregistには登録するという意味は無いんだよな。 2024-06-25 18:02:29

                                                                            ITエンジニア、何かを登録するという意味で「regist」という変数を使いがちだけど、そもそも「regist」には登録するという意味は無い話
                                                                          • ITシステムの可用性と損失を考える | 外道父の匠

                                                                            数値上はこうなるものの、意図的な短期的メンテナンスや、意図しない障害でも1回あたりの期間が短ければ、その期間に積まれるはずだった売上は、その復帰後に売り上がる場合も多いでしょう。その辺りは、ユーザーの信頼を損なわない方法や運用を心がけることで、十分に埋められる可能性を含む性質です。 しかしこれが、あまりに高頻度であったり長期間になると、その復帰後に停止期間分を含めた売り上げにならず、そのまま機会損失となる可能性が高まります。いわゆるユーザー離れというやつです。その損失だけで済めばまだマシで、普通に考えればその後に想定していた売上も減少し続け、元に戻すには相応の時間と労力を伴うでしょうから、数値以上の痛手となるはずです。 こう考えていくと、運用関係者が健全であれば、無理に100%の可用性を目指さず少なくとも合計99%以上となる停止猶予を持たせた運用とし、数日を跨ぐような連続した長期間の停止だ

                                                                              ITシステムの可用性と損失を考える | 外道父の匠
                                                                            • みんなが楽しめる、技術系ポッドキャスト最高峰クオリティ番組「エンジニアの楽園 vim-jpラジオ」

                                                                              2024年7月8日月曜12時、ポッドキャストラジオ番組「エンジニアの楽園vim-jpラジオ」がAuDee(TOKYO FM)公式番組として配信開始されました。 ほかにも以下のプラットフォームから配信されていて、毎週月曜更新となっています。 Apple Podcast Spotify Amazon Music まだお聞きになっていない方は、冒頭から圧倒的なクオリティを感じられますので、騙されたと思ってぜひ一度だけでもお聞きになってみてください。 今回は、こちらのラジオ番組を作った経緯や、どのようにして作ったのかを記録しておきます。 構想5年、実働2ヶ月半で配信開始 # きっかけは、vim-jpでつぶやいたこちらの一言でした。 何気なくつぶやいた「そういえば、vim-jp ラジオ立ち上げたい」という、この発言をきっかけにして、パーソナリティとしてありすえさんが手を上げてくださり、ほかにもたくさ

                                                                                みんなが楽しめる、技術系ポッドキャスト最高峰クオリティ番組「エンジニアの楽園 vim-jpラジオ」
                                                                              • IT系上場企業の平均年収を業種別にみてみた 2024年版[後編] ~ パッケージソフトウェア系、SI/システム開発系、クラウド/キャリア系企業

                                                                                IT系上場企業の平均年収を業種別にみてみた 2024年版[後編] ~ パッケージソフトウェア系、SI/システム開発系、クラウド/キャリア系企業 IT系企業で平均年収が高いのは、勢いのあるネットベンチャー系企業なのか、それとも伝統的なSIerなのでしょうか。毎年恒例の記事を今年も公開します。 上場企業は毎年「有価証券報告書」の発行を義務づけられており、そこには従業員の人数や平均年齢、平均年収などが掲載されています。この記事では、これら公開情報を基に、Publickeyが独自の判断で主な企業をピックアップして業種を分類。平均年収が高い順に並べてみたものです。 ただし、持ち株会社など現場の社員の給与を反映していないと思われる企業は基本的にこの調査からは外してあります(例えばコナミホールディングスなど)。日本で上場していない企業(例えば日本マイクロソフトやGoogle日本法人など)も当然ながら含ま

                                                                                  IT系上場企業の平均年収を業種別にみてみた 2024年版[後編] ~ パッケージソフトウェア系、SI/システム開発系、クラウド/キャリア系企業
                                                                                • PdM/EMが気づくべき「技術負債」の異変

                                                                                  技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。(特に、1.と3.) 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般

                                                                                    PdM/EMが気づくべき「技術負債」の異変