技術書の写経を始めたのでやり方を書いておく
技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ
— Takuto Wada (@t_wada) 2010年2月12日
入社前課題として技術書の写経を始めました。 基本的にはこれをマネしています。 しかし、実際にやってみて僕がやり方を変えたところがありますので書いておきます。
1.ローカルで使える SCM を用意
これは普通にgitとGithubでやっています。
2.「ほんたった」などで対象の本を固定 。しかし、電子書籍とか画面で見られるものの方が便利。
僕はこれを使っています。Amazonで安かったので。ページをめくりにくいのと場所を取るので他のものを現在探し中。 物理本はどうしても、PCの横とかに置くことになるんで首や目を移動するたびに疲れる気がします。
- 出版社/メーカー: actto corp.
- メディア: エレクトロニクス
- この商品を含むブログ (3件) を見る
3.ひたすらサンプルコードを写して実行
基本的にはほとんど実行しています。完璧に分かっているものは、飛ばしています。 プロを目指す人のためのRuby入門をやっているのですが、エディタはやはりRubyMineがいいですね。 補完機能が充実しています。RubyMine上のターミナルから日本語を入力するときに、文字が正しく表示されないのが気になる。
4.実行するたびにコミット(コミットログにページ番号を含める)
大体実行するたびにコミットしていますが、いくつかまとめてコミットするときもあります。 疑問点やなにか書きたいことがあったときにコミットする感じです。 git addやgit commitを何度も打つことになるので、エイリアスを設定しておきましょう。
5.疑問点があったらコミットログや本に書き込む
今は物理本を写経していますが、基本コミットメッセージに書きます。
6.章ごとにディレクトリを分ける
第1章だったら、Section1。第2章だったら、Section2とディレクトリを分けたほうがわかりやすいかなーと思っています。
追記(19/08/21)
章ごとにブランチを切って、その章の最後まで写経したらpushして、プルリクエストを作成してコードにコメントをつけて復習が出来たらmasterブランチにマージしていくというやり方がオススメです。 学生時代に1人でプログラミングを学んでいた時は、プルリクを使う機会が全然なかったのでGitに不慣れでした。こういうときにプルリクを使っておくといいと思います。
写経はいいぞ
僕は読んでいるうちに頭が働かなくなることがあるので、写経で手を動かす方が合っていると思いました。 打って実行すると、強制的に頭が働く気がします。 写経は意味ないぞという意見の人もいるのかもしれませんが、しっかり読んで理解できればどちらもでもいいのかなーと思います。 読んだことのある本でも新しい発見があるので面白いです。 それでは、引き続きやっていきます。
「みんなのウェディング出張1dayインターン@沖縄 2018」に参加してきました。
概要
去年は就活生として参加したインターンに、今年は内定者として参加しました。
あの何も分からなかった頃から約10ヶ月経つのかーと感慨深い思いに浸っていました。 前日に慌ててRubyを勉強して参加した記憶があるので、Ruby歴も約10ヶ月ということになります!
やったこと
Ruby, RSpecとRailsに一通り入門した後に、プロダクションコードにユーザーページのカバー画像を変更する機能を追加するというのをやりました。
Ruby入門
まずはRuby入門ということで変数定義から、最後はライブラリの読み込みやアクセサ定義までを解説されていました。 分かりやすかったです。
RSpec入門
ユニットテスト、インテグレーションテスト、アクセプタンステストなどテストの種類からRSpecの簡易テンプレの使い方までを解説されていました。 普段テストを書かないという人が多かったみたいなので、多くの人にとって有用だったと思います。 自分が一番勉強になっていたかもしれません。笑
Rails入門
Railsの歴史やディレクトリ構成などの基本から解説されていました。scaffoldもやりました。 短時間で解説なんてRailsの大きさを考えると不可能ですが、要点を絞りに絞った感じだったので初めての人もなんとなく理解出来たんじゃないでしょうか。
プロダクションコードを触って、カバー画像の変更機能を開発
hamlに慣れていなくてインデントをミスったり、メソッド定義の順番を間違えたりしつつも何とか最後まで辿り着けました。 一番最後にファイルサイズのバリデーションを実装しようという応用問題があったのですが、慌てていて普通にモデルから書いてしまいました。 この時はTDDを完璧に忘れていたので、反省。 テスト書くの好きになったので、もっと書いていきたいです。 あるべき振る舞いを先に定義していると、向かう先が分かっているので普通にコードを書きやすいと思います。
感想
プログラミング経験があればRuby,Railsを触ったことがなくても何とかついていける内容だったと思います。 ペースは少し速めでしたが。 去年とは内容も開発環境も変わっていましたが、確実に良くなっていました。 学生としては実際に動いているサービスのコードを触れるのは嬉しいですよね。 Cloud9は不慣れな人が多かったと思いますが、環境依存の問題を排除できるというのはメリット大きいですね。 会社のセキュリティ的にも良いはずですし。 デフォルトのファイル検索機能があまり精度が高くないっぽいので、c9コマンドを初めに入れておくと良かったのでは?とか思いました。 そうすればc9 openとか出来ますし。 個人的に学びになったことは色々あったんですが、印象的だったのはテストコードを書くときにtruthyとfalsy(スペルはfalseyではないですよね??)の話が出てきたことです。 英語で語尾にyをつけるときは「~っぽい」という意味ですよね。 つまり、「真っぽい」と「偽っぽい」というのがあるということです。 覚えていなかったところなんで、調べたことを載せておきます。
True and False vs. "Truthy" and "Falsey" (or "Falsy") in Ruby, Python, and JavaScript · GitHub
この記事に以下のように書いてあります。 "In Ruby only false and nil are falsy. Everything else is truthy (yes, even 0 is truthy)."
直訳すると、
Rubyにおいてはfalseとnilのみがfalsy。他の全てはtruthy(そう、0ですらもtruthy)。 ということらしいです。
Rubyの公式ドキュメントにもこのように書いてあります。
とにかく、Rubyの場合はfalseとnil以外は全て真なのですね。シンプルです。
前日の飲み会も懇親会も楽しかったです。 参加者の皆さん、mwed社の皆さんありがとうございました。 実験やって卒論書きつつ、入社前課題を頑張っていきます!!
追記
こんな面白いクイズも見つけました。
builderscon tokyo 2018に行って来ました
全体的な感想
大きめのカンファレンスを純粋に聞くことに徹して、知識をインプットするのに集中したいと思って参加しました。
ワンチャンLTしたいなーとか思ってましたが。
最近、都合が合わずこの手のものに行けないことが多かったのです。
また、スタッフでの参加ではなかなかトークを集中して聞けなかったので、学生無料チケットを使わせて頂いて参加しました。
全体的な感想としては、マイクロサービスとIoTの話題が多かったですが、参加している人たちはWeb系の人が多かったのかなと言う感じです。
Webアプリケーション関連のトークは小さな部屋で開催されていたのですが、人が入り切らなくなっていることもしばしば見られました。
参加者が増えているようなので、来年は会場広くなるといいですね。
気づいたら2週間経ってしまったので、雑なメモだけ公開しておきます、、、、ブログ書く力が最近ない、、、
前夜祭
自作キーボードとロボットボールは頑張れは作れそうな感じがしたので、時間があればやってみたいです。
特に左右分割のキーボードがそんなにいいのか試してみたいです。
また、スマートロックは自分の家に導入しようかと思っていた矢先にIoTの闇の話を聞いたので、もう少し様子を見ようと思いました。
VTuberが中の人も見える状態でLTするという新しいスタイルも見ましたが、印象に残っているのは頭と両手につけた3つのコントローラーからの動きだけで肘や膝の動きを補完して再現できるということでした。
1日目
ランチセッション
- ku8s, microservice, 理想状態への収束
- サイボウズ, Yakumo
パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと
- 推測困難、使い回さない、仕様のバラつきに対応
- パスワード認証をやめるべき
- FIDO2.0, Web Authn API
- Web Authn API,デバイスを使った認証?
- 大事なのは生体認証を実装するかどうかではなく、WebAuthn APIとかの議論(?)
Webサービスにて200週連続で新機能をリリースする舞台裏
- Mackerel、今では当たり前の機能すら未実装なままリリース
- 機能開発のスピード感が顧客に約束できる数少ない価値の一つだった
- 連続リリースにこだわってみるか、と方針を立てた
- どうやって連続リリースを維持したか?
- 3年の長期ロードマップ、四半期ごとの中期ロードマップ
- 週次当番制にすると、属人化を防げる
- マイクロマネジメント(計画しすぎ?)はダメ
- 遊びがないと改善できない
端末管理の話
- 解決しない問題を今後どうしていくのか
- 目的(大事!!!): ライセンス管理、コスト削減、業務最適化、情報セキュリティ対策、不正利用対策
* 性善説は成り立たない
* プロファイルマネージャー: オンプレ管理辛い
* Meraki, Jamf Pro
* audit機能とは? => 使い辛い
* Google Santa: macOS用のバイナリホワイトリスト、ブラックリストツール
* sudo渡さなくても、色々できる
* 水飲むスライド
JavaCard
lld
- LLVMのサブプロジェクト、とにかく高速
- リンカ(linkage editor): オブジェクトファイルを1つの実行ファイルやDSO(DLL)にまとめるプログラム。".o"ファイル
- 採用事例多数
- 良いデータ構造にするのが重要(データが先、コードは跡)、2回書く(1回目の経験を活かす)、最適化する箇所を最小に留める(大半の部分は読みやすさを大事にする)
- 最近のCPUはどんどんコア数が増えている、シングルコアはこれ以上速くならない?
- 問題についてよく考えて、アンチパターンに思えても勇気を持って試す
- 存在しない問題を作り出すのではなく、根本の問題を解決しよう
- 「Unixの開発環境の標準リンカ」になるという大きな目標も、挑戦しない人が多いだけなので、意外と実現可能なので挑戦してみよう
2日目
Webアプリケーションエンジニアが知るべきDNSの基本
- ドメインやDNSを扱うときにドメイン名やIPアドレスを扱う時に怖くないようになる
- 創成期はホスト数が少なかった
- DNS(Domain Name System)の役割、ヒモ付が名前解決
- ルート権威サーバー、ルートヒント(後で読む)
- 権威サーバー、3層構造(ルート、jp,mammy326.jp)
- ドメイン名のツリー構造を形成する空間を名前空間という
- ゾーンとは:ノード単位で管理されるDNS情報
- NSレコードでゾーンがつながっていく
- dig NS(A) www.mamy1326.jp
- ネガティブキャッシュ保持時間
- TTL172800(48時間)
- メール送信元を検証できるSPFレコード
- スタブリゾルバ: Appから名前解決を要求される、OSの機能(?)
- デモ動画(お名前.com => ROUTE53)
- デモ動画のキャッシュの時間はどれくらいだった?
- 正しいTTLの取扱まとめ(資料みる)
- 「浸透」って言うな!!
- 「TTLを調べ、適切な時間表現する」
- 以下最後のまとめ
- 誰かになにか貰ったら少し足して誰かに渡せ
- 恩送り、おれたちは助けられた鶴
- 権威サーバーが下位サーバーにいくかんじが恩送りっぽい
ISUCON8予選、イイカンジになりませんでした@沖縄
経緯など
さぼさんid:saboyutakaを始めとする昨年のISUCON沖縄勢の方々に続く形で始まった今年のISUCON(就活)プロジェクトが終わりを迎えました。
僕らのチームSushiSobaRamenは5月から毎週木曜日に3時間ほどの勉強会を開いてきました。
全くの初心者からWebの仕組みを理解して、過去問演習のための環境構築をして、初歩的なチューニングをできるようになるまではとても長い道のりでした。
初めは何をしていいのか本当に全く分からなかったです。
さぼさんが作ってくれていた「ISUCON初動やることリスト」や「ISUCONパフォーマンス・チューニング」に沿って、約半年学んできました。
卒業研究が忙しくて、勉強会に参加する気が起きなかったこともありましたが予選に絶対に出ると強めに決めていたので何とかやってこれました。
チームを組んでくれた2人ありがとう。
ISUCONの感想
当日やったこと
アプリ担当だったので、構成を確認したあとはブラウザから今回のお題アプリTorb(チケット予約システム)を触りつつRuby実装のコードを読んでいました。
ミドルウェアは想定していたnginxではなくh2oで、データ・ベースもMySQL5系ではなくMariaDB5.5という過去問や模擬との違いに戸惑いつつもセオリー通りに計測してボトルネックを解消していこうとしていました。
しかし、実際に僕が出来たことはほんの僅かなことだけでした。
/geteventや/geteventsや/adminが重いのは分かっていましたが。
ローカル環境の構築に手間取ってしまい、結局色々諦めました。そのせいで、rack-lineprofilerで計測していく作戦も失敗。
DBにインデックスを貼ってもベンチマーカーを走らせるたびに削除されてしまったり、pumaの設定ファイルを書いてみたもののあまり効果がなかったりという感じでした。
id:isoflabonがインフラ担当として、3台構成を色々と試行錯誤してくれていました。torb1だけで動いていてmtorb2とtorb3は初めは何もしていないサーバーです。
これを、
・torb1: デフォルトの状態(Webapp+DB, h2o)
・torb2:
・torb3:
↓↓↓↓↓↓↓↓↓↓↓
・torb1: デフォルトの状態(Webapp+DB, h2o)
・torb2: Webapp+nginx
・torb3: DB
このようにしようとしていたようです。
ログやブラウザから確認した限りでは、問題なく動いていたのですがURLが変わってしまっていてベンチマーカーから怒られるのを解決できなかったみたいです。
練習というか勉強会では一度も複数台構成をやったことがなかったのに、本番で何とかこなしていたid:isoflabonはさすがでした。
後日わかったこと
あとでなんかかく
次の初心者チャレンジャーへのアドバイス
頑張って少しでもデキる人にチームに入ってもらいましょう
当たり前ですが、環境構築や勉強の過程でいくつもの困難に出会います。プログラミング、Web初心者だけではかなり厳しいです。
コードリーディングを優先しましょう
僕らはコードリーディングは各自でやっていて、Web全体の仕組みやパフォーマンスチューニングやインフラ関係のことに割と時間を使っていました。
正直これは失敗でした。
本番で3人のうち2人がアプリ担当をするのは定石なので、一旦過去問でローカルの環境(dockerとかVagrantfile使えば簡単です)と本番環境を作れたら、ガンガンコードを読んで、プログラミングでチューニングする方法を試していくべきです。
公開されているブログやリポジトリから勉強しましょう
こんな感じで、リポジトリを公開している強いチームのコードも読んで勉強に役立てましょう。
www.wantedly.com
「ISHOCON2大会@ギークハウス沖縄」に参加した!!【Ruby】
感想
geekhouse-okinawa.connpass.com
師匠であるid:saboyutaka氏がギークハウス沖縄でISHOCON2をやる会を開催してくれたので参加してきました。
とても楽しかったです。ありがとうございました。
また、ISHOCONの創始者であるid:showwin氏にも大感謝です。AMIが公開されていたので環境構築がとてもラクでした。
github.com
このマニュアルに沿ってやれば、簡単にイメージ、ベンチ共にインスタンスを立てて用意された言語の実装でスコアを出せます。
今までISUCONの過去問等をやった中で、もっともスムーズに競技を始められた気がします!
やったこと
MySQLのチューニングなど
Ruby実装で挑みました。初期スコアは2316でした。
いつも通りツールのインストールを済ませてから、レギュレーションを読んで、マシンスペックやサーバーの構成を確認していきました。
htopで確認したところ、MySQLのメモリ使用率が高かったので、クエリの改善を試みました。
DBのdumpファイルを作成し、ローカル環境に持ってきたものはもちろん、リモートののサーバーで動くDBにもSequel Proからスムーズに繋いでGUIで操作することが出来ました。
最近はチームでは一応アプリ担当だったので、久しぶりにやることが多かった気がします。
しかし、最近DB周りのエラーが多かったのですが、今回は逆でした。
この辺でスコアは10000点でした。
MySQLのチューニング次第でもっとスコアは伸びていたと思います。
Nginxやredisのチューニング,,,のはずだった
完全に技術不足でした。nginx.confの設定やUnicornのワーカー数をいじった程度でした。Ruby実装はここからが本番だったみたいです。
Go実装に切り替えたら20000点出た
Go実装は初期スコアは7000くらいだというのを聞いていたので、もうこの際1人だし全然知らないけどGoやってみるかーと思ってGo実装にした。
Goは並列処理に強いというのも聞いたことがあった(常識?)ので、Go実装にしてベンチマーカーのWorkload数を130くらいに設定してベンチを回したところ20162点出ました。
まとめ
本番直前だけど、redisを使えるようになってオンメモリ戦略取れるようにしたい。
nginxのチューニングはインフラ担当に任せたい。
※オンメモリ戦略: RDB上のデータを正としてプロセスメモリ上のデータをキャッシュとしてのみ利用するのではなく、プロセスメモリ上のデータを正として、RDBは永続化のためだけに使う(もしくはRDBを捨てて別の永続化手段を取る)
ISUCON3&ISUCON7をやってみた、、、
模擬ISUCONしたよ
しかしタイトルに、、、とついているのは微妙な結末になったからなのでした。
この日は本番どおりに10時~18時で時間を取っていたものの、メンバー全員が遅れる連絡をしてからのスタートになりました。笑
ISUCON3はt1.microでは厳しい
本番はm3.xlargeなのですが、今回僕らはAWS無料枠のt1.microにしたのでした。
ここでお金をケチったせいで、開始したもののいざ1回目のベンチマーカーを回す段階になって、メモリ不足に陥っていて計測できくなっていることが発覚。
この日、僕はアプリケーション担当だったので詳細は分かりませんが、id:isoflabonによると、Ruby実装を動かすのに少し手間取ったようです。
・mysqlがエラーを起こしていたこと
・nginxが初期では起動していなかったこと(Apatchが動いていた)
・nginxの設定がされていなかったこと
・言語の切り替えがsupervisorという不慣れな切り替え方法だったこと
(・centosが6だったこと)
要因としてはこんな感じだったみたいです。
この時点で開始から2時間は経過していたので、今日のところは今後の課題を洗い出して作戦会議をしようということになりました。
ISUCON7をローカルで動かす
以前やりかけていたISUCON7も多少触りました。
アプリケーションコードの変更を加えたとき、ローカルで動作確認できると便利だよねということになりDockerで環境構築をしました。
KitematicというGUIツールをポチポチしていけば簡単なのですね。
この辺もid:isoflabonがよしなにやってくれて色々と勉強になりました。
install.shを作る
ISUCONに必要なシェルスクリプトとして、install.sh, deploy.sh, benchmark.shなどがあると思いますが、事前に準備しておいてそのまま使えるのはinstall.shだけですよね。
デプロイやベンチは本番に適宜書き換える必要が出てくるかと思います。
そこでinstall.shだけ作りました。
ちなみにこの日emacsがきちんとインストールされていて動くのかを確認するために、初めてemacsを触りましたw
ISUCON予選突破への道のり遠すぎ
計測ツールの使い方や、ミドルウェアの設定、アプリケーションコードの改善の仕方 などなど課題は山積みです。
しかし最近楽しさを感じているので、なんとか本番までにもう少し賢くなりたいです。
ISUCON8予選へ向けての雑な活動記録的なもの
はじめにやりました。
github.com
模試をやりました。
ConoHaに登録すればカンタンに立ち上げることができるのですが、学生でも有料です。
最も安い630円のプランにしてAmazonPayで支払えばそれ以上のお金の心配はいらないと思います。
github.com
地味な知見
チューニングのことはすごい人が色々詳しく解説してると思うので、書きません。
- 変更を加えたときはもちろん、ブラウザから触ってアプリの仕様を把握することは大事。このとき、パフォーマンスはあんまり気にしない。画像の表示が遅いかな?くらいしか、いつも僕には分からないです。仕様の把握が大事。
- 変更を加えたら必ずベンチマーカーを回して、作業ログを残していく。
- メンバーでドロップボックスペーパーに作業ログを書き込んでいくと便利。付箋がなければTrelloも便利。
- 必ずバックアップは取ること。nginx.confやmy.cnfの設定ファイルは同一ディレクトリにコピペしてnginx_backup.confのようにして残しておくとラク。
- ISUCON7予選問題においてベンチマーカーを回すと、DBの初期化が行われる(?)ので、それ以前に作ったユーザーのIDとPWは使えなくなった。