OBDII経由でECUをプログラミング？！

http://www.automiltech.com/shop/

OBDII経由でECUの完全プログラミングができるアブリタスの診断機

https://automiltech.co.jp/304/

https://vefortec.hatenablog.com/entry/software-car-c

その他、「ECU プログラミング」でググってみるとよい。

MISRA-Cという標準Cとは違うC言語で書かれているらしい。

愛車のTTのDSGが故障し、以前から乗り換え候補として考えていたトヨタ初代ミライ、またはホンダ二代目インサイトを購入することになる予定。(DSGの修理には最低60万円かかり、来年車検となるのでタイヤ交換、リヤブレーキパッド+ディスク等消耗品の交換を含めると１２０万円以上となりそう。それならば、中古の二代目ミライが余裕で買えるので、いっそのこと乗り換えるべき。)

ECUを書き換えてチューニングすることにより、特にミライはテスラModel3みたいに速くなるかもしれないと思い、ECUのプログラミングをかじってみたくなった。(ミライの加速は8J型TT3.2よりはるかに速い。0→60km/h加速は絶対にミライには勝てない。)→要チェック→☛👉️ECUチューニングエミュレーター、ECUプログラミングエミュレーター

もし、ECUプログラミングを習得し、プリウスやインサイトなどのハイブリッド車、ミライのようなFCEV車を自由自在にチューニングできるようになれば、大きなビジネスチャンスが生まれるだろう。

プラットフォームエンジニアとは？

某問答サイトで秀逸な回答が出たので転載する。

アプリケーションプログラマーは何かしらのOS、SDK、フレームワーク等のシステムソフトウェアの上でプログラミングをしますが、プラットフォームソフトウェアエンジニアは、これらプラットフォーム側を開発します。

具体的には、

OSの移植、

デバイスドライバーの開発、

API、SDK、ライブラリー、フレームワーク等を開発します。

特にOSの移植やデバイスドライバーの開発では、ソフトウェアの知識に加えて、ハードウェアの知識とOSの知識が必要になります。

回路図を読み、それを動作させるデバイスドライバーやOSの下層部分をプログラミングして、適切にOSに組み込み、その環境をアプリケーションプログラマーに提供します。

なるほど。

じゃあ、

アスキー出版局の

WDMデバイスドライバプログラミング完全ガイド

とか

秀和システムの

作りながら学ぶ

OSカーネル

保護モードプログラミングの基本と実践

みたいな本を読んだり、Githubで関連するソースコードを漁ったりすればよいのだな？

暴走するC++プログラム

#include <stdio.h>

int main(int argc, char** argv)

{

int i;

for (i = 1; i <=5; i--) {

printf("%d ", i);

}

printf("¥n");

return 0;

}

と書いてAndroidのIDEで実行すると…

i++は数字が1ずつ足されながら実行されていくので、実行すると1 2 3 4 5と表示されてプログラムは終了するが、i--に変えるとエラいことになる。

俺は1ずつ減りながら実行されて1 0 -1 -2 -3と表示されてプログラムは終了すると予想していたのだが。

P.S.

→間違いであることが判明。

#include <stdio.h>

int main(int argc, char** argv)

{

int i;

for (i = 100; i >=5; i--) {

printf("%d ", i);

}

printf("¥n");

return 0;

}

の様に書き換えると、iが５以上である間、100から1ずつ減っていき、5になったらプログラムが終了する。

100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 ¥n

[Program finished]

逆に5 4 3 2 1と1ずつ減っていき、1でプログラムを終了させたければ、

#include <stdio.h>

int main(int argc, char** argv)

{

int i;

for (i = 5; i >=1; i--) {

printf("%d ", i);

}

printf("¥n");

return 0;

}

と書けば良い。

予想の通りにしたければ…

#include <stdio.h>

int main(int argc, char** argv)

{

int i;

for (i = 1; i >=-3; i--) {

printf("%d ", i);

}

printf("¥n");

return 0;

}

と書くと

1 0 -1 -2 -3

となって予想通りに表示される。

短いプログラムだったが、なかなか面白かった。

組み込み系の開発ではどうして今でもC言語が使われているのでしょうか？

組み込み系の開発ではどうして今でもC言語が使われているのでしょうか？

【Quoraの質問と回答から引用】

Cは高級言語にしては珍しく、ハードウェアを直接触れるからです。例えばソフトウェアでハードウェアを操作するときには、特定のアドレスに命令を表す特定のデータを書き込むと言う操作をします。これがソフトとハードの境目なのですが、多くの高級言語では「開発者にハードウェアを意識させないのが良い」という思想なので、ハードウェアのアドレスを指定できないようになっています。

ところがCの場合はポインタ変数を使って任意のアドレスに直接書き込めるのです。この機能を使わなければハードウェアが操作できないので、他の言語では実装できないのです。

一応これはC++でもできます。しかしC++が使える組み込みエンジニアは多くありません。

それは組み込み系のエンジニアはもともとはハード屋さん出身の人も多く、ソフトウェアの知識は限定的なことが多いからです。

特にオブジェクト指向やらデザインパターンやらのソフトウェア工学の話は何回聞いてもさっぱりという組み込みエンジニアは多く、そのような技法を現場に持ち込むと黒船扱いされます。

私はそのようなハード屋に近いプログラマーと仕事をしたことがありますが、継承とかポリモーフィズムのような実際のハードウェアの動きをソフト的に抽象化されるとさっぱり理解できないようでした。

なるほど。C++ができる組み込みエンジニアはすくないのか？

じゃあ、C++で組み込み系もやろうか。

[C++]exeファイルのリバースエンジニアリングメモ

[C++]exeファイルのリバースエンジニアリングメモ

C++逆コンパイラ？

アバストが自社のマシンコード逆コンパイラをオープンソース化

C++言語で書かれた.exeファイルのみを逆コンパイルできるらしい。

C++は逆コンパイル不可能だの何だのほざいてる糞サイトがあるのだが、これはどうなんだ？と問い詰めたい！！！

テメェ等はそんなにソースコードをあばかれるのが嫌なのか？バカなのか死ぬのか？

どうせ未経験可とか未経験歓迎とか虚偽の求人広告を出してる偽装請負多重派遣の極悪ピンハネ詐欺会社のバカ共なんだろ？www

C++でJWCADの外部変形プログラムを作成

あしたから本気出す - 工作 Jw_cadの外部変形の作り方

こちらはC++でJWCADの外部変形プログラムを書いているサイト。

まずはお決まりのhello world!から。

いいね。そうこなくちゃ。

やるならやっぱりC++だな。

それにしてもAutocadじゃなくて頑なにJWCADを使い続ける時代遅れのDQN会社が多くて困る。

いい加減にAutocadに切り替えやがれ！

C++言語をC言語に変換するトランスパイラ？

http://tinqwill.blog59.fc2.com/blog-entry-68.html

正確に言うと、C++言語で書かれたソースコードをC言語としてコンパイルする、ということ。

前の記事で紹介したc2rustが使えるようになるかどうかは不明だが。

もし使えるようになるとしたらC++言語をRust言語に変換可能になるということを意味する。

ChatGPTにIDL言語をC言語に変換してもらった結果www

interactive data languageをc言語に変換する方法、interactive data languageをc言語に変換するトランスパイラがあるなら教えて。

Interactive Data Language（IDL）をC言語に変換するトランスパイラは一般的には存在しません。IDLとC言語は異なるプログラミング言語であり、IDLは科学データ処理や可視化向けに設計された言語で、C言語は一般的なプログラム開発向けに設計されています。そのため、IDLコードをC言語に変換するためには手作業でコードを書き直す必要があります。

IDLからC言語への変換は、IDLの特定の機能やライブラリに依存しており、自動化は難しいことがあります。変換プロセスはIDLコードを理解し、それをC言語で再実装することを意味します。

IDLコードをC言語に変換する場合、IDLコードの機能とアルゴリズムを理解し、手動でC言語コードに移植する必要があります。また、IDLのライブラリやツールがC言語で使用可能か確認する必要もあります。

変換プロセスを容易にするために、IDLからC言語への変換ツールは提供されていないかもしれませんが、IDLからC言語への移植に関するドキュメンテーションやリソースが存在するかもしれません。IDLの公式ドキュメンテーションやユーザーコミュニティで質問をすることをお勧めします。→ウソつきじゃんwww

1：　　pro white_or_black,　xsize,　ysize

2：　　file=dialog_pickfile(filter='*.tif')

3：　　data=read_tiff(file) 　

4：　　x=0

5：　　y=0

6：　　repeat begin

7：　　if( data(x,y) gt 127) then begin

8：　　data(x,y)=254

9：　　endif else begin

10：　data(x,y)=0

11：　endelse

12：　x=x+1

13：　if(x gt xsize-1) then begin

14：　x=0

15：　y=y+1

16：　endif

17：　endrep until (y gt ysize-1)

18：　output=dialog_pickfile(/write)

19：　write_tiff,output,data

20：　end

上記はIDL言語で書かれたソースコードである。これをC言語に変換して。

ChatGPT

IDLコードをC言語に変換することはできます。以下にIDLコードをC言語に変換したものを示します。ただし、このコードは簡略化されており、完全なエラーハンドリングやメモリ管理を考慮していませんので、実際のアプリケーションに適用する際には改良が必要かもしれません。

#include <stdio.h>

#include <stdlib.h>

// Function to read a TIFF file

void read_tiff(const char* filename, int** data, int* xsize, int* ysize) {

// Implement the code to read a TIFF file into 'data' and set 'xsize' and 'ysize'

}

// Function to write a TIFF file

void write_tiff(const char* filename, int** data, int xsize, int ysize) {

// Implement the code to write 'data' to a TIFF file with the given 'filename'

}

int main() {

const char* file = "input.tif";

int** data;

int xsize, ysize;

read_tiff(file, &data, &xsize, &ysize);

int x = 0;

int y = 0;

while (y <= ysize - 1) {

if (data[x][y] > 127) {

data[x][y] = 254;

} else {

data[x][y] = 0;

}

x++;

if (x > xsize - 1) {

x = 0;

y++;

}

}

const char* output = "output.tif";

write_tiff(output, data, xsize, ysize);

// Free memory allocated for data (not shown in the code)

return 0;

}

このC言語のコードはIDLコードを基にしており、read_tiffとwrite_tiff関数がTIFFファイルの読み込みと書き込みを行います。データは2次元の整数配列として表現されています。また、メモリ管理とエラーハンドリングを実装することも重要ですが、このコードは基本的な変換の例として参考になるでしょう。

※ついでにC#に変換してもらった。

using System;

using System.Drawing;

using System.Drawing.Imaging;

class Program

{

static void Main()

{

string inputFilePath = "input.tif";

string outputFilePath = "output.tif";

Bitmap image = new Bitmap(inputFilePath);

int xsize = image.Width;

int ysize = image.Height;

for (int y = 0; y < ysize; y++)

{

for (int x = 0; x < xsize; x++)

{

Color pixel = image.GetPixel(x, y);

if (pixel.R > 127)

{

image.SetPixel(x, y, Color.FromArgb(254, 254, 254));

}

else

{

image.SetPixel(x, y, Color.FromArgb(0, 0, 0));

}

}

}

image.Save(outputFilePath, ImageFormat.Tiff);

image.Dispose();

}

}

→やればできるじゃんwww

エラーが出るかどうかは別としてwww

プラットホームエンジニアとは？Quoraの問答記事から引用

では、どうしたら50歳でもプログラマーを続けることができるかですが、まず、専門分野を持ち、何かに特化したスペシャリストになる必要があります。受託開発の業務アプリケーションばかり書いていると、そこには確実に行けません。思考錯誤、紆余曲折の結果、私の場合は、それは、プラットフォームエンジニアでした。デバイスドライバーや、ＯＳの移植などです。ハードウェアの図面を読み、ＯＳのアーキテクチャーを理解して、チップを制御するソフトウェアです。

プラットフォームエンジニアリングとは？ChatGPTの回答から

検索結果に基づいてお答えします。"プラットフォームエンジニアリング C++" に関する情報は、特定のコンテキストに依存するため、一般的な情報を提供します。

プラットフォームエンジニアリングは、ソフトウェアやハードウェアなどの要素を統合し、システム全体を支える基盤やフレームワークを構築するプロセスです。C++は、高性能で効率的なコンピュータプログラミングのためのプログラミング言語です。プラットフォームエンジニアリングにおいてC++が使用されるケースは多岐にわたります。

以下は、プラットフォームエンジニアリングにおいてC++が使用される一般的な領域のいくつかです：

1. オペレーティングシステムの開発: オペレーティングシステムは、コンピュータの基本的な機能を提供するための重要なプラットフォームです。C++は、オペレーティングシステムのカーネルや低レベルのコンポーネントの開発に使用されることがあります。

2. ゲームエンジンの開発: ゲームエンジンは、ビデオゲームの開発において中核となる部分であり、グラフィックス、物理エンジン、オーディオなどの機能を統合します。C++は、高性能なゲームエンジンの開発に広く使用されます。→Unreal Engine

3. 組み込みシステム: 組み込みシステムでは、限られたリソースで動作するプラットフォームエンジニアリングが重要です。C++は、効率的なコードの生成とハードウェアリソースの最適な活用をサポートするために使用されます。→組み込み系の本を買い漁れ！！！ｗｗｗ

4. ネットワークプログラミング: プラットフォームエンジニアリングにおいてネットワーク通信を管理する場合、C++は高性能なネットワークプログラミングを実現するために使用されることがあります。→SNMPツールのことか？今はZabbixらしいが。

特定のプロジェクトやコンテキストにおける詳細な情報については、関連する文献やウェブサイト、ソフトウェア開発者のコミュニティなどを参照することをお勧めします。

だとよ。

なるほど完結で分かりやすいｗｗｗ

プラットフォームエンジニアの仕事とは？

プラットフォームエンジニアリングとは? | CircleCI

から引用。

「プラットフォームエンジニアリングとは？

プラットフォームエンジニアリング(Platform Engineering)とは、最近生まれたエンジニアリング手法です。モダンなソフトウェアデリバリーが抱える複雑さと不確実性を減らし、開発者の生産性を向上させることに重点を置いています。DevOps を大規模に実施する場合、開発の都合とビジネス上の優先順位をすり合わせたり、アプリケーションライフサイクル全体にわたって複雑に入り組んだツールやインフラストラクチャを手間なく管理可能にしたりといった、大きな課題が発生します。しかし、プラットフォームエンジニアリングを導入することでこれらの課題に対処できます。

プラットフォームエンジニアリングでは、プラットフォームチームがインフラストラクチャの管理を自動化し、一元管理されたテクノロジープラットフォームから信頼の置けるツールやワークフローを開発者がセルフサービスで利用できるようにします。このように開発チームの認知負荷を低減させることで、クラウドネイティブなソフトウェアデリバリーに大きな進化がもたらされます。

プラットフォームエンジニアリングの価値

プラットフォームエンジニアリングがソフトウェア組織にもたらすメリットは、運用の複雑さが軽減されることと、開発プロセスの摩擦が解消されることです。これまでは、開発した人が運用すべきという考え方があり、大規模な分散アプリケーションをクラウドに構築する場合に混乱やムダが生じていました。プラットフォームエンジニアリングは、この状況を変える堅実な考え方です。

プラットフォームチームの役割には、大きく分けて以下の 4 つの領域があります。

1. 内部開発者プラットフォームの構築
2. 重要なデリバリープロセスの標準化とセキュリティ確保
3. 社内のサービスレベル アグリーメントの設定と順守
4. チームのパフォーマンスメトリクスの監視

以下では、上述のプラットフォームエンジニアリングの各分野の詳細と、それらが開発プロセスにもたらす価値について見ていきます。

内部開発者プラットフォーム (IDP)

プラットフォームチームの最も重要な仕事の 1 つは、内部開発者プラットフォーム (IDP) を構築して、保守することです。IDP とは、組織全体でソフトウェアプロダクトの開発とデリバリーをスピーディに行うためのツール、サービス、自動化ワークフローを 1 つのプラットフォームにまとめたものです。IDP では、アプリケーションの構成やインフラストラクチャの管理の手間をサービスレイヤーで抽象化します。

重要なポイントは、IDP があることで、アプリケーションをすばやくスムーズに構築、テスト、デプロイ、監視するためのリソースを開発者がセルフサービス形式で利用できるようになることです。つまり、運用チームにインフラストラクチャをプロビジョニングしたり、チケットを解決したりしてもらう必要なく、クラウド環境のスピンアップ、テストやデプロイを自動化する CI/CD パイプラインのトリガー、ロールバックの実装、ログとビルドアーティファクトへのアクセスなどを、1 つの API や GUI から簡単に行えるのです。

プロセスの標準化と認知負荷の軽減のための “舗装道路”

プラットフォームエンジニアリングでは、一般的な DevOps のプロセスとワークフローを管理、標準化、拡張するための統合システムを用意します。つまり、リソースのカタログを吟味、整理することで、開発の手間を減らしスピードを高める “舗装道路” を構築するのです。この “道路” には、必要なときに好みのツールを使える自律性を開発者に与える効果もあります。

何百人、何千人もの開発者を擁する大組織では、自律性を与えすぎると、ツールの無秩序な増大、知識のサイロ化、コストの急騰、燃え尽きといった弊害が発生する可能性があります。”舗装道路” は、そのような弊害を発生させることなく開発チームが抱える運用の負荷を減らすことができる、実績ある確実な手法です。さらに、セキュリティ、コンプライアンス、予算管理の強化にもつなげることができます。

社内のサービスレベル アグリーメント (SLA) の設定と順守

プラットフォームチームにとって、IDP は商品であり、開発者は顧客です。IDP の導入を広げるために、サービスレベル アグリーメントで IDP の信頼性とパフォーマンスに対して高い期待値を設定し、チームが負う責任を明確にします。

IDP を安定かつセキュアに保つことは、プラットフォームエンジニアの重要な仕事です。内部システムに障害が発生すると、”舗装道路” に従わない開発者が増えるだけでなく、外部顧客に価値を提供するフローに中断が起きるおそれもあります。そのため、プラットフォームチームは、開発者の生産性と組織の顧客の満足度を維持するために、IDP の正常性とパフォーマンスを能動的に監視します。

重要なパフォーマンスメトリクスの監視

プラットフォームチームは、ボトルネックの解消や開発者のニーズに応じたプラットフォームのカスタマイズのために、スループット、ワークフローの実行時間、インシデントの復旧時間などの重要なエンジニアリングパフォーマンスメトリクスを追跡します。そして、たとえば復旧時間が基準値を超えるようになった場合には、パイプラインへの自動テストの追加や、IDP に用意している監視機能やアラート機能の改善などの対策を試します。

また、開発者の生産性やパフォーマンスに関連するデータを追跡することで、IDP が組織の開発パターンやビジネス目標に適切に対応しているかどうかも確認できます。

プラットフォームチームは必要？

多数のチームで複雑なエンジニアリングが必要とされる大規模な分散プロジェクトを進めている場合や、部門横断型のチームを編成してアプリケーションの開発、運用、インフラストラクチャを監督している場合には、おそらく何らかの形で暫定的なプラットフォームエンジニアリングを行っていることでしょう。そのような場合には、プラットフォームチームの編成を検討することをお勧めします。

プラットフォームチームの編成をお勧めする状況は他にもあります。組織に成熟した製品がある、将来に対する明確なビジョンがある、業務の規模を拡張する準備ができている、といった状況です。

また、エンジニアリングチームがクラウド統合とインフラストラクチャ運用に取り組んでいる場合も、プラットフォームチームが必要な可能性があります。検討するうえで重要となる前提条件は、各チームメンバーの役割と責任を明確に理解したうえで、エンジニアリングチームのワークフローが詳しく定義されていることです。エンジニアリングチームのサイズやプロダクトの成熟度は、必ずしも重要ではありません。規模の拡大に伴って、いずれプラットフォームチームが必要になるからです。

一方、組織規模が小さく、少人数の開発者でモノリシックアプリケーションを開発している場合は、プラットフォームチームを編成しても大きなメリットを得られる可能性は低いと考えられます。まずはプロダクトマーケットフィットの達成に注力し、反復タスクを自動化して、開発者がイノベーションに集中できる体制を整えましょう。アプリケーションを個別のサービスに分け、複数のエンジニアリングチームが異なるバリューストリームでデリバリーする段階に達したら、プラットフォームチームを編成すると、スピードと安定性の最適なバランスを実現するのに役立ちます。

CI/CD を使ったプラットフォームエンジニアリング

どのようなプラットフォームチームでも備えておくべきツールとして、堅牢な継続的インテグレーション & 継続的デリバリー (CI/CD) パイプラインが挙げられます。CI/CD パイプラインは自動化エンジンを備えており、テンプレート化されたワークフローをトリガーして開発環境、QA 環境、ステージング環境、本番環境でコードのビルド、テスト、デプロイを行うことができます。より概念的に言えば、成熟した CI/CD パイプラインとは、開発においてビジネス上の優先事項のコード化、適用、測定を行うコントロールプレーンの役割を果たすものです。

CircleCI には、プラットフォームチームが重要な開発タスクを自動化したり、効率化したりするうえで役立つ機能が数多く用意されています。たとえば、CircleCI Orb は移植性に優れた再利用可能な構成コードのスニペットです。Orb を使用すると、人気のツールやサービスをワークフローに簡単に統合したり、一般的なプロセスを複数のプロジェクトで共有したりできます。また、設定ファイルのポリシー管理機能では、グローバルなルールを設定することで、組織のすべてのパイプラインに同じ規則とセキュリティポリシーを適用できます。

Insights ダッシュボードでは、パフォーマンスを視覚的に確かめられます。これを活用して、改善が必要な領域をすばやく特定し、効率が最大になるようにパイプラインを最適化できます。表示される情報には、実行時間が長く頻繁に失敗するワークフローの時系列データ、リソース使用率、クレジット使用量などがあります。それらの情報から、パイプラインで開発者が求めるスピードや今日の企業が必要とするコスト効率を実現できているかどうかを把握できます。

CI/CD には、開発者の作業効率を高め、開発プロセスを改善する力があります。プラットフォームエンジニアリングツールの中核を担い、セルフサービス機能や再利用性など、プラットフォームエンジニアリング手法の重要な要素を形にできます。

まとめ

プラットフォームエンジニアリングは、品質、セキュリティ、効率のいずれも犠牲にすることなく、ソフトウェアデリバリープロセスをスケールアップできる強力なツールです。リソースのプロビジョニングと管理が簡素化および自動化されるので、開発者は今までよりも短時間で、より多くの価値を顧客に届けることができるようになります。

組織としては、プラットフォームチームを編成することで DevOps のメリットを享受し、高めることができます。その結果として、開発者のアジリティが強化され、組織の信頼性、可視性、自信も高まります。組織のパフォーマンス向上のためにプラットフォームエンジニアリングを導入すべき状況にあるなら、ぜひ CircleCI に無料でユーザー登録して、業界トップクラスの継続的インテグレーションサービスが反復サイクルの高速化とデリバリー成果の強化にもたらす効果を実感してください。

」

https://x-tech.pasona.co.jp/media/detail.html?p=9594#

から引用。

「

プラットフォームエンジニアリングとはなにか？

そもそもプラットフォームエンジニアリングとは、どのような意味を持つ用語なのでしょうか。ここでは2つの観点から概要を解説しますので、イメージをつかんでください。

開発者がアプリケーション開発環境を自律的に作成できる

プラットフォームエンジニアリングは、開発者がクラウド環境において、アプリケーションの開発環境を自ら作成できる仕組みを提供します。セルフサービスで使えるツールや環境の自動化は、代表的な項目です。

インフラに関する多種多様な知識を、開発者が覚える必要はありません。またシステムの運用部門やインフラ部門による環境構築を待つ必要もありません。開発者自身が簡単に開発環境を構築できるため、適時適切なタイミングでソフトウェアを提供できることは大きなメリットです。

専門のチームが作られ、ツールが提供される場合もある

プラットフォームエンジニアリングを実現する目的で専門のプラットフォームチームを設け、開発チームを助ける場合があります。プラットフォームチームは内部開発者プラットフォーム（IDP）をつくり、アプリケーションの開発者に対してツールを提供します。

これにより多くの開発者はインフラを気にせず、アプリケーションの開発に集中できるわけです。数十人規模のプロジェクトでも、プラットフォームチームやIDPは役立ちます。目立たない役割であるものの、迅速なシステムの提供には重要です。

プラットフォームエンジニアリングが求められる3つの背景

<picture> </picture>クリックして拡大

プラットフォームエンジニアリングが求められるようになった背景は、3つあります。いずれも現代の開発現場における重要な項目が関連しています。時代にこたえる手法であることを確認してください。

クラウドサービスの普及

かつての環境構築は高価なハードウェアを用意しなければならず、作業も大変でした。ハードウェアの設置はもちろん、メモリなど部品を取り付けることは、インフラエンジニアのおもな作業です。専門性が高い業務であるため、インフラ業務はインフラエンジニアに任せるケースもよくありました。

クラウドサービスの普及は、この状況を変えました。インフラエンジニアでない方でも画面で必要な設定を行ない、開発に必要なサーバーをセルフサービスで用意できます。また高価なハードウェアを用意しなくても、必要な期間だけ使えば良いため価格も抑えられます。多くの開発者が環境づくりに携われるようになったことは、おもな背景の一つです。

スピーディーな開発が求められている

情報化が進んだ結果、多くの業務を迅速に進められるようになり、より速く情報を提供できるようになりました。社会全体のスピード化により、変化に対して迅速な対応が求められます。システム開発においても、より短い期間で充実した機能を提供する必要があるわけです。

開発環境の構築を専門のエンジニアに任せず、簡便化した方法で自ら行なうことは、開発期間の短縮につながります。このことも、プラットフォームエンジニアリングが求められる背景に挙げられます。

ITエンジニアの不足

慢性的なITエンジニアの不足も、プラットフォームエンジニアリングが求められる背景の一つです。人が足りないからといって、システムに求められる品質は下がりません。むしろIT技術の進化にともない、求められる品質は上がっています。

皆さまのなかには、「人が足りないならば、優秀なエンジニアを多く採用しよう」と考える方もいるかもしれません。しかし優秀なエンジニアやフルスタックエンジニアは特に不足しており、各社で取り合いとなっているため、思うように人を採れない企業も多いことでしょう。

開発エンジニアに比重を置いた採用をするならば、できるだけ開発業務に専念できる仕組みづくりが必要です。インフラの手間を軽減する仕組みが求められるでしょう。

DevOpsやSREとの相違点

よく使われる開発の手法には、DevOpsやSREなどが挙げられます。プラットフォームエンジニアリングとの相違点に加えて、どのような課題を解決しているのかについて確認していきましょう。

DevOpsよりも開発者の役割を軽減できる

DevOpsとプラットフォームエンジニアリングは、効率的な開発により生産性を上げる点が共通しています。一方で開発者への負担は異なります。DevOpsでは、環境構築にかかる負担が開発者にのしかかるためです。開発業務を行ないながら、環境構築や運用に関する多種多様な業務をこなさなければなりません。優秀なエンジニアは他のエンジニアの支援を行なわなければならず、パフォーマンス低下の要因となりかねません。

プラットフォームエンジニアリングでは、開発者の負担軽減がコンセプトです。専門のチームやIDPなどの活用により、開発業務に集中して取り組める環境を提供できます。

SREとは着眼点が異なる

SRE（サイト信頼性エンジニアリング）とプラットフォームエンジニアリングは、着眼点が異なります。SREの目的は、プロダクトやサービスの信頼性を上げることです。品質の向上により開発期間の短縮につながる可能性はありますが、おもな目的ではありません。

一方でプラットフォームエンジニアリングは、効率的な開発を目的としています。環境構築の標準化・簡素化により、品質アップにつながる可能性はあります。しかしおもな目的は開発者の負担を軽くして、開発業務にリソースを集中させることです。

プラットフォームエンジニアリングを活用する4つのメリット

<picture> </picture>クリックして拡大

プラットフォームエンジニアリングの活用により、さまざまなメリットが得られます。おもな4つの項目について、どのようなメリットがあるか確認していきましょう。

開発期間を短縮でき生産性も向上する

開発期間を短縮でき生産性も向上できることは、おもなメリットの一つです。IDPの活用により、開発環境の構築においてプラットフォームに強いエンジニアの手を煩わせる必要がありません。待ち時間がなくなることで開発期間を短くできるとともに、優秀なエンジニアへの集中を防ぎ開発業務に専念させることで生産性が上がります。

また開発業務の多くで、自動化技術が採用されるでしょう。標準化される業務も増え、短期間でのリリースが可能となります。本番環境への移行が楽になることは、代表的なメリットの一つです。

保守開発も迅速に実施し顧客に提供できる

どれだけシステムを完璧に作ったとしても、環境の変化に対応するなどの理由で修正が入ることは避けられません。このような保守開発のフェーズにおいても、プラットフォームエンジニアリングならば迅速に実施し、顧客に提供できます。開発者は数回のクリックにより、現在の環境に適したシステムを作成できるためです。環境作成の手間が減り、少ない作業で短期間での対応が可能となることは大きなメリットといえるでしょう。

経験の少ないエンジニアでも開発現場で活躍できる

プラットフォームエンジニアリングでは、さまざまな自動化技術が活用されています。開発環境や開発業務の遂行における業務の多くが自動化されます。覚えるべき項目が減るため、スキルによる差は縮まることでしょう。

このため経験の少ないエンジニアであっても即戦力になりやすく、開発現場での活躍がしやすくなります。しかるべき品質のソフトウェアを作りやすくなることも、メリットといえるでしょう。

優秀なエンジニアをレベルの高い業務に集中配置できる

優秀なエンジニアをレベルの高い業務に集中配置できることも、見逃せないメリットに挙げられます。そもそも慢性的な採用難のなか、優秀なエンジニアの確保や育成は簡単ではありません。エンジニアの負担を軽くする工夫が必要ですが、DevOpsでは開発以外のさまざまな業務に時間を割かれがちとなり、逆に優秀なエンジニアほど忙しくなる事態を招きかねません。

プラットフォームエンジニアリングならば、開発以外の負担を軽減する仕組みが整えられています。高いレベルのエンジニアがさまざまな業務に忙殺されることを防ぎ、難しい業務を集中して任せられるため、人材の有効活用も行なえるでしょう。

顧客にフィットするシステムを迅速に開発できる方法

プラットフォームエンジニアリングは、顧客にフィットするシステムを迅速に開発できる方法です。この方法は新規開発だけでなく、保守開発にも有効です。ツールの活用により、限られた人材を開発業務に集中させることが可能となります。適時適切なソフトウェアの提供につながり、より良いビジネスにつながることでしょう。

これは近年よく聞かれる「フルスタックエンジニア」と逆行する動きのように見えますが、エンジニアのキャリアパスが多様化する現れともいえるでしょう。一般の開発エンジニアがインフラを意識しなくて良い時代となれば、開発スキルをより一層磨き続ける必要に迫られそうです。」

だとよ。

客先常駐c++プログラマーが転職を成功するには？

Quoraの問答より引用。

※ポイント

①英語の技術ドキュメントが読めて、メールのやりとりができ、ソースコードのコメントが英語で書けるレベルの英語力

②プラットホームエンジニア

③オブジェクト指向、UMLを使った分析手法、アナリシスト

28歳月収15万の客先常駐c++プログラマーです。ここから転職を成功させる最善策をどうか教えて頂けますか？

その歳、その世代でC++ができるのは、まさに貴重です。オブジェクト指向が身についているというも貴重です。C、C++に拘らず、それを活かせる分野がよいはずです。

プログラミングでは、ぜひ、アプリケーションではなく、プラットフォーム側に挑戦するとよいと思います。業務アプリケーションプログラマーは履いて捨てる程、ごまんといますが、プラットフォームは希少ですから、付加価値があるはずです。流行に流されず、惑わされないことが重要だと思います。

さらに身に着けるべきスキルは、はやり、オブジェクト指向、そして、UMLを使うような分析手法のスキルかと思います。ただのプログラマーは価値が低いですが、分析、アナリシスのスキルをもった、ソフトウェアエンジニアとなると、そう沢山はいません。ぜひ、おかしな、世界に通用しないSEとやらではなく、まっとうなソフトウェアエンジニアを目指しましょうよ。

加えて、英語を身に着けませんか。これは受験英語ではなく活きた英語です。街の英会話教室で、ネィテブ外国人に習えば十分に身に付きます。場所によては、会話にとどまらず、読み書きも教えてくれます。全て英語で書かれた英語を母国語としない人達に向けて作成されたテキストが準備されているはずでし。さらに、この授業料は、雇用保険から補助してくれます。

そもそも、プログラマーが英語ができないというのは、あり得ない事です。ソフトウェア開発の世界は日本が中心ではなく、日本以外の世界が中心です。世界では日本市場などしれていて日本語など眼中にありません。べつに完璧になる必要はなく、英語の技術ドキュメントが読めて、メールのやりとりができ、ソースコードのコメントが英語で書けるレベルで十分です。

現実問題、現状の収入、客先常駐という環境、本来、質問者さんが得るべき報酬の大部分を、ピンハネされ、搾取されています。結果的に自分を安売りしていることに気づいてください。単純に、依頼者が払っている代金がどのくらいで、どれだけ中間マージンを引かれ、その上で、あなたの直接の雇用者が、さらにマージンを引き、最終的に、あなたの報酬はいくらになっているか、調べてばわかるはずです。無知の生真面目は搾取されます。

転職先を探す時は、大手に拘らず、少数精鋭の実は特定分野に特化しているしられざる会社を探すとよいでしょう。日本の大手メーカーやＳＩｅｒはほぼ外れです。福利厚生や世間のブランドに騙されないでください。今の時代、安定などありません、上場企業でも、スタートアップベンチャーでも、職を失うリスクは同じです。ならば、何処へ行っても通用するスキルを磨くことができる環境を主軸に探した方がいいです。そして合理的に考えて、競争相手は少ない方がいいんです。

年功序列、終身雇用は、今更ながら、やっと壊れつつあります。行く先がダメなら、あるいは、目的のスキルをこれ以上得る見込みがなくなったら、また次を探すという覚悟がいいと思います。就社ではなく就職を繰り返していく方がいいです。特定の会社にしか通用しないスキルを身に着けるのは時間の無駄で、俗に、潰しの利かない会社員になってします、最後には、組織に捨てられます。会社は道具であると割り切って、下手に骨を埋めるなど考えない方がいいです。自分軸でいきましょう。

最後に、資格云々ですが、よほどの事情、専門性のための必要性がない限り、資格取得は時間の無駄です。資格を取れば門徒が開けるというのは所詮、学校の先生レベルの発想であり、仮にそれが効果があったとしても、資格で足切りするような会社とは所詮そのレベルでしかなく、入ったあとに、後悔することになると思います。

【やねうらお著】Windowsプロフェッショナルゲームプログラミング

『Windowsプロフェッショナルゲームプログラミング』(やねうらお)の感想(4レビュー) - ブクログ

https://booklog.jp/item/1/479800314X

C++プログラマーのやねうらお氏の著作。

どこぞの詐欺師がウリの弟子ニダ、ウリはやねうらおの師匠ニダ、やねうらおは藤井聡太の師匠ニダ、などと戯けたことをぬかしていたが、その詐欺師がプログラムのプの字はおろか、日本語の読み書きすら覚束無い有り様www

C++プログラマーとして、そしてゲームプログラマーとして、神レベルの巨匠がやねうらお氏だ！

ヤフオクでプログラミング本を漁っていたら、新着アラートにこの本が出てきたから即買い！！！