上手な教え方の教科書をよんでいる
- 作者: 向後千春
- 出版社/メーカー: 技術評論社
- 発売日: 2015/08/05
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
会社の人から借りて一通りザーッっと読んだのでメモっておく。あとでうちの部として購入してもらおう
どのような本なのか?
「教えること」を教えるための本。インストラクショナルデザイン(ID)とは?というところから始まり、IDを構成している要素でどのようにしたら人に教えることの主役である教えられる側がうまく吸収してくれるのかという仕組みが書いてある。
感想
教育という分野で仕事をしてるので時々理念とか理想という単語をよく聞くようになったが、IDは時代時代で変わる理念・理想などを持っておらず「正しい」という概念を持っておらず、効果的かどうかが基準というところに非常に好感が持てた。これは仕事内での評価で「あの人は〜」とかの恣意的な流れではなく評価(Evaluate)するというところにもつながっていくはず。
この本仕事をする先輩が後輩に教える中でうまく行かず、先輩の上司からIDを教えてもらうという筋書きなので、同じようなシチュエーションで悩んでいる人には最適な本だと思う。なので、部下ができた人や、組織を作る(特に新卒)レイヤーの人には読んでおいて損はないと思う。
自分はエンジニアで特に後輩とかもいないので、この本で言っていることで使える部分をどのようにプロジェクトマネジメントやサービスに取り込むかというところにフォーカスを当てていた。今までは経験や口伝、上司の背中を見てやってきた部分がほとんどでその背景をわからないまま表層だけを使っていた部分があったので、そこが知識体系として背景としてまとまっていたので、自分のやり方の方向性の確認もできたと思う。
余談:メモを取りたいから1節ずつ読んでエディタにかくという方式を取っていたがこれは思考がとまるのでダメだった。こういうときは紙が良さそうな気がするので次はそちらの方法を取ってみる
FuelPHPのModelにはちゃんとデータ型を書こう
===
での演算子結果がなぜかtrueにならなくて調べてたらこれが原因だった
data_typeを設定していない
<?php class Model_User { protected static $_table_name = 'users'; protected static $_properties = [ 'id', 'name' ]; }
php oil c の結果
>>> var_dump(Model_User::find(1)->id) string(1) "1"
data_typeを設定
<?php class Model_User { protected static $_table_name = 'users'; protected static $_properties = [ 'id' => ['data_type' => 'int'], 'name' ]; }
php oil c の結果
>>> var_dump(Model_User::find(1)->id) int(1)
Sidekiq
Ruby界隈はエコシステムがしっかりしてるなぁ
- Redisが必要になる
- クライアント → Redis ← Workerが処理
- workerを増やすことはできる
- workerが増えたときに同じジョブを実行することは?→Redisシングルスレッドなのでそこで担保
Redisが死んだときは?
- 定期的に再接続してるから復旧したら再接続するみたい
タスク中にworkerが死んだら?
- さすがにロストする
- タスク実行中にプロセスが死んだときはどうなる?(redisに残ってる?)
- redisに残っているというよりも、正常終了するときはredisにpushしてる
- タスク実行中に正常終了SIGTERM投げれば正常に終了して次にリトライが走る -> SIGHUPとかSIGQUITではリトライが走らない
- https://github.com/mperham/sidekiq/wiki/Signals をみると USR1 -> TERMをやったほうがよさそう
- USR1を実行すると新規workerの開始を停止する。実行中workerは継続 -> TERMで停止する
- 基本リトライが走る前提で処理を組むのは大前提
社内環境改善活動の話
この記事は Classi Advent Calendar 2016 - Qiita12日目の記事です。前日はhilotterによるエンジニア立ち居振舞い: 明日いなくなってもいいように仕事をする – hello-world.jp.netでした
www.wantedly.com この話を書こうと思ったのですが、既に結果は書かれてしまったのでそこに至るまでの経緯などを書きます
話の発端
現在Classi所属の社員は3人(他はベネッセ・ソフトバンク・ヒトメディアなどから参加してるメンバー)いるのですが、毎月1回副社長とランチをする会があります。その中でよいエンジニアを採用するにはどうしたらよいか?という話の中から出てきました。(ここでエンジニアとしてるのは3人共エンジニアであるため)
もちろん、会社の事業内容、雰囲気や技術で人を引きつけるということは基本的なところなのですが、それと同時に会社インフラも整備して社員を大切にしていることも重要という話をした記憶があります。
アンケートをとる
最初に3人でこういうものがほしい。というのをスプレッドシートに起こしました。椅子・本の定期購読・ウォーターサーバー・ディスプレイなどなど。これはエンジニアとしての主観だったのでそれと並行して、メンバー全員に対してGoogleフォームを使って金額が10万、20万と分けてアンケートを取りました。20万としてるのは深い理由はないのですが固定資産の都合上です。
その結果、ウォーターサーバー、無料コーヒー、お菓子などが上位に上がってきました。エンジニアからはバロンなどの高級椅子・キーボード・マウスなどが上がりやすく、他の職種からは本の購読・本棚などが上位に来てました。その結果以下のように決まりました。なおこれらはトライアルという形式を取っています。
選定・購入する
オフィスファミマ
こちらは副社長が決めてくださったので特に何もしなかったです。感謝。あと、スタバのポットサービス検討していたのですが、都度都度行くのが面倒だろうということで、オフィスファミマのカフェを頼んでます。両方共無料ではなくメンバー自身で購入してます。
ウォーターサーバー
当初はお店にあるようなショーケースにペットボトルを入れるという案もありましたが、コスト的なところを考えて最終的にはウォーターサーバーになりました。また、どこから購入するか最後まで探していました。結果、以下のような理由で 《公式》天然水ウォーターサーバーNo.1【コスモウォーター】の宅配水 にしました。
- 月額費用
- トライアルなので解約時に発生する金額を最小限にする
- 衛生面
- 自分たちで清掃するのは最小限にしたい
最初は消費量がわからなかったので水を12L✕2本頼んでいたのですがそれが2日半でなくなったので慌てて4本追加注文しました。この辺は水なので余裕持ってもよかったかもしれません。
椅子の購入
予算は30万と決めて、メンバーで実際に試し座りに行きました。その上で オフィス家具・中古オフィス家具通販のオフィスバスターズ から中古を購入しました。申し込んですぐに電話がかかってきてマジびっくりした...
運用・効果を計測する
オフィスファミマは毎週補充に来てくれるので特にやることはありませんが、カフェで使っているドリップマシンは毎朝掃除(といっても、キレイキレイで拭いてるだけ)してます。また、毎週月曜日に軽くウォーターサーバーの清掃も行ってます。この辺は最初から気づいた人がやると運用よりも最初は自分がやったほうが回ると考えているためです。5分〜15分ぐらいで終わるので朝にTwitterを見てる時間をこちらに回すだけです。
これらは月末にGoogleフォームでアンケートをとり次の改善に使っていく予定です。
今回は却下・保留にしたもの
以下のようなものは今回は却下・保留にしました。
- キーボードなどは個人の好みの差と値段が激しすぎる
- 本などは楽に申請するフローを決めないと承認する上長の負荷が上がる
公平性と区別
これはあくまでも私見なのですが、何を導入するという基準には「公平性」と「区別」が必要になると考えてます。
公平性というのは職種・契約形態に関わらず全員が平等に受けられるものを整備することです。例としては今回採択した3つとも公平性にあたると考えています。あとは通常のディスプレイなどもそうですね。弊社は椅子に座ってノートPCを使っている人が多いためこの辺を整備すると生産性が上がることは目に見えてます。これまで仕事で外部ディスプレイを使ったことがない人に対しては、どのぐらい効率が上がるのかイメージも湧かないでしょうから、とりあえず使ってみてくださいと言う形で半強制的に貸与してもよいかと思っています。
区別は職種によってある程度異なるものを整備する必要があるのではないかと考えています。例えば、デザイナーは通常のディスプレイではなく高解像度のディスプレイにするとか、マーケティングは外出が多いからWifiルータやデモ用のiPadを貸し出せるなどもあるかもしれません。現在はこのあたりはまだ手をつけれていないのですが直に整備が必要になる部分かと思います。
感想
これらは約1ヶ月〜1ヶ月半の話だったのですが、社内の環境を改善していくという目的に対してトップダウンとボトムアップがうまく働いた例かなと思います。上がお金やビル側などの複雑な調整をし、下が予算などの制約の中で持っている経験などから最適解を出せたのではないかなと思っています。環境改善は一時的なものではなく会社がある限りずっと続くものなので、メンバーのニーズや会社規模などに応じてこれからもみんなが働きやすい環境を作っていければと思います。
wantedly
こんな感じで会社を作っていくことに興味がある方は是非お願いします www.wantedly.com
明日は
kyottyyのコーポレートサイトをLinuxからS3+Lambdaにした話です
buildersconで知ったkuba-awsを触ってみた
この記事は Classi Advent Calendar 2016 - Qiita 7日目の記事です。前日はkitaharamikiyaによるFabric Beta によるテストアプリの配信 - Qiita でした。
12月3日に builderscon - Discover Something New に行ってきました。そこでkubernetesをAWS上で動かすという紹介をやっていたので、自分でも試しに触ってみました。と言ってもほとんどチュートリアルをやっただけです。事前にお断りしますがこれがClassiのサービスに入るわけではありません。ただこういう素振りは手を動かしてこそ身になります。
なおバージョンは0.9.1です。
完成図
チュートリアルを進めた結果ざっくりとこんな感じのものができました。
ローカル環境から kube-aws validate --s3-uri=<S3URL>
と実行すると、事前に作成したS3へ設定ファイルがアップされました。その後、 kube-aws up --s3-uri=<S3URL>
を実行するとCloudFormation経由で図に書いてあるRoute53へ登録を行ったり、VPC作成、ELBなどの設定が行われて、kubernetesを使う準備ができます。
それぞれを複数台,MultiAZになっているので、仮にどちらかのサーバがダウンしてもAutoScaleが働いて別サーバが立ち上がる構成になってます。実際のプロダクション環境の場合は多重障害を懸念するのと、サーバ負荷の関係でNodeサーバは3台以上立ち上げる構成にすると思います。実際にサンプルアプリを配置すると各NodeにそれぞれDockerがビルドされました。
この絵を手で書いてるときに思ったのがこちら。MongoDBと似てるとなるとお金かかりそうな気がする。
AWS上にkubernetesを作っていたらどこかでみた構成だなーとおもったらMongoDBに似てる気がした。masterがmongosで etcdがmongocでnodeがmongod
— Eiji Hachiya (@hachi_eiji) 2016年12月4日
普通にプロビジョニングをするのか、Dockerなどでインフラもアプリもまとめるのかはサービス次第なのですが自分はアプリケーションサーバなど頻繁に変わるものはDockerにしたいタイプです(Amazon LinuxのDocker Imageもできましたし)。可能な限りベンダーロックインは避けたいのでECSもなぁという気持ちはあります。
まだきちんと調べきれてない/触れていないところ
- 上の図では書いてますが、controllerとetcdの通信経路。(AZをまたいで通信してるのか?)
- 不要になったDocker Imageを廃棄する方法
明日は
未定らしいです。なければ frontrend 勉強会に行ってきた記事でも書きます
9月から教育サービスClassiで働いてます
この記事は Classi Advent Calendar 2016 - Qiita 5日目の記事です。
Classiにまつわる技術ネタを書きたかったのですが、入社以来ほとんどコードを書いておらず技術ネタがないので転職エントリー書きます。
なぜ教育だったのか?
積極的に次の仕事を考えていたわけではないのですが、定期的に自分のスキルを棚卸ししてて1年ぐらい前から自分のスキルはこのままでいいのかなと思い続けてました。幸いにして前職は同僚・給料・開発環境に恵まれていたのですが、今の上司に「遊びに来ませんか?」というメッセージをもらって「お、なんか有名な @sasata299 からだ」という軽い気持ちで話を聞きに行った覚えがあります。
最初は今の上司である佐々木がインタビューを受けてた記事を読んで(リンク忘れた)是非一緒に働いてみたいという気持ちだけだったのですが、それに加えて、経済を回すという+世の中に還元できることをしてみたいなぁというのがありました。
教育は大抵の人が通るところでそういうところで働けると言うのは社会的意義があるのかなと思ってます。自分の甥や姪が何年かすると自分が作ったサービスを使っているかもしれないことを想像すると楽しみです。先生や生徒がClassiを使って少しでも楽になりました、成績があがってやりたいことができるようになりましたと言ってもらえるサービスを作って行きたいです。個人的にはどうしても教育を受けれない人とかにも同じものを提供できたら最高ですね。
技術的な話
弊社ではインフラはAWS,DBはMySQL(Aurora)を使ってますが、マイクロサービスで構成されていることもあり、サーバサイドはRails, PHP, フロントはAngular,React, Backboneと複数言語で構成されています。これは過去の経緯からそうなっているので、正直現時点ではあまりポジティブな理由ではありません。この辺は常にどうしようか?と言うのは議論されているところです。そのうちサーバサイドはRailsに寄せるのではないかなと思っています。(フロントはReact or Angular2 or Vue.js?)
これまでMySQL,Java,プライベートクラウド(AWSも少し使っていた)がほとんどだったので、ぜんぜん違う技術を使ってみたいというのも転職理由の1つです。また、経験や年齢的にマネジメント中心になっていたので実際に手を動かしてコード書いてたり、アーキテクチャ考えたりしてる方が好きなのでそちらもやりたいのです。
前職では人数も潤沢に揃っておりスペシャリストもたくさんいたので、他の領域に手を出しにくかった部分がありました。また自分の中ではエンジニアはインフラもサーバもフロントもできないとダメだと思っているので、まだ始まって2年のサービスでエンジニアも不足しているチームでは手を出しやすそうな雰囲気ではあります。また、いままではサーバサイドは1年弱ぐらいNode.js書いたけどほぼJavaだけでした。今後の将来を考えたときに、1つの言語で食べていくと言うのは厳しいと思ってました。
自分は不器用な部類の人間だと思うのですが、不器用だからこそたくさんの事をできないと生きていけないと思っています。
昔は不器用だからこそ1つのものに専念したいと思ってたのですが、確か高校時代の進路相談で先生から不器用だから逆にたくさんのことできないとダメだぞと言われたことがありました。その意味がここ数年でわかってきた気がします。ITが求められること、できることが増えたからこれだけ知っていればサービスは作れない。自分がその道だけで食べていけるスペシャリストではないので、数年後どうなっているかもわからない。だからこそ幅を広げることが必要かなと思います。
あとは色々なことを知ると考え方の応用が効いてきます。Node.jsを勉強してたときに、その考え方とか構文とかがJava8の書き方やRubyの書き方にもすんなり入れました。もちろん最低限の物を吸収しなければいけないし、幅を広げると言っても取捨選択は必要なので、今のところは以下のように絞ってます。(と、書いてて思ったのですが、大して幅が広くないw)
- サーバ: Ruby, Rails, PHP:軽く見る
- フロントエンド: React, JavaScript, CSS設計やコンポーネント、Angular,Vue.js:軽く見る(フロントエンドは正直カオスすぎて自分の中では一番ふわふわしてる)
- インフラ・クラウド: AWS(AWSは中のサービスが多いので絞ってる)、Docker、セキュリティ、GCP:軽く見る、Azure:捨ててる
- マネジメント: 一応見ておく
- 人工知能・AI:流し見程度
- ネイティブアプリ:捨ててる
- IoT:捨ててる
が、今年はプロダクションレベルのコードをほとんど書けてないので来年こそ書きたいです(切実)
wantedly
技術・組織的な課題は色々ありますが、教育サービスを作っていきたいと思ってる方はぜひ。 www.wantedly.com
明日は
kitaharamikiya による Fablic Beta によるテストアプリ配信です
buildersconに行ってきた感想
駆け足で感想書く。
tl;dr
- 人口密度高くて盛り上がっている感がすごかった
- 生mattnさん見たかった
- 多様性がものすごかったので次回は全く違いものばかり聞いても面白いかもしれない
- 土曜にイベントがあると日曜日ガッツリ触れるからいい