サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
坂口博信さん、成田賢さんが2024年6月22日放送のJ-WAVE『ゆう坊とマシリトのKosoKoso放送局』の中で初期『ファイナルファンタジー』シリーズなどを手がけた天才プログラマー、ナーシャ・ジベリについて話していました。 （鳥嶋和彦）やっぱり当時は（開発が）早いよね。 （坂口博信）最長で10ヶ月ですね。 （Naz Chris）ドラクエも早かったんですよね。 （堀井雄二）1なんか半年ぐらいで、2もそのぐらい作っていて。すぐ出したからね。で、3」でやっと1年かかったという話なんで。 （Naz Chris）当時のファミコンのゲームって、そんなもんなんですか？ 平均的に1年以内で開発できるんですか？ （堀井雄二）容量が少ないんでね、分量がなかったんだよね。1で64KBしかないんで。そこに絵を入れて、音楽を入れて、プログラムをしてっていう。 （坂口博信）そうですね。成田が言ったようにナーシャって
Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。Google TestingBlog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用
JavaScript において、特に苦手とする人が多い印象のある Promise ですが、await と async の文法が導入されたことで、Promise の仕様を深く理解しなくても非同期処理を自然に書けるようになってきたのではないかと思います。 極論ですが、JavaScript の非同期処理は async await new Promise のみで、（ほぼ）全て表現可能です。特別な理由がない限り then を使わないようにしましょう、ということを周知するのがこの記事の目的です。 なお本記事では Promise の rejected の状態についてほとんど解説しておりません。基本を理解したら、別記事でぜひ学んでみてください。 Promise とは？ Promise は、少し乱暴に説明すると「実行が終わっていないかもしれない何らかの関数」を包んだオブジェクトです。 普通の関数とは違って、
<img id="$img" src="https://js.cx/clipart/ball.svg" width="40" height="40"> <script> $img.onpointermove = function(event){ if(event.buttons){ this.style.left = this.offsetLeft + event.movementX + 'px' this.style.top = this.offsetTop + event.movementY + 'px' this.style.position = 'absolute' this.draggable = false this.setPointerCapture(event.pointerId) } } </script>
HTMXとは https://htmx.org/ HTMXは、JavaScript を記述せずに、Ajax通信や高度なUXを実現できるライブラリ。 軽量 で 高速 で、既存のサーバーサイドのフレームワークとシームレスなやり取りができる。また、AJAX通信の発火、フォームの送信処理、DOMの更新などを既存のHTML要素を拡張するだけで可能とする。WebSocketやSSEにも対応しているので、チャットアプリなどにも適している。2023JavaScript Rising Starsでは、フロントエンド・フレームワーク部門で見事2位に輝いた！(一位はReact、全部門だとshadcn/ui) 似たような機能として、Ruby onRailsのHotWireがあるらしい。 2024年はHTMXがくると言われているぐらい世界で騒がれているのだが、あまり日本では流行っていない。以下はGoogle
祖母の就寝と、システムの不具合が同期して起こる事件。IT業界にはこういった事件がまま見られる……。ITサスペンス物としてこういうネタ楽しいのができるかもしれない。いや、間口狭すぎるか？ 祖母が就寝するとDBインサートができなくなる https://t.co/q2PBRL3JzS — 寺島壽久/ゲームキャストの中の人 (@gamecast_blog) January 8, 2024 この手の話、自分も大好物なんで早速リンク先に飛んで読ませていただいたのですが、自分の経験でもちょうどこんな話に当てはまる出来事があったことを思い出したので、noteにまとめました。それが、タイトルにもある「カナダ大使館でだけ名刺交換やしりとりが失敗する話」です。 まず、前提としてこの話は「どこでもいっしょ」（以降、どこいつ）というゲーム開発中の話でになりまして、25年ほど昔の話になります。タイトル中の「名刺交換」
列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2.switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
上記のようにコードエディタを開くコマンドを分けるために、既にcodeコマンドをVScodeで使っている方はcursorダウンロードの際にcursorコマンドのみインストールするようにしてください。codeの方もインストールすると、codeコマンドでVScodeとCursorどちらも開いてしまうようです。 Cursor主要機能紹介 cmd + Shift + L or cmd + L でGPTとChat機能 エディタ上で画面右にGPTに質問できるサイドバーが出現する。何も選択してないと無から質問できる状態になっていて、コードを選択した状態で開くとそのコードがあらかじめ引用された状態になっている(別の部分のコードもどんどん追加できる)。 ↑10~21行目をcmd + Lした後に31~33行目を追加でcmd + Lした画像 cmd + K でAI Edit機能 コードを選択した状態でcmd +
追記: 10/11 ハテブでバズっているようで、色々指摘があったので追記 getElement*は動作が早いのでIDやクラス名が自明の場合はgetElement*を使う方がいいと言う意見もあり、また、ページの表示で大量に呼び出されるわけではないからボトルネックにはならないと言う意見もある。 getElement*で返されるオブジェクトは動的な変化に対応しており、querySelector*は動的な変化に対応していないため、場合によってはgetElement*を使うといい。このサイトで遊んでみよう。 https://ja.javascript.info/searching-elements-dom#ref-263 for await ... ofは非推奨なので Promise.allを現代的な書き方にした 顧客先のブラウザが古い場合も考慮して、あえてレガシーな書き方もする場合があるらしい。現
ゲームのロード画面においては、ロードの進行を表す“進捗バー”が用意されていることもある。この進捗バーは、わざと不規則な速さで進むように設計されていることが多いという。開発者たちがSNS上で明かしている。 開発者の口からロード進捗バーについての意外な“真実”が明かされる発端となったのは、コメディアンのAlasdair Beckett-King氏のツイートだ。同氏はゲームのロード画面の進捗バーは均等な速度で動くべきであり、ロードにかかる時間を適切に反映する必要があると問題提起。そうした仕組みを用意してからほかの部分の開発を進めるべきである、との願望を伝えている。ゲームにおいてロード進捗バーが止まったり急に進んだりしがちという、いわば「あるあるネタ」を述べているのだろう。 Game developers need to invent a loading bar that moves at an
マイクロソフト、「C#は進化させ続ける」「Visual Basicに新しい構文の導入はしない」。.NETのプログラミング言語に関する最新の戦略を明らかに マイクロソフトは、.NETでサポートする3つのプログラミング言語「C#」「F#」「Visual Basic」の今後に関する戦略を、最新版にアップデートしたことを明らかにしました。 下記はマイクロソフトで.NETのプリンシパルプログラムマネージャを務めるKathleen Dollard氏のツイート。 We've updated our .NET Language Strategy. You can read more and get the links here: https://t.co/SsmZJBSEUA — Kathleen Dollard (@KathleenDollard) February 6,2023 最新版の戦略はこれま
「ソースコードを書くのは単純作業」──そんな内容の記事がITエンジニアなどを中心にTwitter上などで話題になっている。記事を掲載したのは、GitHubの日本法人ギットハブ・ジャパン。ヤマト運輸のGitHub活用事例を紹介する記事の中で、ヤマト運輸のDX推進を担当する中林紀彦執行役員がこのように発言したとしていた。 話題となった記事では、ヤマト運輸のデータ・ドリブン経営について、中林執行役員などが解説。開発環境の内製化のためGitHubを採用したことや、2年で約100人のITエンジニアを採用したことなどを記載している。その中で、今後の展望としてGitHubを活用した内製化の新たな形を探りたいという旨で、中林執行役員の発言として以下の記載があった。 「これまでの内製化はアウトソーシングからの見直しが主体でした。これからは、アーキテクチャのデザインや、GitHubを活用したソースコードのガバ
国内個人開発者THIQXIS氏は12月19日、Twitter上で海外ユーザーに起きた不具合とその原因について投稿した。文化の違いに端を発する問題は開発者を中心に瞬く間に話題となり、驚きや共感の声が寄せられている。問題の原因は、国ごとでの「数字区切りに用いる記号」の違いだった。 THIQXIS氏は、モバイル向け音楽ゲーム『TAKUMI³』などを手がける国内個人開発者だ。同氏は先ごろ、自身のTwitterアカウントにて「ベトナムのユーザーから不具合の報告があり、その原因がわかった」と投稿。解決法についてゲーム開発者たちにアドバイスを求めていた。どうやら、国によって違う「数字区切りにおけるピリオドとカンマ（コンマ）の使い方」が、不具合の原因になっていたようだ。 ベトナムのユーザーさんから原因不明の動作不良の報告が来ててついさっき謎が判明しました。 まじで原因やばすぎる、そりゃcsv全滅するしスコ
同僚だったロシア人のMはとにかくすごいエンジニアで、給料について社長ともめていたかと思えば、スーパーデプロイシステムを一人で作り上げていたり、Python推しの会社の中で、各所を説き伏せてTypeScript on node.jsの導入を進めたりしていた。 皮肉屋で、だれかれかまわず議論をふっかけていたが、とにかく仕事が速くて品質がよいので絶大に信頼されていた。 私は開発者としてMから様々な教えを授けられた。当時私はPHPerあがりのひよっこで、日々ダメコードを生産していた。 ある日Mにコードレビューを依頼すると、こんなことを言われた。 「堀さん！ソースコードにコメントを書いてはいけない！」 // connect to thedatabase named "mysql" on thelocalhost val driver = "com.mysql.jdbc.Driver" val u
You too can find work as a programmer in Japan!Programming and software development is one of the few fields where non-Japanese can find great jobs in Japan. But in order to work in Japan,it is essential to learn theJapanese language. Especially, one must know the lingo used in the field where one is working -- namely software! For this purpose, I have gatherednotes during my four years worki
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
