コーディング面接対策サイトCodilityの練習問題を解いてみた(CyclicRotation)
問題
与えられた配列aの各要素をk回,右に動かす(このとき、最後尾の要素は先頭に持ってくる)。
回答
def solution(a, k)
b = []
for current_index in 0..(a.length-1)
new_index = (current_index + k) % a.length
b[new_index] = a[current_index]
end
b
end
p solution([3,8,9,7,6], 3) == [9, 7, 6, 3, 8]
p solution([3,8,9,7,6], 0) == [3, 8, 9, 7, 6]
p solution([3,8,9,7,6], 5) == [3, 8, 9, 7, 6]
感想
パフォーマンスは気にしなくて良いらしい。 kが配列の要素数よりも大きい場合を考慮する必要がある。
コーディング面接対策サイトCodilityの練習問題を解いてみた(BinaryGap)
問題
nを二進数にして、1に囲まれた0の数を数える
回答
def solution(n)
s = n.to_s(2)
zeroes = s.split('1')
zeroes.pop if n % 2 == 0
return 0 if zeroes.empty?
zeroes.map{ |z| z.length }.max
end
# debug
puts solution(20) == 1
puts solution(6) == 0
puts solution(1041) == 5
puts solution(255) == 0
puts solution(529) == 4
puts solution(66666) == 5
puts solution(1024) == 0
puts solution(9) == 2
puts solution(11) == 1
感想
この書き方、知らなかった。
9.to_s(2) #=> "1001"
はてなさんの「エンジニア実績システム」をベースにして、2016年の目標をたててみた
もはや4月も終わろうとしていますが、まとまった時間がとれるゴールデンウィークを前に意識が高くなっています。 そんな今だからこそ、業務外での目標をリストアップしてみます。
2016年の目標
10年後も食べていけるエンジニアになる。(こちらの記事を読んで、色々と危機感を感じたので、、、)
注力領域
以下の4つ。
効率的なモバイルプログラミングの手法を学ぶ
- Swift熱も高まってるし
- 自動化できない領域を模索する
- テストの自動化やストーリーボードの分割、ライブラリのアップデートの効率化など、保守運用コストを下げる手法を模索する
フロントエンドへのキャッチアップ
- デプロイとかトラブルシュートを考えると、フロントエンドエンジニアにお任せではすまない
- そもそも分業できるほどエンジニアいないw
機械学習の基礎を学ぶ
- インフラやライブラリも充実してきた
- ちょっとずつ活用イメージが湧き始めている
- 久しぶりに数学も勉強したい
アウトプットを増やす(OSSへの貢献や登壇など)
- トップエンジニアのソースを読む機会を増やしたい
- GitHubを派手にしたい
- 業務だけだと選択肢が狭まりそうだし
- まだ数が少ないので、スピーカーに選ばれる難易度やPull Requestの内容はここでは問わない
TODO
アウトプットをゴールにしないとモチベーションが続かなそうなので、具体的なアウトプットを残しながら勉強することを考えています。はてなさんの実績解除システムを参考にさせて頂きました。
実績を解除してエンジニアスコアを上げろ！はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog
効率的なモバイルプログラミングの手法を学ぶ
- [ ] Ray Wenderlich | Tutorials for iPhone / iOS Developers and Gamersを読んでサンプルプログラムを作る
- [ ] こないだ参加したAKIBA.swift 第１回 - connpassのまとめブログを書く
フロントエンドへのキャッチアップ
毎月Web+DB PRESSのフロントエンド先遣隊を読んで、読後メモを書く
- [ ] vol.92
- [ ] vol.93
機械学習の基礎を学ぶ
入門書を読んで読後メモを書く
- [ ] Amazon.co.jp： 線形代数 ベクトルと固有値 (大学入門ドリル): 丸井洋子: 本
- [ ] 図解・ベイズ統計「超」入門 あいまいなデータから未来を予測する技術 (サイエンス・アイ新書) : 涌井 貞美 : 本 : Amazon
- [ ] マンガでわかる統計学 素朴な疑問からゆる~く解説 (サイエンス・アイ新書) | 大上 丈彦, メダカカレッジ, 森皆 ねじ子 | 本 | Amazon.co.jp
- [ ] ITエンジニアのための機械学習理論入門 : 中井 悦司 : 本 : Amazon
- [ ] 電子工作入門以前
- [ ] 数学ガールの秘密ノート/微分を追いかけて | 結城 浩 | 本 | Amazon.co.jp
ディープラーニング使って何か作る
- [ ] hogehoge
アウトプットを増やす(OSSへの貢献や登壇、Qiita/Stack Overflowでの投稿など)
登壇する
OSSへPull Requestを送る
- [x] fix bug that InfoHub does not show post on iOS9 by tjnet · Pull Request #49 · systers/malaria-app-ios
- [x] Fix warnings on Xcode7.3 by tjnet · Pull Request #205 · HighBay/PageMenu
- [x] add docs for statistics API by tjnet · Pull Request #872 · errbit/errbit
- [x] add basic tests by tjnet · Pull Request #6 · errbit/errbit_github_plugin
自分で何かOSSを作る
- [ ] hogehoge
その他
やせる
- 夕食の炭水化物を制限する(おでんや牛丼ライトで代替する)
お金の管理をしっかりする
- ライフイベントに備えて、貯める
全部できるかな、、、頑張ろう。
"Amazon.co.jp： Amazon Web Services パターン別構築・運用ガイド " Chapter1を読んだ
Amazon.co.jp： Amazon Web Services パターン別構築・運用ガイド: NRIネットコム株式会社, 佐々木 拓郎, 林 晋一郎, 小西 秀和, 佐藤 瞬: 本のChapter1を読んだメモ。
概要
本業以外のプロジェクトでインフラ構築も担当することとなり、本書を購入しました。 図解が豊富で、記述レベルが細かすぎず、要点をつかみやすい気がしました。 日進月歩で変わっていく領域なので、参考リンクが随所にあるのも嬉しい。
疑問
この章で気になったのは、Elastic Beanstalkのとこ。 フルセットでELBとか用意してくれるの、すごいじゃん！ 良さそうに見えるが、あんまり活用している人が周りにいないのは何故だろう。。？
と思ったら、このあたりに詳しく書いてあった。
のp.55辺りに詳しく書いてある。 Beanstalkは、アプリケーションコンテナを選択するだけで、フルセットの環境一式が準備できるが、Cloud formationと比較してフレキシブルではない、とある。
触ってみないとわからないけども、Elastic Beanstalkではミドルウェア導入済みのEC2インスタンスを使用するそうなので、技術選定(APサーバとか)の自由度は低くなるんじゃないかな。。。PaaSライクなものかな?
アプリサーバー対決 パート1：主なRubyアプリケーションサーバーの機能比較 [和訳] - Engine Yard Blog
Cloud formationの利点は、テンプレートが再利用できること。ステージングと本番で同一構成のシステムを複製したり、インフラ構成自体をバージョン管理したりすることも容易になる。
まとめ
導入の容易さ
Elastic Beanstalk > Cloud formation
自由度
Elastic Beanstalk < Cloud formation
多分どこよりも早い ドッツサミット2015 レポート
dots.summit 2015とは?
フリークアウトのおしゃれオフィスでトップエンジニアによる講演を聞きながら、エンジニア同士の交流をはかる素晴らしいイベント。運営はインテリジェンスさんですね。それにしてもバスケットゴールやらビリヤード台やらがあって、遊び心いっぱいのオフィスでした。
『短納期＆少人数でも実現できるCI』
株式会社LiB 米山諒氏
女性向け転職サイト、
キャリア女性のための会員制転職サービス | LiBz CAREER（リブズキャリア）を運営しているLiB 米山さんのお話です。
なんだかんだスピード優先されて、わやくちゃになるこのフェーズでも、CIやコードレビューを導入しているスタートアップのお話。すげーな。米山さん、いつ寝てるんだろう。確かまだ設立1年経ってないはず。。。LiBのエンジニアカルチャーを定義したり、コードレビューを行う文化だったり、エンジニアを大切にする風土が伝わってくるお話でした。
『SPEEDA/NewsPicksを支える技術の選定手法』
株式会社ユーザベース 竹内秀行氏
技術を選定する際に大切にしているポイント、というお話でした。
「ただそれを作りたいから作る」「ただ自分がその言語を使いたいから使う」という公私混同に陥ってはいけない。
「その技術はユーザに価値を届けているのか」、忘れがちな視点ではあるので、改めて肝に銘じたいと思います。
『何故scalaを選んだのか？ 〜 アドテクスタジオの場合 〜』
株式会社サイバーエージェント 神田勝規氏
20150207 何故scalaを選んだのか
スライドは、まだ公開されていないようで、残念。。。
scalaを採用した理由は、こちらにも詳しく書かれていますね。
http://careerlaboratory.jp/archives/742
Tech Talk ～ サイバーエージェントアドテクスタジオがScala言語を選んだ理由 | キャリア・ラボラトリー
Javaだと冗長になりすぎる所をシンプルに記述できたり、並列分散処理に優れていたり、といった点が好まれているようです。
トップダウンで導入した、というよりは社内勉強会を開いたり、新しい技術の習得に熱心な風土は素晴らしいですね。
『変わったUIを持つアプリ”へやくる！”』
株式会社ネクスト 大坪五郎氏
お題のアプリはこちらですね。FacebookのPaperを参考にしたというアプリです。
今度、ネクストさんの勉強会にもお邪魔したい!
大規模並列検索サービスGoogle BigQueryについて』
Google Inc. 佐藤一憲氏
ビジネスサイドからの
・ ディレクターの人でも解析、分析したい
・ブラウザから色々やりたい
といった要求にこたえやすいかもしれません。
Google BigQueryについては、こちらのスライドで丁寧に説明されています。
Google BigQueryを使ってみた！
Treasure Data と OSS
『ビックデータ時代のビジュアライゼーション』
Tableau Japan 株式会社 飯塚桂子氏
『会員数180万人のマッチングサービスpairsの急成長を支える技術基盤』
『次世代のリアルマーケティングプラットフォームに挑戦するラクスルの開発体制について』
『ベストアプリW受賞を支える開発手法』
株式会社VASILY 今村雅幸氏
CTO対談！！
～ CEOが迫る！ヒットサービスを生み出す技術組織の作り方 ～
・モデレーター ランサーズ株式会社 代表取締役社長 秋好陽介氏
・株式会社VASILY 取締役CTO 今村雅幸氏
・株式会社ユーザベース 執行役員 竹内秀行氏
Q.CTOって何してるの？
A.広報とか技術戦略とか採用とか雑用とか。
コード書く時間は、やっぱり減った。
Q.成長するエンジニアとは?
A.ハングリーで、5分に1回くらい、サービスの成長につながる事を考えてるような人(僕は無理ですけどw)。組織に深くコミットして、終電とかになりながらも、でもインプットの時間もきちっと取れているような人。
Q.ダメなエンジニアを雇ってしまったら
A.今、思い返しても、そんな人いない。モチベーションの低い人を雇ってしまうと、全体としてレベルが下がる。入り口(採用)でどこまで慎重になれるか。どこまで本気度高くやれるかが大事です。VASILYではエンジニア10人呼んで、10対1で面接する事もあります。
そろそろ「パーフェクト Ruby on Rails」読んで本気出す ⊂('ω'⊂ )))Σ≡=─༄༅༄༅༄༅༄༅༄༅
購入の経緯
とりあえず、日々の仕事については、ある程度こなせる様になって来ました。
ただ、Raisのベストプラクティスやイケてるスタートアップの開発フローと比較すると、色々と思うところがあり、Railsの世界観を学ぶため、本書を購入するに至りました。
Amazon.co.jp： パーフェクト Ruby on Rails: すがわら まさのり, 前島 真一, 近藤 宇智朗, 橋立 友宏: 本
こんな人にオススメ
- 現職でRailsを使用している
- Railsで簡単なTODOアプリとかなら、大体作れる
- Modelが肥大化してきた時の対処法/設計指針を学びたい
- TDDやってみたい
- おすすめのgemとか教えてほしい
- 環境構築 => 開発 => テスト => 本番環境構築 => デプロイという一連の工程をモダンな環境で行いたい
Rails初心者の方が、1冊めとして手に取る本ではない気がします。
Railsは全く初めて、という方であれば、こちらのチュートリアルを先にこなした方が良さそうです。
Ruby on Rails チュートリアル：実例を使って Rails を学ぼう
この分量、クオリティで無料ってすごい。
サンプルコード
こちらに、公開してくださっています。書籍のサポートページもあるようなので、そちらも併せてご参照下さい。
パーフェクト Ruby on Rails のサンプルアプリケーションを Github 上で公開しました - willnet.in
とりあえず、今の自分に必要そうな所だけ、丁寧に読みました。
第1章 Ruby on Railsの概要
環境構築方法や、Railsの設計思想に関するお話。
ActiveRecordの設計思想や、RESTのお話は、復習しておきたいですね。
第2章 Ruby on RailsとMVC
MVCに関する記述は、意外と薄め。前提としてMVCって何なの?という知識は事前に必要な気がします。
REST、ルーティングについても、ここで復習できます。
StrongParametersについては、Rails4で導入されたものなので、現場の状況によっては知らない人もいるのかな?
variantsによるテンプレートの切り替え、特定のレイアウトを適用する方法は、次のお仕事でも使いそう。
第3章 アセット
必要な時に読み返せば済む領域だと考えているため、スキップしました。
第4章 Railsのロードパスとレイヤーの定義方法
MVCにあてはまらないモジュールをどのように管理するのか、その考え方について述べています。ロードパスとかもここで復習しました。MVCにあてはまらないレイヤーの設計指針については、第9章で更に掘り下げていきます。
第5章 開発を効率化するgem
Better Errorsとpryはさっそく使ってみたい。
第7章 Railsアプリケーションのテスト
駆け足ではありますが、TDD、静的解析、CIまで一連の流れを解説してくれています。使用しているツールやサービスも実務でお目にかかる可能性の高いものだと思います。
本書とは直接、関係はありませんが、Rspec入門としては、こちらの記事がおすすめです。
第8章 Railsのインフラと運用
とてもコンパクトにまとまっています。が、インフラは扱う領域が幅広いので、個別のツールについては、別途掘り下げる時間が必要です。DevOpsやスタートアップに興味のある方は、ここにあるキーワードはおさえておくと良さそう。
第9章 より実践的なモデルの使い方
なぜ、バリデーションとコールバックをクラスに分離するのか、その必要性について納得いく形で答えてくれます。
サービスクラスの使いどころと、使用する際の注意点についても触れています。
業務で悩むのも、まさにこの「より実践的なモデルの使い方」だったりするので、今の自分にはぴったりだと思っています。
それなりに難しく、読み応えのある部分なので、何度も読み返したいです。
まとめ
Railsエンジニアの2冊めとしておすすめ。みんなが勧めるのもよくわかる。
第9章は読み返したい。
Special Thanks!
【本場でも通じるふりかえりテクニック】アンチパターンとその対策
本場ってどこやねん。。。
"改善MTG(ふりかえり)"あるある
プロジェクトの節目に行うふりかえりMTG、改善MTG。
これって、盛り上がらなかったり、自然消滅してしまう事も多いですね。その原因となるアンチパターンや対策について考えてみました。
上からメセニストとしてではなく、自戒を込めて書いています。
ふりかえる必要性を感じているメンバーがいない
本当に、ふりかえる必要性を感じているメンバーがいないのであれば、そのチームは完全無欠で理想的な状態にあるのかもしれません。ただ、そんなチームあるのかな。。。
ふりかえった事がなくてキョドる
いきなり"ふりかえりMTGやりましょう"と言われたら、ほとんどの人がどうしていいかわからない。
ただ、ちゃんと探せば、やり方まとめてくれてる人がいるんですね。勉強しようっと。
下のリンクは、めっちゃわかりやすいです。
ふりかえり会のススメ(進捗会議編)
http://objectclub.jp/download/files/pf/RetrospectiveMeetingScenario.pdf
一度のみ振り返り
こういうものは、一度で効果が出る方がむしろ稀なので、繰り返さないと駄目ですね。そもそも一度だけ振り返っても効果が計測できないですし。
自戒を込めて書きました。
効果がない(改善案が生かされない、実行に移されない)
プロジェクトの最後にふりかえりを行ってしまうと、こうなりがちですね。
この手のMTGは、プロジェクトの途中、まさに問題に直面している過程で定期的に行う方が良さそうです。結果をどう生かすのか、まずメンバー間で共有してからMTGを始めなければいけないのだと、お仕事を通じて学びました。
どうやって進めればいいのかわからない
何となく改善MTGを導入すると、一人一人が反省点を口にして、何となく終わってしまう。未来につながるお話にならない。そこでKPT。「型」を導入する事で、進め方をまず共有する。
批判の応酬、責任のなすり付け合いになってしまった
これ、僕もやってしまった事があります。。。そもそも、うまくいっていないチームだと、こういう場を設けた時に、一気に不満が噴出する事があります。これは解決が難しそうですが。。。
まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。
あとは、"**のせい"という論調になりかけた時に、「自分ならどうする?」「これからはどうする?」と自責で、未来志向で考えられるように声がけを行う事でしょうか。不思議なもので、第三者がこういった声がけを行うだけで、ほとんどの発言者は無意識のうちに自責で考え、未来に向けた思考を行えるようになるものです。僕自身も、何度もこの言葉に救われた気がします。
言葉の持つ力を甘く見てはいけないですね。
また、不満を抱えているメンバーには、MTGが始まる前に個別にお話をして、ガス抜きをする事も重要かもしれません。
Keep飛ばし
いきなり"Problem(問題)"から言及して、みんなどよーんとする。お通夜MTGの幕開け。
対策は、まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。大事な事なので、２度書きました。
ほとんどのメンバーが効果を感じていない or 楽しくない
では、なぜ、メンバーが効果を感じていないのか。効果が目に見えないから、もしくはフィードバックを受け取るまでのサイクルが長過ぎるからではないでしょうか。
効果が計測できて、フィードバックまでのサイクルを短くする事ができれば、やっているうちに楽しくなってくるはず。では、どうすれば可視化できるのか、フィードバックを短くできるのか。
考えられる解決策としては、このあたりでしょうか。
- 可視化できるものを目標にする。
- フィードバックサイクルが長過ぎるものは、短く分割して、短期間にフィードバックを得られるようにする。
なげっぱなし、言いっぱなしのTry
誰が何時、何時までに、何をどうする。などより具体的で明確な内容に落とし込む。場合によっては、実行されたかどうかの確認方法まで盛り込む。
。。。。というより、こういう風に具体的に落とし込めないものは諦めて、本当に出来そうなものだけ、3つだけTryする、というのが良いかも。
短期間で、そんなに5個も10個もTryしながら、改善活動できない気がする。
【参考】
