「ポエム」の記事 - Crieit

ただのブログを書こうぜ（＾～＾）？

2022-07-31T00:05:21+09:00

「　👇 ブログ は昔はほぼ毎日書いていたが、体重が増えてきて止めた」

📖 ぐれーすけーるブログ

「　体重と　ブログを書くことに　比例関係があるのかだぜ？」

「　疑似相関よ。体重は増え続けているのだから」

「　疑似相関も　相関だろ。何が関係ある？」

「　やる気 がなくなってきて　体重は増えるし、ブログは書かなくなった」

「　ほぼ毎日　日記を書く人は　やる気がありますからね」

「　じゃあ　やる気を出せだぜ」

「　財布を捨てると　やる気は出てくると思うが、　そんなやる気が出ないぜ」

「　なんで　財布を捨てると　やる気が出てくるんだぜ？」

「　出せるものは　やる気　しかなくなるからだろ」

「　貯蓄があると使ってしまう人だから、長期的な計画をしないのよ。
がんばって苦労して我慢して貯めていく、ということはできないし、
ダイエットもできないのよ」

「　ということは　一時は　９０００円　まで減った銀行通帳の残高（円）が
今は少しは余っているということかだぜ。良いことだぜ。
全部捨ててしまえだぜ」

「　やる気を出す方法が　お金を捨てる方法一択なのが　わらう」

「　元気なものは胃袋ぐらいなもので、わたしに何かをがんばってやらせようと思っても　無駄だぜ」

「　胃袋の中に　お金を捨ててるのかだぜ？」

「　できれば　そうしたいが、　体脂肪 が付くからできない。
今では　わざと　高くて量が少ない高級フルーツ　を買って食べたりしている　シャインマスカット　2000円」

「　体脂肪になりにくい赤身の　ハラミ　だけを食べたりしてるわよね　ときわ亭　3000円」

「　じゃあ　お金を捨てることは　やってるのか」

「　一番捨てたいのは体脂肪」

「　捨てろだぜ」

📖 肥満に関係するだけじゃない⁉ 第3回肥満シリーズ脂肪細胞の正体

「　👆 体脂肪は細胞に溜まるんだぜ。体脂肪だけを切り取って　掃除機で吸い取って　腹の外に出す、ということは　できないんだぜ」

「　体脂肪は　どうやったら　外に出る？」

📖 プランクで痩せるは『嘘』って本当？噂の真相をを専門家が徹底解説！

「　👆 プランク」

「　じゃあ　プランクしろだぜ」

「　２秒しか持たん」

「　２秒でいいから　しろだぜ」

「　するかあ」

「　変形性腰椎症 を持ってるんでしょ。それとの相性はどうよ？」

「　壁を押したり、プランクしたり　交互にやればいいだろ」

「　ヒトが１日の間にできる決断の回数は７０回という俗説もあるそうだぜ。
お父んは　その決断の回数を　壁を押すことと　プランクすることで消費してしまう」

「　3000回だったり　35000回だったり　俗説は延長する。
プログラマー30歳定年説、35歳説、そんな説は無かった説。
何年何月何日に滅亡する地球」

「　お父んが　腹減った　と思ってる回数だけ　頭　使ってないだろ。
その時間がもったいないぜ。　腹減ったと思うことを止めろだぜ」

「　20代のわたしなら　ラーメン のおかずにご飯を食べ　汁まで残さず食べていたから　腹減った　という雑念は無かった」

「　炭水化物 と脂（あぶら）を採ったら　体脂肪になるみたいよ」

「　ラーメンは全滅だぜ」

「　しかしお父んは　ラーメンを食べるな、と言っても　食べてしまう」

「　ココ壱番屋　は　低糖質カレー　というのがあって　白米の代わりにブロッコリーか何かが入っている。
あれで　カレーも食べやすくなった。
ラーメンの麺も　ブロッコリー　にならないのかだぜ？」

「　だったら　ブロッコリー食べてろだぜ」

「　ラーメンは食べるし、それを踏まえて　体脂肪　を減らす方法を教えてくれだぜ」

「　ラーメンを食べたくなったら　キャベツを胃袋に詰め込んだら　どうなの？」

「　前は　白米を止めて　腹が減ったら　コロッケ　を胃袋に詰め込むようにしていたが、コロッケは糖質の固まりだった。
食べたいものとは別の物を　胃袋に先に入れてしまう作戦は　続かないぜ」

「　お父んの評価関数通りに指したら　勝たずに　太るんだぜ。
評価関数を　差し換えろだぜ」

「　差し換えたら　動物として生存競争に負けてしまうのでは」

「　昭和後期、平成、令和、35億歳の地球の上で　たまたま　評価関数が　おかしな働きをする時期と場所なのよ」

「　食べるものがなくなれば　痩せるというわけか」

「　デブも餓死するらしいぜ。腹出てるのにな」

「　お父んが　体重のことを　毎日毎日　考えていても　なんのスキルの向上にもつながらないのでは？
ブクブク太って　プログラムのことを考えていたら　どうだぜ？」

「　そうだぜ！」

「　体重が９６キログラムもあると、布団から立ち上がるとき、突っ張りになる机が横にないと　体を起こして立ち上がるのも難儀するのよ」

「　そうだぜ！」

「　じゃあ　宇宙に行けだぜ」

「　宇宙に興味はないぜ。ただのスペース」

「　地上で　お金を捨てながら　ラーメンを胃袋に詰め込んで　体脂肪を増やす生き方を止めてほしい」

「　意志はラーメンに勝てない」

「　ラーメンを食べささなかったときの　知能の退行が大きいから　食べさせて　そのときできたエネルギーで　あとのことを考えればいいんじゃないの？」

「　原子力発電みたいだな」

「　あるいは　近くにラーメン屋のない山奥に引っ越すとかだな」

「　良い案だぜ」

「　ニイザシティーに引っ越してきたのは　少し離れた駅まで歩くのが健康だから、という理由なのよ。
その離れた駅にある　ラーメン屋　に行くのよ。
山奥に引っ越しても　ラーメン屋　に行くわね」

「　ダメな案だったぜ」

「　また明日　ラーメン食べたろ」

2021年個人的なまとめ：個人制作と技術記事など

2021-12-28T18:17:57+09:00

年末なので超個人的に今年の個人制作とお仕事を振り返ろうと思います。Qiitaでやると会社の宣伝っぽくなっちゃいそうな気もするし、Zennもなんか違うなーって思うので、Crieitで書きます。

個人開発

まずはプライペートの開発から。UXとかやってた割に、個人で何か作るときはサービス開発とかマネタイズとかあいかわらずガン無視です。おかげで一銭にもなってません。。カモン石油王

2021.2 3代目メザシアタック（ゲーム）

ネコメザシアタック21

リポジトリ: https://github.com/yuneco/mezashi21
記事: VueとPixi.JSでアクションゲーム『ネコメザシアタック』を開発して3年目なのでソースと解説

毎年恒例になってしまった猫の日のゲーム開発。今年はPixiでグラを頑張ったらコード量倍増。
技術的には得るもの大きかったけど、なんかダメなゲーム開発の系譜を辿ってる気もするので来年はやるならもうちょいコンパクトにいきたい。

上記の記事には3年分の変遷をまとめているのでよろしければ見てやってください。

開発環境 Vue CLI
言語　TS3.9
Vueのバージョン
- vue: 3.0.0
- vue-router: 4.0.0-0
- vuex: 4.0.0
コンポーネントの書き方: Composition API

2021.7 petite-vueのジャンプゲーム（ゲーム・実験）

リポジトリ: https://github.com/yuneco/petite-vue-example-game
記事: ゲームを作ってpetite-vueを完全に理解する

なんかVueの新しいのが出たぞ！って話で、とりあえず試してみたかった。
正直普段はVite + TSの方が楽なので、あんまり使い所がないのがちょっと悲しい。

petite-vueについては@ojklabさんが文系大学生のためのpetite-vue入門にまとめてくださっているので気になる方は是非（無料...だと...？）

開発環境なし
言語　JS（ネイティブES Modules）
Vueのバージョン
- petite-vue 0.2.2

2021.10 miracle-pencil（お絵描きアプリ）

いい感じになってきた。年内にはリリースしたい pic.twitter.com/bEwiH6fur5
— ゆき (@yuneco) December 19, 2021

リポジトリ（コア）: https://github.com/yuneco/symmpaint
リポジトリ（UI）: https://github.com/yuneco/miracle-pencil

複雑GUI会のペイントソフト回に触発されて始めたプロジェクトでシンメトリーに特化したお絵かきソフトです。万華鏡とか薔薇窓とか魔法陣とかみたいな、円形に対称な図形が並ぶ表現を簡単に作れます。

コアの機能を生Canvas + TSでゴリゴリ書いて、UIはVueでサクッとつけるアプローチ。アイデア自体はずいぶん昔からあったんだけど、ようやく自分のスキルが追いついて実装できた。でも数学弱いから座標が辛い...。。「エンジニアに数学は必要か？」みたいな話題は毎年一度は出てくるけど、「数学できればもっと踏み込めるのに」って思うシーンは多いので、できるに越したことはないんじゃないかなぁ...。

開発環境: Vite 2.6
言語:　TS4.4
Vueのバージョン
- vue: 3.2.16
- pinia: 2.0.0
コンポーネントの書き方: Composition API + Script setup

2021.12 アニメーション粉砕するマン（クソアプリ）※Chrome拡張

リポジトリ: https://github.com/yuneco/animation-pulverizer
記事: 😡webのスクロールでふわっと出てくるやつ絶対粉砕するマン【クソアプリ】

年末恒例のクソアプリです。個人的に最近Qiitaのアドベントカレンダーは業務参加の真面目な記事増えちゃってちょっと面白くないなーって感じてるのですが（情報発信にポジティブな会社が増えてるからいいことなんですけどね、もちろん）、ここだけは相変わらず無法地帯というか、職務もポジションも全部捨ててやりたい放題な感じがすごく好きです。

結果的にこの記事が今年一番ウケた技術ネタになってしまってちょっとやっちまった感もあるのですが、ツイートやはてブのコメントを見る限りネタとして笑いつつ技術的な部分に興味持ってくれた方が結構いたようで、頑張った甲斐はあったと思ってます。

仕事で書いた記事

会社の仕事は基本的に受託の業務であんまり外に公表できるネタがないのだけど、その代わり記事をいくつか書いてます。
今年は「バズり狙いはせず、フロント界隈のために自分が必要だと思ったことを書こう」って趣旨で、できるだけ表層的なライブラリとかテクニックとかの話題は避けるようにしてました。まあ結果はお察しなのだけど、それでも良いのです（強がり）

VS Code & TypeScriptとp5.jsで始めるモダンなクリエイティブコーディング入門

Processing界隈とフロントエンド業界、近いように見えてあんまりオーバーラップしてなさそうだっので、うまく橋渡しできないかなーって気持ちで書いた記事。もっとフロントの人もクリエイティブな作品作りに触れて欲しいし、Processingから始めた人は是非モダンな環境でパワーアップして欲しい。

あと、個人的にはこのOGP画像は結構頑張って作ったので、可愛いって言ってもらえて嬉しかったです。

もう誤魔化さない！CSS Transform完全入門(2D編)

CSS Transformをちゃんと解説してる情報って意外と少ないなーって思って書いた。transformって結構仕様複雑で普通に使っててハマる落とし穴も多いと思うんだけど、みんなどうやって回避してるんだろう？あんまり伸びなかったけどすぐに古くなる情報ではないので長く誰かの役に立って欲しい。

もう誤魔化さない！CSS Transform完全入門(3D編)

2D編の続きで書いた。正直transformの3Dはイロモノすぎて自分でも微妙だなー、とは思う。でもこの情報は2Dと3Dでセットになってることに意味があると思うので、後悔はしていない（強がり）

jQueryからTypeScript・Reactまで！Viteで始めるモダンで高速な開発環境構築

流行りのネタは書かないといいつつ、これだけは書きたくて書いた。「これはそこそこバズるだろう」って思って書いたものが想像通りにはてブのホットエントリーに載ると嬉しいは嬉しいけどやっぱちょっと微妙。まあでもViteの話題は有益だと思うのできちんと整理した情報を出せたのはよかった、かな。

Twitterかどこかのコメントで「今更IEとか、もうよくね？」って言われていて、それについては完全同意です。でもその層にも振り向いて欲しかったんだ。

個人的にはIEを正しく終わらせることはエンジニアみんなの責務だと思うので、2022年は頑張りましょう。

コンポーネントを小さく・きれいに設計しよう　Vue Composition APIを活用したコンポーネント分割術

コンポーネントの責務や単一責任の原則、Fat Componentの回避...みたいな設計論の表層をできるだけ実例ベースで柔らかく紹介した記事。難しい理論は私自身あんまり理解できてないっていうのもあるけど、これくらいの柔らかさが読み物としてはちょうどいいと思う。

この記事は実は社内向けの啓蒙の要素もあって、その意味でも個人的にはちょっと頑張った。弊社のようにシステム開発というよりもWeb制作に近い領域で仕事してると、コンポーネントの分割が「ざっくりページ単位」みたいに大雑把になりがちで、見た目とは違う軸でのモジュール設計って中々考える機会がないのです（でも、やらなくていいってわけではないのが問題）。

多分同じような領域で仕事してる他社さんも似た課題持ってるんじゃないかと思う。

プログラミングの幅を広げよう！　一段上のPromise活用テクニック

プログラミングの幅を広げよう！一段上のPromise活用テクニック

今年最後の記事はPromiseネタ。PromiseはQiitaでちょくちょくトレンドに上がるふんわり概要記事と、『JavaScript Promiseの本』みたいな本格的な本の中間が薄いなー、って思って書いた記事。

Promiseってほんと良くできてて使いこなせると世界が広がるのに、何故かあんまり重要視されてない気がする。モーダル出すのもAPI叩くのも個別のライブラリはあるけど、実際それだけに頼れないケースは少なくないので一度生Promiseと戯れておくのは良いと思います。

そんなに伸びはしなかったけど、意図が伝わった感のあるコメントをいくつかいただけたのが幸い。

おまけ

ちなみに今年一番伸びたのはBlenderで作ったたまさんでした🐱

Blender入門して1ヶ月かけてようやくここまで…色々粗はあるけど…可愛いから…見て pic.twitter.com/I6fp5TLzL0
— ゆき (@yuneco) August 9, 2021

そんなわけで来年もよろしくおねがいしますー

40歳になって忘れたこと、覚えていること

2021-12-15T07:00:09+09:00

すごく楽しかったあのアニメやゲーム、記憶をなくしてもう一度楽しみたい、それができる年齢になってきました。昨年末40歳になりましたが、よくよく思い返してみるとあのゲームやアニメのストーリー全然覚えてないわ、みたいなことが増えてきている気がします。

年末ということでよく１年を振り返ったりする時期かと思いますが、せっかくなのでこの20～30年くらいを振り返りつつ、どういうものを覚えていて、どういうものを忘れているかの傾向を思い返していきたいと思います。

FF

FF5は僕が小学生のころに自分で初めてやったゲームで、これは色々とはっきり覚えています。僕の中でFFの最高傑作と言ったらこれです。初めてやったFFだからというのもあると思います。

当時ジャンプで毎週ジョブ紹介の連載をしていて、そのページを全部切り取ってコレクションしていつも見返していました。ゲームを買う前からかなり楽しみというか既に楽しんでいました。最後はジョブも全てコンプリートして最強のすっぴんを作るまでやり込んでいました。このゲームがきっかけでスクウェア（スクウェア・エニックスじゃない）に入ってゲームが作りたいと思っていました。

FF6も最高で、ちょこちょこ忘れてるところはあるかもですがわりと色々覚えています。音楽もすごく良くて今も色褪せない最高傑作だと思っています。

FF7は大学入試が終わってから狂ったようにやりました。マテリアも全てコンプリートしてすごいマテリアを作ってた記憶があります。ただ、ストーリーはだいぶ忘れています。要所は覚えていますが、サブ的なところはほとんど覚えていません。

FF8、9はほとんど忘れています。雰囲気しか覚えていません。

FF10は逆にそれらよりは覚えています。ストーリーが好きだったのかも。ただちょっと旅は面倒だった記憶があります。

やっぱこうして見返すと若い頃に一番最初に得た大きな衝撃が心に残りやすいような気がします。

ドラクエ

ドラクエは一番最初にやったのは３なんですが全くクリアできず、ちゃんとクリアできたのは４でした。これも小学生くらい。なので４は一番良く覚えています。章で別れているので覚えやすいというのもあるかもですが。３も一応進んだところまではすごくよく覚えています。３はもしクリアできていたらFF5くらいの衝撃はあったと思います。すごく面白かったです。ジョブチェンジ的なのが好きなのかも。

あとは大学のころにやった７が全然期待していなかったのにめちゃくちゃ面白かったので記憶に残っています。衝撃効果。とはいえあれは区切りが多すぎるのでだいぶ細かいところは忘れてると思います。

ミスチル & globe

僕の青春です。中高あたりが一番聞いてました。何度も何度も聞いたしアコギの弾き語りで歌いまくってたしとにかく記憶に刻まれてます。アルバムもどういうのあったな～と覚えてますし歌詞も割と思い浮かびます。

シュタゲ

これは当時じゃなく大人になってからやりました。なので覚えてます。が、意外と途中は忘れてるような気がします。正直ノベル系の最高傑作のうちの一つだと思うのですが、やっぱりプレイした年齢でしょうか。

プログラミング

これはずっとやってるので当初からの記憶があまり薄れている感じがしません。CakePHP1のコードを良く見てましたが、シンプルだったせいか今でも書ける気がします。（多分実際書いてみると全然別物になる気がしますが）

428

これもノベル系の最高傑作のうちの一つなんです。が、だいぶ忘れてる気がします。大人になってからやって、期待せずにやったんですがむちゃくちゃ面白くてドハマリしました。しかしそういえばあのキャラクターのストーリー全然思い出せない、みたいなのがあるのです。これも始めた年齢のせいなのかもです（とはいってもだいぶ若かったと思いますが）。なのでこれ多分記憶をなくしてもう１回楽しめるレベルまで来てます。

細かいところとか主題歌とかは結構覚えてそうな感じもするんですが。

ドラゴンボール

これは小ちゃい頃からなんどもコミックで読んでたのでほぼ覚えてると思います。多分。むっちゃハマってました。

クロノ・トリガー

これも小学生か中学生くらいで、むちゃくちゃハマりました。エンディングもいっぱい見ました。だいぶ要所は覚えています…と言いたいところですが、なんとなく忘れてるところも多いような気がしています。忘れている気がするのでどこを忘れてる気がするのかは覚えてないんですが。

クロノクロス

クロノトリガーの続編。まったく覚えてないです。全部クリアしたしエンディングもちょいちょい見たんですが。そもそもエンディングすら覚えてなかったんですよね…。多分当時の僕には意味がわからなすぎて。大学生くらい？　なのに。ちょっとおとなになって忙しかったのと、難しいのの組み合わせでわけわからなくなっていたのかもしれません。あとキャラが多すぎてキャパ超えてたのかも。不思議です。

サガフロンティア２

むっちゃ面白くて感動しました。大学の頃。かなり覚えているようなイメージはあるんですが、でも細かいところは多分殆ど忘れているんじゃないかと思います。これも多分もう１回楽しめそうな気がします。特にラストは全然進めなくなって当時知り合った人に代わりにクリアしてもらったんです。今ならちゃんとしっかりやり込んでストーリーももっと深く味わえそう。

逆にロマサガ３とか全く覚えてないです。これも楽しんでクリアまでできたと思うんですが。カタリナの音楽かっこよすぎでした。

ライブ・ア・ライブ

これもマジで最高傑作でした。むっちゃ何度もやり込みました。中学か高校？　音楽がかっこよすぎてサントラも買いました。でも覚えてないんです。と思ったんですが、思い返してみたら結構覚えてるかも。キャラによってはもしかしたら忘れてるのかも？

もう一回やっても楽しめそうな気もするんですが、なんか最後のストーリーに持ち込むために各キャラクターで結構頑張ってアイテム集めとかしてたので、それをもう忘れてると思うので難易度上がってる気もします。

saga

１～３まで全部やりました。ただ細かいストーリーは覚えてるとこも忘れてるとこもありますね。３なんかはあまり覚えてない気がします。どれもむちゃくちゃ面白かったんですが。１は何年か前に細かいストーリーのレビュー記事を見たんですが全く覚えてませんでした。

ファイアーエムブレム

初代はだいぶ覚えてます。あと外伝も。むしろ外伝の方がレベル上げし放題で難易度が低く小学生の僕には好みでした。初代はクリアできなかったような気がします。でもシミュレーションRPG初だったのですごく楽しくて衝撃的で心に残ってます。リフ。

トルネコ、試練

むっちゃやり込みました。でも中学生の僕には難しくて１回クリアするので精一杯でした。トルネコのストーリーは完全に忘れていました。このまえYouTubeで実況見てなんとか一部思い出した感じです。シレンはその後に出て面白いシステムが増えてたのでかなり気に入ってよく記憶に残っています。（ストーリー的なストーリーはそんな無いからかもですが）

聖剣伝説

これも１～３までやりました。でもはっきり言ってだいぶ忘れてます。１は後にガラケーでも出たんですが、その時すでにだいぶストーリー忘れて最後まで楽しめました。なのでちょっと覚えてます。すごく切ない。

２はスーファミで出て、むちゃくちゃやり込んだゲームです。ラストダンジョンとか、序盤は結構覚えてます。ただ途中はだいぶ忘れてるかも。でも最高傑作でした。ボスのところで止まるバグが辛かったですが。

３もすごく面白かったはずなんです。でも全然覚えてません。当時ニコニコでプロの声優を目指してる方がアフレコやってて、むっちゃ面白くて最後までみました。そういう意味でちょっと記憶に残ってます。でもストーリーあまり思い出せません。

ジョジョ

ジョジョわりと１～４部くらいまでは覚えてます。忘れてるとこもいっぱいありそうですが。親戚のうちに１，２部があったので結構読みました。なので３部が結構忘れてる気がします。いや覚えてるかも？　多分もう１回読み直しても楽しめます。逆に３部からの方が忘れてる量が多いので楽しめそうな気がします。

デスノート

これはだいぶ覚えてます。むちゃくちゃ面白かったです。映画も見に行きました。インパクトのあるストーリーなのでかなり細かく覚えてる気がします。

寄生獣

むっちゃ面白いですよね。だいぶ覚えてると思います。でも途中覚えてないような気もします。

幽遊白書

結構覚えてると思います。でも大学の頃既にエンディングどんなんだったっけ？　と完全に記憶になくて読み返したんですよね…。それ以外は結構覚えてると思います。

ダイの大冒険

今アニメで見てます。覚えてるところもあるんですが、終盤は全然覚えてないので今まったく新しい気持ちで見てます。どうなるんだろう！？

ドラマ

ドラマはびっくりするほど覚えてません。誰が出てたとか、大雑把にはどういう話とか、主題歌とかはなんとなく覚えてますが、細かい話を覚えてるドラマはほとんど無いです。じゃあ見たいドラマがあるか、と言われると、う～ん、ドラマやゲームと違ってなぜか全然思いうかばない。一過性のエンターテイメント性が強いんでしょうか？

ハルモニアとか、未満シティーとか、堂本剛のタイムリープのやつとか、銀狼怪奇ファイルとか、思い返してみるとなぜかKinki Kidsのドラマの内容はすごく覚えてて不思議です。どれも面白かった。

まとめ

まあという感じで、もう１回楽しめる、みたいなの結構増えてます。みなさんも同じ様に忘れてもう１回楽しめる日が来るということです。もしくはもっと忘れてるということです。胸熱ですね！！！！

他にもこんなのはどう？　みたいなのあったら聞いてくれれば思い出してみます。

ゲームを遊んだら、自分を遊べ(あるいは『プログラミング後に、自分をステップ実行』)

2021-12-14T20:25:14+09:00

(もしかしたら今後、挿絵を挿れるかもしれない)

この記事は、
『CoderDojo Advent Calendar 2021』の23日目の記事であると同時に、
『えだ管理Discord鯖アドベントカレンダー 2021』の24日目の記事の予定です。

「フライング投稿は如何なものか」
と読者の皆様は思われると存じますが、この記事は上記の日付までに何度か改版が入る前提で投稿しました。

また、
「アドベントカレンダーを投稿する事を忘れる」
という失態回避の目的も兼ねております……というより そっちの方が動機としては強いです 。

不躾とは存じますが、ご容赦頂けると幸いです。以降、本文となります。

事前にお伝えする事として、筆者は以下の書籍や情報の影響を強く受けている；

『禅とオートバイ修理技術』
数理論理学(しかし、過激な関数型プログラミング狂信者の様な「プログラミングも自然言語も人間の心情も数学。理解できない連中は野蛮人」という発想には疑念を覚える)
クトゥルフ神話 TRPG で用いたキャラクター達
他多様なフィクション

つまり、
「歪んで現実の人間への不信の極みに陥いって、フィクションに逃げてるヲタクの世迷い言」
として受け取って読んでもらうくらいが丁度良いと思う。

なおタイトル元ネタは小飼弾氏の『本を読んだら、自分を読め』である。

「くそ長い。はよ言え」な人向けに

復習大事。振り返り大事
振り返りの内容は表現できるとなお良い
振り返りの表現のコツとして「感情描写。比喩・擬音・擬態」とか

自分を遊べとは

TRPG には『感想戦』という「感想共有」の時間が設けられている事が多いし、ほとんどのシステムのルールブックに明記されている。

戦という字から誤解を招きやすいとは思うものの、あくまで主目的は、
「あの場面のあの人のロールプレイは良かった」
とか、
「あそこの場面でプレイヤー自身はああしたかったが、ダイス目の都合で……」
という、リスペクトや暴露会なのが丁度良い。

その感想戦をする中で、その卓の人々で気づきがあるはずである。

可能であれば、しばらくその気づきに入り浸るなり、深めると良い気がする。

気づきの深め方

ここでの気づきの深め方については「脳内で言語化する」だけで必要条件は満せるかもしれない。

ただ筆者個人としてはせっかくなので、その内容を 3 行まとめで良いので書き起こす事を勧めたかったりする。

あわよくば 筆者個人としては 、二次創作と称して小説やマンガ・イラストや音楽に書き起こしてもらえたら、これほどシナリオ制作者やゲーム制作者として嬉しい事は無い。

その過程で、別の物語があなたの中で湧いたなら、感無量である。

デジタルゲームでも同じ事

異様と思われるだろうが、これはデジタルゲームにも言える。

ただし振り返る対象が物語ではなく、自身の身体制御や操作直前の思慮、ひいてはその後のゲーム展開や身体が覚えたジョイパッド(コントローラー)やキーボード・マウスから来る反作用(抵抗力)、そして身体部位の緊張感などが主となる。

あの瞬間何を思って操作を行なったか
その時の指先や手の甲の動き具合
その際に指先で感じた反作用・抵抗力、あるいは緊張した身体部位

これを続ける事で、もしかすると自分に適したゲーム内の戦術や入力機器の選択の幅を絞る事ができるかもしれない。
ただ、筆者や周りの人々の様子を伺う限りでは、
「1ヶ月間、毎度振り返り続けると、入力機器に順応してる」傾向が多い。

自分をステップ実行とは

さて、ゲームとは真逆にも捉えられそうなプログラミングの話が混入してきて、読者の方々の中には困惑を覚えたりするだろう。

しかし筆者個人としてはほぼ同一の感覚を覚えてしまったからこそ、就労移行支援事業所での個人活動の時間にこんな世迷い言を認(したた)めているのである。

閑話：俗に言う「美しいソースコード」の個人解釈

ソースコードを書いたり読む時に、多少の彩(あや)を感じる事がある。

空行の数、チェーンメソッドの並べ方、変数名。

その彩をある程度共通にする事で、「後からコードを読む人々にに余計な思考の徒労を与えない様にする」為の『コード規約』と筆者は捉えている。

なので識者以外には異様に思えるかもしれないがプログラミングでも、
「行間を読む」
という行為や、
「語の並びに思慮を巡らす」
事が無い事も無い。

暴論だが、むしろそれらを怠ったコーディングをしているコードには、
デスマーチの最中でのコーディングとは留意するものの
激しい憤りの念を覚えるし、そういうコードを書かざる負えなかった環境には尚更憤怒の念を覚える。

かと言って筆者の様な、
「言葉やコードの彩に躓いては、躓いた対象をじっくり観察・分析・解剖する」
様な輩が地方の末端派遣社員や農家のアルバイトをやるとクビが飛んだり怒号や罵声を浴びるのは、こういう、
「他人が直感で解っていたり無視できる事をいちいち気にして、傍から見れば無用な時間を過ごしている」
からだと自負はする。

ステップ実行の仕方

さて、具体例を挙げよう：

自分の書いたソースコードを眺める
改めて、「なぜこの様な書き方をしたのか」と自分に問う。例：
- フレームワークや言語仕様の都合でそう表現するしか無かった
- 良い方法はあったが、改修範囲が多岐に渡り、時間も要するから
とりあえずその「なぜこの様な書き方をしたのか」をソースコードのコメントに書いておく

その上で；

「もっと良い実行コード上での表現方法は無いだろうか」
「自分の中で言葉にするなら一言で収まる処理だが、ノイマン型コンピューターではもっと細分化が必要だっただろうか」
「もっと細分化するなら、どの主語や述語を軸にして分解し、手順を並べるか」

と自分に問うてみよう。

オープンソースは考え方の宝庫

これが巡り巡ってコンピューターや自分自身の理解の促進に繋がるかもしれないと筆者は思うと同時に体感している。

ここ最近は、
「自分の頭の中が Linux カーネルだったら、この『注意力散漫』さを少なくするには？」
「弁識ができても行動に移せないのはなぜ？」
と思い至って、『CPU スケジューラー』や『システムコールの実装』について興味を抱いている所だ。

幸い、今日は Linux カーネルそのものはもちろん、そこから派生したカスタムカーネルもある上、ソースコードがWeb
上で公開されている時代である。

直接自分の思考過程への焼き込みはできなくとも、参考になるものはあるかもしれないという希望を持つので興味が強化されている筆者が居る。

もっとも、ここまでの発想に、
「そんなもの、気合や根性が足りないからだ」
と一蹴できるのであれば、あなたはよっぽど健全な人間なのだろうと筆者は勝手にあなたの事を羨ましく思い、皮肉めいた感情を抱く次第である。

総括

振り返りは大事

ここ最近、
「『振り返り』は脳科学の観点でも良い刺激を自身に与える」
という話はとても散見される。

しかしいざ集団で振り返りをするとなると、その場に適する表現を求められるのが世の常では無かろうか。

そこで筆者としては、
「個人の個人による個人の為の振り返りを、頻繁に行ったておくだけでも十分な効果があるんじゃね？」
という思い付きを共有した次第である。

ただの独り感想戦

やる事は感想戦である。最悪、言語化とか映像化も難しいだろう。

それはまず、今のあなたはそうであるという事実が確認ができる。
そして、そういうものもしっかりと認識するだけでも違うかもしれない。

その感覚・体感に深入りする事を無理強いしないが、時間や心情に余裕やゆとりがある時にはやっても良いだろう。

感想戦の内容は表現できると尚良し

上述で、

やる事は感想戦である。最悪、言語化とか映像化も難しいだろう。

とは書いたが、可能であれば脳内に留めず自分の手を動かして表現した方が良いと思う所存である。

その表現したものを眺めたり聴くなりして自分自身の表現能力を真の当たりした方が、頭身大の自分に気付けるかもしれない。

補遺：心の在り様に苛責(かしゃく)は愚息

オープンソースは考え方の宝庫の終わりについ、

もっとも、ここまでの発想に、「そんなもの、気合や根性が足りないからだ」
と一蹴できるのであれば、あなたはよっぽど健全な人間なのだろうと筆者は勝手にあなたの事を羨ましく思い、皮肉めいた感情を抱く次第である。

とこぼしてしまったので、書き加えておく。

気合や根性、あるいは知性や教養でも良いのだろうが、
「単一の対象による評価での優劣で自他を呵責ないし揶揄する。または自惚れるのは如何なものか」
という持論がある。

かく言う私も人間の出来損ないなのでいくら親父に、
「お前は愛や人間感情を理解できずに自分の損得だけで動いているからすぐに解雇されるんだ」
と言われたり、とある現場の上司からは、
「お前も発達障害かもしれないし、俺も本当は発達障害かもしれない。けれどもそれに甘んじて向上心を絶やすのが一番愚か」
と言われたり、どこかの『自称 IQ148』の人間からは、
「君が不幸なのは不幸な考え方をしているからだ。もっと僕みたいに自分を好きになりなよ」
と言われ、果てはとある派遣会社の同僚や営業からは、
「お前が趣味と仕事を混同して社内チャットに投稿してくれるおかげで、こっちは集中力が削がれるんだ。仕事しろ」
「プロ意識というものは無いのか？そんな『使えないなら切り捨てれば良いだろ』という発言に無責任さを感じる」と散々言われ続けてきたにも関わらず；

行動の鈍化(本人も他人の様に素早く正確な行動をしたいものの、他人の様な正確さが損なわれる)
通勤途中での嘔吐
起床不良・不眠症
弁識能力の低下による業務指示理解・遂行能力の顕著な低下(環境手順書があるものの、内容が古すぎる為に公式ドキュメントで示されている手順で勝手に進める。他)
記憶能力の欠如(自分が言った事を数日で忘れる。他)

などが顕著になったり悪化したりして、最終的には『地域包括支援センター』や『相談支援事業所』と呼ばれる所に
掛け込んで、幸か不幸かはまだ判らないが「生活困窮者と認定され、かつ就労移行支援から出直し」という、
まさに人間の出来損ないらしい現状に至っている。

散々愚痴を吐いたが、各人には、
「付き合って頂き、有り難う御座います」
という思いは多少ある。

ただ、もしかするとそこまで思ってはいないのかもしれないし、その場を取り付くろう為に罵声や怒号を浴せたのかもしれないが、筆者個人としてはここまで読んで下さっている方々には留意して頂きたい事がある：

「五体満足で言葉も喋れるならば、自分と同じ認知・思慮・推察、および注意持続能力をもっていて当然」
という発想は かなり危険 である。

とは言え読者の方々の中には上述について割り切れない心情が沸く事もあるのは筆者も容易に想像できるし、
そういった感情と上手く付き合えない故に、物心着いた頃から常に孤立感を抱いている筆者の現状がある。

でなけりゃ、わざわざ自分でこんなクソ長い世迷い言を書き記し続ける動機や気力も、とっくに尽きているか満足しているのである。結果論だが。

会社がなくなって、転職を余儀なくされた件。

2021-12-03T11:21:47+09:00

社内SEに向いているのはこんな人（かもしれない）2020年振り返り記事
↑2020年のアドベントカレンダーに書いた件。↑お文具満載♪↑

2021年の秋に会社がなくなりました。

転職活動して、
今は、IT企業で
派遣で働いてます。

でもなんか
思ってたんと違う。。。(´；ω；｀)

時給が安い上に、
全然役に立てない。(´；ω；｀)

周りができる人ばかりで
自分は・・・という無力感。(´；ω；｀)

コードを書く仕事も
させてはもらえない。（VBAじゃないからね...）

無力・・・orz

これなら在宅勤務の

VBAの仕事の方が、時給高いし良いよ！！

と思ったので、
AccessとSQLをバリバリにマスターして（？）

転職する予定です（・◇・）/~~~

難しいことは、できる気がしないので
AccessとSQLならがんばればなんとかなるだろう、という安易な考えです。

難しく使おうと思ったらいくらでもできるとは思うのですけども、
基本的なことはなんとかなるだろうと。（バリバリはどこへ？）

VBA資格取ったよ！

とりあえず、

Excel VBA使えるよ！という証明書的なやつ

取りました！！

あまり関係ないというか知らないこといっぱいあって
前日まで体調崩してて、焦ったけど・・・。

何年も前から、取っといた方がいいよなーと思ってた資格だったのですが
やっと受験して、1回目で受かりました。

受験料もそんなに安くないから、受かって良かったです。

VBA試験対策は

↓これ買って、WEBで練習問題たくさんやって。

VBAエキスパート試験対策

あんまり繰り返してやると答えを覚えてしまうので
意味なく丸暗記してしまわないように気をつけつつ。。。

しかしこれよくできてて、解答履歴とかもあるし、パーセントも出るし、
過去○回間違えた問題だけを出すとかも選べるし、回答の選択肢の番号もランダムにできるし
こんなの作れたら、、、いいよなーと憧れます。

めっちゃ手間かかりそうだけど、コツコツ稼げそう。。。

あと、

↓VBAサイトで有名な田中さんの本も買って試験範囲を把握しておきました。

VBAエキスパート公式テキスト Excel VBAスタンダード田中亨

テーブル操作とか仕事で使わなかったし、関数もそんなに使ってないので、
どんなのが出るのかわかって良かったです。
知らないところはルーズリーフに手書きでまとめながら覚えようとしました。

試験を受けたことでやっと「VLookUP」と「Index」と「Match」の使い方を覚えました。
まとめて覚えないとどれがどれか分からなくなるのです。

最終的には、
練習問題をやって、分からなかったところを覚える、というのが
私には向いていました。（テキストだけ見てても覚えられません。）

まとめ

今の環境をバネに
こんな会社やめてやるー！！というモチベーションで

勉強がんばります！！

ｶﾞﾝﾊﾞﾙ୧(⑉•̀ㅁ•́⑉)૭✧

Accessをやるぉ「メンサ会員本気のACCESS入門講座！」

2021-12-03T08:41:57+09:00

以前、

Excel VBAの話を書いていました

私の記事一覧

が、

諸事情により（別で記載）

Access　もっとがっつりやったるで！

SQL　もやったるで！！

と思い立ったので、がっつりしっかり勉強始めます（宣言）。

~~ちなみに「やるぉ」は「やるぞ」の入力に失敗しただけでs~~

手始めに、

1:25:29　もある動画を見ました。これとても良い動画です。
話しているのは女性です。聞きやすいです。

【Excel中級者向け】メンサ会員本気のACCESS入門講座！理解してアクセスを使うデータベースから学ぼう・Accessとは・テーブル設計・主キー・SQL・クエリ・リレーションシップ・フォーム

試しに見てみましたが、
YouTube、想像以上に良いですねー。
概要を掴んで流れを把握するにはとても。

というか前半は、知ってるよーという内容もあるので気を抜いて見つつ、
しっかり見て学ぶ部分もありました。

前に変な表示になって直せなかったのは、
この設定直せばよかったのかとか、そういうことも知れました。
（タブ表示じゃなくなって、直せなくなってた。なんだこの変な枠は？と思ってた。）

この動画を見るまで、
AccessのSQL文ってどこに書くのかも知らなかったのですが、

さらに知りたいのはAccess VBAってどこからどう使うの？という点なので、
さらに勉強していこうと思います（宣言）。

Markdown、いまだに慣れません。いつもテキトーにやってるからですね...
見辛くてスミマセン...m(._.)m

ところで（広告に表示されていた）「中高年・・・」といえば彦摩呂を思い出すのですが彦摩呂じゃなくて、きみまろか、、

頭が悪いのでプログラミングしてるんです(カム着火インフェルノォォォォォォォウ)

2021-07-27T19:14:18+09:00

私自身が嫌悪感を抱く度に過去を無用に反芻し、それらがつもりつもって独りでキレているとは自負するし、こういう事はチラシの裏に書いて着火し、灰になるのを眺めるのが健全で謙虚なプログラマ仕草だろう。

上記の断りも社交辞令でしか書いてない。

これから書く事は「開発者側の発想・エゴ」を、じめじめしてカビ臭くて小ハエが飛び回っている様な部屋で1ヶ月煮詰めた様な話なので、そういうのが不快・不愉快な人はブラウザバックしてもっと有益な時間を使った方が良いに決まってる。ましてやオチも無ければ学びとなる話も無かろう。筆を進めている私自身も書き進める度に、
「そんなに同情されたいんなら、責任・責務を果してから言えクソが」
と、頭の中で悪態を零しながら書いている。

筆者スペック

地方の末端派遣社員も継続できない31歳人間のクズ
現在無職で精神科デイケアと就労移行支援事業所に通所
知性が無いのでなんでもやりたがるし失敗する。そして散財・浪費する

おまえ、本気で俺に「頭が良い」と思ってるの？

よー知らんが、成人してからプログラマであったりパソコン関係でやたらと知見を出してしまうので、
「頭が良いんですね」
と言われる事が多い。大抵は社交辞令なのだろうし、場合によってはその様に煽ててマルチ商法や新興宗教の勧誘に誘い込むのだろう(実際に体験済み)。

むしろ個人の思いとしては以下の様な体験があるため、
「お前それ本気で言ってるのか？」
とおこになる；

空想癖・妄想癖の類いによる頓珍漢な発想や失言を未だにしがち
学生時代の算数・数学は学年で下から2,3番目の成績
授業中に隣の同級生からのチョッカイを無視する事ができずに叱られる事はほぼ毎日
学校の宿題や長期休暇の課題を「家業の手伝い最優先」「やった方が良いのだろうが、やった結果が期待の10分の1程度の成果と技能向上感」なので、ほぼやらない
長期休暇明けの漢字・英単語の暗記テストは合格点を満せずに1ヶ月以上は毎日追試と怒号を浴びる
授業の初めに言われた自習内容を忘れたくせに教員に尋ねに行かなかった事で教員に気合入れ(軟禁による叱責)をうけた

など、挙げればキリの無い「知性皆無な愚者エピソード」はいっぱいある。ましてや家族や高校の同級生も認める程度には「頭がオカしい」タイブの人間ではあるし、自負もしてる。

補足

人によっては上記のエピソードから、
「発達障害じゃん」
と思われたかもしれない。

実際に成人してから精神科に通院治療し、去年の12月に心理検査の結果を頂戴したが、どうもその通りらしい(『ADHD』らしい)。

というのは、心理検査の報告書には明記されていなかったものの、お世話になっている生活相談員さんや就労移行支援事業所の職員さんからの『医師の意見書』や『処方箋の内容』についての情報を聞く限りではそういう事らしいからである。

しかし私個人はそういう診断を得て諦めが付いた安堵と同時に、それまでごく普通な生活を強いられできなければ叱責を受ける日々のおかげか、素直には受け入れられていない。ましてやこの診断を免罪符に、
「ちょっと他人との共感や意思疎通が難しい人型害畜らしいので、許してちょ!」
とは言える訳や道理も無かろう。

「てめぇ発達障害か？」
という罵倒に対する開き直りと自虐のネタとしては積極的に使えるが。

むしろ「頭が悪い・オカしい」から、プログラミングとフリーソフトウェア(ハードウェア)の世界に逃げてきた

見出しでは「逃げてきた」と書いたが、実の所釈然とはしていない。しかし父親は確かに、祖父母は湾曲的にその様に言うのでその通りなのだろうと思う。

「逃げてきた」という事で話を進める。そして何から逃げたのかをあえて明記しておく。

人間、もしくは 人間の営み のいずれか両方であろう。特に『感情』の部分である。

集団との違和は大抵嘲笑の対象になり、さらに言えば「腕っ節うでっぷしと富・地位・名誉」を重んじられる様なのが田舎である。その為、五体満足で日本語も喋れる様な奴がこんな減らず口を宣いているのは怠慢やサボりだし、それを正当化する言い訳としか言われない。

実際そうなのかもしれないが、31年自分なりにやってきても改善されないのだから、少しは ~~自分の~~ 腑に落ちる理屈が欲しいのであろう。

という理由を、昔の私自身は自覚できずただ単に、
「楽しいものを作りたい」
という思いだけでプログラミングを学び初め(しかもできるだけお金を掛けずに)、OSはLinuxのDebianディストリビューションと長く付き合い、果ては自分の使ってるソフトウェアの簡単な部分のコードを読んで不具合の原因を推測するだけの遊びをしたり、
「作れるものなら作ってみよう」
と自作キーボードにも手を出してしまったのではある。

更にはあんなに嫌な思い出のある算数や数学(特に高校数学での集合論に随する辺り。数理論理学も自分の中ではそれ)を興味本位で自分なりに学んでいるので、我ながら妙な話ではある。

それでも「腕っ節と富・地位・名誉」で殴りにくる連中に供えてる事

こういう連中は端から『黙らせる』事しか考えていない。『多様性』の前に『(その集団内での)有用性』を要求してくる。

ましてやこうやって減らず口を叩いてる様な『頭のオカしい奴』は、そのオカしさの原因を怠慢で切り捨てる。

何げ無く過ごしている人々にはそれこそ、
「怠慢だろ。考えろ。意識しろ」
と思うのかもしれないが、少なくとも自分なりに31年人間の姿で暮らす中で以下については自分なりに努力した：

楽しくない勉強を楽しくする方法
時間の使い方(自己啓発本を読み漁ってしまった程度に。しかし自分が使える時間内に期待する成果を出せなかった)
(未だにかつ意固地だろうが、この様に)自分なりに表現して、自分が苦手だったり至らない事について思慮する

閑話休題。そういう連中とやり合う為に今足掻くも同然で供えている事としては、

自重トレーニングによる自身の身体の動かし方の確認と鍛錬
感情論に対する数理論理や集合論による解釈の練習
知的好奇心の維持や探求・および私自身の好奇心の根源の解釈

と書いたが、連中からしたら「土俵に上がって込ない時点で逃げてる」のだろう。『心配』と言うが、犬死にさせてでも心配している対象を『正しい者』にしたいのでは無かろうかと歪んで斜めに構えてしまっている。

1 あくまで思慮。熟考と言うには意固地で浅はかと思い抱く。

逃げてしまって今

大抵のフィクションや美談での「敵前逃亡した愚者の末路」の様に、自分も成ってるであろう。
相談支援事業所の助けを借りてデイケアと就労移行支援を利用させてもらっているのではあるが、常時背徳感を覚えているしそれを紛らわす為にデイケアと就労移行支援事業所では何かと企画を立案してしまっている。

そもそも、自分でしっかりと理性を保ち自己を正し、職種を選ばずに働き続ければこんなザマには成らないし、ましてや他者との価値観や世界観の乖離に苦しんだとしても諦めや割り切りができただろうに。とは言葉は容易に並ぶ。

現実としては、いくら自分なりにがむしゃらにやってきても、他者や集団の共有している価値観や世界観と一致していなければ、人間は生きる権利を剥奪されても仕方無いのかもしれない。その人間が五体満足で言葉も喋れるなら尚更である。

この散文の筆者の抱く『世界観』『価値観』

もっと陳腐でバカらしく書いてしまえば ユートピア観 だろうか。確実にこの「自己の中で思い描くユートピア」が他者との乖離に一役、もっとそれ以上にかっているであろう；

互いに気ままな創作行為
創作物によるじゃれ合い喧嘩
創作して表現する権利(それこそ、富・地位・名誉・腕っ節で簡単に奪われないもの)

確かに私は労働は嫌いではある。しかし、労働は経済や社会の持続の為には必要であるし、理由はなにであれ「創作表現ができないが、他人の手足になれるし喜びさえ感じる」人はいるし、そういう人達の喜びを奪うつもりは無い。

とはいえ、
「人間社会を生き抜く為に戯れ言や世迷言よまよいごとを言わないと気が狂うし、実際気が狂ってしまった」
私としては、そういう「遲れてきた自我」なのか「自覚せぬまま過ごした自我」が暴発している上、人の手足になる事が人間とは思えぬ程に出来損なっている。

そして自分の体験から産まれた詭弁とは思うが、
「創作表現ができない人は、何か道具や知識が足りてなかったり、用いる道具や知識を習得する為の階段を踏み外してしまったのでは」
「もしかすると当人の中では最適な道具が思い浮かんでいるけど、当人が持ち合わせている能力や知識だけでは、道具を作ったり表現する事ができない為に、不安や苛立ちを抱いている可能性もあるのでは」
「そして私にとっても都合の悪い事に、当人の表現が伝わらない自分の様なのが居たりもする」
という発想が出てきたりする。逃げているのかもしれないが。

〆(しめ)

この記事を投稿しているサービスが、
「プログラマー、クリエイターが何でも気軽に書けるコミュニティ」
であった事をトイレで用を足して思い出したので、ちゃんとそういう事は書き留めておく：

ダラダラ書いて察しの良い方は、
「あ、リチャードストールマンほどには過激じゃないけど、フリーソフトウェア信者だな」
と思ったであろう。その通りだ。

フリーソフトウェア信者だからこういう意固地な発想に至るのかもしれないし、元々意固地な発想がフリーソフトウェアに触れて強化されてしまったのかはここでは脇に置く。

『パソコン』と書くと高価な印象を与えるかもしれないが、もっと広く「パーソナルなコンピュータ」と書けば、スマートフォンやワンボードコンピュータだってパソコンである。

安価だと処理能力も低いため創作物を作る一手々(いっていって)にかかる時間も増えてしまうのではあるが、私の様に、
「準備や後片付けの時間が10kmを6km/hで走る事を3回やった後の様に疲れてしまうし、ましてや忘れ物も多い」
という人はむしろパソコン上で創作活動をした方が良い気がしてしまう。

また、パソコンというよりはプログラミングかもしれないが、焦らす者はいない。ただし細かい事にいちいち躓いてしまうため、しょっちゅう製作者に、
「ここはどうしたら良いんです？」
や、
「ちょっと知らない単語がでてきたんですよ」
または、
「書かれた通りにやりました(製作者の思った通りとは言っていない)!」
という面倒臭いしウルサい道具なのではあるが、私の様な、
「他人に不信感を抱き安く、不信感が限界になると喋らないので仕事の確認もできない」
様な人型害畜の相手をするよりは大分マシと思う。

更に今日では『図書館』という「調べもののプロフェッショナルが居る知識の宝庫」や『オープンソース・フリーソフトウェア』という「具体例の宝庫」があるので、パソコン上の道具で気になる事があれば、腑に落ちるまで中身を覗いたり、せっかくなら自分の都合良く改造して使ってしまって良い(ここではその際の著作権・ライセンスの話は省く)。

パソコン上で無くても良いのではあるが、創作って楽しい地獄なんでな……つい深く入っちゃうんよ。

📔 マイペースに技術研鑽を継続する方法

2021-06-26T20:44:05+09:00

Image by Hans Braxmeier from Pixabay

はじめに

技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。

昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃

ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。

技術研鑽のサイクル

自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。

「きっかけ」：実現したい開発アイデアが浮かぶ

Image by Hans Braxmeier from Pixabay

個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。

アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。

また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。

当たり前ですが NDA に触れるような内容を自身の成果として公開してしまうのは絶対にダメです。あくまでも一般的な技術知識のみを自身の得た知見として公開するというスタンスです。

「行動」：開発アイデアを検証可能な形で実装する

Image by Sasin Tipchai from Pixabay

開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。

例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。

技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。

まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。

「みかえり」：過程で得たもの全てをアウトプットする

Photo by Greg Rakozy on Unsplash

成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。

上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。

成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。

具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。

ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤修一さんの Youtube 動画と同様の考え方に自然に至りました。

全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮

おわりに

現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。

また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違

この記事内容がどなたかの行動を起こすきっかけとなれれば幸いです！🙏

ある日突然ロードアベレージが200を超えた

2021-05-14T12:59:20+09:00

※サーバの知識が乏しい為、誤った情報を載せるわけにもいかないので
具体的な解決方までは記載してません。ポエム感覚です。

何が起きた

ある日、自分が開発した社内チャットツールが504エラーで開けなくなりました。
クッソ時間をかけてターミナルを開き、topで確認したところload average：86　となっていて爆笑しました。（笑っている場合ではない）
その後、色々対処している最終に230くらいになりました。写真撮っておけば良かったな(白目)。

どうしてそうなった

他のツールから、かなりの数のメッセージが送られてきたのが原因でした。
と言っても1分に100件～200件程度なので、めちゃくちゃ多いのか？と言われれば微妙なところです。

とりあえず復活させるぞ

実は以前にも同じことが起きたのですが、そのときはまだサーバの知識が今より乏しく、
とりあえず早く復旧させなきゃという気持ちが先走ってrebootしてしまいました。
もちろんこれで直ることもありますが、下手するとrebootしてから1時間くらい立ち上がらないなんてこともあるので(経験者は語る)、
むやみにやらないべきだと思います。

何が原因か突き止める

めちゃくちゃ重いときはターミナルを開くのも一苦労であることが多いですが、めげずに待ちましょう。
で、私はとりあえずtopでロードアベレージやメモリ、CPUを確認します。
入っているなら、htopの方が見やすいかも。

その後はひらすらググります！！！
「ロードアベレージ　高い」「メモリ　解放されない」とか。
もっと根本的に「504エラー　原因　突き止める」とか。

あと、アプリ自体のlogも確認します。
今回の場合は、ログファイルが朝の時点で昨日より3倍のサイズだったり、
メッセージ送信のAPIがめちゃくちゃ呼ばれていた形跡があったので、予測通りこれ原因だな…と確信しました。

原因の元をどうにかする

とりあえずApacheの再起動を試みましたが、タイムアウトでエラーになり出来ませんでした。
これはkillするしかないな…と思い、以下のように対処。

# Apacheのプロセスを確認
ps agx | grep httpd

# とりあえず一番上に出てきたプロセスをkill
sudo kill 34568 (※PID)

# ロードアベレージが落ち着いてきたらApache再起動
sudo systemctl restart httpd

この処理が終わるまでも時間かかりますが、
killされてからは徐々にロードアベレージも減っていきました。
Apacheを再起動し、なんとか復旧しました。

おわり

根本的に、
「100件程度のメッセージで落ちないような設計にしろよ！」とか
「そもそも1分に100件送ってくんなよ！！」とか
その辺りの問題はまだありますが、それはまた別の話として。

以前よりはサーバダウンにも冷静に対処出来たんじゃないかなと思います。
今回は原因がわかっていたので良かったですが、また別の要因で再発したときにも慌てず対処したいなと思う所存でございます。

【プログラミング全般】「登録する」の意でregistと書くことの是非について

2021-05-12T21:20:27+09:00

はじめに

「登録する」という意味でregistと書くのがあるあるなのかは分かりませんが、色んなプロジェクトで色んな人が書いたコードを見ても、結構registが使われていました。

英語的には誤りであり、registという単語は存在しません。正しくはregisterです。ではなぜregisterではなくregistが使われているのか、そう書いた人ひとりひとりを捕まえて「あなたはなぜregiterではなくregistと書いたのですか？」とインタビューすることはできないので、勝手に推測しています。

registerではなくregistを使う理由を推測

-erが動詞っぽくないから

個人的には一番それっぽい理由だと思います。

registerはまぎれもなく動詞なのですが、-erという接尾辞が「～する人」ということを表すので、-erを抜いたregistが「登録する」ということなのだろう、と思ったのではないかということですね。まぁ分からなくはないですが、辞書引こうよ…とは思いますね。

慣習になっているから

自分たちが手をつける以前のソースコードでびっしりとregistが使われており、registerを使いたいけど統一感なくなるのも気持ち悪いので、いやいやregistを使っているパターンですね。

短い方がいいから

registerという語であることは知っているけど、registの方が短いしチーム内で意味も伝わるからregistにしているパターン。これもなくはないでしょうし、ベテランエンジニアがこんな感じで書いてたら他のメンバーも合わせざるを得ないみたいな感じになりそうです。

insert→ins、update→updみたいに省略してもある程度意味が伝わるので、わざわざregisterと書く必要はないじゃんという発想かもしれません。

おそらく上記のような理由があるのではないかと思います。

ググってみる

「登録する regist プログラマ」みたいなキーワードでググってみたところ、以下の記事がヒットしました。

「登録する」の罠: registは間違い、アクセントにも注意

registerではなんとなく動詞らしく見えないので、こういう勘違いが発生してしまうのでしょう。

「動詞っぽくないから説」を提唱されています。私もそう思います。ちょっとややこしい単語ではありますよね。

この記事へ反応する形で、次のような記事もありました。

正確さよりも意図が“素早く正確に伝わる”ことが重要 - 2011年09月05日

プログラマやＳＥにとって、この単語が正しい英語かなんてどうでもいいことだ。さらに発音なんてさらにどうでもいいことだ。重要なことは、この単語を見た人間（おそらく同じプログラマかＳＥか）が、この単語が付いた機能なりファイルなりの概要を名前から安易にかつ正確に想像できるか？という点にある。

これに関しては半分同意といいう感じです。発音に関しては個人的にはどうでもいいと思います。それは私の周りにもネイティブの英語話者がいないからかもしれないですが、コードレビューしていて「このトライアップロードメソッドは何をしているの？」みたいにカタカナ英語で言いますし双方通じています。

ネーミングから容易に処理が分かるかというのも大事な視点です。

たとえば、認証という単語はrecognitionやcertificationを使うのが妥当だと思われる。しかしrecognitionやcertificationという単語はあまり馴染みが無い。意味を調べるのに辞書を要する人間も多いだろう。さらに文字数も多すぎる。それを考慮して、俺は認証をする機能にはauthという略語（造語？）を良く使う。

これに関しても同意できます。一方、英語の細かいニュアンスの違いを命名に落とし込んであると、より良いコードだなと思うこともあります。たとえば

beginとstartの違い
deleteとremoveの違い
sinceとfromの違い

などがコードリーディングを助けることもあるでしょう。

例として挙げられているものでも、たとえばrecognitionだと「一度認識しているものを改めて認識する」ようなニュアンスの認証ですし(接頭辞re-が付いていますね)、certificationだと「何かを申請して、それが他の誰かに承認される」ようなニュアンスの認証、auth(authentication)だとIDとパスワードを使って認証(本人確認)するようなニュアンスの認証です¹。これらのニュアンスの違いがあるのに、認証は全部authでいいや！というのはちょっとどうかと個人的には思います。

英語はやっぱり大事

そういう意味では、「正しい英語」というのはニュアンスの違いなどの理解が及ぶ範囲であれば、それは重要だと個人的には思います。ただ、registとregisterに関してはニュアンスの違いとかではなくそもそも存在しない語と存在する語の違いなので、ここでは若干違う話題ではありますが。

また、プログラミングはだいたい英語を使うため、正しい英語の重要性みたいなのを理解していないとトンチンカンなコードを書いたりします。一度directoryPassみたいな変数を見たことがあります(おそらく書きたかったのはdirectoryPath)。pathは結構頻出基礎的な単語だと思うのですが、自分より何年も長くコードを書いているような人が間違えていると、ある程度正しい英語を使うクセ付けというか、そういうのは大事だよなぁとも思います。少なくとも分からなかったらググる、あまりにも長くなりそうだったらローマ字で書くとかが「正確に伝わる」という意味ではアリだと思います。ローマ字の是非はまた議論が別れそうですが、個人的にはpathをpassと書かれるくらいならpasuと書いてもらった方が…いやpathくらい覚えてほしいな、やっぱ。

個人的にはregistだろうがregisterだろうが意味は伝わるので、既にregistが使われているプロジェクトではregistを使います。でも自分が0から作るならregisterを使います。IDEの補完機能などを使えば2文字増えようが関係ないですし、逆に2文字をケチって「あれｗこの人registっていう英単語はないって知らないのかな？ぷっぷくぷーｗ」と思われるくらいならしっかり書きます²。まぁ思われても別にいいですけど。

結局は環境次第ということだと思います。メリットデメリットあるので、ある程度クローズドな環境であればregistでもいいんじゃない？とは思いますね。ただ、世界中に公開するようなコードを書くのであればregisterを使っていた方が無難だとは思います。少し紹介しましたが、insert→ins、update→updで伝わるのになんでregistはダメなんだ！と思われたら、中途半端に略してて気持ち悪いからだと思います。中途半端にerだけ省略しても誰も幸せにならないのでregくらいまで省略すれないいんじゃないですかね？regだったら省略しているということが明かなので。registだと若干ひっかかるというか、気持ち悪い感は否めないです。個人的に。

私の理解が正しいかはわからないので鵜呑みにしないでくださいね。 ↩︎
私がregist派のみなさんをそのように思っているという訳ではないですよ。 ↩︎

新卒IT社員に伝えたいこと

2021-04-15T20:19:11+09:00

はじめに

プログラムを書いてエラーが出ると「自分が否定された」「尊厳を奪われた」と感じる人もいる、という話

上記のまとめを読んで、何年か前にこういう新人さんがいたことを思い出しました。

せっかくなので私も、IT新人さんへ向けてのTIPS的なものを書いてみようと思います。各所で言われていることかもしれないですが書いてみます。

なお、あくまで私の個人的な考えなのであらゆる組織で通用する考えという訳ではないので注意してください。私自身はそんなに有名なサービスに関わっている訳でもない、ただの地方のエンジニアです。そんなに変なことは書いてないと思いますが、以下を鵜呑みにせず色々な人の「IT新人へのアドバイス」みたいな言葉を見て、必要な情報を取捨選択してください。また、分からない用語などが出てきたら都度ググってみてください。

エラーは怖くない

上記のまとめでも言われていることですが、エラーを怖がる必要はありません。正確に言えば、本番で出たエラーは怖いんですが、開発中やテスト中はむしろどんどんエラーを出すべきだと個人的には思います。

開発中やテスト中にエラーが発生すると、当然デバッグすることになります。すると本番ではそのエラーは発生しません。エラーは本番で発生すると、その調査や修正によりコストがかかります。

それらは実際にリリースされて既に価値を生み出している製品なので、稼働を止めることによる機会損失や、ユーザーの信用を失うことに繋がるからです。

一方、開発やテスト中にバグを見つけて修正することができれば、機会損失や信用の失墜を避けることができます。

上記まとめにもありましたが、エラーや警告のメッセージはあなたを攻撃したりあなたを否定したりするものではありません。逆です。「こういうミスがあるよ」「ここの書き方がちょっとおかしいよ」「一応動くけどデータによってはエラーになるかもよ」と教えてくれるものです。

動いているものが急に止まって、よくわからない英語がダラダラーっと出てくるので怖いかもしれませんが、一つ一つの文章はとても簡単な内容なので噛み砕いて理解するのは簡単だと思います。

使える機能やライブラリは積極的に使う

あなたが何かの機能を作ることになった時、その「何か」は既に他の人が似たようなものを作ったりしていることがあります。

それを自分でやることは、それはそれで良い経験になったりはしますが、ITエンジニアは「面倒なことや難しいことを1と0で解決させる」ことです。要は、基本的に面倒くさがりな人が向いている気がします。誰かが既に作っているものを自分で新しく作るのこと(車輪の再発明と言ったりします)は基本的にはやめた方が良いでしょう。

特にOSSなどで広く公開されているライブラリなどは積極的に導入を検討するのも良いでしょう。それらはあなたが個人で開発するよりも、より大勢の人の目によって使われて何度もバグが修正されていたり、最適化されていたりします。

ただ一点勘違いしてほしくないのは、「自分で書かないだけで、書こうと思えば書ける」という状態にはなっておいた方が良い、ということです。

たとえば配列のソートなんかは、だいたいどの言語でもarray.sort的なメソッドがあります。ソートをするならそれを使えば良く、わざわざソート用のメソッドをあなたが0から実装する必要はありません。

ただし、「じゃあソートってどういうアルゴリズムなの？sortっていうメソッドの中では何をやってるの？」という状態は好ましくないと個人的には思います。そういう状態であれば、ソートをするメソッドを書いてみるのも良いでしょう。それにより配列の特性を学んだり、なぜこの処理だと時間がかかるのか、なぜこの書き方が推奨されるのか、などを実体験として獲得できます。これは大きなアドバンテージで、この体験を積み上げていくことがとても大切です。後に同じような問題が発生した時も、これらの経験から「ここが怪しいんじゃない？」となんとなく分かるようになります。

また、エディターによっては変数名やメソッド名の自動補完や、より良い方法を示したりする機能もありあます(EclipseのContent AssistやVisualStudioのIntelliSenseなど)。それらは便利な反面、「関数名などを中途半端にしか覚えなくなったりタイピングが上達しなくなったりするなどの理由から、新人さんには使わないように言っている」という人に一度だけ会ったことがありますが、個人的には使えるものはなんでも使って言った方が良いと思います。

どうせ関数名は英語が分かればだいたい分かるし、何度も使ううちに覚えていきます。タイピングの上達は確かに大事なことですが、入力補完でtypoを減らせるのも充分なメリットです。毎日何時間もキーボードを叩いていれば自然にタイピングは上達すると思います。それにどうせ後から使う機能ならば最初から慣れておいた方が良いと思います。私だったら、気になったものはなんでも使ってみるように指導します。

ネットから拾ってそのまま使わない

上記と少し矛盾するかもですが、ネットからコードを適当に拾ってきてそのまま使うのは避けた方が良いでしょう。

理由は以下の2つです。

そのまま使うだけでは得るものがないから
ライセンス的に問題があることがあるから

まず1点目ですが、たとえば何かしらの関数をググってコピペして、それであなたがやりたかったことが実現できたとします。すると、あなたのコードを見た先輩や上司が「ここはなんでこの変数名なの？」「なんでこういう書き方をしているの？」などと疑問に思うかもしれません。

そのような質問をされた時に、ネットから拾ってコピペしただけだとスムーズに答えることができません。これだと、先輩の疑問も解消されませんし、何一つ学べていないということになります。ググってコピペするというだけの簡単な作業ですが、せっかくなら何をしているか分かった方が良いですよね？

特にITの世界は移り変わりが激しいので、その記事が書かれた当時ではモダンなコードだったとしても、1～2年経ったら古臭い書き方、懐かしい書き方になっていることもザラにあります。古臭い書き方が常に悪という訳ではないのですが、コードを見る人は「なんでわざわざこんな書き方してるんだろう？」と疑問に思う訳ですね。

また、致命的なバグが含まれている可能性もあります。私が執筆している記事に関してもその可能性はあります。そして、仮にコピペしたコードがバグを引き起こして何かしらの損害を被っても、そのコードを書いてネットに載せた人は一切責任を取ってはくれません。

2点目は、ライセンスの問題です。無償公開してあるものでも、MITライセンスなどは著作権表示が必要です。ライセンスポリシーによっては料金が発生するものもあるでしょう。当然不正使用となると重大な問題、コンプライアンス違反となります。

アウトプットするクセをつける

得た情報は積極的にアウトプットした方が良いです。なぜなら、アウトプットして他の人の視点が入れば、「ここはこんな感じにも書けますよ」とか「他にもこんなに便利なツールがありますよ」など意見交換に繋がるからです。発信した内容(自分が事実だと思っていたこと)に誤りがあればそれを指摘してもらい、正しいことを知るきっかけになったりします。

そしてアウトプットしておくことで、後から自分が見直すことができます。「久々に〇〇をやろうとしてググったら自分が書いたページがヒットした」みたいなのも、たまに見聞きします。

アウトプットするのもいくつか方法はありますが、オススメなのはQiitaです。アカウントを作っていなければ今すぐにでも作って良いと思います。他にも私が利用しているCrieitや¹、ブログを書くというのもあります。QiitaもCrieitも、ブログではWordpressやはてなブログでもそうですが、Markdownで記事を書くことができます。Markdownに慣れておくのも良いと思うので、練習がてら書いてみると良いでしょう。

また、「今から調べることは後からまとめてアウトプットするんや…！」というつもりで情報を集めると、不思議なことに集められる情報の質が上がります。自分の理解を越えて良いアウトプットをすることは出来ないので、良いアウトプットをするなら必然的に自分の理解度を上げることに繋がります。これは最終的に自分が得をします。

また、アウトプットのクセを付ければ、他の人がわかりやすい表現をする練習にもなります。自分だけが分かる書き方ではなく、誰にとっても分かりやすい表現ができるようになります。信じられないかもしれませんが、人によっては「ボタンを押したらデータと日付を画面にオープンする」みたいなことを仕様書に書く人もいます²。結局「どのデータか」「日付はどういうフォーマットか」「画面にオープンするとはどういう意味か」などといちいち質問する必要があり、それは双方にとって不必要なコミュニケーションコストです。初めから分かりやすく書かれているに越したことはありません。

道具にこだわる

あらゆる道具にこだわりましょう。キーボード、マウス、モニター、机、椅子、OS、エディター、その他ツール…挙げればキリがありません。

キーボードなら日本語配列か英語は配列か、フルサイズかテンキーレスか、キーピッチはどうするか、直行配列にするか、セパレートキーボードにするか、トラックポイントは必要か、ワイヤレスか有線か、キースイッチは何方式か、メカニカルなら何軸か。モニターは何枚にするか、アームはつけるか、縦置きか横置きか、インチ数はどうするか、画面解像度はどうするか、デイジーチェーンにするか、など色々と拘こだわることができます。

会社の都合などで、特にハードウェアは望み通りのものを使えないことがあるかもしれませんが、こだわることは大事だと思います。たとえばタイピングしやすいキーボードはそれ自体がモチベーションにもなりますし、見た目でも性能でも気に入れば愛着がわいて長く使いたくなります。職業柄PCに向き合う時間も長くなるので、せっかくなら徹底的にこだわって好きなもので固めた方が楽しいです。

便利なショートカットを覚える

ショートカットはめちゃくちゃ便利です。使いこなせばキーボードからマウスに持ち替える動作が大幅に減り効率化できます。

Windowsであれば

Ctrl + C(コピー)
Ctrl + X(切り取り)
Ctrl + V(貼り付け)
Windows + E(エクスプローラーを開く)
Alt + D(エクスプローラーやブラウザのアドレスバーにフォーカス移動する)
Alt + Tab(表示中のウィンドウを切り替える)
Windows + 数字(タスクバーにピン留めしているアプリを起動)

あたりはマジでよく使うと思います。普段から慣れておくと良いでしょう。付箋などに書いて目に入る場所に貼っておくのも良いと思います。

タイピングに早く慣れる

馬鹿にしている訳ではないですが、「最近の新人さんはスマホ世代なので、タイピングに慣れていないどころかローマ字もよく分からない人が結構いる」みたいな発言を見ました。その状態ではプログラミングはおろか、チャットやメールなども難しいと思うので、とりあえずさっさとタイピングに慣れましょう。

上記にある通りアウトプット記事を書いてみたり、寿司打などのタイピングゲームをすれば慣れてくると思います。ホームポジションを覚えればかなりタイピングもスムーズになるでしょう。たまにタイピングが遅くてホームポジションもめちゃくちゃだけどめっちゃ優秀な人もいますが、まぁしっかりタイピングできるに越したことはないと思うのでしっかり慣れましょう。

プログラミングはほとんどが英語の単語や文章なので、ローマ字のタイピングは得意でも英単語はスムーズにタイピングできないという人もいます。できれば練習の段階で英単語も挑戦するようにしましょう。

タイピングに関してはキーボードとの相性も関わってきますので、自分にあったキーボードを見つけることも重要です。特にホームポジションは変な癖がつくとなかなか矯正できません。私も昔はずっと小さいキーボードを使っていて変な癖がついてしまっています。

わからないことをわからないまま放置しない

これが結構大事かもしれません。わからないことをわからないまま放置すると、後から調べるにも面倒になります。ググれば10秒もかからず調べることができるのですから、せめて概要だけでも知るようにしましょう。SiriやGoogleアシスタント、Alexaなどの音声アシスタントサービスを利用するのも良いでしょう。

ミーティングにPCやタブレットなどを持ち込めるのであれば、ミーティング中に出てきたよく分からん単語をその場で調べたり、メモしておいて後でググったりすると良いでしょう。ミーティングがオンラインであればなおさら簡単にできますね。ちなみに弊社は絶賛オフラインです、本当にありがとうございました。

一般的なことであればググれば分かることが多いですが、詳しい人に聞くのも効果的です。その人独自の視点や体験を交えて教えてくれるかもしれないですし、ググるだけではたどりつけない情報を知ることができるのも、人に質問することの大きなメリットです。人間は知識をひけらかしたい生き物なので、質問されて嫌な人はそんなにいないと思います。先輩だろうが上司だろうがガンガン質問していきましょう。

まとめ

色々と書きたいことはありましたが、まぁ概ねかけたと思います。他にも「ググる力を付ける」「情報取捨選択の力を付ける」「手段にこだわりすぎない」なども書こうと思ったのですが上手くまとめられなさそうなのでやめました。要望があったら書きますので、Twitterなどで反応いただければと思います。

Qiitaに記事はほとんど書いていませんが、アカウントは作っています。Crieitを利用している理由は、メインでブログを書いており、カノニカルURLを設定がQiitaではできずCrieitではできるからです。 ↩︎
組織やチーム内で、最終的なイメージや暗黙の仕様が充分に共有されていればこの粒度でも良いこともありますが…。 ↩︎

現役サーバエンジニアしてる私の話【自己紹介】

2021-03-24T21:41:25+09:00

はじめまして、ゆみおです！
サーバエンジニア歴7年ほどで、ずっとやってみたかった技術ブログに手をつけました。
技術記事を投稿していく前に、自己紹介を書こうと思った次第です。

【本記事の内容はこんなかんじです】
* どんな人か
* サーバエンジニアになるまでの経緯
* どうして技術ブログを始めようと思ったのか
* 書こうと思っている記事の内容

どんな人か

サーバエンジニア歴7年
（RHEL、Windows、ESXi、シェルスクリプトなど）
一児の母（育休復帰済）
ゲームと音楽が好き
時々ゲーム実況配信、投稿
めんどくさがり

こんな感じです！

サーバエンジニアになるまでの経緯

大学は芸術大学に通っていました。
就活はちょうどリーマンショックが起こり、就職氷河期と言われていた頃。
就活をナメになめていた私は当然就職できるはずもなく、
卒業後、1年半ほどはフリーターをしていました…笑

ライブハウスの依頼でフライヤーやCDジャケット作ったり、
スーパーでパート勤務して、友達の伝手でWeb制作のバイトをして。
親からさすがに「そろそろ就職しろ」、と言われてWeb制作してた会社で社員になります。

が、Web制作だけでは正社員に払えるようなお金が会社に入らないとのことで、
サーバエンジニアのドキュメント作成要員として客先常駐の仕事をすることになりました。

そこの常駐先のお客さんがとても良い人で私をサーバエンジニアとして育ててくれました。
それから別の会社に転職して今に至る感じです。

どうして技術ブログを始めようと思ったのか

ずばり、承認欲求が私を動かしました！笑
大人になると誰も褒めてくれないの！笑
褒められたいし感謝されたいんだ、「いいね！」くれ！！！笑

でもずっと書きたいなあとは思ってたんです。
自分の性格上、仕事で学んだことや情報のメモを付けることが習慣になっていて、
でも何回かそのメモを参考にしても、フォルダの奥底に眠ってしまうことが多くて、
情報共有すれば、助かる人がいるかもしれないのに、もったいないなあって。

ドキュメント書くのは好きだし、
他人に教えるの好きだし、
他人に伝わりやすい書き方の勉強にもなるし、
アウトプットすることで、自分の頭に定着しやすいし、
もしかしたら収益化できるかもしれないし←

メリットしかないじゃん！！ってなったわけです。

書こうと思っている記事の内容

書こうかなと思ってる記事の内容はこんな感じです。
* 初心者向け、IT基本講座
* 初心者向け、Excel、Word、PowerPointを使った資料作成講座
* RedHat Enterprise Server（CentOS）の構築手順
* ミドルウェアの構築手順（Zabbix、Oracleなど）
* 便利そうなシェルスクリプトの公開
* Macbook AirでSwitchゲーム配信する手順

主に仕事で関わる部分だったり、趣味の範囲だったりです。

以上です。
まだ記事は書いてませんが期待を込めて
「いいね！」や「フォロー」してくださるととても嬉しいです！

技術的な有料記事を書いていくためにどうすればいいかの考察

2021-01-06T08:06:50+09:00

技術的な内容で有料記事を書いていこうと思った場合に、一体どのプラットフォームに、どの様に書いていけばいいかを考察してみました。

ちなみに僕は別に単体の有料記事で稼いだことはありませんので基本的に以下の内容は個人的な想像です。また、技術書展やZenn等での「本」の販売については今回は含みません。単体の有料記事についての話になります。

前提

集客について

「書けば売れる」そんな場所はありません。「noteの有料記事で稼いでるって人がいるから自分もやってみよう！」……売れません。というか誰も見てくれる人すらいません。

基本的に集客は自分で頑張る必要がありますし、そうでない場合は何かうまい方法を考える必要があります。

有料であることに躊躇しない

無料のアウトプットが世の中にあふれています。「なんだ、有料かよ、読んで損した」なんて罵声をあびることもあるでしょう。ただそれは気にする必要はありません。重要な情報が有料であるのは当たり前のことです。無料のものが多すぎて多くの人が当たり前のことを忘れているだけなのです。

「有料で買ってよかった！」と思ってもらえるような情報を提供するよう努力すればよいだけです。なんとなく見たい、と思う人は買わないかもしれませんが、絶対欲しい、なにがなんでも必要！　という人は買うでしょう。無理にみんなに買ってもらおうとせず、そういう方々に買ってもらえればよいだけです。

noteの有料マガジン

noteには有料マガジンという機能があります。記事の投稿者は有料マガジンを作成することができます。記事の閲覧者は有料マガジンを購読することでそのマガジンの全ての内容を閲覧することができます。購読していない場合は一部だけが閲覧できます。

記事にしろアプリにしろ、毎月継続して費用を払ってもらえるのは重要なことです。一回きりの金額と、毎月発生する金額というのは当然積み重ねると大きすぎる違いがあるからです。

そのため単に有料記事を書くよりも、有料マガジンを利用してユーザーを手放さない執筆運用をしていくことが本来は望ましいでしょう。

しかし、その場合は当然ユーザーが飽きないように続けていく必要があります。しっかりと止まることなく継続することが必要となります。

また、書く内容についても考える必要があります。というのも、例えば僕の場合はサービス開発についてのポエムを書いたり、フロントエンドのことを書いたり、バックエンドのことを書いたり、インフラのことを書いたり、アプリのことを書いたり、かなり雑多なことを書いています。この場合、たとえばフロントエンドについて興味のある人が購読してくれたとします。しかし書かれる内容はアプリのことだったりよくわからないポエムだったり。そうなると解約してしまうでしょう。

購読してくれた人がずっと見続けていられるように、内容については絞って書いていくべきだと思います。もしくは別ジャンルについてもたくさん継続して書けるのであれば別の有料マガジンとしてどんどん書いていくと良いでしょう。

なんにしろ「大変」であることに間違いはないです。書くことが好きでなければ続かない可能性はあります。

投げ銭

noteやZennでは記事に対して投げ銭をすることができます。Twitter等で「サポートしてもらった！」というようなツイートを見かけることもよくあります。

このようなサポート機能は、特に有料記事ではなく一般公開記事として書いても投げ銭してもらえることが特徴です。

ただし、「有料記事で稼ぐ」という観点で考える場合は投げ銭はあてにしない方が良いでしょう。どれだけ有益な記事を書いたとしても基本はサポートされないと考えましょう。してくれる場合は割と知り合い同士だったり、投げ銭慣れしている人ばかりだったりします。検索でたどり着いた人などはそもそもユーザー登録などもしていませんので、投げ銭自体知りませんし、登録してまで投げ銭しようと思い立つことはほぼ無いでしょう。

されたとしても振り込みが発生するレベルの額に到達するにはかなりの年月がかかると思われますので、ちょっとしたお小遣い程度になると思います。

普通の有料記事

あとは普通の有料記事です。noteや当サービスCrieitで有料記事を書くことが可能です。また、Zennでも本機能を使って有料記事として売っている人もいるようです。

ただしそれで稼いでいくことはなかなかに厳しいと思います。前述のマガジンと異なり、１回きりの購入となります。一度買ってくれたユーザーが他にも買ってくれるという保証もありません。その場合は投げ銭と同様雀の涙程度の稼ぎになるでしょう。たくさん売るためにはひたすら頑張って集客し、継続的に売れる仕組みを作っていかねばなりません。

ただしこれはシンプルであるがゆえにやり方によってはそれなりに売っていける可能性も秘めているような気がします。どのように有料記事を書いていけばいいかを考えてみました。

マイナーな内容を書く

マイナーな内容は有料記事に向いている気がします。というのも、メジャーな内容というのは自分以外にも多くの人が興味、関心をもちアウトプットしています。そもそも有料部分として書こうと思っていた部分は、自分が思いつくより前にすでにわかりやすくて詳しい記事として一般公開されている可能性も高いですし、量も多いです。そういったありふれた情報をわざわざ有料記事として買ってくれるような人はいないでしょう。

有料で売りたい内容は程よくマイナーであると良いでしょう。どのくらいかと言うと、その技術自体は世の中にありふれているけども、その機能自体は全然情報がなく、検索しても全く見つからない、もしくは見つかったとして英語の情報ばかりや、わかりにくい記事の中にちょろっとその話が混じっている程度、というレベルです。例えばPHPの情報はありふれているけど、その中で～～をやろうとすると誰もやったことがない、という情報です。

こういった情報はあまり需要がないかもしれませんが、でも逆にいうと探しても全然見つからないため、それを直接必要としている人にはかなり需要が高いです。

最初の前提で「集客は自分で頑張る必要がある」と書きましたが、この方法であれば検索でも見つけてもらいやすい気がします。もうそこにしか情報がないのでは、と思ってもらえれば解決のために買ってもらえる可能性も上がるでしょう。

とは言ってもマイナーすぎる情報はやはり売れないでしょう。売れても生涯で数件程度かもしれません。このあたりのバランスを模索しながらたくさん書いてみる必要はありそうです。

そこに答えがある、と感じさせる

適当に有料記事を書いても売れないと思います。公開部分と非公開部分の絶妙なバランスは必要です。無料公開部分で記事に納得感を与えることで、「あ、この人は絶対答えわかってるな」ということを感じさせます。そして、ギリギリのギリギリまで無料部分で詳しく解説を行います。そして最後の最後に、絶対必要な情報、もしくは絶対読者が欲しがる情報を有料部分として販売します。

というのも、有料記事を買わない理由の一つに、買っても欲しい情報がなかった、という可能性がありそうだからです。有料部分は見えないため、買うまでわかりません。本当に欲しい情報があるかどうかわからないとどうしても躊躇しています。そのため、あ、絶対にあるわ、と思わせるような流れを作ることはかなり重要だと思います。

逆に、かならず有料部分には買って納得できるものを書いたほうが良いでしょう。頑張って書いても最初はそれが達成できなかった場合、どんどんブラッシュアップしていけばよいでしょう。

有料にする必要のないもの

とはいえ、全てを有料記事にする必要はありませんし、有料記事だけを書く人になる必要はありません。下記のようなものは無料のほうが良いでしょう。

自分をアピールしたい場合

自分の持っている技術をアピールする場合や、それによってその技術者を探している人を集めたい場合などは無料公開にしてどんどん自分、もしくは自社のことを知ってもらえるようにした方が良いでしょう。

布教したい情報の場合

たとえば新たに出たフレームワークや、お気に入りのライブラリなどがある場合です。これはみんなにどんどん知ってもらいたい、という情報があれば無料で情報を公開して世間の認知を広めて自分にとってもその技術が使いやすい世の中にしていくことができます。

古すぎる情報の場合

古すぎる情報は探す人も少なく売れることも少ないと思います。こういう場合は元々有料記事であっても無料公開に変更し、メモリアルとして残していくほうが良いように思います。

まとめ

ということで色々と考察したことを書き残してみました。ぜひ試してみてください。

技術的な有料記事であれば当サービスCrieitでも販売が可能です。手数料はnoteより安いです。詳しくは下記解説にて。

有料記事を販売できるようになりました

AI画伯とか、2020年作ったもの反省

2020-12-31T11:51:36+09:00

今年はいろいろな方に支えられて、たくさんの個人開発アプリを作ることができました！
本当にありがとうございました！

大晦日なので、今年一年作ったものとか振り返りをしようと思います。

1. ピクセルミー - 自撮りドット絵変換

https://pixel-me.tokyo/

Twitterを本格的にやり始めてからサービスがバズるようになったので、
Twitterと個人開発アプリはとっても相性がいいみたい？です。

2. すごろくメーカー - リアルタイムすごろく作り

https://sugoroku-maker.tokyo/

だらさん主催のWeb1Weekというハッカソンで作ったアプリです。
ユーザーの投稿がメインコンテンツとなるサービスや、ユーザーが沢山いないと成り立たないサービスは難しいと再確認。。。

3. AI画伯 - 自撮り絵画変換

https://ai-art.tokyo/

ピクセルミーではTwitter共有などバズる仕組みをアプリに組み込まなかったので、AI画伯ではバズらせることを目標にアプリを作ってみました。
今までに1000万人以上の方に使っていただきほんとに嬉しいです！
バズったときはサーバー代金が大変なことになってしまい、皆さんにたくさん助けていただきました。
本当にありがとうございました！

4. 水たまりの鏡 - 地面を反射する水たまりにする

https://mirror-puddle.tokyo/

これもだらさん主催のハッカソンweb1weekで作ったアプリ！
全然流行らなかったのですが、たぶん生成画像のクオリティーが低すぎたのと、ユーザーが主体的に選択できる要素が少なすぎたのが原因かも？

5. AI Draw - AI線画お絵描き

https://ai-draw.tokyo/en/

AI画伯は画像の処理を完全にサーバーでしているのですが、それだとサーバー代が凄まじいことになるので、
AIDrawでは半分サーバー、半分クライアントサイドで処理しています。
試み的には成功したのですが、ユーザーの反応はイマイチ。。。

6. AI画伯風景画モード

https://ai-art.tokyo/

アーティストさんたちからは「ここで生成した画像をもとに絵を書きたい」みたいな感じでいい評価を頂いたのですが…
大多数のユーザーさんからの評価はあまり良くなく…
肖像画モードと風景画モードは使う層が違うのかも？

7. AI画伯アプリ

AppStore
GooglePlay
Flutterを使った初のアプリ！
高解像度化などの要望が強かったので、有料オプションを作りたいと思いアプリ化

8. AI画伯風景画アプリ

AppStore
GooglePlay

9. エモカメラ（仮）- リアルタイム水彩画変換カメラ

時代は動画！
な気がする。。。

まとめ

今年はいっぱいいろんな方に支えられ、いろんなアプリを作ることができて大満足でした！
私はマネタイズが苦手で、作ったものはほとんどお金になっていないのですが…
来年は好きなものを作りつつ、マネタイズに関してももっと勉強していきたいです！

社内SEに向いているのはこんな人（かもしれない）2020年振り返り記事

2020-12-18T04:35:01+09:00

あばうとみー

去年から田舎の小さな事業所(50名以下)で、
プログラマー兼社内SEみたいな仕事を　パート　でしている。
1年半ぐらい前から。（募集内容と違う職種で採用された）
何でも屋さんなのだけど、結果的に社内SEになってるんじゃ？と思ってそう名乗ることに。

前の仕事でメンタルぶちのめされていたため、リハビリのつもりの仕事だった（週3日ぐらいならなんとか行けるだろうと思って応募した、PCを使う別の内容の募集だった）。

パートですよパートですよ「パートさん」ですよ〜

（週2,3日契約だが最近は週3日というか週4日の時もある。出勤と在宅勤務と両方で。）
（しかし規定時間以下なので雇用保険入ってない、もったいない、、やめても失業手当出ない、、）

パートだけど、やりたい放題（？）

仕事は主にプログラミングなはずだったのだが、PC関連のことは全部回ってくるし、
PCに詳しい人は事業所内に他にいない。上司だけはちょっと詳しい。

これまで在宅勤務には対応していなかった、その事業所で仕事をしている。

（事業所を）在宅勤務に対応させる！

2020年は世の中が急激に在宅勤務推奨になっていった。
なので職場でも、なんとか在宅勤務ができるようにしようと、上司と相談して進める事になった。
環境の準備と、従業員の教育の両方が必要だった。

それと在宅勤務者が手が空いた時の、仕事の確保も。
さらに上司は上層部や担当部署へのツール使用許可申請が必要となった。

母体となる会社組織全体ではGsuiteが使われており、
じゃあGoogle使い放題じゃん、となるはずなのだが...。

事業所はほとんどが契約社員という名の3ヶ月更新の人々なので、使用制限があった。
GmailはOKだが、GoogleドライブはNGというGsuiteの無駄遣い状態なのであった。
（お金は払っているのに使える機能がかなり制限されている）

今回在宅勤務をするにあたり、Googleドライブの許可申請を母体の会社の担当部署にしたが
むげに却下されて、上司は戦意喪失してしまった。

ただ、取引先がクラウドサービスを使っていたので、結局そこに間借りする形で、
データのやり取りをすることになった。

私は資料とチェックリストを作り、在宅で本業の手が空いた際にやってもらう仕事を考え、
会社で使っている独自ツールのプログラムを書き換え、在宅でも使えるように対応させて、
もはやこれはパートの仕事ではないだろういう範疇で仕事を進めた。（コンサルぽいなぁと思いつつ）

仕事で何かに対応するためにどうしたらいいのか？を考えるのは苦ではないので、
上層部とのミーティングで失意の上司を「大丈夫、（私がいるから）大丈夫」と励ましながら（？）
緊急事態宣言明けぐらいだったかな、、在宅勤務に次々人を送りこんだ。

業務では社内にあるサーバーを使っているため、かつ、データを印刷する必要があるため、
【全員】の在宅勤務は叶わないが、なんとか出勤者を減らすことができた。

その間もその後も私は会社に出ていた。在宅勤務の人が増えると、
そのために会社でやらなければいけないことが増えるので、出勤する必要があるのだ。

在宅勤務に向いてない（私）

それに気づいたことがあるのだが、私は在宅勤務があまり向いていないようだ。
会社の中の状況が見えない、上司が忙しくしているのか何なのかわからない。
文字で連絡してもレスポンスが遅いと仕事が進められないこともある。
（確認しなくていい作業なら進められるけど。）

そういう時に私はネガティブに捉える性格なのだ。
自分が放っておかれているように感じてしまう。

在宅勤務、向いてないなーと思った。
基本、テレビ電話もネット面接もきらいで、
別に人と話すのが好きなわけでも会いたいわけでもないが
面接なら対面の方が（めっちゃ緊張するけど）マシ。
仕事も対面で状況を見ながら質問しながら進めたい。
（コーディングするだけの時は在宅でも大丈夫。）

人と仕事をするの楽しい（？）

自分だけで仕事を抱え込みたいわけではないので、
できることはどんどん空いている人がいれば頼むようにしている。
説明をしないといけないが、頼めばやってくれる人ばかりだ。
いろんな人と話をする。お願いをする。

お願いして喜んで引き受けてくれたのに忘れていたり（笑）、
終わった報告をしてくれなかったり、途中までで止まっていたり、
いろんな人がいるけど、私はそれを面白いと思えている（今のところ）。

仕事を頼まれることがいやじゃないから、基本的には相手もそうだろうと思えている。
いやだったら、やらなくていいからね！と伝えている（つもり）。

やったことがないから、と、ドキュメント作成で自信なさそうにいう人がいる。
やったことないことを業務でやらせてもらえるなんてラッキー！！と思う私なので
そうか、この人はこれはやりたくないのかな？と認識する。

たとえドキュメント作成だって、実務経験を積めたり、
わからないこと検索して調べながら資料を作れる機会なんて、
（そのことに興味があるなら、）チャンスだと思う。

どこかでその人の才能とか発揮されたらいいなと思って、
あれこれいろんな人に頼んでみる。

新しいものに意欲的な人もいる。
VBAとはいえさすがにコーディングは一朝一夕にはできないので、
できそうなところから頼んでみる。
本業があいた時にサイトで勉強しているらしい。えらい。

コミュニケーション取りながら仕事するの楽しい♪

あれ、私ってそういうタイプだっけ？と
思い返してみると
まさにそうだった。

役割があるところで人にいろいろお願いしたり、仕事の話をしたりするのは好きだ。
自分の個人的な話をしたり、他人の個人的な話を聞くのはきらい。（＝相手によっては聞く方はきらいではないけど、エンドレスでおしゃべりが止まらない人は苦）。

いろんな意味で、なかなか難しい！

人に頼むのは難しいし、教え方もわからない。
コーディングは自分は教わってないし、教わってできるようになるのかな？っていう疑問がある。
そして、自分が当たり前にやっていることは、これまで勉強していた積み重ねが役立っているのだなぁと気づく。

わからないなりに書籍を何度も読んで、ちっとも進んでいる気がしないのにJavaとか勉強して、
高い資格試験受けたり、めんどくささになんとか打ち勝って国家資格受けたり（申し込んだのに受けない人の多さよ、もう試験に出席できたらそれだけで半分勝ち）
ドットインストールやプロゲートやったり、
それでもちっともできるようになった気がしない。あれもこれもまだ何もわかってない。

VBAさえ、何も調べずにサクサク書けるわけではない、どう書くんだっけ？と調べながら書いてる。

既存の業務でのエクセルの使い方を見て、なんて非効率なんだ、と思うこともある。
（それを言うと直す事になるのは私なのだけど、言う）

社内業務でよかったなと思うのは締め切りがあまりない事。
なるべく早く、と言われる事もあるし、年末年始はいろいろ準備しないといけないのだけど。

スパルタ（自分のためにPCスキルを...）

今の職場で、後から入ったのに偉そうにしている私（偉そうにしているつもりはないが、先輩に仕事を頼んでいるのは偉そう？）。
パソコンのことで困ったことがあると、解決を求められる。頼られる。
そこで堂々と対応しているから、偉そうに見える？かな？かも？

今の職場の人にたちのPCスキルはあまりなかった。
だけど在宅勤務になったらある程度は自分で解決できないといけない。
私の作った「在宅勤務をする前にできるようになっておくこと、理解しておくこと」のチェックリストは50項目を超えていた。
そのせいかはわからないけど、全体的にPCの基本スキルは上がってきていると思う。
どうだろう。。。多分。。。

さらに在宅勤務ではなく出社の人にも、自分のPCの面倒がある程度自分で見られるように、と、
資料を作っては配布し、各自に作業をお願いしている。
わからなかったらわかる人に聞いてね！と伝えつつ（こんなにフランクな表現ではないが）、
徐々に、お願い事を増やしていっている。

質問されることといえば、

私がいる時は聞いてくれていいよ、とは言っているが、
飛んでくる質問は、
(WindowsUpdateをしたら)
「再起動してくださいって出たんですけど、どうすればいいですか？」
とか、
そういうのもあって（この質問をしてくれたのは1人だけではない）、、、
なかなか、、、まあ、、、経験積みましょう、、、という、、、

「PCにログインできません！」
CapsLockがオンになってます、って画面に書いてあるよ、、、

なんのことかわかりませんってそうですかそうですよね...

休みの日でも何かあったら...

言ってください、とは伝えてたけど
（私が休みの日でも緊急の困りごとがあったら知らせていいよと）

「Microsoft はお客様のプライバシーを尊重しています」

という画面が出たけど
どうすればいいですか？

という、緊急の質問。。。orz

orz

orz

「これが出てエクセル使えなくて困ってます。」
「（その後）はい、いいえどっち選べばいいですか。」

・・・なるほどね、わからないよね、
どっちでもいいよ、後から変えられるし（涙）。

がんばっ...

これから生きていく上で、
PCの基本スキルはある程度必要。
大きな会社なら管理部がやってくれるとはいえ、

わからない知らないで損すること多くなるよ。
そんな時代にもうなりつつある。

だからせめて少しでも慣れておこう。
せっかく仕事で使ってるんだから。

そう、みんなの幸せを願う社内SEのパートさんなのでした。

2020年総括

これまで、「プログラミング大好きです！」と言っていたけど、
「自分の得意なことを役立てつつ、人とコミュニケーションして仕事を進めていくの、めっちゃ楽しいです！！」というのが本当のところなんだなーと、気付かされた一年でした。

余談。
今の事業所にいる人たち、みんな優しくて、いじめとか派閥もなくて、女性多いので基本的な会話が普通にできる、素敵な職場です。人間関係大事、天気の会話も大事。

今まで男性が大多数の職場に居たので「基本的な会話スキル」が全然違うです...。仕事以前の問題。

あと、私は深入りしないようにしている（≒脳内お花畑で仕事したい）ので、平和に見えるのはそれもあるかもしれない...?

辞めないこと

2020-12-16T07:00:10+09:00

Crieitのなんでも Advent Calendar 2020の16日目の記事です。
ちょっと、今年を振り返ってみます。
純度100%のポエムです。

あ、やべー。今年何もしてねえ

っていうのが今年の総括になってしまいますね……。今年の振り返り、以上。
いや、ちゃんと仕事はしていたんですけど。プログラマのアウトプット的な意味で、何もしていない。
Crieitにも記事を一つ書いただけですし。

でも、誰にも怒られない

だって、好きでやっているだけだもの。仕事じゃないもの。
自分の場合は、ゆるーくやっていければそれで良いかなーとは思っています。
似たようなことは去年の今頃も言ってますけど。

とはいえ、好き勝手やっているともちろん悪いこともあって。
それは、「辞めてしまう確率が上がる」ことだと思っています。

大事なのは辞めないこと

僕の好きな言葉に
1番になりたかったら続けなさい。周りが勝手に辞めていくから
というのがあります。
（実は、昔twitterで見かけた言葉で、誰が言ったのかもわからないのですが）
「継続は力なり」とか言われると教訓じみていて少し嫌ですけど、もっと俗っぽい言い回しなので好きです。
1番になれるかとか、なりたいかとかはともかくとして、続けるって大事。辞めないって大事。
さらに言えば、続ける事というか、辞めない事が大事。ちょっとしたニュアンスの違いだけど。

一度辞めてしまうと、再開する時のエネルギーってものすごく必要になると思うんですよね。
再開する資格があるかとか、再開できる環境かどうかとか、そして何より再開する気力が湧くかどうか。
そして結局、再開できない。

「好きでやっているだけだから」と言って、この辺りの事を見失ってしまうと、あっさりと辞めてしまう気がするんです。すると、もう戻って来られない。
だから、好きでやっているだけでも良いけど、これを肝に銘じて続ける。どんなにペースを落としても良いから辞めない。
これが大事なんじゃないかなと思います。

というこの記事を書く事で、僕は今年何もしていなくても、超スローペースでも、何も辞めなかった事にします。

2020年に作ったものと神の宿る場所

2020-12-14T07:00:10+09:00

この記事はなんでも Advent Calendar 2020の14日目の記事になります。

今年の振り返りポエムをどこに書こうかなと思ってCrieitさんにお世話になることにしました。
醤油瓶(@seuyu_bin)というアカウント名で活動しています。

2020年

今年は世界的に大きく変わりましたが、私としてもRailsエンジニアとして駆け出した変化の大きい年となりました。

去年の末にSIerから転職して実務未経験からRailsを触り始め、なんとかクビにならずに仕事こなせるようになりました。

2020年、特に目標を持っていたわけではないですが「何か新しいこと」というのは根底にあって、今までで最もいろんなものを「作った」年になったなと思います。

時系列順に作ったものを列挙して振り返りたいと思います。

4月ショートショートに手を出す

初手から開発の話じゃないです。小説の話です。

ショートショートとは数百から数千文字程度の超短編小説のことです。著名なショートショート作家である田丸雅智さんの情熱大陸か何かのテレビをみて、自分も書いてみようと思い立って書いてみました。

自分が書いていたのはショートショートの中でも、超ショートショートと呼ばれる2000文字くらいのお話です。

書いたショートショートはnoteに公開しています。→セウユ

4月末から5月くらいにかけて13個ほど作りました。

今読んでも我ながら面白いやつもあれば、「ちょっと何言ってるかわからない」というのもあります。

個人的ベストは、ちょっと頭おかしい系の「クリップ」という作品です。

小説を書いてみて

ショートショートを書いてみて思ったのは、2000文字というレベルでさえ作るのに苦労するのに、長編小説をかける人の頭の中は一体どうなっているのだろうということ。

普段さっと読んでしまうなろう系のラノベだったり、著名な小説家だったり、ショートショートを書いてみた後に触れた小説という小説の全てがすごいと思えるようになって、「どうやってプロットを整理したんだろう」とか、「この言い回しってどうやって生きてきたら思いつくのだろう」と小説に対してただ楽しむだけでなく、１段踏み込んだ考えをするようになりました。

これは実際に作ってみて本当によかったことで、字を書くということに対する解像度が一つ上がったかなと思います。

ショートショートを書くというのは、ネタが浮かんだら数時間で完成まで持っていけるので割とフットワークの軽い趣味になります。今後も定期的にゆるく続けていきたいです。

5月ボカロに手を出す

ショートショートのネタが割と尽きたタイミングで手を出したのが、作曲です。

楽器を習っていたわけでもなく、何か知識があったわけでもなく、とにかくゼロから作曲して、結果としてボカロ曲を2つYoutubeに公開しました。

ここで紹介するのはやめておきます笑　ショートショート公開するより恥ずかしい笑

作曲する

「コード進行って何？」みたいなところかスタートしたわけですが、Youtubeで誰かがやさしく解説してくれている時代ですので、入門するのに特にハードルはありませんでした。

王道小室進行とか、カノン進行とか、「ああ、聞いたことあるな」というコードの流れがなぜ心地よいのか、スケールの話から、トニック、ドミナントといったコードの機能まで、基本的な知識は全てYoutubeで教えてくれます。

作りたい曲のイメージは最初からあって、コード進行がひたすらループする系の曲を作ろうと決めていました。

Aviciiが大好きで、最初の曲はAviciiの「wake me up」という曲のコード進行を真似して作りました。コード進行ループ系の曲は初心者としても考えることが少ないので結構とっつきやすいところだったと思います。

コードが破綻しないように主旋律を打ち込んでいって「あーでもない、こーでもない」と考えながらメロディを作っていきました。

大体1週間、20時間くらいで一応曲としては作れたと思います。

作詞する

割と時間がかかったのが作詞の部分、売れているアーティストって何か伝えたいことを詞にしていると思うのですが、残念ながらあんまり伝えたいことが浮かばず、ありがちなストーリー、ありがちなセリフしか浮かんできませんでした。

最終的に出来たものも特に面白みもなく、ありがちなものになってしまったので、悔いが残っている部分です。

作曲は楽しく夢中でやった感がありましたが、作詞はひたすら苦しみました。

作曲してみて

ここでも解像度の話ですが、実際にコード理論を勉強したり作ってみたりしたことで、音楽を聴くことに対する解像度が上がったと思います。良い曲というのは、ドラムのハイハットの入れ方一つ、ベースの音一つ一つに工夫があって、好きだなと思う曲をよくよく聴いてみると音作りから詞の一単語に至るまで、細部まで計算されていたり、工夫が凝らしてあります。

まだまだ初心者なので知ったかレベルですが、やればやるほど奥の見えない世界の一端を覗けた気分になりました。

２曲目は、ちょっとだけレベルアップしたものを作れましたが、1曲目、2曲目合わせても合計100再生に満たずYoutubeの海に沈んでいきました。

2021年は一つネタが浮かんでいるので、創意工夫をふんだんに入れてゆっくり時間をかけて作ってみたいと思っています。

8月フラットアイコン制作に手を出す

絵なんてほとんど書いたことなかったですが、アイコン制作をしてみようと思ってフラットデザインのアイコンを制作し始めました。理由はあんまり覚えてないですが、Youtubeのフラットデザインのイラスト制作のチュートリアル動画を見て「楽しそう」と思ったからだと思います。

これがなかなか楽しくて、毎日コツコツ作りました。
Affinity Designerというイラストツールを使っていますが、だんだん慣れてくるとショートカットも手に馴染んで、四角と三角と丸でなんでも作れるようになってきました。

普通のイラストを描くのと異なる点は、ペンを使わず、マウスとトラックパッド操作だけで図形をベースに作るので、どうやっても整った形にしかならない点がとっつきやすいと思います。

フリー素材サイトを作り出す

はい、やっと開発の話です。出来たアイコンをベースに素材サイトを作ろうと思いました。

そろそろエンジニアとして最新のフロント技術を勉強せねばと思っていたので、Nuxt.jsとGatsby.jsを試してみて、結局ReactのGatsbyで作ってみました。

出来上がったサイトがこちら「FLAT SVG DESIGNS」です。

詳細についてはZennで記事を書いています。
「Gatsby.js, TailwindCSS, Netlifyでフリー素材サイト作ってみた」

この開発でReactとVueの雰囲気をつかめましたし、javascriptをガッツリ書いたのも初めてでした。

i18n対応したのでHacker Newsに投下してみたら、割と高評価を貰えて、その後誰かがRedditのWeb Designカテゴリの掲示板にリンクを貼ってくれて、リリースしてから1週間ほどは毎日数千人が全世界から流入してくるなど、世界をまたにかけたサイトとなりました笑(なおフィーバー後は1日数十人程度に落ち着きましたorz)

また、残念ながらフィーバー中はAdsense審査待ちで、フィーバー後に審査が通ったので全く恩恵預かれず。

次に出すアプリはどんなに待ち遠しくてもAdsenseが通ってからと心に決めました。

Tailwind CSSに出会う

あと、このサービスを初めてよかったのがTailwindCSSというフレームワークに出会ったこと。
NuxtJSのデフォルトCSSフレームワークの一つとして入っていて、「これなんだろう？」とたまたま導入してみたことが出会いでした。

普段仕事でRailsを触っている中で、スパゲッティ化したCSSを修正したりしている状況で、このフレームワークの思想は衝撃的でした。「これが完全なる自分の中の答え」と崇め、崇拝しています。

フロントを触り出す

GatsbyJSで調子に乗り始め、「やっぱりシステム開発が一番楽しいかな」と再認識したのでフロントをもっと触ろうということでNext.jsとTypeScriptに入門しました。

今は機能を絞ったTwitter連動系のミニアプリを製作中です。

実はもうリリースできる状態ではありますが、Adsense承認待ちです笑。

昨日審査落ちてたので、年内のリリースは出来ないと思います。。

Adsense通るまで絶対にリリースしません笑

神は細部に宿る

そんな感じで小説執筆、作曲、アイコンイラスト制作、Webアプリ開発と散らかりすぎですが、「モノを作る」という点で共通点があり、得られた教訓も同じです。

それは、「神は細部に宿る」ということ。タイトル回収。

誰も気がつかないかもしれない細部にどこまで拘れるか、どこまで考えて工夫を盛り込めるか。

これがどれだけ最終成果物に影響するか、というのをひたすら感じました。

そして、どんなジャンルでも良い作品というのは創意工夫が詰め込まれ、考えに考えて作られたものだということ。初心者レベルの知識がついたことによって創意工夫を発見できる視点が強化されたと思います。

繰り返しの言葉ですが、解像度が上がりました。

2021年は

自分のダメなところははっきり分かっているつもりです。

「継続できないこと」「限界まで諦めずに工夫し続けられないこと」

その代わりジャンル問わずフットワーク軽くなんでも手を出せるという能力は気に入っています。

でもそれだとただの器用貧乏で終わってしまい、結局何もできない人です。

2021年はそこに手を入れなきゃなという思いです。継続、そして突き詰めて考えること。

これをモットーに来年はやっていこうと思います。運営者ギルドというコミュニティに混ぜてもらったのでその中で頑張ってる人を見て奮起していこうと思います。

なんか4000文字もポエムを吐いてしまいましたが、最後まで読んでいただきありがとうございました。

P.S.
フラットアイコン作り始める前に、漆喰と珪藻土を使ったアートパネルを５作品くらい作ったりもしてましたが、それはもう書くの面倒なので割愛しました。

誕生日のノリでアドベントカレンダーに投稿予約して感じた変化

2020-12-06T07:00:00+09:00

はじめに

まず、私の誕生日は 11/6 なので本日 12/6 は誕生日からちょうど 1ヶ月後になります。

誕生日なので何か書くことにした✍️ | なんでもに参加しました！ https://t.co/1NXySfMlak #Crieit #crieit_advent_calendar @crieitcommunityより
— 𝚗𝚒𝚔𝚊𝚎𝚛𝚊 (@n1kaera) November 2, 2020

はい。完全にノリで参加しようと投稿予約してから、後日確認して気づきました。。ｗしかし、その間違えに気づいてから、何を投稿しようかなあと考え始めた時に、ふと「以前の自分だったら絶対ノリでアドベントカレンダーに登録するっていう行動しないよなあ」ということに気づきました。

そこで、今回は以前の自分と比較して、今の自分がどう変わったのか考察してみることにしました。この記事書いてるときは誕生日からまだ 1週間経ってないし、ちょうど考察するには良い機会かなと思って。

以前の自分

Photo by Luis Villasmil on Unsplash

以前はやりたいことがあっても全部後回しにしてしまっていました。何故かと言うと仕事やプライベートも含めて、他に直近でやらなければならない、もしくはそう思いこんでいる TODO があったときに、それらが残っていると次々に心配事や考え事が増えていってしまい、やりたいことに集中出来なくなるからです。

つまり、やりたいことは本気で集中できるタイミングが来たらやろうと考えていました。

そのため、読もうと思って買った本を読みたい、買って届いた新作ゲームをやりたい、OSS 活動をしてみたい、ライブラリを自分で作成してみたい等々のやりたいことは全て後回しになっていました。

何も考えないでサクッと取り組めるプレイ済みのゲームを遊んだり、気に入っている Youtube の動画を何度も繰り返し見たりして時間を浪費していました。

ボーッとしながら何も考えないで過ごす時間や遊ぶ時間は気力を養う上で重要で必要だと認識しているのですが、それだけを余暇に費やすのは少し勿体ないなと感じていました。

そして、ある時ふと気づきました。多分このままの生活してると連休とか仕事の区切りのタイミングとかでしか、自分がやりたいことに取り組むことはできないなと。。ちなみに、私はいわゆる ON/OFF みたいな切り替えが出来ないタイプなので、「仕事が終わったらスイッチを OFF にしてプライベートを全力で楽しむようにする」とかは無理なタイプです。

そこで、過去自分が気分がノリ続けて作業できたり、新しいことに挑戦し始めたときのことを思い返しながら、現状改善のために簡単に出来ることからやってみようと 1年前くらい前から行動を起こし始めました。

試したこと

Free-PhotosによるPixabayからの画像

まず、前提として下記項目はあえて頑張って解決するとかは諦めました。理由は中学生くらいの時から「そうだったなあ」って感じていることだったので潔く諦めた感じです。

仕事プライベート関係なく、やりたくない面倒な TODO を意識してしまい無駄に疲れる
- ふとした瞬間に思い出して不快になるかつ、それらの TODO は後回しにしてしまいがちなので、更に不快になる機会が増えてきて、結果疲れ続ける
やるべき必要がある TODO が増えてくると最優先で迅速に全部片付けたくなる
- それらが意識の端にあると心を休めた状態で日々を過ごすことが難しくなってきて、結果疲れ続ける

上記の解決を諦めても、やりたいことが自然と出来る環境が作れるようにしようとしました。

仕事プライベート問わず TODO の総量を減らしていく

TODO が増えてくることによって、やるべき TODO も必然的に増えてきます。最初は優先度の低い TODO だったのに、作業していくうちにそこから更にやるべき他の TODO が生まれてくることもあります。

そのため、そもそも仕事でもプライベートでも優先度とか関係なく TODO を日常的に増やさない努力を行いました。 割とお願いされたら何でも引き受けてしまいがちだったので、そこは常に意識するようにしました。

直感的に自分に向いて無いと思ったり、自分が請け負う必要が無い TODO は極力減らすか、その内容を簡素にしてもらいました。 常に多少の余裕が感じられる範囲で TODO を抑え込むようにすることで無駄に TODO を意識して気力を消耗し続けることは少なくなっていきました。

やりたくない TODO は疲れない範囲で対処していく

もちろん、それでも 出来ればやりたくないけど、やらないといけない TODO は出てきました。

ただ、やりたくない TODO は大抵やりたくない何かを自分が勝手に想像していることも多いです。つまり、TODO の具体的な内容が明らかになっていない中で勝手にその作業内容を想像してしまい嫌になっているケースです。

その場合は、作業内容を具体化する作業を行うことで解決できる可能性があります。やりたくないと考えていることが、実は絵空事の場合もあるからです。

例えば、TODO を依頼してきた相手がいる場合、具体的な作業内容を文章にしてもらう、万が一それが出来ないと言われた場合は、自分が不快に感じないレベルで作業して適宜内容を報告することで、相手が方向性を正しいか間違っているかを随時指摘してくれて、次の作業の内容もどんどん具体化してきて TODO の全体像が見えるようになってきました。

全体像が見えてきてしまえば、あとは適切な粒度に TODO を切り分けてひたすら消化していくだけなので、無駄に意識が TODO に向かってしまい気力が消耗していかないよう、サクサク片づけるように心がけました。

段々 TODO の扱い方が分かってくると、常に一定以上は自分のために使える時間が作れるようになってきました。

軽めのやりたいことは時間が出来れば自然にやれてた

意識するまでも無く時間が作れるようになってきてからは、新作ゲームや積読してた本に取り掛かることを意識せず自然にやってました。TODO 意識しちゃって新作楽しんでても心から楽しめないとかいう気持ちから脱することができる状況になったおかげで、自然と新たな行動が起こせるようになったからかもしれません。

重めのやりたいことには必ず「自分のため」の理由付けを行う

例えばやりたいことを行う理由が「誰かに認められたい」とか「自分の価値を周りに認めてもらいたい」とか世間体を気にした動機になってしまっていると、そのやりたいことは他人が認めてくれて初めて達成となります。つまり、例えやりたいことが達成できたとしても、他人に評価してもらえない限りは未達の状態であり、その結果が気になって気力を消耗し続けます。

私は上記のパターンに過去何度もハマり、やりたい TODO が達成できたはずなのに、その後 TODO に対する他人からの評価を常に気にし続けなければならず、無駄に気力が消費され続けて全くその後の行動が続いていかないという現象にハマっていました。

例を言うと、例えば技術記事を書くとしたときに 「世間に新たな価値を提供したい」「誰かの役に立つような内容を意識する」「しっかり内容を書かないと記事にする意味が無い」 という他人から見られることを意識している動機づけは世間体や他者からの評価です。

それら一切度外視で、「文章書く練習のために書く」「後々また困りそうな技術的問題を自分が解決できるようにするために書く」「他の記事と内容が重複しても自分の勉強や理解を深めるために記事は書こう」と自分の行動の動機を他人と切り離すことで、やりたい TODO を完了したときに「達成できた！満足！」という実感が即湧きます。

やりたい TODO をちゃんと達成できたという実感は次の行動のモチベにも繋がっていくので、一石二鳥です。

ちなみに、やりたいことのモチベは 「なんとなく興味あってやりたいからやってみるけど飽きたら即止めよう」 という意識でも自分の行動の動機としては全然問題無かったです。そんな薄いモチベでもやり始めたら楽しくなってきてこだわり始めてやりたいことの精度や質がグングン上がっていき、継続して取り組める趣味となることも経験しました。

自分の具体例で言うと、その程度のモチベで始めたことである普段飲むコーヒーの質向上が、結果、自家焙煎とか豆のブレンド比率にこだわり始めたところまで来ていて飽きずに今でも続けられています。

その結果

Photo by Jorge Gonzalez on Unsplash

そうして、やりたくない TODO の総量を減らして使える時間が増えていくと、最初のほうは時間を浪費していた時の行動となんら変わりない行動をしてしまうのですが、、ふとした瞬間に、それらの浪費行動に飽きるタイミングが来ます。暇すぎたり飽きに耐えきれなくなってきて、気力も十分に蓄えられてくると、ふとした瞬間に「やろうと思ってたことやってみるか」という感情に僕はなりました。むしろ、そういう感情になるまでは、仕事プライベート問わず TODO を減らし続けたり、遠慮なくダラケまくってボーッとしまくって休息する時間が必要なのかもしれません。

あとは、気力は体力と同じく有限であるが、無くなっている状態が慢性的に続くと、それに気づくことすら出来ない。更に失った気力を回復するのには結構時間がかかる (1週間とかの単位) ということに気づくことが出来ました。

私は気力を失っているかどうかの判断軸として、何かをやりたいと思えてたはずなのに「今は忙しいからな」とか「途中でやめそう」とか保守的なモードに入って行動が起こせなくなっていたら、気力が失われていると判断しています。そうなっていたら、休息だけでなく TODO の総量も同時並行で減らすように心がけています。

「2」がお題の時の web1week の時に参加出来なかったのは、まさにやりたいと思っていたのに、上記の保守的なモードに入っていたので行動に移せず終わってしまった感じでした。

また私は前述してきた内容を意識してきた結果、下記の以前からやりたいと思っていたことを自然に達成できました。

これらは世間体や他人の目、TODO などを気にせず、自分の意志のみにフォーカスして活動できるようになったことが大きく起因していると感じています。

おわりに

My pictures are CC0. When doing composings:によるPixabayからの画像

まとめると、私にとっては下記が重要だったということになりそうです。

仕事やプライベートや大小や重要度関係なく TODO の総量はとにかく減らす
- やりたいことがあっても時間や心労が原因でできていないのであれば、まずは自分のために使える時間を増やすことにだけ、ひたすら意識を傾ける
世間体や他者からの評価をモチベの糧にするような行動は決して起こさない
- それで一時的に行動できていたとしても評価されないと気力を消費し続ける原因になってしまい、モチベや行動が後に続いていかない
気力の消費には自分で気づくことは難しいので常に余力が持てるよう意識し続ける
- 何かやりたいことがあるなら、他者に縛られる時間や仕事プライベートにおける TODO の総量を極力減らしていく
無意識に気力を削ぎ取ってくる外部要因は意識的に排除していく (フォロワーの数や SNS での反応等々)

今回ノリでアドベントカレンダーに参加できたのも、上記が達成できていたからだと思います。(気力が十分にあって、世間体等を気にせず、自分が記事を書いてみたいと思ったから参加できた)

もちろん、この記事が誰かの参考になれれば物凄く嬉しいは嬉しいのですが。。ｗ

また最近は行動を起こすにもインプットの量が足りてないとアウトプットしたいものも無くなってくるなと感じているので、自分が本当にやりたいことの総量を増やして、アウトプットを増やすことで人生を純粋に楽しむためにも、インプットの量を意識的に増やしていっています。

ちなみに私がモチベや記事に書いている内容を意識し始めたキッカケは教育心理学を学ぶ会で購入した理論と事例でわかるモチベーションですので、本記事内容にご興味お持ちいただいた方は是非チェックしてみてください。著者は kawagoi さんです。

最後にこのような機会を用意してくれただらさんに感謝して終わりたいと思います。

[供養] Qiita の記事に投げ銭サービスを仕込むハックでやらかした話

2020-12-02T07:00:10+09:00

人生はじめての Advent Calendar に挑戦です！今年は挑戦を恐れず色々やってきましたが、その中で「あー、やっちった～」的なものを１つご紹介して私の中で供養しようかと思います。

※ なお、具体的なやり方は記載しませんが、やり方を想像できる方もいらっしゃると思います。真似なさらないようにお願いします🙇‍

序章

ブログを収益化できる投げ銭サービスというものが世の中にはあって、それを使って「何か面白いことできないかな～」と純粋な気持ちで考えていました。「自分のブログには既に広告を貼ってるし、あー Qiita か・・・」

(この時の私は『Qiita で投げ銭するのは多分グレーだろうな～あとで利用規約確認するとして、とりあえず技術的に実現できるのか試してみよう』などと思っていました)

一旦それぞれの仕様をまとめてみます

投げ銭サービスは iframe タグと script タグを実行できれば使える
(自分のブログに iframe, script タグを張り付けることを想定している)
Qiita には CodePen を埋め込める

この２つの情報があったので、もはや試さずにはいられませんでした。ええ、Qiita 上で投げ銭のボタンを表示することに成功してしまいました👺

やらかし (〃´∪｀〃)ゞ

『Qiita 投げ銭』というタイトルで具体的な方法を記載したうえで Qiita に投稿しました。
その数分後に１通のメールが届くことになります。内容は Qiita でコメントされたと。コメントの内容は・・・

Qiitaの利用規約違反になりませんか？

と。(この時コメントくださった方。本当にありがとうございました)
記事を一旦削除した上で利用規約を再度確認してみました。以下に該当部分を抜粋します。

https://qiita.com/terms

第三章：禁止事項・本ユーザー資格の停止について
第10条(禁止事項)
3. 登録ユーザーは、本サービスを利用するに際し、以下のような本サービス利用上不適切な行為を行ってはなりません。
(4)客観的には事実上、広告・宣伝や商用を目的とした勧誘と認められる行為（検索サイト最適化又はアフィリエイトを目的とする投稿行為を含むがこれに限らない）。ただし、当社が本サービス上で別途定める場合はその限りではありません。

なるほどよくわからん。『事実上…商用を目的とした…』に当たりそうなような当たらなそうな・・・

運営さんに問い合わせ

わかないことは聴くのが一番早いので、Qiita 運営に問合せてみました。
以下送った内容です。

Qiita の記事内に CodePen を利用して投げ銭サービスを組み込むことは規約違反でしょうか？

規約を確認する限り判断できかねるため Qiita 運営の判断を仰ぎたいと思いました。

参考までに以下の URL で実際の動作を確認できるように「限定公開中」にしております。問題があればすぐに削除いたします。
https://qiita.com/alclimb/private/********

(以下、対象規約部分を抜粋)
第三章：禁止事項・本ユーザー資格の停止について
第10条(禁止事項)
3. 登録ユーザーは、本サービスを利用するに際し、以下のような本サービス利用上不適切な行為を行ってはなりません。
(4)客観的には事実上、広告・宣伝や商用を目的とした勧誘と認められる行為（検索サイト最適化又はアフィリエイトを目的とする投稿行為を含むがこれに限らない）。ただし、当社が本サービス上で別途定める場合はその限りではありません。

--
以上です。お手数ですがよろしくお願いいたします。

夕方 18:40 頃に問い合わせして、40 分後の 19:20 頃には　Qiita サポートから回答が来てました。(はやっ)
回答の一部のみ引用すると、

今後状況が変わる可能性も0ではありませんが、少なくとも現時点では利用規約違反となります。

とのことでした。はい利用規約違反でした。申し訳ございませんでしたー
今後状況が変わる可能性も０ではないとの事なので今後に期待したいです。

まとめ

Qiita で投げ銭は技術的に可能だけど利用規約的に NG
Qiita サポートは回答が早くユーザーとしては嬉しかった。個人開発としても見習いたい部分
失敗は何らかの形で供養するとセルフ反省会にもなるのでおススメ

きっと来年もいっぱい失敗します。でも『とにかくやる！』で精進していきたいと思います✨

明日の Advent Calendar 3日目はみににさんです！よろしくお願いします

今年の総括。スマホアプリに力を入れたこととか。

2020-12-01T07:53:54+09:00

年末ということで今年やったことの総括的なものです。今年はサービスとアプリを13個ほど作りました。うち６つはイベントで作ったものやネタで作った小さなものです。それ以外のちゃんと作ろうと思って作ったもののうち、Webサービスは２つ、スマホアプリは５つでした。ということで今年はスマホアプリ開発を再開し、そちらに力を入れた年でした。

アプリ作りを再開した理由

アプリ作りを再開した理由はいくつかあります。

良い開発ツールが整ってきた

アプリを作るのに実用的な開発ツールが整ってきたことが一つの理由です。ゲームにはライセンス料なしのGodot、それ以外にはFlutterを使うことでクロスプラットフォームのスマホアプリを作ることができます。どちらも非常に開発しやすく、実際に今年６つのアプリをAndroid, iOS用の両方にリリースできました。

初めてゲームを作ったのはもういつかわからないのですが、日本でauの実用的なAndroidのスマホが発売されたあたりでした。ゲームエンジンもなく、OpenGLで作っていました。当時はマーケティングもASOも何のノウハウも分からず、開発が大変だったのにもかかわらず全く利用されませんでした。

最後に作ったのは多分５年前くらいで、cocos2dxを使ってJavaScriptでクロスプラットフォームで作ることができるようになっていました。とはいえまだまだネイティブでガリガリ書く必要があったり、よくわからないエラーでアプリが落ちる様になってしまったりと、気楽という感じではありませんでした。

ここに来てようやく十分なものが整ってきたな、という感じがします。

Webより稼げそうな気がした

Webをずっとやってきましたが、未だに不労所得でウハウハなんて状況にはなっていません。Twitterの個人開発者で稼いでいる人を見ると、大体がスマホアプリ開発者です。もちろんその方たちのアプリのクオリティやノウハウが素晴らしいことであることは色々聞く限り間違いはないのですが、そもそもの稼げるようになるまでの敷居がWebサービスは高すぎるのでは、という気にもなってきました。

アプリは広告以外にも課金機能も用意されていますし、広告もゲームであればリワード広告という手段もあります。

スマホアプリは重要だと思った

単純にスマホアプリは重要だなと思うようになったためです。僕のようにプログラミングを生業としている人からしたらPCでWebを色々利用して色んなことを行い、それをあって当然の基盤として生活することが当たり前です。

しかし時代が変わっていくに連れ、ブログも全部スマホで書くよ、とか、Twitterなんてやってないよ、とか、既に話を聞く限りでも僕にとっては信じられない常識の中にいる人達が多く増えてきています。スマホはtiktokとLINEしかやってないなんて人も多いでしょう。すでにブラウザなんてよくわからないしだいたい全部スマホアプリでやってるよ、という人たちも増え続けていることでしょう。Webアプリとして作っておけば誰でも使えるし大丈夫、という時代は終わりつつあるような気がしています。スマホに必要な機能をアプリで追加してそれを使えば済む、という世代が増えていくのではないかと感じます。というか既にかなり多そうにも思います。

実際にはそうではない可能性があっても、Webだから便利なことと、アプリだから便利なことがやはりあると感じます。Webだけでなくアプリを提供してアプリのことを知っていくのは重要なことだというのは間違いないと感じるようになりました。思いついた何かしらの作りたいものがWeb向けかアプリ向けかをちゃんと判断していったほうが良いと思いました。

そもそもなぜアプリづくりをやめていたのか

前述の通り、開発環境がつらかったというのがまず一つです。

あとはスマホアプリはSDKやストアがガンガンアップデートされていくため、これはきっと作ってもいつか使えなくなるな……という気持ちが強まったためです。100個作ったとしても多分追従して全部をアップデートしていくことは時間がなくて無理だと思いました。売れているならともかく、ほとんどは売れないアプリになるでしょうし。

しかも時間がたつにつれ、ソースコードを失う恐怖もありました。Webアプリケーションであれば最悪サーバーからダウンロードしてきて復旧すればよいのですが、アプリはビルドされていますのでソースを失うともう復旧は不可能です。作り直すしかありません。GitHubも昔は使っていなかったりプライベートリポジトリが有料だったりで使っていなかったため、今より全てを失う可能性は高かったです。cocos2d-jsなどはどこをignoreしてどこをコミットすればいいのか非常に分かりづらかったので、リポジトリに保存していたとしても復旧は困難そうに思います。アプリづくりをしながらこういう喪失感を容易に想像できていたので、それもやめてしまった原因でした。

今年やってみてどうだったか

今のところは全然です。ほとんどインストールされないアプリがほとんどです。一つだけぼちぼち成長してるアプリがありますが、収益的には全然です。ゲームもストア上の数が多すぎるのか、リリース時に一瞬たくさん使われただけであとは全然です。

ただ元々すぐ収益につながるようなことになるとは思っていないので、とにかく今年は種まきと、あとは実際にやってみて情報収集と勉強のためにやっている部分が大きいです。そのためまだまだ来年は何をどうやっていこうか、というところを考えることも楽しみです。

ただやはり前述の通り開発しやすくなった、というのは僕だけではなくあらゆる人にとってそうであり、多分新しいアプリが出てくる量はかなり以前より増えているのではないかと思います。Twitterなどでもちらちら、昔はアプリを見つけてもらいやすかったけど今は辛い、という実体験の情報なども見かけたりしました。今流れている情報を鵜呑みにせず、今後の状況をしっかり見ていく必要はあると思いました。これはWebもなのかもしれませんが。何にしろこっちが良さそうだからこっち、やっぱあっちがよさそうだからあっち、みたいに、何も考えずにひょいひょい適当クオリティでやっていくのは厳しいだろうなというのは間違いなさそうに思います。

来年からはどうしていくか

作りたいものがWebサービスにもスマホアプリにもあります。そのあたりは何も考えず、作りたいもので、役に立ちそうなものをどんどんまた作っていったり改良していったりしたいと思います。あとはSide QuestでVRゲームをリリースしたいなとも思います。

まとめ

とにかくやる！

「ポエム」の記事 - Crieit

ただのブログを書こうぜ（＾～＾）？

2021年個人的なまとめ：個人制作と技術記事など

40歳になって忘れたこと、覚えていること

ゲームを遊んだら、自分を遊べ(あるいは『プログラミング後に、自分をステップ実行』)

会社がなくなって、転職を余儀なくされた件。

Accessをやるぉ「メンサ会員 本気のACCESS入門講座！」

頭が悪いのでプログラミングしてるんです(カム着火インフェルノォォォォォォォウ)

📔 マイペースに技術研鑽を継続する方法

ある日突然ロードアベレージが200を超えた

【プログラミング全般】「登録する」の意でregistと書くことの是非について

新卒IT社員に伝えたいこと

現役サーバエンジニアしてる私の話【自己紹介】

技術的な有料記事を書いていくためにどうすればいいかの考察

AI画伯とか、2020年作ったもの反省

社内SEに向いているのはこんな人（かもしれない）2020年振り返り記事

Accessをやるぉ「メンサ会員本気のACCESS入門講座！」