実機 iPhone だと 設定 > 壁紙 から壁紙を変更できるが、シミュレータだと壁紙や Wallpaper の変更画面が表示されない。
しかし、写真アプリからなら壁紙設定画面にたどり着ける。
手順としては以下。
- Photos(写真) アプリを開く
- 壁紙にしたい画像を選ぶ
- Action ボタンをタップ
- 画面下に選択肢が出てくるので、 Use as Wallpaper を選択
- 壁紙を Set !
実機 iPhone だと 設定 > 壁紙 から壁紙を変更できるが、シミュレータだと壁紙や Wallpaper の変更画面が表示されない。
しかし、写真アプリからなら壁紙設定画面にたどり着ける。
手順としては以下。
会社の先輩に「短くて読みやすくて良い」と勧められたので読んで見た。本当に短くて、1.5時間くらいで読み終わった。
内容は、複雑なソフトウェアは良くないのでシンプルにしよう、そのためにはこのようなルール、事実、定義、法則があるので、その法則にのっとり開発していこう、という内容だった。
感想としては、リーダブルコードと同じようなことが書いてあっただけで、あまり目新しい内容はなかった気がする。
ソフトウェアデザインにとって第一に考えるべくは未来、と言っているのに、未来のことは未来に考えようと言っていてちょっと混乱した。
インクリメンタルな開発として、現状見えている範囲だけを確実に実装し、将来新しい要件が増えたらそれに合わせて実装を拡張していけば良い、とのことで、私は YAGNI 好きなので理解できる。
でもこれは誤って捉えられてしまうと「クソコードでも動けばいい」となってしまうので、これをちゃんと実践するには技術力が必要になると思う。オブジェクト指向の本に「変更可用性の高いコードを書こう」とあるので、つまりそういうコードを書く必要があるということだ。
クソコードを書くのではなく変更可用性の高いコードを書くべき、というのは肝に命じておきたい。
友人と slack で話してて、「エンジニアとして生きていくためにはどうするべきか」という題の結論として離島に橋を掛けたい、といういい話をした。
2017年1月27日の深夜の会話。
star__hoshi [00:25] :thinking_face: これガチで動いたらすごいけどどうなんだろ sjnya [00:29] htmlをjavaとかswiftに変換する感じなんかな star__hoshi [00:30] なのかなあ、クソアプリが増えるのだけはやめてほしいな sjnya [00:31] 逆に考えるとネイティブエンジニアはちゃんとネイティブ要素考えないとって気になってくるな ネイティブ要素だけで生き残れるのか… star__hoshi [00:31] 確かに sjnya [00:32] webエンジニア極めたほうがニーズある気が star__hoshi [00:32] まあ5年たったらスマホもオワコンな気がするんで、アプリに縛られない基礎的な知識とかサービスの概念とかそこらへん押さえとけって感じですかね sjnya [00:33] あー分かる、そういうこと考えたことある star__hoshi [00:33] web の方が明らかにニーズありますよね、 react-native キテるし、webフロントエンドに投資するのが一番コスパは良さそう iOS やってて、iOSで最適に動かすためにはどうするかってのよく考えるんですが、それって iOS がなくなったら死ぬ知識なんでもっと根本的に OS がどうとか言語がどうとか設計とか知らないと死ぬなあという気持ちです sjnya [00:35] そうだねー コード書くのが楽しいから、目先の楽しさ追っちゃいがちになるけど、そういう先のこと考えないとだめだよなー star__hoshi [00:40] といっても雇用は創出されるし、低レベルと言ってはあれですがもっとダメなエンジニアもたくさんいると思うので死ぬことはないですが、がむしゃらにコード書いてても成長しないなあと最近実感します sjnya [00:44] スキルどうこうじゃなくてコード書くのが好きなんだからいいんだよ、的な言い訳してる感あるし、その言い訳のためにコード書くの好きだと思い込んでるだけかもしれないって思うことがある 冷静になるとコード書くよりも、パン焼いてるほうが楽しい的なw star__hoshi [00:45] わかる sjnya [00:45] 本当にやりたいのかって思うと分かんなくなる star__hoshi [00:45] というかおれにはコードを書いていく以外の人生が見えていないのでひたすらそれで高みを目指さねばならない、という強迫観念が強くて辛いところがある もっと広い視野とか持てば人生楽になるのだろうな〜とか思う... sjnya [00:46] あぁそれねー 無理にアイデンティティー化しようとしてる感 star__hoshi [00:48] そばとか1回も打ったことないけど、そば打ってみたらそれが天職かもしれないし、狭い IT 業界で色々考えるのもな〜という感じ sjnya [00:48] ww [00:49] hoge さんにこのはなしするとき、そば打ち題材にしてたわw 自分が本当になりたいものに自信がないのが原因だから、同じことばっかしないで人生経験つんで何か見つけなさいって結論だった star__hoshi [00:50] そば打つか sjnya [00:51] 飲食のバイトとか楽しかったしなぁ star__hoshi [00:52] コンビニバイトは何も身につかないし何も楽しくなかった sjnya [00:52] コンビニバイト以外の何かだな star__hoshi [00:52] 早朝の新聞配達とかやってみたいな sjnya [00:53] 案外生き生きしてるかもね shinyaozawa [00:53] 土方おもしろいよ star__hoshi [00:53] ITドカタ 物理でもの作りたい sjnya [00:54] まじでやってみないと分かんないよなぁ star__hoshi [00:56] 不労所得で生きいけるようにして3年くらい色々やりたいけどそれただの自分探しの旅だわ [00:56] アメリカ横断する意識の高い大学生みたいだな shinyaozawa [00:57] 橋作ろうぜ star__hoshi [00:57] 橋良い shinyaozawa [00:57] 離島にかける橋 star__hoshi [00:57] カッケェ sjnya [00:57] あぁーいい star__hoshi [00:57] 本土と Dash 島つなごう shinyaozawa [00:58] Dash 島って福島じゃねーの?w sjnya [00:58] 近いw star__hoshi [00:58] それ dash 村では [00:58] http://xn--50-hi4azc9fsf5155c.com/wp-content/uploads/2014/10/e.png (254KB) sjnya [00:59] ばれてんのか star__hoshi [00:59] 荒らしに行くか [00:59] 海賊だ sjnya [01:00] 僕はもくもく会からはじめて世界広げてくよ [01:01] 今年は迷走してみよう! star__hoshi [01:01] いいな [01:01] スローガン: 迷走 sjnya [01:02] 嫌いな人としゃべるとかもして、世界広げてく star__hoshi [01:02] 意識高い sjnya [01:02] 圧倒的成長 star__hoshi [01:03] やっていくぞ
誰かの DeepWork の書評に「これならエッセンシャル思考を読んだ方が良い」などと書いてあったので読んでみた。
エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方で、本書の中で繰り返し述べられてたのは2点だと感じた。
とにかく本当に大事なことにだけイエスをして、それ以外はノーと言うので、結果としてより大きな成果が出る、と言う感じ。わかる、しょーもない仕事はしない方が良い。
と言ってもなかなかノーと言うのは難しい。この前も悩んだ末に社員旅行と言うイベントにイエスと言ってしまった。行きたくないが、まあ断るのもアレだしと思ってイエスにしてしまった。
イエスと言ってしまうことはあるかもしれないが、ノーと言える基準はしっかり持っていきたい。
話は変わるが、サンクスコストと言うのがある。一度やり始めたから後戻りができなくなって無駄にズルズル続けてしまうのは良くないので、早々に辞めろと言うやつだ。本書でも言及されている。
なぜいまソフトウェアエンジニアをしているのかと言うと、その職しか知らないから、と思っている。もちろんコードを書くのは楽しいし、ユーザに価値を提供できる仕事だし、合理的な会社が多い、などの理由もある。
そもそもコードを書こうと思ったのは、大学の周りの人がプログラミングをしててかっこいいと思ったからが5割で、暇だったからが5割。
そのコードを書き始めたのも大学の中盤からで早いとは言えず、最初の頃は勉強するのが辛くて仕方がなかった。中学高校から息を吐くようにプログラムを書いている人とは違う。数学も苦手で、高校1年の初めてのテストが赤点でそれからずっと苦手で、受験も日本史で入学した。仕事でコード書いててもつらい気持ちになることが多いし、毎日勉強しないといけないという焦燥感があるし、5年コード書いているのにオブジェクト指向も良くわからないし、デザインパターンも5個くらいしか知らないし、劣等感ばかりつのる。
つまり私はソフトウェアエンジニアに向いていないのではないか、という話である。
向いていないのであれば、それはサンクスコストなので早々に辞め別のことをした方が良い。
「ソフトウェアエンジニアに向いていないかもしれない」と思いながら「自分の仕事の本質」などを考えるのはおかしいのでは?と思ってしまっている。
しかしコードを書くのが楽しい時もあるし、適当にコード書いてる人よりかはまともなコードかける自信が付いてきたし、正直それ以外の職でどうやって働くのか全くイメージが湧かない。
結局ソフトウェアエンジニアとして顧客に価値を届けることに従事していきたい、という結論に達した。
IT と全く関係ない他の職も経験してみたい、パン屋さんになりたい、蕎麦打ってみたいし、ろくろも回してみたい。しかし他の職を体験したら絶対に「こんな非効率的な職業ありえない」と言うと思うし、ソフトウェアエンジニアに向いているのかもしれない。いや染まっただけか。
読み始めた、半分近くまで来たので明日読み終わりそう。
Deep Work みたいな内容で、何かを選択することは何かを捨てることである、自分が何を選択すべきなのか考えよう、みたいな内容。
いわゆる自己啓発本ってやつっすね。
読み終わった。
いい本だったが、自分の考えとだいぶ近く「ウンウンわかる」という内容だったので読む意味はあまりなかったかもしれない。
オブジェクト指向設計実践ガイド ?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
先日 「オブジェクト指向でなぜつくるのか」を読んだ が、内容が薄かったのでもっと濃いオブジェクト指向についての本が読みたかったので、先輩に勧められたこともあり読んでみた。
内容は濃くて良かった、こういう本が読みたかった。
特に良かったのが「オブジェクトがあるからメッセージを送るのではなく、メッセージを送るためにオブジェクトがある」とのところ。
自分はそんな真面目に考えたことはなく、軽い気持ちでクラスを定義しメソッドを作成してしまうので、そうではなく相互関係をちゃんと検討した上で実装すべきなんだなと思った。
そういうメッセージベースの考え方ができるようになると一段上に上がれるとのことなので、意識していきたい。
また、クラス内で具象化してしまうと依存度が高くなってしまい良くないので、 DI して依存度を外から設定できるようにしよう、というのが繰り返し述べられていた気がする。
ここはテスト書くときにほぼ必須なので最近気をつけている。
1つ疑問だったのが、この著者は静的型付を「コンパイル時間がかかる割にメリットが少なすぎる」と言って動的型付を持ち上げているところ。
別にそれはいいのだが、静的型付だったら何も意識しないで済むところを動的型付はテストを書くことでカバーしていて、静的型付にもメリットがあるところをちゃんと書くべきでは、と思った。
全体的な内容は良かったのだが結構難しく、正直あまり理解できない部分が多い… 3ヶ月後くらいにまた読み直そうと思っている。
以下 wikihub 日報 に雑に書いてた感想まとめ。
読み始めた。 Ruby でオブジェクト指向についてガチで学ぶ感じになりそう、うわべだけのオブジェクト指向 ではなく真髄に迫る感じがして良い。
25%まできた。
ためになる!(いつもためになるって言ってる気がする)
Gear と言うクラスを愚直に作った後に徐々に綺麗にしていく流れ。
自分はメンバ変数をいろんなところで叩いてしまうのだが、この本によるとアンチパターンっぽい…。
オブジェクト思考はクラスがどうこうではなくメッセージをどう送り合うか、と言うことらしい。
正直あまり理解ができてない点が多く、自分は全く理解できてないだなと言うのを理解できて良い。
真ん中まで読んだ。
ためになる!のだが、静的型付と動的型付を比較し、最終的に「いいから動的型付は最高なんだよ」みたいに押し付けっぽい感じになっててかなり萎えた。
それぞれ良さはあるし、「私は動的型付けの方が良いと思っています」と主張を述べるだけのが良いのでは、この本の内容全部押し付けなのかなと思ってしまう。
65%まできた。 Module と Class の違いが述べられていたがあまりよくわからなかった、つらい。
75%。コンポジションとかの話、正直よくわからなくて、もう一度この本を読み直した方が良さそう :cry:
87%まできた。明日読み終わる。
静的型付だったら問題にならないようなことをつらつら書いていて、なんでこの人静的型付ディスってたんだろうって感じがある。
読み終わった、良い本だった。
モバイルアプリ開発エキスパート養成読本 (Software Design plus)
モバイルアプリ開発エキスパートになりたいので読んでみた。
初っ端からいきなり Kotlin の話があり攻めてて良い。
iOS エンジニアなので iOS 関連のところの心に残ったことだけ、さらにこれは書評ではなくメモに近いので、本の内容がどうこうよりもそれを読んで感じたことを書いておく。
Swift 3 の命名規則についての記事を読むたびに、英語力が足りないと Swifty なコードをかけないと感じる…。
Protocol の命名、 HogeProtocol とか書いてるのみたりするけどそれは思考停止で Swifty じゃないのだろうな。
メソッドの定義はなんとなく動詞で書きたくなってしまうのだが、これは Swift 関係なく改めないとマズそう。
Memory Graph Debug の使い方などが書かれている。
Xcode Extension については、私は XVim のために署名を外して使ってしまっている、誰か XVim-Extension を作ってくれと言う気持ちしかない。
Rx なんとなく理解してきたタイミングで読んだが、やっぱり概念はわかるけどモヤモヤが晴れないと言う感じ。難しい。
Subject や Value は積極的に使うべきではないと書かれていて、でも MVVM やるなら PublishSubject とか使うわけじゃないですか、これもアンチパターンなのだろうか。
宣言的にかけるのは確かに良い。のだが、素人が Rx してしまうとわけがわからない複雑な Stream ができてしまう気がする。と言うか私の書いている個人開発の MVVM がだいぶ辛くなっている。
自分一人でやっていると間違いに気がつきにくいので、複数人でレビューし合いながらやるのは良いと思う、自分の理解力や実装力が足りないと言われてしまえばそれまでだが。
UITextField の初期化時に空文字列が bind されてしまうのに困っていたのだが、 skip(1)
で初期化時の空文字列は無視しよう書かれていて、一つ疑問が晴れてよかった。
storyboard, TableViewCell の初期化やキャストを Swifty に書いていこうという内容。
会社でやっているのは segue で画面遷移しているので、 segue は早く引き剥がしたい。
TableViewCell のもこのやり方に変えるぞ!
めちゃくちゃためになる。
UITest は書いたことないし、パフォーマンスがテストできるのも恥ずかしながら知らなかった。
今後 UITest を書くかと言われると微妙、でも書いてある通りログイン画面などの非常に重要なところはあったほうがいいかなと思った。
読むのにそんなに時間はかからないし、ポイントがわかりやすくまとまっているので良かった。
やはり読んだだけではモバイルアプリ開発エキスパートにはなれなかったので、学んだことを少しでも実践していきたい。
あと表紙のおっさんは誰なんだろう。
めっちゃいい本だった。
ソフトウェアエンジニアとして勝ち組になるためには〜みたいなことがひたすら書かれており、意識が高い。
面接、給料、資産運用、健康などとソフトウェアとは関係ないことも多く、確かに人生マニュアルだった。
1年に1回読み直したい。
特に強く心に残ったことが2つあった。
何かをやろうと思うとき、バカにされるのが怖くて一歩を踏み出せないことがある。
例えば勉強会に登壇して失敗したらどうしようとか、記事を公開した時に内容を間違えていたらどうしようか、などである。
しかし勉強会で上手く話せなかった人のことをあなたは覚えているだろうか、そんなことは誰も気にしないし過ちにも気がつけるのだから勇気を出しなさい、と書かれていた。
また、失敗は敗北ではないのでどんどん失敗し学んでいけとあり、自分は割と失敗を怖がり安全に走るので心にクる内容だった。
本を読み終わりとりあえず勉強会の登壇ボタンをポチッと押した。
生産性を高めるためにポモドーロが良いと書いてあり、実際にやってみたらめちゃくちゃ進捗出てすごい。
25分仕事して5分休む、というのは前にもやってみたけど全然効果がなかったけど、「ちゃんとその日やるタスクを決めてからそれを25分以内に1つ消化できるように全力を出す」ようにしたらめっちゃ効果が出て、ちゃんとタスクを決めるのが重要なんだなと思った。
また、ポモドーロやっていると、誰かから話しかけられた時にタイマーを指差して「その話めっちゃ緊急ですか?10分後でもいいですか?」とできるので良い。(向こうは面倒だと思うだろうけど…)
Deep Work にも、毎週・毎朝のスケジュールを決めて時間を意識し仕事をすると進捗が出るなどと書いてあって、本当にその通りだった。
KanbanFlow というサービスがあって、これはタイマーとタスクリストを連携させて、そのタスクがどれだけ時間かかったかなどの分析も丸っとできて良い。
以下 wikihub 日報 で雑に書いてた感想のまとめ。
読み始めた、17%くらい。読み応えがある。
耳が痛いことがめちゃくちゃ書かれている。この本は毎年読み返した方が良い気がする。
特に
自分の仕事はコードを書くことだと思っているなら、考え直すべきだ。…他のあらゆる職種と同様、人と接することである。
がだいぶ心にきた。 :sweat:
以下雑なメモ:
5% くらい読み進めた。
32% くらいまできた。
自分の価値を高めよみたいな話で、有名な Podcast にでろとか言ってるけど、そもそも有名な Podcast に出る人は価値が高いんじゃないですかね?
ためになる。
自分をプロモーションするために SNS をうまく使え、カンファレンスで講演しろみたいな話が続く。
ひたすら意識が高い。
55%まできた。
理解を深める一番の方法は人に教えること、というのが強調されている。
また、生産性の章では Deep Work に書いてあるのとほぼ同じことが書かれている。
本の前半で「あなたの仕事はコードを書くことではなく人間とコミュニケーションを取ること」と書いてあったが、この章では「オフィスのドアの前に'話しかけるな!'と書いた札を置いておけ」と書かれてて、ハア〜どっちなんじゃいという感じだ。
75%くらい。めっちゃためになる。
「この本を読んでる君たちは特別だから勝ち組になろうや」みたいに書いてあって、読んでるだけで肯定感があって上手いな〜と感心してる。
85%、明日読み終わる気がする。 筋肉は素晴らしい、体の健康は心も健康にするなどと書かれている。
私は胃下垂というやつで食べても太れない側の人間で、筋肉をつける前にまず一般的な体型になりたい…。 BMI は17.5とかで異常値であり、大変厳しい。まず病院に行こうと思う。
読み終わった。
いい本過ぎた、感化されたので勉強会に登壇するボタンを押し、病院に予約を入れた。
失敗は良いことだしどんどん失敗しろ、怖いかもしれないが失敗は敗北ではない!とあり、なるほどという感じがある。
自分は本を読むのが遅く、さらに理解度が低いというつらい感じなので、そこらへんをなんとかしたいと思ってこの本を手にとってみた。
「本を読むのが遅い人は無駄に頑張って読みすぎなので、音楽を聴くようにもっと気軽に本を読んで、1行でも心に残る文章があったらそれで良いんだぞ」みたいな内容だった。あと見出しで判断して違うと思ったら読まなくて良いんだぞ、とか。
無駄に頑張って本を読みすぎというのは心当たりがあるのだが、見出しレベルで判断するというのはする気になれない…それが遅読の原因なのかもしれないが。
言っていることはわかるのだが、あなたはそう考える人なんですね、という感じで自分にはあまりためにならない本だった。
というかそもそもこの本は内容が薄く、1/3くらいでかける内容を冗長に書いている感じがして、遅読家向けの本なのに内容が薄く長いというのはどうなんだ。
遅読の人が読むんだからもっとページ数少なくするべきでは。わざと冗長に書くことで読み飛ばすことを実践させるという高度な内容になっているのかもしれない、などと思いながら読んでいた。
本を読んだ後に「もっとも素晴らしいと思った引用を1つだけ選ぶようにしよう」とあったので、1つだけ引用する。
「なにか」が頭の片隅に残っているのだとすれば、少なくともその部分が自分にとって必要だということ。
その本から得られる価値の全てはまさにそこにあり、1冊を読み通したことの意味は、その一節に出会えたことにある
以下雑なまとめ。