Bootstrapすごい
こないだ友人がやっていたので追随。
最近、コーディング案件が多くて、
時間当たりのタイピング量的に理論限界値が遠くに見えてきたので、
このまま手打ちじゃ厳しいなとbootstrapを遅ればせながらいじってみました。
作りながら学べるのがあったらよかったんだけど、
いまいち見つからなかったので、W3Schoolsのチュートリアルをリファレンス的に
正直な感想としては、めちゃめちゃ爆速で作れます。
体系的にまとめられたスぺニットの塊みたいなイメージ。
使いこなせると、たぶん２倍ぐらいのスピードで構築できるはずです。
２倍ぐらい早くなる理由。
例えば3つの要素を隣り合わせて並べるとしましょう。
するとfloatやらflexboxで並べるわけです。
さらに、レスポンシブ対応のため、display:blockしたり、flex-flowを変えたりしなくてはなりません。
という手間がcol3で済みます。
タイプ量的にはかなり削減できます。
もちろん、個別にスタイルを当てる必要はあるでしょうが、
「早く構築する」という点では、一定の成果が得られるはずです。
自分の「ウリモノ」を把握する方法
いわゆる、自己分析というやつなのですが、
を見て、ちゃんと言語化してみようかなと
これらの記事で言わんとするところって、ゲームでいうところの自分のステータス画面ちゃんと見てみたほうがいいよってことだと思うんです。
「自分の強み」と言ってしまえばそうなのですが、漠然としすぎてるので
「自分が今できることで他者に利益を与えうる能力、もの」ってことかな？
わたしの今の手持ちのカードを見てみると、
① 一応お金取れるレベル（といっても中の下ぐらい）のWebDesignができる！
② フロントエンドの実装もお任せあれ！（フレームワークは勘弁）
③ サーバーサイド？ワードプレスとか簡単なWebアプリぐらいならできるよ！
④ 人工衛星の軌道計算ツールとか大学で作った（航空宇宙工学の学位がある）。
⑤ C++とかでバイナリいじったり、ポインタのメモリ１つずれてるじゃんとか
ソケット通信でヘッダいじったり、デスクトップアプリも作れた。
んんー
一人でそれなりのWebサイトが作れて
プログラミングも初心者は抜けたかなぐらいの航空宇宙工学の学位もちか。
正直、一人でそれなりのWebサイトを作れる人なんてごまんといて、
プログラミングちょっとできるやつなんてそれこそ膨大にいて、
ただ、航空宇宙の学位を持ってて、その辺のスキルがお金取れるレベルの人材となると、希少性は高そうだし、面白そうなことができそうなステータスではあるんだよなー
これだけはやっておきたいカーニング
Webサイトと呼ばれる表現技法に占めるテキストの割合は少なくありません。
そんなテキストをよりユーザーに分かりやすく、ストレスなく読んでもらうため、
カーニング（文字詰め）は重要なポイントになります。
特に大きな級数の文字が文字詰めされていと、違和感がすごいです。
CSSでも
font-feature-settings :"palt";
と入力すればカーニングを自動でしてくれるフォント「も」あります。
しかし、案件によっては対応していないフォントの必要を迫られることもあるでしょう！
「せめて句読点だけでも」
「せめてかっこだけでも」
そんなデザイナー、フロントエンジニアの夢をかなえるのが下の約物のみを半角にしたフォントです！
作者様にはこの場を借りて感謝を。。
Git③：Gitが見ている世界
エンジニア界隈にいて聞く日のない日はないと言っても過言ではない「Git」
そもそもGitとはなんぞや？
と周回遅れでもいいところですが、見ていきます。
この記事はgitの公式ドキュメントをベースに自分なりの補足を加えたものになります。
厳密な情報がほしい方は公式ドキュメントが優秀ですのでそちらをご覧下さい。
Gitが見ている世界
私たちが普段目にしている、ファイルやフォルダをGitではどのような仕組みで理解しているのでしょうか？
今回は、Gitが見ている世界、Gitオブジェクト（今回は２つのみ）について解説します。
Gitも私たちと同じように「ファイル」と「フォルダ」でデータを区別しているのですが、機械でも区別できるように工夫しなければなりません。
そこでgitでは「ブロブ：blob」と「ツリー：tree」という仕組みを用いています。
例として、下記のようなファイル構成の場合を見ていきます。
「test.txt」の中には「test content」と書かれています。
ブロブ：blob
ブロブは「ファイルの内容」と「ハッシュ値」の組み合わせで構成されるオブジェクトです。
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content「ハッシュ値」で問い合わせることで、「ファイルの内容」を参照することができます。
ツリー：tree
ツリーは「ファイル名」と「ハッシュ値」に加え、「タイプ」、「ファイルの種類」の組み合わせで構成されるオブジェクトです。
「タイプ」はそのオブジェクトがtreeなのか、blobなのか、などを表しています。「ファイルの種類」はそのオブジェクトが実行可能なファイルなのか、などを区別しています。
ここでキモなのは、ツリーオブジェクトの中にツリーオブジェクトを入れることができる。という点です。
この仕組みによって階層構造を実現しています。
100644 blob 08cf6101416f0ce0dda3c80e627f333854c4085c test.txt
040000 tree 5efb9bc29c482e023e40e0a2b3b7e49cec842034 file
このようなシンプルな仕組みでファイルを認識することが高速な動作に一役買っていそうです。
Git②：バージョン管理の仕方の変遷
エンジニア界隈にいて聞く日のない日はないと言っても過言ではない「Git」
そもそもGitとはなんぞや？
と周回遅れでもいいところですが、見ていきます。
この記事はgitの公式ドキュメントをベースに自分なりの補足を加えたものになります。
厳密な情報がほしい方は公式ドキュメントが優秀ですのでそちらをご覧下さい。
個人でのバージョン管理
最も簡単なバージョン管理の手法として、
「新規ドキュメント-2」
「新規ドキュメント_最新」
「新規ドキュメント_20190106」
などの更新ごとに「名前」で区別する方法があります。
この手のバージョン管理手法を「ローカル・バージョン管理システム」といい、
簡単に実行できますが、
「新規ドキュメント_最新（２）」
などと付けてしまったり、しまいには、最新版を上書きしてしまったりなど、
事故の多い手法です。
これを自動化したものにVCSというものがあります。
自動化したことにより前述の問題点はなくなりますが、基本的にこの手法では、複数人が同時に作業することはできません。
複数人でバージョン管理
そこで、変更の履歴を持っているVCSをウェブサーバー上など、複数人で管理できる状態にしたものをCVCS：集中バージョン管理システムと呼びます。
これで、複数人でもバージョンを管理しながら作業することができるようになりました。
ところが、サーバーなどが使用できない状態になると、誰も作業できないといった問題点が明らかになってきます。
複数人で個々にバージョン管理
そこで編み出されたのが、「DVCS：分散バージョン管理システム」です。
これに分類される仕組みとしてはGit、Mercurial、Bazaar、Darcsなどがあります。
変更の履歴を持っているVCSをサーバー上など、複数人で管理できる状態にし、さらに、作業者のローカル環境にそのコピーを作成することで、サーバー依存に起因する問題点を解決しています。
糖質制限って結局なんなん？って話②
前回は、糖質制限という行為が、
炭水化物（炭素と水素の化合物）を制限する行為であるらしいことを見てきました。
生物学的な分類では、炭水化物のうち消化できるものを糖質、消化できないものを食物繊維としています。
そこで今回は、糖質制限、もとい炭水化物制限が炭水化物を具体的にどの程度まで制限するべきなのかを見ていきます。
今回は医学ジャーナル「THE LANSET」*1から、
「食生活の炭水化物摂取量と死亡率：将来のコホート研究とメタアナリシス。」
（原題：Dietary carbohydrate intake and mortality: a prospective cohort study and meta-analysis）*2
を参考に見ていきます。この論文は、日本人を含む432,179人の被験者に対し、炭水化物の摂取状況を中央値で25年間追跡調査した結果から炭水化物摂取量と死亡率の相関について分析したものです。
どうやって測るのか？
参考論文を含む多くの炭水化物と死亡率について調査している論文では、
総エネルギー摂取量における、炭水化物由来のエネルギー量の割合
を指標としています。
一番死亡率が低い割合は？
最も死亡率が低かったのは、50％～60％の割合で炭水化物からエネルギーを摂取したグループでした。それ以上の割合で摂取しても、それ以下で摂取しても死亡率は上がる傾向にあります。
炭水化物由来のエネルギー量の割合が低いほうが、高い人よりも死亡リスクが上がります。
結局どうすればいいのか？
炭水化物を制限するのであれば、
総エネルギー摂取量における、炭水化物由来のエネルギー量の割合が50％～60％程度
になるように制限すると、長く生きられる可能性が比較的高いようです。
今からできること
成人男性の理想的な１日の摂取カロリーが2,000kcalといわれています。
その約半分ですので1,000kcal程度を炭水化物でとるのが良いようです。
まずは、自分が食べているもののカロリーを把握するところから始めなくては…
Git①：Gitというシステムが作られたワケ
エンジニア界隈にいて聞く日のない日はないと言っても過言ではない「Git」
そもそもGitとはなんぞや？
と周回遅れでもいいところですが、見ていきます。
この記事はgitの公式ドキュメントをベースに自分なりの補足を加えたものになります。
厳密な情報がほしい方は公式ドキュメントが優秀ですのでそちらをご覧下さい。
「オープンソース」の力に世間がまだ気が付いていない時代、
「オープンソースのOSを作ろう」という野心的なプロジェクトが立ち上がります。
後にLinuxと呼ばれるこのシステムの開発は、
１．膨大なソースコードの量になる。
２．世界中のプログラマが改良を加える。
という点で他のプロジェクトとは一線を画していました。
この膨大で、入り乱れた改良を管理するため、
「高速な動作」が可能で、
「数千にも及ぶ開発ライン（ブランチ）を管理」することができ、
「開発ラインごとに干渉しない」（あっちをまたないと進められないみたいなのがない）
バージョン管理システムが必要とされました。
そうして生まれたのが「Git」です。
もう少し詳しく書くと
もともとLinuxカーネル（OSの心臓部）の開発ではBitkeeperと呼ばれる商用ソフトウェアを使っていたのですが、
リバースエンジニアリング騒動やらBitkeeperへの不満やらお金やらなんやかんやで使えなくなったので、その代用として開発されたシステムです。
次回は今回提示した要求をどうやって満たしているのかを見ていきます。
