おおばログ

おっさんプログラマーのブログ。

2020年買ったもの

今年はいろいろ購入しました。コロナ影響で在宅が増え、ありがたいことにソフト開発の副業も沢山頂けたので、仕事環境の充実を図ることができました。
記事中のURLはノーアフェリエイトなので、躊躇なく踏んでください(笑)

Apple iPhone SE (Gen2)

娘用に購入。彼女にとってはじめての新品iPhone、愛着もって使ってくれてるようです。
www.apple.com

SONY ワイヤレスヘッドフォン WH-1000XM3

2月に購入。「XM4が夏くらいに出るかも？」という海外リーク情報を見て、待てずに購入。後悔はしていません。SONYヘッドフォンとの相対評価ですがノイズキャンセリングは控えめに言って最高。音の味付けもドンシャリ傾向でSONYっぽいです。3月から在宅中心になったことで、今年一番活躍、買ってよかったデバイスになりました。
www.sony.jp

SONY Xperia 10II (SIM Free Model)

副業のAndroidアプリ開発のテスト端末として40K円くらいで購入。ミッドレンジでもアプリがちゃんと動くようにするのは大切なことです。重量151gで幅狭コンパクトボディーなので、ポケットに入れても違和感がありません。よく持ち歩くセカンダリーデバイスになりました。しかし150gオーバーって、ひと昔前なら重量級だったのだけど(笑)。
www.sonymobile.co.jp

EPSON インクジェットプリンタ EW-M752T

10年くらい使ってたプリンタがついに壊れ、買い替えました。コロナの影響で娘も自宅学習が増え教材を印刷しまくっていたので、今年一番活躍したデバイスかもしれません。エコタンク方式、インク残量が目視できることでインク補充の判断を妥当にできるので、精神的にも良いです。
www.epson.jp

LG モニター 4Kディスプレイ 24UD58-B

仕事環境快適化のために購入。諸事情で24インチ前後の4Kを探してたら、これくらいしか選択肢がありませんでした。購入当時はAmazonで33K円くらい。今は30K円まで値下がりしてて、4Kパネルでは破格かなと思います。入力はDPx1 / HDMIx2、4K 60Hz表示も可能です。3ヶ月使って快適なので、追加で1台買いたいところ。
www.lg.com

ELECOM 高精細Full HD対応500万画素Webカメラ UCAM-C750FBBK

自宅Mac miniでもビデオ会議ができるようにと購入。動画は綺麗に映りマイクの感度も良好。
製品には直接関係ないのですが、ELECOMさんからはmacOS向けユーティリティーが提供されていないので、カメラ映りのキャリブレーションができないのが欠点。Mac App Storeからキャリブレーション用ソフトを別途購入して対応しました。
www.elecom.co.jp

Dowinxゲーミングチェア

適当なデザイナー椅子(笑)に座って仕事していたら疲労蓄積して肩首がおかしくなってしまい、それを機に購入しました。ゲーミングチェアといえば "ほにゃららRacing" みたいのが有名どころでしょうか？仕事仲間からもお勧めされていたのですが、レザー系素材しかなさそうでした。Dowinxはファブリック生地だったのでその点で選びました。夏は蒸れず冬も冷たくならずで、ファブリック生地を選んで良かったと思っています。購入はAmazonで20K円でした。
https://www.amazon.co.jp/dp/B088PKH7CJ?tag=devicebook-22&linkCode=ogi&th=1

PFU HHKB Professional HYBRID Type-S

この手のデバイスは好みが出ますよね。私の前職の代表製品(笑)ってことで、長らくHHKBを使っています。これまでHHKB Professional2 Type-S（有線）を使ってましたが、8年も使ったら経年劣化でキータッチが重くなってしまいました。買い換えるか？ならば無線化だ、ということで。最大3つの機器とBTペアリングが可能。キーボードのホットキーでペアリング切り替えができるので重宝しています。
happyhackingkb.com

Apple Magic Trackpad 2 - スペースグレイ

HHKBとタイミングをあわせて購入しました。デスク上の省スペースが捗りました。
www.apple.com

Apple MacBook Air M1

人柱です。林檎の呼吸です。キーボード配列はもちろんUSです。M1はサクサク動いて速いけど、ベンチマークの数字ほどか？というとそうでもないかなーという感じ（決して遅くはないです）。しかしどれだけ処理負荷をかけても熱くならず、バッテリーがめちゃくちゃ保つ。総じてコスパのよいデバイスだなと思います。
www.apple.com

Apple HomePod mini

ソフトボールくらいの大きさです。大きさの割に低域からよく出ますし、値段相応以上の音を鳴らしてくれます。これも追加で購入してステレオ化したいと思っています。ちなみに（本記事を書いている2020/12/31現在で）iPhoneを持っていないとセットアップすらできません。Mac単体でもセットアップ不可です。いいデバイスなのになぁ、こういうところやぞApple。
www.apple.com

キーボードとかスキャナの会社を退職しました

雑記

f:id:tworks:20180629224006p:plain

キーボードとかスキャナの会社を昨日退職しました。フリーランスの頃から勤務していて途中なんやかんやあって正社員になり、2000年から勤務していたので18年ちょっとお世話になったことになります。せっかくの節目なので、ログにまとめてみたいと思います。

何やってたの

システムインテグレーター(SI)を担当するシステムエンジニア(SE)でした。ざっくりいえば受託開発を行っていて、クライアントからオーダーメイドのシステム・アプリの開発を受注し納品するお仕事です。受注したあとは、社内リソースで開発するかリソースが足りない部分は外注（してマネジメント）するパターンが多かったです（よく聞く多段請負や外注さん丸投げはやらない主義）。

18年の中で、プログラマー → サブリーダー → リーダー（単一クライアント） → リーダー（複数クライアントかけもち）みたいな王道パターンを経験しました。

気づきのきっかけ

サブリーダーをやっていた頃、サブシステムの設計をすることが増えましたが、引き続きコードもよく書いていました。頃合い同じころに id:tmyt がグループ会社に入社してきて、グループ会社WANのIRCで相談に乗ってもらったりで助かっていました。そんなある日 id:tmyt がチャットでこんなことを書いたのです。
「おおばさんは開発者じゃないしなー」
何気ない id:tmyt の一言が俺を傷つけた？いいえ、彼はいつも忌憚のない意見をくれていたのでこのセリフも真正面から受けざるをえませんでしたし、その頃自分でも「開発者としてセンスがないな」ということに気づいていました*1。じゃぁどうしようか...コードを書くセンスを磨くか？他を目指すか？など、いろいろ考えるきっかけになりました。

どうしたか

コードセンスを磨くことをスパっと諦め*2、立ち位置を変えることにしました。id:tmyt のようなセンスの塊みたいな開発者が居たとして、彼らのパフォーマンスを最大限引き出し楽しく仕事ができるようにしようと、そこに対して自分ができることをやろうと考えを切り替えました。

具体的になにしたか

開発環境を良くする

開発環境＝開発マシンを良くすることが手っ取り早いです。開発マシンの購入は人件費とくらべたら安いものですし、そもそも経費にできるので難易度が低いんですよね。その頃は自分で企画・提案書を作成してクライアントからの受注を伸ばしていたので、自分の意見が比較的通りやすい状況になっていました。そこを利用して半年に1回は新規マシンを購入し、自分のチームメンバーは3年くらいで最新スペックのマシンにローテーションできるようにしました。

開発者に丸投げしないことを肝に命じる

どんな開発者でも神様ではないので、決まっていないものに対して開発することはできません。でもこの業界、ときどき理不尽の風が吹きます。
「何もきまってないけど、スケジュールが決まっているから、開発走らせよう」
それは開発者にしわ寄せしているだけであってはならないことです。だから開発をお願いするまでに、次のことはキッチリやることにしました。

クライアントのことを透過的に伝える

このシステムを作る明確な理由・動機、機能の必然性・優先順位など、クライアントときっちり握ったあと、チームメンバーに丁寧に説明することを心がけました。誰しも開発するなら良いものを作りたいと思うのが自然で、そうであれば何が優先されるかを把握したいというのは心情ですよね。また開発側の提案や課題などをクライアントに説明し、必要な調整を行うようにしました。

設計に対するPoCと見積り

要件をもとに設計を行うわけですが「絵に描いた餅」の設計にならないように最低限の検証コードは自分で書くようにしました。自分でコードを書くことで、設計の勘所や課題が見えてきたりスケジュール感の根拠も作れるメリットがあります。センスが無いなりにでもコードが書けてよかったなと思いました。あとはインフラ設計（AWS/Azure）も出来るよう日々勉強しました。

信頼関係を築くことに手を抜かない

同じ会社のメンバーであっても社外のメンバーであっても所詮は他人同士。お互い信頼関係がなければいい仕事はできないと考えています。ですので彼らを常にリスペクトし、彼らの意見にできる限り傾聴し建設的に議論することを心がけました。

そのほか

外部設計をきっちりやる、詳細設計も開発者と相談して必要であればやる、スケジュールが想定とずれてきたらクライアントと調整する...当たり前のことを守ることを頑張りました。

結果どうなったか

某社のエースと仕事をして、そのプロジェクトが終わったとき
「これまでで一番仕事がしやすかったです」
という一言をもらうことができました。
f:id:tworks:20180630001858p:plain
自分のアプローチが少なくとも間違ってなさそうだな、と本当に嬉しい一言でした。

あれ？じゃぁなんで辞めちゃうの

受託開発が窮屈になってきたからです。次の「デメリット」の方を強く感じるようになったからですね。

受託開発のメリット

  • 自社プロダクト開発のように、特定テクノロジーにロックインされることが少ない
    • クライアントの数だけ新しいテクノロジーに触れるチャンスがあり、そこに挑戦することで、開発側の経験や知識を増やしていくことはできると思います（できました）。
  • 面白案件に関わるチャンスがある
    • 自分の場合、World WideなNDA案件に多数関わることができました。某DRMを使ったシステム開発で国内最初の人になれたりとか。

受託開発のデメリット

  • クライアントの望む以上のことができない
    • 予算にしてもスケジュールにしてもクライアントの都合が最優先されます。これは時にBestよりBetterな（もしくはそれ未満の）戦略を取ることがあるということです*3。開発側からみた場合、妥協したプロダクトが出来上がってしまうことが時にあるということです。
  • チームメンバーが固定しにくい
    • 案件によって規模や期間が異なるため、その都度メンバーを組み替えることが多かったです。これはアジャイルなどを用いたチーム成長をやりにくくする状態になります。

経験とともにキャリアプランが変化した

そうして経験を積んでいくうち
「固定されたチームを持ち、そのチームを成長させつつ、そしていいプロダクトを出し続けたい」
そんな気持ちが強くなったわけです。それは今の会社では実現できないため辞めることを決意しました。キャリアプランのミスマッチが出てきたわけですね。それが敵うであろう次の会社はすでに決まっていまして、来週からJOIN予定です。お約束の「試用期間」がしばらくありますので、そこが終わったあたりで状況をお伝えできればなと思っています。

謝辞

この場を借りて、転機のきっかけとなった id:tmyt と某社のエースさんに、御礼申し上げます。

おまけ - 上司や仲間に退職を伝えた時の反応

快く送りだして頂けた上司に感謝。

  • 上司A「そうか...新天地でも活躍期待してるからな！」
  • 上司B「今回は本気やな？」
  • 同僚A「お！ついにですか！」
  • 同僚B「えーーーーーっ！！！独立するんじゃなかったんですか...」
  • クライアントC「うちじゃないんですかｲﾔｰｰｰｰｰｰｯ！」

*1:id:tmyt と比較すると "並の開発者はすべてセンスなしレベル" になるという話もある。

*2:いまもコードは書き続けていますが、チームビルディングなどの別の役割に時間を割くようにしました。

*3:ほとんどが政治的理由なもの。どうみても使いにくいUIに対し「これ絶対使いにくいのでこうこう変えた方がいいです」と提案しても、クライアント上層部が「OKこれで！」ってなると、クライアント企業のパワーバランスによりそのまま行くことが往々にあります。ここは何とかしたかった悔いの残るところです。

角から生えるやつ Windows版ができた

C# WPF

★ TL;DR

  • 角から生えるやつ Windows版ができた
  • 角から生えるやつ とは...
  • プログラムを公開するから、あとはみんなでがんばれ

★ 角から生えるやつ Windows版ができた

  • 意外と早くできました。
  • Visual Studio / C# / WPFで作りました。

★ 角から生えるやつ とは...

こんなやつです。


先にmacOS版を作っていて、詳細は以下に書いています。
tworks.hatenablog.jp

★ プログラムを公開するから、あとはみんなでがんばれ

  • コードはgithubで公開しています。MITライセンスです。

github.com

  • 諸事情でコマ画像は公開していません。察してください。

角から生えるアイツ

ラブライブ Objective-C

この記事はラブライブ！ Advent Calendar 2016 - Adventarの21日目の記事として公開されました。

f:id:tworks:20161220110726p:plain

★ TL;DR

  • ちょっとだけプログラミングの話
  • 愛おしいラブライブのキャラクターを身近に
  • プログラムを公開するから、あとはみんなでがんばれ

★ 私とラブライブ

ラブライブといえば、キャラ（アニメ・誌面）/音楽/声優さんの三位一体が成した素晴らしい作品です。私の場合は声優さんがキッカケで「南條さんが声優しているの！？」というところから入り、気づけば絵里推しとして大ハマリしていたのでした。じょるの尊い...。えりちふつくしい...。ちなみにAqoursは梨子が好きになりました。直前のスクフェスのイベント（梨子イベ）は60位に喰い込みました。愛の力ですね。f:id:tworks:20161220013938p:plain

★ 愛おしいキャラクターを身近に

さて、ラブライブを語るときに魅力的なキャラクターの話はつきものだと思います。そして私もそうですが「魅力的なキャラをもっと身近に！」という気持ちの方は、多かれ少なかれおられると思います。その手軽な方法の1つに、PCやスマホの壁紙設定があり、私は劇場版の特典色紙をスキャンしてPC壁紙にしていました。
f:id:tworks:20161219204145p:plain
えりちふつくs

★ 動かしたい？

こうして、PC壁紙のえりちを見るたびに癒されるわけですが、ある日思ったのです。
「これ、動かせないかな...？」
次の瞬間、隣でこんなことを言われた気がしました。
「やりたいからやってみる。本当にやりたい事って、そんな感じではじまるんやない？」
これはもうやるしかない。やるったらやる！

★ 作り方（レシピ）

材料
  • アニメーションのコマ画像を数点
    • 画像を綺麗に切り出すための熱いハートがあれば（最重要）
  • 透明なウィンドウ
実装
  • マウスカーソルの追従
  • 透明なウィンドウを表示（って見えないけど）
  • コマ画像をパラパラアニメの要領で透明なウィンドウに描画

★ 出来上がっていく様子

ここからはTwitterのPostで、カタチになっていく様子をご覧ください。

1.劇場版BDのエンディングシーンから素材を丁寧に切り出し、コマ画像を作っていきます。

2.試しに透明なウィンドウの上に、1コマ描画しました。この時点ではまだ動いていません。

3.アニメーション処理を入れてみました。それっぽく動いています。

4.マウスカーソルが左下に来たら、ピョコっと生えるようにしました。いい感じです。

5.アニメーション終了時にフェードアウト処理を入れつつ、アニメーション速度を調整しました。

作業時間はコマ画像切り抜き11時間/プログラミング1時間。そんな感じで出来上がっていくのでした。このアプリを常駐させておき、ふと疲れたときにマウスを左下にもっていくと...癒されるわけです（・8・）自分で作っておきながらですが、動くものを目の当たりにするとハァアァァルゥゥアァアショォォーーー！ホッコリしますね。

★ 下から生える

一度仕組みができてしまえば、アニメのコマの差し替え＋アニメーション調整でバリエーションが増やせそうです。ということで早速...ヨーソロー！


★ そして駆け抜ける！

勘のよい方は気づかれたかもしれません。
「あなた絵里推しなのに、ここまで絵里要素ないじゃん！」
と。
「私だって、好きなことだけやって、それだけで何とかなるんだったらそうしたいわよ！！」
「ちょっと待って、別にやりたいなんて。大体、私がアプリになるなんておかしいでしょう？」
と言いたい衝動を抑えつつ、作成に入ります。


2期1話冒頭のシーンですね。こちらは透明なウィンドウを画面全体に表示し描画しています。ああ...えりちふつk

★ まとめ（主に開発者の方へ）

  • 「プログラムを公開してほしい」という声を各所からいただいてましたので、これを期に公開（OSS化）します。MITライセンスです。

github.com

  • 諸事情でコマ画像は公開していません。察してください。＼ダレカタスケテー！／
  • 実装は動けばヨシの心でアニメーション処理はベタ書きです。気になる方はcloneするなりforkするなりして、カッチョよく実装してあげてください。pull reqを送っていただけると作者が泣いて喜びます。
  • 私の都合でいまのところmacOS版しかないです。Windows版は一度作りかけたのですが頓挫しています。以降の開発は https://twitter.com/od_10z に引き継ぎますので、リクエストは@od_10zへ出していただけるとスピリチュアルやね。

　→（12/22 Updated / Windows版もできたかも...githubからリポジトリ公開したら本Blogからもご連絡したいと思います）
　　→できました。
tworks.hatenablog.jp


  • 「プログラムを公開されても俺には開発環境ないし...」という方は、開発できる身近な方を探してみてください（すみません）
  • 知人から「テクノロジーは変態によってこうなるのだ！」という名言を頂きました。み、ミトメラレナイワァ...

★ 最後に

本プログラムが少しでも皆様の癒しになれば幸いです。＼ハラショー！／

課金コンテンツをAppleに預ける - How to implement "Hosting Content with Apple"

iOS アプリ内課金 Objective-C

iOSアプリ内課金についての記事です。

前置き

iOSのアプリ内課金を実装するとき、プロダクト（課金アイテム）をどのように提供するか、検討が必要になります。そうはいっても採択できる方法は次の2つになるのですが。

  1. プロダクトをアプリに内包し課金後それが使用できる実装にする
  2. プロダクトをアプリ外（公開サーバ等）に配置し課金後にダウンロードし使用できるようにする

前者は、軽量なコンテンツを提供する場合や、課金アイテムの実体が要らない場合で採用されることが多いです。

対して後者は、比較的大きなコンテンツを提供するときに使われます。たとえばコンテンツがゲームの追加ステージの場合、ステージの画像データ、BGMなどが含まれるでしょう。それらをアプリに内包してしまうと、アプリのサイズが肥大化、アプリダウンロードに問題が生じる可能性があります（モバイル回線でダウンロード可能なiOSアプリのサイズは100MBまでです）。

例として、iOSアプリの「太鼓の達人」は、アプリ内課金で楽曲を追加購入することができ、購入後に楽曲データを公開サーバからダウンロードしています。
f:id:tworks:20140103181245j:plain

コンテンツ管理サーバを用意する？

さて、プロダクトをアプリ外に配置し課金後にダウンロードできるようにするためには、プロダクトの配置先となる公開サーバが必要になります。またプロダクトを単純に配置してしまうと、購入していないユーザもダウンロードできてしまいますので、正規購入者だけがダウンロードできるようなセキュリティーの実装（Webアプリケーションの実装など）が必要になります。
f:id:tworks:20140103182226p:plain
しかし公開サーバの運用は、多くの場合でコストがかかります。私もそうですが、個人の開発者にとってこれが足かせになることが多くあるように思います。そしてこれがボトルネックとなり、プロダクトの提供が思うようにできないことがあるかもしれません。

コンテンツ管理サーバが不要な "Hosting Content with Apple"

このボトルネックについてAppleが解決策を提供しています。ダウンロードさせるプロダクトをAppleのサーバに預ける（Hostingする）ことができる "Hosting Content with Apple" です。"Hosting Content with Apple" を利用することで、開発者は公開サーバの運用やセキュリティーの実装を省略でき、iOSアプリの開発だけに集中することができます。
f:id:tworks:20140103182948p:plain

続きを読む

Copyright © tworks, All rights reserved.