OmniAICreator/Qiita-1.07M huggingface dataset:
Pulpで電力最適化の問題を解いてみる！

## 動機
・ずっとエネルギーマネージメント系の仕事でお金を稼ぎたいと思っていた。
・仕事で触れる機会もないので、まずは自分でやってみた。
・数理最適化も勉強してみたかった。

## 感想
・pulpは使いやすそう。
・制約式をきれいに書く方法がわからない。もっと手早く書ける気がする。
・電力の同時同量原則を守るようにすると、実行可能解がでない。。。


## コード
```python:qiita.py
#もし入ってなければpulpのインストールから
!pip install pulp

#問題を定義
import pulp
problem = pulp.LpProblem('エネマネ', pulp.LpMinimize)#数理モデル定義



#解く問題は”24時間の電力コスト最小化”
#電力ソースは自社発電機と電力市場購入
#発電機は、発電量と稼働コストが異なるものが６台(u_i,i=1~6).購入したら、期間(t=1~24まで)中ずっと電力を供給してくれる。
#電力市場購入は、発電量と購入コストが異なるものが３つ。(x1_t,x2_t,x3_t,t=1~24).各時間で購入する必要がある。

#今回の問題は、”バイナリ変数x_1_t,x_2_t,x_3_t,u_i（t=1~24, i=1~6）をうまく設定して、コストが最小になるようにしてね”という問題になる。（変数が1で購入、変数が0で非購入扱い）

#変数を定義
#電力市場購入
x1 = [ pulp.LpVariable( 'x1_{}'.format( i ),cat=pulp.LpBinary) for i in range(1,25) ]
x2 = [ pulp.LpVariable( 'x2_{}'.format( i ),cat=pulp.LpBinary) for i in range(1,25) ]
x3 = [ pulp.LpVariable( 'x3_{}'.format( i ),cat=pulp.LpBinary) for i in range(1,25) ]
#発電機購入
u = [ pulp.LpVariable( 'u_{}'.format( i ),cat=pulp.LpBinary) for i in range(1,7) ]


#制約式用の係数を作る
#市場購入電力のコスト,どの時間でも一定とした。
c1 = [10 for i in range(1,25)]
c2 = [15 for i in range(1,25)]
c3 = [20 for i in range(1,25)]
#発電機の購入コスト
cG=[90, 130, 160, 170, 250, 280]
#発電機発電量
kwh_G ={5, 6, 8, 10, 15, 20}
#市場電力の電力量は制約式を作る際に手打ちした。もっと上手い書き方がある気がする。。。
#電力需要
kwh_Demand=[23, 23, 25, 25, 28, 33, 43, 43, 48, 53, 63, 69, 65, 60, 53, 48, 55, 63, 61, 53, 43, 33, 28, 25]

#電力需要の可視化
import matplotlib.pyplot as plt
time = [i for i in range(1,25)]
plt.bar(time, kwh_Demand, tick_label=time)

#目的関数をセット
#コスト最小化したいので、コストの式を入れる
problem += pulp.lpDot( c1, x1 ) + pulp.lpDot( c2, x2 ) +pulp.lpDot( c3, x3 ) +pulp.lpDot( cG, u )

#制約関数をセット
#購入電力について、x1=5kWh,x2=10kWh,x3=20kWhと置いた。
for i in range(24):
    problem += 5*x1[i] + 10*x2[i] + 20*x3[i] + pulp.lpDot( u, kwh_G ) >= d[i]
    problem += x1[i] + x2[i] + x3[i] <= 1


#制約式と目的関数の確認
print(problem)

# 解く
result = problem.solve()

#解けているか確認。result=1でないと解けていない。
print("result=",result)

# 結果を出力
print('objective value: {}'.format(pulp.value(problem.objective)))
print('solution')
for i in range(len(x1)):
    print('x1_{} = {}'.format( i+1, pulp.value(x1[i]) ))
    print('x2_{} = {}'.format( i+1, pulp.value(x2[i]) ))
    print('x3_{} = {}'.format( i+1, pulp.value(x3[i]) ))
for i in range(len(u)):
    print('u_{} = {}'.format( i+1, pulp.value(u[i]) ))

```


## githubにコードを上げています。
https://github.com/kawasaki3/energy_maneg


## ご参考にさせていただいたサイト
https://www.letsopt.com/entry/2020/08/12/232018
Vus.js3へDatePicker導入[vue-datepicker]

## 環境
___
| フレームワーク | バージョン |
| ---- | ---- |
| Laravel Framework | 9.30.1 |
| Vue.js | 3.2.36 |

## インストール
____
```bash
npm install @vuepic/vue-datepicker
```
## 使い方
___
#### SFCを用意
```vue: resources/js/components/InputDate.vue
<script setup>
import { ref } from 'vue'
import Datepicker from '@vuepic/vue-datepicker'
import '@vuepic/vue-datepicker/dist/main.css'

const date = ref(new Date())
</script>

<template>
  <Datepicker v-model="date"></Datepicker>
</template>
```

#### SFC読み込み
```js: resources/js/app.js
import InputDate from './components/InputDate.vue'

const app = createApp({
    components: {
        'input-date': InputDate,
    }
});
app.mount('#app');
```

#### baladeで適用
```php: resources/views/index.blade.php
<input-date name="birthday"></input-date>
```

### 確認
___
![](https://storage.googleapis.com/zenn-user-upload/ad2eb41d3d44-20221224.jpg)

### カスタマイズ
___
1.日本語化
2.フォーマットを調整
3.「Select」「Cancel」ボタンを無くし、日付選択時にinputに反映

```diff_vue: resources/js/components/InputDate.vue
// 省略
const date = ref(new Date())

+ const format = (date) => {
+ const day = date.getDate()
+ const month = date.getMonth() + 1
+ const year = date.getFullYear()

+ return `${year}/${month}/${day}`
+ }

// 省略
-  <Datepicker v-model="date"></Datepicker>
+  <Datepicker v-model="date" :format="format" locale="jp" auto-apply></Datepicker>
// 省略
```

### 結果
___
![](https://storage.googleapis.com/zenn-user-upload/b4a9472c4e14-20221224.jpg)

## 公式ドキュメント
https://vue3datepicker.com/
ハッカソンで役に立つサービス（mapbox）

# はじめに
この記事は[**ハッカソン Advent Calendar 2022**](https://qiita.com/advent-calendar/2022/hackathon)の17日目の記事です。
本日は、ハッカソンで役に立つサービス**mapbox**について書きます。

## mapboxとは
一言でいうと、『**オシャレな地図アプリを開発できるツール**』です！

公式ドキュメントの説明
> Mapboxは開発者向けの地図開発プラットフォームです
社内外の様々なデータを自由に組み合わせ、ユースケースに最適な地図を
構築することで企業のロケーションデータ活用を促進します。

https://www.mapbox.jp/

## mapboxを使うメリット

### 1. UIがとってもきれい

アプリのテーマに合わせて、多くのデザインからマップを選択できます

https://www.mapbox.jp/maps

### 2. 便利なAPI/SDKが用意されている
開発効率があがります

https://docs.mapbox.com/jp/

### 3. 費用が低い
無料枠が用意されています
ハッカソンで試用するのであれば、基本無料枠に収まります

https://www.mapbox.jp/pricing

# おわりに
**mapbox**はいろんなハッカソンでお世話になっています
今後も地図アプリを作るときは**mapbox**を使うと思います！
Supabaseストレージに画像をアップロードし、表示する

どうも、SupabaseでDevRelをしているタイラーです。

意外とちゃんとSupabaseストレージの使い方を日本語で説明している記事がなく、`download()`を使ったりした少し回りくどい実装をしているケースを見かけたりしたので、今日はシンプルに[Supabaseストレージ](https://supabase.com/docs/guides/storage)に画像をアップロードしてその画像を表示するやり方を紹介します。

## アップロード

アップロードはシンプルに`storage.upload()`メソッドを呼ぶだけでできます。下記はReactを使った簡単な例です。`type="file"`の`input`エレメントを用意して、そのエレメントに対して選択されている画像が変更されたときに`handleImageChange()`メソッドが呼ばれ画像がアップロードされるようになっています。

```tsx
  const handleImageChange = async (
    event: ChangeEvent<HTMLInputElement>
  ): Promise<void> => {
    if (!event.target.files || event.target.files.length == 0) {
      // 画像が選択されていないのでreturn
      return
    }

    const file = event.target.files[0] // 選択された画像を取得
    const filePath = `my_folder/${file.name}` // 画像の保存先のpathを指定
    const { error } = await supabase.storage
      .from('my_bucket')
      .upload(filePath, file)
    if (error) {
      // ここでエラーハンドリング
    }
  }
  ...
  <input type="file" onChange={handleImageChange} />
```

ここでは`filePath`という変数でファイルを指定バケットのどこのパスに保存するかを指定する形になっています。`filePath`は他にもこのようにユーザーのユーザーIDを使った方法などが主流かもしれません。

```tsx
const user = await supabase.auth.getUser() // ログイン中のユーザーのユーザーオブジェクトを取得
const filePath = `${user.id}/${file.name}` // ユーザーIDのフォルダの中にファイルを保存
```

ここではReactとTypescriptを使った例を紹介しましたが、Flutterなど他のフレームワークでも同じようなメソッドがあるのでほぼ同じ感じで実装できます。

## 画像の表示

画像の表示はとてもシンプルです。Webであろうがモバイルアプリであろうが画像はその画像のURLさえ取得できてしまえば表示できるのでURLを取得しましょう。URLの取得の仕方は２種類あります。

エラーハンドリングは省略しますが、
```tsx
// publicなバケットに画像が保存されている場合
const { data } =  supabase.storage.from('my_bucket').getPublicUrl(filePath)
const imageUrl = data.publicUrl

// privateなバケットに画像が保存されている場合
const {data, error} = await supabase.storage.from('my_bucket').createSignedUrl(filePath, 600)
const imageUrl = data.signedUrl
```

これだけで`imageUrl`変数に画像のURLが格納されます。あとはこれをウェブであれば`<img />`の`src`に指定するだけだし、Flutterであれば`Image.network`ウィジェットに渡してあげるだけです。

あと、よくあるのは画像をアップロードした際にその画像のURLを取得してしまって、そのURLをデータベースに保存してしまう手法です。個人的に何かアプリを作るときはこのやり方をいつも使っています。

```tsx
  const handleImageChange = async (
    event: ChangeEvent<HTMLInputElement>
  ): Promise<void> => {
    if (!event.target.files || event.target.files.length == 0) {
      // 画像が選択されていないのでreturn
      return
    }

    const file = event.target.files[0] // 選択された画像を取得
    const filePath = `my_folder/${file.name}` // 画像の保存先のpathを指定
    const { error } = await supabase.storage
      .from('my_bucket')
      .upload(filePath, file)
    if (error) {
      // ここでエラーハンドリング
    }
    
    // 画像のURLを取得
    const { data } = supabase.storage.from('my_bucket').getPublicUrl(filePath)
    const imageUrl = data.publicUrl
    
    // 画像のURLをDBに保存
    const { error: databaseError } = await supabase
      .from('my_table')
      .insert({ imageUrl: imageUrl })
  }
```

DBに保存する部分のコードは実際にはユースケースによって変わってくると思うのですが、例えばこの画像アップロードがプロフィール画像を変更するような処理なのであれば`profiles`テーブルに対して`update`するような処理になるでしょうし、何か画像つきの投稿をするようなアプリなのであれば`posts`テーブルに対して投稿文などの他のデータと一緒に`insert`するような処理になるのかなと思います。

このようにDBに画像のURLを挿入してあげることで今度そのDBからデータをロードした際には`supabase.storage`系のメソッドを呼ぶことなく直接そのURlを`<img />`などに渡してあげることで表示することができ、実装が楽になります。

以上、少しでもみなさんのSupabaseストレージの理解を深めるお手伝いができたら光栄です。
GORMのアソシエーションの自動更新で削除した関連が復活していた


# 起きたこと
GORM(v1.9.16)を使っていて、アソシエーションの削除がうまくいかなかったときにハマったのでその時の調査メモです。
Productモデルと、そこに紐づくShopモデルを並行して更新するようなプログラムを作成していました。

```go:main.go
package main

import (
	"github.com/my-best/products.my-best.com/go/internal/models"
	"golang.org/x/sync/errgroup"
)

func main() error {
    var product models.Product
    eg := errgroup.Group{}
    eg.Go(func() error { return updateProduct(&product) })
    eg.Go(func() error { return updateProductShop(&product})
    // 略
}
```

`updateProductShop`の内部では不要になった`Shops`を削除するような処理が書かれていました。
```go:update_product_shop.go
err := db.GetDB().Transaction(func(tx *gorm.DB) error {
    db.GetDB().Model(&product).Related(&product.Shops)
    for _, shop := range product.Shops {
        if err := tx.Delete(&shop).Error; err != nil {
            return fmt.Errorf("既存のShopの削除中にエラーが発生しました: %v", err)
        }
    }
}
```

ところが、実際に`main.go`を回し終わっても、削除されているはずの`Shop`が残ってしまっていました。

# Save(&product)にて関連が上書きされてしまっていた

ログを確認してみると、下記のようになっていました。（一部抜粋）

```
// updateProductShopの処理
[2022-07-12 10:51:16]  [2.35ms]  SELECT * FROM `shops`  WHERE (`product_id` = 17821591)
[1 rows affected or returned ]
[2022-07-12 10:51:16]  [1.40ms]  DELETE FROM `shops`  WHERE `shops`.`id` = 155648
[1 rows affected or returned ]
// updateProductの処理
[2022-07-12 10:51:17]  [1.85ms]  SELECT * FROM `products`  WHERE (product_id = 17821591)
[0 rows affected or returned ]
[2022-07-12 10:51:17]  [1.59ms]  UPDATE `products` SET （略） WHERE `products`.`id` = 17821591
[1 rows affected or returned ]
[2022-07-12 10:51:17]  [1.51ms]  UPDATE `shops` SET `product_id` = 17821591,　（略） WHERE `yahoo_shops`.`id` = 155648
[0 rows affected or returned ]
```
これを確認してみると、`updateProductShop`ではたしかに削除ができているのですが、`updateProduct`でなぜか削除したはずのshopのUPDATEが行われていることがわかります。

こちらを実行元を見てみると、
```go
db.GetDB().Save(&product)
```
が呼ばれていました。

# AssociationのDeleteも合わせて行う

どうやらGORMでは単にShopを削除するだけではなくて、関連も削除してあげないといけなかったようです。

> GORMはレコードの作成・更新時にUpsertを使用して自動的に関連データとその参照を保存します

https://gorm.io/ja_JP/docs/associations.html#%E9%96%A2%E9%80%A3%E3%82%92%E5%89%8A%E9%99%A4%E3%81%99%E3%82%8B

```diff_go:update_product_shop.go
err := db.GetDB().Transaction(func(tx *gorm.DB) error {
    db.GetDB().Model(&product).Related(&product.Shops)
    for _, shop := range product.Shops {
        if err := tx.Delete(&shop).Error; err != nil {
            return fmt.Errorf("既存のShopの削除中にエラーが発生しました: %v", err)
        }
    }
}
+if err := db.GetDB().Model(&product).Association("Shops").Delete(shop).Error; err != nil {
+    return fmt.Errorf("関連の削除に失敗しました: %v", err)
+}
```

このように書くことで暫定対応しました。

# Omitオプション

恒久対応としては、他箇所のdb.GetDB().Save(&product)の箇所にOmitオプションを付けるのが良さそうです

> 作成/更新時のアソシエーションレコードの自動保存をスキップするには、 Select または Omit を使用します。


https://gorm.io/ja_JP/docs/associations.html#%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E8%87%AA%E5%8B%95%E4%BD%9C%E6%88%90-x2F-%E6%9B%B4%E6%96%B0%E3%82%92%E3%82%B9%E3%82%AD%E3%83%83%E3%83%97
【合格体験記】データベーススペシャリスト 勉強内容など

令和4年度のデータベーススペシャリスト試験に合格しました。
受験に向けて取り組んだ内容をまとめていきます。
今後取得を目指される方の参考になれば幸いです。

# 結果
午後Ⅱが不安でしたが，なんとか合格ラインに乗ってました。
午後Ⅰでは問1,2を，午後Ⅱは問2を選択しました。
![スクリーンショット 2022-12-24 173153.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952850/0f3a56b2-72a3-73c6-a547-62a2764bb9ac.png)

# やったこと
学習開始前の状態として，SQLは業務で使っていたので，DMLとDCLは問題なく使えるレベルです。
DDLも使ったことはありましたが，自信ありってほどではないです。
学習期間は2,3ヶ月としっかり確保しました。

## 教材
#### 情報処理教科書 データベーススペシャリスト 2022年版
この参考書には，DBの基礎知識と問題解答時のコツ，おすすめの過去問など，あったら嬉しい情報がたくさんあります。
この1冊があったからこそ，試験のことをたくさん知ることができ，安心して受験できたと思います。

https://www.amazon.co.jp/%E6%83%85%E5%A0%B1%E5%87%A6%E7%90%86%E6%95%99%E7%A7%91%E6%9B%B8-%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%82%B9%E3%83%9A%E3%82%B7%E3%83%A3%E3%83%AA%E3%82%B9%E3%83%88-2022%E5%B9%B4%E7%89%88-IT%E3%81%AE%E3%83%97%E3%83%AD46/dp/4798174904/ref=asc_df_4798174904/?tag=jpgo-22&linkCode=df0&hvadid=553790046648&hvpos=&hvnetw=g&hvrand=12037300008522337050&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009129&hvtargid=pla-1792921924472&psc=1&th=1&psc=1

#### 過去問道場
午前問題対策といえば過去問道場でしょう。
PC，スマホで利用できるので，電車内や外出先で学習できて本当に助かります。
気分転換に掲示板を見ると，戦友兼ライバルたちの努力してる様子が見えて勉強のモチベが上がります。

https://www.db-siken.com/dbkakomon.php

## 学習内容
基本的には過去問演習ですが，試験区分ごとに内容を詳細にまとめていきます。
学習開始時期も併せて書いておきます。

### 午後Ⅱ（7月下旬から）
問2（概念設計）の過去問を，およそ10年分を解きました。
概念設計を選択するつもりでしたが，午後1で物理設計をやらざるを得ないので，物理設計も3年分演習しました。
(正直，物理設計の方が自分に合っていた気がします。)

過去問演習は本番を想定し，***紙に印刷して***やっていました。
1,2回目はしっかり解いて解説を熟読し，解答のロジックを理解するようにしました。
3回目以降はロジックを確認できれば良いと思っていたので，問題文を眺めて解答を想像して解説で確認していました。
***確認型の学習は，いろんな過去問を短時間で周回できるので個人的にはおすすめです。***

受験2週間前にパン屋問題を初見で8割取れたので，そこそこ自信はありました。

### 午後Ⅰ（9月から）
過去問を計10年分ほどやりました。
学習方法は午後2と一緒です。

午後Ⅰは，概念設計以外に物理設計寄りの問題も選択する必要があるので，どんな問題が来てもいいように過去問を満遍なく演習しました。
さらに試験時間が90分と短いので，概念設計には45~50分，物理設計は40分のように，***実際に使う時間を意識して***演習していました。

***どの問題を選択するべきか，どれくらい時間を使うかなど，試験中に考えることがありすぎて，午後Ⅰが1番不安でした。***

### 午前Ⅱ（7月下旬から）
道場で過去問を5年分やりました。
受験1ヶ月前に9割は取れるレベルまでいったので，残りの期間は午後対策に全振りしました。

1週間前に復習したら8割後半は維持できていたので，自信はありました。

### 午前Ⅰ（9月から）
過去問を5回分やりました。
応用情報で地盤はできていたので時間はそこまで割かずに，スキマ時間で午前Ⅰをやる感じでした。
***午前問題は問題数が少ない分，凡ミスが命取りになる***だろうと思っていたので，油断せずに挑もうと思っていました。

# 振り返り

## 試験直後
午前Ⅰ：7割は堅い，6割は行った。
午前Ⅱ：いいかんじー
午後Ⅰ：うっそーん！めっちゃ出来が良いんだが！合格あるぞ！
午後Ⅱ：いや，まいったね。

午後Ⅱはテーマの業務を正確に理解して，***実際の運用をイメージした上で***設計に落とし込む力が必要だったのかなと思いました（個人の感想です）。
***矢印を書いたり，関係スキーマを埋めるだけじゃ合格させんぞ***，というIPAの気持ちを感じました。
問題文が長すぎて気絶しそうでしたが，今までの努力を無駄にしたくない気持ちが勝り，根気強く頑張れました。
時間は足りなかったです。

## 合格発表
午後Ⅱが不安すぎて，自己採点はしない＆合格発表日も確認しないまま，気づいたら合格発表日になっていました。
いかんせん昼休憩中に「合格発表今日なの！？」となったので，その瞬間は食欲が完全になくなりド緊張しました。
合格だと分かったあとは，グラコロをしっかり頂きました。

# おわり
1発で合格できたのは良かったですが，午後Ⅱでは力不足を感じました。
まだまだ勉強が必要ですね。

今後はインフラ周りの知識も習得したいので，情報処理技術者試験ではネスペや支援士に挑戦する予定です。
Unityお勉強

(Unity初心者です)

Unity2021.3でShaderGraphを使ってみました。
2Dの絵をスクロールする事ができました。
これて2Dシューティングの背景スクロールとか作れるのでは？と思いました。

■ShaderGraphの使い方(2D)
まず、Unity>PackageManagerのUniversalPRのInspectorでShaderGraphが有効であればOK。

Projectにsample.png(何でもよい)を設定
Sceneにsample.pngを配置してPlayerに変更。
PeojectでCreate>ShaderGraph>URP>SpriteLitShaderGraphでsh_testを作成。
sh_testを右クリックからCreate>Materialでmat_testを作成。
PlayerのSpriteRendererのMaterialにmat_testを設定。
sh_testをダブルクリックでShaderGraph設定画面を開く。

Texture2D作成。
SampleTexture2DのTextureに結線。
FragmentのBaseColorに結線。
ハッカソンで役に立つサービス（オープンデータ） 

# はじめに
この記事は[**ハッカソン Advent Calendar 2022**](https://qiita.com/advent-calendar/2022/hackathon)の16日目の記事です。
本日は、ハッカソンで役に立つサービス**オープンデータ**について書きます。

## オープンデータとは
一言でいうと、『**二次利用可能なデータ**』のことです！

自治体オープンデータより引用
> 「人口統計」や「公共施設の場所」などをはじめとした様々な公共のデータを、ユーザ(市民、民間企業など)に有効活用していただき、社会経済全体の発展に寄与することを目的として、世界中で同様の試みに取り組まれています。

https://www.open-governmentdata.org/about/

## オープンデータを提供しているサイト

https://www.data.go.jp/

他にも**オープンデータ**を提供しているサイトはあるので、『**オープンデータ　(欲しいデータ)**』で検索するとヒットするかもしれません

## オープンデータのハッカソン

**オープンデータ**をテーマにしたハッカソンも開催されています

https://odhackathon.metro.tokyo.lg.jp/

## おわりに
**オープンデータ**はデータの形式が扱いにくいものもありますが、上手く扱うことができれば有益なデータがたくさんあります！
Google UXデザイン：高忠実度プロトタイプへの移行

# はじめに

わたしが[Google UX Design Certificateで得られた素晴らしい体験][google]を、特に重要だと思われるポイントを小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ Google UX Design Certificateを受講してみてください。

[google]: https://qiita.com/mapami/items/7a0d0a3d4661c50f8bec

https://www.coursera.org/professional-certificates/google-ux-design

<details><summary>これまでの振り返り</summary>

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/d371bce4-836a-0ba5-fd7d-9d2e55f1b909.jpeg" width="700">

</details>

# 高忠実度プロトタイプへの移行

あなたは、これまでモックアップの作成に時間を費やしてきました。さて、いよいよそれを忠実度の高いプロトタイプに仕上げる時が来ました。

- プロトタイプとは、機能を実証する製品の初期モデルのことです。
- 高忠実度プロトタイプは、最終製品のような詳細でインタラクティブなバージョンのデザインです。

***<font color="MediumVioletRed">『高忠実度プロトタイプは、モックアップをインタラクティブにしたもの』</font>***

## ビジュアル要素

まず、プロトタイプに含まれるすべてのビジュアル要素を確定する必要があります。基本的には、テキスト、イラスト、グラフィック、外部リンクなどを確認することです。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/eafd2d05-72f9-3639-395c-4dd77c7bcacd.png" width="６00">

- **低忠実度プロトタイプ(左)**: 名前のプレースホルダーとして線が使われています。低忠実度のプロトタイプでは、「First name, Last name」のようなプレースホルダー・テキストも使用されるかもしれません。
- **高忠実度プロトタイプ(右)**: プレースホルダーの代わりに実際の名前と説明を使用しています。目標は、リアルな名前とプロフィール写真で、実際のアプリ体験をシミュレートすることです。

## ナビゲーション

高忠実度プロトタイプでナビゲーションをチェックするときは、次のような質問を自問してください。

- ユーザーはある画面から次の画面へどのように移動するのか？
- ユーザーはある画面から次の画面にどのように移動するのか、戻る矢印のようなナビゲーション関連のアイコンの位置はわかりやすいか？
- ユーザーの旅はどの地点で終わるのか？

## インタラクティブ

最後に、高忠実度プロトタイプには、インタラクティビティが必要です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/70da4154-712d-ece3-4018-79c3cf815eab.png" width="６00">

#### Figmaの設定

1. 接続を作成するには、まずホットスポットにしたいアイテムを選択します。ここでユーザーとのインタラクションが行われます。ボタンやアイコン、見出しなど、どんなものにもホットスポットを作成することができます。
1. 接続を作成します。これは、ホットスポットと目的地を結ぶ矢印や麺のことです。円の中にある小さな青いプラス記号をクリックすると、接続を行うことができます。
    1. 接続先を指定します。これは、接続が終了する場所です。接続先は、フレームまたは画面でなければなりません。フレーム内のアイテムであってはいけません。
1. 接続が完了したら、インタラクションとアニメーションを追加します。インタラクションやアニメーションには、ジェスチャーやモーションなどが含まれます。
Asanaについての初歩的な知識

# ジャンル
タスク管理

# プラットホーム
1. ウエブ版
1. デスクトップ版
    - Windows (64-bit, 32-bit)
    - Mac
1. モバイル版
    - Android
    - iOS

# 価格
1. Basic (0円)
    - タスク、プロジェクト、メッセージ、アクティビティログ、ファイル数無制限
    - １ファイル100MB
    - コラボレーション最大15人
    - お気に入りアプリとの連携
        - Microsoft Teams
        - Google Calendar
        - Notion
        - Trello
        - Miro
        - 他
1. Premium (1,200円/月)
    - タイムライン
    - ワークフロービルダー
    - 無制限のダッシュボード
    - 高度な検索
    - カスタムフィールド
    - ゲスト無制限
    - フォーム
    - 開始日と開始時間
    - マイルストーン
    - 管理者コンソール
1. Business (2,700円/月)
    - ポートフォリオ
    - ゴール
    - ワークロード
    - 承認リクエスト
    - 更生
    - Salesforce, Adobe Creative Cloud, Tableau, Power BI との高度な連携

　1ファル100MBでファイル数無制限というのは、個人使用においては制限がゆるいと思うので、意外と使えるのでは？

# 概要
　Dustin Moskovitzは、2004年にMark Elliot ZuckerbergとEduardo Saverinが始めたFacebookに合流し、共同創業者となった4人のうちの一人です。同社の最高技術責任者で、その後エンジニアリング担当副社長となりました。映画「ソーシャル・ネットワーク」ではJoseph Mazzello IIIが演じています。

　2008年にエンジニアリングマネージャーを務めていたJustin RosensteinとともにFacebookを退職し、新会社Asanaを設立しました。Asanaのミッションは、オフィスで働く人達の効率を向上させ、プロジェクトやタスクの管理・追跡のためのツールを提供することにあります。

　2011年に無料のベータ版をリリース、2012年には有料サービスを開始しました。2020年9月に上場しました。現在、MoskovitzはCEOにとどまり、Rosensteinは取締役およびアドバイザーをしています。

　Moskovitzは潤沢な資産を有しており、2011年には慈善団体Good Venturesを妻とともに設立しています。また、Bill GatesとWarren Buffettが行ったキャンペーン「The Giving Pledge」に署名した最年少のカップルとなりました。このキャンペーンは、超富裕層がその財産の大部分を慈善団体に寄付することを宣言するものです。28カ国から236人が署名しています。

# 機能

　十分な機能が安価に提供されているサービスだと思います。個人のタスク管理に使用するには、Notionほどの面白みはないですが、使いやすく、すぐに始められるサービスだと思います。

<img width="800" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/864075/7136a06b-b224-2e46-24bd-00e6533bb359.png"/>

<img width="800" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/864075/83d182cd-6c1c-1269-5e71-2f5d47a37fb8.png"/>


 他のアプリとの連携機能も豊富なので、チームで使用するにはコンパクトながら十分能力を持っているアプリではないかと思います。
ハッカソンで役に立つサービス（obniz）

# はじめに
この記事は[**ハッカソン Advent Calendar 2022**](https://qiita.com/advent-calendar/2022/hackathon)の15日目の記事です。
本日は、ハッカソンで役に立つサービス**obniz**について書きます。

## obnizとは
一言でいうと、『**IoTが簡単に開発できるツール**』です！

公式ドキュメントの説明
> obniz（オブナイズ）は、ON/OFFやUART通信などのIO制御をクラウドのAPI経由で行う仕組み、つまり「ハードウェアのAPI化」を実現しました。 どのプログラム言語でも、ハードウェアがどこに存在していても連携が可能となります。

https://obniz.io/ja/how_obniz_works



## obnizを使うメリット

### 1. とにかく操作が簡単
OSのセットアップやクラウドの構築が不要なので、とても簡単に始められます

### 2. JavaScriptで書ける
プログラムは`JavaScript`で動作するため、エンジニアにはとっつきやすい

### 3. 安い
スターターキットは1万円弱で購入できます

https://obniz.com/ja/products/starterkit


# おわりに

**obniz**を始めて触ったとき、セットアップがとても簡単で驚きました！
今後も様々な場面で活用していきたいです
Google UXデザイン：デザイン批評会

# はじめに

わたしが[Google UX Design Certificateで得られた素晴らしい体験][google]を、特に重要だと思われるポイントを小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ Google UX Design Certificateを受講してみてください。

[google]: https://qiita.com/mapami/items/7a0d0a3d4661c50f8bec

https://www.coursera.org/professional-certificates/google-ux-design

<details><summary>これまでの振り返り</summary>

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/d371bce4-836a-0ba5-fd7d-9d2e55f1b909.jpeg" width="700">

</details>

# デザイン批評会とは

デザイン批評会は、UXデザイナーがチームメンバーに自分の作品を発表し、フィードバックを聞くために計画された時間です。また、この活動は、他のチームメンバーにフィードバックを与える練習をする絶好の機会でもあります。

### 参加者

- ***ファシリテーター*** : 批評会を運営し、プロセスを導きます。また、時間を監視し、目標が守られているかどうかを確認することもあります。さらに、全員の声が反映されているか、すべてのアイデアが共有されるのに十分な時間があるかを確認します。ただし、すべてのデザイン講評会がファシリテーターによって運営される必要はないことを覚えておいてください。

- ***プレゼンター*** : セッションで自分の作品を他の人と共有するデザイナーのことです。もしあなたがプレゼンターなら、事前に準備する必要があります。積極的に参加し、フィードバックがあった後に明確化するために質問できるように準備しておきましょう。

- ***レビューアー*** : デザインについてのフィードバックを行い、取るべき行動を明確に提示します。デザイン批評では通常、複数のレビュアーが存在します。

- ***メモ係（オプション）*** : レビュアーからのアイデアやフィードバックをすべて記録し、プレゼンターが完全にプレゼンスと集中力を保てるようにすることができます。

### 進行

批評会の進め方を記します。

1. ファシリテーターがデザイン批評会の概要を説明し、具体的な目的を定義します。
2. プレゼンターは自分のデザインを共有します。その間、レビュアーは質問、アイデア、好きなもの、課題という形でフィードバックを書き留め始めます。
3. ファシリテーターは、レビュアーに順番にフィードバックを説明させます。
4. ファシリテーターは批評会を総括します。

# デザイン批評会のベストプラクティス

### 準備

デザイン批評会用のプレゼンを準備する際には、デザイン決定の背景にある考え方について議論できるようにしておく必要があります。

次の5つの質問に集中することが有効です。

- 誰のためにデザインしているのか？
- どのような問題を解決しようとしているのか？
- あなたのデザインは、これらの問題をどのように解決していますか、あるいは解決していませんか？
- あなたはデザインプロセスのどの段階にいますか?
- デザインのどの部分についてフィードバックを求めていますか？</font>

***<font color="MediumVioletRed">『フィードバックを得るのに十分な情報を提供すること』</font>***

### 発表

さて、これでプレゼンの準備は万全ですね。それでは、批評会でのプレゼンターのベストプラクティスを紹介します。

- アクティブリスニングに重点を置くことが重要です。自分の悪いところを指摘されるのは、なかなかつらいものです。身構えてしまったり、説明したくなってしまうこともあるでしょう。そうではなく、相手の言い分をよりよく理解するために、耳を傾け、質問することに集中しましょう。
- セッション後には、受け取ったフィードバックに基づいて、いつ、どのようにアクションを起こすかを考えます。

***<font color="MediumVioletRed">『フィードバックによって、船が正しい方向に進んでいるのか、それとも大なり小なり方向転換が必要なのかを理解すること』</font>***

# デザイン批評会のフィードバックによる改善例

***<font color="Tomato">『画面上部のアイコンデザインを見直す』</font>***

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/72efc028-dc4d-aed6-65c7-d91ae4ff2d9a.png" width="600">

- 修正前： 画面上部の3つのアイコンはそれぞれ円で囲まれ、その下にテキストラベルが添えられていました。
- 修正前： 円も文字もなく、アイコンは単独で表示されています。この新しいデザインは、すっきりとしていて、忙しない印象です。

こうした作業を必要に応じて反復的に行います。


---

参考）

https://suelynyu.medium.com/a-practical-guide-to-running-effective-design-critiques-c6e8166c9eb0
転職する前と後

# はじめに
気づけば2022年も12月末になり、仕事もプライベートも節目の振り返りが多くなってきました。
著者は今年4月に転職をして環境を新しくしたので、変化をまとめたいと思い投稿しました。

# 今年変化したこと
ここからは転職する前と後を連ねて書いていきます。
どう書くと比較できるかわかっていないので、リストで表記してみます。

転職前は通常フォント、転職後は太いフォントで記述していきます。

- 転職前
- **転職後**

## エンジニアリング関連
まずは使用している技術を書いてみます

- PHP Laravel
- Python Flask
- **Go Gin Gorm**
- JavaScript Vue2
- **TypeScript Vue3**
- **Terraform**
- AWS
    - EC2
    - RDS
    - **ECS ECR**
    - **Lambda**
    - **DynamoDB**


## 働き方
- 週5日出社（出社必須）
- **週2~3出社(リモートと出社のハイブリッドワーク)**
- 隔週1で2H講師を招待して勉強会
- **金曜午前は勉強時間に充ててOK**


## 研修、業務関連
- 半年続けて要求される機能の開発は難しくなく、タスクを通じて成長できるのは限界があると感じていた
- **入社月から研修で要求されるレベルの高さを痛感し、鼻をへし折られる**
- **要件定義、設計を任されること、テストの設計など開発以外のスキル不足を痛感**
- **開発時にチャレンジングな実装に対面。チームメンバーも未経験の技術を使って実装**
- **メンバーの入れ替わりが激しく、かつコードの統一性が著しくかけていたためリファクタリングを担当。自らパターンを提案し導入まで経験**

## その他思いついたこと
- 未経験からエンジニアへの転職とエンジニアからエンジニアの転職は自分の培ったスキルが通じる/足りないを知るキッカケとなった
- 前職では技術にはある程度自信があり、実現できない動きは無いと思いこんでいた。
- **実装だけは意味がなく、テストは十分であるか、性能は問題ないかなど品質保証に対して考えるようになった。**
- **バグの修正に対してはどこで治すのが適切なのかを考えて対応するようになった**


# 最後に
マンネリ化していたら転職をして環境を変えてみることも手だと思います。
これまでの自分のスキルが外ではどこまで通じるか、これからのキャリアをどうするかなど一段と深い思考が得られ、成長のスピードも上げられます。

良いエンジニアライフを。
【Azure】コストのアラート設定方法（1000円ごと）

# はじめに

Visual Studio Professional サブスクリプションだと Azure で毎月6000円分のリソースを使用することができます。
しかし、6000円を超えると使用していたリソースが停止し、翌月まで一時的に使えなくなるためコスト管理は重要になります。

この記事では実際のコストが1000円/2000円/3000円/4000円/5000円のタイミングでメールで通知するためのコストのアラート設定方法を共有します。
コストのアラートを設定したことにより、急激に料金が増加した時に異変を察知し、対策を取ることができました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/309633/3512c54f-c7ef-2e1f-6eb6-cb3c15b5acd1.png)

# コストのアラート設定方法（1000円ごと）
1. Azure Portal を開きます。
2. コストの管理と請求 → コスト管理を開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/309633/9d6e2176-ae08-9e26-74d8-b1b3c45b0e77.png)
3. コストのアラート → 追加 → 予算の追加 を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/309633/96adb6db-fc22-51cc-66f1-17b7d0015e2c.png)
4.予算の詳細を入力し、金額を1000に設定します。そして次へをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/309633/741f68fe-8d6b-3c93-216b-beb92431558e.png)
5.種類: 実際、予算の割合: 100,200,300...、そしてアラートの受信者（メール）を設定し作成をクリックすれば完了です！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/309633/1cfcc6c4-1c1b-9ec1-b2f5-52387b613a16.png)
Juliaで学ぶプログラミング テキスト処理 /Webからテキスト抽出

# webサイトからテキストを抽出する


## 例題　青空文庫「吾輩は猫である」からテキストを読み込み最初の４つ目から７つ目の文書（。区切る）を出力しなさい。(Url ="https://www.aozora.gr.jp/cards/000148/files/789_14547.html")

## 回答例

```julia
# モジュールインポート必要時
# using Pkg
# Pkg.add("HTTP")
# Pkg.add("Gumbo")
# Pkg.add("TextAnalysis")
# Pkg.add("StringEncodings")

using HTTP
using Gumbo
using TextAnalysis
using StringEncodings

url = "https://www.aozora.gr.jp/cards/000148/files/789_14547.html"
cherset_str = "Shift-JIS"

# データ取得 
res = HTTP.get(url)

# レスポンスの文字列への変換
decodeHtml_str = decode(res.body,cherset_str)

# htmlタグ除去
html_sd = StringDocument(decodeHtml_str)
prepare!(html_sd,strip_html_tags)

# top4-7Line目表示
top3TextLine_ary = [_line_str for _line_str in split(html_sd.text,"。")][4:7]
top3TextLine_str = join(top3TextLine_ary,"。")　*　"。"
println(top3TextLine_str)
```
出力結果
```julia
何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪（どうあく）な種族であったそうだ。この書生というのは時々我々を捕（つかま）えて煮（に）て食うという話である。
```


## 解説

responseの値はバイト値
```julia
res = HTTP.get(url)
println(res.body)
#=
UInt8[0x3c, 0x3f, 0x78, 0x6d, 0x6c, 0x20, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x3d, 0x22, 0x31, 0x2e, 0x30, 0x22, 0x20, 0x65, 0x6e, 0x63, 0x6f, 0x64, 0x69, 0x6e, 0x67, (省略)
=#
```

だから文字列変換必要
（今回はダイレクトでSHIF-JISを指定、クローリングなどで不明な場合は判定ルーチンを入れる必要あり）
StringEncodingsのdecodeを使う
この段階でHTMLが取得できる
```julia
# レスポンスの文字列への変換
decodeBody_str = decode(res.body,cherset_str)
println(decodeBody_str)
#=
<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" >
<head>
	<meta http-equiv="Content-Type" content="text/html;charset=Shift_JIS" />
	<meta http-equiv="content-style-type" content="text/css" />
	<link rel="stylesheet" type="text/css" href="../../aozora.css" />
	<title>夏目漱石 吾輩は猫である</title>
	<script type="text/javascript" src="../../jquery-1.4.2.min.js"></script>
  <link rel="Schema.DC" href="http://purl.org/dc/elements/1.1/" />
	<meta name="DC.Title" content="吾輩は猫である" />
	<meta name="DC.Creator" content="夏目漱石" />
	<meta name="DC.Publisher" content="青空文庫" />
</head>
<body>
<div class="metadata">
<h1 class="title">吾輩は猫である</h1>
<h2 class="author">夏目漱石</h2>
=#
```

今度はhtmlタグを消去する今回はTextAnalysisを使う
```julia
# htmlタグ除去
html_sd = StringDocument(decodeHtml_str)
prepare!(html_sd,strip_html_tags)
```

しかしStringDocumentではSplitが使えない。そこでStringDocument.textでString化する。

```julia
# 何故かTextAnalysisのサイトではtext(StringDocument)と書かれているがそちらはエラーになる。
html_sd.text
```
チーム開発を支える名言

これは [弁護士ドットコムアドベントカレンダー 2022](https://qiita.com/advent-calendar/2022/bengo4com) の25日目の記事です。
昨日の記事は @namizatork さんの [PHP初心者とお仕事した時に用意したコーディングルールのテンプレ](https://qiita.com/namizatork/items/79b0a8002575bc74dfd8) でした。

2022年ももう終盤ですね。今年は年末にかけて [UniFi Dream Router](https://jp.store.ui.com/products/dream-router) や [Steam Deck](https://www.steamdeck.com/ja/) といったデバイスが発売され、喜んで買ったもののまだ全然使い込めていません。年末年始で使い倒していきたいと思います。

# はじめに
現代はチーム開発の時代です。スーパースターが1人だけでプロダクトを作るのではなく、各分野のプロフェッショナルが集まってプロダクトを作り育てていかねばなりません。
ただ、バックグラウンドも視点も異なる人々が一緒になってものごとを進めていくのは、そう簡単なことではありません。
今回はそうしたチーム開発を支える名言を紹介したいと思います。

# 「その場にとどまるためには、全力で走り続けなければならない」
ルイス・キャロルの「鏡の国のアリス」のセリフです。転じて、進化論における「赤の女王仮説」の命名の由来としても知られています。
プロフェッショナルは、専門的な知見や技能があるからこそプロフェッショナルです。そしてそうした知見や技能は常に更新されます。全ての領域に精通することは不可能でも、各分野にアンテナをはり、必要があればキャッチアップが必要になります。
プロフェッショナルとしてチームに貢献するには、昨日までと同じこと「だけ」をしていてもいけません。これまで通りの居心地のいい comfort zone から出て、居心地の悪い新たな挑戦をしていく必要があります。

# disagree & commit
いわゆる「名言」ではないですが、Amazonの[リーダーシップ行動指針](https://www.amazon.co.jp/b?ie=UTF8&node=4967768051)の1つです。また Intel の名経営者 アンディ・グローブ のマネジメントスタイルが源流として知られています。
チーム開発には様々な人が参加します。多様な意見を集めた方が、結論の質が上がります。だけど全てを合議で進めていては、いくら時間があっても足りません。この2つをどう両立させればよいのでしょうか。
議論を発散させるフェーズでは、多様な視点を取り込んで視野を広げるべきです。「健全な対立」を生むためにも、それぞれのプロフェッショナルがそれぞれの知見を活かして意見や提案を出していく必要があります。
一方議論を収束させるフェーズでは、合意を目指しつつも、最終的には責任者が意思決定すべきです。難しい意思決定であればあるほど、完全なる合意に至るのは難しいからです。
チーム開発で物事を前に進めるためには、反対意見であったとしても (disagree) 、決まったことには従って成果を出す (commit) 、行動様式が必要になります。

# 「世界を敵と味方だけに分けたら、すべてを焼き尽くすことになる」
宮崎駿の「風の谷のナウシカ」の漫画版におけるセリフです。
「会社は現場をわかってない」「営業は開発をわかってない」といった摩擦はありがちですが、なにか摩擦が起きた時に「こちら vs あちら」という対立構造でみると、「あちら」は焼き尽くすべき敵となり、最後には草も生えなくなります。
そうではなく「問題 vs 我々」の対立構造として捉え、一緒に問題に取り組む仲間として巻き込んだが、実際の問題解決に繋がります。
チーム開発が回るようになると、逆にチームの外を「あちら」としてしまいがちです。でも同じ会社であれば、本来は同じ目標を持ったまた別の「チーム」でもあるはずです。社外の人も含められるかもしれません。どこまで「チーム」として捉えるかで、解決に向けたアプローチも変わってくるでしょう。


# おわりに
チーム開発を支える名言を3つほど紹介しました。
どれも実践するとなると難しいですし、そもそもチーム開発が回るようになること自体が難しい話です。それでも、チーム開発が少しでも改善するヒントとなり、より社会をよくするサービスやプロダクトにつながると嬉しいです。

今年も1年間おつかれさまでした。みなさんよいお年を。
JQuery メモ　.each()と＄each()の違い

each()メソッドの書き方例
$('.item').each(function () {        / jQueryオブジェクトのループ処理に対して適用される/
});

＄each()メソッドの書き方例
$.each(data, function(i, item) {      /dataはjQueryオブジェクトではなくただの配列のため＄each()を適用
　　　　　　　　　　　　　　　　　　　　　　　　iは0から始まる要素のインデックス　itemはその要素の値/ @iとitemはindex value elem など任意も文字列でも可
});

/!JQuery最高の教科書　p214 引用!/
ペットボトル micro:bit イルミネーション

![320241543_627172972430684_7098362843486674624_n.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/4187b3b4-438a-1802-6a10-19345c244a7e.jpeg)

# はじめに

 毎年、12月につくばで開催されているつくばランタンアートが3年ぶりに開催されました。

https://www.tsukucen.com/%E3%83%A9%E3%83%B3%E3%82%BF%E3%83%B3%E3%82%A2%E3%83%BC%E3%83%88

今年は、5,000個の子どもたちが作ったランタンが点灯されました。
光源としては通常はロウソクなのですが、CoderDojoつくば、CoderDojo守谷、micro:bit財団、地元の小中学校の協力で、81個のインタラクティブなmicro:bitイルミネーションを作成＆点灯させる事が出来ました。

# 仕組み

今回は、micro:bit+[TFW-IL1](https://tfabworks.com/product/tfw-il1/)+500mlのペットボトルで実現しました。
ペットボトルは出来るだけ凹凸が多い物の方が光の拡散が美しいのですが、サントリーの南アルプス天然水を採用。これを9x9=81個を並べました。
![2022-つくばランタンアート企画-Google-スライド (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/c061dbe8-4e0d-fcad-54b2-6e722ecc302e.png)

- 通常は子どもたちが作った個性あふれる点灯
- 🟢のランタンには人感センサーを置き、人が近づくとそのブロック(3x3=9個)が一斉にフラッシュ
- ドラをハンマーで叩くと全ランタン81個が一斉にフラッシュ

という仕組みにしました。

# プログラム

子どもたちには、はじめ0番のLEDが赤く点灯するだけのあえて残念な雛形を渡し、まずはmicro:bitへのダウンロード手順を説明。

![Microsoft-MakeCode-for-micro-bit (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/503a317e-5c2c-898b-8322-b1f0baecb97f.png)
https://makecode.microbit.org/_FFbLrxTzYgJt

無事、ダウンロードが出来るようになったら、改造方法として以下の情報を伝えました。

![iPad「ランタン」手順2022-Google-スライド.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/8d2c3e6b-7b0f-948b-735a-605417357efb.png)

MakeCodeが初めての子どもが大半でしたが、45分の中で思い思いの作品を作り上げる事が出来ました。

完成した作品は、共有URLをGoogleフォームやTeamsで提出してもらい、スタッフが後から人感センサーとドラの仕組みを埋め込みました。（埋め込み方については追って記事を書きたいと思います）

# 展示

子どもたちの手で夕暮れ前に設置。

![320205084_850557089587637_7738997493595089619_n.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/c8bf4ce8-5c7b-dfe2-c52d-9b88ee17b2be.jpeg)


薄暗くなったところで全員で点灯を行い、夜には来場した大勢の子どもたちの笑顔を見る事が出来ました。

![320442301_846138903171641_5515129141947219824_n.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44523/04b6c407-12f3-4edf-386a-43770c298a4b.jpeg)

残念だったのは、開催が12/17,18の2日間の予定だったのですが、2日目は強風で中止となってしまいました。

来年はもっと多くの作品を子どもたちと作れたらと思います。
看護師の大量離職を経験しジーズに入ることを決意した話

## 自己紹介
Qiita初投稿です！
最初に自己紹介をさせてください。

3年半前に起業し、福岡市内で訪問看護ステーションを運営しています。
訪問看護とは看護師とリハビリ専門職（理学療法士、作業療法士、言語聴覚士）がご利用者の家に訪問し、その人に必要な看護やリハビリを提供する仕事です。
ちなみに僕も言語聴覚士というリハビリの資格を持っています。

起業する前は福岡市内の病院で言語聴覚士として嚥下障害や言語障害の方にリハビリを実施していました。そこから在宅リハに興味を持ち、大阪の訪問看護ステーションで3年半過ごし（どうしても大阪に住みたかった！裏難波が大好き！）、福岡へ帰ってきて起業したという経歴です。

全然関係ないですが、蒸留酒がめちゃくちゃ好きです。ウイスキー好きの方、是非一緒に飲み行きましょう！

## 看護師の大量離職を経験
2019年8月に訪問看護ステーションを立ち上げ、1年目、2年目と苦しみながらも順調に売上は伸びました。
売上向上に伴い、人を増やし、店舗数も増やしたのですが、3年目に当たる去年1年間で11人の退職を経験しました。この時期社員数は20人ほどだったので約半数の退職です。

この1年間はなかなかしんどかったです。
ただでさえ痩せているのに体重が10kg減りました。

ある時期から毎月のように退職者が出るようになりました。
ポツポツと続く時期もあれば、まとまって出る時期も。

その度に新しい看護師を採用し、人が入れ替わります。

オープン当初は全メンバーとつうつうでコミュニケーション取れていたのが、人の入れ替わりに伴い少しずつお互いが見え辛くなっていました。
当時、店舗管理者を任せていた一番信頼していた創業メンバーもこの時期は疲弊していました。
フォローしていたつもりでしたが、その後このメンバーも退職することに（これが一番辛かった...）。

次々と出てくる退職者にこの時期は悩みまくってました。。

チームから会社へ不信感のような空気を感じるようになり、さすがにまずいなと思い今まで以上に1on1を入れ、ヒアリングとメンタルフォロー、安心感を与えるためのコミュニケーションに時間を割きました。そこで挙がってくる声の多くが「疲れてます」という声でした。

今振り返って思うのは、全然チームに目を向けれていなかったなということ。
これまでを振り返ると、立ち上げ1年目からとにかく売上を上げることに力を入れ、がむしゃらに走ってきました。1人1人の給与を絶対に下げないため、そして会社を成長させるため。

けど、売上ばかりを追い続けることによって、チームの1人1人に目を向けることができておらず、時間外業務を増やしてしまいハードワークが当たり前になっていました。
勉強会や研修などのスキルアップのための時間も作れていませんでした。

毎月の1on1で現場から「もっとケースカンファを増やしたい」、「現場で1人で判断するのに自信がない」等色んな声をもらってましたが、後回しになっていました。

気付けばチームが疲弊している、という状況でした。
看護業務だけでなく書類業務や営業活動も皆でやっていたので、それも負担になってたんだろうなあとか、もっと看護に集中したかったんだろうなあとか、振り返ると反省点だらけです。

去年の反省もあり、今は中に目を向け、業務効率化を進め、教育体制づくりの一歩としてキャリアラダーを作り始めています。

## ジーズに入ることを決意
去年の経験から看護師1人1人がどうやったら笑顔で幸せに働けるようになるかなーと考えるようになりました。他所の訪問看護ステーションの方ともこのテーマで話すようになったところ、僕と同じように離職で悩んでいる人が多いことに気付きました。そして、日本の訪問看護師の離職率を調べてみると、病院看護師よりも圧倒的に高いことが分かりました。

自社だけでなく地域全体の訪問看護師の働き甲斐を高めることができれば、よりよい地域になるんじゃないかと考えるようになりました。

ジーズに入ろうと思ったきっかけは、ネット広告だったと思います。
もともとプログラミングには興味がありました。
訪問看護師の離職問題についてなんとかしたいと思っている時にジーズの情報を知り、最後までプロダクトをつくり切ることができるという方針に惹かれ、「訪問看護師が幸せに働けるようになるサービスを創りたい！」と決意しジーズの門を開きました。

ジーズに入ってもうすぐ3ヶ月が経過します。
はっきり言って最高です！

こんなに刺激的で楽しい環境はないです。

毎週課題発表会があるのですが、皆毎回すごいもの作っくるから、「やべー、負けられない！」っていつも刺激をもらってます。
同期だけじゃなく先生方やチューターの方々、みんな困ったらすぐ助けてくれるし、Give文化が半端ないです。

シンプルに楽しいです！

残り3ヶ月ですが、大好きなこの同期と走り切りたいと思います。

## 改めて僕はどういう看護チームにしたいのか
僕は「想い」を軸にした看護を大切にしています。
それを実現できる訪問看護ステーションをつくりたいと思い起業しました。

看護技術や知識がどれだけ高くても、目の前のご利用者に対する想いがなければ、相手に寄り添った看護はできません。
僕自身が将来看護を必要とする最後の瞬間を迎えた時、形だけの看護をしてくれる看護師より、寄り添ってくれる看護師に訪問してもらいたい。

最近は病院から訪問看護の世界に飛び込んでくる若い看護師が増えています。
在宅でじっくりとご利用者と向き合う看護がしたい、という声が多いです。
これめちゃくちゃ嬉しい！

飛び込んできた看護師が「在宅って微妙だな」って感じて病院に戻ってしまうのが一番悲しいです。
在宅が合わないのは仕方ないけど、戻る理由が会社側や環境の問題なのは嫌です。

想いを持った看護師が自信を持って、目の前の看護に集中して働けるチーム。そして同じ想いを持った看護師同士でいつもご利用者のことで盛り上がれるチームにしたいです。

数字に追われ大切な原点を見失っていました。これがそもそもの原因だったと思います。
改めて原点に立ち戻り、自分が理想とするチームを目指したいと思います。

ちょうど今ジーズでは卒業制作に向けて課題の整理をしています。
去年の大量離職の本質的な課題はなんだったのか、そこからどういうサービスを産み出していくのか。

ジーズで学んでいることを活かし、サービスを完成させ、自社に取り入れることはもちろん、地域の訪問看護師が幸せに働ける社会を目指します。

おわり。
フロントエンドエンジニアがこれだけは知っておいて欲しい ~ 不具合調査について ~

## はじめに

最近だと、フロントエンドから開発の世界の飛び込み、バックエンドやインフラは未経験という方もいらっしゃるかと思います。

バックエンドやインフラを知らなくても開発ができてしまう時代、だけど、不具合が起きた時に原因がわからない（バックエンドエンジニアに頼るしかない）というのが辛いときはありませんか？

僕も自分の知識不足を感じることが多々ありますが、インフラやバックエンドの経験もあるため、不具合が発生した時にどこに問題があり、どうすれば修正できるのかがなんとなくはわかったりします。

なので、今回は、フロントエンドエンジニアが知っておきたい不具合調査についてまとめようと思います。

## STEP1: 何が発生しているのかなんとなくでもいいので把握する

ページが真っ白になっているのか、ユーザーが見えてはいけないコンテンツが見えているのか、表示が崩れているのか。
何がどのページで発生しているのか把握してください。

正確にわかるに越したことはないですが、ここに時間をかけるぐらいならSTEP2へいってください。

## STEP2: 関係者に報告する

これはフロントエンドエンジニアに限らず、エンジニアの基本です。
不具合が発生したかもと思った瞬間、上司や関係各所に報告をしてください。

調査の基本は「調査しないで報告をすること」です。
結果、不具合じゃなかった。ならそれでいいじゃないですか。
不具合だったのに誰も報告していなかった。ということほど信頼を落とすことはありません。

## STEP3: 別の問題が発生していないか確認する

これもできてない人が多いです。
「何が原因か」ということに集中しすぎて「何が発生しているのか」の把握を怠っています。

真っ白になっているのは本当にそのページだけですか？
STEP2の関係者というのは必要十分ですか？
個人情報が漏れるみたいなクリティカルな事象は本当に発生していないですか？

考えうる最大限、別の問題が発生していないか考えてください。

:::note
STEP2が重要。というのは関係者を増やすことで、この**別の問題**に気づきやすくするという意味もあります。
あなたの上司はあなたよりシステムや影響範囲に詳しい可能性が高い。だからまずは報告しましょう。
:::

## STEP4: 問題がどこにあるのかを見極める

ここからはフロントエンドエンジニア特有で伝えたいことです。
不具合調査っていっても、フロントエンドしかわからないし、、という人はこれができていないことが非常に多いです。

問題がどこにあるのかを見極めましょう。

1. フロントエンド
1. フロントエンドからバックエンドへの通信部分
1. バックエンドのコアロジック
1. DB
1. インフラ（ネットワークやインスタンス的な問題）

フロントエンドエンジニアがまず調査することは1や2の部分を疑い、調査すること。

フロントエンドといっても、SSRなどであれば、サーバーサイドの問題なのか、クライアントサイドの問題なのかも切り分ける必要があります。

- ブラウザのネットワークタブやコンソールを見て、エラーが出ていないか確認する
  - クライアントサイドの問題なのか、サーバーサイドの問題なのかを見極める
- SSRのサーバーサイドログを確認する

最終的にはユーザーに誤った画面が出ているということは、エラーメッセージがどこかには出ているはずです。
エラーメッセージを見つけたら、バックエンドエンジニアやインフラエンジニアにも共有しましょう。

これだけでもめちゃくちゃ助かります。

## STEP5: 途中経過をちゃんと把握し、俯瞰し、報告する

これもできていない人が多いです。
不具合が起きた時、フロントエンドエンジニアができることはそこまで多くありません。

バックエンド的な問題だった場合や、インフラの問題だった場合、フロントエンドしか触ったことがない人より、専門的に普段から触っている人の方が早く調査が進むと思います。

でも、やることは終わりではありません。

**非エンジニアに定期連絡をする**。これがフロントエンドエンジニアにできることだと思います。

エンジニアが集まって解決してくれていることはわかるけど、何が起こっているのかわからない。非エンジニアの人たちは不安です。
なので、**何が発生していて**、**どういう影響があって**、**今何をしているのか**ということを非エンジニアの方達に伝えてください。

何が起きているのか自分もわからなければ、「**僕、ちょっとみんなに進捗を報告しておきたいので、今何が起こっているのか簡単に教えてください**:bow:」と言ってみるといいと思います。

ここまでできれば、フロントエンドエンジニアとしての不具合調査完了です！

## 番外編: 終わったら、何が発生していたのかをより正確に把握する

これもできていない人多いです。

結局、何が発生していて、どうすれば修正できたのか説明できますか？
不具合が終わった後にこれが**説明できないのであれば、成長なし**です。

バックエンド、インフラで起こったことであったとしても説明できるようにしましょう。
わからなかったらその周辺知識を勉強して、勉強した内容と相違ないか、ベテランエンジニアに話してみましょう。

## まとめ

今回はフロントエンドエンジニアに知っておいて欲しい不具合調査についてお話ししました。

不具合を0にすることは不可能です。
つまり、不具合調査とは切っても切れない関係にあるわけですね。

不具合が発生した時に、ぼーっとしなくていいようにしていきましょう。
統計学：区間推定の変数の置き換えへの疑問

# 区間推定

```math
X \sim N(\mu,\sigma^2)\\
\bar X \sim N(\mu,\sigma^2/n)
```
の時、95%信頼区間は標準化して、範囲を計算する。

```math
P(-1.96< \frac{\bar X-\mu}{\sigma/\sqrt{n}}  < 1.96) = 0.95

```
ここで、$\mu$を中心として変数を分解して

```math
P(\bar X -1.96 \frac{\sigma}{\sqrt{n}} < \mu < \bar X + 1.96 \frac{\sigma}{\sqrt{n}} ) = 0.95

```
よって、母平均は95%

```math
\bar X -1.96 \frac{\sigma}{\sqrt{n}} < \mu < \bar X + 1.96 \frac{\sigma}{\sqrt{n}}
```
この範囲に入る。

# 疑問
本来

```math
P(-1.96< \frac{\bar X-\mu}{\sigma/\sqrt{n}}  < 1.96) = 0.95

```
は$\bar X$が確率変数として変化する場合の確率で、**母平均$\mu$は変化しない、定数であったはず**である。
なぜ、母平均が変動するような結果になるのか？

$\bar X$が確率変数で、得られた標本の具体的数値である標本平均を代入しても問題ないのか？

「$\mu$は95％この範囲にある　=　**$\mu$は分布関数を持つ**」ように捉えられる。


# 解決
**母平均$\mu$は変化しない、定数であったはず**
この点には
定数とみなしていることは変わっていない。

$\bar X$が確率変数で、得られた標本の具体的数値である標本平均を代入しても問題ないのか
この点に関しては、具体的数値を入れて固定していると考えるより、次のように考えた方がしっくりくる。

$\mu$の値によって次のように、複数世界

![5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405484/8ab910a9-f561-951e-2bdc-c4886be50151.png)

が存在する。
この中で、$\bar X$の値が得られた。
ならば、次の世界線の限られる。
![6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405484/6d53765e-9b46-8cf0-71eb-46b11d66fc93.png)
この95％をどう考えるかが問題である。

各世界線で$\bar X$はランダムに動くことができる。ただし、$\bar X$は95％の確率で特定の範囲に入る。

$\bar X$が観測された。
$\bar X$が「$\bar X$が95％の確率で入る範囲」内である世界線のみ取り出す。

この時、
この95%という値は **$\mu$が95%この範囲にある**ということになるのか

たぶん、この言い方自体が間違いだろう。

「信頼係数0.95の範囲はこれだ」という言い方が正しい。
$\mu$は定数であるので確率分布を持たない、よって95%という言い方自体が間違いだ


# 追記：統計学入門　p.225より

> 信頼区間の意味は、繰り返し多くの標本について信頼区間を計算したとき、真値が区間内に含むものの割合が$1-\alpha$になるということである。

とやっぱり書いてあるので、信頼区間内に真値が含まれる確率というわけではない。
ruby 練習問題43　（アウトプット用）

以下の条件を満たすコードを記述する問題。

・Bookクラスを作成する
・Bookクラスは@titleと@priceをプロパティとして持っている
・attr_readerを使用する
・Bookクラスのインスタンスを作成する（タイトル、価格は任意）
・作成したインスタンスから、タイトルと価格を取得し画面に表示させる。
以下、模範解答
```ruby
class Book
  attr_reader :title, :price

  def initialize(title, price)
    @title = title
    @price = price
  end
end

book = Book.new("プロを目指す人のRuby入門", 3218)
puts book.title
puts "#{book.price}円"
```
以下、解説
まず、attr_readerメソッドとはインスタンス変数を呼び出すメソッドを定義するメソッドである。主に記述する量を減らすために使われるとの事。
attr_readerを使用しないコードだと
```ruby
class Book
  def initialize(title, price)
  @title = title
  @price = price
  end
  
  def title
    @title
  end

  def price
    @price
  end

end

book = Book.new("プロを目指す人のためのRuby入門", 3218)
puts book.title
puts "#{book.price}円"
```
となる。
attr_reader :title, :priceという記述で、@titleと@priceにアクセスできるようになり、
```ruby
def title
    @title
  end

  def price
    @price
  end
```
の記述が不要となる。
Google UXデザイン：デザインに対するフィードバックの受け方と与え方

# はじめに

わたしが[Google UX Design Certificateで得られた素晴らしい体験][google]を、特に重要だと思われるポイントを小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ Google UX Design Certificateを受講してみてください。

[google]: https://qiita.com/mapami/items/7a0d0a3d4661c50f8bec

https://www.coursera.org/professional-certificates/google-ux-design

<details><summary>これまでの振り返り</summary>

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/d371bce4-836a-0ba5-fd7d-9d2e55f1b909.jpeg" width="700">

</details>

# フィードバックについて

自分の作品を共有するときはいつでも、チームメンバーからフィードバックを受けられるようにしておく必要があります。

***<font color="MediumVioletRed">『フィードバックとは、何がうまくいっているか、あるいはうまくいっていないかについて、アイデアを求めたり、受け取ったりすること』</font>***

良いフィードバックは、これまで考えもしなかったような新しい疑問やアイデアを思いつくのに役立ちます。これは、自分の仕事を改善する方法を見つけるのに役立ちます。

UXデザイナーにとって、自分の価値観や偏見を理解することは、デザインに影響を与える可能性があるため重要です。

# フィードバックを得る

定期的にデザインのフィードバックを求めることには、たくさんの利点があります。

- ***<font color="MediumBlue">あなたのデザインを改善し、より良いデザイナーになるのに役立ちます</font>***。チームメイトは、あなたが今まで考えもしなかったようなアイデアや提案をしてくれるかもしれません。

- ***<font color="MediumBlue">あなたの自信とスキルを向上させます</font>***。継続的にフィードバックを受けることで、時間の経過とともに自分がどのように改善されたかを認識できるため、自信を深めることができます。フィードバックを受ければ受けるほど、スキルは向上していきます。

- ***<font color="MediumBlue">デザイナーとしての視野を広げるのに役立ちます</font>***。理想的なのは、さまざまなスキルや経歴を持つ人と一緒に仕事をすることです。彼らは、あなたが見落としているデザインを改善する機会を発見することができます。多様な人たちからフィードバックを受けることは、私たちが創造するものに個人的なバイアスがかかっていることを意味します。新しい視点は、デザインにおけるバイアスを軽減し、課題を解決するための新たな方法を提供するのに役立ちます。

# フィードバックを与える

時には、あなたがフィードバックをすることもあります。フィードバックをすることもまた、難しいことです。UXデザイナーとして素晴らしいフィードバックをするためのヒントをいくつか紹介しましょう。

- ***<font color="MediumBlue">状況に応じて調整する必要があります</font>***。エンジニア、プロジェクトマネージャー、同僚デザイナーなど、フィードバックをする相手の役割を考えましょう。また、自分と同じ新人なのか、先輩なのか、相手の経験値も考えなければなりません。

- ***<font color="MediumBlue">フィードバックの根拠となる理由を用意することです</font>***。例えば、あるプロジェクトでうまくいっていないと感じた部分についてフィードバックをする場合、なぜうまくいっていないと思うのか、その理由を説明できるようにしておく必要があります。例えば、
    - 「あなたが選んだ色が気に入らない」といった大まかな感想は役に立ちません。
    - 「あなたが選んだ色は、アクセスしにくいので好きではありません」と伝えれば、あなたの理由を説明し、デザイナーに実行可能な改善策を提供することになります。

- ***<font color="MediumBlue">解決策を提示するのではなく、デザインの問題点を説明すべきです</font>***。デザイナーとして、デザインがどう見えるか、どう感じるかについてアドバイスしたくなるかもしれませんが、相手の立場になって考えてみてください。

# さいごに

UXデザイナーは、プロセスの早い段階で、できるだけ頻繁にフィードバックを求めてください。デザインの反復的プロセスはとても大切なのです。
経過時間測定とC言語で呼出元関数名取得

# 概要
 C言語で関数呼出履歴（スタックトレース、バックトレース）を取得する。関数通過ごとにprintfするのはよくやるやり方だけど、性能検証目的では「printf」自体に時間がかかりノイズになる気がする。そこでメモリ上のリングバッファに溜め込み、任意のタイミングでリングバッファの内容を出力する方法を考えた。

[ソースコード,github](https://github.com/harasakih/trace)


## 関数一覧

| 関数名 | 概要 |
| :--- | :---|
| int TR_INIT() | 出力ファイルのOPEN,RING-BUFの初期化,ELAPS-TIMEの初期化 |
| int TR_PUSH() | トレース情報（関数名、時刻）の取得 |
| int TR_FPRINT() | トレース情報とELAPS-TIMEのファイル出力 |
| int TR_TERM() | 出力ファイルのCLOSE |
| int TR_SETSTART() | ELAPS-TIMEの初期化(起点時間の設定) |
| int TR_DIFFTIME() | ELAPS-TIMEの時間計算 |

## 使用例
```
void some_function {
	TR_INIT();
	sub1();	
	sub2();	
	sub3();	
	TR_FPRINT();
	TR_TERM();
}

void sub1()
{
	TR_PUSH();
// 関数の処理
}
```
## トレース情報の出力例
```
---- gCounter=15 gTraceStackMax=10 gTraceFname=
[04]sub511  :Mon Dec 19 01:12:53 2022 ELAPS[0.001373000sec]
[03]sub51   :Mon Dec 19 01:12:53 2022 ELAPS[0.001369000sec]
[02]sub5    :Mon Dec 19 01:12:53 2022 ELAPS[0.001365000sec]
[01]sub411  :Mon Dec 19 01:12:53 2022 ELAPS[0.001297000sec]
[00]sub41   :Mon Dec 19 01:12:53 2022 ELAPS[0.001294000sec]
[09]sub4    :Mon Dec 19 01:12:53 2022 ELAPS[0.001290000sec]
[08]sub311  :Mon Dec 19 01:12:53 2022 ELAPS[0.001222000sec]
[07]sub31   :Mon Dec 19 01:12:53 2022 ELAPS[0.001219000sec]
[06]sub3    :Mon Dec 19 01:12:53 2022 ELAPS[0.001215000sec]
[05]sub211  :Mon Dec 19 01:12:53 2022 ELAPS[0.001152000sec]
```
dockerでxargs is not available

macです。
docker入れて

# docker起動
```
k.morikawa@MacBook-Pro　% docker exec -i -t  hoge /bin/bash

bash-4.4# bash-4.4# sh gradlew build
xargs is not available
```

# 解決

```
bash-4.4# microdnf install findutils
Downloading metadata...
Downloading metadata...
Package                                                                                                       Repository                                 Size
Installing:                                                                                                                                                  
 findutils-1:4.6.0-20.el8.x86_64                                                                              ol8_baseos_latest                      540.6 kB
Transaction Summary:
 Installing:        1 packages
 Reinstalling:      0 packages
 Upgrading:         0 packages
 Removing:          0 packages
 Downgrading:       0 packages
Downloading packages...
Running transaction test...
Installing: findutils;1:4.6.0-20.el8;x86_64;ol8_baseos_latest
Complete.
bash-4.4# sh gradlew build
```
動いた
はじプロをやり初めて良かった事! 

今年の４月からはじプロをやり始めました！

買ったきっかけは、ヒトノードンが、昔やっていたちびロボに似ていて、可愛いと思ったからです！

そして直ぐにはクリア出来ないので、楽しそうなのでは？と思いました。

しかし、悩みも出てきました

プログラミングは、普通に難しすぎるのでは？と

しかし人に話したら「小学生でも出来るから」と言ってくれたので

普通に出来る物なのかな。と思って

まずは体験版をダウンロードしてやってみました!

色んなノードン達も可愛く、自分で好きなのが作れるのはとても楽しそう！
こういうの絶対好きだな！
と思って、買っちゃいました(⁠^⁠^⁠)



はじプロをやり初めてから、本当に初めての事を沢山学びました。

色んなゲームを投稿しました！

プログラミングの事はもちろん、You TubeのLIVEで人にやってもらって、嬉しい気持ちと、やっている人がどう思うのかを感じる事が出来ました!

twitterで投稿するのとは、全然違うな！と思いました。



そしてはじプロでも、はじプロ以外でも、SNSでコミュニティの輪が広がり
凄く嬉しいです！

![PXL_20221207_074727482.MP~6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/23dd412e-7da2-c14c-d955-a03c78b11919.jpeg)


「なっちゃん」というキャラクターを登場させる事で、自分自身もはじプロの世界に行った感じが出るので、そこも凄くやりがいがあります！







はじプロは、ナビ付きレッスンは終って
今はエキストラチェックの３個目までクリアしましたが

まだまだ難しい所や、ナビ付きレッスンでやった事も分かっていない所も、沢山あります。

実はナビ付きレッスン６のチェックポイントから、どうしても出来なかったのでスキップしり、攻略本見ながらやった所も、ありました。

それ以外のナビ付きレッスンチェックポイントは
分からなかったら、ノードンガイドを何回も聞いてから、直にやってみたらクリアしました。

ほとんどは、覚えたのではなく
ノードンガイドの通りにやったから、たまたまクリア出来た。と言う感じです。



プログラミングで難しい所は、今は少しだけ出来るようになりましたが、まだ分かっていない事も多いのが

「連結」です


どちらの方向に連結させますか？に対し


例えばシンプルなモノノードンでしたら、（ここは下方向？）と思いきや、モノノードンから見たら、全然別の方向になっていたり‥など

モノノードンから見て、下向き方向ってどこ？と迷ってしまいます。



他にも難しい所も、ありますが
今、やっと自分だけで出来るようになったのが

「アイテムを取ったらパンチ」

「５個取ったらクリアのフェクトが出てリトライする所」

「爆発ががなっているのをＢボタンで押すと止まる」

「ボタンを５回押すと、丸いのが出てくる」です!（一番最後のは攻略本に乗ってるのを見てやってみました!）

![Screenshot_20221224-140552~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/b7a46f90-c2f8-d74d-2aa8-3ec6401d0b87.png)






今は新作を作っている最中です!

タイトルはまだ考え中ですが、
「よなかの、ちびっこひろば」にしようか
「夜中の、貸し切り公園」にしようか
迷っています。


皆さんも、子供の頃に遊んだと思う「キッズルーム」を作りました。



今回はなっちゃんだけではなく、みーさんとつんさんも、初めて登場します！

![PXL_20221224_040443488.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/287d48ad-fd1e-e16f-5666-d60b23b6d929.jpeg)






夜中で子供達はいない間は、大人が自由に貸し切りで遊んでいる！というのが本当の設定です。

大人だけれども３人とも可愛く、楽しく遊んでいます！![PXL_20221219_160359662.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/367c6348-65de-87e6-79c1-9270c451e6c4.jpeg)




ちなみに、ちびっこ広場は前作にも出していました。

初めての作品・ゲームであそぶ、ちびっこひろば

![Screenshot_20221224-204704~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/897b74f2-13c7-9dbe-8673-69f2a9b34475.png)


私が５歳の時に遊んだ、ちびっこ広場を出来る限り再現して書きました。

（緑のぬいぐるみと、白のぬいぐるみは本当にあったのをそのまま描きました）

![Screenshot_20221224-203722~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/aa5d48b0-cf55-bfe3-ab04-48c21fb8f294.png)





２・よるの、ちびっこひろば!![-yb0coq.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/a12a2eb2-a356-deca-3123-ea8552d86272.jpeg)

ちびっこ広場の夜バージョンです。

大好きなノードン達と、私が飼っているペットを描きました(⁠◠⁠‿⁠・⁠)⁠—⁠☆

![Screenshot_20221224-203731~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2955099/1f1de681-d0c3-9b75-dede-9980c305f006.png)


次回出す新作は
その夜中バージョンです。

そのまま引継いで
「よなかの、ちびっこひろば」にしようか
別のタイトルにしようか、まだ考え中です

来年１月頃に投稿する予定です！



楽しみに待っていて下さい！

ここまで読んでいただき、ありがとうございました(⁠^⁠^⁠)
【Ruby】selfでinitializeメソッドからセッターメソッドを呼び出す

# 概要
メタプログラミングの学習を進めてて、つまずいたのでメモ程度に残していきます。
initializeメソッドとセッターメソッドを深掘りします。

# initializeメソッドとセッターメソッドの定義

initializeメソッドを定義しセッターメソッドを定義すると次のようになります。

```ruby
class Car
    attr_accessor :name
    def initialize(name)
        @name = name
    end
    
    
    def say
        "私の車は#{name}です"
    end
    
end

my_car1 = Car.new("toyota")
p my_car1.name
p my_car1.say

# =>"toyota"
# =>"私の車はtoyotaです

```

通常ですと、変数の受け渡しにインスタンス変数（＠name)を使用しますが、
これをローカル変数に変えてみます。

```ruby
class Car
    attr_accessor :name
    def initialize(name)
        name = name
    end
    
    
    def say
        "私の車は#{name}です"
    end
    
end

my_car1 = Car.new("toyota")
p my_car1.name
p my_car1.say

# => nil
# => "私の車はです"

```

nameメソッドを呼び出した時点でnilが発生します。これは、インスタンス変数であるnameがローカル変数となっているため、class内で変数を共有できなかったことが問題となっています。

そこで、セッターメソッドを明示的に指定することで、インスタンス変数を保持することができます。
selfを使用してレシーバを指定します。

```ruby
class Car
    attr_accessor :name
    def initialize(name)
        self.name= name 　#=>　name= メソッドを呼び出してる
    end
    
    
    def say
        "私の車は#{name}です"
    end
    
end

my_car1 = Car.new("toyota")

p my_car1.name # =>"toyota"
p my_car1.say  # =>"私の車はtoyotaです"
```

これで、明示的にセッターメソッドを呼び出していることがわかります。
ちなみにsayメソッドの中にあるnameインスタンスにselfを使用しても呼び出すことができますが、使用しなくでも呼び出しができます。

```ruby
・
・
・
  def say
        "私の車は#{self.name}です"
    end
.
.
.
```
ゲッターメソッドに使用するとコードが煩雑になりますので、使用する必要がないことも覚えておきましょう。
TypeScriptでサーバーもフロントも書いてGraphQLするやつアドカレ25記事書ききった

[Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く Advent Calendar 2022](https://qiita.com/advent-calendar/2022/shwld)
の**25日目**。[株式会社mofmof](https://www.mof-mof.co.jp/)に生息している[shwld](https://twitter.com/shwld)です。

前日は[Next.jsとgraphile-workerをRailwayにデプロイする](https://qiita.com/shwld/items/49a310aadc0a34e2a721)について書きました
# TypeScriptでサーバーもフロントも書いてGraphQLするやつアドカレ25記事書ききった

25記事を書ききったので、ふりかえって感想を書きます。

## 良かったこと
学んだ内容を無理やりアウトプットできた。
アドベントカレンダー25日分最初に埋めたので後戻りできないなという気持ちに
普段アウトプットあんまりしてないのでいい機会。

内容的にもやってるぞってアピールしたい内容なので、ログとして残せたのは精神的に大きい。

## 課題点
内容が粗い、文章が読みづらい。
内容は25分割したので一つ一つが小さめなのはもちろん、期間もあまりないので内容や日本語が粗いです。
見直すと気になるところがたくさん出てくる。

## ネクスト
自分は [REVELUP](https://www.revelup.games) というサービスを作っていて小さなメモはそこにちょくちょく取っていたのですが、小さなメモはあくまで自分向けのメモになることが多く、誰かに説明するときにどう伝えるかなどはあまり考えて書いていませんでした。

しかし、今回アウトプット祭りしてみて、アウトプットはそれはそれで別の技術なので、力を付けるためにもっとこまめにやったほうがいいなぁと感じました。
まずは、小さなメモの内容を他の人が読んでもわかるようにする。を意識していくのをやっていきたい。