年明けに出勤日は毎日ブログを書いていくぞ宣言をしましたが、体調不良でまともに記事がかけませんでした。
何らかの影響で記事書けない日がでてしまうことは今後もありうるので、これからは週1-2ぐらいを目処に更新していくのをマストにブログを書いていきます🙏🏻
年明けに出勤日は毎日ブログを書いていくぞ宣言をしましたが、体調不良でまともに記事がかけませんでした。
何らかの影響で記事書けない日がでてしまうことは今後もありうるので、これからは週1-2ぐらいを目処に更新していくのをマストにブログを書いていきます🙏🏻
最近kramdownというgemを触る機会が増えてきたのですが、使い方など参考にしようとググっても実際に使ってみた例などあまり多くはないようなので公式のドキュメントを参考にしつつ、実際に使ってみようと思う。長くなりそうなので今回は簡単な紹介だけします。
github.com kramdown.gettalong.org
githubのdescriptionによると
kramdown is a fast, pure Ruby Markdown superset converter, using a strict syntax definition and supporting several common extensions
と書いてあって、稚拙ながら直訳すると「pure rubyで書かれているmarkdown上位変換機能で処理が早い。厳密な構文を使って、幾つかの共通拡張をサポートしています」みたいな感じに書かれています。「???」みたいな気持ちになったので公式サイトの方を見たらわかりやすい図がありました。
参照: https://kramdown.gettalong.org/
要するに様々なインプットに対して、様々なアウトプットへの変換をサポートしているらしいです。2017年1月時点だと
以上には対応しているそうです。便利。
簡単ですが最近使っているgemの紹介でした。明日は実際に使ってみた例を書いていきます。
私は新規で作成するテーブルにはほぼ必ずidカラムを作成しています。定義は以下のような感じです。
`id` int(11) NOT NULL AUTO_INCREMENT, ... PRIMARY KEY (`id`)
自分がidカラムつけるのは主に、データ量が膨大なテーブルを扱う時にシーケンシャルな処理ができることです。 実装をそのidを基準に処理をかけばrow readsが少なくDBに優しい処理をかけます。
例えばPKがある場合
SELECT * FROM hoge WHERE id > 0 ORDER BY id asc LIMIT 1000;
SELECT * FROM hoge WHERE id > 1000 ORDER BY id asc LIMIT 1000;
みたいな処理をかけば、row readsは1000になると思います。これが例えばindex key基準に処理した場合そのindexでヒットする件数分row readsになると思うので良くないなという時があります。idを追加した場合のデメリットは、その分のデータ量が増えることかとおもいますがそれを許容できるような条件ならば追加しておいても損はないかなと。
ここ数年でRailsプロジェクトに関わるようになったのですが、Railsもmigrationでテーブル作成するとidカラムは自動でついてくるみたいでちょっぴり嬉しい。
先日勤怠のChrome拡張を作ったというブログを書きましたが、一人でしばらく使ってみて便利だったので今回社内向けに公開しようとおもって調べました。
社内向け = 一部のユーザに限定して公開
とした時に現状以下の選択肢があります。
Trusted Tester
というテスターのメールアドレスを明示的に指定し、彼らにのみ公開今回は社内向けということでドメイン限定の方が都合がよかったのでこの方法を選びました。 ドメインで縛りをつけて公開する方法は公式ドキュメントのこちらに書いてあるのでそちらを参考にしてください。
管理者ユーザの方にコンソール上から「Chromeウェブストアに公開することを許可する」を有効にしてもらわないとドメインの選択肢がでてきません。ドキュメントよく読めばわかることですが、よく読まないと???ってなります。
ウェブストアに公開にするには1点以上のスクリーンショットが必須らしいのですが、この項目入れないでも公開ボタンが押せます。この項目を入れなかった場合に、ポリシーに反しているよっていう自動メールと思わしきものが飛んできますがどう読んでも文章が繰り返しの表現とか誤解を招く表現とかしか書いてなくスクリーンショットの問題じゃないか気づくのに難儀しましたが現状そこ以外問題なりそうな点はないので間違いないかと。(※スクリーンショットが必須という点は入力時にフォーム付近にカーソルをあてたらhover?で注意書きがでてきます)
2, 3度失敗したら人力によるチェックに移るらしく数営業日待たされるそうです。
. . . . . . . . . . . .
そして私は今待っています。 (泣)
もし急ぐような場合などでは、管理者だと電話やチャットでのサポートが受けられるそうなので、相談してみるといいのかもしれません。
2017年になりました。年始めということで「今年の目標」と「エンジニアをすることについて」を書こうと思い筆を取った次第です。
の3つになります。
昨年の終わり頃に書いたブログは200日以上ぶりという感じで、「|'-') 今年一年何してきたか振り返れないやん?」みたいな気持ちになったし、対外的に見ても何してるかよくわからない人に見えたと思うので、今年はアウトプットしていこうという気持ちです。このブログはその初めということで。
また出勤日という括りにしているのは自分のルーチンとして生活に組み込みやすいからという意味以外はないです。
これは去年他の人のwebサービスを作成したのだけれど、それを経て自分もつくりたいなっていう気持ちからやろうと思った次第。
エンジニアとして今年で5年目になるのだけれど、基礎的な知識で自分がわからないところを明確にするために受けてみようかなという試みです。とりあえず有名な柏木先生の本を買ったのだけれど早速わからないところがあって何とも言えない気持ちになった!
新しい知識を学ぶ機会だと切り替えて引き続き頑張る
今年も改めて自分がエンジニアをすることについて簡単に振り返ると、
以上の2つかなと思います。
やっぱり真剣にものづくりするのがすごく楽しいし、そういった環境に近い場所にあるエンジニアという職業は楽しみしかないなというところにつきます。自分で頑張った分だけスキル・できることも増えるし、努力した分だけより多くの表現ができるようになるのは楽しいかなと。
この業界に身をおいて5年目ですが、自分がまだまだわからないことあるのにどんどん新しい面白い技術がでるので、常に新しいことに触れている感じで常に成長できるのではみたいな感じが面白い。頑張って成長するように努力はするけど、自分よりすごい人たくさんいてもう我以外皆我師
みたいな感じで常に合掌して学ばせてもらっております。
以上です。 本年もよろしくお願い致します。
誕生日のお祝いでカロリさんから頂いた「小さなチーム、大きな仕事【完全版】」を読んだ。
以上の点が印象的だった。
本に書かれた内容自体は概ね共感できるし、実体験から書かれたいい本だった。この本と出会うきっかけをくれたカロリさんに感謝です🙏