Githubにファイルが挙げられなくなった際の参考サイト
githubにsourceTree経由で全くファイルが挙げられなくなり、
github周りの初期設定を1からやり直した時に
参考にしたサイトを備忘録として残します
■Githubへのファイルをアップロードする環境構築手順
■SSH認証鍵登録
■ステータス確認、オプションあれこれ
■originが既に存在している時のエラーと対処方法
事の発端は、SourceTreeからファイルを挙げようと思った際、
突如、何故か全くGithubに通信が行かなくなり、403というエラー
対応を続けていたところ、githubにも接続が出来なくなったことです。
Githubにファイルをターミナルから直接挙げることも難航し、
結局1から全ての設定をやり直すことになりました。
相変わらずSourceTreeの方は正常に使えませんが、
とりあえず、ファイルを挙げたり共有できる
最低限の状態までには持ってくることができたのと、
問題の原因がSouceTree側の設定にあるという点だけでも
ハッキリしたので良かったです。
かれこれ一ヶ月くらい細かい時間を確保しては対策を探し、
精神的にかなり参っていたので、肩の荷が一つ降りました。
環境構築周りでは何かとトラブルが多いので、
設定周りを弄る時は、とにかく慎重にやることと、
何を参照したか、何の命令を打ち込んだのか、
記録を残しておく事の大切さを感じます。
（Qiitaの関連記事は、テーマがほとんど同じでも
内容が微妙に違う、似通ったものが多いので、
検索経由だと、二度と辿り着けなさそうな記事が多いです）
あと、エラーコードを一つ一つ打ち込んで粘り強くググれば
必ず何かしらのヒントは見つかって前進するので、
とにかくググって何とかする精神は忘れないようにします。
仕事が早い人は何をしているのか
表題の本を読みました。
題名の通り、仕事が早い人は何をしているのかについて、
特に「ミスを減らすための方法」という視点で書かれた本です。
タイトルの第一印象は、よくあるハウツー本ですが、
思った以上に読み応えのある本で、著者の方が製造業出身なこともあり
自分が過去に働いていた職場での話と、似通った部分も多かったです。
注意を払わなくてもミスが起こらない仕組みを作る
この本は、そのために書かれたと言っても良いくらい、
全体を通して、ミスを起こさないための
「仕組み化」について追及されています。
例えば、僕は財布や携帯を置き忘れることが多いのですが、
どんなに気を付けても、一年間普通に過ごしていた場合、
ほぼ間違いなく、どこかの場面で紛失をしてしまいます。
財布だけならいいのですが、各種証明書を丸々紛失した際は
再発行で失う時間が半端じゃなかったので、これはもう、
意思の力で解決するのは無理だと思い、
・仕事中は財布をチェーンで衣服に固定する
ということを始めた結果、紛失が起きなくなりました。
かなり原始的な話ですが、これも一つの仕組み化です。
この本の主なテーマは「仕事におけるミス」ですが、
・書類を間違えていないか？
・提出期限を間違えていないか？
・予定のダブルブッキングをしてしまっていないか？
それぞれに対する注意力は、人によって全く違います。
・絶対に時間だけは守るが細かいチェックが苦手
・慎重な確認作業は得意だけど人の名前が覚えられない
・朝の集中力はすごいけど夕方になるにつれ注意力が散漫に
など、注意力というのは、人による差があったり
環境や状況に左右されてしまうケースもあります。
なので、うっかりミスを減らしたり、
誰に任せてもミスの確率を一定の確率やゼロに収める為には
そうなるような仕組みを作ることが重要。
注意力に頼らないといけない時点で、それが作業として
成熟していないというのが、著者の考えです。
その仕組み化のヒントになる、
具体的なエピソードや提案が山盛りです。
自分は昔、プリンタの品質評価の仕事をしていましたが、
当時、現場で何か問題を起こした時も、
ただただ恫喝されるようなことは少なく、注意力などの
曖昧さに頼らずミスを防ぐ対策が多かったのを思い出します。
ただ紙を流して印刷しまくるだけの仕事にも、
ダブルチェックの基準を別々に用意したり、
重複した試験を削って工程自体を減らしたりと、
工夫できることは、いくらでもあります。
どんな仕事も、最初は雑用に近いものを任されますが
この型や仕組みを作る習慣、勘のようなものは、
今後どこで何をやるにしても生きてきます。
逆に、仕組み化の習慣が無いと、一人暮らしの時も
本来はする必要の無かった無駄な苦労をたくさん抱えます。
共同生活でも迷惑をかけ、周りの足を引っ張る存在になります。
だから、やはり人は普段から仕事をして、
仕組み化を嫌でも考えずにはいられなくなるよう、
適度に追い詰められる経験をした方がいいと思うのです
ブログも、なかなか毎日がっつり書くのは大変です。
作業を細かく分けて、根性とやる気に左右されずに済むよう
こちらも仕組み化をもう少し考えてみることにします
Laravel環境構築のエラー対応
現在、Javascriptのフレームワークを学んでいますが、
最終的にPHPとJSのフレームワークでアウトプットをする際は
HTMLを書く土台はLaravelのView部分になるだろうと思い、
環境構築の部分だけ先行でやってしまおうと思い、始めました
ところが、新しい言語や開発環境で毎度お馴染みの環境構築で
やはり色々と足止めを食らってしまい、これは期間を空けたり
現場に入って新PCでもう一度やるとハマる臭いが満載なので、
備忘録として、ハマったポイントについてまとめておきます。
1.Laravel自体のインストールができない
MacのOSがcalifolniaになっている人は
特有のエラーが出てインストールが成功表示にならないので、
以下のリンク先のbrewコマンドを入れると解決します
https://qiita.com/michimoy/items/73834c07f425a55ee552
brewはhomebrewというパッケージソフトのコマンドなので
これも合わせてインストールしておきましょう
2.コマンドが見つからない
今日一番時間を食ったのは、Laravelでプロジェクトを作成した後、
バージョン確認や各種コマンドを使おうとしても
「Could not open input file: artisan」
が表示されるだけでさっぱりうまくいかない現象。
しかし、この記事を読んで驚愕
https://qiita.com/saku_tto_chan/items/724f00d6495deaceabaf
「ディレクトリが違う。
ホームディレクトリに移動しろ」
…たったこれだけのショボイ原因でした。
ですが、エラーコードを1行1行最初から地道に追っていけば、
恐らく、もっと早く解決したのは間違いありません。
Laravelに限らないことですが、とにかく、ハマってしまったら
冷静にエラーコードやエラーの解説文章を1行1行コピペしてググり、
先駆者の技術記事を読み漁ることが重要だと改めて実感しました。
FLOCSSを書き始めて思ったこと
HTMLのレスポンシブ対応やsass形式で作ったサイトを
FLOCSSのCSS設計で書き換える際に使った外部情報や
感じたことを、備忘録としてまとめます。
FLOCSSとは何か？
FLOCSSは、CSS設計の一種で、これまで使われてきた
様々なCSS設計の思想のいいとこ取りをした手法であり、
現在も多くの現場で使われているそうです。
しかし、求人サイトを巡回して色々なWEB制作会社の制作実績や
企業自体のホームページのソースを見ましたが、このFLOCSSを
100%完全に採用しているWEBサイトは見つかりませんでした。
その一方で、部分的な命名規則は一部使われていたり、
クラス名の命名規則が似通っていたりということはあるので、
明確にここまでが規則、という境界線は引かれておらず、
現場次第で曖昧なものであるという印象があります。
恐らく、FLOCSSをガッツリ採用するのは、
外部非公開の大人数で開発する中規模以上のWEBサービス、
社内ITシステムの開発現場ではないかと予想しています。
（予算がより多く、納期が長く、エンジニアが入れ替わり
保守性がより重要になってくると思われるので）
FLOCSSはどうやって導入するのか
実際の現場では、FLOCSSの設計記法に最初から則って
CSSを書いていく形ではなく、適当な要素名を当てて
WEBサイト自体の全体の形を先に完成させてしまい、
後から修正をしていく流れが多いそうです。
なので、これに沿って自分でWEBサイトを作ろうとした時も、
まずはとにかくサイト自体を完成させることを優先しました。
次に、その既存のCSSをFLOCSS方式に
書き換えていくのですが、実際に自分で一通りやってみて
注意すべき点だと感じた事は、３つあります。
1.階層の順番に沿い、上から下へと書いていく
FLOCSSには、大きく5つの階層があり、
・Foundation
・Layout
・Compornent
・Project
・Utility
という順で連なっている層だと考えると、
上の階層のCSSで組んだサイトの部分に、
下の階層のCSSで組んだサイトの部分を
積木のように積み上げるような仕組みになっています。
図に表す場合は以下の記事先の画像が参考になります（かわいい）
CSS設計の概要の説明を受けた段階では
やることが膨大に感じるので、
一体何からやればいいんだろうと最初は思いますが
一つ一つ分解して考えれば
・Foundationに該当するCSSを上から下まで書く
・layoutに該当するCSSを上から下まで書く
・共通化できそうな部分をCompornentとして書く
・それ以外の部分は基本Projectとして書く
（CompornentとProjectは行ったり来たりする）
・細かいちょっとした部分のCSSはutiltyとして書く
これらを一つ一つ、上から下までやっていく、
今までやってきたことに比べると、機械的な作業です。
時間はかかりますが、WEBサービスの中身作りに比べれば
想像が全くつかない要素は少ないので、最初は面倒ですが
コツコツやれば、やっただけ確実に手応えがあるので、
PHPで何かを実装する事に比べたら精神衛生上は楽です。
ちなみに、現場の方々のCSS設計の初体験記を読むと、
一番多かった悩みが、CompornentとProjectの分類が
わかりにくい、曖昧であるという点です。
Compornent
モジュール単位
固有の幅や色の機能を持たない（共通化できる要素）
Project
基本はProjectで、繰り返される要素をcompornentとして切り出す
コンポーネントの方が上の階層
命名ルールは
「親となる要素__子要素—要素の変化した状態」
が基本の型です。
「子要素単体が階層で複雑になっている場合はどうするの？」
など、よく分かっていない部分は多いですが、
著者の方も、教材の中で唯一の決まった形は無いとか、
とりあえず困った場合はprojectに分類しましょう、
という旨を明言しており、今はそれを参考にさせてもらっています。
・FLOCSS公式ドキュメント
・芝犬のFLOCSS
あとはひたすらググって、書いてみて、
反映されるかどうかを確かめて、修正して…を
ひたすら延々と繰り返していました。
正直、細かい所まではよく分からないので、
一度一通り書いてみた今は、これ以上自分で悩むよりも
実際に書いたコードを現役の方に対価を払って
見てもらおうと思います
2.バックアップを取った方がいい
後から書き換える際にかなり難航するので、変更をする度に
画面表示を確認すると、思った以上に構成が崩れます。
自分は変更前のクラス名と変更後のクラス名を
毎回エバーノートに一つずつ貼り付けておき、
完全に書き換えが完了したら次へ、と慎重に進めました。
実際の開発現場や卒研でこの調子では日が暮れるので、
最初にHTMLとCSSを組み上げる時点で、変更しやすいように
命名を工夫しておいた方が書きやすくなると感じます。
もしくは、1機能書き換える毎に
都度gitに挙げて更新した方が良かったかもしれません。
後から変更前の状態に戻せるようなので。
それから、ゆるおじさんという方が以前Twitterで書いてましたが、
僕は実務に出るまで「コードレビュー」ってのをしてもらったことがなかったんだけど、独学してる人は変な癖がつく前にお金払ってでもコードレビューしてもらった方がいい。
— ゆるおじ@フロントエンド1年目 (@yuruoji) February 19, 2020
特にフロントの人はコードめちゃくちゃでも見た目だけそれっぽいもの作ることは出来ちゃうから危ない。
仰る通り、今の段階でどれだけ頭を捻っても
我流の変な癖が付きそうな予感がプンプンしているので、
MENTAを使って早めにコードレビューを受けようと思います
今は、現場に早く入りたい気持ちが日増しに強くなっています。
4月5月にガッツリ求人を漁って再び面談に臨みますが、
同期メンバーで現場に入っている人達の業務日誌を読むと、
1日8時間以上金を貰いながらコード書く環境に入らずに
どうやって追い付くんだろうというのを、今更ながら感じています
3.入れ子構造でCSSを書かないと死ぬ
例えば、以下のような画像、
お問い合わせフォームのCSSを当てる際ですが
・「お問い合わせ」の部分
・電話番号の部分
・営業時間の部分
・ボタン画像の部分
でそれぞれ、４箇所にCSSを当てる命令があります。
「よし、これまでheader-contact〜だったけど
今からp-header__contact--XXXXX という名前で統一しよう！」
となると、4箇所全てのCSS、4箇所全てのHTMLを
手入力もしくはコピペで変更する必要が出てきます。
まだ4箇所くらいなら何とかなると思いますが、
これが仮に10箇所20箇所の手作業になると、
どこかでうっかりミスをしたり、1箇所2箇所だけ
変更すること自体を忘れてしまう可能性は
十分に考えられます。
すると、仮に画面上の表示が崩れてしまった場合、
最悪の場合、その20箇所を一つ一つ目視で追って
間違い探しをしなければならず、結構な戻り時間が発生します。
ですが、sassの入れ子構造で、一番親の部分である
先頭のクラス名が変わった際、それに他の部分が追従する形の
CSS構造を最初にガッチリ組んでおけば、急なクラス名の変更や
まとまったパーツを丸々別の場所に引っ越す作業の際に
ミスや戻り作業が出る可能性を大幅に減らすことができます。
なので、sass形式でCSSを書くメリットは、
何故こんな面倒なことをやるんだろうと最初は思いましたが
使わないリスクの方が相当大きいだろうなと感じました。
逆に、個人で完結する仕事、短納期で完成まで短い仕事、
客先に一度納品してその後のメンテがほぼ必要ないサイトは
ここまでやらなくていいような気がします。
いずれにしても、現場に入らないと分からない事なので
この辺の詮索は程々にして、フレームワークのアウトプット、
来月からの面談に向け、引き続き取り組んでいきます
追伸1：
コロナの影響はかなり長引きそうなので
今後半年から一年にかけて、多くの会社が
求人や外注に回す予算をかなり絞ってくると思います。
仕事を探している人は、
早めに動き出した方が良さそうです。
追伸2：
CSSの名前を「親要素__子要素—変化」のテンプレに沿って
書き換えると、それだけでCSSが一切効かなくなる現象が
色々な箇所で発生しましたが、原因が全く検討がつきません。
今後もサイトを組む機会は何度かあるので、
今度は最初からこの記法に沿って組み上げていき、
何が効かない要因なのか切り分けをしてみようと思います。
レビューを受ける機会が先に来れば、
真っ先に確認したいところです
CSSを凝りすぎると永久に終わらない問題
HTMLのレスポンシブ対応の確認として、
架空会社のページを作成しています。
その中で、実際に存在する会社、企業ページなどを
数多く見ていく中で、
「何故この部分はこのスタイルを使っているんだろう？」
と思う箇所が腐る程出てきたので、備忘録として残します。
・line-height
line-heightは「行間の高さ」を指定します。
例えば、私が見た某サイトでは、ページのbodyタグに1.6と設定されていましたが、これはfontが10pxだとしたら要素の高さが1.6倍の16px分用意されるという事です。
そして、空白の6px分は、均等に上下に分けられて、上下中央に配置されることになります。
この仕組みを利用して、要素を上下方向に中央揃えする使い方を、HTMLの初級の内容で解説していたのを思い出しました。
・text-size-adjust
text-size-adjustは「テキストの拡大・縮小制御の制限」を行います。
プロパティには「none/auto」「パーセント表示（数値）」のどちらかが使われることが多いです。
その為、一般的にtext-size-adjustには「100%」のプロパティを設定し、画面を拡大縮小した場合文字サイズも連動するようにすることが多いそうです。
実機確認でも、要素のサイズ過不足やレスポンシブ対応による要素の並びなどを確認するだけでなく、拡大縮小を漏れなく確認項目に入れておく必要がありますね。
・letter-spacing
letter-spacingは、文字間の制御を行います。
ピクセル表示もできますが、文字サイズが違う各要素に対してbodyで一括で指定する場合、em単位で指定した方が便利です。（1em＝１文字の高さ）
サルワカという有名なサイトにも丁寧な解説がありますが、
0.1emでも十分広く見える為、これ以下に抑えた方が良いし、0でも正直、文章として見た目に違和感は感じません。
しかし、先程挙げた文字の行間を広めに設定している場合は文字間の距離がゼロだと窮屈な印象を与えてしまいますし、部分的にフォントが太い文字や細い文字だったりする場合の文字間は、要素毎に細かく設定した方が良いと感じます。
・font-smoothing
フォントの滑らかさを調整します。
...と、こういった色々な表現を調べていく中で感じたのは、
「これ一つ一つ丁寧に全部調べて導入していたら、永久に終わらなくないか？」
ということです。
現に、書籍でも全てが網羅されている訳ではありませんし、ウェブカツなどのスクールで教える内容も、当然厳選されています。
仕事の現場で求められる最低限度の品質を満たすために必要な、優先度の高い注意点や知識は、他にいくらでもあるからです。
誰かが言っていましたが、勉強自体はいくらでもできます。あとは、何にどれだけの時間を投下するかという問題。
一般公開されている企業のページは、時間と金を突っ込んで細部まで作り込まれていたり、他社案件で使ったソースを丸々引用して使い回したりしていると思われる為、当然ながら、細部まで、かなり作り込まれています。
今、最も優先すべき事は、
・レスポンシブ対応に関する全技術
・CSS設計（FLOCSS）
の２点に慣れること。
それだけは忘れず、念頭に置きながら、引き続き、サイトを組んでいきたいと思います。
365日24時間働けと実際に言われた時の話
Twitterのフィードを読んでいたら、
こんな呟きが目に入ってきました。
僕が会社を始めたばかりの人に100%言うアドバイスは
— 谷 英希 縫い場のない縫製工場CEO (@I_hideki22) January 31, 2020
「今すぐ商工会に行け」です
開業書類作成
源泉徴収
年末調整
専門家派遣
資金調達支援
ビジネスマッチ
社員入社手続き
ぜーーーーーーーーーんぶ
商工会会費だけでやってくれます。
じじ臭いと思わず、
今すぐ商工会に行きましょう。
自分も数年前、当時住んでいた横浜市で、税理士さんに勧められて商工会に行ったことがあります。
商売を始める際、商工会に顔を出すことは大いに賛成ですが僕がそう感じる理由は、引用元Tweetの内容とは違うので、当時のことを、少しだけお話させて頂きます。
業種や商売に関係なく、事業を自分で立ち上げる人達は、世間で普通に働いている人と比べると、仕事に対する熱意や売上利益を稼ぐことに対する基準値が、かなり違います。
商売をやる以上、早い段階でそういった方々の周辺の空気を一度浴びておいた方が良いと思う点が、経営者の集まる場に顔を出した方がいいと個人的に感じる、一番大きな理由です。
当時、ここを訪れるよう案内をしてくれたのは、青色会計事務所という口コミ主体の会計事務所だったのですが、そこの担当者の尾島さんという方から言われた、今でも忘れない言葉があります。
「大木さんはまずとにかく、
売上と利益を上げてください。
他業種も含めた一般的な中小企業の社長さんは、
365日24時間、仕事をするのが当たり前です。
最低でも年収1000万を超えるまでは、
売上に繋がらない一切の活動を辞めてください」
そう言われ、丁度確か確定申告前の時期だったと思いますが、頼もうと思っていた仕事をその場で断られました。
大人同士のやりとりなので、言葉遣い自体はオブラートに包まれましたが、そこまでに一通り話していた身の上話も含めて、
・囲碁の普及活動は論外。他人のことよりまず自分
・その程度の売上で平気でいる事を恥ずかしく思った方がいい
と言わんばかりの、無言の圧を感じました。
もちろん、嫌味とかではなく、こちらのことを思って、わざわざ言い辛いことを言ってもらったと感じており、申し訳ないと思いつつも、感謝しています。
実際、その後に紹介して頂いた方や、商工会へ行くことを促されて会わせて頂いた方々も、仕事の業種や内容は違えど、同等かそれ以上の高い基準値を当然のように設けて過ごしている人ばかり。
中卒の焼き鳥屋のおっちゃんや、ギャル風のネイル店経営者が普通に年収1000万以上稼いでいるような世界です。
学歴や経歴、小賢しい地頭やセンスなど、何の役にも立ちません。
最低でも時給3000円は超える仕事をしないと、社会保障を考えたら正社員で働いていた方がマシ、話にならない、という空気感です。
そういう基準値に一度触れてしまうと、あまり意識をしなくても、単価の安い仕事を請けたり、働ける時に働かなかったりすることに、ものすごく心理的な抵抗を覚えるようになります。
また、ハードワークに任せた肉体労働の力技に対しても、どうやって仕組み化をするのか、効率化をするのか考え出し、やるべきではないと思ったことは損切りをしたり、根本から改善する方法を探るようになります。
逆に、普段から自分と同じ業種の仕事をしている人、自分と同じ基準値で商売をやっている人としか関わらないと、今やっていることに何一つ疑問を持たないので、そういった向上心や危機感を持つ機会が失われていきます。
エンジニア界隈で言えば、未経験同士で交流するだけでなく、既に就業済みのバリバリの経験者、WEB業界以外のエンジニア、異業種出身の人など、居心地が悪くなるような場に飛び込めば、似たような状態になるのは、未経験の立場でも想像がつきます。
少なくとも商売においては、自分より一段二段稼いでいる人や商流がずっと上の人の話を聞くと、確実に何かしらの刺激になり、このまま現状維持ではマズいという危機感が沸いてくるので。
かく言う自分も、最近は知らない環境に飛び込んでいないので、今後は都内に出る機会が多い地の利を生かして、普段行かないところに積極的に足を運んでいきたいと思います。
sass関連の環境構築
先日からウェブカツのHTML上級にあたる
宿題に取り掛かっており、今日は一日掛かりっきりでした。
正直、本編でざっと触れて、ボリュームや難易度を想像すると
そこまで難しいと思っていなかったので、軽い気持ちで
取り組み始めたところ、色々なところでハマってしまい、
想像していた以上に苦戦しています。
1.sassの環境構築
レスポンシブ対応のサイトを作るにあたり、
sassという、より保守性の高いcss記法を使い始めました。
sassは、それ自体の内容を編集しただけでは
ファイルの更新を自動で監視してくれるライブラリを
インストールして、ターミナルで実行する必要があります。
しかし、このインストールやコマンドの実行を行う為に
適切に設定作業を行う必要があり、一つでも間違えてしまうと
本来の設定と違う状態になり、sassが全く使えません。
また、正しい手順で行っていたとしても、
パソコンの環境毎では動かなかったりすることがあり、
追加のオプションをコマンドに含める必要もあったりします。
私の場合は、サンプルプログラムと自分で入れるプログラムを
似たような名前のフォルダにしてしまっていた為、作業の一部に
抜け漏れがあったせいか、なかなか正常に動いてくれませんでした。
そんなこんなであっという間に2時間が経過。
その後、画面の挙動を確認したり、CSSを変更した後の
画面の見え方や挙動を確認する作業に移ったのですが、
その後も何度か、変更を加えたファイルと、元々用意していた
サンプルファイルが混同して、変更が反映されたのかどうか
確認する作業の手間が結構かかりました。
2.sassのコンパイルが行われているか、常々確認する
これまでの製作・編集作業では、CSSが効いていないとしたら
真っ先に疑っていたのは、ブラウザのキャッシュが残っていて
それをクリアしているかどうかだったのですが、
今後は、sassの吐き出す先のファイルを正しく参照しているか、
そもそも、ネットワークは確実に繋がっていて、
sassのコンパイル作業自体が正しく行われているかどうか、
この辺りにしっかり意識を回す必要があると感じます。
あれもこれもと変更を試した末、何も効果が出なかった原因が
「sassのコンパイルが機能していない、エラーが出ている」
「自動コンパイル機能が何故か途中で止まっていた」
だったりすると、試した変更点を１から全部また一つ一つ
確認する戻り作業が発生してしまいます。
メディアクエリ、マップ変数なども一通り触りましたが、
実際にやってみると分からないことがかなり多いです。
とにかく書きまくって試行錯誤して覚えるしかないと感じます。
そんなこんなで、
・メニューボタンの非表示化
・回り込み要素による右側の余白対応
は、明日に持ち越しです。
一つ一つ確認して粘り強くやっていけば
必ず解決するはずなので、引き続き頑張ります
