こんにちは！たけぴです。
Call of Duty Warzoneが先日リリースされました！
現在、PS4/Xbox One/PC向けに配信されています。
リリースから3日間でなんとプレイヤー数は1,500万人を突破したそうです。
これはApex Legendsを超える勢いだとか。
他のバトロワ系ゲームから良い所を取り込んで進化させたCall of Duty Warzone。
他のプレーヤとの実力差が如実に現れてしまうところが競争心を掻き立てる面白い点でもあり、人によってはすぐ諦めてしまう弱点にもなっていそうです。
もう少しやりこんだらまたリポートしたいと思います。
そんなCall of Duty WarzoneをさらっとファーストプレイしてみたESPNの記事はご参考まで。
こんにちは！たけぴでっす。
男は皆、スピードを追い求める生き物。。GPUも例外ではないと思うたけぴであります。
それはさておき、私、最近のコンシューマモデルのマルチGPUの事情にあまり追いつけていないのですが、AMDのCrossFire技術って今後もう注力しないらしいですよ。
（昨年の半導体カンファレンスでAMDのCEOが言っちゃったみたいなので）
CrossFireと言えばNVIDIAのSLI技術と同様に複数のビデオカードを刺して性能UPを図るもの。
今後注力しないのは一言でいうとそこにマーケットがないから（ゲーミング市場での話）、ということかと思うけどその理由は、
・最近はシングルGPUで4K/高FPSがでるからマルチにする必要性があまりない
・異なるグラボで同様の効果が出せない。（対応していないマザーもある）
・なのでゲームデベロッパーが対応する旨味を感じてくれない。
このあたりが原因かなぁと思うが、確かではない。調べて何かわかったら別の機会にリポートしましょうかね。（誰か詳しい人いたら教えて）
また噂では、Intelが2枚のカードを適切にスケーリングする実装をするべく、マルチGPUで特別なことを計画している可能性があるとか。。
techraderから、今どきの2枚刺しの性能UP等を確かめた記事が参考になります。
こんにちは！便利なアプリにいつも飢えているたけぴです。
Pixelmator、低価格な画像加工ソフトとして僕もお世話になってマス。
iOS用のPixelmatorがメジャーアップデートして機能追加する話題が持ち上がっています。（開発を止めた訳ではないとのこと）
新機能は新しいファイルベースのドキュメントブラウザー、画像サイズのプリセットと写真ブラウザです。
iPhone用としてはiPadやPCより画面が小さい分、ブラウジング機能を強化するんですね。
Mac用のPixelmator ProとPixelmator Photosもさらに使いやすくアップデートされるそうです。
AdobeのソフトもiPad対応が進んだり、マーケットも変化してきているようですが、PCアプリをタブレット等でも使えるようにするという話はやはりUI/UXをどれだけ活かすかというのが重要なポイントかなと思います。
参考：Cult of Macの記事
こんにちは！たけぴです。
ゲームタイトルが有名になればなるほど次回作が気になってしまいませんか？
そんなユーザの期待が膨らむと、デベロッパー間の大物プロデューサーの移籍も話題になりますね。
日本では数年前コナミを離脱し「コジマプロダクション」を設立した小島秀夫氏が大きな話題になりました。
今回はDiablo4開発のために移籍したプロデューサに絡む話題。
Diablo4といえば昨年Blizzcon 2019にて発表があったDiabloの次期最新作。 次回作はオープンワールドでPvP要素が追加されるそうでPC/PS4/Xbox Oneでリリースされる予定です。
リリース日は2021年以降になると予想されています。
GearsスタジオThe Coalition（※2）の元ヘッドであるRod Fergusson氏は、ブリザード（※1）のDiabloチームを率いてDiablo 4を開発するために最近辞任しました。
Fergusson氏はゲーム開発で長いキャリアを積んでおり、BioShock Infiniteが大まかなパッチを当て終えたことを支援したことで有名です。 その後、彼は2K（※3）でマフィア3になるゲームに取り組み、最終的には創造性の違いのためにそこを去り、その後ブラックタスクのマネージャーになり、後にThe Coalitionに移りました。
ちなみにRod Furgusson氏は
Day 1 - let’s raise some Hell! #Diablo #BlizzLife pic.twitter.com/ajg96fU3Qs
— Rod Fergusson (@RodFergusson) 2020年3月3日
このような方です。ワイルドだ！
参考：GAMESPOTの記事から
==
（※1）ブリザード：ブリザード・エンターテイメントは、アメリカのゲーム会社
（※2）The Coalition: バンクーバーに拠点を置くXbox Game Studiosのスタジオ
（※3）2K: テイクツー・インタラクティブの子会社で、テレビゲームの販売を行う企業
こんにちは！たけぴです。
皆さんは普段スマートウォッチを着けていますか？
最近は本当に色々なスマートウォッチが出ていて、たけぴもよくチェックしているんです。
電車とか乗っていてかっこいいスマートウォッチ着けている人を見るとついチラ見してしまいます。
スマートウォッチのたけぴ的チョイスポイントは
・外観デザイン
・バッテリー持ち
・動作速度
・軽さ、適度な大きさ
といったとこですね。
今回紹介するSkagen Falster 3もなかなか魅力的です。
参考：Pocket-lintのレビュー
こんにちは！たけぴです。
ソフトウェアエンジニアの皆さん開発プロジェクトでチームリードに悩んでいませんか？
開発リーダやマネージャ以上の方はどうやって上手くプロジェクトを回すか、という問題に直面することは少なくないかもしれません。
プロジェクトの構造定義とか開発プロセスの提案とか、ややもすると「めんどくさい」と思ってしまうかもしれませんね。
そんな悩みに対するヒントになればと、今回はDEVELOPER by Andrea Medda の記事をお届けします。それではどうぞ！
小規模で独立したチームで作業することは、エンジニアにとって難しい場合があります。 フィンテックセクターの急成長企業であるカーブのエンジニアとして経験して分かったのですが、チームごとにまったく異なるアプローチを使用する傾向があることがあり、チームの移動とチーム間のコミュニケーションが課題になります。
カーブでは、プログラミングにGolang（または略してGo）を使用します。 Goは、シンプルで信頼性の高い効率的なソフトウェアを簡単に構築できるオープンソースのプログラミング言語です。
複数のチームでオープンソース言語を使用すると、独自の課題が発生する可能性があります。 たとえば、構造の違いやさまざまな規格への適合から多くの問題が発生します。 すべてのプロジェクトがベストプラクティスに従うことを保証しながら、高いコード品質基準を維持しようとするのは困難な場合があります。
定義済みのプロジェクト構造をチームと共有すると、このような課題を克服できます。 また、Goなどのオープンソース言語を使用する場合は生産性も向上します。
これが発生すると、すべてのプロジェクトがより似たような外観になり、チーム間の移行がはるかに簡単になります。 また、経験豊富なGopher（Goのエンジニアと呼ばれます）は、関連するファイルやディレクトリを見るだけで何が起こっているかを知ることができるため、プロジェクトメンバーが貢献するのも簡単です。
明確に定義されたプロジェクト構造は、確立された標準に従うことが容易であるため、新しいGo開発者にも役立ちます。 新しいチームメンバーは、サービスの動作を学習する必要なく、変更を加えて他のプロジェクトに複製することができます。
問題は、組織でこのような仕組みをどのようにして確立するかです。
あなたの配置された立場では2つの選択肢があります。 1つ目は、go-kitやgo-microなどのフレームワークを使用して、構造とアプローチを提案することです。
このタイプのフレームワークを使用する利点には、すぐに使用可能なユーティリティ（ロギング、トレース）、および事前に合意され、コミュニティとオープンに共有されている標準が含まれます。ただし、この方法にはいくつかの欠点があります。それはこのようなフレームワークには多くの定型文が付属しており、コアコンポーネントに変更を加えることは困難であるということです。また、コミュニティによって管理されているという事は、変更を待つ時間が長すぎるため、バイナリのサイズが大きくなることも意味します。
2番目の選択肢は、単純に会社レベルでプロジェクト構造に同意することです。これを行うことで、あらゆるアプローチやライブラリを自由に使用でき、迅速な変更を行い、バイナリを小さくし、慣用的なGoを簡単に追跡できます。これの潜在的な欠点は、これらの変更に同意して適用するプロセスを促進するために、会社のエンジニアリング文化が十分に成熟している必要があることです。このような長く退屈なプロセスにより、仲間のエンジニアは価値があるかどうか疑問に思うかもしれませんが、一部の標準は自然に発生し、時間とともに進化します。詳細を確認した後、合意された標準を再検討することは何の問題もありません。
カーブでは、この2番目のアプローチを選択したのですがこれには課題がありました。たとえば、複数の会議と長い議論のため、合意プロセスには数ヶ月かかりました。急成長企業では、これは生産性レベルに大きな影響を与えてしまうでしょう。また、明確なフレームワークがないため、チームは通常「すぐに使える」要素を手動で実装する必要があり、場合によっては、複数のサービス間で誤ってコードが複製されてしまうこともありました。
多くの場合、開発しながら学習し、ほとんどの決定はエンジニアの日々の経験に基づいてフィードバックを受け取った後に行われました。それはコミュニティに注目しながら、また他の成功したGoベースの企業が何を行うかを調査しながらでした。
この方法を採用することで、時間の経過とともに大幅に改善されました。コアチームのエンジニアで構成してGo関連の決定を行うために、「Goチャプター」というものを設置しました。彼らは数週間ごとに会合を開き、関連するトピックについて議論し、新しい標準の採用案に投票します。次に、すべてのチームがすべての新しいサービスにそれを採用し、プロジェクトをリファクタリングする時間を自律的に割り当てて、プロジェクトをフォローします。
プロジェクト構造に関しては、採用する前にすべてのトピックについて何度も議論します。 また、ビジネス目標を確実に達成するために、必要に応じて何度でもプロセスを修正および変更します。
これまでのところ、この新しいアプローチは私たちにとってうまく機能しています。 これは、高品質で安定したサービスをより頻繁に出荷できることを意味し、譲渡を簡素化できます。 これにより、すべてのエンジニアが何をすべきか、問題を解決してバグを見つける方法を簡単に知ることができます。
ただし、次の2つの欠点も確認されています。
・レガシーサービスのリファクタリング
・既存のサービス全体に変更を置き換えること
後者については、最近、ログ記録と監視の戦略を見直し、それに従うためにすべてのサービスに関わる必要がありました。
これまでのところ、このアプローチの維持は比較的簡単です。エンジニアは、構造とコードの再利用に関連するサービスの問題を解決しようとして、新しいより良い方法を見つけるかもしれません。実験してチームメイトからのフィードバックをもらったら、エンジニアは「Goチャプター」で提案できます。
最近の例では、grpcではなくhttpまたは両方の可能性があるサービスを使用する必要性に基づいて、トランスポートレベルを分割することを決定したことです。これを容易にする素晴らしい方法を発見し、承認されました。
このプロジェクト構造は、チームや会社が十分に成熟しており、サービスを学習して改善したいがために間違いを犯してしまう場合にも有効です。明確なコミュニケーションと努力が必要ですが、最終的には合理化されたプロセスに取り組む価値があります。
