タグ

開発に関するmurapongのブックマーク (14)

  • ロックスターになれなくてもいい。ソフトウェア開発に長く携わる技術「メタエンジニアリング」とは - Findy Engineer Lab

    Developers Summit 2020に登壇 こんにちは! 塩谷啓(@kwappa)と申します。ヘイ株式会社(2022年10月よりSTORES 株式会社)のエンジニアリング室という部署で、マネージャーをしています。 エンジニアとしてのキャリアを家庭用ゲームソフトの開発からスタートし、SESや受託開発を経て、いくつかのWebサービスの会社で働いてきました。2011年ごろから、エンジニアリングと並行して採用の仕事も担当するようになり、現在ではマネジメントとメタエンジニアリングを主な業務領域としています。 並の腕前のエンジニアが発見した新しい適性 ごく平凡なエンジニアであることの焦燥感 突然の採用担当 メタエンジニアリングのめざめ 技術広報・採用・組織開発でそれぞれ何をするのか? 技術広報 ─ アウトプットを実現して社外から信頼を得る 採用 ─ 公開情報のメンテナンスと選考プロセスの整備

    ロックスターになれなくてもいい。ソフトウェア開発に長く携わる技術「メタエンジニアリング」とは - Findy Engineer Lab
  • 「家庭用ゲーム機へ移植不可能」とされた『片道勇者』がNintendo Switchデビュー。難しすぎる移植はいかにして実現されたのか? - AUTOMATON

    ホーム インタビュー 「家庭用ゲーム機へ移植不可能」とされた『片道勇者』がNintendo Switchデビュー。難しすぎる移植はいかにして実現されたのか? 弊社アクティブゲーミングメディアが運営するパブリッシングブランドのPLAYISMは6月18日、個人デベロッパーSmokingWOLF氏が開発した強制横スクロールRPG『片道勇者プラス』をNintendo Switch向けに配信開始した。価格は税込1500円。作はもともとフリーゲーム『片道勇者』としてリリースされたタイトルで、2012年8月に配信されるや否や瞬く間に熱狂的なフリーゲームファンに受け入れられ、数十万のプレイヤーが“左から迫る闇から逃れながら”魔王を倒すことに夢中になった。稿の趣旨はインタビューであるが、インタビューに入る前に、移植における紆余曲折を説明させていただきたい。 移植が困難と思われたウディタ製ゲーム インディ

    「家庭用ゲーム機へ移植不可能」とされた『片道勇者』がNintendo Switchデビュー。難しすぎる移植はいかにして実現されたのか? - AUTOMATON
  • コードの品質を維持したまま開発スピードを上げる | POSTD

    高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる

    コードの品質を維持したまま開発スピードを上げる | POSTD
  • 開発フロー研修 @ Wantedly - Qiita

    Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

    開発フロー研修 @ Wantedly - Qiita
  • 【前編】CTO不在で、開発組織改善に着手! 一休のエンジニアが語る苦悩の1年

    Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏(@naoya_ito)。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第四回のゲストは、伊藤氏が現在、技術顧問として就任し、開発部門の組織改善を行っている『株式会社一休』のエンジニア、宿泊事業部のシステム開発部の部長である笹島祐介氏(写真中央)と開発組織改善の発起人である田中健介氏(写真右)の2名が登場!CTOが不在の開発現場で10年以上前からサービス提供している、そんなよくある状況の中、どのように現状の改革に挑んでいるのか――苦労話も炸裂し、現役エンジニアには興味深い話が展開されることに!お楽しみに! — 伊藤直也(以下「naoya」):とりあえず乾杯しましょうか。 — 笹島祐介(以下「笹島」)&

    【前編】CTO不在で、開発組織改善に着手! 一休のエンジニアが語る苦悩の1年
  • エンジニア向け絶対に挫折しない個人サービスの作り方

    エンジニアが一人で個人サービスを作ろうとすると、途中で飽きちゃったり、技術で詰まっちゃたりして、なかなか作りきれないことよくありますよね?つまずいてしまうポイントをうまく回避して最後まで作りきって公開まで持っていく、エンジニアだったら誰でも実践できるコツを教えます。 4/18 Creators Meet Up発表。

    エンジニア向け絶対に挫折しない個人サービスの作り方
  • Machinationの紹介

    Game Community Summit 2013 でお話しさせていただいた Machination 話のスライドです。 上記スライドの「DEMO」の段階で用いたマキネーションのファイルは次のリンクからダウンロード可能です。マキネーションツールの File > Open からロードすることができます! - https://dl.dropboxusercontent.com/u/1534057/GCS/2013/soul_01.xml - https://dl.dropboxusercontent.com/u/1534057/GCS/2013/soul_02.xml - https://dl.dropboxusercontent.com/u/1534057/GCS/2013/soul_03.xml

    Machinationの紹介
  • ソースコードの品質向上のための効果的で効率的なコードレビュー

    ちゃんとした C# プログラムを書けるようになる実践的な方法~ Visual Studio を使った 高品質・低コスト・保守性の高い開発

    ソースコードの品質向上のための効果的で効率的なコードレビュー
  • コードレビューについて - camlspotter’s blog

    このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや

    コードレビューについて - camlspotter’s blog
  • configの話 - がるの健忘録

    で、ついでにconfig関連のおいちゃん的見解。 端的には「いいじゃん一カ所にまとめなくても」。 んと…分解して。 DRYはとても大事だと思うです。ここに異論はなし。 ただ、現実問題として「ン千行とかのconfigファイル」を見るにつけ、なんていうか「倦んずあり」なんですわ、正直。 過去にみたconfig、いくつかの設定が「2度も3度も書かれていたり」して、明らかに「管理できてない」感じだったし。 で。 そんなこんなを経て、「これくらいがちょうどよくね?」的な落としどころを考えてみました。 っつかおいちゃん自身は大分前からこのパターンなので、一度書いておこうかなぁと思ってね。 今、絶賛「暗黙知を形式知に変換すること推奨期間」なのでw ・「運用さん」とか、プログラマ以外が変更する可能性のある設定 問答無用でconfigに。できれば、形式も「name=value」のような、わかりやすいものにし

    configの話 - がるの健忘録
  • 継続開発のススメ 2012-06 版 - Twisted Mind

    変更履歴 2012-06-24 ドキュメントの所に *diag シリーズについて追記 概要 開発があればリリースがあり、リリースが終われば、メンテナンスがあり、さらに開発があります。プロダクトが EOSL (End Of Service Life) を迎えるまではこれを続ける必要があります。 去年の 8 月に「継続開発のススメ」というので、やっていることをまとめたのですが約 1 年経ってもう少し細かくまとめて見ようと思いました。基的には自分がいる環境を前提に書いてます。 継続開発のススメ http://d.hatena.ne.jp/Voluntas/20110823/1314036482 開発スタイルは常に変化し続けていくべきだと思っています。これだ、というのを作らないのが一番良い開発スタイルでは無いかなと。 脳内を書き出しているので、日語がおかしい上に一貫性が無いと思います ...

    継続開発のススメ 2012-06 版 - Twisted Mind
  • Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用

    Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用 急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。 Pythonで開発し、Amazonクラウドで運用 1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。 PinterestPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえま

    Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用
  • 継続開発のススメ [Python 温泉編] - Twisted Mind

    とりあえず書き出してみました、これから色々修正します。 こうしたら良いと思う、こうしたら良かったの両方がごちゃごちゃっとなってますが、あくまで考え方なので銀の弾丸ではありません。 #bucho Python 温泉で @torufurukawa と色々話しをしました、いい機会なのでまとめてみます。 自分が色々やっている中で、こうした方がいいと思いますという内容がほとんどです。 @torufurukawa がエントリあげてました、実践的な話しなのでオススメです。 Even More Addicted to Indentation: Python 温泉で開発プロセスの教えを乞う 銀の弾丸はない 開発手法にベストプラクティスはありません。環境、仕事内容、人によってそれぞれでしょう。 そのため、今回書かれていることが銀の弾丸になる事はありません。 開発手法は固定するモノではなく、常々変化するモノです

    継続開発のススメ [Python 温泉編] - Twisted Mind
  • MVCの議論で思い出したこととか | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記

    みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー たまにPython自体の技術コンサルみたいなことを頼まれることがある。プロダクトのコードを読ませてもらって,改善点を指摘したりするようなことをやる。 ただ,純粋にPythonにかかわるアドバイスって最初のうちだけで終わってしまい(Pythonは覚えること少ないからね),だんだんと設計みたいな部分に切り込んでゆくことになる。フレームワークを使ったコードで当によく見かけるのが「分厚いコントローラに薄いモデル」みたいな設計。もっと進んで「分厚いテンプレート(ビュー?)に薄いコントローラとモデル」というのもたまにあるんだけどあまりない,かな。 で,そういう場合は「テスト」を軸にして,設計上コ

  • 1