- 投稿日：2019-05-02T21:50:40+09:00
Bootstrap のチームメンバーになった話
先日、Bootstrap の作者 (@mdo) からチームに加わらないかとお誘いのメールがあり、喜んで受け入れて、Bootstrap のチームメンバーになりました。
↑ Organizations の所に Bootstrap のアイコンが表示されるようになりました。
どういう経緯でチームメンバーになったのかを書いてみたいと思います。
はじめての Issue 報告
私が初めて Bootstrap に Issue を報告したのは、今から 2 年と少し前の 2017 年 1 月のことでした。
Issue の内容は、「同じ Nav コンポーネントでも、タブスタイルとピルスタイルでマウスオーバーした時のマウスカーソルの形状が異なるが、その理由を知りたい」というものです。
mouse cursor on active item of tabs and pills #21560
「これはバグだ！」と言わず、「なぜそうなっているか知りたい」と言ったのは、「実装漏れかもしれないが、そう設計されているのには何か訳があるのかもしれない」という気持ちがあったからです。
Bootstrap は CSS フレームワークと説明されることが多いですが、私はデザインシステムの雛形のようなものだと思っています。そのまま使うというより、色を変えるなど独自にカスマイズして使います。色々カスタマイズできるからこそ、ベースとなるオリジナルが適切に設計されている必要があります。
Bootstrap はこの業界では世界でもっとも有名で、歴史も長いですし、使う側としてはちゃんと作られていると信じて疑わないでしょう。当時の自分もそう思っていた節がありました。Bootstrap の設計はちゃんとしているだろうから、おかしいなと思うことがあっても何かデザイン上の理由があるのかもしれないと。
しかし、Issue 報告後、その理由は説明されることなく、メンバーによって修正のための Pull request （以降PR）が作られ、問題が修正されていきました。
どうやた、ただの実装ミスだったようです。
当時は、ドキドキしながら Issue を書いていたと思いますが、淡々と進んでいったので、OSS に貢献した満足感とかも特になく、まあそんなもんか、という感じでした。
貢献活動の本格化
頻繁に Bootstrap に Issue や PR を報告するようになったのはそれから半年ほど経った 2017 年 8 月ごろからで、月に 2、3 件の報告をしていたように思います。
継続的に Bootstrap に貢献するようになった理由は、仕事がきっかけです。単発で Web サイトや Web アプリを作るだけだったら、Bootstrap のおかしな点に気が付いてもわざわざ OSS を修正する手間をかけるメリットもないと思いますが、私の場合は Bootstrap のテーマ的なものを作っていたので、不具合を独自に修正するよりも、本体に報告した方が良いことがありそうだと考えました。
ある程度の数の PR がマージされると、貢献者ランキングに名前が表示されるようになります。このランキングは GitHub の機能で自動で更新されていきますので、順位が上がるたびに自分のフロントエンドのスキルが認められていると感じられます。
やっていた活動は、不具合報告やバグ修正のPRだけでなく、こうなっているべきだという提案や、ソースのリファクタリングなどいろいろ行なっていました。
こうして、Issue や PR を通してBootstrap のチームメンバーと関わりを続けていると、あることが見えてきました。
それは、CSS 担当の不足です。
JavaScript に関するものは活発に開発が進んでいますが、CSS の部分は Issue が報告されても数日そのままということがよくあります。
しかし、時期によってはいっきに開発が進むこともあります。
Bootstrap のチームメンバーは（私も含めて）普段の仕事の傍で OSS 活動をしていますので、なかなか時間を裂けません。時間がとれたときに開発が進むということですね。みんな個人活動をしているんだからと考えたら当然のことです。
そういった中で、自分がチームメンバーに入れたら、もっと開発を進められるかもしれないと思うようになりました。
チームメンバーに入る方法は、2 通りしかないと思います。
- 自分からメンバーに入れてくれと希望を出す
- チームメンバーから入らないかと誘いをもらう
自分から申し込んだ場合、断られたら 2 度はないかもしれないので、「自分が作った PR が 100 個マージされたら作者にメールする」と決めて、まずはこのまま活動を継続することにしました。
（結果的に、PR を 70 個作った頃にメンバーから誘われることになりました）
日常生活の変化
OSS に貢献するようになると、日常生活も変化します。
きっかけが仕事の延長とはいえ、こういう活動をすることを会社から許可をとったわけではなく、個人活動として行なっていますので、作業は休憩時間とか、プライベートの時間で行います。
作業時間は日にもよりますが、多い時で 3 時間くらいを週に 3 日とかでしょうか。夜中の 2 時くらいまで Bootstrap の活動をして、8 時半に出社という生活スタイルです。
隙間時間の使い方も変わってきます。GitHub プロジェクトに対するすべての活動をメールで通知する設定にしていますので、毎日 15 〜 30 件のメールが携帯に届くようになります。新しい Issue や、新しいコメント、PR がマージされるなど、すべての動きに目を通して、状況を把握するようにしています。
朝起きて、布団の中で溜まった通知メールを読むということをずっとやっています。電車での移動中や、会社の休憩時間も携帯で通知を読みます。
プライベートワークが認められていて、普段の仕事と二刀流で仕事している方はだいたいこんな感じなんじゃないでしょうか。
活動のピークから現在まで
2019 年に入った頃、貢献の数が増えてきてチームメンバーとの会話も増えてくると、名指し（メンション付き）で意見を求められるようになりました。「@ysds はどう思う？」という感じですね。
そういうやりとりを通して、作業頻度には波もありましたが、およそ２年ほど Bootstrap への貢献を続けていたら、作者からお誘いのメールが来た、というのがつい先日のことになります。
結果的に、現在までに 52 件の Issue と 70 件の PR を作成し、晴れて Bootstrap のメンバーになることができました。
今後、チームメンバーになったことでどのような変化があるかまだわかりませんが、引き続き Bootstrap に貢献していくつもりです。
日本人で一人しかいない Bootstrap チームメンバーですので、そういった点でもなにかオファーがあったりしないかな〜なんて思ったりもしています。
Bootstrap を使っている方々は引き続き、使っていない方はぜひ便利に使ってもらえれば嬉しく思います<3
- 投稿日：2019-05-02T21:50:40+09:00
Bootstrap の開発メンバーになった話
先日、Bootstrap の作者 (@mdo) からチームに加わらないかとお誘いのメールがあり、喜んで受け入れて、Bootstrap のチームメンバーになりました。
↑ Organizations の所に Bootstrap のアイコンが表示されるようになりました。
どういう経緯でチームメンバーになったのかを書いてみたいと思います。
はじめての Issue 報告
私が初めて Bootstrap に Issue を報告したのは、今から 2 年と少し前の 2017 年 1 月のことでした。
Issue の内容は、「同じ Nav コンポーネントでも、タブスタイルとピルスタイルでマウスオーバーした時のマウスカーソルの形状が異なるが、その理由を知りたい」というものです。
mouse cursor on active item of tabs and pills #21560
「これはバグだ！」と言わず、「なぜそうなっているか知りたい」と言ったのは、「実装漏れかもしれないが、そう設計されているのには何か訳があるのかもしれない」という気持ちがあったからです。
Bootstrap は CSS フレームワークと説明されることが多いですが、私はデザインシステムの雛形のようなものだと思っています。そのまま使うというより、色を変えるなど独自にカスマイズして使います。色々カスタマイズできるからこそ、ベースとなるオリジナルが適切に設計されている必要があります。
Bootstrap はこの業界では世界でもっとも有名で、歴史も長いですし、使う側としてはちゃんと作られていると信じて疑わないでしょう。当時の自分もそう思っていた節がありました。Bootstrap の設計はちゃんとしているだろうから、おかしいなと思うことがあっても何かデザイン上の理由があるのかもしれないと。
しかし、Issue 報告後、その理由は説明されることなく、メンバーによって修正のための Pull request （以降PR）が作られ、問題が修正されていきました。
どうやら、ただの実装ミスだったようです。
当時は、ドキドキしながら Issue を書いていたと思いますが、淡々と進んでいったので、OSS に貢献した満足感とかも特になく、まあそんなもんか、という感じでした。
貢献活動の本格化
頻繁に Bootstrap に Issue や PR を報告するようになったのはそれから半年ほど経った 2017 年 8 月ごろからで、月に 2、3 件の報告をしていたように思います。
継続的に Bootstrap に貢献するようになった理由は、仕事がきっかけです。単発で Web サイトや Web アプリを作るだけだったら、Bootstrap のおかしな点に気が付いてもわざわざ OSS を修正する手間をかけるメリットもないと思いますが、私の場合は Bootstrap のテーマ的なものを作っていたので、不具合を独自に修正するよりも、本体に報告した方が良いことがありそうだと考えました。
ある程度の数の PR がマージされると、貢献者ランキングに名前が表示されるようになります。このランキングは GitHub の機能で自動で更新されていきますので、順位が上がるたびに自分のフロントエンドのスキルが認められていると感じられます。
やっていた活動は、不具合報告やバグ修正のPRだけでなく、こうなっているべきだという提案や、ソースのリファクタリングなどいろいろ行なっていました。
こうして、Issue や PR を通してBootstrap のチームメンバーと関わりを続けていると、あることが見えてきました。
それは、CSS 担当の不足です。
JavaScript に関するものは活発に開発が進んでいますが、CSS の部分は Issue が報告されても数日そのままということがよくあります。
しかし、時期によってはいっきに開発が進むこともあります。
Bootstrap のチームメンバーは（私も含めて）普段の仕事の傍で OSS 活動をしていますので、なかなか時間を裂けません。時間がとれたときに開発が進むということですね。みんな個人活動をしているんだからと考えたら当然のことです。
そういった中で、自分がチームメンバーに入れたら、もっと開発を進められるかもしれないと思うようになりました。
チームメンバーに入る方法は、2 通りしかないと思います。
- 自分からメンバーに入れてくれと希望を出す
- チームメンバーから入らないかと誘いをもらう
自分から申し込んだ場合、断られたら 2 度はないかもしれないので、「自分が作った PR が 100 個マージされたら作者にメールする」と決めて、まずはこのまま活動を継続することにしました。
（結果的に、PR を 70 個作った頃にメンバーから誘われることになりました）
日常生活の変化
OSS に貢献するようになると、日常生活も変化します。
きっかけが仕事の延長とはいえ、こういう活動をすることを会社から許可をとったわけではなく、個人活動として行なっていますので、作業は休憩時間とか、プライベートの時間で行います。
作業時間は日にもよりますが、多い時で 3 時間くらいを週に 3 日とかでしょうか。夜中の 2 時くらいまで Bootstrap の活動をして、8 時半に出社という生活スタイルです。
隙間時間の使い方も変わってきます。GitHub プロジェクトに対するすべての活動をメールで通知する設定にしていますので、毎日 15 〜 30 件のメールが携帯に届くようになります。新しい Issue や、新しいコメント、PR がマージされるなど、すべての動きに目を通して、状況を把握するようにしています。
朝起きて、布団の中で溜まった通知メールを読むということをずっとやっています。電車での移動中や、会社の休憩時間も携帯で通知を読みます。
プライベートワークが認められていて、普段の仕事と二刀流で仕事している方はだいたいこんな感じなんじゃないでしょうか。
活動のピークから現在まで
2019 年に入った頃、貢献の数が増えてきてチームメンバーとの会話も増えてくると、名指し（メンション付き）で意見を求められるようになりました。「@ysds はどう思う？」という感じですね。
そういうやりとりを通して、作業頻度には波もありましたが、およそ２年ほど Bootstrap への貢献を続けていたら、作者からお誘いのメールが来た、というのがつい先日のことになります。
今後、チームメンバーになったことでどのような変化があるかまだわかりませんが、引き続き Bootstrap に貢献していくつもりです。
日本人で一人しかいない Bootstrap チームメンバーですので、そういった点でもなにかオファーがあったりしないかな〜なんて思ったりもしています。
Bootstrap を使っている方々は引き続き、使っていない方はぜひ便利に使ってもらえれば嬉しく思います<3
- 投稿日：2019-05-02T20:17:19+09:00
スマホでfont-size 10px以下の文字を表示する
ラベルやアイコンで10px以下の小さな文字を使いたい。そんな場合画像で対応していませんか。
Google Chrome では10px、Safari では9pxが最小表示単位となっています。
10px以下の文字が表示できないChromeでもCSSで対応できる方法です。解決コード
こちらが解決コードです。続いて解説をしていきますね?
CSS.hoge{ display:block; font-size: 10px; transform: scale(0.8); transform-origin:0 0; }1.transformで縮小する
font-sizeを10pxで指定し、
transform80%表示＝font-size8px相当で表示します。
10pxを指定すると計算が楽です。CSSfont-size: 10px; transform: scale(0.8);2.display: blockを指定する
縮小する要素がインライン要素の場合は display: block; を忘れずに。
インライン要素にはtransformが効きません。CSSdisplay:block;3.transform-originを指定する
transformで縮小指定すると、縮小した分が中央に表示されてしまいます。
transform-origin:0 0; で位置指定をしておきます。CSStransform-origin:0 0;これで小さい文字もテキストで表示できます。
単純な方法で対応できる方法を考えた人…スーパー頭いい！！参考サイト
以下のサイトを参考にさせていただきました。
いつもお世話になっております??♀️Google Chromeでfont-sizeが10px以下にならない時の対処法
https://kotori-blog.com/soft/chromefontsize/font-sizeを10px以下に指定したい！そんな時に使えるCSSの書き方｜それゆけ！アラサー乙女 | それゆけ！アラサー乙女
https://chasoko-log.com/fontsize-lesstah10px-css/
- 投稿日：2019-05-02T17:54:13+09:00
BEMでElement__Elementを許容するのを検討する
始めに
皆さんはCSSはBEMで書いていますでしょうか？僕は基本的にBEMを使っていて、Elementは1つのみに徹底して書いてきました。ただこの運用にするとあんまりに辛いなと思ってきてElementにElementを書いてもいいんじゃないかと思ってきました。
理想のBEM構成にした時の問題
例えばTODOリストをコーディングするときに、Blockとしてはリストとアイテムは分けておくと柔軟性が良くなるので以下のようにしておくのがベストです。リスト側でアイテム間のマージンを設定しておくと、アイテムだけのパーツは他の場所でも使いまわしやすくなります。
オンラインエディタで書いたものはこちらになります。
See the Pen
Element2階層のBEMサンプル by wintyo (@wintyo)
on CodePen.
理想のBEM構成//- リストのBEM ul.todo-list //- アイテムごとのマージンをここで書く） li.todo-list__item //- アイテムのBEM（ここではマージンをかかない） .todo-item input.todo-item__check(type="checkbox") span.todo-item__text TODO button.todo-item__button 削除 li.todo-list__item .todo-item input.todo-item__check(type="checkbox") span.todo-item__text TODO2 button.todo-item__button 削除 li.todo-list__item .todo-item input.todo-item__check(type="checkbox") span.todo-item__text TODO3 button.todo-item__button 削除// TODOリストのリスト部分のみ .todo-list { padding: 0; &__item { & + & { margin-top: 10px; } } } // TODOリストの中身のみ .todo-item { display: flex; align-items: center; width: 100%; padding: 10px; border: solid 1px #ddd; border-radius: 5px; &__text { flex: 1 1 0; padding: 0 5px; } }ただこの運用は明らかに冗長で、まとめてひとつのBlockにしたいときもあります。その場合、以下のように書いてしまうことがあります。
形式だけElement一つにするul.todo-list li.todo-list__item //- アイテムElementの後ろに名前を足して配下感を出す input.todo-list__item-check(type="checkbox") span.todo-list__item-text TODO button.todo-list__item-button 削除 li.todo-list__item input.todo-list__item-check(type="checkbox") span.todo-list__item-text TODO2 button.todo-list__item-button 削除 li.todo-list__item input.todo-list__item-check(type="checkbox") span.todo-list__item-text TODO3 button.todo-list__item-button 削除.todo-list { padding: 0; &__item { display: flex; align-items: center; width: 100%; padding: 10px; border: solid 1px #ddd; border-radius: 5px; & + & { margin-top: 10px; } // itemエレメント以下で使っている感じを出す &-text { flex: 1 1 0; padding: 0 5px; } } }一応SCSSの階層関係を見るとElementの下に更に書かれそうだなという雰囲気は出てますが、単純に単語を連結したいのかの判断が難しくなります。
Elementの中にElementを書くのを許容して明記させる
これを書くくらいだったらもう
__をもう一つ増やしてElementの下に更にElementをはやしていることが分かるようにした方がいいかなと思いました。3つは流石にキツいのでブロックを分けましょう。Elementの中にElementを書くul.todo-list li.todo-list__item //- アイテムElementの下で使うクラス名だと一目瞭然（もし違った書き方をしていたら指摘しやすい） input.todo-list__item__check(type="checkbox") span.todo-list__item__text TODO button.todo-list__item__button 削除 li.todo-list__item input.todo-list__item__check(type="checkbox") span.todo-list__item__text TODO2 button.todo-list__item__button 削除 li.todo-list__item input.todo-list__item__check(type="checkbox") span.todo-list__item__text TODO3 button.todo-list__item__button 削除.todo-list { padding: 0; &__item { display: flex; align-items: center; width: 100%; padding: 10px; border: solid 1px #ddd; border-radius: 5px; & + & { margin-top: 10px; } // itemエレメント以下で使う設定 &__text { flex: 1 1 0; padding: 0 5px; } } }終わりに
真面目にBEMで書いていくと、すぐにブロックを分ける必要がありました。Vue.jsとかだと同一ファイルに何個もブロックを書いても問題ありませんが、単純な静的サイトでscssファイルに書く場合はクラス名とファイル名は一緒になっていないと探しづらかったりするのでブロックの安易な分割は結構辛いなと思っていました。なるべくブロックを分割せずに上手くまとめようとすると謎のHTML構成になってしまい、修正が難しくなってしまうことも多々ありました。
そこで2階層まではBlock__Element__Elementで書けるようにして1つのブロックにまとめれるようになるともう少し保守がしやすくなるんじゃないかなと思いました。
- 投稿日：2019-05-02T16:08:23+09:00
「令和元年」を「プログラミング元年」に
はじめに
未来電子テクノロジーでインターンをしているKentoです。
元号が平成から令和に変わるタイミングにどこかで変わりたいと思っている自分がいました。
そこで、思い立ったのがプログラミングです。
普段はWebマーケティングの業務を務めていますが、こうした業務をこなしながらプログラミングを頑張っているインターンの仲間がいたのもプログラミングを始めるに至った大きな要因です。具体的な目標はありませんが、個の力で生きることが要求される令和時代を生き抜くためにも、少しずつプログラミングを学んでいこうと思います。
プログラミング初心者であるため、内容に誤りがあるかもしれません。
もし、誤りがあれば修正するのでどんどん指摘してください。踏み出した第一歩
インターン先のカリキュラムに沿って、まずはProgateの「HTML&CSS 初級編」から手をつけました。
こうして私のプログラミング元年がスタートしました。※プログラミングに精通している人からすると、HTMLやCSSは厳密にはプログラミングではないと思われるでしょうがご容赦ください。
プログラミングに初めて触れた率直な感想は「すっげぇぇぇ〜けど、いちいち細かい……」です！！（笑）
自分が打ちこんだコードが形となり、様々なものを駆使すればするほど、見やすく複雑なものになっていくことに感動と達成感を覚えました。
一方で、ちょっとしたスペルのミスや記号一つですぐにエラーを吐かれるので、融通が聞かないなあと苦しみもしました。今後について
今後はこのままProgateでHTMLやCSSを学び、それが終わればPHPなどを学んでいこうと思います。
学習を進めていく上で、常に楽しむということは大事にしていきたいと思います。