現在勤めている会社を 5 月末日で退職します。 最終出社日が 5⁄20 だったので現在は有給消化期間です。 次の会社は 6⁄1 からです。 前職で何をやっていたか フロントエンド全般のエンジニアリングと、一部の期間はスクラムマスターをやっていました。 入社当時は、モノリスなアプリケーションをフロント・バックエンドのイマドキの構成に分離するプロジェクトが走り始める直前でした。 入社初日の私にフロントエンドの構築をほぼ一任されたとき、「あぁ、これがスタートアップか」と思ったことをよく覚えています。 前職で学んだこと 入社当時は良くも悪くも、「自分の持ち場で良い仕事をする」が仕事の理念でしたが（SES 出身だったことも関係してそう）、「チームで良い仕事をする」のような考えに変わりました。 もうとにかくプロダクトに関わる人が多かったりそもそもプロダクトが巨大だったりで、「これはもしかして自分だけが良い仕事しててもプロダクトは成長しないのでは…？」と思い、スクラムやアジャイルを本格的に勉強するようになりました。 @chichi1091 に誘われて参加した TDDBC Online の影響も大きかったです。 「スクラム…イテレーション…TDD…DevOps…あぁ、全てが繋がった、これがアジャイルか！」と閃いた瞬間があって、この辺りから開発チームロールとしてスクラム・アジャイルを啓蒙するような動きもしていました。 なぜやめるのか 月並みですが子どもが産まれて、育児の時間を大切にしたいと思うようになりました。 また、フロントエンドの構築は一旦やりきれたので、技術的なステップアップとしては頃合いかなぁと感じていました。 そう思っていたタイミングで、前職でお世話になっていた方からカジュアル面談の誘いがありました。 話を聞いてみると今よりも更に柔軟な働き方ができそうなことが分かり、事業内容にも共感できたので、そこからはトントン拍子に決まっていった感じです。 ちなみに前職へのネガティブな面も全くゼロではないですが、会社勤めなら誰しも少しぐらいは感じ得る不平不満ぐらいなもんです。個人的にここに特段強い気持ちはないので割愛。 これからのこと 次もスタートアップです。フロントエンドを強みに足りないことはなんでもやろうと思っています。話を聞く限りでは前職よりも更に落ち着いた雰囲気になりそうです。 実は技術スタック的にはあまり噛み合ってなかったりするのですが、私は得意分野にとどまり続けると逆にモチベ維持ができない人間なので、逆に勉強できるラッキーぐらいの気持ちで頑張ろうと思います。 おまけ （ 例のやつ です）

本記事は vue-cliで始めるVue.jsチュートリアル (2) - Qiita を移植したものです。 かなり古い内容ですが更新ができておらず、また2020年になってもvue-cli2.x系の記事にLGTMがついてしまうのは不味いのではないかと思い、Qiita側では文章を削除しております。 以下記事は上記を踏まえて参考にしていただければと思います。 以下転機 Vue.js チュートリアル(2) 前回プロジェクトの作成と、その中身を見てみました。 vue-cliで始めるVue.jsチュートリアル (1) ここからはこれらのコンポーネントを修正して、実際にTodoリストを作ってみます。 Todoリストの要件 Todoリストアプリケーションの要件は以下のように定義しておきます。 Todoはリストで一覧表示すること Todoはテキストボックスから追加できること それぞれのTodoにはチェックボックスが付いており、それを切り替えることでTodoの状態（未達成／達成済）を切り替えること チェック済のTodoを一括で消すボタンがあること それぞれのTodoは編集可能なこと 一般的なCRUD(Create, Read, Update, Delete)を持つインターフェースだと思います。 最終的にできあがったTodoリストはGitHub-pagesを使って配信するところまでを一先ずの目標とし、その後可能であれば、 コンポーネントの分割（親子間でのデータのやり取り） Vuexの導入 まで出来れば理想ですが一先ず一つのコンポーネントにべた書きでTodoリストを作ってみましょう。 SASS/SCSS その前に、*.vue ファイル内の<style> タグ内で、SASS/SCSS を書けるようにしましょう（これは好みなので、普通のCSSでいい人は入れなくてもよいです。但しサンプルコードはSCSSで書かれています） プロジェクトディレクトリ内で以下を実行します。 npm install sass-loader node-sass --save-dev これでSCSSが書けるようになりました。 HTML & CSSの作成 まずはhtmlとCSSでTodoリストのイメージを組み上げてみます。 diff: https://GitHub.com/sin-tanaka/vuejs_tutorial_todo_management/commit/07faa150878b8dade8fa48ee4f58168da31d08a2 <template> <div id="app"> <img src="./assets/logo.png"> <h1>Todo Management.</h1> <hr /> <router-view></router-view> </div> </template> <script> export default { name: 'app' } </script> <style> #app { font-family: 'Avenir', Helvetica, Arial, sans-serif; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; text-align: center; color: #2c3e50; margin-top: 60px; } </style> <template> <div> {{ msg }} <form> <button>ADD TASK</button> <button>DELETE FINISHED TASKS</button> <p>input: <input type="text"></p> <p>task:</p> </form> <div class="task-list"> <label class="task-list__item"><input type="checkbox"><button>EDIT</button>vue-router</label> <label class="task-list__item"><input type="checkbox"><button>EDIT</button>vuex</label> <label class="task-list__item"><input type="checkbox"><button>EDIT</button>vue-loader</label> <label class="task-list__item--checked"><input type="checkbox" checked><button>EDIT</button>awesome-vue</label> </div> </div> </template> <script> export default { name: 'hello', data () { return { msg: 'Welcome to Your Vue.

本記事は vue-cliで始めるVue.jsチュートリアル (1) - Qiita を移植したものです。 かなり古い内容ですが更新ができておらず、また2020年になってもvue-cli2.x系の記事にLGTMがついてしまうのは不味いのではないかと思い、Qiita側では文章を削除しております。 以下記事は上記を踏まえて参考にしていただければと思います。 以下転機 Vue.js チュートリアル 最近Vue.jsが楽しいです。そこそこ構文にも慣れてきたので、自身の理解度チェックも兼ねてTodo管理アプリを作成するチュートリアルを作成してみました。間違っている箇所あればご指摘頂ければ幸いです。 ※2018.9.10 追記 本記事執筆時は、vue-cli のバージョンは ｖ2.x.x 系でしたが、現在では v3.0.0 がリリースされていることにご注意ください。 https://github.com/vuejs/vue-cli/releases テンプレートからプロジェクトを作成するときの対話形式が大きく異なっております。また、そのほかにも変更点があるかもしれません。折を見てアップデートする予定ですが、それまではv3.x.x系には未対応ということでお願いします。大筋は変わらないはず。。 チュートリアルのゴール vue-cliをつかってプロジェクトを作成する Vue.jsでTodo管理アプリケーションを作成する 作成したアプリケーションをvue-loader、webpackでビルド／バンドルして、GitHub-pagesで配信してみる できたらやりたいこと コンポーネントに分割（親コンポーネント・子コンポーネント間でのデータのやり取り） Vuexの導入 詰んだ時 公式サイト: https://jp.vuejs.org/index.html 日本語の公式ドキュメントが充実しているのは私達がVue.jsを使う上での利点の一つです。困った時は公式ドキュメントを読んでみるとよいです。 作るもの 以下のようなTodo管理アプリケーションを作ってみます。 GitHub-pages: https://sin-tanaka.GitHub.io/vuejs_tutorial_todo_management/ リポジトリ: https://GitHub.com/sin-tanaka/vuejs_tutorial_todo_management/ 環境 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G1611 $ node -v v6.11.3 $ npm -v 3.10.10 vue-cliを使うためにはnodeとnpmが必要です。 エディターはIntelliJ系のIDEであれば、Vue.js用のプラグインがあるのでオススメです。筆者はPycharmです。 プロジェクトの作成 まずはvue-cliをinstallします。 vue-cliは雛形からプロジェクトを作成してくれる公式ツールです。公式には、「nodeやnpm、webpackに詳しくないならあまり使わないほうがいいよ」と書いてあるのですがとても便利なので使います。

自分用の引越ししたメモ そこそこ大変だったのでもう当分するまいと思ってますが、そんな忘れ去りたい記憶こそ残しとくといつか役立ちそう。 なぜしたのか 現住居が手狭になってきた 事情により駅チカな立地が求められた 更新月になったのでいっそ広いことに引っ越したい 家の探し方 効率的な賃貸物件の探し方 | nanapi [ナナピ] 賃貸関連のブクマは年1回ぐらいホッテントリしますが、おおよそ大元はこの記事に準拠しているようで、今回これを試した。 以下感想 始めるのに腰が重い メールアドレス探すのが大変 如何にして問い合わせ受けようとしてないかが伺える メールのやりとりでわかる情報は多い シンプルに激ヤバ文章力な仲介業者はこの時点でシャットアウトできる あとは返信早いとか遅いとか 業者で使ってるチャットへ案内されたりするとITリテラシ高そうだなとか 対面じゃないので圧で負かされることがなくなる 大体どこの業者も同じ物件を扱っているので条件さえちゃんと決めれば同じ物件が返ってくる 比べられるので適当なこと言ってるなとかも分かる 最終的にはいい感じの物件が見つかった インフラ整備まわり ガス・水道・電気の辺りは問題なく進んだが、インターネット回線の手続きで悔しい思いをした。 以下経緯 引越し前にプロバイダに連絡すると、「物件設備の調査及び工事日の調整に時間がかかるため、確約はできないが1.5-2ヶ月程度かかる」とのこと 1.5~かかるとなると仕事に支障が出るため、いっそのこと速度制限の無いクラウドWiFiにすればよいのでは いい感じの業者を見つけ申し込む 最大で30Mbps出ると謳っている 端末が届く 死ぬほど遅い 300kbpsとか Twitterでエゴサするとそんな声ばかり 解約を申し込む 違約金(12k)を請求される さすがに300kbpsはひどいので違約金なしでお願いできないか頼んで見る むり ここまではもうしょうがないと思ってた 端末一式の返却を求められる 説明書捨てた旨を伝える 端末一式(端末、外箱、説明書)なので欠品があると満額(13k)請求する ほぼ何もサービスを受けられないまま契約が終了し30kぐらい支払うことになる←いまここ 参考までに TheWiFi って業者です(ネガキャン) プロバイダ探し ネット回線探しは魔境みたいなサイトばっかり出てきてほんとどうしようもない感じですが、とりあえずプロバイダと回線提供者だけ決めたら価格ドットコム辺りから申込むとキャッシュバックが付くのでいいはず。キャッシュバック提供してる会社色々あるけど、前もこちらから申込んでキャッシュバック無事申請できたし、大手だしそこそこ信頼してもいい気がする。

この記事は https://qiita.com/sin_tanaka/items/77f7b6bf2c11d41617fc にも紐付いています。 TL;DR Slackで動的なユーザグループがあると便利そう @here みたいな Slackの usergroups.users.update APIを使うと行けるのでは？ Chalice (Python)と AWS Lambda 使って定期実行したらできた できたけど問題が発生したので辞めた 用途にあってるのか技術検証大事 前置き 弊社は歴史が古いながらも、「コアタイムなしのフルフレックス&リモートワーク推奨」な自由な働き方を売りにしている会社です。 出社時間はみんなバラバラですし、3割ぐらいはリモートワーカーです。よって、オフィスを構えているものの全員が出社することは稀です。 しかし働き方が変わると、議論すべき良し悪しや、解決すべき課題も発生します。 本記事はリモートワークの課題を解決しようとした話です。 リモートワーク時のチャット運用の課題 昨今、 @here , @channel 禁止等、各社のSlackの運用の話題になるのを見かけます。 通知は便利ですがプログラマの集中力を乱す原因にもなるからです。 そんな中、弊社Slackでこんな @here メンションがありました(自分のポストです、、) どうでしょうか？状況としては、「少し急ぎ」「アクティブなユーザにのみ通知したい」な状況なので、一般的な @here の使い方かと思います。 しかしリモートワーカーからしたらどうでしょうか リモートワーカーにとって社屋の会議室、応接室の使用状況は共有されなくても問題ないはずです。 つまりリモートワーカーにとってこの通知は不要なのです。 もちろんこれは通知をされる側だけでなく @here で通知する側もリモートワークの人に通知飛ばすの申し訳ないな、、と感じるかもしれません。 「リモートワーク推奨・・・だけど関係ない通知たくさんするよ！！」な会社だったらプログラマにとって働きやすい環境とは言えないのでは…？ このように、リモートワーカーが増えるとチャットの 通知先を設計 することが重要になってきます。 動的なメンション そこで考えたのが動的なメンションです。 ある条件を満たすユーザのみに通知されるメンションがあればこの問題を解決できると考えました。 今回の例でいうと、「今日出社している人のみに通知されるメンション」となります。 そういえば、 @here もチャンネル内のアクティブなユーザのみに通知する、という意味で動的なメンションですね。 実装の検討 弊社には内製の行き先ボードと、そのREST APIがあります。 これを利用すればオフィスに出社している人は一覧で取れる。 なのであとはなんとかオフィスに出社している人一覧に向けてSlack上でメンションできればよさそうです。 Slack側にいい感じのAPIがないか調べていると usergroups.users.update というAPIを発見しました。 usergroups.users.update method | Slack usergroupにグループのID、usersにユーザのIDの配列を渡すことでユーザーグループのユーザーを更新できるというものです。

この記事は https://qiita.com/sin_tanaka/items/64b4a48bcb6dac924380 にも紐付いています。 前置き Vue.jsにはVueインスタンス(コンポーネント)上のデータの変更を監視する watch というプロパティがあります。 さらに、 watch には immediate というオプションがあります。 watch は通常監視を始めて、データが変わった直後にコールバックが呼ばれますが、 immediate オプションを付与した watch は監視を始めた直後に一回コールバックが呼ばれます。 また、Vueにはインスタンスのライフサイクルに合わせて関数を実行する ライフサイクルフック という仕組みがあります。 そこで、 immediateオプション付きのwatchはライフサイクルにおけるどのタイミングで呼ばれるのか？ という疑問が湧いたので調べてみました。 画像は Vue インスタンス — Vue.js より引用 TL;DR watchのコードリーティングしてみた 実行タイミングは beforeCreate と created のあいだ ドキュメントには記載無さそう?現状のコードではこのタイミングってぐらいなはず ひとまず実行してみる 以下のコードで試してみたところ、immediate 付きの watch は beforeCreate と created の間に実行されました。 https://codepen.io/sin-tanaka/pen/ExaxrZx new Vue({ el: '#app', data: function() { return { helloWorld: 'HelloWorld' }; }, beforeCreate: function() { console.log('call beforeCreate'); }, created: function() { console.

2019-11-11時点で知ってることについてまとめておこうと思います。 前提 状況に応じて使い分けましょう 2/3系の最新、ぐらいの大きなくくりでも問題ない人 2.6環境を用意しなければいけないとき😔 Win環境でデータ解析した人で仮想環境とか考えなくてもいいのであれば全部入りのanacondaでもいいかもしれない 標準でPythonが入っているLinux環境(Mac含む)では推奨しない (仮想環境を使いこなせばanacondaのような環境作るは簡単) 良質な仮想環境構築記事を見分けられるようになりましょう お前を信じる仮想環境を信じましょう 最初にまとめ さまざまな仮想環境ツールがありますが、基本的には、 PATHに仮想環境作成時のpythonのsymlink or 実体を追加する sys.pathにsite-packagesを追加する を実現するためのツールなので必要に応じて使い分けましょう。 その他にも、 pythonのバージョン管理も内包 (pip以外の)pythonのパッケージ管理も内包 があるので必要に応じて使い分けましょう。 筆者は以下を必要に応じて使い分けてるので、いずれにせよ pyenv はあると楽かも pyenv + venv pyenv-virtualenv pyenv + pipenv venv 公式の提供するモジュールです。3.3からデフォルトで使えます。 venv --- 仮想環境の作成 — Python 3.8.0 ドキュメント ※ 2.7等には入ってません 仮想環境を有効化する とは venvでの仮想環境構築を通しておおまかな仮想環境有効化の動きを追ってみます。 $ python -V # Python 2.7.10 $ python3 -V # Python 3.6.8 $ pwd /Users/yourusername/foobar # python3 -m venv /path/to/new $ python3 -m venv .

ありがたいことに、昨年のPyCon JP 2018に続き、今年もCfPが採択されたので登壇 & 参加してきました。 スライド: https://speakerdeck.com/sin_tanaka_21/pyconjp-2019 配信: https://youtu.be/lCQWLAJf6xQ CfPや、当日の意識したこと等、メモ書き程度に残しておきます CfPについて 昨年は割と小賢しいタイトルをつけたなぁと自負していて、「実践入門」って一体なんだよって感じではあったので今年はシンプルに、「やりたいこと」と「PyCon自体のテーマ」をかけ合わせる感じにしました。 PyCon JP 2018のスライド: https://speakerdeck.com/sin_tanaka_21/pyconjp-2018 YouTube: https://youtu.be/zgTP_4-XEpw 決まったタイトルが Pythonでライブをしよう!FoxDotを使った新時代のPython活用法 でした。 まぁ、「新時代」と謳いつつも、 FoxDot やライブコーディング自体は随分前から存在しているので微妙だなと思わんではないのですが、「PyConの場でライブコーディングの実演したら新時代感あるやろ！」と思って応募しました。 内容の検討 CfP出した段階で草案は考えていたのですが、内容を詰めたのは採択が決まってからです。昨年は7月の半ばぐらいでしたが、今年は6月には採択速報が出ていたため、準備期間が長くてありがたかったです。 考えた結果、ライブコーディングについて説明するのだから、やはりデモは力入れたいというのと、私自身がが知識欲満たせるプレゼンが好きという理由で特殊メソッドのオーバーロードの解説をすることにしました。 あとは、当初メディア・アートとの関連も少し話す予定でしたが、 自分が詳しくないので付け焼き刃 Pythonとの関わりが薄い の理由で話さないことにしました。 当日のデモ FoxDot だと3連5連のハイハット作るのが楽だし、トラップ流行ってるしそれっぽいBPM/ビートでいくかーとか、電子音に合いそうだし小室っぽいコード進行(GetWild風)にするかーとか、全部で5案ぐらい考えたんですが、最終的には、「変わったことはしないで、すごい風に魅せる」を念頭において、 カノン進行 一般的な House/Techno 辺りのBPM FoxDot のbellが結構いい音 & カノン進行に合うので主軸に置く メソッドチェーンで音を重ねる 転調で盛り上がりを作る 徐々に音数を増やす/減らす なデモに仕上げました。 あとは事前に用意したコードを徐々にコメントアウト解除する方式でやれば本番も大丈夫かな！ …と思ったのですが、むくむくと欲が出てきて、 「本当のライブコーディングは事前に用意したコードをコメントアウトしておくのか…？」 「その場でコーディングしてくのが本物のライブコーディング&カッコいいのでは…？」 と思い立ち、PyCon前の土曜日にデモの案ができあがって、そこからはひたすら流れの暗記と練習をしました。 結果、本番では無事成功し、やはりコメントアウト方式よりも説得力が出た気がしています。相当アドレナリン出ました。 後日同僚から「カンペあったの？」と聞かれたのですがカンペは用意できませんでした。 ライブ性のあるものに対し、カンペを用意しないのはプレゼンとしてはバッドプラクティスかもですが、今回はギリギリまでデモを詰めていたためカンペを用意する余裕がなかったのと、「カンペを見ながらやる」というのも実はそこそこ練習が必要、の考えのもと用意しませんでした。 その他 今年からリアルタイムで配信されており、休憩時間にスマホで過去の配信を見ることができたので、かなり体験として良かったです。 良くも悪くも来年現地行くか迷うぐらい。。 今年は以下の辺りの発表を見ました。まだ全然観きれてない。。 メディアが運用すべき持続可能なVTuberをつくる技術(加藤皓也/Hiroya Kato) - YouTube 知ろう！使おう！HDF5ファイル！(thinkAmi) - YouTube 基調講演_Pythonで切り開く新しい農業(小池 誠) - YouTube Pythonで始めてみよう関数型プログラミング(寺嶋 哲/Terajima Satoshi) - YouTube Doujin-activity with Ren’Py(Daisuke Saito) - YouTube Djangoで実践ドメイン駆動設計による実装(大島和輝) - YouTube Pythonと便利ガジェット、サービス、ツールを使ってセンシング〜見る化してみよう(知野 雄二/Yuji Chino) - YouTube PythonとAutoML(芝田 将) - YouTube PythonとGoogle Optimization Toolsの最適化ライブラリで、「人と人の相性を考慮したシフトスケジューラ」を作ってみた。(鈴木庸氏) - YouTube 個人的には発表を受けて Ren'py について調べていたら近年の超名作 Doki Doki Literature Club!

CUI vs GUI 「別にどっちつかってもgitの難しさは変わらないのでCUI使ったほうがよくない？」が私の意見です。 なぜなら、branch, push, pull, conflict, rebaseのあたりの概念理解のinterfaceに依らないからです。 変わるのはコマンド叩くかボタン押すかだけです。 じゃあなぜCUIを進めるのか 概念理解の速度が変わらないならGUIだっていいじゃないかと思うかもしれません。 CUIを進める理由は2つです 問題が発生したとき、原因の切り分けが難しい GUIクライアント特有のメタコマンドとgitのコマンドが紐付いていない場合がある 原因の切り分け？ 例えば、GUI上でbranchをpushをしてエラーが発生した場合、原因は何でしょうか？ GUI上で設定が漏れている? 単純にremoteに今のcommitよりも進んだbranchが既にpush済なのかも? CUI上でエラーが発生した場合、疑う箇所はgitのエラーだけです。GUI特有の問題かも？という懸念を捨てられます。 またGUI特有の問題は以下の理由により検索性が高くないです。 GUI特有のメタコマンド？ revert という単語の意味は もとに戻す という意味です。 (これは一部想像も交じるし、そんなGUIクライアントは無いと思いますが、)もしもGUI上に revert stage というボタンがあった場合、「現在のstageにある変更をHEADと同一にする」という意味かもしれません( git reset . && git checkout . に相当) そして、gitには revert というコマンドがありますが、これは「あるcommitの打ち消しのcommitを作成する」というコマンドです。 GUI上でやっていた revert stage と git revert パッと見は似ていますが、動作はまるで違います。 このように、GUIではボタンにかかれている動作が、gitのコマンドそのものになっていない場合があります。 GUIでラップされてしまったボタンを覚えるよりも、CUIでgitのコマンドを覚えるほうがのちのち役に立ちますし、検索性も高いです。 結論 裏側でどんなコマンド走ってるのか、そのコマンドの意味を理解できている、調べればわかる人はGUIでもいいと思います。 最初に言ったとおりgitの難しさはCUIだろうがGUIだろうが変わらないので、それならgitそのものを学べるCUIがオススメという話でした。

SlackのInteractiveComponent Making messages interactive | Slack SlackBotでもInteractiveComponent自体を投稿することはできるが(単にattachmentsを付与すれば良い)、アクションのリダイレクト先を指定することができないのでSlackAppを作成する必要がある ※: SlackBotとSlackAppは別物 想定仕様 EventAPIとInteractiveComponentのリダイレクト先に指定するサーバはAPI Gateway + Lambdaを使う Flaskライクに書いたAPIをAPI Gateway + Lambda etc..へデプロイできるフレームワークChaliceを使う SlackAppにメンションを飛ばすとInteractiveComponentを返す EventSubscribe(EventAPI) で app_mention イベントをlistenする RedirectURLは foo-bar-domain/api を想定 InteractiveComponentにはYes/Noボタンを付ける どちらかのボタンが押されたとき対応する文章を返す RedirectURLは foo-bar-domain/api/reaction とする SlackAppの作成 Slack API | Slack でStartBuildingボタンを押すとアプリを作成することができます つづけて、 - BotUserの作成 - InteractiveComponentsの有効化 - Permissionの設定 - chat:write:bot - bot BotUser作成したときに付与される をしておきます。最後にInstallAppすることでWorkspaceへAppをインストールします RedirectURLはデプロイ後、URLが決定したら設定します ChaliceでEventAPI、InteractiveComponentのRedirectを受けるAPIを作る chaliceをインストールしてプロジェクトを作成します AWS Chalice — Python Serverless Microframework for AWS 1.8.0 documentation