技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
フロント学習の最高の教材集 - Qiita
はじめに 今回はフロント学習で重宝できる教材をまとめました。 軽く自己紹介として、自分は新卒でフロントエンジニアとして入社し2022年で2年目になります。 実際に実務を通す中で「この教材のおかげで実装がスムーズにできた」「この教材をやってたおかげで理解ができた」といったような場面が2年の間で多々ありました。 今回紹介する教材は自分自身が実際に使ってよかったものかつ、そのほとんどが無料で学べるor低価格の教材になっています。 「フロントエンドを網羅的に学べかつ実務の基礎作り」という目的で教材を紹介します。 この記事の主な対象者 フロントエンドの学習をこれからしていきたい人 何を学べばよいのかがわからない人 HTMLとCSSはある程度かける人 この記事の目標 フロント学習の指針が立てられる 実務現場でも活用できるスキルを学べる教材を知れる JavaScript ドットインストールのJavaSc
決済ステータス定義の最適解
ネットスーパーシステムの決済ステータス表現 (状態遷移) は複雑だ。 その理由は要求要件が多いことに起因しているが、多いことが悪いのではなく、それに応えなければシステムとして真の価値を発揮できないからで。逆に問題解決できなければ、著しく利便性を落としてしまうので、必須要件という位置付けにある。 前提文脈を汲み取りづらいモデリングなので、問題解決例を示すのはあまり見かけないが、自分が考えた決済ステータス定義の答えを示す。 この内容は過去にブログや登壇で話した内容の延長でもあるので、過去の内容も参考にすると良いかもしれません。 「E-Groceryにおけるカード決済処理の難しさと設計戦略」 「ネットスーパーの買い物体験を支える工夫と決済機能実現の過程」 前提条件 注文から支払い完了まで時間差がある注文後に注文内容の変更ができる品切れが発生するケースがある販売員が注文内容を変更できる0円での支払
30歳エンジニア転職で役に立たなかった経験と役に立った経験 - Qiita
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか？ と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん（転職した人）の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか？ ・AWSなど
個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
Flashエミュレーター誕生のきっかけは別に「フラッシュ愛」じゃなかった 「swf2js」開発者の本音と数奇な運命【フォーカス】
株式会社ソニックムーブ エンジニアグループ ソリューションユニット マネージャー 家永 稔之 2011年にソニックムーブに入社。個人ではJavaScriptとTypeScriptを用いて、「swf2js」や「Next2D」の開発を手がける。業務のリモート化をきっかけに地元の消防団に所属し、防災活動として月に数回、消防車両に乗って地域の巡回を行う。 X GitHub Animation Tool かつてインタラクティブなWebコンテンツを支えた「Adobe Flash」。「Adobe Flash Player」は2020年12月末でサポートを終了し、ほとんどのコンテンツはすでに姿を消しました。そんなFlashコンテンツ（SWF）を最新のHTML環境で再生可能にする、オープンソースのJavaScriptライブラリが「swf2js」です。ソフトウェアエンジニアの家永稔之さんが開発し、2015年に
魅力的なキャラクターはいかにして生まれたのか？ 視聴者が湧いた「hololive Live2D 3.0」の制作裏側とプロジェクトマネジメント【alive 2023セッションレポート】 | GameBusiness.jp
2023年12月1日に秋葉原UDXで開催されたイベント「alive 2023」。Live2D社が主催するこの大型イベントはLive2Dのクリエイターを対象にしたもので、数々のセッションや展示コーナーを設置してクリエイターの交流を図っていました。 ホロライブプロダクションを運営するカバー社は、そのセッションのひとつ「Live2Dを使用したプロジェクトをどのように進めたか （hololive Live2D 3.0参考例）」に登壇しました。 VTuberの世界では配信に使用するアバターとして重宝されているLive2Dですが、多くのクリエイターが参加する大規模な制作プロジェクトについて解説される機会は少なく、詳しく知らない人が多いはず。 本セッションではそのプロセスを企画立案からクロージングまで解説するとともに、ホロライブでは最新バージョンとなる「hololive Live2D 3.0」の実例を示
メンテのいらないソフトウェア - 誰かの役に立てばいいブログ
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
コンパイルハートが10月1日から新体制に移行。『魔導物語4（仮）』など新作5タイトルを発表！ これからの事業方針についてふたりのトップクリエイターにインタビュー!! | ゲーム・エンタメ最新情報のファミ通.com
新体制のふたりの取締役兼プロデューサー ――2023年10月からコンパイルハートの経営体制が変更になったとお聞きしました。まずはおふたりのお仕事の内容についてお話いただけますか？ 冨長10月1日付から取締役社長ということで、コンパイルハートのとりまとめをすることになりました。役割としては、開発からマーケ・販売までの全般を見てはいますが、ハイ・コンセプト（チャンスを見出し、新しいモノを生み出す）を決めるというのがおもな仕事となっています。 ――ちなみに、冨長さんが全般的に見ている社内の開発部や制作部といったところには、新体制で何らかの変化はありますか？ 冨長開発部はコンパイルハート内製ラインで、制作部は社外の開発さんといっしょに制作するラインですが、そのへんは変わってないですね。 ――なるほど。冨長さんはこれまでどんなお仕事をされてきたのでしょう？ 冨長じつはですね、私、広島にあったコンパイ
小さなゲームを作ること、それ自身が楽しいのだ - ABAの日誌
小さなゲームとは何か。スモールゲームマニフェスト（宣言書） 1 によれば、1プレイが10分以内に終わる、ブラウザなどで手軽に遊べるゲームを指す。 その定義で言うと、私は小さなゲームをすでに350個以上 2 作っていることになる。1年間で139個作ったこともある 3 。無類の小さなゲーム好きだ。 小さなゲームの何が良いって、短時間で作れるのが良い。速くて2時間、ちょっと苦戦しても10時間くらいではできるだろう。アートワークなどを凝り始めるといくらでも時間はかけられるが、ここでは1週間に1つゲームを作る、Game a week 4 のような取り組みでできる規模の、開発者目線でも小さなゲームとしたい。 短時間で作れるということは、いろんなアイデアを簡単に試すことができるということだ。「ヘンテコにおもしろい小さなゲームを作ろう」 5 というエッセイを、「ゲームクリエイターが知るべき97のこと2」と
インシデント共有方法に格の違いを感じ勝手に敗北感を味わった話 - Qiita
私は普段、お客様のチームに入り込み、SEとして仕事をしております 今日はそのチームで実際に起こった出来事からなぜか勝手に敗北感を味わった話をしたいと思います まずなにがあったか 普段すでに本番運用がされているシステムに新規要件を実装してまして、定期的に新機能をリリースするようなそんな運用となっています そんな中のある日、定例（朝会）の中で、直近リリースで発生したインシデントの共有がありました えーっと実は昨日〇〇という障害が本番環境で発生してその対処をしてました 調べてみた結果、原因は〇〇さんのこのプルリクでして （私：おいおい個人名だすのか！！ このファイルのこの行でNullチェックが漏れてました （私：わわわわ、公開処刑だぁぁぁ まぁたしかにこの辺はほげほげふがふがで （私：ふむふむさすがにフォロー入るかぁ でもテストやレビューでちゃんとカバーしときたかったですね （私：全員巻き込んで
ABテストが難しい場合の施策効果の評価・推定方法
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。サイエンス統括本部でデータ分析による社内サービスの課題解決支援をしている関口です。 ヤフーではたくさんのABテスト（※1）が常に行われており、サービス改善に活かされています。しかしながら実際には、さまざまな理由からABテストができないことがよくあります。本記事では、そのような場合にどのようにして施策の効果を評価・推定するかについて、具体的なケースからアイデアを紹介していきます。 なお今回はYahoo!ショッピングを題材にしたケースばかりですが、アイデア自体は汎用的なものとなっています。 ※1： ABテストはウェブサービス上のUI改善、機械学習モデル改善、機能追加etc.といったさまざまな施策が、KPIにどれくらいのイン
Googleに依存しないプッシュ通知プロトコル「UnifiedPush」
新着メッセージや新着ニュースなどの情報をスマートフォンに即時通知してくれる「プッシュ通知」は、スマートフォンを使う上で非常に便利な存在です。しかし、ほとんどのAndroidアプリのプッシュ通知はGoogleが開発したプロトコルに依存しているのが現状。この現状を打破するべくオープンソースで開発されたプッシュ通知プロトコルが「UnifiedPush」です。 UnifiedPush https://unifiedpush.org/ UnifiedPush: a decentralized, open-source push notification protocol | F-Droid - Free and Open Source Android App Repository https://f-droid.org/2022/12/18/unifiedpush.html プッシュ通知は情報を迅速
「RPG Developer Bakin」、RPG制作ツールなのに発売1週間で“アクションゲーム作品だらけ”になる。愉快な現状を開発元に訊いた - AUTOMATON
スマイルブームは10月18日、「RPG Developer Bakin」（以下、Bakin）の早期アクセス配信を開始した。同作はスマイルブームによる、新たなゲーム制作ツール。プログラミングの知識を必要とせず、どんな人でもRPGを作れる……という謳い文句だが、同作ではユーザーにより、やたらとアクションゲームが作られているようだ。スマイルブーム代表取締役の小林貴樹氏に詳細を訊いた。 10月8日の配信から一週間も経たないうちに謎のアクションゲーム作品だらけになっている正統派RPG作成ツール RPG Developer Bakin のローンチセールがまもなく終了です。皆様のご協力で極端なぶっ飛び系も収まってきました。引き続き不具合やご要望のご協力をお願いいたします！#RPGBakin https://t.co/fIPBgr1ygc — 小林貴樹@SmileBoom (@notohoho) Octo
ゲーム開発者らが「初めてゲームを制作する人への、もっとも大事なアドバイス」をSNS上に続々投稿。“ある意見”だけダントツで多い - AUTOMATON
近年は、UnityやUnreal Engine、GameMakerなどをはじめとして、無料で使い始めることができるゲームエンジンがさまざま提供され、ゲーム制作のハードルはかつてより下がったといえる。そうしたツールを使って、ゲームを作ってみようという人も増えているかもしれない。初めてのゲーム作りに挑み、分からないことだらけの方も多いだろう。 インディーゲームイベントIndieCadeの公式Twitterアカウントは9月12日、「初めてゲームを制作する人への、もっとも大事なアドバイス」を、現役のゲーム開発者から募集。数多くの投稿が寄せられているため、本稿ではいくつか紹介したい。 まずid Softwareにて『DOOM』や『Quake』などを手がけたことで知られるゲームデザイナーJohn Romero氏は、小規模な作品から始めるようアドバイス。完成までやり遂げることができる規模のものを、まずは
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
個人でWEB開発を１５年くらいやってる者ですが
この記事を見てびっくりした。 https://laiso.hatenablog.com/entry/nope-sql 「個人開発のコストはDB次第」 まずビックリしたのは「DBってそんなにお金かかる？」という点。 もちろんDBがストレージ、CPU、メモリを食うのは分かる。 でもVPSならそんなにコストかからんだろう？ 俺は１日100万PVほどのエロサイトを運営しているが、WEBサーバ1台、DBサーバ1台、画像サーバ2台で動いているぞ？ VPS4台で月額6000円くらい。 次にビックリしたのは、個人開発なのに難しそうなDBサーバを使っている事。 「Cloud Firestore」「Amazon DynamoDB」「MongoDB Atlas」 ↑俺、全部知らない。。。 もちろん、こうしたDBサーバの必要性は分かるのよ。 稼働率、安定性、拡張性などなど。 でもそれって、大規模サイト向けじゃない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unity経験ほぼゼロの状態から1年半でツインスティックシューター『NeverAwake』を完成。その開発方針から具体的な工夫まで解説【IDC2023】
IT業界の日常を図にしてみたら「地獄絵図」「ウチの会社の悪口はそこまでだ！」になった→これから業界に入る人は身震い
