投稿

ラベル(メモ)が付いた投稿を表示しています

Nuxt.jsを短期間でFirebaseにデプロイしてCircleCIで自動デプロイをするところまでを設定するマニュアル

イメージ
楽をするのは良いことだ 環境 構築 Firebase Nuxt.js 楽をするのは良いことだ ということで、個人的に好きで使っているNuxt.jsをFirebaseにデプロイし、その後Githubにプッシュするたびに自動的にデプロイされるように設定するまでをこの記事では解説しておきます。 Firebase使ってみた こちらの記事を参考にさせていただきました。 環境 OSX Catalina npm version6.14.6 node.js v12.18.4 構築 Firebase まず Firebase にログインします。 Googleアカウントが必要となるので持っていない方は取得してください。 こちらのページにアクセスしたら使ってみるをクリックし、以下の個人のプロジェクトを管理するページに移ってください。 そしてプロジェクトを追加をクリックし、任意のプロジェクト名を設定し、プロジェクトを作成してください。 これでプロジェクトを作成できました! ひとまずターミナルを開き、以下のコマンドを使ってFirebase CLIをインストールしておきましょう。 $ npm install -g firebase-tools そしてついでにログインをしておきましょう。 $ firebase login 次はNuxtプロジェクトを作成し、Firebaseとつないでデプロイしてみましょう。 Nuxt.js mkdir firebase cd firebase vue init nuxt-community/starter-template sample こちらでfirebaseディレクトリ内にNuxtのテンプレートが作成されました。 そして次にfirebaseとつなぐ必要があるので以下のコマンドをターミナルで実行してください。 また、ここではHostingを選択してください。 $ firebase init MacBook-Pro sample % firebase init ######## #### ######## ######## ######## ### ###### ######## ## ## ##

SwiftのCoreDataってなんやねんって話

イメージ
忘れることが多いので 逐一メモしておく。 間違えている場合は親切な方が指摘してくれると思う。 で、コアデータってなんやねんという話。 調べてみたら、 Apple系の製品(WatchOSとかMacOSも含む)アプリ開発ではデバイス単体でオフラインでもアプリのデータを使えるようにしたり、一時的なデータをキャッシュしたりとかするためにコアデータフレームワークなる仕組みでデータを管理してるんだそうな。 それらの特徴としては、 アプリケーションにおけるモデルレイヤにあたる部分 データを溜めて、取り出して、更新して、削除ができる オブジェクトグラフを管理できる 特別な実装をしなくてもUNDO/REDOができる 一時的なデータをキャッシュできる 大きな枠組としてはデータベースではない (一般的にはSQLiteを使う事が多いみたい) 特徴的にはこんな感じっぽい。 SQLiteってデータベースの枠組みに入るんちゃうんかい・・・と思ったけど、バイナリデータとかXMLファイルで管理することもあるらしく、くくりやすくするためにざっくりとまとめたらそうなったみたい。 あまり納得は言っていない。 オブジェクトグラフというのは例えば本があった時にそれに付随するその本の筆者やジャンルなどの付随情報をグラフ構造で管理している、みたいな形式のことらしい。 データベースを使うんだろうなぁと個人的には思っていたので個人的には衝撃。

Pythonで学ぶスタック

イメージ
スタック スタックについて Pythonでのスタック利用例 Pythonでの表記法と注意点 連結リストの要素を逆転させる 逆ポーランド記法の計算 ディレクトリ構造の短縮化 スタック について改めて使い道を模索してみたのでメモ。 スタックについて 底のある箱の中に積み木を積んでいくイメージ。 いわゆるLIFO(last in first out)、最後に入れたものを最初に取り出す、というデータ構造。 要素を取り出す時の操作を pop 、要素を入れる時の操作を push という。 スタックを連結リスト、もしくは配列で実装した場合のpop、pushの操作はO(1)の計算量となります。 Pythonでのスタック利用例 Pythonでの表記法と注意点 他の言語と同様に、Pythonでも Stack が組み込み関数として用意されています。 ここで注意すべきなのは上記で用意したPythonでリストを用いてスタックを表す場合には push ではなく、 append を使う点です。 スタックとして使う場合は以下のように要素の出し入れを行います。 >> > stack . append ( 6 ) >> > stack . append ( 7 ) >> > stack [ 3 , 4 , 5 , 6 , 7 ] >> > stack . pop ( ) 7 >> > stack [ 3 , 4 , 5 , 6 ] >> > stack . pop ( ) 6 >> > stack . pop ( ) 5 >> > stack [ 3 , 4 ] 他にもスタックには様々な使い道があります。 連結リストの要素を逆転させる def reverse_linked_list ( head ) : nodes = [ ] while head : nodes . append ( head . data ) head = head . next 逆ポーランド記法の計算

LeetCodeのDatabaseカテゴリで見つけたTRUNCATE TABLEについて

イメージ
LeetCodeのDatabase問題にて。 181. Employees Earning More Than Their Managers という問題を解いた時の話。 LeetCodeのDatabaseカテゴリの問題では SQL Schema という欄があり、どういったクエリを実行して該当テーブルが作成されているか、またその中に入っているデータはどういったものかを見ることができる。 その中に TRUNCATE TABLE Employee という一文を見つけた。 Employeeはテーブル名なので TRUNCATE TABLE テーブル名 という使い方をするものなのだろう。 恥ずかしながら知らなかったので調べてみたところ、指定したテーブルの全てのデータを削除するという内容らしい。 これまではそういった操作はDELETE文で実行していたが、どうやらTRUNCATE TABLE文には以下のようなメリットがあるらしい。 オートインクリメントの初期化 大量のデータが存在する場合はDELETE文よりも高速であること オートインクリメントの初期化がされるのは知りませんでした。確かにDELETE文だと初期化されなかった記憶があるので助かります。 削除が高速なのはDELETE文はあくまで特定のデータを削除することに特化しているからなのだろうか?確かに全て消去しかないのと特定の条件を付けられるものだと後者の方が処理は複雑になる傾向があるが。ここら辺も根本的な理由を調べる機会を設けたいな。 一方で、DELETE文を実行した際のログなどを記録するようなトリガーを設定していても、TRUNCATE TABLE文はDELETE文とは関係ないので当然追跡はできません。そこには注意が必要ですね。

特定の値まで素数を生み出すアルゴリズム in Python3

イメージ
特定の値まで素数を生み出すアルゴリズムとか 以下のようにリストで真偽値を管理するやり方で書くといいらしい。 Elements of Programming Interviews in Python  より。 # Given n, return all primes up to and including n. def generate_primes(n): primes = [] is_prime = [False,False] + [True] * (n-1) for p in range(2,n+1): if is_prime[p]: primes.append(p) for i in range(p*2,n+1,p): is_prime[i] = False return primes n = 100 print(generate_primes(n)) # [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97]