  |
はてなキーワード: フレームワークとは
githubでなにか作ったものをアップロードするのは、自分向きではないことに気がついた。
私が仕事で作っているようなwebアプリケーションというのは、誰でも使える一般性の高いものではなく、もっと特定のビジネスに依存した特殊なものである。
だから一般的な誰でも使えるようなものを作るというのにはあまり慣れていないのだ。
なにか作る場合はkaggleのほうが遊び場として向いていると思っている。
kaggleで「コンペ」に参加するつもりはないし、あれはBERTが出現したぐらいからは、少なくともNLP(自然言語処理)界隈は不毛な場となってしまった。
指標があれば不毛なハックがある。それが現実というものである。
それに業務で実用レベルで使えるモデルというのは、もっと運用のしやすいシンプルなモデルである。
モンスターアンサンブルで精度がSOTAでーすピロローン！なんてことには興味がないが、コンペはそれを目指している。
ではなぜkaggleが良いかと言うと、データセットが転がっていて、notebookも簡単に作成できるからである。
「このデータをこうやって使うとこういうツールが作れる」「このデータをこうやって分析するとこういう知見が得られる」というのは、「web開発用のMVCフレームワークを作ります」よりも具体性がある。
そして特定のデータに対するモデリングをするために論文を調べるようなことになった場合は、勉強にもなる。
私は昔、自然言語処理のブログを書いていたが、実験したことのコードを載せるタイプの記事が多かった。
ところが自称データサイエンティストや自称NLPエンジニアがツイッター上で「ゴミのようなブログを書くな」と言っていて、自分が言われている気がして怖くなったのでブログを閉鎖した。
そういう「政治おじさん」との接触を最大限減らすには、ブログというフォーマットではダメだと思うわけである。
私のマグカップには"Talk is cheap, show me the code."と書かれている。
これはリーナストーバルズの名言だが、政治おじさんが近寄らない場所というのは、具体的なコードが存在する場所であると言えよう。
はい、GPUの仕組みや重要性を分かりやすく説明した本や教材はいくつかあります。例えば以下のようなものが挙げられます。
1. 『GPUを支える技術』 株式会社ボーンデジタル (2023年)
GPUの基本的な仕組みから、最新のGPU技術まで幅広く解説されています。技術者向けですが、図解も多く分かりやすい内容です。
2. 『つくりながら学ぶ! PyTorchによる発展ディープラーニング』 小川雄太郎 (2020年)
機械学習フレームワークPyTorchを使ってGPUプログラミングを学べる実践的な書籍です。サンプルコードを動かしながら理解を深められます。
GPUの歴史から最新アーキテクチャまでを網羅的に解説。コンピュータサイエンスの基礎知識がある大学生・大学院生向けです。
4. Udemy「GPUプログラミング入門 - CUDAとOpenCLで学ぶGPUコンピューティング」
オンライン学習プラットフォームUdemyの動画講座。GPUの基本からCUDAやOpenCLでのプログラミング方法まで解説しています。
ただし、ご指摘の通り小中学生向けのGPUの仕組みを分かりやすく教える本は少ないかもしれません。GPUはCPUに比べると新しい技術なので、教育現場での普及はこれからという面があるでしょう。
技術の発展に合わせて、今後さらに分かりやすい入門書や子ども向けの教材が増えていくことが期待されます。ITリテラシー教育の一環として、GPUについても触れる機会が増えるかもしれませんね。
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check, Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの？」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか？
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか？
それをなぜ、個々のチームに依頼する？
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/15 10:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
使ったことがないのならまずはオズボーンのチェックリストを使おう。
手っ取り早く例を挙げる。
あなたの脳内でいつもあなたを励ましてくれるかわいい女の子の魅力を書きたいとしよう。
1. 転用してみる
かわいい女の子にさらに魅力が追加されるとしたら、どんな属性があるか考えてみよう。
元々想像していたのが黒髪で巨乳で運動神経が鈍い料理上手な女の子だったとする。
ここにさらに他に得意なモノやコトがあるとしたら何があるか考えてみるといいかもしれない。狙撃とか。読経とか。
2. 適合・応用してみる
料理好きのかわいい黒髪女子に匹敵する魅力のあるモノは他に何かないだろうか？
かわいい料理上手な黒髪女子に対抗意識を燃やす平行四辺形や水死体が存在したら、何が起こるだろうか？
3. 変更してみる
黒髪で巨乳で運動神経が鈍い料理上手な男の子を登場させてみるとどうだろうか。
4. 拡大してみる
ネタを壮大にしてみよう。
死神が宿る漆黒の髪をなびかせ、アカシックレコードを秘めた乳房を持ち、家の外に一歩も出たことはないがその腕が生み出す料理は建物を土台から吹き飛ばすことができる宇宙一の美少女の話にしてみたらどうだろう。
5. 縮小してみる
逆に控えめにしてみよう。
茶色っぽい黒髪が特徴で、やや胸が大きいことを気にしていて運動はすこし苦手だが料理人の父を持っていて料理上手になりたい女の子である。
なんだか急にリアリティが生まれて、これはこれでなんだか物語性を感じないだろうか。
6. 代用してみる
元ネタを直接書かない、登場しないとしたら誰が代わりになるだろうか。
例として「黒髪で巨乳で運動神経が鈍い料理上手な女の子」に恋する人物、例えば前頭三枚目になりたくて異世界から来た不死鳥の甥がいたら、どのような主人公になれるだろう？
7. 再配置してみる
例えば、巨大料理を作りたくて市民運動をしている乳牛大好きな色黒の女の子がいたらどんな物語が生まれるだろうか？
8. 逆転してみる
金髪で低身長で運動神経がいい料理下手な男の子を登場させたらどんなシナジーが生まれるだろうか？
9. 結合してみる
いままで挙げたアイデアを合体させてみよう。
例えば、黒髪で低身長な平行四辺形の猫が市民運動を展開する前頭三枚目の乳牛に恋をしてアカシックレコードと水死体を料理する話があったとしたら、それはどのようにドラマチックにできるだろう？
いかがだろうか。
「黒髪で巨乳で運動神経が鈍い料理上手な女の子」という例から少し極端なアイデアを作り出してみたが、ありふれたフレームワーク（オズボーンのチェックリスト）を使うだけでも恐ろしいほどにたくさんのアイデアを作り出せることがわかっていただけたと思う。
ここまで極端でなくても、身近なものを上記のように捻るだけでいくらでも書きたいものが生まれると思う。
あなたが仮に政治に興味があるとしたら、自民党の党首が仮にアメリカ生まれのブロンド美女だったらどうなるか、考えてみてもいいだろう。
野球なら、横浜ベイスターズを異世界魔導ギルド球団に、読売ジャイアンツを異世界冒険者ギルド球団に置き換えたらどのような選手構成に置換できるだろう。
もっと身近なもの、例えばXとInstagramとTiktokが巨大大陸だとしたら、それぞれどんな民族が住んでいて、どのような文化を形成しているだろうか。
思い返してみれば、上記のような「少し違う」何かを混ぜたフィクション作品はたくさんあると思う。
他にも似たようなアイデアを生み出すためのフレームワークはたくさんあるので探してみてほしい。
時代はつねに進み、移り変わっているので、新鮮さやなつかしさも同じように少しずつ移り変わっている。
次から次へとFizzBuzzプログラム書けない、パソコンの操作わからないゴミ人間に会う。
前の職場でもそうだった。
前の職場もそうだったし、その前もそうだった。
3C コレクション全体が 1 つのパッケージに収まりました。 *
3C オールインワン ツールボックスは、多くの機能を最新の使いやすいインターフェイスを備えた 1 つの巨大なツールボックスに統合します。すべての Android デバイスを監視、制御、微調整するために必要なすべてのツール。
Play ストアでの最速かつ最もフレンドリーなサポート。アプリの設定、ヘルプ、サポートからお気軽にリクエストを送信し、懸念事項について言及してください。
一部の機能では、root が必要になるか、Android 6 以降以降の PC 用の 3C Companion アプリの使用が必要になる場合があります。
このアプリは、アプリを簡単に停止したり、アプリのデータを自動的にバックアップしたりできる 2 つのユーザー補助サービスを提供します。どちらも情報を収集することはありません。 プライバシー ポリシー
★ プロに移行するか、アプリ内購入を使用して、次の機能のロックを解除します
記録項目とオプション
ステータス通知から任意の機能にアクセスするための通知ショートカット
多くの追加ウィジェット
★ デバイス マネージャー は、非常に強力なプロファイル、タスク スケジュール、デバイス ウォッチドッグを提供します。
★ ファイル マネージャー は、サムネイルやフォルダー サイズなどを備えた、非常にシンプルでありながら非常に強力なエクスプローラーです。ビデオや写真をお気に入りのプレーヤーに直接ストリーミングします。ローカルでも、Samba、FTP、WebDAV、Google Drive、Dropbox の場所からでも。
★ アプリケーション マネージャー は、Titanium Backup をインポートする機能を含む、すべてのお気に入りのアプリのバックアップ/復元を提供します。また、Xused フレームワークを使用して、アプリのイベント、向き、フルスクリーン、および制御権限を保護およびカスタマイズすることもできます。
★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート
★ ネットワーク マネージャー を使用すると、ネットワーク トラフィックの設定と監視が可能になります。
★ タスク マネージャー は、シンプルな UI を提供しますが、さまざまな用途に応じてアプリを分類し、不要なアプリを削除するのに非常に効果的です。
★ CPU マネージャー は、シングルからオクタコアの CPU、サーマル、マルチコア、およびほとんどのカスタム カーネル設定を制御します。
★ システム マネージャー では、Linux カーネル設定を構成できます。
★ROM マネージャー を使用すると、Android OS の設定を行うことができます。
★ すべてのアプリケーションとハードウェア コンポーネントのアクティビティを監視および記録します。履歴グラフィックを含むステータス バー通知が含まれます。
★ アプリ、ウィジェット、またはプロファイルのシステム コンポーネント スイッチにより、約 20 以上のデバイス コンポーネント (WiFi、Bluetooth など) のオン/オフを切り替えることができます。
はい、ブラウザの実装は確かに**コンピュータサイエンス**の一部です。以下に、その理由をいくつか挙げてみます：
1. **アルゴリズムとデータ構造**：ブラウザは、効率的な検索、ソート、データの格納と取得など、多くのアルゴリズムとデータ構造を使用します。
2. **ネットワーキング**：ブラウザは、HTTPやHTTPSなどのプロトコルを通じてインターネットと通信します。これらのプロトコルの理解と実装は、コンピュータサイエンスのネットワーキングの分野に直接関連しています。
3. **レンダリングエンジン**：ブラウザのレンダリングエンジンは、HTML、CSS、JavaScriptなどのコードを解析し、それをユーザーが見ることができる視覚的なウェブページに変換します。このプロセスは、計算理論、グラフィックス、プログラミング言語の理解を必要とします。
4. **セキュリティ**：ブラウザは、ユーザーのデータを保護するために、さまざまなセキュリティメカニズムを実装します。これには、暗号化、サンドボックス化、同一生成元ポリシーなどが含まれます。
これらすべての要素は、コンピュータサイエンスの基本的な概念に基づいています。したがって、ブラウザの実装は、その「サイエンス」の部分を明確に示しています。ブラウザの設計と実装は、これらの理論を実際の製品に適用するための実践的なフレームワークを提供します。それらは、問題解決、効率的な設計、そして最終的にはユーザーに価値を提供するための方法を探求します。これが、ブラウザの実装がコンピュータサイエンスである理由です。
こんにちは、皆さん。今日は少し物議を醸すかもしれないトピックについて語りたいと思います。
それは、「ソフトウェア技術の99.9%はインターネットから学べるのでググる力を身に着けましょう」という考え方です。
現代のソフトウェア開発者にとって、インターネットは最も重要な学習リソースの一つです。
オンライン上には無数のチュートリアル、ドキュメンテーション、フォーラム、ブログ記事、論文があり、それらは私たちが新しい技術を学び、問題を解決するのに役立ちます。
しかもこれらはソフトウェエア技術のほぼ全分野をほぼ網羅しており、見つからない情報はありません。MIT OCW, arxiv, github, kaggleなどなんでもあります。
「ググる力」とは、情報を効率的に検索し、適切な情報を見つけ出す能力のことを指します。
これは、適切なキーワードを使用したり、信頼性のある情報源を識別したり、関連性のある情報を抽出したりする能力を含みます。
ソフトウェア開発は常に進化しています。新しい技術やフレームワークが日々生まれ、既存のものも更新され続けています。
このような環境では、すべてを覚えることは不可能ですが、必要な情報を素早く見つけ出す能力があれば、それが可能になります。
私の主張は、すべてのソフトウェア開発者が自分自身で学ぶこと、そしてそのための最良のツールがインターネットであるということです。
そして、そのためには「ググる力」を身につけることが不可欠です。
映像のない YouTube のような存在が ポッドキャストです。
YouTube のように、素人も投稿できる音声 メディアです。
※Googleポッドキャストは、YouTube musicに統合の話が出ている
他にSpotify、Amazon music、radikoからも聞けるらしい。
経済系の番組はおじさんがしゃべっていることが多いが、この番組は若い大学生～大学院生の女の子が最近の経済について 話しており、非常に聞きやすく、軽い気持ちで聞けるのが良い。ポッドキャスト的な流し聞きに向いてる。
日経トレンディ及び日経クロストレンドという雑誌の編集部が送るポッドキャストで、最近おすすめのサービスや商品の紹介など。
ボケとツッコミの激しい2人が、最近のサービスや商品、漫画、映画、ドラマなど、とにかく流行っているものについて面白おかしく語る。バルミューダ社長のいじりが好き。
世界や日本の歴史をデータベース化して収益を上げようとする会社が運営しており、歴史に関して何時間も熱く語り、勉強になる。田川をいじるネタが面白い。YouTube番組でもある。
茂木健一郎が、さまざまなゲストを迎えて話すラジオ番組。最近だと、鈴木おさむさんだとか、Pecoさんが出た。過去に ホリエモンやメンタリストDaiGoさん等、有名な人がめちゃくちゃ出ている。スポンサーは聖◎新聞な点が気になりますが、特にそっち系の話はない。
Dream Heartと同じくゲストを迎えて、大学の研究者などから色々な話を聞けるラジオ番組。残念なことに放送終了している。
初期の方は、笑い飯の哲夫さんが仏教に関してあれこれ教えてくれる番組でしたが、ネタが切れてきたのか、だんだんとお坊さんをゲストに迎え、 仏教に関するあれこれをトークする番組 に変わっている
ニュースを読んで、日本語と英語で雑談する番組。 私は英語のリスニング能力が低いので、英語は部分部分しか聞き取れないが、マミはだいたい日本語で話をしているため、文脈からなんとなく英語がわかる気になれる。マイケルは日本語を喋れるのに、かたくなに英語しか喋らない。
文法のあれこれに関して、うんちくを語り尽くす番組。YouTube番組でもある。 とにかく収録時間が長い。よくも文法や単語に関して長時間話せるものだとトークスキルの高さと教養に感心する。
栄養士と料理人とコンサルトの3人が日本の食文化の知識に関して語り尽くす番組で、普段何気なく食べている食事にも深い概念があると気づける。
中学生から知り合いらしい高槻市出身の2人の雑談番組で、以前はどうしようもない下ネタが多かったが、近年、配信者が結婚や子育てを重ね、人間としてまともになっていく感じが興味深い。初期の方から聞いていると、配信者の人生を覗き見している感じが良かったが、 現在、過去回は封印されている。
トヨタ vs ホンダ、任天堂 vs ソニー、ナイキ vs アディダスなど、業界内で有名な2つの企業がどうやって生まれたのか？どのように成長していったのか？をストーリー仕立てにした番組。 もともとは海外の番組で、それを日本語に翻訳した番組でありちゃんと構成が練られている。
新刊の本の内容をドラマ化や、要約して配信する番組。近年、YouTubeでよく見る本の要約のプロ版だと思う。劇団員やナレーションが声優をしていそうに見える。しかし、現在 2020年で更新は止まっている。
大手企業相手の人事コンサルタントである楠田祐が、様々な有名企業の人事部をゲストに、人事評価ってどうやるのか、社内コミュニケーションをどうするのか、リモートワークの対応はどうなのかなど、 どのような人を採用するのかなど、人事に関する貴重な話を聞ける。
フリーランス全般に関して、家賃をどうしているだとか、発注に関する話だとか、 業界を限定しないフリーランスの話を聞ける。しかしコロナ禍の始まりと共に更新が止まっており 、コロナ禍以降、彼らはどうしたのか気になって仕方がない。
転職サイトのGreen編集部が配信している番組で、転職にまつわる話題を話したり、ユニークな事業をしている企業をゲストに迎えて話す番組。
散財王のドリキンと、長らく Web系記事のライターで活躍していた松尾さんがメインでお送りする番組です。主にガジェット系の話でApple 製品や カメラの話などを語っています。かつてはIT系のニュースについて話す番組だったが、 最近は自由気ままに好きなことについて話す番組となっている。AIに関する話題も聞ける。 コミュニティ活動も盛んな様子です。
テック系のポッドキャストも多く聞いてるのですが、 テック系に興味がない方もいると思うので 別にまとめます。 YouTubeの場合、IT系の番組は初心者向けすぎたり極端な意見を述べる番組を散見するが、ポッドキャストは本格的に技術的に語る番組が多い気がする。
宮川達彦さんが運営している番組で、知り合いのエンジニアたちをゲストに迎えて、あれこれ雑談する話で、サンフランシスコで働いているエンジニアも居ますが、意外と技術 寄りの話は少なく雑談が多い。過去に、Perll開発者のラリー・ウォールや、Ruby開発者のまつもとゆきひろが出演していた。
ブラウザの仕様変更やフロントエンド系のフレームワークの最新動向などをキャッチアップして放送する番組で、そういう情報は基本的に英語なので日本語で話してくれると、とても 勉強になるのだが、話の内容が本格的すぎて気軽に聞ける番組ではない。
特定の技術の専門家を招き、深堀って専門的な話を聞してもらえる番組。これまた、えらく話が専門的で理解が難しいことが多い。最近、t_wadaさんがTDDの誤解について語っていて勉強になった。
Qiitaプロダクトマネージャーの方が、Qiitaに投稿している人をゲストに迎えて話を聞ける番組。ミノ駆動さんや、無職やめ太郎の話が聞けて興味深い。
LINEヤフーのフロントエンド チームが送る ポッドキャスト 番組で、フロントエンドの最前線の話が聞ける。インターン組のレベル高すぎて、それを聞いてるワイは死にそうになった。
「Androidを支える技術」を書いているkarino2さんが配信している番組。技術的な話や、プログラマーがどうあるべきかなどの心構え などを語っている。この番組が特徴的なのは、定期的にkarino2さんがほとんど1人で延々と喋って配信している点であり、ポッドキャスト番組の中には一人で喋っていることに限界を感じて ゲストを迎える 番組も多いのに珍しいと思う。なろう系について語り続ける場合もある。
おそらく、サイバーエージェント系の会社で一緒だった人たちが始めている番組で、 主に雑談や近況報告など。気軽に流し聞きできて良い。
スクラム道関西というコミュニティが運営しているアジャイルやスクラムについて話す番組です。アジャイルやスクラムの世界の話が聞ける。アジャイルやスクラムではない近況報告や雑談などのほうが多い気もする。
主にエンジニア的な組織論に関する話です。組織に関する抽象度の高い哲学的な話が多く、毎回、理解できるような、難しくて理解できないような気持ちに駆られる。
PHPにまつわる配信番組なのですが、最近更新されていないのが残念。
はてなの開発部もポッドキャストを公開してます。非常に淡々とした雰囲気。
安住紳一郎アナウンサーの番組も ポッドキャスター化されており いつか聞いてみたと思う
コミュニケーション力が上がりそうなので いつか聞いてみたいと思う
コンピューターサイエンス系の論文を紹介している番組らしいのでいつか聞いてみたいと思う
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
味噌汁にクソを入れるかミソを入れるかはどうでも良くないよ
デザインパターンというのは言語やフレームワークを超えて使うものだよ
GAFAのSWE面接で言語やフレームワークなんか聞かれないよ
好きな言語で答えてくださいって言われる
俺は知ってるんだよ
2回落ちたから笑
フレームワークとか言語は「技術のある」エンジニアならすぐ慣れるんだよ
靴が変われば影響はあるかもしれないけどすぐ慣れるでしょ
君の言ってるのはもう書いたけどデザインパターンとかアルゴリズムとかだね
そういうのも本読めば誰でも（サポーターでも）なんでも言えるけど
実際に使って実績を上げてるかどうかは全然違う話だね
そこはその通り
言語とフレームワークに詳しいこと自体は、サッカーでいうとサポーターでも出来ることで、実際にサッカー選手としてどのレベルなの？という観点では実際にサッカーの実戦もしくは過去の戦績 を聞かないと分からないという話だぞ
そして、優れたサッカープレイヤーは、大抵どちらも優れているという話だな、若手・新人や管理職や営業職なら、熱心にサッカーを観戦して知識があるだけでも俺は良いことだと思うぞ
言語とかフレームワークは今は靴がどこのがいいとか審判からここは見えないとかいうことであって
ドリブルがうまいとか足が速いとかシュートが正確とかいうサッカーの技術ではないんだよ
サッカー知らんけど
「言語やフレームワークは技術でない」というのは、例えばサッカーでプレイヤーとしての価値を測る物差しはフォーメーションや戦術に関する知識量よりも、実際のプレーや戦績という話であって、ある程度の水準以上の選手はプレーも知識も優れているし、フォーメーションや戦術はサッカーではないという奴はいないだろう
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
