手が痺れるエンジニアを支える技術
こちらに触発されて「そういや俺も手が痺れて色々やってたしな、共有したろ！」と思い筆を取りました。 過去形っぽく書いていますが今でも油断して悪い姿勢で作業し続けると痺れが再現します。 ひどい時は無理せず休みましょう。 手の痺れの原因 手の痺れと一口に言っても原因は実に様々ですが、痺れている部位でどの神経が痛めつけられているかわかるので、それである程度特定することができます。 私の場合は主に手の外側、小指と薬指が痺れる範囲でした。 この範囲の場合、圧迫されているのは尺骨神経という神経のため、考えられる疾患としては肘部管症候群、胸郭出口症候群、頚椎ヘルニアのあたりでした。 引用: 尺骨神経とは？解剖・支配筋・感覚枝 https://www.doctor-1.com/archives/2110 色々MRIやらCT取っても確定診断は出なかったのですが、後述する分離型キーボードを導入してかなり楽になっ
社内システムを外注する際のポイント
私分かりませんから全てお願いしますは止めろコンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。 自社の業務は理解しておけAccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ？別に業務フロー寄越せとか言ってないぞ。 要求を理解しておけ割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ？」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ！」とキレる役職者まで。コンサルは契約
ゲーム開発未経験、たった4人のチームがなぜ全世界75万本のゲームを作り上げるに至ったのか？──病み系女子育成ADV『NEEDY GIRL OVERDOSE』のはじまりからおわりまで。
ゲーム開発経験のない、ディレクター兼開発者、原案・シナリオライターのチームで75万本を売り上げたインディーゲーム──日本発のインディーゲームとして、異例の実績の『NEEDY GIRL OVERDOSE』ですが、Switch版の発売、おめでとうございます。いま累計でどれくらい売れてるんでしょうか？ 斉藤大地氏（以下、斉藤氏）： ありがとうございます。売上は全世界で75万本です。 ──そんな『NEEDY GIRL OVERDOSE』はどのようなチーム構成で作られたのですか？ メインチームは4人と聞いていますが。 斉藤氏： 全員いわゆるゲーム業界はほぼ未経験で、まずゲーム開発経験が1度もないディレクター・開発・デザインのとりいさん。ブログやツイッターが人気のライターの原案・シナリオのにゃるらくん。もちろんゲーム開発経験はありません。 次いでDLsiteでエッチなドットゲームを作っていたグラフィッ
「まずは小規模なゲームから」に聞き飽きた人のための中規模ゲーム制作手法｜MetaFormingPro
■前説この記事は、Unityゲーム開発者ギルド Advent Calendar 2022に投稿した記事をリファインしたものとなります。UGDGアドカレは他にも知見になる記事が多くあるので興味ある方は見てみましょう。 ■前節みなさん、ゲームを作ったことはありますね。 みんなゲーム作ってる人ではない？ そうですね。 でもたぶんここ読んでる人の多くは一本位はゲームを完成させている人だと思います。 というかそれが前提です。 ところで、ネット上の多く存在するゲーム制作講座、何かしら読んだことがあると思います。 そしてそのほとんどの場所で、「初心者」向けにこういっているでしょう。 「いきなり大作を作ろうとしないで、まずは小さい作品から😊😊」 うるせえ！！ 俺はもうそこは通り過ぎたんだ！！ そこはもう通り過ぎたから、まとまった規模の作品を作りたいんだ！！ となる。 そう。「入門講座」は小規模ゲームを
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
機能は追加すればいいというものではない
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
機械学習システム開発と運用の落とし穴
クローズドで行われた勉強会の資料です、画像認識まわりでありがちなハマりどころについて解説しています
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
開発に使える脆弱性スキャンツール - NTT Communications Engineers' Blog
この記事は、 NTT Communications Advent Calendar 2022 7日目の記事です。 はじめに こんにちは、イノベーションセンター所属の志村と申します。 「Metemcyber」プロジェクトで脅威インテリジェンスに関する内製開発や、「NA4Sec」プロジェクトで攻撃インフラの解明・撲滅に関する技術開発を担当しています。 今回は「開発に使える脆弱性スキャンツール」をテーマに、GitHub Dependabot, Trivy, Grypeといったツールの紹介をさせていただきます。 脆弱性の原因とSCAによるスキャン 現在のソフトウェア開発は、多くのOSSを含む外部のソフトウェアに依存しています。Python、Go、npm など多くの言語は、様々なソフトウェアをパッケージとして利用できるエコシステムを提供しており、この仕組みを利用してOSSなどのコンポーネントをソフト
スケジュールの見積もりを適当に答えたらコミットメントにされる問題について｜きゅーい / koyo
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの？出来なかったらどうするの？」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
学習を日常の開発に取り込むこと - Mitsuyuki.Shiiba
去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
いわゆる受託開発における「プログラミングは簡単な部類」は本当なのか - Qiita
上記ツイートについて、いわゆる「受託開発企業」で働く私の印象としては、本当にその通りだな〜と思います。 そして、これまであまり意識しておりませんでしたが「受託開発における納品（完了）までの各フェーズ出し」をしてみようかと思います。 受託開発における納品までの各フェーズ出し １. 問い合わせへの返答 「お問合せいただきありがとうございます。それでは早速Webミーティングにて詳細を」 ２. 第１回Web打ち合わせ「お互い紹介」編 会社スライドにて自社紹介。依頼内容の確認・質問。 できればここで「依頼内容に対してのざっくりの予算感」をさりげなく聞きましょう。奇想天外な予算を想定しているパターンもあります。 ３. 見積もりの作成 できるだけ素早く見積もりを作成し提出すると吉。（早いと喜ばれやすい） 保守費用についても記載してくださいね。（後で聞かれるパターン多い） 見積もり項目は細かい方が信頼度は
30分でわかるFour Keysの基礎と重要性
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
アマチュア向けゲーム開発環境を13年前と比較すると - ABAの日誌
昨今の自作ゲーム向けハンドヘルドゲーム機を調べたついでに、13年前の2009年にアマチュア向けゲーム開発環境について書いていたことを思い出した。 せっかくだからハンドヘルドゲーム機以外についても、ここ13年でどういう変化があったか、知っている範囲で書いておこうかと思う。 PC 王道。最先端のCPU, GPUを使ったゲーム開発が可能。言語、ライブラリもお好みしだい。欠点としては、ゲームが実行される環境があまりにバラバラなので、環境依存の問題がおきやすいことと、統一したゲーム配布プラットフォームがないこと。アマチュア向けSteamみたいのがあるといいんだが。 Unity、Unreal Engine、Godotを代表とするゲームエンジンを使うことが標準となった。DirectXを直接さわってごにょごにょみたいなことはだいぶ減ったと思う。ゲームエンジン本体の豊富な機能と、付属するアセットストアがゲー
ゲーム開発で使えるオープンソースソフトウェア個人的まとめ - Qiita
恐らく最も有名なOSSのゲームエンジンです。 UnityやUE5の代替となるソフトウェアです。 Godot以外にもOSSのゲームエンジンはいくつかありますが、現状実用に耐えうるのは恐らくこのゲームエンジンくらいです。 3D,2D双方の開発ができ、多くのプラットフォーム向けに出力できる、UnityやUE5に引けをとらない出来のソフトウェアです。 特徴は以下の通りです。 OSSかつ無料である すばらしい。 ゲームエンジン自体がかなり軽い(2桁MBくらいしかない) その分起動もかなり早い。この手軽さはやっぱり便利。 有名なゲームエンジンと比べ後発であるためUIが洗練されている 例えばUnityではオブジェクトにコンポーネントを足していくという感じですが、Godotは全てがノードでありシンプルな設計です。 エディタが内蔵されている 外部エディタは必要なく、全てGodot内で済ませられます。 基本的
Clean Craftsmanshipで感じたソフトウェア開発者に求められる職人気質
開発プロセスより大事なことこのような背景からClean Craftsmanshipの発売を楽しみにしていました。 Clean Craftsmanshipの概要Clean Craftsmanshipについて簡単に紹介します。 Marc AndreessenのWhy Software Is Eating the Worldが示す通り、ソフトウェア開発者が世界に持つ影響力は日に日に大きくなっています。 また、ソフトウェア開発の最も有名な手法の1つとしてアジャイルソフトウェア開発宣言があると思います。 本書は、このような世界でアジャイルソフトウェア開発宣言では触れられていないソフトウェア開発者のクラフトマンシップ（職人気質）について書かれた本です。 Clean Craftsmanshipの感想本書の中で、プログラマーが関係する事故としてボーイング737 MAXの事故やトヨタの急加速事故などが紹介さ
ゲームの売上予測に役立つツールキットと資料のリンク集
[本記事は、GameDiscoverCoニュースレターの日本語翻訳です。GameDiscoverCoの許諾を得て翻訳・掲載しています。] ゲームをいかにプレイヤーから認知してもらうかが成功に関わりますが、そのためにもあらかじめゲームの予算計画と売上予測をするべきです。開発者が予算計画と売上予測をしなかったとしても、パブリッシャーは必ずしています。では、開発者として投資収益率をどう予測すれば良いのでしょうか？また、パブリッシャーや出資者はどう考えればよいでしょうか。今回の記事は売上予測の”間違った”計算方法と、予測のポイントを紹介します。 まず、パブリッシャーと開発者の前提状況を整理しましょう。 まず、当然ではありますが、パブリッシャーはリスクを管理するため、様々なゲームを取り扱っています。そして、現代の市場では、パブリッシャーの扱っているゲームのうちヒットは少数で、その少数のヒットから稼い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
yusuke56.eth / Coincheck on Twitter: "新規事業をやる時に見返している「ソニーの開発18ヵ条」 https://t.co/0rLHXsu390"
