ごまなつ Blog

楽しく働ける世界を目指して

『はじめる技術 つづける技術』を読んで

技術書典6で購入した中の1冊、『はじめる技術 つづける技術』を読んだ感想です。私は、何かを続けようとして習慣化しようとして失敗した人に特に読んでほしいと思います。

はじめることについて

やりたいことがないのは、やりたいことになるであろうことを知らないだけです。知ることから始めましょうということでしたが、その通りだなと思いました。趣味は、突然はまっていくことが多いですが、その時がやりたいことを知った瞬間なんだなと思いました。やらないことを選んでいるのは自分であり、やらない理由を探しているというのは、まさに自分だなと思いました。何かを始めるには、今始めるのが一番早いです。他人と比較せず、自分のペースで進め、過去の失敗にとらわれすぎないというのも重要だと思いました。未来について、失敗を恐れすぎず、失敗してもいいような状況にして失敗するのが良いと思います。しかし、一番重要なのは無理して始めようとしないことです。体調、心理状態もあるし、それが自分にとってやらなければならないことなのかということも考えようと思いました。

私は、ある物事をやる前に判断してしまうことがあります。それは自分の先入観によるものなので、先入観を持たないように、やっていないのに判断しないように心がけようと思います。

つづけることについて

やる気がないときはやらない！それについて罪悪感を持つ必要はない。続けるのはつらいことなのだから...... 確かにこれが重要だと思いました。習慣化するのが良いと聞き、習慣化しようとしたときに少し失敗したときに罪悪感を感じやめてしまうことがありました。やるにしても休むにしても自分で選ぶことで、考えるきっかけを作るようにしたいと思います。

周囲を意識してしまう、これは承認欲求ですね。SNSは簡単に情報発信とレスポンスができるからこそ、この悩みに直面する人が増えたと考えています。これで頑張れるなら無理しないよう注意する、心が折れるならほかのことをしてそちらの評価を待ったり、気分転換する。また、タイミングが悪かっただけかもしれないという要素が考えられることを知り、私が承認欲求とどう向き合うか考えていこうと思いました。効果については、成長にかかる時間・やり方を考え、内容について悩むことで止まってしまわないようにしたいと思います。

続けるのはつらいことです。よって、休むことの重要性に気づく、決めたことを守れなかったことで悩んで立ち止まらないということをこれから心に留めていこうと思います。

あとがきについて

これらの技術を紹介したあと、なんでこの本を書いたのか説明されていました。それは、はじめて続けて、楽しさを感じ、それを誰もが発信している世界が最高だからそうしたいとのことでした。私もこの本を読んで書いてある技術を実践し、何か楽しいことを発信する一人になれるよう頑張ります！

Go言語学習記録

技術系

ポインタ

C言語と同じようにポインタがある。

ポインタ型変数宣言は

var p *int = &n

ポインタの処理はＣと同じ。メモリ番地と値の関係になっている。 アドレスの値を見たいときは*nのようにする。

s := make([]int, 0)は[]int
m := make(map[stirng]int)はmap[string]int
ch := make(chan int)はchan int
var p *int = new(int)は*int
var st = new(struct{})は*struct{}

makeとnewの違いは、ポインタを返すならnew, そうでないならmakeということ。

構造体

type Vertex struct{
  X, Y int
}
func main(){
  v := Vertex{X: 1, Y: 2}
}
fmt.Println(v.X, v.Y)

で1 2が表示される。 構造体の要素の名前が大文字だとpublic,小文字だとprivateになる。

var v4 Vertex v4 := Vertex{}
v6 := new(Vertex)とv6 := &Vertex{}

はそれぞれ同じ意味になる。

func changeVertex(v Vertex){
  v.X = 1000
}

v := Vertex{1, 2, "test"}
changeVertex(v)
fmt.Println(v)

では、{1 2 test}が表示される。値は変わっていない。構造体の値を渡しただけで、本体は変わっていないため。

v2 := &Vertex{1, 2, "test"}
changeVertex(v2)
fmt.Println(v2)

では、&{1000 2 test}が表示される。fmt.Println(*v2)にすれば、{1000 2 test}が表示される

メソッド、ポインタレシーバー

//関数の書き方
func  Area(v Vertex)int{
  return v.X*v.Y
}
//メソッドの書き方
func (v Vertex) Area() int{
  return v.X*v.Y
}

構造体vがArea()という関数を持つようにするイメージ。 呼び出すときはfmt.Println(v.Area())でできる。 メソッドがvに紐づけられるので、v. とすると補完でArea（）が出てくるようになる

func (v *Vertex) Scale(i int){
  v.X = v.X * i
  v.Y = v.Y * i
}

v.Scale(10)で呼び出せるが、もしこの関数のVertexのをなくすとこの関数が読まれなくなる。 この関数をポインタレシーバーという。普通の関数は値をもらうので値レシーバーということがある。

Embedded

goには継承がないが、Embeddedというものがある

type Vertex struct{
  x, y int
}

type Vertex3D struct{
  Vertex
  z int
}

こうすると、Vertexにⅹとyは組み込まれているので、Vertex3Dはx,y,zを持っている. 書き方は

func (v Vertex3d) Area3D() int{
  return v.x * v.y　* v.z
}

func New(x, y, z int) *Vertex3D{
  return &{Vertex{x, y}, z}
}

goには継承がないが、Embeddedで同じことができる。

type MyInt int

func (i MyInt) Double() int{
  return int(i * 2)
}

func main(){
  myInt := MyInt(10)
  fmt.Println(myInt.Double())
}

structではない自分だけの型のメソッドを作ることもできる。func (i MyInt) Double() intの中のiの型はmain.MyIntになっている。

ダックタイピング

type Human interface {
    Say() string
}

type Person struct {
    Name string
}

func (p *Person) Say() string {
    p.Name = "Hi, " + p.Name
    fmt.Println(p.Name)
    return p.Name
}

func DriveCar(human Human) {
    if human.Say() == "Hi, Mike" {
        fmt.Println("Run")
    }else{
        fmt.Println("Back off")
    }
}

func main() {
    var mike Human = &Person{"Mike"}
    var x Human = &Person{"X"}
    DriveCar(mike)
    DriveCar(x)
}

interfaceで指定したメソッド(今回はSay())を持っていないとエラーになる。絶対持っていてほしいメソッドを指定するときに使う。 Say()はポインタレシーバーになっているので、アドレスを渡す。func (p *Person)に&Person{"Mike"}を渡すということ。 この例では、 DriveCar(human Human)の時に、Humanは絶対にSay()を持っていなければならないというものになっている。 interfaceで指定したメソッドを絶対に持っていなければならないようにすることをダックタイピングという。

interface型、タイプアサーション

func do (i interface{}){}

のようにinterfaceを引数にするとどの型も受け取れるようになる。しかし、

func do (i interface{}){
  ii := i * 2
}

はエラーとなる。interface型は四則演算ができない。そのため、

ii := i.(int)
ii *= 2

としてタイプアサーションをしなければならない。つまり、interfaceには何でも入るが、入った段階ではinterface型なので、タイプアサーションをするひつようがあるということ。 stringは

ss := i.(string)

とする。 switch type文があり、これを用いて

func do (i interface{}){
  switch v := i.(type)
  {
    case int:
      fmt.Println(v * 2)
    case string:
      fmt.Println(v * "!")
    default:
      fmt.Printf("I dont know %T\n, v)
  }
}

とすると、どんな型でも受け取れる関数ができる。 goでは、一般的なキャストをタイプコンバージョンということもある。interfaceの要素に型をつけるのは、タイプアサーション。

type Person struct {
  Name string
  Age  int
}

func (p Person) String() string{
  return fmt.Sprintf("My name is %v", p.Name)
}

func main(){
  mike := Person{"Mike", 22}
  fmt.Println(mike)
}

こうすると、出力結果はMy name is Mikeになり、Ageを出力しないようにできる

カスタムエラー

type UserNotFound struct{
  Username string
}

func (e *UserNotFound) Error() string{
  return fmt.Sprintf("User not found: %v", e.Username)
}

func myFunc() error{
  //something wring
  ok := false
  if ok{
    return nil
  }
  return &UserNotFound{Username: "mike"}
}

func main(){
  if err := myFunc(); err != nil{
fmt.Println(err)

とすると、自分で決めたエラーメッセージを表示できる。UserNotFoundがポインタになっているが、これをポインタにしなくても実行はできる。しかし、エラー内容の比較を行う際に問題が起きる。違うエラーとして定義して比較してもtrueになる。 ファイル入出力に使うライブラリにioがあり、その中にio.EOFがある。(EOFはEnd Of File)自分でErrors.New("EOF"）として作っても、io.EOFとは違うEOFになることに注意する。エラーにはポインタを用いること。

倉貫義人 × 沢渡あまね トーク&ワークセッション「新しい組織・働き方のあり方」参加レポート

勉強会

3/27に開催された、倉貫義人 × 沢渡あまね トーク&ワークセッション「新しい組織・働き方のあり方」に参加してきました。私のメモをまとめたものになります。うまく整理されていないかもしれませんがご了承ください。

管理とは？

日本語の管理は英語の3つの意味を持っている

  • Management（やりくり）
  • Control（統制）
  • Administration（事務執行）

良い管理、悪い管理とは？

良い管理は、本来価値に振るコミットする仕掛けを作るため、本来価値へのコミットの障害を取り除くもの。 悪い管理とは、管理職が管理職であるためにやるもの。無駄な決裁など。

  • 大企業になると、決まったことに経理、総務などが「法人をかませてください」などといった本質を見ていない管理が入る。子会社、支社だと、親会社、本社から本質を見ていない管理が入る。それに気づいた人は、本社飛ばし、親会社飛ばしをしている。
  • 役割、部署が何のためにあるのか、本質を見ていない
  • 社員を管理したいなら、それはコンピュータが得意なので任せればよい。わざわざ紙に印刷して人間が確認といった手間は無駄。

管理は必要悪である。しょうがないから管理をしている。しかし、管理はお金を生まない。管理がなくても生産性が上がるなら、管理に使っていた管理職の人件費が要らず、それが利益になる。管理は減らすべき。

管理の中にManagementがあるモデルはいまの時代に合っているのか

Managementは、「なんとかする」という意味。管理ではない。しかし、Control, Administrationは管理に近い。たくさん手を動かした人が成果を出せる仕事なら、管理すると成果が多く出る。しかし、今の仕事は毎日違う仕事をするし、誰もが同じ仕事をしていない。つまり、再現性が少ない仕事が増えてきたため、管理ではMagagementできない。Managementのほうが管理よりも上位概念なのでは？今の時代にはManagementの手段に管理が合わなくなっている。管理の仕方が昔と変わっていないのが問題。産業革命時代の製造業であれば、管理をすればするほど成果が出た。現在の日本では管理が製造業型であるため、このような状況になっているのではないか。

評価について

同じ仕事をしていないのにできる？実際は高い評価をつけるための作文ごっこや、ノルマが上がらないように評価をすり合わせたりする。まさにごっこ。出世をする人を決めないといけないので評価に差をつけろと指示が出る。しかし、みんな優秀だし、低くなった人はモチベが下がる。評価はもともとはランク付けするためではなく、気持ちよく仕事するためのものだったのでは？評価するよりも、その人のキャリアを一生懸命考えてあげることが必要。

性善説の管理になぜできる？

ソニックガーデンの採用基準は厳しい。入社前にかなり審査している。応募があってから入社まで1年から1年半かかる。その間は友達になる期間と考えている。友達になれるほど信頼しているから、性善説ができる。他にも、会社のビジョンと共鳴していれば、信頼できて性善説ができる。

性善説のいいところ

オペレーションコストが下がる。従来では信頼関係が構築できたのに、ガチガチなコミュニケーション（性悪説）をしているので管理コストがかかっている。 コストをどこにかけるのかの問題で、性善説は採用にコストをかけて、管理にコストをかけていない。 なぜ従来のようになるのかというと、入社ハードルが低いから、管理コストがかかる。管理はその人がいる間ずっとしなければならないので継続的なコスト。 採用コストは採用するときの一過性のものだからこのほうが効率いい。実質、友達であることが重要。

職場で本音を言えていますか？

一言で言えば心理的安全性があるかどうか。評価をなくしたのでやりたいことと業務のすり合わせの面談をしているが、そこでは何でも言っている。

本音が言えない背景6つ

  • 勇気がない、怖くて言えない
  • わざわざ言わない（時間かかる）
  • 言語化できない（もやもやのままになっている）
  • 気づかない、気づけない
  • この人たちに言っても仕方がない（無力感）
  • 得をしない

言えなくても、景色を合わせることができると簡単に解決することがある。それぞれの立場で意識はずれているので、現場に来てもらうなど景色合わせをすると良い。立場の話だと、もし自分が上司なら、自分から本音を言うと相手も本音を言うようになる。

組織の問題解決

今の自分の組織の問題点をみつける。働き方改革は言葉が重過ぎる。小さな課題でもいい。KPTのふりかえりをする。問題に対して考える、振り返りから始める。 自分たちで自分たちのことを認識しないと始まらない。 仕事のやり方を変えていくことを考える時間を作る。 進捗が遅れるのは何か悪い構造があるのではないかと考える。

木こりの斧

木こりが一生懸命木を切っているが、かなり遅い。旅人が見ると、斧がさびている。「斧がさびているから、研いだらどうか」「そんな時間があるわけないだろ」 これがどこでも起こっている。時間を手続きに置き換えてもよい。人間は意識では変わらないので、あらかじめ予定に入れておく。予定に振り返りの時間をあらかじめ決めておく。自分の気持ちに行動を頼らず、予定を入れておくと行動できる。

肯定ファースト

人間は肯定されることを望んでいる。肯定することから始める。相手に対してまず肯定する。褒めるのが難しくても、存在を認めること。何を言われても「そうか」、という。生産性が最も高いのは心理的安全性が高い状態である。

論じてばかりで実行されない

  • そもそも、問題を言語化できていない可能性
  • 自分なら、実行する。他人なら、ほっとくと良い。どういうことかというと、他人に期待しすぎている。自分を変えられるのは自分だけ、これはすべての人に当てはまるので他人を変えることはかなり難しい。

問題解決の仕方

相手のキーワードを見つける。リモートワークを認めれば優秀な人が採れるとか。部署と役割で定義をした瞬間動かなくなる。総務がこうなるからというと戦えなくなる。 人の名前で考えてその人のところに行けばいい。人対人は話せる。それで動かないから仕方ない。会社を変えるために提案の形をとってはいけない。 上司は何か言っておかないととなる。相談の形で行く。こうするべき、という提案をするとと反発される。これで困ってるんですけど、どうしたらいいですかね…と相談するとよい。提案より相談。別に上の立場が下に相談してもよい。そのほうがやる気が出てうまく回る。

最後に

自分の力で他人をコントロールすることはできない。が、変わるきっかけを作ることはできる。目の前でできる人がいると変われる可能性がある。つまり、自分の周りでできることをやっていく。周りとコラボレーションするか、自分でやるかは自分で決める。自分のことを何とかしていくしかない。自分が成長実感を持つ。ロールモデルを見つける。自分がつぶれない、染まらないようにする。絶対にアウトプットする。

感想

まず、何よりもお二人のお話が面白く、聞いていてとても面白かったしためになりました。性善説の管理の話はすごく腑に落ちました。当たり前ではありますが、能力があるから、信頼できる人であるからそのような管理ができるということですね。採用にコストをかけて管理にコストをかけないというのはとても合理的だと思いました。自分にできることをやっていく、自分を何とかするというのは今の自分のテーマなので、地道に自分がコントロールできる範囲で努力していこうと思いました。

転職LT #4 参加レポート

勉強会

はじめに

3/25に開催された、転職LT#4 〜春の転職まつり〜 【はじめてのイベント参加歓迎】に参加してきました。最初にイベント初参加の方～？という質問があったのですが、多くの方が初参加でした。初めての方にも優しいイベントということが分かる出来事だったと思います。

スポンサーLT

スポンサーLTではありましたが、転職に関する知見もお話しいただ来ました。ありがとうございます。

株式会社DIVE INTO CODE様

転職したいというエンジニアは、転職したい、という未来へのことに目が向きがちです。しかし、転職をするのであれば

  • 今まで何をやってきたか、今どうしているか、長所と短所という過去と現在の棚卸を先に行い、先の5年、3年、1年それぞれでWill,Want,Mustを具体的に言語化します。
  • その後、理想の自分を達成するため、具体的な行動指針を決めよう。
    というお話しでした。

株式会社giftee様

転職はしていないが起業した@i7a16kさんのお話しでした。同期の起業を手伝うことで起業しましたが、起業はガチャ要素が大きいです。 起業は、以下の点を考えようということでした。

  • 副業からかかわる形を検討
  • 事業への興味があるか
  • メンバーと働きたいか
  • 事業の将来性があるか
  • ファイナンス知識を持っておく必要がある
  • 自分なりの撤退ラインを決める

転職活動の際に、SIerだからと卑下しなくてよいというお話もありました。VTRyoさんからSIerのスキルはB向けに活きるため、B向けSaasの企業にはSIer出身は重宝されるという補足もありました。

株式会社リブセンス様

GWは長い時間をとることができるので、そこで

  • 自分は何ができるか（それを示すためのアウトプットの方法）
  • 自分は何がしたいか（どんな会社？どんな技術使いたい？どんなエンジニアになりたい？なぜ？）
    をしっかり考えることができます。

転職活動することに意味があるので、転職活動を楽しんでやっていこうということでした。

転職成功者LT

@ryokky59さん

  • 退職してからエンジニアになるための勉強を始めた（1日10時間以上勉強）
  • 転職活動中、エージェント経由で面接を20回以上こなしていたため、Twitter転職をした際に面接で将来どうなりたいかなど、難しい質問を答えることができた
  • twitter, qiitaで学んだことをアウトプットしていたため、Twitterで転職宣言すると声がかかった。

行動力がすごい方だと思いました。アウトプットしていると、自信がついていくんだということもわかりました。Twitter転職は、自信があって客観的にスキルがあると思われないと成功しないものなんだなとあらためて思いました。

VTRyoさんの補足：githubだけで勝負しても、コードしか載っておらず、全部を見ることが難しい。自分でエラーを解決したかどうかがわからないので採用側は不安要素になる

@okash1nさん

所属企業にTwitterアカウントがバレている状態でTwitter転職の宣言をした結果、企業に混乱をもたらしてしまったというお話しでした。 気を付けることは、

  • 退職が受理される前にツイートしない
  • 会社が自分についてどう考えているかを考える（不義理になる）

です。現在、会社に依存しない時代だからこそ、人付き合いが大切です。SNS転職だからこそ、人付き合いが大切になります。入りたい会社の人が主催、参加している勉強会で関係構築しておくと良いのではないかということでした。

一般LT

@nomizoooneさん

職務経歴書、フォーマット決まってないんだから自分で作ろうよ、というお話しでした。実際に@nomizoooneさんの用いた職務経歴書は、とても見やすいものでした。また、面接では高確率で自己紹介が一番最初なので、自己紹介の練習はしておこう、緊張しにくくなるよということでした。

VTRyoさんの補足：Wordのスキルを証明するために、職務経歴書を自分でWordで作成した人がいた

tofu511さん

転職を始めた当初は内定が出なかった。Railsに挫折したが、Javaを用いていたためScalaはできた。Scalaを用いてポートフォリオを作ると順調に進んだ。転職できると、自分がコントロールできないことで思い悩むことが減った。自分で変えられる環境に行ければ、前向きにどう変えるのがいいか考えられるようになる。転職活動は失敗して、学んで改善していくことが重要。困ったら周りに助けを求めるようにしようということでした。

最後にVTRyoさんからひと言

行動力が重要。人と絡んでいく姿勢がいつか実を結ぶ。

感想

転職成功した方は、行動力が本当にすごい人たちだと思いました。自分も、行動力を高めていきたいと思います。とりあえず、GWにはまとまった時間が取れるので、過去、現在、未来のキャリアを考えて、具体的な方策を考えようと思いました。また、アウトプットをして自信をつけていったり、人とのかかわりを大切にしていこうと思います。

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でお話を聞いていただくとよりよい未来に近づく方法のヒントが得られると感じました。私も使ってみようと思います。イベント会場を後にする際、他の参加者の方が「いいコミュニティだった」とおっしゃっていたのはとても印象的でした。