桐生あんずです

京都在住大学生のブログです。日常やプログラミングについて書いてます。

京都の中小企業でエンジニアのアルバイトとして働いて1ヶ月経って思ったこと

桐生あんずです。

2017年12月からインターンとして働いていた会社で晴れて2018年2月にアルバイトになりお金をもらって働くようになったのですが、思ったこと、勉強したことみたいなのを振り返ってみようと思って書いてみたエントリです。

 

どんな会社で働いているのか

まずどんな会社で働いているのか紹介タイムに入らせていただきます。

一言で説明するのがちょっと難しいのですが、私がエンジニアとしてアルバイトをしている「株式会社坂ノ途中」は有機農業などの環境にやさしい農業に取り組む新規就農者さんや若手農家さんを応援し、環境負荷の小さい農業を広めることを目指す会社です。主なサービスとして自社のウェブサイトでお野菜の定期便サービスを運営したり、農家さんと買い手さん(スーパーやレストランなど)のマッチングやコミュニケーションを支援するWebサービス「farmO(ファーモ)」を運用しています。他にも、東京や京都で小売店を展開していたりも。

(京都の東寺のすぐそばにお店があります!)

f:id:kiryuanzu:20180318201253j:plain

ITをメインにしている会社ではなく流通な会社ですが、少量多品目の生鮮品の流通の現場ではITで解決するべき問題もたくさんあると感じています。私が所属しているITチームでは自社のECサービスの運用とfarmOの開発・運用がメインになっていて、私は主にfarmOの方に関わって主にバックエンドの機能追加や修正を行なっています。Rails周りをガリガリやっています。

オフィスには出荷を担当する方や経理や人事、営業をしている方など色んな方々がいらっしゃるのですがITチームの方も他のチームの方々もみんな優しい方々でリラックスした状態で仕事ができています。

そして野菜をたくさん使ったまかないを毎日食べています。すごく美味しいです。

f:id:kiryuanzu:20180318201438j:plain
f:id:kiryuanzu:20180318201345j:plain



 

実際にエンジニアとして働いてみて学んだこと

私のブログやTwiiterを以前から知っている方は既にご存知だと思いますが、去年の今頃はRailsを初めて触って間もないという状態でした。それからプログラミンスクールに行ったり自分のWebサービスを開発してみて、エンジニアのアルバイトをやってみたいと思い探していたところ、京都のインターネット界隈の繋がりのおかげで紹介してもらうことができました。

でも、やはり即戦力のエンジニアとしてはまだまだということでインターンとして簡単な機能修正や機能追加を行いつつ勉強したり教えてもらったりして、ある程度できるようになったらアルバイト採用という流れで1月の間出社させていただきました。そして、2月になって面談をしたのちに無事アルバイトとして採用されることになりました。エンジニアとしてお金をもらえるのは初めてのことで、決まったときはすごく嬉しかったです。

という経緯を説明したところで、どんなことを学んだかバンバン書いていくぞ!

1,チーム開発の感覚が分かるようになる

今まで個人開発では適当にGitコマンドを打ってコミット、リモートにプッシュをしていたわけですがそうはいかないのがチーム開発です。タスクごとにブランチを切って、コードを書き、コミットしてリモートにプッシュしコードレビューをしてもらいます。その中で「この書き方だとちょっとわかりにくいかも」、「もっとスマートに書けるんじゃないかな〜」などとアドバイスをもらえてすごく勉強になります。また、困った時にはチームメンバーにアドバイスや調べ方を教えていただけてありがたいです。また、こちらからも「このgemを使ってみたら良いと思います」「この設計やってみたいです」など提案して議論させてもらえてすごく楽しいです。

最近だと、開発に関わっている人たちを集めて開発しているサービスの機能を一から全部触るウォークスルーを企画してみんなで「この画面はどうなんだろう」「こんな機能あったら良いと思う」など議論できてすごく面白かったです。

個人開発の時は基本的に全部自分で考えて、ユーザーの声を聞きつつ機能修正をしていく流れでコードを書いていくことが多いですが、チーム開発の場合は様々な方と協力して議論しあってサービスを作り上げていく面白さがあり、やりがいがあると思います。

ちなみに、緊張感と慎重さを持ってGitコマンドを打つスキルがチーム開発には一番必要かもしれない…。

 

2,いろんな機能に触れることができる

インターンの最初期にはSEO対策(metaタグのdiscriptionの中身やTwitterCards)を個別ページごとにより適切にセットしようというコードを書きました。その中でも、どのように書いたら簡潔に書けるか考えたり、テストコードを書いてみたり、ちゃんと本番環境で反映されるかどうかチェックする必要があるなど様々な流れがあり、勉強になった記憶が残っています。

それ以外にも、ユーザのアクションを検知してSlack通知をつける機能やステージング環境と本番環境のfaviconのイメージを変えたり、ActionMailerのメソッドを新しく書くなど、個人開発では手が回らなかった部分にたくさん触ることができています。

最近だとSTI設計を作ってみる試みもさせていただいて、色々勉強になりました。(話すと長くなってしまいそうなので別記事でいつか書きたい)

また、バイト先で書かせてもらったコードを参考にして、個人開発のサービスの方にも機能を追加してみようという試みもできていてすごく良い循環になっています。

 

3,コードを綺麗に書く努力をするようになる

今までしていなかったのかよとなるんですが、大学4年までコードをまともに書いたことがなかったのでインデントのスペースなんて気にしないままコードを書いていることがかなりありました…。

今までは「動けば良いや」という気持ちで書いていた部分がかなりあったのですが、バイト先でコードを書くようになって「この記述もっと行数減らせるんじゃないのかな」とか「インデントのスペースの間隔が変で気持ち悪い」といったような感覚を得られるようになりました。よかった。

 

4,テストコード、デバッグのやり方を覚えてきた

今まで、個人開発の時はエラーが出たらエラー文をそのままググる→なんか色々試行錯誤して直すみたいなことばっかりで、テストコードもデバッグRailsチュートリアル以外ではほぼやったことがなかったのですが、バイト先で機能追加や修正のタスクをやるたびに「じゃ、まずテストコード書いてみよう〜!」とメンター役の方から提案されるようになったことで、書くようになりました。最初はassert関連のメソッドやインテグレーションテストの書き方もよくわからず、メンターの方に聞いてばかりだったのですが、もともと書かれていたテストコードを眺めているうちに書く流れがわかってきて最近はサッと書けるようになってテストを回すようになってきました。

もし通らなかったときはbyebugを駆使してコンソールでパラメータにちゃんと値が入っているかチェックしたり、テストログをおいかけてどんなエラーが起きているか見る癖もじわじわとついてきました。

デバッグのやり方は最初分からないことばかりでしたが、慣れれば慣れるほど自分で手を動かせるようになれるので楽しいです。

 

5,技術書をちゃんと読むようになった

お仕事としてエンジニアをやらせてもらってすごく楽しいし勉強になる!…のですが、今までザ・文系の人間で大学では情報学を全く学んでいない人間です。他の情報系の大学生の人たちに比べたら本当にまだまだだと思います。

実際のところ、すいすいとコードを書いて機能設計できている自信は正直まだまだなくて、スキルはまだまだだと思います。それでもこうやって雇って仕事を任せていただけて本当にありがたい限りです。だからこそ、絶対に強くなりたいと思いコンピュータ科学の基礎的な技術書からRubyの教本やDB設計の教本をガンガン読むことを始めました。

一冊一冊説明すると長くなってしまうのでまとめますが、こんな感じの本たちを2ヶ月の間読みました。

f:id:kiryuanzu:20180318201517j:plain

入門 コンピュータ科学」や「プロを目指す人のためのRuby入門」を読んだことで、プログラムの書き方が多少見えてくるようになったり、DB設計やサーバーの基本書を読んでみてどんな風にWebサービスが回っているかのイメージがどんどんと肉付いて見えるようになって良かったです。

ハッカーと画家」や「ネットコミュニティの設計と力」も、ものづくりやWebサービス開発において大事なことがたくさん書かれていてすごく面白かったです。

今までネットの文献で知識を得ようとすることが多くて、今でも実際にコードを書く時はネットで調べるのは欠かせないのですが土台の知識があってちゃんとしたコードを書けることに繋がることがわかってきてもっと早く読むべきだったとなりました。アルゴリズムとデータ構造系の分野がまだまだ弱い気がするので積んでる本を早く読み終えたい。

 

まとめ

バイトになってまだ1ヶ月ちょっとですが、振り返って見ると学べたことがたくさんあってまだまだ学ぶことが沢山ありすぎるという感じです。仕事がうまくできなくて悔しいと思うこともよくありますが、やっぱり情報学やWebサービスの勉強はやってて楽しいし、コードが書けるとすごく嬉しいです。

なんでこんなに楽しいと思うんだろうという理由の一つとして、最近読んだ「ネットコミュニティの設計と力」を読んでふと気付いたですが、今までラーメン研究会や京都大学サークルクラッシュ同好会のような様々な大学サークルのコミュニティを渡り歩いた経験から、自然と「コミュニティ」を育てたり関わることが好きになってきていて、それと同じ感覚でWebサービスをといった一つの「コミュニティ」を生成し発展させることに楽しさを覚えているんじゃないかなあということです。

バイト先では主に「農家さん」といった私が普段観測しているインターネットのメインユーザー層からは少し外れておりどう展開していくかまだ考えているところですが、その中でユーザーに便利かつ楽しんでもらえる機能を考えて実装していくことで、独特なインターネットコミュニティが形成できたらすごく面白そうだしやってみたいのが今後の目標です。そんなイメージをしつつも技術書読んでコードをガンガン書いていくぞ〜。

そんな感じの近況でした。

 

宣伝タイム

株式会社坂ノ途中では、Webショップで野菜の定期便の販売を行っています!

多様なお野菜セットが販売されております。お米やお茶、コーヒーも購入できちゃいます。どの野菜も甘みと栄養が詰まっているものばかりで大変美味しいものばかりです。

気になる方、まずはお試しセットからいかがでしょうか!!!

面白法人カヤックの「ブレストカード」で遊びました

桐生あんずです。
今日はサクラ荘の1階のリビングをお借りして、面白法人カヤックさんで出されている「ブレストカード」というブレインストーミングを手助けするカードゲームで遊びました。
brainstorming.kayac.com


「ブレストカード」とはイラスト入りの100枚のカードと他人のアイデアへの「乗っかり力」を高めるための「乗っかりチップ」7個が入っていて、この道具を駆使してブレストゲームをしていきます。
流れとしては、
①参加者の中からまず最初に1人投資家を決める。投資家は「アイデアを出して欲しいお題」を考えて他の参加者たちに伝える。

②投資家以外の参加者は、山札のカードから1枚ずつ順番に引いて30秒以内にカードから発想したアイデアをプレゼンしていく。

③全員がプレゼンし終わったら「乗っかり」フェーズに以降。投資家の「せーの!」の掛け声で他の参加者たちが自分のアイデアカード以外のカードに良いと思ったアイデアのカードに乗っかりチップを乗せる。

④投資家以外の参加者は、乗っかりチップを乗せたアイデアについて30秒以内で「これが良いと思った」「これを◯◯したら◯◯したらさらに良いと思う」など、想像を膨らませてプレゼンを行う。

⑤全員のプレゼンが終わったら、再び良いと思ったアイデアのカードに乗っかりチップを乗せて、④の時と同じように更にアイデアに対する想像を膨らませて参加者がプレゼンを行う。(なお、同じカードに乗っかりチップを乗せた参加者はグループワークを行なってアイデアを出し合ってもよい)

⑥参加者のプレゼンを聴き終えた投資家は、一番良いと思ったアイデアのカードに「ナイスアイデア!」と指差して1ゲーム終了。そのアイデアを発想した参加者、アイデアについて乗っかった者には60億円(!?)が分配される。1ゲームが終了したら最初の投資家になった参加者の左隣の者が投資家になる。そして全員が投資家の役割をこなした時点で本ゲームが終了し、一番資金を持っていたものが優勝。

お判りいただけたでしょうか。60億円が分配されるのがちょっとシュールですね。
このゲームの特に面白いところは、
「30秒以内で思い浮かんだアイデアについて話さなければいけない」「『乗っかりフェーズ』では、自分のアイデアには乗っかることはできず、他人のアイデアを膨らませていく」です。
なので、短い時間内にフッと思いついたアイデアをプレゼンしていかなければならないし、自分のアイデアは最終的には他人の手によって膨らまされていきます。

最初は「アイデアってすぐ出てくるか心配だし、人のアイデアを膨らませるのって難しそう…」と思ってしまいそうですが、やってみると様々な発見があってめちゃくちゃ面白かったです。
また、④の第一乗っかりフェーズでは「良いと思ったアイデア」について、参加者個人個人がプレゼンを行い、⑤では同じカードに乗っかりチップを乗せた人たちで1分ほどグループディスカッションを行なったのちにじゃんけんで勝った一人がプレゼンを行うチームプレゼン形式にしました。

全体的な感想を書く前に、まずはお題ごとの感想や流れを簡単な書いていこうと思います。面白そうなアイデアがたくさん出ました。(ちょっと長いので読むのが面倒になった人は飛ばしてもらって大丈夫です)

①雨の日を楽しむ方法

「水で膨らむと大きくなるおもちゃを街中にばらまく」、「服の整理整頓」、「雨の中で星を一番早く見つけるゲーム」などのアイデアが出た。
最終的に、「雨の中で星を一番早く見つけるゲーム」のアイデアが膨らまされて、「雨の中で星を見つけるゲームを婚活パーティーでやる。ペアでゲームを行なって、一番先に見つけたペアにディズニーランドチケットが優勝商品としてもらえる」といったアイデアが選ばれた。
他のアイデアにも元のアイデアからゲーム性を付与して遊ぶ企画へと昇華されて面白かった。
採用された理由は「ペアを組んで仲良くなってもらうこと、そして勝ったら更に仲良くなれそうな景品が用意されていることなど過程が明確に示されていたから。」だった。

②やってみたら面白そうな野外フェスの企画

「コスプレパーティー」、「ホールの中を真空にする」「ベルトコンベアで演者を移動」などのアイデアが出された。
ベルトコンベアのアイデアからは、「円形や空中など様々に移動ができ、見える側によって多様な解釈を産むイベントができる」といったように膨らまされた。
コスプレパーティーのアイデアからも、「開催側が服を全て用意し、メイクも指導してくれる。一つのテーマを決めてみんなで同じ服装をすることでライブの一体感を生み出すことができる」とまで膨らまされ、コスプレパーティーのアイデアが選ばれた。

③作ってみたいWebサービス

個人的に一番やってみたかったお題で、様々なWebサービスが生まれてとてもよかった。せっかくなので全部紹介します。
・日記を投稿したら「悲しい」「嬉しい」などの感情を表す発言によって音楽が自動で生成されるWebサービス
・人に渡せなかったプレゼントをネットに公開してランダムで受け取る・受け取れるWebサービス
・自分のテキストの続きがランダムに挿入されていくWebサービス
・ゲーム実況についての実況や感想を投稿できるWebサービス(ゲーム実況実況)
・文章を投稿するとAIによって多面的な角度から批評されて自己分析を助けるWebサービス
・物を持ち運ばなくてもいいように目的地に物があるかどうかが見れるWebサービス
・コーディネートを考えてもらって採用した人にお金を渡せるWebサービス

ちょっと言葉だけでは説明しづらい内容のWebサービスもいくつかあるのですが、様々な観点から作りたいWebサービスのアイデアが出てきてすごくよかった。もちろんこのアイデア群も参加者によって膨らまされていきプレゼンされていったのが面白かった。精神医学的観点によって論じたプレゼンを行う人や、「日記が音楽に変わることで他者からの反応がなくとも個人でも楽しむことができる」といった理由で推す人など、様々なプレゼンが見られたのも面白かった。
最終的に選ばれたのは「文章を投稿するとAIによって多面的な角度から批評されて自己分析を助けるWebサービス」でした。
④作りたいサークル
ここでは、「サークル会員がそれぞれ地図を作って紹介し合うサークル」や「日の出を各所で見に行くサークル」「猫を愛でるサークル」、「当番制で料理を振る舞うサークル」などのアイデアが出た。サークルの企画にゲーム性を盛り込めたプレゼンをしたり、そのサークルに所属することでのメリットやコミュニケーションの楽しさについてプレゼンが出てきた。
最終的に「当番制で料理を振る舞うサークル」が採用された。

全体的な感想

最初はすごく難しいのではと思ったが、カードを元にアイデアを出す作業は意外と苦ではなかった。
また、30秒以内でプレゼンをするというルールを設けることで「頭の中に出てきたアイデアをどんなものだったとしても殺させない(言いとどまらせない)」、「30秒以内でわかりやすく共感してもらえるプレゼン能力の向上」などのメリットがあると感じた。
そう、アイデアがどんどん生まれることもこのゲームの大事なポイントなのですがプレゼン力や共感能力を鍛えるゲームにもなっているんです。これ。
また、「自分以外のアイデアに乗っかって膨らませていく」という段階もすごく良いなと思いました。実際、元のアイデアよりも元のアイデアが膨らまされて出来上がったものの方がすごく面白く仕上がります。なので、他人のアイデアであっても自分で作り上げたもののように感じちゃうのです。

ゲームをやっていて、自分が考えたアイデアが採用されて勝つことと、他人のアイデアを膨らませてプレゼンしたものが採用されて勝つことがどちらもあったのですが、不思議なことに後者の時の方がかなり嬉しかったです…。(もちろん前者の時も勝者なので嬉しいんだけど、達成感が違う気がする)
これはちょっとした発見で、たとえ自分が最初に生み出した作品ではなくても、その作品を更に膨らませて良いものにしていく作業もすごく楽しいんじゃないかと思いました。これは今後、ものづくりの仕事をしていくにおいて良い発見だったなーと思います。

また、ゲーム性もかなりあります。実際、人に選ばれそうなアイデアのカードに乗っかりチップを乗せたり(いわゆる美人投票…)、投資家が好きそうなアイデアのカードに乗っかるといった戦略を考えたり。
複数人が乗っかりチップを乗せてるアイデアを選ぶのをあえて避けて、孤軍奮闘で闘って採用されたら賞金をたくさん得る、といった戦法ももちろんできます。

また、「自分が出したアイデアが二番目にベット(乗っかりチップが置かれている)されているときは一番目のアイデアを選ぶ、自分の出したアイデアが一番選ばれていたら二番目に置くと勝つ確率が上がる」といった戦略論を展開する人が現れたりもして、アイデア力やプレゼン力を高める以外にも様々な楽しみ方があることがやっていて明らかになりました。

このように、アイデアを考えるのが好きな人、プレゼンをするのが好きな人、ボードゲームをするのが好きな人など、様々な人が楽しめるとても良いゲームだと思います。

お値段はちょっと張りますが(4,216円)、仲間内で割り勘しあえば普通に買える値段になりそうです。(もしくは部費で買っちゃおう!これもサークルクラッシュ同好会の会計で買ってもらえました…)
何度も遊べて楽しいカードゲームなのでちょっと高いと思っても触って損はないな〜と思います。仲間内、学校、サークル、会社など様々なコミュニティで遊べるはずです。

まだまだいろんな遊び方がありそうなので今後もやってみたいです。参加してくださった方々、ありがとうございました〜。

フライパンでガトーショコラを作ろう #独身男性手作りチョコバトル

桐生あんずです。巷では独身男性手作りチョコバトルなる催しがインターネットで行われているらしい。それも兼ねてチョコを作った時のことを記事を書こうと思います。

(私は独身男性ではないですが、このイベントは独身男性でなくてもチョコに関係なくとも参加できるらしいです。)

 今まで私はバレンタインデーに手作りチョコを生成するにしても、湯煎で溶かしたチョコを流して市販のタルトの型(ロフトとかでよく売ってるやつ)に流し込むぐらいしかしていなかったのですが、さすがに22歳女子大生がこのような状態を貫くのはやばいのではないかという危機感に襲われるようになり、今年は何か手の込んだことをしたいとずっと唸っていました。

だが、一人暮らしの下宿先にオーブンなどない。炊飯器や電子レンジで何か作ることもできそうだけど、あんまりうまくできるか不安だなあとなりどうすべきかとなっていた時に大学の先輩のid:chidorimemoさんのこの記事を読んで、

バレンタインデーの手作りチョコでガトーショコラを炭にした話 - とりめも

ガトーショコラがフライパンでも作れることを知りました。

フライパンで作ってみるの、なんか手料理感があるし焼き加減もコントロールできるし楽しそう。よし、フライパンでガトーショコラを作るぞ!!!

f:id:kiryuanzu:20180215020605j:plain

まずはチョコ100gとバター一切れを湯煎(45~55度くらい。沸騰するくらいまで沸かしてしまうとチョコの旨味がなくなっちゃうらしい。)に溶かす。

溶かしたら、卵一個、ホットケーキミックス600g、砂糖大さじ2杯、無糖ココアパウダー大さじ2杯を一緒にかきまぜて、フライパンにクッキングシートを敷き、弱火で10分ほど焼いてみました。

f:id:kiryuanzu:20180215020718j:plain


なんか、こんな感じに焼けました。ちょっとこのままだと見た目が微妙ですね…。

なので、クッキーの型を使ってハート形や星型を作ってみました。

f:id:kiryuanzu:20180215020742j:plain

ちょっと可愛くなった。

ただ、これ失敗しやすい上に型の外側の余った部分が非常にもったいないことになる。なので全部に適用するのは断念しました。(余った部分は調理者が作った翌日の朝ごはんとして美味しくいただきました。)

f:id:kiryuanzu:20180215020748j:plain

星型を作ろうして失敗した図。

 

結果的に、一口サイズくらいに包丁で切ってココアパウダーとかホワイトシュガー(名前間違ってそう)みたいなやつをかけたらそこそこいい感じになりました。

f:id:kiryuanzu:20180215020752j:plain

f:id:kiryuanzu:20180215020756j:plain

わーい。

 

そんな感じで初めてバレンタインデーにほんのちょっとだけ手の込んだお菓子を作ることができました。味見してみたらちゃんとガトーショコラの味になってました。よかったです。1回分作るだけでも30分満たないぐらいはずだったのでお手軽です。フライパンは良いぞ。

 

作ったガトーショコラは、アルバイト先とその日会った人にあげました。ありがとうございました。

 

「入門コンピュータ科学 ITを支える技術と理論の基礎知識」を読んだ

桐生あんずです。
最近、プログラミング言語の教本を読み進めて勉強してはいるけれども、もっと根底の部分というか情報学の土台の部分をもっと知るべきなのではないかと思ってまずはKADOKAWAから出版されている「入門コンピュータ科学 ITを支える技術と理論の基礎知識」を数日間かけて読んでいた。

入門 コンピュータ科学 ITを支える技術と理論の基礎知識

入門 コンピュータ科学 ITを支える技術と理論の基礎知識

内容としては、1~3章はブール演算の説明から始まり、マシン語オペレーティングシステムといった情報学の土台の土台と言えるような話が続く。

個人的に、実学的な話だと強く感じ始めたのは4章からでネットワークの基礎の話が始まりサーバーとクライアントの構造やネットワークセキュリティの解説が参考になった。一番ハッとさせられたのが5章のアルゴリズムについての章で、どのようにコードを構築すべきかを具体的にイメージするプロセスが細かく説明させられていたのがすごくよかった。
コーディングがちゃんとできるようになるためには、問題解決をするためのプロセスのイメージを膨らませて具体化させていく作業がとても重要だとわかったので、今後開発をしていく中でも困ったらすぐネットの文献やサンプルコードに頼るのではなく開発における問題で何が起きているのかをまず捉えて、どのような対処をすべきなのかを書き出して捉える作業をしようと思った。
問題解決のイメージをどう段階的に膨らませるかについては、P209に紹介されていたポリアの問題解決の段階の定義をプログラムの文脈に置き換えた話ががすごくわかりやすかったので引用します。

第一段階:問題を理解する。
第二段階:問題を解く計画を考案する。
第三段階:計画を実行する。
第四段階:解の正確さと、それが他の問題を解くためのツールとなり得るかどうか評価する。
プログラム開発の文脈に翻訳すると、これらの段階は次のようになるだろう。
第一段階:問題を理解する。
第二段階:アルゴリズム的な手続きによって、どのような問題が解けるかのアイデアを得る。
第三段階:アルゴリズムを定式化して、プログラムとして表現する。
第四段階:プログラムの正確さと、それが他の問題を解くためのツールとなり得るかどうかを評価する。

これをちゃんと行うためには、問題を捉えることはもちろん大事で、問題を解決するために繰り返し構造や再帰構造をどう使っていくかといった「武器」の扱い方を理解することが大事だと思う。
私の場合、問題を捉えるところまでいっても言語に用意されている「武器」の使い方についての知識が乏しいせいで自分で考える能力がまだちゃんと身についてない状態と言える(つまり日本語の読み書きが不自由な状態…)ので、まずは武器の使い方を教本やサンプルコードで理解し、問題を用意して武器をどう使うべきなのかを自分で考えるといった勉強方法が必要なのではと思った。

6章のプログラミング言語について紹介された章も、5章と同じくらい重要なことが書かれていた。
プログラミング言語の形成の歴史から始まり、変数とデータ型、データ構造といった伝統的なプログラミング概念、オブジェクト指向プログラミングにおけるクラスとオブジェクトの概念などといったプログラミング言語の学習においてはかかせない常識が一から説明されている。
この部分に関しては、いずれかのプログラミング言語を勉強してから読んでみると、スッと入る部分が多かったと思う。もちろん早めに知っておくべき話ばかりなのだが、RubyJavascriptの基本的な書き方をある程度知った後に読むと具体的な使い方のイメージがすごくしやすいと思う。
7~9章もモジュールの扱い方やデータ構造、SQLなどといった開発においてはかかせない説明が多くあり、特にDMBSについての解説はまだ完全に理解できない部分はありながらも重要そうだと思った。
なので、一度で読み終わらすにはとても勿体無い本だと思ったので4~9章は定期的(まずは週一ぐらい)に読み振り返っておきたい。

なんとかして全体通して読んでみたけれど、文系非情報系エンジニア見習い的な立場としては情報工学の基礎を文字通り入門できた気がする本だった。
実際、同年代の情報理工系の人はこういった内容を1回生ですでにやっているのだろうと思うしやっぱり専攻の違いはデカいなあ…と今更ながら思った。そんなことを嘆いても仕方ないので、バイト先や個人開発でコードを書いて実際に学びつつ、彼らが授業で知り得ている内容は技術書をガンガン読んで知見を得ていくしかないのだと思う。
また、読んでいて難しいとは思うところはかなりあれど、「ああ、ここが知りたかったんだよ!!!」とずっと思いながら楽しく読めた。

自分が使っているプログラミング言語の教本を読み進めることも大事だけど、もっとこういった基礎じみたことを勉強したいなあとなったので基本情報技術者試験を申し込んでみた。
去年、プログラミング言語のことをあまり理解してない状態でITパスポートを取っていた時よりかは実学的なイメージで勉強ができそうなので楽しみ。
ITパスポートの時にもお世話になった栢木先生の本を書いました。のちのち午後問題の対策もやらないとなあ…。

そんな感じです。文系で情報系に入門したい方はかなりおすすめの本でした。ありがとうございました。

1/30~2/1に東京に行っていました

桐生あんずです。タイトル通りの話です。12月の東京遠征の際はプリパラのライブとコミケといった感じで趣味メインでしたが今回は会社訪問で就活メインで動いていました。

Twitterではちらっと社名は出していましたが、あんまり掘り下げて書いてはいけないお仕事に関する話もあると思うので抽象的な感じで今回の東京遠征を感想を書いていきます。つまりポエムです。恥ずかしいので短めです。

 

勉強会等で京都の会社のオフィスに遊びに行かせていただくことは何度かありましたが、会社訪問という体で行くのは今回が初めてでした。最初はすごく緊張していてどのように社員さんたちと話せばいいか不安でしたが、技術の話や会社のサービスの話をたくさんしてもらえて次第にリラックスできました。あと、こちらが作ったものも見てもらえてすごく嬉しかったです。

会社訪問ということで、オフィス見学がメインになるのかなと思っていたのですが想像以上にエンジニアさんや人事さんとフランクに話せて興味深いお話をたくさん聞けました。インターネットの人の話や、RubyKaigiやRailsGirlsの話もできました。RubyKaigiで知り合った方々とこの機会のおかげで再会することができたのも本当に良かったです。

 

また、3日間ずっとそれぞれの会社を回ったおかげで、それぞれの会社の特徴、福利厚生や働き方の違いをより深く考えることができて今後の就活を考えるにおいてかなり重要な経験になったと思います。

また、どの会社でも「ちゃんと手を動かしてて偉いね」と褒められたのがすごく励みになりました。

Twitterでも述べたことなんですが、子供の頃から使っていた身近なサービスの会社や今もよく利用させてもらっているサービスの会社の方々とここまで身近な距離で好意的にコミュニケーションさせてもらえることが正直まだ非現実すぎて、ものすごく動揺しています。

周りにすごい人がたくさんいるということもあり、自分の技術力に関しては本当にまだまだだと思っていて自信はあまり持てません。でも、今回の3日間の中でいろんなすごい人たちから褒めていただけて、「私が今までやってきたこと、やっていることに関してはちょっとだけ自信を持っても大丈夫なのかもしれない」と頑張って思うことにしました。正直まだまだ自信は持てないけれど、否定してしまったらその方々にすごく申し訳ないと思うので。

その気持ちを大切にして、自分が行きたい企業をちゃんと選んで就活していこうと思います。人生初の会社訪問でそれぞれの会社の状況を生で見れたこともすごく良い学びになったのですが、これからの就活に備えて自分への自信をちょっとだけ持てるようになったことが一番大きいと思います。

 

テストの疲れも癒えてきて、会社訪問も終えて日常に帰って来た気がするのでとりあえず2月,3月の具体的な目標とスケジュールをちゃんと立てようと思います。(遅い気がする)

就活が始まって人生がどんどん進んでしまっている気がして正直不安もちょっとありますが、止まらないように手だけは動かしていきたいです。体調も考えつつ。

そんな感じです。ありがとうございました。やっぱりポエムになってて恥ずかしい。

 

Railsのminitestで画像アップロードのテストをする際にpublic/system以下に余分なディレクトリを生成しないようにする

桐生あんずです。
以前に以下の記事で、
kiryuanzu.hatenablog.com
paperclipで画像アップロードをした際の画像テストのやり方を紹介しました。
ただ、このままの状態だと、テストするたびにpublic/system以下にディレクトリが生成されてしまう現象を確認しました。
このような何層にも連なる画像コピーファイルのディレクトリが生まれて、テストするたびに更新されています。
f:id:kiryuanzu:20180130133022p:plain
テストする際に大きな問題はないかもしれませんが、余分なディレクトリが毎回生成されるのは邪魔なので、生成されない方法を考えたいと思います。

どこかに手がかりはないかな〜と思ってpaperclipの公式リファレンスを見ることにしました。
github.com
Testingの章を探っていくと、似たような問題に言及している記述が。

Integration Tests

Using integration tests with FactoryBot may save multiple copies of your test files within the app. To avoid this, specify a custom path in the config/environments/test.rb like so:

Paperclip::Attachment.default_options[:path] = "#{Rails.root}/spec/test_files/:class/:id_partition/:style.:extension"
Then, make sure to delete that directory after the test suite runs by adding this to spec_helper.rb.

config.after(:suite) do
  FileUtils.rm_rf(Dir["#{Rails.root}/spec/test_files/"])
end

ここでは、FactroyBotを利用した際にテストファイルのコピーが発生するのでそれを避けるためにコピーファイルを指定のディレクトリに生成したのちにテストが終わったらファイルを削除する記述のやり方を教えてくれているようです。
rspecによる書き方ですが、minitestの構文に書き換えて同じことをやってみたらなんとかなりそうですね。

Railsテスティングガイドを見ていくと
Rails テスティングガイド | Rails ガイド

 # 各テストの実行直後に呼び出される
  def teardown
    # @article変数は実際にはテストの実行のたびに直前で初期化されるので
    # ここで値をnilにする意味は実際にはないのですが、
    # teardownメソッドの動作を理解いただくためにこのようにしています
    @article = nil
  end

teardownを使うことで各テストの実行直後にメソッドを呼び出すことができることがわかりました。

なので、config/enviroments/test.rbに

 Paperclip::Attachment.default_options[:path] = "#{Rails.root}/minitest/test_files/:class/:id_partition/:style.:extension"

と記述してminitestのディレクトリにコピーを生成するようにし、
テストを実行するファイルに

def teardown
   FileUtils.rm_rf(Dir["#{Rails.root}/minitest/test_files/"])
end

と記述し、指定したファイルをテストの度に消すようにしました。(FileUtilsはrubyのメソッドでファイルを消したり、他にも様々なことができるメソッドです)

そのように記述することで、無事不要なディレクトリが生成されることはなくなりました。いい話。

期末試験を終えての振り返りと法学部の試験勉強のやり方

桐生あんずです。先週の土曜日から始まっていた大学の期末試験が終わりました。

1週間プログラミングに関わることはお休みして大学の試験勉強&本番の試験という流れをずっとやっていたけれど、政治学や、日本史、法学などを中心とした法理念や学説を叩き込む勉強が中心だったのでプログラミングのことをやりたいのにやれないストレスもあいまって気が狂いそうになっていました。

大学4回生にもなり、試験への耐性もついてきた…と思いたいのですが毎回心も体も疲弊してしまうのであんまりついてないと思います。でも、試験のための勉強のやり方はなんとなく身に付いてきたかもしれません。
最近、周りをみていると法学部でいることの苦しみを語る若い後輩がたくさんいて1,2回生時代の自分ととても重ねてしまい辛い気持ちになります。その後輩たちのためになるかはわからないのですが、今回はどう勉強していったら法学部でも単位をうまく取ることができるのかを先輩からの伝聞や自分の経験を元にしつつ、簡潔にまとめていくエントリにしたいと思います。

大学にうまく馴染めなくて単位が取れない人のための単位取得メソッドっぽいエントリは1年近く前にも書いたのですが、今回はその続編的記事として読んでいただけたらと思います。(今更ながらタイトルだけ読み返して思い出したけど私って去年までは卒業できるかすら分からないレベルだったんですね。泣けてきた。)
kiryuanzu.hatenablog.com
前回は「難易度の高そうな試験科目をやらず、出席点やレポート点の多い科目を狙っていこう」という趣旨の話メインでしたが、人間どうしても試験を受けないと単位がもらえない時期がきます。ということで今回は試験科目メインの対策を考えていきます。
そんな感じで、箇条書きで自分が今回行った試験対策を紹介していきます。 (これは、あくまでも私のやり方なので相性が合わない法学部生はいると思われます。そこはご理解お願いします。)

・一夜漬けをやめる

単位がなかなか取れない法学部生のみなさま、普段どのように勉強をしていますか。これは私の予想にすぎないんですが単位を落としまくる6割くらいの人たちは一夜漬けして頑張ってみたけど残念ながら取得できなかった人たちなんじゃないかと思います。ぶっちゃけると私がそうです。

もちろん、暗記中心の科目で覚えることが少なかったり、試験問題が確実にわかっている科目でしたら一夜漬けでも十分乗り切れると思います。ただ、私が通う大学の法学部の専門科目は試験範囲が超曖昧かつ膨大なことが多いです。これを一晩でやるのは専門知識が元々ある人or要領がいい人以外ではないと普通に単位をもらうことは無理だと気づきました。そして私は要領が良くないです。

正直、大学で勉強する内容は人生において役に立つかわからない科目が多いです。第一次世界大戦の独ソ関係を覚えたところで将来役に立つことってほとんどなくないですか。だから、やる気が湧かずギリギリになって一夜漬けで頑張って覚えようとします。でも結局ヤマをかけていたところが出ない時もあるし、ここは出ないだろと思って勉強しなかったところが出ることもあります。そのような事態を考えると、どんなに学ぶ意味が見出せなくても最低でも3日、最長で1週間前から覚え始めることが私にとっての単位を取る鍵なのかもしれないと気づきました。

なので、今回は最低でも3日前から授業のレジュメを読み込んでまとめる作業を始めることにしました。結果的に、これ覚えられるのかな?と思っていた単語や判例が意外に頭の中に残ってて、そのような勉強方法で挑んだ科目の試験に関しては白紙答案で出すことは今回一切ありませんでした。
というわけで、一夜漬けで単位が取れない人は1週間~3日前からレジュメを読み込んでまとめる作業をやってみましょう。当たり前の話っぽいけど単位が取れないということは今の勉強方法が間違っているか先生が鬼畜かのどちらかです。一夜漬けができない脳であることを受け入れて試してみてください。(もしかしたら周りの友達に一夜漬けで乗り切る人が結構いるかもしれませんが、そういう人は法学についての予備知識があるか要領が良くて頭のいい人たちなので参考にしないほうがいいです。)

チームプレイをしよう

上述のエントリでも述べたかもしれませんが、私は授業に関することで人に頼みごとをするのがめちゃくちゃ苦手です。人の努力を利用して自分が楽をしているのではという罪悪感が湧いてくるからです。ただ、どうしても一人で授業を受けて試験勉強するのは難易度が高い時があります。そういう場合、やっぱり一緒に授業を受けている知り合いがいるかいないかで大きく変わるんですよね。4回生になったということもあり、来年度中に卒業も就活もできないとまずいので申し訳ないながらも今回は後輩や同期に頼る行いを増やすことにしました。

だけど、頼るだけなのは忍びない…ということで先輩からもらった楽単リストや過去問を後輩や同期に情報提供しつつ、見せてもらうといったトレード交換っぽい感じにして罪悪感を減らしました。実際、そうやって互いに協力することでお互い頼りやすくなって情報交換もしやすくなります。私みたいに罪悪感をこじらせて人にお願いするのが苦手なタイプの人は先に交換条件として何か情報を所持しておきましょう。

これも当たり前すぎる話だと思うんですが、難易度の高い試験科目の場合授業のレジュメが1回分ないだけでも致命的な場合があります。授業に行って自分でレジュメを手に入れ書き込むことが一番気持ち的には楽なんですけど、文化祭の準備で忙しくなる、具合が悪い時、等どうしても授業にいけない時は出てくるのでその時は人に頼るのが単位を取るためには大事な取り組みです。そのお礼に情報交換をしたりお菓子をあげるとWin-Winな人間関係が築けるかもしれません。

過去問をやろう

正直過去問をやるかやらないかで試験対策ってめっちゃ変わってきますよね。過去問の問題形式を見つつ、レジュメのどの部分を重点的に覚えていくかを探る作業が試験勉強において超重要です。だから過去問をチェックしないのは論外です。
あと、気づいたんですけど授業を取り始めた時から大学のmanabaページから先に過去問をプリントアウトしておいて、過去問の中身をチェックしつつ授業を受けたら重要ポイントを理解するにおいてめちゃくちゃ効率いいのでは?来期試してみます。

丸暗記は極力しない

私は割と丸暗記は好きなんですが、ぶっちゃけコスパ悪いし法学部の専門科目に向いている試験科目ではありません。でも別に暗記が悪という訳ではないです。問題をコスパよく解くためには記憶力が必要です。

法学部の専門科目の場合、制度趣旨や判例、学説を覚えることがメインだと思われます。正直私は数年前まで覚えると言ってもどう覚えたらいいかわかりませんでした。そんな中、プログラミングの勉強を趣味でやり出してしばらくした時、プログラミングの勉強と法学の勉強は結構共通点があることに気づきました。

プログラミングの場合、教本やチュートリアルをこなして写経するのは確かに勉強になるけどコードを丸暗記するだけなのはあまり大きな意味はなくて「このメソッドやこのコードの流れはどういう意味合いがあってどういう時に使うことができるか」を念頭に考えて理解する学び方が大事だと思います。これは法学も一緒でただ虚無になって条文を覚えるよりも。「どんな問題が出てきた時にどんな制度を使って、どんな判例を持ち出してどういった主張をもってどう解決すべきなのか」をイメージしながら制度趣旨や判例を覚えるとするっと頭の中に入ってくることがわかりました。
つまり法学部の専門科目の単位を取るためには高校でやったような歴史、政治経済、倫理の科目でやったようなただ事実を丸暗記していく解き方とかなり相性が悪いのです。
ということで、「この問題を対処するためにはこの武器(制度趣旨、判例、学説)が必要だ」とイメージして覚えていくと重点的に覚えたほうがいい判例や学説、制度が見えてきます。
例えば、売買契約で商品に隠れた瑕疵が発覚した問題が発生したときをイメージしてみましょう。損害賠償請求をするためには瑕疵担保責任を求めることになるけど、特定物か不特定物かを検討しなきゃとか、法定責任説か契約責任説をとるかどうかとか、そもそも売主に帰責事由はあるのか、とか問題を解くにおいて必ず考えるべき要点に触れることになるのです。そのような要点理解がいわば所持すべき武器であり、テストでもちゃんと書けるぐらい覚えるところなんだと思います。

要は自前の論理思考能力を駆使しつつ問題に対抗するための要素を把握しとけ〜って話ですね。自前のパワーも大事だけどそのためにはやっぱり覚えることが大事です。
法学部の場合、覚える内容が専門的なことが多いため勉強量を増やさないとどうしても単位が落ちる結果になってしまうんだと思います。辛い。

おわりに

法律系専門科目に試験に苦しむ法学部のみなさま、参考になりましたでしょうか。
ちゃんと単位をとってる人たちからしたら「当たり前すぎるでしょ」といった話ばかりだと思います。また、この方法を使わずともゴリ押しで単位を取ることだってできると思います。ただ、効率よく安定して試験で単位を取るためには人の力を借りたり暗記の仕方を工夫しないと難しいなあとこの1年で気づきました。
成績発表がくるのは3月はじめで、一体どうなってるか謎ですが4回生補正の力も加わってちゃんと単位がもらえていたら嬉しいです…。(結局補正頼み)
単位取得に悩む、法学部の方々も法学部ではない方々も頑張っていきましょう。ではでは。