オープンソースの定義にこだわるのはもう無意味なのか？ - YAMDAS現更新履歴
[2023年8月22日追記]：松尾研究室の投稿にあるように、問題のプレスリリースは修正がなされ、「オープンソース」の記述は削除されている。 weblab.t.u-tokyo.ac.jp 東京大学松尾研究室が大規模言語モデル（LLM）を公開というニュースが先週話題となったが、「商用利用不可のオープンソース」という記述に「商業利用できない」のであれば、オープンソースではないという突っ込みがすかさずあがり、佐渡秀治さんも「座視することが難しい」と意見表明している。 ワタシもこれらの意見に賛成である（事実そうした声を受けて、ITmedia などは記事の記述を改めている）。ただ、この話題にすっぽり重なる文章を少し前に見て、居心地が悪い思いをしていたので、それを紹介しておきたい。 www.infoworld.com 「オープンソースのライセンス戦争は終わった」というタイトルだが、どういう文章なのか？
AIはどのような仕事ができるようになったのか？ChatGPTで変わる「優秀な人材」
この図はざっくりと3つの領域に分かれます。まず左下が従来のプログラミングの領域です。これは簡単に言うと「プログラムは間違ってはいけない定形な仕事を奪う」ということです。次にその上の士業が責任を取る領域です。これは「責任」を取る人がいないと成立しない仕事です。ミスが発生した際に罰則を与えるという形で、ミスの発生を防いでいます。最後に右側のホワイトカラーの仕事の領域です。ホワイトカラーの仕事は入出力が不定形であり、作業フローも非定型であったりします。そのため、多少のミスはあっても仕方ないという前提の上で仕事が行われています。 機械学習がビジネスに組み込まれるにつれ、ホワイトカラーの仕事領域はそれらによって少しずつ代替されつつあります。その図がこちらになります。 ホワイトカラーの担っていた領域は、表データの機械学習（重回帰や、Lasso回帰、SVM、RandomForest、LightGBMなど
プログラマだった親父が死んだ
俺にとってはビル・ゲイツよりもスティーブ・ウォズニアックよりもリーナス・トーパルズよりもケン・トンプソンよりもアラン・チューリングよりもティム・バーナーズ＝リーよりもブライアン・カーニハンよりもビャーネ・ストロヴストルップよりもジョン・バッカスよりもグレース・ホッパーよりもデニス・リッチーよりも数々の功績を挙げた偉大なプログラマよりも本当に本当に偉大なプログラマだった 親父の職業がプログラマだと子供の頭で理解したとき本当に驚きだった 俺の親父はテレビテニスが作れると知ったとき、オリジナルのゲームウォッチを目の前で作りあげ誕生日プレゼントだと渡してくれたとき、俺の親父は何でも出来る人なんだと本当に憧れた PC9801やX68000で疑似3Dやワイヤーフレーム3Dをレンダリングされた際の衝撃が理解できるだろうか？俺はまさに最先端のゲームを目にしていると子供ながら身を震わせてしまったことを今でも
デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
ソースコードを書くのは単純作業？ GitHub日本法人の記事が物議 発言元のヤマト運輸「誤解を与えてしまった」
「ソースコードを書くのは単純作業」──そんな内容の記事がITエンジニアなどを中心にTwitter上などで話題になっている。記事を掲載したのは、GitHubの日本法人ギットハブ・ジャパン。ヤマト運輸のGitHub活用事例を紹介する記事の中で、ヤマト運輸のDX推進を担当する中林紀彦執行役員がこのように発言したとしていた。 話題となった記事では、ヤマト運輸のデータ・ドリブン経営について、中林執行役員などが解説。開発環境の内製化のためGitHubを採用したことや、2年で約100人のITエンジニアを採用したことなどを記載している。その中で、今後の展望としてGitHubを活用した内製化の新たな形を探りたいという旨で、中林執行役員の発言として以下の記載があった。 「これまでの内製化はアウトソーシングからの見直しが主体でした。これからは、アーキテクチャのデザインや、GitHubを活用したソースコードのガバ
(令和4年6月29日)ソフトウェア業の下請取引等に関する実態調査報告書について | 公正取引委員会
令和4年６月2９日 公正取引委員会 １ 調査趣旨 昨今のＤＸ（Digital Transformation）化の流れを支えるソフトウェア業においては、多重下請構造型のサプライチェーンの中で、下請法上の買いたたきや仕様変更への無償対応要求といった違反行為の存在が懸念されている。このため、公正取引委員会は、ソフトウェア業における２万1000社（資本金３億円以下）を対象としたアンケート調査、関係事業者・団体に対するヒアリング調査などによって、ソフトウェア業の下請取引等に関する実態調査を実施した。 ２ 調査結果 報告書本体及び概要参照。 関連ファイル （印刷用）（令和４年６月29日）ソフトウェア業の下請取引等に関する実態調査報告書について （印刷用）（令和４年６月29日）ソフトウェア業の下請取引等に関する実態調査報告書（概要） （印刷用）（令和４年６月29日）ソフトウェア業の下請取引等に関する実態
少しマジレスしたくなったので書いてみようかな。 まず、君は間違いなく中..
少しマジレスしたくなったので書いてみようかな。 まず、君は間違いなく中途枠での採用となる。君の競争相手はすでに経験のある人たちだ。君はそのハンデを覆さないとならない。 ITは割と簡単にこの辺ひっくり返すことができるが、君のアプローチは採用するがわからしたら、ふーん、というものでしかない。 他の人たちには必ず＋経験というブースターがついているので、Javaができます、Javaを使ってこんなことをしました、という話ができるからだ。 採用する側がほしいのはこんなことをしました、という部分なので、君には悪いが魅力がない。 なのでこのままだと無理だ、という回答になる。 こういった無理筋なことをひっくり返すには何をすればいいのか、という話に戻る。 大事なことをいくつか言うね。 君が何をやったのか 君に何ができるのか 君が何者かこれらがとにかく大切だ。勉強しまた！ではないからね まず、君が何をやったのか
プログラミング言語別の平均年収ランキング トップ10にPythonやJSなど入らず 1位は？ パーソル調査
プログラミング言語別の平均年収ランキング トップ10にPythonやJSなど入らず 1位は？ パーソル調査 パーソルキャリアは6月6日、日本におけるプログラミング言語別の平均年収ランキングを発表した。1位は「ABAP」で平均年収661万円。2位は「R」で656万円、同率3位は「Perl」と「VC・VC++」で630万円だった。同社が過去に調査した「ITエンジニアが学びたい言語ランキング」ではPython、Java、JavaScriptが上位だったが、これらはトップ10に入らなかった。 プログラミング言語別の平均年収ランキングでは、5位が「Delphi」で629万円、6位が「ASP」で628万円、7位が「Go」で627万円、8位が「PL/1」で618万円、9位が「Cocos2d-x」で607万円、10位が「C++」で605万円だった。調査結果は、パーソルキャリアが転職支援サービス「doda」
エルデンリングから学んだ、プログラミング学習に必要な７つのこと - Qiita
導きのはじまり おぉ、貴方は…褪せ人ですね。 そして、エルデンリングを求め、この狭間の地にやってきた。 この先、プログラミング学習の攻略に繋がる貴重なアイテム が、7つあるぞ すごいなにかだと思うだろう？ 以下の記事を、ご照覧あれい！ 1. 強い敵はスルーして先に進む プログラミングを勉強していると、序盤にツリーガードのような強敵が現れることがありますが、 スルーして先に進むことが大事です。 序盤から強敵と戦うと、ボコボコにされて心が折れます #include <stdio.h>は、こういうもんだと「おまじない」としてスルーする。 var body: some Viewや、fn longest<'a>など、 見慣れない表記を見ても、いったん気にしない。前に進む。 強敵は、力を付けてレベルが上ってから再戦しましょう。 目の前に現れたすべての敵と戦う必要はありません。 ボスまでのルートを開通す
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/masanork/status/1741282755147882950
非エンジニアにドン引きされたんだけど、画面上のコードと声に出して会話するのって普通だよね？「死ぬほど言う」「返事が帰ってきたら病院へ」
https://twitter.com/uupaa/status/1625245983033663489
https://twitter.com/tDKcJ5QVAcKFMDd/status/1615246129331064832
https://twitter.com/coffeeyaaaa/status/1610228922242797569
https://twitter.com/komitsubo/status/1608230053472768000
プログラミング始めたいって言うと
https://twitter.com/komitsubo/status/1540094458917978112
https://twitter.com/hyuki/status/1539135633481838592
https://twitter.com/sugoi_kaizen/status/1536509212490014720