koogawa blog

iOS、Android、foursquareに関する話題

StackOverflow、昨年リリースした Documentation の投稿受付を終了

去年リリースされた StackOverflow の Documentation というサービスを覚えているでしょうか?

www.publickey1.jp

上記の紹介記事も300以上ブックマークされていることから、日本でも一部では注目されていたのではないでしょうか。

その Documentation ですが、静かにその役目を終えようとしています。

meta.stackoverflow.com

文中では

We still think Stack Overflow Documentation is a good idea.

「我々は今もなお Documentation は良いアイデアだと思っている」という考えは強調しつつも

By May, it was clear we weren't on the right path. New users weren't coming to Documentation. So we went back to the drawing board and started another round of user interviews focused on Transact SQL. We brought on a user experience researcher to help us interview technical writers. The results were encouraging in the sense that we know a lot more about what makes for great documentation and how we might support that effort.

以前から新しいユーザー集めに苦戦していたことは認めており、それを解決するために色々と試行錯誤を重ねていたようです。

But it was also clear fixing Documentation would require a significantly larger team.

しかし、すべてを解決するためには莫大なリソースが必要になることもよくわかっていたようです。

今後

投稿されたコンテンツの扱いについては、今後ユーザーと議論しながら決めていくようです。最低限、テキストのアーカイブは提供されるとのことです。

Documentation によって獲得した reputation やバッジの取扱についても詳しく書かれているので、気になる方は読んでみると良いでしょう。

iOS 11にアップデートしたら「○○が位置情報を利用中」という青いバーが常に表示されるようになった場合の対処法

iOS 11にアップデートした直後、次のような「○○が位置情報を利用中」という青いバーが常に表示されるようになった場合の対処法です。

f:id:koogawa:20170618224214p:plainNDA期間中につき、スクリーンショットiOS 10のものを使用しています

1. どのアプリが青いバーを表示しているか確認

「○○が位置情報を利用中」の○○の部分がこの青いバーを表示しているアプリの正体です。上記の例だと、Google Maps がそれにあたります。

2. 位置情報の利用設定を変更

設定アプリを起動します。

f:id:koogawa:20170618224703p:plainNDA期間中につき、スクリーンショットiOS 10のものを使用しています

プライバシー>位置情報サービス>アプリ名

の順にタップします。

f:id:koogawa:20170618230330p:plainNDA期間中につき、スクリーンショットiOS 10のものを使用しています

「常に許可」以外 を選択することで青いバーは表示されなくなります。

注意

「このAppの使用中のみ許可」を選択した場合、当然そのアプリは起動している間しか位置情報を利用できなくなります。アプリによっては起動中以外も位置情報を取得し続けることが前提で作られているものもあります。その場合はアプリが正常に動かなくなる可能性もあるのでご注意下さい。(自己責任でお願いします)

なぜ青いバーが出るようになったのか?

技術的な理由を知りたい方は下記エントリをご覧ください。

qiita.com

【iOS 11】#WWDC17 What's New in MapKit メモ

developer.apple.com

【iOS 11】#WWDC17 What's New in Location Technologies メモ

developer.apple.com

PHPカンファレンス福岡 2017 #phpconfuk に参加してきたよ

最近はサーバーサイドエンジニアをやっております @koogawa です。

今日は博多にて開催された PHPカンファレンス福岡 2017 に参加してきました。

f:id:koogawa:20170610140029p:plain

福岡での開催は今年で3回目だそうです。

会場はFFBこと、福岡ファッションビルです。

f:id:koogawa:20170610140052p:plain

ちなみに、私がPHP関連のイベントに参加するのは約10年ぶりになります。最後に参加したのはたしか 日本 PHP ユーザ会 (Japan PHP Users Group) :: メイン :: PHPカンファレンス2008 - プログラム概要 だった気がします。

***

以下はイベント中のメモになります。間違いなどありましたらご連絡ください。


PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計

セッション内容: PHP はバージョンを追う毎に堅牢なコードを書くための機能が充実してきましたが、 PHP7 ではついに例外や表明の機能が大幅に見直され、強化されました。本講演では、例外処理を設計する際の基本的な考え方や、表明(assertion)の使い方、そして表明と例外を使い分け、堅牢なコードに導くための設計手法「契約による設計(Design by Contract)」の考え方を説明します。

登壇者:和田卓人 (@t_wada)

  • 予防的プログラミング
    • 問題発生を事前に防ごうというコーディングスタイル
    • 「そうなるはずだ」と決めつけない
    • 不正な使われ方をしても被害を受けないようにすること
    • ※悪いコードに絆創膏をあてることではない
  • 攻撃的プログラミング
    • 早めにクラッシュさせる!
    • 障害を抱えて中途半端に動いているプログラムよりも死んだプログラムのほうがダメージは少ない
    • PDOException が発生する設定にする
    • 例外は無視できない!
    • PHP7のassertを使う
  • 契約プログラミング
    • ソフトウェアモジュールの権利と責任を文書化(そして承諾)し、プログラムの正しさを保証するための簡潔かつパワフルな技法
    • 実行時の表明違反(や、バグを示すための例外)は、そのソフトウェアにバグがある証拠である
    • バグと例外を区別し、さらに誰の責任かも見分けられるようにする

API型決済サービスから見る決済の未来

セッション内容: APIへリクエストを送るだけでクレジットカード決済が出来てしまうAPI型決済サービス。導入もとても簡単で、直接カード情報を取り扱わないのでセキュリティ的にも安心です。 そして、各サービスを利用していると決済UIがとても似ていることに気が付きます。これが共通化されれば特別な実装なしで決済が出来てしまいます。

実はW3Cでは昨年からWeb決済 ""Payment Request API"" の仕様策定が進んでおり、一部ブラウザに既に実装されています。 そんなAPI型決済サービスの現状とPayment Request APIを踏まえて決済の未来についてお話します。

登壇者:穴井怜 (@gorou_178)さん

私が今最も興味を持っている分野ということもあり、興味深く聴かせて頂きました。Payment Request API については、恥ずかしながら名前すら知らなかったので、後で詳しく調べたいと思います。

  • API型決済サービスとは
    • 「このクレジットカードに100円課金して」という情報を送信するだけで支払い完了
    • 数行のコードコピペで実装できちゃう
  • API型決済サービスでできること
    • クレジットカード決済
    • 顧客管理
    • トライアル・クーポン
    • 多彩な通貨での課金(APPLEPAY, BITCOINなど)
  • セキュリティは大丈夫なの?
    • PCI DSS に準拠しているので安心
  • 利用審査
    • 審査には時間がかかる
    • 審査に通るまで入金されない
    • 会社にもよるけど、だいたい1ヶ月ぐらいかかる
  • 課題
    • 対応通貨に差がある
    • 支払方法の種類に差がある
      • ○○は対応してるけど〜は未対応
    • 様々な支払い方法に対応するには複数のAPIを導入しないといけない
    • UIがバラバラ
  • 今後の決済の未来
    • BITCOINイーサリアム、Ripple
    • 国境がなくなってきている
    • 決済という共通の仕組みがあればどこでも購入できるようになる
    • 経済を変えてしまうインパクトの有る技術

新卒2年目がサービス開発の際に乗り越えた課題とその解法など

セッション内容: Fusicは、2017/04/01にsigfyという連絡網サービスをリリースしました。 その開発は、登壇者(2016年新卒入社)と、 先輩エンジニア(2015年新卒入社)が中心となって行いました。

既存サービスの機能をCakePHPで完全リプレイスし、機能追加するプロジェクトでした。 登壇者は、このプロジェクトの仕様設計からサービスのリリースまで関わりました。 その過程で数々の問題に遭遇し、それらを解決してきました。 本セッションでは、どのように問題を認識し、解決したのかを発表したいと思います。

登壇者:株式会社Fusic 濱野泰明 (@gorogoroyasu)

  • sigfy
    • LINEとメールに届く連絡網
    • 連絡網と言えば昔は電話だったけど、今は個人情報とかうるさくてできないらしい
    • サービス名は signal fire(のろし)から由来
    • PHP 7.0 + CakePHP 3
  • チーム
    • PO、営業、エンジニア2人
  • PHP 5.6 => 7.0 対応
    • もともとはPHP 5.6
    • いきなり受託で試すわけにはいかないので、まずは自社サービスで試す
    • 実は 5.6 の方がサポート期間が28日も長い
    • 速くなった話はここではしないので懇親会で聴いてね
  • デプロイ方法変更
    • git clone でやってた
      • コマンドが多く、煩雑
      • テストサーバーがどこだかわからない
      • デプロイツールを導入した
    • capistrano を採用
      • コマンド一発で完了するようになった
      • 設定ファイルにデプロイするbranch情報、パス情報、お客様固有の情報を書き込む
  • デプロイの自動化
    • 問題点
      • 設定ファイルが命
      • 間違ったら終わる
      • 黒い画面を開く必要がある
    • 管理サイトを作った
      • 設定ファイルを持たなくて良くなった
      • 非エンジニアもさわれる
  • 大量配信
    • Amazon SESを使っている
    • 送信数に上限がある(1日あたり10000通)
    • ソフトバウンスとハードバウンスをちゃんと管理する

僕達がやってきたレガシープロジェクトとの付き合い方

セッション内容: 弊社で運用している「超」レガシーなプロジェクトの運用改善事例を紹介します。 巷ではPHP 7.x系が話題ですが、サポート切れのPHP 5.3.x系のプロジェクトの話でも聞いて、和やかな気持ちになってください。 キーワードは「安全」で「楽」な「(レガシーだけど)モダン」な運用です。

登壇者:株式会社ハシゴ 渡辺 謙一郎 (@_nabeen)

  • プロジェクト概要
    • いわゆるブラウザゲー
    • 運用歴5年
    • LAMP
    • SVN 管理
    • PHP + Codeigniter + MySQL
    • PHP 5.3(2年以上前にサポート終了)
  • 問題点
    • テストコードが全く無かった
    • エンジニアがini職人化していた
      • エクセル化されたものをエンジニアがini化
    • コードレビューの文化がなかった
      • esa.io で変更点をまとめてレビュー依頼
      • svnにコードレビューの仕組みを淹れるのは簡単ではない
  • やったこと
    • 新規でコミットする部分についてはテストを書いた
    • エクセルから .yml を介して .ini を吐き出すツール作った
    • SubGitという git と svn を同期してくれるツールを使った

Fusicホール/14:15〜14:30 【ゴールドスポンサーセッション】海外からのアクセスを制御する

セッション内容: ホスティングという様々なお客様のいる環境下で、海外IPからの不正なリクエストを効率よく制限するために、検討したことや使用したソフトウェアの紹介をおこないます。 登壇者:GMOペパボ株式会社 田平 康朗

1,800リクエスト/秒の世界

セッション内容: AWSでEC2 2台 + RDSで運用されているCakePHPベースのとあるサービスに、2017年3月1日、1,800リクエスト/秒のアクセスがやってきました。 このアクセスは事前に予定していたことだったので、いくつかの対策をし、無事サーバダウンすることなく乗り切ることが出来ました。

本セッションではこのシステムの設計や、高負荷対策のプランニングと実行、当日の様子などについてお話します。

登壇者:長谷川智希 (@tomzoh)

iOSの勉強会でお世話になっている長谷川さんとPHPの勉強会で、しかも九州でお会いすることができました!

  • 今回の対象システム
  • 負荷がやってくる
    • 就活解禁日は 03/01 0:00 決まっているので、みんな一斉にアクセスしてくる
    • 負荷を想定する
      • Webサーバのスケールアウトで対応したい
      • DBがツラければスケールアップ
  • 負荷がやってきた
    • 予想以上にツライ
    • 負荷をかけ始めた瞬間にレスポンスが悪化し、ELBから外される
    • 5分と持たない
    • いくつかのAPIを静的ファイル化
    • 爆速になった!
    • 今回は3/1を乗り切ればいいのでこの対応で大丈夫

Progressive Web Apps + AMP = PWAMP for PHPer

セッション内容: 通信速度の向上と共に肥大化していくWebページ。いざ低通信速度環境や通信の出来ない環境に来た時に、ネイティブアプリなら通信の必要の無いコンテンツやキャッシュで一見普段と変わらないコンテンツを表示してくれることが多いですが、ブラウザは何も表示してくれませんね? それはあなたのWebサイトが時代に追いついていないからなんです。

Progressive Web Apps -> Service WorkerやApp Shellを有効に実装・活用することで、オフライン環境でもアプリ感覚でWebサイトをユーザーに届けることが出来ます。 Accelerated Mobile Page -> パフォーマンス向上の為に制約を設けられたHTMLのサブセット、というのは最早過去の話。色々なリッチコンテンツを作成出来る拡張機能を備えたマークアップ言語に成長しています。

これらを利用して、どこでも、より早く、ユーザーに有用なWebコンテンツを届けることが出来ます。 まずは、これらを気軽に触れるような機能の紹介や導入の手引をご紹介します。また弊社サービスでの取り組みをお話出来たらと。

登壇者:坂本結衣 (@yui_tang)

  • なぜWeb?
    • 回線環境の悪い国々ではアプリをダウンロードすることへの抵抗感が未だ強い
    • 1アプリ200円ぐらいかかったりすることも
    • Webでできることが増えている
  • AMP(Accelerated Mobile Pages)
    • リッチで遅い→シンプルで早い
    • HTMLに似ていて学習コストが低い
    • MOBILEって名前だけど、別にモバイル専用ではない
    • 既存ページと二重管理する必要がある、というconsも
    • AMPに必要なコンポーネント読み込み用のJS以外は基本的に使えない
    • モダンブラウザなら基本的に動く
  • PWA (Progressive Web Apps)
    • グーグルが中心になって進めている
    • WEBページでAPPのようなUXを実現する
    • Safari非対応
    • Twitter lite は PWA
  • Service Worker
    • 通常のページで動くjsとは違い、ブラウザ内でよしなに起動・停止するJS Worker
  • PWAとAMPを組み合わせるメリット
    • PWAはSWインストール後が早い
    • AMPはリッチなコンテンツはできないが、最初から早い
    • AMPページでSWがインストールできたら?
    • amp-install-servieworker

PHPerに覚えて欲しい日本語の重要性

セッション内容: バリデーションメッセージはPHPerにとって、ないがしろにしやすいものではないでしょうか?

「言葉なんて、あとでどうにでも修正できる。」 「これで通じるやろ」

そのように思いながら設定していませんか?

日本語は複数の意味を持つことができてしまう言語です。 また、「空気を読む」ことで、何となく理解しようと努力してしまう国民性もあるかもしれません。

伝わる日本語が書かれていないせいで、そのシステムが難しいシステムになっていないでしょうか?

今回は、テストして感じたシステムにおける日本語の重要性について、事例とともに紹介します。

・未入力です ・正しく入力して下さい

このようにバリデーションメッセージを設定しているPHPerのみなさまは是非聴講してください。

登壇者:フクダリナ (@rina)

  • よく見るバリデーションの例
    • 未入力です
    • 正しく入力してください
  • 未入力です
    • それは見たらわかる
    • どうすれば登録できるのかわからない
    • 〜してください にする
  • 正しく入力してください
    • 正しくって何?
    • 何が正しいのか、ユーザーはわからない
    • 全角で入力してください等にする
  • 下さい と ください
    • 下さいは欲しい時
    • くださいはお願いする時←こっちを使う

エラーと例外の再入門

セッション内容: アプリケーションを作る際、問題が起きたことを知らせるエラーと例外の機構は必要不可欠な存在です。 PHP7よりfatal errorが例外扱いになり、これまでのエラー機構を忘れている方も多いかもしれませんが、今でも便利な場面が多数存在します。

「エラー」「例外」とは何かを機能面から整理し直し、使い分けについて解説します。

登壇者:中野拓 (@Hiraku)

  • PHPはエラーの範囲が非常に広い
    • lint 的なのもエラー
  • エラー発生と後始末をわける
    • 例外はこのためにある
  • エラーと例外がある
    • 例外は無視できない
    • 基本的には例外を使おう
  • PHPerも例外安全を意識しないといけない
    • 我々は例外安全と共に生きなければならない!
  • Pokémon catching
    • やたら広い例外クラスで catch してること

ライトニングトーク(各5分)

PHPでWebサーバ作ろう

登壇者:富所亮 (@hanhan1978)

  • PHPでWebサーバを作れなくてよいのは中学生まで
  • 14行でWebサーバーが爆誕
  • Webサーバ作るとhttpリクエスト・レスポンス、IOの処理モデルがわかる!

WHERE 1 =1

登壇者:金澤裕毅

(こんふぃでんしゃる)

カンファレンスのこちら側とあちら側

登壇者:長谷川智希 (@tomzoh)

  • 本を発売して天狗になっていた
  • そんなとき勉強会に出てみたら著者だらけだった!!
  • 勉強会で発表している人はすごいようにみえるけど、実はそんなにすごくないよ!
  • 発表する側(あちら)と聴いてる側(こちら)は意外と近い
  • いつか発表したいと思っている人は今すぐ発表するべき!「いつか」なんて永遠に来ないよ

ガラケーの世界

登壇者:濱野泰明 (@gorogoroyasu)

SendGridで人生変わった

登壇者:s-ichikawa (@ichikawa_0829)

  • メールに関する様々な機能を提供するSaaS
  • Laravel でも使えるようにするライブラリ作った
  • 世界各地のエンジニアから連絡が来るようになった

バックエンドからのSEO対策 〜JSON-LDでのschema.org入門〜

登壇者:うえしー (@uessy_akr)

〜わたしの外国語学習法〜

登壇者:石田知世 (@chiyochan81)

  • 英語、韓国語、アラビア語を勉強中!
  • 勉強する目的を明確にする事
  • 外国人の友達と話したい!など

CakePHP3アプリを徹底チューニングしてみた

登壇者:貞方毅 (@sadapon2008)

  • メモリキャッシュ活用でI/O削減 267trans/sec -> 280
  • composerのautoload調整 280 -> 329
  • Apache チューニング(聞きそびれた!)329 -> 355

クイズを支える技術2017

登壇者:平田哲 (@debility)

  • 本日5つめのLT
  • 結婚式2次会の余興システム作った
  • はやすぎて聞き取れずw(とにかく賑やかなLTでした)

感想

PHPから長い間離れていたこともあり、時間の流れをところどころ感じました。

とあるセッションで「私達はまだPHP 5.3を使ってるんです」→会場笑い、みたいな流れがあったんですが、PHP 4 をメインで使っていた自分にとっては、あそこが笑うところだと気付きませんでした😅

こういったイベントに参加すると、その分野のトレンドを知れるのも良いところですね。

また、ここ数年ずっとiOSアプリ開発ばかりをやってたので、他のコミュニティから見たアップルの立ち位置みたいなのがわかって勉強になりました。(各社対応する中、Appleだけが対応してない・・!という話が結構あった)

***

全体的に素晴らしいイベントでした。運営の皆さま、スピーカーの皆さま、おつかれさまでした!

勉強会ゴロの件

anond.hatelabo.jp

こちらを読んで色々と思うことがあったので、レス形式で書いてみる。

(最初に言っておくとDISではないです。共感できる部分も結構ありました)

・一か月に50件や100件を超える申し込みをしている ・とりあえず申し込んでからキャンセルする ・同じ日に複数のイベントがあろうと、とりあえずエントリーする ・抽選で受かったイベントだけ残して、あとをキャンセルする

これだけだけならまだ良いのでは。

キャンセルしてくれるだけまだ良い。

・抽選で受かっても高確率でキャンセルする ・そして、イベント当日は高確率でドタキャンする

ドタキャンはなるべくやめていただきたいけど、仕事の都合などで本当に行けなくなる場合もあるので難しいところ。 自分が主催者側になる際は、あらかじめドタキャン率を考慮するようにしてます。

イベントではほとんど質問をしない or 自己アピールのための的外れな質問をし続ける

発表する側の経験から言うと、誰も質問してくれないのはやはり寂しいものがあるので、 何か疑問に思ったことがあれば質問してくれると嬉しい。 恥ずかしければTwitterでこっそり聞いてくれるも良いし。

ただし、本当に質問がない(質問するスキがないor価値がない)場合もあるので、これは参加者だけの問題ではない気もする。

「自己アピールのための的外れな質問」これは自分も気をつけます🙇🏻

「イベントに参加する」がゴールなので、そのあとの懇親会には来ない

これはよくわからなかった🤔

自分も人と話すのが得意ではないので、話したい人がいなければ懇親会が始まる前にさっさと帰ります。

懇親会がタダ飯の場合、隅っこでメシを食ってるケースが多い

これはそっとしといてくださいw

発表者になることは絶対にない

これも別に良いのでは。 オーディエンス側に回って発表内容をまとめるのも良いし、Twitterでタイムラインを盛り上げるのも良いし。

もちろん、発表者側に回ったほうが得るものは大きいんですけどね。*1

情報交換する、ディスカッションを行うという勉強会の目的上、勉強会ゴロに参加されると、コミュニケーションを円滑に行うことができなくなり、とても困る。

色んな勉強会に参加してみるとわかるけど、発表中に質問が飛んでそのままディスカッションに発展する勉強会は割と少ない(人数が多い勉強だと特に)。発表者が一方的に話して、質疑応答時間に何人かが質問して終わり、というのがほとんどだと思う。

また、懇親会を見てみても、孤立してずっとスマホをいじっているだけの人は割と多い。(私も孤立するのが得意である)

情報交換する、ディスカッションする、というのが本当の目的なのであれば、例えば座席をセミナー形式ではなく円形にするとか、開催者側も何かしら工夫が必要だと思う。

勉強会に参加し、腕の立つ人と一緒の空間にいることで、自分もそのような人物であると勘違いしている。

これは何だかわかるような気がする。。自分も気をつけます。

そのため、自分が彼らと同等の人物であるとアピールしようとして、的外れな質問をし続けたり、逆に、話すと自分が出来ないことが明るみに出るので、極力人と話さないようにする。

自分の弱みを隠すことは、最終的に自分を苦しめることになるのでやめたほうが良いと思う。

彼らは平日も週末も勉強会に行き続けており、自分で手を動かすことをしないため、いつまでたっても成長しない。 当人たちは、勉強会に参加することで、自分が成長していると思い込んでいるようだけど。

この人の言うとおり、勉強会はただ参加するだけでは何も成長しないので、発表内容をまとめてブログ書いたり、余裕があれば発表者側に回るなどしたほうが良いと思う。

会社の偉い人が勉強会に申し込みまくり、自分の部下に行かせることで、情報収集をしようとしているパターン。 明らかに興味がないのに、勉強会に参加しているというケースがあり、この可能性を疑っている。

これが本当だとしたら、非常に良くない🤔

たまにメモも取らずに全てのスライドをパシャパシャ撮って帰っていく人がいるけど、もしかするとあれはこのケースだったりするのかしら・・・いやいや邪推はやめておこう。

勉強会ゴロを排除したいので、イベント申し込みサイトの運営の方はNGユーザ機能を作ってくれないですかね。 勉強会を数度運営したり、それこそ適当なイベントの参加者を軽く舐めれば、誰が勉強会ゴロなのかは一発でわかるので。 月間イベント申し込み回数と、イベントのキャンセル率の二つの指標で勉強会ゴロは一発でわかるので、「勉強会ゴロの申し込みを禁止する」というチェックボックスを作ってほしいです。

どうでもいいけど、「勉強会ゴロの申し込みを禁止する」というチェックボックスの名前があまり穏やかではないw

というのは置いといて、あまりにも迷惑行為が多いユーザーを取り締まる仕組みは必要だと思うので、この機能自体はあってもよいのかなー、とは思う。

まとめ

勉強会に参加しまくるのは自由だけど、主催者や参加者に迷惑かけたらあかん😤

いずれにせよ「発表聴いて終わり」はあまりにも時間が勿体無いと思う。

Re: 半年後の自分へ

半年ぐらい前ですが、数ヶ月後に一児の父親になる自分に宛てて質問を書いていたので、回答したいと思います。

今もコードは書けていますか?

割と書けています。

子供が生まれる前(2016年の冬ごろ)と比べるとさすがにコミット数は減りましたが、今でも気になる技術があれば簡単なサンプルコードを書いてみたり、自分が公開しているライブラリのメンテも続けてますよ。

とは言え、いつでも自由にコードを書けるわけではなく、子供が寝た後の時間を利用して書くことが多いです(この記事も子供を寝かしつけた後に書いてます)。

逆に言うと、子供が起きているうちは何もできないと思った方が良いです。

勉強会には参加できてますか?

できるだけ子供と過ごす時間を大事にしたいので、参加する勉強会はかなり厳選するようになりました。

どうしても参加したい勉強会の例としては、

  • 会場となるオフィスを一度見てみたい
  • 会ってみたいエンジニアが参加者の中にいる
  • 自分が発表メンバーである

などです。

ちなみに最近は、Twitter上で開催される勉強会があるのも嬉しいですね。

Swift Tweets

こういった勉強会が今後も増えていってほしいですな😃

情報収集の時間はありますか?

これも「コードを書く時間はあるのか?」の回答と同じで、子供が起きているうちはほぼ不可能です。

さらに、最近は自転車通勤に切り替えたため、通勤中の電車の中で情報収集することができなくなりました。

よって、

  • 朝、子供が起きる前のわずかな時間
  • 昼休み
  • 夜、子供が寝た後

に集中して情報収集する感じになっています。

その他、半年前の自分に言いたいことは?

「子供が起きてる時間は何もできない」と散々書いてきましたが、これは決してツラいわけではなく、むしろとても幸せな時間なんですぞ😊

最初の数ヶ月は子供の顔が毎日のように変わっていくので、一緒にいる時間を大切にするんじゃよ😇