go言語の基本の基本

go言語の基本を学んだので、まとめてみようと思います。C言語をやったことがあるので、それとの比較になります。

基本構文

package　パッケージ名

import(インポートするプラグイン名（複数書ける)）

init(){}//main関数よりも先に呼ばれる

main(){}

変数宣言

var{
  i int =1
  f64 float64
  s string
  t, f bool
}

変数の型は、変数名の後に書く。初期値を宣言していない場合は自動的に初期値が入る。 この宣言は他の関数外に書いてすべての関数で使えるようにできる。関数内でしか使えない変数宣言は

xi := 1
xf54 :=1.2
xs := "test"
xt, xf := true, false

のように:=を使って宣言する。型は、自動的に設定される。 printfはCと同じような構文。printlnもある

fmt.Printf("%v", 変数名)

fmtはライブラリ名。ライブラリの中の関数を呼ぶ形になるため、ライブラリ名.関数名という呼び出しになる。 %vの部分はCのように%dだったり%fのように用途によって使い分ける。 %Tは、変数の型を調べられる。%vは変数の値、%tは論理値を表示する。 float32型はvarの宣言を使う必要がある。改行文字は"\n" const宣言はある。constは明示的に型を宣言しない。そのため、その変数を使うときにオーバーフローしていなければエラーにならない。 しかし、型を宣言していると使う前でもオーバーフローさせた時点でエラーになる。 型にはcomplex64、complex32という複素数の型もある。 goが推奨するインデントは一番長い変数にそろえる。

var｛
  u8  uint8     =255
  i8  int8      =127
  f32 float32   = 0.2
  c64 complex64 = -5 + 12i
}

変数シフトは、　変数名 << シフト回数 文字列のワイルドカードは、``（シングルクォーテーション）で文字列全体を囲むか、ワイルドカードしたい文字の前に\をつける。 型変換は

var x int = 1
xx := float64(x)

のようにするとxxにfloat64型のxが入る。intをstringに変換するときは

i, _ := strconv.Atoi(s)

とする。変数の_は、この返り値を使わないという宣言。Atoi(s)は、intとerrorの2つの返り値を返しているが、iしか使わないときはこのような書き方をする。

配列、スライス、マップ

配列の宣言は

var b [2]int = [2]int{100, 200}

のように宣言する。[2]intの部分が型になっている。 スライスの宣言は

n := []int{1, 2, 3, 4, 5, 6}

スライスはスライス特有の取り出し方がある。 n[2:4]は[3 4]を取り出す。前の値は最初のインデックスは0だが、後ろの値は最初のインデックスは1になっている。2つの値の差の個数分取り出せると覚えておけばよい？ n[:2]は[1 2]。最初から2個目までを取り出すという意味。 n[2:]は[3 4 5 6]。n[2]から最後まで取り出すという意味。 スライスの中にスライスを宣言することもできる。

var board = [][]int{
  []int{0, 1, 2}
  []int{3, 4, 5}
  []int{6, 7, 8}
}

とすると[ [0 1 2] [3 4 5] [6 7 8] ]が宣言できる。 スライスはappend(n, 入れたい値)で要素を末尾に追加できるが、配列はリサイズ不可能なので要素追加できない。 makeでスライスを宣言する方法もある。

n := make([]int, 3)

[]int型の長さ3、キャパシティ5のスライスを作れる。 len(n)で長さ、cap(n)でキャパシティが表示できる。キャパシティは柔軟なので、超える量の値が来たら要素をすべて追加して超えた量だけキャパシティが増える。

b := make([]int, 3)

では長さ、キャパシティともに3になる。makeはキャパシティ分をメモリ確保する。

関数

func add(x, y int)(int, int) {
  z := x+y
  return z
}

関数名（この関数内で使う変数）（返り値の型）という形。x, y intでどちらもintになる。返り値を複数返すことができ、複数返すなら(int, int)のようにする。 返り値の部分で(result int)とするとint型のresultを返す。関数の返り値を代入する変数には型を宣言しなくてもよい。

クロージャ

f := func()

とすると,fという名前のfuncの処理をする関数ができる。 func (x int){ fmt.Println("inner func", x) }(1) とすると、一回変数に入れなくてもこの関数が動く。

func incremaentGenerator()(func() int){
  x := 0
  return func() int{
    x++
    return x
  }
}
func main(){
  counter := incrementGenerator()
  counter()
}

counter()でincrementGeneratorが動く。関数が返り値として帰ってきているため。counterを呼ぶと1ずつ増えていく。 どう使うかという例

func circleArea(pi float64) func(radius float64) float64{
  return func(radius float64) float64{
    return pi*radius*radius
  }
}

c1 := circleArea(3.14)
fmt.Println(c1(2))

でpiが3.14、radiusが2の状態で上の関数が動く。

c2 := circleArea(3)
fmt.Println(c2(2))

でpiが3、radiusが2の状態で上の関数が動く。 この2つの状態をmain関数の中で記述できる。具体的には、関数の中の値をmain関数の中で設定して呼ぶことができる。

可変長引数

func foo(params ...int){}

で可変長引数が宣言できる。これは、引数の数が変わっても柔軟に対応できるもの。

s := []int{1, 2, 3}
foo(s...)

とすると、[1 2 3]を渡せる。展開して引数として渡している。

if文、for文

if 条件文　{} 条件文に()はいらない。

if result2 := by2(10); result2 =="ok"{}

でby2の返り値がokかどうかのif文が書ける。

for i :=0; i<10 ;i++{}

が基本。()はいらない

l := []string{"python", "go", "java"}
for i,v := range l{
  fmt.Println(i,v)
}

とすると、0 python 1 go 2 javaが出力される

m := map[string]int{"apple":100, "banana": 200}

for k, v := range m{
  fmt.Println(k, v)
}

とすると、apple 100 banana 200が出力される

switch文

defaultはなくてもよい。C言語と基本的には同じ。だが、条件式に()がいらない

defer

遅延実行を宣言する。

func main(){
  defer fmt.Println("world")
  fmtPrintln("hello")
}

とすると、hello worldが出力される。つまり、deferの行はその関数の最後に実行される。 注意点としては、

func main(){
  defer fmt.Println("1")
  defer fmt.Println("2")
  defer fmt.Println("3")
  defer fmt.Println("4")
}

とすると、出力は4321になる。deferの処理はスタック順になるため後入れ先出しになるため。 deferをファイルクローズに使うと、openした次の行に書けるため、クローズし忘れることがなくなる。

log

log.Println("logging!")とすると、日時を表示した後logging!が表示される log.Printf("%T %v, "test","test")とすると、日時を表示した後string testが出力される log.Fatalln("error!!")がよく使われる。これは、Fatallnの行でプログラムが終了する log.Fatalf("%T %v, "test","test")でもこの行でプログラムが終了する

エラーハンドリング

ログの内容をファイルに書き込む

func LoggingSettings(logFile string){
  logfile, _ := os.OpenFile(logfile, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
  multiLogRFile := io.MultiWriter(os.Stdout,logfile)
  log.SetFlags(log.Ldate|log.Ltime|log.Llongfile)
  log.SetOutput(multiLogFile)
}
LoggingSettings("test.log")

func main(){
  file, err := os.Open("./lesson.go")
  if err !=nil{
    log.Fatalln("Error!")
  }
  defer file.Close()
  data := make([]byte, 100)
  count, err := file.Read(data)
  if err != nil{
    log.Fatalln("Error")
  }
  fmt.Println(count, string(data))
}

とすると、100　lesson.goの内容が表示される。os.Openは、エラーでなかったらnilを返す。file.Readもエラーでないならnilを返す。よって、nilでないならエラーである。 ほかの言語ならtrycatchを使うが、goはこのようにする :=は、最低一つ代入があれば使える。同じ変数名だったら上書きされる。

os.Chdirは、errorという1つの数を返すので、 err := os.Chdir()とするとエラーになる err = os.Chdir()とするとエラーにならない if err = os.Chdir("test); err != nil{ log.Faralln("Error") }

panic, recover

panicは、自分で例外を投げられる。

func thirdPartyConnectDB(){
  panic("Unable to connect database!")
}
func save(){
  thirdPartyConnectDB()
}
func main(){
  save()
  fmt.Println("OK?")
}

として実行すると、panicでメッセージを表示した後エラーを表示して強制終了する。

func save(){
  defer func(){
    s := recover()
    fmt.Println(s)
  }()
  thirdPartyConnectDB()
}

に変更するとpanicのスタックトレースを表示しない。recoverはpanicで強制終了しないようにできる。 deferの部分は先に書くこと goはpanicを自分で書くことを推奨していない。panicを書くコードはなるべく書かないようにする。

終わりに

goの基本を学びました。学ぶだけでなく、実際に使ってみないと身につかないのでこれから何か作っていこうと思います。

「聞き手を『前のめり』にさせる登壇技術を勉強する会」の参加レポート

3/12に開催された、エンジニアの登壇を応援する会による「聞き手を『前のめり』にさせる登壇技術を勉強する会」に参加してきました。今回は、登壇内容の設計から実際に話して伝えるところまで学ぶことができました。登壇なさった方は、ariakiさん、かっきーさん、KANEさん、てつのすけさんでした。イベントページに登壇スライドがあるので、ぜひ見てみてください。

engineers.connpass.com

登壇内容を設計しよう/ariakiさん

登壇をやろう！となった時に、資料がないと話すことができません。また、良い資料がないと良い登壇もできません。登壇時のテクニックも重要ですが、事前準備や内容の設計が重要だとわかりました。 私なりのキーワードは以下の通りです。

• 最も深い見識を伝えることが常に最適ではない！
• パーソナルブランディング、タグ付け
• ペルソナ設計
• 知らなかった、の割合は2～3割が良い
• 内容を聞いた後の行動を設計する

登壇初心者が語彙力を高める技術を学習したお話 / かっきーさん

登壇のためにいい資料を作っても、内容が伝わらなければ意味がありません。伝える力に語彙力があります。語彙力は言葉の調味料です。よって、語彙力のさしすせそがあります。語彙力のさしすせそを用いて、聴講者にイメージしてもらえる伝え方が分かりました。 私なりのキーワードは 以下の通りです。

• 語彙力は相手がイメージできる内容に言い換える力
• 数字は過去からの推移も示す
• 登壇は成長と自信をくれる

登壇における声の届け方 / KANEさん

内容が良くても、伝え方がうまくても、声が届かなければ意味がありません。声を風船に例えて、風船を届けるにはどうするのが良いのかという話でした。実際に参加者で声を出したため、楽しい雰囲気になりましたし、技術を使うと良くなるということが実感できました。声をうまく届けるための方法が分かりました。 私なりのキーワードは以下の通りです。

• 減衰と指向性
• 発表練習しないと身振り手振りまで行かない
• Podcastを配信しましょう！

研修講師が注意しているオープニングトークのデザイン / てつのすけさん

内容が良くて、伝え方がうまくて、声が届くなら、最初のつかみもうまくやりたいですよね。プレゼンの最初のつかみにあたる、オープニングトークについてのお話しでした。聴講者が手を上げるという動作によって参加している感と一体感がありました。参加者がプレゼンに参加してもらえるよう、心がけることや手法が分かりました。 私なりのキーワードは以下の通りです。

• 出会う絵
• 聴衆態度のスタート地点を考慮
• サプライズはされる相手の気持ちを考えて
• いいプレゼンとはエスコートである

出会う絵の意味はぜひスライドをご覧ください。

スポンサーLT

forkwell様

いろいろな勉強会をスポンサーしてくださるforkwellさんのLTです。forkwellの説明だけでなく、勉強会の趣旨に合わせた内容を盛り込んでいただけることがあり、大変ありがたいです。今回の内容はためになりました。今後、ぜひ使わせていただきます。

• 抑揚を文字の大きさでメモる
• 間をとるには同じスライドを複数枚作る

株式会社カサレアル様

今回場所を提供していただいたカサレアル様のLTです。カサレアルとは、スペイン語で「真の家」という意味だそうです。ロゴマークは家の形になっています。いろいろなプログラミング言語の研修を提供しており、すべて最新版に対応しているとのことです。

最後に

登壇の技術を準備、伝え方、発声、つかみの4要素から学ぶことができました。学んだことを生かしていければ、登壇内容をより良いものにできます。私もこれから登壇するときは聴講者のペルソナや自分が伝えたいことを設定して伝え方を考え、発表する際には発声に気を付けるとともに出会う絵に取り組むことができるようにしたいと思います。

エンジニアのキャリアを語るMeetUp【しがないラジオ×kiitok】の参加レポート

エンジニアのキャリアを語るMeetUp【しがないラジオ×kiitok】に参加してきました。

trackrecords.connpass.com

しがないラジオは、SIerからWeb系に転職した2人のエンジニアがパーソナリティを務めているPodcastです。2人だけの回もあれば、ゲストをお呼びすることもあり技術の話からキャリアの話までします。リスナーは転職を考えている人が多く、Meetupを行うと多くの人が集まるコミュニティの面もあります。 kiitokは、転職を前提とせずに現役エンジニアにキャリアの相談ができるサービスです。現在活躍されているマネージャー職の方に自分のキャリアについて相談できるので、とてもいいサービスだと思います。

今回のイベントでは、kiitokのメンターでもある、Gunosy加藤さん、エス・エム・エス田辺さん、リブセンス竹馬さんの3名から、ご自身のこれまでのキャリアに関するLTと登壇者によるパネルディスカッションが行われました。

私の属性

歴史ある大企業メーカの子会社勤務です。親会社の風土を受け継いで古い考えの部分があるので、現在は変化を起こそうと行動中です。

LTについて

今回のLTは、技術的な内容ではなくキャリアの話でした。自らのたどってきたキャリアパスを話しながら、その時にどう考えてどう行動したのかということを話していただきました。職場の閉塞感を感じた、成長できないと感じた、人とのつながりがキャリアにつながった、転職のきっかけは三者異なるものでした。しかし、転職する際によく考えていた、少し先の未来を見ていたというのは3者とも同じだったと思いました。

パネルディスカッション

自分が気になった話題を2つ取り上げます。

転職活動は気軽にしていいの？

気軽にしていいという話でした。採用側としては、転職する気があまりない人でも出会って説明すると選考に進んでくれることがありますし、応募側としては出会う企業を増やすことができます。出会いは運の要素が強いですが、とてもいいことに出会えると幸せです。出会いは何が起こるのかが分からないものですということでした。

エンジニアのキャリアを考える人に一言

心の持ちよう、マインドセット、今楽しいかどうかを大切にということでした。しっかり寝て、美味しいものを食べることで心の持ちようが変わり、見える景色が変わってきます。自分の今いる場所で楽しいことを見つけ出すのも才能ですが、見つけようとしても見つけられないのはどこかで閉塞感を感じているからです。人の経験できる会社の数には限りがありますし、楽しくないなら転職すればいいとのことでした。

感想

当たり前ではありますが、すごい人がすごい人たるのは今までの経験やスキルが積みあがっているからです。キャリアパスをお聞きしたときにそのことを強く感じました。そのことを忘れて私は焦り、大きな将来の不安に押しつぶされそうになり考えるのをやめてしまうことが多くありました。キャリアを考えていくことも大切ですが、それよりも先に今現在で経験やスキルを積み上げていくことが重要だと感じました。kiitokのメンターの方と懇親会でお話しした際にこの結論に至ったので、kiitokでお話を聞いていただくとよりよい未来に近づく方法のヒントが得られると感じました。私も使ってみようと思います。イベント会場を後にする際、他の参加者の方が「いいコミュニティだった」とおっしゃっていたのはとても印象的でした。

「カイゼン・ジャーニー」を読んでの感想

この記事の概要

「カイゼン・ジャーニー」を読んだ私が、感じたことを書いていきます。

「カイゼン・ジャーニー」とは

舞台はIT企業。主人公が自分一人の行動から会社を変えていき、その後アジャイル開発に挑んでいくお話です。物語仕立てとなっており、読みやすいだけでなく実際のアジャイル開発に役に立つ知識も学ぶことができる本です。

読んだ感想

何かを始めたいなら自分から始める。これが重要だと感じました。アジャイル開発に関しては、やってみたいとは思いますが弊社には取り入れにくいと感じました。アジャイル開発は、成功例をそのまま持ち込むと成功するような万能なものではないです。置かれた状況に合うように変えたものを導入するのが良いと聞いたので、それを考えようと思いました。

印象的だった文

• あなたは何をする人なんですか？
  この言葉、めっちゃ心に刺さりますね。「何をする人」というのが内省というか、自分と向き合うきっかけを与えてくれる言葉なんだと思います。デブサミ2019で「あなたは何をする人なんですか？」と書いてある付箋をいただきました。これを会社の自分のデスクに貼っておくと目についたときに気が引き締まるのでお勧めです。
• 勉強会からの帰り道は、現実への帰り道
  これも私にはかなり刺さりました。勉強会に参加して、何か学びを得て帰る。これが当然ですし、私も行っています。しかし、この言葉を見た後自分を振り返ると、最近は勉強会に参加すること自体が目的になっているように感じました。勉強会に参加すること自体が楽しいと思っており、楽しむことが学びを得ることよりも優先度が高くなっているように思いました。勉強会は、社外の場で、社外の人と関わることになります。要するに、非現実感なのです。非現実感を楽しんでいるだけなのではないかとも考えさせられました。また、参加したことで満足してしまい、勉強会の内容を身に着けることができているのだろうかとも考えさせられました。勉強会という非現実で楽しい場所から、自宅に帰るということは、また自分の職場で働くことを意味します。現実への帰り道で、何を得ることができたのか、何をこれから生かしていけるのかということを考えることが重要であり、そうしていこうと思いました。

  最後に

  「カイゼン・ジャーニー」は名著だと思います。アジャイルに興味があるけどどう勉強したらいいのか迷っているという人にはかなりおすすめです。知識として持っておくこともできるので、ぜひ一回読んでほしいと思います。

いきなり１on１を受けてきました

いきなり１on１とは

nitt-sanさんという方が行っている、あまりお互いに面識がない状態で1on1を行うことでコーチングのスキルを向上させるという取り組みです。やる側からするとスキルの向上になるし、受ける側からするとこれからの道筋が見えるというWin-Winの関係になる素晴らしい取り組みです。

nitt-sanさんの振り返り記事

概要に関しては、nitt-sanさんのブログにある今回の1on1の振り返り記事をご覧ください。話した内容は、この記事のノートにすべて書いてあります。

nitt-san.hatenablog.com

感想

1on1開始前

1on1をする場所を探す際には話しながら移動するわけですが、私はnitt-sanさんとはまだ1回しかちゃんと話したことがありませんでした。このような状態では私自身が話題に困る人なので、話題に困りながら移動することになるかと思ったのですが、杞憂でした。nitt-sanさんがいろいろと話題を振ってくれました。このことは、話しやすい雰囲気を作り出すスキルが高いゆえなのだろうなと感心していました。

1on1中

グラフィックレコーディングというんですね。nitt-sanさんが話しながらノートに図を描いていたのですが、すごくわかりやすかったです。お互いの認識の齟齬がなくなるので無駄な時間が減るし、自分としては同じようなことを何回も話す癖があるので、もうこれは話しているということが分かるというのが一番の効果でした。終わった後に描かれた図を見ると、話したことが全部わかるし、すごい良いものだなと思いました。

1on1終了後

普段業務で1on1はしておらず、どのようなものなのかわかっていませんでした。ですので、優先度を高くした内容がコーチングにつながるものではなく、カウンセリングにつながるものだということが分かっていませんでした。こちら側の反省点です。ですが、自分の考えや状況を話すことによって整理し、自覚して考えていくという点ではカウンセリングもコーチングも同じなのではないかと感じました。自分が考えていることは、ただ単に循環しているだけで次に進むことができていなかったことが分かり、スッキリしたと同時に、次にやるべきことが分かりました。また、自分の思考の癖が少しわかった気がします。

最終的に

私自身、新卒1年目で雑務しかやっていないということもあり仕事に関して大きく困ったことはありませんでした。しかし、このような状況では何もスキルがないということを考え、将来への漠然とした不安と焦りが自分の思考を堂々巡りさせていたということが分かりました。これからは、自分がコントロールできる範囲を少しずつコントロールしていくようにしていこうと思いました。定期的だと形骸化するかもしれないので、行きたいときに行ける1on1があるといいですね。kiitokはいいサービスだと思います。1度でもいいので、スキルのある人に1on1を受けると大きな学びがあると思います。

EMFM Meetup#1 参加レポート

ゆのんさん・広木大地さんがパーソナリティを務めるEM（エンジニアリングマネージャー）のためのPodcast、EMFMの2万回再生記念（当日は、危うく3万回突破しそうだった）の公開収録イベント、EMFM Meetupに参加しましたので、感想を書こうと思います。

はじめに

私はEMではなく、中小メーカ勤務の新卒1年目です。将来はIT企業に転職して、マネジメントをやっていきたいと思っています。いわゆるPjMしか学生時代は知りませんでしたが、EM, PdMという役割を知って興味を持ち勉強しているところです。知らないことが多いため、日々勉強しています。適切に見積もることや仕事を割り振ることは技術を知っていないとできないため、技術の勉強も進めていこうと考えています。

内容

公開収録でのゲストは、メルカリのVPoEの方とCTOの方でした。メルカリの取り組みはもちろん、マネジメントをどう考えているかという個人の考えも聞くことができました。自分が興味を持った部分のメモを書き留めておきます。

メルカリがダイバーシティを目指す理由

ダイバーシティのため、外国人も積極的に採用している。いろんな価値観を持っているチームがいろんなことに取り組むと、チームの力で想定していたよりも良いものを作ることができる。また、新しいものを生み出すスピードも速くなる。エンジニア一人ひとりが個性を発揮することによって、勝手にプロダクトがよくなる組織を作ることができる。このような状況だと、マネジメントは難しくなるが、マネージャーは成果のためにみんなが一つになるために、新しいやり方を考えて見つけていく必要がある。一人一人のエンジニアが自由に発想してやっているが、会社にとって不利益にならない世界を目指す。自分で考えて決め、実行していくことがこれからのエンジニアに必要になっていく。好きなことをやらせて、データで会社に不利益か判断して続けるか決める仕組みが必要になる。

非エンジニアとのコミュニケーションに必要なこと

• 意思決定に必要な情報を伝える
• リスペクトする
• Fact,Recommend,Willを持っていく
• 普段から失礼にならない程度にコミュニケーションする

コミュニケーションのきっかけとして、山登りはいい。 山登り中と、後の温泉でディスカッションできる。さらに、運動後で新しい考えが出ることがある。

そのほか

‐ エンジニアは、技術志向の先にプロダクトをちゃんと見ているかが重要。技術は陳腐化するので、変化を受け入れられる人が強い - 入って2，3年目で自分をクビにできるほど仕事をなくせないと無能だと考えている（私はこれが一番の衝撃でした）

感想

EMという言葉を初めて聞いたとき何をする役割なのか全然わかりませんでしたが、EMFMを聞くことで少しずつ理解できていると思います。組織によって必要な行動は変わるし、不確実性と向き合う仕事なので難しい。しかし、エンジニアの成長を支援するなど、とても価値のあるものだしとても面白いものだと感じた。自分が必要なくなるほどチームを作り上げることはとても面白く、とても価値があることだと感じました。

最後に

EMFMは、エンジニアのマネジメントをする人が聞くと必ず学びがあるものだと思います。聞いたことがない方はぜひ聞いてみてください。じっくり考えながら聞くことは難しいですが、EMFM公式応援団（月額500円）に入れば文字起こしされた内容を見ることができます（現在1話のみ、順次拡充予定だそうです）。文字起こしした内容を見ることができるのは本当に嬉しいです。広木さんに話しかけて、「エンジニアリング組織論への招待」の本ににサインをいただけたのは嬉しかったです。緊張してうまく話せなかったのが心残りです......。