読者です 読者をやめる 読者になる 読者になる

Life is Really Short, Have Your Life!!

ござ先輩の主に技術的なメモ

Segueが2回呼ばれてしまったらSegueをVCから貼り直す

Swift

StoryboardでUITableViewからSegueを伸ばしていると、VCのライフサイクルとdidSelectAtRowのタイミングで2回呼ばれてしまうようです。

こいつを治すには、Segueの貼り方を変えるだけ。VCから対象のViewControllerに向かってSegueを貼ります。あとはdidSelectAtRowのデリゲートメソッドでperformSegureしちゃって。

f:id:gothedistance:20161125165338p:plain

自分で敷いたレールの上の人生を歩みたいよねっていう話

この記述、すごくわかる。僕もそう。だから独立した。同じような考えの人っているもんだ。

「自分たちのサービスで勝負したい」という想いがどうしても強く、既に誰かが成功させたビジネスに乗っかって、更に成功を拡大するためにプログラマーとして働くという選択肢を取ることができなかったという理由です。

東京の会社を退職して山形に移住することにしました - セカイノカタチ

わかる・・・わかるよ・・・ 多分同じ感覚だ。商売がしたいんだよね、仕事がしたいのではなく。仮にGoogleから年俸で1000万のオファーがあっても、給料の1000万にはさしたる興味がない。でも、自分で作ったサービスなりシステムなりで100万円売り上げることに、やりがいを覚えてしまう。10分の1しかなくてもね。そういうものなのだ。

僕の場合は自分のサービスで勝負したいの他に、独立を志した理由があった。顧客を作る努力をしようと思ったから。今36歳になっちゃったんだけど、アラフォーになったら転職は当然難しくなる(一般的にね)。独立したって同じように厳しい。質は違えど、どっちの道を選んでも厳しいわけ。どちらかがえらい簡単なことはない。職につく努力をするか、自分の顧客を作る努力をするか。どっちがしたいと考えて、後者を選びました。顧客を作る努力のほうが楽しいもん。

ご武運をお祈りします。お互い頑張りましょう!

おっさんの説教という最凶のバズ

レールに乗った人生は嫌だの石田さんの炎上っぷりをみて、改めて感じたこと。おっさんが説教したくなる内容ってはてブを中心に火がついてバズる。すごく。

イケハヤさんも燃え上がったのは若くてソコソコ頭が回るのに全く明後日の方向を向いたコンテンツを量産していたから、というのが自分の中で腑に落ちる。「いやその理屈はおかしいけど、若気の至り臭すごい。まだ間に合う、まだ引き返せる。言わずにはいられない。」というギリギリのバランスがあった気がする。今は単なるおっさんになってしまったから、誰も説教しようともしなくなった。石田さんは今が旬だけど、1年後には燃料が切れる。ろうそくのようなもので、どんどんすり減っていく。継ぎ足すことはできない。

高知のおっさん、ほんまにどうするんだろ。サロンとnoteは急上昇のあと急降下、ブログは適当に書き散らかすのみ。謎の農地を購入して公園の砂場遊びに明け暮れている。彼の言うことに耳を貸す人が減ったから商品価値も減っている。思いつきで生きているから仕事を請けることの意味もわかっていない。打つ手が無いので遠目には四面楚歌に見える。老害として再ブレイクするしか無いんじゃないかな。キャラしかコンテンツに出来ないのなら時間の問題だ。

ラーメンが苦手

どうしても食べ飽きてしまう。サッポロ一番塩ラーメンだけは好き。

温かいうどんや、リンガーハットのちゃんぽんとかは好きなのに。ラーメンだけが苦手。

恐らく脂が原因だと思う。ズドーンと脂が前に来るのが苦手。二郎系はもう色々無理。スープも味付けが濃いラーメンが多い。薄味で整えるのは難しいし食った気がしない人が多いだろうから、薄味のスープのラーメンって作ってもリピーター来ないんだろうな。

あと、麺。ラーメンって麺の種類がすごく豊富だけど、麺がうまくないと食べ飽きるんじゃないかなぁ。醤油ラーメンも醤油の味を感じてしまうと飽きてしまう。

ラーメン苦手だけど、実はラーメンってすげー作るのが難しい一品なんじゃないでしょうか。

筋書きを書くこと

どうもこれが一番好きみたいだ。ストーリーを書くといってもいいか。

プログラミングが好きなのも、プログラミングで1つの筋書きを書くから。

文章の読み書きが好きなのも、筋書きを考えるのが好きだから。

やきうが好きなのは、そこに筋書きがないから。これだ。

おれが野球を愛する理由はここにあったな。

仕様書策定の良いツールはないものか

やっぱりOfficeソフトを使っている会社さんが多く、画面設計書なんかはPowerPointで書かれていたりします。

当然のことなんですけど、「この画面項目はDBのどのテーブルのどのカラムに該当するか」がわからないとプログラムを書くことが出来ません。そういう情報をパワポに盛り込んでしまうと、DB側で変更があった時に差分が取れなくなります。取れなくなるというか、手で修正する必要があります。逆も然りで、ER図に変更があった場合は設計書に反映しないといけない。

例えばだけど、ERに変更があったらそこからテーブル作っちゃって、画面設計書の項目をマッピングする時に作ったテーブルのカラムをプルダウン(オートコンプリート)で選んでいくみたいなレベルまで徹底している現場って…あるんでしょうか?

こういう不整合が重なると、仕様書が死ぬと思うんだけど...

Markdownで書けばいいじゃんっていう説もあるようですが、Markdownって複数の文書間の整合性を取れるもんじゃないですよねぇ...