tekitoumemo’s diary

C#、.NET系の技術ブログを書いています。みんなの洋楽ランキングを運営しています。

食洗機が最強すぎた

今までいろいろ購入して便利だったものを書きました。

tekitoumemo.hatenablog.com
tekitoumemo.hatenablog.com

乗り物ばっかやんけ!!

僕も昔と比べて大人になりました。もう結婚もして子どももいます。なのでもう少し実用的なものを紹介します。

食洗機!!

やばい、まじやばい。買わない意味がわからない。一人暮らしでも買う価値ありまくりで生活が鬼のように変わった。

買ったやつはこれ

ヤマダ電気で値切って6万ぐらい。工事費含めると7万ちょいで付けられる。

良かったこと

これ。適当に皿を水で流して食洗機に突っ込むだけ。今の食洗機は水で流す必要すらないと思いますが、手を洗うついで的な感じで。手洗いの場合は水に付けて洗剤スポンジにつけてゴシゴシして空いてるとこに食器おいて水で流す。ヌメってたらまた洗い直す。アホやろ。

静か

音は鳴るけど、深夜でも使えるレベル。洗濯機に比べたらすごく静か。

めっちゃ汚れ落ちる

手洗いより全然落ちる。フライパンも一撃。食洗機用の洗剤は強力で手洗い用の洗剤とは格が違います。手洗い用の洗剤は食品衛生法の管理化にあるらしく、野菜や手荒れなどを考慮した基準で作られてるから弱いらしい。つまり、ゴシゴシはまじで無駄だったってこと。

乾燥が最強

洗って乾燥すればあとは食器棚に入れるだけ。洗うだけでもダルすぎた作業に加えて食器を拭かなきゃいけないとか辛すぎ。電気代も対して変わらないのでゴリゴリ使っても良いかも。

後先考えずに料理ができる

これかなりメリットだと思う。何品か料理作ると同時に皿も増えるので結果皿洗いが増える。妥協するとバランスだったり食事が貧相になるので何も考えずに料理作れるのは良いことだと思う

夫婦仲がよくなる

当番制、仕事が楽な方などどちらかが辛い思いをしなければいけないのですが、食洗機だとどっちがやってもいいレベルで楽です。最近は子育てが辛い嫁を気遣って僕がやるようにしてますが、それだけで感謝されるので最強。

無駄な水を使わない

らしい。

悪かったこと

でかい

水切りカゴを置く場所がなくなりました。なくなっても良かったので結果おけ

たまに手洗いが必要

でかいフライパンとかしゃーない。

ピー音が冷蔵庫の開けっ放しの音と似てる

うちだけかもしれないが、食器洗いが完了するとピー音がなってビビる。

感想

はよ買えばよかった

個人サービスでの設計について

みんなの洋楽ランキングを一年ちょい運用してみて、ある程度それなりの設計をしてるので書き溜めてみる

一応ドメイン駆動設計に基づいて作ってる気がするのですが、そこで疲弊するのが辛いからわりかし適当、というか設計わかりません。個人サービスだと開発に関わる人間が基本一人なのである程度複雑でも対応出来るし、複雑な設計してもサービスを展開するスピードが遅くなるだけなのであえてある程度適当にしてるって言う意図があります(何も考えたくないだけ

構成は

サーバー: centos
サーバーサイド: ASP.NET Core
フロント:react
フレームワーク:MVC

Controller

リクエストをアプリケーションサービスに渡す、返すだけ。まじなんもしてない。たまにリクエストヘッダーとかセッションとかここで使う

Dependency Injection

ASP.NET CoreからDIアーキテクチャが導入されたので全てのクラスをインターフェースを介して使ってる。

Repository

データの永続化を担うとこ。要はデータアクセスの場所。複雑なクエリはアプリケーション側の都合だと思ってるから本当に単純なデータを引っ張ってくるとこ。ここはDapper早いしLinq強いから出来ることだと思う。インピーダンスミスマッチとか気にせずSQLゴリゴリに書いてる。

Model

スキーマと全く同じ構成のクラス群。Dapperというライブラリを使っていて、複雑なエンティティ(集約)を作ると辛くなるのでテーブルとクラスが一対一になっている。多分C#だったらこれはあるんじゃないかな?

ViewModel

UIにゴリゴリ依存したクラス群。Viewsと対になってる。

Middleware

.NET CoreではDIするためのインスタンスをStartupってところで作るのですが、ゴリゴリにでかくなるのでちょっと分けちゃったりしたりするとこ。一般的にはinfrastructureって呼ばれるとこかな

Views

ビューのレンダリングはrazorって言うASP.NETレンダリングエンジンってやってる。そのHTMLの置き場。

ResponseModel

react用のREST APIがいくつかあってそのレスポンスの型定義。名前とか終わってる気がするけど「ビューモデル」があるからオッケーってノリで

Extensions

C#には拡張メソッドって言う天才的なものがあって型にオリジナールのメソッドを作れる。日付変換などアプリケーションの仕様的なものはここに詰められる。ほかの言語だとfunctionとかかな?(その名前も大概だけど)

Constant

定数置き場。普通はDomainとかなのかな?

ClientApp

reactコンポーネント置き場。dotnet cliで生成された名前。

Attribute

CustomAttributeの置き場。

Manager

名前微妙ですが、「外部との連携するために独立して動くもの」って感じのやつが入ってる。Twitterライブラリのラッパーだったりアナリティクスラッパー、メール送信等々。azure functionから使ったりwebサービスから使ったりと共通して使えてかつ依存しないものを詰め込んだもの。実際は別リポジトリで管理してsubmoduleして使ってる。よくありがちな抽象的な名前にしたら何でも屋になった的な感じ。HTTP Clientはrepositryだろと思うけど、アプリケーションデータの核となる部分と認識しちゃってたからデータアクセスやらに限定してた。

Service

ビューモデルやResponseModelを作るところ。アプリケーションがどういった振る舞いをするかはここみれば大丈夫だろうってところ。でかくなりがちでいろいろやり過ぎてる感満載。複雑のデータの取得をしないように心掛けてるからどうしてモデルの整形などはここに集中してしまう。規模に応じてアプリケーションサービスとドメインサービスを分ける予定。

library

自前のライブラリ群。自作してだっぱーのらっぱーとか入れてる

Styles

共通して使うスタイル、画面特有のスタイルとざっくり分けてる。ここら辺はほんと適当。画面特有のスタイルなんてほとんどないから共通系が肥大化して「あれ?意味なくね?」ってなってる。

Images

画像とか思いっきりまとめてる。そこまで数が無かったんだけどちょっと増えてきたから検討中

db

ddldmlがあるとこ。C#に良いマイグレーションツールがない。ほんとdb系は弱いなぁという印象。

Test

まんまテスト。ちょーざっくりしたインテグレーションテストしかやってないけど

運用してみて

あいまいな名前(Service、Managerなど)は何でも屋になりやすいし、ゴミ箱(なんでも詰められる)になりがち。設計は抽象度が保たれた方が良いと思うけど、言語特有の分け方した方が、言語に精通してる人にはわかりやすい気がする。デカくなったら分ける、これでいいと思う。DIは最強、このおかげである程度依存が切り離せてるから素敵。でもどこでもDIはよくない。どうしてもN+1を考慮した作りをすると複雑で分かりにくいからここは課題。やっぱドメインサービスつくるかぁ。図を作った方が良いなこれは

SEOの結果が出るまで

一年ちょい運用してたみんなの洋楽ランキングが望んだキーワードで上位10位に入りました。

まぁ、結局SEOなんてものは気まぐれだし思うようにコントロールなんか出来ないので、ポエムってるところが多いがご了承下さい

狙ったキーワード

洋楽ランキング
洋楽 ランキング

検索ボリューム

15〜20万

現状のアクセス数

だいたい月7000〜8000PVってとこ。ユーザー数は1500ぐらい。今月はSEOの威力で15000PVぐらいで留まりそう。

対策

ここに書いてあるやつはだいたいやったかも。ここら頑張ったとこですぐには結果は出ないので、折れない心が大事。流入少なすぎて個人サービスクローズする人がめっちゃ多い気がする。とにかくコンテンツを強化するのに徹した。

記事数

多分1000以上

ブログじゃないんだけど、解説が誰でも書けるので「記事数」って呼んでる。7〜8割が人が書いた記事で残りはwikiを引用してます(wikiも人間が書いてるから100%人が書いたって言っても問題無いけど)wikiはちゃんと明記したら引用出来るよ!

時系列

だいたいここに書いたが、ざっくり説明。

・リリース月
ほぼ流入なし。
・3ヶ月目
SEOで4位に。月2万PVまで伸びる。
・半年
圏外に落ちる。月4000PVぐらいになる。Googleネムーンって本当にあるんだなーと実感。
・10ヶ月
会員登録実装して誰でも投稿出来るようにした結果、月一万PV超え。相変わらずSEOは絶不調で50位ぐらいに。
・今
先月あたりから20位〜10位あたりを行き来。万越えは確実に

考察


正直

よくわかんない

わからないなりに分析すると

サイトに価値を高めることが重要

キーワードに対してその価値を提供出来てるのかがめっちゃ重要だと思う。まぁ、だいたいこんな感じのことはどこでも書いてあって「知りたいのはそこじゃねぇ!」ってなるんだけど、具体的に、直帰率離脱率滞在時間かなと。普通に考えて「洋楽ランキング」とか調べて「演歌」のページにアクセスしたら2秒で直帰するよね。もうその「演歌」のページは「洋楽ランキング」としての価値はないのでSEOが下がる感じかな。

キーワードからユーザーが何をしたいか想像できるページが良い

サイトの価値を高めることの分析だとキーワードが違えど魅力的なページではあれば上がるのでは?と疑問が出ると思うが、その通りで結局は魅力的であれば上がると思う。例えば「車」って検索すると「中古車」がトップに出てきて「車とは?」が出ない。車なんて誰でも知ってるからユーザーが何をしたいかと言うと「車を買いたい」とかなんだよね。まぁ、全く違うキーワードは流石に論外なんだろうけど。

生きてることが大事
サイトが生きてることも大事な要素だと思う。最近、ブログが下降ぎみ(だと思う)の理由は更新されないからだと分析。やはり「ユーザーがキーワードを用いて何かをしたい」を軸に考えると「今」が超重要で古くて価値のない情報は淘汰されるはず。ただ、その新しくて生きてる情報を分析するのはさすがのGoogleでもムズイと思うので更新頻度ってのが重要なんだろうと

歴史は超重要
結局はコレ。新しいサイトで上位に食い込むのはかなり難しいと思う。日本人の性質として新しい情報に抵抗があって、古い知ってるサイトを使いたくなるのは間違いないので最終的にアクセスされるのは古いサイト。海外のSEO事情とか知らないので適当なこと言ってるけどだいたい合ってそう。確実性を重要視する日本人の性質はめっちゃ良いと思うけどね!

個人サービスで戦うには

上の分析を踏まえながら戦っても個人での情報量、お金、運用が企業に絶対勝てないので以下の三つのどれかで戦うしかないだろうと思う

・ニッチなサービス
・ツール系
・犯罪系

最後のは論外だけど、勝てると言えるのはこの三つかなと。だけど諦める必要なんて全くなくて希望と運用の楽しさ、知識などはお金に換算出来ない価値なのでやってみるのは良いと思いました。

原付を購入してよかった

原付を購入しました。クレアスクーピーって可愛いやつで11万円。写真のボケてないやつ

突然原チャを買った理由は、自転車があまりにも辛すぎて通勤出来ないレベルで発狂、車だと小回り利かないので衝動買い

ちなみに僕のブログでダントツで閲覧数が多い記事

原付買ったことで良くなったことなど書いてこうかと思います。

自転車の不満

自転車の乗り心地が最悪

まず、サスペンションがないからケツが激痛い。さらにケツより小さめのサドルなので疲れる&ケツ痛い。さらにさらに歩道の路面酷すぎてスピード止まるし、ケツ痛いからほぼ立ち漕ぎだしとにかく酷い。僕は乗り物じゃなくて歩行補助器って呼んでます

危ない

ヘルメットなしで30kmぐらい出るから普通に危ねぇ。歩道走るにしてもぶつかったら致命傷だと思う

漕ぐってなんなの?は?

もう令和だっていうのに漕ぐって意味不明。今さらポケベルとかWindowsXPとか使わないでしょ。そういうこと。そういうことだから

原付購入にあたって迷ったこと

電気バイク

こういうのとか

こういうのがある

「充電だるすぎ」

却下

電動チャリ

これ11万

高っか

「充電だるすぎ」(2度目)

却下

セニヤカー


この洗練されたデザインと機能備。免許もいらないし、最高。新車で30万するけどヤフオクで安いのあるんじゃねーか?と思って調べたら

最高速度は時速1km~6kmの範囲で

え?

1km~6kmの範囲で

却下

購入した原チャの感想

クレアスクーピー


とにかくてデザインが良い。日本製で水冷だから良いらしい。ドリンクホルダーないけど、そんな距離乗らねーからオッケー👌

ケツが痛くない

Dioとレッツ4、JOGを乗り比べて一番乗り心地良かった気がする。

燃費良すぎ

毎日乗って一月500円行くかな?ってところ

スタンドなくてちょっとダルい

スクーピーにはデフォルトでスタンドないっす。ちょっとめんどいかなぁ。

主に女の人が乗ってる車種

可愛いデザインなのでほとんど女の人が乗ってる。気にしないおじさんだから

任意保険微妙に高い

チューリッヒの原付特約っての付けた。車年間30000円なのに半年で7000円した。

メットは良いものを

半ヘルが楽かなと思ったけど、転ぶシュチュエーションしたら絶望だったのでこれ買った

あとバイカーから褒められる

毎日バス乗るとかちょこまかした移動すること考えたら余裕でペイできるので本当買ってよかった。っか迷う必要ないレベルで買うべき

App Service on Linuxでnpm iするとシンボリックリンクが使えなくなってエラーになる

みんなの洋楽ランキングのReactを最新にしたらデプロイ時に意味わからないエラーが発生しました。

エラーログ

Command: /home/site/repository/deploy.sh
Handling ASP.NET Core Web Application deployment.
  Restore completed in 721.71 ms for /home/site/repository/library/Client/Client.csproj.
  Restore completed in 62.82 ms for /home/site/repository/library/DapperSlackOff/DapperSlackOff/DapperSlackOff.csproj.
  Restore completed in 489.23 ms for /home/site/repository/src/mygkrnk.csproj.
react@0.0.0 /home/site/repository/src
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules/chokidar/node_modules/fsevents):
`-- (empty)
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

npm ERR! Linux 4.4.0-128-generic
npm ERR! argv "/opt/nodejs/6.11.0/bin/node" "/usr/bin/node_modules/npm/bin/npm-cli.js" "install"
An error has occurred during web site deployment.
npm ERR! node v6.11.0
npm ERR! npm  v3.10.10
npm install failed
npm ERR! path ../esprima/bin/esparse.js
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall symlink

npm ERR! enoent ENOENT: no such file or directory, symlink '../esprima/bin/esparse.js' -> '/home/site/repository/src/node_modules/.bin/esparse'
npm ERR! enoent ENOENT: no such file or directory, symlink '../esprima/bin/esparse.js' -> '/home/site/repository/src/node_modules/.bin/esparse'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! Please include the following file with any support request:
npm ERR!     /home/site/repository/src/npm-debug.log
npm ERR! code 1
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules/chokidar/node_modules/fsevents):\nnpm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})\nnpm ERR! Linux 4.4.0-128-generic\nnpm ERR! argv "/opt/nodejs/6.11.0/bin/node" "/usr/bin/node_modules/npm/bin/npm-cli.js" "install"\nnpm ERR! node v6.11.0\nnpm ERR! npm  v3.10.10\nnpm ERR! path ../esprima/bin/esparse.js\nnpm ERR! code ENOENT\nnpm ERR! errno -2\nnpm ERR! syscall symlink\n\nnpm ERR! enoent ENOENT: no such file or directory, symlink '../esprima/bin/esparse.js' -> '/home/site/repository/src/node_modules/.bin/esparse'\nnpm ERR! enoent ENOENT: no such file or directory, symlink '../esprima/bin/esparse.js' -> '/home/site/repository/src/node_modules/.bin/esparse'\nnpm ERR! enoent This is most likely not a problem with npm itself\nnpm ERR! enoent and is related to npm not being able to find a file.\nnpm ERR! enoent \n\nnpm ERR! Please include the following file with any support request:\nnpm ERR!     /home/site/repository/src/npm-debug.log\nnpm ERR! code 1\n/opt/Kudu/bin/Scripts/starter.sh /home/site/repository/deploy.sh

よくわからないけどシンボリックリンクが貼れないっぽい。あやしそうなこいつを調べてみます。

no such file or directory, symlink '../esprima/bin/esparse.js

Azure App Serviceのsshディレクトリがどうなってるか調べてみます。

-????????? ? ?      ?           ?            ? esparse
-????????? ? ?      ?           ?            ? esvalidate
-????????? ? ?      ?           ?            ? tsc

は、なにこれ

いみわかんね。

お友達にfreeBSD大好きな変態がいるので聞いてみました。

お友達「わかんね。」

statシステムコールで想定していない属性値になっているみたいで、要はファイルシステムがぶっこわれているようです。

完全詰みました。これのせいでリリースができません、いや出来るんですが、CircleCIで設定するコストを考えすぎたらだるすぎて困りました。

どうしてもkuduをつかいたい。

いろいろ迷ってたら以下の記事を見つけました。
stackoverflow.com

dockerやらwindows環境でシンボリックリンクが貼れない場合はnpm iに以下のオプションをつけるとシンボリックリンクを使わずにインストールしてくれるようです。

npm install --no-bin-links

これでやっと成功しました。
f:id:tekitoumemo:20190623194254p:plain

あまり良くわかってないけど、App Serviceはコンテナで動いてるのかな?とりあえず、オンプレと同じようなことをするとファイルシステムがおかしくなることがあるっぽいのでこれはつけといたほうが良いかもしれません。

開発体制を振り返る(2社目 Webベンチャー 後半)

1社目のSIerについてはこちら

2社目Webベンチャー前半はこちら

前回の記事では、モノを作ればヒットするの成功体験をもった傲慢な開発体制を書きましたが、当然流行り廃りがあり、みるみるうちに業績が下がっていきました。その成功体験が通用しないと皆が理解したときに出た対策がBtoCに提供したものをBtoBに出来ないかという浅はかな考えでした。さらにリストラや鬱になる人が増え、どんどん人が辞める事態。そのときの話です。

案件

BtoCの自社サービス

エンジニア数

5人ぐらいorz

技術

C#、angular、jquery

関連人物プライオリティ

サポート >> 営業 > 開発

プライオリティ理由

BtoBにシフトしたことで営業が高くなると思いがちですが、あくまでも収益を上げてるのは既存のサービス。営業も業績を変えるほどの売り上げを確保出来ないのでこのような力関係に。

見積もり手法

開発モデル

ウォーターフォール

開発モデル詳細

開発がサービスを考える(なぜ?)

営業が売れるサービスを作れと依頼する

揉める

とりあえず両者に最低限必要なものを考え出す

期限がイかれてるのでとりあえず気合い開発

テストもろくにせず、リリース

顧客から苦情

営業激おこ

無限ループ

開発しなくなる

外注+辞める人続出(僕も🙋‍♂️)

稼働

月30〜100時間残業(常にこれぐらい)

成果物

プログラム

得た知見

開発はお金がかかること。
カオスな時期に新しい技術を導入しない方が良いこと(このとき主導でGit導入した)
周りに理解がある体制が一番大事

やりがい

辛い。

考察

BtoCと違い、顧客の声がダイレクトに来るので開発体制に見直しが入ったのは良かった。ただ、この状況だと開発が疲弊しているので新しい技術を導入するのは失敗。とにかく目も当てられないぐらい使いこなせない。この状況は「テストを増やしましょう」、「チェック体制整えましょう」レベルでいいのかも、何事もコツコツと💪

開発体制を振り返る(2社目 Webベンチャー前半)

1社目のSIerについてはこちら

SIerを3年勤め、次はWeb系ベンチャーに転職しました。ひとつ言っておくと、Web未経験を入れてくれるベンチャー企業なので全然イケてません。むしろかなりヤバめ。カオスすぎて前半後半で開発体制がガラリと変わったので2部構成で書く

案件

BtoCの自社サービス

エンジニア数

12人ぐらい

技術

C#、angular、jquery

関連人物プライオリティ

開発 >>> サポート >> 営業

プライオリティ理由

BtoCの自社サービスで収益を賄えている会社だったのでエンジニアが考えて作る成功体験からエンジニアの力が強かった。

見積もり手法

開発モデル

ウォーターフォール

開発モデル詳細

あったらいいな🤭を考える

作れるかな?を考える

開発

テストはサポートに丸投げ

リリース

稼働

月30〜100時間残業(常にこれぐらい)

成果物

プログラム

得た知見

プログラム言語の知識。
気合い。
作る楽しさ。

やりがい

基本的にやりたい放題なので、プログラム出来る人はちょー楽しい。プロジェクトを進めていく力と設計知識ほ全くつかず、動けばおっけぃ。

考察

とにかく成果物を世に出すことがミッションだったので、エンジニアだけで進めることが多く、他の業種との対立が半端なかった。仲介に入ると両方から挟まれいろいろ詰む。だからやりがいのある「作る」にフォーカスする人が多いが、結局技術力もマネジメント能力もつかない(期間内で出来ることしかやらないから惰性コードが増える)。後半にも書くが、この「自分達が会社を支えてやってるんだ」という傲慢さが後半にも続く悲劇の始まりだった。。一番楽しいけど、一番最悪な開発体制。