もしもいま、Ruby/Railsをイチから学び直すとしたら？ Ruby技術書著者・五十嵐 邦明さんに聞いた学習ロードマップ - Findy Engineer Lab
めまぐるしく変化するテックの世界。技術を身に着けるうえで学ぶべきポイントや学習環境なども年々変わっています。 そこで「もしもいまの環境で、テックのことをイチから学び直すことになったら、自分はどんな風に勉強したいか」というIFストーリーを通じて、技術との向き合い方を考え直してみる企画「テック転生」。 今回お話を伺ったのは、Ruby・Rails関連の技術書を数多く上梓し、学習環境の充実化やエンジニア育成に尽力されてきた五十嵐邦明さん（＠igaiga555）。“自分だったらこう進めたい、Ruby・Ruby on Railsの学習ロードマップ”を伺いました。 初心者に向けて執筆した『ゼロからわかる Ruby超入門』が最適 ――五十嵐さんがいま、イチからRuby・Railsを学び直すとしたら、何から始めますか？ もしも私がこれから学び直すとしたら、自分が執筆した『ゼロからわかる Ruby超入門』を使
エンジニアをやめました - よく寝てよく寝る
Xの名前やプロフィールを変えたので気づいた方もいるかもしれませんが、 1ヶ月前くらいにエンジニアからジョブチェンジし、技術広報のお仕事をしています。 転職はしてません。 転職してから何してたの なんでエンジニアやめたの 感謝したいこと これからについて 転職してから何してたの 技術広報を始めるきっかけがあるまで、何やってたかを書いてます。 たいした伏線にはならないので興味のない方は読み飛ばしていただいて構いません。 ペパボからグロービスにバックエンドエンジニアとして入社するとまず、グロービス学び放題というビジネススキルを動画で学習できるサブスクサービスの事業部で、新規ユーザーを獲得するための開発施策を実施するチーム(当時)に配属されました。 このチームの守備範囲はサービスのLPにあるメールアドレス登録フォームからサブスクのプランを選択して決済操作を完了させるまでです。 チームメンバー全員が
【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 | レバテックラボ（レバテックLAB）
TOPコラムテック最前線レポート【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 2024年8月8日 プログラマ、テスト駆動開発者 和田 卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブ
管理職であり連載作家、ピエール手塚先生に学ぶ「時間の作り方」。怠け者な自分を「ハック」するテクニックとは - ミーツキャリアbyマイナビ転職
日々多くのタスクに追われるビジネスパーソンにとって、「24時間をどう使うか」はスキル・キャリアアップのための重点テーマです。業務効率化しながら自己研鑽の時間を捻出する方法について、普段から考えを巡らせている人も多いでしょう。 会社員のかたわら、漫画家として商業誌への連載を続けてきたピエール手塚さんも、時間の上手な使い方を徹底して模索してきた一人。会社では管理職としてマネジメント業務もこなしながら、スキマ時間を漫画制作にあてることで、月2回連載を継続しています。そこには時間を作り出すためのさまざまな工夫がありました。 今回はそんな手塚さんに、日々の時間の使い方はもちろん、手の動いていない時間を減らす方法、やる気が出ない時のマインドセットなど、時間をうまく使うためのテクニックや極意を学びます。 ピエール手塚さん。会社員、漫画家。30代で漫画を描き始め、同人誌即売会に出展。同人誌『ねえママ あな
ITベンチャーあるある……ではないと思うけどみんなどうしてるのか知りたい - Really Saying Something
後から優秀な人がどんどこ入ってくる 自分は創業期ではないけど社歴でいえばかなり初期の頃に入社しており、それはそれで運が良かったし、カオスな時期ものどかな時期も大変だった時期もあってそれを乗り越えたといえば聞こえがいいが、会社が整うにつれてめっちゃ優秀な人に囲まれるようになって、ふと気が付くとちょっと引け目を感じる。 その優秀な人がみんな年下だったりする 社歴が長いのでその分年を重ねるわけだけど、若くて優秀な人がたくさんいて、みんなすごくて、もちろん出世（昇格を指す）もしていくので、ちょっとした置いてきぼり感がある。 チームが生まれたり消えたり統合したり分割したりするので、それに伴う降格（？）もあったりする いろいろな試行錯誤があるのでチームが変わり、一瞬上長的な役割になったけどそこから外れることももちろんあって、気持ちの持って行き場所がない時があった。 ちなみにこれは、以前の上長が「マネジ
「顔写真で自閉症を判別」 AI講座受講者がアプリ公開し物議…… 講座運営企業が謝罪 「倫理的に懸念」
IT企業のアイデミーは8月7日、同社のAIアプリ開発講座受講者が、講座の一環で「顔写真から自閉症を判別するWebアプリ」を公開し物議を醸した件について謝罪しました。 Aidemy Premium 「倫理的に問題がある」など批判 物議を醸したのはアイデミーが提供する講座「Aidemy Premium」の受講者によるブログとアプリ。当該の受講者は講座の成果物として、顔写真から自閉症を識別するとするWebアプリを開発。受講修了要件を満たすためとして、アプリを公開し、開発の過程などを記載したブログを公開していました（その後アプリは非公開になりブログは削除）。 削除されたブログ これに対して、悪用を懸念する声や、差別を助長するのではないかといった批判、倫理的に問題があるとする意見などが寄せられました。「医師が慎重に時間をかけて診断しているものを、写真だけで判断できるものではない」との指摘もあり、受講
演奏会のリハで「楽器の調子がおかしい」と話していたら、その場に居合わせた整体師が「ちょっと見せてもらってもいいですか？」→楽器を渡すと次々と信じがたいことが起きた
taro terahara @srgmtaro ちょっと、にわかには信じ難い出来事があった。先程、夜の打ち合わせ会場にたまたま居合わせた整体の方。 「ちょっと見せて貰っても良いですか？実は僕、楽器の整体もやるんですよ」 リハで、楽器の調子がおかしいという話をしていた時だった。え、なになに？楽器の整体？どーゆーこと？ taro terahara @srgmtaro バーンスリー奏者。人生の半分以上インドの横笛バーンスリーを吹いてます。 控えめに言ってインド音楽馬鹿。ちゃるぱーさと一緒にアフガニスタンの音楽も。srgmtaro.jimdo.com （寺原太郎） note: note.com/srgmtaro srgmtaro.jimdo.com taro terahara @srgmtaro 不安気な顔で見守るみんなの視線をよそに、太鼓の枠や皮をひとしきり撫でたりさすったりして、「どうでしょう
単体テストの考え方/使い方のメモ・単体テストについて学んだこと｜くぼぴー
単体テストとはテスト・コードを含めたすべてのコードは負債 そのため、テスト・ケースがもたらす価値の基準を高く設定し、その基準を満たしたテスト・ケースのみをテスト・スイートに含めなくてはなりません。 価値のないテスト・ケースをいくつも用意するよりも、価値のあるテスト・ケースを必要な分だけ揃えるほうがプロジェクトの継続的な成長に効果があるのです。 単体テストでバグを発見すると、かなりお得！！ 🐤 単体テストの性質3点1単位の振る舞い(a unit of behavior)を検証すること。 実行時間が短いこと。 他のテスト・ケースから隔離された状態で実行されること。 (1 つのテスト・ケースに関する修正が他のテスト・ケースに影響を与えてはいけない) ※ Googleでは80%がユニットテスト。 ※ テストの保守性に重きを置き、テストが失敗するまではそのテストに考える必要がない程度の品質が必要。
単体テストの考え方/使い方 まとめ
著者は古典学派のスタイルを好んでいて、本書では古典学派の定義を採用している テスト対象の焦点をクラスに当てるのは間違っていて、1単位の振る舞いに焦点を当てなければいけない。 また、ロンドン学派のスタイルだと単体テストがテスト対象の内部的なコードと密接に結びつく傾向があるため、賛同できない。 3章 単体テストの構造的解析 AAAパターンという単体テストの構造を用いることで、全てのテストケースに対して簡潔で統一された構造を持たせることができる。また、この構造に慣れることで読みやすさが向上し、保守コストを下げることにつながる。 準備フェーズ(Arrange)フェーズ...ケースの事前条件を満たすように、テスト対象システムとその依存の状態を設定するフェーズ 実行(Act)フェーズ...テスト対象の振る舞いを実行するフェーズ 確認(Assert)フェーズ...実行した結果が想定した結果であることを確
単体テストの単位はコードではなく振る舞いである
単体テストの単位はコードではなく振る舞いである 2023.01.07 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の振る舞いから見た振る舞いが壊れていないことを保証してくれる度合いです。この耐性が高ければ、開発者は安全にコードを変更できます。 この記事では、単体テストをコード単位で書いた場合と振る舞い単位で書いた場合をそれぞれ提示して、リファクタリングに対する耐性がどのように異なるのかを見ていきます。 単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の
その単体テストは 振る舞い を検証できていますか？ - Qiita
はじめに 本記事は単体テストにおける偽陰性に焦点をあてています。偽陽性は別記事にします。 目次 振る舞いを検証できていない場合ただの負債になりかねない そもそも単体テストの目的って？ 単体テストで検証したいものって？ 振る舞い と 内部実装（実装の詳細） 観察可能な振る舞い とは 内部実装（実装の詳細） とは 注意：振る舞いと内部実装は視点によって変化する 検証したいものは外部から観察可能な１単位の振る舞い 現実世界で 振る舞い と 内部実装 を考える テストケースに内部実装が漏れ出ている例 このテストケースの問題点 テストケースで内部実装の検証をしている場合... 振る舞いの変更があったのにテストが落ちない（偽陰性：False Negative） 振る舞いを検証するように修正した例 おわりに 振る舞いを検証できていない場合、ただの負債になりかねない コードは書いた時点で負債になるとも言わ
ユニットテストは振る舞いをテストするもので、実装に対して書くものでは無い
この記事の要約 ユニットテストは実装内容に注目せず、実際の用途と入出力に焦点を当てて行う。 １つの振る舞いに対して、１つのテストを行うのであって、１つのコードではない。 必要な振る舞い単位で関数を分けず、機械的な単位分割は避ける。 部分的にテストをしたいからといって、privateをpublicにしない。 「単体テストの考え方/使い方」は実装コードを改善するうえでも、とても良い本。 書籍リンク：単体テストの考え方/使い方 「単体テストの考え方/使い方」を読んで、 今まで悪いユニットテストを書いていたことが分かり、 同時に良いユニットテストが何かも分かったので、思考を整理するために記事にしました。 どう変わったかを、送料計算を例に説明していきます。 要件 購入金額に応じて送料を計算する。 1000円以上の購入で送料無料になる。 読書前の思考パターン（悪い例） この要件を受けて、次のように考え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
売上60万本突破の2人専用協力プレイゲーム『違う冬のぼくら』は、「ケンカしてほしい」という願いのもと作られた。次回作はもっとギスギスさせる予定 - AUTOMATON
