ノーコード開発ツール
アプリを作るためには、RubyやPython、C言語やJavaなどプログラミング言語を用いることがスタンダードな開発方法です。
ですが、ソースコードを書かずに視覚的にアプリ開発をするのがノーコード開発です。
ノーコード開発
先ほども申し上げた通り、ソースコードを記述せず直感的にシステムを作り上げることができる開発のことです。
基本的にはドラックアンドドロップでテキストボックスやボタン・入力ボックスを設置し、そのボタンや入力ボックスの動きをメニューから選択すれば、動作もつけることができます。
そのため、詳細に設計をせずとも開発することが可能であり、小規模のアプリであれば数日で公開することも可能にしました。スピード感のある開発が得意とも言えます。
もちろん基本的なプログラミングの知識を持っていればデータベースの考え方や、テーブル作成、画面遷移などの実装方法も掴みやすく慣れるのにも時間はかからないでしょう。
デメリット
プラットフォームへの依存度が高く、開発環境が限られているため、別の開発環境へ移そうとすると不具合が生じてしまう可能性もあります。
また、ノーコード開発ツールを利用する場合は、プラグインも用意されていますが、拡張性に限りがあり独自性は中々出せないようです。
そしてノーコード開発を提供しているのも海外製のものが多いため、日本語に対応しておらず、英語が苦手な方は翻訳しながら使い方を理解する必要があるので、最初のうちは思うように開発が進まないこともあります。私も英語を勉強中のため翻訳しながら四苦八苦触ってます。
とはいっても、社内の業務改善のためなど限定的に使用する目的であれば、ノーコード開発ツールを利用したアプリは環境が限定されていても問題なく利用することができ、独自性が出せなくても見た目の自由度は高いので、差別化を図ることも可能です。
また、日本語対応しているノーコード開発ツールもいくつかあるので、英語に不安がある方は日本語対応しているものを利用することで開発しやすくなります。
現在CMしているサイボウズも、このノーコード開発ツールの一つです。
前職でサイボウズを利用したアプリを社内で使用していましたが、こんな身近にノーコードツールを利用していた例があり驚いております。
ノーコード開発ツールをほんの少し触ってみた
海外製のノーコード開発ツールである「Bubble」を少し触ってみたところ、見た目を作るのにも「Design」から感覚的にエレメント（テキストボックスや入力ボックスといったアイテムのこと）を配置することができ、機能を使いこなせればおしゃれなページを作ることも夢じゃないと思いました。
（まだ使いこなせてないのでおしゃれな見た目を作ることができてません）
また、データベースもメニューにある「Data」からボタンひとつでテーブルを作成でき、フィールド（カラムのこと）も「Create a new field」ボタンを押すだけで追加することができます。
Rubyで言うコントローラーの設定、つまり動作の部分は「Workflow」から設定したり、「Design」で配置したエレメントから設定することも可能です。
感想
なんといっても感覚的に作成していけるので、「プログラミングでアプリ開発している」というよりは「システム開発してる」という感覚になります。どちらもほぼ同じ意味ではありますが作っている時の「次どうしようかな」とか「これ実装しよう」など作っていく順番や感じ方が違いますね。
DB作成して見た目(view)作って動作(controller)をつけるという大まかな流れは、どの言語やツールを使っていたとしてもさほど変わりはないですが、思いついたことを気軽に実装できる点においてはノーコード開発ツールの強みかな、と思いました。
もう少し触って簡単なアプリをさまざまなノーコード開発ツールを使って作成してみたいです！
学習成果発表会に参加しました！
半年間のプログラミング学習の集大成として、受講先で開催される学習成果発表会に参加してきました。
その勢いでブログを執筆しています笑
皆つまづくところは一緒なんだなぁ、と安心したのもありますし、他の方のオリジナルアプリについてお話を聞けて良い刺激になりました。
自分も立ち止まってる場合じゃないな、とお尻に火がつきました！
まずはレイアウトの壁を一枚ずつ崩していきたいと思います。
オリジナルアプリのテーマ選びもその人の良さが現れており完成が待ち遠しいです！
会社の仕事を円滑に回せるアプリであったり、思い出がテーマの育児サポートアプリであったり、コスメを身近なものにするアプリであったり、個性豊かで素敵な方々と半年間同じ学習をできたこと、本当に嬉しく思います。
ただ、参加人数の関係でルームが分かれてしまい、全員分の発表がリアルタイムで聞けなかったのはちょっと残念だったな、と。聞きたい方がいっぱいいたので。致し方なしですが。
ここまで頑張ってこれたのは、同じ期間で同じものを学習している仲間がいるということも大きな要因だと思います。とても励みになりました。
もうそんなところまで進んでるの！すごい！とか、そこはこないだ取り組んだところだ！そうだよね！応援してる！などモチベーションの維持にとてもお世話になっており、一人だけど一人じゃない気持ちになれていたので、やはり人パワーは大きいな、と感じます。
と、勢いで記事を書きましたが、この発表会で得た刺激を大事にしていきたいです！
勢いもまたパワーをとても持っているので、更に学習に取り組んで、自分自身のパワーを更に強くしていこうと思える発表会でした！
自分の言語化について
今回はプログラミングではなく、自身の言語化についてご紹介していきます。
学習中お世話になった方に文章の言語化が上手とお褒めの言葉をいただいたことで、ちょっと自信がついたため、改めて自分の言語化について考えてみました。
大事にしていること
一番大事にしていることはどう表現したら相手に伝わるかです。コレが大前提としてあります。むしろこれが言語化の本質と考えてます。
言語化の大部分は「伝えたいことがある、だから言語化する」のであり、相手に伝えたいことがあるということは、同僚であっても、上司であっても、友達であっても、見知らぬ人でさえも、その時の自分にとって何かかしらの関係があるから言葉にすることがほとんどですよね。
しかし言葉にするけど相手に伝わっていなければ、言葉にした情報は情報ではないと言えます。
物事を説明するとき、業界用語や専門用語がよくわからない相手に専門用語で説明しても「この人何喋ってるかわからん理解できん、もっとわかりやすく教えて」となりますよね。
もっと踏み込んだ具体例を挙げると、便利なアプリがあったとして「これ便利だよ」だけでは、何がどうなっていて便利なのか相手には伝わりません。ただ便利であるという情報しかないので、自分にとって便利でも「便利だよ」って言われただけでは、相手にとって便利か便利じゃないか判断しようがないのです。
そのアプリの何がその人にとって便利なのかを伝えられなければ、相手は「ふーん、よかったね」で終わってしまいます。
せっかく便利なアプリを見つけたのに、どんなアプリなのかを伝えることができないと自分の感動を伝えることができないのです。
もしも言語化できれば
「前まで使ってたカレンダーアプリは5色までしか設定できなかったから細かく使い分けることができなくて意外と不便だったんだよね。でもね、このアプリは24色も設定できるから家族のスケジュールと家事・仕事・趣味・通院予定とか分けられるし、娘のスケジュールも学校行事と塾とって別に分けられるからわかりやすくなったの！詳細ページも予定を入力した順じゃなくて、バーチカルタイプで見やすいんだよ」
とアプリのメリットをいくつか挙げることで
「へーそうなんだ、色が多いと分けられるから便利だよね」と便利な部分に賛同してくれる率が高くなります。相手にとって判断できる情報を渡せばその人にとっての良い悪いは判断できるようになります。
表現の仕方は人それぞれであり語彙力によりますが、詳細を伝えることでより伝わりやすくなると考えてます。
相手に自分の考えていることが伝わると単純に嬉しいですよね。
とは言っても。
とは言えるけど、言語化っていざ実行に移すと難しいんです。本当に。
私は口下手なので、対面の会話やビデオ通話などリアルタイムの言語化にとても弱いです。プレゼンではある程度台本を作って臨むこともありますが、後になって「あー言えばよかった、こう言えばよかった」となることがほとんどです。例え台本があったとしても。なので「喋る」ことはまだまだ未熟のため練習中ですね。
文章の言語化
文章の言語化はじっくり考えながら言葉を構築するため、こちらの方がハードルが低く感じます。
言語化していて、文章の流れでここは先にした方がわかりやすいな、この言葉じゃなくて別の言い方がないかChatGPTに聞いてみよう、と自分の中で整理しながら情報を視覚化していくので言語化の練習としてみると向いているんじゃないかと個人的には思います。
ただ、伝わるかどうかも考えながらなので言葉だけで伝えようとすると、どうしても文章が長くなることが自身の最近の悩みですね。なので、今は端的に重要なことをまとめることを意識してます。背景がわからないと伝わりづらいかなー、とか前提を伝えないと流れが汲みにくいかもしれない、など考えてしまうためズバっと言語化できる人本当に尊敬します。
言語化の学習
ここからは自身の言語化の学習や練習についてお話ししていきます。
コンテンツについて単語でもなんでも良いから感想やメモをバーーーっとリアルタイムで書き留めて文字列という形にすることから始めました。
いくつかの学習系動画を倍速視聴しながらメモを書き殴り、一通り視聴が終わってから人に伝える体で全体をまとめる、ということをひたすら1ヶ月間繰り返すことで、なんとか読むことのできる文章を書けるようになった、みたいです。（実感はイマイチわかりませんでしたが、読み返すと明らかに初期の文章と1ヶ月後の文章とでは違いました）
注意することは「ありのままを書く」ことです。伝えることは意識しつつ自分らしさを残すためにありのまま。例えば「うわー難しい！わからなかった！明日またここやろう！」という感想を文章にすると「とても難しいと感じました。今日は理解できなかったので明日また取り組みます。」とカッコよく言い換えたくなるのです。言い換えるのも状況や人それぞれですが、自分が感じたままの文章はエネルギーを持っているので感情も含めて伝わりやすいと思います。
ここまでで私自身が取り組んだことをまとめると
1. とにかくメモをリアルタイムでとっていく（感情も含めて） 2. 一通りメモを取ったら自分の感情と一緒に人に伝える形でまとめる
なんだ、簡単じゃん。と思っても実際取り組むと言語化するのは難しいし、さらには思ったことをそのまま言語化するの恥ずかしいと感じると思います。私は書いたことをそのまま人に読んでもらってたので余計に恥ずかしかったですね。だって「カッコよく見せるための皮」を被った文章ではなかったからメチャクチャでした笑
また、言語化する上で自然と本を読むようになりました。それまではあまり読書をしてこなかったので、自分でもったいないなぁとしみじみ思います。
その分出会ってない本が多いので、一冊一冊との出会いを大事にしていこうと思いました。
逸れてしまいましたが、読む本もなんでも良いです。絵本・哲学・文学・啓発・エッセイ…自分が読みたいと思ったものを読むのが一番です。
絵本なんか端的に文章がまとまってる代表ではないか、と最近考えることが多いので、時間があれば読み漁ってみたいですね。
手軽にサクッとできる言語化の練習は「食レポ」が最たるものでないかと思います。
美味しいと感じた理由、どんな味がするか、どんな時に食べたくなるかなど、考えてメモをとると良いかもしれません。
まとめ
・言語化することは人に伝える能力が育つ
・普段から感想を自覚し、メモを取ることで徐々に言語化に慣れていく
以前「物事のいろんなことに感想を持つ」ことを意識しているというお話を伺った時、自分の言語化に対する意識が低かった！と感じたので、そこは私も忘れないように気をつけようと強く思いました。
感想は人それぞれ絶対抱くものですが、意識していないと感想を持っていることに気がつかないんですよね。だから読書感想文や、話を聞いた時の質問や感想何かありますかー？に詰まってしまうことが多いのかな、と考えました。（私も心当たりがありすぎてグウゥとなります）
「思想と体現はバランスが大事、どちらか一方が優れていても片方がダメダメだと、せっかく良いものを持っているのに台無しになってしまう、そんなことで損するのは残念」という言葉が頭にずっと残ってますが、本当にその通りだと思います。
仕事で業務連絡をするときに、言語化をちょっと意識するだけで円滑にできるのに勿体無い人だなぁなんて思ったりすることがあります。
言語化は学習だけでなく、日常にも活かせることだらけです。むしろ活かせることしかないです。
言語化について改めて記事にすることで、自分自身ももっともっと言語化を鍛えていきたいと強く思いました。
【アルゴリズム問題】閏年の判定
閏年を判定するアルゴリズム問題も目にします。
グレゴリオ歴における閏年の条件として
1. 年が4で割り切れる（大前提の要件） 2. 年が100で割り切れる 3. 年が100で割り切れるが400では割り切れない
1の条件は言葉の通りなのであまり深く考えることはないのですが、2と3が厄介そうですね。
今回はこの閏年を判定するコードを考えていきましょう。
必要な知識
このアルゴリズム問題に必要となる知識は
1. 条件分岐( if / when ) 2. 論理演算子( && / || ) 3. 配列 4. getsメソッド(判定させたい年月を入力するため)
シンプルですね！これだけで閏年を判定することができます。
条件をひとまず置いておくとして、早速最低限の雛形を作っていきましょう。
閏年判定メソッドを起動させるための雛形
今回の前提条件として「閏年がわかる機能がついた年月判定ツール」ということを念頭に置いてください。
前提条件を理解できたら、まずは必要な知識の3番を使ってササっと雛形を完成させちゃいましょう。
def get_uru_days(year, month)
month_days == [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
end
p "年を入力してください"
year = gets.to_i
p "月を入力してください"
month = gets.to_i
days = get_uru_days(year, month)
p "#{year}年#{month}月は#{days}日間あります"
あくまでも年月の判定ツールとして相手が知りたい年月を入力できるよう変数定義します。
1ヶ月の日にちは[28, 29, 30, 31]のどれかなのでdaysは閏年判定メソッドを呼び出し、daysを定義できるようにしましょう。
get_uru_daysメソッドを呼び出すため、入力してもらったyearとmonthを引数として指定します。
month_daysで日にちを配列として格納します。（恐らく賛否両論かと。好みの問題にもなってきますが、今回先に2月かそれ以外かで考えていくので配列を使用します。）
何月何日のこと？
耳タコですが、年月判定ツールなので2月だけでなく他の月についても日付を定義できるようにします。
ここのフェーズでは「2月か、それ以外の月であれば30日なのか、31なのか」を考えていきましょう。
1. 2月かそれ以外か
引数で渡されたyearが2の場合とそうでない場合と言い換えると、
1. もしもyearが2だったら 2. yearが2の時
の2パターンに分けられます。今回は先にもしもyearが2だったらで考えていきましょう。
もしも、なので使用する条件分岐はifですね。
if month == 2 # 閏年判定内容 else #2月ではない方 end
month == 2であった場合はさらに年について考える必要があるので一度ここまでにします。
2. 2月ではない方
次に2月ではない時の処理についてです。2月でなければ月の日数は30か31なので,monthの引数をどうにか処理すれば配列に格納したものを引き出せそうですね。
if month == 2 # 後ほど閏年判定の処理を記載 else days = month_days[month -1] end
month - 1をしたのは配列を呼び出す際に月がズレてしまうからです。というのも配列は0番始まりなので、monthが5で入力された場合は0から数えて0,1,2,3,4,5と実際には6番目が呼び出されてしまいます。そうなると6番目は30が格納されているので、5月は30日です、といったポンコツツールになってしまうためしっかり-1をしましょう。
ここまでで2月かそうでないかを判別することができました。
年が4で割り切れる
ここはサクッとyearが4で割り切れる場合は閏年とそうでない場合との条件分岐を作っちゃいましょう。
month = 2の場合にyearが4で割り切れる場合はとりあえず全て閏年と考えてみます。
「割り切れる」場合を考えるので「year ÷ 4 の余りは 0」になれば良いので演算子は「%」を使用します。
割り切れない場合は28日です。
if year % 4 == 0 days = 29 else days = 28 end
days = 28ですが、せっかく配列があるのでdays = month_day[month - 1]としてもOKです。(個人的には簡潔な28の方が気持ち可読性面で好みです。遠い未来はわかりませんが、2月自体28日もしくは29日というのは不変的な決まりなので無理やり配列を使う必要もないかと思ってます。)
ここまでで2月でない場合の処理が決まったので、上記のmonth == 2の条件式と合体させます。
if month == 2
if year % 4 == 0
days = 29
else
days = 28
end
else
days = month_days[month -1]
end
ifの条件をネストさせることで「2月の場合」であり「yearが4で割り切れる時」と2つの条件と合致する場合に分岐することができます。
踏み込むと「2月の場合」でないときは「days = 28」と閏年ではない場合の条件も7割作成できました。
年が100で割り切れるけど、400では割り切れない時は閏年ではない
恐らく最大の難関であるこの部分について見ていきましょう。
年が「100で割り切れる時」と「400で割り切れない時」なので2つの条件式をまずは単純に考えていきます。
先ほど4で割り切れる時と同じように「100で割り切れる時」を条件式にすると、year % 100 == 0となります。
続いて「400で割り切れない時」を条件式にしたい場合は演算子の「!」を使用します。
「!」は否定を表し、使い方としては「10÷3は0ではありません」を表す時には10 % 3 !=0と表現し「=」の前に配置してあげることで否定の意味になります。つまり、year ÷ 400は0ではないという指示にしたい今回にぴったりの演算子です。
もうここまで読んでくれた方はわかりきっているかと思いますが、改めて「year ÷ 400は0ではない」を条件式にするとyear % 400 != 0と記述することができますね。
条件式がわかったところで、次に条件分について考えていきます。
「4で割り切れる」条件は先ほど考えたのでちょっと端っこに置いておいて、言葉としてまとめると
閏年の時は「yearが100でも割りきれるし400でも割り切れる」
逆に閏年でない場合は「yearが100で割り切れるけど400では割れない」
となりますね。
この場合より「閏年ではない場合」の方が特殊な状況下の条件であり、当てはまる確率的に低いのでこちらの条件がTrueの場合とFalseの場合で条件分岐を考えていきましょう。
先ほど確認した2つの条件式は「year % 100 == 0」と「year % 400 != 0」でした。両方の条件を満たしていると「閏年ではない」場合Trueの結果を返すように記述します。
if year % 100 == 0 && year % 400 != 0 days = 28 else days = 29 end
「2つの条件式を満たす」という条件式を示すために論旨演算子の&&を使用します。
あとは結果としてdaysを定義するだけです。
この条件分岐を先ほどネストさせたコードに更に合体させてネストします。合体させる場所は「4で割り切れる場合」の部分に更に条件を付け足すのでここにネストさせます。
if month == 2
if year % 4 == 0
if year % 100 == 0 && year % 400 != 0
days = 28
else
days = 29
end
else
days = 28
end
else
days = month_days[month -1]
end
これで閏年判定ツールの処理が完成です。
最初に作った雛形と合体させる
上記で作成した処理と最初に作った雛形に合体させると以下のコードとなります。
def get_uru_days(year, month)
month_days == [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
if month == 2
if year % 4 == 0
if year % 100 == 0 && year % 400 != 0
days = 28
else
days = 29
end
else
days = 28
end
else
days = month_days[month -1]
end
return days
end
p "年を入力してください"
year = gets.to_i
p "月を入力してください"
month = gets.to_i
days = get_uru_days(year, month)
p "#{year}年#{month}月は#{days}日間あります"
return daysで関数の外でも日数を取得できるように返り値として設定します。
ユーザーが知りたい年月について、閏年に対応済みのひと月の日数を返すツールが完成しました。
リファクタリング
完成したとは言ってもifが多いしネストが多くて見づらいですよね。ココからリファクタリングして読みやすくしていきましょう。
（コードを整理して可読性を向上させることをリファクタリングと言います）
まとめられそうなものはyearの条件分岐です。「4で割り切れる」「100で割り切れる」「400で割り切れない」を1行で演算子と論理演算子を利用できそうですね。リファクタリングは言い換えの問題でもあり、視点を変えて考えたりするのでちょっとした頭の体操になります。
まずグレゴリオ歴における閏年の前提条件として「4で割り切れる」は不変のルールです。
しかし1900年は4で割り切れますが閏年ではありません。なぜならば「100で割り切れる」けれど「400では割り切れない」からです。逆にいうと「100で割り切れない」か「400では割り切れる」のであれば閏年です。（例：2000年)
これを条件式にすると(year % 4 == 0 && year % 100 != 0) || year % 400 == 0と考えられます。
これに沿ってリファクタリングすると
if (year % 4 == 0 && year % 100 != 0) || year % 400 == 0 days = 29 else days = 28 end
先ほどよりもシンプルになりました！
def get_uru_days(year, month)
month_days = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
if month == 2
if (year % 4 == 0 && year % 100 != 0) || year % 400 ==0
days = 29
else
days = 28
end
else
days = month_days[month - 1]
end
return days
end
他にも好みの問題ですがリファクタリングするとしたら、month == 2 にifを使用するのでなくwhenを使用するのも良いかもしれません。
def get_days(year, month)
case month
when 1, 3, 5, 7, 8, 10, 12
days = 31
when 4, 6, 9, 11
days = 30
when 2
if (year % 4 == 0 && year % 100 != 0) || year % 400 ==0
days = 29
else
days = 28
end
end
return days
end
閏年の判定処理をメソッドとして独立させるのも可読性が上がるかもしれません。
def leap_year?(year, month)
(year % 4 == 0 && year % 100 != 0) || year % 400 ==0
end
def get_uru_days(year, month)
month_days = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
if month == 2
if leap_year(year, month)
days = 29
else
days = 28
end
else
days = month_days[month - 1]
end
return days
end
コードが十人十色であるようにリファクタリングも十人十色です。今回は3つのリファクタリング案を出しましたが、別の記述をしようと思えば他にも出てきます。
まとめ
・いかに条件を条件式で表せることができるかがコードを記述していく方向性や方針になる。
・リファクタリングすることを前提としてまずは素直に一つずつ処理ができるコードを記述してみる。
コードには読みやすい読みにくいはあれど、正解という正解がないので、相手が読みやすいか、自分が読みやすいコードはどのようなものかを少しずつ少しずつ探っていくことが大事なのかと思いました。
SCSSについて調べてみた
CSSをより記述しやすくするためにSCSSという効率化ができる言語について記事にしていきます。
SCSSでできること
最初にも書いたようにCSSの記述を効率化できるスタイルシート言語記法(拡張言語)の一つです。
CSSでは下記のように記述します。
.item{
background: #ffffff;
font-size: 12px
color: #000000
}
.item a{
color: #0000cd;
text-decoration: none
}
基本的に一つ一つのセレクタごとに記述が必要であったり、同じ記述を繰り返さなければいけない場合もあります。（特にカラーコードは頻出ですよね）
SCSSでは同じ記述を繰り返さなくても済むよう様々な方法が用意されています。
1. ネストできる 2. 同じスタイルを何回も記述しなくても済む(変数を使用することができる) 3. あらかじめ配列に格納した値を取り出すことができる 4. モジュール化できる
他にも条件分岐で処理を変更できたり、コードを簡略化させることが得意な言語だなーと個人的に感想を抱きました。
上記のCSSコードをSCSSで記述すると
$color: #000000, #ffffff, #0000cd... //配列の記述
.item{
background: nth($colors, 2);
font-size: 12px
color: nth($colors,1)
a { //ここからネスト
color: nth($colors,3)
text-decoration: none
} //ここまでネスト
}
あらかじめ使用する色を格納したcolorsという配列を用いて呼び出したり、.itemセレクタにかかるaタグ部分も別にCSSを記述する必要がないので可読性をあげてくれます。
今回CSS自体が短く簡潔なものだったため、あまり短縮できたり可読性が上がったりの恩恵を受けているように思えませんが、実際のCSSは100行以上に渡る場合が多い上一つ一つのセレクタに対し記述が必要です。人間は少しでも楽したい生き物なので省略できることはなるべく省略したいですよね。
例えば、カラーコードであれば複数回記述している内どちらかの記述において4文字目と5文字がうっかり逆に入力していた、なんてこともあるかもしれません。そんな時に配列から呼び出せれば、複雑なカラーコードを何回も打ち込まずに済むためミスもグッと減ります。
また、ネストすることでセレクタ毎の管理も容易になり可読性も上がります。上記の例で言えばCSSでは.itemを2回打ち込んでますが、片方をうっかり.itenにしてしまい想定していたはずのレイアウトが崩れてしまう、なんてことも起こりうるわけです。（経験談です）
更に、通常CSSはスタイルシート1つで管理していきますが、SCSSはモジュール化が可能なため機能毎にファイルを分けて管理をすることも可能です。
CSSだとファイルはstyle.cssのみですが、SCSSを使用することでmain.scssとheder.scssとfooter.scssと別ファイルでCSSの管理をすることができ、どこにどんなCSSを適用させているかを管理するのが容易になるため修正したい場合にどこを参照すれば良いかもわかりやすくなります。
呼び出したい場合もstylesheet.css内に
@use "main"; @use "header"; @use "footer";
を記述することでそれぞれの記述を呼び出すことができます。
SCSSの注意点として.scssのファイルだけではレイアウトに反映されない、ということです。
CSSを効率的にする拡張言語のため、SCSS自体にはレイアウトに対する効力を持ちません。そのため反映するには.scssファイルを.cssファイルにする必要があります。（コンパイルと言います）
CSSは変数定義したり配列を使用することがそもそもできないため、SCSSで記述したものをCSSの形に改めて変換する作業が必要です。
それぞれのコーディングアプリの拡張機能を使用したり、ターミナルにてsassコマンドを実行しコンパイルする必要があります。（今回こちらは割愛致します。）
RubyでSCSSを適用させるには？
RubyでSCSSを適用させるにはgemのインストールが必要です。
と言っても、Gemfile内に#でコメントアウトされているgem "sassc-rails"の#を消し、ターミナルでbundle install`を実行するだけで、お手軽にSCSSを適用させることができます。
まとめ
・SCSSはCSSの拡張言語であり、繰り返しの記述を減らしたり、可読性の向上が見込める有用な言語である。
・あくまで拡張言語のため、SCSSで記述されたものをCSSにコンパイラする必要がある。
・Rubyにおいては使用するための準備がすでに組み込まれており、Gemfile内のコメントアウトを削除することで使用することができる。
ファイルを分けることができたり、変数や配列を使用したり、可読性がグッと上がる素敵な言語だと思いました。修正したい部分を探すのが容易になるのでSCSSをしっかり使いこなせるようにしていきたいですね！
ちなみに私はVScodeを使用しているので、コンパイルするため拡張機能のLive Sass compilerを利用しています。ボタンひとつでコンパイルできるので超便利です。
Pythonで文字を画面上に出力してみた
今回は表題の通りPythonのことについて書いていきます。
私が半年間プログラミングスクールで学んできたのはRubyですが、武器を増やしたいとも常々考えていたので人気のPythonを少し齧ってみました。
なぜPythonなのか
どうしてPythonを選んだのか、という部分についてです。
1. 機械学習やAI化という分野において注目されている言語 2. 他の言語もさらっとコードを見たところパッと見一番Rubyに似ていると感じたので、今の自分の第二言語として学習しやすそうだと感じた。(もちろん言語の名前も違うので全て一緒というわけではない。) 3. 個人的なことですが、知り合いが現在メインで取り扱っている言語で学習前から興味があった 4. 今現在人気なので資料が多い
といった理由から興味が湧いたので少しずつ学んでみようと選び、最低限の環境を構築し取り組んでみました。
基本的にこのブログでPythonを扱う場合、Rubyと似ているが違うところはどういったところなのか、という比較しながら見ていこうと考えてます。
Rubyを学んで次の言語どうしようかなって人にPythonの扉を開くお手伝いもできたら嬉しいです
文字を出力するアルゴリズム構築
ようやく表題の件に触れていきます。
Rubyでは
puts "出力する文字列" # (出力結果) => 出力する文字列
と記述していた部分で、本当に最低限の基礎的な部分です。
上記がPythonの場合
print("出力する文字列")
# (出力結果) => 出力する文字列
という記述になります。
putsがprintに変化し、()も必要です。()がないとsyntax errorになってしまうので注意しましょう。
また、数値についてもRubyと同様に""は必要ありません。
print(39) # (出力結果) => 39
ここまでで違いといえばputsがprint()に変化しただけなので何も難しいことはありませんよね。
文字列の中で変数を出力したい
Rubyで変数で定義した値は#{変数名}で出力していました。
実際に記述していくと
ave = (80 + 30 + 90) / 3
puts "平均点は#{ave}点です。"
# (出力結果) => 平均点は66点です。
上記のように記述することで変数を出力することができます。 対してPythonにおいて変数の出力方法は複数あります。
ave = (80 + 30 + 90) /3
ave = int(ave) # 注1
1つ目の方法
print("3教科の平均点は",ave,"点です。")
# (出力結果) => 平均点は 66点 です。
2つ目の方法
print("3教科の平均点は{}点です。".format(ave))
# (出力結果) => 平均点は66点です。
3つ目の方法
print(f"3教科の平均点は{ave}点です。")
# (出力結果) => 平均点は66点です。
注1.Rubyと違い、計算したものは少数点も含まれるため、整数として取り扱う場合メソッドで指定してあげる必要があります。 今回は小数点切り捨てでint()を使用してます。
恐らく時と場合によるでしょうが、一番スタンダードなのは3番目の例であるprint(f"文字列{変数名}")がよく使用されていそうだな、と感じました。
他にもprint("文字列{}".format(変数名))であったり、print("文字列",変数名,"文字列")の方法もありますが、可読性に優れている点として最初に挙げたprint(f"文字列{変数名}")が個人的にはRubyに似ていて馴染みのある{}の中に変数名を入れる方法が記述しやすいです。
ちょっとした文字列と数値のみであれば上記の例だと1つ目の方法で十分かと思います。ただ、スペースに注意しないと余計な空白ができて位しまうので注意です。
2つ目の出力方法は変数が一つであれば混乱が起きにくいのですが、変数は複数ある場合もあります。そんな時、format(変数名)にどうすれば良いか、という疑問が沸いてきますよね。
変数定義は省略させていただきますが、下記が複数ある場合の例です。
print("国語は{}点、英語は{}点、数学は{}点でした".format(kokuko, eigo, suugaku)
# (出力結果) => 国語は80点、英語は30点、数学は90点でした。
とformat(変数名, 変数名…)と「 , 」で変数と変数の間を区切ることで複数使用できます。
ただ、この時{}の順番と変数名の順番に注意しなければなりません。
一つ目の変数は一つ目の{}、二つ目の変数は二つ目の{}、といったように.format()で変数を指定する場合、順番が違えばもちろん出力内容が変わってしまうので注意です。
上記の.format()の変数名を入れ替えると
print("国語は{}点、英語は{}点、数学は{}点でした".format(eigo, suugaku, kokugo))
# (出力結果) => 国語は30点、英語は90点、数学は80点でした。
と学力結果を出すプログラムであれば生徒はもちろんのこと先生の重大なミスになりかねません。
3つ目の出力方法に関しては{変数名}で直接指定するため、命名にさえ気をつければ順番を気にすることもないしスペースを気にすることもないしどの変数をどこに使っているのか一目瞭然なのでミスはガクッと減少するでしょう
そのため、print(f"文字列{変数名}")を使用する機会が圧倒的に多いはずです。
（まだ学習したてでどの方法がどのタイミングで生きてくるかはわかりませんが）
まとめ
・RubyとPythonは似ているため、Rubyを学習した方であればPythonに取り組み易いはず。
・Pythonでの最低限出力する方法はprint("文字列")
・変数の出力を行いたい場合print(f"文字列{変数名}文字列")が可読性が高くシンプルな記述である。
AWSのS3を利用する際に出会ったエラー
私がよくエラーと遭遇しているため、このブログでもエラーについて取り扱うことが多くなってきました。
今回もタイトル通り出会ったエラーについて短めにサクッとお話ししていきます。
S3とは？
タイトルのS3とはAWS（Amazon Web Services）が提供しているストレージ（保管庫）のことです。
これを利用するために諸々設定し、さぁいよいよローカル環境で画像をアップロードしてみるぞ！となった時にエラーはやってきました。
AWS::MissingCredentialsError unable to sign request without credentials set
端的にいうと「認証情報が見つかりませんでした」と言われています。
S3を適用する為、外部から操作できないようAWS_ACCESS_KEY_IDとAWS_SECRET_ACCES_KEYの環境変数を設定していました。
その際にAWSと入力しなければならないところを片方のみAWXと入力していたため、そりゃ認証通りませんわなぁ…と。
AWSに直して、source ~/.zshrcを実行し環境変数を使えるようにします。
再度画像をアップロードしてみたところ、無事に理想通りの挙動になりました。
