プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか?」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
🐳この記事は「ログラスサマーアドベントカレンダー2023」の10日目の記事です。明日はポーカー海外大会優勝という偉業を成し遂げたことがある、CSの比留間さんの記事です! みなさんこんにちは。 ログラスでVP of Engineeringとしてエンジニア組織全体のマネジメントをしております、いとひろです。 本記事は主にソフトウェアエンジニアの皆さんに向けて書いております。 最近「ログラス」という会社名を、よく見かけるようになったと感じる方もいらっしゃるかもしれません。よく見かけるのでなんだか勢いがある会社だと、なんとなく感じている方もいらっしゃるでしょうか でも、「何がスゴいのかはよくわからない」そう思っていませんか?そもそもログラスを聞いたことないという方もいらっしゃるかと思います。 そんな方たちに向けて、ログラスという会社がソフトウェアエンジニアにとってどんな魅力を備えているのか、何が
ネットがあるでしょ? わたしもそう思っていた。 ITスキルに限らず、新しい技術や分野を学ぶとき、最初にすることは検索だ。ネットで紹介されている記事やノウハウを読むことで、どんなものか把握できる。無料で最新の情報が手軽に手に入る。お金をかけずに学習できるメリットは大きい。 一方で、ネットで検索するためには適切なキーワードを入れる必要がある。 知りたいことがピンポイントで言語化できるなら、かなり便利だろう。だが、そもそもどんな用語を入れたらよいのか、その言葉すら分からない段階では、ネットを使いこなすのは難しい。自分に何が足りないのかは、自分には見えにくい。知らない知識は検索すらできない。 いわゆる探求のパラドクスだ。知らないことが何であるのか分からないのなら、「それ」を学ぶことすらできない。行き当たりばったりに学んで、「それ」に行き当たったとしても、「それ」が何であるか分からないのだから、行き
こんにちは! 2023年度エンジニア新卒の、吉田です。 株式会社リクルート 新卒エンジニアコースでは、部署への配属前に、BootCampと呼ばれる新人研修を行っています。 本日は2023年度の研修の内容を、実際に受講した新卒の立場から紹介させていただきます。 研修の内容については毎年反響をいただいていますが、今年度も一段と進化し、より充実した研修でした。 ページ下部に研修資料を公開していますので、ぜひ研修の雰囲気を感じ取っていただけると嬉しいです。 研修の概要 エンジニアコースの新人研修は、配属後にスピード感を持って成長できるようになることを見据え、 「さまざまな技術領域の講座を受け、興味関心を広げて、知らなかった好奇心に出会う」 「現場で求められる『仕事への取り組みスタンス』をつかむ」 「気軽に相談できる仲間(同期)をつくる」 の3点が目的とされています。 今年度は、入社前に行われたスキ
歴史が苦手だったのは、こんな昔のイベントや用語を覚えて、いったい何になるんだ?と思ったからだった。 そして、個々の知識が細かすぎて、解くべき問題に結びつくまでが遥か遠い、とでも言うべき感覚が嫌だった。 知識をいくつも覚えて、それらを組み合わせてようやくたった一つの答えがわかる。 しかも、それも知ってるか否かだけ。私個人による創意工夫の余地も無い。端的に面白くない。 それらをもどかしく思っていたのだ。 まとめると、歴史は、覚えることのコスパが悪い知識であり、私個人を疎外する教科だと感じていた。 その点で、数学の知識、つまり、公式は一般性を持つので適用範囲が広いし、私の創意工夫も生かせる。 だから、数学は大好きだった。 公式はひとつ覚えれば、多くの問題に適用できるのだ。覚える個数としても、そんなに多くない。 だから、ビジネス書に書かれた格言が多くの応用と工夫の余地を期待されるように、 私も適用
皆さんこんにちは。株式会社ラクーンホールディングスで働いている川崎です。 最近「システム設計の面接試験」という本を読みました。 個人的にとても面白いと感じたので、オススメポイントと感想を共有します。 直近でシステム設計の面接を受けない方も、きっと読んで得るものがあると思います。 本の概要 システムの設計はシステムの機能や仕様、データのアクセスやセキュリティを左右するため、非常に重要だが、従うべき一定のパターンがないために、その習得は難しいと言われています。 一方で、システム設計自体がITエンジニアに日常的に求められる作業であるため、システム設計の面接試験は米国で広く採用されています。 本書では、「Webクローラ」「通知システム」「ニュースフィードシステム」「チャットシステム」「youtube」など実践的なテーマに沿って、システム設計の問題を出題し、その回答を解説することで、システム設計力を
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか?」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
AWS DevOps & Developer Productivity Blog How organizations are modernizing for cloud operations Over the past decade, we’ve seen a rapid evolution in how IT operations teams and application developers work together. In the early days, there was a clear division of responsibilities between the two teams, with one team focused on providing and maintaining the servers and various components (i.e., st
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い(&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1)は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です(結論) スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ~変化を抱擁せよ
Pydanticが今最高にCool こんにちは、極論モンスターのYosematです。pydanticに替えてdataclassを使う理由は今ほとんどありません。pydanticがV2になったこのタイミングでpydanticに乗り換えましょう。この記事ではなぜdataclassよりもpydanticなのか理由を述べていきます。 ※2024/02/26追記 OpenAIのクライアントもPydanticを採用しました 素敵なブログからの引用。ただし現在はdataclassもslotを導入している。slotを利用して通常より高速にフィールドアクセスしたい人はattrsやdataclassもアリ。 理由① より洗練されたインターフェース pydanticをdataclassに代えて使うのはなんといってもかゆいところに手が届くインターフェースです。はっきりいってdataclassも素晴らしいライブラリ
この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖
スピードチェック(PDFファイル) 使い方はこちら(動画) 第01話 先史・オリエント 第02話 ギリシア 第03話 ローマ 第04話 古代インド 第05話 中国①(黄河文明~後漢) 第06話 中国②(三国~唐) 第07話 中国③(北宋~清) 第08話 イスラーム世界 第09話 中世ヨーロッパ前半(十字軍まで) 第10話 中世ヨーロッパ後半(十字軍以降) 第11話 大航海時代・ルネサンス・宗教改革 第12話 主権国家体制 第13話 産業革命・アメリカ独立・フランス革命 第14話 19世紀の欧米諸国 第15話 帝国主義・第一次世界大戦 第16話 ロシア革命・戦間期・第二次世界大戦 第17話 中国④(アヘン戦争~辛亥革命) 第18話 中国⑤(第一次大戦~現在) 第19話 近現代インド史・西アジア史 第20話 戦後の世界 20話に基づいた教材を作ってみました。10~20分で穴埋めをしてから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く