プログラマーの上級職

プログラマー上級職のイメージはこんな感じでしょうかね。

  1. プログラマー → プロジェクトマネージャー → 凄腕プロジェクトマネージャー → 一流マネージャー
  2. プログラマー → システムエンジニア → 凄腕システムエンジニア → 一流ITコンサルタント
  3. プログラマー → 凄腕プログラマー → 一流プログラマー

この中で、一般に学生さんがイメージするジョブチェンジはおそらく2だと思います。

実際は1ないし3で、精々プロジェクトマネージャーもしくは凄腕でくすぶります。
やはり一流には簡単になれませんね。

いやいや、一流なんて目指してませんから!!って?
そうですか。でも、一番しんどいのは凄腕ですのポジションです。
コスパは最悪。

コンサル目指すのも本音は楽そうに見えるからでしょ?

VSCodeの使い方 – 右側のミニマップを消す

VSCodeの右側のミニマップの消し方だけ先に述べておきます。

ファイル → ユーザー設定 → 設定
→ 検索条件にminimapと入力 → Editor › Minimap: Enabled のチェックをオフ。

では、画像付きで手順を公開していきます。

ブログ記事の整理プロジェクト – WordPressのバックアップ

ブログ記事の整理プロジェクト続編です。
最初から読みたい変わり者はコチラへどうぞ → ブログ記事の整理プロジェクト

ブログ記事の整理を行うにあたり、まずバックアップを取っていきます。

バックアップの取り方は色々ありますが、
今回は以前僕が作ったバッチを使ってバックアップを取っていきます。

※環境はAWSのBitnamiを使用しています。

何に困ってますか?と聞くことが超上流と考える3流

ソフトウェア開発において
超上流工程というのは問題を提議し課題を明らかにしていきます。

一般にソフトウェア開発者とユーザーは会話が通じません。
そこでどちらの知識も持った人が間に入って一つのシステムを作り上げます。
いわゆる通訳ですね。

僕が過去にインド人と仕事をした際、
日本語と英語の壁があり間に通訳が入りました。
通訳と言ってもインド人か日本人かによって全く理解度が変わってきます。
日本人の通訳が入るとこっちサイドはわかりやすいのですがインド人との会話はあまり通じて無さそう。
インド人の通訳が入ると僕は日本語には聞こえるが理解できない言葉に悩まされます。
ソースコードでなら会話ができるという異様な状況。
システム屋とユーザーの間の通訳も同じです。

インド人ほどではありませんが
日本語ネイティブ同士でも開発者とユーザーはあまり言葉が噛み合いません。
そんな状態で超上流工程を進めていきます。楽しいですね。

ソフトウェアの「つくれば保守が増える問題」

なければ作ればいい。名言ですね。誰が言ったのでしょう。
リスクを考えたら何もつくれない。いやぁその通りです。
でも、後のことそろそろ考えませんか?

ソースコードを読むしかないと思わせるドキュメント。
意図の読み取れないコメントで構成されたソースコード。
ソースコードを読んでも全くわからない論理構造。

僕たちはどれだけ過去の遺産に苦しめられないといけないのでしょうか。
なぜ10年も20年も前の古い技術や古い思想のお守をさせられているのか。
もちろんユーザーの要求や環境が変化するからです。

今、僕は被害者ぶっていますが、自分のつくったソフトウェアに対する文句です。
僕のソフトウェアも10年選手が登場し始めました。

もうぶっちゃけます。
当時は丁寧に書いたつもりでしたが、今見るとソースコードもドキュメントもコメントも何を言ってるのかさっぱりわかりません。
毎日過去の自分に毒づいています。うへぇ。

とはいえ、自業自得と片付けるのはあまりに芸がない。
だって読みやすいドキュメントがあっても保守は辛いので。

ユーザーは神様か?

かの松下幸之助さんは言いました。
お客様は神様です。

我々プログラマーは成果物を評価される立場にあります。
完成品を世に送り込んで、誰かに使ってもらいます。

僕にとってのお客様はユーザーです。
では、ユーザーは神様でしょうか?
ぶっちゃけ敵です。

行先ボードでも作ってみるか⑦ – 内部設計(クラス図)

今回はクラス図を書いてみます。
Visual Studio Codeの拡張機能「Markdown Preview Mermaid Support」を使用しています。

いきなりコーディングに入る人もいますが、クラスが増えていくと迷子になります。
つまりは今回の僕です。

クラス設計を端折ろうとして迷子になりました。
己を律せない・・・。

今回はクラス図を書いていきます。

ブログの記事数からアクセス数を予測する

僕はブログの記事数とアクセス数の関係を出したいと考えていました。

記事が増えればアクセス数が増える。
感覚的にはわかるのですが、どのくらいの記事にすればどの程度のアクセス数になるのか?
というのがわかりません。

ちまたでは100記事くらい書けば収益化は可能だよ。
とか申しておられるのですが、100記事程度では全然ダメ。
200記事書いたけど赤字の真っ最中です。

元プログラマーがプログラマーと製造業についてぼやくという特段需要のなさそうなコンテンツ。
どれくらいの記事をかけばどのくらいアクセス数を稼げるのか検証していきます。
ついでに月2000円(僕のブログ用のAWS費用)稼ごうと思ったら何記事必要なのかも算出します。

単純な単回帰分析でいけそうです。

DXの設計書⑳ – クラウド?オンプレ?

定期的にお金が出ていくクラウドの仕組みが世の中に受け入れられ始めてきました。
また、社外にデータを置くことにも抵抗がなくなってきたように感じます。

クラウドサービスの形態はさまざまです。
端末やOS管理がいらないソフトウェアだけを借りる
Saas(Software as a Service)を対象にお話ししていきます。

クラウドを選ぶべきかオンプレでいくべきか

DXの設計書⑯ – ユーザーを味方につけよ

ゴールや目的が「XXシステムを構築する」になっているケースをよく見かけます。

手段が目的になってますが大丈夫ですか?

程度の差はあれど、システムやソフトウェアは秩序やルールに従わせるものです。
人にはそれぞれ価値観があり、そぐわなければ秩序もルールも煩わしいだけです。

何の縛りもなく自由にやれてたユーザーはストレスを感じます。
ユーザーにとってシステムの導入はストレスです。