blogこの広告は、90日以上更新していないブログに表示しています。Qiitaの19日目」の記事です。子育てとエンジニアという視点で今年を振り返ってみたいと思います。今年は占いによると僕は良い年らいしいのですが、気づけばもう終わろうとしている。できたことか、ひとまず今年の出来事が来年以降良い方向に繋がってくれることを期待。僕は今27歳でエンジニアとして働く一方で、妻と5歳の長男と2歳の次男がいます。学生結婚なので社会人年数よりも子育て年数の方が長いです。結婚して子供ができるとコードを書く時間が減るとよく言われます。子供のいない社会人生活を知らないので、そこの変化にどう対応するかとかは分からないですが、子供がいる中でどう家族、子育て、仕事のバランスを保つようにしているか今年振り返りながら書いてみたいと思います。今年1年間は妻が製菓学校に通っていて、土日は製菓の会社で働いていたため休みの日は僕が子育てしていました。子育てはいつ何が起こるか予測できません。喚くこともあれば、突然体調崩したりすることもあります。仕事のようにスケジュール立てることはできないに等しいので、正直仕事よりも大変な部分は多いです。主婦の大変さがよく分かりました。製菓って大変なんですね。やりたいならやっていんじゃない、と軽く答えてしまった僕の責任。調べとけばよかったw妻が朝早いので僕が長男を幼稚園、次男を保育園に送ってから出社しているので朝は戦いですね。家族がやりたいことできてたほうが良いしこれまでの経験上家庭で問題起こると仕事もうまくいかないですね。家庭がうまくまわれば必然的に仕事もうまくまわります。結果的には正解だったなと思います。これまですべてにおいて仕事第一で考えていた時期もあったのですが、結果的に家庭うまくまわらず仕事にも影響でるケースもあったので、基本家庭第一で考えたほうが楽だなと感じた年でした。家族とエンジニア仕事からエンジニアという視点で考えた時、エンジニアって家庭とのバランス取りやすい職種だなと感じてます。柔軟な働き方ができるので、子供のイベントには結構参加できます。幼稚園の運動会のリレーとか積極的に走ります。長男の遠足に一緒に行った際も周りはお母さんでお父さん僕一人の状況もありました。言ってくれるので妻としては悪い気しないですよね。父親の立場としてもメリットしかないですね。始めからメリットを考えて動いたわけではなく結果的にそうなったと。エンジニアという職種だからできた部分でもあったなと感じました。子供のためにと思って参加したことで、それが家族にとって良い方向に繋がり、仕事のパフォーマンスにも繋がります。子育てとプログラミングエンジニアにとってコードを書くことは重要です。土日子育てしているとコード書く程のまとまった時間は取れないです。子育てしながらだといつ何が起こるかわからないので、コード書いていたとしても頻繁に手を止めなきゃです。今年を振り返ってみてもなかなか書けていないなと。来年は次男が3歳になるのでもう少し子育ても楽になること期待。長男が最近パソコンに興味持ち始めているのはエンジニアとしては嬉しいこと。と最近よく言うので早速一緒に何か作ってみようと思います。小さい頃は何か一緒にやるといってもおもちゃで遊んだりとかがメインでしたが、徐々にやれることが増えて、そしてゲーム作りたいとか言われたら、じゃ作ろうとなりますよね。来年は子供と色々作りながらコードを書く時間も作っていきたいと思います。有効に使うプロジェクトが大きくなるにつれてドキュメントの重要性は増していきます。ベンチャー企業では、スピード重視でドキュメントを残すよりも開発ばかりに重点が置かれてしまうこともあるかと思います。企画が決まり、じゃ開発、リリースこの日にしようみたいな具合に。リリース後に整備しようと思っていても、もはやそんなモチベーションもなく、むしろ次のリリースに向けプロジェクトは進んでいきます。今の自分のプロジェクトがこの状況で、見直さないとなと思っているところです。当たり前ですが、開発前の準備がないため開発中に諸々問題が発生します。必要なことに気づく、など挙げればたくさんあります。開発の手戻りはとにかくコストが高いため、開発前にドキュメントまとめればこういった問題は防げるはずです。言っても、ドキュメントを書くということもコストかかります。まとめておけば、そこまでコストもかからず、その後の開発がかなり効率よく進むのでは思っています。Development。書いてから開発に入るという手法。ドキュメントとしても利用します。書こうと考えています。Deployこれによって、スピード落とさずドキュメントも残せて開発前にある程度の問題は潰せておけるのではと思っています。人の入れ替わりがあっても引き継ぎがスムーズに進み柔軟な体制が組めます。あげておけば一元管理できるので楽です。ベースにまずはこの手法取り入れてみて、プロジェクトにマッチした形にカスタマイズしていきたいなと。書くだけでも色々な問題が解決する気がします。いうログライブラリがあります。ログの出力レベルがあり、コンソールやファイルにログを出力できます。ログフォーマットも自由にカスタマイズできます。このライブラリを使うことで、アプリを実機で検証しているときにアプリクラッシュ時のログが追いやすくなり、不具合改修時の手助けになってくれることを個人的には期待しています。書いておくのが楽です。デバックビルドでは出力レベルを低く設定、リリースビルドでは出力しないようにしています。#endif#endifコンソール出力時のカスタムフォーマットコンソールに吐き出す際のフォーマットをカスタマイズします。<DDLogFormatter>@endログレベルと、どのクラスの何行目で吐いているか出力するようにしています。ここではコンソールとファイルに吐き出すための記述をしています。適当に以下のようなログを出力します。log");コンソール先ほどのカスタムフォーマットが適用されこんな感じになります。どのクラス(SampleViewController)の何行目で吐かれたかもちゃんと表示されています。ファイルが配置されます。今はデフォルト設定でファイル出力していますが、ファイル名や拡張子は好きに変更できます。まとめログの設定がだいぶ柔軟に行えるようになるかと思います。ログ周りを整備するだけでもだいぶ開発が捗ります。spring今開発しているアプリのリニューアルをするにあたり、サーバサイドのフレームワークの選定が必要となりました。決めたのでその経緯をずらずら書いていこうと思います。リニューアル?一般的にシステムの寿命は長くて5年と言われています。出たり、新しい端末が発売されたりと、5年はまず持たないですね。アプリも2年半くらいたつのですが、そろそろ作り替えが必要な時期にきています。アプリの作り替えだけでなく、サーバサイドも設計の見直しも必要でした。設計がいまいちイケていなく、アプリで結構ロジックをガリガリ書かなければいけない箇所が多く発生していました。アプリではロジックを減らし表示させることだけに専念し、細かな処理は全てサーバサイドで行うようにできれば、開発スピードも上がり今後の運用も楽になります。いうことで、アプリのリニューアルに合わせ、サーバサイドのリニューアルも行うにあたりました。書かれており、これまで社内フレームワークを利用し実装していました。フレームワークが充実していてドキュメントも整備されているこの時代に、わざわざ社内フレームワークを使わなくても良いのではというここと、ちょっとした社内事情もありまずはどのフレームワークを利用しようかの選定が必要でした。Dropwizard。書いても良かったのですが、プロジェクトのメンバーが入れ替わったときの学習コストが高かったりとちょっとうちの会社には合っていないかなと思い断念。使いがいないというのと、会社の規模が割と大きいのと、メンバーが流動的に動く環境であったという色々な理由があり学習コストは極力抑えたかった。ものがあると知りました。プロジェクトの1つです。リリースされたばかりです。設定ファイルは意識する必要がありません。意識した設計になっていたため、導入への敷居が低かったことも決め手でした。今リニューアルし始めですが、これまでと比べかなりコード量も減らせ、さくさく開発が進みます。書いていこうと思います。通知からダイレクトにブラウザを起動させたとき、アプリが10秒くらい固まった後にようやくブラウザが起動する問題が起こりました。呼ぶとアプリが固まってしまうそう。なく以下に変更されてます。呼び出すことで解決できます。おけるマルチスレッドの手法の一つです。渡すことで逐次実行します。使うことでタスクの処理を非同期で実行してくれます。dispatch_sync。固まるのか原因が定かではないですが、これによってスムーズにブラウザを起動させることができます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。