Memory技術のこととか、技術以外のこととか、思ったことを書き留めています。2019-12-312019年の振り返り記事が消えた確か6000字くらい書いた気がするんだけどなぁ...一回同じタイトルで振り返り記事を書いたのですが、投稿中に無線LANの接続がおかしくなり記事が消えました。(公開ボタンを押下した後、Safariが「ページを読み込めません」画面を表示、再読みこみのためCmd+Rを押したところ記事が全部消えた状態で編集画面が表示された)来年の目標は家の無線LANアンテナを買い換えて安定した回線を手に入れることです。来年までの時間が許す限り思い出して書いていきたいと思います。後輩Qiitaにも書きましたが、インドから来た新卒のエンジニアさんが後輩になりました。qiita.comまた、高校生のインターン生も来ました。この二人に、今後エンジニアとして活躍できるようにスキルやマインドを伝えていくことが今年の目標です。発表とかDoridKaigi初登壇でした。docs.google.comdocs.google.comdocs.google.comdocs.google.comdocs.google.comdocs.google.comdocs.google.com今年もDroidKaigi登壇します!来てね!!!エンジニアリングFlutterしてる一年でした。developer.diverse-inc.com昨年からリプレイスしていたアプリを公開でき、たくさんの方から注目していただく事例になったので感無量です。世の中的にはiOS/Androidのどちらが覇権を握るか、という競争が(結局どちらも覇権を握らなかった、という形で)ひと段落し、モバイルのエンジニアは両プラットフォーム向けにアプリを作らねばならない、というある意味では非効率的な状況になっています。した中でクロスプラットフォーム(X-Plat)なフレームワークの一つとしてFlutterが注目されている、というのが現状なのだと思います。MPPに力を入れていくようです。(8.0)をいじったりしてました。pandasとnumpy何もわからないんですが...あれむずくない?旅行id:side_tanaさんに縁のある人たちで台湾旅行に行かせていただきました。私以外の人たちが水曜どうでしょうノリで面白かったりして(私だけ水曜どうでしょう未履修だった)、めっちゃ楽しかったです。他にはシンガポール行ったりタイに行ったりしました。タイではハスキーに人生相談に乗ってもらいましたプライベート未だに通勤に片道1.5時間かかっている生活が続いているので、早く通勤時間を短くしたいところです。昨年に「実家を出られない事情は時限式」と書いた気がするのですが、前提が崩れてしまい事情が無期限になってしまった、というように状況が悪化しているので、心労がやばいです。来年の抱負まずは後輩たちにもっと成長できる環境を用意することが一番です。今のところは、「どんなコードが良いコードか」を判断できるようになって欲しいかなと思っています。「良いコードとは、ドメイン知識に合わせた適切な抽象度でクラスやメソッドが分割されていて、各種原則に則していて...」という説明は当然してはいますが、一つ一つの具体例に対してしか説明できていないので、もっとたくさんコードを読むとか、自分で書いたコードを長期間メンテナンスしてみるとか、してもらうしかないのかも、と思い始めているところです。多少なりと話せるようになったので、あとは語彙力をつけていきたいと思います。23:442019年の振り返り広告を非表示にするもっと読むコメントを書く2019-11-17日本語話者が英語を話すことの難しさ私も多分にもれず、中高の6年間も英語教育を受けていたにも関わらず全然英語を話せない種類の人間なのですが。最近仕事で英語で会話する機会が増えて、その度になかなか話したいことの英語表現がスッと出てこないので、自分なりに原因を考えてみました。私の場合、日本語で何か伝えたいことが出てきた場合に、以下のプロセスを通して口から言葉が出てきている気がしています。段階では「何となく」しか話したいことが浮かんでいません。言葉にしてみないと整理できていなかったりする支離滅裂なこともあったりします。段階でようやく言語化していて、この段階で、抽象概念的な何かが言葉になります。英語で話す場合は、抽象概念的な何かを言語化するプロセスでいろいろなことが起こります。話したいことがもやっと頭に浮かぶ(非言語)言語化する必要のある部分だけ言語化する。英語で発話するあくまで私の場合ですが、英語で直に発話できる場合と、英語に該当する語彙がない・日本語の方で先に概念に該当する語彙を見つけてしまったなどの原因で和英翻訳をかける必要がある場合の二つがあります。あれです、CPUのエミュレーションをせずネイティブで動いている場合と、CPUエミュレーションしているみたいな違いです。すると、スッと英語で話せるようにするには、エミュレーションなしで話せるようになればいい訳です。英語に該当する語彙が見つからないケース当然ただ単に語彙が不足していることもあるのですが、普段の日本語での思考の癖が足を引っ張っているケースが少なからずあることに気づきました。上司が部下に「それ、なんとかしておいて」と言うみたいな、超抽象的なことを伝えたい時。英語でこれと同じことを伝えようと思ったら、私はけっこう骨が折れます。?こう訳すだけでも、「なんとかする」の翻訳はちょっと考え込んでしまいました。以下のような、言葉の解像度を上げると言うか、具体化するというか、そういったプロセスが必要だったためです。way."この間3〜4秒程度でしたが、会話だとちょっと「間が開いた」と思われるには十分な時間がかかっているわけです。抽象的な概念から直に英語の表現が出てくれば問題ないのですが、問題は日本語で「なんとかする」という語彙を先に閃いてしまった場合。「なんとかする」に直接的に対応する英語の語彙を私は知らなかったので、どうしても日本語の便利な語彙「する」に頼りがちです。一度「する」という語彙に落ちてしまうと、英訳が非常に難しくなります。同じような概念の言葉ではないから。「する」だけではないですが、日本語って曖昧で、普段の会話の範囲だけで考えを言語化しようとすると、英語に落とし込むためには具体度が低すぎる考え方になってしまいがちで、すぐに考えが英語にならないのが一因にあるのでは、と思いました。日本語話者が英語を話せるようになるには日本語でも抽象度が高いまま話さず、具体的に話す(動詞だけでなく、副詞、形容詞も)英語の語彙をたくさん身につけるというようなことが必要なのではないでしょうか。普段から文章をたくさん書いている人とかは、文語体で考える癖がついていて、文の構成要素が具体的になりやすくて英語で話しやすい、とかあったりするのかしら。principle他にも増やしたい語彙が見つかったらまた書く。人間というのは不思議なもので、知っている物事は簡単に認識できても、知らないものはなかなか認識できなかったりします。知らないもの、というか、意識の外にあるもの、というか。いうものは簡単には認識できない傾向にあるようです。私は同僚が髪を切ったとか、そういうことに無頓着だったのでにあまり気づかない人でした(今でも気づかなかったりすることがあります)。人生において色々な物事が自分の脇を通り過ぎていくように思えますが、そのうち認識できているのはどの程度なんだろうか、それを認識できるようになるにはどうしたら良いのだろうか、とふと思ったりするわけです。いったものを認識するにはそのものを知る必要、もしくは強烈に認知する必要があります。髪を切ったことに気づくには、「人が髪を切ったことは話題になるし、気付いてもらえると嬉しい」ということをわかっているか、誰かに「あの人、髪を切ったね」と教えてもらうか、とかがそれぞれに該当するかも。かたや、リベラルアーツとか教養の必要性がよくわかられていない、というような話がTwitterでよく見受けられる気もします。私も大学時代は教養の必要性はわかっておらず、授業のテーマで「なぜ大学や大学院が必要なのか」を考えることになった時に「同等の教育ができるなら専門学校があれば良いのでは」という結論を出したこともありました。今であれば、知らないと気づけないから、予め広い分野において知識を仕入れておくこと、広い世界があるのだと知っておくこと、色々なことに気付けるようになること、それが教養なのだと思います。話の通じない弟には様々な分野の本を読んで欲しい...(奴はラノベしか読まない)いくら自分に対して思索を深めたところで、自分以外の考え方や世界があることを認めなければ、いつまでも井の中の蛙なのだということをわかって欲しい...まあ私もまだまだ教養が足りない部類の人間だから、そう言っても行動で示しても伝わらないのかもしれないけれど...自戒を込めて。広告を非表示にするもっと読むコメントを書く2019-10-20エンジニアの育成とマネジメントが難しい(と私は思い込んでしまっている)年一更新のブログになってしまいそう。それでは良くないので、思ったことを未整理のままでも書き出してみたりしようかと。職場に新しいエンジニアの方々お二人がいらっしゃって、それぞれのメンターを務めることとなりました。どちらもお若くて、ほとんど新社会人みたいな感じ。お一方はインドの大学の新卒、もうお一方は高校生インターン。どちらもプログラミングは結構できる方。私は人を育てるということを上手くできた試しもないので、勝手に育ってもらうしかない。なりたいのかを聞きつつ、なるべくその要望を叶えられるようにタスクを振ろうと思っているところ。タスクを振るって言っても、私はタスクマネジメントも苦手なので、そこも上手くできるか自信がない。どれだけのことをお任せしても大丈夫なのかわからない。どんな仕事の進め方をしたら楽しんでもらえるのかもわからない。私がそんな振り方されたらマイクロマネジメントだと思う。お二方とも基本的な型というか、「この種のプロジェクトでは、このコードはこう書く」みたいなところまで理解が及んでいるのかわからないし...いやいや、そんなの書いてみてもらってコードレビューするまでわからない。2〜3年前のペーペーの頃はどう指摘したものかわからなかったけれど、最近の私なら設計原則に関する語彙があるので、理由を説明した上で必要であれば軌道修正ができるかも。なると比較的最初から設計の方針を話し合いの上で決めた方が良いのだろうか。納得の行く進め方をしたいし、そうした方がきっと良い。まとまらないまま書き始めてみたら悩みが一つまとまって解決してしまった。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。