Kuehar's Blog

どっちでもいいじゃん、そう思っていました for文とWhile文を使うシチュエーションについて深く考えたことがなかったのです。 正直できることにほとんど差がないし すると、 コーディングを支える技術――成り立ちから学ぶプログラミング作法 を読んでいるときにどちらも一緒ならばfor文の方が読みやすいよ！と書いていたので確かに！と思ったのでメモ。 そう述べているメインの理由として例を見ながら考えてみます。 C言語でwhile文が要素が以下のように散らばるのに対して、 i = 0 while ( i < N ) { printf ( "%d\n" , i ) ; i ++ ; } for文では以下のような文法のため、一塊の処理として読んだ時に1度で理解しやすくなる、というものでした。 for ( i = 0 ; i < N ; i ++ ) { printf ( "%d\n" , i ) ; } チームで開発する以上、何度も読み返すような例は良くない。 何より自分ですらどういった意図を持ってそのコードを書いたかなんて忘れてしまうのだから簡潔にかけている方がいいですよね。 確かにその通りだと思ったので今後はよっぽどの理由がない限りチーム開発では繰り返し処理をfor文で書くことにしようと思いました。というお話。

@Stateってなんぞや と言う話。 ただのメモなので基本の当たり前のことについて書いておく。 まあ更新可能な変数を宣言したい時につけとけばそう言うものとして扱ってくれるんだろうなぁ、程度のイメージだった。 ただ、知らなかったのはこの値を更新するたびに body を更新、画面を 再描画 するということ。 Swift初期のこととかよく知らなかったけど、この仕組み自体 Swift5.1 で追加されたものらしい。 そもそも論としてstructが基本的に更新不能と言うことを考えれば何かしらの回避可能な仕組みがあって当たり前だろう、ということになりそうなものだけど新しい事を学ぶ時ってインプットが多くなりすぎて詰め込む方に意識がいってしまいすごく今更なメモになった。 ちなみにひとまず動かしてみた例がこれ。 トグルボタンを用意して状態出力するもの。 ソースは ここ 。

初心者向け 開発者定義のViewModifier 初心者向け の記事。 SwiftUIではViewでUIの要素を指定し、ViewModifierで要素のレイアウトを整えていく。 その書き方はそれぞれの要素に対して // // ContentView.swift // Modifier // // Created by kuehar on 2021/07/01. // import SwiftUI struct ContentView : View { var body : some View { Text ( "Hello, world!" ) . padding ( ) } } struct ContentView_Previews : PreviewProvider { static var previews : some View { ContentView ( ) } } プロジェクトを作ったときはこういう形式でコードが生成されるが、このコードの中の .padding() が実際のViewModifer。 Previewで見てみると最初はこんな感じだが、 例えば .padding(bottom) に変えてみると、 少しだけ Hello, World! が上に動いている。非常に分かりづらいが。 こういった形で各要素を修飾することによって要素の内容を変えていく。 開発者定義のViewModifier 同時に、開発者側で定義する再利用可能なViewModifierを作成できる。 開発者でどのビューにも適用できる再利用可能なViewModifierを作成したい場合に用いるもので、いくつかのViewModifierを組み合わせて新しいViewModifierを作成することができる、というもの。 例えば Apple公式のViewModifier のドキュメントでは以下のようなViewModifierを定義し、使用しています。 // // ContentView.swift // Modifier // // Created b

Webスクレイピングとか 試していたらこれが突然出た。 macOS用公式インストーラーのPython 3.6でCERTIFICATE_VERIFY_FAILEDとなる問題 という記事に解決策が書いてあったが、 python.orgで配布されているmacOS用の公式インストーラーでインストールしたPython 3.6を使い、 urllib.request.urlopen() で https:// のWebページを取得しようとすると、以下のエラーが発生します。 で、このタイトルのエラーに当たっていたよう。 私の場合はPython3.8.5を使っていたので $ /Applications/Python\ 3.8/Install\ Certificates.command というコマンドをターミナルで叩くことで事なきをえた。 読んでないのが悪いとはいえこれはハマる人が多いんじゃなかろうか。

たまたま目にしたので Create Phone Number たまたま目にしたので CodeWars なるサイトがあるとのことで試しに登録してみた。 サイトで問題を解いてコーディングスキル上げてね！みたいなサイトです。 Create Phone Number そこで２問目(3問目だったかも)で出てきた Create Phone Number についてPythonで解いていました。 この問題はリストで10桁の数字が与えられるので、それらの値を電話番号のフォーマット、下のような形式で変換して返してほしいという問題です。 create_phone_number ( [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 0 ] ) # => returns "(123) 456-7890" 僕は愚直にfor文の中で分岐を何度も挟むことで作る、という方法を取りました。 def create_phone_number ( n ) : phone_number = '(' for i , num in enumerate ( n ) : if i < 3 : phone_number += str ( num ) if i == 2 : phone_number += ') ' elif i <= 13 : phone_number += str ( num ) if i == 5 : phone_number += '-' return phone_number でもよく見たらこれって書く量も多いし、なんかあんまりいけてないなぁと思っていたところ他の方の回答を見たところ、こんな解答を見つけました。 def create_phone_number ( n ) : return "({}{}{}) {}{}{}-{}{}{}{}" .

楽をするのは良いことだ 環境 構築 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 ######## #### ######## ######## ######## ### ###### ######## ## ## ##

社内システムとAPI 社内でとある雑談をしている際に、社内システムを構築する際にAPIを設計、開発するとより簡単、かつ疎結合なシステムを作る時に便利になってくるのではないか、という前提を元にAPIについて勉強しなおしました。 どうせ勉強するならアウトプットして外に出すことで間違っていた際にご指摘を受けることも出来ますし、自身の勉強の証にもなるだろうということでサクサクっと書いていきます。 参考図書 Webを支える技術 Web API: The Good Parts 学習の順番 Webを支える技術 Web API: The Good Parts の順で勉強しました。 正確には Webを支える技術 は読んだことがあったので、基本的な歴史や仕様について学び直すために読んだ、と言ったほうが正しいかもしれません。 そもそもHTTPとかを理解できていないとAPIについて何を言っているのか分からない、というのはあると思うのでWebの仕組みを理解する基礎固めのためにも読むべきだと思います。 あと単純に面白いです。 Web API: The Good Parts はWeb APIをこれから設計、開発しようという人を対象とした本なので、APIについてのざっくりとした説明はあるものの、主軸はあくまでこういうAPI設計したら気持ち悪くね？こっちの方がよくね？とか、特定のユーザーにAPI叩かれすぎたら困るよね？じゃあこうしよう！などの開発者向けの内容がメインです。 こちらも面白かったです。 オライリーの本ですが、著者が日本の方ということもあり、分かりにくい表現も少なく、スラスラ読める、という印象なので困っている方に特におすすめです。 そもそもAPIって何よ？ 一般的な定義 Application programming interface の略です。 よく言われるAPI、というのは大体の場合Web APIのことを指します。 なお、APIを使うことをITエンジニア界隈では「APIを叩く」、と言います。 これはAPIを使うことを英語で「hit api」というためで、それが和訳されて使われ続けて今に至るとか。 なお、Web APIとは、 Web API: The Good Parts にある通り、 Web APIとは「HTTPプロトコルを

SwiftUIマスターに、俺はなる！ という冗談は置いておいて。 なんか楽しそうなアニメーションとかやりたいよなぁ〜と思い、YouTubeで SwiftUI Animation で検索したら面白そうなのがあったので見様見真似で模写。 コードは ここ。 何ができるかというとこんな感じのボタンを押した時に以下のようなアニメーションを行うというもの。 すっごい立体的・・・ 特に技術的な記事ではないけど無料でこういうちょっとした遊びを学べるのはいい時代だなぁと思いました。 基本は公式のチュートリアルでさくっと学んであとは無料で真似て描いてこれっていうものを作ってみるという時代が来ているのかも。 これからも楽しく学んでいけるといいなと思いました！ （小学生の感想文かな?)

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

djoserとは 使い方 djoserとは djoser とはDjango REST Framework上での基本的なユーザー認証や登録などの認証周りをサポートしてくれるライブラリです。 カスタムモデルに対しても使え、Djangoのコードを再利用するような形をとるのではなく、Single Page Application(以下SPA)によりフィットするようなアーキテクチャを目指して作られています。 今回はdjoserの最もシンプルな認証機能の実装について書きます。 なお、この認証はセキュリティの面などから実際に使用するべきではなく、以下のJWT認証のようなより強固なセキュリティの設定があります。 あくまでお手軽な認証として紹介します。 ソースコードは こちら なお、以下の全てが導入後にエンドポイントとして使えます。 /users/ /users/me/ /users/confirm/ /users/resend_activation/ /users/set_password/ /users/reset_password/ /users/reset_password_confirm/ /users/set_username/ /users/reset_username/ /users/reset_username_confirm/ /token/login/ (Token Based Authentication) /token/logout/ (Token Based Authentication) /jwt/create/ (JSON Web Token Authentication) /jwt/refresh/ (JSON Web Token Authentication) /jwt/verify/ (JSON Web Token Authentication) Getting started djoser関連の記事を他にも書いています。 djoserを使ったDjango REST Frameworkでの認証機能の実装 djoserを使ったDjango REST FrameworkでのJWT認証機能の実装 なお、今回はJWT認証を用いたユーザー認証を実装することとします。 使い方 途中

スタック スタックについて 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 逆ポーランド記法の計算