taeha 2025-03-13 | 親コメント | トピック: Mistral OCR公開 - 最高水準の文書理解API (mistral.ai) 韓国語の性能に関する内容はありませんが、試してみたところ悪くなさそうです wantutopia 2025-03-13 | 親コメント | トピック: 最先端のWebスクレイピング技術 (github.com/simonw) マクロ防止の回避機能を備えれば……市場の勝者になれそうです。 yshrust 2025-03-13 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) かなり議論が白熱しているようで、Anders Hejlsberg本人が直接コメントを残していますね https://github.com/microsoft/typescript-go/… wedding 2025-03-13 | 親コメント | トピック: Seven39 - 毎晩3時間だけ開くソーシャルメディアアプリ (seven39.com) そうです、それです！ jjpark78 2025-03-13 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) TypeScriptにコンパイルして、成果物がそのままバイナリとして出てきてほしい派 kipsong133 2025-03-13 | 親コメント | トピック: 強化学習（RL）の数学的基礎：書籍とYouTube講義 (github.com/MathFoundationRL) 良い資料のご紹介、ありがとうございます。 caniel 2025-03-13 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) SWCはBabelのように互換性のあるJavaScriptコードを生成し、バンドルするところまでに焦点がありますが、こちらはTypeScriptコードをJavaScriptに変換したり、エラーをチェックしたりすることに焦点があります。 cosine20 2025-03-13 | 親コメント | トピック: LLMは実際にプログラマーの生産性をどれほど向上させているのか？ (lesswrong.com) 私の体験とも似たような感じですね。 シンプルだけれど覚えるのは難しいコード（ファイル入出力処理、コンテナの扱いなど）を書くとき コンパイルエラーやランタイムエラーが発生したとき、それがどんなエラーで、どのコードが原因なのかを知りたいとき すでに書いてある関数と似ているけれど、少し違う機能を入れた関数を書き直したいとき あるライブラリに依存しているコードを別のライブラリに置き換えたり、自前の関数に置き換えたりしたいとき 特定の機能を実装したり、特定の環境で作業したりするときに、どのように開発すればよいかガイドが必要なとき 上のようなケースでは、かなり多くの時間が短縮されました。Google+Stack Overflowの組み合わせではうまく見つからない場合も多いですし、特にStack Overflowでは、ある回答があってもコメントで異論がいつも多く出たり、古いバージョンの実装方法なので使ってはいけないと言われたり、そういう問題があってイライラすることが本当に多かったのですが... ceruns 2025-03-13 | 親コメント | トピック: エンジニアリングチームの集中の技術: 少なくすれば、より多くを実現できる (resources.github.com/developer-productivity) 1〜2週ごとに分けることになると、自然と1つの機能についての全体像は限られた人しか分からなくなる気がします。プロセスとスレッドの違いのように。関心を限定しつつ生産性を高めるわけですから。 たとえ全体像を共有したとしても、その全体像に対して疑問を持つだろうという前提ではあるのですが、スプリントプランニングのたびに少しずつ変わる方向性に応じて、大きな絵をどう追っているのかを合わせられない、という前提も私が自然に置いていたようです。 mmiroro 2025-03-13 | 親コメント | トピック: エンジニアリングチームの集中の技術: 少なくすれば、より多くを実現できる (resources.github.com/developer-productivity) 大きな全体像を共有し、全員が理解した状態で業務を小さなタスクに分割することではないでしょうか?? kipsong133 2025-03-13 | 親コメント | トピック: 2025年にAndroidアプリを作る (dev.to) 良い記事をありがとうございます ceruns 2025-03-13 | 親コメント | トピック: エンジニアリングチームの集中の技術: 少なくすれば、より多くを実現できる (resources.github.com/developer-productivity) このように細かいタスクに分割してしまうと、大きな全体像を持っているリーダーの権限が大きくなります。一緒にいるエンジニアたちは、むしろ動機を失って「自分たちはいったいどこへ向かっているんだ」となってしまいます。スプリントベースのアジャイルの代表的な欠点です。 あまりにもリーダーの視点だけで書かれているように思いますね、タイトルどおり。 エンジニアのモメンタムは、リーダーが旗をどの方向に掲げているかにも大きく影響されます。顧客に提供したい価値が何なのか、各スプリントごとのoutputとdelivery outcomeが何なのかを示せる方法についても、もう少し考える必要がありそうです。もちろん難しいソフトスキルなので、きちんとできるリーダーを見ることも少なく、そうした文章もあまりありませんが。 passerby 2025-03-13 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) フロントエンドは門外漢なので……swc とは違うのでしょうか？ crawler 2025-03-13 | 親コメント | トピック: Seven39 - 毎晩3時間だけ開くソーシャルメディアアプリ (seven39.com) 今は朝8時40分なのに、何気なく見たらちょうど 7:40:28 PM EST ですね……不思議だ ohyecloudy 2025-03-12 | 親コメント | トピック: 50年間の旅で得たヒント (kk.org) マクドナルドに立ち寄るのは簡単そうです。楽しい体験になりそうです。 bungker 2025-03-12 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) .NETは理解できますが、RustはGoと同じ位置づけだと思います。やはり、既存のJS関連のGoプロジェクトやライブラリも判断に影響したように思います。 justart 2025-03-12 | 親コメント | トピック: Seven39 - 毎晩3時間だけ開くソーシャルメディアアプリ (seven39.com) 本当に斬新なアイデアですが、他のコメントにもあるように、トラフィックが集中したときにどう対処するのかも気になります。 asheswook 2025-03-12 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) それはNodeのようなランタイムのことを指しているようですが、ここで言っているのはTS言語自体のコンパイラです。 halfenif 2025-03-12 | 親コメント | トピック: 10倍高速になったTypeScript (devblogs.microsoft.com) > TypeScriptコードがもはやTypeScriptで書かれなくなると、チームがTypeScriptを直接使わなくなり、長期的には開発体験に影響する可能性がある。 いわゆる「ドッグフーディング」ですね。自分たちが作ったものを自分たちで使うことです。でも、言語の場合は少し悩ましいですね。 ganadist 2025-03-12 | 親コメント | トピック: 2025年にAndroidアプリを作る (dev.to) とはいえ、最新技術(?)を導入しようとすると JUnit4 が足かせになることがしばしばあるので、個人的には JUnit5 へ移行してほしいというささやかな願いがあります。 https://docs.gradle.com/develocity/test-distribution/ junit-vintage-engine を使えば大きな修正なしに junit4 のテストを junit5 で動かすことはできますが、オーバーヘッドがかなり大きいです。（おおよそ 20% ほど遅くなります） コメントをさらに読み込む
韓国語の性能に関する内容はありませんが、試してみたところ悪くなさそうです
マクロ防止の回避機能を備えれば……市場の勝者になれそうです。
かなり議論が白熱しているようで、Anders Hejlsberg本人が直接コメントを残していますね
https://github.com/microsoft/typescript-go/…
そうです、それです！
TypeScriptにコンパイルして、成果物がそのままバイナリとして出てきてほしい派
良い資料のご紹介、ありがとうございます。
SWCはBabelのように互換性のあるJavaScriptコードを生成し、バンドルするところまでに焦点がありますが、こちらはTypeScriptコードをJavaScriptに変換したり、エラーをチェックしたりすることに焦点があります。
私の体験とも似たような感じですね。
上のようなケースでは、かなり多くの時間が短縮されました。Google+Stack Overflowの組み合わせではうまく見つからない場合も多いですし、特にStack Overflowでは、ある回答があってもコメントで異論がいつも多く出たり、古いバージョンの実装方法なので使ってはいけないと言われたり、そういう問題があってイライラすることが本当に多かったのですが...
1〜2週ごとに分けることになると、自然と1つの機能についての全体像は限られた人しか分からなくなる気がします。プロセスとスレッドの違いのように。関心を限定しつつ生産性を高めるわけですから。
たとえ全体像を共有したとしても、その全体像に対して疑問を持つだろうという前提ではあるのですが、スプリントプランニングのたびに少しずつ変わる方向性に応じて、大きな絵をどう追っているのかを合わせられない、という前提も私が自然に置いていたようです。
大きな全体像を共有し、全員が理解した状態で業務を小さなタスクに分割することではないでしょうか??
良い記事をありがとうございます
このように細かいタスクに分割してしまうと、大きな全体像を持っているリーダーの権限が大きくなります。一緒にいるエンジニアたちは、むしろ動機を失って「自分たちはいったいどこへ向かっているんだ」となってしまいます。スプリントベースのアジャイルの代表的な欠点です。
あまりにもリーダーの視点だけで書かれているように思いますね、タイトルどおり。
エンジニアのモメンタムは、リーダーが旗をどの方向に掲げているかにも大きく影響されます。顧客に提供したい価値が何なのか、各スプリントごとのoutputとdelivery outcomeが何なのかを示せる方法についても、もう少し考える必要がありそうです。もちろん難しいソフトスキルなので、きちんとできるリーダーを見ることも少なく、そうした文章もあまりありませんが。
フロントエンドは門外漢なので……
swcとは違うのでしょうか？今は朝8時40分なのに、何気なく見たらちょうど 7:40:28 PM EST ですね……不思議だ
マクドナルドに立ち寄るのは簡単そうです。楽しい体験になりそうです。
.NETは理解できますが、RustはGoと同じ位置づけだと思います。やはり、既存のJS関連のGoプロジェクトやライブラリも判断に影響したように思います。本当に斬新なアイデアですが、他のコメントにもあるように、トラフィックが集中したときにどう対処するのかも気になります。
それはNodeのようなランタイムのことを指しているようですが、ここで言っているのはTS言語自体のコンパイラです。
> TypeScriptコードがもはやTypeScriptで書かれなくなると、チームがTypeScriptを直接使わなくなり、長期的には開発体験に影響する可能性がある。
いわゆる「ドッグフーディング」ですね。自分たちが作ったものを自分たちで使うことです。でも、言語の場合は少し悩ましいですね。
とはいえ、最新技術(?)を導入しようとすると JUnit4 が足かせになることがしばしばあるので、個人的には JUnit5 へ移行してほしいというささやかな願いがあります。
https://docs.gradle.com/develocity/test-distribution/
junit-vintage-engineを使えば大きな修正なしに junit4 のテストを junit5 で動かすことはできますが、オーバーヘッドがかなり大きいです。（おおよそ 20% ほど遅くなります）